Service modeling

A service model is a logical representation of the relationship between IT infrastructure components that are required to support or provide functionality to the service. A service model helps improve IT operational efficiency and enables assessment of the impact of technical issues on business and operations.

On a high level, a service model is a collection of components, also known as configuration items (CIs), that represents a business service. A business service can have one or more business processes. Each business process can contain several functional applications, each of which can have multiple IT CIs. A service model will contain the processes, show how the CIs are interconnected, and show how CI failures propagate and impact the upstream services.

Some examples for infrastructure components are devices, groups, computer application systems, and so on. A device is any computer that needs to be managed in order to deliver an IT application, and a group is a selected set of devices or monitors, determined by your operating needs. A service model provides you the real time picture of its dependent components and their impact on the overall service.

Purpose of service models

In order to provide additional value the BMC CMDB allows for the construction of Service Models. Service Models allow users of the system to visualize the relationships of CI's back to services that are consumed, either by systems or by actual users. Due to this the processes such as Incident Management and Change Management are enriched further because Service Model allows these participating processes to understand the impact to the consumers of those services in a more user friendly fashion.

Constructing Service Models in the BMC CMDB is inherent in the data populated, normalized and reconciled as part of your data population process as this includes building and maintaining the relationships between the CI's as such when your data is refreshed so are those relationships.

Service Modelling is not a special activity that is separate from the data population process but an inherent part of population the BMC CMDB with data.

The main activity related to Service Model construction is ensuring that the relationships are in place, impact attributes are set appropriately - either from the source of the data or managed via normalization, or manually within the BMC CMDB as part of your data maintenance processes and that Service CI's exist for your CI's to be related to in a logical fashion.

The following figure shows an example of a service model:

In the example, Calbro Systems represents the entire service, which is a logical entity and is the top level node in the service model. Calbro systems is a telephone service provider that provides both landline services and cell phone services in a small rural town.

Cellphone Systems, and Landline Systems are the two computer application system nodes that provide major functionalities to the Calbro Systems service.

The data storage nodes, Cellphone Database, and Landline Database, is where data is stored and accessed by the service entities.

The lines between the nodes represent their dependencies.

Impact service models

Service models can belong to several categories such as network topology, data-flow, dependency, and impact. In the context of Infrastructure Management, a service model is typically an impact service model.

An impact service model shows you how higher-level entities are impacted when lower-level IT infrastructure entities are affected by some condition. Higher-level entities include technical services, business services, applications, and so on. Lower-level IT infrastructure entities include servers, network devices, application systems, and so on.

In the impact service model, all of the entities are referred to as configuration items (CIs), and the relationships between the CIs that specify the impact are called impact relationships. The most basic step involved in defining an impact service model is to divide a business service to identify and document business processes, identify the IT services that support them, and identify IT CIs and assets that provide the IT services.

Advantages of an impact service model

An impact service model is used to:

Identify which higher-level entities are impacted, and how they are impacted, when lower-level IT infrastructure components are affected by some condition.

Provide a visual display of the status of a service and its dependencies for a Network Operation Center (NOC) display.

Configuration items

In the impact service model, each entity is referred to as a Configuration Item (CI). A CI is any component that must be managed in order to deliver an IT service. CIs typically include hardware, software, buildings, people, and formal documentation, such as process documentation, and Service Level Agreements (SLAs). A CI must be uniquely identifiable, manageable, have certain attributes that are associated with it, and can be recorded in BMC CMDB.

Information about each CI is recorded in a configuration record within BMC CMDB and is maintained throughout a CI's life cycle by Configuration Management. CIs are under the control of Change Management. For more information, see How the Common Data Model represents service models.

Providers and consumers

A service model relationship is a link between a component that provides a service and the component that consumes that service. In this relationship, the provider status naturally impacts the consumer status. In the following graphic, Component B is a provider in one relationship and a consumer in another.

A service model administrator can manually create service models through CMDB Explorer. For more information about using the CMDB Explorer to create a service model, see Managing a service catalog by using CMDB Explorer

Components in a service model

To support a service model that complies with ITIL v3, BMC CMDB includes several components that combine the utility (what a service does) and warranty (how the service is delivered). The following figure shows a high-level view of these components.

Service model components

Service — Describes functionality that an organization provides. In CMDB, the service is a container that includes service and requestable offerings and service level targets.
- Business service — Services available to customers that show the consumer view of services, such as email or an online store.
- Technical service — Supporting IT and infrastructure resources required to support business services that are not visible to customers, such as servers, applications, and network configuration items (CIs). These technical services can be associated in Explorer with CI queries.
Service offering — Defines what service an organization provides and how it is provided. A service offering defines a level of service for a price; it combines the service (utility) and a service level target (warranty), and add-on options to bring value to the customer. All technical and business services must have at least one service offering. However, a service can have more than one service offering. You can also associate a service offering with a technical service.
Requestable offering — Defines what service an organization provides and how it is provided. However, unlike service offering, end users can see and select a requestable offering. The requestable offerings provide options for how IT implements the service offering. Each requestable offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), and add-on options.
Service level target — Describes measurements for the performance of a service or offering.
Options — Describes discrete choices that customers can select. for a service, requestable offering, and transactional offering. Each option has one or more choices, each of which has cost and price information. These options and their choices are available for users to select. They are managed separately from offerings because they do not rely on a specific offering, making the options reusable.