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:
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.