One of the success factors in introducing and operating a service-oriented architecture (SOA) is governance of the architecture's components, such as services and processes. Effective SOA governance can be implemented by deploying a registry/repository for the entire life cycle of the components.
Corporate governance regulates an organisation within a framework of laws, values, standards, rules and guidelines to achieve long-term goals—while maintaining basic conditions. IT governance seizes on an organisation's strategies and objectives and implements them via IT solutions. SOA governance is a part of corporate governance that deals with regulating and monitoring the components of a service-oriented architecture.
Effective governance for service-oriented architectures defines rules for their operational and organizational structure, as well as technological rules, for the entire life cycle of such a landscape. The organisational aspects, for instance, include determining who "owns" the services. In addition, roles responsible for certain areas of the life cycle are established.
An IT architect, for example, is responsible for services within a department, where the architect decides whether to develop new services. It is essential to integrate this role into the development process as a way of ensuring that new services are realised only if the responsible architect has approved and a service goes into production only after it has been documented and tested completely.
The example of the IT architect demonstrates that governance must manage the SOA's technical complexity as well. In addition, it requires an infrastructure in the form of monitoring and implementation mechanisms for regulating and guiding development processes in the context of an SOA environment.
SOA governance is not a task that can be implemented as a functionality within a single software application. Its complex aspects are implemented via a powerful governance solution that is used across applications and projects as a central control tool.
The registry/repository is among the most important components of such a solution. A registry manages meta information, for example about services, processes, format descriptions, etc., and maps relationships and dependencies. The objects themselves are not managed or stored here. Thus, the registry enables categorisation and organisation of the services or other components. Users can publish new components in the catalogue and search for existing ones. The components can be categorised in several ways, so that services are assigned to a certain service domain, technical function, or process, so that the architecture is fully documented.
A registry is essential for accessing services in a distributed architecture of loosely linked services. The repository augments existing information with additional information, such as descriptive documents, specifications, SLAs, etc. In addition, a governance solution makes it possible to map the entire life cycle of a component and by using policies, it can monitor a component's transition from one phase of the life cycle to the next.
A governance solution should offer a combined registry and repository and be based on open standards.
Governance begins during the design phase for the services and processes, and its job is to ensure that certain predefined rules are applied during the definition and development of components. The policies could ensure, for example, that a service is technically correct and valid and meets the relevant standards before it is published.
This type of review workflow can be automatically activated via an existing policy if developers want to publish a new service, for example. "Smart policies" can determine which policies are assigned to a component type, so the correct rules for each type are applied automatically with new services. Not only does this save time, but it also guarantees complete governance.
At runtime, governance means defining and implementing policies that guide the use and implementation of the services. Rules of this type typically apply to quality criteria and requirements that a service or process must comply with at runtime, such as quality-of-service aspects, service-level agreements (SLAs), existence of security tokens, access monitoring, and performance monitoring.
If these criteria are set as policies, then a policy enforcement point (PEP) handles preparation and implementation during operation. An example of such a PEP in an SOA is a news transport system that operates as an intermediary layer between the service provider and the consumer. If a consumer wants to use a service, the PEP can check whether certain regulations and security standards are maintained or whether SLAs are available.
This communication can take over an enterprise service bus (ESB), which typically handles additional functions like data transformation, message queuing, and reliable messaging as well. One advantage of an intermediary separating consumers and providers lies in the fact that the existing implementation need not be customised.
SOA governance also addresses change management of components after their introduction. Corrections and add-ons are needed because the components must be adapted constantly to new business requirements as well as being taken out of operation one day. This part of governance depends primarily on change management practices.
Above all, in this phase of the life cycle of a service, it is important to know what effect the changes to a component have on other services, processes, and departments. Because all components in the system are linked with each other, this can be found out easily via a dependency analysis.
Ideally an organisation has only one central registry and repository. As the organisation grows, however, it often happens that various registries/repositories are in use, for example, for an individual ERP system or for an organisational unit that is acquired. This is not fundamentally bad, as long as a master registry/repository is defined and is guaranteed a consistent data inventory via a standards-based data exchange.