Modeling SOA Implementation

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.

A common initial reaction to the maturity model proposals was that they are premature, and that two to three years of experience is needed before SOA best practice is understood well enough to provide the basis for a useful model. This ignores the pace at which SOA is developing. Two years ago SOA was almost unknown. Now everyone is talking about it and enterprises are starting to adopt it. The industry can no longer afford the traditional strategy of waiting for practice to emerge before codifying it. The model must emerge in parallel with best practices. This will mean that adjustments are needed in the light of experience, but there will at least be something that enterprises can use in the crucial early take-up stage.

Requirements for successful modeling

Whatever approach is adopted, it must relate to business value. Technology can be fascinating, but it is the application of technology that matters.

It might be possible to measure service granularity, for example, but would this be useful? Service granularity can enable business agility, but it is the agility, not the granularity, that has the value – so it is the agility, not the granularity, that should be measured. Counting the number of services per function to assess business value is about as helpful as counting the average number of colors per square inch in a painting to assess its value as a work of art.

The modeling technique must produce system descriptions that can be easily understood by business people as well as by technologists. The process itself may require special expertise, just as it takes a draughtsman’s skill to draw a plan of a building, but it should be easy for everyone to grasp the results.

Most important of all, there must be a single approach, common across the IT industry. Multiple, conflicting modeling methods, from which vendors can pick and choose, will not help to remove the confusion, which is at the core of the problem.

A standard for SOA implementation modeling will benefit the 70% of global enterprises that are reportedly implementing, or planning to implement, SOA by helping them to assess what they need, and to compare what their prospective suppliers are offering. It will also help the suppliers – or at least the quality suppliers - by simplifying their communications with customers and making it easier for those customers to identify the best proposals.

Such a standard must be designed to enable business value to be measured in terms that can be easily understood by business and technical people. It must be accepted by enterprises implementing SOA, by SOA product vendors, and by solution providers and integrators. It must therefore be developed, not by a single vendor or a small club of vendors, but in a forum where all of these stakeholder communities are represented.

This development must proceed in parallel with the deployment of SOA, not wait until the need for it has gone. It will take time, and require constant adjustment in the light of experience, but it will deliver real value to enterprises implementing SOA and to the suppliers of SOA solutions.

For more information, please contact Dr. Chris Harding at

About the Author

Dr. Chris Harding leads the SOA Working Group at The Open Group - an open forum of customers and suppliers of IT products and services. In addition, he is a Director of UDEF Forum, and manages The Open Groups work on semantic interoperability. He has been with The Open Group for over ten years.

Dr Harding began his career in communications software research and development. He then spent nine years as a consultant, specializing in voice and data communications, before moving to his current role.

Recognizing the importance of giving enterprises quality information at the point of use, Dr. Harding sees information interoperability as the next major challenge, and frequently speaks or writes on this topic. He is a regular contributor to ebizQ.

Dr Harding has a PhD in mathematical logic, and is a member of the British Computer Society (BCS) and of the Institute of Electrical and Electronics Engineers (IEEE).

More by Dr. Chris Harding

About Open Group

The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow will enable access to integrated information within and between enterprises based on open standards and global interoperability. The Open Group works with customers, suppliers, consortia and other standard bodies. Its role is to capture, understand and address current and emerging requirements, establish policies and share best practices; to facilitate interoperability, develop consensus, and evolve and integrate specifications and open source technologies; to offer a comprehensive set of services to enhance the operational efficiency of consortia; and to operate the industry’s premier certification service. Further information on The Open Group can be found at