ITIL 4: The Practice Guides

ITIL®
OFFICIAL
PUBLISHER
Published by TSO (The Stationery Office), part of Williams Lea,
and available from:

Online
www.tsoshop.co.uk

Mail, Telephone, Fax & E-mail

TSO
PO Box 29, Norwich, NR3 1GN
Telephone orders/General enquiries: 0333 202 5070
Fax orders: 0333 202 5080
E-mail: customer.services@tso.co.uk
Textphone 0333 202 5077
Architecture management
ITIL® 4 Practice Guide
AXELOS.com
2 Architecture management

Contents
1 About this document 3
2 General information 4
3 Value streams and processes 11
4 Organizations and people 18
5 Information and technology 22
6 Partners and suppliers 24
7 Important reminder 25
8 Acknowledgments 26
 Architecture management 3

1 About this document

This document provides practical guidance for architecture management practice. It is split into
five main sections, covering:
● general information about the practice
● The practice’s processes and activities and their roles in the service value chain
● the organizations and people involved in the practice
● the information and technology supporting the practice
● considerations for partners and suppliers for the practice.
1.1 ITIL® 4 QUALIFICATION SCHEME
Selected content from this document is examinable as a part of the following syllabus:
● ITIL Specialist High-velocity IT.
Please refer to the respective syllabus document(S) for details.
4 Architecture management

2 General information
2.1 PURPOSE AND DESCRIPTION

Key message

The purpose of the architecture management practice is to explain the different elements that
form an organization. This practice explains how the elements interrelate to enable the
organization to effectively achieve its current and future objectives. It provides the principles,
standards, and tools that enable an organization to manage complex change in a structured and
agile way.

A comprehensive architecture management practice applies to all levels of an organization’s

architecture. This includes the following:
● business architecture
● product and service architecture
● information systems architecture, including data and applications architecture
● technology architecture
● environmental architecture.

The scope of the practice is defined by an organization’s position, vision, and strategy. For
example, the architecture management practice of an internal IT service provider is likely to focus
on the architecture of its products, services, information systems and technology. In other cases,
the lower levels of technology architecture might be excluded from the scope, if third parties
provide the infrastructure and platform for the organization. This is also likely to be reflected in
the IT systems architecture. However, the architecture management practice should be developed
consistently at all levels of the organization, as well as at all levels of the architecture.

The architecture management practice should describe the organization’s service value system and
resources of all four dimensions of service management, which are:
● organization and people
● information and technology
● processes and value streams
● suppliers and partners.

This is illustrated in Figure 2.1.

 Architecture management 5

Figure 2.1 Architecture levels and the four dimensions of service management

The architecture management practice ensures that:

● the organization’s current architecture is understood and mapped to the organization’s strategy
● the target organization’s architecture is identified and agreed
● the organization’s architecture is continually optimized to achieve the target architecture.

To meet these objectives, architects analyse the organization and describe its current
architecture. The architecture is then assessed to identify optimization points that currently are or
could become obstacles for the organization’s strategy realization. The target architecture is
defined to resolve these obstacles. This practice allows the organization to evolve from its current
architecture to the desired architecture; it also allows for ongoing course corrections, as the
organization’s strategy and environment change.

2.2 TERMS AND CONCEPTS

There are several types, or levels, of architecture, that can be included within the scope of the
practice. These are described in further detail below.

Business architecture

Definition: Business architecture

A formalized description of how an organization uses its resources for realizing its strategy and
objectives.

Business architecture explores how an organization’s resources are used to co-create value within
the organization and with its stakeholders. Organizations use resources to create products and
offer and deliver services based on these products.
6 Architecture management

Product and service architecture

Definition: Product and service architecture

A formalized description of an organization's products and services, their components and inter-
relationships and the principles and guidelines governing their design and evolution over time.

Product and service architecture provides an overview of an organization’s products and services.
It also explores the interactions between the services and models that describe the structure, such
as how the components fit together, and the dynamics, such as the activities, flow of resources,
and interactions, of each product and service. These models can be used as templates for multiple
products and services. Digital products and services are based on applications and data, as well as
supporting information technologies, operational technologies and communication technologies.

Information systems architecture

Definition: Information systems architecture

A formalized description of an organization's applications, data assets and data management

resources. Information systems architecture shows how applications and data are interconnected
and managed for the benefit of the organization.

Information systems use supporting infrastructure and platforms, incorporating information,

operational, and communication technologies. These are described by the technology architecture.

Technology architecture

Definition: Technology architecture

A formalized description of an organization's technology infrastructure, including information,

operational and communication technologies, their inter-relationships and the way they support
the organization's information systems.

Environmental architecture

Definition: Environmental architecture

A formalized description of external factors impacting the organization and the drivers for change,
as well as all aspects, types, and levels of environmental control and their management.

Organizations might find it useful to maintain an account of the environment in which they operate
in, to ensure that its products and services are suitable for these environments and do not conflict
with external constraints.

Environmental architecture includes: developmental, technological, business, operational,

organizational, political, economic, legal, regulatory, ecological, and social influences. It helps
organizations understand and manage its position within the ecosystem it operates in.

The architecture management practice includes the definition of the scope and structure of the
architecture, which is based on the organization’s strategy and positioning.
 Architecture management 7

2.3 SCOPE
The scope of the architecture management practice includes:
● understanding and describing the organization’s current architecture
● defining the target organization’s architecture and agreeing it with the relevant stakeholders
● continual optimization of the organization to meet the target architecture
● ensuring continual oversight of the ongoing changes to ensure they are aligned with the agreed
target architecture.

There are several activities and areas of responsibility that are not included in the architecture
management practice, although they are still closely related to it. These are listed in Table 2.1,
along with references to the practices in which they can be found. It is important to remember
that ITIL practices are merely collections of tools to use un the context of value streams; they
should be combined as necessary, depending on the situation.

Table 2.1 Activities related to the architecture management practice described in other practice
guides
Activity Practice guide

Solution design (products, Service design

services, information systems and
technologies)

Implementation of the Project management

architecture road map
Change enablement

Organizational change management

Investment decision and Portfolio management

authorization of architecture
options

Definition of the organization’s Strategy management

direction and objectives

Detailed mapping of Service configuration management

configuration items and assets
IT asset management

2.4 PRACTICE SUCCESS FACTOR

Definition: Practice Success Factor

A complex functional component of a practice that is required for the practice to fulfil its purpose.

A practice success factor (PSF) is more than a task or activity, as it includes components of all four
dimensions of service management. The nature of the activities and resources of PSFs within a
practice may differ, but together they ensure that the practice is effective.

The architecture management practice includes the following PSFs:

● ensuring that the organization's strategy is supported with a target architecture
● ensuring that the organization's architecture is continually evolving to the target state
8 Architecture management

Ensuring that the organization's strategy is supported with a target

architecture
The organization’s architecture should be optimized to achieve and support its strategy. This will
require a target architecture model.

To develop an effective and realistic target architecture, architects need to understand the
following:
● the organization’s strategy and its current performance
● the organization’s current architecture, benefits, and constraints
● major pain points and its mapping to the architecture
● the organization’s portfolios and ongoing developments
● environmental factors and trends
● technology trends, risks, and opportunities
● other relevant trends and factors.

Analysing these areas will lead to an understanding of the current and desired state of the
organization from the architecture perspective. Current and target architecture models can be
developed based on this. The effectiveness of the architecture can be expressed in some of the
following characteristics, depending on the organization’s strategy:
● scalability
● cost-effectiveness
● compatibility with other organizations
● compliance to regulations
● agility
● sustainability
● security.

This is not a definitive list; other objectives can be created to ensure that the architecture is
effective.

As the strategies of organizations are likely to continually evolve, architecture modelling should
not be an isolated exercise. The current architecture model should be updated as the components
change, and the target architecture model should be reviewed as the strategy changes. These
updates initiate a review of an architecture road map (see 2.4.2).

Architecture analysis and target architecture planning are performed in close conjunction with
other practices (see 2.3 for a list of these practices). It is important to ensure that the
architecture models are correct, realistic, and that the understanding of the current and target
architectures is shared among stakeholders. Realistic architecture planning is based on a good
understanding of the current architecture, including legacy systems, constraints, vital business
functions and behaviour patterns, adopted by internal and external stakeholders. It is also
important to take other requirements and constraints into account, such as budgets, legislation,
and so on. Finally, good knowledge of the technology landscape, including emerging technologies
and industry trends, is important.

As well as a description of the target architecture, the road map should include recommendations
and requirements for: taxonomy, standards, guidelines, procedures, templates and tools, which
are to be used in architecturally important initiatives, such as product and service design,
changes, projects, and so on. This includes integrating the recommended architecture controls
into the relevant practices and value streams, to ensure that the activities of the organization
adhere to the agreed development direction.
 Architecture management 9

Ensuring that the organization's architecture is continually evolving to

the target state
To ensure that an organization is evolving to the target architecture, an architecture road map is
created. The road map is a collection of initiatives designed to change from the current
architecture to the target architecture. Where appropriate, these initiatives can be managed as
programmes or projects. Realizing the architectural changes involves several stakeholders and
practices, depending on the nature of the changes. The architecture management practice ensures
that the implemented changes follow the agreed road map and support the organization’s
evolution to its target architecture.

Key message

The transition from the current architecture to the target architecture is rarely a revolution.
Rather, it is an evolution enabled by a set of architectural principles, standards, and guidelines
that the organization agrees to follow. Some legacy solutions may coexist with newer solutions for
a significant time. Changes from the current architecture to the target architecture are always
subject to portfolio decisions and careful prioritization. The architecture management practice is
used to define the target architecture, and to maintain the agreed direction and pace of the
architectural evolution.

Another important aspect of the architecture management practice activities is to ensure that the
changes made to the organization’s resources, products, and services support the architecture’s
evolution, by following the recommended architectural taxonomy, standards, guidelines,
procedures, templates, and tools. They also should not contradict the architecture’s requirements
and principles. This implies that the architecture management practice is involved in every service
value stream that includes the introduction of new components, new third-party services, or other
changes that affect the architecture.

2.5 KEY METRICS

The effectiveness and performance of the ITIL practices should be assessed within the context of
the value streams to which each practice contributes. As with the performance of any tool, the
practice’s performance can only be assessed within the context of its application. However, tools
can differ greatly in design and quality, and these differences define a tool’s potential or
capability to be effective when used according to its purpose. Further guidance on metrics, key
performance indicators (KPIs), and other techniques that can help with this can be found in the
measurement and reporting practice guide.

Key metrics for the architecture management practice are mapped to its PSFs. They can be used
as KPIs in the context of value streams to assess the contribution of the practice to the
effectiveness and efficiency of those value streams. Some examples of key metrics are given in
Table 2.2.
10 Architecture management
Table 2.2 Example of key metrics for the practice success factors
Practice success factors
Ensuring that the organization's
strategy is supported with a
target architecture
Ensuring that the organization's
architecture is continually
evolving to the target state
Key metrics
Fulfilment of the agreed requirements for the target
architecture
Number and impact of architectural constraints limiting
realization of the organization’s strategy
Number and impact of strategic decisions not supported by the
architecture
Completeness and quality of the target architecture, based on
internal and independent assessments
Duration and impact of delays between the strategy update and
the alignment of the target architecture
The number and impact of changes implemented that did not
follow the agreed target architecture
Number and impact of architecturally significant changes that
have not been assessed for conformance to the agreed
architecture
Progress in fulfilling the architecture road map
 Architecture management 11

3 Value streams and processes

3.1 VALUE STREAM CONTRIBUTION
Like any other ITIL management practice, the architecture management practice contributes to
multiple value streams. It is important to remember that a value stream is never formed from a
single practice. The architecture management practice combines with other practices to provide
high-quality services to consumers. The main value chain activities to which this practice
contributes are:
● engage
● deliver and support
● design and transition
● improve
● obtain/build
● plan.

The contribution of the architecture management practice to the service value chain is shown in
Figure 3.1.

Figure 3.1: Heat map of the contribution of the architecture management practice to the service
value chain activities

3.2 PROCESSES
Each practice may include one or more processes and activities that may be necessary to fulfil the
purpose of that practice.

Definition: Process

A set of interrelated or interacting activities that transform inputs into outputs. A process takes
one or more defined inputs and turns them into defined outputs. Processes define the sequence of
actions and their dependencies.
12 Architecture management

Architecture management activities form three processes:

● architecture governance
● development of a target architecture and road map
● ongoing architectural control.

Architecture governance
This process includes the activities listed in Table 3.1 and transforms the inputs into outputs.

Table 3.1 Inputs, activities, and outputs of the architecture governance process
Key inputs Activities Key outputs

Organization’s principles, Analyse the organization and Architecture vision

policies and vision
Organizational strategy
Environmental factors
Organizational structure
Product and service portfolio
requirements
Architecture principles and
Develop and agree architecture requirements
vision
Monitor the organization’s
architecture

Programme and project portfolio

Customer portfolio

Architecture review reports

Audit reports

Figure 3.2 shows a workflow diagram of the process.

 Architecture management 13

Figure 3.2 Workflow of the architecture governance process

Table 3.2 provides examples of high-level descriptions of each of the activities of the architecture
governance process.
14 Architecture management

Table 3.2 Activities of the architecture governance process

Activity ‘Full stack’ architecture management IT architecture management

Analyse the organization
and requirements
Executive leaders of the organization define
the scope of the architecture management
activities and appoint an architecture
committee
CIO, IT architects, product
owners, and business analysts
review the available
information regarding the
organization’s vision, strategy,
and requirements, and appoint
an IT architecture committee

Develop and agree Architecture committee develops IT architecture committee

architecture vision
architecture vision for the organization and
agrees the vision with the executive leaders
develops the architecture
vision for digital products and
services, IT systems, and
supporting technology and
agrees the vision with CIO

Monitor the organization’s Based on periodic architecture review and
architecture audit reports, or on relevant exception
reports, executive leaders of the
organization review the effectiveness of the
architecture and architecture management
practice and provide input to the ‘analyse
the organization and requirements’ activity
Based on periodic architecture
review and audit reports, or on
relevant exception reports,
CIO, IT architects, product
owners, and business analysts
review the effectiveness of the
architecture and architecture
management practice and
provide input to the ‘analyse
the organization and
requirements’ activity

Development of a target architecture and road map

This process includes the activities listed in Table 3.3, and transforms the inputs into outputs.

Table 3.3 Inputs, activities, and outputs of the development of a target architecture and road map
process
Key inputs Activities Key outputs

Architecture vision Identify requirements Architectural assessment

Architecture principles and
requirements
Service configuration data
Asset register
Third-party contracts
Product and service portfolio
Document current architecture
Develop target architecture
Design standards, frameworks,
and guidelines
Design, agree, and communicate
architecture road map
report
Current architecture model
Target architecture model
Architecture controls,
frameworks, and guidelines
Agreed architecture road map

Programme and project portfolio

Customer portfolio

Figure 3.3 shows the workflow for the development of a target architecture and road map process.
 Architecture management 15

Figure 3.3 Workflow of the development of a target architecture and road map process

Table 3.4 provides examples of high-level descriptions of each of the activities of the development
of a target architecture and road map process.

Table 3.4 Activities of the development of a target architecture and road map process
Activity ‘Full stack’ architecture management IT architecture management

Identify requirements Architecture committee analyses the IT architects analyse the IT

architecture vision and requirements. architecture vision and
requirements.

Document current If the current architecture in the scope
architecture of requirements has not been
documented or is not up-to-date,
architects explore and document
current architecture at all levels, from
business architecture to technology
infrastructure.
If current IT architecture in the
scope of requirements has not
been documented or is not up-to-
date, architects explore and
document current IT architecture.

Develop target Architects, business analysts, Architects, business analysts, and

architecture relationship managers, and product product owners review the
owners review the current architecture current architecture to identify
to identify constraints and constraints and misalignment with
misalignment with the agreed the agreed architecture vision and
architecture vision and develop a model develop a model for target IT
for target architecture at all levels, architecture.
ensuring consistency between the
levels.

Design standards, Based on the target architecture, Based on the target IT

frameworks, and architects develop supporting architecture, IT architects
guidelines standards, guidelines, procedures, develop supporting standards,
templates, and tools to ensure effectiveguidelines, procedures,
integration in the relevant practices templates, and tools to ensure
and value streams. These are discussed effective integration into the
and agreed with stakeholders, including relevant practices and value
practice owners, product owners, and streams. These are discussed and
others. agreed with stakeholders,
including practice owners,
product owners, and others.

Design, agree, and Architects identify the most critical Architects identify the most
communicate gaps between the target and current critical gaps between the target
16 Architecture management

architecture road map architectures; they then propose an and current architectures. They
approach to migration and to ongoing then propose an approach to
architecture control. The road map migration and to ongoing
includes controls ensuring adherence to architecture control. The road
the agreed architecture throughout the map includes controls ensuring
organization. This work is supported by adherence to the agreed
product owners, risk managers, architecture throughout the
financial managers, and other relevant organization. This work is
leaders and experts. supported by product owners, risk
managers, financial managers,
The proposed architecture road map is and other relevant experts
discussed and approved by the
executive leaders. If not approved, the The proposed IT architecture road
road map is returned to one of the map is discussed with and
previous steps. approved by CIO. If it is not
approved, the road map is
Approved road map together with the returned to one of the previous
supporting standards, frameworks, steps.
guidelines, and controls are
communicated for a detailed planning Approved road map together with
and execution to the relevant teams, supporting standards, frameworks,
including programme and project guidelines, and controls are
managers, HR, portfolio and finance, communicated for detailed
product owners, and so on. planning and execution to
relevant teams, including
programme and project managers,
portfolio and finance, product
owners, and so on.

Ongoing architectural control

This process is focused on the implementation of the architecture road map and maintenance of
the agreed architecture. It includes the activities shown in Table 3.5 and transforms the inputs
into outputs.

Table 3.5 Inputs, activities, and outputs of the ongoing architectural control process
Key inputs Activities Key outputs

Agree architecture road map Identify architecturally Architecture (non-)conformance

significant changes and events reports
Change backlog
Check for conformance to the Architecture review reports
Project plans target architecture
Product backlogs Escalate non-conformance
Continual improvement register Review progress against the
architecture road map
Service configuration data

Asset register

Third-party contracts

Product and service portfolio

Figure 3.4 shows the workflow for the ongoing architectural control process.
 Architecture management 17

Figure 3.4 Workflow of the ongoing architectural control process

Table 3.6 provides examples of high-level descriptions of each of the activities of the ongoing
architectural control process.

Table 3.6 Activities of the ongoing architectural control process

Activity Examples

Identify architecturally When an architecturally significant change, project, or improvement

significant changes and initiative is being planned, an architect is included in the approval
events workflow. Identification of the architectural significance is performed by
the role responsible for planning, according to the agreed architecture
controls. This activity is applicable to all architecturally significant
initiatives, including those specifically created as part of the
architecture road map.

When an architecturally significant event is identified (a design error,

incorrect implementation, or a change bypassing an architecture
control), it is reported to an architect for review. Identification of these
events can be made by product owners, problem investigators, risk
managers, auditors, and others.

Check for conformance toAn architect reviews the proposed initiatives and reported events to
the target architecture assess conformance to the agreed target architecture model.

Initiatives that conform to the target architecture (including those

triggered by the architecture road map), are approved and their
processing continues in the respective value stream.

Events that conform to the to the target architecture are approved and
their processing continues in the respective value stream. If the agreed
approval procedure has been bypassed, the architect reports this to the
relevant authority (product owner, project manager, change manager,
continual improvement manager, or others).

Escalate non- Identified non-conformances are escalated to the relevant authorities

conformance (product owner, project manager, change authority, continual
improvement manager, CIO, architecture committee, or others).

Architects provide the necessary information to identify alternative

solutions that conform to the target architecture.

Review progress against After significant changes and fixed intervals, a progress report is
the architecture road produced by the architects that explains the implementation and
map maintenance of the architecture road map. The report is communicated
to the relevant stakeholders and serves as an input to the architecture
governance process.
18 Architecture management

4 Organizations and people

4.1 ROLES, COMPETENCIES, AND RESPONSIBILITIES
The practice guides do not describe the practice management roles such as practice owner,
practice lead, or practice coach. They focus instead on specialist roles that are specific to each
practice. The structure and naming of each role may differ from organization to organization, so
any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember,
roles are not job titles. One person can take on multiple roles and one role can be assigned to
multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a
competency profile based on the following model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Competency Competency profile (activities and skills)

code
Leader Decision- making, delegating, overseeing other activities, providing
L incentives and motivation, and evaluating outcomes
Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting,
А and initiating basic improvements
Coordinator/communicator Coordinating multiple parties, maintaining
C communication between stakeholders, and running of awareness campaigns
Methods and techniques expert Designing and implementing work techniques,
М documenting procedures, consulting on processes, work analysis, and continual
improvement
Technical expert Providing technical (IT) expertise and expertise-based assignments
Т

Table 4.2 Examples of roles with responsibility for architecture management activities
Activity Responsible roles Competency profile Specific skills

Architecture governance

Analyse the organization Executive leaders TCA Good knowledge of the

and requirements organization, its
Architecture committee environment,
portfolios, products,
Architects resources, and
customers
Product owners
Understanding of
architecture
management
frameworks

Develop and agree Executive leaders TLMC Good knowledge of the

architecture vision organization, its
Architecture committee environment,
portfolios, products,
Architects resources, and
customers
Product owners
Strategic thinking

Leadership skills
 Architecture management 19

Monitor the Executive leaders TCA Good knowledge of the

organization’s organization, its
architecture Architecture committee environment,
portfolios, products,
Architects resources, and
customers
Product owners
Understanding of
architecture
management
frameworks

Strategic thinking

Development of a target architecture and road map

Identify requirements Architects TAC Analytical skills

Product owners Good understanding of

the architecture vision
Resource managers
Good understanding of
the current
architecture

Document current Architects TMA Good practical

architecture knowledge of the
Product owners architecture’s
management
Resource managers frameworks

Good understanding of
the organization’s
resources at the
documented
architecture level

Analytical skills

Develop target Architecture committee TMC Analytical skills

architecture
Architects Good understanding of
the architecture vision
Product owners
Good understanding of
Resource managers the current
architecture’s
strengths and
weaknesses

Good understanding of
external opportunities
and threats

Design standards, Architecture committee TMC Analytical skills

frameworks, and
guidelines Architects Good understanding of
the architecture vision
Product owners
Good understanding of
Resource managers the current
architecture’s
20 Architecture management

strengths and
weaknesses

Good understanding of
external opportunities
and threats

Design, agree, and Architecture committee MTCL Good understanding of

communicate organization’s capacity
architecture road map Architects and constraints,
understanding of
Product owners business priorities.
Resource managers Good understanding of
organization’s value
streams and practices
affecting the
architecture

Communication and
negotiation skills,
presentation skills,
leadership skills

Ongoing architecture control

Identify architecturally Product owners T Good understanding of

significant changes and the architectural
events Change authorities impact of initiatives
and events
Project managers

Continual improvement
managers

Product owners

Risk managers

Internal auditors

Check for conformance Architects TM Good knowledge of the

to the target agreed target
architecture Product owners architecture, good
understanding of the
Architecture committee agreed architecture
road map, including
controls

Analytical skills

Communication skills

Escalate non- Architects CA Good knowledge of the

conformance agreed controls
Product owners
Good communication
Architecture committee skills

Review progress against Architects AC Good knowledge of the

the architecture road architecture road map
map Product owners
Analytical and
 Architecture management 21

communication skills
Architecture committee

Architect
The key practice-specific role is the architect. This role can be specialized, such as a business (or
enterprise) architect, IT architect, or solution architect, depending on the practice scope.

The role of an architect is key for the architecture management practice. As described in table 4.2
above, most practice activities are performed or managed by architects.

The key competencies of an architect include:

● understanding the business strategy, business model, and operating model of the organization
and the service consumers’ organizations
● understanding the environment in which the organization operates
● knowledge of technologies used by the organization and of developing technologies available to
the organization
● knowledge of the organization’s portfolios: resource, product and service, customer
● knowledge of the organization’s value streams and practices
● expertise in architecture management frameworks, such as Zachman FrameworkTM, TOGAF®
● expertise in relevant solution architecture frameworks, such as AWS, SOA, EMC, and so on.

The competence profile of an architect is TMCAL. Architects are experts in the organization’s
resources and architecture management methods. However, communication and leadership skills
are also important.

The responsibilities of architects within an organization may vary depending on the scope of the
practice. Whereas business (enterprise) architects are key contributors to an organization’s
strategic planning and business development, solution architects are focused on the architecture
of specific products or systems.

It is not unusual to find dedicated job roles to fulfil the architect role. However, in smaller
organizations the solution architect role is sometimes performed by product owners, and the
business architect role is performed by executive leaders, usually on an ad hoc basis.

4.2 ORGANIZATIONAL STRUCTURES AND TEAMS

When organizations develop the architecture management practice, many find it useful to
establish a team to drive architecture-related initiatives and to ensure ongoing architecture
control. This is often known as the architecture committee and includes representatives from
different levels and functions of the organization. Besides architects, this committee typically
includes business function leaders, product owners, service designers, risk managers, portfolio
managers, HR managers, and financial managers.

The architecture committee, which is sometimes called an architecture board, usually reports to
the executive leadership team; the committee’s decisions affect all areas of the organization.
Therefore, it is important to ensure that the committee has enough authority.
22 Architecture management

5 Information and technology

5.1 INFORMATION EXCHANGE
The effectiveness of the architecture management practice is based on the quality of the
information used. This includes, but is not limited to, information about:
● organization’s strategy
● organization’s environment, key stakeholders
● organization’s portfolios: resources, products and services, customers
● service configuration and IT asset information
● change schedule
● programme and project portfolio
● continual improvement register
● organizational structure
● technology trends.

This information may take various forms. The key inputs and outputs of the practice are listed in
section 3.

5.2 AUTOMATION AND TOOLING

The automation of the architecture management practice is focused around three main areas that
enhance information exchange:
● office automation tools: document, spreadsheet, and presentation tools
● analysis and modelling tools, such as: computer-aided design, diagramming, and data modelling
tools
● Communication tools, such as: workflow, task management, and omnichannel communication
systems.

Table 5.1 lists specific methods of automation relevant to each activity of the architecture
management practice.

Table 5.1. Automation solutions for architecture management activities

Activity Means of automation Key functionality Impact on the effectiveness of
the practice

Architecture governance

Analyse the Communication and Collection, processing, High

organization and collaboration tools and presentation of
requirements data from diverse
Analytical systems sources

Knowledge
management tools

Develop and agree Communication and Collaboration and Medium

architecture vision collaboration tools information sharing

Monitor the Communication and Collection, processing, High

organization's collaboration tools and presentation of
architecture data from diverse
Analytical systems sources

Knowledge Reporting engines

management tools Dashboard systems

Development of a target architecture and road map

 Architecture management 23

Identify and Analytical systems Collection, processing, Medium

requirements and presentation of
Enterprise data from diverse
architecture sources
management tools
Reporting engines

Document current Enterprise Architecture mapping High

architecture architecture and analysis
management tools

Develop target Enterprise Architecture mapping High

architecture architecture and analysis
management tools

Design controls, Enterprise Architecture mapping High

frameworks, and architecture and analysis
guidelines management tools
Process design
Communication and
collaboration tools

Workflow and task

management systems

Design, agree, and Enterprise Architecture mapping High

communicate architecture and analysis, road map
architecture road map management tools mapping

Communication and Collaboration and

collaboration tools information sharing

Ongoing architecture control

Identify Workflow Work planning, High

architecturally management and assessment and
significant changes work planning tools, approval flows and
and events ITSM toolsets, controls
enterprise
architecture Event detection and
management tools correlation

Monitoring and event

management tools

Check for Enterprise Architecture mapping Medium

conformance to the architecture and analysis, road map
target architecture management tools mapping

Escalate non- Communication and Collaboration and Medium

conformance collaboration tools information sharing

Review progress Enterprise Architecture mapping High

against the architecture and analysis, road map
architecture road map management tools mapping
24 Architecture management

6 Partners and suppliers

The organization’s architecture should support its strategy and ensure that all components of the
organization effectively contribute to its success. The architecture is not limited to the
organization’s own resources. This includes the organization’s service portfolio and the way it
interacts with its service consumers. However, third-party services should not be underestimated.

At the business architecture level, important trends include multi-sourcing, service integration and
management (or on the other hand disintermediation). At the technology architecture level,
digitization and the resulting third-party cloud services are the main trend affecting the
architecture.

Both business and technology trends influence the product and service architecture. This should be
reflected in the organization’s architecture and considered when planning target architectures and
road maps. To address this, the architecture management practice should be conducted in close
conjunction with other practices, including: portfolio management, supplier management,
organizational change management, risk management, infrastructure and platform management,
and of course strategy management.
 Architecture management 25

7 Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an
organization might consider when establishing and nurturing their own practices. The practice
guides are catalogues of things that organizations might think about, not a list of answers. When
using the content of the ITIL practice guides, organizations should always follow the ITIL guiding
principles:
● focus on value
● start where you are
● progress iteratively with feedback
● collaborate and promote visibility
● think and work holistically
● keep it simple and practical
● optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of the
ITIL® Foundation: ITIL 4 Edition publication.
26 Architecture management

8 Acknowledgments
AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance.
These practice guides incorporate an unprecedented level of enthusiasm and feedback from across
the ITIL community. In particular, AXELOS would like to thank the following people.

8.1 AUTHORS
Pavel Demin, Roman Jouravlev

8.2 REVIEWERS
Dinara Adyrbayeva, Anton Lykov, Irina Matantseva