I've been spending a fair bit of time this week talking to a journalist I've known for years, Danny Bradbury, for a series of features he's writing on the middleware strategies of some of the big enterprise software vendors.

After our first chat, something suddenly struck me (probably very belatedly): when middleware is talked about and sold today, what is being discussed is completely different to the stuff I first learned and wrote about in the mid 1990s. The difference is all to do with the meaning of the word "middle".

In the mid 1990s, "middle" meant "the gaps between applications and software components". Middleware was technology you turned to in order to try to build distributed systems: we were faced with transaction processing middleware, database middleware, object middleware, and so on—all different forms of middleware optimised for supporting different kinds of distributed software development paradigms. Middleware was a technological concept.

But with the birth of the application server concept in the late 1990s, which consolidated a lot of the popular distributed computing patterns of the time, together with the rise of web protocols and open-source alternatives to commercial web infrastructure, the idea of "middleware" changed fundamentally.

Now, when you see most of the talk about "middleware", "middle" means "the gap in a technology stack between an operating system and packaged applications". Middleware is now defined largely by vendors from a software product marketing perspective, rather than by customers from a technology perspective. Consider the portfolios of IBM, TIBCO, SAP, Oracle: they all talk about "middleware stacks", but these things include process management, content management, master data management, and business intelligence tools—and sometimes even DBMSs. [As a side-note, Microsoft is interesting because to an extent, it's gone in the opposite direction—building more and more "traditional middleware" capability and avoiding talking up the big stack.]

Why is the changing nature of middleware conversations important? Because, as I've mentioned before, the people and organisations that influence the language we use to describe things often end up in the best position to control what gets bought, by whom. By redefining "middleware" as being about ever-growing portfolios of infrastructure software, the biggest software vendors we have end up crowding out the propositions of smaller specialists.

So—should we reclaim "middleware", or should we just let it die a natural death?