It seems like not a day goes by lately in which some new story of malfeasance in office doesn’t come out – whether it’s lying under oath, using the services of a call girl, or spying on other officials in the government in order to further a personal agenda. Clearly, our elected officials don’t have a clue about the meaning of governance.

Given that, it’s not really surprising that there seems to be some confusion in the SOA market place about what we mean when we say “SOA Governance.” To some vendors, governance means a product. When I say governance, I mean a process. While I think it’s simple to explain what we mean, I don’t think the confusion about terms is beneficial to the industry.

When an enterprise IT organization adopts SOA, it begins a journey of transformation within the infrastructure as well as within the fundamental business processes of the corporation. This has a number of results that are fundamentally disruptive to the steady state of the organization (change always is). The small pilots that are created as the first steps toward SOA have very little impact on the organization. They create a few services, help define product selection and everyone goes on the way they have been working. But after a certain point, maybe 20 or 30 services or so, a variety of issues crop up.

One is ownership of a service. Ownership implies control, but it also implies cost and funding. When a department funds a small server to do LDAP, and it becomes overwhelmed because 16 other departments now want to use the same shared service (identity management), finger pointing can quickly occur. Rarely do funding models and growth predictions get rolled into the first services, and yet many of them are the support services that are necessary for every project. 

Another issue is that of version control and consolidation. When a company decides that there will be one defining service for some particular purpose, it needs to be able to consolidate various versions of the truth that may already exist. This poses several problems. The most immediate problem is getting multiple groups to agree on what the single version of the truth is. Sometimes this results in huge battles or a large number of “optional” parameters. Groups that have defined basic communications differently (like marketing and manufacturing having their own views of what is a customer) are not likely to easily change their perspectives, but it’s usually in the organization’s best interests not to have multiple versions of the truth. In the case of a tie, who gets to be the tie breaker?

These and other questions point to the organizational and managerial aspects of service-oriented architecture. While there are multiple ways to organize around these basic issues, there is no getting around the fact that there needs to be some organization that makes decisions and helps determine the transformation of the IT landscape from silo applications to shared (or at least shareable) services.

That’s really what I mean when I say governance – organization and processes for controlling the use of services.

Now what some vendors seem to call governance is something I think of as SOA Management – namely the observation of, enforcement of, and reporting of the quality of service or service level agreements. SLAs and QoS are both important facets of the IT world – but I rarely regard them as governance. In most cases you can’t truly decide on the SLA or QoS, rather it’s derived from best performance characteristics or limiting factors like network latency. So rather than governance, I usually think of this as Management or Reporting.

Most of the time, confusion over terms isn’t so bad – but you can see that calling one thing something else can lead to bad behavior and mistaken purchase orders. 

Time to run; I think I’ve just been nominated for governor.