If you're old enough, you probably remember the whole episode with Al Haig in the White House, saying "I'm in charge here" during the period when Reagan was shot. He wasn't really, but it's a good illustration of the concept of confusion, and how different people react to situations. How is this relevant to SOA and Web services? That's an excellent question.

As in a country, an organization implementing SOA needs governance and direction. A simple example may help shine a light on this subject. Let's suppose a division of a large company implements a new security service. Since it's only one division (let's suppose the company has some 50 divisions), they size the service to suit their needs only, and use a small server (maybe two for redundancy). Now, the service is successful, and other divisions start to use it, and so on. Pretty soon the service is up and down like an elevator, and when it is up, the response time is slow.

This illustrates why SOA and Web services need a governance model. Our hypothetical division implements the service for its needs, without considering the bigger picture. However, one of the goals of any SOA is reuse of services and reduction of redundancy, so any service that is successful needs to be designed for reuse. One of the key issues, of course is who pays for it. Why should that single division shoulder the burden of maintenance and equipment for the other 49 divisional needs?

Key concepts in the governance of SOA are cost and control. These two concepts go hand in hand - you can't expect control without expecting to bear the cost of the service. As services become more widespread and usage increases, organizations have to deal with scalability challenges, increased maintenance, and eventually with version-control issues.

Another key challenge is managing the reduction of complexity. Everyone is in favor of reducing the number of different ways to do the same task, as long as you don't touch MY way of doing things. One division of a large corporation surveyed its various applications and identified about 1,000 services. Then they did some comparisons and realized that because of redundancy, they could reduce the service count to fewer than 200. Over 80 percent of their software portfolio was redundant.

When things are that way, they are that way for reasons. Some have to do with specialized systems for special purposes - silos of useful functionality, but limited scope. It's not uncommon for organizations to have three or four or more systems for every real service - in telecommunications for example, it's often the case that they add a new billing system to account for new ways of doing business, rather than wait for changes to the old billing system. These are the problems SOA is designed to solve, but the key issue is governance. You may have heard the expression "You can have it fast, you can have it cheap, or you can have it quickly, but you can't have all three." Somewhere along the line the decision of whether we need it right now, or whether we will stick to a service interface and make changes has to be made. Fortunately, SOA allows us to put a façade in front of any new system to make it conform to the needs of the organization. In this fashion, it allows an organization to add new capabilities quickly, without compromising the overall integrity of the architecture. It also enables reduction of redundancy, without the pain of intermediate states of a system.

In order to achieve this nirvana - this heaven of software and services, there has to be order, and management and governance. The corporate equivalent of Al Haig must stand up, and say "I'm in charge here." However, in order for it to work, he must REALLY be in charge - and stick to his guns long enough to effect change.