Architecture management
ITIL® 4 Practice Guide
AXELOS.com
26th
February
2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
2
Architecture management
Contents
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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
AXELOS Copyright
View Only – Not for Redistribution
© 2020
1
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
3
4
Architecture management
2
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
5
6
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Product and service architecture
Definition: Product and service architecture
A formalized description of an organization's products and services, their components and interrelationships 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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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,
services, information systems and
technologies)
Service design
Implementation of the
architecture road map
Project management
Change enablement
Organizational change management
Investment decision and
authorization of architecture
options
Portfolio management
Definition of the organization’s
direction and objectives
Strategy management
Detailed mapping of
configuration items and assets
Service configuration management
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
AXELOS Copyright
View Only – Not for Redistribution
© 2020
7
8
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
9
10
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Table 2.2 Example of key metrics for the practice success factors
Practice success factors
Key metrics
Ensuring that the organization's
strategy is supported with a
target architecture
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
Ensuring that the organization's
architecture is continually
evolving to the target state
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
AXELOS Copyright
View Only – Not for Redistribution
© 2020
3
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
11
12
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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,
policies and vision
Analyse the organization and
requirements
Architecture vision
Organizational strategy
Environmental factors
Organizational structure
Architecture principles and
Develop and agree architecture requirements
vision
Monitor the organization’s
architecture
Product and service portfolio
Programme and project portfolio
Customer portfolio
Architecture review reports
Audit reports
Figure 3.2 shows a workflow diagram of the process.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
13
14
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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 vision
Architecture committee develops
architecture vision for the organization and
agrees the vision with the executive leaders
IT architecture committee
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
Architecture principles and
requirements
Document current architecture
Service configuration data
Asset register
Third-party contracts
Product and service portfolio
Develop target architecture
Design standards, frameworks,
and guidelines
Design, agree, and communicate
architecture road map
Architectural assessment
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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
architecture vision and requirements.
IT architects analyse the IT
architecture vision and
requirements.
Document current
architecture
If the current architecture in the scope
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-todate, architects explore and
document current IT architecture.
Develop target
architecture
Architects, business analysts,
Architects, business analysts, and
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,
frameworks, and
guidelines
Based on the target architecture,
Based on the target IT
architects develop supporting
architecture, IT architects
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
communicate
Architects identify the most critical
gaps between the target and current
Architects identify the most
critical gaps between the target
AXELOS Copyright
View Only – Not for Redistribution
© 2020
15
16
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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
significant changes and events
Architecture (non-)conformance
reports
Project plans
Check for conformance to the
target architecture
Architecture review reports
Product backlogs
Escalate non-conformance
Change backlog
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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
significant changes and
events
When an architecturally significant change, project, or improvement
initiative is being planned, an architect is included in the approval
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 nonconformance
Identified non-conformances are escalated to the relevant authorities
(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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
17
18
Architecture management
4
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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
code
L
А
C
М
Т
Competency profile (activities and skills)
Leader Decision- making, delegating, overseeing other activities, providing
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
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
and requirements
Architecture committee
Architects
Product owners
Good knowledge of the
organization, its
environment,
portfolios, products,
resources, and
customers
Understanding of
architecture
management
frameworks
Develop and agree
architecture vision
Executive leaders
TLMC
Architecture committee
Architects
Product owners
Good knowledge of the
organization, its
environment,
portfolios, products,
resources, and
customers
Strategic thinking
Leadership skills
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Monitor the
organization’s
architecture
Executive leaders
TCA
Architecture committee
Architects
Product owners
Architecture management
Good knowledge of the
organization, its
environment,
portfolios, products,
resources, and
customers
Understanding of
architecture
management
frameworks
Strategic thinking
Development of a target architecture and road map
Identify requirements
Architects
TAC
Product owners
Good understanding of
the architecture vision
Resource managers
Document current
architecture
Architects
Analytical skills
Good understanding of
the current
architecture
TMA
Product owners
Resource managers
Good practical
knowledge of the
architecture’s
management
frameworks
Good understanding of
the organization’s
resources at the
documented
architecture level
Analytical skills
Develop target
architecture
Architecture committee TMC
Analytical skills
Architects
Good understanding of
the architecture vision
Product owners
Resource managers
Good understanding of
the current
architecture’s
strengths and
weaknesses
Good understanding of
external opportunities
and threats
Design standards,
frameworks, and
guidelines
Architecture committee TMC
Analytical skills
Architects
Good understanding of
the architecture vision
Product owners
Resource managers
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Good understanding of
the current
architecture’s
19
20
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
strengths and
weaknesses
Good understanding of
external opportunities
and threats
Design, agree, and
communicate
architecture road map
Architecture committee MTCL
Architects
Product owners
Resource managers
Good understanding of
organization’s capacity
and constraints,
understanding of
business priorities.
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
significant changes and
Change authorities
events
T
Good understanding of
the architectural
impact of initiatives
and events
TM
Good knowledge of the
agreed target
architecture, good
understanding of the
agreed architecture
road map, including
controls
Project managers
Continual improvement
managers
Product owners
Risk managers
Internal auditors
Check for conformance
to the target
architecture
Architects
Product owners
Architecture committee
Analytical skills
Communication skills
Escalate nonconformance
Architects
CA
Product owners
Good communication
skills
Architecture committee
Review progress against Architects
the architecture road
Product owners
map
Good knowledge of the
agreed controls
AC
Good knowledge of the
architecture road map
Analytical and
AXELOS Copyright
View Only – Not for Redistribution
© 2020
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture committee
Architecture management
communication skills
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
21
22
Architecture management
5
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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
organization and
requirements
Communication and Collection, processing, High
collaboration tools and presentation of
data from diverse
Analytical systems sources
Knowledge
management tools
Develop and agree
architecture vision
Communication and Collaboration and
collaboration tools information sharing
Monitor the
organization's
architecture
Communication and Collection, processing, High
collaboration tools and presentation of
data from diverse
Analytical systems sources
Knowledge
management tools
Reporting engines
Dashboard systems
Development of a target architecture and road map
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Medium
Architecture management
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Identify and
requirements
Analytical systems
Collection, processing, Medium
and presentation of
data from diverse
sources
Enterprise
architecture
management tools
Reporting engines
Document current
architecture
Enterprise
architecture
management tools
Architecture mapping
and analysis
High
Develop target
architecture
Enterprise
architecture
management tools
Architecture mapping
and analysis
High
Design controls,
frameworks, and
guidelines
Enterprise
architecture
management tools
Architecture mapping
and analysis
High
Communication and
collaboration tools
Process design
Workflow and task
management systems
Design, agree, and
Enterprise
communicate
architecture
architecture road map management tools
Architecture mapping High
and analysis, road map
mapping
Communication and Collaboration and
collaboration tools information sharing
Ongoing architecture control
Identify
architecturally
significant changes
and events
Workflow
management and
work planning tools,
ITSM toolsets,
enterprise
architecture
management tools
Work planning,
assessment and
approval flows and
controls
High
Event detection and
correlation
Monitoring and event
management tools
Check for
conformance to the
target architecture
Enterprise
architecture
management tools
Escalate nonconformance
Communication and Collaboration and
collaboration tools information sharing
Review progress
Enterprise
against the
architecture
architecture road map management tools
Architecture mapping Medium
and analysis, road map
mapping
Medium
Architecture mapping High
and analysis, road map
mapping
AXELOS Copyright
View Only – Not for Redistribution
© 2020
23
24
Architecture management
6
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
7
AXELOS Copyright
View Only – Not for Redistribution
© 2020
Architecture management
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.
AXELOS Copyright
View Only – Not for Redistribution
© 2020
25
26
Architecture management
8
Acknowledgments
AXELOS Copyright
View Only – Not for Redistribution
© 2020
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
AXELOS Copyright
View Only – Not for Redistribution
© 2020