SOI versus SOA

Anne Thomas Manes’ “SOA is dead” post back at the beginning of the year sparked quite a debate, which is still going strong. On the Yahoo SOA group, the question was asked on exactly what Anne meant by SOI, or Service-Oriented Integration. Here’s my response:

SOI, service oriented integration, is probably best stated as WSOI- Web Services Oriented Integration. It’s simply the act of taking the same integration points that arise in a project and using web services or some other XML over HTTP approach to integrate the systems. Could this constitute a service-oriented application architecture? Absolutely, but in my mind, there is at best incremental benefits in this approach versus some other integration technology.

Because the scope is a single application, it’s unlikely that any ownership domains beyond the application itself were identified, so there won’t be anyone responsible for looking for and removing other redundant service implementations. Because the scope of the services involved didn’t change, only the technologies used, it’s unlikely that the services will have any greater potential for reuse than they would with another integration technology except that XML/HTTP will be more interoperable, than say, Java RMI, if that’s even a concern. To me, SOA must be applied at something larger than a single application to get anything better than these incremental gains. Services should be defined along ownership domains that create accountability for driving the redundancy out of the enterprise where appropriate.

This is why an application rationalization effort or application/service portfolio management is a critical piece of being successful. If it’s just a “gut feel” that there is a lot of waste in the IT systems, arbitrary use of a different integration technology won’t make that go away. Only working to identify the areas of redundancy/waste, defining appropriate ownership domains, and then driving out the redundancy through the use of services will make a significant difference.

4 Responses to “SOI versus SOA”

  • Bob Slook:

    All good points. I was going to disagree with you at first but I see what you mean. I did a SOI type project and that was hard enough. Doing true SOA takes a mind set not many organizations have.

  • […] quote Todd’s definition of SOI: SOI, service-oriented integration, is probably best stated as WSOI — Web […]

  • […] SOI vs SOA¬†by Todd Biske – Is SOA dead already? […]

  • Todd – This is an interesting post. I am in complete agreement with your stated distinction between SOI and SOA.

    We have had no shortage of Integration technologies or SOI going all the way back with RPC models, CORBA, JEE RMI, and SOAP etc. The evolution in integration technologies is best confined to the realm of interoperability and the availability of tools that make it easy to use the programming models.

    However, none of the technology options could replace the need for having a disciplined approach to business architecture that includes business process rationalization and information exchange model optimizations. Together these models become the driver for SOA. It is this discipline and the services coming out of this effort that have a chance at being reusable and consistent in delivering to the promise of generating enterprise value. Of course, as you point out in your blog you will need to reinforce this effort by undertaking the discipline of “service portfolio management” and “service governance”.

    Again, I feel that the goal of SOA is to deliver sustained business value in being driven by the business and for the business and the service oriented architecture paradigm would allow one to gain from advances such as automation of service composition, automation of provisioning of services and having an infrastructure that enables management of QoS.

    A couple of my blogs provide some more content on the subject of SOA and Business Architecture.

    Thanks for listening.
    surekha –

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.