SOA in Action Blog

Dave Linthicum has created quite a stir across the blogosphere with his pronouncements that enterprise service buses (ESBs) should be parked, out of the way of the growing stream of service oriented architecture traffic. Not only that, enterprise service buses are blocking our view of the wonderful new SOAs under construction.

Dave first stirred the pot a couple of weeks back with an InfoWorld post in which he declared that ESBs 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. ESBs, he said, don;t solve dysfunctional integration messes -- they only create more messes. “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, here at ebizQ, Dave has elaborated further on his anti-ESB stance. He notes how some vendors and analysts in recent years have promoted ESBs as "SOA in a box"-type technology. I completely agree with his point that "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."

Dave also cites a quickie poll I posted over at ZDNet which asked readers whether they found ESBs to be an effective platform for SOA. Forty percent said that it really doesn't matter if there are ESBs down there or not, since SOA should be neutral to underlying solutuons. However, as Dave points out, another 28% said they felt "ESBs create costly messes." Twenty-eight percent means more than one out of four feel this way, which is nothing to sneeze at. As Dave elaborates:

"Perhaps this proves my point that they were dragged into the enterprise for the wrong reasons, and without the proper amount of planning. Typically, there is no holistic architecture defined and the enterprise is a huge collection of one-off tactical solutions that don't work well together. Thus, the architecture is fragile and static, the opposite goal of SOA. At least the way I define SOA."

Dave says ESBs are too often deployed as short cuts around the long-term, deliberative work that goes into SOA. And they get misplaced. As Dave puts it, "they are typically repurposed messaging systems with services interfaces built on top of them. Thus, some ESBs have issues with how they deal with true service behavior, and are really just service-oriented message brokers when you get right down to it." He adds, however, "in some instances, your architecture may need a service-oriented message broker, or an ESB. The ESB still needs to be within the context of a much larger architectural plan."

There are many, many companies out there with ESBs (or middleware integration brokers of some kind or another), and rips and replacements will be a costly industry initiative. In in most cases, they work for their intended purpose. SOAs are not going to be pretty, and indeed, many will even end up as downright strange contraptions. But the purpose of SOA is to ultimately abstract any and all underlying technology, and bring islands of integration together, including ESBs.

__________________________________________________________________