I've always been a bit unclear about why integration and SOA were such a taboo connection for some pundits.
I mean, come on-it makes sense. Why would you want to do point-to-point integration when you could service-enable systems and just call the services?
Anne Thomas Manes, of the Burton Group, has talked extensively about the difference between SOA and what she terms service-oriented integration. Recently, I contacted the Burton Group for an interview with Manes to cover her recent obituary for SOA. As an aside, I mentioned that I knew she thought SOA was not a good integration approach, and I'd like to explore what people should be doing.
I should've revisited her arguments, because my memory apparently isn't as good as it once was. Manes rightly objected when we spoke on the phone.
"SOA is a great way to do integration," Manes said. "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."
What bothers her is that people are confusing the use of services to achieve integration with a service-oriented architecture. While integration via services is a useful thing, it's not that different from the more traditional approaches to integration. And it's certainly not as hard or as valuable as a full-blown architecture based on services.
You'll be disappointed if you're hoping to reap the promised benefits of a service-oriented architecture with what's basically integration, she warned:
"Most of the other case studies are pointing to integration projects where we saved a little bit of money in the creation of this point-to-point integration effort by using this new technology. And yes, every single one of those projects, if they're successful, adds value to the business because you integrated some things that weren't integrated before and you managed to solve the specific business problem that was required in that circumstance. There's nothing wrong with that, but it doesn't help you achieve the huge benefits that have been positioned around SOA, which are increased agility and reduced cost. If I'm getting 5 percent benefit out of it, that's not a very big return on investment."
Five percent may sound pretty good to you in this economy, but when you consider that building a service-oriented architecture saved Nationwide Insurance Group tens of millions a year, you start to understand her point. But to achieve those kind of results, you have to do more than service-enable a few appliations. You have to re-engineer everything, even if you do it a little bit at a time - a process Manes and I discussed further in the second portion of interview, which should publish next week.
That's also why Manes said she never declared SOA dead as a way of building IT systems. SOA is still very much a viable approach for IT-but, like most overhyped IT initiatives, it's lost its allure with business executives. You can't just say, "I need to fund SOA" and expect business to fork over the dough. Or, as Manes put it:
"That is the whole intent behind it: Don't go out there and say, "Oh yeah, you have to give me another million dollars this year so I can continue this investment into SOA" or, more likely, more than a million dollars. You need something more concrete than that."
Of course, there will be those who disagree that SOA is still viable for IT. If that's you, head to our discussions: Patrick Avery, who heads IT Business Edge's Knowledge Network, recently started a discussion about this very topic and wants to know what you think.
Before you chime in, though, I encourage you to read the full Q&A with Manes. In addition to explaining more about SOA and integration, Manes offered several great examples of how companies have achieved major success with SOA. Along the way, she also offers a few useful lessons on how IT can align with the business and really figure out their real needs-as opposed to addressing vague concerns that may or may not be the real problem.