A primer on SOA governance

How would a small company, perhaps a net consumer rather than a provider of services, relate to SOA Governance?

If the company is a net consumer of SOA services from other business partners then governance is of tremendous value as it can be used to enforce service level agreements and to validate both service requests and service responses. Reversely, SLA monitoring could be used to establish premium prices for higher service availability or response times.

What are the (internal) roles and responsibilities involved in SOA Governance?

Since SOA governance needs to be planned and implemented along with the SOA infrastructure it makes a lot of sense to bring the two together, typically by establishing a SOA Centre of Excellence that is responsible for enterprise-wide planning and assists in execution. However, it is also advisable to separate the roles of the SOA architect and the governance architect since conflicting interests may sometimes arise.

In terms of responsibilities, anyone touching the SOA infrastructure needs to be properly trained to ensure that governance guidelines are followed.

Do you see SOA Governance as primarily a technical issue, or a cultural/business issue?

It has to be both since you want to focus your governance efforts on things that matter from a business execution point of view and not just pure technical compliance at the SOA infrastructure level.

When I was at QCon recently, I asked Burton Group Analyst Anne Thomas-Manes about the issue of the 'dark path' in SOA – what happens when one of a group of services contributing to a business operation fails and you have to sort out the mess? Is this dark path ever properly designed and tested? She said this was simply a governance issue. What are your views on this?

If by failure we mean that the service produces non-compliant data (as a part of a request or a response), then properly implemented governance can certainly help you by imposing schema validation, checking of digital signatures etc. However, pure operational failure would normally be handled in other ways. Logging, tracking and auditing can help you sort out failure in a post-mortem fashion, but halting erroneous operations as they occur is where most value is to be gained since corrective business processes can be invoked immediately.

You have a service virtualisation technology called Active Matrix. Surely, this is just a neat technical solution to building SOA effectively. How do you see virtualisation generally (and, perhaps, ActiveMatrix specifically) as contributing to SOA Governance - if you do?

Before addressing that question I think it's worthwhile pointing out that by service virtualisation we mean a technology that separates all aspects of the operational environment that a service executes in from the core logic of the service. This means that no aspects of governance and policy management logic, such as encryption, authentication, schema validation, routing etc is contained within the service itself but rather configured externally. What this means is that control of how governance is applied and operated can be transferred from programmers to operational staff, which is where governance really should be handled. However, it also means that no aspects of governance are contained in code, where it rapidly becomes invisible and unmanageable but rather transferred to configurable governance policies that can be managed as proper assets.

So, service virtualisation holds great promise in alleviating many of the core pains that are currently associated with implementing governance in a consistent and manageable fashion while easing the pain for those who implement the core service logic. By doing this, it also enhances the prospect of services being reused since the core services have no internally embedded policies.

With ActiveMatrix, we have taken this concept several steps further and also made it technology and deployment neutral. In clear, this means that we can mix .Net services with Java services in the same OS-process or in a distributed fashion while imposing governance policies on every single interaction between services. We do this by complying with the JBI standard and the emerging SCA standard, but extending it beyond Java to .Net, C++ and scripting languages and embedding governance at the core of the platform.