Service management profile: introduction

The service management profile (SMP) distills the best practices for governance across varied business types and industries.

Governance involves modeling your business objects and practices so that everyone in your enterprise follows a predefined set of behaviors in a way that can be controlled and audited.

The SMP contains three main concepts:

Objects
Lifecycles
Policies

Objects model your business. Each type of object has a lifecycle: a predefined set of states and transitions between these states. Each transition between states in a lifecycle can be controlled by a policy, or a set of policies; known as governance policy validators. These policies control aspects of the transition: for example, who can make the transition and what relationships or attributes need to be set before the transition can occur. In this way, the SMP is the blueprint of good behavior for your enterprise.

The following table shows the main types of object available.

Table 1. Main objects types in the SMP
Object	Description
Organization	In any governance process, there must be ownership. The organization object embodies this ownership. Every other object must be owned by an organization, either directly or indirectly.
Business capability	A business capability object expresses a business view of a capability that is required within your enterprise. The object describes the business needs and concerns, but not the implementation. The capability can be viewed from a generalized business perspective. There are a number of types of business capability. For example, a capability might be used with other capabilities to build a wider capability. In this case, the capability is considered as a service and represented as a business service. Business service, business application, and business process are specific types of business capability.
Capability version	A capability version is the realization of a business capability. The capability version indicates how the business capability is provided, for example, whether it is a web service, whether it requires messaging, and so on. Aspects of the implementation, such as web service definitions or SCA modules, are referenced from the capability version. In the same way as business capabilities have specific types, so do capability versions. For example, capabilities which are built from other capabilities, or are used to build other capabilities, can be considered as service versions. Service versions, application versions, and process versions are all specific types of capability version. One of the key aspects of capability version objects is that they have version numbers. There might be numerous versions of a capability version which realize the same business capability.
Service level definition	The service level definition (SLD) describes non-functional, or quality of service, characteristics of a capability. These include characteristics such as how many hours a day the capability is available, or the types of security needed on interactions with the capability. Consider a capability version deployed onto a number of different servers, servicing different types of customer, or different geographies. Each server might not be able to provide the same qualities of service and require unique SLDs. However, each consumer interacts with the capability in the same way.
Service level agreement	If a Capability Version is offered for reuse in your enterprise, a service level agreement (SLA) must be created to describe the details of the agreement between the capability consumer and provider. The SLA is usually a subset of the qualities of service offered by the SLD of the providing capability version. For example, the SLD might state that the service is available from Monday to Friday inclusive, but the SLA might define that the service is only required on Wednesday.
Service endpoint	When a capability version is deployed on a runtime system, it has one or more network addressable endpoints. These endpoints are represented by service endpoints. Service endpoint objects inform the user of the service where the service is available on the network.

The following example illustrates how the SMP objects relate to one another.

A Credit Check business service is owned by the Common Services organization. This business service has a real implementation in the form of the Credit Check service version, which has been deployed into three geographical locations. Each geographical location hosts the service on a different server and so there is a different SLD for each installation. Each SLD can offer a distinct set of service endpoints for the service.

shows how the objects in the example relate to one another

After the service has been implemented, it can be offered for reuse. Reuse requires a service level agreement (SLA), and introduces the concepts of service providers and service consumers.

The Commercial division is defining and constructing their own capability called Eligibility Service. They decide to use the Credit Check capability from the Common Services organization as part of their own service. The Commercial division is based in the UK, they negotiate the conditions of the service interaction and capture the conditions in an SLA named SLA – Credit Check.

The following diagram shows the capability version, Credit Check, in a consumer/provider relationship with another capability version, Eligibility Service. The diagram shows the final structure of the main objects in this governance example.

shows the relationship between the eligibility service and the credit check service

The following topics look in detail at how the Credit Check service was evolved and governed, then at how the Eligibility Service was evolved. It examines how the Eligibility Service governance story takes into account the Credit Check service.

Follow the related links for more information on some of the major concepts involved in understanding the service management profile. Work your way through the SMP tutorials to look at different governance scenarios in more detail. The tutorials also provide more discussion about different implementation types such as SCA and REST.