Mobile Middleware Matters

I recently had a conversation with an IT vendor who asked whether mobile middleware still mattered. Is it still worthy of consideration, or is it simply a technology that users acquire more or less carelessly as part of a larger commitment to a particular vendor's server middleware, framework, or packaged application?

Thinking about the fate that has befallen many smaller mobile middleware vendors over the last couple of years I could understand the point of the question, but I came to this conclusion: Mobile middleware still matters because it's is as much a business-process decision as a technology selection.

As long as companies believe they can exploit mobile technologies to achieve business advantages over their competitors, they'll need to develop unique custom applications to meet those special requirements. And as long as they need to develop custom applications, they'll need to integrate them with enterprise back-ends via middleware. Different choices of mobile middleware can dramatically affect not only the technological effectiveness of an application, but its suitability in enabling that advantageous business process.

A while ago I came across a model from A.T. Kearney that classified IT according to three categories. The first category is described as "operational excellence": providing essential enterprise IT services at the lowest cost and highest reliability. This is probably the view of IT that Harvard Business Review had in mind when it published its now-notorious article, "IT Doesn't Matter" (Harvard Business Review, May 2003). Minimizing cost at this level usually argues for maximizing standardization and for implementation using off-the-shelf applications, typically with some minor customization, as much as possible. At the other end of the spectrum, A.T. Kearney described "white-space breakthroughs," business applications that are by definition innovative, even unique, and therefore almost certainly require custom application development (or an equivalent effort in customization), and, by extension, custom integration via middleware.

The middle ground between these two includes applications that reduce cycle times, increase asset utilization, improve processes, and increase service levels. These are common benefits of mobile technology, and are highly valuable without being the white-space breakthroughs of applications that support a reinvention of the business process.

It's here that the debate becomes most clouded. Some companies manage to standardize far more of the technology required to deliver such applications, or can even meet their needs with customized packages, leaving them free to focus their discretionary dollars on more strategic business requirements. If packaged software is to meet these requirements, it must embed extensive domain knowledge and must be highly relevant to the specific application area that the adopter requires. At the same time it must be flexible, not just in terms of the user interface but, more important, for workflow and back-end integration. Otherwise, the customization and integration efforts become as great as a custom-development project.

For companies that are able to adopt customizable packaged software for these kinds of projects, the middleware usually becomes irrelevant in the sense that it ceases to be a technology decision and instead becomes a product feature. In other words, instead of asking "does the application use a local database?", we ask "is the application available offline?" But for many other cases, custom application development is still necessary, and with it mobile middleware.

Now, it could be argued that it's possible for all of the above to be true and for middleware to still not matter in the sense of this question. It ultimately may be that a user simply acquires a particular implementation of a widely agreed standard, probably embedded in some more comprehensive software purchase. Many middleware technologies pass through such a process of stabilization and eventual commoditization. For example, at one time there was a thriving competitive market in TCP/IP stacks for PCs, with reviewers eagerly comparing features and performance of each new release. But over time the version that shipped with the operating system increasingly met most needs, and differences between vendors ceased to be meaningful distinctions.

However, what history shows us is that as one layer of middleware matures, the decision point moves further up the connectivity and complexity stack. For example, the decision becomes whether to use a Web-services approach rather than which vendor's TCP/IP implementation to choose. Historically, middleware decisions have floated above the waterline even as the tide rises. Furthermore, in the mobile realm we're still a long way from achieving the level of middleware maturity that the tethered IT world enjoys.

This brings us to the most important reason that mobile middleware still matters: in the mobile realm, questions of architecture--thin versus fat client, synchronous versus asynchronous connections--reflect choices of business process, and architecture leads to the choice of middleware.

These architectural decisions mirror business-process decisions as long as we live in a world in which networks are less than perfect and less than all-pervasive. The choice of architecture is essentially a business choice in which availability of functionality is traded against currency of data. The ability to use an application at all times (availability) requires local functionality and data, with independence from network connections. At the same time, the application must ultimately be connected back to the enterprise with a frequency determined by how current the data you use must be. For example, if you need to commit inventory with certainty--such as a specific seat on a flight--you'll need current, real-time data. The particular choice of architecture, and how it's carried out in middleware design, will determine the key characteristics of the application in terms of both currency and availability.

In other words, as long as business-process matters, and as long as technology platforms are evolving, then mobile middleware matters.

Carl Zetie is an analyst with Forrester Research.