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.
An impact service model is used to:
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.
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.
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.
You are performing event management only.
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.
You create service models by using the following BMC products:
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 .