Getting control in SOA strategy

The registry and repository are key to SOA governance, says Tim Holyoake

Holyoake: SOA governance should set out rules for the whole life cycle

One of the success factors in introducing and operating service-oriented architecture (SOA) is governance of the components, such as services and processes. Effective SOA governance requires a registry and repository for the entire component life cycle.

Governance for SOA should set out rules for the operational and organisational structure as well as technological rules for the entire life cycle.

You must determine who ‘owns’ the services. Also, roles around certain areas of the life cycle must be established.

It is essential to integrate the IT architect’s job, for instance, into the development process so the right services are approved, documented and properly tested.

Governance must manage the SOA’s technical complexity as well. It also requires monitoring and implementation mechanisms for regulating and guiding development processes.

SOA governance cannot be deployed as a functionality within a single software application. Complex aspects must be used across applications and projects.

The registry and repository are important. A registry manages meta-information – for example, about services, processes and format descriptions – maps, relationships and dependencies.

The objects themselves are not managed or stored there. 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.

Components can be categorised to assign services to a certain service domain, technical function, or process. This means the architecture is fully documented.
A registry is essential for accessing services in a distributed architecture of loosely linked services.

The repository adds information, such as descriptive documents, specifications, service level agreements (SLAs). Furthermore, a governance solution means you can 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 of services and processes so certain predefined rules are applied. 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 activated automatically via an existing policy if developers want to publish a new service.

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 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, SLAs, existence of security tokens, access monitoring, and performance monitoring.

If these criteria are set as policies, a policy enforcement point (PEP) handles preparation and implementation during operation.

An example 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.

The existing implementation need not be customised.

SOA governance also addresses change management of components after their introduction.

Above all, in this phase of the service life cycle, use a dependency analysis to figure out what effect the changes to a component have on other services, processes, and departments.

Ideally an organisation has only one central registry and repository. If an organisation grows, however, various registries and repositories may be used, say, for an individual ERP system or a new unit.

Tim Holyoake is lead technologist at Software AG