Best Practices for creating a service model - BMC Software · PDF file2 9/5/2006 ©2006...
Transcript of Best Practices for creating a service model - BMC Software · PDF file2 9/5/2006 ©2006...
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