Service-oriented architecture - the architecture approach you adopt to simplify integration and get everyone on the same page of standards -- that very same architecture is now causing integration problems.
In retrospect, it was inevitable. Haven't they told us from the start that you should build your SOA to match your business needs? Except businesses change -- they get bought out by bigger businesses, or they operate independently within huge, multinational conglomerates that one day decide the individual divisions should share more information. The business world is just too complex and dynamic a place for this not to become an issue.
Fortunately, this problem is not insurmountable. In fact, the answer's straightforward, though I wonder if the implementation would be. More on that in a moment.
You can learn more about this issue by watching "Multiple ESBs: SOA Reality in a Federated Environment," a Webcast featuring Gartner VP and Distinquished Analyst Masssimo Pezzi and Hub Vandervoort, the CTO for Progress Software. Progress sells application infrastructure software, including event-processing tools and SOA technologies, such as ESBs.
I'm not 100 percent sure how old this Webcast is, but it apparently aired fairly recently, since the Progress blog, The SOA Infrastructure, just posted a link to it on Friday, Jan. 25.
Pezzi provides the background on the three causes of this problem, which is called federated SOA. Sometimes, there is a pure technology cause -- one business unit might have its SOA based on SAP or Oracle and another unit might be more pure Microsoft, and so used that approach. Sometimes it's because there are actually different business requirements within a large organization: One department is on a limited budget and needs a simple SOA, while another focuses more on scalability or performance.
The result is that you have two or more SOAs, built slightly differently, with integration problems.
You could approach the problem by dismantling some of the SOAs and rebuilding, but as Pezzi describes it, that's a fool's game (my words, not his). He calls this approach expensive and risky.
A more realistic approach is to get the SOAs to work together. To do that, he says you'll have to tackle three fundamental challenges:
One way to do this is to agree to the standards and protocols each ESB must use and basically, through a registry, outline the rules the ESBs must obey. Another way, as Vandervoort explains, is to use another ESB to integrate all the ESBs. I like to think of it as a sort of Lord of the ESBs -- you know, one ESB to rule them all, find them, bring them all and in the darkness bind them. Coincidentally -- ahem -- Progress offers such a solution, called Sonic ESB.
This issue of multiple ESBs is not insubstantial. As I've written before, since most packaged solutions come with an ESB, you may have more of these sitting around than you think. Fortunately, as Robin Bloor, a partner with consultants Hurwitz & Associates, has pointed out, ESBs are really good at integration. Bloor went so far as to argue that, in fact, ESBs are essentially integration engines, pointing out even in November of last year that this meant they could be used to mediate between different SOAs.
(For fascinating historical information on ESBs, I recommend this piece by Paul Fremantle, co-founder and vice president of technical sales at WSO2.)
There's a lot of information in this nearly 25 minute-long presentation. You'll need to provide basic registration information -- your contact info, title, and a bit on your technology needs.
If you're short on time, just click on the "transcription" tab at the bottom of the presentation and then press pause on the video so you can read through it. But be forewarned -- there are a lot of cuts in Vandervoort's presentation, which aren't obvious when you read through the presentation. It can be a bit confusing.