November 19, 2009, 4:58 PM — At the Interop New York conference this week I've seen a lot of product and service demos. Many have shown mobile enterprise applications, but most have danced around the issue of which handset is going to be used for delivering the app. The general assumption is that the organization will standardize on a single platform, but that assumption flies in the face of most conference presentations here, which have centered on the growing trend of allowing (or forcing) employees to provide their own mobile handset for business use.
If employees are bringing in their own phones and you can't count on everyone having the good taste to choose the Blackberry/iPhone/Android/Windows Mobile platform, how can you economically develop applications that span a variety of phone types? You really have only a couple of choices right now: Web or framework.
The web is an application delivery platform that lots of companies have chosen, but we can all agree that it's not the optimal solution for most smart phones. Even if you factor out the differences in browsers and their capabilities, you're left with different display sizes and image rendering. While it can certainly be done, developing web apps for multiple mobile phones currently falls into the "their has to be a better way" category of projects.
Developing native apps is the way to go, but very few companies have the resources or the desire to develop separate applications for every possible smart phone. AT&T, in the business of selling both bandwidth and phones, also has a mobile application framework that I saw here at the Javits Center. The advantage of the framework is that applications developed using its capabilities will run on approximately every handset that AT&T supports. The disadvantages are, of course, that it requires you to use AT&T's network and buy its phones.
One of the nice things about the AT&T Control Center framework is that it both allows for widespread distributing of the application and provides for central application reporting and management. In a growing mobile enterprise, that back-end management may ultimately be more important than the specific phones on which the application is deployed. I was impressed with the general capabilities of the framework, though I didn't have the opportunity to sit down and spend extended time with it alone. I suspect that we're going to see many more of these develop as the idea of open access becomes a political necessity for wireless providers. It will make less and less sense for companies to lock their employees into a single platform when the carriers are busy opening their networks to all.
That future is going to be interesting to watch, and the information I've seen this week tells me that it will be less single-platform simple than most managers would like. The good news from that fact is that we'll be able to get a good idea of which platforms work best in most situations. The bad news is that we'll have to deal with the less-successful platforms along the way.
Since this is my first Mobile Enterprise blog post, let me tell you just a bit about how I'm approaching this. First, don't look for much in the way of personal mobility coverage here. My fellow blogger Mike Elgan has that covered over at Brains Without Borders. Instead, I'll be looking at the products, practices, and services that allow for mobile work and applications on an enterprise scale. Now, I'm going to define "enterprise" pretty broadly since there are some great mobile technologies that allow small companies to compete more vigorously with large companies. The key will be that I'm looking at the business side of things -- a side that should keep me very busy.
Let me know what you think, and what you want to see me cover here. I'm going to be doing a lot of blogging, but I'd like this to be a conversation rather than a lecture. I'll look forward to hearing from you!
