Thursday, February 19, 2009

SOA Mismatch

SOA Mismatch

With all the talk these days about how “SOA is dead,” one might wonder: What does it really mean and what could have killed it? Yes, there has been disillusionment, but there are also examples of great success. From where I sit, I see the difference as a mismatch between SOA definitions and expectations. Let me explain.

There seems to be two major competing definitions of SOA floating out there. From the top down, the definition is that SOA is an architecture of interacting services. From the bottom up, the definition is that SOA is an integration technology – a more flexible way to hook things together (such as via web services). Each of these definitions has broad-reaching implications, from planning to governance to infrastructure support. From the business perspective the holy grail is the “adaptive enterprise” – the agility to turn the business on a dime to meet the requirements of a rapidly changing environment. The first definition of SOA holds out this promise – having a collection of architected services to mix and match allows a business to reconfigure the business and supporting IT to meet new demands. From a technology perspective, the second definition provides the benefit of network flexibility – making different technologies interoperable and allowing disparate technologies to be plugged in more easily.

So, for purposes of this discussion, the question is: is what is being promised the same as what is expected? In many cases of SOA disappointment, I contend the “buyers” (typically the business side) have been told that SOA leads to organizational agility. But, the SOA implementers have set out to deploy according to the second definition. Let’s be clear; there is a lot involved in implementing SOA according to either of these definitions. So, after the initial deliverables, the team shows the business what they have produced and the response is: How does this achieve organizational agility? The problem is they are both right – just using different definitions of SOA. Unfortunately, that is probably the end of the SOA initiative for that organization.

Perhaps what we need is to start each conversation with a comparison of the definition each party is using. This might help avoid the mismatch between what is expected and what is produced.