SOA, Composability and Business Architecture

Irving Wladawsky-Berger, formerly of IBM, has a recent post on SOA and Business Architecture.  While the entire post is excellent, I wanted to call out a few things.

Composition-Oriented

First, I like his description that "SOA is based on modularity, composability and interoperability".  It seems that most people focus on SOA's modularity (re-use potential) and interoperability (technology standards) and discount the composability. 

Just yesterday, during the IT Becoming Componentware panel at MIT's CIO Symposium, an audience member asked "Won't companies lose differentiation in a world where everyone is implementing the same (industry supplied) business services?"  The majority of panelists conceded that differentiation would be lost, therefore business service acquisition strategies need to consider parity versus competitive advantage. 

I disagree.  To me, you can easily introduce business differentiation via composition (orchestration).  Common business services can be composed for your distinct business processes and business interactions.  That's the power of SOA, and why I'm such a huge fan of the ‘agility triumvarate’ -- SOA, EDA and BPM.  I've often thought SOA (and friends) would be better described as composition-oriented and services-based. 

SOA is an Approach

Second, I was glad to see Irving's separation of "SOA" from the related products "The hope is that with SOA and the many different tools developed around it..."

Business-Driven

Third, in his ever present business focus, Irving also incorporates the concepts of business simulation and calls for a disciplined approach to business architecture. 

The hope is that with SOA and the many different tools developed around it we will be able to design, simulate and test business services in business terms - prior to their implementation in IT systems.  Such architectures would then be much more reflective of the basic concepts of the business - be it a hospital, a retail distribution center, an industrial organization or a government department - rather than those of the IT foundations on which they are being implemented. 

This is very challenging for a variety of reasons.  To name one, there is no tradition of architecting, designing and simulating business services and business systems.  It has all been done in a relatively ad hoc, labor-intensive way.  This is not unusual, as every discipline that is now a well established engineering discipline - civil, mechanical, electrical, and so on - went through such a transition decades ago.  But eventually the industry starts settling on a suite of standards and modular components, sophisticated tools are developed as well as the ability to extensively simulate and test various design options, and a more structured, engineered discipline starts to emerge.  This will come to business architecture as well over time, with the help of major software technology innovations like SOA.

Irving mentions he’ll be at IBM’s Impact event next week. I hope he expands on these topics, and the session is on my schedule!

[Disclosures: IBM is not a client of Elemental Links, however IBM is a founding sponsor of the SOA Consortium, which is a client of Elemental Links.  IBM has invited me to Impact and is providing for my travel accommodations.]

Comments

[James Taylor]

"Won't companies lose differentiation in a world where everyone is implementing the same (industry supplied) business services?"

To some extent I agree with you, that services are the answer to this, but I think the problem of process templates and standard approaches may mean that orchestration/composition does not solve the problem. I see customers (and outsourcers) focusing on control of the critical decision services in their business. Even if these are orchestrated into an industry-standard process, making decisions (about pricing, marketing, origination, collections) differently means your (standard) process feels and looks different to customers and resists commoditization.

JT

[Martin Hromek]

Just a minor comment: Isn't it true that modularity and interoperability are the necessary prerequisites for composability/orchestration?

[brenda]

Martin - absolutely. In "composition-oriented and services-based", I think of modularity and interoperability as "service-based". As for "interoperability" it needs to be both technical and business (semantics). -brenda