1. Front cover
Service Level Management Using
IBM Tivoli Service Level Advisor and
Tivoli Business Systems Manager
Integrate Tivoli Business Systems
Manager and Tivoli Service Level Advisor
Map business service management
to service level management
Achieve proactive service level
management
Edson Manoel
Kimberly Cox
Eswara Kosaraju
Matt Roseblade
Alex Shafir
Venkat Surath
Eduardo Tanaka
Brian Watson
ibm.com/redbooks

3. International Technical Support Organization
Service Level Management Using
IBM Tivoli Service Level Advisor and
Tivoli Business Systems Manager
December 2004
SG24-6464-00

4. Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
First Edition (December 2004)
This edition applies to IBM Tivoli Business Systems Manager V3.1, IBM Tivoli Service Level
Advisor V2.1, IBM Tivoli Enterprise Console V3.9, and IBM Tivoli Monitoring for Transaction
Performance V5.3 products.
Note: This book is based on a pre-GA version of a product and may not apply when the
product becomes generally available. We recommend that you consult the product
documentation or follow-on versions of this redbook for more current information.
© Copyright International Business Machines Corporation 2004. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.

5. Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Part 1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introduction to service level management . . . . . . . . . . . . . . . . . 3
1.1 Service level management overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Service level management benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Service level management components . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.3 People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Business service management approach to service level management. . 17
1.4.1 Convergence of business service management and service level
management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Improving service level management through integration . . . . . . . . . . . . . 20
1.6 Scope of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 2. General approach for implementing service
level management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 A look at the ITIL process improvement model . . . . . . . . . . . . . . . . . . . . . 25
2.2 Planning for service level management implementation . . . . . . . . . . . . . . 26
2.2.1 Identifying roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Understanding the services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Assessing the ability to deliver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Implementing service level management . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 Developing service level objectives . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2 Negotiating on service level agreements . . . . . . . . . . . . . . . . . . . . . 37
2.3.3 Implementing service level management tools . . . . . . . . . . . . . . . . . 38
2.3.4 Establishing a reporting function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.5 Adjusting IT processes to include service level management. . . . . . 41
2.4 Ongoing service level management program . . . . . . . . . . . . . . . . . . . . . . 44
2.4.1 Maintenance of service definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 45
© Copyright IBM Corp. 2004. All rights reserved. iii

6. 2.4.2 Service level agreement management via historical reporting . . . . . 46
2.4.3 Priority management of real-time faults . . . . . . . . . . . . . . . . . . . . . . 47
2.5 Continuous improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.5.1 Improving quality of service levels . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.5.2 Improving efficiency of service level management . . . . . . . . . . . . . . 49
2.5.3 Improving effectiveness of service level management . . . . . . . . . . . 50
Chapter 3. IBM Tivoli products that assist in service level management 53
3.1 IBM Tivoli product mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.1 The monitoring and measurement layer . . . . . . . . . . . . . . . . . . . . . . 54
3.1.2 The service level management layer . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 56
3.2.3 Benefits of using IBM Tivoli Business Systems Manager . . . . . . . . . 58
3.2.4 Key concepts in IBM Tivoli Business Systems Manager . . . . . . . . . 59
3.2.5 IBM Tivoli Business Systems Manager architecture . . . . . . . . . . . . . 62
3.3 IBM Tivoli Data Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 65
3.3.3 Benefits of using Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . 66
3.3.4 Key concepts in Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . . 67
3.3.5 Tivoli Data Warehouse architecture . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4 IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.4.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.4.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 72
3.4.3 Benefits of using IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . 74
3.4.4 Key concepts in IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . 75
3.4.5 IBM Tivoli Service Level Advisor architecture . . . . . . . . . . . . . . . . . . 76
3.5 IBM Tivoli Monitoring for Transaction Performance . . . . . . . . . . . . . . . . . 78
3.5.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.5.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 79
3.5.3 Benefits of using IBM Tivoli Monitoring for Transaction Performance80
3.5.4 Key concepts in IBM Tivoli Monitoring for Transaction Performance 80
3.5.5 IBM Tivoli Monitoring for Transaction Performance architecture . . . 83
3.6 IBM Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 87
3.6.3 Benefits of using IBM Tivoli Enterprise Console . . . . . . . . . . . . . . . . 88
3.6.4 Key concepts of event groups in IBM Tivoli Enterprise Console. . . . 89
3.6.5 IBM Tivoli Enterprise Console architecture . . . . . . . . . . . . . . . . . . . . 90
3.7 IBM Tivoli Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.7.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
iv Service Level Management

7. 3.7.2 High level description and main functions . . . . . . . . . . . . . . . . . . . . . 94
3.7.3 Benefits of using IBM Tivoli Monitoring . . . . . . . . . . . . . . . . . . . . . . . 95
3.7.4 Key concepts in IBM Tivoli Monitoring . . . . . . . . . . . . . . . . . . . . . . . 96
3.7.5 IBM Tivoli Monitoring architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.8 Bringing it all together in support of SLM processes . . . . . . . . . . . . . . . . 100
3.8.1 Service definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.8.2 Real-time monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.8.3 Historical monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.8.4 Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.8.5 SLA reporting and alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.8.6 Problem and change management . . . . . . . . . . . . . . . . . . . . . . . . . 107
Chapter 4. Planning to implement service level management using Tivoli
products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.1 Implementing SLM using Tivoli products. . . . . . . . . . . . . . . . . . . . . . . . . 110
4.1.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.1.3 Ongoing SLM program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.1.4 Improvement process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.2 IBM Tivoli Business Systems Manager V3.1. . . . . . . . . . . . . . . . . . . . . . 117
4.2.1 Propagation, alerts, and events . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.2.2 Basic business system building . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.3 Best practices for business system building . . . . . . . . . . . . . . . . . . 120
4.2.4 IBM Tivoli Business Systems Manager business system types . . . 121
4.2.5 IBM Tivoli Business Systems Manager views in an SLM context . . 125
4.2.6 IBM Tivoli Business Systems Manager roles in an SLM context . . 132
4.2.7 Understanding your services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.2.8 Using IBM Tivoli Business Systems Manager 3.1 features for the benefit
of SLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.2.9 Using PBT and RLP to manage high availability scenarios . . . . . . 139
4.3 Tivoli Data Warehouse V1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.4 IBM Tivoli Service Level Advisor V2.1. . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4.4.1 Building SLAs in IBM Tivoli Service Level Advisor . . . . . . . . . . . . . 156
4.4.2 Supporting SLM with IBM Tivoli Service Level Advisor. . . . . . . . . . 164
4.4.3 Realistic expectations for real-time SLAs . . . . . . . . . . . . . . . . . . . . 186
4.4.4 Integrating IBM Tivoli Service Level Advisor with IBM Tivoli Business
Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.5 Additional products supporting SLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
4.5.1 IBM Tivoli Monitoring for Transaction Performance . . . . . . . . . . . . 190
4.5.2 IBM Tivoli Monitoring for Operating Systems . . . . . . . . . . . . . . . . . 192
4.5.3 IBM Tivoli Monitoring for Databases . . . . . . . . . . . . . . . . . . . . . . . . 192
4.5.4 IBM Tivoli Monitoring for Web Infrastructure. . . . . . . . . . . . . . . . . . 193
Contents v

8. Part 2. Case study scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Chapter 5. Case study scenario: IRBTrade Company . . . . . . . . . . . . . . . 197
5.1 Background of the business and its current issues . . . . . . . . . . . . . . . . . 198
5.1.1 The business perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
5.1.2 The Information Technology perspective . . . . . . . . . . . . . . . . . . . . 200
5.2 Existing IT infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.1 Systems environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.2 Systems management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.2.3 Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.3 A service level management solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
5.3.1 Where we want to be . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.3.2 Where we are now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.3.3 How we will get there . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.3.4 How we will know we have arrived . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.4.1 Additional instrumentation required. . . . . . . . . . . . . . . . . . . . . . . . . 212
5.4.2 Identifying the business service . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
5.4.3 Identifying necessary users roles . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.4.4 Required resource types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
5.4.5 Creating business systems based on business functions. . . . . . . . 231
5.4.6 Defining executive dashboard views. . . . . . . . . . . . . . . . . . . . . . . . 239
5.4.7 Agreeing to and defining service level objectives . . . . . . . . . . . . . . 251
5.4.8 Identifying metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
5.4.9 Enabling data sources in IBM Tivoli Service Level Advisor . . . . . . 260
5.4.10 Setting up schedules, realms, and customers . . . . . . . . . . . . . . . 262
5.4.11 Setting up offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.4.12 Setting up SLA in IBM Tivoli Service Level Advisor . . . . . . . . . . . 276
5.5 How the new solution works in practice . . . . . . . . . . . . . . . . . . . . . . . . . 292
5.6 Continuous improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Chapter 6. Case study scenario: Greebas Bank. . . . . . . . . . . . . . . . . . . . 315
6.1 Background to the business and its current issues . . . . . . . . . . . . . . . . . 316
6.1.1 The business unit perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
6.1.2 IT management perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
6.2 Existing IT infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
6.2.1 Systems environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
6.2.2 Systems management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
6.2.3 Existing service level management. . . . . . . . . . . . . . . . . . . . . . . . . 322
6.2.4 Business service management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
6.3 A service level management solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
6.3.1 Where we want to be . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
6.3.2 Where we are now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
vi Service Level Management

9. 6.3.3 How we will get there . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
6.3.4 How we will know we have arrived . . . . . . . . . . . . . . . . . . . . . . . . . 330
6.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
6.4.1 Stage 1: Defining services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
6.4.2 Stage 2: Enhancing instrumentation . . . . . . . . . . . . . . . . . . . . . . . . 333
6.4.3 Stage 3: Determining users and roles . . . . . . . . . . . . . . . . . . . . . . . 337
6.4.4 Stage 4: Determining IBM Tivoli Business Systems Manager resource
types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
6.4.5 Stage 5: Creating IBM Tivoli Business Systems Manager business
systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
6.4.6 Stage 6: Creating IBM Tivoli Business Systems manager views . . 351
6.4.7 Stage 7: Agreeing to service level agreement objectives . . . . . . . . 363
6.4.8 Stage 8: Defining metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
6.4.9 Stage 9: Preparing for ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
6.4.10 Stage 10: Preparing IBM Tivoli Service Level Advisor . . . . . . . . . 371
6.4.11 Stage 11: Creating offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
6.4.12 Stage 12: Creating SLAs and OLAs . . . . . . . . . . . . . . . . . . . . . . . 395
6.4.13 Stage 13: SLA reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
6.5 How the SLM solution works in practice . . . . . . . . . . . . . . . . . . . . . . . . . 414
6.5.1 Example 1: Component failure without loss of service . . . . . . . . . . 414
6.5.2 Example 2: Component failure terminates a service. . . . . . . . . . . . 421
6.5.3 Root cause analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
6.5.4 Assessing the SLM solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
6.6 Continuous improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Appendix A. Service management and the ITIL . . . . . . . . . . . . . . . . . . . . 447
The ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Service management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Service delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Service support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Service support disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Service desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Incident management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Problem management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Release management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Service delivery disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Capacity management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Availability management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Financial management for IT services . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Contents vii

10. IT service continuity management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Service level management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Bringing it all together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Constant improvement is a must . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
The power of integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Appendix B. Important concepts and terminology . . . . . . . . . . . . . . . . . 515
IBM Tivoli Service Level Advisor concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . 516
IBM Tivoli Business Systems Manager concepts. . . . . . . . . . . . . . . . . . . . . . 521
Appendix C. Scripts and rules used in this book. . . . . . . . . . . . . . . . . . . 527
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
viii Service Level Management

11. Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2004. All rights reserved. ix

12. Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Eserver® DB2® Redbooks (logo) ™
ibm.com® IBM® Redbooks™
z/OS® IMS™ Tivoli Enterprise™
AIX® Lotus® Tivoli Enterprise Console®
CICS® NetView® Tivoli®
CICSPlex® OMEGAMON® TME®
Database 2™ OS/390® WebSphere®
Domino® OS/400®
DB2 Universal Database™ Rational®
The following terms are trademarks of other companies:
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others
Peregrine ServiceCenter is a trademark of Peregrine.
x Service Level Management

13. Preface
Traditional availability management focuses on managing the state of IT
resources at a component level, without the context of the required service
necessary to support vital business functions. As IT organizations mature and
focus more on meeting business objectives, they recognize the value of providing
sustained levels of availability. They also improve service quality that is
consistent with business objectives and cost constraints.
Managing IT costs requires repeatable and measurable processes such as the
best practices for service level management (SLM) documented in the IT
Infrastructure Library (ITIL). Central to the ITIL best practices are the service
management processes. These are subdivided into the core areas of service
support (day-to-day operation and support) and service delivery (long-term
planning and improvement).
This IBM® Redbook takes a top-down approach that starts from the business
requirement to improve service management. This includes the need to align IT
services with the needs of the business, to improve the quality of the IT services
delivered, and to reduce the long-term cost of service provision. It focuses on
how clients accomplish this by implementing SLM processes supported by IBM
Tivoli Service Level Advisor and IBM Tivoli Business Systems Manager. The
approach used in this book leverages Tivoli® and non-Tivoli monitoring sources.
IBM Tivoli Monitoring for Transaction Performance, IBM Tivoli Monitoring, and
various IBM Tivoli Monitoring PACS, along with Peregrine ServiceCenter, serve
as interface points to provide the end-user perspective of service delivery.
For IT managers and technical staff who are responsible for providing services to
their customers, use this IBM Redbook as a practical guide to SLM with IBM
Tivoli products. It takes you from a general outline of SLM to specific
implementation examples of banking and trading that incorporate the Tivoli
monitoring products.
The key elements that are addressed in this redbook are:
Organizational considerations for implementing the ITIL processes
Identifying which services or business functions will be used for the initial
deployment
Determining the metrics and monitoring sources required for operational and
service level agreements (SLA) definition and evaluation, including business
schedules and maintenance periods
© Copyright IBM Corp. 2004. All rights reserved. xi

14. Leveraging IBM Tivoli Business Systems Manager for configuration and
availability management of services
Peregrine ServiceCenter for service desk in a component-level for SLA, as
well as managing service incidents in real-time
The value of understanding the impact of end-user response time on service
delivery
Managing end-to-end services that include mainframe and distributed
components
Improving service delivery with proactive service management using
predictive analysis and operational status alerts
Providing ongoing executive-level status, and on-demand reporting
The next steps for expanding the deployment using the ITIL continuous
improvement process approach
Overall business value attained through the implementation of these
processes and tools
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization (ITSO), Austin
Center.
Edson Manoel is a software engineer at IBM working in the ITSO, Austin Center,
as a Senior IT Specialist in the systems management area. Prior to joining the
ITSO, Edson worked in the IBM Software Group, Tivoli Systems, and in IBM
Brazil Global Services Organization. He was involved in numerous projects in
designing and implementing systems management solutions for IBM Clients and
Business Partners. Edson holds a Bachelor of Science degree in applied
mathematics from Universidade de Sao Paulo, Brazil.
Kimberly Cox is an IBM Certified IT Specialist with IBM Software Services for
Tivoli. She joined IBM in 1998. She has six years of field experience and her
current area of expertise is the architecture and deployment of IBM Tivoli
Business Systems Manager/Distributed. She holds a master degree in computer
science and engineering from Pennsylvania State University.
Eswara Kosaraju is an advisory software engineer for the IBM Tivoli Software
Group in Research Triangle Park, North Carolina. He joined IBM in 1999. He
holds a master degree in science and technology in engineering physics from
Regional Engineering College, Warangal, India.
xii Service Level Management

15. Matt Roseblade is a services consultant with the PAN-EMEA Services for Tivoli
Software based in the United Kingdom (UK). He has worked for IBM for nine
years and has four years of experience in working with IBM Tivoli Business
Systems Manager on engagements throughout Europe. Prior to working for IBM
Software Group, Matt worked for IGS SSO leading a team responsible for the
systems management of IBM and outsourced z/OS® systems across EMEA.
During his 14 years in IT, Matt has acquired 12 years experience in system
management disciplines on the mainframe.
Alex Shafir is an advisory software engineer with the IBM Tivoli Software Group
in Research Triangle Park, North Carolina. He has been working with IBM Tivoli
Business Systems Manager since 1997 and joined IBM in 2000. He has over 30
years of IT experience in both technical and management positions. He has been
involved in SLM, capacity planning, and performance management since 1984.
He holds master degree in electrical engineering from Polytechnical Institute,
Riga, Latvia.
Venkat Surath is a senior IT specialist, as well as an IBM Certified IT Specialist,
and part of IBM Software Services for Tivoli Americas. He holds a master degree
in computer science from Illinois Institute of Technology, Chicago. Upon
graduation, he joined Communications Products Division, IBM Research Triangle
Park, NC in 1983 as a software engineer developing network management
software. In 1997, he joined Tivoli Services North America and provides Tivoli
Business Systems Management services. His areas of expertise include IBM
Tivoli Business Systems Manager (Distributed) and Tivoli Monitoring for
Transaction Performance.
Eduardo Tanaka is a software engineer for the IBM Software Group, Tivoli
Division in Research Triangle Park, North Carolina. He worked nine years in
UNIX® server hardware and software development and management for a
Brazilian company. Then, in 1990, he joined IBM where he served as the
development, function and system test team leader for various system and
network management products. He holds a degree in electronic engineering from
the Instituto Tecnologico de Aeronautica in Brazil.
Brian Watson is a consulting IT specialist from Tivoli Services, EMEA North
Region, IBM Software Group. He has worked for IBM for over three years, has
over 25 years of IT experience in both public and private sectors, and specializes
in systems management. He was one of the first people to be ITIL certified in
1995, and has successfully completed many large and complex systems
management projects including implementations of IBM Tivoli Business Systems
Manager.
Preface xiii

16. Front row (left to right): Matt Roseblade, Kimberly Cox, and Venkat Surath; back row:
Edson Manoel, Eswara Kosaraju, Eduardo Tanaka, Alex Shafir, and Brian Watson
Thanks to the following people for their contributions to this project:
Peer van Beljouw
Ruth van Ouwerkerk
ABN AMRO Bank, Netherlands
Budi Darmawan
Morten Moeller
ITSO, Austin Center
Rosalind Radcliffe
BSM Integration Architect, IBM Software Group, Raleigh
Eduardo Patrocinio
Tivoli SWAT Team, IBM Software Group, Raleigh
Jayne T. Regan
Service Level Advisor Development Manager, IBM Software Group, Raleigh
Michael D. Tabron
Tivoli Service Level Advisor Interaction Designer, IBM Software Group, Raleigh
Joe Belna
Shawn Clymer
Subhayu Chatterjee
TSLA Development team, IBM Software Group, Raleigh
xiv Service Level Management

17. Gareth Holl
TSLA L2 Support, IBM Software Group, Raleigh
Tom Odefey
TBSM SVT Specialist, IBM Software Group, Raleigh
Tony Bhe
ITM SVT Specialist, IBM Software Group, Raleigh
Jon O. Austin
John Irwin
Yoichiro Ishii
Tivoli Customer Programs, IBM Software Group, Raleigh
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Preface xv

18. Comments welcome
Your comments are important to us!
We want our Redbooks™ to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an email to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
xvi Service Level Management

19. Part 1
Part 1 Fundamentals
This part includes the following chapters:
Chapter 1, “Introduction to service level management” on page 3
Chapter 2, “General approach for implementing service level management”
on page 23
Chapter 3, “IBM Tivoli products that assist in service level management” on
page 53
Chapter 4, “Planning to implement service level management using Tivoli
products” on page 109
© Copyright IBM Corp. 2004. All rights reserved. 1

20. 2 Service Level Management

21. 1
Chapter 1. Introduction to service level
management
This chapter introduces service level management (SLM). It also outlines an
approach to the management of the business-oriented delivery of IT services
that this book details in later chapters.
Refer to Appendix A, “Service management and the ITIL” on page 447, for details
about the organization and activities of SLM and the contributing IT management
disciplines.
© Copyright IBM Corp. 2004. All rights reserved. 3

22. 1.1 Service level management overview
The goal of maximizing profits drives change as well as innovation. It often
involves the use of IT to gain a competitive advantage in selling a company’s
products and services. To achieve their goals, business units partner with an IT
organization to implement technology projects and thus become IT customers.
Accordingly, IT organizations are hired by business units to provide technology
services. Therefore, they must meet their requirements for those services. In
today’s cost-conscious environment, IT organizations are under pressure to
reduce costs even as they must deliver a higher level of service to increasingly
well informed users.
Why service level management?
For this reason, customer perception of the availability and performance of these
services drives customer satisfaction. As a service provider, an IT organization
must be able to demonstrate and guarantee quality of service to its customers.
However, IT management has often struggled to measure delivered services
while reconciling such measurements with the perceived quality of this delivery.
To solve this problem, IT organizations are deploying SLM that includes contracts
between IT and its clients that specify the client expectations, IT’s
responsibilities, and the compensation that IT will provide if the goals are not
met.
The main factors for driving interest to SLM are:
Complexity: A dramatic increase in the number of applications, their
importance, and demand on IT infrastructure
Dissatisfaction: Increasing user sophistication and growing dissatisfaction
among users with service that they receive from IT
Better technology: More mature technology that can provide end-to-end
measurement, reporting, and management at a reasonable cost and offer
more simple process
What is service level management?
SLM is a means for the lines of business (LOB) and IT organization to explicitly
set their mutual expectations for the content and extent of IT services. It also
allows them to determine in advance the steps to take if these conditions are not
met. The concept and application of SLM allows IT organizations to provide a
business-oriented, enterprise-wide service by varying the type, cost, and level of
service for the individual LOB.
4 Service Level Management

23. According to the highly popular, process-based methodology IT Infrastructure
Library (ITIL), SLM is the process of negotiating, documenting, agreeing and
reviewing business service requirements and targets, within service level
requirements and agreements between service providers and their customers.
These relate to the measurement, monitoring, reporting, reviewing, and
continuous improvement of service quality as delivered by the IT organization to
the business.
ITIL’s methodology provides two models for IT activities: service delivery and
service support.
Service delivery
SLM, along with availability management, capacity management, IT service
continuity management, and financial management for IT services, comprises
the service delivery model. The primary role of this model is to offer a proactive
process of planning and management of service according to the plan.
Service support
The service support model includes incident management, problem
management, change management, release management, and configuration
management. The primary role of this model is to offer operational
implementation and monitoring of service according to the plan.
Figure 1-1 shows how the service delivery and service support models fit in the
ITIL roadmap for service management.
Planning to implement
Service Management
Service Management
The Business
Information
Perspective
Service Delivery Service Support Technology
perspective
Linking business goals to IT
Providing IT Services Providing IT Services
cost-effectively support and maintenance
Applications Security IT Infrastructure
Management Management Management
Figure 1-1 The ITIL service management roadmap
Chapter 1. Introduction to service level management 5

24. According to the ITIL, SLM relates to the other aforementioned disciplines as
follows:
Supported by availability management, IT service continuity management,
capacity management, problem management, and configuration
management
Provides information to incident management and change management
Monitored via financial management for IT services, incident management,
capacity management, and availability management
Supports application management, business processes, and event
management
SLM is the disciplined, proactive methodology. Procedures are used to ensure
that adequate levels of service are delivered to all IT users in accordance with
business priorities and at an acceptable cost. Service levels typically are defined
in terms of availability, responsiveness, integrity, and security delivered to users
of the service.
Pros and cons of service level management
Although the duration and scale of SLM implementations may vary, both large
and small corporations can capitalize on the benefits of SLM. They do so by
choosing the components that are most appropriate to their specific SLM needs.
Implementing SLM requires time and effort. It is difficult to rationalize allocation
of IT resources to this project if IT is already working with limited resources. In
addition, IT clients sometimes abuse the SLM processes, especially when they
aim for unreasonable or unattainable service level commitments.
However, this should not stop IT management from developing SLM, which can
be equally important for both business units and an IT organization. SLM
increases the efficiency of an IT organization and introduces a financial incentive
and penalty system for service delivery.
Indeed, the rising popularity of SLM testifies to its value. For an IT organization,
the effective SLM is often a matter of survival particularly if its mission is to
operate as a business. The product of an IT organization is the service it delivers
to business units.
For an IT organization, providing quality services is not enough. The service
must consistently be of the same high quality both in actual delivery and in the
eyes of the users of the services. SLM supports IT organizations to improve the
quality of the services provided and the quality of the services as it is perceived
by the users of IT services. Refer to Appendix A, “Service management and the
6 Service Level Management

25. ITIL” on page 447, for a definition of quality of services and how it is perceived by
users and customers of IT services.
Both an IT organization, as a seller, and a business unit, as a buyer, need a
contract that clearly defines both the capabilities and limitations of this process.
For reasons of customer satisfaction and cost control, the product must meet the
specifications of this contract.
1.2 Service level management benefits
Businesses need to respond quickly to market demands and seek to maximize
profits. These goals often result in a high volume of change for IT organizations.
Every IT organization has an objective to align its goals with business
requirements and to better support business needs. They use SLM to ensure
that scarce IT resources are prioritized to focus on key business requirements.
By implementing SLM, IT organization can achieve many of their goals. However,
they must overcome many challenges to ensure that the SLM program is
successful.
Goals
The goals of SLM are:
Understand and meet the requirements of customers and end users
Use resources efficiently, effectively, and provide value for money
Improve continuously through a process of learning and growth
Use internal process to generate added value for customers and survive
Establish a business-like relationships between the customer and supplier
Challenges
The challenges of SLM are:
Divergent views of business and IT organizations
Diversity of organization business areas
Changing the mind set from products and systems to services
Perception of IT (historically not always good)
Unknown components, dependencies, and ownership
Poor quality management information and metrics
Unable to justify investment or assess risk
No measure of proof of improvement
Coping with infrastructure complexity
Providing consistent and stable services
Chapter 1. Introduction to service level management 7

26. Faced with many constraints, an IT organization wants recognition for providing
good services based on component-centric measurement metrics. At the same
time, business units feel that they are paying for a service, but cannot perform
their work and do not trust IT that always report good service. SLM offers
evolution for measuring IT effectiveness by moving from the component-based
evaluation of service to service-based management.
Figure 1-2 illustrates a situation where the reduction of the downtime of
components reported by the IT organization does not improve customer
satisfaction because the damage has already been done. It emphasizes the fact
that business units and IT organizations have different views of the customer
perception on the quality of the services provided.
BUSINESS
MANAGER
IT
ME
AS
UR
EM CUSTOMER
EN IMPACT
TS
TS
EN
EM
UR
AS
Outages
S ME
ES
SI N
BU
IT
COMPONENTS
DOWNTIME
IT MANAGER
Time
Figure 1-2 IT and business views often differ
When used correctly, SLM helps an IT organization to deploy resources fairly,
defend itself from user attacks, and advertise good service.
8 Service Level Management

27. How can SLM help IT to deploy resource fairly?
Client satisfaction
SLM necessitates IT management to initiate a dialog with business units to
understand the requirements for service. It also forces business units to
clearly state their requirements and expectations. Improved client satisfaction
is the main benefit of SLM, which ensures it through negotiated SLAs,
established benchmarks for service measurement, and continuing dialog
through reporting and reviews.
Managing expectations
SLM makes it possible to avoid an expectation creep of rising levels of IT
clients’ undocumented expectations. Undocumented users’ requirements and
expectations levels usually lead to expectations staying ahead of service that
is being delivered. SLAs document negotiated requirements and establish
expectations. They also serve as brakes when users want higher levels of
service than IT committed to deliver.
Resource regulations
SLM provides a mechanism for governing IT resources. It allows IT to reject
demands for resources to applications that unfairly tie up resources, and
therefore, regulate workload based on business priorities. SLM helps to avoid
capacity problems by providing early warning of SLAs being violated.
Additional equipment might be required to support IT commitments.
Cost control
SLM helps IT to determine, through dialog with users, the level of service
required and to determine the acceptable capacity and staffing it needs to
provide. SLM can demonstrate that desirable service is not always affordable
and can impact costs through moderating user demands for higher levels of
service. It allows IT to explain the financial impact of higher levels of service
and avoid the unnecessary cost by forcing users to justify the additional cost.
SLM helps to change relationships between business units and IT from a
negative acceptance of IT as a necessary evil to viewing IT as an asset in
executing their mission. When the clear service objectives are documented and
negotiated measurement reporting is in place, IT has the means to manage its
resources as well as user dissatisfaction.
Benefits
In summary, the benefits of SLM are:
IT service designed to meet agreed requirements
Clearly defined roles (activities, responsibilities, and authority)
Measurable, realistic SLAs for improved customer and supplier relationships
Balances service requirements against the costs
Chapter 1. Introduction to service level management 9

28. Reduces risk of unpredictable demand and capacity problems
Helps identify service weaknesses
Allows underpinning of supplier management
Provides basis for charging and measuring value
Establishes an improvement baseline
1.3 Service level management components
To create and maintain SLM, IT managers need well defined processes, proven
tools, a dedicated effort, and a business wide commitment. SLM shifts IT
management perspective away from technology and toward the demands of the
business and user experiences. It introduces new methods and procedures as
well as makes enhancements to the old ones.
SLM focuses on the management of an IT service in support of a specific
business process. An IT service includes applications and infrastructure
resources used by this business process. Management includes planning,
monitoring, and reporting. SLM uses SLAs to identify service and determine its
management criteria.
SLM is a process that is supported by several other processes, including
performance and availability management. Both performance and availability
management processes are essential for monitoring SLAs. However, an
understanding of end-user perspectives through synthetic transactions and
communications with users is also critical. Accordingly, monitoring of
performance and availability must be adjusted to account for user experiences.
For this reason, IT operations must incorporate end-user experiences and
business function knowledge into the management IT infrastructure and
applications. In addition, IT support must incorporate business requirements into
the asset management, change management, and incident management.
The following sections introduce four SLM components that are essential for
implementing a successful SLM program.
Processes
Documentation
People
Tools
10 Service Level Management

29. 1.3.1 Processes
The functions in SLM can be divided as follows:
Identify users’ expectations and define parameters for service.
Ideally, IT must identify all of the business processes that must be managed.
In practice, it is acceptable to select the critical business processes during the
first stages of the SLM process implementation and then incorporate
additional business processes as the SLM process mature. The IT
organization can work with business owners to pinpoint the elements of these
business processes. They can define service parameters such as end-user
expectations of service, participating IT application and infrastructure
components, and metrics for measuring service levels.
Assess service capabilities and negotiate service agreements.
First an IT organization must have a clear understanding of service
expectations, composition of service elements, and service level
measurement metrics. Then it must collect data and assess its current
capabilities for meeting a customer’s expectation of service levels. After
studying current capabilities for delivering all services required and
indentifying opportunities for improvement, IT management is ready to talk
with customers about the service levels that it can provide.
IT should avoid technical terminology and describe services and expectations
in a manner that is understandable to its customers. At the same time, IT
should fully understand what service levels it can deliver and achieve
agreement from its customers on service levels measurement and reporting
criteria. IT must document negotiated expectations and measurements
metrics as well as agreed upon acceptable service levels values.
Manage to meet service level objectives (SLOs).
IT must align its processes to proactively monitor, measure, and manage
against negotiated SLAs. Accordingly, IT must develop SLOs to meet SLA
obligations for underlying IT components, measure actual values against
SLOs, and associate the measured status against the SLAs.
Upon recognition of service level degradation (preferably through real-time
alerts), IT can immediately start finding a problem and restoring service to
acceptable levels as defined by SLAs. If the problem is serious, IT may also
notify users so they can avoid affected services and calls to the help desk.
SLAs that relate to IT operations and support (OLAs) recognize component
issues quickly and evaluate their measurements prior to their impact on SLAs
and IT customers. IT must come up with monitoring processes, measurement
metrics, and automation that allow prompt responses to problems by
technical staff in addition to reporting an OLA’s status to management.
Chapter 1. Introduction to service level management 11

30. SLM uses reporting to communicate overall service level performance to IT
and business management. Effective reporting should show IT performance
against service-level commitments (successes and failures). It can be used
together with financial incentives to improve IT processes and users behavior.
Continue service refinement and improvement.
The SLM process should always be examined for process effectiveness,
service changes, and reporting accuracy. Customer expectations change as
business processes grow and new applications and users are added. As
monitoring technology improves, IT can expand metrics that measure
component performance and customer satisfaction. IT must periodically
re-evaluate the services it provides.
Service improvement is a continuous process that allows IT to add more
value, adjust to new realities, justify new technology, and often derive more
revenue. The same can be said about the SLM process that needs
continuous improvement to gain the trust of business owners, improve
efficiency through automation, and effectiveness through a better
understanding of business-to-IT relationships.
Figure 1-3 illustrates the SLM functions.
Negotiate SLAs
Manage and monitor Define parameters for
SLOs services
Service refinement and
improvement
Figure 1-3 SLM process
12 Service Level Management

31. 1.3.2 Documentation
Because SLM relies on several parties involved in defining the processes,
negotiations, penalties, and so on, documentation is a must. The following
documents support SLM:
Service level agreements
An SLA is an agreement between business units (the customer) and IT
organization (the service provider). It describes the service and service level
measurement metrics, defines the approval and reporting process, and
identifies the primary users. It can also include financial terms and conditions.
SLAs provide a mechanism for establishing accountability for both IT and their
customers for the provided service levels which are negotiated and agreed to
based upon business requirements, priority, and cost. SLA measurements
must be directly aligned with customer expectations. SLAs are the basis for
service level evaluation and improvement processes that include periodic
reviews and adjustments if needed.
Operational level agreements
An operational level agreement (OLA) is an internal agreement that shout be
established between all business and IT groups prior to the execution of an
SLA. The OLA establishes specific requirements that each IT group needs to
meet in support of service levels and make them accountable for their
contribution to the overall improvement of service levels.
Well-defined OLAs show IT management which areas have more impact on
service levels, where to focus attention and financial rewards, and how each
group can contribute if business requirements require a change of SLAs.
Underpinning contract
IT should establish underpinning contracts (UCs) for any service provided by
external service providers and vendors. UCs add accountability for external
component of service levels in the same way as OLAs account for the internal
components of service levels.
IT can use the contractual agreements that they have with their third-party
vendors and feed the pertinent data into the SLM process. As service levels
need to be changed, IT may need to re-negotiate external contracts with
vendors and modify the UCs. Figure 1-4 illustrates the flow of customer,
internal, and external contracts.
Service catalog
The service catalog provides a place to document all services provided to the
customers and to record such details as key features, components, charges,
and dependencies for each service.
Chapter 1. Introduction to service level management 13

32. Customers
SLA SLA
IT Services Provider
Service 1 Service 2
IT Infrastructure
Underpinning
OLA
Contracts
Internal organization External organizations
Figure 1-4 SLM customer, internal, and external contracts
Service level objectives
SLOs define service levels that have been agreed to by parties that
negotiated SLAs which need to be monitored and reported. They include one
or more service level indicators (SLIs) presented in the business context. The
SLO defines the component of service and how it is being measured.
SLIs determine measurement metrics for SLM quantification. SLIs should
reflect user perspective such as pain points and priorities, service availability,
and responsiveness.
For example, the most common SLOs are availability and performance. A
service availability SLO may include the SLI measured in the percentage of
time that the service was in available state. A performance SLO may include
two SLIs: service responsiveness (response time) and completed work
(number of transactions).
An IT organization must use monitoring for measuring the actual results of
SLIs and reporting for communicating these results to business and IT
managers. The format, details, and period vary depending on the recipients of
reports. SLM can also include real-time information, alerting IT when results
approach or breach service levels are guaranteed by SLAs.
14 Service Level Management

33. Service improvement program
SLM is a continuous process that includes service level improvement and
SLM improvement activities. IT should never be satisfied with current level of
service even if it satisfies its obligations to customers.
IT should develop a service improvement program and document a service
quality plan. This plan should include how to maintain awareness of changing
business objectives, cost-effectively add new technology, improve daily
operations, and expand SLIs and reporting to match user perception of
service as much as possible.
1.3.3 People
The SLM process requires the involvement of people at various levels within
business and IT organizations. The request for service improvements often starts
with the head of a business unit or a senior executive who begins demanding
more consistent service and accountability from IT. IT management may respond
with tactical improvements but may be forced to implement the SLM program.
SLM is a collaborative effort. Its implementation includes a number of people in
dedicated or supporting roles. Responsibility for overall management of the SLM
program is most likely to be assigned to a senior IT executive.
IT may also assign a dedicated project manager and a dedicated service level
manager. The project manager is responsible for implementing the SLM project.
A service level manager is active throughout the entire implementation phase as
well as after the phase. This person also coordinates ongoing management and
improvement programs. In their effort, both the project manager and the service
level manager need support from line managers of IT and business groups.
The SLM team must include representatives from both business units and IT
service delivery and may require some assistance from consultants. However,
SLM is primarily an IT effort as it is IT who must handle the technical aspects of
the SLM implementation, deployment, and operation. The SLM program must
have an executive sponsor who provides funding for the program and is
ultimately responsible for the success of the SLM program.
For more details about the roles and responsibilities of the people involved in
implementing SLM, see 2.2.1, “Identifying roles and responsibilities” on page 26.
1.3.4 Tools
While developing the SLM plan, the IT organization must choose tools to enable
the SLM process that is being developed. Depending on the selected
measurement metrics and the service composition of related IT resources, these
Chapter 1. Introduction to service level management 15

34. tools support monitoring of the chosen service indicators and user experiences.
They also provide analytical capabilities and aggregation for reporting.
In addition, IT must organize the collected data and make it accessible to
everybody with a stake in the SLM process. Analytics and reporting must present
this data in a manner that aligns the service views of both IT and their customers,
allowing them to reconcile the customers’ perception of service with the service
levels delivered by IT.
IT wants to understand how resource performance and availability affects service
levels and what adjustments are needed to improve service. Customers want to
make sure that IT delivers availability and responsiveness to the critical
applications that they use for automating their business processes. When their
business process is impacted, they want IT to accurately report it so they can
impose the negotiated penalties on IT.
SLM is a hot topic, and many companies have made claims that their products
provide SLM solutions. Some products are specifically designed for SLM. Others
offer only aspects of monitoring capabilities but still market their products as SLM
solutions.
When implementing SLM, IT should choose the following tools to meet their
design specifications:
Monitoring tools to provide the measurement metrics they need to collect
Reporting tools that process the data being captured and satisfy all levels of
report recipients
Analytical tools that provide aggregation and analysis of the collected SLM
data in a manner that offers fast recognition of business impact and proactive
response
Administration tools that improve the productivity of SLM operators and users
as well as provide the integration of monitoring, reporting, and analytical tools
This book introduces solutions provided by IBM, which include a wide range of
products that can monitor a variety of distributed and mainframe servers,
databases, transactions, networks, Web servers and end-user experiences.
In addition, IBM offers analytical products in SLM space that provide the real-time
integrated event console, event correlation, business service management
(BSM), and proactive SLM. All these products accept data from the majority of
today’s monitoring products.
16 Service Level Management

35. 1.4 Business service management approach to service
level management
The philosophy of managing services in a business context is receiving more
traction with IT organizations that are trying to improve relations with their
customers. These same organization are also trying to overcome historical
challenges such as customer perception and the increasing complexity of
technology. Understanding how shared infrastructure resources are being used
by business processes significantly improves the ability of business and IT
executives to negotiate, measure, and evaluate service contracts.
Many IT organizations are turning to BSM solutions to facilitate a
business-defined view of IT-delivered services. BSM solutions provide facilities
and analytics that enable IT to manage service levels with the business
consumer for a specific business process to ensure that the SLA associated with
this process is fulfilled.
Why business service management?
Earlier this chapter introduced SLM as the management of IT resources to
deliver the required service at the required level of quality. BSM allows IT to
incorporate business knowledge into the service management process and to
translate data from traditional infrastructure and application management tools
into business-level representations.
BSM relies on IT organizations that work with business units to map
resource-to-service relationships and organize them into structures that depict
and visualize the components of IT infrastructure as well as automate
components of the business process based on the knowledge of their
relationships. Accordingly, with BSM, IT management and business executives
can reconcile their perspective of IT performance. This is because BSM can
report both real-time status and historical service-level compliance for each
business function supported by IT.
What is business service management?
BSM is a service management application that aligns IT operations with business
processes. Therefore, it allows business functions to receive maximum leverage
from IT resource management.
BSM solutions enable real-time management of events and service levels based
on knowledge of their relationships to an IT service provided to a business entity
responsible for a business process.
BSM provides IT with a set of algorithms and visualizations that IT must
incorporate in its SLM processes. It is designed to display and report the service
Chapter 1. Introduction to service level management 17

36. delivery health and business impact of IT based on performance and availability
of IT resources. The visualization of BSM runs on federated event and monitoring
data as well as business and IT relationship data.
The four aspects of BSM are:
It consists of identifying the components of a business system.
It involves measuring the performance and availability of those components.
It ensures that the components are performing within SLOs.
It alerts to any deviation or potential deviation from SLOs.
The concepts behind BSM include:
Resources are components of IT infrastructure.
Business transaction is a group of IT resources supporting a particular IT
workload.
Business system is a group of resources that supports a business goal.
Business process is composed of some automated (IT services based) and
some manual steps.
When policy data or service level information is attached to a business
system, it turns into an IT service.
IT service can be perceived as a collection of IT resources that make up the
automated part of the business process.
1.4.1 Convergence of business service management and service level
management
With BSM, an IT organization gains insight into a business process. It can use
this insight to design SLM based on the aforementioned relationship structures
that we call business systems. A business system is a representation of a group of
diverse but interdependent enterprise resources that are used to deliver specific
business functionality.
Business systems allow flexible and automated arrangements of IT resources
into models of services that IT provides to automate business functions.
Together, they represent what we call the Business/IT knowledge base that is an
important element of the SLM methodology.
As a result of a joint effort to develop the Business/IT knowledge base, an IT
organization and business units have a framework for SLA that allows them to:
Identify all components of a service
Create SLA and OLA contracts based on business systems
Measure resource performance and availability by business systems
18 Service Level Management

37. Get service violation and trend alerts for any deviation or potential deviation
from the SLO
Ensure that services are performing within the SLO
The Business/IT knowledge base provides the foundation for BSM and SLAs. In
reality, BSM allows IT to decompose business processes into IT systems and
document the negotiated service levels in SLAs to be managed by BSM via
monitoring and analytics organized by business systems.
BSM accepts data from a variety of performance and event data sources that
monitor IT resources. The BSM analystics then consume this data to determine
business systems status and understand its business impact.
Figure 1-5 demonstrates that business systems are a cornerstone for
establishing service levels and managing IT resources based on business
objectives for IT services.
Underpinning Historical
SLA OLA
Contracts Reporting
Service Level Management
Service
Business IT Services
Business Services Business
Systems
Business
Systems
The Systems - databases The
Business - banking - web servers Technology
- trading - banking application
- e-commerce - application support
Service - development
Service
Business
Business Business
Systems
Systems Systems
Business Systems Management
Incident
Contextual Real time
resolution Business views
alerting monitoring
prioritization
Figure 1-5 Business system organizes IT resources and other business systems
A successful SLM program that aims to solve user perception issues should
establish a common understanding between business units and an IT
organization on service delivery and quality of service measurements. As
outlined earlier, the BSM approach to SLM helps this effort by collecting business
knowledge and exposing the use of resources by services. This makes SLA
contracts and measurement metrics more meaningful to both IT and business
units.
Chapter 1. Introduction to service level management 19

38. 1.5 Improving service level management through
integration
SLM is the continuous process of measuring, reporting, and improving the quality
of agreed upon service that an IT organization provides to the business. This
requires that an IT organization clearly understands each service it provides, its
business importance and priority, who consumes this service and how, and the IT
resources are used. Such information is usually dispersed and requires a
significant effort from IT to obtain and organize it a meaningful way that can
expose business use IT resources.
As demonstrated earlier, you can use BSM to compose and refine services from
related resource and business systems objects.
Service compositions defined by BSM allow IT to design SLAs and service level
measurement criteria in an integrated manner and provide:
Improved effectiveness of SLAs
When a IT organization uses the same definitions of services for aggregating
monitored data, service management, and service evaluation, it can
significantly improve the effectiveness of SLAs and make investigations of
SLA violations more productive.
Improved effectiveness of communication
Through a set of federated monitoring data and views, IT can use service
compositions to effectively communicate with users (while developing and
reporting SLAs) and to prioritize management of incidents.
Figure 1-6 presents a high-level view of integrating monitoring, service
management, and service evaluation around service compositions.
Management of IT resources within the context of the business services they
provide includes:
Automatic discovery of IT resources and their relationships
Automation for constructing services and business systems
Detections of incidents for IT resources in a service context
Determination of service status and business impact of incidents
Warehousing of historical data for IT resources and services
Service level evaluation and alerting in service context
Reporting service health and service level compliance with SLAs
20 Service Level Management

39. Business Service
Service Level
Management Management
- Business Systems - SLA
- Services - OLA
- Contracts
Service Management Service Evaluation
Measurement
Metrics
Business/IT Knowledge Base
Monitoring
Service Service
Composition Delivery
Business Business
Applications Infrastructure
Process Knowledge
The Business Information Technology
Requirements
Figure 1-6 Using business knowledge for managing IT services
Large enterprise IT environments deploy many system management products to
operate their diverse resources. It is difficult to integrate data from such a variety
of data sources into the SLM process. BSM solutions meet this challenge by
accepting data from all major monitoring vendors. BSM then integrates this data
by supplying business analytics and automation that allow IT to define and
manage services throughout the life cycle of SLM.
Armed with business knowledge and negotiated service composition and
measurement metrics, an IT organization can design its business system
management, SLM, and monitoring processes to measure quality of service that
correlates with user perception. To improve acceptance, IT must continue to
Chapter 1. Introduction to service level management 21

40. refine the service composition and measurement metrics until they become
transparent to business units.
1.6 Scope of this book
As outlined in this chapter, there are many aspects to SLM. One of the main
objectives is to relate the definition of service to the perception of IT users and
business unit management. The quality of services delivered to these users is
judged according to users’ ability to use services effectively and cost-efficiently
when required by their job functions.
Although IT managers place a high priority on meeting this objective, the task of
reporting on quality of service that users accept as matching their experiences is
often hit and miss. The BSM approach (outlined earlier in this chapter) to SLM
offers significant improvements in this area by making business to IT
relationships more factual and transparent through several implementation steps.
The topics in this book are structured to guide you through analysis of SLM and
its planning aspects to detail implementation of BSM, SLM, and monitoring
integration approach using Tivoli products. They include a summary of
improvement opportunities for each topic. The remainder of this book is divided
into the following chapters:
Chapter 2, “General approach for implementing service level management”
on page 23, describes a generic approach for SLM implementation, following
the ITIL process improvement model as close as possible.
Chapter 3, “IBM Tivoli products that assist in service level management” on
page 53, provides an overview of the IBM Tivoli products that support SLM
processes.
Chapter 4, “Planning to implement service level management using Tivoli
products” on page 109, outlines the planning and implementation of SLM and
BSM through the integration of several IBM Tivoli products.
Chapter 5, “Case study scenario: IRBTrade Company” on page 197, provides
a test case of the SLM program implemented to manage the distributed
environment for a trading company.
Chapter 6, “Case study scenario: Greebas Bank” on page 315, provides a
test case of the SLM implementation of enterprise management (mainframe
and distributed) for a bank.
Appendix A, “Service management and the ITIL” on page 447, discusses the
various components and definitions behind Service Management in ITIL
terms. It is designed as a reference for Anyone involved in the SLM process.
22 Service Level Management

41. 2
Chapter 2. General approach for
implementing service
level management
Service level management (SLM) is an important initiative. It requires the
participation and support of many resources. A successful implementation has
an established business need, commitment from all those involved, and funding
to ensure adequate resources and tools for completion. It requires a strategy and
a flexible plan for negotiating, implementing, and maintaining service level
agreements (SLAs).
The typical motivation for SLM is the need to improve IT service delivery as
perceived by customers. In many cases, the team responsible for IT service
delivery does not have all the information required to meet the needs of the
business. As a result, IT delivers and reports on top quality service, while
business units experience service that is perceived to be of a low quality. SLM
provides a means to overcome this challenge, providing the many benefits
described in 1.2, “Service level management benefits” on page 7.
Executive management commitment for SLM is essential since the goal of
aligning IT and business requires an organization-wide commitment from both
business and IT representatives. It takes hard work and discipline to implement
SLM. Simply providing funding is not enough. Executive management can
© Copyright IBM Corp. 2004. All rights reserved. 23