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

There’s LOTS of overlap between the focus areas of
Architecture and ITIL
High
Low
5
Maturity
of
Best
Practices
Operational Tactical
Strategic
Activity
Type
Architecture
Med
ITIL
Architecture has further
reach and more
sophisticated guidance for
strategic activities, while
ITIL better covers daily
operational activities

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).
Continual
Service
Improvement
Service Operation
6
Prelim

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.
7

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

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
9

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
Tactical
Operational
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
High
Low
14
Maturity
of
Best
Practices
Operational Tactical
Strategic
Activity
Type
Architecture
Med
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
Are we doing
the right things?
Plan
Act
Deming
Cycle
netting the expected
Check Do
Are we doing
things right?
Are the results
benefits?
Are we getting
the expected
results?

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.

ITIL as a Modified Deming Cycle
18
• 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

ITIL in the Foundational IT Lifecycle
Service Operation
22
• 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

TOGAF and ITIL in the Foundational IT Lifecycle
Continual
Service
Improvement
Service Operation
23
Prelim
• 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
• 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

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

Architecture & ITIL Exists at Multiple Levels of IT
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

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

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

Architecture & ITIL Roles – IT Portfolio Level
29
• Architecture supports the IT
portfolio lifecycle with:
• Best practices:
• Master Data Management
• Models:
• Maturity
• Capability Development Roadmaps
• Analytics:
• Portfolio capability gaps and
redundancies
• Program/Project interdependencies,
redundancies and synergies
• ITIL does not address the IT
portfolio level

Architecture & ITIL Roles – IT Service Level
30
• Architecture supports with:
• Best practices:
• Business Process Modeling/Improvement
• SOA
• Models:
• Process
• Solution Architectures
• Analytics:
• System interdependencies/interactions
• Governance:
• Technology Standards
• ITIL supports with:
• Processes:
• Service Lifecycle Management
• Continuous Improvement
• Capacity Planning
• Governance:
• Service/Process Owners and Stewards
• Service Level Agreements

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

TOGAF Integration by
ITIL Stage and Process
• 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

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
means governing and
managing the Service
Portfolio, and identifying
new needed services
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
means EA and PPM
types of governance
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
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
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.
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.
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)
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
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)

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
alignment and value
assessments for work
packages that have
submitted change
requests. (EA)
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
alignment and value
assessments for work
packages that have
submitted change
requests. (EA)
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

Other Considerations - Process
• 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 - Data
• 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 - Governance
62
• 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.

Integrating architecture and itil

More Related Content

What's hot

Viewers also liked

Similar to Integrating architecture and itil

Recently uploaded

Integrating architecture and itil