Middleware is supposed to solve integration problems, but some say its proliferation may cause more integration problems than it solves. For instance, in November, ZapThink wrote a piece arguing that one reason SOA hasn't cut integration costs is because companies are using too much middleware.
Recently, I interviewed Craig Muzilla, vice president of JBoss at Red Hat. We chatted about potential problems with open source up the stack, JBoss's new product announcements, and the market in general. But since JBoss is Red Hat's middleware division, I couldn't resist asking him for his opinion on middleware and whether its proliferation inside companies is causing problems.
Is middleware causing more integration problems than it solves or is middleware integration, as ThoughtWorks chief scientist Martin Fowler and Dr. Jim Webber once put it, "a fat bloke with a beer belly and man boobs?"
People who don't regularly read my blog are always a bit taken aback by questions like that, so I rephrased the question.
"Are companies using too much middleware?" I asked.
Muzilla was a good sport about it, particularly for someone who makes a living developing and selling middleware products. The problem, he said, isn't the middleware but a lack of a common reference architecture:
"Most companies try to come up with a methodology or an architecture or a reference architecture and choose some best of breed pieces to that architecture and try to standardize. Then I would argue that that is not too much middleware, that's the right balance and you can achieve more efficiencies. If its too disparate and there are too many different components and too many different methodologies in there, yeah it becomes very, very difficult."
Another problem attributable to poor planning, it seems.
I jokingly asked, "What's the solution, switch everything to JBoss?"
"That's one answer," he chimed back.
Ultimately, Muzilla pointed out, middleware is about convenience. It won't work for all situations, but in general, it can help in 80-90 percent of situations:
"You don't need middleware. You could literally write code to solve any problem. The problem is that it's really tough sometimes to do that and middleware tries to close the gap by saying, "Okay, here's a way that you, Mr. Developer, don't need to write the code yourself to call these two services but there is something in between that provides the security, that does the beta transformation, that may translate messages. You know, there are some things that may help make your life a little easier.' That's all middleware is."
I think he makes a good point. Is it really fair to blame the middleware - to, in effect, blame the software messenger? Or is the real problem a lack of internal planning. Feel free to join our Knowledge Network discussion on this topic.