When deploying mobile applications to your mobile devices, there are two fundamental choices available: Rich mobile platforms or mobile Web-based services in the cloud. The first is native application execution directly on the mobile device -- that device being essentially a mini computer with a very rich application environment that includes storage, networking and communications, and a graphical user interface. On the other hand, the mobile Web-based services/cloud-computing model has obvious appeal, as these rich-platform mobile devices probably have a serviceable browser, and there's a good chance that your client/server infrastructure is already fairly Web-centric. As we'll explore this month, though, neither of
We're transitioning to a back-to-the-future IT model -- but that transition is going to take a while. OK, I'll be the first to admit that sounds like a bad Japanese horror film and, as you'll see below, the factors that complicate setting a strategy for mobile applications deployment can indeed seem like one. On the one hand, we have the model that IT has grown up with: The everybody-gets-a-CPU, local-application-execution model that's both familiar and effective. Take, for example, the iPhone, with 75,000 mobile applications, and the mobile application stores that are now being established by carriers and other handset and mobile OS vendors. Looks like the way to go, right? Not so fast.
There's a danger lurking here, however, in locking your company to a particular mobile device, which makes carriers and handset vendors happy but may not be a good economic or even practical choice for your enterprise. There are also device-independent development environments, but those are a viable option only if the enterprise is developing a custom application itself. Whatever the case, local apps are the time-honored approach and usually work very well.
On the other hand, cloud services and browser-based remote apps have a lot of appeal because they are device-independent (assuming a serviceable browser on your particular mobile device, of course) and because so many apps simply won't run standalone on handsets because the data they require is so voluminous that a big server on the other side of the wireless link is the only practical solution. But we run into the big drawback in this alternative: A gap in coverage that is potentially fatal. But the carriers are working hard to include additional broadband, voice, and even Wi-Fi services into their networks and mobile devices and the chances of getting a usable connection improves every day. And, to the point, many of those 75,000 iPhone apps are really just front ends for Web and cloud services. They won't do much at all without a wireless connection to the Web.
The only real drawback today to adopting the mobile Web-based services model entirely is this fundamental variability in connection reliability. But there's also the argument that these solutions look more like the timesharing of the distant past, and this is indeed true to a very great degree. But keep this in mind: In the olden days, we shared computers because processors and storage were expensive. The data itself was fairly cheap and mundane. Today, computers and storage are cheap, but the data is expensive in terms of its value -- careers and indeed lives often depend upon reliable access to whatever's needed wherever the user happens to be. Since so much data is being created on the fly, and since it would be impossible to store everything locally anyway, the cloud model is ultimately going to win. The carriers are continuing to build out 3G and 3.5G capacity, and 4G services like WiMAX and LTE are going to become much more common over the next five years. Eventually, multi-megabit service with excellent reliability will be so common that we won't give connectivity a second thought -- exactly how we think of landline broadband services today!
The bottom line here is that mobile Web and cloud-based solutions are just another instantiation of one of the hottest trends in IT -- software as a service (SaaS). This, too, is yet another incarnation of our back-to-the-future friend, timesharing. But, again, keep in mind that we're most importantly timesharing the data; the client/server model is still entirely intact. To bring the argument full circle, though, it's important to note again that -- while many locales are just fine -- we really don't have continuous connectivity in every location today. So for the next couple of years, anyway, think hybrid solutions -- a combination of rich mobile platforms and cloud/Web/SaaS capabilities for your mobile application strategy. This model could in fact have very long legs: Even as connectivity becomes continuous and services become more cloud-based, applications being built today around the rich-platform model won't become instantly obsolete, and ROI isn't necessarily imperiled. Nevertheless, in making the decision as to which way to go, my usual advice still applies: Start with the data (what it is, who needs it, under what circumstances, and how it should be tracked and secured), and then put in place the applications and network services required to make it fly.
About the author: Craig J. Mathias is a principal with
Farpoint Group, a wireless and mobile advisory firm based in Ashland, Mass. The company works with
manufacturers, network operators, enterprises, and the financial community in technology assessment
and analysis, strategy development, product specification and design, product marketing, program
management, education and training, and the integration of emerging technologies into new and
existing business operations, across a broad range of markets and applications. Craig is an
internationally recognized expert on wireless communications and mobile computing technologies and
has published numerous technical and overview articles on a variety of topics.
This was first published in October 2009