Service modeling white paper

7/29/2019 Service modeling white paper

1/46

SIM Best Practices

Service Model Design Guidelines

September 2005


2/46

Service Modeling Best Practices BMC Software3/30/2007

Page 2 of 46 3/30/2007

Table of contents

1 Document owner & history....................................................................................... 32 Acknowledgements..................................................................................................33 References...............................................................................................................34 Introduction .............................................................................................................. 45 Disclaimers .............................................................................................................. 46 Concepts review.......................................................................................................57 Benefits of Service Impact Management.................................................................. 78 Process overview..................................................................................................... 99 Before you begin .................................................................................................... 10

9.1 Different focuses.............................................................................................109.2 Bringing business value .................................................................................. 109.3 Bringing operational benefits........................................................................... 119.4 Bringing business and operational value ........................................................ 11

10 Preparing for the design ..................................................................................... 1410.1 Scope and terminology ................................................................................... 1410.2 Agreeing on a model blueprint ........................................................................1610.3 Class and name conventions.......................................................................... 19

11 Service decomposition and modeling.................................................................2211.1 Sources of information.................................................................................... 2211.2 Selecting a first service ................................................................................... 2511.3 Entry points to the model ................................................................................ 2611.4 Decomposition ................................................................................................2811.5 Service impact ................................................................................................2911.6 The main shapers of the service model .......................................................... 31

12 Use cases........................................................................................................... 4112.1 Modeling a stand-alone application server...................................................... 4112.2 Modeling a database-based application server............................................... 4112.3 Modeling a central application used in different places................................... 4212.4 Taking into account end-to-end monitoring and SLA/Os................................43

13 Annex A: sample interview form. ........................................................................45


3/46


Page 3 of 46 3/30/2007

1 Document owner & history

Date Name Organisation Phone Email

September 28,2005

Philippe Plomteux BMC Software (+32) 2 712 57 80 [email protected]

Date Version Description Editor

Septermber 28,2005

V 1.0 initial release N/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 andHenrik 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, ITILstandards have been applied.

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

The BMC Service Impact Manager product documentation includes valuableinformation on the principles of service modeling and service impact management, inparticular chapters 3 to 7 of the BMCImpact 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 howthis information is instantiated.


4/46


Page 4 of 46 3/30/2007

4 Introduction

While BSM is about a lot more than service and service impact management, thedesign 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 tohave a common understanding of the relationships between the technology (ICT) layersand the services these deliver.Therefore, service model design is more than often a highly-visible, highly-impactingactivity 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 thepurpose quite clear for everyone, the whole discipline is still relatively new and clearguidelines 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 productsneeded to actually implementthe 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 maintraps 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 whitepaper is not a how-to document addressing implementation considerations.

Only when necessary will references to BMC Service Impact Manager and the BMCAtrium 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 asincident, problem, change and asset management will not be addressed directly, eventhough 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 describedprinciples should apply indifferently to any technology.


5/46


Page 5 of 46 3/30/2007

6 Concepts review

Service impact management (SIM) consists of the identification, definition, andmanagement of critical services, their supporting IT resources, and the relationships

between these entities. SIM has the ultimate goal of identifying and analyzing theimpact of IT problems on the critical business processes to ensure continued delivery ofthese.

SIM depends on the development and maintenance of the service model. The servicemodel is a representation of the IT assets (physical and logical components) thatoperate together to deliver services and of the critical relationships and dependenciesbetween the components. It provides a dynamic, business-oriented view of businessservices. 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 serviceslowdowns or outages.

define and manage the critical relationships between IT assets and businessprocesses.

quickly determine the impact that an IT problem has on various business processesand 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 andphysical assets.

Relationships relate the CI together. A relationship describes the impact that a CIcalled providerhas on another one named consumer. Relationships therefore havea direction (from provider to consumer) that makes straightforward the constructionof hierarchical models.

From an implementation perspective, other data will be needed to make the actualservice 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?


6/46


Page 6 of 46 3/30/2007

When is the problem going to be fixed?

Who is responsible?

The relative importance of these questions within an organization will give a shape andfocus 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 thedocument, such as paragraph 10.1.1.


7/46


Page 7 of 46 3/30/2007

7 Benefits of Service Impact Management

There are numerous benefits in modeling services and using these models as the basefor service impact management. Among others:

Focus on end-users and business functions/processesThe availability and performance of a service could only be measured from the end userpoint of view. Availability of all servers is not a guarantee or indication of serviceavailability. The Service Impact Management approach focuses on the monitoringrequirements of business processes within a company and meeting end-usersexpectations.

Facilitate Configuration and Change Management ProcessesConfiguration Management is the process of identifying, controlling, maintaining andverifying 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 anyaspect of services, in a controlled manner, enabling approved changes with minimumdisruption.From these definitions, it is easy to see how the Service Impact Management processwould help the achievement of these other processes.

Reduce Cost of Managing ServicesAccording to ITIL, managers need to ensure that there is a proper balance between thequality of service on one side and expenditure on the other. Any investment thatincreases the costs of providing IT services should always result in enhancement to

service quality or quantity. The process of identifying services and their relationships tobusiness processes is the first step to become more efficient in the usage of resourcesand quality of service provided by IT.

Identify Gaps in MonitoringThrough Service Impact Management and by building a list of all assets that support theservices, the monitoring gaps would be identified. The relationships that exist among allcomponents and the business processes they support are a guiding light to evaluationof 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 valuethat IT brings to the business. That also helps to improve relationships with satisfiedcustomers through improvement of services provided.A model of business servicessupports decision making on IT investments, and priorities are better managed becauseIT investments are now more easily related to the business value of the services theysupport.


8/46


Page 8 of 46 3/30/2007

Service Level Management & SLAFor the purpose of creating a Service Level Agreement (SLA), IT is required to identifycompanys business functions and processes and the services it provides to supportthem. Service Impact Management effort provides IT with means to evaluate its owncapabilities 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 cangain by having knowledge of interdependencies of business functions and processeswith IT Services and their components. As an example, in case of server or applicationbreakdowns, from information within a Service Model, Service Desk could find who isaffected by the service degradation and provide that information to end users throughweb, phone messages or e-mail and reduce number of calls to the Service Desk.

Business Continuity Management / Business Impact AnalysisA key driver in determining IT Service Continuity Management requirements is howmuch 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 Analysisis to assess this through identifying critical business processes and the potentialdamage or loss that may be caused to the organization as a result of a disruption tocritical business processes. Due to its nature, a Service Management effort to identifyservices and their interdependencies (i.e. in the form of a Service Model) would help theorganization in these Business Continuity Management and Business Impact Analysisefforts.

Availability Management / Component Failure Impact AnalysisFrom the ITIL definition of Availability Management1: The goal of the AvailabilityManagement process is to optimize the capability of the IT Infrastructure, services and

supporting organization to deliver a cost effective and sustained level of Availability thatenables the business to satisfy its business objectives.

This is achieved by determining the Availability requirements of the business andmatching these to the capability of the IT Infrastructure and supporting organization...Availability Management should ensure the required level of Availability is provided. Themeasurement and monitoring of IT Availability is a key activity to ensure Availabilitylevels are being met consistently. Availability Management should look continuously tooptimize the Availability of the IT Infrastructure, services and supporting organization, inorder to provide cost effective Availability improvements that can deliver evidencedbusiness and User benefits.

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

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


9/46


Page 9 of 46 3/30/2007

8 Process overview

The remainder of the document will detail the different steps of the service modelingprocess. This section outlines the main phases, which will be covered in detail in the

rest of the document.

Before you beginThis is part 9 of the present document.

Identify the primary focus (operational benefits and/or business value) of theservice models. The shape of the model will be influenced by the chosen focus. Thisis discussed in section 9.1.Identify the main stakeholders and users of the service model/service impactmanagement solution. Both focus and stakeholders will determine the entry pointsto 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 termsand definitions [section 10.1]Agree on a model blueprint that will apply to all service models. The modelblueprint 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 modelingThis 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 impactand urgency of the failed service/process [section 11.2].Identify the entry points to the service model(s). These determine the top-levelobjects within the model [section 11.3].Proceed to business process walkthrough and start decomposition, keeping inmind granularity, hierarchy and modularity benefits in the construction of the model[sections 11.4 through 11.6].


10/46


11/46


Page 11 of 46 3/30/2007

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 theyprovide

prioritizing top issues and assigning the right resources to these issues.proactively informing users of service impactsintegrating 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 theprimary 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 theICT 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 thesame 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 potentialstakeholders. On the vertical axis the main levels of focus are presented (for a definitionof the terms Business Domain, etc, please refer to paragraph 10.1.1), while on thehorizontal axis we find the main possible user groups of the Service ImpactManagement solution. A square ticked in green circle is a clear entry-point, while asimple tick shows a potential match.

.


12/46


Page 12 of 46 3/30/2007

Business

users

Customers

ServiceManagers

ServiceDesk

ITOperations

ITS

upport

Business Domain

Business Function

Business Process

IT Service

IT component

Figure 1

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


13/46


Page 13 of 46 3/30/2007

Figure 2

Notethatthere is no preferred type of model among these three broad categories. Theobjectives, 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 managementIdentify the main users of the service impact management solutionDetermine the different entry-points [see section 11.3] for the service modelDefine your model blueprint [see section 11.2] according to this focus

ITResources

IT Services

BusinessResources

IT Services

ITResources

BusinessResources

BusinessResources

IT Services

ITResources


14/46


Page 14 of 46 3/30/2007

10 Preparing for the design

This section describes some important preparatory work to go through before any of themodel design starts.

First, we need to nail down terminology and concepts, so that all stakeholders are sureto speak the same language.Second, the organization should agree on a model blueprint, which will act as ablueprint for the service models and will ensure consistency and repeatability of theprocess.Finally, name and class conventions should be considered.

10.1Scope and terminologyThe considerations from the previous section on the focus of the service model (seefigure 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 themain concepts and terms used throughout the exercise. The list below may helpclarifying over-used terms.While most of the following explanations are accepted and used industry-wide, theimportant point to take home is not so much these definitions than the fact thatdefinitions must exist.

10.1.1 General definitions

The following list, mostly taken from the ITIL library2, can help the organization agree onthe main concepts and terms.

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

Business FunctionThis is a group of business processes that constitute a specific function such ascustomer support or sales. This represents the second level of business processdecomposition.

Business ProcessBusiness Processis a group of business activities undertaken in pursuit of a commongoal. A Business Process may have dependencies on several Business Functions andalso other Business Processes.This represents the third level of business process decomposition.

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


15/46


Page 15 of 46 3/30/2007

ServiceThe ITIL definition for Serviceis one or more IT systems that support or enable abusiness process. In other words, Servicecould be defined as all IT resources requiredfor the functionality of a business process.

The service can be composed of multiple applications, databases and infrastructurecomponents.A Service is the end-to-end technology infrastructure that enables one or manybusiness processes to be performed.

Typically an IT Service will have a Service Level Agreement (SLA) to specify its agreedserviceability.

IT SystemIT Systemis a group of software/hardware components to provide specific functionalityin 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) tospecify its serviceability.

IT ComponentA 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 becontained within other Components to the required depth to cater for assetmanagement needs, e.g. a Server contains a Disk Caddy which contains a removableDisk.

10.1.2 Defining IT Components

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

An application, for example, can be seen as an entity including many differentcomponents, or simply a process running on a single computer system.The way to follow remains similar: all IT components must be clearly defined to avoidconfusions in the model construction.

Tip:A good starting point for the definition of the different types of components is theCMDB Common Data Model reference (in HTML format) which ships as part of thedocument of the BMC Impact solutions.


16/46


Page 16 of 46 3/30/2007

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. Agood starting base would be the severity level index reproduced below, which woulddescribe the different severities that the state of an IT or Business process can have.

Severity Level Index

Severity Levels Definitions

UNAVAILABLE Permanently DisablingIMPACTED Critical End User Dissatisfaction

MINOR Causes Degradation of ServiceWARNING Causes Inconvenience/Annoyance to End UserINFO/OK Not 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 DataModel.Define a severity level index.

10.2Agreeing on a model blueprintBased on the agreed focus and terminology, entry points and scope, a generalstructure, or model blueprint, of the future service models should be derived.For consistency, repeatability and clarity purposes, the designed models should share acommon 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 onthat topic).that CI of a same type or class should be grouped (as much as possible) at thesame level within the model.that certain types of CI cannot be related to others, and that a model includes afixed, well-defined number of ordered layers.


17/46


Page 17 of 46 3/30/2007

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 thedifferent 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 homebanking environment.

Figure 3

Depending on the focus and the level of detail required [or not], the organization maychoose to use a model blueprint that does not necessarily cover all layers upfront (eventhough the blueprint and the models could be enriched as the solution grows), but ratherintroduces other types of objects to meet specific viewing requirements [seebusiness/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 boxesshows the name of the CDM classes that should be used for instantiation [see classconventions in paragraph 10.3.1].


18/46


Page 18 of 46 3/30/2007

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 relationshipsit defines that CI of a same type (class) should be as much as possible be at thesame 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 differentlevels 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 aBusiness Process/User Community, a geographical an SLA standpoint]Use subsequent designs of service models to validate the universality of the modelblueprint. This possibly will lead to amendments to the initial model blueprint.Allow for some flexibility in the model blueprint, not allmodels may exactly fit amodel blueprint which imposes a fixed number of layers.


19/46


Page 19 of 46 3/30/2007

For the modeling of an IT service, between 4 and 6 layers of CI are generallysufficient.The IT layers (IT System/IT components) may be automatically instantiated usinge.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 Discoverysuite3.

10.3Class and name conventionsAlthough these considerations mostly apply to the implementation phase, it is worththinking of a consistent way of classifying the different components of the model and ofnaming these same components.

10.3.1 Class conventions

The BMC Atrium CMDB relies on a Common Data Model (CDM) which defines a certainnumber of component (asset) classes available to classify the CI instances. The CDM isitself based on the industry-standard CIM model, which has been produced by theDesktop Management Task Force (http://www.dmtf.org).

Familiarity with the available classes and associated attributes on one side and with theadopted terminology on the other side will greatly help setting up a mapping tablewhere the different CI to instantiate have a corresponding CDM class.

An important note towards implementation: Many of the classes of the CDM can beinstantiated using the BMC Discovery solutions. As the discovery solutions introduce

constraints on the classes of objects that can be linked together, it is not recommendedto manually instantiate these classes. Check the BMC Atrium CMDB and DiscoverySolutions product documentation to verify which CDM classes can be automaticallyinstantiated.

Examples

The following table gives examples of possible mappings between the adoptedterminology and the classes available in the CDM.

Type of component CDM class Icon4

Business Process BMC_BusinessProcess

3Check the BMC Discovery suite product documentation for more information.

4Default icon in BMC Atrium CMDB 1.1


20/46


Page 20 of 46 3/30/2007

Type of component CDM class Icon4Service BMC_Service

IT System BMC_Group

application server BMC_ApplicationServer

physical server BMC_ComputerSystem

other infrastructurecomponents

(various) (various)

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

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 andattributes defined in the CDM. Leverage on previously defined terminology andconcepts.For CI that will be manually created (typically, the logical objects of the model), useclasses that are not instantiated by the Discovery solutions.Double-check that a class/attribute does not exist yet before deciding to create it inthe 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 aliasesof 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 lowercasedfully qualified domain name of the system


21/46


Page 21 of 46 3/30/2007

2. A CI of class Service has a name made out of the svc_ prefix, followed by theCamelCase 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 managementapplication, is in place and how can it be used/extended in the context of ServiceImpact Management.What is the name structure for a given CI type? For example, the name could bebuilt on the template :

/ /

Should the name reflect the type of the CI? (This may look as redundant informationbut 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 usespace 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 tohide the ugliness of event association.


22/46


Page 22 of 46 3/30/2007

11 Service decomposition and modeling

With the preparation work described in the previous section done, we can move on to amore 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.1Sources of information

One of the main challenges of the service modeling process is certainly to gather,confirm and make the synthesis of disparate, and sometimes unstructured, sources ofinformation within a given organization.This should be seen as another added value to the process. Translating information thatis often within the heads of a few people into structured service models highlycontributes to the consistency and durability of the knowledge and its diffusion acrossthe enterprise.

11.1.1 Interviews

The data on business processes and IT Services are collected by interviewing theproper resources.

Depending on the service identified for monitoring and management, the list of peopleto interview might differ. As an example, if the monitored service is email and theapplication used is MS Exchange, then anyone who is responsible for any componentswithin the MS Exchange environment would be a candidate for interview. The purposeof interviews would be to identify critical services within the environment and based onthat to identify the service components and their functionalities, availability andperformance parameters, failure points, cause and effects of failures, prevention anddetection options.

Annex A at the end of the document contains a simple list of typical questions to askwhen it comes to identifying and gathering information on business or IT services.


23/46


Page 23 of 46 3/30/2007

11.1.2 Documents

The Service catalog should be the authoritative document where the different servicesare defined and related to others in the organization.

Service Level Agreements are other reliable sources of information as to find the list ofIT Services and their components.A SLA is a written agreement between an IT Service provider and the IT customersdefining the key service targets and responsibilities of both parties.

Operational Level Agreements (OLA) are internal agreements covering the delivery ofservices which supports the IS organization in their delivery of services. OLA should setout specific back-to-back targets for support groups that underpin the targets included inSLA. For example, if the SLA includes overall time to respond and fix targets forIncidents (varying on the priority levels), then the OLA should include targets for eachof 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 networkrelated errors assigned to them). OLA therefore describe the required availability of anIT Service or component to perform its required function.

Business process models usually come under the form of diagrams and show thedecomposition of a business process into different steps, complete with theirinterdependencies and branch statements, if any. Business process models conveyinvaluable 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 SalesRepresentative (CSR) to handle customer requests over the phone in a retailorganization.

Automatic pickupphonecallcustomer

Automatic lookupcustomer

information

CSR takesphonecallcustomer

CSR lookuporder

CSR createorder

CSR updateorder

CSR closeorder

CSR lookupcustomer

CSR updatecustomer

yes

CSR endsphonecallcustomer

no

CSR lookupproduct

Next action

Figure 5


24/46


Page 24 of 46 3/30/2007

Application topology diagrams are a quite usual source of information when it comesto analyzing the ICT layers of the model. A topology diagram will usually show theinterconnection of the main IT components (servers, applications, databases, etc) of theimportant 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 contactsand sources of information. The approach should be to initially contact top managers toreceive buy-in and enforcement needed to get time with key personnel. The chart alsorepresents the organizational structure of the company that is helpful for identifyingBusiness Functions within the company.

Disaster Recovery Plans are also important source of information when trying toidentify the service components within IT environment. A disaster recovery plan shouldinclude 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 transferredover to an asset management tool or database and used for the Service Modeling.

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

Purchase Orders are basically a list of all IT assets purchased by the company and thepurpose 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 othersources.

11.1.3 Other sources of information

An existing asset management application or CMDB will obviously be a good startingbase, not only in terms of data population, but also to help to determine namingconventions and such.


25/46


Page 25 of 46 3/30/2007

11.2Selecting a first serviceAt the start of a service modeling engagement, or during a Proof-of-Concept, it isimportant to carefully choose which service or business process will be modeled.There are two main aspects to consider what the most critical processes in theorganization are: their respective impactand urgency. First of all, the nature of theprocess will usually give it an inherent impact:

ImpactUsually, the processes directly related to cash-flow generation (customer-orientedprocesses) 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 internalprocesses of people, technology and planning management.

UrgencyOther factors come into play to determine the priority of a given service or process. Toname 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 inthe current delivery of the service, operational needs and funding possibility will have animpact on the final priority ranking of the different services.

The following figure gives an example of how impact and urgency can be combined todetermine service priority.

Business Services

Importance Rating

Impact

Urgency

1.Metering

2.Invoicing

3.Output-Services

4.Distribution

5.Call Centre

6.Payments

low medium high

low

medium

high

Figure 6


26/46


Page 26 of 46 3/30/2007

Other factorsOther factors such as the complexity of the service (starting with a simple service willensure a smoother learning curve), the completeness of ITSM capabilities for thisservice (e.g., is it well monitored from an ICT availability perspective) should ideally betaken into account at this stage.

A careful weighting of these different aspects combined with the overall Corporate/ITGovernance information and IT strategy plan should be a solid basis for a discussionwith the key stakeholders to finally identify which services to pick up.

11.3Entry 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 decompositionexercise.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 9of 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 differentbusiness processes and the different user communities or customers who actually usethese business processes. The need to take into account Service Level Agreementsmay also dictate that models be constructed from the point-of-view of these SLA: Inmany cases there will be a need to combine both business and technical views. Aservice 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 technicalfailure so that it can be detected and fixed before the service is expected to be availableagain.

In the case of a more technical focus, IT services, applications and geographical entrypoints will commonly be elected.

11.3.2 Target audience

The different user groups of the final solution will also influence the different entry pointsto 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 BMCAtrium CMDB) will allow for a mix-and-match of these different entry points according tothe exact needs of the organization. There is no exclusive choice to make in thatrespect.Also, do not forget to align the selection of entry-points to the model blueprint discussedin section 10.2.


27/46


Page 27 of 46 3/30/2007

Refer to figure 1 in section 9.4 for more details on the correspondence between targetaudience and entry points.

11.3.3 Deriving business and technical views

In many cases, especially if the target audience is diverse and includes stakeholdersfrom the business and technical sides, the organization will desire different viewpointson the same set of components: LOB managers and business users will want a view onthe 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 thereforevisualization], as in the example of figure 4 where the whole model blueprint has beenreproduced in the box at the top.Box 1 presents a typical business entry point. The entry point is the Business Processlevel, drilling down towards the technology layers.Box 2 presents the geographical standpoint: the entry point is the region, drilling downtowards the sites and the different services that are available there.Box 3 presents the technological standpoint, where the different technologycomponents are grouped according to their type [servers, databases, etc.]

Figure 7


28/46


Page 28 of 46 3/30/2007

11.4DecompositionKnowing which services to model and what the various entry points to the service modelare, we can proceed to the service decomposition itself. This section covers the globalmethodology to adopt, while the following section on the shapers of the service modelwill give more detailed information on how to design the model itself.

11.4.1 Business Process Walkthrough

Considering that business processes are identified as entry points of the model, the keyobjective of the business process walkthrough is to trace the sequence of activitiesnecessary to the execution of the end-to-end process. With the help of the end-users orbusiness owners, the different activities (process steps) of the process or service areidentified and described.In a recursive fashion, each process step can be decomposed further in itsdependencies towards IT services.

The top-down approachIt 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 ourway downto 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 andnot silo-oriented

that, having in mind the implementation phase, gaps in the monitoring solution canbe identified

Starting in the middleThe top-down should be favored in any case, however in more complex situations thistask can be daunting and the overall learning curve quite steep, so a good compromisewill consist in starting in the middle, i.e. start the decomposition and analysis at theapplicationor IT servicelevel, build their model, and only afterwards start modeling theservices and processes that depend on these applications.This technique will usually yield quicker results and value (as the model of theapplications 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.


29/46


Page 29 of 46 3/30/2007

Best practices on the business process decomposition

adopt different view points (end user, service manager, service desk) to identify thevisible and invisible parts of a business processachieve 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 theICT layersstart in the middle for complex caseskeep your decomposition steps and terminology aligned with the model blueprintuse hierarchy, granularity and modularity to give shape to the model

11.5Service impactAfter the services and business processes have been decomposed down to thetechnology layer, it is important to assess if, how and when the technical componentsactually impact the services or business processes.The purpose of this assessment is to determine (looking towards implementation) theintensity of the impact relationships, and whether status computation should includecluster or weighted logic5.

Input from Incident/Problem Management Database is usually very helpful to relateservice impact to component impact. The ITIL documentation for AvailabilityManagement also contains very useful techniques that help identify the causes ofservice and business impact.

For example :

Component Failure Impact Analisys [CFIA]The purpose here is to predict and evaluate the impact of component failure on serviceavailability.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

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


30/46


Page 30 of 46 3/30/2007

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 Managementto 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 highAvailability 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 informationfamiliarize with the status computation capabilities of BMC Service Impact Managercontinuously refine and improve the service impact model. It is likely that not allpossible impacts are taken into account in the first version of the service impactmodel.


31/46


Page 31 of 46 3/30/2007

11.6The main shapers of the service modelIn this section many important considerations that ultimately give shape to the servicemodel will be covered. Once again there are no absolute answers or guidelines that canfit all contexts and all organizations. However we hope to help raising the rightquestions and avoiding the main traps in the process.

11.6.1 Overview

Identifying the stakeholders and users of the solution will determine the main entrypoints and granularity of the service model. Technical users will want a model where thedifferent ICT layers are presented and detailed, while business users will want a modelwhere the different business processes and services are represented.The previously defined model blueprint will dictate the instantiation of a stricthierarchical model, built following a top-down decomposition, where modularity bringsseveral benefits.

11.6.2 A hierarchical model

The case is quite clear: there is no other way than thinking your model from a puredependencystandpoint, rather than from a topology one.The confusion can especially arise in the technical layers of the model, where peopleare more inclined to think in a what is connected to what mode, rather than whatdepends on what. Many sources of information that are available when modeling theICT layers, e.g. application architecture diagrams and the like, will show a puretopological layout, and a translation work must be done to switch to a hierarchicalrepresentation.

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


32/46


Page 32 of 46 3/30/2007

Web Server

Application Server

Database ServerFirewall 2Firewall 1

Internet

Figure 8

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

Figure 9

While the impact of the failure of any of the technical CI on the Money TransferBusiness Process CI would correctly be computed, the other impacts along the chainwould 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 therespective availability of each technical component, so a hierarchical representation istherefore needed. Figure 10 shows a hierarchical representation of one businessprocess sitting on top of the application infrastructure shown above. In this diagram theavailability 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 blueprintexample of figure 4, as presented in the blue boxes next to the model.


33/46


Page 33 of 46 3/30/2007

Figure 10

A note on model simplification

Sometimes the temptation to simplify the model arises, for would-be clarity andrepresentation purposes. This is typically the case when many CI depend on a commonother CI. For example, a given IT service could be decomposed into different ITsystems, 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 : theunavailability of the DNS system impacts all other systems, and ultimately thedepending service.

Figure 11


34/46


Page 34 of 46 3/30/2007

A common temptation in such a case is to simplify the model by placing the DNSsystem as direct provider for the IT service, as in figure 12. Doing so reduces thenumber 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 thedifferent systems.

Figure 12

Best practices for building a hierarchical model

Use topological diagrams with caution. Do not translate topological relationshipsliterally. connected to does not mean depends on.Simulate how impacts propagate in the model you build. Ask yourself if a propagatedimpact 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 themodel


35/46


Page 35 of 46 3/30/2007

11.6.3 What granularity?

By granularity, we mean the level of details which we want to reach when constructing aservice model. A lowgranularity means that we do not go in deep details and that the CIused in the model could potentially be decomposed further. A highgranularity meansthe opposite, i.e. CI can potentially represent very detailed objects.

The considerations of this section mostly apply to the technical layers of the model, butcan nevertheless be considered as generic.Discovery tools are especially good at finding fine-grained information on the differentcomponents making up, for example, a computer system. CMDB entries will be createdfor the motherboard, the network interfaces, the hard drives and so on.This information is useful in the context of asset, change and configurationmanagement, but is usually of little interest in the context of service modeling, so abalance 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 andbusiness processes, not the detailed interactions of the underlying technical wiring.The hierarchical paradigm described above is likely to show its limits when it comesto representing low-level technical relationships.When service models are finally instantiated using BMC SIM, other tools such as thePATROL console will be in place to allow for a deep drill-down in the technicallayers. In many organizations, the majority of the SIM users will not need such alevel 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 toaddress the complexity of the model and the fact that when it comes to instrumentthe model (i.e., associating monitoring events to the instantiated service model), atechnical event can be attached to only one component of the model.6

For example, imagine we need to model two databases DBOne and DBTwo.These two databases are hosted on the same computer named system1. In afirst approach, we could imagine modeling these two databases without using aspecific 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 aprovider of the two databases, as in figure 13 below.

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


36/46


Page 36 of 46 3/30/2007

Figure 13

Root-cause drill-down will offer more fine-grained results if the CI are detailed. AComputer System CI identified as the root-cause of a given impact offers lessdetail than if we can narrow down on the specific component (disk, memory, etc) thatis the originating root-cause.Another benefit of a reasonably fine-grained model is that, when instantiated in BMCSIM, it offers better ways to control how impacts propagate along the dependencychain, hence allowing us to avoid the red or green syndrome, where serviceimpacts 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 necessaryWhen modeling applications running on distributed systems, stop the decompositionat Computer System level, and do not represent its different componentsLeverage on the flexibility of event association to avoid the creation of multiplecomponents

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 andcan be re-used independently.For example, consider the model of an application Application 1, complete with alldependencies towards the ICT layers, as in the next figure.


37/46


Page 37 of 46 3/30/2007

Figure 14

If Application1 is a provider for a first IT System (IT System 1 below), the model ofApplication 1 will be directly integrated to the model of this service, as in the followingscreenshot.

Figure 15

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

Figure 16


38/46


Page 38 of 46 3/30/2007

Making sure models are self-containedThis however requires, even though we seem to be stating the obvious, that services 1and 2 use the same application Application 1. But is it really the case in real life? Infact, 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 owncomponents, and not tocomponents whose usage vary according to the different services that depend on theapplication.

The following example illustrates the importance of the modularity, but also of carefullychoosing the entry points to the model. The model below is the representation of aservice 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 tothese 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 17

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

Figure 18


39/46


Page 39 of 46 3/30/2007

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

Figure 19

Once again, it is really important to question the model and check if the constructionmakes sense from an impact propagation perspective : to come back to the aboveexample, if a problem in application A1 has an impact on S1 but not on S2, then themodel 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 spaghettisyndrome. 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 20


40/46


Page 40 of 46 3/30/2007

It is therefore a good idea to create (within the limits of the model blueprint) a containerobject which will be used to regroup all the different providers, hence simplifying themaintenance 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-treeuse container objects to simplify the model and minimize the number of relationshipsin the model.question your model and verify if impact propagation makes sensealign your model with the model blueprintdesign your model to the last level of detailto avoid unpleasant surprises during theimplementation

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


41/46


Page 41 of 46 3/30/2007

12 Use cases

The following section describes commonly encountered use cases. It is impossible tocover all scenarios, but these simple examples may help to familiarize with the concepts

and way of thinking.

12.1Modeling a stand-alone application serverApplication servers (mail, web, etc.) are nearly always part of a service model. It isalways a good idea to separate the application layer from the system layer, as a samesystem may host multiple applications and as the application and the system may bemonitored differently.Therefore it is common to model as follows:

A first CI of type BMC_ApplicationServer describes the application itself. Eventsrelated to that application will be attached there.

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

Figure 22

12.2Modeling a database-based application serverIn the case an application requires an application server and a database to run, acommon way to build the service model for that application is as follows:

A CI of type BMC_ApplicationServer describes the application itself. Events relatedto that application will be attached there.

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

A CI of type BMC_DataBase describes the database instance

A CI of type BMC_DataBaseServer describes the database server.


42/46


Page 42 of 46 3/30/2007

A CI of type BMC_ComputerSystem describes the physical system hosting thedatabase. It may be same CI as the first BMC_ComputerSystem described above ifboth 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 23

12.3Modeling a central application used in different placesWhen a same application running in a data center needs to be accessed from differentsites 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 CIwill have as direct providers the following :

one CI that represents the central application, using for example the ideas of theprevious use cases

One BMC_ApplicationConnectivity CI for each remote-site connection.

The model then looks as follows:


43/46


Page 43 of 46 3/30/2007

Figure 24

12.4Taking 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-EndResponse Timer) are used in conjunction with element monitoring to check theavailability 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 inthe service model, adding to the classical service model built out of the separateelements.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, thetraditional service model of a web-based service is created as the infrastructuremodel. On the right side of the model, the different end-to-end monitoring probes arethe 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 forreference.


44/46


Page 44 of 46 3/30/2007

Figure 25


45/46


Page 45 of 46 3/30/2007

13Annex A: sample interview form.

The question form below contains a short list of typical questions to ask when it comesto 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 technicalcomponents 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 involvedDescribe the relations between the different teamsRoles & responsibilities of the different teams.

6. What group of people, functions, do you see as the recipients of information fromthe business/IT service monitoring solution? (Roles & responsibilities) Alsodescribe 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, takenfrom 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?


46/46


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 monitoringsolution?

16. What are the success criteria for this project?

Service modeling white paper

Documents

Transcript of Service modeling white paper