A service model is a logical representation of the relationship between IT infrastructure components that are required to support or provide functionality to the service. Some examples for infrastructure components are devices, groups, computer application systems, and so on.
A device is any computer that needs to be managed in order to deliver an IT application, and a group is a selected set of devices or monitors, determined by your operating needs. A service model provides you the real time picture of its dependent components and their impact on the overall service.
The following figure shows an example of a service model:
In the example, Calbro Systems represents the entire service, which is a logical entity and is the top level node in the service model. Calbro systems is a telephone service provider that provides both landline services and cell phone services in a small rural town.
Cellphone Systems, and Landline Systems are the two computer application system nodes that provide major functionalities to the Calbro Systems service.
The data storage nodes, Cellphone Database, and Landline Database, is where data is stored and accessed by the service entities.
The lines between the nodes represent their dependencies.
Impact service model
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 decompose a business service to identify and document business processes, identify the IT services that support them, and identify IT 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.
- 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 Network Operation Center (NOC) display.
In the impact service model, each entity is referred to as a Configuration Item (CI). A CI is any component that must be managed in order to deliver an IT service. 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, manageable, have certain attributes that are associated with it, and can be recorded in BMC Atrium CMDB.
Information about each CI is recorded in a configuration record within BMC Atrium Configuration Management Database (CMDB) and is maintained throughout a CI's life cycle by Configuration Management. CIs are under the control of Change Management. 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 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.
A service model administrator can manually create service models through BMC TrueSight Infrastructure Management. The tools you use to create and edit the service model depends on the products you have installed and integrated with Infrastructure Management Server:
- Use the Services Editor in the administrator console. For more information, see Editing a service model using Infrastructure Management administrator console.
- Use Impact Model Designer to create and maintain the service models. For more information, see Building and publishing service models from BMC Atrium CMDB.
- Use BMC Atrium Discovery and Dependency Mapping to discover the infrastructure components and their relationships. Use Impact Model Designer in Atrium Core Console to refine the sub-models and relate them to the higher-level configuration items (CIs). For more information, see Editing a service model using BMC Atrium Explorer.
Discrete and distributed service models
Infrastructure Management monitors multiple components (CIs) that compose parts of a service model. Infrastructure Management also displays the status of the CIs and identifies the root cause of the service being impacted. Service models can be categorized as discrete and distributed models as explained in the following section:
- Discrete service model: A service model in which all the Configuration Items (CIs) are created on a single Infrastructure Management Server is called a discrete service model. The number of CIs in a discrete model is limited to the maximum number of CIs supported by Infrastructure Management. For example, Calbro Systems is a telephone service provider that provides both landline services and cell phone services in a small rural town. Calbro Systems requires a service model that spans a large number of CIs. The needs of Calbro Systems can be met by a single BMC TrueSight Infrastructure Management Server that can accommodate a service model containing a large number of CIs and a Publishing Server that can publish these CIs. For more information, see Discrete service models.
- Distributed service model: A service model that is distributed across two or more Infrastructure Management Servers is called a distributed service model. When the number of CIs in a service model exceeds the maximum limit of CIs allowed in a single server, it is possible to distribute the model across multiple Infrastructure Management Servers. For example, Calbro Systems is a telephone service provider that provides both landline services and cell phone services. Calbro Systems requires a service model that spans a large number of CIs. At present, a single BMC TrueSight Infrastructure Management Server can only accommodate a service model that contains a limited number of CIs and the Publishing Server can publish only few CIs at a time. To build and manage a large number of CIs, Calbro Systems must split a service model across multiple BMC TrueSight Infrastructure Management Servers. For more information, see Distributed service model.
In environments that use large service models, the need arises to distribute different components of the model across various Infrastructure Management Servers but at the same time it must allow the IT service operators to view the complete model and its status from a single user interface. You can monitor these huge service models in the TrueSight console. For more information, see Setting up services to monitor from the TrueSight console.