In most organizations, virtually every IT resource and process will have some level of governance associated with it in the form of policies, rules, and controls that define how a particular asset is managed and utilized, or parameters around how a certain IT function is performed.
The act of establishing and enacting these rules falls under the broad umbrella of IT governance, with the purpose being to institutionalize discipline and maturity in IT processes so as to gain greater control and economies.
SOA governance, is a subset of IT governance related to establishing policies, controls, and enforcement mechanisms—within the context of the activities and constructs associated with SOA—similar to those that exist for managing and controlling other aspects of IT.
Initially, the concept of SOA governance was applied narrowly to the development and use of Web services, for example, validating the conformance of a Web service with specific standards or managing Web services in the SOA run-time environment.
The paper defines SOA Governance in the following way:
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.
Without effective SOA governance, organizations will experience some predictable challenges:
1. A fragile and brittle SOA implementation
2. Services that cannot easily be reused because they are unknown to developers or because they were not designed with reuse in mind
3. Lack of trust and confidence in services as enterprise assets, which results in a “build it myself” mentality (further compounding the lack of reuse with redundancy and unnecessary duplication of functionality)
4. Security breaches that cannot easily be traced
5. Unpredictable performance
The first requirement of SOA governance is architecture governance.
Architecture governance is necessary to ensure that SOA as architecture evolves by design and not by accident.
A key aspect of SOA architecture governance is defining a roadmap that will guide the smooth and orderly evolution of the architecture over time.
SOA exposes standalone application functionality at a fine-grained level of granularity, thus necessitating a new form of governance—service-level lifecycle governance.
Service-level governance applies at the level of individual services and covers a wide gamut of requirements and situations.
Design-time governance is primarily an IT development function that involves the application of rules for governing the definition and creation of Web services.
Policies might include ensuring that services are technically correct and valid, and that they conform to relevant organizational and industry standards.
If an organization has an SOA governance infrastructure in place—in the form of software that facilitates the implementation of SOA governance practices—these checks can be invoked automatically when developers check services into a registry.
In addition, approval and notification workflows can be triggered by a governance-enabled registry to ensure that services pass through pre-defined review and approval steps so that they meet architectural and organizational standards for business function encapsulation, reusability, reliability, and so on.
Governance at run-time revolves around the definition and enforcement of policies for controlling the deployment, utilization, and operation of deployed services.
These run-time policies typically relate to non-functional requirements such as trust enablement, quality-of-service management,and compliance validation.
Examples of run-time governance include:
- Checking a service against a set of rules before it is deployed into production, for example, to ensure that only a certain message transport or specific schemas are used
- Securing services so that they are accessible only to authorized consumers possessing the appropriate permissions, and that data is encrypted if required
- Validating that services operate in compliance with prescribed corporate standards, in effect, to confirm that a service is not just designed to be compliant, but that its implementation is actually compliant
A more specific case of run-time governance involves service-level monitoring and reporting.
Change is inevitable and, at some point, services deployed in the run-time 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 lifespans, change-time governance—the act of managing services through the cycle of change.
The second section of the white paper describes the technologies behind SOA Governance.
At a basic level, an SOA governance system should facilitate service-level governance across the lifecycle from design-time to run-time to change-time. It should allow polices to be defined and created, and provide mechanisms for these policies to be enforced at each phase of the service lifecycle.
The main components of this system include:
- A registry, which acts as a central catalog of business services
- A repository, for storing policies and other metadata related to the governance of the services
- Policy enforcement points, which are the agents that enact the actual policy enforcement and control at design-time, run-time, and change-time
- A rules engine for managing the declaration of policies and rules and automating their enforcement
- An environment for configuring and defining policies and for managing governance workflows across the service lifecycle
A registry is usually identified as one of the first requirements of SOA adoption and registries play an important role in governance. In simple terms, a registry is a catalog or index that acts as the “system of record” for the services within an SOA. A registry is not designed to store the services themselves; rather, it indicates their location by reference.
As the place where services are made known within the SOA, a registry is also a natural management and governance point. For example, compliance requirements—such as
conformance with the WS-I Basic Profile or the use of specific namespaces and schemas— might be imposed on services before they are allowed to be published in the registry. Or, as services are registered or changed, the registry also has the ability to trigger approval and change notification workflows so that stakeholders are alerted to changes.
An SOA registry typically fulfills the following functions:
- Stores service descriptions, information about their end-points and other technical details that a consumer requires in order to invoke the service, such as protocol bindings and message formats
- Allows services to be categorized and organized
- Allows users to publish new services into the registry and to browse and search for existing services
- Maintains service history, allowing users to see when a service was published or changed
A governance repository should support the following capabilities:
- An information model or taxonomy for representing and storing organizational and regulatory policies that can be translated into rules that are enforced by the SOA governance system. It should be possible for policies and rules to be interpreted
by people or machines (and sometimes both) as appropriate.
- Audit capabilities for tracking the trail of changes and authorizations applied to assets within the repository context.
- Identity management capabilities and role-based access controls to ensure that
only appropriate parties have access to policies.
- A notification system and content validation capabilities to provide additional assurances that policies are well-formed, consistent, and properly applied.
In practice there are many benefits to combining both Registry and Repository into a single entity.
Implementing them as separate products creates the burden of duplicate data entry, sets up the need to synchronize information, and increases the risk of inconsistencies between the two.
The places where policies are actually applied and enforced—the policy enforcement points—change depending on the lifecycle stage. During design-time, the registry/repository itself is the point of enforcement. During run-time, policies are generally enforced by the underlying message transport system that connects service providers with consumers. Finally, during change-time, policies are typically enforced by the IT management system.
A rules engine is not strictly a requirement of an SOA governance system, but incorporating rules engine technology within the registry/repository enables a significant degree of flexibility and automation, while reducing the reliance on humans to perform mechanical governance tasks.