The SOA Elephant

SOA is like that old fable from India about the blind men and the elephant - everyone describes it a bit differently (analyst definitions are omitted because I want to focus on implementations, not forecasts or speculations):

  • To IBM SOA appears to be an IT infrastructure for business enablement:
    • “SOA is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.” (from a recent IBM Webcast)
  • To BEA SOA appears to be about making IT more efficient using web services:
    • “SOA is a design methodology aimed at maximizing the reuse of application-neutral services to increase IT adaptability and efficiency. While these concepts have existed for decades, the adoption of SOA is accelerating due to the emergence of standards-based integration technologies like web services and XML." (from a recent BEA white paper)
  • To Sun SOA appears to be business-centric services using the web services specifications:
    • “SOA is an architectural style that emphasizes well-defined, loosely coupled, coarse-grained, business-centric, reusable shared services. Services are well-defined encapsulations of business assets. They are network based, described using standards-based interface languages, such as the web services Description Language (WSDL), and accessed via Web-based protocols such as the Simple Object Access Protocol (SOAP). A service can be accessed by any client capable of making SOAP invocations. However, services are typically accessed by Business Process Execution Language (BPEL) engines, portals, and/or applications. Additionally, services descriptions and APIs are published in a common registry to enable easy discovery by potential service consumers.” (from a recent Sun white paper)

These definitions are all well and good, but I believe they miss the point - SOA is a means, not an end. In other words, SOA is just a way to enable an agile enterprise - its not the endgame. Its only after SOA that things really start to get interesting.

I think the concept of Service Orientation (lose the "A") is a much more exciting idea. If we think purely in terms of service orientation, then:

  1. Everything within a SOA can be perceived as a service provider (even things like a printer or that annoying guy from purchasing)
  2. Service providers expose capabilities through publicly abstract interfaces (this is WSDL today, possibly something more expressive in the future)
  3. Service capabilities can be aggregated into processes (processes may extend, constrain or reconfigure existing services)
  4. The SO model is fractal (processes (entire SOAs even) can be viewed as a whole, aggregated, or cleaved into more granular services)

What are your thoughts (or flames) on this?