<<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*
<http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1321663,00.html?track=NL-110&ad=651139&asrc=EM_NLN_4061195&uid=5657679>
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* <http://www.itbusinessedge.com/item/?ci=45975>. 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*
<http://www.ebizq.net/topics/soa/features/9913.html> 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* <http://www.itbusinessedge.com/blogs/mia/?p=303> and, in fact, can
be useful. As *I wrote back in December,*
<http://www.itbusinessedge.com/blogs/mia/?p=264> 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*
<http://www.infoworld.com/article/06/06/19/79392_HNsoaesbmind_1.html> --
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.>>
*You can read this at:
*
*http://www.itbusinessedge.com/blogs/mia/?p=423&nr=EEB
*
*Gervas*
