ITSM and TOGAF 9 v0 5

ITSM And TOGAF 9

www.opengroup.org A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 1

ITSM And TOGAF 9

Applying ITSM to a TOGAF Environment

A White Paper by:

Nayan B. Ruparelia

Hewlett-Packard Company.

Salim Sheikh

Independent Consultant.

November, 2009.

ITSM And TOGAF 9


Acknowledgments

The authors should like to thank the following individuals, listed alphabetically,

for their reviews, comments and suggestions:

Charlie Bess, HP Enterprise Services.

Cindy de la Cruz, HP Enterprise Services.

Dave Eley, HP Enterprise Services.

Harry Hendrickx, HP Enterprise Services.

Linda Fernandez, HP Enterprise Services.

Saverio Rinaldi, HP Enterprise Services.

ITSM And TOGAF 9


Copyright © 2009 The Open Group

All rights reserved. No part of this publication may be reproduced, stored in a

retrieval system, or transmitted, in any form or by any means, electronic,

mechanical, photocopying, recording, or otherwise, without the prior

permission of the copyright owners.

FOR ARCH FORUM ONLY: This White Paper is an informational

document and does not form part of the TOGAF documentation set. Readers

should note that this document has not been approved through the formal

Open Group Standards Process and does not represent the formal consensus

of The Open Group Architecture Forum.

The definitive version of this document is available at

www.opengroup.org/bookstore/catalog.

Boundaryless Information Flow™ and TOGAF™ are trademarks and Making

Standards Work®, The Open Group®, UNIX®, and the “X” device are

registered trademarks of The Open Group in the United States and other

countries. All other trademarks are the property of their respective owners.

All other brand, company, and product names are used for identification

purposes only and may be trademarks that are the sole property of their

respective owners.

Document Title

ISBN No.: ISBN

Document No.: Doc. No.

Published by The Open Group, Month, Year

Any comments relating to the material contained in this document may be

submitted to:

The Open Group

44 Montgomery St. #960

ITSM And TOGAF 9


San Francisco, CA 94104

or by email to: [email protected]

mailto:[email protected]

ITSM And TOGAF 9


Table of Contents

Executive Summary 7

Introduction 8

Purpose ............................................................................................................... 9

Scope ................................................................................................................ 10

Target Audience ............................................................................................... 10

ITSM and ITIL 11

The Role of ITIL in ITSM ................................................................................ 11

ITIL3 Overview ................................................................................................ 13

Enterprise Architecture and TOGAF 17

The Role of TOGAF In Enterprise Architecture .............................................. 17

Review of TOGAF 9 ........................................................................................ 17

ITIL and TOGAF 20

The Role of ITSM in TOGAF 9 ....................................................................... 21

The Role of ITIL in TOGAF 9 ......................................................................... 21

ITIL Service Life Cycle and TOGAF ADM .................................................... 22

Service Orientation ........................................................................................... 23

ITIL as a TOGAF Viewpoint ........................................................................... 24

ITIL CMDB and TOGAF Enterprise Continuum............................................. 24

Recommendations 26

Appendix A: TOGAF ADM 27

Appendix B: Glossary 28

Appendix C: TOGAF 9 And ITIL 3 Mappings 29

About the Authors 38

About The Open Group 39

ITSM And TOGAF 9


ITSM And TOGAF 9


Boundaryless Information Flow

achieved through global interoperability

in a secure, reliable, and timely manner

Executive Summary

This whitepaper considers the alignment of ITSM within a TOGAF aligned

enterprise. A key driver for having such an alignment is to remove the business

execution silos that come to exist in an enterprise when implementing projects that

fall under either ITIL 3 or TOGAF 9. At a high level, we propose to remove such

silos by creating a mapping between the two frameworks as well as between ITSM

and TOGAF 9. This should create a standard set of artifacts or standard interfaces

between those artifacts so that an enterprise may have a common platform for both

service management and enterprise architectures. Such commonality is best

implemented at the initial requirements establishment phase of an initiative and so the

necessary information sharing and processes should be in place at the outset.

Our recommendation is for this to happen within the wider TOGAF 9 context where

ITIL 3 can be considered as an integral extension of enterprise architecture. This is

achievable because there is a lot of synergy between ITSM’s ITIL 3 and the TOGAF

9 framework, especially since TOGAF 9 has shifted to a more service-orientated

approach to Enterprise Architecture.

ITSM And TOGAF 9


Introduction

IT practitioners have learned to look at a business as a set of challenges that

must be embraced and managed, rather than a series of technology puzzles

that need to be solved. A sound strategy is essential for the creation of high

quality IT services to address business needs. A recent Gartner study

reports that the business context should be used to help drive other

complementary efforts in order to deliver or recognize real business value1.

By coupling IT Service Management (ITSM) and The Open Group

Architecture Framework (TOGAF), organizations have an opportunity to

harmonize their services and achieve the alignment of business and

technology goals.

Combining ITSM within a TOGAF context provides a toolkit for delivering

this vision. This is because ITSM provides a framework that guides the IT

practitioner in the delivery of IT services; on the other hand, TOGAF

provides a methodology and framework that guides Business and IT

stakeholders for transforming IT across an organization. Furthermore,

collaboration via integrated toolsets should help in developing and

maintaining a consistent view of the enterprise processes and services (as

part of an Enterprise Architecture) and IT Processes and Services (as part of

ITSM). This approach should provide all stakeholders, typically involved in

enterprise-wide transformation programs, with a shared view to make more

informed decisions and choices around Business and Technology

roadmaps, operating models, target architectures and governance. The

benefit this provides is that all stakeholders in an organization will be better

able to collaborate, in a more effective manner, when delivering large-scale

transformation or business change as part of a single program of work

rather than through siloed projects that run the risk of not being aligned to

the business goals.

Enterprise Architecture (EA) and the planning and implementation of ITSM

should happen in a coordinated and integrated manner. As a result, the

target EA and ITSM architectures can be planned and implemented with a

coordinated and integrated method. This coupling allows businesses to

provide highly available services that are cost-effective, scalable and agile;

ITSM is instrumental in addressing these and, when combined with

TOGAF, provides a flexible architecture framework that should facilitate

different business needs in the future.

It is impossible to either control or predict all the factors in a business

environment. The risks as a result of this challenge can translate into

opportunities or challenges depending on the alignment between service

management capabilities and the emergent needs of customers. This

alignment is best served through TOGAF which provides a detailed

1 Betsy Burton, Philip Allega, Anne Lapkin, Gartner Research, November 2009; 'Business Context' and

'Business Architecture' Are Not the Same.

By coupling ITSM and

TOGAF, organizations

have an opportunity to

harmonize their services

and achieve the

alignment of business and

technology goals

ITSM And TOGAF 9


framework to develop an organization’s Enterprise Architecture. When

combined with TOGAF, ITSM has the following benefits.

Enables IT services to be designed and delivered in-line with

business service level requirements.

Focuses IT services and resources on those areas which the

business thinks are important.

Provides a clear business engagement model to handle

incidents, requests and changes.

Provides a clear service level model - both parties to the

service level and operational agreements have a better and

clearer view of their roles and responsibilities as well as the

level of service required.

Provides a control framework - specifies targets against which

service quality can be measured, monitored and reported.

Encompasses all types of change.

Serves to improve the relationship with the business customer.

We map, at a high-level, the processes, artifacts and phases between the

two frameworks as a mechanism to align ITIL 3 and TOGAF 9. In a way,

this whitepaper can be viewed partly as creating a mapping of the

taxonomies between ITIL and TOGAF. But it is important to outline the

taxonomy related to services because both are increasingly becoming

service-oriented. Generally, everything can be thought of as a service with

the distinction being that ITSM and ITIL tend towards operational services

whilst TOGAF tends to be more aligned to transformational and delivery

services. In this context, an ITIL service is a set of capabilities that is

provided to a customer and is underpinned by a service-level agreement; in

TOGAF, a service represents a self-contained and repeatable logical

business activity that has a specified outcome (for example, check

customers’ creditworthiness, provide alerts, consolidate financial reports).

Appropriately, this eases our taxonomy mapping because we consider a

TOGAF service to encompass an ITIL service since, in a broader sense, we

view the ITIL service as a business activity that is self-contained and

repeatable.

We start the paper by providing a review of ITSM and TOGAF in a broader

context and follow that with a review of ITIL 3. Thereafter, we discuss how

ITSM should align with TOGAF and conclude with a mapping between

ITIL 3 and TOGAF 9.

Unless warranted otherwise, we refer to ITIL 3 as ITIL and TOGAF 9 as

TOGAF throughout this paper. Acronyms that we use in this paper have

been listed in Table 2 as provided in the Appendix.

Purpose

The purpose of this whitepaper is not to tender recommendations for

improving TOGAF; rather, it is to consider EA best practices for the

application of ITSM principles generally, and ITIL 3 specifically, in a

Generally, everything can

be thought of as a service

with the distinction being

that ITSM and ITIL tend

towards operational

services whilst TOGAF

tends towards

transformational and

delivery services.

The purpose of this

whitepaper is to provide

best practices in applying

ITSM, and ITIL 3 in

particular, in a TOGAF 9

environment.

ITSM And TOGAF 9


TOGAF 9 environment. Allied to this, a more general purpose is to

compare Enterprise Architecture with ITSM. However, because ITIL is

presently the de facto standard framework for ITSM, it is considered in this

paper in exclusion of other ITSM frameworks.

TOGAF 9, when compared to TOGAF 8, provides new material such as

capability‐based planning, security architecture and Service Oriented

Architecture (SOA). It also shows in detail how the Architecture

Development Method (ADM) addresses other IT governance domains such

as Risk management, Operations management, Project and Portfolio

management, and Service Management. This paper therefore extends earlier

work done in mapping between ITIL 2 and TOGAF 8.

Scope

The scope of this paper is ITSM and TOGAF. In this regard, we consider

ITIL 3 and build upon previous work that looked at the mapping of ITIL 2

with TOGAF 82.

Target Audience

This whitepaper is intended to be used by anyone involved in the planning,

consulting, implementing or testing of ITIL 3 in relation to a TOGAF 9

framework.

2 Serge Thorn; Merck, June 2007. An Open Group whitepaper that defines the mapping between ITIL v2

and TOGAF v8.

This whitepaper is

intended for those

involved in planning,

consulting, implementing

or testing ITIL 3 within a

TOGAF 9 context.

ITSM And TOGAF 9


ITSM and ITIL

The origins of service management are in traditional service businesses

such as airlines, banks, hotels and telephone companies. Its practice has

grown with the adoption by IT organizations of a service-oriented approach

to managing IT applications, infrastructure and processes.

IT Service Management (ITSM) is increasingly used to address business

needs for the strategy and operations of IT systems. It offers a model of

capabilities, functions and processes for providing value to customers

through services. These capabilities take the form of functions and

processes for managing services over their lifecycle. Furthermore, ITSM

focuses on strategy, design, transition, operation and service improvement.

In this section, we consider the role that ITIL plays within ITSM and

provide a summary review of the ITIL 3 framework.

The Role of ITIL in ITSM

IT organizations are faced with rapidly evolving environments where

standardization of optimal systems and procedures is a critical success

factor in achieving high quality customer service. To address these IT

service management challenges, The Information Technology Infrastructure

Library (ITIL) was developed by the UK's Office of Government

Commerce (OGC). ITIL is now supported by ISO/IEC 20000 (previously

BS 15000) and is the de facto world-wide standard for IT service

management (ITSM). It is now in its third version, which emphasizes the

alignment of IT to the business.

While ITIL 2 was focused on the operational processes of IT, ITIL 3

introduces the concept of the Service Lifecycle which consists of five books

(or stages), as follows:

1. Service Strategy

Covers the reason WHY the IT service is needed, and to what extent

the service would be needed by the customers.

2. Service Design

Design consideration and Quality criteria for the Service that is to be

created AND the environment that is required to support the service

to the customer’s needs.

3. Service Transition

Control and risk mitigation strategies while the new – or changed –

service is moved into the Production environment.

IT Service Management is

increasingly used to

address business needs

for the strategy and

operations of IT systems.

ITSM And TOGAF 9


4. Service Operations

Activities and departments that are needed to support the IT Services

on an ongoing basis to the standards that have been agreed upon with

the customer.

5. Continual Service Improvement

This comprises of methodologies for the ongoing improvement of

the services, the IT environment and its processes.

These five ITIL books are related to each other in the form of a continually

improving cycle that consists of service design, service transition and

service operation as the cycle components with service strategy forming the

hub, as Figure 1 shows.

I

ITSM advocates the principles of aligning IT service delivery to business

objectives. It includes the need to negotiate service and operational level

agreements with business departments. These agreements are monitored

regularly to measure customer (internal or external) satisfaction levels. By

defining service and operational level agreements in terms of business

success and describing them in ways that reflect the shape of the business –

not the IT infrastructure – ITSM aligns IT with the Business.

In summary, ITIL 3 is a standard for the implementation of ITSM and it has

become the de facto standard having gained wide currency within IT

organizations.

Figure 1:

ITIL 3 Books

ITSM And TOGAF 9


ITIL3 Overview

The five ITIL books may be considered in terms of the activities they

provide and the inputs that drive them, as Figure 2 shows.

The five ITIL books are described below in terms of their key service

components as well as the service lifecycle.

Service Strategy

Service Strategy provides guidance on the principles underpinning the

practice of service management with respect to developing service

management policies, guidelines and processes across the ITIL Service

Lifecycle. Supporting practices of Service Strategy are:

1. Demand Management

This promotes reduced demand for services in terms of incentivizing

users to reduce their demand of IT services.

2. Financial Management

This includes the accounting, charging and collection of fees for the

use of IT services.

3. Service Portfolio Management

This is the management of a catalogue of planned, existing and

retired services.

4. Risk Management

Figure 2:

ITIL 3 Service Lifecycle and

Related Artifacts

ITSM And TOGAF 9


This identifies, evaluates and determines responses to risks.

The Service Design Package is an artifact that is created at this stage; it

defines the service’s composition through each stage of the service

lifecycle. Its key components are, as Figure 2 shows, the Statement of

Requirements (SLAs, OLAs, and Contracts), the Acceptance Criteria, the

Service Level Requirements and the Targets.

Service Design

Service Design provides the design of a new or modified service in order to

make it ready for the Service Transition stage. At the Service Design stage,

service requirements are defined, a service solution is designed, service

suppliers are evaluated and services assets are integrated into a service.

Supporting processes are:

Service Level Management

Ensure that IT customers – both internal and external –

receive an agreed level of service.

Service Catalogue Management

Manages and provides an accessible service catalogue.

Supplier Management

This manages service provides and ensures that they

conform to service level targets.

Availability Management

Availability is the ability of an item to perform its function

when required and this process analyses and plans activity

related to availability.

Capacity Management

Analysis and planning of performance and capacity related

activities.

Information Security Management

This aligns IT security with Business security.

IT Service Continuity Management

This ensures that services continue to operate in compliance

with agreed plans.

The scope of Service Design is not limited to new services, but includes the

changes and improvements necessary to increase or maintain value to

customers over the lifecycle of services. Key factors towards achieving this

goal are the continuity of services, maintenance of service levels, and

conformance to standards and regulations.

Service Transition

Service Transition provides guidance for the development and improvement

of capabilities for transitioning new and changed services into live service

operation. Primarily, this stage plans all the activities that must be

performed in order to transition the service from design to production. An

Service Design is not

limited to new services,

but includes the changes

and improvements

necessary to increase or

maintain value to

customers.

ITSM And TOGAF 9


overall framework is provided within this stage to assess whether the

service is in an acceptable state for it to proceed to production.

Processes that support the Service Transition stage may be categorized into

two groups: enabling processes and informational processes. The former

comprises of the evaluation process, change management, release

management, and service validation. The latter comprises of knowledge

management, asset management and configuration management.

Service Operation

Service Operation embodies practices in the management of the day-to-day

operation of services. Strategic objectives are ultimately realized through

Service Operation, therefore making it a critical capability. Guidance is

provided on how to maintain stability in service operations, allowing for

changes in design, scale, scope and service levels. These then form

requirements for the next lifecycle as inputs to its Service Strategy stage.

Processes that support this stage are:

Incident Management

This concerns the restoration of service operations to users

as rapidly as possible.

Problem Management

This relates to the analyses and diagnosis of root causes of

incidents and ensures that changes are requested to resolve

those root causes in order to reduce the number of future

incidents.

Request Fulfillment

Requests for information and service requests are handled

by this process.

Access Management

This provides appropriate rights to a user to access a

service.

Event Management

This identifies and resolves system events that represent

failures within configuration items.

The first four processes in the list above constitute the processes of a

service desk, as they relate to users of services directly whereas Event

Management relates to failures in configuration items.

Continual Service Improvement (CSI)

During this stage, data and feedback from the various users and

stakeholders is gathered and analyzed with the purpose of providing

recommendations and implementing them. A seven-step improvement

process for doing this is adopted and all service improvement

recommendations are scrutinized in terms of whether they fulfill business

needs and provide an overall return on investment. Supporting processes for

Strategic objectives are

ultimately realized

through Service

Operation.

ITSM And TOGAF 9


this stage are service reporting, service level management, service

measurement, return on investment analysis for CSI, and business

alignment questions for CSI.

ITSM And TOGAF 9


Enterprise Architecture and TOGAF

The Role of TOGAF In Enterprise Architecture

Enterprise Architecture (EA) is a capability that aligns an organization’s

processes, information systems and personnel with its business goals and

strategic direction. It forms the technical foundation for the enterprise’s IT

strategy by providing a technology plan for managing the enterprise-wide

IT investment.

There is no shortage of enterprise architecture frameworks. A few of the

better known ones include the Zachman Framework, the Department of

Defense Architecture Framework (DODAF), the Federal Enterprise

Architecture Framework (FEAF), Enterprise Architecture Planning (EAP)

and TOGAF. Each of these enterprise architecture frameworks is supported

by an extensive knowledgebase and a few of them have been mapped to

their competitive frameworks.

Just as ITIL has become the operations standard for service management

and COBIT is established for good IT governance, so TOGAF is

increasingly becoming a standard framework for architecting technology

and business change. Around a third of organizations now favor the

standard processes that TOGAF describes for creating architectures.

Review of TOGAF 9

TOGAF 9 was released in February 2009 and has evolved from earlier

versions of the framework to be better aligned to business needs than its

predecessors. This means that the approach to viewing IT has also evolved:

instead of considering IT as comprising of hardware and software

components, it is considered in terms of the lifecycle management of

information and related technology within an organization. Thus, greater

emphasis is placed on the actual information, its access, presentation, and

quality, so that it can provide not only transaction processing support, but

analytical processing support for critical business decisions.

The Architecture Development Method (ADM) is a major component of

TOGAF and it provides guidance on the lifecycle of enterprise architecture

in terms of phases. These phases are reviewed below succinctly.

ITSM And TOGAF 9


Preliminary Phase

The Preliminary Phase provides guidance on establishing an enterprise

architecture framework and planning for architecture development.

Additionally, it discusses how TOGAF relates to other operational or

delivery frameworks such as ITIL, COBIT and PMI.

Phase A - The Vision Phase

This phase emphasizes the readiness of an organization to undergo change.

The steps in the list below constitute this phase:

Establish the Architecture Project

Identify Stakeholders, Concerns, and Business Requirements

Confirm and Elaborate Business Goals, Business Drivers, and

Constraints

Evaluate Business Capabilities

Assess Readiness for Business Transformation

Define Scope

Confirm and Elaborate Architecture Principles, including

Business Principles

Develop Architecture Vision

Define the Target Architecture Value Propositions and KPIs

Identify the Business Transformation Risks and Mitigation

Activities

Develop Enterprise Architecture Plans and Statement of

Architecture Work and Secure Approval

The Vision phase maps to ITIL’s Service Strategy stage or book.

Phases B to D

Phases B to D are, respectively, the Business Architecture, Information

Systems Architecture (Application and Data Architectures), and

Technology Architecture phases. These are collectively known as the

Design phases, and have the following common steps:

Develop Baseline Architecture Description

Develop Target Architecture Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the Architecture Landscape

Conduct Formal Stakeholder Review

Finalize the Architecture

Create Architecture Definition Document

Phases B to D share the same scope, and map to the Service Strategy phase

because they set the overall design of the enterprise. These design phases

TOGAF ADM’s design

phases map to ITIL’s

Service Design stage.

ITSM And TOGAF 9


map to ITIL’s Service Design stage when the Service Design stage

represents a component of an enterprise capability.

Phases E and F

Phases E and F are the Opportunities & Solutions phase and the Migration

Planning phase respectively. They feature a detailed method for defining

and planning enterprise transformation based on the principles of

capability-based planning. These phases allow an organization to generate

an overall implementation and migration strategy and a detailed

implementation plan.

They map to the Service Strategy, Service Design, depending on the scope

of the service. When the service is at the enterprise level, then they map to

ITIL’s Service Transition stage or book.

Phase G: Implementation and Governance

Enterprise architects compose holistic solutions that address the business

challenges of the enterprise and support the governance needed to

implement them3.

Phase G establishes the connection between architecture and

implementation through an architecture contract that facilitates

implementation oversight and governance. ITIL’s Continual Service

Improvement stage can be a part of this overall Enterprise Architecture

Life-cycle governance process. This phase ensures that the architecture

specifications deliver to the business requirements of the sponsor and

stakeholders. It is at the end of Phase G that the business starts to realize the

business value of the enterprise architecture.

This phase maps to ITIL’s Service Transformation and Continual service

Improvement stages or books.

Phase H: Architecture Change Management

Phase H provides for changes to the framework and principles that were set

up in the Preliminary Phase.

The objective of Phase H is to ensure good housekeeping and best practices

to keep the enterprise architecture up-to-date, fit for purpose and to

continue to achieve its original target business value or business case. It

allows for changes throughout both the development and the operational

lifecycle of the enterprise architecture.

Changes may be needed due to:

Asset management and infrastructure refresh requests.

Business process improvements.

3 Bruce Robertson, Gartner Research, November 2009; EA and ITIL: The Business Architecture of IT.

ITIL’s Service Operation

stage has no mapping to

TOGAF’s ADM;

however, its Service

Continuum maps to the

Enterprise Continuum.

ITSM And TOGAF 9


Reorganizations.

Market and business capacity changes.

Mergers and acquisitions.

This phase maps to ITIL’s Service Design and Service Transformation

stages or books.

Requirements Management

At this phase, requirements are validated against the needs and expectations

of the business for each stage of a project’s lifecycle. Aligning the

architecture definition and implementation to the business requirements

should achieve the business objectives and realize the expected value of the

overall initiative.

ITIL and TOGAF

In order to map the ITIL and TOGAF frameworks, it is important to clarify

some of the definitions first. TOGAF, being an architecture framework,

views architecture in one of two contexts:

1. A formal description of one or more systems that underpin the

processes, information, structure and business of an organization.

2. The structure of components, their inter-relationships, and the

principles and guidelines governing their design and evolution over

time.

In the context of ITIL 3, there is a common ground when considering the

latter architectural context because in ITIL 3 terms, the systems and

operational components of TOGAF may be considered to be ITIL services.

However, the scope of TOGAF is much wider and its concept of a service

much broader than ITIL’s because a TOGAF service represents a self-

contained collection of business functions, IT systems, processes,

capabilities and resources that provide a business outcome or business

value. As a result, we consider ITIL as a TOGAF service or Viewpoint in

this paper.

ITSM And TOGAF 9


The Role of ITSM in TOGAF 9

While TOGAF provides the architecture building blocks to develop an

organization’s Business/IT alignment strategy across the enterprise, ITSM

serves to define some of the key assets, services and operational processes

necessary to implement an evolving Enterprise Architecture. In this regard,

ITSM enables the organization to achieve the following benefits:

reduce costs,

streamline it’s IT processes,

improve the productivity of end-users through services,

improve customer satisfaction of the end-users,

improve management of services at a company-wide level

Figure 3 presents an example of how ITSM may be incorporated into an

organization in practice based on the principles of ITIL 3. Each of the

processes shown in the figure can be established by the ADM mappings

discussed earlier in this section. Further, by linking ITIL’s Continual

Service Improvement (CSI) stage with the TOGAF Requirements

Management phase, all the enterprise assets can be improved iteratively and

continuously.

The Role of ITIL in TOGAF 9

ITIL’s Service Operations and Service Lifecycle both map to the TOGAF’s

ADM Cycle and Requirements Management.

The high-level mappings between the phases of the TOGAF ADM and

ITIL’s stages are shown in Figure 4. The Service Operation stage of ITIL

Figure 3:

ITSM and TOGAF in the IT Organization

By linking ITIL’s

Continual Service

Improvement stage with

the TOGAF Requirements

Management phase, all

the enterprise assets can

be improved iteratively

and continuously

ITSM And TOGAF 9


has no mapping to TOGAF’s ADM but should have a mapping to the

Enterprise Continuum in terms of the Services Continuum.

We consider the mapping of ITIL processes, stages and artifacts in this

section in terms of three major areas: a) the TOGAF ADM, b) Service

Orientation, and c) the Enterprise Continuum. This is supplemented by

Appendix A, which provides a detailed list of the TOGAF sections that

relate to ITIL.

ITIL Service Life Cycle and TOGAF ADM

ITIL’s Business Requirement Change processes, which form part of the

Service Strategy stage, map to TOGAF ADM’s Preliminary and

Requirement Management phases. As part of the Preliminary phase of

TOGAF, project initiation and preparation activities translate the business

requirements to technical ones, and these activities map to ITIL’s

Requirements Change and Continuous Service Improvement processes.

Phases A and, to some extent the Preliminary phase, of the ADM map to

Service Strategy, the first book of ITIL 3. This aligns the enterprise

objectives, budgets, funding, enterprise strategy and capabilities, and can

also be used to define, prioritize and manage programs.

At the centre of this mapping is the Service Catalogue tool which supports

the creation and publication of service offerings with the following

artifacts.

Figure 4:

High-level Mapping

between

TOGAF ADM and ITIL Stages

ITSM And TOGAF 9


1. Descriptions of service offering features, functions and benefits in

business terms.

2. Supported service levels and available service level options.

3. Pricing and costing defined dynamically with reference to service

levels selected.

4. Included service components.

5. User-defined attributes.

ITIL’s Service Design stage maps to Phases B, C, and D (the development

of architectures) of TOGAF. This enables greater integrity and consistency

of business processes and functions across all three architectures as well as

the standards and guidelines that straddle both frameworks.

ITIL’s Service Transition stage maps to Phases E, F, G and H of TOGAF.

This provides a more agile means of responding to changing demands,

customer needs, and migration strategies.

Operational service improvements occur in ITIL’s Service Operation stage.

However, there is a link between the CSI and Service Operation stages as

they work together to improve operational service plans and operational

services respectively. The output from these stages defines the business

requirements that drive the Service Strategy stage. So both stages map to

TOGAF’s Requirements Management phase because it ensures that

architectural improvement occurs through interaction with all the phases.

Each of the above mappings is managed by the Continuous Service

Improvement phase of the Service Lifecycle. Mapping the Service

Lifecycle to the ADM cycle and the ubiquitous Requirements Management

phase in TOGAF helps to create an efficient Service Portfolio that results in

cost benefits to the internal and external customers of an organization.

Service Orientation

From the ITIL perspective, SOA comprises of repeatable pieces of services

which can be reused across multiple domains and business processes. Like

SOA, ITIL now focuses on services, not just from a development

perspective, but as a continuous process. This enables better governance of

SOA services in an ITIL compliant environment. For instance, Service

Oriented Accounting, which is part of Service Strategy in ITIL, facilitates

financial management of services in terms of consumption and

provisioning.

With TOGAF, SOA is considered a part of the enterprise architecture and

so in that sense, many ITIL artifacts that govern SOA can become part of

the Enterprise Continuum and be governed by the Requirements

Management phase of the ADM.

ITSM And TOGAF 9


ITIL as a TOGAF Viewpoint

A TOGAF Viewpoint provides a perspective of the architectural model and

documents. A viewpoint consists of several views, and every view has an

associated viewpoint that describes it. Views are abstractions, or

simplifications, of the entire design in a manner that some characteristics

are made more visible by leaving details aside. TOGAF has a number of

Viewpoints, some of which are shown categorized in Figure 5.

The Requirements Viewpoint is related to the Business and Technology

domains from two perspectives: operational (for ITIL) and delivery (for

TOGAF). The sum total of these views and viewpoints make up an

Enterprise Architecture domain. The next two Viewpoints of Figure 5 are

delivery related and, for TOGAF, map to artifacts created in Phases B, C,

and D of the ADM. The Operational Viewpoint is added as specific to ITIL.

Four ITIL stages are used to provide Views within the Operational

Viewpoint. The Validation Viewpoint is made up of two conjoined Views:

the Test View (for TOGAF) and the Continual Service Improvement View

(for ITIL). On the basis of our ADM to ITIL mappings, as discussed in the

previous section, a data flow mapping is creating between the various

Views.

ITIL CMDB and TOGAF Enterprise Continuum

The ITIL Configuration Management Database (CMDB) and, at a broader

level, the ITIL Service Knowledge Management System (SKMS) can be

aligned with the TOGAF Enterprise Continuum or Enterprise Architecture

Figure 5:

TOGAF Views and Viewpoints

ITSM And TOGAF 9


Repository (EAR). This should include integration of the Service Catalogue

and would support all ITSM services and processes.

The CMDB is the repository which supports ITIL services from an

operational perspective. An Enterprise Architecture Repository (EAR) is

used during the architecture development process to store Architecture

Building Blocks (ABBs) and Solution Building Blocks (SBBs). Services

are described by a Configuration Item (CI) and are maintained in the

CMDB. The Enterprise Continuum, being an index of artifacts, can be

extended to include the CMDB and asset database. Furthermore, the EAR,

itself a constituent of the Enterprise Continuum, should be a federated

repository that also includes, under its umbrella, the CMDB and asset

database used by ITIL processes.

By merging the CMDB and the EAR in a federated manner, it is possible to

create holistic and enriched viewpoints of the up-to-date “AS IS”

operational view of the enterprise. A federated repository scheme enables

relevant configuration items from the CMDB to form part of the EAR.

Since the CMDB must be capable of handling thousands of transactions a

day, a distributed or federated integrated repository architecture is

necessary in order to avoid any impact on architecture related transactions.

Further, this federation could be extended to include all types of

repositories that relate to the organization including the CMDBs, SOA

design-time and runtime service registries, SOA management and

monitoring repositories, diagnostics, third party policy and capacity

management engines, and asset repositories, for example. Naturally, the

level of integration and federation between the various repositories will

depend upon the maturity of the organization’s ITSM and EA capabilities

and toolsets.

Practically, having a two-way communication mechanism whereby the

CMDB can pull information from the wider EAR could also facilitate data

exchange between a CI and its associated EA meta-model and service

artifacts. This would enhance the ITSM Knowledge Management System

and would provide a more comprehensive Application and Data integration

perspective based on a holistic view of Enterprise Business Architecture

and Business Models. Consequently, this would provide a much stronger

Enterprise Operations Architecture and IT Operational Management.

Alignment of ITIL with TOGAF in this area can be used to share the

architectural assets of the enterprise architecture, and vice versa, for greater

efficiency in the storage, gathering and use of information. This has the

potential of integrating IT operations with related information artifacts of

the enterprise architecture.

By merging the CMDB

and the EAR, it is

possible to create holistic

and enriched viewpoints

of the up-to-date “AS IS”

operational view of the

enterprise.

ITSM And TOGAF 9


Recommendations

At a high-level, our recommendations for applying TOGAF to ITSM are shown in the mind-map of Figure 6 below. We expect

that these recommendations be applied at the very outset in order to ensure that organizational silos do not exist between the

service management and architecture domains. Further, our vision is for Enterprise Architects to play a key role in determining

this alignment.

Figure 6:

High-level Recommendations

for Applying TOGAF to ITSM.

ITSM And TOGAF 9


Appendix A: TOGAF ADM

The Architecture Development Method (ADM) is at the core of TOGAF. It

offers an iterative approach divided into phases that guide end to end

architecture work.

The concerns of each stakeholder may be considered by addressing their

specific perspectives or viewpoints by creating views from the EAR as

needed, as illustrated by Figure 7.

The ADM is supported by the other main parts of TOGAF:

ADM Guidelines and Techniques (set of guidelines, templates,

checklists)

Architecture Content Framework

The Enterprise Architecture Continuum (typically maintained

by the EAR that stores architecture assets including

descriptions, models, patterns and building blocks)

TOGAF Reference Models

The Architecture Capability Framework

The concerns of each

stakeholder may be

considered by addressing

their specific viewpoints

and creating “views”

from the EAR as needed.

Figure 7:

The TOGAF ADM and the EAR

together help address

stakeholder concerns.

ITSM And TOGAF 9


Appendix B: Glossary

KEY

AMIS Availability Management Information System

ADM Architecture Development Method

CMDB Configuration Management Database

CMIS Capacity Management Information System

CMS Configuration Management System

COBIT Control Objectives for Information and Related Technology

EAR Enterprise Architecture Repository

ITIL IT Infrastructure Library

ITSCM IT Service Continuity Management

ITSM IT Service Management

KEDB Known Error Database

OLA Operational Level Agreement

RFC Request For Change

SCD Supplier Contract Database

SKMS Service Knowledge Management System

SLA Service Level Agreement

SLR Service Level Requirement

SOA Service Outage Analysis

TCO Total Cost of Ownership

TOGAF The Open Group Architecture Framework

ITSM And TOGAF 9


Appendix C: TOGAF 9 And ITIL 3 Mappings

The table below maps sections of TOGAF 9 to the relevant underlying concept or process in ITIL 3.

TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS

CHAPTER SECTION SUB-SECTION

TOGAF 9 CONCEPT

5. Introduction to the

ADM

5.1 5.1.1 The ADM and the Enterprise

Continuum

Architecture Assets

Service Asset and

Configuration

Management

Service Catalog

Management

Architecture repository that

includes reference architectures,

models,

and patterns

Enterprise Continuum Service Asset and

Configuration

Management

CMDB

5.1.2 The ADM and the Foundation

Architecture

Re-usable common

models, policy,

governance definitions

and specific technology

selections

Service Asset and

Configuration

Management

Configuration Items

5.1.3 ADM and Supporting

Guidelines and Techniques

Guidelines, templates,

checklists and other

detailed materials

Service Asset and

Configuration

Management

Documentation

5.2 Architecture Development

Cycle

Service Asset and

Configuration

Management

CMDB

ITSM And TOGAF 9




TOGAF 9 CONCEPT

5.2.2 Basic structure Phases of the ADM

cycle

Service Asset and

Configuration

Management

CMDB

5.4 Architecture Governance Architecture artifacts,

governance repository

Service Asset and

Configuration

Management

Service Level

Management

Service Asset and

Configuration

Mangement

- CMDB

- Service Catalog

5.5 Scoping the Architecture Vertical scope Service Asset and

Configuration

Management

CMDB Scoping

5.5.3 Vertical scope /

Level of Detail

Service Asset and

Configuration

Management

CMDB Scoping

5.5.4 Time Period Service Asset and

Configuration

Management

CMDB Scoping

6. Preliminary Phase Preliminary phase of

ADM

Service Asset and

Configuration

Management

Service Level

Management

8. Business

Architecture

ADM - Phase B

8.2 8.2.2 Developing Baseline

Description

Service Level

Management

Service Catalog

ITSM And TOGAF 9




TOGAF 9 CONCEPT

8.4 8.3.2 Non-Architectural Inputs Service Level

Management

SLAs

9. Information Systems

Architectures

ADM – Phase C

9.3.2 Non-Architectural Inputs Service Level

Management

SLAs, OLAs

10. Information

Systems

Architectures — Data

Architecture

ADM – Phase C

10.2.2 Architecture Repository Service Asset and

Configuration

Management

CMDB content


Management

SLAs, OLAs

11. Information

Systems

Architectures —

Application

Architecture

ADM – Phase C


Configuration

Management

CMDB content


Management

SLAs, OLAs

12. Technology

Architecture

ADM – Phase D

ITSM And TOGAF 9




TOGAF 9 CONCEPT


Configuration

Management

CMDB content


Management

SLAs, OLAs

12.4.3 Develop Target Technology

Architecture Description

Architecture Building

Blocks

Service Asset and

Configuration

Management

Links between ABB

and Services

12.4.4 Perform Gap Analysis Service Level

Management

Service Catalog

12.4.6 Resolve Impacts Across the

Architecture Landscape

Business Impact Analysis

Change Management

Change Advisory

Board

Change Request

(RFC)

12.4.8 Finalize the Technology

Architecture

Service Level

Management

Service Catalog

12.4.9 Create Architecture Definition

Document

Service Level

Management

Service Catalog

13. Opportunities &

Solutions

ADM – Phase E

13.2 Approach Change Management

13.4 13.4.11 Create Portfolio and Project

Charters and Update the

Architectures

Steps Release / Capacity /

Availability

Management

Business Plans

Business SLRs

13.5 Risk Register Impact Analysis Financial Management SOA

TCO

14. Migration Planning ADM – Phase F

14.2 Approach Change Management

ITSM And TOGAF 9




TOGAF 9 CONCEPT

14.4 14.4.2 Assign a Business Value to

Each Project

Steps Release Management Business SLRs

14.4.4 Prioritize the Migration Projects

through the Conduct of a

Cost/Benefit

Assessment and Risk Validation

Steps Financial Management SOA

TCO

14.5 Change Requests arising from

lessons learned

Outputs Change Management

Service Catalog

Management

Change Advisory

Board

15.Implementation

Governance

ADM – Phase G

15.2 Approach Release

Management

15.4 Steps Change Management

15.5 Outputs SLAs Change Management

Service Catalog

Management

Change Advisory

Board

16. Architecture

Change

Management

ADM – Phase H

16.2 Approach Release

Management

16.2.2 Enterprise Architecture Change

Management Process

Change Management RFC

SLAs

OLAs

ITSM And TOGAF 9




TOGAF 9 CONCEPT

16.5 Outputs Architecture Updates,

New requests,

Architecture Contract,

Compliance

Assessments

Change Management

Service Catalog

Management

Change Advisory

Board

17. ADM Architecture

Requirements

Management

17.2 Approach Requirements

Management

Change Management

17.4 Steps Change Management ITIL Change

Management

17.5 Outputs Requirements Impact

Assessment, Updated

Architecture

Requirements

Specification

Change Management

Service Catalog

Management

Business Impact

Analysis

Business SLRs

24. Stakeholder

Management

Financial Management - Accounting

- Investment Analysis

- Charging Policy

- Charging Model

27. Gap Analysis Change Management - Change Impact

Assessment

- Change Financial

Assessment

28. Migration Planning

Techniques

Change Management - Change Impact

Assessment

- Change Financial

Assessment

- Demand

Management

- Business Continuity

Plan

ITSM And TOGAF 9




TOGAF 9 CONCEPT

31. Risk Management IT Service Continuity

Management

- Business Plans

- SLAs

- OLAs

- Service Catalog

32. Capability-based

Planning

Availability Management - Business SLRs

- Service Catalog

- CMDB

37. Building Blocks Opportunity Identification

Building Block Re-Use

Service Asset and

Configuration

Management

CMDB

39. Enterprise

Continuum

IT Service Continuity

40. Architecture

Partitioning

Service Asset and

Configuration

Management

CMDB

41. Architecture

Repository

Service Level

Management

Service Asset and

Configuration

Management

Service Catalog

CMDB

42. Tools for

Architecture

Development

ITSM Tools - CMDB

- DHS

- DSL

- KEdb

- CDB

43. Foundation

Architecture: Technical

Reference Model

ITSM And TOGAF 9




TOGAF 9 CONCEPT

43.1.1 Role of the TRM in the

Foundation Architecture

Service Asset and

Configuration

Management

CMDB

43.1.2 TRM Components Service Asset and

Configuration

Management

CMDB

43.3 TRM in Detail Service Asset and

Configuration

Management

CMDB

43.4 Application Platform —

Taxonomy

Service Level

Management

Service Catalog

SLA/OLA

43.5 Detailed Platform Taxonomy Service Level

Management

Service Catalog

SLA/OLA

44. Integrated

Information

Infrastructure

Reference Model

44.2.1 Derivation of the III-RM from

the TRM

Service Asset and

Configuration

Management

CMDB

44.3 Detailed Platform Taxonomy Service Level

Management

Service Catalog

SLA/OLA

47. Architecture Board Change Management Change Advisory

Board

ITSM And TOGAF 9




TOGAF 9 CONCEPT

49. Architecture

Contracts

IT Service Continuity

Management

- Business Continuity

Management

- Ongoing

Operational

Management

50. Architecture

Governance

Service Level

Management

Change Management

- Business SLRs

- Service Catalog

- CMDB

Glossary Appendix A ITIL Glossary

ITSM And TOGAF 9


About the Authors

Nayan B. Ruparelia is a Chief Architect at HP. Since joining HP in

February 2007, Nayan helped formulate the IT strategy for the merger and

acquisition activities of a leading global bank in his capacity as the

Assistant CTO. Thereafter, he was part of a winning sales bid team that

won a new account for HP with a TCV of $1 billion.

Nayan previously spent 15 years as an independent consultant specializing

in EAI and SOA technologies from their pioneering years in the 1990s. His

assignments varied from a C++ developer to Lead Architect during this

time. Prior to that, Nayan was a Principal Electronics Engineer in the

Aerospace industry for 10 years. He participated in two government-

sponsored workgroups that defined data transmission standards that were

later adopted for use by the entire Aerospace industry across Europe.

Nayan has contributed to a number of publications; the latest being an

article in the September 2009 issue of Microsoft Architecture Journal

documenting the creation of a new SOA pattern. Nayan is TOGAF and

Prince 2 Practitioner certified, and a senior member of the ACM. He earned

his B.Sc. from London University (King’s College) and M.Sc. from

Westminster University.

His blog is at http://archreport.wordpress.com and his profile is available on

LinkedIn.

Salim Sheikh is an Enterprise Architect and Strategist. He is an

independent consultant with 14 years of experience across diverse

industries and provides solutions and advice that relate to technology,

strategy, and governance to help achieve Business-IT alignment. He is

certified in a number of frameworks, including TOGAF, Zachman, COBIT,

and ITIL. In addition, he is a Certified Process Professional and LEAN/Six

Sigma practitioner.

Salim is a member of the Board of Directors for the Centre for the

Advancement of the Enterprise Architecture Profession (CAEAP) – a non-

profit organization that advocates the practice and profession of Enterprise

Architecture.

Recently, Salim was appointed as the Enterprise Architect for Royal

Botanic Gardens, Kew (UK) to direct a 10 year transformation program

which includes delivering an IT and Digital Media strategy.

Salim is writing a series of books and articles on Enterprise Architecture,

SOA and ITIL. His blog is at http://uksheikh.wordpress.com and his profile

is available on LinkedIn.

http://archreport.wordpress.com/

http://www.linkedin.com/in/nayan

http://www.caeap.org/

http://uksheikh.wordpress.com/

http://www.linkedin.com/in/ssheikh

ITSM And TOGAF 9


About The Open Group

The Open Group is a vendor-neutral and technology-neutral consortium,

whose vision of Boundaryless Information Flow will enable access to

integrated information within and between enterprises based on open

standards and global interoperability. The Open Group works with

customers, suppliers, consortia, and other standards bodies. Its role is to

capture, understand, and address current and emerging requirements,

establish policies, and share best practices; to facilitate interoperability,

develop consensus, and evolve and integrate specifications and Open

Source technologies; to offer a comprehensive set of services to enhance

the operational efficiency of consortia; and to operate the industry's premier

certification service, including UNIX system certification. Further

information on The Open Group can be found at www.opengroup.org.

http://www.opengroup.org/