SOA in Action Blog

Joe McKendrick

Move That Bus! Time for an Extreme SOA Makeover?

user-pic
Vote 0 Votes

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.

__________________________________________________________________

No TrackBacks

TrackBack URL: http://www.ebizq.net/MT4/mt-tb.cgi/11903

1 Comment

| Leave a comment

Joe, I've been thinking through this a bit as I read through Dave's and now your posts on this mis-use or over-use of the service bus. What I am trying to understand is how you would manage abstraction without the bus. Specifically looking at composite applications and business process composition, if you have business services that are used in multiple apps or multiple business processes how do you manage that abstraction without a bus? I understand if you have a process specific service, or a fine grained service that is unlikely to see reuse that this level of abstraction is not necessary, or is that the point? Is it just a matter of understanding the business use/need of a given service to determine the level of abstraction required? And obviously the other attributes of the bus around content based routing and transformations.

Thanks for a good, thought provoking article...well, between you and Dave! :)

Leave a comment

SOA in Action Blog

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. Joe is also SOA community manager for ebizQ, and speaks frequently on Enterprise 2.0 and SOA topics at industry events and Webcasts. Joe also authors ZDNet's SOA blog. He also serves as lead analyst and author of Evans Data Corp.'s highly regarded bi-annual SOA/Web Services and Web 2.0 surveys. Joe writes a regular column for Database Trends & Applications, and has authored numerous research reports in partnership with Unisphere Research for user groups such as SHARE, Oracle Applications Users Group, and International DB2 Users Group. In a previous life, Joe served as director of the Administrative Management Society (AMS), an international professional association dedicated to advancing knowledge within the IT and business management fields.


Subscribe



Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives

ADVERTISEMENT