Last week, after spying on Yahoo's SOA Group, I wrote a piece questioning why so many SOA experts hate the SOA/integration connection. Basically, I couldn't grasp why it was such a big deal-why not let people use SOA for integration as a first step to using SOA more broadly, I argued.
After all, that's what most companies are doing anyway.
I've been spying on Yahoo's SOA group some more, and the debate is still raging. There's even some noise that the original Gartner analyst quote about "SOA is integration" may have been a misquote-something meant to be sarcastic, but taken as straight in the original article.
You may be wondering whether this sort of pedantry is worth your time. But the fact is, there are important arguments against using SOA for integration-or, at the very least, building SOA with integration as the end game. If these arguments are right, it could mean your SOA investments won't payoff. And nobody wants that.
I'm not going to synthesize a bunch of different posts (yawn!) when you can read the whole thread for yourself. And, frankly, there's no need to, because Burton Group Vice President and Research Director Anne Thomas Manes wrote an excellent blog response that covers the most important arguments against SOA as a means to integration.
When heated discussions like this start, people tend to get distracted on tangents. Eventually, their arguments get fleshed out, but it can take awhile.
Manes, whose work is focused on research, tends to write like a researcher: She thinks the issue through calmly and thoroughly and her writing reflects this. Her research background also gives breadth to her insights. As a result, her response-to me - represented the best of the arguments raised against SOA and integration.
Her first point is that just because companies are reporting success with using SOA for integration does not mean those cases are, in fact, SOA. In fact, her research shows they aren't really service-oriented architecture, but rather examples of service-oriented integration:
"... they are examples of projects that used service oriented protocols (e.g., WS-*) and middleware (e.g., ESB) to integrate two or more application systems. But from an architectural perspective, you still have monolithic systems bridged by integration middleware."
Now, as Manes points out, there's nothing wrong with this approach, but you shouldn't expect big-picture SOA results if all you're really doing is integration:
"It's fine to use service oriented middleware to implement integration projects, but then you need to readjust your expectations. Most organizations that I speak with say that the goals of their SOA initiative are to reduce costs and increase agility. Unfortunately, these organizations aren't likely to achieve these goals if their projects only focus on integration."
Manes also offers a response on the newsgroup that addressed, albeit indirectly, my suggestion that analysts encourage companies to start with integration and then build up:
"I always recommend a 'think big, take small steps' methodology. So I concur with the take one small step at a time' advice. But I find that many organizations forget the 'think big' part of the equation."
Her post discusses the success companies have found when they did focus on architecture. Alas, so far, she's found only four such companies.
It's important to note that there are many people who agreed with Manes and Michael Poulin, who started the thread with his plea to "to slow down spreading such Integration SOA madness?" (BTW: Poulin wrote a response to the original IT Business Edge post as well.)
There are also a lot of people who think SOA can be used for integration, but that the value proposition shouldn't stop there.
And then there are people like Gartner analyst Nick Gall, who raised this biting question:
"Doesn't the suspicion that SOA is vacuous grow stronger when you see that we can't even agree about the relationship of SOA and integration?"
So, where does this leave those of you who don't care about SOA philosophy, but do want to know what SOA can do for you?
Well, let's assume you don't care whether you're living up to someone's ideal of SOA. If you're solving your problems-even integration problems-and you're using service-oriented principles and you want to call it SOA-that's your business. Sure, analysts and others may find it annoying, because then it's hard to quantify if "SOA" is succeeding or not, but that's really not your problem, is it?
You might even want to download this vendor-written white paper I stumbled across recently called-Manes, look away now! - "Worst Practices in SOA Implementation," which focuses on the top-four worst practices for SOA integration. That'll show 'em.
On the other hand, if you want to make sure that you achieve the big-picture results that SOA promises and you're planning to spend (or already have spent) a lot of money service-enabling your systems ... well, then, you might want to pay attention to the nuances of this debate, particularly since some say starting out with integration can mess up your efforts from the get-go.
Unfortunately, the experts can't seem to agree on the 'right' answer to the SOA/integration question. And even when they do agree, there are nuances to where they stand on the issue.
So, stay informed but beware: This issue may boil down to a judgment call - and it's ultimately yours to make.