New Buzzword, Same Mess?

Though so increasingly complex it’s now a “mess of spaghetti,” middleware is also rapidly becoming invisible.

“Middleware is spaghetti that just keeps looping and layering new approaches over old. The industry keeps ladling more sauce over the mess, in terms of such nebulous nomenclature as enterprise application integration, enterprise information integration, business process management and message-oriented middleware. New buzzword, same mess.” —James Kobielus, NetworkWorld

Remember the days when auto enthusiasts could open the hood of a car and actually do things more significant than adding windshield-washer fluid or coolant mix? Back in those days, knowing what a carburetor was mattered to parts manufacturers, suppliers, and mechanics. And it actually mattered to quite a few consumers. Carburetors were not invisible to consumers, they were something that humans could reach out and touch, attempt to understand, clean, and possibly even replace. But open the hood of a car nowadays, and all you’ll see is an unidentifiable mass of bulky plastic and metal occupying the entire engine compartment. That’s why, during a recent episode of the popular National Public Radio call-in show “Car Talk,” the hosts advised a caller that she would need to find a gray-haired mechanic to look at her 1970-ish Volvo; a mechanic any younger might not know what a carburetor was, and certainly would not have the proper diagnostic experience to assist her.

To those readers who write code for middleware, my carburetor analogy may not hit home, but to consumers and the rest of us, it just may. Consumers, for instance, don’t care about middleware. They don’t want to hear about it and they don’t want to think about it. As in my auto analogy, they only want to know how it performs for them. With today’s cutting-edge automobiles, technology, sufficiently advanced, now seems to be indistinguishable from magic. That’s true with software, too: Application-to-application software is even more in demand as we (in business and in higher education) all move to larger, more integrated, and more complex systems.

Middleware, Redefined
Today, the term “middleware” strikes me as a buzzword—a fashionable word that is used in a wide variety of contexts, but one that no longer is easily defined. Yes, it’s definitely “in the middle,” so in that vein, the term makes sense. Yet today, I don’t believe it’s a term that means much to anyone, except the relative handful of people who write it or who need it written. I wonder, even, if in terms of quantity, “middleware” might actually be the preponderance of all software, and if specific terms to identify other software might be more meaningful than having a specially-named category for what is, in actuality, the majority of all software.

Who Needs to Know?
Another common analogy to middleware is “bureaucracy.” Putting this analogy in people terms, a large government office is filled with people who function within that organization as human middleware. D'es the person walking into an immigration office to speak with a clerk care about who the clerk reports to and interacts with, within the organization? No. That person just wants to accomplish his own interaction with the government, and he wants to have it happen efficiently. Unfortunately for bureaucracies, it’s a lot tougher to engineer human behavior than it is to engineer auto parts or code middleware.

But, back to the car analogy. Do the users of application servers, content management systems, SOAP (Simple Object Access Protocol; a simple XML-based protocol that lets applications exchange information over HTTP), Web services, and other kinds of complicated (especially enterprise-wide) software really care about middleware, want to know what it is, or want to know what kinds of middleware are “inside,” and integral to the operation of their software? No. They just want it to work and help them do whatever they need to do with it. And even if they did want to know, the industry keeps changing the nomenclature in such confusing ways that it would take a real expert to know what is what—and users don’t need or want to be experts. And this reaction g'es beyond mere users, even to those working with information technology. Similarly, most of the people working in the automobile industry no longer need or want to know about whatever is replacing carburetors. In the software world this attitude may be more pronounced, if only because middleware is proliferating and changing at a speed that defies tracking.

Going, Going…

The term “middleware” is also sinking into the kind of wider-world-obscurity where all of our mysterious car parts have gone. Lots and lots of people write code for it and work on it, and seek to accomplish appropriate universal standards for it. And lots and lots of people are making money with it. Clearly, there would be no need for the annual Campus Architectural Middleware Planning (CAMP) Workshops (www.nmi-edit.org) or for Educause’s active Middleware Constituent Group (www.educause.edu) if that weren’t so.

We’re no longer in the early days of computing, however, when just about everyone who used a computer wanted to fiddle around inside it or play with edits to the software. In relation to the number of people who use computers and software, the percentage of those who know or care about middleware is diminishing even faster than jobs are being outsourced offshore.

That said, the importance of middleware—as is evident in this issue’s articles discussing all types of software used on campus—will not diminish. Like the various other “invisible” infrastructures that power or support not just automobiles, but air flight, bridge building, and other important parts of our physically built environment, middleware is boring when it works well, and should be transparent to the users. That d'esn’t make the prospects for its future any less exciting; it will continue to adapt and evolve, hopefully along with a growing set of standards for the sake of efficiency. So what if the next generation of humans d'esn’t acknowledge its existence?

comments powered by Disqus