This action might not be possible to undo. Are you sure you want to continue?
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.”  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.”  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.
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.
This action might not be possible to undo. Are you sure you want to continue?