Wrong, wrong, wrong! Service-oriented integration is definitely NOT the same thing as using Web services, or, God forbid, an ESB for integration.
That's more or less what a recent ZapThink column is saying this week, responding to this year's on-and-off again discussion about service-oriented integration. But to be fair, from ZapThink's perspective, everybody else is just now following up a discussion they first started seven years ago.
Why would you, a busy IT Business Edge reader, revisit this somewhat pedantic issue of SOA and SOI?
To be honest, I get a little sick just thinking about it, too, but, like Paul Harvey, ZapThink has "the rest of the story." And if we're all going to make informed decisions about SOA and its potential for saving your company time and money on integration-you need to know the full story. Bottom line: We've both got a duty to follow through.
The facts, according to ZapThink, are these:
First, a minor correction, but with a significant point: ZapThink-not Anne Thomas Manes, as I had believed - first introduced the phrase service-oriented integration. They coined the term in 2002-as a means of-and here's the key point-differentiating integration by loosely coupled services from Web services adapters. It's also different from using an ESB for integration.
In fact, they see SOI as requiring a service-oriented architecture:
"The point we've been making over the years is that SOI requires SOA, in other words, SOI is an architecturally-driven approach to solving integration issues that can yield business agility, in particular, a flattened cost of dealing with business change over time."
This leads to ZapThink's second point, which is:
"SOA requires us to rethink how we approach the problem of integration altogether, in the context of an architecture oriented toward Services rather than toward tightly-coupled interfaces. Instead of taking a 'connecting things' approach to distributed computing, therefore, we need to take a 'composing Services' perspective."
Third: Integration moves from being something IT has to do to support business needs to being a byproduct of service composition. It's "business process-driven," and "lines of business (LOBs) to take greater responsibility for such integration," contends ZapThink:
"If the IT organization has abstracted all of its capabilities as composable Business Services, then the LOBs can drive the integration of those Services via their Business Process Management efforts. And while LOB users will still likely call upon IT personnel to create the compositions themselves, they will be doing so at the behest of business process specialists who are focusing on solving process-centric business problems."
Of course, I've just hit the highlights. You'll want to read the full piece for the nuances, and, as always with SOA, the devil can certainly be in the details.
As ZapThink points out, this is not just about integration, but about "SOA's fundamental purpose." Is SOA for solving integration problems or is it more of a "business transformation approach centered on implementing agile business processes?" they ask.
Ultimately, they conclude it's both-with the caveat that SOA changes the integration rulebook.
I suspect Manes would actually agree it can be both. When I interviewed her back in February, she quickly established that she thought SOA was a great solution for integration:
"SOA is a great way to do integration. If your goal is to do integration then you should be applying service-oriented principles to your systems to make sure what it is you're creating. When you're creating services as opposed to applications, those services are integratable right from the start. You're building capabilities with the intent that other applications can use those capabilities."
The problem is, this SOA-based integration approach doesn't seem to be what's actually happening in the real world. Most companies, it seems, are using ESBs and Web services for integration - which is what Manes called SOI. No matter what you call it, the analyst seem to agree that's not the same as SOA - and it's far less likely to provide the integration revolution ZapThink advocates.