CMDB and 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
Use service models to visualize the relationships of CIs back to services that are consumed, either by systems or by actual users. Incident Management and Change Management use these service models to understand the impact on the consumers of those services.
Service modeling 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.
The main activity related to creating service models is making sure that the relationships between CIs are logical and in place, and the impact attributes are set appropriately either from the source of the data or managed via normalization, or manually within BMC Helix CMDB.
Service models have the following purposes for infrastructure management:
- To be able to see how CI failures propagate and impact the upstream services.
- To visualize the impact to a service and to automatically open Intelligent Incidents that contain information about the failed or failing IT components. It also shows the services that these IT components impact and helps with prioritization and faster troubleshooting.
The following figure shows an example of a service model:
In the example, Apex Global represents the entire service, which is a logical entity and is the top level node in the service model. Apex Global 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 Apex Global 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.
The following table provides more information for creating service models in BMC Helix CMDB and exporting the service model to generate reports:
Task or concept | Reference |
|---|---|
Use a query that finds CIs associated with a specific service and add them to the service model. | |
Monitor your IT environment by tracking the changes that occurred in a service model. | |
View the list of CI superclasses, CI types, and CI classes as defined in the data model. Then, you can use the CI as a service model component. |
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 Common-data-model.
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 — Describes the functionality that an organization provides. In BMC Helix CMDB, the service is a container that includes service offerings, requestable offerings, and service level targets.
- Business service — Services available for customers to use, 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 CMDB Explorer with other CIs.
- Service offering —Defines the service that an organization provides for a price and how it is provided.
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 — Similar to a Service offering, defines the service that an organization provides and how it is provided.
However, unlike service offering, end users can see and select these services. Requestable offerings provide options for how IT implements the service offering. Each requestable offering too 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 an offering.
- Options — Describes discrete choices that customers can select for a service, requestable offering, and transactional offering.
Each option has one or more choices with cost and price information. Options are reusable and are managed separately from offerings because they do not rely on a specific offering.
The following image shows an example of different services in a service model:
