integrating architecture and itil

Integrating Architecture and ITIL Best Practices, Part 1

Warren Weinmeyer

Aug. 2014

Table of Contents

• Executive Summary ………………………………………………Slides 05-09

• The Case for Integration ………………………………………Slides 12-14

• TOGAF & ITIL as Deming Cycles …………………………Slides 16-19

• Foundational IT Lifecycle & IT Levels ……………………Slides 21-26

• Architecture & IT Roles at Different IT Levels………Slides 28-30

• TOGAF Integration by ITIL Stage & Process…………Slides 32-58

• Other Important Aspects of Integration ………………Slides 60-62

2

3

Introduction

• This slide deck attempts to offer some concrete guidance on how Architectural activities and outputs can be integrated into the ITIL framework• The focus is on integrating into ITIL processes

A brief summary for Managers (and for you TL;DR types)…

4

Low

5

Maturity of Best Practices

StrategicOperational

ActivityType

Tactical

Architecture

Med

High

ITIL

There’s LOTS of overlap between the focus areas of Architecture and ITIL

Architecture has further reach and more sophisticated guidance for strategic activities, while ITIL better covers daily operational activities

Serv

ice

Tran

sitio

n

Service Operation

6

Service Design

Continual Service

Improvement

TOGAF and ITIL are examples of a Deming Cycle.

When colour-coded against the Deming Cycle steps and plotted over the generic IT lifecycle, you can see they have a good synergy (at a high level).

Serv

ice

Stra

tegy

Prelim

A.Architecture

Vision

C.Info SystemArchitecture

B.Business

Architecture

D.TechnologyArchitecture

E.

Opportunities

& Solutions

F.

Migration

Planning G.

Imple

mentat

ion

Govern

ance

H.Architecture

Change Management

RequirementsManagement

ServiceStrategy

Service Support

Opportunity Identification Service

Road-mapping

Project Mgmt.

Change Mgmt.

Service Operations

Service

Service

Portfolio

Portfolio

7

Portfolio

Architecture & ITIL operate at multiple levels of IT (their areas of focus as well as their activities are different at different levels).

At each layer, Architecture and ITIL require coordination and integration.

Portfolio Strategy Capture

Capability Planning

Technology Landscape Mgmt.

Program Mgmt.

Master Data Mgmt.

ITStrategy Capture /Review

Help Desk

Demand Mgmt.

IT Road-mapping

Project PortfolioMgmt.

Change Mgmt.

Here is a 1-page look at integrating Architecture outputs into ITIL

9

You need to consider Process, Data and Governance to get a complete picture of the integration.• Process (to a certain level of

detail) is covered in this deck

End of

Summa

ry

10

This is the beginning of the main slide deck.

Let’s start off with some general background…

11

ITIL and Architecture: The Case for Integration

• Historically, EA has not been active in ITIL initiatives

• A Forrester paper says that even today most ITIL programs still have little involvement from EA

• The belief seems to be that these are different worlds and different concerns

• However, both ITIL and Architecture have expanded their frameworks over time and now have significant overlap

12

• You may have seen this diagram in some whitepapers that discuss integrating TOGAF with ITIL• This view illustrates how TOGAF can

complement ITIL’s weakness in Strategic matters and vice-versa for Operational matters

• Two challenges with this diagram:• The way it’s laid out leaves an initial

impression that Architecture and ITIL are nice complementary halves of the whole, not heavily-overlapping frameworks

• This only looks at Enterprise Architecture: what about the Architecture practice as a whole?

13

Strategic

ITIL

Operational

Tactical

EA


• This diagram perhaps more realistically illustrates the type of overlap between the two frameworks

• In the Operational area, ITIL provides SLA concepts that Architecture doesn’t talk about.

• In the Strategic area, ITIL does not address anything above the level of portfolio of Services

• There’s a lot of area in between where integration is required

• Note: This may not reflect your specific company:• Many companies do not try to

implement all of ITIL

• Many companies do not have a modern and/or comprehensive Architecture practice

Low

14

Maturity of Best Practices

StrategicOperational

ActivityType

Tactical

Architecture

Med

High

ITIL


Synchronization of processes is an important part of integration, so let’s take a moment to compare the TOGAF and ITIL lifecycles…

15

TOGAF and ITIL Are Modified Deming Cycles

• The Deming Cycle is an iterative process (originating in the manufacturing sector) for quality management and continuous improvement.

• It consists of 4 steps:

• Plan: Establish objectives

• Do: Implement the plan

• Check: Study the results

• Act: Adjust to bring results in line with

objectives

• TOGAF and ITIL are all about quality

control and continuous improvement

16

Plan

DoCheck

Act

Deming Cycle

Are we doing the right things?

Are we doing things right?

Are we getting the expected

results?

Are the results netting the expected

benefits?

TOGAF as a Modified Deming Cycle

17

• Here is a diagram of TOGAF’s ADM (architecture development method). Colour-coding is used to map TOGAF stages to Deming Cycle steps.

• Quality control and continuous improvement entails:• iterating and going back to

previous steps when necessary

• constant cross-references between Requirements as they evolve versus the architecture specifications as they evolve.

• assessing gaps, redundancies and performance of delivered architectures

• defining future states with capability maturity models and roadmaps,

• transitional architectures to guide progress to the future state.

18

ITIL as a Modified Deming Cycle

• Here is a diagram of ITIL’s lifecycle. Colour-coding is used to map ITIL phases to Deming Cycle steps.

• Quality control involves defining expected levels of service and metrics to assess whether levels are met.

• Continuous improvement involves a formal 7-step quality improvement process.

• Note: The size of the pie slices are not meant to indicate the relative time or focus dedicated to any particular phase

TOGAF and ITIL Overlaid as a Deming Cycle

19

• Overlaying ITIL with TOGAF shows that, at a high level, the two frameworks sync up pretty well in terms of the main Deming-type focus of each of their respective steps.

• When we dive a little deeper into the activities of each step in these frameworks, we see the picture is a little more complicated, because several TOGAF phases actually bridge ITIL phases

• We will go through that later on in this deck

Now let’s see how Architecture and ITIL relate to different levels of IT…

20

The Foundational Annual IT Lifecycle

21

• Even companies that have implemented ITIL tend to keep to a traditional, fundamental annual rhythm that has 3 basic phases:

• Planning for the upcoming year

• Executing Delivery projects that were identified in the planning stage

• Maintaining delivered solutions as part of corporate operations• Includes the monitoring,

operating and supporting of systems

Serv

ice

Tran

sitio

n

Service Operation

22

Service Design

• If we plot ITIL stages onto the basic IT lifecycle, we see a pretty close alignment with the basic IT organization lifecycle.

• Service Transition straddles Delivery and Operations because that phase begins with the final phases of a delivery project and continues through the warranty period of the delivered solution operating in Production

Continual Service

Improvement

ITIL in the Foundational IT LifecycleSe

rvic

e St

rate

gy

Serv

ice

Tran

sitio

n

Service Operation

23

Service Design

Continual Service

Improvement

TOGAF and ITIL in the Foundational IT LifecycleSe

rvic

e St

rate

gy

Prelim

A.Architecture

Vision

C.Info SystemArchitecture

B.Business

Architecture

D.TechnologyArchitecture

E.

Opportunities

& Solutions

F.

Migration

Planning G.

Imple

mentat

ion

Govern

ance

H.Architecture

Change Management

RequirementsManagement

• Overlaying ITIL with TOGAF shows us how TOGAF phases relate to the ITIL lifecycle

• Phase B is shown as straddling the Strategy and Design stages because TOGAF allows for the scenario where the is little or no pre-existing Business Architecture and so work needs to be done to get buy-in for the key Business objectives, to build Business Strategy and Vision if there isn’t one, etc.

• Phase F bites into Service Transition because the transition plan is finalized in Phase F, and is one of the first things completed in Service Transition

• Phase G straddles Design and Transition because TOGAF specifies that IT projects happen during that phase

• Phase H has aspects of Continual Service Improvement: that is where operational monitoring as well as monitoring for changes in the environment occurs. Changes in the Business environment can result in changes to the service strategy and architecture vision.

The Basic Lifecycle Exists at Multiple Levels of IT

24

IT Organization

IT Portfolio

IT Service

• The top level is at the level of IT as an organization

• The second level is typically a portfolio of some kind, which can be based on a Capability, on related technologies, on the Business Unit customer, etc. Portfolios typically consist of multiple systems or services.

• The third level is typically a Service or system

• These levels are “typical” – your org may be different

Opportunity Identifi-cationService Strategy Capture

Service Road-mapping


Capability Planning

Strategy Capture /Review

Help Desk

Demand Mgmt. IT Road-

mapping


Project Mgmt.

Change Mgmt.

The Basic Lifecycle Exists at Multiple Levels of IT

25

• At the IT Level:• Involves strategically prioritizing and

sequencing Business demand• Governance of delivery and change

management• Centralized Help Desk function

• At the Portfolio Level:• Involves identifying and planning strategic

capability enhancements• Management and synchronization of projects

impacting the portfolio technical landscape• Identifying capability gaps and redundancies

in the technical landscape of the portfolio• Managing the portfolio information landscape

• At the Service Level:• Involves identifying and planning service

improvements• Managing delivery projects• Managing the introduction of new solutions

into the technical landscape• Operating, monitoring, supporting and

maintaining solutions


Program Mgmt.

IT Organization

IT Portfolio

IT Service

Master Data Mgmt.

Service Support Operations Change

Mgmt.

ServiceStrategy

Service Support

Opportunity Identification Service

Road-mapping

Project Mgmt.

Change Mgmt.

Service Operations

Service

Service

Portfolio

Portfolio

26

•IT Organization level:• ITIL is concerned with building a

service catalog, assigning service ownership roles and responsibilities, and coordinating and standardizing Service Design approaches

• Architecture is focused on EA concerns, such as the business priorities, investment prioritization, architectural governance (standards, arch. patterns and compliance) and future-state visioning/planning

•Portfolio/segment level:• Architecture is concerned with

portfolio management and capability planning.

•IT Service level:• ITIL lifecycle and practices are

applied to each Service• Architecture complements ITIL with

specific best practices applied across the ITIL lifecycle and is concerned with the application of Solution Architecture practices within service delivery projects

Portfolio

Architecture & ITIL Exists at Multiple Levels of IT


Capability Planning


Program Mgmt.

Master Data Mgmt.

ITStrategy Capture /Review

Help Desk

Demand Mgmt.

IT Road-mapping


Change Mgmt.

Let’s get a little bit more specific regarding what Architecture and ITIL contribute at the different IT levels.

27

ITILArchitecture

Architecture & ITIL Roles – IT Organization Level

28

• Architecture supports with:• Best practices:

• Strategic Planning• Models:

• Strategy/Motivation• Capability/Value Chain

• Analytics:• Demand/Opportunity strategic value

interdependencies, redundancies and synergies assessments

• Governance:• Standards and Patterns• Strategic Alignment

• ITIL supports with:• Processes:

• Change Management• Help Desk/Support

• Governance:• Organizational structures• Functional Role Definitions• Service Portfolio• Standardized Processes

• Models:• CMDB

Strategy Capture /Review

Help Desk

Demand Mgmt. Road-

mapping


Change Mgmt.

IT Organization

Architecture

Architecture & ITIL Roles – IT Portfolio Level

29

• Architecture supports the IT portfolio lifecycle with:• Best practices:

• Strategic Planning• Master Data Management

• Models:• Maturity• Strategy/Motivation• Capability Development Roadmaps

• Analytics:• Portfolio capability gaps and

redundancies• Program/Project interdependencies,

redundancies and synergies

• ITIL does not address the IT portfolio level



Program Mgmt.

Capability Planning

Master Data Mgmt.

IT Portfolio

ITILArchitecture

Architecture & ITIL Roles – IT Service Level

30

• Architecture supports with:• Best practices:• Strategic Planning• Business Process Modeling/Improvement• SOA

• Models:• Strategy/Motivation• Process• Solution Architectures

• Analytics:• System interdependencies/interactions

• Governance:• Technology Standards

• ITIL supports with:• Processes:• Service Lifecycle Management• Change Management• Continuous Improvement• Capacity Planning

• Governance:• Service/Process Owners and Stewards• Service Level Agreements

IT Service

Opportunity Identifi-cation

Service Strategy Capture

Service Road-mapping

Service Support Operations Change

Mgmt.

Project Mgmt.

Now let’s zoom in for a look at some concrete ways of integrating TOGAF into the ITIL lifecycle.

31

• Here’s a basic view of TOGAF and ITIL without any of the lifecycle flow arrows

• Using this view, we are going to build a mid-level mapping of Architecture activities and deliverables against each ITIL process

• We will also indicate which TOGAF phase will govern the interaction with the ITIL process

TOGAF Integration by ITIL Stage and Process

TOGAF Integration by ITIL Lifecycle Stage

• Strategy Mgmt. involves determining how to manage IT Services to optimize their value to the organization• At the IT level, this

means the IT Service strategy as a portfolio of services

• At the Service level, this means doing strategic planning for a service

• The TOGAF Preliminary phase provides basic guiding context at both the IT level and for individual services• Verify the opportunity,

the buy-in, the level of organizational capability and maturity, and the organizational model

• Phase A supports the identification of the relevant Stakeholders, Vision, Principles and Strategy, and assessing strategic alignment and readiness for Business Transformation

• Phase B supplies Business context: Value Chains & Processes, Requirements, and Operating Models


• Business Relationship Management (BRM) involves identifying customer needs and ensuring that an IT service provider can meet these needs, now and as customers' needs change over time

• The Preliminary phase can accommodate preparation for building relationships and for doing strategic planning • Create understanding of

the stakeholders, their expectations, build the organizational model, and assess the business capability maturity

• Phase A provides strategies & roadmaps from Business and IT, and supports the modeling of Stakeholders’ Concerns and the Vision, Principles and Strategy. As well, assessing organizational readiness for Business Transformation

• Phase B supports creation of Business and Process models, and the capture of Requirements & Drivers


• Financial Management involves ensuring the management of a service is undertaken with due consideration of the value, risks, benefits, and costs of the service

• Phase A provides relevant strategies & roadmaps from Business and IT, as well as strategic alignment/value assessments of services and supporting elements

• Phase B provides insights regarding the relevant Business requirements, along with risk/impact assessments of relevant Business Cases


• Demand Management involves interpreting and influencing customer demand for services, as well as providing capacity to meet those demands• Creating PBAs (Pattern of

Business Activity) and UPs (User Profile) to make demand patterns more predictable

• Creating SLPs (Service Level Package) to satisfy the PBAs

• The Preliminary Phase provides the Stakeholder Framework, which describes the Stakeholder types, their roles and responsibilities and their standard Concerns

• Phase A provides specific stakeholders’ Concerns, as well as roadmaps from Business and IT, to inform on potential future demand.

• Phase B provides Business processes, requirements & drivers, to inform on potential future demand and required service levels


• Service Portfolio Mgmt. involves determining which IT services to include and how those services will be tracked throughout their lifecycles• At the IT level, this

means governing and managing the Service Portfolio, and identifying new needed services

• At the Service level, this means launching a new service or identifying required changes to one

• The Preliminary phase provides the opportunity, buy-in and approval, the Capability landscape and Service taxonomy, and the organizational model needed to support a new service and the Portfolio

• Phase A provides strategic alignment and readiness assessments for services

• Phase B supplies Value Chains and Processes, and Requirements needed for establishing the Business Case for a new service

• Phase H shows changes in the enterprise that trigger new or changed services


SS Stage Summary

• As indicated in the high-level view, the Preliminary Phase, Phase A and parts of Phase B provide integral inputs to ITIL’s Service Strategy stage

• Also as per the high-level view, Phase H provides a continuous improvement feedback loop into the Service Strategy stage


• Design Coordination involves ensuring quality and consistent design practices and documents and coordinating design activities across projects• At the IT level, this

means EA and PPM types of governance

• At the Service level, this means launching and governing IT projects and SA governance

• Phase A provides the strategic alignment and value assessments for project proposals (PPM), and Business/IT strategies and roadmaps (EA). At the SA level, it supports the definition of project Vision, Principles and Objectives, & Risk/Impact Assessments.

• Phase B supports the discovery of functional Requirements, as well as the identification of roles, activities, organizational units and capabilities involved in the solution.

• Phases C & D provide…(next slide)…


• Phases C & D provide Data and Technical standards and patterns (EA), support the discovery of non-functional and security Requirements, and elaboration of the logical information and technical characteristics of the required solution (SA).

• Phase E supports the RFx and solution selection and assessment processes within IT projects and the specification of the physical architecture of the solution

• Phase F supports the valuation and coordination of proposed capability enhancements across services (EA), as well as supports the creation of solution implementation and migration plans (SA)

• Phase G supports the construction of deployment environments as well as the creation of oversight architecture documents for solution deployment and validation


• Service Level Management involves negotiating SLAs and ensuring that they are adhered to through monitoring, reporting and soliciting customer feedback

• Phase B provides Business strategy and service functional Requirements and supports mapping these to the existing capabilities of the service.

• Phases C & D provide the security and non-functional Requirements, and support mapping these to the existing capabilities of the service.

• Phase H supports monitoring of the operational solutions supporting the service, and assessing their compliance with functional, non-functional and security Requirements


• Service Catalog Mgmt. involves ensuring that there is a central, accurate, and consistent source of data about all operational services and about all services being transitioned to the live environment

• Phase B provides solution stakeholder maps to help identify Business-facing services and their customers

• Phases C & D provide information and technical models and landscapes to feed and validate CIs in the CMDB and service catalog.


• Availability Mgmt. involves measurement, monitoring, analysis, and reporting of the availability, reliability and maintainability of the service

• Phase A provides enterprise strategy, principles and policies regarding high-availability and disaster recovery to guide proactive planning of service availability requirements

• Phase D provides reference architectures, patterns and standards for reliably attaining required availability levels from solutions supporting the service.


• Capacity Mgmt. involves ensuring that the maintenance and growth of IT resource capacity (compute, bandwidth, storage,) is aligned to the requirements of service customers and the preservation of required service levels

• Phase B provides Business capacity Requirements from across the enterprise (EA)

• Phase D provides current capacity for components of the shared infrastructure (EA) and specific solutions (SA)

• Phase F provides timelines for projected additional capacity and capacity requirements from architectural roadmaps (EA)


• Supplier Mgmt. involves ensuring that suppliers meet the terms, conditions, and targets of their contracts and agreements & optimizing the value from the supplier services

• Phase C provides information principles and master data management policies (EA), as well as information management and privacy requirements for the data processed or hosted by the supplier (SA)

• Phase D provides security principles and guidelines (EA), as well as non-functional and security requirements for the solutions developed or hosted by the supplier


• Info Security Mgmt. involves ensuring that availability, confidentiality, integrity and authenticity of information and systems is maintained by managing risks and monitoring for compliance

• Phase A provides info-sec and information mgmt. strategy, principles and policies (EA)

• Phase B provides user roles, role access privileges, and use-cases

• Phase C provides info-sec, information mgmt., and privacy patterns and standards, as well as data flow profiles across solutions (EA)

• Phase D provides security patterns, standards (EA) as well as solution deployments specifications of interface points and security mechanisms (SA)

• Phase G provides security architecture compliance assessments of solution specifications (EA)

• Phase H provides changes in business environment


• Service Continuity Mgmt. involves ensuring that required IT technical and service facilities can recommence within required timescales by maintaining continuity and recovery plans in compliance with SLAs, perform Business Impact and Risk assessments and DR testing

• Phase A provides DR/BC strategy & principles (EA)

• Phase B provides Business Impact assessments, Risk Assessments, as well as Return to Operations (RTO), Recovery Point Objectives (RPO) specs and other BC requirements (SA)

• Phase C provides data restore processes (SA)

• Phase D provides DR patterns & standards (EA) & solution deployments

• Phase G provides solution DR/BC compliance assessments (SA)

• Phase H provides changes in the business environment (EA)


SD Stage Summary

• As one would expect, there are numerous points of integration between TOGAF and ITIL at the Service Design stage

• The nature of the various points of integration includes both EA and SA activities

• The Design Coordination high-level process is umbrella beneath which IT development projects are spun up and executed, but Design Coordination does not actually manage or execute the projects.• This is analogous to the

relationship between IT projects and TOGAF’s Phase G.


• Release and Deployment Mgmt. involves guiding the planning, scheduling, building, testing, and deployment of releases

• Phase F assists in the coordination of the solution deployment with other governance bodies and processes, provides an Implementation and Migration plan to assist in the development of a Release and Deployment plan, and provides critical success factors defining the successful deployment of the solution (SA)

• Phase G provides a description of required resources and skills for a successful deployment, a Deployment Risk/Impact assessment, oversight of the construction of the Production and QA environments, as well as oversees the retirement and disposition of obsolete and redundant solution and data components (SA)


• Knowledge Management involves ensuring that perspectives, data, ideas, experience & information, are retained and readily available

• Phase F provides for the completion & confirmation of the various EA and SA architectural documents and artifacts for the current iteration of the architecture cycle


• Service Asset and Configuration Mgmt (SACM) ensures that the assets required to deliver IT services are properly controlled, and that accurate and reliable information about those assets is readily available

• Phase F provides for the completion & confirmation of the various EA and SA architectural documents and artifacts for the current iteration of the architecture cycle


• Transition Planning and Support involves overall planning for Service Transition processes and coordinates the resources that they require

• Phase F provides for identifying and resolving conflicts and inter-dependencies between implementation projects, & coordination/sequencing of the projects for optimal benefits realization (EA)

• Phase G provides the identification of required skills and resources for a successful deployment (as well as governance over the solution construction and deployment (SA)


• Service Validation and Testing provides quality assurance, and verifies that a new or changed IT service is fit for purpose and fit for use.

• Phase G provides validation of architectural compliance of the solution to architectural standards (EA), and assists in validating the service through providing fit/gap assessments for the non-functional, security and functional characteristics of the solution compared to Requirements (SA)


• Change Management involves the enablement of beneficial changes with minimal disruption to IT services through risk management, ensuring changes are documented, controlled and prioritized for value and strategic alignment

• Phase A provides strategic alignment and value assessments for work packages that have submitted change requests. (EA)

• Phase F provides for identifying and resolving conflict/interdependencies between implementation projects, sequencing of the projects for optimal benefits realization (EA), and deployment and roll-back plans (SA)

• Phase G provides validation of architectural compliance of the solution to architectural standards (EA), and assists in validating the service through providing non-functional and functional fit/gap assessments to listed Requirements (SA)


• Change Evaluation involves a consistent and standardized means to assess the performance or value of a proposed IT service change, to facilitate a decision about whether to authorize the change

• Phase A provides strategic alignment and value assessments for work packages that have submitted change requests. (EA)

• Phase F provides for identifying and resolving conflict/interdependencies between implementation projects (EA)

• Phase G provides a Deployment Risk/Impact assessment (SA) and also provides a host phase for ARB approval for the change (EA)


ST Stage Summary

• There are a surprising number of both EA and SA integration points between TOGAF and ITIL at the Service Transition stage

• The Release & Deployment Management process is where the work gets done to move solutions into Production.• This is analogous to the

relationship between IT projects and TOGAF’s Phase G.


• For operational services, the role of Architecture is focused around ensuring the services continue to provide the required benefits and to identify when changes are needed• Providing insight into

changes in the Business environment that might change the operating conditions or expectations for services

• Checking that service levels meet Requirements

• Providing guidance on system/data access and usage


• Here’s everything summarized on 1 page

Wait! We’re not done yet!

There is more to talk about Process, and also Data and Governance

• each of these is worth a slide deck on their own, but we’ll close off with a few slides to paint an overview

59

• The previous analysis of TOGAF Integration by ITIL Stage is a pretty instructive and prescriptive look at integration from a Process perspective, but it doesn’t tell the whole story. This view:

• does not show that many ITIL processes span multiple ITIL stages, and also does not peer inside the processes, so the timing of the Architectural inputs into the processes is not clear in this view

• only shows a 1-way relationship of Architecture inputs to ITIL, but not ITIL inputs to Architecture

Other Considerations - Process

• ITIL has a few different categories of Service: 1. Business Service: A service delivered to business customers by business units. Note that this is demarcated from any technology - since ITIL is IT-scoped, the internal workings of a Business Service are really outside the scope of ITIL, though of course we need to understand the inputs, outputs and controls so that IT can support these activities. 2. IT Service: A service provided by IT. These are really what ITIL Services are all about. There are two types of IT Service, Customer-facing and Supporting: A) Customer-facing Service: These are the IT Services that are directly interacted with by the Customer. The Customer means internal customer (i.e. the Business): not the public and not other IT groups. Why not the public? Because the Business Services are the interface to the public, not IT Services. Why not other IT groups? Because if other IT groups can be customers then all IT Services will be Customer-Facing, making the service catalog pretty useless for one of its primary goals: making it easy for the Business to find and engage services. B) Supporting Service: These are the IT services that support Customer-facing Services. The customers of these services are other IT groups.

So, that's the ITIL service types: they are differentiated by the type of end customer, but they are what you would call "organizational" services. They all are mapped to an org unit that delivers them, they all include management, planning, monitoring, and support resources (people, budget, equipment, etc.).

TOGAF (if you include the extensions to the meta-model) has the following service types: Business, Information System, and Platform. TOGAF service types map to different layers: Business Service ---> Organizational: between people as part of business processes Info System Service ---> SOA: between systems as part of processes Platform Service ---> Technology: interfaces between technology and/or software

Now look back at ITIL: those services are all at the Organizational layer. So, you actually have a 3:1 overloading of ITIL Service to TOGAF Business Service.

• Other important ITIL concepts must also be mapped in a manner that preserves integrity for both TOGAF and ITIL. Sometimes this is straight-forward, sometimes it isn’t!

61

Other Considerations - Data

62

Other Considerations - Governance• The ITIL books do offer

some discussion regarding interacting with other governance bodies, but its recognition of Architecture governance is mostly restricted to specifying standards.

• ITIL does not mention common Architecture governance bodies, such as ARB, nor does it talk about the scope of mandate an ARB may have.