We've established in part one and two of this series (see sidebar) that mobility will ultimately be just another part of an enterprise's architecture. Enterprise applications will have mobile attributes just as they have security, networking and data storage components. And there will be a common set of processes for managing and integrating mobility. However, the challenge remains in getting from here to there, and doing that requires us to confront the dual crises created by the proliferation of disparate mobility architectures and the lack of established mobility processes.
In other words, we've got to clean up the mess we're making today.
What's this mess?
Readers may be quick to point out that everything is going fine with their mobile deployments. Aside from an occasional media drama about BlackBerry, BES is doing fine, new devices are coming out, and everyone is happy. And that's a good point. Everything is fine.
And yet, there are storm clouds on the horizon. Will these architectures scale? How will we integrate them with our existing computing environments? And how will we deal with the hordes of end users who want to bring all sorts of mobile devices into the enterprise? Will we be able to simply barricade the doors to the IT department?
And what will happen when someone on the executive team wants an iPhone? We certainly jumped when the C-level executives asked for BlackBerry and that's what we have today. But what about the time when a new, consumer-oriented device becomes a "must have" for every top manager?
The questions are myriad and the answers are few. The point about the "mess" that we're in is that we're going to have to clean it up sometime.
Mess #1: Architecture
The simplicity of solutions like BlackBerry and Good is the security and control that a vertically integrated platform provides. We can argue about degrees of integration, but these platforms have been designed to provide standalone mobility in conjunction with a corporate email platform like Exchange, Notes or even GroupWise. From an enterprise perspective, the aforementioned mobility platforms offer sufficient security for large corporate deployments. Other mobility solutions are available as well, and Microsoft even makes mobile email a free upgrade to Exchange – the price is less appealing than the promise of corporate-wide integration with architectures and applications.
Most leading mobility platforms are, in a word, "middleware." This can have both positive and negative connotations for enterprise architects, but mobile middleware is necessary to provide features critical to mobile applications. These include: synchronization, data management, maintenance of application state, user permissions, and security. These mobile platforms often rely on corporate directories for user information and create additional local user and directory information for mobility-specific purposes. Integrating this information back into central directories can present a challenge down the road.
As enterprises migrate to service-oriented architectures (SOAs), composite applications and Web services, it is unclear what role existing mobile middleware will play in these frameworks. Clearly, mobile middleware will be with us for quite some time, as it will take decades for companies to phase out the software they are using today. The architectural challenge will be to migrate mobile features from standalone mobile middleware platforms to company-wide mobile services.
One last architectural issue for mobile middleware is the issue of scalability. Despite a growing number of users on mobility platforms, we know little about the scalability of approaches like BlackBerry. Virtually every technology faces a limit to growth, and we know that such limits exist for mobile middleware. What we don't know is how those constraints will manifest themselves. Is the limitation in the software, the network, or the approach that packages software and hardware as a bundle?
This last question raises an issue of process that is the second mess that we will need to clean up.
Mess #2: Process
The appeal of BlackBerry is easy to understand – a well-designed product that delivers as advertised out of the box. This has translated into thousands of enterprise deployments, millions of subscribers and healthy margins on BlackBerry devices. There are many reasons for this success, but one worth mentioning is the process inherent to the solution. There are few variables, a limited number of devices and a great deal of control. Want BlackBerry mobile email on your corporate email account? Then you have to go through the IT department.
In a nutshell, solutions like BlackBerry and Good have placed the IT department in the center of the process for provisioning devices, users and accounts. The process is inherent in the platform and the solution, so IT departments don't have to spend months (if not years) figuring out the process for purchasing the device, identifying the user, provisioning services and enforcing policies. Anyone can buy a BlackBerry and use it for mobile email, but it takes another step to involve the IT department and get that corporate email account onto the device.
The BlackBerry approach is simple, contained and cost-effective. The process is part of an architecture that was designed at a time when mobile telephones were limited in terms of computing power, display, text input and battery life. The current generation of mobile telephones – even the low-end devices – can play music, store files, and send text messages and even emails.
And thus we're at the proverbial fork in the road. We have two choices ahead of us. We can stick with solutions that define process for us, or we can accept the inevitability of mobility and start working on a far more complex set of processes for defining the services we will deliver to mobile users and devices. Implicit in this latter approach is an acceptance that the selection of a mobile device is highly personal and a choice that we expect will remain with the user.
Two worlds
Is there a crisis for mobility? That's largely a matter of perspective. Many IT organizations are confident that they will be able to maintain centralized control over mobile devices, users and applications. For these managers, the processes are simple, the devices are defined and there's one way to do things. In this world, there are no crises.
On the other hand, as users camp out, line up and wait for new devices like the Apple iPhone, it's clear that there is a great deal of energy and enthusiasm for mobility. The dominance of retail outlets for mobile devices, including those destined for enterprise duty, has become a foregone conclusion. And companies that accept this view of the world face a number of challenges in defining architectures and processes for incorporating user-provisioned mobile devices into enterprise computing environments.
If you see user provisioning – at one level or another – as inevitable for the enterprise, then read on. The rest of this series will address the forthcoming architectural and managerial challenges facing IT departments in delivering mobile services to users who select, purchase and choose their own mobile devices.
About the author: Daniel Taylor is managing director for the Mobile Enterprise Alliance, Inc. (MEA), and he is responsible for global alliance development, programs, marketing and member relations. He brings over fourteen years of high technology experience and is well known as a subject matter expert on many of the aspects of mobility, including wireless data networking, security, enterprise applications and communications services. Prior to the MEA, Dan held a number of product marketing and development positions in the communications industry.
