Service model design considerations

Building a service model can be a daunting task. When you begin the process, it might be helpful to select one critical business process or service, decompose it to identify all aspects of the service, and build a complete service model for that part of your enterprise.

Understanding how the various components of one business service interact helps you construct other pieces of your service model, and helps you understand how services themselves affect each other. For example, you might discover that your payroll service depends on a technical service that provides access to information through the corporate intranet.

The following figure shows an example of a service model with business users, services, and IT structure layers. The lines between the component instances represent impact relationships.

 Example of a service model 

Consider the following factors in determining how to design a service model:

• The diversity of IT resources and how they are monitored
• The location of resources and how the management responsibilities for them are distributed within and among IT groups
• The relative importance of various resources in the delivery of business services
• The need for Change Management
• The maintainability of the service model over time

The service modeling process involves:

• Defining business goals
• Decomposing a business service
• Defining the service model

Best practices for designing a service model

When designing a service model, consider the following recommendations:

• Agree on a model blueprint that applies to all service models. The model blueprint acts as a template to the construction of the different service models, and should define a hierarchical organization and the types of configuration items (CIs) that relate to each other. The blueprint should allow some flexibility.
• Define terms and concepts beforehand. To your organization, what is a business process or an IT component? What are your severity and priority levels and what is the meaning of each? You don't necessarily have to use the ITIL definitions for all these things, but you should have definitions that can guide you and help settle disputes while you design service models.

Business goal definitions for the service model

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

To do so, the IT group must engage the business managers in defining short-term, mid-term, and long-term goals 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 are:

• Business continuity and service availability — This type of implementation is driven from the top and makes sure that IT is delivering their services as agreed. It consists of a business-centric model in which business processes, services, and service level agreements (SLAs) rely on a small number of vital IT components that measure the pulse of the underlying environment.
• 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 components, such as systems and applications, and the logical components, such as services, and other business objects.
• Operational efficiency — This type of implementation is run by and for the IT 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 components. Services are logical groupings that provide a convenient way of classifying the technical resources. For example, you might use an email service to classify all of the servers and software required to enable people to send and receive email.

Determining cell topology for the service model

There are three basic approaches to cell topology, which are as follows:

• Centralized
• Domain-based
• Layered

The centralized (default implementation) approach is to implement the service model on one cell, with all the service management objects created and maintained in that cell. Then, use distributed cells to collect and process the raw events of interest before they enter the model. 

The domain-based approach separates the service model into two or more parts that correspond to clearly established entities or domains in the organization. Each part is run on a different cell, and users connect to the cells on which the CIs that they manage reside. Lines of business and independently operated sites are good candidates for this approach. With this approach, you can represent some resources in more than one cell, provided that the event flow is directed or propagated correctly. 

The layered approach separates the service model into two or more stratified management layers, such as IT CIs and logical CIs. Each layer is contained in a different cell, or possibly distributed among several cells if geography is a factor.

Component property updates

The cell updates the status of a CI as new events are received or when an impact from other CIs occurs. 

However, other CI properties that can change over time are not maintained by the cell. You can update these properties automatically only if the new values arrive in an event or are added in a data table. You must create a few simple rules to implement this mechanism.

Related topics

Planning a service model

Identification and documentation of business processes