SOA Governance – Short and Sweet

In my quest to demystify the whole SOA Governance thing, I read many articles, newsletters, white
papers and whatever I could lay my hands on. But I realized one thing,most of them say the same
things using the same words, the words which we call buzzwords. And worse some are purely
marketing docs. But in the end they fail to explain in simple terms what they mean to.

So I decided to take a systematic approach and go through this and in the beginning I was sure at the
end I would be as dumb as I started with. But I proved to be wrong, hopefully, if whatever I am going
to write now is correct.

First and foremost thing, forgive me for using any buzzwords I use in this because my head is currently
buzzing with them.

What is SOA Governance all about?

Everyone agrees, SOA Governance is about Governance in context of SOA and not about Governing
SOA, but the explanations and details vary from one person to other, based on who you are asking.

In Definition section of SOA Governance, in Wikipedia we find this,

The definitions of SOA governance agree in its purpose of exercising control, but differ in the
responsibilities it should have. Some narrow definitions focus on imposing policies and
monitoring services, while other definitions use a broader business-oriented perspective.
Webmethods defines SOA governance as “the art and discipline of managing outcomes
consistent with measurable preconditions and expectations through structured relationships,
procedures and policies applied to the organization and utilization of distributed capabilities
that may be under the control of different ownership domains.” [1]

Another definition is from Anne Thomas Manes: “Governance refers to the processes that an
enterprise puts in place to ensure that things are done (…) in accordance with best practices,
architectural principles, government regulations, laws, and other determining factors. SOA
governance refers to the processes used to govern adoption and implementation of SOA.” [2]

But in short and sweet terms,

SOA Governance is knowledge of the services on your setup and ability to apply control in various
ways at the various points in the services' lifecycle and keep a track of the services.

Let us see these three parts one by one,

1. Knowledge of the services:
Knowledge of the services means to know what services are available on your infrastructure,
how to access them, where they are hosted and how to call them and stuff like that.
2. Apply control at various points in the Services' lifecycle:
To understand this first thing to know is Services' Lifecycle. A services' lifecycle is the three
stages of the service in use, viz., Design, Run and Change. Now the services are controlled in
 their various stages using policies. Now these policies are nothing but rules/workflows which
are to be triggered depending on the stage of the service and the access requested.
Corresponding to the 3 stages of the service we have 3 different policies type, Design Time
Policies, Run Time Policies and Change Time Policies
3. Keep a track of the services:
We have to keep a record of the services in all it's life cycle phases, for eg. We should be able to
track when a services was put from design to run time, who accessed it then, when was it
updated or changed or removed, etc.

How do we implement governance?

To answer this also let us go step by step,

How to know what all services are there and keep a track of them?

This is the place a service registry comes into play. A service registry is a metadata, “system of
records” that holds information of various services in the setup and also the pointers to them. Whenever
a service is created it should be published in the registry and whenever someone wants to use a service,
it should be fetched from the link in the registry. This has several advantages, major ones being, having
a record of all services, standard way and point of accessing the services, independence on the actual
location of the services and means to handle changes without affecting the consumers.

How to exercise control on the services?

Controlling the services in different phases of the lifecycle is done by different means. So let us divide
this in the three stages of service lifecycle:

Design time service control:

When we say design time of services it includes design, development and deployment. The
development of services actually will be separate from the production environment, so we'll
concentrate on the control on service from deployment and there on.

First thing is to decide whether we have to publish the service itself. If yes, who can do it? Where to do
it? All these aspects can easily be implemented at our central access point i.e. the service registry. For
eg. when anyone tries to publish a service to the registry it can trigger an approval workflow, to get the
required conformations. This is where the repository also comes in. Repository is the location where all
data, the rules, governance workflows and other data, that doesn't fit in the scope of registry but is
required from governance perspective will go in. And the registry and repository work in tandem. It is
therefore advantageous to have an integrated service registry and repository, which minimizes the
duplication and synchronization issues and also makes sure the integrity of the data.

This is also the point where we implement the standards, global or organizational. This can involve
WS-I BP Compliance, use of proper namespaces, schemas and other validations.
Run time Governance:

Run time governance involves Access Control Rights, SLAs, QOS, and everything related to the
runtime of the service.

This feature is generally implemented by the messaging framework/broker/gateway. Whenever a

service call, or for that case any message comes in the framework it calls a rule or workflow to decide
how to process it. These workflows are driven by various factors including but not restricted to, the
sender, the called service, the content of the message, the version, etc. Most messaging systems or
ESBs as they are commonly called have the support for this in some form or another, primarily
designed in their routing system.

The rules/workflows themselves will be stored in a repository and the framework should be able to
fetch them, execute them and understand the outcome. So while choosing the ESB and repository it is
important that we select the combination that works properly together.

Change time Governance:

Mostly the SOA infrastructure itself on whole and services in particular are always in development and
keep on progressing. There should be proper procedures to handle this change management. On one
side where the Design and Run time governance relies very much on hard rules and can be mostly
machine driven Change time governance is to a big extent human driven and is therefore also called
soft governance mechanism. Change time governance is very much organization oriented which
depends much on the IT mechanisms of the organization.

Change time governance involves deciding whether a particular change can be put in, updating the
services, analyzing the impact, keeping a track of the changes. In many ways this relies on the data
from registry/repository, the logs and the IT management system.

How do I keep a track of the services?

Here is the part which requires the whole SOA implementation to work in unity and harmony. It
requires data from all the lifecycle of the services from all the parts of the SOA infrastructure. From
registry we get to know which services are available, the monitoring system shows which were used
and when they were used and also by whom and the IT infrastructure and change management system
defines when the service came up, when was it hanged/updated and what was changed.

Conclusion:
This was supposed to be shorter, but then I couldn't compress it further. From this we see that SOA
Governance is a very vast and crucial aspect of SOA. It may appear that SOA Governance asks for
tight coupling of components which is not true. One sentence I saw somewhere is SOA Governance is
about getting a single view for the wide and diverse components in the SOA infrastructure, It calls for
a logical coupling of components while physically, technically and geographically they remain as
decoupled as they always were.