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.

Organizational SOA

Anybody recently tell you that SOA is an IT integration technology? Don’t believe it. SOA’s biggest selling point is agility, and you don’t get that from an integration technology. SOA is actually architecture.

Forget IT. SOA can be applied to an organization (even one devoid of IT). If we throw out the conventional definition of organizations of hierarchies and functional units and replace it with a framework of business units offering services, we can derive a service oriented organization. Starting with the products and services we provide to external parties (external customers) and the products and services we obtain from external parties (external suppliers), we have the beginning of a framework to describe the organization. If we then add sets of internal customers and suppliers and define the act of providing a product or service to a customer as a service, we have the next step – a collection of services – tasks performed for a consumer. We can then map the incoming products and services to outgoing products and services by defining processes that consist of steps in transforming inputs to outputs. The processes and steps in the process are the services previously defined. So, processes become a string of services that are orchestrated to produce outputs. Now services are a lot like processes (very fractal) with inputs, activities and outputs; and, they can consume other services, so we need some rules to prevent service conflicts and circularities. This is achieved by defining an architecture of services with layers dividing the services based on rules about which services can call which other ones (for example, a typical rule is services at a given layer cannot call services at a higher layer).

Organizations that define themselves as collections of service (org) units, achieve agility from two basic facts: (1) processes can be changed by rearranging the services or replacing a given service with a different (new?) service and (2) new products can be produced by combining existing services in new ways and adding a few additional ones. Think about an insurance company offering a new coverage product – many of the activities required are the same as for existing products and can be reused.

In IT, the concepts are the same, except that now we are talking about software components instead of organizational units and they are even more flexible – software services can be offered to multiple consumers from the same distributed component on the network (i.e., the “cloud”). All of this adds up to a significant gain in agility both on the organizational and the IT side.