There has been a bit of a blogging war going on over the last few weeks, starting with a post I made that, in essence, pushes back on the use of multiple ESBs (Enterprise Service Buses) in a particular enterprise. It was not the use of ESBs that bothered me. It was that perhaps there was not a lot of architectural thinking going on, and people are dragging ESBs into their enterprises for the wrong reasons.

While I've hit this topic about 50 times in the last four years, for some reason that post hit a nerve. Half of those responding said I was "spot on." The other half thought I was muckraking. The truth is, I've called ESBs into question since they hit the marketplace, and will continue to do so. My cautionary tales do not focus on the value of ESBs, but the fact that, in many instances, they are overhyped and overused, and, generally speaking, not a lot of architectural forethought has preceded the selection of an ESB, or worse, ESBs.

Backing up for a bit, ESBs really became a way to label JMS-based middleware, which was service enabled as "ESBs." Although Progress Software and the Gartner Group had a bit of back and forth on who invented the term "ESB," at this point it really does not matter. What does matter is that with the explosion of interest in SOA, almost all of those who had anything that resembled an integration server, message-oriented middleware, or a message broker, re-labeled their product as an "ESB." Thus, you had dozens of ESBs out there, all different, thus all supporting the notion of SOA differently.

Moreover, the use of ESBs were promoted as "SOA in a box"-type technology. While architects should have been going through typical business requirements analysis, they instead ran out and purchased ESBs in hopes that the answer would somehow come out of the box. Unfortunately, in many cases, they actually made things more complex, and thus worse. That was the essence of my argument.