I had the pleasure of joining Motorola, SugarCRM, and Funambol on a panel at LinuxWorld regarding the future of mobility. The depressing bit was that we panelists admitted that we could have made almost identical points three years ago: (1) the Web (1.0 more than 2.0) is coming soon to mobile devices, but the experience isn’t entirely there yet; and (2) the challenge to extending applications for mobile devices continues to be exacerbated by innovation in device profiles (more on that below). However, the good news is (1) that a “smart phone” profile is converging—a profile that is likely the right target for non-consumer mobile applications; and (2) that “over the air” sync to the native Personal Information Management (PIM) software on mobile devices has gotten dramatically easier/cheaper, and provides exciting new opportunities for mobile application extension.
As an old Web hand, I’m no doubt biased, but I think the Web is a generally the right model for business application extension to mobile devices, simply because the Web does not require any a priori installation of client-side software. After all, if the Web is already the dominant model for B2C and B2B applications on PCs, then it is arguably an even better architectural fit for lower horsepower (CPU, memory) mobile devices. Web 2.0/Ajax clients seem like a natural fit too—Ajax is a zero client install and its client/server interaction model is actually a better fit for higher latency networks like those of the wireless carriers. The challenge is that rich Ajax applications (ones with mouse-overs, drag ‘n drop, etc.) consume enough laptop CPU that they are still out of the computational reach of most smart phones/PDAs, let alone basic telephones.
The alternative application model to the Web (I include WML/HTTP under the Web architecture) is of course more traditional fat client applications—such as those programmed for J2ME, Windows Mobile, Symbian, Palm, or mobile Linux. Fat client app’s are ideal for PIM (email, SMS, calendaring, contacts, tasks), games, and other code that handset manufactures or the carriers are willing to preinstall, but a tougher sell for non-expert business and consumer end-user installation.
However, there is yet another approach that we proposed. It is particularly relevant for applications that can be surfaced via PIM software, such as your customer contacts from your CRM system, your travel itinerary from your procurement application, an urgent notification (via SMS), or even an email request to visit a particular URL. Such items can be submitted to a server like the Zimbra Collaboration Suite (ZCS), and then delivered to the mobile device via “over the air” sync. Zimbra Mobile, for example, can sync contacts, appointments, and messages to Nokia, Motorola, Samsung, Treo, and Blackberry smart phones, and both intranet and Internet applications can securely export to Zimbra over open/standard protocols. Putting the two together allows Web-enabled applications to deliver PIM-oriented data all the way to the mobile device.
So for applications that can be naturally surfaced via the native mobile PIM, there are now easier/cheaper options for mobile extension. For those business applications that have no such easy fit with PIM, I’m afraid you must still weigh the classic Web versus fat client architectural trade-off. In either case, I think that choosing the smart phone/PDA as the target profile makes more sense because of their relative consistency (screen size, scroll-to-click, J2ME vs. Windows Mobile platform), at least when compared with targeting the continuing stream of ever more compact, ever more personalized mobile phones.
Comments are closed.