The movement to service-oriented architecture (SOA) continues to gather pace, with the latest survey data from Forrester indicating that nearly 70% of global enterprises have adopted or will adopt SOA. But there are almost as many different definitions of SOA as there are vendors offering to deliver it, and to date there are few completed implementations. Most enterprises do not yet have SOA, but are working on it. How do they really know what they will get – and that it will meet their business needs?

Understand the SOA you are buying – if you can

The confusion over the varying definitions of SOA is notorious. Gartner gives it as the first reason why small and midsize businesses find the prospect of introducing SOA daunting. Large organizations are better equipped to cope: their CIOs probably know at least as much about the latest trends as do their technology vendors, and they have specialists on hand to investigate and evaluate new ideas - but even they need to have a common understanding with their suppliers. Few people would buy a house without knowing how big it is, yet that is what an enterprise risks when buying “SOA”. Buildings can be measured in feet and inches, but how do you measure how loosely services are coupled? The problem is not that suppliers do not want to say what will be delivered; it is that we just cannot yet describe SOA in simple terms that all technical and business people can understand the same way.

A standard way of modeling SOA implementation could help answer this problem, just as scale drawings provide a standard way of modeling buildings that everyone can comprehend. But how SOA implementation should be modeled is not obvious.

Modeling SOA implementation

The most straightforward approach is the one being followed by the OASIS SOA Reference Model Technical Committee, which has just released its first Committee Draft for public comment. This contains a set of high-level definitions of SOA technical concepts – service, visibility, interaction, execution context, and so on. It helps an enterprise to answer the question, “Is this SOA?” But it does not shed any light on the deeper question, “What kind of SOA is this?” And that is the key question that must be addressed if a model is to be of practical use to enterprises in planning SOA implementation.

Another approach, which does help to answer the second question, is that of the maturity model. In the fall of 2005, SOA product vendors Sonic Software, AmberPoint, BearingPoint and Systinet announced their Service-Oriented Architecture Maturity Model, in which the maturity of SOA is characterized in five levels, from Initial Services up to Optimized Business Services. More recently, IBM has proposed its Service Integration Maturity Model. The latter is more sophisticated; it looks at five aspects of an enterprise's IT, ranging from the infrastructure to the business viewpoint, and classifies them in seven levels, from silos to dynamically-reconfigurable services. While the word “maturity” implies that there is a natural progression through the stages over time, the real value of these models is to enable an enterprise to assess how service-oriented it currently is, how service-oriented it should become (it does not necessarily need to be at the most “mature” level), and how to progress to the desired state.