In order to provide additional value the BMC CMDB allows for the construction of Service Models. Service Models allow users of the system to visualize the relationships of CI's back to services that are consumed, either by systems or by actual users. Due to this the processes such as Incident Management and Change Management are enriched further because Service Model allows these participating processes to understand the impact to  the consumers of those services in a more user friendly fashion.

Constructing Service Models in the BMC CMDB is inherent in the data populated, normalized and reconciled as part of your data population process as this includes building and maintaining the relationships between the CI's as such when your data is refreshed so are those relationships.

Service Modelling is not a special activity that is separate from the data population process but an inherent part of population the BMC CMDB with data.

The main activity related to Service Model construction is ensuring that the relationships are in place, impact attributes are set appropriately - either from the source of the data or managed via normalization, or manually within the BMC CMDB as part of your data maintenance processes and that Service CI's exist for your CI's to be related to in a logical fashion.

Planning a service model involves the following steps:

1. Define the type of service model and goals.
2. Identify the users of the model.
3. Define the model components.
4. Decide the level of detail that the model should capture.
5. Decompose the service.
6. Analyze component impacts.
7. Verify monitoring of components.
8. Create the service model.
9. Review the service model with the stakeholders.
10. Deploy the service model.

Using BMC CMDB extensions , Impact model designer can identify and document business processes, identify the IT services that support them, and identify IT CIs and assets that provide the IT services. Decomposition approaches- Top-down, bottom up, middle out

Defining the type of the service model and goals

The most basic step involved in defining a service model is defining the specific business goals you hope to achieve with the model. 

To do so, the IT or Integration Service (IS) group must engage the business managers in defining short-term, mid-term, and long-term goals for service impact management for the enterprise. These goals guide the design and development of deliverables for all service model development phases and define the amount of time and effort required for development and implementation. 

Some possible goals for service impact management are as follows:

• Operational efficiency—This type of implementation is run by and for the IT or IS group. It consists of a thin layer of logical groups on top of a large number of IT resources, ranging from applications and systems to hard disks and other hardware configuration items (CIs). Services are just logical groupings that provide a convenient way of classifying the technical resources.
• Business-focused operational efficiency—This type of implementation is likely to involve various populations and centers of management in the enterprise. It consists of a balanced representation of the operational environment, encompassing the IT CIs, such as systems and applications, and the logical CIs, such as services, user groups, and other business objects.
• Business continuity and service availability—This type of implementation is driven from the top and ensures that IT or IS is delivering their services as agreed. It consists of a business-centric model in which business processes, services, and SLAs rely on a small number of vital IT CIs that measure the pulse of the underlying environment.

The service model can be of the following types:

• IT oriented
• Business or Service Level Agreement (SLA) oriented
• Business or process oriented

Identify the users of the service model

You must identify the sponsors and the stakeholders of the service model. You must also identify the users and consumers of the service impact information.

The following list consists of some of the users and stakeholders of the service model:

• Business executives and managers
• IT executives and managers
• IT operations
• Service owners
• IT technical staff

Define the model components 

You must create the 'blueprint' that ensures consistency in how IT services are modeled. This includes the following steps:

1. List the configuration item (CI) types that need to be in the data model.
2. Make sure that the service components are represented with appropriate common data model (CDM) classes.
3. Develop naming conventions for model components.
4. Decide the hierarchical structure of component relationships.
5. Decide the entry points through which users and stakeholders will enter the model.
   Business and technical entry points are needed. For example, service, organization, geographic, technology, and so on.

Decide the level of detail that the model should capture

The level of detail you want to capture depends on the focus of the model. Discovery tools provide a high level of technical details while you need a very low level of detail of IT components for business-focused models. More effort is required for maintenance of the model if it is very detailed. Very low details could result in the model not properly representing the service. You must have enough detail to pinpoint the cause of an impact. You do not need to duplicate other tools functions.

Decompose the service

The purpose of decomposing a business service is to identify and document business processes, identify the IT services that support them, and identify IT CIs and assets that provide the IT services. For example, a hardware manufacturing organization might identify a business function as microprocessor procurement, a supporting IT service as procurement information storage, and the supporting IT assets as servers, databases, and related hardware and software systems. 

On a high level, a service model is a collection of components, also known as configuration items (CIs), that represents a business service. A business service can have one or more business processes. Each business process can contain several functional applications, each of which can have multiple IT CIs. A service model will contain the processes, show how the CIs are interconnected, and show how CI failures propagate and impact the upstream services. 

Approaches for decomposing the service

The following decomposition approaches exist:

Approaches for decomposing the business processes 

You can decompose a business process by analyzing the following business processes:

• Core competencies
  For example, plan and develop products or manage customer relations are core competencies based on which you can decompose business processes.
• Business functions
  For example, business functions include marketing and research and development, sales, front office, and customer support.
• Business processes
  For example, market research, product planning, response management, or order to cash. These processes may have sub processes.

Decomposing IT services

Decomposing IT services consists of the following steps:

• Map the lowest level of business process to services from the IT service catalog.
  Examples:
  • The Webstore service supports the 'orders' business process.
  • SAP AR supports the 'accounts receivable' business process.
• Identify the IT CIs that support IT services.
  For example, you can identify the following IT CIs:
  
  • Applications
  • Database
  • Servers

Identifying logical components 

You must identify the logical parts of the service and its consumers. To achieve this you may have to refer to business process documentation. You may also have to see application test and use cases along with interviewing people to identify some components.

For example, you can identify the following logical components:

• Business process
• User groups
• Locations
• Functional groups
• Sub-services

Identifying physical components

Physical components are mostly software and hardware configuration items. Discovery tools provide most of this data. You may also refer network or application architecture diagrams to facilitate this activity. 

Using network diagrams may result in incorrect models as the topology may not be the same as impact relationships.

Analyze component impacts

This activity involves finding out what happens when a component fails or has restricted functionality. 

You can use some of the following sources to analyse component impacts:

• Disaster recovery or Service continuity plans.

• Application architecture diagrams.

• Documented test or use cases.

• Incident and problem records from the service desk.

• Risk analysis on requests for change.

You can use the following analysis techniques to analyse component impacts:

• Component failure impact analysis
• Fault tree analysis
• Ishikawa diagrams

Analyze Status Propagation

The following factors determine the status of a CI:

• Event severities are mapped to component status values.
• Status Propagation rules set the status of dependent components

You must take the following step to analyse status propagation:

• Review the event source for each component.
• Find whether the component status is set appropriately for each event.
• Find whether the status propagation reflect the real state of the service.

Verify monitoring of components

You must make sure of the following best practices regarding monitoring components:

• Correct metrics for a component are monitored and verify this with subject matter experts for that component. 
• Simplify the model and exclude components that are not monitored. 
• Define alias formulae for associating events to components.
• Not all events should affect the component status.

Create the service model

The following steps facilitate the process of creating the  service model:

1.  Identify business services.
   Sources of information include business unit managers, business process managers, and staff personnel knowledgeable about the business services. Company organization charts might be helpful in identifying the relevant people.
   The process involves interviewing the managers and identifying the following information:
   • Business processes – Identify key business processes such as market research,product planning, response management, or case management. There can be multiple levels of business processes, starting with higher-level core competencies and business functions to specific sub-business processes.
   • Functional applications – Identify the business applications that support the business processes. Map the business processes to the functional apps.
     Map the functional applications to IT service CIs to create business service models.
2.  Identify IT services.
   Sources of information include IT managers and staff. Disaster recovery plans, help desk documents, and purchase orders might be useful in identifying IT CIs and the business processes that they support.
   The process involves identifying the list of IT assets (components). Interview the IT management and staff, or utilize an asset/configuration management database as resources:
   • Create a list of IT services (service catalog); discover what IT services are offered to business units through use of IT assets. Examples of IT services include customer support and customer call monitoring.
   • For each IT service, identify the IT assets that support the service. Discovery solutions such as BMC Discovery help with automated identification of IT assets and offer continuous and regular updates to ensure that the service model components accurately reflect real IT environment. 
   • Identify the interdependencies among the IT CIs and formulate a topology map. Consider the relationships and dependencies between IT CIs.
3. Build a business service model, and link the business processes to the IT services that you have identified.
4. Simulate failures of components and verify model correctly updates service status.

Review the service model with stakeholders

You can review the service model by performing the following activities:

• Walk through the model with the stakeholders 
• Use impact scenarios to verify requirements are met.
• Identify refinements to the model.

Deploy the service model

You must put the service model into operation.

Related topics

BMC Communities: Best Practices in Service Model Design and Optimization