I came across this article on TechTarget.com by Rich Seeley, outlining issues around ESB integration. "Enterprise service bus (ESB) intermediation remains an issue despite the adoption of WS-* standards, argues John Michelsen, chief architect at iTKO Inc., the testing vendor specializing in service-oriented architecture (SOA)." "They're finding that two or three different divisions of their company are using dif I came across this article on TechTarget.com by Rich Seeley, outlining issues around ESB integration. “Enterprise service bus (ESB) intermediation remains an issue despite the adoption of WS-* standards, argues John Michelsen, chief architect at iTKO Inc., the testing vendor specializing in service-oriented architecture (SOA).” “They’re finding that two or three different divisions of their company are using different ESBs from different vendors.” Okay, there are so many things wrong with this I don’t know where to start. First, if there is indeed “enterprise architecture” and an “enterprise architect” then the different divisions should not be using different ESBs, or even an ESB for that matter. 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, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly. 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. No two ESBs are alike, and thus you will typically find it’s much cheaper to blow all of them out of there and start from scratch than attempt to figure out how you’re going to make them talk. Again, just to be clear, you determine your requirements, and then the solutions patterns, and then the technology. Based on the TechTarget article, enterprises seem to be doing this backwards. SOA will fail if you focus on just layering in more technology, versus normalizing the existing technology, aligning any changes with the business, and focusing on actually making things more simple and agile. Focus on the simple, and stop dragging technology into your enterprise without the concepts of a more holistic plan. Software Development