We have been hearing about enterprise mobility — the ability to deliver relevant data to employees with mobile devices — for over 20 years. In the 1990s the prevalent notion was to develop “fat” applications (requiring up to 256MB of RAM) for rugged Windows Mobile devices. While this notion worked then, it doesn’t scale for today’s consumerization of the enterprise.
For example, among the 20 million trucks in the U.S. transportation industry, less than two million drivers have handheld devices with a GPS to perform basic applications with fulfillment visibility functions. The reason for such low penetration is not the absence of a compelling business case or business need. The fact is, in order to fulfill such numerous and distinct needs, vendors would have to consider multiple applications and numerous backend systems across a fragmented and disconnected supply chain for each and every prospect. (See Leapfactor’s white paper “The Amazing Case of RIM and SAP”).
And yet, research firm Gartner, which coined the term Mobile Enterprise Application Platform (MEAP), reported early in 2010 that the MEAP market would top US$1 billion by the end of 2010, with more than 95 percent of organizations choosing a MEAP solution rather than point solutions through 2012. As Gartner defines it, a MEAP provides “tools and client/server middleware for mobile (targeting any sort of mobile application) and multichannel (highly device/OS- and network-adaptive) thick (offline) enterprise application development.”
This sounds so 1990s. Really, “thick” is the key concept, because these applications are full-featured, monolithic, and difficult to update quickly. MEAP was first designed to serve these applications to rugged devices used by truck drivers, sales people, and warehouse employees — devices that could be used wearing gloves. Enterprises can now deploy a MEAP to serve full-featured applications with offline as well as online capabilities, and IT departments can distribute mobile devices ready to run them. However, a MEAP in-house deployment is expensive, and involves complex process integration with backend ERP systems. The thick applications can take 9-12 months to build or update, and are limited to only users who understand their capabilities and are qualified to use them.
MEAP was not created for this new world of “cloud” Internet services, and of an unprecedented acceleration of the adoption of micro apps for the iPhone and other mobile devices. MEAP can’t keep up with this consumerization trend that has put a powerful cloud-accessing device in everyone’s pocket. It was designed for on-premise applications running on specific servers, and doesn’t scale to the wider population of workers. It lacks the dynamic allocation of resources available with cloud services.
Most enterprises need to communicate with all of their employees, partners, and customers — and all of them already have powerful cloud-accessing devices, and micro apps that they use as consumers. Regarding the debate over the issue of managing multiple mobile platforms, Philippe Winthrop suggests in “The Cloud is The Mobile Device: Mobile Platforms Won’t Matter” (The Enterprise Mobility Forum) that “within another 18+ months we just won’t care.” I believe that the cloud holds blue-sky opportunities (if you’ll forgive the pun) for enterprise mobility, and the way to exploit them is through the use of “thin” micro apps — just like the ones you use as a consumer with your iPhone — which can be built and updated quickly and provisioned to users automatically. The real opportunity is to enable as many mobile use cases as possible with these thin apps, and in a cost-effective and simple manner.
The need for more widespread enterprise mobility can’t be properly addressed with a costly and complex MEAP approach with thick applications. What enterprises can really use is the ability to deliver actionable data securely to all mobile users in the organization, without having to make complex requirements of their backend systems, and without having to build their own operational infrastructures.