Multiple ESBs Causing Problem, but Nobody's Listening

Loraine Lawson

The ESB (enterprise service bus) is perhaps the most controversial of tools used for integration and SOA. I say perhaps only because I could've missed something -- but I really can't think of any other integration-related technology tool that's so widely adopted and yet generates such debate over whether and how it should be used.


Perhaps part of the problem is that ESBs are becoming more widespread. As I've said before, you can practically get one free with every children's meal these days. They're proliferating like kudzu within the enterprise.


Ironically, there are so many found in enterprises these days that ESBs are creating integration problems of their own, according to John Michelsen, chief architect at iTKO Inc., who's quoted in this TechTarget article on the problem:


"There's a whole space emerging among enterprise architects called ESB intermediation. They're finding that two or three different divisions of their company are using different ESBs from different vendors. Yet they're trying to build business processes across these ESBs. But the ESBs are designed to be their own center of the universe. How do you intermediate transactions across these ESBs?"


I actually found this article via David Linthicum's Real World SOA blog on InfoWorld. Linthicum was pretty annoyed by the whole topic -- you could practically see his veins throbbing just reading the post, particularly when he wrote, "Okay, there are so many things wrong with this I don't know where to start."


But he managed. And how.


His first point: This shouldn't be happening because you should have a centralized SOA plan and an enterprise architect overseeing it who can stop this sort of silliness.


His second point is my favorite, of course, since it ties back directly to integration and better explains why this is such a problem:

"Second, considering that my first point is correct (which it is), 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. The fact of the matter is that integration engines mediate the differences between multitudes of systems using very different approaches. Thus, having two or more ESBs within your enterprise means that you're dealing with two or more very different approaches to information integration, and service mediation."

This wouldn't be happening, he continues, if companies would take the following steps in order:

  1. Determine your requirements.
  2. Determine the solution patterns you need.
  3. Buy the technology you need to fulfill steps one and two.

Identify the problem, make a plan and then find technology that makes that plan work? Linthicum, that's just crazy talk. Madness, I say!


Sorry if I seem flippant. But his post cracked me up. After all, this is exactly the type of situation Linthicum's been warning about for a long, long time.


Linthicum's an advocate for clean, working architecture. He even suggested in a recent piece for ebizQ that companies should just redo their enterprise architecture if it's too dysfunctional. Partner integration was justification number two, by the way.


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.


Then again, companies may not be concerned about multiple ESBs simply because they get conflicting advice about it. While some experts, like Linthicum, think it's bad design, others seem to think it's no big deal and, in fact, can be useful. As I wrote back in December, one company thought having two was a great option, because they could serve as backups for each other.


On the other hand, it must be something of a problem, because SOA Software even offers a product - Network Director 4.0 -- to mediate multiple ESBs.


Common sense makes me think it would be better to have fewer things to integrate than more, so Linthicum's argument makes more sense to me. But then again, what do I know? Maybe common sense has no place in modern IT architecture.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jul 21, 2008 12:58 PM Rob Eamon Rob Eamon  says:
Linthicum appears to be assuming a clean slate. M & A activity all but guarantees multiple tools.Even within a company, divisions that hitherto never interacted but now suddenly need to for any of a number of reasons will face the same issue. A solution "based on the requirements of the business" (back in 2003 or whenever) is just as likely to have introduced the situation as is the chasing of shiny new technology.Federated ESBs is a valid approach. Standardizing on one ESB (or eliminating them altogether) just for standardization's sake is foolish--especially after the fact. In some cases, it might be completely unnecessary and ESB "bridges" may be exactly the right answer for a given situation.I agree with Linthicum's conclusion about normalizing the existing technology. It's *likely* to be the right thing to do. But the assumptions leading up to that are high on hyperbole."Common sense makes me think it would be better to have fewer things to integrate than more..."Then are you an opponent of SOA? Following SO principles tends to create more, independent moving parts, not fewer. Reply
Jul 21, 2008 1:10 PM Loraine Lawson Loraine Lawson  says:
Good point about the SOA - although, isn't it supposed to make them easier to integrate? Reply
Jul 21, 2008 1:15 PM Rob Eamon Rob Eamon  says:
"Yet theyre trying to build business processes across these ESBs. But the ESBs are designed to be their own center of the universe. How do you intermediate transactions across these ESBs?The same way one builds processes and intermediates transactions that involve external parties. It's done all the time, isn't it? Company A has a process, part of which involves interacting with Company B. Company A has ESB X while Company B has ESB Y.Why is this being presented as new problem? Reply
Jul 21, 2008 2:02 PM Rob Eamon Rob Eamon  says:
"Good point about the SOA - although, isnt it supposed to make them easier to integrate?"Certainly. Does the use of multiple ESBs make services less reachable or discoverable? Less easy to integrate? Strictly speaking, no, not IMO.In an SO approach, the ESB is simply an interface host. It might also host the service implementation but consumers don't care about that.The consumer would just connect to the appropriate URL (assuming a WS interface for the moment) for the service it wants to use. It connects to the URL which is part of the service contract. The consumer has no idea it is talking to an ESB. So it shouldn't matter if it is talking to ESB A or ESB B.If for some reason, the consumer is not allowed to talk to the particular URL directly (security, network issues, whatever) then it may make sense for the "local" ESB to serve as a proxy. But to the consumer, it makes little difference. It gets configured with http://xyz.com/service/saveTheWorld instead of http://abc.com/service/saveTheWorld.Bridging the ESBs in this case could be any of a number of forms, including the most simple: the local ESB simply connects to the remote ESB using the URL that the original consumer wanted to use (firewall rules allow the local ESB server to connect to the remote ESB, perhaps, but nothing else). The local ESB has no idea it is talking to another ESB--and doesn't care. As long as the interface provides the contracted behavior, everything should come up aces.I may be oversimplifying the example here, but IMO Linthicum is overstating his case. Multiple ESBs and potentially bridging them in some fashion is not necessarily the flat-out wrong notion he posits.Sure, it isn't an optimal situation to find oneself with multiple ESBs. I fully agree with him that a holistic plan is a Good Thing and that "normalizing the existing technology" is likely the proper course in many cases. But IMO there will be cases where multiple ESBs is a-okay. Reply
Jul 24, 2008 5:09 PM John Michelsen John Michelsen  says:
Thanks for joining the conversation - and what a conversation it is. I just posted a followup on this whole "issue" at http://blog.itko.com/2008/07/esbs-cohabitati.html.In any case, I wouldn't say ESBs are inherently good or bad - if you are looking at M&As, or multi-enterprise workflows, some intermediation is inevitable... and they do help us integrate a bunch of underlying technologies so we can abstract them as services later.Now, where customers put themselves in peril, is when they believe an ESB vendor is giving you a "SOA out of the box" which is simply not the case. "SOA is what you do, not what you buy"... everyone repeat... Reply
Jul 29, 2008 12:04 PM Eric Roch Eric Roch  says:
Most people don't know how to properly use tools like the ESB. http://it.toolbox.com/blogs/the-soa-blog/how-to-use-esbs-for-soa-26280 Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.