Runtime governance relies on an SOA infrastructure that is able to exercise policy enforcement in a way that is transparent to, and independent of, the service providers and consumers. This is generally achieved through an agent or intermediary that resides between provider and consumer, and a registry that addresses both the needs of service discovery as well as policy enforcement. The intermediary interacts with the registry to find services and their runtime policies, and enforces the policies during the execution of the service (See Figure 1).

Intermediaries serve as the policy enforcement points for SOA. Without SOA, the ability to control and manage applications is restricted both by the scope and the capabilities of the underlying platform. Thus, when different applications are integrated, it is generally infeasible to apply a common policy context to the integrated result. A typical challenge is enforcing access security when two applications with different user communities are integrated. For example, application A automatically draws data from application B, but application A users are not authorized to use application B. How do you now control the data that users have gained access to within application A? With intermediation, it becomes possible for a distributed network of services to share a common policy-managed context. This is a powerful capability which emerges as a direct result of SOA.

Change Time Governance
Change is inevitable and at some point, services deployed in the runtime environment will have to be changed to adapt to new business requirements. Since the majority of services will be designed once and then modified several times over their lifespan, change time governance - the act of managing services through the cycle of change - is arguably more important in the long term than design time governance. Change time governance requirements and considerations include:

• Understanding inter-service relationships and dependencies
• Performing impact analysis to determine the implications of changing a particular service within the runtime environment
• Managing the rollout of services into the existing runtime environment
• Managing service custody transfers through the design, coding, testing, and deployment stages
• Managing changes to existing policies and service-level agreements

An important aspect of change time governance is involvement from the line of business. While easy to overlook when looking at governance from an IT-centric perspective, this need arises from the fact that services exist to support business functions as well as the inter-organizational relationships and dependencies that are implicit in SOA, particularly when services are exposed and invoked across organizational and corporate boundaries. Since changes are generally initiated and driven by business requirements, business users need to be intrinsic participants in the governance lifecycle.

Consider, for example, a service that enables vendor managed inventory. A change in the service, say, to reduce inventory data latency from a week to one day, will involve not only technical changes to the service (and possibly source applications and databases), but more importantly, changes in the business relationship between the company and its suppliers. A comprehensive governance strategy is needed to ensure coordination between the technical and business-level changes. As with design time and runtime, this change time governance can be facilitated by a governance-enabled SOA infrastructure that allows change time policies to be defined and enforced through service contracts and workflows.

Getting Started
For the many companies who are just getting started with SOA, at what point should consideration of governance come into play and where should it be focused?

One priority is to make an SOA governance strategy a subset of any larger SOA strategy, and to ensure that governance capability related milestones are synchronized with SOA adoption milestones, so that you do not end up trying to retro-fit governance after the fact. Ideally, the right time for governance is before you put any services into place so that any SOA pilot proves out not only the approach itself, but also the related governance practices along the way.

As part of the SOA governance strategy, there should be a roadmap that defines which specific governance capabilities the organization wants to put into place and when they will be implemented. Typically, companies will first want to pay attention to the SOA architecture and to design time governance policies in order to get the SOA journey off on the right foot. In fact, since architecture and governance are what separate a collection of Web services from being a true SOA, organizations that went down the path of simply developing and exposing Web services without the appropriate controls or a broader architecture will want to consider an investment in governance.

Finally, while governance is not a solution that comes in a box, having the right technology framework makes it easier - and in some situations is the only feasible way - to enforce policies and controls. As explained in this article, this framework should include mechanisms for defining and enforcing policies and service contracts through the service life cycle of workflows, intermediaries, and other automated means. By establishing the right balance between organizational practices and supporting technologies, companies will be able to turn the concept of SOA governance into a practical reality.

• Executing an SOA Governance Plan
• The Four Stages of SOA Governance