CMDB and service modeling


Important

If you have subscribed to BMC Helix Discovery or BMC Helix AIOps, use the blueprints templates to build your service models.

For information about blueprints in BMC Helix Discovery , see Service modeling with blueprints in BMC Helix Discovery.
For information about blueprints in BMC Helix AIOps , see Building service models by using blueprints in BMC Helix AIOps.

A service model maps the relationships between IT infrastructure components (CIs) critical for delivering and supporting business services. It improves IT operations by visualizing dependencies, assessing failure impacts, and linking technical issues to business services.

Business services consist of multiple processes supported by functional applications and IT infrastructure. The service model shows these components, their interconnections, and how disruptions in one CI affect others, influencing service delivery.

Infrastructure components include devices, groups, and applications. Devices are essential managed entities, while groups are resource sets defined by operational needs. The service model provides a real-time view of these dependencies, enabling proactive management and swift issue resolution.

Example

Apex Global is an e-commerce company that is represented by the Business Service as the logical entity (top level node). To deliver the business service, there is the Technical service tier represented by two key systems (nodes) - Catalog and Inventory

The Infrastructure tier forms the foundation by providing critical resources (nodes) such as servers and databases to the Technical service tier. 

The lines between the nodes represent their dependencies.

The following image shows a visual representation of the example for a service model:

Example_services in a model.jpg

Purpose of service models

Use service models to visualize the relationships of CIs with the services consumed by systems or actual users.

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 serve 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 table provides more information for creating service models in BMC Helix CMDB and exporting the service model to generate reports:

Task or concept

Reference

(BMC Helix ITSM suite-only customers) Use predefined templates from blueprints to create service models quickly for topology data discovered from multiple data sources.

Use a query that finds CIs associated with a specific service and adds 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.

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.

Providers and consumers.jpg

For information about creating a service model, see Managing-service-models.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*