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.
Implementation knowledge | Use case | Deployment scenario | Service models |
|---|---|---|---|
Very low | You are performing event management only. | Events only | None |
Very low | You are monitoring systems but not modeling even up to the application level. | Basic monitoring (data and events) | None |
Low | 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 |
Medium/low | 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 |
Medium | 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 |
High | 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 |
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
Related topics