ITSM and TOGAF 9 v0 5


Published on

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.

Published in: Technology

ITSM and TOGAF 9 v0 5

  1. 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, A White P aper P ublished by The Open Group 1
  2. 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 A White P aper P ublished by The Open Group 2
  3. 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 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. A White P aper P ublished by The Open Group 3
  4. 4. ITSM And TOGAF 9 San Francisco, CA 94104 or by email to: A White P aper P ublished by The Open Group 4
  5. 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 A White P aper P ublished by The Open Group 5
  6. 6. ITSM And TOGAF A White P aper P ublished by The Open Group 6
  7. 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 A White P aper P ublished by The Open Group 7
  8. 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 otherBy coupling ITSM and complementary efforts in order to deliver or recognize real business value 1. By coupling IT Service Management (ITSM) and The Open GroupTOGAF, organizations Architecture Framework (TOGAF), organizations have an opportunity tohave an opportunity to harmonize their services and achieve the alignment of business andharmonize their services technology goals.and achieve the Combining ITSM within a TOGAF context provides a toolkit for deliveringalignment 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, TOGAFtechnology 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 A White P aper P ublished by The Open Group 8
  9. 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 White P aper P ublished by The Open Group 9
  10. 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 A White P aper P ublished by The Open Group 10
  11. 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 UKs 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 A White P aper P ublished by The Open Group 11
  12. 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 A White P aper P ublished by The Open Group 12
  13. 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 A White P aper P ublished by The Open Group 13
  14. 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 activityService Design is not related to to new services,  Capacity Management Analysis and planning of performance and capacity relatedbut includes the changes activities.and improvements  Information Security Managementnecessary 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 compliancecustomers. 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. A White P aper P ublished by The Open Group 14
  15. 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 isStrategic objectives are provided on how to maintain stability in service operations, allowing forultimately 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 ServiceOperation. 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 A White P aper P ublished by The Open Group 15
  16. 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 A White P aper P ublished by The Open Group 16
  17. 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 A White P aper P ublished by The Open Group 17
  18. 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 KPIsTOGAF ADM’s design  Identify the Business Transformation Risks and Mitigationphases map to ITIL’s ActivitiesService 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 A White P aper P ublished by The Open Group 18
  19. 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 A White P aper P ublished by The Open Group 19
  20. 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 A White P aper P ublished by The Open Group 20
  21. 21. ITSM And TOGAF 9 The Role of ITSM in TOGAF 9Figure 3:ITSM and TOGAFin 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 levelImprovement stage with Figure 3 presents an example of how ITSM may be incorporated into anthe TOGAF Requirements organization in practice based on the principles of ITIL 3. Each of theManagement phase, all processes shown in the figure can be established by the ADM mappings discussed earlier in this section. Further, by linking ITIL’s Continualthe enterprise assets can Service Improvement (CSI) stage with the TOGAF Requirementsbe improved iteratively Management phase, all the enterprise assets can be improved iteratively andand 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 A White P aper P ublished by The Open Group 21
  22. 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 MappingbetweenTOGAF 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. A White P aper P ublished by The Open Group 22
  23. 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 A White P aper P ublished by The Open Group 23
  24. 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 A White P aper P ublished by The Open Group 24
  25. 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 A White P aper P ublished by The Open Group 25
  26. 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 Recommendationsfor Applying TOGAF to A White P aper P ublished by The Open Group 26
  27. 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 asstakeholder 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 FrameworkFigure 7:The TOGAF ADM and the EARtogether help addressstakeholder A White P aper P ublished by The Open Group 27
  28. 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 A White P aper P ublished by The Open Group 28
  29. 29. ITSM And TOGAF 9Appendix C: TOGAF 9 And ITIL 3 MappingsThe table below maps sections of TOGAF 9 to the relevant underlying concept or process in ITIL 3.TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER SECTION SUB- TOGAF 9 CONCEPT SECTION5. Introduction to the 5.1 5.1.1 The ADM and the Enterprise Architecture Assets Service Asset andADM 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 A White P aper P ublished by The Open Group 29
  30. 30. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER 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 Management6. Preliminary Phase Preliminary phase of Service Asset and ADM Configuration Management Service Level Management8. Business ADM - Phase BArchitecture 8.2 8.2.2 Developing Baseline Service Level Service Catalog Description A White P aper P ublished by The Open Group 30
  31. 31. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER SECTION SUB- TOGAF 9 CONCEPT SECTION 8.4 8.3.2 Non-Architectural Inputs Service Level SLAs Management9. Information Systems ADM – Phase CArchitectures 9.3.2 Non-Architectural Inputs Service Level SLAs, OLAs Management10. Information ADM – Phase CSystemsArchitectures — DataArchitecture 10.2.2 Architecture Repository Service Asset and CMDB content Configuration Management 10.3.2 Non-Architectural Inputs Service Level SLAs, OLAs Management11. Information ADM – Phase CSystemsArchitectures —ApplicationArchitecture 11.2.2 Architecture Repository Service Asset and CMDB content Configuration Management 11.3.2 Non-Architectural Inputs Service Level SLAs, OLAs Management12. Technology ADM – Phase A White P aper P ublished by The Open Group 31
  32. 32. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER 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 Management13. Opportunities & ADM – Phase ESolutions 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 TCO14. Migration Planning ADM – Phase F 14.2 Approach Change A White P aper P ublished by The Open Group 32
  33. 33. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER 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 Management15.Implementation ADM – Phase GGovernance 15.2 Approach Release Management 15.4 Steps Change Management 15.5 Outputs SLAs Change Management Change Advisory Board Service Catalog Management16. Architecture ADM – Phase HChangeManagement 16.2 Approach Release Management 16.2.2 Enterprise Architecture Change Change Management RFC Management Process SLAs A White P aper P ublished by The Open Group 33
  34. 34. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER SECTION SUB- TOGAF 9 CONCEPT SECTION 16.5 Outputs Architecture Updates, Change Management Change Advisory New requests, Board Architecture Contract, Service Catalog Compliance Management Assessments17. ADM ArchitectureRequirementsManagement 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 Specification24. Stakeholder Financial Management - AccountingManagement - Investment Analysis - Charging Policy - Charging Model27. Gap Analysis Change Management - Change Impact Assessment - Change Financial Assessment28. Migration Planning Change Management - Change ImpactTechniques Assessment - Change Financial Assessment - Demand Management - Business Continuity A White P aper P ublished by The Open Group 34
  35. 35. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER SECTION SUB- TOGAF 9 CONCEPT SECTION31. Risk Management IT Service Continuity - Business Plans Management - SLAs - OLAs - Service Catalog32. Capability-based Availability Management - Business SLRsPlanning - Service Catalog - CMDB37. Building Blocks Opportunity Identification Service Asset and CMDB Building Block Re-Use Configuration Management39. Enterprise IT Service ContinuityContinuum40. Architecture Service Asset and CMDBPartitioning Configuration Management41. Architecture Service Level Service CatalogRepository Management CMDB Service Asset and Configuration Management42. Tools for ITSM Tools - CMDBArchitecture - DHSDevelopment - DSL - KEdb - CDB43. FoundationArchitecture: TechnicalReference A White P aper P ublished by The Open Group 35
  36. 36. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER 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/OLA44. IntegratedInformationInfrastructureReference 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/OLA47. Architecture Board Change Management Change Advisory A White P aper P ublished by The Open Group 36
  37. 37. ITSM And TOGAF 9TOGAF 9 COMMENTS ITIL CONCEPT COMMENTSCHAPTER SECTION SUB- TOGAF 9 CONCEPT SECTION49. Architecture IT Service Continuity - Business ContinuityContracts Management Management - Ongoing Operational Management50. Architecture Service Level - Business SLRsGovernance Management - Service Catalog Change Management - CMDBGlossary Appendix A ITIL A White P aper P ublished by The Open Group 37
  38. 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 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 and his profile is available on A White P aper P ublished by The Open Group 38
  39. 39. ITSM And TOGAF 9About 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 industrys premier certification service, including UNIX system certification. Further information on The Open Group can be found at A White P aper P ublished by The Open Group 39