This documentation supports the 21.05 version of BMC Helix CMDB.

To view an earlier version, select the version from the Product version menu

Service modeling

A service model is a logical representation of the relationship among 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 represent 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 contains the processes, shows how the CIs are interconnected, and shows how CI failures propagate and impact the business and technical 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, BMC Helix CMDB allows for the construction of service models. Service models allow users of the system to visualize the relationships of CIs 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 on the consumers of those services.

Constructing service models in BMC Helix CMDB is inherent in the data populated, normalized, and reconciled as part of your data population process. This process includes building and maintaining the relationships among the CIs. When your data is refreshed, these relationships are also refreshed.

Service modeling is not a special activity that is separate from the data population process but an inherent part of population of BMC Helix 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 BMC Helix CMDB as part of your data maintenance processes and that Service CIs exist for your CIs 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 technical services that support them, and identify 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, such as an outage.
  • 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 Helix CMDB.  

Information about each CI is recorded in a configuration record within BMC Helix CMDB and is maintained throughout a CIs 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, BMC Helix 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 —  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.


Related topics

Building a service model

Was this page helpful? Yes No Submitting... Thank you

Comments