Page tree

Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

A service model is a generic term for a logical representation of the relationship between IT infrastructure components. Service models can belong to several categories such as network topology, dataflow, dependency, and impact. In the context of Infrastructure Management, a service model is typically an impact service model. An impact service model specifies which higher-level entities, such as applications, technical services, business services, and organizations are impacted, and how they are impacted when lower-level IT infrastructure entities, such as servers, network devices, and application systems are affected by some condition. 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.

Benefits 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
  • Perform root cause analysis or probable cause analysis to identify the underlying cause of a problem reported on a higher-level service
  • Provide a visual display of the status of a service and its dependencies for a NOC display
  • Generate intelligent incidents (when integrated with BMC Remedy Service Desk) that contain information about the causal event, the impacting CI, and the impacted top-level service

Configuration items

A CI is any component that must be managed in order to deliver an IT service. Information about each CI is recorded in a configuration record within BMC Atrium Configuration Management Database (CMDB) and is maintained throughout its lifecycle by Configuration Management. CIs are under the control of Change Management. 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, have some characteristic that can change, be manageable, have certain attributes that are associated with it, and be recorded in BMC Atrium CMDB.

Information about a CI can be stored in Infrastructure Management even without the presence of BMC Atrium CMDB. However, this information will be limited to performance and event management. BMC Atrium CMDB is required from an asset management or configuration management perspective. 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 components that consume 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.

Levels of impact service model

The levels or layers in an impact service model can vary but impact service models typically start at the physical device level and work up through the various application infrastructure levels to the application and on to the technical service, business service, and organization levels. Even when the goal is to model up to the business service level, it is good to start off by modeling up to the application level, and then relating the applications to the services that they support.

The approach and level of detail used in creating service models depend a great deal upon your implementation knowledge. Unless all of the details are known ahead of time, it is good to start off with a simple model and add detail or granularity later as and when needed.

The table below lists the type of service models you can create depending upon your use case and implementation knowledge.

Implementation knowledge

Use case

Deployment scenario

Service models

Very low

You are performing event management only.

Events only


Very low

You are monitoring systems but not modeling even up to the application level.

Basic monitoring (data and events)



You are managing at the application/technical service level. You create service models at the simplest level to represent the application or the technical service and these models are used for root cause analysis and probable cause analysis. The number of models you require is relatively low (lesser than 50).

Standalone Infrastructure Management

Application or technical service models, 2 to 4 levels deep


You are managing at the application/technical service level. You might create models at a slightly more granular level and may include tiered services. You use CMDB to edit the service models. The number of models you require is low to medium (25 to 100).

Infrastructure Management with BMC Atrium CMDB (without BMC Atrium Discovery and Dependency Mapping)

Application or technical service models, 2 to 6 levels deep


You are managing at the technical/business service level. Application or infrastructure models are discovered and pulled into higher-level service models.  The number of applications modeled is medium to high (50 to 200).  The number of business services modeled is medium (10 to 50).

Infrastructure Management with BMC Atrium CMDB and BMC Atrium Discovery and Dependency Mapping

Technical or business service models, 3 to 8 levels deep


You are managing at the business service level. Application or infrastructure models are discovered and pulled into higher-level service models. The models may be split across multiple Infrastructure Management Servers.  The number of applications and business services modeled is high (greater than 200 applications, greater than 50 services).

Multiple Infrastructure Management Servers

Business service models that include high level of granularity, 4 to 10 levels


Working with modeling at each level does not preclude including CIs from higher levels. For example, you might be implementing only event management or basic monitoring and may integrate with BMC Atrium CMDB and BMC Atrium Discovery and Dependency Mapping to be able to discover and pull in the computer systems in the environment. This will enable you to integrate with BMC Remedy Service Desk at the Computer System CI level.

How service models are created

You create service models by using the following BMC products:

  • BMC Atrium Explorer
  • BMC Impact Model Designer
  • Infrastructure Management administrator console


If defined, you can monitor business services (instances of the bmc_businessservice CI) from the Applications page in the TrueSight console. For information, see "Viewing business services and cross-launching to the Infrastructure Management operator console" in Viewing the health of applications in your network Open link .


Related topics

Use cases for centralized service models

Defining the service model