In-Depth

Software applications infrastructure: The “new middleware”?

• By Steve Garone
• February 1, 2004

Let’s be honest. How often have you recently seen or heard an IT vendor use the term “middleware” -- especially in regard to its products? In recent years this term has been pushed aside in favor of the ultimate vision of an integrated software “stack.” The introduction of the Web services model into the mix has forced the evolution of IT architecture, as instantiated in the notion of the Service-Oriented Architecture (SOA), which leverages this stack as an integration model. It’s no wonder the middleware moniker left the lexicon.

This is why I was surprised recently to see a billboard, sponsored by a very well-known IT industry leader, with the word “middleware” prominently featured. Surprise quickly turned to understanding after thinking about how deployment environments have changed over the past few years.

It is important to note that much of the application- and industry-agnostic competitive action around many traditional middleware elements is virtually gone. For all practical purposes, you either choose J2EE or .NET as enabling technologies. Even major J2EE application server vendors are working closely together to lessen the barriers to universal deployment among their products. The XML standards that govern how Web services are built, deployed and managed have served to neutralize many of the integration-related value-adds that some vendors enjoyed. The result: With some minor exceptions, the core application server, which for the past few years has served as the foundation for the middleware required to build solutions based on a multitier architecture, has essentially been commoditized.

If this is the case, what exactly should those developing solutions view as “middleware”? The answer lies in an understanding of how vendors are approaching the software stack as a means of implementing the SOA. More and more functionality -- from portals, to BPM engines, to application frameworks -- are being provided by a variety of companies, most of which also enjoy the advantage of a significant “platform” installed base to which this stack can be sold. In some cases, all or most of the stack is being productized as the application server itself -- in all likelihood, as a means of countering its being viewed as a commodity.

The AlignIT Group has been observing vendor and enterprise activity in this area, and has created a model, which it calls the Software Applications Infrastructure (SAI). [Go to http://www.alignitgroup.com for additional information on this model and research programs.] Simply put, SAI describes a set of tightly coupled but interoperable software elements that in total represent all that is required to build, deploy and manage multitier applications as an implementation of a SOA. The SAI model distinguishes an integrated vendor offering from a traditional application server based on the additional functionality a vendor provides, and the degree to which all elements of the offering operate in an integrated fashion. It is important to recognize the difference between a collection of software functions and a truly integrated product. The latter facilitates installation, application development, deployment and management. All of these help make enterprise use of IT -- throughout the application life cycle -- more efficient and cost-effective.

Indeed, research recently performed as part of our IT Alignment program supports the importance of low-cost and fast time-to-market for new and enhanced applications -- two metrics that an integrated stack supports. For example, more than half of the enterprises that have recently purchased and used IDEs for software development report budgetary issues as the most significant barrier to procuring that product type, more by far than any other barrier. More than 65% of them took less than six months to make their decision, and more than 70% are relying on internal IT staff (more than any other option) to build solutions using the IDE and other tools (both of these indirectly imply that bringing applications online quickly remains a high priority). Finally, in our examination of user experiences with IDE (and other) products, time and ease of deployment are consistently of great concern. Java will become even more important than it is today as an enabler to effective cross-platform deployment.

So, while middleware appears to be regaining visibility as a piece of terminology, its meaning has grown to encompass much more than point products that delivered functionality supporting data access, transactions, messaging and so on. It also encompasses more than just the application server or other individual functions that reside on a middle tier. The definition now includes it all -- and users are increasingly demanding that vendors distinguish their offerings based not only on performance and reliability, but also on how quickly, and inexpensively, solutions can be built and deployed. Look to the “platform” vendors -- companies such as IBM, Oracle and Novell -- to lead here.

Yes, folks, middleware is back ...

Please see the following related stories:
“Do tools matter?” by Michael W. Bucken and Jack Vaughan

''Tool talk''