9/5/2006

Best Practices for Creating a Service Model

Greg WilsonWipro Technologies

9/5/2006 ©2006 BMC Software2

Introduction

› Why Best Practices for Service Modeling– It’s a complex activity– Getting it wrong is very easy – A lot of the work is “Process” or “Analysis”

9/5/2006 ©2006 BMC Software3

Steps in creating a Service Impact Model

1. Define the type and focus of the model2. Identify the users of the model and entry points3. Define the model blueprint4. Decide the level of granularity5. Decompose the service6. Analyze component impacts7. Verify monitoring of components8. Put it all together 9. Review with the stakeholders 10. Go Live !

9/5/2006 ©2006 BMC Software4

Step 1 – Model type and focus

› Why model an IT Service– Business Value

• Visibility into the impact of technical issues on business services and operations, better prioritization of response

• Improved communication between IT and the business• Improved availability of IT services supporting the business

– IT Operational Efficiency• Prioritizing incidents and assigning resources• Informing users through the Service Desk• Documenting and understanding relationships and interdependencies between IT

components– Both the above

9/5/2006 ©2006 BMC Software5

Types of Service Models

Type A: IT oriented Type B: Service/SLA oriented Type C: Business/Process oriented

ITResources

IT Servicedecomposition

BusinessResources

IT Servicedecomposition

ITResources

BusinessResources Business

Resources

IT Servicedecomposition

ITResources

BR

IT/S

IT/R

9/5/2006 ©2006 BMC Software6

Deciding the Focus of the Model

› What are the goals– Business Value– IT Operational efficiency

› Who will use the model– Sponsors and Stakeholders– Users / Consumers of Service Impact information

› What level of detail is required– The lowest level of components to be modeled– Structure of the model

9/5/2006 ©2006 BMC Software7

Step 2 – Users and Entry Points

› Who are the users of the model– Business Executives and Managers– IT Executives and Managers– IT Operations– Service “Owners”– IT Technical Staff

› What are the “entry points”– Users will need to enter the model from different views– Depends on the focus of the model– Business vs. Technical entry points are needed

• Service • Organization• Geographic• Technology

9/5/2006 ©2006 BMC Software8

Model Entry Point – Line of Business

9/5/2006 ©2006 BMC Software9

Model Entry Point – Users

9/5/2006 ©2006 BMC Software10

Step 3 – Defining the Model Blueprint

› Creating a blueprint ensures a consistent decomposition of IT Services being modeled

› The blueprint defines – What Configuration Item types will be in the model– Representation of service components with Common Data Model classes– Naming conventions for model components– The hierarchical structure of component relationships– Entry points for the different stakeholder views

9/5/2006 ©2006 BMC Software11

Example Model Blueprint

9/5/2006 ©2006 BMC Software12

Step 4 – Granularity of the Model

› Deciding on the right level of detail in the model depends on the model focus

– Discovery tools may provide an overwhelming level of technical details– For Business focused models, low granularity of IT components– More effort is required for maintenance of the model if it is very granular– Too little granularity and the model does not properly represent the service– Cannot pinpoint the cause of an impact without – No need to duplicate other tools functions

› Use judgment to balance the requirements – Beware of over simplification– Beware of over complexity

9/5/2006 ©2006 BMC Software13

Step 5 – Decompose the Service

› The first question you need to answer– What is the service to be modeled?

• Not always a simple question to answer• Customer may not agree on the definition of IT Service

› Where to find Services– Service Catalog– Service Level Agreements– Business Process Documentation

› Chose the service based on– Impact to the business of service unavailability

• e.g., Loss of a revenue generating service such as “webstore”– Visibility or Urgency

• A service that has a lot of pain associated with it

9/5/2006 ©2006 BMC Software14

Choosing the Service

Business ServicesImportance Rating

Impact

Urg

ency

1.Metering2.Invoicing3.Output-Services4.Distribution5.Call Centre6.Payments

low medium high

low

me

diu

mhi

gh

9/5/2006 ©2006 BMC Software15

Decomposing the Service

› Decomposition approaches– Top Down

• Recommended approach• Starting from the business service• Take different user views as stating points• Follow the process in “real life”

– Bottom up • Starting from the technology layers• Can get stuck in the silos

– Middle out • Starting from an application • Use in case of complex services or when business process is not documented

9/5/2006 ©2006 BMC Software16

Decomposing Business Processes

› Core Competencies– Examples Plan and Develop Products or Manage Customer Relations

› Business Functions – Examples Marketing and Research & Development or Sales Front Office

and Customer Support› Business Processes

– Market Research, Product Planning, Response Management, or Order to Cash

– These processes may have sub processes, examples Orders, Fulfillment, Invoicing, Accounts Receivable

– The rule of thumb is to take the lowest level as the link to IT Services

› The top layers are not always included in the service model

9/5/2006 ©2006 BMC Software17

Identifying the Logical components

› Logical Components– Are harder to identify than technology components– Represent logical parts of the service and its consumers– Refer to business process documentation– Application test and use cases– Use Interviews to collect “hidden” data from peoples memory

› Examples– Business Process– User Groups– Locations– Functional groups– Sub-Services

9/5/2006 ©2006 BMC Software18

Decomposing IT Services

› Map the lowest level of business process to services from IT Service Catalog

– “Webstore” service supports the “Orders” Business Process– “SAP AR” supports the “Accounts Receivable” business process

› Identify IT configuration items that support the IT service– Applications– Database– Servers

9/5/2006 ©2006 BMC Software19

Identifying the Physical components

› Physical components – Software and hardware configuration items– Can be simpler to identify than the logical components– Network and Application architecture diagrams– Discovery tools can provide the data

› Topology vs. Impact relationships– Using network diagrams requires caution– Can create an incorrect model

9/5/2006 ©2006 BMC Software20

Modeling Physical Components

Translating Network Diagrams to Impact Models

Web Server

Application Server

Database ServerFirewall 2Firewall 1

Internet

Does the failure of the database impact the firewall?

9/5/2006 ©2006 BMC Software21

Modeling Physical Components

Web Server

Application Server

Database ServerFirewall 2Firewall 1

Internet

9/5/2006 ©2006 BMC Software22

Step 6 – Analyzing the Impact of Failures

› What happens if the component fails?– Disaster Recovery / Service Continuity plans are a great source of

information– Application Architecture Diagrams– Documented Test and/ or Use Cases – Incident and Problem records from the Service Desk– Risk analysis on Requests for Change– Analysis techniques

• Component Failure Impact Analysis• Fault Tree Analysis• Ishikawa diagrams

9/5/2006 ©2006 BMC Software23

Example

Internet Information ServerASP Application ComponentsWebsphere MQ

SQL Server

CICSDB2Websphere MQ z/OSz/OS

9/5/2006 ©2006 BMC Software24

Component Failure Impact Analysis

› Technique to evaluate the Impact of a component failure– Code ‘A’ if failover to alternate component– Code ‘X’ if service is impacted

Configuration ItemAccount

RegistrationAccount Logon

Account Enrollment

Account Online

PaymentAccount View Bill

SQL Server - A A A A A ASQL Server - B A A A A AASP Application Components X X X X XInternet Information Server - A A A A A AInternet Information Server - B A A A A AWebsphere MQ X XServer A X X X X XCICS X XDB2 X XWebsphere - MQ z/OS X Xz/OS X X

9/5/2006 ©2006 BMC Software25

Analyze Status Propagation

› Status is determined by– Event severities are mapped to component status values – Status Propagation rules set the status of dependent components

› Analysis Steps– Review the event source for each component– Is the component status set appropriately for each event?– Does the status propagation reflect reality of the service?

9/5/2006 ©2006 BMC Software26

Step 7 – Verify monitoring of Components

› Components that are not monitored do not contribute to the model– Gaps in monitoring reduce the effectiveness of the model– Can be time consuming to address components not monitored– Simplify model to exclude components that are not monitored

› Are the right metrics for the component being monitored– Verify with Subject Matter Experts for the type of component

› Define alias formulas for associating events to the components– Not all events should affect the component status

• Informational events

9/5/2006 ©2006 BMC Software27

Step 8 – Put it all together

› Create the model with Service Model Editor› Associate the event sources to model components› Test the model

– Simulate failures of components and verify model correctly updates service status

9/5/2006 ©2006 BMC Software28

Step 9 – Verify with the stakeholders

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

9/5/2006 ©2006 BMC Software29

Step 10 – Go Live !

9/5/2006 ©2006 BMC Software30

Questions?

9/5/2006 ©2006 BMC Software31

References

› Service Modeling Best Practices White Paper– Philippe Plomteux, BMC Software, September 2005

› ITIL Publications– Service Support, – Service Delivery, – ICT Infrastructure Management

› BMC® Service Impact Manager– Service Model Development, Maintenance and Administration Guide

› BMC® Atrium CMDB– Common Data Model white paper– User’s Guide