Introduction

Service Modeling Best Practices

BMC Software1/20/2015

Service Modeling Best Practices

White PaperSeptember 2005

Table of contents31Document owner & history

32Acknowledgements

33References

44Introduction

45Disclaimers

56Concepts review

77Benefits of Service Impact Management

98Process overview

109Before you begin

109.1Different focuses

109.2Bringing business value

119.3Bringing operational benefits

119.4Bringing business and operational value

1410Preparing for the design

1410.1Scope and terminology

1610.2Agreeing on a model blueprint

1910.3Class and name conventions

2211Service decomposition and modeling

2211.1Sources of information

2511.2Selecting a first service

2611.3Entry points to the model

2811.4Decomposition

2911.5Service impact

3111.6The main shapers of the service model

4112Use cases

4112.1Modeling a stand-alone application server

4112.2Modeling a database-based application server

4212.3Modeling a central application used in different places

4312.4Taking into account end-to-end monitoring and SLA/Os

4513Annex A: sample interview form.

1 Document owner & historyDateNameOrganisationPhoneEmail

September 28, 2005Philippe PlomteuxBMC Software(+32) 2 712 57 80philippe_plomteux@bmc.com

DateVersionDescriptionEditor

Septermber 28, 2005V 1.0initial releaseN/A

2 Acknowledgements

Many people contributed directly to the contents of this white paper. Among others : Zohreh Hosseini, Olivier Pignault, Michael George, Dave Schofield, Jean-Marc Molina, Jan Merivirta, Markus Dillmann, Karl-Anders Falk, Chris Warwicker, Charlie Tan and Henrik Erikssonn have provided many of the ideas included in this document.

3 References

The ITIL Service Delivery and ITIL Service Support guides are regularly referenced in the document. Particular pointers are provided when needed. Wherever possible, ITIL standards have been applied.

The Common Data Model [CDM] used by the BMC Atrium CMDB is very important to get familiar with as it underlies many design considerations. A good starting point for its description is the BMC CMDB Common Data Model white paper.

The BMC Service Impact Manager product documentation includes valuable information on the principles of service modeling and service impact management, in particular chapters 3 to 7 of the BMC Impact Manager Service Model Development, Maintenance, and Administration Guide.

Finally, it is worth looking at the BMC Discovery suite product documentation to gain knowledge on what type of information is discovered by the Discovery suite and how this information is instantiated.

4 Introduction

While BSM is about a lot more than service and service impact management, the design of service models epitomizes the value BSM brings to any organization: it finally allows business users, service line managers, the service desk and the IT operations to have a common understanding of the relationships between the technology (ICT) layers and the services these deliver. Therefore, service model design is more than often a highly-visible, highly-impacting activity that is meant to provide a lot of value in many BSM projects. In other words, wed better do it right.

However, even though the general concepts are relatively straightforward and the purpose quite clear for everyone, the whole discipline is still relatively new and clear guidelines do not abound in the area.This white paper proposes a pragmatic, generic and repeatable approach to service model design. There are virtually no mention of the underlying technology and products needed to actually implement the service model, only guidelines on how to do it right. There are not (yet?) rules carved in marble in terms of what is right or wrong in the area, but the objective of the document is to raise the good questions and identify the main traps to avoid when doing the exercise of building service models.

5 Disclaimers

The topics covered in this document are pretty much product-agnostic and this white paper is not a how-to document addressing implementation considerations.

Only when necessary will references to BMC Service Impact Manager and the BMC Atrium CMDB be made.

Service modeling is a vast discipline in itself. In the context of the present document, the design considerations are geared towards building service impact models.Relationships between service impact management and other processes such as incident, problem, change and asset management will not be addressed directly, even though service impact management has numerous interfaces with these processes.Finally, examples and scenarios will in general be taken from the distributed world. The specifics of mainframe environments are not covered here, but all the described principles should apply indifferently to any technology.6 Concepts reviewService impact management (SIM) consists of the identification, definition, and management of critical services, their supporting IT resources, and the relationships between these entities. SIM has the ultimate goal of identifying and analyzing the impact of IT problems on the critical business processes to ensure continued delivery of these.SIM depends on the development and maintenance of the service model. The service model is a representation of the IT assets (physical and logical components) that operate together to deliver services and of the critical relationships and dependencies between the components. It provides a dynamic, business-oriented view of business services. The service model is used by IT operations staff and business managers to manage IT and service information from an easily interpreted, graphical view quickly discover the underlying IT assets that are causing business service slowdowns or outages. define and manage the critical relationships between IT assets and business processes. quickly determine the impact that an IT problem has on various business processes and user groups. integrate real-time IT and service information with the help desk for improved end-user responsiveness and value.A service model is essentially made up of two broad types of objects: Components, or Configuration Items (CI), represent the various logical and physical assets. Relationships relate the CI together. A relationship describes the impact that a CI called provider has on another one named consumer. Relationships therefore have a direction (from provider to consumer) that makes straightforward the construction of hierarchical models.

From an implementation perspective, other data will be needed to make the actual service model work, but this is beyond the scope of this paper.A Service Impact Management solution should help answering the following questions: What is the impact of a technical failure on the business? What is impacted? Who is impacted? What is the priority of a problem compared to others? When is the problem going to be fixed? Who is responsible?The relative importance of these questions within an organization will give a shape and focus to the service models, and will also help determine the model entry points, as will be covered in sections 9.1 and 11.3.

Other concepts and terminology will be introduced or reviewed in other parts of the document, such as paragraph 10.1.1.7 Benefits of Service Impact ManagementThere are numerous benefits in modeling services and using these models as the base for service impact management. Among others:Focus on end-users and business functions/processes

The availability and performance of a service could only be measured from the end user point of view. Availability of all servers is not a guarantee or indication of service availability. The Service Impact Management approach focuses on the monitoring requirements of business processes within a company and meeting end-users expectations.

Facilitate Configuration and Change Management Processes

Configuration Management is the process of identifying, controlling, maintaining and verifying the versions of the Configuration Items (CI) and the relationships that link them together. Change Management is the process of controlling changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved changes with minimum disruption. From these definitions, it is easy to see how the Service Impact Management process would help the achievement of these other processes.

Reduce Cost of Managing Services

According to ITIL, managers need to ensure that there is a proper balance between the quality of service on one side and expenditure on the other. Any investment that increases the costs of providing IT services should always result in enhancement to service quality or quantity. The process of identifying services and their relationships to business processes is the first step to become more efficient in the usage of resources and quality of service provided by IT.

Identify Gaps in Monitoring

Through Service Impact Management and by building a list of all assets that support the services, the monitoring gaps would be identified. The relationships that exist among all components and the business processes they support are a guiding light to evaluation of monitoring requirements.

Increase Value of IT to Business

By gearing the IT management of services toward the needs and wants of the end-users and support of business processes, IT managers would be able to show the value that IT brings to the business. That also helps to improve relationships with satisfied customers through improvement of services provided. A model of business services supports decision making on IT investments, and priorities are better managed because IT investments are now more easily related to the business value of the services they support.Service Level Management & SLA

For the purpose of creating a Service Level Agreement (SLA), IT is required to identify companys business functions and processes and the services it provides to support them. Service Impact Management effort provides IT with means to evaluate its own capabilities and the level of service it could offer to its customers. Service Desk Management (End-user communication)

Service Impact Management considers proactive capabilities that IT Service Desk can gain by having knowledge of interdependencies of business functions and processes with IT Services and their components. As an example, in case of server or application breakdowns, from information within a Service Model, Service Desk could find who is affected by the service degradation and provide that information to end users through web, phone messages or e-mail and reduce number of calls to the Service Desk.

Business Continuity Management / Business Impact Analysis

A key driver in determining IT Service Continuity Management requirements is how much the organization stands to lose as a result of a disaster or other service disruption and the speed of escalation of these losses. The purpose of a Business Impact Analysis is to assess this through identifying critical business processes and the potential damage or loss that may be caused to the organization as a result of a disruption to critical business processes. Due to its nature, a Service Management effort to identify services and their interdependencies (i.e. in the form of a Service Model) would help the organization in these Business Continuity Management and Business Impact Analysis efforts.

Availability Management / Component Failure Impact Analysis

From the ITIL definition of Availability Management: The goal of the Availability Management process is to optimize the capability of the IT Infrastructure, services and supporting organization to deliver a cost effective and sustained level of Availability that enables the business to satisfy its business objectives.

This is achieved by determining the Availability requirements of the business and matching these to the capability of the IT Infrastructure and supporting organization... Availability Management should ensure the required level of Availability is provided. The measurement and monitoring of IT Availability is a key activity to ensure Availability levels are being met consistently. Availability Management should look continuously to optimize the Availability of the IT Infrastructure, services and supporting organization, in order to provide cost effective Availability improvements that can deliver evidenced business and User benefits.

The capability of the Availability Management process is positively influenced by the range and quality of methods and techniques that are available for deployment and execution within the process.

8 Process overview

The remainder of the document will detail the different steps of the service modeling process. This section outlines the main phases, which will be covered in detail in the rest of the document.Before you begin

This is part 9 of the present document. Identify the primary focus (operational benefits and/or business value) of the service models. The shape of the model will be influenced by the chosen focus. This is discussed in section 9.1. Identify the main stakeholders and users of the service model/service impact management solution. Both focus and stakeholders will determine the entry points to the service model [section 9.4].Preparing for the designThis is part 10 of the present document. Nail down terminology and concepts before they are used. Refer to ITIL for terms and definitions [section 10.1] Agree on a model blueprint that will apply to all service models. The model blueprint acts as a template to the construction of the different service models [section 10.2]. Adopt class and naming conventions [section 10.3].Service decomposition and modeling

This is part 11 of the present document. Inventory and use all sources of information available [section 11.1] Prioritize the different to-be-modeled services. Priority will mainly depend on impact and urgency of the failed service/process [section 11.2]. Identify the entry points to the service model(s). These determine the top-level objects within the model [section 11.3]. Proceed to business process walkthrough and start decomposition, keeping in mind granularity, hierarchy and modularity benefits in the construction of the model [sections 11.4 through 11.6].9 Before you begin9.1 Different focusesThe first factors that will ultimately scope and shape the future service models are to be found in the overall objectives and added value that the organization wants to achieve when these service models are designed and implemented.Typically overall objectives could be filtered out of a Business Plan, a Balanced Scorecard, the existing Corporate/IT Governance characteristics and structures and/or an IT strategy plan.

The service model provides vital information in continuously aligning IS with the business to achieve the overall business goals in an organization. The most important step involved in organizing a service model is balancing the weight of IT resource availability against the weight of business needs from the service impact solution.To do this, the IT or IS group must engage the business managers to define short term, mid-term, and long-term goals for service impact management in the enterprise. These goals should determine the design and development of all deliverables for all other service model development phases.

Business value and operational benefits of the project are the obvious targeted goals, but their relative importance can differ from one organization to the other.9.2 Bringing business value

Bringing Business value in the context of Service Impact Management is about: better end-user productivity

minimizing the business and financial impact of service disruptions

knowing when technical problems impacting the business/service will have a resolution

better communication between the IT and the business, with pro-active notifications from the IT in case of service disruptions.Customers primarily looking for business value will usually have Line-Of-Business (LOB) Managers as the principal stakeholders and sponsors of such projects.

The primary users of service model and service impact information will be business users and LOB managers.

In this situation service models are likely to be more business-focused, in the sense that particular attention and detail will be paid to the definition of the business layers, i.e. business function and process decomposition.9.3 Bringing operational benefits

Increasing operational benefits in the context of Service Impact Management is about: understanding the interrelationships between the ICT layers and the services they provide

prioritizing top issues and assigning the right resources to these issues. proactively informing users of service impacts integrating service impacts in all IT management processes, such as incident, problem, change and asset management. providing vital information to ensure availability and recovery design criteria.

IT operations and service desk will be the principal stakeholders and sponsors when the primary objective is to increase the IT operational efficiency of the organization.

In that case, the service models will usually include a fine-grained decomposition of the ICT layers, with a strong focus on the different IT elements and their dependencies.

9.4 Bringing business and operational value

Obviously, most organizations will try and maximize both values increasing at the same moment both operational and business efficiency through the exercise. It is in conclusion worth raising the following questions before going further: Who are the sponsors and stakeholders? Are roles and responsibilities identified?

Who will use the service model/service impact information?

What will the model be used for?Figure 1 below may help identifying the different needs and focuses of the potential stakeholders. On the vertical axis the main levels of focus are presented (for a definition of the terms Business Domain, etc, please refer to paragraph 10.1.1), while on the horizontal axis we find the main possible user groups of the Service Impact Management solution. A square ticked in green circle is a clear entry-point, while a simple tick shows a potential match.

.

Business usersCustomersService ManagersService DeskIT OperationsIT Support

Business Domain

Business Function

Business Process

IT Service

IT component

Figure 1According to the final balance achieved between business and IT focus, the service models fall into 3 broad categories, as illustrated in the figure 2 below. The first diagram on the left side illustrates a IT-focused model, where the ICT layer predominate, while the diagram on the right presents a model where the focus is on business. Finally, the central diagram shows a model where business and ICT resources are balanced.

Figure 2Note that there is no preferred type of model among these three broad categories. The objectives, audience and constraints of the organization will ultimately dictate which option or mix of options to follow.

Best practices

Identify the primary focus of the organization in doing service impact management Identify the main users of the service impact management solution

Determine the different entry-points [see section 11.3] for the service model

Define your model blueprint [see section 11.2] according to this focus

10 Preparing for the designThis section describes some important preparatory work to go through before any of the model design starts.

First, we need to nail down terminology and concepts, so that all stakeholders are sure to speak the same language.

Second, the organization should agree on a model blueprint, which will act as a blueprint for the service models and will ensure consistency and repeatability of the process.Finally, name and class conventions should be considered.10.1 Scope and terminologyThe considerations from the previous section on the focus of the service model (see figure 2) should already help outline the scope and focus of the service model.

Another capital, pre-required step before moving on is to nail down the definitions of the main concepts and terms used throughout the exercise. The list below may help clarifying over-used terms. While most of the following explanations are accepted and used industry-wide, the important point to take home is not so much these definitions than the fact that definitions must exist.10.1.1 General definitionsThe following list, mostly taken from the ITIL library, can help the organization agree on the main concepts and terms.

Business DomainThis is an entire business area where the organization is active. It is also known as its core competencies and represents the highest level of business process decomposition, e.g. Plan and Develop Products and or Services to do X.Business Function

This is a group of business processes that constitute a specific function such as customer support or sales. This represents the second level of business process decomposition. Business Process

Business Process is a group of business activities undertaken in pursuit of a common goal. A Business Process may have dependencies on several Business Functions and also other Business Processes.

This represents the third level of business process decomposition.Service

The ITIL definition for Service is one or more IT systems that support or enable a business process. In other words, Service could be defined as all IT resources required for the functionality of a business process. The service can be composed of multiple applications, databases and infrastructure components.

A Service is the end-to-end technology infrastructure that enables one or many business processes to be performed.Typically an IT Service will have a Service Level Agreement (SLA) to specify its agreed serviceability.

IT System

IT System is a group of software/hardware components to provide specific functionality in support of one or more Business Processes and included as parts of IT Services. They are the logical building blocks of an IT Service.Typically an IT System will have an internal (to IT) Operating Level Agreement (OLA) to specify its serviceability.

IT Component

A component is a physical or logical asset required to support one or more Systems, e.g. an Application, a Server, a Database, a Network Router. Components can be contained within other Components to the required depth to cater for asset management needs, e.g. a Server contains a Disk Caddy which contains a removable Disk.

10.1.2 Defining IT Components

Physical components themselves must also have a clear definition. It is quite often assumed that the concept of application, system or network (to name just a few) is understood and clear, while it has a very different meaning from one organization to the other.

An application, for example, can be seen as an entity including many different components, or simply a process running on a single computer system.

The way to follow remains similar: all IT components must be clearly defined to avoid confusions in the model construction.Tip: A good starting point for the definition of the different types of components is the CMDB Common Data Model reference (in HTML format) which ships as part of the document of the BMC Impact solutions.10.1.3 Defining other concepts

Any other frequently referenced concept must also have a clear definition. In particular, and looking towards the implementation, severity levels should have a clear definition. A good starting base would be the severity level index reproduced below, which would describe the different severities that the state of an IT or Business process can have.Severity Level IndexSeverity LevelsDefinitions

UNAVAILABLEPermanently Disabling

IMPACTEDCritical End User Dissatisfaction

MINORCauses Degradation of Service

WARNINGCauses Inconvenience/Annoyance to End User

INFO/OKNot Noticeable by End User

Best practices on terminology Use ITIL definitions whenever applicable. Define all concepts and clearly communicate on them.

Come back to these definitions in case of conflict or debate. Enrich these definitions to avoid any ambiguity.

Align the definitions of IT components with the definitions of the BMC Common Data Model. Define a severity level index.

10.2 Agreeing on a model blueprintBased on the agreed focus and terminology, entry points and scope, a general structure, or model blueprint, of the future service models should be derived. For consistency, repeatability and clarity purposes, the designed models should share a common layout.

Agreeing and complying with a pre-defined model blueprint will greatly help in that area, at the same time simplifying and speeding up the process by making it highly-reusable.A model blueprint applied in the service impact management context will typically impose: a strict hierarchical organization of the CI in the model (see also paragraph 11.6.2 on that topic). that CI of a same type or class should be grouped (as much as possible) at the same level within the model. that certain types of CI cannot be related to others, and that a model includes a fixed, well-defined number of ordered layers.

the allowed CI types that can be defined at the different levels of the service model.The following diagram presents on the left side a model blueprint that organizes the different type of objects as defined in paragraph 10.1.1.On the right side, what could be corresponding CI instances in the example of a home banking environment.

Figure 3Depending on the focus and the level of detail required [or not], the organization may choose to use a model blueprint that does not necessarily cover all layers upfront (even though the blueprint and the models could be enriched as the solution grows), but rather introduces other types of objects to meet specific viewing requirements [see business/technical views in paragraph 11.3.3]. The following illustration shows an example model blueprint where user communities as well as sites and SLA are also represented in dashed boxes. The text in the boxes shows the name of the CDM classes that should be used for instantiation [see class conventions in paragraph 10.3.1].

Figure 4

Best practices on the model blueprint The model blueprint should have the following characteristics :

it imposes a strict hierarchical organization of the CI relationships

it defines that CI of a same type (class) should be as much as possible be at the same level.

it defines the layout of the different levels of the service model. it defines the possible CI types [classes] that can be defined at the different levels of the service model. Use the design of a first service model to refine and validate the model blueprint. Make sure that the blueprint allows the different stakeholders to access the model according to their own standpoint [in figure 4, the model can be accessed from a Business Process/User Community, a geographical an SLA standpoint] Use subsequent designs of service models to validate the universality of the model blueprint. This possibly will lead to amendments to the initial model blueprint. Allow for some flexibility in the model blueprint, not all models may exactly fit a model blueprint which imposes a fixed number of layers. For the modeling of an IT service, between 4 and 6 layers of CI are generally sufficient. The IT layers (IT System/IT components) may be automatically instantiated using e.g. BMC Discovery suit. Make sure that the model blueprint an d class conventions [paragraph 10.3.1] comply with the integrity constraints introduced by the Discovery suite.

10.3 Class and name conventions

Although these considerations mostly apply to the implementation phase, it is worth thinking of a consistent way of classifying the different components of the model and of naming these same components. 10.3.1 Class conventionsThe BMC Atrium CMDB relies on a Common Data Model (CDM) which defines a certain number of component (asset) classes available to classify the CI instances. The CDM is itself based on the industry-standard CIM model, which has been produced by the Desktop Management Task Force (http://www.dmtf.org).Familiarity with the available classes and associated attributes on one side and with the adopted terminology on the other side will greatly help setting up a mapping table where the different CI to instantiate have a corresponding CDM class.

An important note towards implementation: Many of the classes of the CDM can be instantiated using the BMC Discovery solutions. As the discovery solutions introduce constraints on the classes of objects that can be linked together, it is not recommended to manually instantiate these classes. Check the BMC Atrium CMDB and Discovery Solutions product documentation to verify which CDM classes can be automatically instantiated.ExamplesThe following table gives examples of possible mappings between the adopted terminology and the classes available in the CDM.

Type of componentCDM classIcon

Business ProcessBMC_BusinessProcess

ServiceBMC_Service

IT SystemBMC_Group

application serverBMC_ApplicationServer

physical serverBMC_ComputerSystem

other infrastructure components(various)(various)

While the product allows for bespoke extensions of the CDM, they should in any case be kept to a strict minimum to avoid maintenance issues during product migrations or upgrades.

Best practices on class conventions

Identify the different CI types that the model will contain and make sure there is a corresponding CDM class associated to each CI type.

Even if they are irrelevant to a given environment, do not delete classes and attributes defined in the CDM. Leverage on previously defined terminology and concepts. For CI that will be manually created (typically, the logical objects of the model), use classes that are not instantiated by the Discovery solutions. Double-check that a class/attribute does not exist yet before deciding to create it in the CDM. Keep changes to the CMDB data model to the minimum.

10.3.2 Naming conventionsIn a similar fashion, a naming convention should be defined for the names and aliases of the created CI. All CI types should have a well-defined naming convention attached. Typical examples are:1. A CI of class BMC_ComputerSystem has a name made out of the lowercased fully qualified domain name of the system

2. A CI of class Service has a name made out of the svc_ prefix, followed by the CamelCase notation of the service name as defined in the service catalog.Some good questions to ask in that area are: What existing naming convention, e.g. coming from an existing asset management application, is in place and how can it be used/extended in the context of Service Impact Management.

What is the name structure for a given CI type? For example, the name could be built on the template :

/ /

Should the name reflect the type of the CI? (This may look as redundant information but may help for sorts, lists, searches, etc.) Should manually created (as opposed to automatically discovered) CI wear a specific prefix/suffix indicating their manual origin? What is the separator between words? It is supported but not recommended to use space characters in names. Is there a convention on casing (lower case, upper case, CamelCase, etc)?

Best practices on naming conventions

Have one. Assess existing naming conventions and try to use them. Use a naming convention that is consistent across all CI types.

Keep names humanly readable, that is their only purpose. Use aliases instead to hide the ugliness of event association.

11 Service decomposition and modelingWith the preparation work described in the previous section done, we can move on to a more detailed discovery and decomposition of the services down to the underlying infrastructure.The main points covered within this section include: assessing the different sources of information within the organization

considerations on how a first service is selected within the organization.

making sure that the entry points of the service model are identified. reviewing the main steps of service decomposition.11.1 Sources of informationOne of the main challenges of the service modeling process is certainly to gather, confirm and make the synthesis of disparate, and sometimes unstructured, sources of information within a given organization. This should be seen as another added value to the process. Translating information that is often within the heads of a few people into structured service models highly contributes to the consistency and durability of the knowledge and its diffusion across the enterprise.

11.1.1 Interviews

The data on business processes and IT Services are collected by interviewing the proper resources.Depending on the service identified for monitoring and management, the list of people to interview might differ. As an example, if the monitored service is email and the application used is MS Exchange, then anyone who is responsible for any components within the MS Exchange environment would be a candidate for interview. The purpose of interviews would be to identify critical services within the environment and based on that to identify the service components and their functionalities, availability and performance parameters, failure points, cause and effects of failures, prevention and detection options.Annex A at the end of the document contains a simple list of typical questions to ask when it comes to identifying and gathering information on business or IT services.11.1.2 DocumentsThe Service catalog should be the authoritative document where the different services are defined and related to others in the organization. Service Level Agreements are other reliable sources of information as to find the list of IT Services and their components.

A SLA is a written agreement between an IT Service provider and the IT customers defining the key service targets and responsibilities of both parties.

Operational Level Agreements (OLA) are internal agreements covering the delivery of services which supports the IS organization in their delivery of services. OLA should set out specific back-to-back targets for support groups that underpin the targets included in SLA. For example, if the SLA includes overall time to respond and fix targets for Incidents (varying on the priority levels), then the OLA should include targets for each of the elements in the support chain (target for the Service Desk to answer calls, escalate etc, targets for Network Support to start to investigate and to resolve network related errors assigned to them). OLA therefore describe the required availability of an IT Service or component to perform its required function. Business process models usually come under the form of diagrams and show the decomposition of a business process into different steps, complete with their interdependencies and branch statements, if any. Business process models convey invaluable information when it comes to building service models.Figure 5 gives an example of a typical way business processes can be represented. This particular Business Process describes the different steps for a Customer Sales Representative (CSR) to handle customer requests over the phone in a retail organization.

Figure 5Application topology diagrams are a quite usual source of information when it comes to analyzing the ICT layers of the model. A topology diagram will usually show the interconnection of the main IT components (servers, applications, databases, etc) of the important enterprise applications. Figure 8 gives an example of a (very simple) application topology diagram.Organizational Charts are very important in the sense of identifying the right contacts and sources of information. The approach should be to initially contact top managers to receive buy-in and enforcement needed to get time with key personnel. The chart also represents the organizational structure of the company that is helpful for identifying Business Functions within the company.

Disaster Recovery Plans are also important source of information when trying to identify the service components within IT environment. A disaster recovery plan should include a list of IT assets, owners, and locations at a minimum and maybe user groups or dependencies and relations to business processes. These data could be transferred over to an asset management tool or database and used for the Service Modeling.

Help Desk / Support Databases & Documents could be used as sources of information on IT assets. By reviewing these records, the more critical areas could also be identified through number of high severity cases opened. The relation between IT Components and Business Processes could also be identified within support calls by correlation and filtration of events or cause and effect analyses.

Purchase Orders are basically a list of all IT assets purchased by the company and the purpose of the purchase might also be included in these records as in what service they were intended for. This would be last resort if data were not available through other sources.

11.1.3 Other sources of information

An existing asset management application or CMDB will obviously be a good starting base, not only in terms of data population, but also to help to determine naming conventions and such.11.2 Selecting a first service

At the start of a service modeling engagement, or during a Proof-of-Concept, it is important to carefully choose which service or business process will be modeled.There are two main aspects to consider what the most critical processes in the organization are: their respective impact and urgency. First of all, the nature of the process will usually give it an inherent impact:

ImpactUsually, the processes directly related to cash-flow generation (customer-oriented processes) are considered as the most important, as their unavailability has a direct, immediate impact on company revenues and image.Processes related to the generation of tomorrows cash flow, such as development, marketing, R&D and the like will come in second place, followed by all other internal processes of people, technology and planning management.

UrgencyOther factors come into play to determine the priority of a given service or process. To name a few, the internal and external visibility (e.g. a highly visible customer service), the competitive position and political awareness of the service, identified pain-points in the current delivery of the service, operational needs and funding possibility will have an impact on the final priority ranking of the different services.The following figure gives an example of how impact and urgency can be combined to determine service priority.

Figure 6Other factors

Other factors such as the complexity of the service (starting with a simple service will ensure a smoother learning curve), the completeness of ITSM capabilities for this service (e.g., is it well monitored from an ICT availability perspective) should ideally be taken into account at this stage.A careful weighting of these different aspects combined with the overall Corporate/IT Governance information and IT strategy plan should be a solid basis for a discussion with the key stakeholders to finally identify which services to pick up.11.3 Entry points to the modelAn entry point of a service model is a point selected to start the service decomposition. Identifying the entry point(s) of the future model is a pre-requisite to the decomposition exercise.Different factors once again will affect the decision.

11.3.1 Business versus Technical focus

The focus of service impact management within the organization as discussed in part 9 of the document will usually dictate the level of entry of the service model.

If the primary focus is on the business, the entry points will most likely be the different business processes and the different user communities or customers who actually use these business processes. The need to take into account Service Level Agreements may also dictate that models be constructed from the point-of-view of these SLA: In many cases there will be a need to combine both business and technical views. A service may for example not be impacted by a technical failure because this failure occurs outside service hours, but there will still be a need to visualize the technical failure so that it can be detected and fixed before the service is expected to be available again.In the case of a more technical focus, IT services, applications and geographical entry points will commonly be elected.

11.3.2 Target audience

The different user groups of the final solution will also influence the different entry points to select when constructing the model. EG, Service support staff will have different needs from operations and business users.

It is important to remember that the underlying technology (BMC SIM and the BMC Atrium CMDB) will allow for a mix-and-match of these different entry points according to the exact needs of the organization. There is no exclusive choice to make in that respect.

Also, do not forget to align the selection of entry-points to the model blueprint discussed in section 10.2.

Refer to figure 1 in section 9.4 for more details on the correspondence between target audience and entry points. 11.3.3 Deriving business and technical views

In many cases, especially if the target audience is diverse and includes stakeholders from the business and technical sides, the organization will desire different viewpoints on the same set of components: LOB managers and business users will want a view on the business processes, while IT operations will want a view organized around sites [datacenters, etc] or IT services [network services, middleware services, etc].

The model blueprint should allow for different grouping of the CI [and therefore visualization], as in the example of figure 4 where the whole model blueprint has been reproduced in the box at the top.

Box 1 presents a typical business entry point. The entry point is the Business Process level, drilling down towards the technology layers.

Box 2 presents the geographical standpoint: the entry point is the region, drilling down towards the sites and the different services that are available there.

Box 3 presents the technological standpoint, where the different technology components are grouped according to their type [servers, databases, etc.]

Figure 711.4 Decomposition

Knowing which services to model and what the various entry points to the service model are, we can proceed to the service decomposition itself. This section covers the global methodology to adopt, while the following section on the shapers of the service model will give more detailed information on how to design the model itself.11.4.1 Business Process WalkthroughConsidering that business processes are identified as entry points of the model, the key objective of the business process walkthrough is to trace the sequence of activities necessary to the execution of the end-to-end process. With the help of the end-users or business owners, the different activities (process steps) of the process or service are identified and described.In a recursive fashion, each process step can be decomposed further in its dependencies towards IT services.

The top-down approach

It is essential that the iterations of the walkthrough follow a strict top-down approach, i.e. that we start at the top of the model, i.e. the identified entry points, and walk our way down to the ICT layers.

Proceeding so will ensure: that we work from the view point of the business

that all elements making up a business process or service are accurately covered

that the decomposition, especially down to the ICT layers, is truly cross-domain and not silo-oriented

that, having in mind the implementation phase, gaps in the monitoring solution can be identifiedStarting in the middleThe top-down should be favored in any case, however in more complex situations this task can be daunting and the overall learning curve quite steep, so a good compromise will consist in starting in the middle, i.e. start the decomposition and analysis at the application or IT service level, build their model, and only afterwards start modeling the services and processes that depend on these applications.This technique will usually yield quicker results and value (as the model of the applications and services can be done and used quicker), and help the organization to refine its service modeling process before moving on to more ambitious tasks.

Best practices on the business process decomposition adopt different view points (end user, service manager, service desk) to identify the visible and invisible parts of a business process

achieve understanding of the business process by following its real execution by the end users.

assess whether or not a given process step is IT or non-IT related. always adopt a top-down approach : from the business or IT services down to the ICT layers

start in the middle for complex cases

keep your decomposition steps and terminology aligned with the model blueprint use hierarchy, granularity and modularity to give shape to the model

11.5 Service impactAfter the services and business processes have been decomposed down to the technology layer, it is important to assess if, how and when the technical components actually impact the services or business processes.The purpose of this assessment is to determine (looking towards implementation) the intensity of the impact relationships, and whether status computation should include cluster or weighted logic. Input from Incident/Problem Management Database is usually very helpful to relate service impact to component impact. The ITIL documentation for Availability Management also contains very useful techniques that help identify the causes of service and business impact.For example : Component Failure Impact Analisys [CFIA]The purpose here is to predict and evaluate the impact of component failure on service availability.From the ITIL Service Delivery guide, Availability Management, paragraph 8.9.1 :

CFIA achieves this by providing and indicating:

the impact of component failure on the business operation and Users

component and people dependencies

component recovery timings

the need to identify and document recovery options

the need to identify and implement Risk reduction measures.

single points of failure that can impact IT Availability

The above can also provide the stimulus for input to IT Service Continuity Management to consider the balance between recovery options and risk reduction measures, i.e. where the potential business impact is high there is a need to concentrate on high Availability risk reduction measures, i.e. increased resilience or standby systems.

For more details, check the ITIL Service Delivery Guide.

Best practices on business impact analysis use a systematic approach such as CFIA or BIAT to relate component unavailability to service impact.

use the incident/problem management database as a source of information

familiarize with the status computation capabilities of BMC Service Impact Manager

continuously refine and improve the service impact model. It is likely that not all possible impacts are taken into account in the first version of the service impact model.

11.6 The main shapers of the service model

In this section many important considerations that ultimately give shape to the service model will be covered. Once again there are no absolute answers or guidelines that can fit all contexts and all organizations. However we hope to help raising the right questions and avoiding the main traps in the process.

11.6.1 Overview

Identifying the stakeholders and users of the solution will determine the main entry points and granularity of the service model. Technical users will want a model where the different ICT layers are presented and detailed, while business users will want a model where the different business processes and services are represented.

The previously defined model blueprint will dictate the instantiation of a strict hierarchical model, built following a top-down decomposition, where modularity brings several benefits.11.6.2 A hierarchical modelThe case is quite clear: there is no other way than thinking your model from a pure dependency standpoint, rather than from a topology one.

The confusion can especially arise in the technical layers of the model, where people are more inclined to think in a what is connected to what mode, rather than what depends on what. Many sources of information that are available when modeling the ICT layers, e.g. application architecture diagrams and the like, will show a pure topological layout, and a translation work must be done to switch to a hierarchical representation.

ExampleLet us consider the following nave example, where a online banking application, must be modeled to determine the availability of the functions the application proposes, e.g. money transfer over the internet see figure 8 below.

Figure 8A dumb translation of the above architecture diagram would yield a topology-based service model, where the different elements are chained exactly as in the architecture diagram, as in figure 9:

Figure 9While the impact of the failure of any of the technical CI on the Money Transfer Business Process CI would correctly be computed, the other impacts along the chain would be plain wrong: Does a failure on the database really impact the firewall? Er. No.

Rather, the availability of the application of the Money Transdfer is the addition of the respective availability of each technical component, so a hierarchical representation is therefore needed. Figure 10 shows a hierarchical representation of one business process sitting on top of the application infrastructure shown above. In this diagram the availability of the services and processes is the sum of the separate availability of each technical component. Note also that the model has been aligned to the blueprint example of figure 4, as presented in the blue boxes next to the model.

Figure 10A note on model simplificationSometimes the temptation to simplify the model arises, for would-be clarity and representation purposes. This is typically the case when many CI depend on a common other CI. For example, a given IT service could be decomposed into different IT systems, each of them depending on a basic IT system such as the naming service (DNS), as in figure 11 below, which presents the accurate impact dependencies : the unavailability of the DNS system impacts all other systems, and ultimately the depending service.

Figure 11A common temptation in such a case is to simplify the model by placing the DNS system as direct provider for the IT service, as in figure 12. Doing so reduces the number of relationships to create and maintain.

This approach is not recommended: the dependency model is not correct any more and will, once instantiated, give incorrect results when looking at the availability of the different systems.

Figure 12

Best practices for building a hierarchical model

Use topological diagrams with caution. Do not translate topological relationships literally. connected to does not mean depends on. Simulate how impacts propagate in the model you build. Ask yourself if a propagated impact makes sense by questioning the model: Is it really the case that if A is down, then B is also down? Do not simplify the model, especially if OLA/SLA are attached anywhere in the model

11.6.3 What granularity?By granularity, we mean the level of details which we want to reach when constructing a service model. A low granularity means that we do not go in deep details and that the CI used in the model could potentially be decomposed further. A high granularity means the opposite, i.e. CI can potentially represent very detailed objects.

The considerations of this section mostly apply to the technical layers of the model, but can nevertheless be considered as generic.

Discovery tools are especially good at finding fine-grained information on the different components making up, for example, a computer system. CMDB entries will be created for the motherboard, the network interfaces, the hard drives and so on.

This information is useful in the context of asset, change and configuration management, but is usually of little interest in the context of service modeling, so a balance must be achieved to make sure that the right level of details is obtained.Here are a few arguments in favor of a low granularity: The purpose of the service modeling exercise is usually to model IT services and business processes, not the detailed interactions of the underlying technical wiring. The hierarchical paradigm described above is likely to show its limits when it comes to representing low-level technical relationships.

When service models are finally instantiated using BMC SIM, other tools such as the PATROL console will be in place to allow for a deep drill-down in the technical layers. In many organizations, the majority of the SIM users will not need such a level of details. A lower granularity will mean a smaller number of CI and relationships to maintain. The maintenance of the service models will therefore be easier.On the other hand, a high granularity model has its advantages: First and foremost, it is often not a choice but an obligation to use detailed CI to address the complexity of the model and the fact that when it comes to instrument the model (i.e., associating monitoring events to the instantiated service model), a technical event can be attached to only one component of the model.

For example, imagine we need to model two databases DBOne and DBTwo. These two databases are hosted on the same computer named system1. In a first approach, we could imagine modeling these two databases without using a specific CI for system1. However, if system1 is unavailable, the two hosted databases are unavailable as well so the CI must be created and be set as a provider of the two databases, as in figure 13 below.

Figure 13 Root-cause drill-down will offer more fine-grained results if the CI are detailed. A Computer System CI identified as the root-cause of a given impact offers less detail than if we can narrow down on the specific component (disk, memory, etc) that is the originating root-cause. Another benefit of a reasonably fine-grained model is that, when instantiated in BMC SIM, it offers better ways to control how impacts propagate along the dependency chain, hence allowing us to avoid the red or green syndrome, where service impacts are of an all-or-nothing type.

Best practices on granularity Adopt a low granularity whenever possible. Increase the granularity of the model only when necessary

When modeling applications running on distributed systems, stop the decomposition at Computer System level, and do not represent its different components

Leverage on the flexibility of event association to avoid the creation of multiple components

11.6.4 Leveraging on modularity

One of the advantages of hierarchical service models is that parts thereof can be re-used as needed, in a modular fashion.

Models should be built so that each of its parts (the sub-models) is self-contained and can be re-used independently.For example, consider the model of an application Application 1, complete with all dependencies towards the ICT layers, as in the next figure.

Figure 14If Application1 is a provider for a first IT System (IT System 1 below), the model of Application 1 will be directly integrated to the model of this service, as in the following screenshot.

Figure 15Finally, if Application 1 is also the provider for another IT System (IT System 2), the same model can once again be re-used. The next figure illustrates this.

Figure 16Making sure models are self-containedThis however requires, even though we seem to be stating the obvious, that services 1 and 2 use the same application Application 1. But is it really the case in real life? In fact, cases where services 1 and 2 actually use different parts of A1, rely on different network elements and a slightly different infrastructure are the vast majority.

We must therefore be careful to make sure that the model of Application 1 is self-contained and has only dependencies towards its own components, and not to components whose usage vary according to the different services that depend on the application.The following example illustrates the importance of the modularity, but also of carefully choosing the entry points to the model. The model below is the representation of a service IT Service, with its dependencies towards database and application systems. This service is accessed from two remote sites A and B, and the network connectivity to these remote sites has been included in the service model of IT Service. If IT Service is the top-most layer in the model, this could be acceptable

Figure 17However if the decision is made to model the two remote sites A and B as well, the model of the service 1 is not good enough : From the picture below, we can see that a loss of the Network to B will yield an impact on both sites, which is incorrect.

Figure 18To make sure that Service 1 remains self-contained and can be re-used by a future site C, all network dependencies are externalized from the model of the service, to give the following model:

Figure 19Once again, it is really important to question the model and check if the construction makes sense from an impact propagation perspective : to come back to the above example, if a problem in application A1 has an impact on S1 but not on S2, then the model must be reviewed and the model of A1 be made more modular.

Solving the spaghetti syndromeAnother very useful application of service modularity will help us solve the spaghetti syndrome. This frequently encountered problem occurs when a list of consumer objects C1Cn depends on a same list of provider objects P1Pm.Without simplification, the model looks as follows:

Figure 20It is therefore a good idea to create (within the limits of the model blueprint) a container object which will be used to regroup all the different providers, hence simplifying the maintenance and increasing the clarity of the service model.

Figure 21

Best practices on modularity

always try to separate the elements common to a given service in a separate sub-tree

use container objects to simplify the model and minimize the number of relationships in the model. question your model and verify if impact propagation makes sense align your model with the model blueprint design your model to the last level of detail to avoid unpleasant surprises during the implementation

if there are more than valid alternative to build a given model, multiply the number of objects by 10 to check which alternative offers the best maintainability.

12 Use casesThe following section describes commonly encountered use cases. It is impossible to cover all scenarios, but these simple examples may help to familiarize with the concepts and way of thinking.12.1 Modeling a stand-alone application server

Application servers (mail, web, etc.) are nearly always part of a service model. It is always a good idea to separate the application layer from the system layer, as a same system may host multiple applications and as the application and the system may be monitored differently.

Therefore it is common to model as follows: A first CI of type BMC_ApplicationServer describes the application itself. Events related to that application will be attached there.

A second CI of type BMC_ComputerSystem describes the physical system on which the server is running. This second CI is set as a direct provider of the BMC_ApplicationServer CI.

Figure 2212.2 Modeling a database-based application server

In the case an application requires an application server and a database to run, a common way to build the service model for that application is as follows: A CI of type BMC_ApplicationServer describes the application itself. Events related to that application will be attached there.

A CI of type BMC_ComputerSystem describes the physical system on which the application is running. This second CI is set as a direct provider of the BMC_ApplicationServer CI.

A CI of type BMC_DataBase describes the database instance A CI of type BMC_DataBaseServer describes the database server.

A CI of type BMC_ComputerSystem describes the physical system hosting the database. It may be same CI as the first BMC_ComputerSystem described above if both application and database run on the same system.

(Optionally) a CI describing the Application to Database connectivity can be added, usually of class BMC_ApplicationConnectivity

Finally, a CI of type BMC_Application has as direct providers the application server, the database and the connectivity CI.

A sample model is illustrated below.

Figure 2312.3 Modeling a central application used in different places

When a same application running in a data center needs to be accessed from different sites and the availability of the application across different sites needs to be monitored, an obvious way to proceed is to build a model as follows: Create one CI for each remote site, e.g. of class BMC_PhysicalLocation. These CI will have as direct providers the following : one CI that represents the central application, using for example the ideas of the previous use cases

One BMC_ApplicationConnectivity CI for each remote-site connection.

The model then looks as follows:

Figure 2412.4 Taking into account end-to-end monitoring and SLA/OsIt is often the case that end-to-end monitoring tools (e.g. based on Patrol End-To-End Response Timer) are used in conjunction with element monitoring to check the availability of a given application or IT service.

Also, it is often required that SLAs or SLOs be represented within the service model.

End-to-end performance monitoring information can be added as a separate branch in the service model, adding to the classical service model built out of the separate elements.

SLA agreements are usually set as consumers of the service CIs.

The following picture gives a simple illustration of the case. On the left side, the traditional service model of a web-based service is created as the infrastructure model. On the right side of the model, the different end-to-end monitoring probes are the providers of the end-to-end monitoring branch. Above the service CI, two SLO CIs have been added to illustrate that an impact on the service may directly translate as an impact on the SLO(s).

The correspondence with the example model blueprint of figure 4 has been added for reference.

Figure 2513 Annex A: sample interview form.The question form below contains a short list of typical questions to ask when it comes to gathering information on a given service or application.1. What is your role in the organization?

2. What is your role regarding this business/IT service?

3. Describe the business/IT service architecture. What are the technical components supporting the business/IT service.

Inventory of hardware and software (OS version, Application version).

Logical architecture of business/IT service.

Physical architecture of business/IT service.

4. Describe the business/IT service from a customers perspective. Which are the different supported business processes? What is the criticality of the different business processes?

How is a degradation or outage of a process quantified?

How is the customer informed in case of degradation/outage?

Describe the relation IT services business processes.

5. Describe the IT organization in relation to business/IT service:

Which teams are involved

Describe the relations between the different teams

Roles & responsibilities of the different teams.

6. What group of people, functions, do you see as the recipients of information from the business/IT service monitoring solution? (Roles & responsibilities) Also describe what information the different groups should receive.

7. Do you know where a problem resides when a user failure has happened?

8. How is the perceived and actual availability from a customer perspective, taken from the last month?

9. Which issues with the current monitoring solution do you want to overcome for business/IT service?

10. Do you have Service Level Agreements (SLA) with your customers?

If not, do you have plans to close SLA with you customers in the near future?

What kind of SLA do you have with your customers? (some examples)

How are the SLA measured?

11. Do you have Service Level Objectives (SLO)?

If not, do you have plans to have SLO in the near future?

What kind of SLO do you have today? (some examples)

How are the SLO measured?

12. What is the goal of the business/IT service monitoring solution?

13. What are the success criteria of a good business/IT service monitoring solution?

14. How will you measure the success of the business/IT service-POC

15. What are your biggest concerns on the implementation of a new monitoring solution?

16. What are the success criteria for this project?

IT

Resources

IT Services

Business

Resources

IT Services

IT

Resources

Business

Resources

Business

Resources

IT Services

IT

Resources

See the ITIL Service Delivery Guide, chapter 8, Availability Management

See e.g. the ITIL Service Support guide, appendix C: glossary.

Check the BMC Discovery suite product documentation for more information.

Default icon in BMC Atrium CMDB 1.1

For more information on this, check the BMC Service Impact Manager product documentation

BMC SIM offers technical alternatives to this paradigm, but they are not recommended.

Page 17 of 46

1/20/2015

_1162647173.vsd