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?