Impact Management and service models

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.

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