Enterprise Service Busted?

Call it rage against the machine. In all the years I have been writing this blog I have never seen such outright vitriol about a solution as I've seen against Enterprise Service Buses. Nothing like it against UDDI, nothing like it against BPEL, nothing like it against anything Microsoft.

ESBs: an inconvenient truth?

Dave Linthicum recently announced how much he hates ESBs, and has taken a zero-tolerance stance against such solutions. He says they are the cause of dysfunctional messes. Jim Webber has always hated ESBs, but he hates all middleware. Loek Bakker once described ESBs as being like a one-day fly: serving some unknown purpose in the ecosystem, and being around only a short time.

Loraine Lawson likens ESBs either to junk-food prizes or parasitic weeds: "Perhaps part of the problem is that ESBs are becoming more widespread. ...you can practically get one free with every children’s meal these days. They’re proliferating like kudzu within the enterprise."

John Michelson says ESBs make SOA really, really, more complicated than it should be.

So ESBs are parasitic, short-lived pests that sap all the joy from life. What else is new? ESBs have been kicked around for years now.

There's been a fresh new wave of revulsion against this much-maligned middleware, kicked off by Rich Seeley's recent article which featured an interview with Michelson. John Michelsen talked about the issues enterprise architects are having integrating incompatible ESB deployments, and said the only hope for resolving things is through vendor consolidation.

I like John's description of the ESB phenomenon, which are the multiple elephants in many enterprise rooms. "This is the inconvenient truth that enterprise architects run into when designing projects that cross different ESB implementations in a corporate IT environment," he said.

Dave Linthicum said Michelsen didn't go far enough in condemning ESBs --that they are not something to be tolerated and worked around, but, rather, ripped out of the enterprise in favor of a simpler and purer form of SOA:

"Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you're left with a dysfunctional mess that's not easily corrected, and clearly costly. ...why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether? Because, call me crazy again, that would be cheaper."

Dave followed up on the post with some feedback, as well as this thought: "What I'm asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that's not occurring."

Loraine is in agreement with Dave that ideally, ESBs have no place in a well-functioning SOA-based architecture, but they have to be dealt with.  "I completely see his point, but I suspect rip-and-replace may be just too radical for most organizations – too difficult to admit mistakes were made, too hard to undo all the work you’ve put into an architecture, too expensive to start over."

I got John's reaction to Dave's post. The question that comes to mind is whether having ESBs -- even if they aren't compatible at the time -- may be okay at this relatively early stage of the SOA evolution. Is it necessary to rip out these mediators to move to a purer form of SOA mapped out by enterprise architects, as Dave suggests? Isn't SOA about service-orienting any and all approaches, no matter how ugly?

John says "that the greatest IT value of a service-based architecture is that it enables these things. With them I can be more responsive to business needs faster.  I'm also too much of a realist...  we have to try and refine over time."

The implementation technologies deployed under the service interfaces being consumed may not even matter, "so long as the governance and testability are there.  Why preclude any technology from making a contribution, especially one that is doing fairly well at the job like ESBs?"

Jeff Schneider also weighed in on the matter, noting that in an ideal world, somebody could wipe the slate clean of ESBs, but for now, they have to deal with the hand they've been dealt. (Not sure if Jeff personally loves or hates ESBs, though.) As he put it: "Companies are buying ESBs, will continue to buy ESBs, will buy products that are packaged with ESBs and will acquire/merge with other companies that have ESBs. They aren't going away - so yes, large companies will have to figure out how to deal with having more than one."

Readers, what are your impressions of the renewed great ESB debate? Are ESBs a creature whose time has come and gone? Or are they still a valid path to service-enablement?

[poll id=13]