So SOA Governance—I’m sure you’re seeing lots of announcements regarding this from an ever increasing motley crew of providers. These are all pieces of a larger puzzle.

There is some significant confusion among end users about this vital topic. Gartner says that the top reason for failure in post-pilot SOA projects in 2006 will be a lack of governance mechanism—but with all the vendor buzz and confusion, there’s a need for clarification on this essential topic. Hopefully this guide will help.

What is SOA Governance?

It’s the creation, communication, enforcement, maintenance and adaptation of policies across the SOA lifecycle of design time, run time and change time.

Why is SOA Governance important?

It’s a poorly kept secret that SOA has too many moving parts. This means that without mechanisms of control and enforcement, business policies can be breached (resulting in individuals acting in ways that hurt the organization) and technical policies can be breached (resulting in nonfunctioning, inefficient or noncompliant technical services).

What are policies?

Policies are guidelines that influence decisions or actions. The actions can be carried out by humans or machines. Policies typically have a “target set” or “filter” which determines when they are in force. For example, an equal opportunity policy applies to the set of employment applicants to the company. An executive retention policy applies to the set of managers ranked above “E10” in the HR system. A security policy can be applied to “all messages passed outside the firewall.” These generally fall into two classes: business policies and technical policies.

Why are business policies important?

Business Policies ensure that every action taken within an organization is to the benefit of the organization. With so many moving parts in SOA, no single constituency should be able to run an agenda counter to the interests of the whole business. An example would be an IT service organization which seeks to reduce cost of service support by shutting down essential services. This meets the division’s goals of lowering cost, but at the expense of the greater whole. In many cases, business policies are implemented by people.

Technical policies can be extended to include the set of all enforceable (executable) metadata associated with a service. This would include WSDL and Schema documents, most certainly, but also things like BPEL which defines “policy” about how orchestration happens, as well as governance rules within a rules engine. Typically in SOA, policies are defined in XML declaratively, which makes them transparent, agile (mutable) and conformant.

Why are technical policies important?

Technical Policies represent a class of Externality which cuts across enterprise services. This means that policies are particularly hard to encode and maintain in traditional IT application development systems. This is why in SOA, policies are externalized as metadata—so they can be changed as the circumstances dictate. In many cases, technical policies are implemented by machines.

Who participates?

Typically in an enterprise-scale project, you see cross-functional Centers of Excellence (CoE), Competency Centers, Architecture Teams, or other such bodies. You need a budget authority, as well as organizational competencies to handle a reorganization of the company in order to align with the idea of shared services. In some cases, external entities, such as System Integrators, help to add methodology and best practice to Governance.

Why reorg?

Today’s IT fiefdoms are used to battling with one another for enterprise resources, not for sharing. The reporting structures are usually not set up correctly. Best practices include setting up things like “shared resources” organizations, which are tasked with providing service to other organizations. Matrix and virtualized teams also emerge, but the key is to provide an appropriate structure for accountability. If you just let people fight over the shared resources, you could hit choppy waters fast.

What’s the tooling?

It depends—but you need two mechanisms (which could be a single entity). You need a policy system of record, and a policy enforcement point. These entities change as you move across the lifecycle of design time, run time and change time. A significant feature of a policy system of record is accessibility—you want to ensure that all appropriate constituencies have access to define, communicate and change policies. And of course, access should be controlled to prevent inappropriate access.

Whatever tooling you select, make sure that you have a policy system of record and a policy enforcement point (or mechanism) for each of design time, run time and change time.

What’s the significance of “SOA Registry Repository”?

SOA Registry Repository acts as a policy system of record for policies across all three lifecycle stages. During design time and change time, the Repository itself acts as a policy enforcement point—enforcing reuse policies, running conformance and interop tests, and managing change through impact analysis and change notification and approvals.

Where do specialized developer tools fit in?

Increasingly, source code repositories and asset management systems are being used as a policy system of record during design time. They can also act as a policy enforcement point for design time policies.

What’s the significance of “Service Bus” or “Service Fabric”?

A run time intermediary acts as a policy enforcement point during the run time lifecycle stage.

How do you define “Change Time”?

Change time is unique to SOA—and adapting to change is the most significant value of SOA (even more than reuse). Change time involves absorbing run time metrics about policy enforcement events, and making appropriate adjustments to services, processes and policies.