Unlike previous software paradigms where an application package enters a support or maintenance phase once put into production, SOA involves a dynamic network of interdependent services that are in an ongoing state of adaptation and optimization. Since services, transactions, and SOA events of interest can be monitored by the IT management system, it's a logical source of runtime information that can be fed back into the registry/repository to facilitate the orderly evolution of the SOA environment.

This information might include:

• SLA-related metrics, such as the average response time, availability, or throughput of a specific service
• Process-related metrics in the form of Key Performance Indicators (KPIs) that associate services with user-defined busi-ness process metrics (e.g., average order amount)
• Business activity monitoring (BAM) alerting and notification events related to business-level exceptions.

Information such as this can be used to optimize service delivery during the change-time cycle by guiding adjustments in policies, service levels, or in the services themselves. Changes to services will require the change-time governance practices described earlier to be put into effect, for example, performing an impact analysis to assess the implications of changing a service and dealing with the resulting version management issues.

As with integration between the message transport and the registry/repository, it's beneficial to have out-the-box linkages between the registry/repository and the management system so that data flows seamlessly between the two without needing additional integration.

Governance Rules Engine
A rules engine isn't strictly a requirement of an SOA governance system, but incorporating rules-engine technology in the registry/repository enables a significant degree of flexibility and automation, while reducing the reliance on humans to perform mechanical governance tasks (and the associated risk of error).

Rules are typically associated with events, while the rules engine handles the firing and chaining of rules. For example, a company's policy might be that access to services in production is strictly limited to staff belonging to an IT operations role, whereas in the test environment, access is also granted to developers. The rules engine could automate the process of setting and resetting access control switches at lifecycle milestones such as when a service is promoted from development into testing or production. A rules engine also provides the basis for creating complex policies based on reusable templates.

Besides automating governance tasks, the rules engine can help deal with policy federation, or the ability to allow multiple policy authors and authorities. This is an important use case for enterprise SOA adoption where governance policies might not be authored and controlled by a single department or organization. A more robust model - that is the basis for policy federation - is to enable both centralized as well as distributed policy creation. Policy federation requires the establishment of guidelines and rules for reconciling policies that come into conflict, and the rules engine assists in the execution of these rules.

Lifecycle Management
The final key ingredient of an SOA governance system is the user environment that presents the human interface to the regis-try/repository and incorporates the governance lifecycle processes and workflows. Typically, the process workflow includes the following steps:

• Publishing a service by an authorized provider
• Discovering a service by a potential consumer
• Requesting use of the service by the consumer
• Agreeing on the terms of delivering the service
• Authorizing the consumer
• Provisioning of the service
• Monitoring of the service delivery

Related to each of these steps, organizations might define approval and notification workflows, exception alerts, and a variety of other process steps. The SOA governance lifecycle management capability will manifest itself in the forms of screens - with information customized to the user's role in the governance frame-work - reports, and integration with e-mail to communicate notifications and approval requests. An important feature when serv-ices are extended to business partners is the ability to make these lifecycle management capabilities available securely across the firewall.

Conclusion Ultimately, SOA governance is about maintaining control over the environment to engender the level of trust required for ongoing SOA adoption and success. While effective governance rests in how it's institutionalized in the organization, having the right technology framework makes it easier - and in some situations is the only sustainable way - to enforce policies and controls. This framework should include mechanisms for defining policies and service contracts and enforcing them through the service lifecycle through workflows, intermediaries, and other automated mechanisms.

By establishing the right balance between strategy, 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