amazon simple storage service (s3) - forewords3.amazonaws.com/quint.redwood/sd/itil sd...

Foreword

The strategies and content in this book are a result of experience and understanding of ITIL® and

the refresh of ITIL in July 2011. The evolution of the core principles and practices provided by the

framework provides the more holistic guidance needed for an industry that continues to mature

and develop at a rapid pace. We recognize, however, that many organizations and individuals who

have previously struggled with their adoption of the framework will continue to find challenges in

implementing ITIL as part of their approach for governance of IT service management practices.

This workbook’s primary purpose is to complement the accredited ITIL Service Design Program. This

book is not a replacement for completing the course.

Each process contains a summarized overview of key knowledge. These overviews are designed to

help you to reference the knowledge gained through the course.

We hope you find this book to be a useful tool in your educational library and wish you well in your IT

service management career!

ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

IT Infrastructure Library® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights

reserved

Copyright The Art of Service | Distributed by Quint Wellington Redwood | Accredited by PeopleCert

Notice of Rights

All rights reserved. No part of this book may be reproduced or transmitted in any form by any

means, electronic, mechanical, photocopying, recording, or otherwise without the prior written

permission of the publisher.

Notice of Liability

The information in this book is distributed on an “As Is” basis without warranty. While every

precaution has been taken in the preparation of the book, neither the author nor the publisher

shall have any liability to any person or entity with respect to any loss or damage caused or

alleged to be caused directly or indirectly by the instructions contained in this book or by the

products described in it.

Trademarks

Many of the designations used by manufacturers and sellers to distinguish their products are

claimed as trademarks. Where those designations appear in this book, and the publisher was

aware of a trademark claim, the designations appear as requested by the owner of the trademark.

All other product names and services identified throughout this book are used in editorial fashion

only and for the benefit of such companies with no intention of infringement of the trademark.

No such use, or the use of any trade name, is intended to convey endorsement or other affiliation

with this book.

Contents Foreword 1

1 ITIL Certification Pathway 16

1.1 Exam Specifics 17

1.2 Exam Prerequisites 17

1.3 Exam Hints 18

2 The Objective Tree 20

2.1 Study Notes 21

3 Introduction 22

4 IT Service Management 23

4.1 Benefits of ITSM 24

4.2 Business and IT Alignments 25

5 What is ITIL? 29

6 Core Concepts and Common Terminology 32

7 Common Terminology 36

7.1 What are Services? 36

7.1.1 Business Units and Service Units 38

7.1.2 Creating Service Value 40

7.1.3 Service Packages and Service Level Packages 42

7.1.4 Service Portfolios 46

7.2 Processes and Functions 48

7.2.1 Defining Processes 48

7.2.2 Defining Functions 51

7.2.3 Connecting Processes and Functions 53

8 Introduction to Service Design 56

8.1 Relationship to Service Lifecycle 56

8.2 Purpose and Objectives of Service Design 57

8.3 Scope of Service Design 57

8.4 Business Value of Service Design 58

8.5 Context of Service Design to Other Lifecycle Stages 59

8.5.1 Service Strategy 59

8.5.2 Service Transition 60

8.5.3 Service Operation 61

8.5.4 Continual Service Improvement 62

8.6 Service Design Inputs and Outputs 64

8.6.1 Service Design Package 66

8.7 Service Acceptance Criteria 68

8.8 Elearning Module 3 & Workbook Review Questions 72

9 Principles of Service Design 75

9.1 Holistic Service Design 75

9.1.1 General Service Design Requirements 77

9.1.2 The Four Ps 78

9.1.3 Service Composition 80

9.2 Design Aspects of Service 81

9.2.1 Service Solutions 82

9.2.2 Supporting Systems 87

9.2.3 Architectures 91

9.2.4 Processes 96

9.2.5 Measurement Systems and Metrics 99

9.3 Balanced Design 104

9.4 Requirements and Drivers 106

9.5 Design Activities 110

9.5.1 Inputs and Outputs of Service Design 110

9.5.2 Subsequent Design Activities 111

9.5.3 Design Constraints 113


9.7 Service-Oriented Architecture Principles 118

9.8 Service Design Models 119

9.8.1 Delivery Models and Strategies 121

9.8.2 Design and Development Approach 125


10 Processes of Service Design 129

10.1 Design Coordination 129

10.1.1 Purpose and Objectives 130

10.1.2 Scope 131

10.1.3 Value to Business 133

10.1.4 Policies, Principles, and Basic Concepts 134

10.1.5 Process Activities 136

10.1.6 Process Activities – Lifecycle 137

10.1.7 Process Activities – Individual Projects 140

10.1.8 Triggers, Inputs, and Outputs 142

10.1.9 Critical Success Factors and Key Performance Indicators 145

10.1.10 Challenges and Risks 146

10.1.11 Summary for Design Coordination 147


10.3 Service Catalog Management 153


10.3.2 Scope 154



10.3.5 Service Definitions 156





10.3.10 Summary of Service Catalog Management 163


10.5 Service Level Management 167

10.5.1 Scope 168





10.5.6 SLA Framework and Documentation 174

10.5.7 Service Monitoring and Reporting 178

10.5.8 Service Reviews and Other Reviews 181

10.5.9 In Cooperation with Business Relationship Management 184




10.5.13 Summary of Service Level Management 190


10.7 Availability Management 195


10.7.2 Scope 196



10.7.5 Process Activities – Reactive Availability Management 201

10.7.6 Process Activities – Proactive Availability Management 209




10.7.10 Summary of Availability Management 222


10.9 Capacity Management 227


10.9.2 Scope 228







10.9.9 Summary of Capacity Management 241


10.11 IT Service Continuity Management 245


10.11.2 Scope 246







10.11.9 Summary of IT Service Continuity Management 259

10.12 Module 11 & Workbook Review Questions 260

10.13 Information Security Management 263


10.13.2 Scope 264




10.13.6 Triggers, Inputs and Outputs 270



10.13.9 Summary for Information Security Management 274


10.15 Supplier Management 279


10.15.2 Scope 280


10.15.4 Policies, Principles and Basic Concepts 282





10.15.9 Summary of Supplier Management 290


11 Technology-Related Activities 294

11.1 Requirements Engineering 294

11.2 Data and Information Management 299

11.3 Application Management 301


12 Organizing for Service Design 309

12.1 Organizational Development 309

12.1.1 Stages of Organizational Development 310

12.2 Departmentalization of Organization 314

12.2.1 Functions 315

12.2.2 Service Design Structures 316

12.3 Organizational Design 317

12.4 Roles and Responsibilities 318

12.4.1 Service Owner 319

12.4.2 Process Owner 320

12.4.3 Process Manager 323

12.4.4 Other Roles in Service Design 330

13 Technology Considerations 334

13.1 Service Design Tools 334

13.2 Service Management Tools 337

13.2.1 Tool Selection 338

13.2.2 Tool Evaluation 339


14 Implementing Service Design 343

14.1 Implementing Service Design 344

14.1.1 How to Improve 345

14.1.2 Measuring Service Design 348

15 Challenges, Critical Success Factors, and Risks 350

15.1 Challenges for Service Design 350

15.2 Risks of Service Design 351

15.3 Critical Success Factors in Service Design 352

16 Answers to Elearning Module & Workbook Review Questions 354

17 Glossary 356

18 References 369

19 Index 370

As this itiL intermediAte Workbook is designed to help you memorize and understand the official ITIL terminology,

in addition to helping you to apply this theory in a practical scenario, many instances of formal definitions and

terminology have been quoted from the official core publications.

ALL GrAy, ITALIC texts Are from the five ITIL official lifecycle books (SS, SD, ST, SO, CSI) Copyright © AXELOS

Limited 2011. Reproduced under licence from AXELOS Limited. All rights reserved. ITALIC text is referenced to

corresponding book and page number.

ALL other texts Are bAsed on AXELOS material. ITIL® is a registered trade mark of AXELOS Limited, used under

permission of AXELOS Limited. All rights reserved. IT Infrastructure Library® is a registered trade mark of AXELOS

Limited, used under permission of AXELOS Limited. All rights reserved

16

1 ITIL Certification Pathway

Since July 2007, a new certification path was also released. This new path encompasses all

the new Programs, ending in the possible attainment of “Expert Status.” The figure below

demonstrates the possible pathways that you could take to achieve the Expert status. The 2011

update to ITIL made no significant changes to the certification path.

To achieve Expert status, you are required to gain a minimum of 22 points by completing various

ITIL programs:

• You must complete the Foundation Program (2 points).

• You must complete 15 credits minimum from the Foundation and Intermediate modules.

(3–4 points for each module).

• Optional: qualifications from earlier versions of ITIL and complementary qualifications can

also earned additional credits (0.5-3.5 points each).

• You must complete the Managing across the Lifecycle Program (5 points).

• You must process a balanced knowledge base across the ITIL Service Lifecycle.

The numbers on each program indicate the point value.

It is yet to be finalized how the “Advanced Level” can be achieved, but it is expected to be based

on demonstration of practical experience in ITIL and IT Service Management.

Chapter 1

17

1.1 Exam Specifics

The ITIL Intermediate Qualification Service Design exam has the following features:

• Multiple-choice exams.

• 90 minutes in length.

• 8 scenario-based questions.

• Passing mark is 70%.

• Closed book exam.

• Scaled Marking system:

Ř Most correct answers – 5 marks.

Ř Next – 3 marks.

Ř Next – 1 mark.

Ř 1 answer – 0 marks.

It is possible to do a paper- or a web-based exam. (Please check with your Accredited

Examination Center for more information on this.)

1.2 Exam Prerequisites

In order to sit the ITIL Intermediate SD Exam, you MUST have an ITIL V3 or 2011 Foundation

Certificate and completion of an accredited program from an ITIL-Accredited Training Provider.

1.3 Exam Hints

18


ITIL® SERVICE DESIGN INTERMEDIATE LIFECYCLE WORKBOOK

When it comes time to sit your exam, you need to do this through an accredited Authorized

Examination Center. You may have the option to do the exam as web- or paper-based. Either way,

you will be given a paper copy of the Scenarios. A good thing! (Especially if you are doing web-

based exam—do not waste time opening web versions of the scenario—use the paper ones.)

Do not be fooled by the “only 8 questions” concept. These questions are designed to test you—

not only your knowledge, but also your understanding and application of the theory. You have

90 minutes, which means roughly 11 minutes per question. Most questions come with their

own case study/scenario. You need to CAREFULLY read the scenario, then the question, then the

scenario again.

There are 4 possible answers—1 is totally WRONG! And usually it is obvious to see which that is. If

we do our math—you need 28/40 to pass. This means that if the answers are based on a 5/3/1/0

scale—you really cannot afford to get any 0 answers. You MUST get at least 2 × 5 mark answers

and the remaining averaging 3s (to get minimum of 28). So you DO need to know your stuff.

THINK Business! Remember, as “Techies,” we tend to get caught up in “our” IT world. The ITIL lifecycle and, in particular, ITSM is customer-centric… THINK THIS WAY when answering questions!

Know your content—know your order. This study guide gives you a solid revision approach to

this course—but does not cover ALL content (that’s why you do the course). Make sure you know

what makes up a policy/plan and the activities for each process, as well as who does what.

Case Study Hints:


19

a. Identify main process/concept being tested.

b. Identify the “issue/problem” faced within the scenario—there will always be one—your

role is to resolve that issue.

c. Once you have read the associated question, go back and identify/confirm that you are

on the right track.

Question Hints:

• The 4 possible answers will appear to be similar—you need to read the possible answers

carefully.

• Eliminate the most obvious “wrong answer.” Things to look for:

Ř Order of activities.

Ř Red herring activities.

Ř Wrong processes.

Ř Wrong description.

• From the remaining 3 responses, start to identify similarities/differences. This will help you

to eliminate the next response generally. The differences will be a hint that one of them is

incorrect—you have to decide which one.

• It is probable that the “most correct” response would have the correct order of activities/

descriptions and “just that little bit more.”

• DO NOT assume that the longest response is the most correct one.

• Expect a “phase” question. While most questions are obvious with what it is testing for (i.e.

process), you could expect to get a “big picture” question asking about Service Transition in

general—so make sure you understand your related phases.

20

2 The Objective Tree

This Objective Tree is a very useful tool for understanding and “tunneling” down into how ITSM

can contribute to achieving a corporate objective. This helps us to better understand how the

Service Lifecycle can contribute to achieving the Business objectives.

The aim of

Chapter 2

21

the Objective Tree is to walk down the tree to understand HOW each level of the organization is

assisted in achieving their objective by receiving support from the level below.

Once you get to the bottom, you then walk back up the tree, giving an example of WHY each

would be of benefit to the one above in achieving its objectives.

ITIL contributes in the darker IT aspects in providing quality IT Service Management.

2.1 Study Notes

The following study notes are broken down into the following topics:

• Introduction to Service Design.

• Service Design Principles.

• Service Design Processes.

• Technology-Related Activities of Service Design.

• Organizing for Service Design.

• Technology Considerations.

• Implementing Service Design.

• Challenges, Critical Success Factors and Risks.

Again, these study notes are not intended to replace an accredited ITIL Foundation or

Intermediate Qualification Program. These notes are supplementary and may not include EVERY

concept that may be tested.

22

3 Introduction

While often seen as a stepping stone into higher-level specialist roles in IT, operational support

plays a critical part in the quality of IT services being delivered in any organization supported

by technology. Many factors influence the success being experienced in operational support,

including customer expectations, staff turnover, the relative age and complexity of the

infrastructure, quality of communication, and knowledge-sharing practices, as well as the overall

quality of service management employed by the IT organization.

In light of this, this workbook aims to develop the reader’s knowledge and appreciation of the

practices for IT Service Management, with particular focus on those capabilities required for

Service Design (SD) in the modern IT environment. It also seeks to challenge some traditional

thinking of the role of IT support, including the measurement of its success. Rather than

focusing on a limited set of activities or Service Level Agreement (SLA) targets, organizations

are now beginning to focus on the value provided by IT support, specifically its impact on user

productivity and business-unit performance.

This comprehensive book is designed to complement the in-depth accredited ITIL Service Design

(SD) eLearning program and, together with your practical experience gained in the field, prepare

you for the corresponding examination. Assumptions are made by the authors that readers

already have some familiarity with IT and ITIL terminology and have already completed an ITIL

Foundation program

Chapter 3

23

4 IT Service Management

The term IT Service Management (ITSM) is used in many ways by different management

frameworks and organizations seeking governance and increased maturity of their IT

organization. Standard elements for most definitions of ITSM include:

• Description of the processes required to deliver and support IT services for customers.

• The purpose primarily being to deliver and support the technology or products needed by

the business to meet key organizational objectives or goals.

• Definition of roles and responsibilities for the people involved including IT staff, customers,

and other stakeholders.

• The management of external suppliers (partners) involved in the delivery and support of the

technology and products being delivered and supported by IT.

The combination of these elements provides the capabilities required for an IT organization to

deliver and support quality IT services that meet specific business needs and requirements.

The official ITIL definition of IT Service Management is found within the Service Design volume

on page 16, describing ITSM as “the implementation and management of quality IT services

that meet the needs of the business. IT service management is performed by IT service providers

through an appropriate mix of people, process, and information technology.” These organizational

capabilities are influenced by the needs and requirements of customers, the culture that exists

within the service organization, and the intangible nature of the output and intermediate

products of IT services.

Chapter 4

24



However, IT Service Management comprises more than just these capabilities alone. It is being

complemented by an industry of professional practice and wealth of knowledge, experience,

and skills. The ITIL framework has developed as a major source of good practice in Service

Management and is used by organizations worldwide to establish and improve their ITSM

practices.

4.1 Benefits of ITSM

While the benefits of applying IT Service Management practices vary depending on the

organization’s needs, some typical benefits include:

• Improved quality service provision.

• Cost-justifiable service quality.

• Services that meet business, customer, and user demands.

• Integrated centralized processes.

• Everyone knows their role and knows their responsibilities in service provision.

• Learning from previous experience.

• Demonstrable performance indicators.

It is important to consider the range of stakeholders who can benefit from improved ITSM

practices. These stakeholders can come from:

• Senior management.

• Business unit managers.

• Customers.

• End users.

• IT staff.

• Suppliers.


25

4.2 Business and IT Alignments

A central concept to keep in mind when discussing the benefits of IT Service Management

is the goal of business and IT alignment. When staff members of an IT organization have an

internal focus on the technology being delivered and supported, they lose sight of the actual

purpose and benefit that their efforts deliver to the business. A way in which to communicate

how IT supports the business is using Figure 4.A (on page 27) that demonstrates business and IT

alignment.

Figure 4.A divides an organization into a number of supporting layers that work toward meeting

a number of organizational goals. These layers are communicated by the following:

Term DefinitionOrganization What are the key strategic goals and objectives for

the organization? These objectives define who we are as an organization and where we want to be in the future.

CORE Business Processes These are represented by the repeatable business activities that produce desirable results for the business. Without these results, the organizational objectives defined above would not be supported or achieved.

IT Service Organization Defines the IT Services and supporting infrastructure that is required to enable the effective and efficient execution of the business processes above. IT Services are used by the business to facilitate and enhance outcomes, including improved efficiency of operations or ensuring accuracy in the records and information being managed.

26



Term DefinitionIT Service Management Made up by the repeatable, managed, and

controlled processes used by the IT department that enable quality and efficiency in the delivery and support of the IT Services above.

IT Technical Activities The actual technical activities required as part of the execution of the ITSM processes above. ITSM is utilized to ensure that any resources and effort spent performing the technical activities are optimized according to the greatest business need or reward. As these activities are technology specific (e.g. configuring application server), they will not be a focus of this book’s content.

Each layer within this structure is utilized to support the layer(s) above. At the same time, each

layer will, in some way, influence the layer below it. For example, a business process that is

required to be executed at all times without disruptions (e.g. emergency health services) would

result in highly resilient IT services—being implemented and supported by ITSM processes—

that reduce the risk and impact of disruptions occurring.


27

Figure 4.A – Business and IT Alignment

Example to illustrate business and IT alignment.

Business: A fashion store.

28



What are some of your organization’s objectives or strategic goals?

• We want to make a lot of money $$$!

• We want to have a good image and reputation.

What business processes aide in achieving those objectives?

• Retail, marketing, buying, procurement, HR, etc.

What IT services are these business processes dependent on?

• Web site, email, automatic procurement system for buying products, Point of Sale Services.

We have ITSM in order to make sure the IT services are:

• What we need (Service Level Management, Capacity Management, etc.).

• Available when we need it (Availability Mgt, Incident Mgt, etc.).

• Provisioned cost-effectively (Financial Mgt, Service Level Mgt).

If we do not manage the IT services appropriately, we cannot rely on these services to be

available when we need them. If this occurs, we cannot adequately support our business

processes effectively and efficiently. And, therefore, we cannot meet or support our overall

organization’s objectives.

29

5 What is ITIL?

ITIL stands for the Information Technology Infrastructure Library. ITIL is the international de

facto management framework describing best practices for IT Service Management. The

ITIL framework evolved from the UK government’s efforts during the 1980s to document

how successful organizations approached service management. By the early 1990s, they

had produced a large collection of books documenting the best practices for IT Service

Management. This library was eventually entitled the IT Infrastructure Library.

ITIL has gone through several evolutions and was most recently refreshed with the release of

the 2011 edition. Through these evolutions, the scope of practices documented has increased

in order to stay current with the continued maturity of the IT industry and meet the needs and

requirements of the ITSM professional community.

ITIL is only one of many sources for best practices, including those documented by:

• Public frameworks (ITIL, COBIT, CMMI, etc.).

• Standards (ISO 20000, BS 15000).

• Proprietary knowledge of organizations and individuals.

Generally, best practices are those formalized as a result of being successful in wide-industry

use.

Chapter 5

30



Figure 5.A – ITIL Framework

Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights

reserved.

Five volumes make up the IT Infrastructure Library:

• Service Strategy.

• Service Design.

• Service Transition.

• Service Operation.

• Continual Service Improvement.

Each volume provides the guidance necessary for an integrated approach and addresses

the direct impact of capabilities on a service provider’s performance. The structure of the

ITIL framework is that of the service lifecycle. It ensures organizations are able to leverage

capabilities in one area for learning and improvements in others. The framework is used to

provide structure, stability, and strength to service management capabilities with durable

principles, methods, and tools. This enables service providers to protect investments and

provide the necessary basis for measurement, learning, and improvement.


31

In addition to the core publications, there is also ITIL Complementary Guidance. This consists

of a complementary set of publications with guidance specific to industry sectors, organization

types, operating models, and technology architectures.

32

6 Core Concepts and Common Terminology

Critical to our ability to participate with and apply the concepts of the ITIL framework is the

need to be able to speak a common language with other IT staff, customers, end users, and

other involved stakeholders. This chapter documents the important common terminology

that is used throughout the ITIL framework. Most of these concepts and terms will not be new

to you, as you will be using them within your workplaces and/or remember them from your

foundation level study. This chapter is provided to help you revise the key terms and refresh

your memory of the definitions.

A full glossary has also been included at the back of this book for terminology and acronyms

that are covered under the ITIL 2011 SS syllabus. The following introductory glossary is provided

as an introduction to the common terms found within the framework. Throughout the book,

relevant terms will be discussed in more detail in the context of their corresponding process

and/ or lifecycle stage.

Chapter 6

33

Terminology ExplanationsBaselines (ITIL Continual Service Improvement) (ITIL Service Transition)

A snapshot that is used as a reference point. Many

snapshots may be taken and recorded over time but only

some will be used as baselines. For example:

• An ITSM baseline can be used as a starting point to

measure the effect of a service improvement plan.

• A performance baseline can be used to measure

changes in performance over the lifetime of an IT

service.

• A configuration baseline can be used as part of a

back- out plan to enable the IT infrastructure to be

restored to a known configuration if a change or

release fails.Business Case A decision support and planning tool that projects the likely

consequences of a business action. It provides justification

for a significant item of expenditure, includes information

about costs, benefits, options, issues, risks, and possible

problems.Capabilities The ability of an organization, person, process, application,

CI, or IT service to carry out an activity. Capabilities can

be described as the functions and processes utilized

to manage services. These are intangible assets of an

organization that cannot be purchased but must be

developed and matured over time.

The ITSM set of organizational capabilities aims to enable

the effective and efficient delivery of services to customers.External Service Provider Service provider that provides IT services to external

customers e.g. providing internet hosting solutions for

multiple customers

34



Terminology ExplanationsFunctions A team or group of people and the tools they use to carry

out one or more processes or activities. Functions hold units

of an organization responsible for specific outcomes. ITIL

Functions covered include:

• Service Desk.

• Technical Management.

• Application Management.

• IT Operations Management.Internal Service Providers An internal service provider that is embedded within a

business unit e.g., one IT organization within each of the

business units. The key factor is that the IT services provide

a source of competitive advantage in the market space

where the business exists.IT Service Management A set of specialized organizational capabilities for providing

value to customers in the form of services.

Process A set of coordinated activities combining and implementing

resources and capabilities in order to produce an outcome

and provide value to customers or stakeholders.

Processes are strategic assets when they create competitive

advantage and market differentiation. They may define

roles, responsibilities, tools, management controls, policies,

standards, guidelines, activities, and work instructions if

they are needed.


35

Terminology ExplanationsProcess Owner The person/role responsible for ensuring that the process

is fit for the desired purpose and is accountable for the

outputs of that process.

Example: The owner for the Availability Management

ProcessProcess Manager The person/role responsible for the operational

management of a process. There may be several managers

for the one process. They report to the Process Owner.Resources A generic term that includes IT infrastructure, people,

money, or anything else that might help to deliver an IT

service. Resources are also considered to be tangible assets

of an organization.Service A means of delivering value to customers by facilitating

outcomes that customers want to achieve without the

ownership of specific costs or risks. The role of the service

provider is to manage these costs and risks appropriately,

spreading them over multiple customers if possible.Service Owner The person/role accountable for the delivery of a specific

IT Service. They are responsible for continual improvement

and management of change affecting services under their

care.

Example: The owner of the Payroll Service.Shared Service Providers An internal service provider that provides shared IT service

to more than one business unit, e.g., one IT organization

to service all businesses in an umbrella organization. IT

Services for this provider do not normally provide a source

of competitive advantage but, instead, support effective and

efficient business processes across an organization.

36

7 Common Terminology

7.1 What are Services?

The concept of IT services, as opposed to IT components, is central to understanding the Service

Lifecycle and IT Service Management principles in general. It requires not just a learned set

of skills but also a way of thinking that often challenges the traditional instincts of IT workers

to focus on the individual components (typically the applications or hardware under their

care) that make up the IT infrastructure. The mindset requires, instead, an alternative outlook

to be maintained, with the focus being the service-oriented or end-to-end view of what their

organization actually provides to its customers.

The official definition of a service is “a means of delivering value to customers by facilitating

outcomes customers want to achieve without the ownership of specific costs or risks” (Service

Strategy, page 13). But what does this actually mean? The following analogy explains some of

the key concepts in a way that most (food lovers) will understand.

While most people do enjoy cooking, there are often times when they wish to enjoy quality

food without the time and effort required to prepare a meal. If they were to cook, they would

need to go to a grocery store, buy the ingredients, take these ingredients home, prepare and

cook the meal, set the table, and, of course, clean up the kitchen afterward. The alternative

is that they can go to a restaurant that delivers a service that provides them with the same

outcome (a nice meal) without the time, effort, and general fuss required if they were to cook it

Chapter 7

37

themselves.

Now consider how that person would identify the quality and value of that service being

provided. It is not just the quality of the food itself that will influence their perceptions, but also:

• The cleanliness of the restaurant.

• The friendliness and customer service skills of the waiters and other staff.

• The ambience of the restaurant (lighting, music, decorations, etc.).

• The time taken to receive the meal (and was it what they asked for?).

• Did they offer a choice of beverages?

If any one of these factors does not meet the person’s expectations, then ultimately, the

perceived quality and value delivered to them as a customer is negatively impacted.

Now, relate this to an IT staff member’s role in provisioning an IT Service. If they focus only

on the application or hardware elements provided and forget or ignore the importance of

the surrounding elements that make up the end-to-end service, just like in the example of

the restaurant, the customer experience and perceived quality and value will be negatively

impacted.

But if they take a service-oriented perspective, they also ensure that:

• Communication with customers and end users is effectively maintained.

• Appropriate resolution times are maintained for end-user and customer inquiries.

• Transparency and visibility of the IT organization and where money is being spent is

maintained.

• The IT organization works proactively to identify potential problems that should be rectified

or improvement actions that could be made.

38



To help clarify the relationship between IT services and the business, we need to look at the

concepts of Business Units and Service Units.

7.1.1 Business Units and Service Units

Figure 7.A – Business units


reserved.

A business unit is a bundle of assets with the purpose of creating value for customers in the

form of goods and services. The value received by the customer is paid for by the customer,

which, in turn, ensures that an adequate return on investment is obtained for the business


39

unit. The creation of value is dependent on the business unit’s investment of resources to

increase their capabilities in delivering services. The function of the service can vary from

simply providing resources to the customer to increasing the performance capabilities of

the customer’s business processes. The relationship between business unit and customer is

symbiotic and beneficial when value is created and returns on investment are generated.

Figure 7.B – Relationship between business units and service units


reserved.

Service units are like business units: a bundle of service assets that specialize in creating value in

the form of services. Services define the relationships between business units and service units.

Business units (customers) and service units (providers) can be part of the same organization or

can be from multiple independent organizations.

40



This relationship enables business units to focus on the outcomes provided by services, while

the service units focus on managing the costs and risks of providing the service, possibly by

spreading these costs and risks across more than one customer or business unit.

Figure 7.C – Balancing service potential against demand for services


reserved.

7.1.2 Creating Service Value

Perhaps, historically, both providers and customers have used price as the focal point

for communication and negotiation, but it is this path that ultimately leads to a negative

experience for both parties. One of the key mantras that exist for any modern service provider

(IT or otherwise) is that it is essential to clearly establish value before you can attach a price to

the services offered. This ensures a few key things:

• It avoids an apple-to-orange comparison, which usually occurs with a price focal point.

• It enables the service provider to distinguish their capabilities and differentiation from their

competitors.


41

• It clearly communicates to the customer what they can expect to receive as part of the

delivery service.

Providers of IT services need to take special appreciation of the concept of value creation and

communication, due to the many misunderstandings about technology on behalf of customers

(and poor communication with their IT providers). To support this need, one of the major

elements of the Service Strategy lifecycle is the creation of value through services and service

packages.

Figure 7.D – Creating service value


reserved.

42



Formula: Service Warranty + Service Utility = Service Value

Service Utility describes the positive effect on business processes, activities, objects, and tasks.

This could be the removal of constraints that improves performance or some other positive

effect that improves the outcomes managed and focused on by the customer and business. This

is generally summarized as being fit for purpose.

Service Warranty, on the other hand, describes how well these benefits are delivered to the

customer. It describes the service’s attributes, such as the availability, capacity, performance,

security, and continuity levels to be delivered by the provider. Importantly, the Service Utility

potential is only realized when the service is available with sufficient capacity and performance.

By describing both Service Utility and Service Warranty, it enables the provider to clearly

establish the value of the service, differentiate themselves from the competition, and, where

necessary, attach a meaningful price tag that has relevance to the customer and associated

market space.

7.1.3 Service Packages and Service Level Packages

To discuss service packages, service level packages, and how they are used to offer

choice and value to customers, we are going to use the example of the packages made

available by typical Internet Service Providers (ISPs).

As customers, we have a wide range of choice when looking for an ISP to provide broadband

internet. So, as a result, ISPs do need to work hard to attract customers by communicating the

value that they provide through their offerings. They also need to offer a wide range of choice

for customers, who have varying requirements and needs for their broadband internet service.


43

Figure 7.E – Service package example

A service package provides a detailed description of a package of bundled services available to

be delivered to customers. The contents of a service package includes:

• The core services provided.

• Any supporting services provided (often the excitement factors).

• The service level package.

44



Figure 7.F – Service level package example

Service level packages are effective in developing service packages with levels of utility and

warranty appropriate to the customer’s needs and in a cost-effective way.

• Availability and Capacity Levels.

• Continuity Measures.

• Security Levels.


45

So, for our ISP example, we can define a service package in the following way:

Figure 7.G – Service package example (ISP)

Most of the components of service packages and service level packages are reusable

components of the IT organization (many of which are services). Other components include

software, hardware, and other infrastructure elements. By providing service level packages

in this way, it reduces the cost and complexity of providing services while maintaining high

levels of customer satisfaction. In our example above, the ISP can easily create multiple service

packages with varying levels of Utility and Warranty provided in order to offer a wide range of

choice to customers and to distinguish themselves from their competition.

46



The use of service packages and service level packages enables service providers to avoid a

one- size-fits-all approach to IT services.

7.1.4 Service Portfolios

A service portfolio describes the provider’s services in terms of business value. They include the

complete set of services managed by a service provider. These portfolios are used to articulate

business needs and the service provider’s response to those needs. It is possible for a service

provider to have multiple service portfolios, depending on the customer groups that they

support.

• Includes the complete set of services managed by a service provider.

• Provides the information required to manage the entire lifecycle of all services.

Three categories of services defined in service portfolios:

• Service Pipeline (proposed or in development).

• Service Catalog (live or available for deployment).

• Retired Services (decommissioned services).


47

Figure 7.H – A service portfolio

Service portfolios have a much larger scope than Service Catalogs and are used to manage the

lifecycle of all services in order to maximize the value of IT Service Management to the business.

The portfolio should have the right mix of services in the pipeline and catalog to secure the

financial viability of the service provider. Just like a financial portfolio, we need to ensure the

balance between risk and benefit provided by the service portfolio.

48



The service portfolio uses the above information to provide informed responses to the

following strategic questions:

1. Why should a customer buy these services?

2. Why should they buy these services from us?

3. What are the pricing or chargeback models?

4. What are our strengths and weaknesses, priorities, and risk?

5. How will resources and capabilities be allocated?

7.2 Processes and Functions

7.2.1 Defining Processes

Processes can be defined as “a structured set of activities designed to accomplish a specific

objective” (Service Strategy, page 20). The function of a process is to create a defined output

from one or more definition. This is accomplished by defining the required actions, sequence

of those actions, and dependencies with each other and the defined inputs. When effective,

processes can improve the organization’s productivity. Some basic characteristics exist for each

process including:

• Measurability: The process is measured to monitor performance relative to cost, quality,

duration, and productivity.

• Specific results: A process’ purpose is in delivering a specific result as defined output or

• outcome of using the process, which must be clearly identifiable.

• Customers: The primary results of the process are defined and delivered to customers

and stakeholders, whether they are internal or external to the organization. Within this

context, the process and its results must meet the expectations of the customer.

• Responsiveness to specific triggers: Every process is invoked by a specific trigger. This is

the case whether the process is iterative like incident management or ongoing like event

management.


49

The process is managed and executed by three generic roles:

• Process Owner – ensures the process is fit for purpose. The role takes on the strategic and

tactical aspects of the process and ensures the process is aligned with the objectives of

service management and the customer.

• Process Manager – manages the operational aspects of the process on a daily basis. The

process manager role may be fulfilled by the same person fulfilling the process owner. In

larger organizations, a different process manager may be assigned to different business

units or customers.

• Process Practitioner – primary responsibilities include:

Ř Carrying out one or more activities of a process.

Ř Understanding how their role contributes to the overall delivery of service and creation of

value for the business.

Ř Working with other stakeholders, such as their manager, co-workers, users, and

customers, to ensure that their contributions are effective.

Ř Ensuring that inputs, outputs, and interfaces for their activities are correct.

Ř Creating or updating records to show that activities have been carried out correctly (Service

Strategy, page 332).

50



Figure 7.I – Generic process elements

Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights reserved.


51

The figure above describes the physical components of processes, which are tangible and,

therefore, typically get the most attention. The behavioral component, which is intangible, is

an underlying pattern so deeply embedded and recurrent that it is displayed by most members

of the organization and includes decision-making, communication, and learning processes.

Behavioral components have no independent existence apart from the work processes in which

they appear, but, at the same time, they greatly affect and impact the form, substance, and

character of activities and subsequent outputs by shaping how they are carried out. So, when

defining and designing processes, it is important to consider both the physical and behavioral

aspects that exist.

The ITIL processes covered within the the Service Design capability are:

• Design Coordination

• Service Catalogue Management

• Service Level Management

• Availability Management

• Capacity Management

• IT Service Continuity Management

• Information Security Management

• Supplier Management

7.2.2 Defining Functions

Functions refer to the logical grouping of roles and automated measures that execute a defined

process, an activity, or combination of both. The functions within Service Operation are needed

to manage the steady state operation IT environment. Just like in sports where each player will

have a specific role to play in the overall team strategy, IT functions define the different roles

and responsibilities required for the overall service delivery and support of IT services.

52



The ITIL functions covered within the ITSM capability are:

• Service Desk

• Technical Management

• IT Operations Management

• Applications Management

Figure 7.J – The ITIL functions from service operationCopyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights

reserved.

NOTE: These are logical functions and do not necessarily have to be performed by equivalent

organizational structure. This means that Technical and Application Management can be

organized in any combination and into any number of departments. The lower groupings (e.g.

Mainframe, Server) are examples of activities performed by Technical Management and are not

a suggested organizational structure.


53

7.2.3 Connecting Processes and Functions

It is often said that processes are perfect…..until people get involved. This saying comes from

failure when executing processes due to misunderstandings of the people involved and a lack

of clarity regarding the roles and responsibilities that exist.

A useful tool to assist the definition of the roles and responsibilities when designing processes is

the RACI Model. RACI stands for:

R—Responsibility (actually does the work for that activity but reports to the function or

position that has an “A” against it).

A—Accountability (is made accountable for ensuring that the action takes place, even if they

might not do it themselves). This role implies ownership.

C—Consult (advice/guidance/information can be gained from this function or position prior to

the action taking place).

I—Inform (the function or position that is told about the event after it has happened).

Figure 7.K – The RACI model

”Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights

reserved.”

54



A RACI Model is used to define the roles and responsibilities of the various functions in relation

to the activities of Incident Management.

General rules that exist:

• Only 1 “A” per row can be defined (ensures accountability, more than one “A” would confuse

this).

• At least 1 “R” per row must be defined (shows that actions are taking place), with more than

one being appropriate where there is shared responsibility.

In the example RACI model given, the service desk is both responsible and accountable for

ensuring that incidents are logged and classified, but not responsible for the subsequent

investigation, which, in this case, will be performed by other functional teams.

For the service lifecycle to be successful, an organization will need to clearly define the roles

and responsibilities required to undertake the processes and activities involved in each lifecycle

stage. These roles will need to be assigned to individuals, and an appropriate organizational

structure of teams, groups, or functions will need to be established and managed. These are

defined as follows:

• Group: A group is a set of people who share some common theme or interest, such as

performing the same activities regardless of the technology used or who they perform

the work for. These people may not even work in the same functional unit. For instance,

insurance agents from different companies can be a group. Groups are not used to define

a formal organizational structure, but can be used to logically contain people who must

follow a common process.

• Team: A team is a special type of group who share a common objective or purpose. They

may not be part of the same organization structure, but they are typically working together

and will build relationships with each other. Teams are useful in collaborating between

organizational structures or dealing with a temporary situation, such as a project or major


55

incident.

• Department: Formal organizational structures designed to perform several defined

activities on an ongoing basis. Departments will employ hierarchy involving managers

responsible for the execution of activities by department members, as well as the day-to-

day management of those department members.

• Division: A self-contained entity consisting of multiple departments grouped together by a

shared theme, such as geography

56

8 Introduction to Service Design

8.1 Relationship to Service Lifecycle

Service Design is the second stage of the ITIL Service Lifecycle. The other stages of the service

lifecycle are:

• Service Strategy.

• Service Transition.

• Service Operation.

• Continual Service Improvement.

Service Strategy is considered the hub of the service lifecycle, with design, transition, and

operation acting as spokes to the outer support ring of continual service improvement.

Each stage of the service lifecycle will influence and depend on the effectiveness of the stages;

thus creating an environment of checks and balances between the different aspects of IT

Service Management and ensure services provide value to the customer.

Chapter 8

57

8.2 Purpose and Objectives of Service Design

Service Design is responsible the overall blueprint of the IT services, as well as the underlying

policies, processes, practices necessary to realize the service provider’s strategy and

deliver services which ensure quality, satisfaction, and cost effectiveness against customer

requirements. Within this context, service design is initiated when:

• New or changed service requirements are identified.

• Services are not meeting objectives or facilitating customer outcomes.

• Customer is not satisfied with the delivered service.

• Cost of providing a service is greater than the value it is providing.

The primary objective of service design is to be able to design IT services that require minimal

improvement throughout their lifecycle. This objective does not release the service provider

from adopting practices in continual improvement, but to ensure the services are designed to

be stable over time and across changing trends for as long as possible. While service strategy

will focus on what the service provider should be doing to support the customer, the focus of

service design answers the question regarding, “how the solution should be to support the

customer effectively.

8.3 Scope of Service Design

The scope of Service Design can be seen from two perspectives:

1. The services delivered to the customer.

2. The underling management system used to ensure effective delivery of those services.

58



Service strategy establishes a high level account of the services to be created for the customer:

service design identifies and defines the underlying solution for these services. Strategy still

plays an important role in service design as it provides the guidelines and constraints for

how the solution should be shaped. A major deliverable to the design stage from strategy is

the service model; which service design will leverage to create an appropriate service design

package, service design model and service level agreements.

Service design is driven by several factors, specifically:

• Functional requirements.

• Service level requirements.

• Business benefits.

• Design constraints.

8.4 Business Value of Service Design

Service Design is a set of best practices for the organization to design services that deliver

quality, cost-efficiencies, and achieve stated objectives and outcomes effectively. Specific value

propositions for service design include:

• Reduction in the total cost of ownership over all aspects of services, processes, and

technology.

• Improvement is the quality of services to meet customer outcomes.

• Improvement in consistent delivery of services against strategy, architectures, and

constraints.

• Implementation of new or changed services can occur rapidly, at a lower cost, and with a

reduction in risk when leveraging and integrating with existing service designs.

• Service performance will improve when services are designed to meet specific performance

criteria and plans for capacity, availability, IT service continuity, and finances are leveraged.


59

• The inclusion of controls in service design improves the effectiveness of governance in IT.

• Process design efforts focusing on optimizing the quality and cost effectiveness will improve

the overall value of service management processes used to support and manage services.

• The inclusion of meaningful measurements and metrics in service design will improve

information gathering and decision-making.

• Alignment with strategies and values of the business and the customer can be improved,

ensure the delivery of services which meet all objectives.

8.5 Context of Service Design to Other Lifecycle Stages

Service design is an essential component of the service lifecycle as it establishes the blueprint

for how the service will be delivered and managed. The lifecycle stage ensures the service is

designed according to the rules, policies and plans developed in the strategy stage, but it also

establishes the specific processes, tools, and methodologies used to transition and operated

the service in subsequent lifecycle stages. Its contribution to continual service improvement is

providing a “design baseline” to use in evaluating the effectiveness of the services.

8.5.1 Service Strategy

Strategy is the center of the service lifecycle because it creates the rules, policies, and plans

which all other service management processes align. While the service lifecycle can be seen

as a sequence or cycle of activities, in reality, it is neither linear nor cyclical, but meshed. In

this context, service strategy has an impact on all other lifecycle stages, and how these stages

are engaged by the service provider will have a profound effect on meeting the objectives of

service strategy.

60



Service strategy is focused on the creation of value and begins the process by understanding

the opportunities and constraints associated with organization objectives and customer

requirements. The developed strategy will provide the boundaries regarding the services and

the systems managing those services. It is within this context that the service design operates,

by establishing how the services and management systems will develop and operate for the

purpose of fulfilling strategic objectives and customer outcomes.

Specifically, service strategy provides the following to service design:

• Principles of service management.

• Service management policies.

• Market spaces.

• Service portfolio.

• Service models.

• Service assets.

• Funding and accounting.

• Patterns of business activity and user profiles.

• Objectives and expectations.

• Risks.

• Service charters.

8.5.2 Service Transition

Service Transition is responsible for introducing new or changes services into the production

environment: this includes providing the necessary guidance for developing and improving

capabilities to support such introductions. Service Transition focuses on managing the “state”

of a service, while controlling the risks associated with its introduction to the production

environment. The lifecycle stage ensures the value identified in service strategy and encoded in

service design can be realized in service operation.


61

Service strategy will provide rules, policies and standards that must be honored within the

services flowing through transition, but also for how service transition proceeds. Service design

will “encode” these rules, policies and standards into the necessary service assets and plans for

transition. Most service transitions will be in the form of projects; and it will be necessary to

design a program and project management function which consistently meets its objectives

across all projects regardless of type, size, or purpose.

The Service Knowledge Management System is introduced in Service Transition and serves to

identify, gather, and disseminate information necessary to be effective in all service lifecycle

stages and decisions made in those stages. The design of the SKMS and its operation is a

product of the service design stage, but more importantly, the SKMS serves as a means of

capturing and disseminating information from service design to the other lifecycle stages as

well as making information from those stages to service design for purposes of understanding

the real world opportunities and struggles related to the design of services and management

systems.

8.5.3 Service Operation

Service Operation is responsible for managing services in a production state. This lifecycle stage

fulfills this responsibility according to how the service is designed, as well as how the underlying

management system is designed. The responsibility involves:

• Providingguidanceonachievingandimprovingserviceeffectivenessandefficiency.

• Providingsupportofservicestodeliverexpectedvaluetothecustomer,users,andthe

service provider.

62



The design created within the Service Design stage has an opportunity to create the expected

value within the Service Operation stage. The value of the service will never be realized until it is

available to the customer in an operational state, but this value is a result of understanding how

every component of the service interacts in order to create that value. Service design encodes

the necessary configurations, controls, interfaces, and operations for each service.

The overall purpose of service operation is to ensure value from a service is being created as

established by the service strategy, within the constructs and constraints define by the service

design.

In this context, Service Operation must have the capabilities and resources to:

• Maintain service stability.

• Allow for changes in design, scale, scope, and service levels.

• Respond proactively and reactively to changes.

• Making decisions relative to:

Ř Service availability;

Ř Demand on those services;

Ř Capacity utilization;

Ř Scheduling; and

Ř Resolution/avoidance of service incidents and problems.

8.5.4 Continual Service Improvement

Continual Service Improvement provides guidance on the creation and maintenance of value

through better capabilities in service strategy, design, transition, and operations. Continual

Service Improvement leverages the knowledge and best practices of quality management,

change management, and capability improvement.


63

In theory, the better the organization is on creating and communicating strategy, the more

mature and competitive the organization will be. Likewise, the better the organization is at

designing, developing, deploying, and managing services, the more likely the organization

will fulfill their strategic objectives. Both these situations are made possible through continual

improvement.

Continual Service Improvement can be used to achieve incremental and large-scale

improvements to:

• Service quality.

• Operational efficiency.

• Business continuity.

• Investment return.

Continual Service Improvement provides guidance on:

• The improvement of services.

• The improvement of capabilities and resources to each of the service lifecycle stages.

64



8.6 Service Design Inputs and Outputs

The following inputs to service design are expected from the various service lifecycle stages:

• Service strategy:

Ř Vision.

Ř Mission.

Ř Service portfolio.

Ř Strategy and strategic plans.

Ř Priorities.

Ř Service charters.

Ř Service packages.

Ř Financial information and budgets.

Ř Pattern of business activity and user profiles.

Ř Service models.

• Service transition:

Ř Service catalog updates.

Ř Feedback on service design and service design packages.

Ř Input and feedback to transition plans.

Ř Response to RFCs.

Ř Knowledge and information contained in the SKMS and CMS.

Ř Evaluation reports.

Ř Identified design errors.

• Service operations:

Ř Operational requirements.

Ř Performance information.

Ř RFCs.

Ř Incident and problem records.

• Continual service improvement:

Ř Customer- and user-satisfaction survey results.

Ř Input to design requirements.


65

Ř Data requirements for metrics, KPIs, and CSFs.

Ř Service reports.

Ř Feedback on service design packages.

Ř RFCs for improvements.

The following outputs are expected from service design to the other service lifecycle stages:

• Service strategy:

Ř Input to business cases and service portfolio.

Ř Service design packages.

Ř Updated service models.

Ř Service portfolio updates.

Ř Financial estimates and reports.

Ř Design-related information in SKMS.

Ř Designs for service strategy processes and procedures.

• Service transition:

Ř Service catalog.

Ř Service design packages, containing:

■ Details of utility and warranty.

■ Acceptance criteria.

■ Service models.

■ Designs and interface specifications.

■ Transition plans.

■ Operation plans and procedures.

Ř RFCs regarding transition or deployment of new or changed services.

Ř Input to change evaluation and CAB meetings.

Ř Designs for service transitions processes and procedures.

Ř SLAs, OLAs and underpinning contracts.

• Service operation:

Ř Service catalog.

Ř Service design package, containing:

66



■ Details of utility and warranty.

■ Operations plans and procedures.

■ Recovery procedures.

Ř Knowledge and information in the SKMS.

Ř Vital business functions.

Ř Hardware/software maintenance requirements.

Ř Designs for service operation processes and procedures SLAs, OLAs and underpinning

contracts.

Ř Security policies.

• Continual Service Improvement:

Ř Service catalog.

Ř Service design packages.

Ř Knowledge and information in the SKMS.

Ř Achievements against metrics, KPIs, and CSFs.

Ř Design of services, measurements, processes, infrastructure, and systems.

Ř Design for continual service improvement process and procedures.

Ř Improvement opportunities logged into CSI register

8.6.1 Service Design Package

The major deliverable of any design effort, whether a new service or change to an existing service,

is the service design package (SDP). The SDP is handed to the service transition lifecycle stage and

contains details regarding all aspects of the service and its requirements. The service design package

contains requirements for three major areas:

• Service requirements – basic requirements for the service from the business and the

customer.

• Transition requirements – the conditions and constraints on transitioning the service.

• Operational requirements – the conditions and constraints associated with service

operation and maintenance.


67

The specific contents of the service design package include:

• Business requirements.

• Service applicability.

• Service contacts.

• Service functional requirements.

• Service level requirements.

• Service and operational management requirements.

• Service design and topology.

• Organizational readiness assessment.

• Service program for service lifecycle, including:

Ř Management, coordination and integration with any other projects, activities, services or

processes.

Ř Management of risks and issues.

Ř Scope, objectives and components of the service.

Ř Skills, competencies, roles and responsibilities.

Ř Required processes.

Ř Interfaces and dependencies with other services.

Ř Management of required teams, resources, tools, technology, budgets, and facilities.

Ř Management of contracts and suppliers.

Ř Progress reports, reviews and revision of program and plans.

Ř Communication plans.

Ř Training plans

Ř Timescales, deliverables, targets, and quality targets for each stage.

• Service transition plan, including:

Ř Policies, plans and requirements for builds.

Ř Policies, plans and requirements for testing.

Ř Policies, plans and requirements for release and deployment.

• Service operational plan, including:

Ř Management and planning for interfaces and dependencies.

Ř Events, reports and service issues.

Ř Final service acceptance.

68



• Service acceptance criteria.

8.7 Service Acceptance Criteria

The goal of service management is to ensure that each service can deliver the functionality and

quality expected of it, and that the provider can deliver the service to the customer when deployed.

This goal is fulfilled though proper design of the service, but at some point, the design must be

verified and accepted. The service acceptance criterion is the means by which the service design is

validated and approval is granted to move the service through the subsequent lifecycle stages.

The fulfillment of the criteria is the responsibility of one or more service management processes or

functions within the service provider organization. Examples of service acceptance criteria include

(based on process responsibility) the items listed below.

NOTE: Some criteria will be duplicated because responsibility is shared between multiple processes:

• Change Management

Ř Has the final acceptance criteria been agreed with by all concerned parties?

Ř Has the “go-live” date and the guarantee period been agreed with by all concerned

parties?

Ř Has the deployment project and schedule been documented, agreed and published to

all affected parties?

Ř Have all requests for change and release records been authorized and updated?

• Service Level Management

Ř Has the final acceptance criteria been agreed with by all concerned parties?

Ř Has the “go-live” date and the guarantee period been agreed with by all concerned

parties?

Ř Has the service level agreement/service level requirements been reviewed, revised and


69

agreed by all concerned parties?

Ř Has the service been entered/updated in the service catalog/portfolio within the

configuration management system?

Ř Have all customers and other stakeholders been identified and recorded in the CMS?

Ř Can all SLA/SLR targets be monitored, measured, reported and reviewed, including

availability and performance?

• Incident Management

Ř Has the deployment project and schedule been documented, agreed and published to

all affected parties?

Ř Have incident and problem categories and processes been reviewed and revised for the

new service, together with any known errors and deficiencies?

Ř Has technical support documentation been provided and accepted by incident, problem

and all IT support teams?

• Service Asset and Configuration Management

Ř Has the service been entered/updated in the service catalog/portfolio within the

configuration management system and relationships established for all supporting

components?

Ř Have software licenses been purchased or reallocated licenses used?

Ř Have all hardware components been recorded in the CMS?

Ř Have all software components been recorded in the definitive media library with details

recorded in the CMS?

Ř Have all service, SLA, SLR, OLA and contract details, as well as all application and

infrastructure component details, been entered in the CMS?

• Business Relationship Management

Ř Have all customers and other stakeholders been identified and recorded in the CMS?

• IT Service Continuity Management

Ř Have all operational risks associated with running the new service been assessed and

mitigation actions completed?

Ř Have contingency and fail-over measures been successfully tested and added to the

overall resilience test schedule?

Ř Have all operational processes, schedules and procedures been agreed, tested,

70



documented and accepted?

• Availability Management

Ř Have all operational risks associated with running the new service been assessed and

mitigation actions completed?

Ř Have contingency and fail-over measures been successfully tested and added to the

overall resilience test schedule?

Ř Can all SLA/SLR targets be monitored, measured, reported and reviewed, including

availability and performance?

• Capacity Management

Ř Can all workload characteristics, performance and capacity targets be measured and

incorporated into capacity plans?

• Problem Management

Ř Have incident and problem categories and processes been reviewed and revised for the

new service, together with any known errors and deficiencies?

Ř Has technical support documentation been provided and accepted by incident, problem

and all IT support teams?

• Request Fulfillment

Ř Have all users been identified/approved and their appropriate accounts created for

them?

• Information Security Management

Ř Have all security checks and tests been successfully completed?

• Financial Management for IT Services

Ř Have all ongoing operational workloads and costs been identified and approved?

Ř Are all services and component operational costs understood and incorporated into

financial processes and the cost model?

• Service Validation and Testing

Ř Have all test plans been successfully completed?

• Release and Deployment Management

Ř Have all maintenance and upgrade plans been agreed, with release policies, frequencies

and mechanisms?

• Supplier Management

o Have all new suppliers been identified and appropriate contracts drawn up and agreed?


71

• Project Management

Ř Have all support arrangements between reviewed and revised?

Ř Have all service, SLA, SLR, OLA and contract details, as well as all application and

infrastructure component details, been entered in the CMS?

Ř Have all users been trained, and has user documentation been accepted and supplied to

all users?

Ř Are all relationships, interfaces and dependencies with internal and external systems and

services documented, agreed and supported?

Ř Have appropriate business managers signed off acceptance of the new or changed

service?

• Systems Management and Operations

Ř Are appropriate monitoring and measurement tools and procedures in place to monitor

the new service?

Ř Have all ongoing operational workloads and costs been identified and approved?

Ř Have all operational processes, schedules and procedures been agreed, tested,

documented and accepted?

Ř Have all batch jobs and printing requirements been agreed, tested, documented and

accepted?

72



8.8 Elearning Module 3 & Workbook Review Questions

1. Service Design comes after what stage of the service lifecycle?

A. Service Strategy

B. Service Transition

C. Service Operation

D. Continual Service Improvement

2. What is the overall objective of service design?

A. To create appropriate IT practices, processes and policies

B. To realize the service provider’s strategy

C. To meet the customer’s requirements, needs and outcomes through properly

designed services

D. To design IT services which require minimal improvement throughout the service

lifecycle.

3. Which of the following statements best describes the scope of service design?

A. The creation and proliferation of the service design package

B. The design of services to be delivered to the customer and the underlying

management system to ensure proper delivery

C. The design and delivery of functional, service level, and business requirements

D. The development and testing of key technology concerns in infrastructure,

environment, information and staff

4. When does the responsibility of service design end?

A. When the service design package is completed and handled to service transition

B. When the service is deployed into its operational state

C. Throughout the entire service lifecycle and eventual retirement of a service

D. When senior management has allocated design resources to another project


73

5. Which of the following is not an aspect of service design?

A. New services

B. Changed services

C. Management processes

D. Business strategy

6. Which of the following is not a direct benefit of service design?

A. Customer satisfaction

B. Improved service quality

C. Reduced total cost of ownership

D. Improved IT governance

7. Which of the following is not provided to service design by the activities of service strategy?

A. Service models

B. Configuration management system

C. Service charters

D. Service portfolio

8. What is the most useful output of Service Transition in terms of capturing and disseminating

information and feedback about service designs?

A. Known problem database


C. Service knowledge management system

D. Availability management information system

9. In what service lifecycle stage is the design of a service fully realized?

A. Service strategy

B. Service transition

C. Service operation

D. Continual service improvement

74



10. Which of the following is not a service design process?

A. Availability Management

B. Change Management

C. Service Level Management

D. Supplier Management

75

9 Principles of Service Design

An IT service strategy is a plan, or a set of planning activities, designed to define how the service

provider will achieve the outcomes of its customers though the development and delivery of

IT services. The service strategy will typically be included in the IT strategy of the business or

customer, which focuses on how technology will be used to meet business outcomes.

In the above statements, technology is perceived more as a product, while service is perceived

as a method; therefore, an IT strategy will define how the products will be used, while the IT

service strategy will define how value will be delivered. The definition of service enforces this

value context: a service is “a means of delivering value to customer by facilitating outcomes

customers what to achieve without the ownership of specific costs and risks.”

Strategy often relies on theory, or mental models, to create the necessary plan(s) for achieving

objectives and outcomes. Guiding principles provide the criteria for “good”strategy within an

organization. These principles provide the foundation for creating vision, goals, and objectives.

9.1 Holistic Service Design

The Merriam-Webster definition of holistic is “relating to or concerned with complete systems

rather than with individual parts.” From an IT perspective, understanding this definition is

essential for designing and managing the different components of a service. Each component

of a service, whether it is hardware, software, policy, person, or control, can be designed and

Chapter 9

76



operated independently from each other; however, it isn’t until all the components are brought

together that value can be fully realized.

In service strategy, the concept of a value chain is introduced; where value is added and

strengthened with each step of the business process. Within the context of holistic service

design, every component used to support each step of the process is carefully designed and

integrated with the other components to fully realize he intended value in the chain.

The structure of a service is represented by the functional and performance elements as

described by utility and warranty requirements; however, holistic service design expands

its scope to consider the management and operational elements necessary to ensure the

development and delivery of the service. The specific aspects of service design include:

• Service solution.

• Management systems and tools.

• Architectures.

• Processes.

• Measurement methods and metrics.

Holistic service design is useful in identifying the push and pull of different service components

on the other components of the service. In essence, the relationships, interfaces and

dependencies between different components become intentional and designed. As a result, a

change on one component has the potential to impact other components used in the service.

The level of impact is based on the nature and size of the change: a ripple effect can be created

showing how a seemingly innocuous change can impact a component far removed from the

original source of the change.


77

An argument can be made that every change deserves a significant effort in service design

to ensure the change is properly designed and the impact on related components can be

minimized or controlled. Unfortunately, the comprehensive nature of holistic service design

can lead to considerable commitment for resources, investment, and time: eventually

overshadowing the benefits and value of a particular change. Therefore, it is essential for the

service provider (or business) to what level of design activity is expected for each category

of change and to ensure that every change, at least, be assessed to determine what design

activities should be performed.

9.1.1 General Service Design Requirements

For every service or IT system, some basic requirements are typically expected in its design.

The general direction of the design should benefit the business of the service provider and the

needs of the customer. In this context, these basic requirements include that IT services are:

• Business- and customer-oriented, focused, and driven.

• Cost-effective.

• Compliant to customer’s security requirements.

• Flexible and adaptable, while consistently providing the necessary functionality.

• Able to adapt to changes in type, volume, and rate of demand.

• Supported in continuous operation.

• Managed and operated to an acceptable level of risk.

• Responsive.

To meet these requirements, services and systems must be planned, designed, implemented

and managed appropriately. This begins for fully understanding (and communicating) the

important of service design in achieving quality and its fundamental function of service

management. The capability of service design should be continually reviewed and improved by

the organization.

78



9.1.2 The Four Ps

The design of services and systems, including the practices of service design, is a practice in

understanding, preparing, planning and utilizing the four Ps:

• People.

• Processes.

• Products (services, technology and tools).

• Partners (suppliers, manufacturers and vendors).

The focus on services is insufficient holistically: the overriding focus should be on the

implementation and management of ITSM as a practice. While producing plans, designs,

architectures and policies is expected, the intentions and achievements in service design are

useless if those designs are not made available to interested parties, agreed, distributed and

actively used.

Service design is engaged early in the service lifecycle and influences every stage of the

lifecycle. Here are some specific examples of how service design is incorporated in the service

lifecycle:

• New service solutions are added to the service portfolio in the concept phase and the

portfolio is updated continuously to reflect current status of the service though its lifecycle.

• Service level requirements (SLRs) should be identified and understood as part of the initial

analysis for the service or system.

• New or changed requirements from the customer must be evaluated by existing processes

and functions against current resources and capabilities to ensure those requirements can

be met.

• Financial Management for IT services will be engaged when new infrastructure is required

for new services or expansion of existing services.

• Results of business impact analysis and risk assessments are used in several processes and

should be conducted as early as possible: the processes include IT continuity, availability,

capacity, and security.


79

• The introduction of new services or changes in existing service should be communicated

early to service desk to ensure proper preparation and training of all staff and, potentially,

customers.

• The introduction of new services or changes in existing service should be communicated

early to technical, application, and operations management functions to ensure proper

planning for effective operational support of the service.

• Transition should begin planning implementation and build activities into the change

schedule based on design specifications.

• Procurement of products and services from third party vendors requires engagement of the

supplier management process.

Throughout the service lifecycle, people are expected to execute processes using and

generating products while interacting and collaborating with partners. Each of the service

design activities listed above is an example of this expectation to some extent. It is important

to realize that not only is service design incorporated into the different lifecycle stages, but

service design is also responsible for establishing how the activities of each lifecycle stage are

performed in terms of people, processes, products and partnerships.

Imagine designing an automobile without designing the infrastructure to drive on. Without the

underlying system of roads and highways, most automobiles would not perform as expected.

The same is true with IT services: without the underlying infrastructure and management

system, the services will not perform as expected.

80



9.1.3 Service Composition

The components of a service can be generalized in terms of:

• Utility – what the service does.

• Warranty – how the service behaves.

• Assets – the resources and capabilities required to support and deliver the service.

A holistic service design requires that several perspectives to be taken when considering these

components. These perspectives include:

• Business service management – the business processes and services supported by IT and

owned by the business or customer of the IT service.

• IT service management – the management system(s) used to manage, deliver, and support

IT services.

• IT service(s) – what the service provider delivers to the customer within the constraints of IT

service management and for the benefit of business service management.

The composition of a service will consist of the following:

• Business processes.

• Services.

• Policy, strategy, governance, and compliance.

• Service level agreements/requirements.

• Infrastructure (hardware).

• Environment (facilities).

• Data.

• Applications.

• Supporting services.

• Operational level agreements and underpinning contracts.

• Support teams.

• Suppliers.

• Service management processes.


81

9.2 Design Aspects of Service

The five aspects of service design include:

• Service solutions for new or changed services.

• Management information systems and tools.

• Technology architectures and management architectures.

• Processes.

• Measurement methods and metrics.

Ensuring that each aspect is considered in service design is ineffective without a clearly defined

direction for the effort. This direction comes in the form of desired business outcomes and

planned results. In short, each aspect of the service design must be consistent to achieve the

outcomes and results expected by the customer, the user and the business.

Design efforts not only consider on the components of the service, but also their eventual

transition and operation; specifically:

• Approaches taken and associated timescales.

• Organizational impact.

• Commercial, or financial, impact (funding, costs and budgets).

• Technical impact on infrastructure and personnel.

• Commercial justification assessment on existing business.

• Risk assessment, mitigation and management.

• Communication planning.

• Impact on existing contracts or agreements.

• Expected operational outcomes.

• Service design package.

• Service acceptance criteria.

82



9.2.1 Service Solutions

Service solutions specifically address the requirements of a new or changed service. Service

design considers the design of the solution as well as the formal and structured approach for

designing the solution. This approach is a vital component of the design process as it ensures

that each service is produced at the right cost, during the right timeframe and with the

appropriate and agreed utility and warranty.

While there is no single approach that guarantees the desired results for every service, there are

best practices to consider when approaching service design. The most commonly recognized

practice is iterative or incremental design: a method of evolving or improving the service design

to meet the changing needs of the business and the customer.

This iterative approach is sometimes the most practical approach to take for new markets

or implementations: consider the formal adoption of ITSM using ITIL. There are 26 service

management processes which are necessary to implement and manage nay number of services.

While some processes may already be established within the environment, it is unlikely that

they are matured; and it is unlikely that the organization has the resources and capabilities

to implement (or formalize) all 26 processes simultaneously. As a result, the organization

must prioritize what processes to focus on initially and work on the remaining processes in

increments. As the organization deploys each process into the environment, it cannot be

considered its final iteration, as each new process deployed may demand addition requirements

on it. In this situation, iterative changes are made to each process as new information is

obtained and requirements are discovered.


83

For most design efforts, activities will be completed as a project and a project team will be

assigned to manage and fulfill the requirements of the service. Though serviced design and

service transition are treated as different stages in the service lifecycle, they may be part of the

same project. In truth, there are typically two major phases in a project:

• Design and Development – this phase represents the design and transition activities relative

to a specific service and may be broken down into further project phases.

• Early Life Support – this phase represents the development completion and initial

deployment of the service into a live environment where both project and operation teams

have responsibilities towards the success of the service.

The roles and responsibilities regarding the design and development project are progressive

and will change according to the project schedule. Some organizations will have dedicated

transition teams comprised of designers, project managers, and subject matter experts;

however, every organization will want to engage operational staff in the design and

development of a service as early as possible. Towards the beginning of the project, the

abundance of responsibility will be on dedicated personnel and designers, with responsibilities

shifting towards operational personnel near the end of the project and into early life support.

This is appropriate since operational personnel must continue to fulfill their operational

responsibilities related to services already deployed in the live environment.

A design and development project has three major deliverables which signify a handover to

different service lifecycle stages.

The first major deliverable is the Service Design Package: the deliverable is produced in service

design and provided to service transition as a plan for the service in subsequent lifecycle stages.

84



The second deliverable is the actual service solution, based on the service design package

and deployed in the live environment. At the deployment of the service solution, the design

and development project technically ends as all deliverables have been completed; however,

the actual transition continues into early life support (for more information on the practices of

service transition and early life support, see the Service Transition Certification Kit).

A third deliverable is the service acceptance criteria which is initially created in the design

aspect of the project and expanded as the project progresses, to finally be used to ensure the

service meets requirements and strategic intent.

The design aspect of the design and development project can be seen in three parts:

• Documentation and agreement of business requirements.

• Design of service solution.

• Development of service solution.

Documentation of requirements encompasses a handover between service strategy and service

design. Because of this, the responsibilities of service strategy will typically continue until the

end of this phase and will deliver:

• Organization’s vision and mission.

• Service portfolio and customer requirements.

• Strategies and strategic plans.

• Priorities.

• Service charters.

• Financial information and budgets (design, transition, and operations).

• Patterns of business activity and user profiles.

• Service models.


85

In this phase, the development of the service acceptance criteria begins.

The documentation phase is initiated by a request for change in the formal change

management process. This process will play an important role in ensuring project objectives

are met and progress is communicated throughout the design and development process. The

documentation phase ends when the service is authorized for design: this is a change activity

and authority resides with the Change Advisory Board.

The design phase of the project is solely the responsibility of service design and focuses on the

development of the new or changed service’s design. During this phase, the service provider

should consider the following regarding service design (though some areas may be initially

considered in the previous stage):

• Analyzing business requirements.

• Reviewing existing IT services and infrastructure and producing alternative service solutions.

• Designing service solutions to new requirements including service components, specifically

documenting:

Ř Required functionality, facilities and/or features.

Ř Information regarding monitoring of service or process performance.

Ř Supported business processes, dependencies, priorities, criticality, impact, and delivered

benefits of the service.

Ř Service level requirements and service level targets.

Ř Required service measuring, reporting and review activities.

Ř Timescales and schedules.

Ř Planned outcomes from service and impact on existing services.

Ř Requirements for testing, including user acceptance testing (UAT).

Ř Responsibilities regarding managing test results.

Ř Requirements for integration into the overall service management system.

• Incorporating the contents of the SAC and required achievements into the initial design.

• Evaluating and costing alternative designs.

• Obtaining agreement on expenditures and budgets.

• Obtaining agreement on required timescales related to completion of service design,

86



development, build, testing, and deployment of the service.

• Re-evaluating and validating business benefits, including ROI.

• Obtaining agreement of preferred solution and planned outcomes and targets.

• Ensuring a balance exists between strategies, policies, plans, and architectural documents.

• Ensuring all governance and security controls are included in the service solution.

• Completing organization readiness assessment, including:

Ř The current capability and competency of the organization to deliver the service as

designed.

Ř The commercial impact of the service, including business benefits and projected costs of

service.

Ř The assessment and mitigation of risks associated with t new or changed service.

Ř The capability and maturity of the business to ensure the right processes, structure,

people, roles, responsibilities, and facilities are in place when the service is deployed.

Ř The capability and maturity of IT with regards to the environment, areas of technology,

organizational structure, roles and responsibilities, skills, knowledge and competencies,

IT processes and subsequent documentation, and IT management processes and

supporting tools.

Ř Supplier and supporting agreements.

Ř Completion of service design package.

The end of the design phase is authorization for development by the Change Advisory Board.

The development phase is responsible for the development of the service solution and will

begin early engagement of service transition. The completion of the service design package

is expected at the end of this phase and will be officially initiate the transition aspect of the

design and development project. However, change management still has a hand in controlling

progress and agreement has to be obtained to authorize the service for the subsequent build

and test phases. Once the SDP is delivered and accepted, the responsibilities of service design

end.


87

Each minor phase of the project may be monitored and constrained according to service level

requirements related to the design effort. As an organization matures in the design process,

changes to each phase may impact schedules, costs, and resources. For instance, the initial

phase of the project involved documentation and agreement of business requirements and

usually ends with the submission of the service charter. Some real performance measures may

be used to establish targets for this phase, such as:

• Time required to document the business requirements.

• Number of service charters produced.

• Number of rejections incurred.

• Number of approved service charters delayed because of lack of funding.

• Demonstration of ownership by service design personnel over the success of the phase.

9.2.2 Supporting Systems

Management information systems and tools are another aspect of service design to address.

Commonly perceived as the service management system, these systems and tools ensure

the information required to manage the services appropriately are gathered, organized and

available to all interested parties. Without these systems, the effectiveness of decisions would

be significantly hindered.

The most notable management information systems and tools include:

• Service portfolio.

• Service knowledge management system (SKMS).

• Configuration management system (CMS).

• Capacity management information system (CMIS).

• Availability management information system (AMIS).

• Security management information system (SMIS).

• Supplier and contract management information system (SCMIS).

88



The most critical system listed above is the service portfolio. Ideally, the service portfolio

should be incorporated into the SKMS and registered in the CMS as a database or structured

document. The service portfolio is responsible for articulating the needs of the business and the

organization’s response to those needs. The service portfolio has an important role in service

design as it contains information about every service delivered by the service provider and also

maintains the services current status in the organization. The recommended status options are:

• Requirements – outline requirements have been received from the business or IT for the

service.

• Definition – requirements are being assessed, defined and documented and the service

level requirements are being developed.

• Analysis – the requirements for the service are being analyzed and prioritized.

• Approved – the requirements have been finalized and authorized.

• Chartered – requirements are communicated and allocations of resources and funding has

been made.

• Design – the service and service components are being designed and procured.

• Development – the service and service components are being developed or harvested.

• Build – the service and service components are being built.

• Test – the service and service components are being tested.

• Release – the service and service components are being released into a live environment.

• Operational – the service and service components are operational.

• Retiring – the service is still being delivered to legacy customer, but is not available as a

service to new customers.

• Retired – the service and service components have been retired.

The service portfolio is designed to meet the needs of the business, by containing the details

of all services and their status. During the design phase, the organization should define clear

policies for the service portfolio and the progression of services through the portfolio that

accurately represents the service’s location within the service lifecycle.


89

The design of the service portfolio should consider:

• Unique identification of each version of the service to ensure accurate monitoring.

• Ensuring only one version of a service exists in each section of the service portfolio at any

given time: that is, a different version may exist in the pipeline, the catalog, and retired

services section.

• Newer versions will begin in the service pipeline.

• If two versions of the same service should exist in the same portfolio section, the

organization must define the rules governing the circumstances.

• Policies should be clearly and unambiguously defined regarding the conditions required for

a service status to be achieved.

• A service should be in the service pipeline from the requirements status to the chartered

status.

• A service should be in the service catalog from the chartered status to the operational

status.

• Clear policies should be created regarding transfer of services from pipeline to catalog to

retired sections of the portfolio.

• Responsibility and accountability should be clearly designated for all aspects of a service as

it moves through the service lifecycle.

The content of the service portfolio for each service should be:

• Service name.

• Service version.

• Service description.

• Service status.

• Service classification and criticality.

• Applications used.

• Data and/or data schema used.

• Business processes supported.

• Business owners.

• Business users.

90



• IT owners.

• Warranty level, SLAs, SLRs.

• Supporting services.

• Supporting resources.

• Dependent services.

• Supporting OLAs, contracts and agreements.

• Service costs.

• Service charges.

• Service revenue.

• Service metrics.

In integrating the different systems used to manage services, the design elements of the

service portfolio should be used in other management systems or define how those systems

will interact with the service portfolio. For instance, the service portfolio uniquely identifies

each version of a service within its contents; so the design of the configuration management

system, which is used to track and manage all configuration items in the environment, can

contain an attribute which identifies the service version supported by each configuration item.

The attribute can be restricted to only those choices generated in the service portfolio and

establishes a link between the service portfolio and the CMS. The reverse is also possible, an

attribute(s) defined within the CMS may be designed within the service portfolio: one such

attribute may be the performance measures of different configuration items used for a service:

the information can be rolled up and potentially reported within the constraints of the service

portfolio, thus creating a historical record regarding performance for each service.

The design approach used for the service portfolio and any other management information

system should be the same as the approach used in designing a service. This is to say that the

service portfolio and any other management system should be treated as an internal service

of the service provider; and therefore, should not be treated or managed differently from a

lifecycle perspective than a service designed specifically to support the customer(s).


91

9.2.3 Architectures

Service design is concerned with two types of architectures:

• Technology – typically associated with the services and the components used to deliver

those services

• Management – represents the components used to manage the effective delivery of quality

services.

Architecture is defined as the “structure of a system or IT service, including the relationships of

components to each other and to the environment they are in” (Service Design, page 388). The

term, system, is used in this sense generically to represent any collection of components

designed to complete a specific task.

Architectures can be used to define a variety of “collections,” including collections within other

collections. For instance, enterprise architecture represents the organization and design of the

enterprise overall and may contain several smaller architectures representing different aspects

of the enterprise, including:

• Business/Organization architecture.

• Service architecture.

• Application architecture.

• Data/information architecture.

• Environmental architecture.

• IT Infrastructure architecture:

Ř Management architecture.

Ř Product architecture.

92



Let’s put this into perspective using properties. Consider the construction of a house. Each

house is built upon an existing infrastructure designed by the local authorities. City planning

will provide directions for access to water, power, sewage, and the like. Each of these can be

considered a different architecture overlapping to provide necessary services to the house.

If the house is part of a development project, the developer may have a particular plan, or

architecture, in place which identifies standard features and several options to create unique

living spaces. Each house is constructed according to a blueprint, or established architecture.

Consider the kitchen and the need for particular appliances, such as stove and refrigerator. Each

appliance is designed according to the manufacturer’s architecture; the use of the appliance

must be consistent with this architecture. While most people may not think about it, a family’s

chores can be seen as a formal architecture as it shows how the different family members

interact with each other and the different systems and architectures existing in the house.

Architecture design is a method of developing and maintaining the policies, strategies,

architectures, designs, documents, plans and processes for deploying, operating, and improving

services. The method assesses the needs of each component of the architecture and reconciles

these needs when they are used in conjunction with the other services. If a family’s chore list

is treated as an architecture, some chores may be assigned based on age, safety, or maturity.

Some assignments may be performed by individuals while others must be performed as teams.

The expectation for completing a particular chore may require it to be performed during a

specific time of the day or on a particular day. In truth, the chore list is not the architecture,

but is developed based on an architecture comprised of the policies, strategies, plans and

procedures defined by the parents. The same can be seen for services or systems: they are not

architectures, but are developed based on applicable architectures.

Some considerations addressed in architecture design for IT are:

• IT infrastructure, environments, data, applications and external services.

• Balance among innovation, risk, and cost.

• Compliance with relevant architectural frameworks, strategies, policies, regulations, and


93

standards.

• Coordination between IT designers and planners, strategies, business designed, and

planners.

Given the scope of architectural design, there are at least three architectural roles who may

report to a senior enterprise architect:

• Business/organization architect – focuses on business models, business processes and

organizational design.

• Service architect – focuses on the service, data, and application architectures.

• IT infrastructure architect – focuses on the physical technology and infrastructure

components.

These roles may be separated in more refined roles, reside in different functions, or may

be combined as roles or in the organization: sometimes, these roles may reside outside of

the organization. Comparing these roles to our housing project, we can see an applicable

separation of relationships:

• Between household and neighborhood.

• Between household members, i.e. parent/child, siblings.

• Between internal components (appliances, furniture, etc.).

Architectures impact service design in the following manner:

• Service design must work within the agreed architecture framework(s) and standards.

• Service design will reuse assets created as part of the architectures.

• Service design should work with the three architect roles to maximize benefits from the

created architectures.

94



Architectures should be created in the following technology areas:

• Applications and systems software.

• Information, data and database (including security).

• Infrastructure:

Ř Central service, mainframe, distributed servers, file, and print.

Ř Data networks, wireless, Internet, intranet, and extranet systems.

Ř Converged network technologies, including voice networks.

Ř Client systems.

Ř Storage devices and networks.

Ř Document storage, handling, and management.

Ř Specialty technologies.

• Environmental systems and equipment.

Many technology architectures may be defined by the manufacturer of a product, but must be

expanded to show specific relationships within the organization’s environment which would

not be known to the manufacturer. Go back to our housing project. An appliance is based on a

technology architecture which establishes how the appliance should be used and performance

expectations. However, consider that one parent has talent in the kitchen and the other doesn’t.

The untalented parent may always make a mess when cooking on the gas stove or may not be

able to retrieve ice from the in-door ice dispensary. As a result of these issues, there are specific

rules, policies, and procedures in place within the household to minimize the impact of this

parent while maximizing the talents of the other. In a service environment, the specifications

of the product define the requirements for best use; however, there are times when conditions

require a change to make the product work best. The easiest example is cabling. If using coaxial

cable to connect two components of a system, the components should be within 100 feet of

each other, but what if they are not. Simply put, how systems and products are actually used in

an environment may be different from how systems and products are intended to be used by

the manufacturer and these deviations from specifications must be documented.


95

When considering management architectures, most service providers can take one of two

approaches:

• Select proprietary management architecture – a set of management products and

tools provided by a single source and designed to work together. Usually, a provider of

proprietary tools will support the greatest common denominator of customer needs,

meaning that the tool set will have its inherent strengths and weaknesses which may not

address a customer’s specific needs.

• Select “best of breed” architecture – a set of management products and tools from multiple

sources which are considered “best of breed.” The individual tools are considered the best in

what they do and operate independently of other tools, until the service provider starts to

integrate into a single comprehensive management solution. This may provide the better

solution overall, but is often more expensive and resource-intensive than a proprietary

solution.

Comprehensive management architectures will consider five areas:

• Business needs, requirements, processes, objectives, and goals.

• Scope, tasks and activities of the people managing the delivery and support of services.

• Processes and procedures used to manage IT services.

• Management and support tools required to manage the IT infrastructure.

• IT products and technology used to deliver the service to the right person, in the right plan

at the right time.

The application of management architectures should consider the following perspectives:

• Top-down – the architecture is deeply aligned with the needs and goals of the business.

• Bottom-up – the architecture is fully integrated with the tools and technology used within

the organization.

• End-to-end – the architecture is integrated with the processes and tools used to support the

service.

96



Integration of all IT areas is dependent on the use of a top-down perspective, specifically in

managing business processes and service quality. Too often this is not the case. For instance, a

departmental team has decided to formalize how they share knowledge between themselves

by developing an internal knowledge base. The result increases the competency across all

team members, improves consistency of service, increase customer satisfaction, increases

productivity, and reduces costs for the department. Because of the success of the knowledge

base, the team is looking to integrate it with several systems, some which are not owned and

controlled by the department.

This is a bottom-up approach to system development and the most likely challenge, especially

when integrating with other systems, is the proprietary condition of the knowledge base – as

more systems are integrated, the push to remove ownership of the knowledge base from the

initial department will increase, as well as the resistance from the same department. A better

situation would have the department team request a knowledge solution from the IT steering

committee or other authority. While the initial deployment may not involve system integration,

this authority would be capable of expanding the system’s scope without the ownership issues,

or replicate the knowledge solution for other departments.

9.2.4 Processes

A process is defined as “a structured set of activities designed to accomplish a specific objective”

(Service Design, page 63). Processes may be incorporated in a service solution or a management

system, but are treated separately because they define the interactions and expected behaviors

for a defined set of components. Every process is defined by the same set of attributes, at

minimum these attributes are:

• Inputs.

• Outputs.

• Activities.

• Measurements.


97

Additional attributes may include:

• Roles.

• Responsibilities.

• Tools.

• Management controls.

Processes exist whether they are documented or not. A trip to the store to get milk is a process,

with inputs consisting of money, means of travel, and stocked shelves. The activities include

traveling to the store, choosing milk from the refrigerator, paying for the milk and travelling

home. The output, of course, is the milk, but the quality of the milk may be a concern; such as

the expiration date, whether the milk remained cold traveling home, or even the type of milk

obtained. Most people will probably not document the process for getting milk, but it still

exists.

Documenting a process is necessary to control the process: to plan, regulate, and execute in an

effective, efficient and consistent manner. In an IT environment (or business), a documented

process will ensure the process can be repeated by multiple people or systems and become

manageable. Control over a process can be expressed in degrees: the most common expression

is process maturity. As a process matures, more control exists over the process and the

measurements and metrics related to the process are designed to manage the process at that

level of maturity. Our process for “getting milk” is not controlled at all and has little maturity.

However, the same process implemented by a hotel, school or other institution would have

more controls in place, as well as constraints.

A basic process description would detail what comes into the process (inputs), is processed

(activities), the outputs generated and the outcomes of the process (measurements). Most IT

processes revolve around some form of data processing. Every process is organized around a set

of objectives.

98



For instance, the change management process can be organized to:

• Control changes to the services, the service management system, and to components of the

services to ensure consistent and reliable delivery of services at all times.

• To mitigate the risks associated with change and minimize the impact of change on the

environment.

• To reduce the time required to identify, evaluate and approve changes related to services

and service components.

• To reduce the costs associated with change failures.

Each process is owned by a process owner who is accountable for the process meeting

its objectives and implementing the necessary improvements based on requirements. All

objectives must be defined in measureable terms and should demonstrate, when achieved, a

benefit to the business and underlying strategies and goals. Service design aids the process

owner by providing a standard process vocabulary, templates, and a means of discussion

integration with other process owners.

Quality is a product of process effectiveness, as outputs are produced in conformance to

operational norms. For instance, a quality product of the change management process is a

successfully deployed change which was approved, funded and scheduled. The operational

norm is that only authorized changes are made to the environment, the change is made

on time within the window allocated to them and the costs for making the change are

minimal. Measurements can be established to monitor the achievement of these norms and

the effectiveness of the process is based on these achievements as conveyed though the

measurements. Measurements can also monitor the efficiency of the process—that is, the

number of resources required to execute the process and produce an output.


99

The design of a process incorporates all the different attributes of the process, specifically:

• Inputs – what they are and where they are sourced, as well as the criteria for determining

quality.

• Activities – what is performed, how it is performed, by whom and using what tools,

methods, or aids, the required interfaces and policy constraints (regulations).

• Outputs – what is produced, where it goes, and the criteria for determining criteria.

• Measurements – how measurements are gathered, reported, and acted upon, relationship

to management (internal) controls, acceptable levels of effectiveness and efficiency.

The intent of service design is not to design the “perfect” process, but to design a process which

is practical and appropriate to the service provider.

The design of roles and responsibilities according to processes can be complex and tedious.

This aspect of service design will be covered more fully in the chapter, “Organizing for Service

Design.”

9.2.5 Measurement Systems and Metrics

Peter Drucker once stated, “If you can’t measure it then you can’t manage it.” The underlying

premise for this statement is that any service solution, management system, or process which

is designed and implemented without measurements is uncontrolled and unmanageable. As a

result, the final aspect of service design is measurement methods and metrics.

As with everything else, the design of measurements and metrics begin with business

objectives: that is, they should demonstrate achievement of business objectives. As services

and processes are designed, measurements and metrics should demonstrate the achievement

of objectives specific to those services and processes. In truth, measurements and metrics are

selected, rather than designed, as every aspect of a service or process can be measured: some

metrics are meaningless against the objectives being met and should not be formally measured.

100



The methods used in gathering, interpreting, and reporting measurements and metrics will

have a greater design element to them, as these are systems used by the organization for each

service and process.

Selected measurements should encourage the achievement of objectives or compliance

regarding behavior. Design of measurements should consider:

• Ensuring solutions provide the desired utility.

• Ensuring solutions provide the designed level of warranty.

• Ensuring solutions produce quality outputs the first time and meet expected targets for

activities.

• Ensuring solutions or outputs to not require “rework” or “add-ons” to meet quality

requirements.

• Ensuring solutions are effective and efficient from a business or customer perspective.

Process capability and performance can be measured using four types of metrics:

• Progress.

• Compliance.

• Effectiveness.

• Efficiency.

Let’s look at each of these metric types using the incident management process. Progress of

the process can be measured at two levels: the maturity of the process and the progress of

an individual instance through the process, specifically an incident. An individual instance is

reported, logged, escalated, managed, resolved, and closed. Each activity is defined by the

incident management process and applied equally to every incident reported. As an incident

is processed through the process, its status may change: this demonstrates progress. One

particular characteristic showing progress is whether the incident can be resolved by the initial

person exposed to the incident (Service Desk) or must be escalated to a more knowledgeable

person or group. The benefit of progress metrics is to show where in the process a person is at


101

and whether expectations up to that point have been met.

One defining characteristic of the incident management process is a service level agreement for

resolution time—the time allowed to resolve an incident. Resolution SLAs are typically based

on the priority and impact of the incident: so incidents involving critical business systems and

impacting multiple users will usually have a shorter resolution SLA then an incident involving

a single user on a non-critical system. Since resolution SLAs are created outside of the incident

management process, they are, in essence, a requirement of the process and any measurements

regarding the requirement is considered compliance metrics. Compliance can be measured

against policies, regulations, and standards. Because the process is a form of standardization,

the proper use of the process by the people is another compliance metric to be measured.

Effectiveness metrics focus on the quality of the output/outcomes generated by the process.

First Call Resolution is an effectiveness metrics which demonstrates the capabilities of the

Service Desk to resolve incidents without escalating them to second-level technical teams.

Customer satisfaction measurements can also be seen as effectiveness metrics because it

demonstrates the acceptance of resolutions by the customer. Effectiveness metrics will measure

the accuracy and correctness of the process to produce the “right result.”

Efficiency metrics are used to demonstrate the productivity of the process, including its speed,

throughput and resource utilization. The aforementioned resolution SLA and first call resolution

metrics can be seen as efficiency metrics also: the less time it takes to reach resolution, the

more efficient the process, the service desk and the entire organization is at resolving incidents.

The number of incidents reported to the Service Desk is considered metric for efficiency if put

into the proper context; specifically when meeting other SLA-based metrics and using the

appropriate number of staff on the Service Desk. A staff of five is considered more efficient than

a staff of ten if they are handling the same amount of calls or more and handling those incidents

with the same measurement results, i.e. average resolution time, first call resolution, average call

time, etc.

102



A metric tree approach is the most effective method for designing measurements and

measurement systems. The approach establishes a hierarchy of metrics to create a

comprehensive, top-down, perspective of services, processes and their interactions. Balanced

scorecards are a product of metric trees, where business and IT objectives are defined in terms

of:

• Customer satisfaction.

• Process performance.

• Response and innovation.

• Financial performance.

Metrics for overall services and individual processes are created according to how they impact

each of the categories. For instance, overall service metrics will focus on:

• Service quality.

• Customer feedback.

• Customer complaints.

• Service functionality.

The service provider will identify metrics for each of these areas which will demonstrate

the achievement of objectives in the defined categories. Customer feedback and customer

complaints would definitely impact customer satisfaction, while service quality and

functionality will impact (business) process performance and response and innovation. The

costs of providing services would measure financial performance.

For customers who rely on several services from the service provider, service metrics should

represent overall service delivery and the delivery of individual services. For instance, a

customer may be satisfied with the overall delivery of services, but be dissatisfied with a

particular service.


103

As already stated, processes are measured according to progress, compliance, effectiveness

and efficiency. Process measurements can directly impact the perspectives set by the balance

scorecard: for example, customer satisfaction can be influenced by the effectiveness of the

incident management process, even when the customer is dissatisfied with a particular service

offered by the service provider. However, process measurements can also directly influence

the individual service metrics: for instance, the service the customer is most dissatisfied with is

not performing as designed because it is using an architecture not fully known by the persons

executing the availability management process. In this case, the process is not meeting its

objectives and it is impacting the delivery of the service.

Both services and processes are supported or delivered using individual components, i.e.

hardware, software, database, etc. the metrics of these individual components typically reflect:

• Availability.

• Performance.

• Capacity.

• Failures (incidents).

• Changes.

As mentioned before, the architecture of the failing service is relatively unknown to the

technical team, specifically the availability component. It is reasonable to assume that the

architecture introduces new components to the solution while leveraging existing components

already familiar to the organization. Consider the new components require a particular

configuration to be set in order to achieve optimal performance and the configuration has been

changed to meet requirements set by the organizations standards. With the metric tree in place,

the failure in customer satisfaction can be traced directly to the configuration of an individual

component, newly introduced to environment.

104



The advantages to a metric tree are:

• A top-down perspective of the organization in relation to achievement of business

objectives, services, and processes.

• A comprehensive view of service performance from several levels, including the component

level.

• A comprehensive view of process performance from several levels, including the

component level.

• Tracing the impact of component level issues to high-level objectives and vice versa.

9.3 Balanced Design

What is meant by balanced design? Where holistic service design speaks to the different

perspectives that should be considered in design, balanced design speaks to the delicate fabric

of the design itself. Ultimately, an organization wants to development the best (perfect) design

and this is supported by service design’s purpose. Unfortunately, the perfect design is not

possible due to the constraints already existing in the environment, such as cost, knowledge,

time, space and policy. Balance design deals with the interdependencies existing between

design elements.

If service design is limited to considering three elements, as Jim McCarthy identifies in his

Dynamics of Software Development, balanced design occurs within:

• Functionality – what the service does (utility) and how it will do it (warranty).

• Resources – what assets are allocated to the service throughout the lifecycle.

• Schedule – the time required to complete and deploy the service.


105

The utility and warranty of a service has already been covered sufficiently in the Service Strategy

Certification Book; therefore they will be mentioned briefly here. When a service provider

delivers a service to a customer, they are simply providing utility and warranty to the customer.

For instance, the utility of an application service can be described in terms of the features

and functionality of the application and the contributing components, such as the server,

network, and shared storage. The warranty of the same application service encompasses the

requirements regarding availability, reliability, security, etc.

What does this have to do with balanced design? Simply put, the functionality of the service will

influence and be influenced by the other elements, resources and schedule. For instance, if the

application is being developed in house, the size, complexity, and number of features included

in the application design will typically increase the number of resources and time required to

complete the development. At the same time, the available resources and time requirements

may restrict how much functionality can be developed.

Consider the influences from the perspective of warranty. Increasing the availability SLA of a

service will often require the use of high-end performance assets, some form of replication,

and a method of load-balancing or clustering which requires more services. This becomes an

increase in the type and number of resources needed to support the functionality.

Resources are technical, informational, financial, or human. Resources, themselves, can be

highly dependent on each other. High performance components or highly competency people

(too name a couple) are typically more expensive, but costs can be managed at a lower level

using alternative solutions. Unfortunately, replacing a high-end server may require two or three

moderate servers to provide the same performance. This interdependency within the element

also exists with functionality and schedules: data warehousing for an application service may

not be possible without a suitable storage solution and a timed deliverable in application

development may require the completion and integration of several components from multiple

sources.

106



Schedules simply relate to time, specifically the time required to design, develop, and deploy

a service. With our application service, the schedule may establish a six month timetable for

completion. How does one reduce this timetable to four months? Either throw more resources

into the project (or improve the quality of the resources) or limit the functionality of the service

at the end of the completion. The timetable can be lengthened by doing the opposite: reduce

the number of available resources or increase the functionality requirements.

Balance design considers the interdependencies between different design elements and how

increases and decreases of requirements on these elements will influence each other. Generally

speaking, service providers will seek to deploy services quickly with the most functionality

using the less number of resources.

9.4 Requirements and Drivers

The functionality of a service is based on the requirements placed on the service by the

business and/or the customer. The different considerations include:

• Service requirements.


• Drivers.

Service requirements consist of the service and its components and inter-relationships.

Requirements on the service establish what the service must do in order to deliver on business

requirements, specifically in the following areas:

• Scalability of service to meet future demand.

• Business processes/units supported.

• Agreed utility requirements.


107

• Agreed warranty requirements (service levels).

• Technology used (infrastructure, environmental, data, and applications).

• Internally delivered services and components, including OLAs.

• Externally supplied services and components, including contracts.

• Required performance measurements and metrics.

• Required, or legislated, security levels.

• Sustainability.

The overall design of a service must be a collaborative effort, where the service and its

supporting components are clearly understood and recognized by people within the service

organization. When the service organization is large, departmentalized, or utilizes resources

outside the organization, agreements have to be established to ensure everyone has the same

understanding of the service being support and accepts their responsibility is the success of the

service. Further collaboration must be established in service design to ensure only one party is

accountable for the overall design.

One area where a highly level of collaboration is required is technology, as different domains

may require the personnel who specialize in the appropriate technologies available and used.

Technology can be divided into four domains:

• Infrastructure.

• Environmental.

• Data/information.

• Applications.

While service requirements will focus on the utility and warranty of a service, business

requirements focus on how that utility and warranty is used (performance potential). An easy

example is the acquisition of an exotic sport car (Ferrari). These high performance vehicles

usually provide greater utility and warranty than a standard sport car or a sedan; however, if a

Ferrari is only used to run to the market, then is the additional utility and warranty necessary.

108



Business requirements simply suggest why a particular set of utility and warranty guarantees

are required and are based on what the business needs in order to meet its objectives.

The drivers behind requirements are the people, information and tasks required to fulfill

business objectives. Consider you need a particular set of information: such as credit scores

for loan processing in a bank. This information is provided by a third-party vendor using an

extensive SQL database. An obvious service requirement will be related to the use of SQL or

translating SQL data to be readable in the existing loan processing application. The acquisition

of this information requires payment and can be expensive; however, the providing vendor has

several packages with different levels of access at adjusted prices. Business requirements would

identify what package with be appropriate for the customer based on their need.

Information used to generate business requirements will focus on three areas:

• Requirements on existing services:

Ř New utility requirements due to changes to service features, functionality, and facilities.

Ř Changes in processes, dependencies, priorities, criticality and impact.

Ř Changes in volume or demand of service.

Ř Changes in service levels and service level targets.

Ř Business justification.

Ř Requirements for addition information.

• Requirements on new services:

Ř New utility requirements due to changes to service features, functionality, and facilities.

Ř Requirements management information and needs.

Ř Supported business processes, dependencies, priorities, criticality, and impact.

Ř Business cycles and seasonal variations.

Ř Changes in service requirements and service level targets.

Ř Transaction levels for business and service, numbers and types of users and anticipated

growth.



109

Ř Predicted level of change.

Ř Level of business capability or support required.

• Required utility requirements on features, facilities and functionality:

Ř Scope of retirements in terms of facilities, features, and functionality.


Ř Any replacement of retired service or components.

Ř Interfaces and dependencies on other service’s components or configurations.

Ř Disposal and/or reuse of retiring services service assets and configuration items.

Ř Requirements regarding retirement strategy and plan.

Ř Archiving strategy for business data.

Any effort to design and develop a service must begin with the collection and clear

documentation of requirements. These requirements must be agreed upon by all stakeholders

before they can be acted on. Unfortunately, the business requirements stage is often rushed

and inconsistent: service providers should ensure adequate resources are allocated to ensure

requirements are fully understood. Some practices to best facilitate the business requirements

stage are:

• Appoint a project manager and create a project team and insist on the use of a formal,

structured project methodology.

• Identify all stakeholders, document their requirements and expected benefits.

• Analyze, prioritize, agree and document all requirements.

• Define and agree on the outline (high-level) budgets and benefits.

• Resolve any conflicts between requirements by individual business units and agree on

corporate requirements.

• Establish a process for agreeing with requirements and changes to those requirements.

• Develop a customer engagement plan defining the communication requirements between

the customer and the service provider.

110



9.5 Design Activities

Service design efforts are required by there are changes in business needs or service

improvements, which includes the addition of a new service.

9.5.1 Inputs and Outputs of Service Design

The inputs to service design include:

• Corporate vision, strategies, objectives, policies and plans, business vision, and continuity

plans.

• Service management vision, strategies, policies, objectives, and plans.

• Constraints and compliance requirements (legislative, regulatory and standards).

• IT strategies, policies and strategic plans.


• Constraints, financial budgets and plans.

• Service Portfolio.

• ITSM processes, risks and issues.

• Service transition plans (change, configuration, and release).

• Security policies, handbooks and plans.

• Procurement and contract policies and supplier strategy.

• Knowledge, skills and capability of current staff.

• IT business plans, business and IT quality plans and policies.

• Service management plans (SLM plans, SLAs, SLRs, SIPs, Capacity, availability and IT service

continuity plans).

• CSI register with relevant improvement opportunities.

• Measurement tools and techniques.


111

The outputs from service design include:

• Suggested revisions to IT strategies and policies.

• Revised designs, plans and architectures, specifically impacting IT infrastructure and

infrastructure management, applications and data.

• Designs for new or changed services, processes and technologies.

• Process review and analysis reports.

• Designs for revised measurement methods and processes.

• Managed levels of risk.

• Risk assessment and management reports.

• Business cases and feasibility studies.

• Revised budgets and service costing.

• Feedback on plans.

• Business benefits and realization reviews and reports.

9.5.2 Subsequent Design Activities

Inputs and outputs are relevant to the core design activities as already described in the Design

Aspects section of this book. The design of a service solution has several process options based

on potential alternative solutions. As a result, design activities in this area must deal with the

evaluation of the different alternatives, as well as the procurement of a commercial solution

and/or development of a proprietary solution.

The evaluation of alternative solutions is necessary when services and solutions are obtained

from a third-party external supplier. The intent of the evaluation is to find the best possible

alternative based on the requirements.

112



The evaluation process includes the following steps:

1. Selecting a set of suppliers and completing a tendering process, which requires:

• Documenting scope of service and creating a statement of requirements or terms of

reference.

• Issuing a request for information, proposal or quotation and ITT documents.

• Producing and obtaining agreement on evaluation criteria for solution and/or supplier

and scoring process.

2. Evaluating and reviewing responses from suppliers, selecting preferred supplier(s) and

proposed solution(s).

3. Evaluating and costing alternative designs.

Nearly every service design will utilize a product or service from an external service, especially

in regards to software, applications, and hardware. As such, an effective procurement process is

necessary to ensure the desired product or service: that process includes the steps:

• Completing all necessary checks (background, customer satisfaction, etc.) checks on

preferred supplier.

• Finalizing the terms and conditions of relationship, ensuring corporate policies are enforced.

• Actual procurement of product, solution or service.

Even with the use of externally obtained products, services and solutions, some development

of a service solution is necessary; and this need increases as internal resources and capabilities

are increasingly relied upon. Development of service solution can include all or some of the

following conditions:

• Development of proprietary components or methods.

• Integration of third-party components into internal environment.

• Management of third-party components from internal environment.

• Allowing access to internal data or components from third-party sources.

• Creating interfaces (technical, administrative, and managerial) between internal

environment and external environments.


113

Service solution development should be treated as a program or project with a subsequent plan

and schedule agreed by all parties responsible for required deliverables. The plan should cover:

• Business needs.

• Development/procurement strategies.

• Timescales.

• Resources required (technology, information, financial and human).

• Service and service component development, including management and operational

mechanisms, such as measurements, monitoring, and reporting.

• Service and component test plans.

9.5.3 Design Constraints

The desired service solution and the acceptable service solution available to a customer can

be radically different. The reason for the difference is the constraints placed on the design.

For instance, an adventure-seeker may desire a super-speed hover-car to use when travelling,

however this mode of travel is not acceptable currently because of technology, cost, and

regulations.

Most constraints are identified within service strategy and include:

• Utility requirements.

• Level of warranty.

• Resource constraints.

• Schedules.

• Copyrights, patents, and trademarks.

• Values and ethics.

• Technology.

• Standards and regulations.

• Existing commitments.

114



• Polices and governance.

• Capabilities and competency.

• Comparative unit costs.

Constraints can be sources internally, like policies and governance, or externally, like standards

and regulations. Some of most prominent externally sourced constraints for ITSM include:

• ISO/IEC 27001.

• ISO/IEC 19770.

• ISO 9001.

• ISO/IEC 20000.

• COBIT.

• CMMI.

• SOX.

• Basel II.


115


1. Which of the following is a major aspect of holistic service design?

A. Perspective

B. Plans

C. Process

D. Patterns

2. Which is not a general requirement of service design?

A. Easily deployable

B. Responsive to customer demand

C. Managed at an acceptable level of risk

D. Cost-effective

3. Which is not one of the 4 Ps of service design?

A. People

B. Products

C. Partners

D. Positions

4. When considering balanced design, which of the following is not a consideration

A. Functionality

B. Price

C. Resources

D. Schedule

116



5. Which of the following statements is true about managing service design activities to obtain

a balanced design?

A. All architectural and design documents must be consistent with business policies

and plans

B. IT strategies over business strategies must be available to all designers and

architects

C. Balanced service design is only possible if adequate time and money is provided by

the business

D. Good communication must be managed between customer and service provider

6. Which of the following is not a technology domain for which service requirements are

created?

A. Infrastructure

B. Environment

C. Applications

D. Database

7. What type of information is not required by service design to meet an agreed level of service

quality?

A. Information on the requirements of existing services

B. Information on the requirements of competing services

C. Information on the requirements of new services

D. Information on the requirements of retired services

8. What step of the business requirements stage of service design comes immediately after

stakeholder identification?

A. Appoint project manager

B. Create project team

C. Analyze requirements

D. Resolve conflicts


117

9. When an external third-party service provider is used to provide design support, what

additional stage is required within the service design activities?

A. Evaluation stage

B. Negotiation stage

C. Monitoring stage

D. Requirements stage

10. What is an output of service design?

A. Service portfolio

B. Business requirements

C. Service management plans

D. Risk assessment and management reports

11. What is an input to service design?

A. Managed levels of risks

B. Compliance requirements

C. Service design packages

D. Revised budgets

118



9.7 Service-Oriented Architecture Principles

Service-oriented architecture (SOA) is defined by the Organization for the Advancement of

Structured Information Standards (OASIS) as “A paradigm for organizing and utilizing distributed

capabilities that may be under the control of different ownership domains. It provides a uniform

means to offer, discover, interact with and use capabilities to produce desired effects consistent with

measurable preconditions and expectation” (Service Design, page 73).

The SOA approach is considered best practice in design and development. The approach

focuses on the developing “self-contained” services which can be reused. The best analogy

to the SOA approach is a box of Legos: where each piece is a distinct service. From a child’s

perspective, a toy car can be bought in its entirety and while satisfying, that’s all the child

got—a car. With Legos, a child can build a car and with a few changes and added pieces, the

car could be transformed into a plan or a boat. In IT, businesses often received the same type

of packaging as the car; they received an entire comprehensive package with meet their needs

with little scalability or flexibility. With SOA, they have greater flexibility in the service because

the individual components of the service are self-contained and movable.

Simply put, SOA will break down a service into is smallest parts and then reconstruct the service

accordingly. Not all services need to be broken completely down; for instance, the Service Desk

function (as a service) would be the same no matter what service engages them, even though

the Service Desk has responsibilities that bridge incident management, request fulfillment,

business relationship management and several other processes. Using the Lego analogy in

practical terms, a child could use 4 1 × 2 blocks; but why should they if they have 1 4 × 2 block.

The point of the SOA approach is the ability to leverage and reuse existing services. As

mentioned, the Service Desk is one such service which is self-contained, but the number of

possible services available to the service provider is endless. One prominent service using


119

this approach most people are familiar is identity management, using a single username and

password for multiple applications and functions. Nearly every Internet-based application has

the ability to sign-on using the Facebook, Twitter, Google, Yahoo, and/or Amazon credentials.

This is an example of an existing service (from a third party vendor) being leveraged and

included into a larger package.

For SOA to be effective, a service provider must:

• Determine and define what a service is.

• Understand and clearly identified interfaces and dependencies between services.

• Utilize standards for development and definition of services.

• Utilize common technology and toolsets.

• Investigate and understand the impact of changes to shared services.

• Ensure all IT staff members have SOA-related training.

As reliance on SOA principles increases for the service provider, the dependency on an accurate

service catalog increases. The benefits of the SOA approach attribute to reduced time and

costs associated with service development and greater reliability and flexibility in service

operation. An effective service catalog showing the relationships between services and service

components ensures these benefits are realized.

9.8 Service Design Models

In service design, two different models must be ascertained: the design model and the delivery

model. However, the design model is highly dependent on the delivery model. Consider our

previous example related to a Lego car and a normal toy (die-cast) car: if the output to be

delivered is a car, the process of reaching that intent would be different. Specifically, the Lego

car must be built before being delivered while the die-cast car comes completely assembled. In

120



this situation, the method of delivery will identify what must be handled during the planning

(design) stage.

For this reason, one of the first activities of service design (or last activities of service strategy,

depending on how it is perceived) is a review of current capabilities and provisions regarding

delivery of IT services. The review would consider the following aspects of all new services:

• Business drivers and requirements.

• Demands, targets and requirements of the new service.

• Scope and capability of the service provider or unit of the service provider.

• Scope and capability of external suppliers.

• Maturity of organizations currently involved and their processes.

• Culture of the organizations involved.

• IT infrastructure, applications, data, services and other components involved.

• Degree of corporate and IT governance.

• Level of ownership and control required.

• Budgets and other available resources.

• Staff levels and skills.

The review is simply a means of determining the readiness of the organization to provide

the service in its entirety or in parts. The requirements of the service will determine what

capabilities and provisions the service provider must possess (or obtain externally) to deliver

the service. The review identifies the current “known” state of the service provider which can be

compared against the “desired” state demanded by the requirements to determine what must

be completed for the service provider to be “ready.” The movement from one state to the next is

handled through the development and execution of a delivery strategy.


121

9.8.1 Delivery Models and Strategies

There are several delivery models to choose from, each with their own advantages and

disadvantages. Nearly all delivery strategies are based on some type of sourcing structure—a

means of sourcing the service or solution. The different sourcing structures are found in the

table below (next page)

From a design perspective, every delivery strategy has a level of adaptation and customization

which must be addressed to integrate the solution into the environment. For service being

insourced, the dependency on the design is extremely high; but even outsourced services need

to address concerns regarding integration and management into the overall IT service strategy

and infrastructure.

Sourcing Structure

Description Advantages Disadvantages

Insourcing Resources and capabilities residing within the internal organization are used to design, develop, transition, maintain, operate and/or support the service.

Direct control

Freedom or choice

Rapid prototyping of leading services

Policies and processes are familiar

Company-specific knowledge

Limitations on scalability

Cost and time to market usually higher than outsourced services

Dependent on internal resources, skills and competencies

122



Sourcing Structure


Outsourcing Resources and capabilities residing within an external organization are used to design, develop, transition, maintain, operate and/or support the service.

Economies of scale leveraged

Purchased expertise for service

Enables focus on core competencies for the company

Support of transient needs

Ability to test drive (trial) new services

Less direct control

Barriers to exiting arrangement

Risk of supplier-based solvency

Skills and competencies of suppliers unknown

Business process integration challenging

Increased governance and verification requirements

Co-sourcing/Multi-sourcing

A combination of insourcing and outsourcing where two or more organizations are collaborating together to deliver a single, defined service.

Time to market shorter

Leveraged expertise

Control

Use of specialized providers

Complexity of project

Protection of intellectual property and copyrights

Conflicts between company cultures


123

Sourcing Structure


Partnership A formal version of co-sourcing where strategic partnerships are created to leverage critical expertise or market opportunities.

Time to market shorter

Expansion or entrance to market

Competitive response

Leveraged expertise

Trust, alignment and mutual benefit

“Risk and reward” agreements

Complexity of project

Protection of intellectual property and copyrights


Business process outsourcing (BPO)

Outsourcing or co-sourcing arrangements where one organization becomes responsible for an entire function of the other organization: the most common examples are accounting, payroll and call center operations

Single point of responsibility

“One-stop” shopping

Access to specialization (skills)

Risks transferred to provider

Low-cost location


Loss of business knowledge

Loss of relationships with business

124



Sourcing Structure


Application service provision

Outsourcing or co-sourcing arrangements where one organization provides shard computer-based services (applications) over the other organization on-premise network

Access to expensive and complex solutions

Support and upgrades included

Security and ITSCM options included


Access to facilities, not knowledge

Usage-based charging models possible, but not guaranteed

Knowledge Process Outsourcing (KPO)

BPO arrangement where the sourcing organization provides greater domain-based process and business expertise and has the authority to make in-scope decisions for the other organization

Access to specialist knowledge, skills and expertise

Low-cost solution

Significant cost savings


Loss of internal knowledge

Loss of relationship with business


125

Sourcing Structure


Cloud computing

An insourcing or outsourcing arrangement for pre-defined, on-demand, services through the Internet

Services easily defined

Straightforward outsourcing approach

Relatively easy mapping between service and business outcomes

Greater customer control of service

Complexity for internal clouds

Focus on technology over business relationships

Integration between internal and cloud services difficult

Security and continuity for services managed externally

Multi-vendor sourcing

A combination of previously mentioned structures from multiple vendors.

Less risk as more vendors are used

Leverage of specialist skills

Potential difficulty with coordinating joint efforts

Clearly defined value chain required

9.8.2 Design and Development Approach

The approach used to design and develop a service must consider the following aspects:

• Structure.

• Activities.

• Models providing diverse perspectives (process, data, event, user).

126




1. Which of the following is not an aspect of service design?

A. Service solutions

B. Management information systems

C. Measurement methods

D. Human resources

2. In addition to the components of a service, which of the following is also a consideration for

service design?

A. Organizational impact

B. Strategic alignment

C. Compliance to standards

D. Budgeting

3. The approach used in service design is best described as?

A. Restrictive – to ensure consistency across all aspects of service design

B. Iterative – to ensure the delivered service meets the evolving and changing needs of

the business

C. Comprehensive – to ensure that every requirement is met within the first run at

service design

D. Focused – to ensure the priority functionality required by the customer is provided

first


127

4. The design aspect of a design and development project can be separated into three parts:

which of the following is not one of those parts?

A. Documentation of business requirements

B. Design of service solution

C. Development of service solution

D. Early life support

5. Which of the following is not a common management information system mentioned in

ITIL?



C. Cloud utility management system

D. Security management information system

6. When using the service portfolio to communicate status of a service, which of the following

status options describes when the service requirements are being communicated to service

design and resources and budgets are being allocated?

A. Charters

B. Design

C. Approved

D. Development

128



7. How a service provider approaches the service should be the same as how all management

information systems should be approached: within this context, which of the following is

not a consideration for designing the service portfolio?

A. Unique identification of services

B. One version of the service exists in any section of the service portfolio at any given

time

C. Changes to services must be documented in a change history section

D. Newer versions of services must begin in the service pipeline

8. Which of the following statements best describes the intent of architectural design?

A. The proper coordination of work is obtained between service planners and

designers and operations over the existing architectures

B. The right balance is struck between innovation, risk and cost while seeking a

competitive edge, where desired by the business

C. Technology, people, finances, and information are working together to meet the

needs of the business and its clients

D. Compliance to legislative measures is ensured

9. What is process control?

A. An activity of monitoring a process

B. An activity of manipulating a process to obtain a desired output

C. An activity of analyzing the performance of a process

D. An activity of planning and regulating a process

10. Of the different types of metrics used to measure the capability and performance of

processes, which of the types does the cost of executing the process best fit?

A. Efficiency

B. Effectiveness

C. Compliance

D. Progress

129

10 Processes of Service Design

The processes of Service Strategy include:

• Design Coordination.

• Service Catalog Management.

• Service Level Management.

• Availability Management.

• Capacity Management.

• IT Service Continuity Management.

• Information Security Management.

• Supplier Management.

10.1 Design Coordination

Design Coordination is a service management process designed to provide overarching

management and coordination of all design activities. This is necessary because many of the

activities required through service design are performed by multiple disciplines and/or teams

and are highly integrated with each other. Though careful coordination, the service provider is

able to create designs which are comprehensive and appropriate for the service in question and

the entire service environment.

Chapter 10

130



10.1.1 Purpose and Objectives

The primary purpose of Design Coordination is to provide a single point of coordination and

control for all design activities to ensure the goals and objectives of the service design stage are

met. While much of service design will be conducted as a project, not all activities in this stage

are part of a formal project. For example, the change management process has considerable

influence in the service design stage, but is itself not a function of the project: specifically

process changes are handled differently from service changes, using the same or different

change processes. In this situation, design coordination will ensure that any requirements from

change management are fulfilled within the design project.

The objectives of the Design Coordination process include:

• Ensure a consistent design of services, systems, architectures, technology, processes,

information and metrics.

• Ensure designs meet current and future business outcomes and requirements.

• Coordinate all design activities across multiple projects, changes, suppliers and support

teams.

• Manage schedules, resources and conflicts related to service design.

• Plan and coordination resources and capabilities required to design new or changed

services.

• Produce service design packages.

• Produce appropriate service designs and SDPs for handoff to service transition.

• Manage quality criteria, requirements and touch points between service design and service

strategy and service transition.

• Ensure the conformance of all service models and service solution designs to strategic,

architectural, governance and corporate requirements.

• Improve the effectiveness and efficiency of service design processes and activities.

• Ensure the adoption of a common framework of standard, reusable design practices.

• Monitor and improve service design performance.


131

10.1.2 Scope

The scope of Design Coordination is all design activities regardless of size, complexity, schedule

or justification. Some design efforts will be simple, while others will be extensive and complex.

While new and changed requirements to a service is an obvious choice for needing design

coordination, any change or improvement to a service, a process, a service management

system, or underlying component has a potential need for service design. Because of the

project nature of a design effort, many of the activities which design coordination focuses on

will be project-based; however, the process may also be responsible for coordinating efforts not

directly attributed to a single project.

The extent in which design coordination is utilized in the environment is at the discretion of the

organization. Some organizations consider that every change to the environment has a “design”

stage, and therefore, the design coordination process is engaged. Other organization will

establish minimum criteria for which a change will engage service design, and thus the design

coordination process.

One characteristic of the service design processes which can cause confusion for when design

coordination is engaged is the existence of planning, transition and operational elements. For

instance, availability management is responsible for establishing availability plans (design),

developing availability solutions (design and transition), building and testing those solutions

(transition), deployment of the solution (transition), and management of the solution in

the live environment (operation). This is true for every service design process except design

coordination. However, this characteristic also enforces the need for design coordination during

the planning and initial development of a service.

132



In all, the process for design coordination includes

• Assisting and supporting projects or other changes through the activities and processes of

service design.

• Maintaining policies, guidelines, standards, budgets, models, resources and capabilities

specifically used in service design.

• Coordinating, prioritizing and scheduling service design resources to resolve demand from

all projects and changes.

• Planning and forecasting the resources needed for future demand on service design.

• Reviewing, measuring and improving performance of all service design processes and

activities.

• Ensuring all requirements (utility and warranty) are addressed appropriately in service

designs.

• Ensuring service designs and/or service design packages are produced and handed off to

service transition.

Design coordination is not responsible for activities and processes outside of the design stage

of the service lifecycle. For instance, the Information Security Policy is typically created as part of

the service strategy stage and used as a constraint in producing service designs, but it is not the

responsibility of the design coordination even though the Information Security Management

process is identified as a service design process and accountable for the creation of the policy

mentioned.

Design coordination is also not responsible for the detailed designs of the service solution

or for producing the individual parts of the service design packages; this is the responsibility

of the project, in general, and each service design process specifically. One thing to keep in

mind is, for most organization, the human resources used in both service design and service

transition are primarily assigned operational duties and are engaged for their expertise in the

live environment. While there may be dedicated personnel like designers, architects and project

managers who are dedicated to service design, the majority of personnel are participating

in service design in an “assigned as required” capacity. The reliance on operational personnel


133

increases the necessity of design coordination for ensuring that designs are consistent and

effective in meeting business and customer requirements.

10.1.3 Value to Business

Design coordination is invaluable in producing two key sources of information for a service:

the solution design and the service design package. The value the process brings to the service

lifecycle is creating these sources consistently and meeting quality requirements. What does it

mean to be consistent in service design? Given the holistic approach to service design, several

perspectives must be considered and, within each perspective, checklists can be created to

identify the individual points of concerns, risks, and opportunities the organization is focused

on. Design coordination provides a means to ensure every design effort addresses the same

series of checklists.

Through this coordination effort, organization benefit by:

• Ensuring the intended business value of the service(s) is achieved at minimal and acceptable

levels of risk and cost.

• Rework on service designs is minimal and unplanned labor costs associated with design

issues are minimized in the later service lifecycle stages.

• Achievement of higher customer and user satisfaction levels are supported, including

improved confidence in IT and IT services.

• Ensuring the conformance of all services to a consistent architecture, resulting in greater

ease when seeking integration and data exchanges between services and systems.

• Improving the focus on service value, business outcomes and customer outcomes.

• Improving effectiveness and efficiency of all service design processes and activities,

resulting in higher volumes of successful changes being supported.

• Improving agility and quality in the design of service solutions.

134



10.1.4 Policies, Principles, and Basic Concepts

As mentioned before, the best approach to service design is holistic and iterative. The first part,

holistic, speaks to the scope of the design; while the second part, iterative, speaks to the pace

of the design effort. Ultimately, the goal of service design is to ensure the service solution to

be implemented meets the objectives and requirements of the business and the customer.

Additionally, service design may be formally engaged for every change identified within the

environment, or may be engage for those changes which meet a specific criteria.

The policies of service design must address all the issues mentioned:

• Scope.

• Pace.

• Engagement.

• Expectations.

The greatest impact of these policies will be on the change management process, which must

evaluate every request for change to determine the involvement of service design. For most

organizations, the natural tendency is to engage the appropriate teams based on the context of

the change; for instance, engaging availability teams to handle changes impacting availability.

This tendency is especially inherent when the same people who are likely to participate in the

design change would have probably initiated the change and/or will be implementing the

change. For example, a system administrator sees an opportunity to improve the availability of

a specific server to increase its reliability and the number of hours it is available for service. They

initiate a request for change to create a record of the change, but because of their expertise in

the server, they push the request through quickly and the impact on the service solution is not

evaluated. As a result, the new configuration creates an issue, which ripples across the service’s

value chain and impacts the delivery capabilities for the service. Enforcing one step to evaluate

the change against the design of the solution would have prevented any issue from arising. This

example demonstrates the importance of service design: though the impact of a configuration

change will likely be minimal and the risks may be absorbed by the organization.


135

The policies of design coordination will address:

• Adherence to corporate standards and conventions.

• Compliance to governance and regulatory policies, plans, and procedures.

• Use of standard design elements:

Ř Document templates.

Ř Documentation plans.

Ř Training plans.

Ř Communication plans.

Ř Marketing plans.

Ř Measurement and metrics plans.

Ř Testing plans.

Ř Deployment plans.

• Procedures and criteria for resolving conflicting demand for resources in service design

(resources dedicated to service design, as well as resources leveraged from outside service

design).

• Standard cost models.

Another important area for policies and principles is the integration of design coordination with

project management. While design coordination may be performed as part of a project, the

process simply provides a context for completing the project successfully. Integrating the two

disciplines requires the use and production of the same practices, documents, procedures or

deliverables, as well as training for all project managers in design coordination. The purpose for

this integration is to ensure that every design project is completed to meet the objectives of the

design coordination process.

136



Service design is a progressive endeavor—an organization may not achieve the best solution

the very first time. This is partly due to the knowledge and processes of the service design, but it

is also influenced by:

• Inadequate strategy processes, which do not produce clear and appropriate requirements.

• Emerging technologies, which may be introduced newly to the environment or best

practices are still being discovered for the industry.

• Legislative and regulatory guidelines, which may introduce new requirements without clear

practice or advice for implementation.

• Changes in customer or market space environments.

A formal design coordination process will be built upon existing practices, competencies, and

information, but it most also adapt to changing influences. Ideally, the process should leverage

the process for continual service improvement, for both service design and the design of each

service.

10.1.5 Process Activities

The activities for design coordination occur on two levels:

• Overall service design lifecycle stage.

• Individual service designs.

The activities on each level are similar and include:

• Collection, analysis, and engineering of customer requirements, documented and agreed.

• Collection, analysis, and engineering of service provider requirements, documented and

agreed.

• Collection, analysis, and engineering of technical requirements, documented and agreed.

• Design of service solutions, technology, processes, information and metrics to meet

requirements.

• Review and revision of design for all process and maintenance of processes and process


137

documents involved in service design.

• Production and maintenance of IT policies and design documents.

• Review and revision of all design documents, ensuring completeness and compliance to

standards.

• Use of “roadmaps” programs and project plans for the planning of IT strategy deployment

and implementation.

• Assessment and management of risks associated with all design processes and deliverables.

• Alignment of all corporate and IT strategies and policies.

• Production of service designs and/or service design packages for new or changed services.

The activities of design coordination can be simplified for each level as follows:

Lifecycle Stage Individual ProjectsDefine and maintain policies and design

methods

Plan individual designs

Resource and capability planning Coordinate individual designsCoordinate design activities Monitor individual designsManage design risks and issues Review designsImprove service design Handover SDPs to transition

10.1.6 Process Activities – Lifecycle

The policies and methods of service design define the holistic approach to service design

for the organization and establishes the means by which designs can be consistently and

accurately produced. Design coordination is dependent on the effectiveness and cooperation of

multiple service management processes, related to service design and related to other lifecycle

stages. Through collaboration with other processes, a common framework can be created

consisting of standard reusable processes, procedures and systems. This framework would

contain guidelines on:

138



• Review and agreement of requirements and design.

• Use and management of quality criteria.

• Use and management of requirements.

• Use and management of interfaces.

• Touch points with other lifecycle stages.

As part of the framework, the level of design coordination needed can be defined for projects

and changes of different types and sizes. The framework may extend to predefining design

requirements, or even predefining designs for standard changes. Design coordination will also

maintain a set of architecture documents and principles to be reused in service solutions and

SDPs.

It must be clear that the resources and capabilities used for service design are managed

separately from the resources and capabilities used for projects, operations, change

management, and any other function for the service provider; even if some overlap of resource

and capabilities is likely to occur. The most complex resource type is human, as it is likely that

personnel will be fulfilling several roles, each demanding time and attention from the person.

Different projects will require varied degrees of resources and capabilities based on the service

requirements, agreements, and desired targets.

Planning and coordinating design resources and capabilities require a clear understanding of

accurately documented services within the service portfolio, especially the service pipeline.

In addition, regular communication with the business relationship managers and the service

owners will maintain an understanding the potential changes which may require service design,

and its resources and capabilities. In all, the following actions should be considered when

planning and managing design-specific resources and capabilities:

• Training to existing personnel on design policies and methods.

• Hiring of new staff or inclusion of design-based responsibilities in existing roles and job

descriptions.


139

• Identifying and implementing technologies, automation, design standards.

• Enforcement of design policies, methods, and standards.

• Creating new processes and/or procedures to enhance organizational capabilities.

• Identifying and implementing improvements to existing processes and/or procedures.

• Developing new knowledge and improving accessibility to knowledge.

As part of managing resources and capabilities, design coordination must also be concerned

with potential conflicts with multiple or dependent projects. Demand for resources may create

conflicts if the same resource is needed for to different projects: understanding where those

projects are at and their priority to achieving objectives will define where the resource should

be and when. Managing change so that conflicts with change windows are resolved and new

or changed designs do not adversely impact recent changes is also desirable and should be

coordinated. Ensuring that every design effort produces a solution with the appropriate utility

and warranty for each service is the focus of design coordination, but so it’s the solution’s

integration into the service environment. Design coordination ensures that no service is design

in isolation and can be appropriately integrated into the IT and management infrastructures. In

this context, design coordination is responsible for:

• Ensuring good communication is maintained between different design activities and

concerned parties, particularly planners, designers, architects and strategists.

• Ensuring the availability of the latest versions of all business and IT plans and strategies to all

designers.

• Ensuring all architectural documents, service models, service solution designs and service

design packages conform to strategic, architectural, governance and other corporate-based

requirements.

• Ensuring all architectural documents, service models, service solution designs and service

design packages conform to IT policies and plans.

• Ensuring good communication is maintained with service transition processes.

• Ensure architectures and designs are:

Ř Flexible and enable rapid response to new business needs.

Ř Integrated with all strategies and policies.

140



Ř Supportive of the needs of other service lifecycle stages.

Ř Facilitating new or changed services and solutions to completion and in alignment with

needs and timelines of the business.

Individual design projects will have their own risks and issues, many which can be resolved as

part of the project; however, some risks and issues are the result of service design capabilities or

standards, or are significant enough to require attention from outside the project. Additionally,

the output of service design, specifically poor design, can be risky and must be managed

appropriately. Process and procedures for assessing and managing design risks and issues

should be established and should be consistent with other risk and issue management

processes, particularly those used in project management.

It goes without saying that any improvement to the general policies, practices, and procedures

of service design are opportunities for improving the individual project efforts in service

design. For instance, the implementation and improvement of a knowledge management

system containing all existing designs, plans, architectures, and policies will allow current and

future projects to leverage the information and potentially decrease the time and cost required

for completion. A formal feedback mechanism can capture potential design improvement

opportunities for the overall design program from individual project activities like lessons-

learned. The use of standards in design increases the familiarity of personnel with service

designs as they move forward through the service lifecycle or are asked to participate in

multiple design projects.

10.1.7 Process Activities – Individual Projects

Design coordination may identify opportunities to create standard project plans with clearly

defined activities to be performed for every project; however, it is still important that the design

activity for each project or change be carefully planned. Planning for individual projects and

changes include what needs to be done, when it needs to be done, and what resources and

capabilities are required to ensure completion and quality.


141

While the maturity of service design will ease the planning requirements on each project and

change, not all design efforts will be the same; thus, the best standards and templates can do

is provide an outline to work from or address common attributes in those projects. Still each

project will vary based on the utility and requirements of the service and the constraints placed

on the project, particularly regarding budget, schedules, and resource allocations. For instance,

a blanket 10% cut of all design budgets may have little impact on the small, relatively non-

risk service, but have a tremendous impact on a highly complex and critical service. Even two

different projects for the same service for separate customers can be impacted differently if the

constraints are different. For this reason, careful planning for each individual project or change

should be enforced, even if the effort is verification of key assumptions.

On individual projects, the project manager will be responsible for executing the design

coordination process: on individual changes, this responsibility will fall on the person

accountable for the change. The design coordination process will be able to provide access to

collective knowledge from previous projects and changes to aid the person for the duration

of the effort. Still, it is important to allow for training over these people to ensure their

understanding of what is available and how best to use it.

The actual coordination of design for individual projects and changes entails ensuring the

project participants are working collaboratively to produce a design which meets the desired

objectives and requirements. Both project management and change management will be

used extensively during this activity with design coordination providing support in the form of

collective knowledge, guidance, and compliance requirements.

Each design project and change should be monitored individually and as a collective, both

looking to determine if the design effort is adhering to agreed method, resolving any emerging

conflicts, and ensuring the resultant design solution meets requirements and is documented

142



properly in the service design package. Monitoring at the project or change level enables

the person(s) responsible to adjust the effort accordingly or escalate any issues. Collective

monitoring seek to enforce compliance and identify how the overall service design program can

be improved to benefit the individual projects and changes.

The last step of an individual design effort is to review the design and hand over the service

design package to service transition. Remember, before the SDP is completed, service transition

has been engaged and may have participated in ensuring the design meets requirements

and developing the service transition plan found in the SDP. Design coordination will have

been used to coordinate their participation and, from an overall perspective, identified and

implemented improvements to the review and hand over activities.

10.1.8 Triggers, Inputs, and Outputs

Design Coordination will be triggered by the following events:

• Changes to business requirements and services.

• Requests for change.

• New programs or projects.

• Revision of overall IT strategy.

The inputs and outputs of design coordination are summarized in the following table:

Inputs OutputsService charters Service designs and service design

packagesChange requests from any lifecycle stage Revised enterprise architectureChange records and authorized changes Revised management systems


143

Inputs OutputsBusiness information from strategies, plans,

and requirements

Revised measurement and metrics

methodsResults from Business Impact Analysis Revised service management processes

and other processesService Portfolio Service portfolio updatesIT strategies, constraints and resource

limitations

Updates to change records

Governance requirementsCorporate, legal and regulatory policies

and requirementsProgram and project schedulesConfiguration Management SystemFeedback from other processesEnterprise architectureManagement systemsMeasurements and metricsService management processes

Design Coordination will interface with and direct all service management process at some

level, especially when designing the process. The major interfaces are with service strategy to

obtain information used in service design and service transition to handover designs within the

SDP to be developed and deployed. Details regarding specific interfaces include:

• Service Portfolio Management – the service charter to initiate design work is provided, as

well as all other documents associated with the charter, including business requirements,

service requirements, risks, and priorities.

• Change Management – requests for change requiring design work are provided. The

policies of both processes should be consistent and create a collaborative relationship. In

addition, defined points of the design and transition processes require authorization which

is obtained through the change management process, which will also provide feedback

144



from post-implementation reviews which can be used to improve service design.

• Financial Management for IT Services – provides details regarding the value proposition

of the new or changed service and the budgets associated with the design, transition, and

operation of the service.

• Business Relationship Management – provides intelligence and information related to the

customer, their desired outcomes, their needs, priorities, and requirements. BRM will also

manage the communication with the customer at a strategic level.

• Transition Planning and Support – design coordination provide the completed SDP to

initiate the planning and coordination of the transition aspect of the service lifecycle.

• Strategy Management for IT Services – provides information about the current and future

service strategy to ensure design policies, guidelines, and procedures remain current.

• Release and Deployment Management – the process manages the planning and execution

of individual changes, releases and deployments – all of which are planned and designed

within the service design stage.

• Service Validation and Testing – the process will plan and test the service, process or system

according to designed specifications and requirements – all of which are planned and

designed within the service design stage.

• Change Evaluation – the process determines the performance of the service change,

including an evaluation of the service design against intended requirements. The process is

an activity that design coordination will manage resources.

• Service Level Management – the process defines and obtains agreement for service

level requirements in compliance with the standards and practices developed by design

coordination.

• Availability Management – actively involved in and is responsible for its scope within service

design; ensuring design activities are performed consistently and according to defined

practices and policies developed with design coordination.

• Capability Management – actively involved in and is responsible for its scope within service

design; ensuring design activities are performed consistently and according to defined

practices and policies developed with design coordination.

• IT Service Continuity Management – actively involved in and is responsible for its scope

within service design; ensuring design activities are performed consistently and according


145

to defined practices and policies developed with design coordination.

• Information Security Management – actively involved in and is responsible for its scope

within service design; ensuring design activities are performed consistently and according

to defined practices and policies developed with design coordination.

• Supplier Management – collaborates with design coordination to ensure contributions from

suppliers to design activities are managed properly.

10.1.9 Critical Success Factors and Key Performance Indicators

The following critical success factors and key performance indicators are samples related to

Design Coordination. Each critical success factors has at least one key performance indicators

which is used to demonstrate achievement of the CSF.

1. Service design packages which are consistent and accurate

a. Reduction in the number of revisions for SDP content.

b. Percentage reduction in re-work required for new or changed services.

2. Conflicting demands for shared resources are managed properly

a. Increased satisfaction with service design activities.

b. Reduced number of issues caused by resource conflicts.

c. Percentage increase regarding successful new and changed services in terms of

outcomes, quality, cost and timeliness.

d. Improved effectiveness and efficiency of service design processes, activities and

supporting systems.

e. Reduction in number and percentage of emergency change requests submitted by

projects.

3. New and changed services meet customer expectations

a. Increased customer satisfaction for each new or change service against designed

rating.

b. Increase in number of transitioned services that consistently achieve agreed service

level targets.

146



10.1.10 Challenges and Risks

The greatest challenge of design coordination is the ability to maintain high-quality designs

and SDPs across the entire enterprise, service environment and IT infrastructure. This is possible

when utilizing skilled designed and architects who have experience and knowledge across

several disciplines, as well as the existence and deep integration of design standards and

practices with project management. Even with a firm foundation from which to perform service

design, sufficient time and resources must be allocated to ensure each design and SDP are

completed and aligned with the requirements and constraints placed on the service and the

management system. All of this must be done without including high-levels of bureaucracy and

control into the design processes.

The risks associated with design coordination include:

• Potential lack of skills and knowledge.

• Lack of business participation.

• Poor direction and strategy.

• Lack of information on priorities and impact from business.

• Requirements and desired outcomes are poorly defined.

• Lack of participation (apathy) from project managers.

• Poor communication.

• Lack of participation from relevant stakeholders.

• Interaction or inputs from other lifecycle stages are insufficient.

• Adverse reduction in time and money resulting in poorer designs and increase instability for

the service.


147

10.1.11 Summary for Design Coordination

ContXT is a rapidly growing marketing firm with some major clients. Over the last few years,

they have been a relatively small outfit providing some high quality output. They have grown

from a staff of 10 to over 120 people in the last five years. They have three people who handle

all their IT requirements full time but they have not fully investigated at how IT can enrich their

productivity and corporate goals. As a result for the first time in several years, they are receiving

negative feedback from their clients regarding issues like communication, duplicate requests,

and slower than expected project schedules.

From work done as part of the service strategy lifecycle stage (as detailed in the Service

Strategy Certification Book), the IT department have identified several services (with associated

objectives):

1. Increase the number of available conference sessions each week:

• Teleconferencing service.

• Video conferencing service.

• Client interface with project management system

• Information security.

2. Reduce the overall time and resource commitments allocated to existing and future

marketing schedules (projects):

• Project management system.

• Internal knowledge base.


3. Reduce the risks associated with knowledge capture and sharing internally, with clients, and

through remote network access:


• Remote access (VPN).

148



While the company currently has processes, systems, and practices in place for several of these

services, none have been formally designed and deployed in the environment; while other

services, like remote access, will be completely new to the environment.

The primary role of design coordination will be to create formal service design models and

service design packages for each service. This will include the creation of architectures, plans,

processes, and policies used when designing the service. Some of the efforts can be leveraged:

for instance, service design as a program will be in need of a project management system and

internal knowledge base to facilitate current and future design projects and changes. Since

these services are also required for the customer, it is possible to create a joint venture to create

similar solutions that can meet the needs of both “customers”: the coordination occurring

within the design coordination process. The advantage to this approach is the development of a

standard tool and method which can be reused.

Information security is a shared service which will impact each of the other services listed, but

may not be the highest-priority solution for the services. Even if projects were initiated for each

service simultaneously, the policies and practices defined by Information Security Management

may not be fully explored and applicable to the other services: at the same time, each of the

other projects may identify security risks and options which can be used to complete the ISM

project. These interdependencies between the projects must be understood and managed

appropriately by the design coordination process.

For ContXT, the efforts of service design will be severely hampered by the immaturity of the IT

department. The level of maturity can be increased drastically by raising the competency of the

IT department through the hiring of skilled personnel, procurement of project management

tools, or the use of third-party architects, designers, and planners. As the organization matures,

design coordination will ensure that every service, whether supported internally or externally,

will consistently and effectively meet business outcomes and objectives.


149


1. Which of the following statements best describe the role of the Design Coordination process

in service design?

A. Design Coordination provides a single interface for coordination activities across the

service lifecycle

B. Design Coordination provides a single point of coordination and control for design

processes and activities

C. Design Coordination provides the means of managing the activities against a

defined schedule, budget, and risk profile

D. Design Coordination provides the underlying architectures and standards required

to consistently design services delivered to the customer

2. Which of the following is not an objective of the Design Coordination Process?

A. Produce a service design package

B. Coordination all design activities

C. Ensure consistent design of appropriate services, systems and processes

D. Ensure proper testing of service design before deployment into a live environment

3. Which of the following disciplines would not be directly leveraged in Design Coordination?

A. Risk Management

B. Project Management

C. Resource Management

D. Change Management

150



4. Which of the following is not a responsibility of Design Coordination?

A. The detailed design of a service solution

B. The production of a service design package

C. Ensuring all service requirements are addressed appropriately in the service design

D. Scheduling appropriate resources to service design activities

5. Which of the following statements does not identify a benefit of Design Coordination?

A. Design Coordination minimizes rework required of ill-conceived design solutions

B. Design Coordination ensures the intended business value of services is fully realized

and optimized for the customer

C. Design Coordination ensures the intended business value of services is achieved at

acceptable risks and costs to the service provider

D. Design Coordination develop improved effectiveness and efficiency in all service

design activities

6. Which of the following areas is not covered by policies of Design Coordination?

A. Compliance to standards

B. Standard cost models

C. Procedures for resolving conflicts in requirements

D. Standard design elements

7. Which of the following requirement types are not collected, analyzed and engineered within

Design Coordination process?

A. Customer requirements

B. Technical requirements

C. Service provider requirements

D. User requirements


151

8. When designing for the overall service management system, which of the following steps

incorporates concepts and tools used in CSI?

A. Plan design resources and capabilities

B. Coordination design activities

C. Improve service design

D. Manage design risk and issues

9. When designing individual services, which of the following steps directly interfaces with the

service transition lifecycle stage?

A. Plan individual designs

B. Coordinate individual designs

C. Monitor individual designs

D. Review designs and ensure handover

10. Which of the following is not a trigger of the Design Coordination process?

A. Change to business strategy

B. Requests for change

C. New programs or projects

D. Changes to overall IT strategy

11. Which of the following is not an input to Design Coordination?

A. Service Charter

B. Service Design Package

C. Service Portfolio

D. Configuration Management System

152



12. What service management process works with Design Coordination to evaluate the service

design against intended requirements?

A. Change Management

B. Release and Deployment Management

C. Change Evaluation

D. Service Validation and Testing

13. What key performance indicator best supports the critical success factor for ensuring new or

changed services meet customer expectations

A. Increased satisfaction with service design activities

B. Increased customer satisfaction for each new or changed service

C. Recued number of issues for services

D. Reduction in the re-work required of new or changed services


153

10.3 Service Catalog Management

The service catalog is part of the service portfolio, but the management of the service catalog

goes beyond the strategic focus of service portfolio management. Because of the service

catalog’s importance in IT service management, the management process for this database of

structured document must ensure the catalog is generated and maintained with the greatest

available care and attention.


The service catalog is the single source of information about all services available for use by the

customer, whether they are currently operational are being prepared for operation. The purpose

of the service catalog management process is to generate and maintain this catalog.

The objectives of Service Catalog Management are:

• Manage the information contained within the service catalog.

• Ensure the accuracy of the service catalog relative to service details, status, interfaces and

dependencies within the live environment.

• Ensure the availability of the service catalog to authorized personnel.

• Ensure the service catalog supports the evolving needs of the other service management

processes regarding information on the service, interfaces and dependency.

154



10.3.2 Scope

The scope of the service catalog management process is the generation and maintenance of

information related to all services already or current being transitioned into the operational

environment. As such any new service or new version of an existing service still within the

strategy or design stage would reside in the service pipeline of the service portfolio, not

the service catalog: in many cases, the services still in the development and testing stage of

transition may not be included in the service catalog (based on the organization’s policies).

Services may be presented individually or as packages. Standards like ISO/IEC 20000 require a

service catalog for each customer: a requirement which may be interpreted as a single catalog

available to all customers or a separate catalog containing services only included as part of the

customer contract with the service provider.

The Service Catalog Management process addresses the following responsibilities:

• Development and maintenance of service and service package definitions.

• Contributions to service definitions and service package definitions from service

management processes.

• Production and maintenance of an accurate service catalog.

• Interfaces, dependencies and consistency between the service catalog and service portfolio.

• Interfaces and dependencies between all services and supporting services within the

service catalog and the configuration management system.

• Interfaces and dependencies between services, supporting components and configuration

items within the service catalog and the configuration management system.

The service catalog may link to and leverage information generated and maintained by other

service management processes but is not wholly responsible for the accuracy or validity of that

information. The most prevalent source of information for the service catalog is the


155

configuration management system, which the service asset and configuration management

process is responsible for capturing, maintaining, and distributing information related to service

assets can configuration items. Another process, request fulfillment, is responsible for capturing,

maintaining and fulfilling service requests, which are generated as users request access to

services listed in the service catalog.


The primary value proposition for the service catalog is its existence as a central source of

information on all “available” IT services currently found in the operating environment. The

information within the catalog can be used by users to “shop” for services, by customers

and IT managers to understand what services are being or can be delivered to the customer

environment, and IT personnel to maintain relationships between services and high level

technical information.

The most common benefits of service catalog management include:

• A common understanding of IT services.

• Improved relationship between customer and service provider.

• Improved focus on customer outcomes.

• Improved efficiency and effectiveness of other service management processes.

• Improved knowledge, alignment and focus on the “business value” of each service.

156




One of the first decisions to be made regarding the service catalog is how it will be used. The

primary use of the catalog is as a marketing and communication tool when working with the

customer; however, here are some other uses:

• As a strategic assessment tool – to determine the service provider’s current capabilities in

service support and delivery and how they are used to achieve the objectives and outcomes

of the customer(s).

• As a design tool – to identify the different types of services and potential combinations as

service packages, displaying dependencies, interfaces and potential costs.

• As a risk assessment tool – to determine the extent of potential risks on individual services,

relationships, and dependences.

• As a shopping list (acquisition portal) – for users to determine what services are available to

them based on their position, role, and assigned duties.

• As a troubleshooting tool – used within incident and problem management to evaluate the

impact of incidents and problems on individual services, service packages, and customer

objectives and outcomes.

• As a self-help tool – use within request fulfillment to provide information about available

services and establish a portal for initiating service request: this portal can be extended

as part of incident and problem management to present user-capable resolutions and

workarounds to known errors.

• As a reporting tool – to organize measurements, metrics, and reports based on and included

as part of the presentation of services within the catalog.

10.3.5 Service Definitions

A service is defined as “a means of delivering value to customers by facilitating outcomes customers

want to achieve without the ownership of specific costs and risks” (Service Design, page 417).

While comprehensive, this definition is by far not complete from a service catalog perspective

because a service may be a construct of several services. To make things easier for the customer,


157

the customer/business view of the service catalog may display “service packages”: two or more

services combined to create a complete service for the customer. A technical view of the service

would exist which defines the individual “services” found in those packages.

Each organization has to determine what a “service” is and how I should be defined within the

service catalog. Because the service catalog is a customer-facing document or database, the

most promising place to start answering these questions is understand how the customer views

services and creating a definition consistent with those perceptions.

The service definition policy can be influenced by the following factors:

• The target audiences of the service catalog.

• How services are marketed to customers.

• How communication of the services with the customer is expected to proceed.

• How services are referenced by service provider personnel.

• How services are referenced by users of the services.

• How the service catalog will be used to provide information, support service requests and

managed services.

• Current culture, practices and maturity levels within the organization.

The best approach to defining and organizing services with the catalog is the use of a hierarchy,

where services as identified as either customer-facing or support services. Customer-facing

services are those IT services seen by the customer or user and may be resented as service

packages or the core service of the package: these services have a direct impact on the

outcomes designed by the customer. Support services are those services which underpin the

customer-facing services and are typically invisible to the customer or user. They are essential

to the delivery of the customer-facing services but do not directly impact the achievement of

outcomes for the customer. Support services can go by many names and, in many cases, are

shared across several customer-facing services.

158



The hierarchy can be used to begin understanding how to structure and present the service

catalog to its audience. In reality, not every bit of information contained within the catalog has

value to every person accessing the catalog: for instance, technical staff may take advantage of

the relationships identified between individual service components and the business outcomes

they support, but the technical detail of the service components is usually meaningless to

the end-user of the service. Even at the customer level, one business unit may have access to

a set of defined services which is different from those available to another business unit. For

this reason, many service catalogs are designed to contain a wealth of information with views

created to filter out non-essential information for specific audiences.

Many organizations choose to integrate the service catalog, service portfolio and the

configuration management system to establish a single comprehensive tool for service-related

information. In such as solution, individual services are managed as configuration items with

relationships, interfaces and dependencies identified. As an integrated solution, incidents,

problems, and changes to specific service components can be associated to the services

contained in the service catalog, providing a complete record of every planned and unplanned

occurrence related to the service(s).

In general, a service catalog will have two views minimum:

• Business/customer view – provides the business information about the service for use in

strategic planning, marketing, communication with the customer, and governance.

• Technical/support view – provides the detailed technical information about the service used

in service design, transition, and operation,


159

These basic views may be further divided into smaller units. The customer view can be designed

to distinguish between different customers, business units, locations, or other demographic.

The importance of the service catalog and the information contained within is justification for

ensuring the catalog is a major concern for IT service continuity. In the context of continuity, the

information contained within the service catalog must be accessible and useful should normal

pathways for access to the catalog be disrupted.


The activities of Service Catalog Management are rather simple and are performed in

conjunction with service portfolio management. They include:

• Documenting and agreeing upon a service definition and description for each service.

• Interfacing with service portfolio management to agree upon the contents of the portfolio

and catalog.

• Producing and maintaining an accurate service catalog.

• Interfacing with the business and ITSCM on the dependencies of business units and their

business processes with customer-facing IT services.

• Interfacing with support teams, suppliers, and service management process (specifically

service asset and configuration management) to define interfaces and dependences

between services, service components and configuration items.

• Interfacing with business relationship management and service level management to

ensure contained information is aligned to business objectives and business processes.

160




Service Catalog Management will be triggered by the following events:

• Changes to business requirements and services.

• Requests for change.

The inputs and outputs of service catalog management are summarized in the following table:

Inputs OutputsBusiness information from strategy, plans

and requirements

Documentation and agreement of service

definition Results of Business Impact Analysis,

specifically impact, priority and risks

associate with each service

Update to service portfolio, including

service status and requirements

Business requirements Updates to requests for changeService portfolio and related data and

documents

Service catalog and views

Configuration Management SystemRequests for changeFeedback from other processes


161

Service Catalog Management will interface with all service management process at some

level, especially when defining individual aspects of the service. The major interfaces with the

following processes:

• Service Portfolio Management – the service charter will initiate eventual inclusion of the

service in the catalog and will contain essential information for marketing and managing

the service.

• Business Relationship Management – manages the relationship between customer and

service provider which can be supported using the information contained within the service

catalog.

• Service Asset and Configuration Management – works collaboratively to ensure information

contained within the service catalog and the configuration management system are

appropriately and accurately linked.

• Service Level Management – negotiations the specific levels of service warranty with the

customer which is reflected in the service details contained in the service catalog.

• Demand Management – determines how services should be packaged and ensures those

packages are properly represented in the service catalog (performed in conjunction with

the service portfolio management).


The following critical success factors and key performance indicators are samples related to

Service Catalog Management. Each critical success factors has at least one key performance

indicators which is used to demonstrate achievement of the CSF.

• Service catalog is accurate

Ř Number of services recorded and managed in the service catalog is increases and

represented as a percentage of those being delivered and transitioned in the live

environment.

Ř The number of variances found in the “real world” and the service catalog are decreasing.

• Business users are aware of services being provided by the service provider

Ř Customer-facing views of the service catalog are increasing in completeness

162



(percentage).

Ř Business user survey resources showing knowledge of services listed in the service

catalog are increasing.

Ř Business user access to intranet-based service catalog is measured and increasing.

• IT staff is aware of the technology supporting the services

Ř Associations between services and IT components making up those services are

increasing in completeness (percentage).

Ř Access to information for service desk and other IT personnel is increasing, as determined

by the percentage number of incidents (problems, changes) with information from the

service catalog.


The challenges facing Service Catalog Management include:

• Maintaining the accuracy of the service catalog in collaboration with the service portfolio,

CMS and SKMS.

• Cultural resistance to the service catalog as a single source of information

The risks associated with Service Catalog Management include:

• Inaccuracy of data in the catalog.

• Lack of rigorous change control for data in the catalog.

• Poor acceptance of the service catalog.

• Misuse or failure to use the catalog appropriately in all operational processes.

• Inaccuracy of information received from business, IT and service portfolio.

• Insufficient maintenance of information due to unavailability of effective tools and

resources.

• Poor access to accurate change management information and processes.

• Poor access to and support of up-to-date CMS and SKMS.

• Circumvention of service portfolio and catalog.


163

• Information contained in service catalog is too detailed or too technical to be maintained or

demonstrate value to intended audience.

10.3.10 Summary of Service Catalog Management

The application of the service catalog in ContXT serves to identify those IT service which have

been formalized and introduced into the business environment. The catalog in this situation

addresses three issues:

• Employees of ContXT understanding and access the services which have been approved

for use in the environment; thus also identifying those services which have not yet been

formalized, approved, or available for use at any point in time.

• Executive management has a clear understanding of the relationship between the IT

services being delivered and the business objectives being met; thus enabling the Board

of Directors to determine progress, direction, and funding to establish competitive in the

market space(s).

• IT staff can associate service components with specific services, making support and

delivery of services easily monitored and managed; this include providing detailed

information about existing services to new hires or suppliers of IT services external to the

company.

Because of the current size of ContXT (less than 250 employees including IT), the service catalog

provides the basis for information which can be used effectively to build appropriate business

cases for future IT services or service strategies relative to the existing service offerings.

164




1. What state of services is mostly contained in the Service Catalog?

A. Retired

B. Operational

C. Proposed

D. Approved

2. What is the purpose of Service Catalog Management?

A. To generate and maintain a list and details of services available for use by the

customer

B. To manage services to fully realize the desired outcomes of the customer

C. To provide a high level outline for organizing information according to services

D. To provide senior management with sufficient information to make investment

decisions

3. What is the service catalog not responsible for regarding the information contained within

the catalog?

A. Establishing the interfaces and dependences between different services

B. Development and maintenance of service definitions

C. Ensuring contributions from service management process are accurately

represented in the service catalogs

D. The accuracy or validity of information generated and provided by service

management processes


165

4. What is the greatest value of a service catalog?

A. Having a common understanding of shared services

B. A central source for information on available services

C. Distinguishing available services from proposed services

D. Setting consistent expectations for customers regarding delivery and support of

services

5. Which of the following service management processes would not have a direct interface

with Service Catalog Management?

A. IT Service Continuity Management

B. Business Relationship Management

C. Problem Management

D. Service Portfolio Management

6. What is an output of Service Catalog Management?

A. Service Portfolio

B. Configuration Management System

C. Business Impact Analysis

D. Service Definitions

7. Which service management process works with Service Catalog Management to establish

and maintain meaningful relationships between definable service elements?

A. Service Portfolio

B. Service Asset and Configuration Management


D. Demand Management

166



8. Which of the following recommended KPIs for Service Catalog Management best supports

the critical success factor for an “accurate” service catalog?

A. The number of variances found and the “real world” and the content of the service

catalog are decreasing

B. A percentage increase in the number of customer-facing views of the service catalog

C. A percentage increase in the number of associated made between services and IT

components used to support those services

D. A percentage increase of the number of incidents and problems diagnosed using

information from the service catalog

9. Which of the following knowledge bases will not share information with the service catalog?


B. Known error database

C. Service knowledge management system

D. Configuration management system

10. What is not a risk of the Service Catalog Management process?

A. Inaccuracy of data

B. Poor access to CSM

C. Inaccurate measurement of services

D. Circumvention of service portfolio


167

10.5 Service Level Management

Service Level Management provides stewardship of four basic and interrelated concepts in IT

Service Management:

• Service level requirements – “customer requirement for an aspect of an IT service…based on

business objectives and used to negotiate agreed service level targets.”

• Service level targets – “a commitment that is documented in a service level agreements…

based on service level requirements, and are needed to ensure that the IT service is able to meet

business objectives.”

• Service levels – “measured and reported achievement against one of more service level

targets…sometimes used informally to mean service level target.”

• Service level agreements – “an agreement between an IT service provider and a customer…

describes the IT service, documents service level targets, and specifies the responsibilities of the IT

service provider and the customer.”

(All definitions above can be found on page 419 of the Official Service Design booklet.)

Requirements communicated from service strategy into service design tend to lack technical

meaning: for instance, a business requirement stated as “application is available to all authorized

personnel 24/7” would have more meaning technically if defined as “the application system

has a 98% availability service level target.” While the 98% service level may seem arbitrary, it

takes into consideration the investment into the service, the need for regular maintenance

and updates on service components, and the ability to respond to issues which may make the

service unavailable. Usually, the more a customer is willing to pay, the higher (or better) the

service level target.

168



Service level management is essentially responsible for establishing service level targets

which have meaning, documenting those targets into service level agreements, and obtaining

agreement over those targets from the service provider and the customer. The responsibilities

extend into the operational side of ITSM by ensuring that the service provider is indeed

achieving the agreed service levels. In this respect, service level management is a quality-

driven process; it establishes the criteria for quality for each service and ensures that quality is

obtained for each and every service.

The quality of the service portfolio and service catalog will directly impact the success or

failure of service level management, as the majority of information about the services will be

contained in these database or structured documents. These services will be managed by the

service level management process.

10.5.1 Scope

Service Level Management is the source of regular contact and communication with the

customer and the business managers of the service provider in regards to service levels. The

process represents the service provider to the customer/business and the customer/business to

the service provider. This interactivity can easily be confused with the purpose of the Business

Relationship Management process which is responsible for the relationship between service

provider and the customer at a strategic level. The truth is, both processes should be highly

integrated and, in some organization, the roles of business relationship manager and service

level manager are combined.

However, business relationship management is distinctly different from service level

management in that it determines what services will be delivered to the customers; while

service level management will determine the conditions (service levels) by which the services

will be delivered. Another way to look at this is business relationship management negotiate


169

and agree upon the requirements for service functionality (utility), while service level

management will do the same for the levels of services associated with agreed functionality

(warranty).

The primary deliverable of the service level management process is the service level agreement

(SLA). The service level agreement is between the service provider and the customer for the

level of service necessary to achieve the customer’s business objectives. An SLA is based on

service level requirements. Formally, a service may have multiple service level targets listed

in a single SLA document; however, the term SLA is sometimes used informally to describe

individual service level targets as in “availability SLA” or “performance SLA.” Additionally, a single

SLA document may contain targets associated with multiple services or multiple customers.

Within the context of scope, the service level management process is responsible for:

• Working with the business relationship management process to develop relationships with

the customer/business to achieve the process objectives of SLM.

• Negotiating and agreeing upon current service level requirements and targets.

• Negotiating and agreeing upon future service level requirements and targets.

• Documenting and managing service level requirements for all proposed new or changed

services.

• Documenting and managing service level agreements for all operational services.

• Developing and managing appropriate operational level agreements with service provider

or customer units to ensure targets are aligned with SLA targets.

• Reviewing all supplier agreements and underpinning contracts to ensure targets are aligned

with SLA targets.

• In conjunction with other service management processes, proactively preventing service

failures, reduction of service risks and improvements in service quality.

• Reporting and managing all service level achievements.

• Reviewing all SLA breaches.

• Reviewing, renewing, and/or revising all SLAs, OLAs, and service scope when appropriate.

170



• • Identifyingimprovementopportunitiesrelatedtoservices,servicemanagementand

service level management for inclusion into CSI register.

• Reviewing and prioritizing improvements in the CSI register.

• Instigating and coordinating SIPs for management, planning and implementation of service

and process improvements.

While service level management may be seen as the process for negotiating and managing

service level agreements with the customer, the process is also responsible for negotiating

and managing agreements with service support and delivery teams, in documents commonly

referred to as operational level agreements (OLA). To put this into context, service level

management may establish a service level target for service’s availability (98% service

availability) with a customer, but they are not responsible for the detailed systems and activities

necessary to meet this target. That responsibility lies with the technical team(s). However,

service level management must be assured that the technical team(s) are aware of and can

meet the agreed service level targets. To this end, service level management will negotiate

operational level agreements which are aligned to the service level agreements with the

customer.

Technical teams will be responsible for multiple components necessary to support a service.

In many organizations, different technical teams are responsible for different components, or

different aspects of the service. For instance, a network team will ensure connectivity, a storage

team will provide memory and security for stored data, and a server team will provide system

administration for a variety of services, and so on. Technical teams can reside internally to the

service provider organization and externally as part of the customer organization or third-party

supplier. If the technical team resides with the customer, SLM will likely establish an OLA which

goes into greater technical detail than the SLA. Agreements with third-party suppliers are not

within the scope of service level management, but in the process for supplier management;

however, supplier agreements must align with existing SLAs with the customer.


171


The purpose of Service Level Management is to ensure all new, existing, and planned IT services

are delivered according to agreed achievable targets. The process begins with negotiating and

agreeing upon service level targets: that is the warranty aspect of the service relative to each

functional requirement (utility). The process continues through monitoring, reporting, and

reviewing IT service targets and their achievement. If service targets are not being achieved, the

service level management process will instigate corrective or improvement actions to resolve

the issues.

The progression of the service level management process is not linear, but cyclical. Changes

in the customer environment or the service environment may result in renegotiating service

targets: for instance, the customer may not be able to continue to afford a high, unnecessary

service level or the service provider may have adopted new technology and techniques which

allow a higher SLA at no additional cost.

The objectives of Service Level Management are to:

• Define, document, agree, monitor, measure, repot and review the level of IT services

provided.

• Initiate corrective measures when service level targets are missed.

• In conjunction with Business Relationship Management, provide and improve the

relationship and communication between the service provider and the customer.

• Ensure each IT services has specific and measureable targets.

• Monitor and improve customer satisfaction with the quality of service delivered.

• Set a clear and unambiguous expectation of the level of service to be delivered for both IT

and the customer.

• Ensure proactive, cost-effective continual improvement is applied to levels of service, even

when those levels are being met.

172




Service Level Management sets expectations for the customer and the service provider(s) in the

form of agreed service level targets. The process also establishes the management framework to

ensure these targets are met and to manage any issues regarding service levels.

Service level management continues the relationship between customer and service provider

at a tactical level; thus bridging the strategic and operational aspects of service delivery and

support. SLM ensures that the customer’s desired objectives are met through the consistent

application of IT service assets toward the achievement of service level targets.


Policies related to service level management will focus on criteria to be met when performing

activities, such as:

• Required content within an SLA.

• Acceptable structure for SLA documents (containing multiple services or customers).

• Required content within an OLA.

• Alignment with Business Relationship Management policies and practices.

• Alignment with Supplier Management policies and practices.

• Alignment with Service Catalog Management policies and practices.

• Service reporting – content, frequency, audience.

• Service reviews – content, frequency, audience.

How service level management, as a process, is approached will be defined by the type of

service provider the organization is. For instance, a type I or II service provider will be internal to

the customer (corporate) organization, so service level agreements will not be legally binding as

they describe the internal operations of the organization. However for a type III service provider

who is externally, the SLA is legally binding and may be attached to a contract as a schedule


173

or specification detailing the agreed services (functionality) to be provided. Additionally, a

service provider whom relies heavily on the resources and capabilities of third-party suppliers

may seem to need service level management less, but, in truth, the importance doesn’t change

because SLM focuses more on the relationship between customer and service provider, not

supplier and service provider. However, in this situation, SLM may have greater focus on the

monitoring and management of service delivery over the need to establish OLAs.


The primary activities of Service Level Management include:

• Determine, negotiate, document and agree upon service level requirements for new or

changed services.

• Managing and reviewing service requirements as defined in service level agreements.

• Monitoring and measuring service performance and achievements against agreed targets

documented in SLAs.

• Producing service reports.

• Conducting service reviews.

• In cooperation with business relationship management, collating, measuring and improving

customer satisfaction.

• Reviewing and revising SLAs, service scope and OLAs.

• Assisting supplier management with reviewing and revising underpinning contracts and

supplier agreements.

• In cooperation with business relationship management, developing and documenting

contacts and relationships with the business, customers and other stakeholders.

• In conjunction with business relationship management, logging and managing compliances

and compliments.

• Providing management information necessary for effective performance management and

demonstrating service achievement.

174



Within the context of service design, service level management is responsible for:

• Designing SLA frameworks.

• Developing, maintaining and operating SLM procedures, including handling of complaints

and compliments.

• Developing and maintaining up-to-date SLM documents templates and standards,

including service reports.

• Assisting with the design and maintenance of the service catalog.

10.5.6 SLA Framework and Documentation

The service catalog provides a good foundation for structuring the customer-facing and

supporting services to be delivered to the customer and will provide information about the

functional aspects of those services. The service level agreement framework (SLA framework,

framework) will expand on this foundation by associating the warranty or quality with the

individual services and service packages.

The SLA framework simply defines how service level agreements are approached and there are

three basic methods for doing so:

• Service-based SLAs – the service level agreement covers a single service or service package

for all customers of the service. A single approach as long as all customers have the same or

similar requirements for the service; this type of SLA is best for shared services which have

lower risk or variance in expectations, like an email service or Service Desk service. These

shared services may have increasing classes of coverage, such as bronze, silver and gold

packages with increasing levels of services.

• Customer-based SLAs – the service level agreement covers all the services or service

packages delivered to a single customer. This approach is especially suitable to customers

which have several distinct customer assets which support their core business processes.

The greatest benefit of this approach is the need for fewer (usually one) signatory for the


175

agreement.

• Corporate-based SLAs (or Multi-level SLAs) – most complex form of service level agreement

is a multi-level SLA usually found with a corporate customer with several individual business

units. In this approach, the SLA will first deal with service levels which are common to every

customer in the corporation: a common example is the development, implementation

and adherence to an Information Security Policy. This corporate-based SLA is similar to the

service-based SLA. The multi-level approach will then handle all customer-specific service

level requirements and issues coming from the individual business units and is similar in

focus to the customer-based SLAs. Finally, the multi-level approach will handle any service

level requirements and issues related to a specific service for a specific customer.

Information Security Management is a good subject for demonstrating the benefits of the

multi-level SLA. As already mentioned, the Information Security Policy is a subject that is

important at a corporate level to ensure the confidentiality, integrity and availability of data and

information used within the customer’s business processes. Service levels may detail when the

policy is implemented, reviewed, audited, and updated, as well as targets for compliance by

personnel in the customer and service environments.

Moving down to the customer level, the most prominent department for information security

is the company’s financial department. While the corporate SLAs will cover all information

and data, the financial department is particularly concerned with financial information and

data: which is heavily legislated and regulated (consider Sarbanes Oxley). The service provider

can develop additional requirements regarding financial data and systems: a couple of

prominent requirements concerns auditing and data retention. With the policy, auditing refers

to compliance with the information security policy; but in the context of financial regulation,

auditing refers to compliance to external legislation and regulation.

176



The financial department is responsible for several processes and systems, including general

financing, accounting, payroll, billing, procurement, etc. Each process, from a business

perspective, may have a natural cycle based on the practices of the company. For instance,

payroll may increase demand on IT resources and capabilities once every two weeks or month

based on when the customer’s employees are paid, or the billing cycle may be once or week, or

monthly. These business cycles will feed information needed to establish patterns of business

activity which is used to understand the demand, capacity, availability and performance

requirements of the service(s). For service level management, these patterns may drive different

requirements and issues specific to each service delivered to the financial department.

The service provider must first determine what approach they will take in generating and

organizing service level agreements. The best approach will allow individual SLAs to be easily

manageable, avoid duplication, and reduce the need for frequent updates. However this tends

to lead to far more SLAs whose relationships been to be established and maintained within the

service catalog and the configuration management system.

In addition to the structure of the framework, the service provider has an opportunity to

establish standards, templates, and pro-forma. This ensures that every service level agreement

is developed, used and maintained in a consistent manner; thus reducing effort, confusion, and

costs. The content of SLAs must be clear, concise, and unambiguous; though there is usually

no need to include highly legal or technical language as this may prevent understanding from

all parties. All SLAs should have a glossary which defines any terms and prevents ambiguity.

In addition, some SLAs will cover services provided internationally and must be translated

correctly in different languages. The use of standards and templates are an excellent way of

addressing these issues proactively.

Once the SLA framework has been established and is agreeable by the customer, the work

of service level management begins with documenting and agreeing upon service level

requirements (SLRs). An SLR is a customer requirement on an IT service and is based on business


177

objectives: for instance, a business requirement may be communicated by the customer as

XYZ system must be available to all personnel in the accounting department in order to ensure

financial responsibility for business operations. Several SLRs may be derived from this statement

and further information, such as:

• Availability service level stated as a percentage.

• Business hours for accounting department hours 8 hours, Monday-Friday.

• No remote access to the system is allowed outside the site or business hours.

• Data security must be compliant with Sarbanes Oxley legislation.

• Business Impact Analysis regarding XYZ system shows it is a highly critical system with a

potential financial impact of $150K loss in productivity and fines.

The establishment of service level requirements is an integral part of the service design

stage and the criteria used to accept the service throughout the entire service lifecycle.

The achievement of SLRs will influence the design of the service, should be tested before

deployment, and effectiveness and satisfaction in an operational state be monitored. Because

SLRs are customer requirements, it is best to include the customer in their development; and

representatives from technical teams or processes should also be involved.

Deriving true service level requirements may be difficult. The example above began with a

customer statement of a requirement which needed to be translated into language suitable for

understanding what was required of the service. In many cases, the customer may not know

what they want, in terms of capacity, security, availability or IT continuity. At the same time, they

may not fully understand the constraints related to support specific SLRs: for instance, a high-

performance solution to address an SLR will usually cost more than most customers suspect

and a balance must be negotiated. The final set of SLRs and associated service level targets for

a service is based on negotiations with the customer which establish a balance that works for

both customer and service provider.

178



Service level agreements contain those SLRs and service level targets which have been

documented and agreed by the customer and service provider. These requirements and targets

are used to establish agreements with technical teams in the form of OLAs and suppliers in

the form of underpinning contracts. The relationships between SLRs, SLAs, OLAs, and service

components must be documented in the configuration management system so that the impact

of a change in one can be traced and addressed.

Negotiations on service level agreements are not a one-sided affair: the service provider must

be able to effectively achieve the service level targets. This will require monitoring, measuring,

and reporting on current levels of service to demonstrate the capabilities of the service provider

in relation to the SLRs. The service provider may also want to avoid accepting service targets

which they do not currently measure or cannot be adequately measured. With the introduction

of new services, technology, or processes, a pilot SLA may be established and finalized in the

early life support period of the service transition: this enables the customer to obtain what they

need while the service provider can demonstrate what they can provide. However for existing

services, a final SLA may be established before service transition is initiated.

10.5.7 Service Monitoring and Reporting

If a requirement or target cannot be effectively monitored and measured, it should not exist

within the service level agreement; if included, these requirements and targets can lead to

confusion, disputes and loss of satisfaction with the service and the provider. However, the

service provider should regularly review and upgrade existing monitoring capabilities so that

these requirements and targets can be monitored and measured. These improvements should

occur in parallel with or before drafting SLAs.


179

Monitoring of a service against SLA should be consistent with the customer’s actual perception

of the service: for example, loss of service availability for the customer may be affected by the

loss of a single function of the service rather than the entire service or poor performance rather

than accessibility to the service. Technically, monitoring of service performance can be difficult,

especially in relation to transaction response time—the time between sending a request and

receiving a response such as after a person enters a web address in their browser. To overcome

the technical difficulties of monitoring, the service provider and customer may negotiate

alternative targets, such as:

• A delay in response time of more than x seconds experienced for more than y minutes

should be reported immediately to the service desk.

• A tolerance target for the type and number of incidents reported for a specific time period.

• The logging and accurate categorization of incidents related to “poor response” against each

service.

• The report and subsequent investigation for any breach of transaction response time

targets.

Improved monitoring capabilities can be reached through the use of automation, sampling

or “robot” tools and techniques, and process refinements. SLA monitoring issues also impact

service reporting: if something cannot be monitored or measured, it cannot be reported

accurately. Service reporting incorporates a number of different types of reports, including:

• Operational reports – frequent reporting of current status of services against SLAs and

usually associated with service components and/or aggregated to reflect the entire service

or service package.

• Exception reports – identifies any broken or threatened SLA in the service.

• Management (interim) reports – aggregate reports demonstrating the achievement of SLAs

used by IT management.

• Customer (periodic) reports – aggregate reports demonstrating the achievement of SLAs.

• Summary report (balance scorecard, RAG charts) – high-level, color-coded report of

achievements against targets for quick review without detailed explanation.

180



Every service report must be clearly defined, including:

• Description.

• Audience.

• Frequency.

• Format.

The customer should agree to the frequency and format of their reports. The production of

reports, particularly customer reports, should coincide with periodic service reviews: reports

should be delivers a few days, but no less than 24 hours, before the review. A significant number

of resources are required to produce and verify reports and the process can be time-consuming.

Reports need to provide enough information to prevent misinterpretation without providing

too much detail that the audience is overwhelmed by data.

Service reporting should also collate and measure customer satisfaction. This area of service

delivery cannot be monitored through tools but is the product of active inquiry with the

customer and user population. For SLM, the focus is on satisfaction related to service warranty.

The work in customer satisfaction begins with setting expectations regarding service targets,

then ensuring the resources and capabilities of the service provider can meet these service

targets. Next, the SLM, in a collaborative effort with the BRM and the Service Desk, will ascertain

the customer’s perception of the service through feedback mechanisms such as:

• Questionnaires and surveys.

• Service review meetings.

• Post-implementation reviews.

• Telephone perception surveys.

• Feedback handouts.

• User group or forum meetings.

• Analysis of complaints and compliments.


181

10.5.8 Service Reviews and Other Reviews

On a regular basis, the service provider should review service achievement(s) with the

customer. A service review is performed for each core service or service package delivered to

the customer. The frequency of the review should be the end of an operational period, typically

each month; however, low-risk, low-priority services may be reviewed every quarter.

The agenda for these service reviews will usually encompass three broad topics:

• Status on all outstanding issues and action items from the last service review.

• Performance and achievements of service over the last operational period.

• Potential issues and changes for the service over the next operational period(s).

The purpose of the service review is to communicate the performance and achievements of

the service against agreed targets, to gauge customer satisfaction and continued value for

the service, and to identify potential improvements for the service. Generally speaking, every

service review should produce a set of action items assigned to both the customer and the

service provider to be completed within the next operational period. In this sense, the service

review becomes a means of facilitating collaboration between the two parties, which in turn

builds relationship and trust.

When reviewing the performance of the service over the last operational period, the topic

of major importance is any breach of service level, particularly in determining the cause

of the breach and what can be done to prevent its recurrence. In many causes, problem

management may already be initiated to investigate the issue and derive a resolution, which

is simply communicated at the review meeting. Other times, engaging problem management

may need to be authorized by the participants of the service review. The relationship with

problem management needs must be an agreed policy for the service provider. Another

option for participants to determine is if the service level target is achievable and it needs to

be renegotiated. In any case, the service provider will benefit from gathering the necessary

182



information about the breach before the meeting. The decisions made regarding the breach will

potentially result in service improvement projects (SIPs).

The service review is also an opportunity to discuss the future of the service, in relation to

changes in demand, infrastructure, or process. This information can be communicated by either

the customer or the service provider but should be focused specifically on the service at hand:

any other communications should be made through business relationship management, and

specific requests for change should be referred to either service portfolio management or

change management. At times, these communications may be made months in advance, while

the majority will probably focus on the next operational period.

In addition to service reviews, service level management may be responsible for or participate

in reviewing and revising the following:

• Service scope.

• SLAs.

• OLAs.

• Underpinning contracts.

The purpose of these reviews (SLA reviews, OLA reviews and contract reviews) is to determine

the strategic and tactical value of the service and how the service is delivered to the customer.

While using information generated for the operational service reviews, the focus of this review is

to determine if the service is properly scoped and the existing agreements related to the service

are appropriate to generating the value needed from the service. Generally, these types of

reviews are performed less frequently than service performance reviews but are still performed

regularly, usually annually. In some cases, the objectives of both reviews can be reached during

the same meeting.


183

Because of the nature of the review, business relationship management may be responsible for

facilitating the review; however, service level management performs a major role because of its

responsibilities toward all types of agreements. If third-party providers are involved in service

delivery and support, they are represented through the supplier management process (supplier

manager).

In some situations, this review of agreements is triggered because one, or all, of the agreements

are coming to the end of their contract life. Usually, the only participants involved in the

review are service provider personnel, who must determine if the service and its associated

agreements are still relevant, comprehensive, and aligned to current needs and strategies of

the business and customer. The meeting has to consider changes within the customer and the

service provider environments.

Success of these reviews can be improved by placing all agreements and components

of a service under change control and recording them as configuration items within the

configuration management system. This does two things. First, changes to any configuration

item must be evaluated to determine the impact and ensure compliance to current agreements,

as well as maintain alignment to business objectives. Second, the configuration management

system establishes the relationships between individual configuration items, thus making it

easier to determine the impact of changes across the agreements and constituent components.

184



10.5.9 In Cooperation with Business Relationship Management

Already, the importance of the relationship between service level management and business

relationship management can be clearly demonstrated. In most cases, a pull from one process

will instigate a response from the other process. In this context, there are two other areas where

efforts from both processes can be pooled to produce a more effective outcome:

• Managing contacts.

• Complaints and compliments.

It should be noted that while ITIL 2011 seems to place more responsibility for these areas on

service level management, the international standard of ITSM, ISO/IEC 20000, places more

responsibility on business relationship management. In practice, the responsibility is shared and

may be the primary reason why the business relationship manager and service level manager

roles are assigned to the same person in some organizations.

In managing contacts, the following activities should be performed:

• Confirm stakeholders with BRM, including customers, key business managers and service

users.

• Assist in maintaining accurate information in the service portfolio and service catalog.

• Respond appropriately to the needs of business, customers and users; understand current

and planned business processes and their service requirements and communicating

(documenting) those requirements to all other processes.

• Understand the strategies, plans, needs and objectives of the business, customer, and user.

• Regularly evaluating the service from the customer perspective (becoming the customer/

user in order to experience the service from the receiving end).

• Ensure relationship processes are in place to achieve objectives.

• Conduct and complete customer surveys and participate in analysis of completed surveys.

• Represent IT in organizing and attending user groups and forums.

• Market and exploit the service portfolio and service catalog.

• In cooperation with the business, customers and users, actively ensure IT provides the most


185

appropriate levels of service to meet current and future needs.

• Promote service awareness and understanding.

• Raise awareness regarding business benefits derived from exploitation of new technology.

• Facilitate the development and negotiation of warranty requirements.

• Ensure all parties (business, customer, users and service provider) understand their

responsibilities and commitments.

• Assist in the maintenance of the CSI register.

The other area of cooperation with BRM is the establishment of a complaints and compliment

procedure, which includes the proper path for escalating issues. The logging of complaints

and compliments is similar to incident management and request fulfillment and therefore may

be part of the duties of the service desk. Escalation will be based on the service and subject

matter. Any complaints and compliments regard service levels will be managed by service level

management; therefore there has to be a means of identifying such items, whether they are

escalated to the service level manager or they are categorized within the record and escalated

to the appropriate service owner or IT manager.


Service Level Management will be triggered by the following events:

• Changes to the service portfolio.

• New or changed agreements, SLRs, SLAs, OLAs, or contracts.

• Service review meetings and actions.

• Service breaches or threatened breaches.

• Complaints and compliments.

• Reviews, reports, and customer satisfaction surveys.

• Strategy or policy changes.

186



The inputs and outputs of service level management are summarized in the following table:

Inputs OutputsBusiness information, from strategies, plans

and requirements

SLAs, OLAs, and SLRs

Results of Business Impact Analysis Service reportsBusiness requirements Service improvement opportunitiesService strategy, policies and constraints Service improvement plansService portfolio and service catalog Service quality planChange information Document templates, including SLA, SLR,

and OLA format and content guidelinesConfiguration management system Reports on OLAs and underpinning

contractsCustomer and user feedback, complaints

and compliments

Service review meeting minutes and

actionsCSI register documented improvement

opportunities

SLA review and service scope review

meeting minutes and actionsInput from other service management

processes

Updated change information

Revised requirements for underpinning

contracts


187

The major interfaces for Service Level Management are with the following processes:

• Business Relationship Management – manages the relationship between customer and

service provider and ensures customers are properly involved or represented in the work of

service level management.

• Service Catalog Management – provides accurate information about services and their

interfaces and dependencies which is reflected and updated though the SLA framework,

and identifies the customer/business units who should participate in the work of service

level management.

• Incident Management – provides data related to the performance of services against many

SLA targets.

• Supplier Management – collaborates with service level management to define, negotiate,

document and agree to terms of service with supported to support the achievement of

agreed SLAs with the customer.

• Availability Management – contributes to service level management by defining service

level targets for availability and to validate targets are realistic given the current and future

plans for availability management.

• Capacity Management – contributes to service level management by defining service level

targets for capacity and performance and to validate targets are realistic given the current

and future plans for capacity management.

• IT Service Continuity Management – contributes to service level management by defining

service level targets for business and IT continuity and to validate targets are realistic given

the current and future plans for IT service continuity management.

• Information Security Management – contributes to service level management by defining

service level targets for IT security and to validate targets are realistic given the current and

future plans for information security management.

• Financial Management for IT Services – validates the predicted cost of delivering services at

the designed service levels and ensures actual costs are compared with predicted costs as

part of effective ITSM.

• Design Coordination – works with service level management during the service design

stage to define and develop service level requirements and targets.

188




The following critical success factors and key performance indicators are samples related to Service

Level Management. Each critical success factors has at least one key performance indicators which is

used to demonstrate achievement of the CSF.

• Manage the overall quality of IT services required by the customer (usually measured in

terms of number and level of service).

• Decreased percentage in threatened SLA targets.

• Increased percentage of customer satisfaction with SLA achievements.

• Decreased percentage in SLA breaches caused by suppliers as represented by underpinning

contracts.

• Decreased percentage of SLA breaches caused by internal technical teams as represented

by OLAs.

• Deliver agreed services at affordable costs.

• Total number o and increased percentage of fully documented SLAs in place.

• Increased percentage of agreed SLAs against operational services in live environment.

• Decreased percentage in costs associated with service provision.

• Decreased percentage in the cost of monitoring and reporting SLAs.

• Increased percentage in the speed completing the development and agreement of SLAs.

• Frequency of service review meetings.

• Manage the interface between the business and users.

• Increased percentage of services covered by SLAs.

• Existing SLM processes and procedures are documented and agreed.

• Decrease in the time required to respond to and implement SLA requests.

• Increased percentage of SLA reviews completed on time.

• Decreased percentage of outstanding SLAs for annual renegotiation.

• Decreased percentage of SLAs requiring corrective changes.

• Increased percentage of Current OLAs and third-party contracts.

• Evidence exists that issues that were raised at service and SLA reviews are being followed up

and resolved.

• Reduction in the number and severity of SLA breaches.

• Effective review and follow-up of all breaches to SLAs, OLAs, and underpinning contracts.


189


The major challenge for service level management is identifying the appropriate person(s)

to negotiate an agreement. Sometimes, the person who is initially identified to negotiate the

agreement are located organizational or geographically from the customer based most affected by

the service. Only negotiation with this person(s) may establish a service which is strategically and

financially beneficial but generates no real value because it is created within input from the people

who will be using the service. Conversely, the person(s) may be deeply immersed in the business

processes being supported, but have little to no idea of the strategic significance of the proposed

service. This may start the service provider on a path to implement a service which is not funded, a

duplicate of an effort elsewhere, or will be irrelevant in the future.

This challenge promotes the need to consult different people from several levels of the organization,

including within the service provider; though efforts should be made to find a single person

responsible for signing the SLA officially. However, this attempt to gain information from the

collective organization has its own challenges, including:

• The level of familiarity with the SLM process.

• The difference of perception regarding objectives and requirements from distinct levels of

the organization.

• The possible exclusion of key stakeholders.

• The lack of historical data regarding specific SLAs.

The risks associated with Service Level Management include:

• Lack of input, involvement and commitment from the business and/or customers.

• Lack of appropriate tools and resources necessary to execute and complete the SLM process

effectively.

• The process because increasingly bureaucratic and administrative.

• Lack of access to appropriate information in the CSM/SKMS

• The SLM process is bypassed.

• The difficulty in measuring and improving business and customer measurements which

190



results in the lack of accurate reporting.

• Inappropriate business and customer contacts and relationships developed.

• Customer expectations are high and perceptions are low.

• Communication between business and customers is poor and inappropriate.

10.5.13 Summary of Service Level Management

Support of ContXT has identified several services which must be formalized, developed and

deployed. One such service revolves around the development of video conferencing capabilities:

a service which requires the appropriate hardware (television screens, projectors), infrastructure

(network), software (interface), and administrative (scheduling) requirements. The intent of

video-conferencing from a business perspective is to improve customer/client relationships and

supporting weekly status on marketing projects.

While the functional requirements of the service is the provision of video conferencing, the

warranty requirements have not been fully established, which is where service level management

participates. Demand management identified that there are an average 35 marketing projects in

progress simultaneously. The plan is to have a weekly meeting between the business and each

client. ContXT facilities currently have five conference rooms, but only one has hardware to support

video-conferencing which is used predominately for multimedia presentations. The weakest area

for ContXT at this time is administratively, as the company does not have the proper scheduling

capabilities to managing an increase in meeting using video-conferencing.

Service level management will negotiate and document service level requirements for this service

with the different business units in ContXT. The final signatory will be a representative of top

management. Once agreed, OLAs will be established to identify exactly what the technical teams

(all three people currently) will be required to do in order to support the service, including what

infrastructure to procure and install, on-site support and maintenance, and software and network


191

capabilities. Third-party support of the telephony and network capabilities will likely be required

and contracts needs to be updated or obtained to address the new service requirements. Third-

party solutions may be available to provide the software and administrative functions required for

the service.

Service level management will be accountable for ensure all the related parts of service delivery

and support are working together to provide the service most desired by the customer and agreed

within the documented SLAs. Each month a review of the service will be conducted to address any

issues experienced by the customer and/or the IT department.

192




1. Service level requirements typically cover what aspect of the service requirements?

A. Utility

B. Functionality

C. Value

D. Warranty

2. What service management process must Service Level Management work closely with to

define and agree on customer requirements on service operations?

A. Supplier Management

B. Business Relationship Management

C. IT Service Continuity Management

D. Demand Management

3. What is the primary output of Service Level Management?

A. Operational level agreements

B. Service level targets

C. Service level agreements

D. Service requirements

4. What type of SLA framework will often identify service packages as gold, silver, or bronze

options to the customer?

A. Service

B. Customer

C. Corporate

D. Multi-level


193

5. What type of SLA framework allows for greater customization in service delivery and

support to a specific customer?

A. Service

B. Customer

C. Corporate

D. Multi-level

6. What type of service report is used to identify breaches in SLAs exclusively?

A. Operational reports

B. Customer reports

C. Exception reports

D. Summary reports

7. What is not covered within a service review conducted by Service Level Management?

A. Achievements from the previous reporting period

B. Upcoming issues in the next reporting period

C. Improvements and compliance issues current experienced by the service

D. Overall customer satisfaction in relationship with service provider

8. Which of the following will be subject to revision after a service review?

A. OLA

B. SLA

C. SDP

D. Service Scope

9. What is not a trigger of the Service Level Management process?

A. Changes to service design

B. Breach of SLA

C. Service Complaints

D. Changes to service portfolio

194



10. Which of the following is an output of Service Level Management?

A. Business Impact Analysis

B. Service reports

C. Business requirements

D. Risk assessment

11. What is the primary challenge for Service Level Management?

A. Identifying the right person to negotiate service levels

B. Management commitment to service levels

C. Perceptions in the distinctions between objectives and requirements

D. Lack of historical data regarding achievement of service targets


195

10.7 Availability Management

Availability of a service is a critical component of the delivery and support of the service

and greatly impacts the customer’s perception of the service and the service provider. The

value of the service is directly impacted by the level of availability of the service. Availability

is sometimes viewed as a binary component: the service is either up or down. However, this

perspective is misguided as a service may be partially available because some functionality is

available while functionality is not. Additionally, the perception of a service’s availability may be

skewed if performance levels decrease dramatically: for instance, not enough bandwidth will

cause the service to slow to a crawl and cause greater unproductivity for the customer.

The level of availability required for a service is negotiable and considers what the customer

needs to be productive, the cost of providing the service to meet these needs, and how

resources are actually used. Though service level management is responsible for the negotiation

of suitable SLAs, the experience and knowledge related to availability solutions does not

reside within the scope of the SLM process: therefore a reliance on availability management

is necessary to ensure the proper utility and warranty from this perspective. Availability

management goes beyond the SLM process to ensure the delivery and support of services is

delivered according to defined SLAs.

Availability is a concern for all aspects of IT, usually at the component level but also across

several disciplines of IT, including server, network, applications, etc. In this respect, availability

management is a process for all technical teams in the service provider. However, availability

management has a planning and an operational aspect to it, similar to the service lifecycle

stages of service design and service operations. Within this context, architects and planners may

be dedicated to the creation of availability plans and systems which are executed by operational

personnel, such as system administrators. How the division of duties is assigned is based on the

structure of the organization.

196




The purpose of Availability Management is to ensure the services are delivered at a level of

availability consistent with the agreed availability needs and/or service targets and done so in a

timely and cost-effective manner.

The objectives of availability management include:

• Production and maintenance of up-to-date availability plan(s) reflecting the current and

future needs of the business.

• Advice and guidance availability-related issues to all areas of the business and IT.

• Managing services and resource-related availability performance to meet all service

availability targets.

• Assisting the diagnosis and resolution of availability-related incidents and problems.

• Implementing proactive measures to improve the availability of services.

10.7.2 Scope

Availability management covers the lifecycle needs of IT service and service component

availability, including:

• Design.

• Implementation.

• Measurement.

• Management.

• Improvement.


197

The execution of the availability management process begins when the requirements regarding

service availability can be articulated clearly and continues until the service is decommissioned

or retired. There are two elements to availability: reactive and proactive. Reactive availability

management are tied to event, incident and problem management and focuses on monitoring,

measuring, analyzing and managing the achievement of availability targets in the operational

environment. Proactive availability management is concerns with the planning, design and

improvement of service availability. Naturally, the initiation of the availability management

will begin with proactive activities before reactive; however there are times when reacting to a

major outage or missed availability target, a proactive approach must be taken.

Availability management is concerned with the availability of the services as well as the

components used to deliver and support the service. The premise behind this is a reflection of

the service’s value chain: if one link of the chain is unavailable, the entire chain is unavailable.

However, the true impact of availability is dependent on understanding the requirements from

a business perspective: to build this understanding, the service provider needs to know (the

primary sources for this information are in parenthesis):

• Current processes of the business, their operation and requirements (Demand

Management).

• Future plans and requirements of the business (Business Relationship Management).

• Service targets and current IT service operation and delivery (Service Level Management).

• IT infrastructure, data, applications and environment and their performance (Service Catalog

Management).

• Business impact and priorities (IT Service Continuity Management).

Using this information, the availability management process is able to:

• Support all operational services and technology, specifically those covered by SLAs.

• Support all business-critical IT services.

• Support all new IT services and existing services which SLRs and SLAs have been defined.

• Support all supporting services, as well as partners and suppliers.

198



• Support all aspects of an IT service, their components, and participating organizations,

specifically regarding training, skills, process effectiveness, procedures and tools.

The scope of the availability management process includes:

• Monitoring all aspects of availability, reliability, and maintainability of IT services and

supporting components.

• Maintaining a set of methods, techniques and calculations for all availability measurements,

metrics and reporting.

• Assessing and management risks related to availability.

• Collecting and analyzing measurements for inclusion in regular and ad hoc reports

regarding service and component availability.

• Understanding current and future demands on the business for IT services.

• Participating in the design of services and components to align with business availability

needs.

• Establishing an availability plan.

• Maintaining a schedule of tests for service and component availability.

• Assisting incident and problem management in the identification and resolution of

incidents and problems related to service and component availability.

• Improving service or component availability.

The complexity of IT service continuity and its directly relationship with business continuity

planning is the focus of IT service continuity management (ITSCM), not availability

management; however, the information generated and analyzed as part of availability is

invaluable to the success of ITSCM and the two processes are tightly coupled, especially in the

area of risk management.


199


Availability management ensures that the services necessary to support the customer in

fulfilling their business objectives and outcomes are available when the customer needs them.

In this context, the availability management has a direct impact on customer satisfaction and

the service provider’s reputation in the market.

No other process within the service management process suite has the direct influence on

customer decisions than availability management. Though it may be argued that incident

management as executed by the Service Desk could have the same level of influence, an equally

enticing argument can be made that the success of availability will reduce any exposure to

incident management by the customer.


Simply put, availability management is concerns with ensuring the design for all new and

existing services are appropriate to meet agreed availability targets, without impacting service

performance, and ensuring all services are meeting those targets when in an operational state.

Because of the importance of availability, the process places a part in all stages of the service

lifecycle. In truth, the topic of availability covers four important aspects (Service Design, page

128–129).

• Availability – the “ability of a service, component or configuration item to perform its agreed

function when required.”

• Reliability – a “measure of how long a service, component of configuration item can perform its

agreed business without interruption.”

• Maintainability – a “measure of how quickly and effectively a service, component or

configuration tem can be restored to normal working after a failure.”

• Serviceability – the “ability of a third-party supplier to meet the terms of its contract.”

200



The topic of availability usually encompasses two interrelated levels: service and components

supporting the service. However, service and component availability can be further categorized

to reflect it criticality to the business process, in what is termed as a vital business function

(VBF). In the example used by ITIL, the VBF of an ATM (automatic teller machine) is the machine’s

ability to dispense cash, not its ability to produce a receipt. Using this as a context, a service’s

VBF(s) would usually have higher availability targets and require special designs to meet those

designs. Different designs for availability include:

• High availability – a service characteristic which attempts to minimize or hide the effects of

IT component failure to the service user.

• Fault tolerance – the ability of a service, component or configuration item to continue

operating normally even when one of its component parts has failed.

• Continuous operation – a design approach which eliminates the planned downtime of an IT

service, even when individual components supporting the service are unavailable.

• Continuous availability – a design approach which strives to obtain 100% availability for the

service, thus eliminating all planned and unplanned downtimes for the service.

The design and operational effort in availability management is carried out under a few guiding

principles:

• Service availability is at the core of customer satisfaction and business success.

• The way a service provider reacts to unplanned failure of a service, component, or

configuration items has significant impact on customer and user perception and

expectations.

• Improvements in availability are possible only after the service provider clearly understand

how IT services support the customer’s business operations.

• Service availability is only as good as the weakest link in the service chain (value chain).

• The maturity of a service is improved through proactive availability management more than

reactive.

• Designing the right level of service availability to a service is “cheaper” than building up

capabilities of the service in its operational state.


201

10.7.5 Process Activities – Reactive Availability Management

The activities comprising the reactive aspect of availability management are tightly coupled

with the activities of other service management processes, particularly:


• Event Management.

• Incident Management.

• Problem Management.

The foundation of the activities is continuous monitoring of the operational service to ensure

it is delivering on the agreed levels of availability and responding appropriately when they

do not. The first half of this premise requires monitoring, measuring, analysis, reporting and

reviewing of all service and component availability; which is done in cooperation with service

level management and event management for agreed service targets and auxiliary targets. The

second half of the premise is done collaboratively with incident and problem management

which provides the processes to investigate failures in availability and initiating remedial action.

Reactive availability management is primarily an effort within the context of service operation.

The measurement and reporting of IT availability is the primary output of availability

management and are typically included as part of every SLA, OLA and underpinning contract.

These measurements must be reviewed at every service review. Measurements and reporting is

useful for determining:

• What measures of availability should be established and agreed by all parties.

• The actual availability delivered against agreed targets.

• Unacceptable levels of availability.

• Performance of IT supports the organization in delivering the required levels of availability.

• Opportunities for improvement.

202



The key measures of availability management are:

Availability

Reliability

MTBSI = mean time between service incidents

MTBF = mean time between failures

MTRS = mean time to restore service


203

As evidenced by these equations, the primary measures are a combination of:

• Percentage available.

• Percentage unavailable.

• Duration of uptime or downtime.

• Frequency of failure.

• Impact of failure (user minutes lost or business transaction).

As mentioned before, availability does not always consider the service in terms of up or down;

though this may be the primary concern. Traditionally, availability was measured as a composite

of the service’s different components; however, mature approaches will focus more on the

positive and negative impacts on the vital business functions. The definition of availability

addresses the following questions:

• What is the minimum availability level of functionality for the service?

• At what level of service response would the service be considered unavailable?

• What will the level of functionality and response measure?

• What are the relative weightings for partial service unavailability?

• Would a service be considered unavailable or partially unavailable if one location or office is

impacted?

These questions cover a variety of situations, including:

• What functionality must be minimally available for the business to be reasonable

productive? In a previous example for ATMs, the machine must dispense cash, but can do

without generating a receipt.

• Services which rely on transactions over the network and Internet may be impacted by

throughput and bandwidth which slows down the processing time: but how slow must the

processing time be impacted before the service is considered unavailable? Thresholds are

typically set to identify the minimal acceptable levels in communication.

• Some applications have multiple interfaces for different types of users, including managers,

employees, and customers of the business organization. If the bulk of the functionality

204



required is for employees of the organization, should the service be considered unavailable

if problems with the customer or manager interface are experienced without any

observable impact to the employee interface?

• Several employees are utilizing the same service throughout the day, but only one of

the employees is having any problems connecting: is this a situation where the service is

considered unavailable for the entire organization?

As evidenced by these examples, agreements between customer and service provider must

define what is meant by availability, unavailability, and partial availability. Even with clear

definitions, the monitoring and reporting of availability relies heavily on good data, which

is often obtained by several databases using reporting and analysis tools which monitor the

platform (service) or the individual components (pc-based). Much of the reporting effort is

manual and would benefit from high degrees of automation.

Reactive availability management is primarily concerned with the response to unavailability.

Every event or incident which impacts the availability of a service or component should be

investigated and remedial actions taken to prevent or minimize the impact in the future.

These actions may find their way into the overall availability plan or a service improvement

project. The levels of availability required will be a factor for the overall costs of an IT service;

thus it is important to analyze the availability requirements for the business to assess if or how

the service provider will deliver the IT service. While higher levels of availability may have an

increased costs applied to the service, these levels are usually only associated with vital business

functions which have an increased costs to the business should the service be unavailable; thus

a balance must be found between the cost of meeting requirements incurred by the service

provider and the cost of not meeting requirements incurred by the business.


205

Loss from unavailability is typically measured in terms of time and volume: that is, how long the

service is unavailable multiplied by the number of users impacted or the number of transactions

unable to be processed. The tangible costs associated with unavailable services can cover:

• Loss of productivity for customer organization.

• Loss of productivity for IT organization.

• Loss of revenue.

• Overtime charges related to recovery.

• Wasted goods and material, or rework.

• Litigation, imposed fines, or penalty payments.

Intangible costs associated with unavailable services include:

• Loss of customers.

• Loss of trust, goodwill, and satisfaction from customer.

• Loss of reputation and business opportunities.

• Loss of confidence in service provider.

• Loss of staff morale.

Even if a service does experience a period of unavailability, it is possible to minimize the

tangible and intangible by appropriately responding to the situation. Since unavailability is

measured in terms of time and volume, the best response would be to directly impact those

measures; either by reducing the amount of downtime or isolating and reducing the affected

area.

While incident management may be engaged for individual periods of unavailability, availability

management is concerned with the total downtime and impacted volume over an entire

reporting period(s): using a concept called the expanded incident lifecycle. Consider a service

which has a target availability of 98% and runs 24/7. The reporting period is 30 days. This means

the service must be available 705.6 hours of the reported 720 hours, or the total planned and

unplanned downtime for the service is 14.4 hours for the thirty days.

206



The 14.4 allowable hours of downtime must cover both planned and unplanned outages for

the service: if the average maintenance window for the service is 1.5 hours and performed

each week, the total hours of unplanned failures in service is 8.4 hours. For simplicity, let’s say

availability is an up/down situation: that is, the service is either availability or unavailable with

no definition for partial availability. Let’s also assume the service experiences one failure a week

or an average of four failures in a reporting period. The average length of each outage allowed

by the situation is 2.1 hours (8.4/4).

The importance of managing the lifecycle of each incident (failure) rigorously is evident. With

only 2.1 hours available to resolve the failure and return the user productivity, efforts in incident

management must be done quickly and with the minimum number of mistakes or misdirects

in the process. For this reason, incident management will generally assign a single person as

incident manager for major incidents.

The expanded incident lifecycle considers the efforts of:

• Incident detection.

• Incident diagnosis.

• Incident repair.

• Incident recovery.

• Incident restore.

From an availability management perspective, each stage of the incident lifecycle is an

opportunity for improvement. Given the current calculation, the average number of minutes

available for each stage is 25-26 minutes (2.1 hours/5 stages): that is, the service provider has

25 minutes each to detect, diagnose and repair the failure and recover and restore the service.

Measuring each stage is therefore critical to reducing the total duration of each failure.


207

The expanded incident lifecycle also considers and improves:

• Time between service incidents – measures time from the start of one incident to the start

of the next incident.

• Time between failures – measures time from the end of one incident to the start of the next

incident.

Of course, the purpose of incident management is to minimize the impact of a failure and

restore normal operations as quickly as possible; problem management is responsible for

identifying the root cause of an individual failure. Truthfully, 2.1 hours may not be enough time

to permanently resolve the underlying cause of a particular failure. One of the techniques used

by problem management to this end is service failure analysis (SFA).

The objectives of service failure analysis are:

• Improve the overall availability of IT services by identifying improvement or inputs to the

availability plan.

• Identifying the underlying causes of service failures.

• Assessing the effectiveness of the service provider and service management processes.

• Produce reports containing major findings and recommendations.

• Ensure measurements are in place for all recommended improvements from SFA results.

The SFA should be a joint collaboration between IT and business. It can be a resource intensive

effort and typically a set number of SFAs are assigned each year: meaning that not every service

interruption will be analyzed using the SFA technique. Ideally, the service selection will be

performed as part of availability management’s proactive approach.

208



The high-level structure of the SFA consists of the following steps:

• Select opportunity - the SFA is a highly visible investigation within the service provider and

should have a recognized sponsor from IT and/or business.

• Scope assignment – the areas which are and are not covered are explicitly documented.

• Plan assignment – an SFA is treated as a project and planned for several weeks before

beginning. Data collection may be a part of the planning step. The size of the team

performing the analysis should reflect the scope and complexity of the SFA.

• Build hypothesis – allows the team to focus on the most likely conditions that caused the

failure(s) and build by interviewing key stakeholders or brainstorming within the team.

• Analyze data – data is collected and analyzed.

• Interview key personnel – captures the business and user perspectives regarding in-scope

service failure(s) and the impact experienced. IT personnel should be interviewed to identify

other problem areas. The result may be several “quick wins” foe the service provider.

• Findings and conclusions – the results of the analysis and interviews are validated and final

conclusions made.

• Recommendations – made based on the validated findings and conclusions.

• Report – a final report is published and distributed.

• Validation – a “before” and “after” picture are produced using measurements reflecting

the business and user perspectives. The latter picture validates the effectiveness of the

recommendations and supporting SFA effort to improve service availability.

SFA assignments can:

• Increase the service provider’s ability to deliver enhanced levels of availability without

incurring major costs.

• Demonstrate the service provider’s commitment to the business.

• Develop skills and competencies internally.

• Promote collaboration between cross-functional teams.

• Establish a program of improvement.

• Focus opportunities to deliver benefits to the user.

• Establishes an independent “health check” of service management processes.


209

• Be a stimulus for process improvement.

10.7.6 Process Activities – Proactive Availability Management

Proactive activities are an effort within service design and transition to ensure that new and

existing services can and will deliver the agreed levels of availability, and include:

• Planning and design of new or changed services:

Ř Determining the vital business functions.

Ř Determining availability requirements for a new o changed service.

Ř Creating the availability and recovery design criteria for supporting components.

Ř Defining the service targets for availability, reliability and maintainability.

Ř Performing the assessment and management of risk related to service and component

availability.

Ř Designing IT services to meet availability and recovery design criteria and agreed service

levels.

Ř Establishing measures and reporting of availability, reliability, and maintainability.

Ř Determining impact related to IT service and component failure in conjunctions with

ITSCM.

Ř Reviewing availability design criteria to enhance resilience to prevent or minimize impact

due to service and/or component failure.

• Implementing cost-justified countermeasures.

• Reviewing and testing availability and resilience mechanisms for all new and changed

services.

• Production, maintenance, review and improvement of an availability plan(s).

210



The planning and design aspect of availability management involves several activities,

including:

• Defining requirements.

• Identifying vital business function.

• Designing for availability, specifically :

Ř Base products and components.

Ř Systems management.

Ř Service management processes.

Ř High-availability options.

Ř Special solutions with full redundancy.

• Creating availability and recovery designs.

• Component failure impact analysis (CFIA).

• Single point of failure analysis (SPOF).

• Fault tree analysis (FTA).

• Modeling.

As always, requirements are sourced from the customer or business and are documented as part

of understanding new or changed services. These requirements are refined, agreed upon and

used to initiate the service design. For IT availability, business requirements should address:

• VBFs supported by the IT service.

• The conditions which the business considers a service unavailable (definition of downtime).

• Business impact and risks associated with loss of service (usually identified as part of BIA).

• Quantitative availability requirements.

• Required service hours.

• Assessment of relative importance of different working periods.

• Specific security requirements.

• Service backup and recovery capabilities.


211

A large part of availability planning is determining a balance between meeting availability

requirements and the costs associated with providing availability. Generally speaking, the

higher the level of availability required, the higher the cost. The factors influencing this balance

can be as basic as the components being used or the processes executed to support the

process. For example, a service component which is cannot meet stringent availability and

reliability requirements will not be able to support high-availability requirements. The number

of SFAs conducted is limited because of the extensive (and relatively expensive) nature of the

effort, but can effectively reduce the impact and frequency of failures in service availability.

Defining requirements for availability is more effective when performed in the context of

designing for availability. Within this context, the process is iterative and contains the following

steps:

• Determining business impact of service interruptions.

• Specifying availability, reliability, and maintainability requirements.

• Identifying serviceability requirements for IT services and components provided externally.

• Estimating costs associated with meeting availability, reliability, maintainability, and

serviceability requirements.

• Justifying the costs of meeting availability requirements with the customer.

• Deterring the costs associated with loss or degradation of service.

• Documenting cost-justifiable and agreed requirements for availability, reliability,

maintainability and serviceability.

The work related to negotiating and agreeing on availability requirements with the customer

is primarily the responsibility of service level management, with availability management

playing a consultancy role in the process. However after the requirements are agreed,

availability management plays the primary role in designing availability in the service to

meet those requirements. Design considers two perspectives: availability and recovery. The

availability perspective focuses on delivering on the requirements directly, while the recovery

perspective focuses on how the service recovers from a service interruption or degradation.

Both perspectives will cover all aspects of technology—infrastructure, environment, data,

212



and applications. Recovery plays an important part in the availability solution, especially if the

technology used to provide higher levels of availability cannot be cost-justified.

Designing for availability considers:

• Availability specifications for all service components.

• Instrumentation (measurement points for availability).

• New/enhanced systems and service management requirements.

• IT infrastructure design and architectures.

• Reliability, maintainability and serviceability specifications for components from both

internal and external suppliers.

• Validation that final design meets minimum levels of availability.

In addition to availability and recovery requirement, design considerations also incorporate:

• Security requirements.

• IT continuity requirements.

Component failure impact analysis is a technique used to predict and evaluate the impact on IT

services should a component of the service fail. The results are used to identify where additional

resilience should be added. CFIAs can be used to identify:

• Single points of failure.

• Impact of component failure on business operations and users.

• Dependencies between component and people.

• Recovery times for each component (automatic and manual).

• Recovery options.

• Risk reduction measures.


213

The procedure for CFIA has the following steps:

1. Associate the components (configuration items) to the services they support (usually done

in a grid with all components listed on the left and all services provided listed on the top).

2. Identify the impact of component failure:

• If the component failure has no impact, leave blank.

• If the component failure causes the service to fail, mark with “X.”

• If an alternative component can support the service, mark with “A.”

• If an alternative component can support the service but manual intervention is required,

mark with “M.”

The interpretation of the CFIA results is rather simple. Any component with a high number of

Xs is considered critical and can be seen as single points of failure. If the component is linked to

VBFs, the impact on the business and user can be rightly estimated.

The simple approach of the CFIA can be expanded to show:

• Component availability weighting – the percentage of users or business productivity

impacted by the component failure, i.e. 2000 users are impacted out of a base of 10000

users = 20%.

• Probability of failure – measures the reliability of the component, usually in terms of high/

medium/low or numeric indicator.

• Recovery time – the estimated time of recovery should the component fail.

• Recovery procedures – indicates whether recovery procedures have been reviewed and

updated.

• Device independence – indicates resilience.

• Dependency – identifies any dependencies between components, i.e. value chain.

One concept of particular importance in availability management is the single point of failure

(SPOF). A single point of failure describes a component of the service which, when it fails, will

cause a service interruption and no countermeasure has been implemented. Consider a town

214



where the only access is crossing a bridge over a nearby river. The bridge is considered the

town’s single point of failure because if it collapses, access to the town would be impossible. By

building a second bridge upriver, access to the town can continue using an alternative route.

Is it possible for access to the town to be severed with two bridges? Yes, but the probability of

both bridges collapsing in the same time period is significantly smaller.

In IT service management, SPOF (or CFIA) analysis is used to identify all single points of failure

for a service and appropriate and cost-justified countermeasures. Power (electricity) is one of

the most pervasive SPOFs: should power not be able to get to a component, it will fail. For this

reason, major service provider will implement backup generators and alternative power relays

to ensure continuous power is available to all its components.

Not every service failure is the result of a single component or point of failure; but can

accumulate in a chain of events. Fault tree analysis (FTA) is a technique that can be used to

identify the chain of events (current and future) which can lead to service failure. FTA uses

Boolean notation to represent the chain of events – that is, it distinguishes between different

types of events and establishes relationships. The different types of events found include:

• Basic events – terminal points in the fault tree which are not investigated in great depth, i.e.

power failure, operator error, etc.

• Resulting events – intermediate points resulting from a combination of event: the failure of

an IT service is a highest point in the fault tree and is a resulting event.

• Conditional events – intermediate points which occur only under certain conditions: for

example, IT components overheating when room temperature reaches a specified tolerance.

• Trigger events – events which trigger other events, such as automatic shutdown initiated by

a security breach.


215

The relationships between events can be established using the following logic operators:

• AND – two events must occur simultaneously to trigger a resulting event.

• OR – one or more events must occur before a resulting event is triggered.

• Exclusive OR – one and only one of several identified events must occur before a resulting

event is triggered.

• Inhibit – a resulting event occurs only when input conditions are not met.

Modeling is a means of forecasting availability and assessing the impact of changes to the

infrastructure. The technique uses information about the individual components reliability,

maintainability and serviceability to determine the probability, impact, and risk associated with

an availability design.

Availability management is only effective if a program exists for assessing and managing

risks is implemented. The efforts of this program will also support other service management

processes, including service level management, IT service continuity management and

information security management. A formal risk assessment and management approach will

identify:

• All possible risks and countermeasures.

• All vulnerabilities.

• All threats.

• All expenditures associated with countermeasures.

The intention of risk management and many proactive efforts in availability management

is towards identifying and implementing cost-justified countermeasures to prevent loss of

availability or to minimize the impact of service failures. This work in countermeasures is a

product of efforts in service design service operations and continual service improvement.

216



A basic countermeasure is a planned maintenance strategy for every IT component. The

strategy is a means of continuously identifying and appropriately responding to component

vulnerabilities. The frequency and levels of maintenance will vary based on the individual

components, the technology involved, their criticality to the business processes, and the

benefits applied by each instance of maintenance.

Planned maintenance can perform a number of useful activities, including:

• Preventive maintenance.

• Hardware and software upgrades introducing new capacity or added functionality.

• Business-requested changes.

• Introduction of new technology or functionality.

Planned maintenance is synonymous with planned downtime for the component and what

can actually be performed within a maintenance windows is constricted by the amount a time

that a component (or service)) can be down before its availability target are missed. Of course, if

the required service hours for a service are not 24 hours a day, then maintenance windows are

usually performed outside of service hours; otherwise, maintenance windows are performed

when demand on the service is at its lowest, usually overnight or on weekends. In many cases,

maintenance windows may be explicitly defined within agreements.

In any case, a service provider will typically have a relative short window to perform any

planned maintenance on all components. The establishment of a maintenance schedule is

important for communicating the plan and should be linked to the change schedule: the

change schedule may incorporate the maintenance schedule, but the scope of changes

controlled by the change management process may be broader than the items found in the

maintenance schedule. Ideally, the best approach is to perform maintenance on multiple

components concurrently, but even this approach has its risks, including:

• The organization’s capability to coordinate a high number of changes may restrict the


217

number and type of components impacted during a maintenance window.

• The organization’s ability to perform effective problem determination when a problem

occurs after multiple changes is applied simultaneously.

• The impact of failed changes for one component may require back-out of multiple changes

on several dependent components.

Service transition will test all solutions and components against availability and resilience

requirements defined by service design before the service or component is deployed into

the live environment. As part of any availability and IT continuity plans, these tests typically

continue on a regular basis throughout service operation. Periodic testing and review of

availability is a means of identify potential improvements or opportunities for optimization.


Availability Management will be triggered by the following events:

• New or changes services.

• New or changed business needs.

• New or changes targets in agreements.

• Service or component breaches, events, and alerts.

• Periodic reviews, revisions or reporting.

• Review of availability forecasts, reports and plans.

• Review and revision of business and IT plans and strategies.

• Review and revision of designs and strategies.

• Change of risk or impact on a business process, VBF.

• Request from SLM for assistance with availability targets and achievements.

218



The inputs and outputs of availability management are summarized in the following table:

Inputs OutputsBusiness information, from strategies, plans,

and requirements

Availability management information

system (AMIS)Results of Business Impact Analysis Availability plan(s)Results from assessment of VBFs Design criteria and proposed service targets

for availability and recovery of new or

changed servicesReports and registers Report of achievements against targets for

availability, reliability, and maintainability of

service(s)Service portfolio and service catalog

information

Report of achievements for availability,

reliability, and maintainability of service

components Service information from SLM Revised risk assessment reviews, repots, and

risk registerFinancial information IT service and component requirements for

monitoring, management and reportingChange and release information Availability management test schedule

(transition and operation)Service asset and configuration

management data

Planned and preventative maintenance

scheduleService targets Contributions to projected service outage

(change management process)Component information from CMS Details on proactive availability techniques

and measuresTechnology information Improvement actions Past performance from availability

management information system (AMIS)Information on unavailability or failurePlanning information, i.e. capacity plans


219

The major interfaces for Availability Management are with the following processes:

• Service Level Management – leverages availability management to determine and validate

availability targets as well as to investigate and resolve service and component breaches.

• Incident Management – leverages availability management in the resolution and correction

of incidents impacting service or component availability.

• Problem Management - leverages availability management in the resolution and correction

of problems impacting service or component availability.

• Capacity Management – provides capacity to support the necessary resilience and

availability of a service, as well as provides information obtained though demand

management to use in availability management.

• Change Management – uses contributions from availability management to create

projected service outage (PSO) documentation and assessment of changes against the

impact and risk of service and component availability.

• IT Service Continuity Management (ITSCM) – works collaboratively with availability

management to assess business impact and risk and the provision of resilience, fail-over and

recovery mechanisms.

• Information Security Management (ISM) – service unavailability and data unavailability are

usually synonymous from a customer perspective, so ISM provides the security measures

and policies to be incorporated in all availability and recovery designs.

• Access management – utilizes the methods from availability management to grant and

revoke access to services when required.


The following critical success factors and key performance indicators are samples related

to Availability Management. Each critical success factors has at least one key performance

indicators which is used to demonstrate achievement of the CSF.

• Manage availability and reliability of IT service:

Ř Decreased percentage in service and component unavailability.

220



Ř Increased percentage in service and component reliability.

Ř Review and follow-up of all SLA, OLA and underpinning contract breaches related to

availability and reliability.

Ř Increase percentage in overall end-to-end service availability.

Ř Decreased percentage in the number and impact of service failures.

Ř Improved MTBF (mean time between failures).

Ř Improved MTBSI (mean time between service incidents).

Ř Improved MTRS (mean time to restore service).

• Satisfy business needs for access to IT services:

Ř Decreased percentage in service unavailability.

Ř Decreased percentage in cost of business overtime attributed to unavailable IT.

Ř Decreased percentage in critical time failures (unavailability at service peak times).

Ř Increased percentage in business and user satisfaction.

• Availability of IT infrastructure and applications provided at optimum costs:

Ř Decreased percentage in the cost of unavailability.

Ř Increased percentage in service delivery costs.

Ř Regular risk assessment and system reviews completed in a timely manner.

Ř Regular cost-benefit analysis for infrastructure CFIA completed in a timely manner.

Ř Decreased percentage in third-party contributions to MTRS/MTBF against contract

targets.

Ř Decrease in time required to complete risk assessment.

Ř Decrease in time required to review system resilience.

Ř Decrease in time required to complete availability plan.

Ř Management reports produced in a timely manner.

Ř Decreased percentage in number of security and reliability exposures found in

application designs during operational reviews.


221


The greatest challenge of availability management is establishing a balance between the

expectations of the customer, business and senior management and the actual capabilities

and agreements regarding service and component availability. Most people expect a service

to be available every day of the year, every hour of the day, and when it is not, that it will be

available within a few short minutes. The practically of meeting this expectation is heavily

reliant on the level of investment and design into the service by these very same customers,

business and senior executives. Unfortunately, this level of investment and design falls short

of the expectation. Availability management must set the correct level of expectations while

obtaining quality information about the service requirements and impact on the business if the

service is unavailable.

The need for availability-related data instigates another challenge – the integration of all

information within the availability management information system. This information is to

provide a consistent foundation for analysis on the availability of all services and components.

Obtaining an appropriate level of investment in service and component availability is also

a challenge, especially proactively. Demonstrating the need for greater levels of availability

is simple when in the midst of a service interruption which is impacting the business in an

unexpected way, but an effective process can demonstrate this same need before the service

interruption and prevent it from ever happening.

The risks attributed to availability management include:

• A lack of commitment from the business regarding availability management.

• A lack of appropriate information on future plans and strategies impacting service and

component availability.

• Lack of senior management commitment to availability management, including allocation

of resources and budgets.

222



• Resource-intensive (particularly human) reporting processes.

• Focus on technology over services and needs of the business.

• AMIS maintained in isolation from other process areas, particularly ITSCM, ISM and capacity

management.

10.7.10 Summary of Availability Management

Since ContXT is a marketing firm, the majority of services must be available between “market

hours” which would have natural windows of unavailability to occur during late night and

weekend hours. Of course, some services, such as the project management system and

marketing database may need to be available (partially available) at all times in order to get to

the data. The exact hours of required availability for each service must be defined, documented,

and agreed within the service level agreements.

An effective availability plan for each service needs to be established. Some plans may be

similar, such as voice conferencing and teleconferencing, because of the nature of the services

and how they are delivered (in this case, through third-party probably). The plan addresses all

the availability-related issues related to the service. For the video-conferencing service, those

issues may include:

• How many concurrent connections are possible for each session?

• How many concurrent sessions can be supported?

• What functionality is available?

• What functionality is considered VBF?

• What happens if ContXT’s client does not have video-conferencing support or connection to

a session?

• What steps should be taken when a session is not stable or loses connections?

• What is the response time to correct any problems?

• When will video-conference hardware and software be tested and maintained?


223

To ensure these issues, if valid, are addressed effectively in the availability plan, they should be

quantifiably measured, monitored and reported. For instance if only two concurrent sessions

with four concurrent connections can be supported, than monitoring should demonstrate

whenever these conditions are broken, as a result of scheduling or miscommunication or lack

of resources. This monitoring serves two purposes: validating the services ability to meet the

conditions of the service and identifying the need because the conditions have increased, i.e.

scheduling shows the need for three concurrent session or six concurrent connections.

Many videoconferencing services provide more than video streaming; they provide instant

messaging, multimedia support, and security logins. This additional functionality may not

be required to meet the basic needs of the business and if the core service, video streaming,

is available but the others are not, the service may not be considered unavailable. However,

if these are options used and chosen in scheduling a session and they are unavailable at the

time, the service may be considered unavailable because expectations were set at scheduling:

i.e. multimedia support was requested and guaranteed and not available even though video

streaming was available. The definition of availability, unavailability, and partial availability must

be determined within the SLA.

224




1. What are the four measurable areas covered by Availability Management?

A. Availability, reliability, maintainability and serviceability

B. Confidentiality, integrity, availability and resilience

C. Availability, resilience, redundancy and reliability

D. Availability, resilience, maintainability and reliability

2. The purpose of availability management is concerned each of the following considerations

except what?

A. Level of availability

B. Cost effectiveness

C. Timeliness of the service

D. Business continuity

3. The availability management process will provide guidance on appropriate activities

including all but which of the following?

A. Design

B. Implementation

C. Control

D. Improvement

4. What approach to the availability design is most likely provides the greatest level of

availability at the greatest cost?

A. High Availability

B. Fault Tolerant

C. Continuous operation

D. Continuous availability


225

5. Which of the following processes works collaboratively with availability management to

address immediate issues with service or component availability?

A. Change Management

B. Incident Management


D. Access Management

6. MTRS (mean time to restore service) is a measure of what aspect of availability

A. Availability

B. Reliability

C. Maintainability

D. Serviceability

7. Which of the following activities exemplifies the proactive approach of availability

management?

A. Risk assessment

B. Incident management

C. Service monitoring

D. Remediation

8. The availability management information system contains all but which of the following?

A. Availability plans

B. Availability requirements

C. Availability testing schedule

D. Availability management repots

226



9. Which of the following is not a step of service failure analysis?

A. Analyze

B. Recommend

C. Resolve

D. Validate

10. Which of the following analysis techniques is not an activity of proactive availability

management?

A. Component failure impact analysis

B. Single point of failure analysis

C. Fault tree analysis

D. Service failure analysis


227

10.9 Capacity Management

Where availability management focuses on whether a service can be accessed or not, capacity

management focuses on those components that enable the service to be effective or performed

adequately to provide value. The official ITIL definition for capacity is “the maximum throughput that

a configuration item or IT service can deliver” (Service Design, page 392). Here are some concerns of

capacity:

• Storage – disk drives, RAM memory, RAID systems.

• Network – bandwidth, throughput, transfer speed.

• Server – print, file, web, application.

• Productivity – mobile devices, laptops, desktops.

• Facilities – power, cooling, space.

Capacity management will be used to prescribe and manage the number of resources available

in the environment and how they perform. The concept of capacity management is simple and

analogous to a glass of water. The capacity of the glass is the amount of water which can be

contained within the glass, while the performance of the glass is how well it contains and delivers

the water. If the glass is half full, then half the capacity is unused: in IT, this can be a very expensive

proposition. If the glass is overfilled then not enough capacity is present and either another glass

is needed or a bigger glass. If the glass is cracked, water can’t get into the glass or the receiver of

the water is not getting the expected benefits, the glass is not performing as designed. In truth, the

glass is simply a vehicle for delivering the water: in IT, capacity is a vehicle for delivering services.

228




The purpose of capacity management is to ensure the capacity of IT services and management

systems meet the agreed requirements for capacity and performance in a manner that is timely and

cost-effective.

The objectives of capacity management include:

• Producing and maintaining a capacity plan(s).

• Advise and guide all areas of the business and IT of any capacity- and performance-related

issues.

• Ensuring service performance achievements meet all agreed targets by managing the

performance and capacity of both services and resources.

• Assist the diagnosis and resolution of capacity- and performance-related incidents and

problems.

• Assess the impact of all changes on the capacity plan, as well as the capacity and

performance of all services and resources.

• Improve the performance of services proactively.

10.9.2 Scope

Capacity management considers all resources necessary to delivery IT services to the customer,

including all areas of hardware and software technology, components and environments. The plans

made though the process handle short-, medium- and long-term requirements for capacity and

performance. Where human resources will impact the delivery of a service or result in a breach

of SLA or OLA, capacity management could be used to manage staffing levels, skill levels and

competencies.

The process of capacity management will be involved in the following activities:

• Monitoring patterns of business activity using IT service data regarding performance,

utilization and throughput.


229

• Tuning performance of IT resources to improve efficiency.

• Understanding the current and future demand on IT resources and producing appropriate

forecasts for future capacity requirements.

• Working with demand management and financial management for IT service to influence

demand on resources.

• Producing a capacity plan demonstrating how the service provider will delivery and support

services according to agreements.

• Assist in identifying and resolving all incidents and problems related to service or

component capacity or performance.

• Improve the performance of service(s) and components(s) when costs and benefits to the

business are justified.

Capacity management drives and is driven by:

• Service strategy.

• New technology.

• Business plans.

• Service requirements and agreements.

Capacity management simultaneously identifies what the organization is capable of doing with

the resources it has available to it and establishes a plan to growth in number, type and maturity to

enable the organization to do more.

230




The value of capacity management is captured through:

• Reducing the capacity- and performance-related incidents and problems occurring; thus

improving the performance and availability of IT services.

• Ensuring capacity and performance are met in the most cost-effective manner.

• Ensuring all capacity- and performance- related service levels are met, thus improving

customer satisfaction and user productivity.

• Proactivity supporting the design and transition of new or changed services in the most

effective and efficiency manner.

• Promoting forward-looking capacity planning based on a clear understanding of business

needs and plans to improve capacity-related budgeting.

• Promoting an environmentally responsibility strategy by using green technologies and

techniques in capacity management.


Like most service management processes, the process of capacity management is meant to create a

balance, specifically between:

• Costs and resources.

• Supply and demand.

Resources require an investment; whether they provide the necessary capacity and performance

outright or they need to be matured to bring out the right level of capacity and performance.

However, budget limitations may require procuring resources which have a greater risk of not

meeting requirements. Consider a situation where two $500 servers can be configured to work

together to support a service or a single $1200 server can be procured for the same purpose. In

many cases, the more expensive option is the best approach if it meets the needs of the business;

however, the less expensive option also establishes a level or redundancy that cannot be obtained


231

when using a single server. The cost of capacity and performance and the needs of the business to

determine what resources are procured and used.

Most organizations do not need more capacity than they require. Consider the example of the

half-filled glass and wasted space. Now multiply this glass by one hundred. Is it better to have one

hundred half-filled glasses or fifty filled glasses? The answer is more complicated than you might

think because the question assumes an answer which correlates to a specific point in time. What if,

at any point in time, 25 of those glasses are completely filled, while 25 glasses are less than half filled

or empty? In this respect, the answer depends on the demand on capacity. At a party, the capacity

is directly impacted by the number of guests. At this point, the capacity concern may start with the

number of available glasses but move on to determining what is in each glass and keeping them

filled. In this context, capacity would be dealing with consumption as some guests were demand

more to drink then others. If the goal of the party is to keep everyone’s glass filled, then an obvious

choice may be to provide different sizes in glasses or identify the heavy drinkers to better monitor

their consumption.

But even the party example is simplistic because it assumes a guest has a dedicated glass assigned

to them. In IT, capacity has to deal with shared resources. What if, in the party, some quests were

sharing glasses and others were not? It means that the drink consumption is more rapid in some

cases then others, but it also means that capacity is not directly correlated to the number of quests.

The complexity increases if there are other restrictions, such as glasses only come in one size,

each person’s consumption is limited to five glasses, or other possible constraints. The point of

this example is to show that capacity management does address numerous concerns, including

performance. Where the number of glasses directly correlates to capacity, the wait staff and servers

provide a similar correlation to the need for high performance of the entire system.

232



The driving factors of capacity management are the business requirements of the organization.

In the example above, the primary requirement was to keep all glasses filled, but we can expand

the requirements to food, entertainment, conversation and so on. As a result, some planning must

go into the party to make it a success. In IT, the same commitment to planning must be made and

requires understanding:

• The current business operations and its requirements.

• Future business plans and requirements from the service portfolio.

• Service targets and current IT service operation defined through SLAs and standard

operating procedures.

• IT technology (infrastructure, data, environment and applications), its capacity and

performance.

As the party example demonstrates, complexity can easily grow though the introduction of the

minor factors and conditions, including the size of the event. As a result, capacity management can

be complex and demanding. If in business of organizing parties, it may be best to start with small

parties of 20-30 guests before considering parties of hundreds of people: the same is true with

capacity management, start with smaller services with fewer potentially opposing conditions and

grow competency. This guidance can be applied to all individual services, no matter their size: meet

the requirements initially and then address each factor individually and grow competency. In party

organization, the more parties put on with over 100 guests, the better each subsequent party will be

because of the experience and knowledge obtained.


233

IT environments also have to deal with distributed and mainframe systems. While distributed

systems tend to be more complex because of the number of individual components, mainframe

systems are often harder to work with from a capacity perspective because of its proprietary

nature. In a distributed environment, adding capacity may be a simple as attaching the right

capacity: however, in mainframes, capacity may require changing the core structure. Each

situation has its immediate advantages and disadvantages; capacity management provides the

necessary information for decision-makers to understand:

• What to upgrade.

• When to upgrade.

• How much an upgrade will cost.

In many ways, capacity management is very much like party hosting: in that, it must determine

and ensure the right number and type of resources are available at any given moment. Here are

some possible similarities:

IT Capacity Management Party Planning and HostingDemand for resources GuestsBusiness Requirements Seating, RSVP, pre-selection of menu itemsTechnology Current stock and reserves for food, drink,

and dinnerwareInfrastructure Party location, logistics, security

Environment Decorations, set-upApplications Processes (buffet, seating, dancing)Data Guest list, connections, influence, etc. Financial resources BudgetHuman resources Wait staff, servers, bartendersInformation resources Purpose of party, invites, brochures,

schedule or program, exposure to host or

guest of honor

234



From an IT perspective, capacity management is performed on three levels:

• Business (strategic).

• Service (tactical).

• Component (operational).

The activities are similar at all three levels, but the focus is different. At the component level,

the focus is on individual IT components, their planning, implementation and monitoring.

Components are combined to deliver services; and as such, the end-to-end value chain of

the service must be monitored and measured in order to manage, control and predict the

end-to-end performance and capacity to meet business needs. The support of the business is

actually a combination of several services used to achieve basic outcomes such as profitability,

competitiveness and quality. At the same time, the business is also accountable for investing

and supporting the acquisition of necessary resources and capabilities to be managed at the

service and component levels.

The capacity plan will cover the necessary direction and actions important to all three levels of

capacity management and will be derived from information from different sources, namely:

• Iterative capacity management activities.

• Demand management.

• Modeling.

• Application sizing.

This information, capacity plans and regular reports on business, service, and component

capacity and performance can be found in the capacity management information system

(CMIS)—a subset of the service knowledge management system.


235


Like availability management, the capacity management process is both proactive and reactive.

The proactive activities include:

Identifying potential performance issues and eliminating or mitigating their impact on

operational capacity:

• Identifying trends in the current utilization of services and components and estimating

future capacity requirements.

• Modeling and trending predicted changes in IT services and identify changes to services

and components to appropriately respond and/or support.

• Ensuring appropriate planning, budgeting and implementation of upgrades between SLAs

and service targets are breached or issues occur related to performance.

• Actively improve service performance.

• Publish and maintain a capacity plan.

• Optimizing (tuning) service and component performance.

The reactive activities of capacity management include:

• Monitoring, measuring, reporting, and reviewing service and component performance.

• Responding to all capacity-related events and instigating corrective action.

• Responding to all performance-related issues and instigating corrective action.

The strategic and design activities of capacity management involve:

• Assist the discovery and agreement of service level requirements.

• Verify service level agreements.

• Support negotiations for service level agreements.

• Design, procure or amend service configuration.

• Leverage change, release, configuration and project management to provide control and

coordination for all aspects of capacity throughout the service lifecycle.

• Forecast capacity and performance requirements.

236



• Identify and understand the performance and capacity and utilization of each service

component.

• Exploit new techniques and technology to support the business and innovate

improvements.

• Design resilience wherever cost-justified.

The majority of capacity management operational activities will revolve around:

• Monitoring – capacity and performance is monitored to identify any significant trends,

issues, or risks. Monitored data includes:

Ř Processor utilization.

Ř Memory utilization.

Ř Percent process per transaction type.

Ř I/O rates and device utilization.

Ř Queue lengths.

Ř Disk utilization.

Ř Transaction rates.

Ř Response times.

Ř Batch duration.

Ř Database usage.

Ř Index usage.

Ř Hit rates.

Ř Concurrent user numbers.

Ř Network traffic rates.

• Analysis – data collected during monitoring is analyzed against normal utilization and

service levels to establish baselines and identify:

Ř Bottlenecks or hotspots.

Ř Workload distributions.

Ř Inappropriate database indexing.

Ř Design inefficiencies.

Ř Unexpected increases in workloads and transaction rates.

Ř Inefficient scheduling or memory uses.

• Tuning – operational improvements to the utilization or performance of a service, system or


237

component, specifically in the areas of:

Ř Workload balancing.

Ř Network traffic balancing.

Ř Disk traffic balancing.

Ř Locking strategy (databases, pages, files, records, and rows).

Ř Memory utilization.

• Implementation – introduces any changes to the operational environment derived through

monitoring, analysis and tuning.


Capacity Management will be triggered by the following events:

• New and changed services requiring capacity.

• Service breaches.

• Events and alerts related to capacity and performance.

• Exception reports.

• Revisions to current capacity and performance requirements.

• Review of capacity and performance forecasts, reports and plans.

• Periodic trending and modeling.

• Review and revision of business and IT plans and strategies.

• Review and revision of designs and strategies.

• Review and revision of SLAs, OLAs and underpinning contracts.

• Request from SLM for assistance with targets and explanation of achievements.

238



The inputs and outputs of capacity management are summarized in the following table:

Inputs OutputsBusiness information from strategies, plans

and financial plans

Capacity management information system

s(CMIS)Service and IT information from service and

IT strategy, plans, and budgets

Capacity plan(s)

Component performance and capacity

information from manufacturers and

suppliers

Service performance information and

reports

Service performance issue information from

incident and problem management

Workload analysis and repots

Service information from Service level

management

Ad hoc capacity and performance repots

Financial information Forecasts and predictive reportsChange information Thresholds, alerts, and eventsPerformance information Improvement actionsConfiguration management systemWorkload information and schedules

The major interfaces for Capacity Management are with the following processes:

• Availability Management – works collaboratively to determine the resources required to

ensure required levels of availability for services and components.

• Service Level Management – requests assistance in determining targets for capacity and

performance, as well as the investigation and resolution of service o component capacity-

related breaches.

• ITSCM – seeks assistance in the assessment of business impact and risk, as well as capacity

and recovery requirements related to, extended service interruptions.

• Incident and problem management – seeks assistance in the resolution and justification of

resolutions for capacity or performance related incidents and problems.


239

• Demand management – utilizes the patterns of business activity and user profiles to

determine the current and future demand on service and component capacity and

performance.


The following critical success factors and key performance indicators are samples related to Capacity Management. Each critical success factors has at least one key performance indicators which is used to demonstrate achievement of the CSF.

• Accurate business forecasts

Ř On-time production of workload forecasts.

Ř Accuracy of business trend forecasting (percentage).

Ř Incorporation of business plans into capacity plans performed in a timely manner.

Ř Decrease in the number of variances between business and capacity plans.

• Knowledge of technologies, current and future

Ř Increased competency in monitoring service and component performance and

throughput.

Ř Justification and implementation of new technology in line with business requirements

performed in a timely manner.

Ř Use of old technology is reduced, specifically those technologies causing SLA and target

breaches.

• Demonstration of cost effectiveness

Ř Last-minute procurement to address performance problems reduced.

Ř Over-capacity of IT reduced.

Ř Planned expenditures accurately forecasted.

Ř Business disruptions causes by lack of adequate capacity reduced.

Ř Cost of producing capacity plan reduced.

• Plan and implement appropriate IT capacity to match business need

Ř Decreased percentage in the number of incidents related to poor performance.

Ř Decreased percentage in lost business due to inadequate capacity.

240



Ř Increased percentage of new services implemented matching SLRs.

Ř Increased percentage of recommendations from capacity management which are acted

upon.

Ř Number of SLA breaches due to poor service or component performance reduced.


Data is the greatest challenge to the process. Capacity management is only as good as the information it receives, specifically from the business about its strategies, plan, and demand on services. Unfortunately, this type of information may not be available because of its sensitivity and confidentiality, especially when dealing with an external service provider. Even without this issue, the quality, accuracy or relevance of the data may be in question

Component data regarding capacity management may also be challenging, particularly since different technologies may provide the information using different tools and different formats. This impacts data on the specifications of the components, as well as the day-to-day usage of the components.

Additionally, the amount of data generated to manage service and component capacity management is extensive and makes analysis difficult or time-consuming. While Big Data technologies can be used to simplify the processing and analysis of data, appropriate thresholds must be used and the tools and technologies used to monitor service and component capacity must be relied upon to provide adequate warnings and alerts when variances to normal operations occur.

The risks associated with capacity management include:

• Lack of commitment from the business to the process.

• Lack of appropriate information from business strategies and plans.

• Lack of senior management commitment for the process, specifically with regards to

resources and/or budget.

• Isolated performance of service and component capacity management from business


241

capacity management because of difficulty and/or lack of business information.

• Increased bureaucracy or manual activities in the process.

• Too much focus on technology (components) over service or business.

• Capacity and performance reports and information is to technical or irrelevant to the current

audience.

10.9.9 Summary of Capacity Management

The intent of capacity management is quite simple – ensure an adequate infrastructure is in place to succeed in what one needs to dol. In this sense, the infrastructure consists of the technology, information, finances, and people; where technology incorporates the hardware, software and other IT components. For ContXT, many of services they are seeking to formalize are new: that is, while they may have some components in place, as well as skill, they have not been organized into formal services and have not been implemented to explicitly support business objectives. The truth is that it is doubtful that the current staff of three could fully support all the IT requirements of the business successfully.

For services like video-conferencing and teleconferencing, much of the administrative and software may be handed off to a third party supplier; however, there is still a need to act as the interface between customer and supplier should an incident or problem arise and to maintain the components on-premise, such as telephones and televisions. Additionally, capacity management must work with the supplier to provide adequate information regarding requirements (requirements, targets, and agreements) and demand on services.

The other services like the knowledge base or project management tool may also have third-party alternatives of varying degrees. With the rise of cloud computing, the likelihood of alternative solution is increasing and meets one of the design objectives of capacity management – to identify and exploit new technologies. But the use of alternatives is not a reason of handling off responsibility: the It department for ContXT still must understand the business, its activities and the demand on the different services.

242




1. Which of the following best describes capacity in IT terms?

A. Capacity is the maximum amount that something can contain

B. Capacity is the ability or power to do, experience, or understand something

C. Capacity is the maximum throughput that a configuration item or IT service can

deliver

D. Capacity is the ability to deliver the greatest potential value to the customer

2. Which of the following is not an objective of capacity management?

A. Produce and maintain appropriate plans

B. Reviewing, measuring and improvement performance of all service design activities

C. Assist the diagnosis and resolution of appropriate incidents and problems

D. Improve the performance of services proactivity

3. Which of the following is not an area of concern of capacity management?

A. Hardware infrastructure

B. Applications

C. Human resources

D. Financials

4. What type of technology would capacity management consider if the service provider was

attempting to be environmentally conscience?

A. Green technology

B. Cloud technology

C. Server technology

D. Service-oriented architectures


243

5. Which of the following dynamics is not addressed by capacity management?

A. Cost versus resources

B. Supplier versus demand

C. Reactive versus proactive

D. Cost versus benefits

6. What service management process delivers to capacity management invaluable data about

the customer’s business operations and its requirements to ensure capacity is adequate

provided to IT services?

A. Service level management

B. Demand management

C. Business relationship management

D. Availability management

7. There are three levels of capacity management; for which level is the end-to-end

performance of a service controlled and managed?

A. Business

B. Process

C. Service

D. Component

8. Which of the following is an input of capacity management?

A. Performance information

B. Capacity plan

C. CMIS

D. CMS

244



9. An assessment of business impact which validates capacity requirements for a service is

delivered by what service management process?

A. Demand Management

B. Availability Management


D. Incident Management

10. Which of the following critical success factors for capacity management can be monitored

though the KPI, “reduction in the number of last minute procurements to address

performance problems”?

A. Demonstration of cost effectiveness

B. Accurate business forecasts

C. Knowledge of current and future technologies

D. Plan and implement appropriate IT capacity to match business need


245

10.11 IT Service Continuity Management

IT Service Continuity Management deals with catastrophic events: from natural disasters to power outages, from terrorist attacks to security lockdowns. It is most closely related to and supports Business Continuity of the customer Service continuity is an essential part of the warranty of a service and ensures the business can still receive value even under the most drastic circumstances.


The purpose of IT Service Continuity Management (ITSCM) is to support the business continuity management (BCM) process by managing the risks that could seriously affect IT services. ITSCM makes extensive use of risk assessment and management tools and techniques, both to reduce the risk to IT services and to plan and prepare for the recovery of IT services.

The objectives of ITSCM include:

• Produce and maintain continuity plan(s) for IT services that support the overall business

continuity plan(s).

• Complete BIA exercises on a regular basis to ensure proper and continual alignment of

continuity plans.

• In cooperation with availability management and information service management,

perform risk assessments and management exercises on a regular basis to manage IT

services within the agreed level of business risk.

• Advise and guide on all continuity-related issues.

• Ensure appropriate mechanisms for continuity are implemented to meet or exceed agreed

targets for business continuity.

• Assess the impact of all IT changes on service continuity plans and supporting tools,

techniques and processes.

• Proactively measure the availability of services and subsequent improvements.

246



• Assist in contract negotiations and agreements with suppliers for the provision of necessary

recovery capability to support continuity plans.

10.11.2 Scope

The “events” handled by the IT Service Continuity Management process are defined and agreed between the service provider and the customer: as a result, the term, “disaster,” may vary between customers. For some customers, the definition may be strict and include only natural disasters or loss of a site and/or capability; other customers may extend the definition to include a loss of a significant business process or significant damage to the reputation of the company. In April 2013, Sony’s PlayStation Network was hacked and information on thousands of users was obtained illegally. As a result, the service was down for several weeks and the reputation of the company damaged. This was a situation which would justify the initiation of ITSCM.

Not every failure in the IT environment justifies ITSCM: for instance, a disk failure does not need to invoke a continuity plan unless that failure had a major impact on the business. What the ITSCM process does participate in includes:

• Agreement on the scope of ITSCM policies and process(es).

• The completion of Business Impact Analysis.

• Assessment and management of risks to business and service continuity.

• Production of ITSCM strategy and its integration with a BCM strategy.

• Production of an ITSCM plan and its integration with a BCM plan.

• Testing of ITSCM plans.

• Ongoing operation and maintenance of ITSCM plans.


247


ITSCM is important to the BCM process in the same way a IT strategy is to a customer’s business strategy. Where IT is used to support business processes, the necessary plans and policies must be in place to ensure the continuity of those IT services. An effective ITSCM plan will allow business operations to continue even under the most drastic conditions.


The strategy, policies, plans and identified risks of ITSCM are a direct result of those found during the activities to create a business continuity management program. ITSCM itself is a cyclical process impacted by all stages of the lifecycle. The interesting aspect of ITSCM is its existence provides a level of preparation for the organization and may never be invoked. Even though it provides little benefit to the daily operation of a service environment, it is worthwhile when the conditions support daily operations no longer exist.

The ITSCM process is also a closely collaborative process with BCM, where the initiation and requirements aspect of the process are performed as part of producing the BCM strategy. IT may participate in the production of a BCM strategy and plan: their responsibility begins and ends with the production and maintenance of an ITSCM strategy and plan that underpins BCM. Consider a business process supported by an IT system: the BCM plan may be to invoke a manual process which completely bypasses the system. This may provide IT an opportunity to focus on restoring and recovering the system; or IT may be able to provide a low-cost solution to provide alternative access to the system which would change the BCM plan significantly. Ideally, both the manual process and the alternative actions may be included in the plans as different contingencies based on the severity of the event.

248




There are four main activities for ITSCM:

• Initiation.

• Requirements and Strategy.

• Implementation.

• Ongoing Operation.

The initiation stage is heavily reliant on BCM activities and outcomes. The stage begins with setting policies communicating the intention and objectives of the business and management relative to supporting ITSCM. In addition to creating policies, the scope and responsibilities of ITSCM must be defined, including the responsibilities of all staff within the organization. For instance, to what extent will or should the service provider be involved in risk assessments and business impact analysis? As part of establishing scope, influencing reference points, such as regulations, legislations, standards and client requirements should be identified and understood.

The development and implementation of an ITSCM strategy and plan(s) are best served if completed as a project. This enables the service provider to:

• Allocate necessary resources.

• Define the structure for the project organization and control.

• Enable the agreement of project and quality plans.

The requirements and strategy stage is largely focused on the completion of the BIA and risk assessment and using the information results of the two activities to produce an adequate ITSCM strategy.


249

The purpose of BIA is to quality the impact to a business when service delivery is interrupted. The impact may be “hard” or “soft”; financial loss or loss in productivity is considered a hard loss, while a soft loss incorporates damage to reputation, morality, health and/or safety. A BIA will identify:

• What form the damage or loss will take, such as:

Ř Lost income.

Ř Added costs of service.

Ř Damaged reputation.

Ř Loss of goodwill.

Ř Loss of competitive advantage.

Ř Non-compliance to law, health, or safety regulations.

Ř Risk to personal safety.

Ř Loss of market share (short and long term).

Ř Political, corporate or personal embarrassment.

Ř Loss of operational capability.

• Extent and possibility of escalation due to damage or loss applied to different times of the

day, week, month or year.

• Requirements regarding staffing, skills, facilities and services to enable continuity of critical

and essential business processes at minimum acceptable operational levels.

• The necessary recovery times for staffing, facilities and services to minimum levels.

• The necessary recovery times for staffing, facilities and services to full capacity, performance

and availability levels.

• Relative priorities for each IT service related to business recovery.

Risk assessments provide an overview of the risk, its impact and the possibility of its occurrence under normal circumstances, as well as those conditions which promote or discourage its occurrence. These assessments are an evaluation of the threat to the organization and how vulnerable an organization is to that threat.

250



The results of the BIA and risk assessment(s) are used to produce a ITSCM strategy and plan which meet the needs of the business. The intent of the strategy is to reduce the risk and create an optimum solution for continuing and/or recovering services.

The risk reduction measures often adopted by ITSCM include:

• Uninterruptible power supply and backup power solutions.

• Fault-tolerant systems for critical applications.

• RAID arrays and disk mirroring.

• Spare equipment/components.

• Elimination of single points of failure.

• System and network resilience.

• Multivendor outsourcing.

• Effective physical and IT-based security controls.

• Controls for detecting and suppress service disruptions.

• Comprehensive backup and recovery solutions.

• Off-site storage.

In addition to reducing risk, ITSCM identify potential recovery options for impacted services. Those options include:

• Manual workarounds – implementing alternative procedures which do not make use of IT

technology.

• Reciprocal arrangements – agreements with another organization to share resources and

capabilities in the event of disaster.

• Gradual recovery (cold standby) – the provision of an empty facility with adequate power,

environment and networking to be filled with the organizations own resources, capabilities,

and equipment and may be provided by a third-party.

• Intermediate recovery (warm standby) – usually the use of third-party commercial facilities

with adequate operational infrastructure, system management and technical support. While

access to facility may be instantaneous, the recovery of original facilities and infrastructure

may take some time.


251

• Fast recovery (hot standby) – a secondary recovery site is owned and managed by the

business and/or service provider which can replicate the utility and warranty of the original

site within 24 hours.

• Immediate recovery (hot standby, mirrored site, or load balancing) – restoration of services

is immediate and therefore no loss of service to the customer. The underlying solution is

an active second site which is used during normal operation and serves as a recovery site

during emergencies. This is the most expensive option for recovery but is justified usually

because of its ability to provide continuous operation of critical services during normal

operations.

The third stage of ITSCM is the implementation of the strategy, starting with the development of continuity plans and procedures. The primary plans to develop include:

• Emergency response plan.

• Damage assessment plan.

• Salvage plan.

• Vital records plan.

• Crisis management and public relationship plan.

• Accommodation and services plan.

• Security plan.

• Personnel plan.

• Communication plan.

• Financial and administration plan.

The likelihood the organizational structure during a catastrophic event and recovery will be the same as during normal operations is minimal: this is often due to the fact that the recovery team is often set apart from the core business being run elsewhere. The typical structure during disaster recovery will incorporate he following basic responsibilities:

• Executive – overall authority and control within the organization and responsible for crisis

management and communication.

• Coordination – responsible for coordinating the overall recovery effort within the

organization.

252



• Recovery – represents the vital business functions and the services needed to support those

functions. Each function has relative autonomy to recover according to plans independent

from other functions.

Consider any catastrophic event in the last few years and how an organization may get through this. If the impacted location is simply a branch of an organization, normal operations may continue with modest to significant impact because many of the resources and capabilities already exist in a second or third location. In this situation, the primary concern may be the safety of personnel first, then the restoration and recovery of business operations in the area. Under this directive, the executive may be already exist and immediately mobilized to deal with the situation. In the United States, the executive will coordinate with FEMA or other government agencies. The invocation of the continuity plan will engage key personnel to begin efforts to assess the disaster area, determine what must be done, and who should perform the work. In most situations, the personnel amidst the disaster area have one immediate concern survival and rescue which can be aided through effective coordination. In tragic circumstances, the local teams representing the vital business functions may need to be replaced or supplemented by personnel from outside the disaster areas; the work may likely be transferred to another location.

If the organization is locally based, they cannot leverage personnel from outside the disaster area, but an effective continuity plan will have already prepared the data and vital business functions to be available a reasonable distance outside the disaster area. The greatest challenge in this situation is to understand and implement various contingencies based on tragic circumstances: for instance, what if the disaster takes the lives of persons in the normal and/or planned chain of command – who takes on the necessary authority as executive and coordinator? How would you even know? This requires a familiarity and practices that must be second nature under the demand from the environment. Without the support of outside resources and capabilities, local personnel must be trained and self-sufficient to handle the various unknown conditions of a disaster.

Whether using local personnel, outside personnel moving in or transfer of business functions to secondary locations, the intent of disaster recovery is to reduce any further risk to the business and recovery business capabilities. The more arrangements which can be completed before the


253

occurrence of a disaster, the less pressure placed on personnel, processes and systems during an event. Continuity planning involves understanding and addressing even the most obscure questions, such as providing hotel and meal accommodations for on-site recovery teams. Many of the policies, processes and procedures may not differ much from normal practices but must be implemented or supported with extreme priority and less bureaucracy. Preparation for a disaster may include:

• Negotiating the use of third-party recovery facilities.

• Preparing and equipping the standby accommodation.

• Purchasing and installing standby computer systems.

Testing is a major component of ITSCM; not just for the initial solution, but also ongoing regular testing of the solution. Testing not only ensures the solution meets the changing needs of the business, but also ensures the personnel deeply involved in the execution of the continuity plan are familiar enough with the plan to follow it confidently under any circumstance. There are four basic types of tests used in continuity management:

• Walk-through tests – allows relevant stakeholders to review and “simulate” the continuity

plan to identify strengths and weaknesses to be addressed.

• Full tests – comprehensive testing of the plan performed at least annually and involving

all business units to replicate the required actions in a simulated situation (like a fire drill).

The test is observed by an independent consultant or specialist who will make notes and

recommendations.

• Partial tests – different aspects of the overall continuity plan are tested. For instance, a full

test may involve a fire drill which impacts all personnel in all buildings on a campus, whereas

a partial test may focus on fire drills for each building individually on a campus. Partial tests

should supplement the annual full test of the continuity plan and may be used to verify the

effectiveness of improvements.

• Scenario tests – not all events are the same: in truth, a fire drill is a scenario test, as is tornado

drills, hurricane drills, earthquake drills, security lockdowns, contamination drills, etc. Each of

these drills may require different actions to be taken.

254



A test of the continuity plan should be conducted before it is considered “operational” and these tests must continue throughout the operation stage to ensure changing business requirements are met. The tests or drills) can also supplement efforts in education, awareness, and training. Employee procedures should cover the most likely events for the location and emergency procedures should be posted on walls and bulletin boards for ready access. Regular audits should be conducted to determine the level of compliance and readiness of the organization to invoke the continuity plan.

Change management plays an important role by assessing the impact of changes on the continuity plan. Continuity testing may be a part of the change procedure if the plan was impacted and needed to be modified. The continuity plans, themselves, should be strictly controlled under change management, as well as the configurations for all service components found within the CMS. Where major changes and releases are expected, a BIA and risk assessment may be included in the change procedure.

The realization of ITSCM’s effectiveness is in the actual invocation of continuity plans during a catastrophic event. However, invocation can result in an expensive effort and may differ depending on the circumstances. For instance, an event which occurs overnight may not have as much impact as an event occurrence during peak business hours. Preparation for a hurricane which has been tracked for a couple of days may not be as devastating as a tornado that occurred with no warning for a few minutes. The decision to invoke continuity plans must be made quickly to allow for proper lead times. At the same time, knowing when to invoke is equally important and involves understanding:

• Extent of actual or potential damage and scope.

• Likely length of the disruption and unavailability of premises and/or services.

• Time of day, month, year.

• Impact on business.


255

The content of the continuity plan should address:

• Retrieval of backup media or use of data vaulting to retrieve data.

• Retrieval of essential documentation, procedures, and workstation images stored off-site.

• Mobilization of appropriate technical personnel.

• Commencement of recovery of required systems and services.

• Contacting and alerting suppliers, support services, vendors, and other parties to undertake

supportive actions.


IT Service Continuity Management will be triggered by the following events:

• New or changed business requirements.

• New or changed services.

• New or changed targets and agreements.

• Occurrence of a major incident requiring an assessment to invoke plans.

• Periodic BIA and risk assessments activities.

• Continuity plan maintenance.

• Review, revision or reporting of business or IT strategies and plans.

• Assessment of changes.

• Review and revisions of designs and architectures.

• Change of risk or impact on a business process, VBF, IT service or component.

• Initiation of tests on continuity and recovery plans.

• Lessons learned from continuity events and associated recovery activities.

256



The inputs and outputs of IT Service Continuity management are summarized in the following table:

Inputs OutputsBusiness information Revised ITSCM strategy and policiesIT information ITSCM plans, including crisis management,

emergency responseBCM strategy and plans and disaster recoveryService information BIA exercises and reports

Financial information Risk assessment and management reviews

and reportsChange information ITSCM testing scheduleConfiguration information ITSCM test scenariosTesting schedules for BCM and availability

management

ITSCM test reports and reviews

Capacity management informationITSCM plans and test reports from suppliers

and partners

The major interfaces for IT Service Continuity Management are with the following processes:

• Change Management – all changes are assessment for their impact on continuity plans and

changes to continuity plans are controlled through the change management process.

• Incident and Problem Management – indication of potential major incidents and disasters

which provide information for decisions to invoke continuity plans.

• Availability Management – coordinates risk assessments and responses to availability and

continuity of services and components.

• Service Level Management – ensure recovery requirements are documented and agreed in

SLAs, as well as interim service levels during a disaster.

• Capacity Management – ensures sufficient resources are available to enable recovery of

catastrophic event.


257

• Service Asset and Configuration Management – documents details of configuration items to

be recovered during a catastrophic event.

• Information Security Management – involved in security breaches considered as

catastrophic events, as well as security needs during the event.


The following critical success factors and key performance indicators are samples related to IT Service Continuity Management. Each critical success factors has at least one key performance indicators which is used to demonstrate achievement of the CSF.

• IT services are delivered and can be recovered to meet business objectives.

Ř The success of regular audits of ITSCM plans are increasing and ensures that agreed

recovery requirements can be met at all times.

Ř All service recovery targets are agreed, documented in SLAs and regularly validated as

achievable within the ITSCM plans.

Ř ITSCM plans are regularly and comprehensively tested.

Ř Business and IT continuity plans are regularly reviewed, at least annually.

Ř Negotiation and management of ITSCM contracts with third-party suppliers are regularly

validated.

Ř Reduction in the risk and impact of possible failure of IT services.

• Business and IT service continuity plans are increasingly present in the organization’s

awareness.

Ř Validated awareness of business impact, needs and requirements are increasing within

the IT environment.

Ř Test results for all IT service areas and staff regarding preparedness and response to

ITSCM plan invocations are increasingly successful.

Ř Regular communication about IT objectives and responsibilities are regularly validated.

258




The greatest challenge to ITSCM is the lack of business continuity management. As ITSCM is a response to BCM, the absence of this work can indicate lack of commitment by the customer/business, lead to incorrect assumptions to the criticality of different business processes and adoption of strategies which do not support the business appropriately and higher costs. Along the same vein, a customer which depends heavily on IT may see continuity as strictly an IT responsibility and, therefore, be resistant to establishing extensive BCM foundation.

Even with the existence of a BCM process, some challenge exists in ensuring alignment with the ITSCM. An effective ITSCM strategy requires accurate and up-to-date information about the needs, impact and priorities of the business. This information may be difficult if the business is reluctant to share, especially when the service provider is external to the customer organization. If alignment is successful, it needs to be maintained—causing another challenge if the business sees the sharing of information as a one-time effort or communication pathways disintegrated because of issues with other “operational” efforts.

The risks associated with IT Service Continuity Management include:

• Lack of BCM process.

• Lack of commitment from the business.

• Lack of appropriate information on business plans and strategies.

• Lack of senior management communication, especially allocation of resources and funding.

• Focus is heavy on technology over IT services and the needs and priorities of the business.

• Risk assessment and management are performed without input from availability

management, information security management or other service management processes.

• ITSCM plans and information become out-of-date and lose alignment with business needs,

plans, and the BCM process.


259

10.11.9 Summary of IT Service Continuity Management

The success of ITSCM begins and ends with a commitment from the customer. For ContXT, the board of directors and executive managers must decide what business processes are considered critical for the business: essentially deciding what must the business have in place to “weather any storm.” Given the list of new formal services, a couple arises to prominence when asking this question, namely the project management and knowledge systems. Both these services act as data warehouses for what the company has and are currently doing. The loss of this data will severely impact the competitiveness of the company and can be easily rectified by storing data backups offsite. In more severe events, maintaining backup systems can ensure continuous access to shared files.

The most critical business problem is the loss of skills, knowledge, and experience of ContXT’s employees. Establishing a plan to locate, identify, and replace key personnel should be a major process for BCM, as well as a means to communicate in an emergency situation. Conveying to employees about what to do during an emergency can be done though employee publications and frequent tests and communications throughout the year.

Once the BCM strategy and plans are in place, IT will support the decisions with regular backups of data, maintenance of backup systems for priority services, maintenance of emergency communication network and several contingencies. The completion of BIA and risk assessments can validate the assumption regarding service criticality to the business and make recommendations regarding recovery solutions and controls for reducing risks. Because the size of ContXT is relatively small, the IT department may even take the lead in developing the education, awareness and training programs for the company; or at least contributing to the content.

260



10.12 Module 11 & Workbook Review Questions

1. What business program is IT Service Continuity Management most connected?

A. Business Security Management

B. Business Continuity Management

C. Corporate Governance

D. Enterprise Architecture

2. What type of analysis is chiefly done through IT Service Continuity Management?

A. Service Failure Analysis

B. Component Failure Impact Analysis

C. Business Impact Analysis

D. Requirements Analysis

3. With regard to risk assessment and management, which of the following service design

processes are less likely to be part of a collaborative program?

A. IT Service Continuity Management

B. Availability Management

C. Information Security Management

D. Service Level Management

4. Which of the following is not identified as an ITSCM activity?

A. Invocation

B. Initiation

C. Implementation

D. Operation


261

5. Testing of continuity plans are performed in what stage of ITSCM activities?

A. Initiation

B. Requirements and Strategy

C. Implementation

D. Ongoing Operation

6. Risk assessments are performed in what stage of ITSCM activities?

A. Initiation

B. Requirements and Strategy

C. Implementation

D. Ongoing Operation

7. Which of the following strategies is an input of ITSCM?

A. ITSC strategy

B. Testing Strategy

C. Business strategy

D. Risk profiles

8. Which of the following service management processes is most likely to invoke continuity

plans?

A. Incident Management

B. Problem Management


D. Availability Management

262



9. Which of the following KPIs most directly demonstrates organization’s awareness of the

current ITSC strategy?

A. Regular and comprehensive testing of ITSCM plans achieved consistently

B. Increase in successful test results ensuring all IT services areas and staff are prepared

and able to respond to the invocation of continuity plans

C. Regular reviews are undertaken, at least annually, of the business and IT continuity

plans with the business areas

D. Overall reduction in the risk and impact of possible failure of IT services

10. What is the source of the greatest challenge facing ITSCM?

A. Security

B. IT strategy

C. Staff competency

D. Business Continuity Management


263

10.13 Information Security Management

Information security works within the context of the corporate governance framework, which provides strategic direction for the security of the business, the business processes and the data used throughout the course of doing business. In this context, IT security is about securing the information of the customer using technology.

Information security may not be an isolated service delivered to the customer, but may be part of the warranty requirements for all delivered services: however, information security may be managed by a single, dedicated department within the organization. For corporations with their own internal service providers, this security department may consist of business and IT personnel who are responsible for the overall security of the organization. For external service providers, the focus of IT security will be on the security of the data and data transfers, but some security responsibilities may be shared with the customer, specifically onsite security. In many cases, security responsibilities may be transferred to third-party security companies, especially when dealing with physical security or transport security.


The purpose of Information Security Management is to ensure the alignment between IT security and business security to ensure the confidentiality, integrity and availability of the assets, information, data and IT services within the organization. The primary objective of information security management is to protect the interests of those people, systems, and services which rely on information, which can be stored or transferred using different forms of technology, against failures in confidentiality, integrity and availability.

264



In this respect, information security management will cover the following concepts:

• Confidentiality – “a security principle that requires that data should only be accessed by

authorized people” (Service Design, page 395).

• Integrity – “a security principle that ensures data and configuration items are modified only by

authorized personnel and activities” (Service Design, page 404).

• Availability – “the ability of an IT service or other configuration item to perform its agreed

function when required” (Service Design, page 389).

• Authentication and non-repudiation – a security principle that ensures business

transactions and information exchanges can be trusted.

10.13.2 Scope

All IT security issues are the focus of the information security management process, as well as the creation, maintenance and enforcement of an information security policy defining the use and misuse of IT systems and services. The total IT and business security environment must be understood, including:

• Business security policies and plans.

• Business operations and its security requirements.

• Future business plans and requirements.

• Legislative and regulatory requirements.

• Obligations and responsibilities with regard to SLA content.

• Business and IT risks and risk management.

Confidentiality, integrity and availability concerns are based on prioritizations, mainly defined by the business. As a result, discussions with the business must consistently ask what must be protected and what level of protection is involved. Much like availability, the higher the level of security requirements are for the customer, the more security solutions will cost. In this context, not all data and information may have the highest confidentiality requirements.


265

The information security management process will address the following concerns:

• Production, distribution, maintenance and enforcement of an information security policy

and supporting security policies.

• Understanding and responding appropriately to agreed current and future security

requirements of the business, including up-to-date business security policies and plans.

• Implementation of security controls to support the information security policies and

managing risks associated with service, information and system access.

• Management of access to systems and services by suppliers and contracts, in cooperation

with supplier management.

• Management of all security breaches, incidents, and problems.

• Improvement of security controls, security risk management and reduction of security risks.

• Integration with other service management process to alleviate and address security

elements.

• Establishment and maintenance of an information security management system (ISMS).


Security is a major concern for any business and addresses the protection of the customer’s assets, investments, and competitiveness in the marketplace. As a result, IT security is a natural subset of business security for two reasons:

• Much of a modern business’s assets, investments and competitiveness are a result of or

dependent on the information and data generated by, managed and used by the business.

• IT technologies and techniques can be used to protect the business.

For most businesses and people in general, IT can be its greatest commodity in protecting its assets and its greatest weakness because of lack of knowledge and experience by a business person. An effective information security management process will protect the business from internal and external factors threatening the confidentiality, integrity, and availability of services, information, data, and systems.

266




The information security policy can be a single policy with several statements or a combination of extensive policies. The information security policy will focus on and drive the activities of the customer and the service provider with regard to security. For instance, an information security policy may require the use of a physical lock when using a laptop containing company information off company premises.

The most common areas addressed by the information security policy include:

• Overall information security.

• Use and misuse of IT (company) assets.

• Access control.

• Password protection and control.

• Email usage.

• Internet usage.

• Remote access.

• Anti-virus.

• Information classification.

• Document classification.

• Supplier and contract access.

• Copyright protection and electronic documentation.

• Disposal of assets (hardware, software and data).

• Records retention.

For internal service providers the information security policies, the information used to produce it and its use within the organization will typically extend to the entire customer organization. For external service providers, the information security policies, preceding and subsequent information will be controlled and protected for each customer.


267

The information security management system (ISMS) is a formal system for establishing the policies and objectives for the organization and the means for achieving those objectives. The ISMS will consist of:

• The information security policy and specific security policies addressing every aspect of

strategy, control and regulations impacting the customer and/or service provider.

• The standards, management procedures and guidelines comprising the security

management information security used to support and enforce the information security

policy.

• Security strategies, aligned with business objectives, strategies and plans.

• Security organizational structure.

• Security controls supporting the information security policy.

• Security risks and their management.

• Monitoring processes ensuring compliance to the information security policy.

• Communications strategy and plans regarding security.

• Training and awareness strategy and plans.

The ITIL version of ISMS is based on guidelines from the formal ISO 27001 standard for information security management and incorporates the five elements of the ISO structure:

• Control.

• Plan.

• Implement.

• Evaluate.

• Maintain.

The control element of the ISMS focuses on the establishment of a management framework to initiate and manage information security within the organization, including an organizational structure for preparing, approving and implementing the information security policy. The framework will allocate responsibilities for information security throughout the organization and establish and control the confidentiality, integrity and availability of documentation, particularly that of information security.

268



The planning element of the ISMS will focus on recommending appropriate security measures, based on the requirements of the organization. These requirements, gathered from various business and IT sources, will serve to understand the strategies, risks, plans, and legal, moral and ethical aspects of information security within the organization and will define what needs to be addressed within the information security policy. The output of the plan element is the information security policy.

The implementation element of the ISMS will focus on the implementation of procedures, tools and controls needed to support and enforce the information security policy. Much of the work involved will be in conjunction with the configuration management system, service knowledge management system and data or knowledge management efforts of the customer. Successful implementation requires:

• Clear and agreed information security policy aligned to business needs.

• Security procedures justified and supported by senior management.

• Effective marketing and education in security awareness.

• Mechanism of improvement.

The evaluate aspect of the ISMS will supervise and check compliance with the information security policy and security requirements. Evaluation can be done though several methods, including system monitoring, security audits, and oversight from external auditors and regulators.

The maintain element focuses on improvement: namely improvement of security-related content within agreements and improvement of security measures and controls implementing in the environment.

As mentioned before, information security management is performed within the context of corporate governance; therefore, it should be expected that a level of information security governance is supported by and driven by the information security management process. Information security governance, itself, seeks the achievement of six outcomes:


269

• Strategic alignment – security requirements are driven by corporate requirements and

subsequent solutions support corporate business processes. Investments in information

security are aligned with the strategies and risk profile of the company.

• Value delivery – a standard set of security practices are devised and implemented

universally across the entire organization, though the use of structure, process and

technology and an emphasis on continual improvement.

• Risk management – a risk profile is agreed upon, and demonstrates a clear understanding

of risk exposures, priorities, and reasons and solutions regarding mitigation, acceptance or

deference of risk.

• Performance management – a meaning set of metrics are defined and agreed upon and

managed by a process that will identify and address security vulnerability.

• Resource management – knowledge regarding security, including processes and practices

is captured and made available to all key participants. Infrastructure resources are used

efficiently to establish a security architecture.

• Business process assurance.


The key activities for information security management include:

• Production and maintenance of an information security policy and supporting policies.

• Communication, implementation, and enforcement of security policies.

• Assessment and classification of all information assets and documentation.

• Implementation, review, revision and improvement of security controls, risk assessments

and response to risks, including assessment of impact from individual changes on security

and implementation of improvements to security.

• Monitoring and management of all security breaches and major security incidents.

• Analysis, reporting and reduction of the number and impact of security breaches and

incidents.

• Schedule and completion of reviews, audits and penetration tests regarding information

security.

270



10.13.6 Triggers, Inputs and Outputs

Information Security Management will be triggered by the following events:

• New or changed corporate governance guidelines.

• New or changed business security policies.

• New or changed corporate risk management processes and guidelines.



• New or changed targets and agreements.

• Periodic BIA and risk assessments activities.

• Review, revision, or reporting of business or IT strategies and plans.

• Review and revision of designs and architectures.

• Review, revision or reporting of information security management policies, reports and

plans.

• Service or component security breaches, including warnings, events and alerts.

• Change of risk or impact on a business process, VBF, IT service or component.

• Request for assistance from other processes on security-related issues and/or activities

The inputs and outputs of Information Security Management are summarized in the following table:

Inputs OutputsBusiness information Information security management policyCorporate Governance and Security Specific security policiesIT information Security management information system

(SMIS)Service information Revised security risk assessment processes

and reportsRisk assessment processes and reports Security controls, with details on operation,

maintenance and risksChange information Security audits and audit reports


271

Inputs OutputsDetails of all security events and breaches Security test schedules and plans, including

penetration testsConfiguration management system Security classification and set of classified

information assetsDetails on access by partners and suppliers Reviews and reports of security breaches

and major incidentsPolicies, processes, and procedures for

managing partner and supplier access to

services and information

The major interfaces for Information Security Management are with the following processes:

• Service Level Management – seeks assistance to determine security requirements,

responsibilities and their inclusion in SLRs and SLAs, as well as the investigation and

resolution of security-related service and component breaches.

• Access Management – performs the granting and revoking of access as defined by the

information security policy.

• Change Management – all changes are assessment for their impact on security and changes

to security plans and controls are controlled through the change management process.

• Incident and Problem Management – indication of potential security incidents and

problems.

• IT Service Continuity Management – involved in security breaches considered as

catastrophic events, as well as security needs during the event.

• Availability Management – enabled by ISM to ensure the availability and integrity of assets,

information, and data.

• Capacity Management – considers security implications when selecting and introducing

new technology.

• Service Asset and Configuration Management – documents details of configuration items to

assist with security classifications.

• Financial Management for IT Services – ensures adequate funding to meet security

272



requirements.

• Supplier Management – assists in the management of suppliers as it related to security and

access to services and systems.

• Legal and Human Resources – considered when investigating security issues.


The following critical success factors and key performance indicators are samples related to Information Security Management. Each critical success factors has at least one key performance indicators which is used to demonstrate achievement of the CSF.

• Business is protected from security violations:

Ř Decreased percentage of security breaches reported to service desk.

Ř Decreased percentage on impact from security breaches and incidents.

Ř Increased percentage in SLA conformance to security agreements.

• A clear and agreed policy is defined and integrated with the needs of the business:

Ř Decrease in the number of non-compliances of the information security management

process with the policies and process for business security.

• Security procedures are justified and supported by senior management:

Ř Acceptance and conformance of security procedures increasing.

Ř Support and commitment of senior management to security process and policies

increasing.

• Marketing and education in security requirements is effective and IT staff awareness of

technology supporting the services is competent:

Ř Awareness of security policy and its contents is increasing throughout the organization.

Ř Increased percentage in completeness of supporting services against IT components

supporting those services.

• Information security management is a mechanism for improvement:

Ř Increased number of suggested improvements to security procedures and controls.

Ř Decrease in the number of security non-compliances found during security audits and

testing.


273

• Information security is an integral part of all services and processes managed by service

provider:

Ř Increased conformance with security procedures and controls by services and processes.

• Security incidents are not compromising the availability of services:

Ř Decreased percentage in the impact of security breaches and incidents.

Ř Decreased percentage in the number of incidents of service unavailability caused by

security breaches.

• Security policies have a clear owner and awareness perceived in customer community:

Ř Increased percentage in acceptable scores on security awareness questionnaires

completed by customers and users.


An effective information security management implementation requires the cooperation of the business, business security, and senior management. This is because information security will drive the policies and guidelines of the business throughout the implementation of IT infrastructure, applications and processes; which will also require some level of support or ability to directly enforce information security policies by customers and users of IT and IT services. For many businesses, it is erroneously assumed that the IT service provider is wholly responsible for IT security; however, the use of IT and IT services are mostly used outside the IT organization where they have little to no authority. Without the support, funding, and commitment from the business and senior management, information security would simply be a set of scripted statements with little meaning.

The risks associated with information security management include:

• Increasing requirements for availability and robustness.

• Potential for misuse and abuse of information systems to invade privacy and override ethical

values.

• External dangers from hackers.

• Lack of commitment from the business.

274



• Lack of commitment from senior management.

• Focus is heavily on technology solutions rather than processes, services or the needs and

priorities of the business.

• Risk assessment and management performed within support from availability management

and ITSCM.

• Policies, plans, risks and information regarding security is out-of-date.

• Security policies becoming increasingly bureaucratic and ineffective.

• Security policies providing little to no value to the business

10.13.9 Summary for Information Security Management

Like most companies, ContXT has to be responsible for the security needs of its information and the information obtained by their client base. As a marketing firm, they have access to privileged information about their client’s future plan, products and services. Should that information be leaked to public media, then the strategic competitiveness of their clients will be adversely impacted, as well as the reputation of the company. For this reason, ContXT has strict confidentiality guidelines and requirements for their employees, the systems they use, and the data gathered, analyzed and used to establish and manage marketing campaigns.

Most business and communication is performed in-house, behind the physical doors of the company and the company’s firewall. Internet use is heavily managed and used only for research purposes or building web sites. Many designers, web-programmers, and managers have access to two computers: one with Internet access and the one with internal access only. The project management system and knowledge management system would be associated with the internal network system.

With the expected increased demand on video- and tele-conferencing services, the business has some concerns on exactly what should and should not be communicated during these meetings. After some investigation into third party solutions, the recommendation was to invest in closed, secure lines of communication when using these services. This required the use of an access code sent to participants and announcement of participants entering and exiting


275

the meeting. The feeling was these technical controls will ensure any unauthorized access to the meeting was minimized. Business policies would control what constraints for communication would exist once the secure line was established.

The proposed service of serious concern for ContXT was the advent of remote access to internal systems. In the past, remote access to systems has been forbidden because of the potential security issues. Though employees had the option to work away from the office, any data they needed had to be placed on a secured drive. However, remote access technology has become increasingly secure over the last few years and there is a greater demand to enable work from home opportunities for the employees.

In essence, business policies determine the viability and practices of using a particular technical solution, while the capabilities of the solution can possibly influence how business policies are shaped. In every service being formalized by ContXT, the need for security must consider the business and the IT perspective; some service more than others. Businesses which can isolate their operations from external influence can put strict controls in place to keep information flow internal. In the strictest settings, Internet access is disabled and the use of cell phones and email are prohibited except on designated systems. Allowing access to external sources of information also creates opportunities to send information to external sources, thus controls need to be placed on what and how information is communicated through the Internet, email, telephony, and so on. Providing the means to access internal information from outside the firewall brings a number of concerns, as the company is exposing more of its internal network to the outside world. In most situations, bridging the firewall is conducted by creating specific gateways which control the traffic between internal and external sources.

276




1. Which of the following IT concepts is not directly addressed by Information Security

Management?

A. Confidentiality

B. Integrity

C. Availability

D. Continuity

2. The information security policy may cover a number of topics; which of the following is not

typically addressed in this policy?

A. Remote access

B. Document control

C. Supplier access

D. Access control

3. What international standard is information security management most dependent upon?

A. ISO/IEC 20000

B. COBIT

C. ISO/IEC 27001

D. MOF

4. What element of the ISMS is responsible for the establishment of a management

framework?

A. Maintenance

B. Implement

C. Plan

D. Control


277

5. What element of the ISMS is most dependent on the information found in the CMS in order

to be accountable for asset security?

A. Implement

B. Control

C. Maintain

D. Evaluate

6. Audits are performed in what element of the ISMS?

A. Plan

B. Control

C. Evaluate

D. Maintenance

7. Which of the following is not an outcome of information security governance?

A. Value delivery

B. IT process assurance

C. Strategic alignment

D. Risk management

8. Which of the following is not an output of information security management?

A. Security governance

B. Security policies

C. Security controls

D. Security audits

278



9. What service management process is most active in applying information security policies

to the operational environment?

A. Availability management

B. Access management

C. Change management

D. Service level management

10. What critical success factor of information security management is best supported by the

KPI, “Percentage increase in SLA conformance to security clauses”?

A. Information security is an integral part of all services

B. Security incidents are not compromising the availability of services

C. Business is protected against security violations

D. Security policies has a clear owner


279

10.15 Supplier Management

Supplier Management focuses on the control and management of third-party suppliers of IT services and products to ensure achievement of the customer’s agreed outcomes and targets. Essentially, the service provider has made arrangements to provide the necessary levels of utility and warranty to the customer, but they do not have the resources and/or capabilities to do so on their own: therefore, they are leveraging the services and products of a third-party to provide the added utility and/or warranty needed to satisfy the customer.

The truth is, every service provider uses suppliers. Utility companies are suppliers of power, water, telephony and disposal services which few service providers can provide on their own. Services like security, construction and messaging require skills and management which is outside the core competencies of most businesses. Even the use of IT hardware and software is initiated by engaging an outside manufacturers or developers of products suitable to support the customer. Finally, a company seeking a competitive position in a market or attempting to remain compliant to any laws, regulations or standards are likely to engage external consultants or auditors to look at their business operations and make recommendations for improvements. Given all these examples, the necessity of supplier management becomes increasingly clear.


The purpose of the supplier management process is to ensure a seamless quality of IT services to the customer that meet their agreed needs and to ensure the supplied portions contributing to that quality captures sufficient value compared to the monies spent. Suppliers can provide an entire service or they may only provide part of a service. Some suppliers may be passive, like wholesalers of hardware and software components which make up the IT infrastructure, while others are more active, like the manager/developer of the company’s web site, application, or service.

280



In all cases, the service provider must determine whether the value provided by the supplier is sufficient for the price of that value. If this sounds familiar, it is because it is similar to the customer’s perspective of value from the service provider introduced in service strategy: in this case, the service provider is the customer, and represents the customer, of the supplier. Supplier management, in this sense, is a means of expanding the value discussion as more participants are added to the support and delivery of services.

The objectives of supplier management include:

• Obtain value for money spent.

• Ensure supplier contracts (underpinning contracts) are aligned to business needs and

support agreed targets in SLRs and SLAs.

• Manage relationships with suppliers.

• Manage supplier performance.

• Negotiate and agree contracts with suppliers.

• Maintain a supplier policy.

• Maintain a supplier and contract management information system (SCMIS).

10.15.2 Scope

SLAs are agreements made between customer and service provider. OLAs are agreements made with subset groups within both the customer and service provider organizations to support the agreed SLAs. Only when agreements have to be made with organizations outside the customer and service provider is supplier management required. Underpinning contracts are similar in intent as OLAs with internal or customer groups.

The best way to look at supplier management is to look at the value chain of a service. The service provider must look at their own resources and capabilities in supporting each link in the value chain: if they do not have the resources and capabilities to do so, they must find them elsewhere. The resources could be human and contracting companies may become permanent suppliers of skills and experience needed. The resources could be specific hardware


281

and software components and the suppliers may be the manufacturers/developers, as well as distributors. In these situations, the basis for choosing the right supplier would be the technical specifications of the components themselves. The supplier can even provide the full or partial service(s) required for that link in the value chain or multiple links in several value chains.

Simply, suppliers provide the necessary resources and capabilities needed by the service provider to deliver and support the promised services. The greater the contribution from the supplier is, the greater the need to maintain and manage the relationship between the supplier and service provider. In this sense, some relationships with supplies may evolve into partnerships while others are maintained at a basic operational level. Supplier management supports all types of supplier relationships.

The process for supplier management should include activities for:

• Implementing and enforcing a supplier policy.

• Maintenance of a SCMIS.

• Categorizing and assessing risks on different suppliers and contracts.

• Evaluating and selecting suppliers and contracts.

• Developing, negotiating and agreeing to contracts.

• Review, revision and termination of contracts.

• Managing suppliers and supplier performance.

• Identifying improvement opportunities for suppliers and supplier relationships.

• Maintaining standard contracts, terms and conditions.

• Managing resolutions to contract disputes.

• Managing sub-contracted suppliers.

282




The primary value of supplier management is ensure the correct levels of resources and capabilities are available to deliver the utility and warranty required by the customer when facilitating the achievement of the customer’s desired outcomes. The famous quote, “no man is an island” can be applied to the concept of supplier management as it is highly unlikely that a single service provider can meet all the intricate requirements on their own. An effective supplier management process will enable the service provider to deliver exactly what they promised without owning all the costs and risks.

10.15.4 Policies, Principles and Basic Concepts

In service strategy, a sourcing strategy was developed which defined in what capacity suppliers were to be used. This is the supplier strategy which defines how the contribution of suppliers will be leveraged to support and deliver services to the customer. The strategy will provide the conditions for when a supplier is used, what suppliers will be used, and to what extent.

These conditions will likely be translated into supplier policies, which should cover:

• Acceptable methods of communication with potential suppliers before and during

engagement processes, such as solicitation, bidding and procurement.

• Allocation of roles and responsibilities, i.e. the assignment of supplier manager.

• Rules controlling the acceptance of gifts and promotional items from suppliers.

• Standards used in supplier selection.

• Standards and guidelines for different contract types and/or agreement types.

• Guidelines on data ownership and access policies, in alignment with information security

policies.


283

The basis of the supplier relationship is the underpinning contracts and agreements created between the supplier and service provider. An underpinning contract should be:

• Comprehensive – to minimize the risk of disputes arising from difference of expectations.

• Flexible – to minimize the risk of not adapting to the changing environment of the

customer, service provider and/or supplier.

The typical contents of an underpinning contract include:

• Basic terms and conditions.

• Service description and scope.

• Service standards.

• Workload ranges.

• Management information.

• Responsibilities and dependencies.

• Incentives and penalties.

The form of the agreement, as well as the language and terminology used within the contract may be controlled by legal and procurement standards and methods.

In reality, contracts and agreements provide two different levels of distinctions. Contracts are formal agreements used when the contributions of the supplier are significant to the service provider. They are legally binding and are used when an enforceable commitment is required. Underpinning agreements are similar to OLAs and are designed to formalize the service-based relationships between supplier and service provider. In this sense, contracts can be more strategic and tactical, while agreements take on an operational focus. The distinction may be important when the supplier’s services are being leveraged across several customer sets with a variety of customer requirements regarding process or deliver, or the supplier is providing several different services to support the service provider.

284



The supplier and contract management information system (SCMIS) is a database or structured document used to manage all supplier relationships and contracts, including potential suppliers and retired contracts. The SCMIS should be integrated with the SKMS and CMS, with relationships made to supplemented services and components. The services provided by suppliers should also be represented within the service portfolio and service catalog. The specific content found within the SCMIS should include:

• Definition of new supplier and contract requirements.

• Evaluation and set up of new suppliers and contracts.

• Categorization of suppliers.

• Procedures for maintaining the SCMIS.

• Establishment of new suppliers.

• Management of suppliers and supplier performance.

• Management of contracts.

• Procedures for contract renewal or termination.


The outline of the SCMIS content is consistent with the general activities of the supplier management process, which includes:

• Defining new supplier and contract requirements:

Ř Identifying business needs and establishing a business case.

Ř Producing a statement of requirements (SoR) and/or invitation to tender.

Ř Ensuring conformance to supplier strategy and policies.

• Evaluating new suppliers and contracts:

Ř Identifying method of purchase or procurement.

Ř Establishing criteria for evaluating suppliers.

Ř Evaluating alternative options.

Ř Selecting supplier.

Ř Negotiating contracts, targets and terms, and conditions.

Ř Awarding the contract to desired supplier.


285

• Categorizing and maintaining information about suppliers and contracts:

Ř Assessing/reassessing supplier and contract.

Ř Ensuring changes move through service transition.

Ř Categorizing supplier.

Ř Updating SCMIS with relevant information.

Ř Maintaining information in the SCMIS.

• Establishing new suppliers and contracts:

Ř Adding information about supplier, contract, and services within the SCMIS and other

systems.

Ř Transitioning the supplied service(s).

Ř Establishing contacts and relationships.

• Managing supplier, contract and performance:

Ř Managing and controlling the operation and delivery of service and/or products.

Ř Monitoring and reporting on service, quality and costs.

Ř Reviewing and improving service, quality and costs.

Ř Managing the supplier and supplier relationships.

Ř Reviewing, at least annually, the contract and service scope against requirements, targets

and agreements.

Ř Planning possible renewal or termination of contract.

• Renewing or terminating contracts:

Ř Reviewing contract.

Ř Renegotiating and renewing, terminating or transferring contract.

Ř Transitioning to new supplier (internal or external).

The first three activities are performed within service design, the fourth within service transition, and the final two within service operations; however, all activities of supplier management structure should be designed, developed, and implemented using the structure of the service lifecycle.

286




Supplier Management will be triggered by the following events:

• New or changed corporate governance guidelines.

• New or changed business strategies, policies, or plans.



• New or changed targets and agreements in SLAs.

• Review, revision or reporting of business or IT strategies and plans.

• Review and revision of designs and architectures.

• Review, revision or reporting of supplier management policies, reports and plans.

• Request for assistance from other processes on supplier-related issues and/or activities,

particularly service level management.

• Requirements for new contracts, contract renewal, or contract termination.

• Re-categorization of suppliers and contracts.

The inputs and outputs of Supplier Management are summarized in the following table:

Inputs OutputsBusiness information Supplier and contract management

information systemSupplier and contract strategy and policies Supplier and contract performance

information and reportsSupplier plans and strategies Supplier and contract review minute

meetingsSupplier contracts, agreements, and targets Supplier service improvement plans

Supplier and contract performance

information

Supplier survey reports

IT informationPerformance issues from incident and

problem management


287

Inputs OutputsFinancial informationService informationConfiguration management system

The major interfaces for Supplier Management are with the following processes:

• Service Level Management – assists with determining targets, requirements and

responsibilities for suppliers, as well as manages contract breaches caused by poor supplier

performance and impacting existing SLAs.

• Change Management – controls changes to supplier contracts and agreements as well as

those changes requiring the involvement of suppliers.

• Information Security Management – ensures proper access is provided to suppliers for

systems and services as well as compliance to information security policy from suppliers.

• Financial Management for IT Services – ensures proper funding is available to finance

supplier management requirements and contracts.

• Service Portfolio Management – includes information on supplied services to assist in

determining or validating investment strategies.

• IT Service Continuity Management – works with supplier management to manage service

continuity suppliers.


The following critical success factors and key performance indicators are samples related to Supplier Management. Each critical success factors has at least one key performance indicators which is used to demonstrate achievement of the CSF.

• Protection from poor supplier performance or disruption:

Ř The number of suppliers meeting contractual targets is increasing.

Ř The number of breaches of contractual targets is decreasing.

• Supporting services and targets are aligned with business needs and targets:

288



Ř The number of service and contractual reviews with suppliers is increasing.

Ř The number of supplier and contractual targets aligned with SLA and SLR targets is

increasing.

• Supplier performance does not compromise service availability:

Ř The number of service breaches caused by suppliers is decreasing.

Ř The number of threatened service breaches by suppliers is decreasing.

• Supplier and contractual issues clearly owned and known by appropriate managers:

Ř The number of suppliers with assigned service managers is increasing.

Ř The number of contracts with assigned contract managers is increasing.


The challenges of supplier management include:

• Changing business and IT needs requires continual reassessment of supplier and contract

value.

• Having to work with imposed contracts with poor targets, or terms and conditions, or

definition of service or supplier performance targets.

• Issues related to legacy systems or solutions.

• Insufficient expertise retained within the service provider organization to determine

effectiveness of supplier.

• Long-term contracts with no expectation of improvement and punitive penalties for early

termination.

• Interrelated dependencies between supplier and service provider deliverables which can

impact performance, i.e. the supplier need data feed from service provider.

• Disputes over service charges.

• Interference by either party in operations.

• Drifting into a reactive approach to service delivery, rather than proactive, by either party.

• Poor communication.

• Personality and/or cultural conflicts.

• One party taking advantage of the other within the contract.


289

• Losing strategic perspective and focusing on operational concerns.

These challenges are best handled through:

• A clear, well-written and well-managed contract.

• A relationship which is mutually beneficial.

• Clearly defined roles and responsibilities of both parties.

• Good interfaces and communication.

• Well-defined service management processes adopted by both parties.

• Achievement of recognized certifications by the suppliers.

The risks associated with supplier management include:

• Lack of commitment by business and senior management.

• Lack of information on future business and IT strategies, policies and plans.

• Lack of resources, including financial.

• Badly written and agreed contracts, specifically those done in the past.

• Suppliers agreeing to targets or service levels that are impossible to meet.

• Supplier personnel or organizational culture that is not aligned with the service provider or

the business.

• Lack of clarity or integration with service management processes, policies and procedures.

• Uncooperative suppliers.

• Changes in the supplier ownership, organization, and/or relationship.

• Excessively demanding or bureaucratic supplier and contract procedures.

• Poor corporate financial processes.

290



10.15.9 Summary of Supplier Management

The current IT staff of three in ContXT is a major driver for considering suppliers in enhancing the marketing firm’s resources and capabilities related to the proposed services. After clearly understanding the business requirements on IT and negotiating suitable service level agreements, supplier management provides the means of discovering, evaluating, and selecting potential suppliers for these services, as well as negotiating contracts aligned with the aforementioned SLAs.

Supplier management continues to play an active role in reviewing and reporting the value provided by various suppliers and exploring new or better options for the company.


291


1. Which of the following systems is the responsibility of supplier management?

A. SMIS

B. SCMIS

C. CMS

D. AMIS

2. What service management process does supplier management work closest with to ensure

delivery of supplied services and components meet business requirements?

A. Availability Management

B. Change Management

C. Business Relationship Management

D. Service Level Management

3. The supplier and contract management information system should be integrated with

which other management system?

A. Configuration management system

B. Service portfolio

C. Information security management system

D. Capacity management information system

4. In what supplier management activity is an invitation to tender produced and distributed to

potential suppliers?

A. Evaluating new suppliers

B. Establishing new suppliers

C. Defining new supplier requirements

D. Maintaining information about suppliers

292



5. Which of the following is not a supplier management activities performed in service design?

A. Defining new requirements

B. Evaluating new suppliers

C. Categorizing information about suppliers

D. Establishing new suppliers

6. Which of the following is an input to supplier management?

A. Supplier performance repots

B. Supplier strategy

C. Supplier SIPs

D. Supplier and contract reviews

7. Managing supplier access to relevant systems is the responsibility of what service

management process?

A. Supplier Management

B. Service Portfolio Management

C. Information Security Management

D. Change Management

8. Which critical success factor of supplier management is best supported by the KPI, “increase

in the number of service and contractual reviews held with suppliers”?

A. Business protected from poor supplier performance or disruption

B. Supporting services and their targets align with business needs and targets

C. Availability of services is not compromised by supplier performance

D. Clear ownership and awareness of supplier and contractual issues


293

9. Which of the following is not a challenge facing supplier management?

A. Lack of commitment from customer

B. Dispute over service charges

C. Insufficient expertise retained within the organization

D. Personality and/or cultural conflicts

10. Which of the agreement types is managed by supplier management?

A. Service level agreements

B. Operational level agreements

C. Underpinning contracts

D. Service requirements

294

11 Technology-Related Activities

Service Design can leverage several common standards and technologies, including:

• Requirements engineering.

• Data and information management.

• Application management.

11.1 Requirements Engineering

The effectiveness of discovering and managing requirements is a valuable skill for IT service management and service design, in particular. Because service design is an effort to identify appropriate solutions which can meet requirements, its success is highly dependent on how well requirements are managed. Requirements engineering is an approach which brings rigor and control to the requirements process. The approach supports three stages:

• Elicitation – asking for requirements.

• Analysis – clarifying the requirements.

• Validation – seeking agreement on the requirements.

Several models are available for requirements engineering, including:

• Recommended practice for software requirements specification (IEEE 830).

• Software Engineering Body of Knowledge (SWEBOK).

• Capability Maturity Model Integration (CMMI).

• V-Model.

Chapter 11

295

Many businesses may already have guidelines for requirements engineering in other parts of the business which can be adapted effectively in managing the requirements regarding IT services. Service requirements can be categorized into different types:

• Functional requirements:

Ř Service utility.

Ř Tasks and functions performed.

Ř Data used and exchanged.

Ř Goals and objectives of activities.

Ř Static and dynamic characteristics of the service.

• Management and operational requirements:

Ř Manageability.

Ř Efficiency.

Ř Availability.

Ř Reliability.

Ř Capacity and performance.

Ř Security.

Ř Installation.

Ř Continuity.

Ř Controllability.

Ř Maintainability.

Ř Operability.

Ř Ability to measure and report.

• • Usabilityrequirements:

Ř Ease of use.

Ř Aesthetics.

Several techniques can be used to identify and verify requirements, including:

• Interviews.

• Questions.

• Repots and records.

• Workshops.

296



• Observation.

• Activity sampling.

• Protocol Analysis.

• Shadowing.

• Scenario analysis.

• Prototyping.

Requirements engineering has a number of challenges to its success. The most prevalent is the lack of skill and understanding of an area. This can result in not enough people seeking requirements or too many people. When not enough people are involved, then the set of requirements are not fully formed: for instance, security requirements are missing because a security expert was not involved or the service desk is unprepared to support a new service because they have no idea of the volume of calls for the service. Having too many people is a problem: a customer can be inundated with dozens of people asking the same question but seeking different perspectives. This can be incorrectly perceived as the service provider not knowing their business or not being unified.

Other problems with requirements include:

• Lack of relevance to service objectives.

• Lack of clarity.

• Ambiguity.

• Duplication.

• Conflicts.

• Expressed in a manner which makes achievement uncertain.

• Expressed as a solution.

• Uncertainty from multiple users about what is really necessary.

• Omissions.

• Inconsistent levels of detail.

• Failure to engage key stakeholders (customer and service provider).

• Assumption that parties working requirements have the proper knowledge (customer and

service provider).


297

• Failure to include non-technical requirements.

• Scope creep – gradual additions of small requirements without considering combined

impact on project plan.

Ideally, the solution to the above problems is involve the appropriate people before engaging the customer and understanding what questions should be asked and how they can impact multiple areas. Using this list of questions, fewer people can question the customer, but they are armed with a broader set of questions and understanding of their value across the IT spectrum. But even when seeking requirements, ensuring the right people are participating is important and should include the following groups:

• The business.

• The user (domain experts and end-users).

• The service developer.

• The service manager.

The main problem with requirements gathering is the focus on explicit knowledge, namely what a person can successfully articulate and explain. However, many errors in requirements can be attributed to not effectively mining tacit knowledge. Here are some common reasons:

• Lack of communication skills.

• Information taken-for-granted that “everyone” should already know.

• Tendency to frame a positive spin (front-story) on difficult circumstances, process, or

workplace (back-story).

• Focus on knowledge using future technologies or systems.

• Lack of a common language.

• Lack of intuitive understanding.

• Organizational culture.

298



Every requirement must be documented. At minimum, the documentation of a requirement should include:

• Requirement.

• Source.

• Comment.

• Detail level.

A requirement may need to be rewritten and verified several times until it is well-formed and SMART (specific, measurable, achievable, relevant and time-bound). If there are dependencies between requirements, they should be noted: for instance, you require car insurance if you have a car. Once a requirement or set of requirements have been documented, they can be accepted.

Organizations will want to store documented requirements in a requirements catalog which is attached to the service pipeline of the service portfolio. In this catalog, more detail can be added to the requirement, including:

• Owner.

• Priority (must have, should have, could have, and won’t have).

• Related documents.

• Supported business process.

• Justification.

• Related requirements.

• Change history.


299

11.2 Data and Information Management

Data is a valuable asset of business life: and of providing effective IT services. Data management provides a structured approach to planning, collecting, generating, organizing, using, controlling, distributing, and disposing of data. Effective data management ensures:

• All users have ready access to the information they require through a variety of channels.

• Data assets are fully exploited (shared), within and outside the organization.

• Data assets are protected and secured according to corporate and IT security policies.

• The quality of data is maintained at an acceptable level and must be accurate, reliable and

consistent when used in business dealings.

• The privacy, security, confidentiality and integrity of data are maintained as prescribed by

legal requirements.

• Data and information-handling activities are performed with a high level of efficiency and

effectiveness.

• An enterprise data model is used and defines the most important data entities and their

relationships.

Without effective data management:

• Data is collected and maintained which is not needed by the business.

• Historical data is retained past its usefulness.

• Large amounts of data can be stored which is inaccessible to potential users.

• The dissemination of information may be too many people or too few people than

necessary.

• Inefficient and outdated methods are used when collecting, analyzing, storing and

retrieving data.

• Regulatory requirements are not always adhered.

• The data required by the business is not collecting, reducing the overall quality and integrity

of the data.

300



The scope of data management covers:

• Management of data resources.

• Management of data/information technology.

• Management of information processes.

• Management of data standards and policies.

When data management is applied to the service lifecycle, the following questions must be addressed with each service:

• What data is currently stored and availability and how is this data classified?

• What data still needs collection or created by the business processes?

• How will data be stored and maintained?

• How will data be accessed, by whom, and using what channels?

• How will data be disposed of, and under whose authority?

• How will data quality be maintained?

• How can the availability or accessibility to data be increased?

During the requirements and initial design of a service, the service provider should be data models for each service. Experts in data management should be made available to consult on database management systems and the conversion of logical data models into physical implementations for the service. Data must be considered an asset to the business and the service provider; and therefore data has value. The value of the data can be calculated through:

• Its availability.

• Its value when lost.

• The details of its lifecycle (creation, use, retirement).

• Its classification.

Data is typically classified as operational, tactical or strategic. Operational data describes the ongoing functionality of the organization. Tactical data is usually valuable to second-line managers who are looking for a summarization of operational data or historical data. Tactical data is generally disseminated every quarter or annually. Strategic data is focuses on long-term trends and comparisons with the industry, market space, or competition. While this is not the


301

only approach to classifying data, it serves the purpose of understanding how data should be collected, store, and disseminated across the organization.

Data standards are deeply integrated into data management practices. The first indication of standardization relates to “metadata,” or the data about the data. Metadata standards will often require the assignment of ownership, unique identification for data sets, meaningful data descriptions, a consistent format and the like. Some standards are influenced by outside data standards, such as postcodes, hyperlinks, area codes, country codes, and so on. Still, some data standards are the result of legislative and regulatory requirements which define specific practices to be performed in data management, including:

• Data ownership.

• Data migration.

• Data capture.

• Data storage.

• Data retrieval and usage.

• Data integrity.

11.3 Application Management

An application is any “software that provides functions which are required by an IT service” (Service Design, page 244). In most cases, the functions provided by an application make up the utility required of a service, which is supported by underlying IT components, such as data, hardware, operating systems, and middleware. For instance, an IT service providing business transactional support to the customer will often have, at its core, an application which initiates and manages the lifecycle of the business transaction. However, the application is only one component of the service and service design must address how all components work together to deliver and support the service. This requires a focus on both functional and non-functional requirements of the service.

302



The management of applications requires two approaches: a service development lifecycle (SDLC) used in developing individual services and a global management system for ensuring the ongoing maintainability and manageability of the applications. The SDLC is a systematic approach to problem solving and has the following steps:

• Feasibility.

• Analysis.

• Design.

• Testing.

• Implementation.

• Evaluation.

• Maintenance.

The global approach ensures all applications are described consistently within an application portfolio, a limited number of application frameworks and design patterns are used when developing individual applications and common software components are created and used.

The application portfolio is a database or structured document which contains the defining attributes for all applications within the service environment. The portfolio may be managed separately from other databases and structured documents or they may be a subset of these other assets, namely the configuration management system and/or service portfolio. However, an organization wishes to organize and manage the application portfolio, a basic requirement for the portfolio is to describe the relationships between the applications documented, the services they support and the infrastructure components used to support the application.

Application frameworks are a means of standardizing the management and operational aspects of the applications in use. Frameworks can provide benefits to application developers and users alike by providing common themes, guidelines, and functionality. Some people may see productivity suites, like Microsoft Office, as an application framework because each application has similar functions which are shared, exploited, or integrated. In the same vein of thought, document creator (MSWord, Notepad, WordPad, and Adobe) may be a form of application framework even though they come from different developers and publishers: despite the different sources, they all have the same basic functionality and are often compatible with each


303

other in some way. Application frameworks are a simple means of developing and enforcing architectures and standards which can/must be applied to the various applications used in the environment.

The purpose of application design is to meet the requirements of the organization and includes not just the design of the application, but the design of the infrastructure and environment which the application will operate. As a general rule, success will come for familiarity: the use of standard application and operational architectures will increase the success rate for developing applications. However, architectural considerations will impact how applications and the environment they operate in will be structured and what they can contain. As a result, the architectures themselves may define or influence the requirements of the application and underlying infrastructure.

Another concern of application design is its integration into the existing environment, as it is possible to share resources already in place. This level of integration will impact the existing environment by increasing demand on individual components. With the many different aspects to consider in application design, it may not always be possible to foresee every nuance in detail: for this reason, application design is a constant cyclical effort, rather than a linear approach with a specific end data.

In addition to application frameworks, design patterns may be used in the design of an application or the underlying infrastructure. Design patterns are simply repeatable solutions to commonly occurring problems. For instance, one problem for business applications is the need for authentication, either to access the application or to perform specific functions within the application. Rather than creating individual authentication capabilities within each application, a common solution may be available which can be designed into every application. In this situation, the authentication solution acts as a design pattern and will show relevant relationships and interactions in the environment necessary to enforce authentication.

304



Design patterns are a key feature of object-oriented programming and service-oriented architectures. This is the result of an application (or service) being broken down in to smaller, more manageable components. Individual components can be modified and improved with little to no impact on the other components. While an individual application may not have use for every available component in the environment, different combinations of components will result in different distinguishable functionality or applications with very little effort being made in the development process.

Once an application is designed, it continues into its development phase, where both the application and environment it will reside will be built and transitioned. The development team must maintain a focus on the management and operating aspects of the application as well as understand how the application fits within the overall service solution.

From a design perspective, several development concepts must be produced to ensure a consistent approach is implemented. The most prominent concept is a coding convention; this is a means of standardizing how an application is structured and coded. One reason for the need to standardize coding is the number of programmers who may be involved in the development of an application, currently and in the future. As portions of the application are parsed out to different programmers, different approaches to coding will result in confusion and potential lack of interoperability when the different pieces are brought back together. Standard coding conventions can also benefit separate applications which need to interact with each other.

Another means of driving consistency, especially between multiple applications is the development of templates or skeletons which allow developers to build code by “filling in the blanks.” These templates can also include diagnostic hooks which can be used during testing to identify any errors in the code and provide measurement and management information about the operational state of an application.


305

There are four main categories of diagnostic hooks

• System-level information from operating systems and hardware.

• Software-level information from application infrastructure components (databases, web

server or messaging systems).

• Customer information from applications.

• Information on component and service performance.

306




1. Which of the following is not a stage in requirements engineering?

A. Elicitation

B. Analysis

C. Validation

D. Improvement

2. Security falls within what type or classification of requirement?

A. Functional

B. Operational

C. Warranty

D. Usability

3. Which of the following means of collecting IT requirements are most commonly used?

A. Interviews

B. Observation

C. Shadowing

D. Prototyping

4. Which of the following situations are not typically addressed in interviews to gather

requirements?

A. Current business process

B. Problems with current operations

C. New features for business systems or services

D. Retirement of services


307

5. Workshops are best suited in gathering requirements under what conditions?

A. Insufficient knowledge in process area exists

B. Distrust exists among customer and business representatives

C. Time or budget allowances are constrained

D. Alignment to business needs requires multiple viewpoints

6. What technique in requirements gathering creates a story around respective tasks?

A. Observation

B. Scenario Analysis

C. Shadowing

D. Activity sampling

7. What is the primary problem with requirements engineering?

A. The lack of detailed skill and overall understanding of the area where requirements

engineering is used

B. Insufficient time or budget to engineer good requirements

C. Duplication and conflicts with individual requirements

D. Gradual additions of small requirements

8. When documenting requirements initially, which of the following is not required?

A. Description

B. Source

C. Owner

D. Detail level

9. Which of the following is not a result of an effective data management process?

A. Reduced costs of executing business process

B. Increased competency in service environment

C. Stimulation of innovation in business processes

D. Reduced risks in the business

308



10. Which of the following is not a step in the service development lifecycle?

A. Feasibility

B. Analysis

C. Implementation

D. Improvement

309

12 Organizing for Service Design

Organizations are designed and built for a purpose. The individual interactions present within an organization and between organizations can be seen as transactions, which are executed using resources and capabilities of those organizations. A basic measurement of transactions is cost: the number of resources required to successfully complete the interaction. Organizations must identify, negotiate, monitor, coordinate, and govern the resources needed in these transactions, the body of which are required to produce services. A successful organization learns to manage transaction costs effectively.

12.1 Organizational Development

Organizational change does not occur on its own: it must be planned, designed, and implemented. Organizational change does not occur instantaneously: it can take months and years to achieve its goals. There is no single, or best, way to organize.

Organizations tend to move between two paradigms: centralization and decentralization. Centralization focuses on bringing components under a single, or central, authority and is often initiated when problems within the organization are persistent and complex. Decentralization allows decisions to be made locally to the operations and provides greater autonomy to lower level managers; however, their decisions can be narrow, short-sighted, and incongruent to the larger organization’s objectives.

Chapter 12

310



Organization structures are influenced by:

• Commitment of senior management.

• Industry, regulatory, and legislative factors.

• Corporate and IT strategies.

• Organization age, size, and scope.

12.1.1 Stages of Organizational Development

Management styles will generally describe how an organization operates and can be used to identify and plan the growth and maturity of the organization. There are five dominate management styles:

• Network.

• Directive.

• Delegative.

• Coordination.

• Collaborative.

The organization can be served by each of these management styles for a while, but growth will usually require the organization to change management styles to succeed. To move from one management style to the next, an organization will typically need to overcome a specific challenge related to the dominate management style.

The Network management style represents an informal, rapidly paced, and ad hoc delivery of services. Organizations with this dominant style are entrepreneurial and innovative, will focus heavily on its technology and are avoid establishing formal structures. Past successes will reinforce the need to continue in this style, but growth in service demand makes the model not sustainable over time.


311

The network management style relies heavily on localized knowledge and dedication from staff members. Actions between individuals and groups are coordinated by agreements, rather than authority; relying on people to complement each other without formal structures. To grow as an organization, leadership must be identified and empowered. This focus on leadership will fly in the face of the autonomy present in the network style because it begins to create a formalized structure from which decisions and policies are made.

The advantages of a network structure are:

• Bureaucratic costs due to complex structures are avoided.

• Fewer managers are required, making the organization “flat.”

• The structure of the organization is highly adaptable and can be altered quickly to meet

different challenges.

The disadvantages of a network structure are:

• Management must ensure the integration of individual activities from staff members.

• Significant problems exist when coordinating activities.

• Sourcing functional activities to external providers is extremely challenging as sourcing

decisions are made locally.

Overcoming the leadership challenge of a network structure will move the organization into a directive structure, where upper management becomes focused on “directing” strategy and lower management will assume responsibilities at the operational, or functional, level. The focus of a directive structure is to establish a hierarchy where functional activities are separated and managed. In an IT organization, this may separate technical teams, support for particular applications, systems or processes, and even shared functions like the service desk.

In this style, communication becomes more formal and processes are implemented. Interactions may be defined entirely by the process or through operational level agreements (OLA) which supplement existing SLAs. Managers in functional areas will often be forced to choose between taking the initiative or to follow the process; leading to shift towards centralization as the organization because a major driver in decision making.

312



Autonomy becomes the challenge to organizational growth at this stage: approval is required at high-levels of the organization while successful performance at lower-levels goes unnoticed and unrewarded. To move forward, the organization must be willing and able to shift responsibility downward into the organization though delegation. This downward shift requires management to empower and recognize the efforts of managed personnel.

The structure for delegation shifts authority for minor decisions to lower level managers, whose increased control is matched by a corresponding reward system. Delegation combines the best elements of both network and directive structures: allow the organization to encourage innovation while leveraging efficiencies in the environment. The delegation structure is a decentralized structure which shifts responsibilities appropriately from a functional paradigm to a process paradigm.

When problems arise with the delegation structure, the typical response is to return to a centralized solution at the functional level: which does not enable growth for the organization. The proper response, however, is greater control of the process(es) to improve coordination of individual efforts.

Greater control in the organization results in the implementation of formal systems: a hallmark of the coordination structure. Senior managers will see formal systems as critical to business success and take responsibility for their implementation and use. Coordination techniques and solutions support planned structures for service management which are continuously reviewed and improved. In the coordination structure, functions are centralized and processes are decentralized.

The challenge for the organization at this stage is its agility: the organization’s ability to response rapidly to changes in the internal and external environments, usually because of pressure to adhere to procedural requirements. In theory, the capability towards rapid response is the product of collaboration, as information flows through a diverse group of people rather than a single individual.


313

The most developed organizational structure will encourage greater collaboration between functional units within an organization, with external organization, and between processes. Matrix-based organization structures are representative of the collaborative stage, which identified roles and responsibilities based on function and product or customer.

The advantages of a matrix structure are:

• Barriers between functions are overcome and reduced.

• Personnel can respond better to change, internal and external.

• Communication is improved between functional personnel, or specialists.

• Cross-training between functions is possible.

• Skills and experience from supporting different products and customers can be leveraged

for problematic or new ventures.

The disadvantages to a matrix structure are:

• A control structure is lacking which can develop stable expectations across functional and

customer responsibilities.

• Conflict with roles can developed as greater ambiguity may be perceived, especially in

similar roles supporting different customers.

• Conflict can developed over time between functional and customer teams.

To approach organizational growth and structuring, upper management must understand:

• What stage of development the organization already resides.

• What range of options is available and appropriate to the organization.

• That each solution will create new challenges to overcome.

314



12.2 Departmentalization of Organization

Departmentalization is a method of dividing an organization into manageable components relative to the organizational activities performed by a certain number of people in the organization. Departmentalization is typically a result of growth: as the organization grows in size and scope, groups within the organization are seen as departments. Departmentalization can be facilitated by focusing on the following distinctions:

• Function – specialized resources are pooled together and reduce duplication of effort.

• Product – helpful in environments with diverse strategies, products and services.

• Market space or customer – promotes differentiation for increased knowledge of and

response to specific customer preferences.

• Geography – minimizes travel and distribution costs while leveraging localized knowledge

and expertise.

• Process – supports end-to-end management of a process.

These structures for departmentalization lend to the following strategic considerations:

• Functional:

Ř Specialization.

Ř Common standards.

Ř Small department sizes.

• Product:

Ř Focus on output (product).

Ř Strong product knowledge.

• Market space/Customer:

Ř Unique services to segments.

Ř Customer service.

Ř Buyer strength.

Ř Rapid customer service.

• Geography:

Ř On-site services


315

Ř Closer proximity to customer for delivery and support.

Ř Local perceptions of organization.

• Process:

Ř Process cycle times must be minimized.

Ř Process excellence.

12.2.1 Functions

The term “function” is used in ITIL to describe a team of group of people and other resources used to execute one or more processes or activities. A function may be further broken down into smaller departments, teams, or groups, or may represent a single organization unit. In small organizations, a function can consist of a single person. Service Design must clearly define the roles and responsibilities required to execute a process or activity. While Service Design does not define any specific functions for the organization, it does rely heavily on the skills and knowledge of the technical and application management functions.

Despite the lack of clarity for functions in service design, some organization may elect to define functions within the design phase. One common function is application development, which focuses on the developing the utility required by the business. Most application development work is project-based where specific functionality must be delivered on time and within budget. However, most work is structured using common software development lifecycles.

Another probable function found in service design focuses on project management. This may be a team of certified project manager who are assigned to individual projects to manage skilled subject matter experts to collaborate and produce a comprehensive solution. The project manager may not have any specific IT knowledge to bring to the subject matter of the project, but are in place to manage the project itself. In most cases, this lack of knowledge in the subject matter is advantageous because it requires the project manager to involve team members to greater extent.

316



12.2.2 Service Design Structures

Even in the smallest organizations, the service design manager should be identified. This person will likely be the process owner and/or manager for the design coordination process. However, where this person (and process) is located in the organization structure can vary. The recommendation is to find a person within the organization function with the most contributions to new or changed service, usually falling within the groups responsible for application development or the infrastructure.

For each design project, a representative from each impacted IT function may be assigned. At minimum, this means a person from:





• Business Relationship Management.

• Supplier Management.

• Service Catalog Management.

Ideally, the appropriate representative will be the process manager; however in smaller organizations, the roles of process owner and process manager may be combined—there may even be cases where the process manager roles for multiple processes are combined. As the project grows, additional people may be added to the project, especially when different technology is introduced: for instance, it would be reasonable to have experts (from operations) in distributed systems and mainframe systems be involved and advising the appropriate process managers. These “practitioners” will likely be performing the “heavy lifting” required in transitioning the designed solution. Developers and practitioners that may be assigned to the project are independent from any specific application or technical management team.

In larger organizations, the complexity of a project will increase because there may be global and regional representation on the project. Even if the project is initiated at a regional level, global representation would be appropriate to ensure compliance to global standards and


317

strategies. If the project is initiated at a global level, regional representation is appropriate to capture meaningful feedback about the opportunities and risks associated with the different regions.

In these larger situations, the service design manager may be responsibility for a team of designers, architects and design planners. These people would be assigned to an individual project which is run by an overall project manager assigned from the project management office. The stakeholders in the project would be the global process owners for the ITSM processes, who would assign the appropriate regional process managers and possibly practitioners of the processes. It is possible to have several concurrent regional projects happening, each with their own project manager and practitioners, with responsibilities and representation in the global project.

An important role in any service design project, whether in a small or large organization, is the service owner. This person is accountable for the success of the service and in this capacity they can be seen as the “customer” of the project or its sponsor. The level of participation from the service owner may vary on management style and organizational size; however it is recommended that service owners do not interfere with the formality and control provided through project management.

12.3 Organizational Design

Strategy sets the direction and criteria for designing an organization. The plan for departmentalization in an organization must precede any design effort for key processes. Understanding the key processes for the business must precede any design effort for the organization. In essence, the design of a service is highly dependent on how the organization is formed and operates.

318



Strategic factors for organization design may include:

• Partnerships.

• Control and harmonization.

• Process and decentralization.

• Structure and centralization.

• Speed and creativity.

Strategic focus and the level of process focus lend themselves to determine the appropriate organizational structure (network, directive, delegation, coordination or collaboration).

12.4 Roles and Responsibilities

A role is a set of responsibilities, activities and authorities assigned to a person or team. Roles and job titles (position) are not synonymous terms. Roles are defined by process; job titles are defined by organization. A person fulfilling the responsibilities associated with a job title may be fulfilling several roles.

There are two categories of roles:

• Generic – roles which are found in every process, such as process owner and process

manager.

• Specific – roles which are developed for specific processes.

Roles can be accountable or responsible for a specific activity: meaning several roles may participate in the successful completion of an activity. RACI models are useful tools for separating responsibilities for an activity between different roles.


319

12.4.1 Service Owner

The service owner is a generic role with responsibility for managing a service within a business context. The service owner is accountable for the delivery of a single, and specific, service across the entire lifecycle of the service. Accountability over the service is independent of where technological components, processes or professional capabilities reside in the organization.

A person fulfilling the service owner role may do so for several services. The specific responsibilities of a service owner are (responsibilities are associated with relevant service strategy processes):

• Ensures service delivery and support consistently meet agreed customer requirements.

• Participating in internal service review meetings (with IT).

• Assist in defining service models and service assessments.

• Identify opportunities for service improvements.

• Raise RFCs for service improvements.

• Provide input on service attributes (performance, availability, capacity, etc.).

• Understand the service.

• Solicit required data, statistics and reports for analysis.

• Facilitate effective service monitoring and performance.

• Understand and translate customer requirements into service-related activities, measures,

and components used in meeting those requirements.

• Ensure consistent communication with customer(s) for service-related questions and issues.

• Discuss potential service improvements with customer.

• Serve as a point of escalation for major incidents in service delivery.

• Participate in external service review meetings (with customer).

• Ensure service entry in service catalog in accurate and maintained.

• Liaison with appropriate process owners throughout the service lifecycle.

• Represent the service across the organization.

• Represent the service in change advisory board meetings.

• Participate in negotiating SLAs and OLAs.

• Raise service improvement opportunities in CSI register.

• Review and prioritize improvements in CSI register.

320



• Make improvements to service.

The service owner is a primary stakeholder in all service management processes that underlie and support the delivery of the service they own, including:

• Incident Management.

• Problem Management.

• Release and Deployment Management.

• Change Management.

• Service Asset and Configuration Management.





• Information Security Management.

• Financial Management for IT Services.

12.4.2 Process Owner

The specific roles associated with other service design processes are usually restricted to process owner and process manager. A process owner is accountable for ensuring a process is fit for purpose, or the process performs according to agreed and documented standards and meets the aims of the process definition. A process manager is accountable for the operational management of a process. The same person may be assigned to fulfill the process owner and process manager roles


321

The specific responsibilities for process owner are (additional responsibilities for individual service design processes are also provided):

• Generic:

Ř Sponsor, design and manage change to the process and its metrics.

Ř Define process strategy.

Ř Assist in process design.

Ř Ensure the availability and currency of process documentation.

Ř Define policies and standards relative to the process.

Ř Audit the process regularly to ensure compliance.

Ř Communicate process information or changes.

Ř Provide process resources to service lifecycle activities.

Ř Ensure technicians working the process have the required knowledge and understanding

of business sand technical information needed to deliver the process.

Ř Identify, review and prioritize opportunities for process improvements (with CSI

manager).

Ř Address process issues.

Ř Implement process improvements.

Ř Carry out the above responsibilities for their assigned service management process.

• Design Coordination:

Ř Setting the scope and policies for service design.

Ř Overseeing the overall design of all service design processes.

• Service Catalog Management:

Ř Work with other process owners to ensure integrated approach to design and

implementation of service catalog management, service portfolio management, service

level management, and business relationship management.

• Service Level Management:

Ř Work with business relationship management process owner to coordinate and

communicate between the two processes.


implementation of service catalog management, service portfolio management, service

level management, and business relationship management.

322



• Availability Management:

Ř Work with managers of all IT functions to ensure acceptance of availability management

process as the single point of coordination for all availability-related issues.


implementation of availability management, service level management, capacity

management, IT service continuity management and information security management.

• Capacity Management:

Ř Work with managers of all IT functions to ensure acceptance of capacity management

process as the single point of coordination for all capacity and performance-related

issues.


implementation of availability management, capacity management, IT service continuity

management and information security management.

• IT Service Continuity Management:

Ř Work with business to ensure coordination and communication between business

continuity management and IT service continuity management.

Ř Work with managers of all IT functions to ensure acceptance of IT service continuity

management process as the single point of coordination for all continuity-related issues.


implementation of availability management, capacity management, IT service continuity

management, business continuity management and information security management.

• Information Security Management:

Ř Work with the business to ensure coordination and communication between business

security and information security management.

Ř Work with managers of all IT functions to ensure acceptance of information security

management process as the single point of coordination for all security-related issues.


implementation of availability management, organizational security management, IT

service continuity management and information security management.

• Supplier Management:

Ř Work with business to ensure coordination and communication between supplier


323

management and corporate vendor management and/or procurement.


implementation of supplier management, service level management and corporate

vendor management and/or procurement.

12.4.3 Process Manager

The specific responsibilities for process manager are (additional responsibilities for individual service design processes are also provided):

• Generic:

Ř Work with process owner to plan and coordinate all process activities.

Ř Ensure all relevant service lifecycle activities are executed.

Ř Appoint people to required roles.

Ř Manage resources assigned to process.

Ř Work with service owners and other process managers to ensure smooth running of

services.

Ř Monitor and report on process performance.

Ř Identify, review and prioritize opportunities for process improvements (with CSI

manager).

Ř Implement process improvements.

Ř Carry out the above responsibilities for their assigned service management process.

• Design Coordination:

Ř Coordinating interfaces between design coordination and other processes.

Ř Ensuring service design practices reflect overall service strategies.

Ř Ensuring the designs of services, service management information systems,

architectures, technology, processes, information and metrics are consistent and meet

current and future business outcomes and requirements.

Ř Coordinating all design activities across projects, changes, suppliers and support teams.

Ř Managing schedules, resources and conflicts related to service design.

Ř Planning and coordinating the resources and capabilities required to design new or

324



changed service.

Ř Ensuring service design packages (SDPs) are produced according to service charters and

change requests.

Ř Ensuring appropriate service design and/or SDPs are produced and handed over to

service transitions.

Ř Managing the criteria for quality, requirements and handover points between service

strategy and service design, as well as service design and service transition.

Ř Ensuring service models and service solution designs are in conformance with strategic

architectural, governance and other corporate requirements.

Ř Improving the effectiveness and efficiency of service design activities and processes.

Ř Ensure a common framework of standards, reusable design practices are adopted by all

participants in service design: practices will include activities, processes and supporting

systems, whenever possible.

• Service Catalog Management:

Ř Coordinating interfaces between service catalog management and other processes.

Ř Ensure all operational services or services being prepared for the operational

environment are documented within the service catalog.

Ř Ensure all information contained within the service catalog is accurate and current

Ř Ensure appropriate views to the service catalog are maintained and available to the

appropriate audiences.

Ř Ensure all information contained within the service catalog is consistent with the

information found in the service portfolio.

Ř Ensure all information contained in the service catalog is protected adequately and

backed up on a regular basis.

• Service Level Management:

Ř Coordinate interfaces between service level management and other processes.

Ř Maintain a current awareness of the changing needs of the business.

Ř Ensuring current and future service level requirements are identified, understood and

documented within SLAs and related service level requirement (SLR) documents.

Ř Negotiate and agree with levels of service to be delivered to customer, as formally

documented within SLAs.


325

Ř Assisting in the production and maintenance of the service portfolio, service catalog and

application portfolio.

Ř Ensure the targets between underpinning contracts and SLAs/SLRs are aligned.

Ř Ensure service reports are generated for each service with SLA breaches highlighted,

investigated and actions to prevent recurrence documented and managed

Ř Ensure improvement initiatives identified in service reviews are initiated and progress

reported to the customer.

Ř Review service scope, SLAs, OLAs, and other agreements at least annually.

Ř Ensure all changes are assessed to determine impact on service levels and agreements.

Ř Identify all customers and other key stakeholders.

Ř Develop relationships with customers, key users, and other stakeholders.

Ř Define what a complaint is and the procedure for recording, managing, escalating and

resolving all complaints.

Ř Measure, record, analyze, and improve customer satisfaction in cooperation with

business relationship management.

• Availability Management:

Ř Coordinate interfaces between availability management and other processes.

Ř Ensure all existing services deliver the levels of availability as documented in SLAs.

Ř Ensure all new services are designed to deliver the levels of availability required by SLAs

and validate the final design meets minimum availability targets for the service.

Ř Assist in the investigation and diagnosis of all incidents and problems resulting from an

availability issue of unavailability of service or components.

Ř Participate in infrastructure design particularly in defining the availability requirements

for hardware and software.

Ř Define the requirements regarded automatic monitoring or availability in enhanced

event management systems.

Ř Define the requirements related to reliability, maintainability, and serviceability of

components supplier by internal or external service providers and/or suppliers.

Ř Maintain responsibility for appropriate monitoring or actual IT availability achieved

against SLA targets.

Ř Provide a range of availability reporting to ensure the measurement and monitoring of

326



agreed levels of availability, reliability and maintainability.

Ř Improve or optimize service availability proactively wherever possible.

Ř Create, maintain and review an availability management information systems and

availability plan(s).

Ř Ensure the regular review and audit of the availability management process and

associated procedures.

Ř Create design criteria for availability and recovery for use with new or enhanced

infrastructure design.

Ř Ensure the levels of IT availability required are cost-justified, in cooperation with financial

management for IT services.

Ř Assist in the assessment and management of risk with information security and IT service

continuity management.

Ř Assess changes for impact on all aspects of availability.

Ř Attend CAB meetings when appropriate.

• Capacity Management:

Ř Coordinate interfaces between capacity management and other processes.

Ř Ensure all existing services have adequate IT capacity to deliver required levels of service

as documented in SLAs.

Ř Ensure management is advised on how to match capacity and demand and optimize

current use of capacity.

Ř Ensure capacity requirements are identified through discussions with business users and

in cooperation with service level management.

Ř Size all proposed services and systems to determine capacity requirements.

Ř Understand the usage of the infrastructure and IT services, as well as the maximum

capacity of each component.

Ř Ensure appropriate levels of monitoring on resources and system performance are in

place.

Ř Analyze data regarding capacity usage and performance and report against SLA targets.

Ř Raise incidents and problems when breaches to capacity and performance thresholds

are detected.

Ř Assist in the investigation and diagnosis of all incidents and problems resulting from a


327

capacity issue.

Ř Identify and initiate any tuning required to optimize and improve capacity and

performance.

Ř Identify and implement initiative to improve resource usage.

Ř Assess new technology in respect to capacity and performance.

Ř Understand future demand on IT services and assess the demand on performance

service levels.

Ř Ensure all changes are assessed for impact on capacity and performance.


Ř Generate management reports regarding current resource usage, trends and forecasts.

Ř Size all proposed new services and systems to determine resource requirements,

hardware utilization, performance service levels and cost implications.

Ř Assess new techniques, hardware and software products used by capacity management

to improve the effectiveness and efficiency of the process.

Ř Test performance of new services and systems.

Ř Generate repots on service and component performance against SLA targets.

Ř Maintain knowledge of future demand for IT services and predict effects on performance

service levels.

Ř Determine performance service levels that can be maintained and cost-justified.

Ř Make recommendations regarding tuning of services and system, as well as the design

and use of systems.

Ř Act as focal point for all capacity and performance issues

• IT Service Continuity Management:

Ř Coordinate interfaces between IT service continuity management and other processes.

Ř Perform business impact analysis for all new and existing services.

Ř Implement and maintain the IT service continuity management process, in accordance

with the overall requirements of the business continuity management process.

Ř Ensure all IT service continuity management plans, risks and activities underpin and align

with business continuity management.

Ř Assess and manage risk to prevent catastrophic events wherever possible and cost-

justifiable.

328



Ř Develop and maintain the organization’s continuity strategy.

Ř Assess potential issues to service continuity and invoke appropriate service continuity

plan(s) if required.

Ř Manage the service continuity plan when in operation, including failover and restoration

procedures.

Ř Perform post-mortem reviews of service continuity tests and invocations.

Ř Develop and maintain IT service continuity management plans to achieve recovery

objectives.

Ř Ensure all IT service areas are prepared and ready to response to an invocation of the

continuity plans.

Ř Maintain a comprehensive IT testing schedule for service continuity.

Ř Perform quality reviews for all procedures and ensure procedures are tested.

Ř Communicate and maintain awareness of IT service continuity management objectives.

Ř Perform, at least annually, reviews of continuity plans with business areas.

Ř Negotiate and manage contracts with providers of third-party recovery services.

Ř Assess changes for impact on all aspects of service continuity.


• Information Security Management:

Ř Coordinate interfaces between information security management and other processes.

Ř Develop and maintain an information security policy and supporting policies.

Ř Communicate and market the information security policies to all appropriate parties.

Ř Ensure the enforcement and adherence of the information security policy.

Ř Identify and classify IT and information assets, including their respective levels of control

and protection required.

Ř Assist in business impact analysis.

Ř Assess and manage security risks in conjunction with IT service continuity and availability

management.

Ř Design security controls.

Ř Develop security plans.

Ř Develop and document procedures for operating and maintaining security controls.

Ř Monitor and manage all security breaches.


329

Ř Report, analyze, and reduce the impact and volume of all security incidents in

conjunction with problem management.

Ř Promote education and awareness of security.

Ř Maintain a set of security controls and documentation.

Ř Regular review and audit security controls and procedures.

Ř Ensure all changes are assessed for impact on security.

Ř Ensure security tests are performed.

Ř Participate in any security reviews related to security breaches.

Ř Ensure that the confidentiality, integrity, and availability of services are maintained in

accordance with agreed SLA targets.

Ř Ensure access to services by external partners and supports are in accordance with

contractual agreements and responsibilities.

Ř Act as focal point for all security issues.

• Supplier Management:

Ř Coordinate interfaces between supplier management and other processes.

Ř Assist in the development and review of SLAs and agreements as related to the

involvement of third-party suppliers.

Ř Ensure value for money is obtained from all IT supplies and contracts.

Ř Ensure all IT supplier processes are consistent and interface with all corporate supplier

strategies, processes and standard terms and conditions.

Ř Maintain and review a supplier and contract management information system.

Ř Review and make risk assessments of all suppliers and contracts.

Ř Ensure underpinning contracts, agreement, and SLAs are aligned with those of the

business.

Ř Ensue all supporting services are scoped and documents and interfaces and

dependencies between suppose supporting services and supplier processes are agreed

and documented.

Ř Ensure all roles and relationships are documented, maintained and subject to contractual

agreement, specifically those between lead supplier and sub-contracted supplier.

Ř Review lead suppliers’ process to ensure the meeting of sub-contracted suppliers’

obligations.

330



Ř Conduct reviews on contract and SLA at least annually.

Ř Update contracts or SLA when required.

Ř Maintain a process for dealing with contract disputes.

Ř Maintain a process for dealing with expected or early termination of contract and

transfer of service.

Ř Monitor, report, and review supplier performance against agreed targets.

Ř Ensure changes are assessed for their impact on supports, supporting services and

contract.


Ř Coordinate and support all individual IT support and contract managers.

12.4.4 Other Roles in Service Design

The primary responsibility of the IT planner is the production and coordination of IT plans. The processes of availability, capacity and IT service continuity have an expectation to create appropriate plans within the process areas; however, in most cases, this requires having ample knowledge in multiple areas of IT. In truth, an IT plan may focus on a specific technology, like mainframe, or the entire IT infrastructure and define how that technology will be implemented within the environment. These IT plans must consider the plans of the various process areas, as well as the strategies and plans of the business.

The specific responsibilities of the IT planner include:

• Developing plans to meet IT requirements of the business.

• Coordinating, measuring and reviewing the implementation progress of all IT strategies and

plans.

• Producing and maintaining a set of IT standards, policies, plans and strategies.

• Assuming responsibilities for all aspects of IT standards policy and strategy improvement for

IT.

• Recommend policies for effective use of IT throughout the organization.

• Review IT costs against budgets and new developments.


331

• Assuming responsibility for the management, planning, coordination of IT services and

services.

• Obtaining and evaluating proposals from supports of equipment, software, and services.

• Identify internal and external influencing factors.

• Forecasting future needs and setting plans for effective use of IT.

• Sponsoring and monitoring research, development and long-term planning for the

provision and use for IT architectures, products and services.

• Reviewing IT performance and initiating improvements.

• Assuming responsibility for prioritizing and scheduling the implementation for new or

changed services within IT.

• Working with senior management and other designees to develop plans and make

procurement decisions.

• Recognize key business drivers.

• Identify suitable applications, services and products.

• Development initial plans for improvement of new IT services, applications and

infrastructure support.

• Monitor existing IT plans with respect to changing business needs and IT strategy.

• Investigate options for providing IT services effectively and efficiently.

• Produce feasibility studies, business models, IT models, business cases, statements of

requirements and invitations to tender for recommended new IT systems.

• Oversee and coordinate planned IT project implementation and changes.

• Conduct post-implementation reviews in conjunction with change management.

• Work with strategy, transition and operational teas and processes to plan current and future

needs.

• Provide advice and guidance on relevant industry standards, regulations, protocols and

tariffs, both national and international.

• Document all work using required standards, methods and tools.

• Ensure all IT planning processes, roles, responsibilities and documentation are reviewed

regularly and audited for effectiveness, efficiency and compliance.

• Maintain a good knowledge of al IT product capabilities and technical frameworks.

• Assess changes for conformance to design strategies.

332



• Attend CAB meetings when appropriate.

The IT designer/architect is responsible of the overall design and coordination of the technology in the environment. In most cases, designers and architects specialize in one aspect of design and must work together to create a holistic and comprehensive design solution. The specific responsibilities of an IT designer/architect are:

• Produce and review the designs of all new or changed services, LSAs, OLAs and contracts.

• Produce a process map demonstrating all processes and process interfaces.

• Design security and resilient technology architectures.

• Review and audit regularly the design of all processes, roles, responsibilities and

documentation to ensure effectiveness, efficiency and compliance.

• Design an appropriate service portfolio.

• Design measurement methods and metrics which drive continual improvement of all

services and supporting processes.

• Produce and maintain current IT design, architectural, policy and specification

documentation.

• Produce and maintain all aspects of IT specification, including designs, architectures,

topologies and configurations.

• Recommend proactive, innovative IT solutions.

• Translate logical designs into physical designs.

• Create and maintain IT design policies, philosophies and criteria.

• Work with capacity management to identify trends in traffic flows and levels of service.

• Propose design enhancements to IT infrastructure capacity, continuity, and backup and

recovery.

• Review IT costs against service providers, new developments and new services.

• Propose changes to IT design to reduce service costs.

• Advise and guide on the management of design and planning phases for IF systems.

• Advise and guide all IT and business areas and appropriate personnel on all aspects of IT

design and technology.

• Interface with designers and planners from third-party supports and service providers to

ensure external IT services are designed to meet service levels and targets.


333

• Assist, or drive, the selection of any new IT infrastructure or technology solutions.

• Assume technical responsibilities for IT standards, policies and design for all significant

projects.

• Advise and guide on technical impact of relevant standards, regulations, protocols, and

tariffs.

• Be responsible for design aspects of all stages of the lifecycle of IT systems.

• Work with IT colleagues to produce or update IT and corporate design documentation and

models.

• Update or provide input to cost benefit analysis, risk assessment, business cases, SoRs, ITTs,

and development plans with regard to design decisions.

• Obtain and assist in the evaluation and selection of proposals and solutions from suppliers.

• Construct, interpret and monitor test plans.

• Document all work using required standards, methods, and tools.

• Maintain a good technical knowledge of all IT product capabilities and frameworks.

• Assess changes for their conformance to design principles.

• Attend CAB meetings when appropriate.

334

13 Technology Considerations

13.1 Service Design Tools

Service design can benefit from the use of several tools and techniques which can enable:

• Hardware design.

• Software design.

• Environmental design.

• Process design.

• Data design.

The actual tools and techniques may vary in scope, format, and function; they may be proprietary solutions or may use open standards. However they may be presented, they can benefit service design by:

• Reducing the time and effort required in the design process.

• Ensuring standards and conventions are followed.

• Offering facilities to prototype, model, and simulate.

• Examining “what if?” scenarios.

• Enabling interfaces and dependencies to be checked and correlated.

• Validating designs before development and implementation to ensure compliance to

requirements.

The use of graphical views of the service and its constituent components can make design efforts easily and drive confidence in the end result. Such tools will allow the designer to “show” the service and its components and their relationships to the business processes, service level

Chapter 13

335

requirements and targets, technology processes, teams and agreements. These tools can also capture the “real world” configuration of the design during service operation and support all aspects of the service lifecycle, including:

• Managing all stages of the lifecycle.

• Managing all aspects of the service and its performance.

• Managing service achievements, measurement, reporting, and management.

• Consolidate metrics and metric trees.

• Provides appropriate views across all processes, systems, technologies, and groups that are

consistent and consolidated.

• Demonstrate the relationships and integration of business processes with IT services,

systems, and processes.

• Enable search and reporting facilities to support informed decision-making.

• Manage service costs.

• Manage relationships, interfaces, and dependencies.

• Manage the service portfolio and service catalog.

• Support and integrate with the configuration management system.

• Support and integrate with the service knowledge management system.

To facilitate such a comprehensive approach though service design tools and techniques, the following must be in place within the environment:

• A generic lifecycle for IT assets must be established and the principle processes, policies,

activities and technologies within each lifecycle stage clearly defined for each asset.

• The relationships between different types of IT assets must be formalized, as well as the

relationship between acquisition, management and other IT disciplines.

• All roles and responsibilities involved in the activities of the different types of IT assets must

be clearly defined.

• Measures for understanding the total cost of ownership of an IT service must be in place.

• Policies for the reuse of IT assets across services must be in place.

• A strategy for acquisition and management of IT assets against the alignment with business

and IT strategies must be defined.

336



Different asset types may require additional conditions for success, such as:

• Application assets:

Ř Every role played by the application is documented.

Ř The generic IT asset lifecycle model is adapted and tailored to the appropriate

application types.

Ř Different approaches to application development are standardized.

Ř The role of development methodologies is recognized in the organization.

Ř Procedures are in place to consider tall requirement type sin the early stages of

application development.

Ř Decisions for determining the optimal delivery of applications is standardized.

• Data/Information assets:

Ř The general principles of IT asset acquisition and management are established and used

to manage data/information resources.

• IT Infrastructure and environment asset:

Ř Acquisition and management of IT infrastructure and environment equipment is

standardized.

Ř The generic IT assets lifecycle model is adapted to a specific IT infrastructure lifecycle.

Ř Activities to optimize the infrastructure asset use and reuse, and established.

Ř The need for tools is specified and defines how they can be used to assist in the

management of IT infrastructure.

Ř Green IT/Sustainability requirements are specified.

• People and competency assets:

Ř Define how competency of individuals supporting IT assets and services can be viewed

as an asset within the organization.

Ř Apply the IT asset lifecycle to people assets, specifically in terms of measureable

competencies.

Ř Document the competencies currently in place and how they should be reused or

enhanced.

Ř Ensure standard competency frameworks are used within organization standard.


337

13.2 Service Management Tools

Service Management tools have a variety of benefits, both short- and long-term, including:

• Increasing efficiency and effectiveness.

• Providing access to information.

• Identifying weaknesses and opportunities for improvement.

• Cost savings.

• Increase productivity.

• Increased quality.

When evaluating service management tools for possible inclusion into the environment, the service provider should consider:

• Data structure, data handling and integration.

• Integration of multi-vendor infrastructure components (integration with other tools).

• Conformance to international open standards.

• Flexibility with regards to implementation, usage, and data sharing.

• Ease of use permitted by user interface (usability).

• Support for monitoring service levels.

• Client/server relationships for multiple users.

• Requirements for converting previously tracked data.

• Data backup, control and security.

• Support options from tool vendor.

• Scalability.

Tools should support the process. As such, requirements can be mandatory for the tool and requirements can be desirable: they should be distinguished to ensure the right tool is sought. If possible, a service management tool should be able to underpin multiple service management processes without sacrificing effectiveness and efficiency. If a fully integrated tool is not possible, a factor for driving tool selection will likely be the ability to integrate multiple tools.

338



13.2.1 Tool Selection

The selection process should be driven by a statement of requirements (SoR) with requirements undergoing MoSCoW analysis. MoSCoW analysis simply placed requirements into one of the following categories:

• Must have.

• Should have.

• Could have.

• Won’t have.

The platform (hardware and software) which the tool is expected to operate on is a major consideration for tool selection. Some tools may run better on specific platforms or the IT strategy may restrict what platforms will be supported. Another consideration is the credibility of the tool and vendor. Base selection on historical data available and/or how easy it is to reach the vendor and discuss the tool. See how the tool is being used currently in production at another organization with similar requirements. Consider the training programs available by the vendor as it relates to effective use of the tool.

It is unlikely that any tool will meet 100% of the organization’s requirements, so it is justifiable to adapt the 80/20 rule where 80% or more of the requirements are met. Ideally, the mandatory (must have) requirements have the greatest priority in the list and a tool should be rejected if none of the mandatory requirements are met.

The selection process should also consider implementation: what it will take to ensure successful integration into the operational environment? It is possible that the environment will need to be built up to support the tool, i.e. staff training, hardware and software platform installation, data migration, etc.


339

13.2.2 Tool Evaluation

The tool evaluation process can be summarized in the following steps:

1. Identify requirements.

2. Identify products.

3. Selection criteria.

4. Evaluate products.

5. Short listing.

6. Scoring.

7. Rank the products.

8. Select product.

Products can fulfill requirements in a number of ways:

• Out-of-the-box – requirement is fulfilled without any manual intervention or configuration.

• Configuration – the requirement can be fulfilled though configuration which will take x days

to complete and will be preserved when product upgrades occur.

• Customization – the requirement can be fulfilled through reprogramming which will take x

days to complete and the reprogramming must take place after every product upgrade.

340




1. What does RACI stand for?

A. Responsible, accountable, consulted, informed

B. Reliability, availability, compliance, informed

C. Responsible, authorized, consulted, involved

D. Responsible, accountable, controlled, informed

2. Which of the following rules is not applied to the development of a RACI chart?

A. Only one role can be accountable for each activity

B. At least one role must be responsible of an activity

C. Each activity must have at least one role accountable

D. Communication problems are indicated by having the business responsible for too

many activities

3. Application development teams are focused on what aspect of a service?

A. Management

B. Functionality

C. Warranty

D. Performance

4. What functional unit is actively engaged within service design for the purpose of managing

the costs, schedule and risks associated with individual services?

A. Application development

B. Service Desk

C. Project management

D. Technical teams


341

5. What generic role is responsible for the operational state of a process?

A. Process owner

B. Process practitioner

C. Service owner

D. Process manager

6. What type of analysis is used when producing a statement of requirements?

A. BIA

B. MoSCoW

C. CFIA

D. Risk assessment

7. What step of the tool evaluation process immediately follows the creation of the criteria

used to select tools?

A. Evaluate products

B. Identify products

C. Rank products

D. Select product

8. When choosing tools for service management, which type of tool must be touched every

time a new update is applied?

A. Out of the box

B. Configuration

C. Customization

D. New

342



9. Tools and techniques may vary but which of the following does not benefit service design?

A. Enable interfaces and dependencies to be checked and correlated

B. Examine “what if” scenarios

C. Manage service costs

D. Ensure that standards and conventions are followed

10. Which of the following is a factor that should be in place within the environment, in order to

facilitate a comprehensive approach through service design tools and techniques?

A. All roles and responsibilities involved in the activities of the different types of IT

assets must be clearly defined

B. Manage all stages of the lifecycle

C. Consolidate metrics and metric trees

D. Manage the service portfolio and service catalog

343

14 Implementing Service Design

Service strategy defines the services to be included in the portfolio and the customer who will be serviced for each market space. The agreements regarding customers and services must be supported by the resources and capabilities used across the service lifecycle.

Service Design focuses on identifying and organizing those resources and capabilities to support and deliver the services existing in the service portfolio. The processes of service design addresses the issues related to:

• Where do we start?

• How do we improve?

• How do we know if we are successful?

In its holistic approach, service design focuses on providing services based on:

• The needs of the business – as defined by service level requirements and formalized and

agreed in service level agreements.

• The impact on the business – as defined by business impact analysis which considers the

impact of losing a business process or business function and the effects of service loss

(disruption) on the business.

• The risks to services and processes – representing the known threats and vulnerabilities to

the customer, the service provider, and the services and processes of both customer and

service provider.

Chapter 14

344



14.1 Implementing Service Design

When first engaging an ITIL implementation, the very first question will likely be, “which process do I implement first?” This is a difficult question to answer because all the service management processes are interrelated and together they have greater value than any single process within the suite. Practically though, an organization should start where the greatest need is present. To make effective decisions in this area, it is best to have completed a process assessment identifying the organizations strengths and weaknesses regarding service provision. Using the assessment, strategies can be formed which will impact and communicate short-, medium, and long-term goals and plans.

Short term activities to implement processes should be aligned with long-term goals. “Quick wins” are excellent opportunities to mobilize employees, enforce decisions, and build confidence across the organization; however, if they have to be amended or discarded in the future, they should not be considered “wins.”

Priorities should be set against service improvement plans. For instance, if the goal of the organization is to improve their capabilities in handling incidents, it is clear that incident management will be the primary focus; but any interfacing process with incident management can be improved in relation to supporting incident management, i.e. the development of a known error database in problem management, the interface with ISM for security-related incidents, the proper criteria and procedure for invoking a continuity plan from the service desk, etc.. Taking this holistic approach ensures that all service management processes are being improved in some way without having to focus exclusively on the process.


345

14.1.1 How to Improve

The approach for improving service management, service design, and service design processes should be the same as improving services, namely the use of the Continual Service Improvement. This entails using a six-stage approach to continual improvement

• Determining the vision.

• Determine current state.

• Determine future state.

• Determine what actions to take to move from current to future state.

• Monitor and identify success in actions.

• Continue momentum.

The vision of the organization is highly influenced by the culture and environment of the organization: the people must “buy-into” the vision in order for the organization to be successful. If the people cannot, a change must be introduced into the cultural and structural aspects of the organization. Is it no wonder that huge personnel changes typically follow management changes?

The work required to establish and maintain an effective vision for an improvement:

• Establish a vision which is aligned with the vision of the business (customer) and objectives.

• Establish the scope of project o program.

• Establish a set of high-level objectives.

• Establish governance, sponsorship and budget.

• Obtain commitment of support from senior management.

• Establish a culture focused on:

Ř Quality.

Ř Customer and business focus.

Ř Continual learning.

Ř Continual improvement.

Ř Commitment to improvement cycle.

Ř Ownership and accountability.

346



Once a vision is established the current environment needs to be assessed to establish a “baseline”: what currently exists in terms of processes, procedures, and policies and the maturity of the organization to grow and improve with the process. Assessments can be performed using:

• Internal reviews and audits.

• Maturity assessments.

• External assessments or benchmarks.

• ISO/IEC assessments and audits (ISO/IEC 20000).

• COBIT audit.

• SWOT analysis.

• Risk assessment and management.

The areas of the current environment to be assessed can include:

• Culture and maturity of the organization.

• Existing processes and their capabilities, maturity and extent of adoption.

• Skills and competencies of people.

• Service s and technology.

• Suppliers, contracts, and capability.

• Quality of service.

• Current measurements, metrics, and KPIs.

• Alignment with business goals, objectives, and strategy.

The assessment of culture and processes may be expanded out of necessity in order to clearly define the capabilities and maturity of the organization and the processes used within the organization. Assessments may examine:

• Cultural assessments:

Ř Skills and competencies.

Ř Ways or working together (processes).

Ř Technology and tools used.

Ř Vision, goals and results (steering).


347

Ř Values and beliefs (attitudes).

Ř Level and degree of interaction with business, customer, users and other stakeholders.

• Process assessments:

Ř Vision.

Ř Process maturity.

Ř Roles, responsibilities, and competencies.

Ř Tools and technology.

Ř Culture.

As evidenced above, some overlapping may be found in different assessment frameworks.

The vision and current state assessment will provide insight in determining the future state of the organization, which will typically be expressed in the following terms:

• Improved alignment with the business.

• Improved quality of design.

• Improved service levels and quality.

• Increased customer satisfaction.

• Improved process performance.

The use of SMART objectives will set clear expectations for the organization in defining the future state and enable easier planning when determining how to move from the current to future state. All plans should consider:

• Actions to be taken.

• Methods to be used.

• Approaches to take.

• Activities and timescales.

• Risks.

• Resources and budgets.

• Roles and responsibilities.

• Monitoring, measuring and reviews.

348



The use of SMART objectives will also aid in determine the success of an improvement. Monitoring, measuring and reviews during plan execution will address whether the future objectives were achieved, any lessons learned, and other improvement opportunities to take on next time.

The essence of continual improvement is that it continues after the improvement has been made by diving into another improvement project or program: these requires moving thorough the six-stage approach again. Continual improvement also requires maintaining the momentum which can be influenced in two ways (as defined in physics):

• The forces applied to the object (motivation).

• The forces applied against the object (friction).

To maintain momentum in continual improvement, the organization must motivate while reducing the level of friction. This can be done though:

• Establishing a learning environment.

• Establishing a desire to improvement.

• Reinforcing everyone’s role in quality and improvement.

• Communicating openly about improvements and quality.

14.1.2 Measuring Service Design

The success of Service Design requires the following to exist:

• Clearly defined goals and objectives for service design.

• Strong understanding of processes, procedures, functions, roles, and responsibilities in

service design.

• Strong understanding of interfaces and dependencies between elements of service design

and the service lifecycle.

• Strong understanding of and alignment with business needs.

• Appropriate development and implementation of measurement and analysis technology,


349

methods and techniques.

• Suitable alignment of measurements and metrics to accurately evaluate the health of

service design and identify opportunities for improvement.

• Regular review of measurement program.

Some effective methods for measurements and improvements include:

• Balanced Scorecard.

• Six Sigma.

350

15 Challenges, Critical Success Factors, and Risks

15.1 Challenges for Service Design

The general challenges to service design include:

• Business requirements – understanding them and the priorities behind them and ensuring

they are at the forefront of all design activities.

• Organization and culture – understanding the people and organization culture of the

business and the service provider to identify the right design fit.

• Communication – being able to explain what is happening and the impact on services and

the organization in a clear, unambiguous manner, as well as to listen for the needs and

requirements of individuals.

• Collaboration – involving as many people as possible in the design stage to ensure all issues

are addressed and the right solutions are designed without losing effectiveness or efficiency

in the design processes.

• Commitment – obtaining the appropriate level of commitment from management and staff

to support new and changed service designs.

Specific challenges consist of:

• Resistance to change.

• Resistance to planning.

• Resistance to work within agreed strategy.

• Difficulty with documentation and adherence to agreed practices and processes.

Chapter 15

351

• Unclear or changing requirements.

• Lack of awareness and knowledge of service and business requirements and targets.

• Lack of awareness and adherence to service policies and procedures.

• Certain facilities or functions are not built into the design.

• Inefficient use of resources.

• Over-commitment for available resources.

• Lack of good knowledge of impact and priorities to the business.

• Poor relationships, communication or lack of cooperation.

• Lack of information, monitoring and measurements.

• Unreasonable targets or timescales.

• High cost or complexity in required tools.

• Cost and budgetary constraints.

• Poor supplier management and/or performance.

• Lack of focus on service availability.

• Alignment concerns with current architectures, strategies, and policies.

• Use of diverse and disparate technologies and applications.

• Viewing daily operations as part of design.

• Difficulty ascertaining ROI and relationship of benefits.

15.2 Risks of Service Design

Risk describes a possible event that can cause harm or loss, or impact the organization’s ability to achieve objectives. Risk is measured in terms of probability, vulnerability, and impact. Handling of risk in an organization involves to major activities:

• Risk Assessment.

• Risk Management.

352



The risks associated with service design include:

• All CSFs for individual service design processes must be met to ensure the success of service

design and service management.

• Low maturity of one service management process will adversely impact the full maturity of

other processes.

• Business requirements are not clear to IT staff.

• Business timescales are insufficient to ensure adequate service design.

• Testing is insufficient, resulting in poor design and implementation of the service.

• The balance between innovation, risk and cost cannot/has not been obtained.

• The fit between infrastructures, customers and partners is insufficient to meet overall

business requirements.

• IT planners and business planners do not have a coordinated interface between them.

• Strategies and policies are not available or are unclear.

• Processes are over- or under-engineered.

• Insufficient resources and budget for service design activities.

• Services are developed in isolation.

• Insufficient time or training given to service design.

• Insufficient engagement or commitment with the functional development of an application.

15.3 Critical Success Factors in Service Design

From a perspective of service design, the achievement of every critical success factor within each service management process is itself a critical success factor for service design, particularly with the service design processes. Put this into context: a CSF for Information Security Management is the determination of a clear and agreed information security policy: this inevitably is a deliverable of the service design stage for this process and equally a CSF for service design in this area. The achievement can be extended to compliance by all services, processes and IT components which pass through service design to the agreed information security policy and even identifying potential changes to the policy because of these designs. In essence, achievement of process-specific CSFs (and KPIs) demonstrates the quality of service


353

design.

Other possible CSFs in service design are project-based and reference schedules, budgets, and accuracy. Specific factors can include:

• Percentage of service design requirements specifications created on time.

• Percentage of service design requirements specifications created to budget.

• Percentage of serviced design plans created on time.

• Percentage of service design packages completed on time.

• Percentage of QA and acceptance criteria plans produced on time.

• Accuracy of service design.

• Percentage accuracy of cost estimate for service design.

• Accuracy of SLAs, OLAs, and contracts.

354

Module 3:

1. A

2. D

3. B

4. C

5. D

6. A

7. B

8. C

9. C

10. B

Module 4:

1. C

2. A

3. D

4. B

5. A

6. D

7. B

8. C

9. A

10. D

11. B

Module 5:

1. D

2. A

3. B

4. D

5. C

6. A

7. C

8. B

9. D

10. A

Module 6:

1. B

2. D

3. A

4. A

5. B

6. C

7. D

8. C

9. D

10. A

11. B

12. C

13. B

Module 7:

1. C

2. A

3. D

4. B

5. C

6. D

7. B

8. A

9. B

10. C

Module 8:

1. D

2. B

3. C

4. A

5. B

6. C

7. D

8. C

9. A

10. B

11. A

Module 9:

1. A

2. D

3. C

4. D

5. B

6. C

7. A

8. B

9. C

10. D

Module 10:

1. C

2. B

3. D

4. A

5. D

6. B

7. C

8. D

9. C

10. A

Chapter 16

16 Answers to Elearning Module & Workbook Review Questions

355

Module 11:

1. B

2. C

3. D

4. A

5. D

6. B

7. C

8. A

9. B

10. D

Module 12:

1. D

2. B

3. C

4. D

5. A

6. C

7. B

8. A

9. B

10. C

Module 13:

1. B

2. D

3. A

4. C

5. D

6. B

7. C

8. B

9. A

10. C

Module 14:

1. D

2. B

3. A

4. D

5. C

6. B

7. A

8. C

9. B

10. D

Module 15:

1. A

2. D

3. B

4. C

5. D

6. B

7. A

8. C

9. C

10. A

356

17 Glossary

Glossary terms and definitions are based on the content taken from the five ITIL official lifecycle books (SS, SD, ST, SO, CSI) Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS.

Term DefinitionsAccounting In the context of ITSM, this is a synonym for

IT Accounting.Agreement A Document that describes a formal

understanding between two or more parties. An Agreement is not legally binding, unless it forms part of a Contract.

Application Management The Process responsible for managing Applications throughout their Lifecycle.

Asset Management (Financial Management) Asset Management is the Business Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle.

Availability (Availability Management) (Security Management) Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

See Security Principle.

Chapter 17

357

Term DefinitionsAvailability Management (Availability Management) The Process

responsible for defining, analyzing, Planning, measuring and improving all aspects of the Availability of IT services. Availability Management is responsible for ensuring that all IT Infrastructure, Processes, Tools, Roles etc. are appropriate for the agreed Service Level Targets for Availability.

Baseline The recorded state of something at a specific point in time. A Baseline can be created for a Configuration, a Process, or any other set of data. For example, a baseline can be used in:

• Continuous Service Improvement, to establish a starting point for planning improvements.

• Capacity Management, to document performance characteristics during normal operations.

• Configuration Management, to enable the IT Infrastructure to be restored to a known configuration if a Change fails. Also used to specify a standard Configuration for data capture, release or Audit purposes.

Budgeting (Financial Management) The Activity of predicting and controlling the spending of money. Consists of a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day monitoring and adjusting of current Budgets.

Build (Release Management) The Activity of assembling a number of Configuration Items to create part of an IT Service. The term Build is also used to refer to a Release that is authorized for distribution. For example Server Build or laptop Build.

358



Term DefinitionsBusiness Continuity Plan (BCP) (IT Service Continuity Management) A

Plan defining the steps required to Restore Business Processes following a disruption. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. IT Service Continuity Plans form a significant part of Business Continuity Plans.

Business Impact Analysis (BIA) (IT Service Continuity Management) BIA is the Activity in Business Continuity Management that identifies Vital Business Functions and their dependencies. These dependencies may include Suppliers, people, other Business Processes, IT Services, etc.

BIA defines the recovery requirements for IT Services. These requirements include Recovery Time Objectives, Recovery Point Objectives and minimum Service Level Targets for each IT Service.

Business Relationship Management (BRM) (Business Relationship Management) The Process responsible for maintaining a Relationship with the Business. This Process usually includes:

• Managing personal Relationships with Business managers.

• Portfolio Management. • Ensuring that the IT Service Provider

is satisfying the Business needs of the Customers.

This Process has strong links with Service Level Management.

Capacity (Capacity Management) The maximum Throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets. For some types of CI, Capacity may be the size or volume, for example a disk drive.


359

Term DefinitionsCapacity Management (Capacity Management) The Process

responsible for ensuring that the Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level Targets in a Cost Effective and timely manner. Capacity Management considers all Resources required to deliver the IT Service, and plans for short-, medium- and long-term Business Requirements.

Change (Change Management) The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all Configuration Items, Processes, Documentation, etc.

Change Advisory Board (CAB) (Change Management) A group of people that assists the Change Manager in the assessment, prioritization and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, representatives from the Business, and Third Parties such as Suppliers.

Change Advisory Board / Emergency Committee (CAB/EC)

(Change Management) A sub-set of the Change Advisory Board who make decisions about Emergency Changes. Membership of the CAB/EC may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.

Change Management (Change Management) The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Charging (Financial Management) Requiring payment for IT Services. Charging for IT Services is optional, and many Organizations choose to treat their IT Service Provider as a Cost Center.

360



Term DefinitionsConfiguration Item (CI) (Configuration Management) Any

Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the CMDB and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.

Configuration Management (Configuration Management) The Process that is responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. The primary objective of Configuration Management is to underpin the delivery of IT Services by providing accurate data to all IT Service Management Processes when and where it is needed.

Configuration Management Database (CMDB)

(Configuration Management) A Database used to manage Configuration Records throughout their Lifecycle. The CMDB records the Attributes of each CI, and Relationships with other CIs. A CMDB may also contain other information linked to CIs, for example Incident, Problem or Change Records. The CMDB is maintained by Configuration Management and is used by all IT Service Management Processes.

Cost (Financial Management) The amount of money spent on a specific Activity, IT Service, or Business Unit. Costs consist of real cost (money), notional cost such as people’s time, and Depreciation. Cost is also used as the name of a Charging Policy that recovers the exact cost of providing the service.


361

Term DefinitionsCritical Success Factor (CSF) Something that must happen if a Process,

Project, Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For example a CSF of “protect IT Services when making Changes” could be measured by KPIs such as “percentage reduction of unsuccessful Changes,” “percentage reduction in Changes causing Incidents,” etc.

Customer Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term “Customers” is also sometimes informally used to mean Users; for example, “this is a Customer Focused Organization.”

Definitive Hardware Store (DHS) (Release Management) One or more physical locations in which hardware Configuration Items are securely stored when not in use. All hardware in the DHS is under the control of Change and Release Management and is recorded in the CMDB. The DHS contains spare parts, maintained at suitable revision levels, and may also include hardware that is part of a future Release.

Definitive Software Library (DSL) (Release Management) One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored. The DSL may also contain associated CIs such as licenses and documentation. The DSL is a single logical storage area even if there are multiple locations. All software in the DSL is under the control of Change and Release Management and is recorded in the CMDB. Only software from the DSL is acceptable for use in a Release.

362



Term DefinitionsDemand Management (Capacity Management) Optimizing the

use of Capacity by moving Workload to less utilized times, Servers, or places. Demand Management often uses Differential Charging to encourage Customers to use IT Services at less busy times. Demand Management also makes use of other techniques such as limiting the number of concurrent Users.

Emergency Change (Change Management) A Change that must be introduced as soon as possible. For example, to resolve a Major Incident or implement a Security patch. The Change Management Process will normally have a specific Procedure for handling Emergency Changes.

Financial Management for IT Services (Financial Management) The Process responsible for managing an IT Service Provider’s Budgeting, Accounting and Charging requirements.

Help Desk (Service Desk) A point of contact for Users to log Incidents. A Help Desk is usually more technically focused than a Service Desk and does not provide a Single Point of Contact for all interaction. The term Help Desk is often used as a synonym for Service Desk.

Incident (Incident Management) An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Any event which could affect an IT Service in the future is also an Incident. For example Failure of one disk from a mirror set.

Incident Management (Incident Management) The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Customers as quickly as possible.


363

Term DefinitionsInformation Technology (IT) The use of technology for the storage,

communication, or processing of information. The technology typically includes computers, telecommunications, Applications and other software. The information may include Business data, voice, images, video, etc. Information Technology is often used to support Business Processes through IT Services.

IT Infrastructure Library (ITIL) A set of Best Practice guidance for IT Service Management. ITIL is owned by the AXELOS and is developed in conjunction with the itSMF. ITIL consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them.

See http://www.axelos.com for more information.

Key Performance Indicator (KPI) A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity.

KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.

Knowledge Management The Process responsible for gathering, analyzing, storing and sharing knowledge information within an Organization. The primary purpose of Knowledge Management is to improve Efficiency by reducing the need to rediscover knowledge.

Known Error (KE) (Problem Management) A Problem that has a documented Root Cause and a Workaround. Known Errors are created by Problem Control and are managed throughout their Lifecycle by Error Control. Known Errors may also be identified by Development or Suppliers.

364



Term DefinitionsKnown Error Database (Service Desk) (Incident Management)

(Problem Management) A Database containing all Known Error Records. This Database is created by Problem Management and used by Incident and Problem Management.

Lifecycle The various stages in the life of a Configuration Item, Incident, Problem, Change etc. The Lifecycle defines the Categories for Status and the Status transitions that are permitted. For example:

• The Lifecycle of an Application includes Design, Build, Test, Deploy, Operate, etc.

• The lifecycle of an Incident includes Detect, Respond, Diagnose, Repair, Recover, Restore.

• The lifecycle of a Server may include: Ordered, Received, In Test, Live, Disposed, etc.

Major Incident (Incident Management) The highest Category of Impact for an Incident. A Major Incident results in significant disruption to the Business.

Operational Level Agreement (OLA) (Service Level Management) An Agreement between an IT Service Provider and another part of the same Business that provides Services to them. For example there could be an OLA with a facilities department to provide air conditioning or with the procurement department to obtain hardware in agreed times. An OLA may also be between two parts of the same IT Service Provider, for example between the Service Desk and a Support Group.

Policy Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.


365

Term DefinitionsProactive Problem Management (Problem Management) Part of the

Problem Management Process. The Objective of Proactive Problem Management is to identify Problems that might otherwise be missed. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management Processes to identify trends or significant problems.

Problem The root cause of one or more incidents.Problem Management (Problem Management) The Process

responsible for managing the Lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the Impact of Incidents that cannot be prevented. Problem Management includes Problem Control, Error Control and Proactive Problem Management.

Release (Release Management) A collection of hardware, software, documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.

Release Management (Release Management) The Process responsible for Planning, scheduling and controlling the movement of Releases to Test and Live Environments. The primary objective of Release Management is to ensure that the integrity of the Live Environment is protected and that the correct Components are released. Release Management works closely with Configuration Management and Change Management.

Request for Change (RFC) (Change Management) A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.

366



Term DefinitionsReturn on Investment (ROI) (Financial Management) A measurement

of the expected benefit of an investment. Calculated by dividing the average increase in financial benefit (taken over an agreed number of years) by the investment.

Risk The possibility of suffering harm or loss. In quantitative Risk Management this is calculated as how likely it is that a specific Threat will exploit a particular Vulnerability.

Risk Assessment The initial steps of Risk Management. Analyzing the value of Assets to the business, identifying Threats to those Assets, and evaluating how Vulnerable each Asset is to those Threats.

Risk Management The Process responsible for identifying, assessing and managing Risks. Risk Management can be quantitative (based on numerical data) or qualitative.

Service Catalog A Document listing all IT Services, with summary information about their SLAs and Customers. The Service Catalog is created and maintained by the IT Service Provider and is used by all IT Service Management Processes.

Service Desk (Service Desk) The Single Point of Contact between the Service Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.

Service Level Agreement (SLA) (Service Level Management) An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple customers.


367

Term DefinitionsService Level Management (SLM) (Service Level Management) The Process

responsible for negotiating Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on Service Levels, and holds regular Customer reviews.

Single Point of Contact (SPOC) Providing a single consistent way to communicate with an Organization or Business Unit. For example, a Single Point of Contact for an IT Service Provider is usually called a Service Desk.

Single Point of Failure (SPOF) Any Configuration Item that can cause an Incident when it fails, and for which a Countermeasure has not been implemented. A SPOF may be a person, or a step in a Process or Activity, as well as a Component of the IT Infrastructure.

Standard Change A pre-approved Change that is low Risk, relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request.

Underpinning Contract (UC) A Contract with an external Third Party that supports delivery of an IT Service by the IT Service Provider to a Customer. The Third Party provides goods or Services that are required by the IT Service Provider to meet agreed Service Level Targets in the SLA with their Customer.

368



Term DefinitionsUrgency A measure of how long it will be until

an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the Financial Year. Impact and Urgency are used to assign Priority.

User A person who uses the IT Service on a day-to-day basis. Users are distinct from Customers, as some Customers do not use the IT Service directly.

Vital Business Function (VBF) A Function of a Business Process which is critical to the success of the Business. Vital Business Functions are an important consideration of Business Continuity Management, IT Service Continuity Management and Availability Management.

Workaround (Incident Management) (Problem Management) Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record.

369

18 References

ITIL®. Continual Service Improvement (2011) Cabinet Office. London. Published on behalf of

AXELOS Limited by TSO.

ITIL®. Service Design (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by TSO.

ITIL®. Service Operation (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

ITIL®. Service Strategy (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

ITIL®. Service Transition (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

Chapter 18

370

19 Index

A

ability 32-3, 118-19, 122, 146, 167, 199-200, 242, 251, 264, 273, 295, 337, 356

acceptance 71, 101, 269, 272, 282, 322

accuracy 101, 153-4, 162, 164, 240, 353

acquisition 107-8, 234, 335-6

agreements 81, 86, 90, 138, 183, 188-9, 216-17, 229, 246, 280, 283, 285-7, 325, 329, 356, 366-7

alignment 25, 27, 59, 123, 137, 140, 155, 172, 183, 258, 263, 282, 307, 335, 346, 348-9

AMIS (Availability management information system) 73, 87, 218, 221-2, 225, 291

answers 17-18, 231, 344

application development 105, 315-16, 336, 340

Application Management 34, 52, 294, 301, 356

applications 18, 33, 36-7, 69, 71, 79-80, 94-5, 105, 107, 111-12, 124, 301-5, 331, 336, 351-2, 363-4

architectures 58, 76, 78, 91-5, 103, 111, 130, 139-40, 148, 212, 255, 270, 286, 303, 331-2

arrangements 123-5, 252, 279

assessment 86, 137, 209-10, 218-19, 246, 249, 255-6, 269, 271, 326, 344, 346, 359

assets 35, 38, 80, 104, 263, 265-6, 271, 299-300, 302, 335-6, 342, 356, 366

assistance 217, 237-8, 270-1, 286

attributes 90, 96-7, 99, 360

availability 42, 58, 78, 103, 110, 134, 175-7, 195, 197-204, 206-12, 217-21, 224-5, 263-4, 300, 325-6,

Chapter 19

371

356-7

availability management 35, 51, 70, 187, 195-202, 210-11, 215, 217-19, 221-2, 224-5, 243-5, 256,

260-1, 325, 356-7

availability management information system 73, 87, 218, 221, 225, 326

availability management process 103, 197-8, 224, 322, 326

availability plan 195-6, 198, 204, 207, 209, 223, 225, 326

availability targets 197, 216-17, 219

AXELOS 30, 38-41, 50, 52, 356, 363

AXELOS Limited 30, 38-41, 50, 52, 356, 369

B

baselines 33, 236, 346, 357

Basic Concepts 9-12, 134, 156, 172, 199, 230, 247, 266

BCM (business continuity management) 245, 247, 256, 258-60, 262, 322, 327

BCM strategy 246-7, 256, 259

BCP (Business Continuity Plan) 198, 245, 358

BIA (Business Impact Analysis) 160, 165, 177, 194, 210, 246, 248-50, 254, 259-60, 341, 358

budgets 64, 67, 81, 84-5, 109, 120, 127, 132, 144, 149, 221, 238, 240, 307, 315, 352-3

business 23-5, 123-6, 183-5, 187-90, 196-9, 203-4, 207-8, 220-3, 228-32, 234, 239-41, 245-55, 257-9,

262-5, 272-5

business activity 25, 60, 64, 84, 176, 228, 239

business areas 262, 328, 332

business continuity 63, 224, 245, 358, 368

Business Continuity Plan (BCP) 198, 245, 358

372



business information 143, 158, 160, 186, 218, 238, 241

business objectives 20, 99, 104, 108, 159, 167, 183, 199, 257, 267

business operations 177, 212, 247, 252, 264, 279

business outcomes 75, 130, 133, 148, 158, 323

business perspective 176, 190, 197

business plans 110, 229, 232, 239, 258, 264

business processes 25-6, 28, 42, 76, 80, 89, 93, 106, 159, 200, 216-17, 246-7, 249, 258-9, 334-5, 358

business relationship management 69, 118, 144, 159, 161, 165, 168, 171, 173, 182-4, 187, 192, 197,

321, 358

Business Relationship Management (BRM) 69, 118, 144, 159, 161, 165, 168-9, 171-3, 180, 182-5, 187,

192, 197, 321, 358

business requirements 67, 72, 85, 87, 106, 108, 110, 117, 127, 142, 160, 167, 177, 194, 290-1, 350-2

business security 263, 265, 272-3, 322

business strategies 73, 116, 151, 240, 261

business transactions 203, 264, 301

business units 34-5, 38-40, 49, 158-9, 187, 190, 253, 360, 367

business users 89, 161, 326

C

CAB meetings 65, 326-8, 330, 332-3

capabilities 22-4, 30, 33-4, 39-40, 48, 62-3, 77-8, 80, 86, 120-2, 138-40, 250, 252, 279-82, 343-4, 346

capacity 42, 58, 78, 103, 110, 176-7, 187, 219, 227-8, 230-9, 241-4, 249, 295, 317, 326-7, 358-9

capacity management 28, 51, 70, 129, 187, 219, 222, 227-44, 256, 271, 316, 320, 322, 326-7, 357-9


373

capacity plans 70, 218, 228-9, 234-5, 238-9, 243

capacity requirements 229, 235, 244, 326

catalog 47, 89, 153-9, 161-4, 166, 298

centralization 309, 311, 318

CFIA (Component failure impact analysis) 210, 212-14, 226, 260, 341

Challenges and Risks 146, 162, 189, 221, 240, 258, 273, 288

change management 62, 68, 74, 86, 130, 138, 141, 143, 149, 152, 182, 219, 225, 254, 291-2, 359-60

change management process 98, 130, 134, 143, 216, 218, 256, 271

changed services 58, 65, 71, 73, 81-2, 86, 111, 130, 137, 140, 144-5, 152, 169, 173, 209-10, 331-2

clients 128, 147, 190, 274, 337

CMIS (Capacity management information system) 87, 234, 238, 243, 291

CMS (Configuration management system) 64, 69, 71, 73, 87-8, 90, 127, 143, 151, 154-5, 158, 160-2,

165-6, 176, 183, 291

commitment 77, 167, 185, 189, 221, 232, 240, 258-9, 273-4, 283, 289, 293, 345, 350, 352

communication 22, 37, 40-1, 51, 144, 147, 157-8, 168, 171, 182, 190, 203, 251, 274-5, 322, 350-1

company 54, 148, 163, 175-6, 190, 246, 259, 266, 269, 274-5, 279, 290

competencies 67, 86, 96, 114, 121-2, 136, 148, 208, 228, 232, 336, 346-7

complaints 174, 180, 184-6, 325

completion 17, 85-6, 105-6, 140, 246, 248, 259, 269

compliance 80, 92, 100-1, 103, 126, 128, 135, 137, 142, 144, 150, 175, 183, 254, 268, 331-2

compliments 173-4, 180, 184-6

component availability 198, 200-1, 209, 219, 221, 225

component capacity 229, 234, 239-40

374



component failure 200, 209-10, 212-13, 226

component level 104, 195, 234

component performance 235, 238-40, 327

components 45, 75-7, 80-1, 91-2, 94, 105-7, 197-200, 203-4, 210-14, 216-17, 227-9, 234-5, 237-8,

240-1, 270-2, 304-5

conditions 66, 89, 94, 112, 168, 210, 214, 223, 232, 247, 249, 281-4, 288, 307, 329, 336

confidentiality 175, 224, 240, 263-5, 267, 276, 299, 329

configuration 33, 103, 109-10, 199, 235, 254, 332, 339, 341, 356-7, 359-60

Configuration Item (CI) 33, 90, 109, 154-5, 158-9, 183, 199-200, 213, 227, 242, 257, 264, 271, 357-8,

360-1, 367-8

configuration items 90, 109, 154-5, 158-9, 183, 200, 213, 257, 264, 271, 357-8, 360-1, 364, 367

Configuration Management 159, 357, 360

configuration management system 69, 73, 87, 90, 127, 143, 151, 154-5, 158, 161, 165-6, 176, 178,

183, 268, 287

conflicts 109, 116, 123-4, 130, 139, 141, 296, 307, 313, 323

conjunction 92, 159, 161, 169, 171, 173, 209, 268, 328-9, 331, 363

constraints 42, 58, 60, 62, 66, 80, 90, 97, 104, 110, 113-14, 132, 141, 143, 146, 177

context 32, 48, 57, 59-60, 62, 76-7, 101, 128, 134-5, 139, 159, 169-70, 174-5, 199-201, 211, 263-4

continual improvement 35, 57, 63, 269, 345, 348

Continual Service Improvement 8, 30, 56, 59, 62-4, 66, 72-3, 136, 215, 345, 369

continuity plans 110, 217, 245-6, 251-7, 261-2, 328, 344, 358

contract management information system 87, 280, 284, 286, 291, 329

contracts 67, 90, 172, 185, 191, 199, 265, 280-1, 283-8, 328-30, 332, 346, 353, 356, 367


375

ContXT 147-8, 163, 190, 222, 241, 259, 274-5, 290

cooperation 137, 173, 184-5, 201, 245, 265, 273, 325-6, 351

coordination 67, 93, 128-30, 144, 148-9, 235, 251, 310, 312, 318, 322, 330-2

costs 35-6, 40, 70-1, 98, 104-5, 128, 176-7, 187-8, 204-5, 211, 220, 229-31, 243, 285, 351-2, 360

countermeasures 213, 215, 367

Critical Success Factor (CSF) 10-13, 21, 65-6, 145, 152, 161, 166, 188, 219, 239, 244, 257, 272, 287,

352, 361

Critical Success Factors and Key Performance Indicators 145, 161, 188, 219, 239, 257, 272, 287

CSI register 66, 110, 170, 185-6, 319

culture 23, 120, 345-7, 350

customer 23-4, 32-45, 48-9, 56-9, 77-82, 101-3, 148-50, 153-9, 167-93, 199-200, 203-5, 279-80, 296-7,

313-15, 361-2, 366-8

customer organization 170, 205, 258, 266

customer outcomes 57-8, 60, 133, 155

customer perspective 100, 184, 219

customization 121, 339, 341

D

damage 246, 249

days 180, 205, 254, 339

decisions 61-2, 87, 164, 182, 254, 256, 259, 309, 311, 336, 344, 359

Decreased 188, 219-20, 239, 272-3

delivery 23, 26, 35, 72, 75-6, 95, 102-3, 120, 156-7, 195, 197, 228-9, 291, 315, 319-20, 360

376



Demand Management 161, 165, 190, 192, 197, 219, 229, 234, 239, 243-4, 362

departments 26, 52, 55, 96, 147-8, 191, 241, 259, 314-15, 364

dependencies 48, 67, 71, 76, 85, 108-9, 119, 121, 153-4, 156, 158-9, 187, 212-13, 283, 334-5, 358

design 61-2, 65-6, 72-3, 77-8, 81-6, 88-92, 99, 111, 120-2, 129-34, 136-44, 199-200, 302-3, 321-3, 332-

3, 351-3

design activities 77, 110-11, 129-31, 139-40, 145, 149-50, 235, 323, 350

design aspect 84, 127, 210

design coordination 51, 129-33, 135-52, 187, 321, 323

design coordination process 130-1, 135, 141, 148-51, 316

design efforts 66, 81, 87, 131, 133-4, 139, 141, 317, 334

design elements 90, 104, 106

design phase 85-6, 88, 315

design policies 138-9, 144, 332

design processes 82, 87, 137, 146, 334, 350

design project 130, 135, 141, 148, 316

design stage 58, 131-2, 154, 350

designers 83, 93, 116, 128, 132, 139, 148, 274, 317, 332, 334

developers 92, 279, 281, 302, 304, 316

development 46, 72, 75-6, 83-6, 88, 104-5, 111-13, 118-20, 127, 148, 154, 164, 175, 177, 304, 331

Development of service solution 84, 112-13, 127

development project 83-4, 86, 92, 127

disaster 246, 250, 252-3, 256

disruption 26, 254, 287, 292, 343, 358-9, 364


377

documentation 84, 86, 160, 174, 219, 255, 267, 269, 298, 329, 331-2, 350, 359-61, 365

downtime 203, 205-6, 210, 356

E

effectiveness 56, 59, 87, 98-100, 103, 128, 130, 137, 155, 177, 207-8, 253, 288, 331-2, 337, 363

efficiency 26, 61, 98-101, 103, 128, 133, 150, 229, 295, 299, 324, 327, 331-2, 337, 350, 363

efforts 25-6, 36, 77, 81, 109, 131, 141-2, 148, 184, 189, 201, 206, 209, 211, 215, 252

Elearning Module 72, 115, 126, 149, 164, 192, 224, 242, 276, 291, 306, 340

employees 163, 203-4, 259, 274-5

environment 22, 51, 56, 72, 80, 82, 86, 90-2, 97-8, 103-4, 131, 148, 227-8, 232-3, 303-4, 337-8

events 53, 67, 125, 197, 204, 214-15, 217, 232, 237, 246-7, 250, 253-4, 257, 259, 270-1, 362

expertise 122-4, 132, 134, 314

F

facilities 67, 80, 85-6, 108-9, 124, 227, 249-50, 334, 351, 363-4

failure 53, 103, 162, 168, 199, 201-3, 206-8, 211-14, 218, 220, 246, 250, 263, 296-7

feedback 64-5, 73, 111, 143, 160, 317

Financial information 64, 84, 175, 218, 287

Financial Management 70, 78, 144, 187, 229, 271, 287, 320, 326, 356-7, 359-60, 362, 366

focus 22, 26, 36-7, 40, 57, 78, 82, 102, 107-8, 122, 182, 234, 263-4, 268, 297, 310-11

framework 30, 32, 137-8, 174, 176, 267, 302, 333

frequency 70, 172, 180-1, 211, 216

378



FTA (Fault tree analysis) 210, 214, 226

functionality 68, 102, 104-6, 108-9, 115, 173, 192, 195, 203, 216, 222-3, 302, 304, 315, 340

functions 33-4, 39, 48, 51, 53-4, 68, 78, 93, 119, 123, 130, 138, 252, 301-3, 312-16, 322

G

generic 318, 321, 323, 336

goals 23, 25, 68, 75, 95, 98, 130, 134, 231, 295, 309, 344, 346

groups 34, 54, 100, 311-12, 314-16, 335, 359, 361

growth 229, 310, 312, 314

guide 228, 245, 332-3

H

hardware 36, 45, 66, 75, 80, 103, 112, 190, 216, 228, 241, 266, 279-80, 338, 360-1, 364-5

holistic service design 75-7, 80, 104, 115

hours 134, 177, 180, 205-7, 216, 221, 251

I

IEC 114, 154, 184, 276, 346

implementation 23, 58, 78, 82, 136-7, 140, 170, 175, 196, 224, 234-5, 248, 260-1, 268-9, 312, 337-8

Implementing Service Design 21, 343-4

Incident and Problem Management 256, 271, 364

incident management 48, 54, 69, 185, 187, 199, 201, 205-7, 219, 225, 244, 261, 320, 344, 362, 364

incident management process 100-1, 103


379

incidents 54-5, 64, 69-70, 100-1, 103, 156, 158, 179, 197-8, 206-7, 238-9, 272-3, 325-6, 361-2, 364-5,

367-8

individual components 36, 103, 118, 200, 204, 216, 233, 303-4

individual services 102, 156, 158, 174, 232, 340

information 64-6, 107-8, 116, 143-4, 153-9, 161-6, 174-7, 197-8, 240-1, 258, 263-6, 274-5, 285-7, 323-

4, 360, 363

information assets 269, 328, 336

information security 147-8, 175, 263, 266-9, 273, 278, 326

information security management 51, 70, 129, 145, 148, 175, 187, 215, 219, 257-8, 263-4, 267-74,

276-8, 322, 328

Information Security Management (ISM) 51, 70, 129, 132, 145, 148, 187, 219, 257-8, 263-5, 267-74,

276-8, 291-2, 322, 328

information security management process 132, 264-5, 268, 272, 322

information security policy 132, 175, 264-9, 271, 273, 276, 282, 287, 328

information technology 23, 300, 363

initiation 197, 246-8, 260-1

inputs 9-13, 49, 64-5, 96-7, 99, 110-11, 117, 142, 160, 185-6, 189, 217-18, 237-8, 255-6, 270, 286

Inputs Outputs 142-3, 160, 186, 218, 238, 256, 270-1, 286-7

integration 67, 85, 96, 98, 105, 122, 133, 135, 146, 221, 246, 265, 289, 303, 311, 337

integrity 175, 224, 263-5, 267, 271, 276, 299, 329, 365

interdependencies 104-6, 148

interfaces 49, 62, 67, 71, 76, 109, 112, 138, 143, 151, 153-4, 158-9, 187-8, 323-4, 329, 334-5

Introduction to Service Design 8, 21, 56

investment 30, 39, 77, 164, 167, 221, 230, 265, 269, 366

380



invocation 252, 254, 260, 328, 358

ISMS (information security management system) 265, 267-8, 276-7, 291

ISO 29, 114, 154, 184, 276, 346

IT Service Management (ITSM) 16, 18, 20-6, 28-9, 34, 36, 47, 56, 78, 80, 82, 114, 153, 167-8, 360, 365-

7

ITIL framework 24, 29-30, 32

ITSCM (IT Service Continuity Management) 51, 69, 124, 129, 144, 159, 187, 197-8, 219, 244-8, 250-1,

255-62, 322, 326-8, 358

ITSCM plans 246, 256-8, 262

ITSCM strategy 246-8, 250

K

Key Performance Indicator (KPIs) 65-6, 145, 152, 161, 188, 219, 239, 244, 257, 272, 278, 287, 292, 361,

363

key performance indicators 145, 152, 161, 188, 219, 239, 257, 272, 287, 363

knowledge 18, 24, 62, 64, 66, 86, 96, 104, 110, 121, 123-4, 136, 139, 146-7, 296-7, 315

Known Error (KE) 69-70, 156, 166, 344, 363-4, 368

L

lack 53, 87, 146, 162, 167, 189-90, 194, 221, 223, 239-41, 258, 273-4, 289, 296-7, 315, 351

level targets, agreed Service 167, 170, 172, 359, 367

levels 21, 76-7, 99-100, 104, 107-8, 121, 136-8, 161, 171, 189, 203-4, 234, 264, 298-9, 317-18, 347-8


381

license 30, 38-41, 50, 52, 356, 361

lifecycle 46-7, 57, 72, 78, 104, 137, 196, 206, 247, 300-1, 319, 333, 356, 359-60, 362-5

lifecycle stages 32, 54, 59-61, 68, 79, 83, 137-8, 142, 146, 335

live environment 83-4, 88, 131-2, 149, 153, 161, 188, 217

loss 177-9, 205, 211, 215, 246, 249, 259, 351, 366

M

maintainability 198-9, 209, 211-12, 215, 218, 224-5, 295, 325-6, 356

maintenance 62, 66, 70, 136-7, 154, 164, 174, 185, 190, 196, 216, 246-7, 259, 264-5, 269-70, 276-7

management 23, 35, 55, 67, 76, 94-5, 138, 179, 257-8, 265, 279, 311-12, 331-2, 335-6, 356-66, 368

Management architecture 81, 91, 95

management information systems 81, 87, 90, 126, 128

management systems 60-1, 72, 76, 79-80, 90, 96, 99, 143, 146, 228, 291

managers 35, 49, 55, 155, 185, 274, 279, 311, 316, 322

Managing service 61, 63, 196, 335

manufacturers 78, 94, 238, 279, 281

market 107, 121-3, 184, 199, 279, 328

marketing 28, 156, 158, 161, 222, 272, 274

Material 30, 38-41, 50, 52

maturity 29, 86, 92, 97, 100, 141, 200, 229, 310, 346, 352

measurements 22, 30, 59, 66, 96-101, 113, 135, 143, 156, 196, 198, 201, 207, 304, 325, 348-9

meeting 25, 59, 101, 103, 182-3, 190, 199, 221, 274-5, 286, 319, 329, 358-9

metric trees 102-4, 335, 342

382



metrics 59, 65-6, 76, 81, 97, 99-103, 107, 128, 130, 136, 143, 156, 198, 269, 363

monitor 71, 98, 130, 151, 171, 204, 309, 323, 328, 330-1, 345, 367

N

network 94, 105, 190, 195, 203, 227, 310, 312, 318

new services 66, 69-71, 73, 78-9, 108, 110, 116, 120, 122, 154, 178, 240, 296, 325, 327, 332

new suppliers 70, 284-5, 291-2

number 25, 87, 105-6, 145, 161-2, 166, 179-80, 188, 205, 216-17, 220, 231, 239-40, 272-3, 275-6, 287-

8

O

objectives 25, 57-61, 97-100, 102-3, 110, 130, 134-5, 153, 171, 184, 196, 228, 245, 267, 279-80

occurrence 249, 253, 255

OLAs (operational level agreements) 65-6, 69, 71, 80, 169-70, 172-3, 178, 182, 185-6, 188, 190, 192-3,

201, 280, 311, 364

Ongoing Operation 246, 248, 261

order 17-18, 28-9, 34, 45, 47, 62, 103, 106, 108, 177, 184, 190, 222, 234, 277, 345-6

organization 21-5, 33-7, 63, 82-3, 88-9, 103-4, 120-4, 131, 157-8, 172, 204-5, 247-52, 266-9, 298-303,

309-19, 344-8

Organization structures 54, 310, 316

organizational structure 52, 54, 86, 251, 267

outcomes 25, 34-6, 40, 42, 48, 58, 72, 75, 81, 97, 101, 125, 145, 156-7, 199, 248


383

P

packages 42-3, 108, 154, 157, 161

participants 181, 183, 274, 280, 324

parties 40, 68-9, 78, 87, 107, 113, 139, 176, 181, 185, 201, 231-3, 255, 288-9, 296, 356

perceptions 37, 157, 179, 189-90, 194-5

performance 33, 42, 69-70, 100, 103, 105, 107, 128, 144, 181, 187, 197, 227-32, 234-9, 319, 326-7

person 33, 35, 37, 49, 75, 100, 103, 138, 141-2, 158, 179, 184, 189, 252, 316-20, 367-8

personnel 81, 107, 132, 138, 140, 155, 162, 175, 177, 208, 252-3, 263, 313

perspectives 57, 75, 80, 92, 102, 104-5, 115, 125, 133, 142, 195, 211, 234, 275, 296, 352

planners 93, 139, 148, 195, 330, 332, 352

planning 67, 78-9, 120, 128, 131-2, 137-8, 140-1, 144, 170, 195, 197, 209-10, 232, 234, 285, 299

plans 58-9, 67, 109-11, 139-40, 186-7, 216-18, 221-2, 228-30, 237-40, 247-8, 250-6, 258-9, 267-8, 270-

1, 286, 330-1

policies 59, 61, 67, 92, 110-11, 134-5, 137, 139-40, 143-5, 148, 172, 247-8, 266-7, 271-4, 351-2

portfolio 46-7, 69, 78, 88-9, 159, 302, 343

priorities 48, 64, 84-5, 101, 108, 139, 143-4, 146, 160, 197, 258, 269, 274, 298, 344, 350-1

problem management 70, 156, 165, 181, 197-8, 201, 207, 219, 238, 256, 261, 271, 286, 320, 329, 363-

5

Process Activities 136-7, 140, 159, 173, 201, 209, 235, 248, 269, 284, 323

process manager 35, 49, 316, 318, 320, 323, 341

process owners 35, 49, 98, 316, 318, 320-3, 341

process performance 85, 102, 104, 323

procurement 28, 110-12, 148, 176, 244, 282, 284, 323

384



products 23, 28, 61, 75, 78-9, 94-5, 98, 102, 112, 115, 180, 279, 312-14, 331, 339, 341

program 16, 61, 67, 113, 143, 148, 208, 215, 233, 345, 348

progress 85-6, 100, 103, 128, 163, 190, 325

project management 71, 135, 140-1, 146, 149, 235, 259, 315, 317, 340

project management system 147-8, 222, 274

project managers 83, 109, 116, 132, 135, 141, 146, 315, 317

projects 33, 54, 61, 67, 72, 83-5, 87, 106, 113, 130, 132, 135, 138-42, 147-8, 248, 315-17

providers 35, 39-42, 68, 95, 122-3, 178, 328, 364

Purpose and Objectives 130, 153, 171, 196, 228, 245, 263, 279

Q

quality 22-3, 26, 37, 48, 57-9, 68, 97-9, 101, 106, 133, 140, 145, 168, 285, 347-8, 362-3

R

Reactive Availability Management 197, 201, 204

recovery 205, 211-13, 218, 245, 250-2, 255-6, 326, 332

reduction 58, 145-6, 152, 169, 188, 244, 257, 262, 265, 269, 361-2

regulations 92, 99, 101, 113-14, 175, 248, 267, 279, 331, 333

relationships 38-40, 93-4, 123-4, 155-6, 158, 168-9, 171-3, 181, 183-4, 214-15, 280-1, 284-5, 289, 302-

3, 334-5, 360

Release Management 357, 361, 365

reliability 105, 134, 198-9, 202, 209, 211-13, 218-20, 224-5, 295, 325-6, 340, 356


385

resilience 209, 212-13, 219, 224

resolution 62, 101, 181, 196, 198, 219, 228, 238, 242, 271, 368

resources 35, 62-3, 87-8, 104-7, 121-2, 132, 135, 137-40, 180, 227-31, 250, 252, 279-80, 309, 323, 343

response 19, 64, 102, 112, 123, 179, 184, 204, 256-8, 269, 312, 314, 328

responsibilities 23-4, 53-4, 61, 67-8, 83-6, 132, 167-8, 183-5, 247-8, 257-8, 311-13, 317-19, 321, 323,

329-32, 347-8

review 67, 120, 136-8, 142, 171, 178-83, 185, 217, 237, 255-6, 269-70, 286, 328-30, 332, 347-8

revision 67, 136-7, 142, 145, 193, 217, 237, 255, 269-70, 281, 286

RFCs (Request for Change) 64-5, 85, 134, 319, 365, 367

rights 30, 38-41, 50, 52

risk assessments 78, 81, 111, 117, 194, 225, 245, 248-50, 254, 256, 258-61, 269, 274, 329, 333, 341

risk management 67, 137, 149, 198, 209, 215, 246, 264, 269, 277, 326, 351, 366

risks 35-6, 40, 47-8, 133-4, 140, 146-7, 215-17, 245-6, 249-50, 257-8, 268-70, 273-4, 281-3, 326-7, 350-

2

roles 19, 22-4, 34-5, 49, 51, 53-4, 58, 67, 85-6, 93, 313, 315-18, 331-2, 335-6, 340, 347-8

S

scenario 18-19, 334

schedules 68-9, 71, 85, 87, 104-6, 113, 115, 130-1, 141, 172, 198, 225, 233, 238, 256, 269

SCMIS 87, 280-1, 284-5, 291

scope 29, 62, 67, 76, 93, 95, 120, 131, 134, 144-5, 154, 168-70, 195-6, 198, 246

security 42, 70, 78, 105, 124-5, 170, 177, 187, 214, 220, 257, 262-3, 265-7, 269-75, 328-9, 356

386



security controls 86, 265, 267, 269, 277, 329

security policies 66, 110, 267, 269-70, 272-4, 277-8, 299

security requirements 210, 212, 264-5, 268-9, 271-2, 296

security risks 148, 265, 267, 328

senior management 24, 72, 164, 221, 268, 272-4, 289, 310, 331, 345

servers 52, 105, 134, 227, 230-1, 233, 362, 364

service acceptance criteria 68, 81, 84

Service Asset 155, 159, 218

Service Asset and Configuration Management 69, 161, 165, 257, 271, 320

service assets 39, 60, 155, 172

service availability 62, 170, 179, 196-7, 200, 208, 211, 245, 265, 273, 278, 292, 326, 329, 351

service being 37, 121, 275

service catalog 46-7, 65-6, 69, 89, 119, 153-66, 168, 174, 176, 184, 284, 319, 324-5, 335, 342, 366

Service Catalog Management 129, 153, 155, 159-62, 164-6, 187, 197, 316, 321, 324

service charges 90, 288, 293

service charters 60, 64, 73, 84, 87, 143, 151, 161, 324

service components 76, 88, 98, 119, 158-9, 163, 167, 178-9, 211-12, 218, 236, 254

service continuity 58, 159, 198, 246, 256, 328, 330, 358, 368

Service Continuity Management 69, 144, 187, 192, 198, 219, 244-5, 255, 257, 259-60, 271, 316, 322,

326-7, 358

service continuity plans 110, 245, 257, 328

service costs 90, 249, 332, 335, 342

service definitions 10, 75, 119, 154, 156, 159-60, 164-5, 288


387service delivery 49, 51, 59, 102, 163, 172-3, 180, 183, 191, 193, 249, 280, 285, 288, 319

service design 21-2, 56-62, 64-8, 72-3, 75-9, 81-5, 93, 115-20, 126-7, 129-38, 140-1, 143-6, 148-52,

323-4, 348-53

Service Design (SD) 21-4, 56-62, 64-8, 72-88, 90-4, 98-100, 110-12, 114-20, 126-46, 148-52, 192-6,

314-18, 320-4, 342-5, 348-53

service design activities 79, 117, 145, 150, 152, 242, 324, 352

Service Design Inputs and Outputs 8-9, 64, 110

SERVICE DESIGN INTERMEDIATE LIFECYCLE CERTIFICATION KIT BOOK 18, 24, 26, 28, 30, 34, 38, 40,

42, 44, 46, 48, 50, 52, 54, 58

service design package (SDPs) 58, 64-7, 72, 81, 83-4, 86, 117, 130, 132-3, 137-9, 142-3, 145-6, 148-51,

193, 324

service design packages 64-7, 72, 81, 83-4, 86, 117, 130, 132-3, 137, 139, 142, 145, 148-51, 353

service design processes 21, 74, 129-33, 145, 320-1, 345, 352

service design stage 61-2, 130, 144, 177, 187, 352

service desk 34, 52, 54, 79, 100-1, 118, 162, 174, 179-80, 185, 199, 272, 296, 311, 362, 366-7

service environment 94, 129, 139, 146, 171, 175, 247, 302, 307

service failures 207, 214-15, 220

service improvement projects (SIPs) 110, 170, 182, 204

service incidents 62, 202, 207, 220

service information 218, 238, 270, 287

service interruption 207, 211, 213, 221

service level agreements 22, 58, 68, 80, 101, 167-70, 172-6, 178, 192, 222, 235, 290, 293, 343, 366

service level management 28, 51, 68, 74, 129, 144, 167-74, 176, 182-95, 201, 238, 260-1, 286-7, 320-

4, 366-7

388



Service Level Management (SLM) 28, 51, 68, 74, 129, 167-74, 176, 180, 182-95, 201, 237-8, 260-1,

286-7, 320-4, 366-7

service level management process 168-9, 171, 193

service level requirements 58, 67-8, 78, 85, 87-8, 144, 167, 169, 173, 175-7, 187, 192, 235, 324, 343

service level targets 85, 108, 167, 170-2, 178, 181, 192, 358, 361

service levels 62, 72, 107-8, 167-9, 171, 175, 181, 185, 188, 194, 230, 236, 289, 324-5, 332, 334

service lifecycle 20, 30, 36, 54, 56, 59, 67, 72, 78-9, 83, 88-9, 132-3, 140, 144, 149

service lifecycle stages 61, 63-5, 73, 83, 133, 140, 195

service management 16, 22-4, 26, 29, 34, 49, 60, 68, 77, 80, 167, 170, 294, 312, 337, 341

service management processes 59, 68, 80, 82, 129, 143, 153-5, 159, 161, 164, 169, 207-8, 243-4, 291-

2, 344, 352

service management system 85, 87, 98, 131, 151

service models 58, 60, 64-5, 73, 84, 130, 139

service monitoring 178, 225, 239

service operation 30, 51-2, 56, 60-2, 64-6, 72-3, 119, 192, 195, 197, 201, 217, 232, 285, 335

service organization 23, 25, 107

service owner 35, 138, 317, 319-20, 323, 341

service packages 41-3, 45-6, 64, 156-7, 174, 179, 181, 192

service performance 58, 104, 179, 187, 228-9, 235, 305

service pipeline 46, 89, 128, 138, 154, 298

service portfolio 46-7, 60, 64-5, 73, 78, 84, 87-90, 110, 117, 127-8, 153-4, 162, 165-6, 184-6, 324-5,

342-3

service portfolio management 143, 153, 159, 161, 165, 182, 287, 292, 321


389

service provider 46-7, 57, 77, 102-3, 105-6, 109, 118-20, 154-6, 167-9, 171-3, 175-82, 204-8, 279-83,

296, 358-9, 366-7

service provider organization 68, 170, 280, 288

service quality 58, 63, 96, 102, 116, 169, 171, 346, 352

service reports 65, 194, 325

Service Request 155, 366-7

service requirements 66, 106-8, 116, 127, 138, 143, 150, 173, 184, 192, 221, 229, 293, 295

service review meetings 180, 185, 188

service reviews 11, 172-3, 181-2, 193, 201, 325

service scope 112, 169, 173, 182, 193, 285

service solutions 76, 81-2, 84, 86, 96, 99, 111-13, 126-7, 132-4, 136, 138, 150, 304

service strategy 30, 36, 41, 48, 56-62, 64-5, 72-3, 75-6, 84, 113, 121, 129-30, 143-4, 163, 323-4

service targets 171, 178, 180, 194, 196-7, 209, 218, 232, 235

service transition 19, 30, 56, 60-1, 64-5, 72-3, 83-4, 86, 130, 132, 142-3, 178, 217, 285, 324

Service transition plans 67, 110, 142

service unavailability 219-20, 273

Service Validation 70, 144, 152

service value 40-2, 133

service warranty 42, 161, 180

serviceability 199, 211, 215, 224-5, 325, 356

services

agreed 145, 173, 188, 357

core 43, 157, 181, 223

390



delivered 57, 107, 126, 263

delivering 39, 187, 227

existing 66, 78-9, 85, 108, 116, 118-19, 154, 163, 178, 197, 199, 209, 325-7

improving 92, 198, 285, 345

operational 169, 188, 197, 201, 324

providing 45, 102, 343

restore 202, 220, 225

retired 46, 109, 116

shared 119, 148, 165, 174

supplied 107, 285, 287, 291

supporting 43, 80, 90, 154, 174, 197, 272, 287, 292, 329-30

services being 22, 161, 163, 324

set 34, 36, 54, 58, 75, 95-7, 103, 112, 138, 158, 171, 181, 296-8, 329-30, 344-5, 357

SFA (service failure analysis) 207-8, 211, 226, 260

SIPs (service improvement projects) 110, 170, 182, 204

site 177, 246, 251

skills 24, 36, 67, 86, 110, 120-1, 123-4, 146, 198, 208, 241, 249, 259, 279-80, 294, 346

SKMS (Service knowledge management system) 61, 64-6, 73, 87-8, 162, 166, 189, 234, 268, 284, 335

SLA framework 174, 176, 187, 192-3

SLA reviews 182, 186, 188, 329

SLA targets 169, 187, 325-7

SLAs (Service Level Agreement) 22, 68-71, 167-70, 172-6, 178-9, 185-6, 188-9, 192-3, 197, 222-3, 235,

239-40, 256-7, 324-6, 329-30, 366-7


391

SLRs (Service level requirements) 58, 67-9, 71, 78, 85, 87, 90, 110, 144, 167, 169, 173, 175-8, 185-7,

190, 324-5

SMIS (Security management information system) 87, 127, 270, 291

SOA (Service-oriented architecture) 118-19, 242, 304

software 45, 75, 103, 112, 190-1, 222, 241, 266, 279, 301, 325, 331, 338, 360-1, 363, 365

software components 69, 279, 281

solutions 57-8, 82, 103, 111-12, 121, 131, 134, 139-40, 148, 158, 217, 253, 269, 275, 296-7, 332-3

sourcing 121, 124-5, 311

SPOF (Single Point of Failure) 210, 213-14, 367

staff 23-4, 32, 37, 72, 79, 101, 147, 162-3, 231, 233, 248, 257, 262, 290, 350, 352

stakeholders 23-4, 34, 48-9, 69, 109, 146, 173, 184, 253, 317, 325, 347

standards 29, 34, 61, 93, 101, 110, 113-14, 119, 126, 132, 137, 139-40, 149-50, 176, 282, 333

start 19, 157, 189, 207, 231-2, 343-4

state 60, 120, 164, 345, 347

strategies 58-9, 63-4, 75, 92-3, 110-11, 139, 142-3, 183-6, 216-18, 237-8, 247-8, 250-1, 258, 261-2,

267-70, 330-1

structure 26, 30, 76, 86, 91, 125, 158, 172, 176, 195, 248, 251, 269, 285, 311-12, 314

supplier agreements 169-70, 173

supplier contracts 280, 286-7

supplier management 13, 51, 70, 74, 129, 145, 170, 187, 192, 265, 272, 279-82, 284, 286-93, 322-3,

329

supplier management process 79, 183, 279, 284

supplier performance 280-1, 284, 288, 292

supplier relationships 281, 283-5

392



supplier strategy 110, 282, 284, 292

suppliers 24, 67, 78, 80, 86-7, 112, 122, 130, 145, 241, 255-6, 265-6, 279-92, 322-3, 329, 358-9

support services 157, 229, 255

Supported business processes 85, 108, 298

systems 60, 66, 77-8, 87, 90-2, 94, 96-7, 100, 148-9, 175-7, 247, 263-5, 274-5, 326-7, 331-3, 335

T

teams 34, 54, 92, 96, 129, 208, 315, 317-18, 335

technical teams 103, 170, 177-8, 190, 195, 311, 340

technology 22-3, 26, 41, 54, 75, 95, 107, 113, 136, 211-12, 239-42, 330, 332, 335, 346-7, 363

technology architectures 31, 81, 94

templates 98, 141, 176, 304

Term Definitions 25-6, 356-68

tests 18, 70, 88, 144, 198, 217, 253-5, 364

threats 215, 249, 343, 366

time 26, 33, 36-7, 98, 101, 104-6, 121-3, 146-8, 181-2, 188, 202, 205, 207, 220, 254, 353

timescales 67, 85, 113, 347, 351

tools 20, 30, 34, 53, 59, 67, 76, 78, 81, 87, 95, 97, 240, 333-8, 341-2, 346-7

transactions 203, 205, 309

transition 56, 59, 61-2, 65, 79, 81, 84, 121-2, 131, 137, 144, 154, 158, 209, 218, 230

tuning 235-7, 327

types 61, 77, 91, 97, 100, 105, 108, 116, 128, 172, 179, 182-3, 192-3, 214, 335, 341-2


393

U

unavailability 162, 204-5, 218, 220, 222-3, 254, 325

Underpinning Contract (UC) 65-6, 80, 169, 173, 178, 182, 186, 188, 201, 220, 237, 280, 283, 293, 325,

367

underpinning contracts 65-6, 80, 169, 178, 182, 186, 188, 201, 220, 237, 280, 283, 293, 325, 329, 367

understanding 18, 20, 36, 49, 60-2, 75, 77-8, 107, 138-9, 141, 158, 176-7, 197-8, 253-4, 296-7, 350

updates 16, 143, 160, 167, 333

upgrades 124, 178, 233, 235

users 32, 37, 49, 61, 70-1, 81, 108, 125, 155-7, 184-5, 188, 212-13, 273, 361-2, 366, 368

utility 65-6, 76, 80, 104-5, 107-8, 132, 141, 169, 171, 192, 195, 251, 279, 282, 301, 315

V

value 22, 34, 37-40, 42, 47, 56-7, 59-60, 62, 75-7, 113, 133, 158, 163, 181-2, 279-80, 300

value chain 76, 125, 200, 213, 280-1

Value to Business 133, 155, 172, 199, 230, 247, 265, 282

VBF (vital business function) 66, 200, 203-4, 209-10, 213, 217, 222, 252, 255, 270, 368

vision 64, 75, 345-7

vital business functions 66, 200, 203-4, 209-10, 252, 368

W

warranty 44-5, 65-6, 80, 82, 100, 104-5, 107-8, 113, 132, 139, 169, 174, 192, 195, 245, 279

water 92, 227, 279

workarounds 156, 363, 368

394



Workbook Review Questions 72, 115, 126, 149, 164, 192, 224, 242, 260, 276, 291, 306, 340

amazon simple storage service (s3) - forewords3.amazonaws.com/quint.redwood/sd/itil sd...

Documents