Here's a truly fundamental question: what form will applications take as mobility becomes the dominant element in future IT solutions? Should we just keep doing what we're doing, handing out notebooks, duplicating (or replacing) the desktop, running great big applications locally, and using other mobile devices (wireless handsets, PDAs, ec.) only for simple apps like making phone calls, basic e-mail and messaging, and checking our calendars?
Or should we perhaps expect and demand more from our smartphones and wireless PDAs? Shouldn't these devices be platforms in their own right, hosting local applications and (perhaps much more importantly) providing remote access to intranet-based apps and Web services? Sure, there are user-interface issues inherent in smaller screens and tiny keyboards, but this situation should be manageable for on-the-go, anytime/anywhere access to information.
I'm at INTEROP in Las Vegas this week, where I Chair the wireless and mobile track, and my session at the conference was entitled "Platforms for Mobile Applications". This session was initially intended to look at alternatives for mobile operating systems, and there are a huge number of options here. But the real question we attempted to answer was the form or style that mobile computing will take going forward. The alternatives here are also many - we can continue to duplicate or replace the traditional desktop computer with a mobile computer (typically a notebook running Windows) that does the same thing, We can augment the desktop with a smaller mobile device that started as a PDA but today is fundamentally a communicator that can also cache personal and other information, we can use this device to remotely access the desktop and/or enterprise network, typically via a wireless VPN, or we can replace the traditional desktop/notebook computer by turning the handheld or similar device into a computer in its own right. All of these approaches are valid and all are well-suited to the real mission of mobile computing and communications today, which is accessing enterprise information wherever one happens to be.
But a bigger question is where the applications that manipulate information should reside. If they're on the fixed side of the connection, the mobile device can be substantially simpler than it typically is today. Imagine a desktop-class browser in a handheld, running Web-services apps remotely. This approach, however, won't work until we have ubiquitous wireless coverage, and that isn't going to be the case for a few years yet. So this implies that local execution of app code on mobile devices will remain the norm for some time. Apple, for example, has issued an SDK for the iPhone , and there is a wide choice of platforms for mobile devices, including my current favorite, LINUX.
From an enterprise perspective, though, users are pretty much going to have to follow the paths chosen for them by their key software vendors, including Oracle, Sybase, and SAP. All of these firms have mobile extensions to their product lines (such as SAP's NetWeaver Mobile that involve placing proprietary code on the mobile device. I don't think this is going to work over the long term, however. Sure, every software vendor wants to create enough infrastructure around their products that customers and users are locked in to the greatest degree. But openness and commonality built networking, and they must become the dominant elements in mobile solutions as well. They don't call this show INTEROP for nothing.
This closed-vs.-open argument and the where-should-code-run argument will dominate the discussion around mobile platforms for the next few years. The outcome will be the fundamental determinant of what we'll all be using when mobile for many years to come. My vote remains the same: clients that are as thin as they can be, but no thinner. My thanks again to William of Occam. If he were alive today, he'd work in IT.
Mathias is a principal at Farpoint Group, a wireless advisory firm in Ashland, Mass.
|
|
Why not messaging?
Every mobile device is able to send and receive messages, so why not extend this functionality to let it query databases? You send your query via a message and the answer is sent back instantly, see www.mobiledatanow.com for software which does this.
Well...
This certainly works, but it's clunky and a bit of a kludge.
Thx. Craig.