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.

1. ITSM And TOGAF 9
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.
www.opengroup.org A White P aper P ublished by The Open Group 1

2. 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.
www.opengroup.org A White P aper P ublished by The Open Group 2

3. 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
www.opengroup.org A White P aper P ublished by The Open Group 3

4. ITSM And TOGAF 9
San Francisco, CA 94104
or by email to: ogpubs@opengroup.org
www.opengroup.org A White P aper P ublished by The Open Group 4

5. 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
www.opengroup.org A White P aper P ublished by The Open Group 5

6. ITSM And TOGAF 9
www.opengroup.org A White P aper P ublished by The Open Group 6

7. 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.
www.opengroup.org A White P aper P ublished by The Open Group 7

8. 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
By coupling ITSM and complementary efforts in order to deliver or recognize real business value 1.
By coupling IT Service Management (ITSM) and The Open Group
TOGAF, organizations Architecture Framework (TOGAF), organizations have an opportunity to
have an opportunity to harmonize their services and achieve the alignment of business and
harmonize their services technology goals.
and achieve the Combining ITSM within a TOGAF context provides a toolkit for delivering
alignment of business and 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
technology goals
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.
www.opengroup.org A White P aper P ublished by The Open Group 8

9. 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
Generally, everything can level of service required.
be thought of as a service  Provides a control framework - specifies targets against which
service quality can be measured, monitored and reported.
with the distinction being
 Encompasses all types of change.
that ITSM and ITIL tend  Serves to improve the relationship with the business customer.
towards operational
We map, at a high-level, the processes, artifacts and phases between the
services whilst TOGAF two frameworks as a mechanism to align ITIL 3 and TOGAF 9. In a way,
tends towards this whitepaper can be viewed partly as creating a mapping of the
taxonomies between ITIL and TOGAF. But it is important to outline the
transformational and
taxonomy related to services because both are increasingly becoming
delivery services. 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.
The purpose of this 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
whitepaper is to provide
ITSM should align with TOGAF and conclude with a mapping between
best practices in applying ITIL 3 and TOGAF 9.
ITSM, and ITIL 3 in
Unless warranted otherwise, we refer to ITIL 3 as ITIL and TOGAF 9 as
particular, in a TOGAF 9 TOGAF throughout this paper. Acronyms that we use in this paper have
environment. 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
www.opengroup.org A White P aper P ublished by The Open Group 9

10. 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.
This whitepaper is
intended for those Scope
involved in planning,
The scope of this paper is ITSM and TOGAF. In this regard, we consider
consulting, implementing ITIL 3 and build upon previous work that looked at the mapping of ITIL 2
or testing ITIL 3 within a with TOGAF 82.
TOGAF 9 context.
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.
www.opengroup.org A White P aper P ublished by The Open Group 10

11. 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
IT Service Management is capabilities, functions and processes for providing value to customers
through services. These capabilities take the form of functions and
increasingly used to processes for managing services over their lifecycle. Furthermore, ITSM
address business needs focuses on strategy, design, transition, operation and service improvement.
for the strategy and In this section, we consider the role that ITIL plays within ITSM and
operations of IT systems. 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.
www.opengroup.org A White P aper P ublished by The Open Group 11

12. 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.
Figure 1:
ITIL 3 Books
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.
www.opengroup.org A White P aper P ublished by The Open Group 12

13. 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.
Figure 2:
ITIL 3 Service Lifecycle and
Related Artifacts
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
www.opengroup.org A White P aper P ublished by The Open Group 13

14. 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
Service Design is not related to availability.
limited to new services,  Capacity Management
Analysis and planning of performance and capacity related
but includes the changes
activities.
and improvements  Information Security Management
necessary to increase or This aligns IT security with Business security.
maintain value to  IT Service Continuity Management
This ensures that services continue to operate in compliance
customers. 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
www.opengroup.org A White P aper P ublished by The Open Group 14

15. 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
Strategic objectives are provided on how to maintain stability in service operations, allowing for
ultimately realized changes in design, scale, scope and service levels. These then form
requirements for the next lifecycle as inputs to its Service Strategy stage.
through Service
Operation. 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
www.opengroup.org A White P aper P ublished by The Open Group 15

16. 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.
www.opengroup.org A White P aper P ublished by The Open Group 16

17. 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.
www.opengroup.org A White P aper P ublished by The Open Group 17

18. 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
TOGAF ADM’s design
 Identify the Business Transformation Risks and Mitigation
phases map to ITIL’s Activities
Service Design stage.  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
www.opengroup.org A White P aper P ublished by The Open Group 18

19. 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
ITIL’s Service Operation Phase H provides for changes to the framework and principles that were set
stage has no mapping to up in the Preliminary Phase.
TOGAF’s ADM; The objective of Phase H is to ensure good housekeeping and best practices
however, its Service 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
Continuum maps to the allows for changes throughout both the development and the operational
Enterprise Continuum. 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.
www.opengroup.org A White P aper P ublished by The Open Group 19

20. 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.
www.opengroup.org A White P aper P ublished by The Open Group 20

21. ITSM And TOGAF 9
The Role of ITSM in TOGAF 9
Figure 3:
ITSM and TOGAF
in the IT Organization
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,
By linking ITIL’s  improve customer satisfaction of the end-users,
Continual Service  improve management of services at a company-wide level
Improvement stage with Figure 3 presents an example of how ITSM may be incorporated into an
the TOGAF Requirements organization in practice based on the principles of ITIL 3. Each of the
Management phase, all processes shown in the figure can be established by the ADM mappings
discussed earlier in this section. Further, by linking ITIL’s Continual
the enterprise assets can Service Improvement (CSI) stage with the TOGAF Requirements
be improved iteratively Management phase, all the enterprise assets can be improved iteratively and
and continuously 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
www.opengroup.org A White P aper P ublished by The Open Group 21

22. 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.
Figure 4:
High-level Mapping
between
TOGAF ADM and ITIL Stages
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.
www.opengroup.org A White P aper P ublished by The Open Group 22

23. 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.
www.opengroup.org A White P aper P ublished by The Open Group 23

24. 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.
Figure 5:
TOGAF Views and Viewpoints
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
www.opengroup.org A White P aper P ublished by The Open Group 24

25. 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,
By merging the CMDB
itself a constituent of the Enterprise Continuum, should be a federated
and the EAR, it is repository that also includes, under its umbrella, the CMDB and asset
possible to create holistic database used by ITIL processes.
and enriched viewpoints By merging the CMDB and the EAR in a federated manner, it is possible to
of the up-to-date “AS IS” create holistic and enriched viewpoints of the up-to-date “AS IS”
operational view of the enterprise. A federated repository scheme enables
operational view of the
relevant configuration items from the CMDB to form part of the EAR.
enterprise. 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.
www.opengroup.org A White P aper P ublished by The Open Group 25

26. 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.
www.opengroup.org A White P aper P ublished by The Open Group 26

27. 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 The concerns of each stakeholder may be considered by addressing their
specific perspectives or viewpoints by creating views from the EAR as
stakeholder may be needed, as illustrated by Figure 7.
considered by addressing
The ADM is supported by the other main parts of TOGAF:
their specific viewpoints
 ADM Guidelines and Techniques (set of guidelines, templates,
and creating “views” checklists)
from the EAR as needed.  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
Figure 7:
The TOGAF ADM and the EAR
together help address
stakeholder concerns.
www.opengroup.org A White P aper P ublished by The Open Group 27

28. 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
www.opengroup.org A White P aper P ublished by The Open Group 28

29. 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- TOGAF 9 CONCEPT
SECTION
5. Introduction to the 5.1 5.1.1 The ADM and the Enterprise Architecture Assets Service Asset and
ADM Continuum Configuration
Management
Service Catalog
Management
Architecture repository that Enterprise Continuum Service Asset and CMDB
includes reference architectures, Configuration
models, Management
and patterns
5.1.2 The ADM and the Foundation Re-usable common Service Asset and Configuration Items
Architecture models, policy, Configuration
governance definitions Management
and specific technology
selections
5.1.3 ADM and Supporting Guidelines, templates, Service Asset and Documentation
Guidelines and Techniques checklists and other Configuration
detailed materials Management
5.2 Architecture Development Service Asset and CMDB
Cycle Configuration
Management
www.opengroup.org A White P aper P ublished by The Open Group 29

30. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
5.2.2 Basic structure Phases of the ADM Service Asset and CMDB
cycle Configuration
Management
5.4 Architecture Governance Architecture artifacts, Service Asset and Service Asset and
governance repository Configuration Configuration
Management Mangement
- CMDB
Service Level - Service Catalog
Management
5.5 Scoping the Architecture Vertical scope Service Asset and CMDB Scoping
Configuration
Management
5.5.3 Vertical scope / Service Asset and CMDB Scoping
Level of Detail Configuration
Management
5.5.4 Time Period Service Asset and CMDB Scoping
Configuration
Management
6. Preliminary Phase Preliminary phase of Service Asset and
ADM Configuration
Management
Service Level
Management
8. Business ADM - Phase B
Architecture
8.2 8.2.2 Developing Baseline Service Level Service Catalog
Description Management
www.opengroup.org A White P aper P ublished by The Open Group 30

31. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
8.4 8.3.2 Non-Architectural Inputs Service Level SLAs
Management
9. Information Systems ADM – Phase C
Architectures
9.3.2 Non-Architectural Inputs Service Level SLAs, OLAs
Management
10. Information ADM – Phase C
Systems
Architectures — Data
Architecture
10.2.2 Architecture Repository Service Asset and CMDB content
Configuration
Management
10.3.2 Non-Architectural Inputs Service Level SLAs, OLAs
Management
11. Information ADM – Phase C
Systems
Architectures —
Application
Architecture
11.2.2 Architecture Repository Service Asset and CMDB content
Configuration
Management
11.3.2 Non-Architectural Inputs Service Level SLAs, OLAs
Management
12. Technology ADM – Phase D
Architecture
www.opengroup.org A White P aper P ublished by The Open Group 31

32. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
12.2.1 Architecture Repository Service Asset and CMDB content
Configuration
Management
12.3.2 Non-Architectural Inputs Service Level SLAs, OLAs
Management
12.4.3 Develop Target Technology Architecture Building Service Asset and Links between ABB
Architecture Description Blocks Configuration and Services
Management
12.4.4 Perform Gap Analysis Service Level Service Catalog
Management
12.4.6 Resolve Impacts Across the Business Impact Analysis Change Advisory
Architecture Landscape Board
Change Management
Change Request
(RFC)
12.4.8 Finalize the Technology Service Level Service Catalog
Architecture Management
12.4.9 Create Architecture Definition Service Level Service Catalog
Document Management
13. Opportunities & ADM – Phase E
Solutions
13.2 Approach Change Management
13.4 13.4.11 Create Portfolio and Project Steps Release / Capacity / Business Plans
Charters and Update the Availability Business SLRs
Architectures Management
13.5 Risk Register Impact Analysis Financial Management SOA
TCO
14. Migration Planning ADM – Phase F
14.2 Approach Change Management
www.opengroup.org A White P aper P ublished by The Open Group 32

33. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
14.4 14.4.2 Assign a Business Value to Steps Release Management Business SLRs
Each Project
14.4.4 Prioritize the Migration Projects Steps Financial Management SOA
through the Conduct of a TCO
Cost/Benefit
Assessment and Risk Validation
14.5 Change Requests arising from Outputs Change Management Change Advisory
lessons learned Board
Service Catalog
Management
15.Implementation ADM – Phase G
Governance
15.2 Approach Release
Management
15.4 Steps Change Management
15.5 Outputs SLAs Change Management Change Advisory
Board
Service Catalog
Management
16. Architecture ADM – Phase H
Change
Management
16.2 Approach Release
Management
16.2.2 Enterprise Architecture Change Change Management RFC
Management Process SLAs
OLAs
www.opengroup.org A White P aper P ublished by The Open Group 33

34. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
16.5 Outputs Architecture Updates, Change Management Change Advisory
New requests, Board
Architecture Contract, Service Catalog
Compliance Management
Assessments
17. ADM Architecture
Requirements
Management
17.2 Approach Requirements Change Management
Management
17.4 Steps Change Management ITIL Change
Management
17.5 Outputs Requirements Impact Change Management Business Impact
Assessment, Updated Analysis
Architecture Service Catalog Business SLRs
Requirements Management
Specification
24. Stakeholder Financial Management - Accounting
Management - Investment Analysis
- Charging Policy
- Charging Model
27. Gap Analysis Change Management - Change Impact
Assessment
- Change Financial
Assessment
28. Migration Planning Change Management - Change Impact
Techniques Assessment
- Change Financial
Assessment
- Demand
Management
- Business Continuity
Plan
www.opengroup.org A White P aper P ublished by The Open Group 34

35. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
31. Risk Management IT Service Continuity - Business Plans
Management - SLAs
- OLAs
- Service Catalog
32. Capability-based Availability Management - Business SLRs
Planning - Service Catalog
- CMDB
37. Building Blocks Opportunity Identification Service Asset and CMDB
Building Block Re-Use Configuration
Management
39. Enterprise IT Service Continuity
Continuum
40. Architecture Service Asset and CMDB
Partitioning Configuration
Management
41. Architecture Service Level Service Catalog
Repository Management CMDB
Service Asset and
Configuration
Management
42. Tools for ITSM Tools - CMDB
Architecture - DHS
Development - DSL
- KEdb
- CDB
43. Foundation
Architecture: Technical
Reference Model
www.opengroup.org A White P aper P ublished by The Open Group 35

36. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
43.1.1 Role of the TRM in the Service Asset and CMDB
Foundation Architecture Configuration
Management
43.1.2 TRM Components Service Asset and CMDB
Configuration
Management
43.3 TRM in Detail Service Asset and CMDB
Configuration
Management
43.4 Application Platform — Service Level Service Catalog
Taxonomy Management SLA/OLA
43.5 Detailed Platform Taxonomy Service Level Service Catalog
Management SLA/OLA
44. Integrated
Information
Infrastructure
Reference Model
44.2.1 Derivation of the III-RM from Service Asset and CMDB
the TRM Configuration
Management
44.3 Detailed Platform Taxonomy Service Level Service Catalog
Management SLA/OLA
47. Architecture Board Change Management Change Advisory
Board
www.opengroup.org A White P aper P ublished by The Open Group 36

37. ITSM And TOGAF 9
TOGAF 9 COMMENTS ITIL CONCEPT COMMENTS
CHAPTER SECTION SUB- TOGAF 9 CONCEPT
SECTION
49. Architecture IT Service Continuity - Business Continuity
Contracts Management Management
- Ongoing
Operational
Management
50. Architecture Service Level - Business SLRs
Governance Management - Service Catalog
Change Management - CMDB
Glossary Appendix A ITIL Glossary
www.opengroup.org A White P aper P ublished by The Open Group 37

38. 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.
www.opengroup.org A White P aper P ublished by The Open Group 38

39. 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.
www.opengroup.org A White P aper P ublished by The Open Group 39