I think there is a misconception about ESB. Just because ESB is used does not mean that is a SOA for better or worse. An ESB can be used in a plain old integration project to connect few simple applications. Is there any reason that every IT task has to be SOA? Most projects do have schedule and budget limitations.
H.Ozawa --- In [email protected], Gervas Douglas <[EMAIL PROTECTED]> wrote: > > <<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_gci13216 63,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* >
