ISO/IEC/IEEE 42020:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2019-07
Software, systems and enterprise —
Architecture processes
Logiciel, systèmes et entreprise - Processus d'architecture
Reference number
©
ISO/IEC 2019
©
IEEE 2019
© ISO/IEC 2019
© IEEE 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2019 – All rights reserved
ii © IEEE 2019 – All rights reserved

Contents Page
Foreword .vi
0  Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 6
4.1 General . 6
4.2 Approach to conformance . 6
4.3 Full conformance cases . 6
4.4 Tailored conformance . 7
5 Process overview and application . 7
5.1 General . 7
5.2 Relationship of architecture to other processes and information elements . 9
5.3 Architecture Governance and Management processes .10
5.4 Architecture Conceptualization, Evaluation and Elaboration processes .10
5.5 Architecture Enablement process .12
5.6 Relationship of architecture to design .12
5.7 Architecture adaptation .13
5.8 Process application .13
5.8.1 Criteria for processes .13
5.8.2 Description of processes .14
5.8.3 General characteristics of processes .14
5.8.4 Tailoring .14
6 Architecture Governance process .15
6.1 Purpose .15
6.2 Outcomes .15
6.3 Implementation .15
6.4 Activities and tasks .15
6.4.1 Prepare for and plan the architecture governance effort .15
6.4.2 Monitor, assess and control the architecture governance activities .17
6.4.3 Establish architecture collection objectives .17
6.4.4 Make architecture governance decisions .18
6.4.5 Monitor and assess compliance with governance directives and guidance .19
6.4.6 Review implementation of governance directives and guidance .20
6.5 Work products .20
7 Architecture Management process .20
7.1 Purpose .20
7.2 Outcomes .20
7.3 Implementation .21
7.4 Activities and tasks .21
7.4.1 Prepare for and plan the architecture management effort .21
7.4.2 Monitor, assess and control the architecture management activities .22
7.4.3 Develop architecture management approach.23
7.4.4 Perform management of the architecture collection .24
7.4.5 Monitor architecting effectiveness .25
7.4.6 Prepare for completion of the architecture management plan .26
7.5 Work products .26
8 Architecture Conceptualization process.27
8.1 Purpose .27
8.2 Outcomes .27
8.3 Implementation .27
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved iii

8.4 Activities and tasks .28
8.4.1 Prepare for and plan the architecture conceptualization effort .28
8.4.2 Monitor, assess and control the architecture conceptualization activities .29
8.4.3 Characterize problem space .30
8.4.4 Establish architecture objectives and critical success criteria .31
8.4.5 Synthesize potential solution(s) in the solution space .32
8.4.6 Characterize solutions and the tradespace .33
8.4.7 Formulate candidate architecture(s) .35
8.4.8 Capture architecture concepts and properties .36
8.4.9 Relate the architecture to other architectures and to relevant affected entities .37
8.4.10 Coordinate use of conceptualized architecture by intended users .37
8.5 Work products .38
9 Architecture Evaluation process .38
9.1 Purpose .38
9.2 Outcomes .39
9.3 Implementation .39
9.4 Activities and tasks .40
9.4.1 Prepare for and plan the architecture evaluation effort .40
9.4.2 Monitor, assess and control the architecture evaluation activities .41
9.4.3 Determine evaluation objectives and criteria .42
9.4.4 Determine evaluation methods and integrate with evaluation objectives
and criteria .43
9.4.5 Establish measurement techniques, methods and tools .43
9.4.6 Collect and review evaluation-related information .44
9.4.7 Analyze architecture concepts and properties and assess stakeholder value.44
9.4.8 Characterize architecture(s) based on assessment results .45
9.4.9 Formulate findings and recommendations .46
9.4.10 Capture and communicate evaluation results .46
9.5 Work products .47
10 Architecture Elaboration process .47
10.1 Purpose .47
10.2 Outcomes .47
10.3 Implementation .48
10.4 Activities and tasks .48
10.4.1 Prepare for and plan the architecture elaboration effort .48
10.4.2 Monitor, assess and control the architecture elaboration activities.49
10.4.3 Identify or develop architecture viewpoints .50
10.4.4 Develop models and views of the architecture(s) .51
10.4.5 Relate the architecture to other architectures and to relevant affected entities .52
10.4.6 Assess the architecture elaboration .52
10.4.7 Coordinate use of elaborated architecture by intended users .53
10.5 Work products .53
11 Architecture Enablement process .54
11.1 Purpose .54
11.2 Outcomes .54
11.3 Implementation .54
11.4 Activities and tasks .54
11.4.1 Prepare for and plan the architecture enablement effort .54
11.4.2 Monitor, assess and control the architecture enablement activities .55
11.4.3 Manage the architecture process enablers .56
11.4.4 Acquire, develop and establish enabling capabilities, services and resources .56
11.4.5 Deploy enabling capabilities, services and resources .57
11.4.6 Improve architecture enablement capabilities, services and resources .57
11.5 Work products .58
Annex A (normative) Tailoring process .59
Annex B (informative) Defining metrics for architecture processes .63
© ISO/IEC 2019 – All rights reserved
iv © IEEE 2019 – All rights reserved

Annex C (normative) Interactions with other processes and uses of architecture .66
Annex D (informative) Relationship with other standards.71
Annex E (informative) Notes on terms and concepts .72
Annex F (informative) Architecture enablement and process-enabling resources.91
Annex G (informative) Architecture governance and management .93
Annex H (informative) Mapping of processes to architecture frameworks .95
Bibliography .108
IEEE notices and abstract .111
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved v

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
rules given in the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards
Development Organization cooperation agreement between ISO and IEEE.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
© ISO/IEC 2019 – All rights reserved
vi © IEEE 2019 – All rights reserved

0  Introduction
0.1  Rationale for architecture processes
The complexity of human-made systems has grown to an unprecedented level, which leads to new
opportunities and greater challenges for organizations that create, trade and utilize systems. To
address these opportunities and challenges, it is increasingly necessary to apply concepts, principles,
procedures and tools to make better architecture-related decisions, more effective architectures,
better architecture strategy and increased architecture maturity. Architecture-related activities are
now strategic aspects of projects and enterprises, and the use of architecture frameworks has become
common practice in commercial, government, civil and military domains.
Architecture is increasingly applied to systems—and to other entities that are not traditionally
considered to be systems, such as enterprises, services, data, business functions, mission areas, product
lines, families of systems, software items, etc. The concept of architecture used in this document goes
beyond the traditional use where the architecture entity is a system. This allows for a more generalized
usage of architecture when the processes in this document are applied. These entities are becoming
more complex and architecture practices are increasingly adopted to manage the complexity.
Within enterprises and the engineering disciplines, acknowledgement is increasing for the value
added by architecture, both as a practice and in the realization of artifacts that guide engineering and
management activities.
This document complements the architecture-related processes identified in ISO/IEC/IEEE 15288,
ISO/IEC/IEEE 12207 and ISO 15704 with activities and tasks that enable architects and others to more
effectively and efficiently implement architecture practices. Implementing these practices can help
ensure that the architecture has greater influence on business and mission success.
0.2  Use of the term architecture in this document
This document uses the term architecture in a broad sense. When the word architecture is used without
any qualifier the word refers to the general case where the architecture entails the fundamental concepts
and properties of an architecture entity. When a qualifier is prepended to the word architecture, this
indicates that the architecture applies to that entity, such as in the following cases:
— System Architecture: When the entity is a system.
— Enterprise Architecture: When the entity is an enterprise.
The following are kinds of architecture entities that can be dealt with by the architecture processes
of this document: enterprise, organization, solution, system (including software systems), subsystem,
business, data (as a data element or data structure), application, information technology (as a collection),
mission, product, service, software item, hardware item, etc. The kind of entity can also be a product
line, family of systems, system of systems, collection of systems, collection of applications, etc.
There can be cases where the word architecture is prepended by the subject of interest, not by the entity
being architected, such as in the following examples: security architecture, functional architecture,
physical architecture and so on. See E.4.1 for more examples.
Finally, there are cases when the word architecture is prepended by the purpose of the architecture, for
example integration architecture, coherence architecture, design-control architecture, etc. See E.4.1 for
more examples.
0.3  Purpose
The purpose of this document is to set the standard of performance for the governance, management,
conceptualization, evaluation and elaboration of architectures, and activities that enable these
processes. This document can be used as a process reference model in establishing architecture
practice and be used across a range of contexts and situations. It provides guidance in conforming to
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved vii

the architecture processes specified in this document, and, in a larger context, to facilitate trading in
systems, products and services.
0.4  Field of application
The processes specified in this document apply in the context of:
— understanding, developing and evolving entities through their life cycle stages such as conception,
development, implementation, operation, sustainment, decommissioning and disposal;
— the type of architecture to be developed;
— organization(s) acting as users, customers and providers of the solution specified by the architecture
description; and
— architecting of entities.
The intent is to provide processes applicable across a wide spectrum of architecting domains (such
as the enterprise, systems, services and software domains) for use by a broad range of architects and
users of these practices.
When the entity is a system then it is necessary to consider that:
— Systems can vary widely in terms of purpose, domain of application, complexity, size, novelty,
adaptability, qualities, locations, life spans and evolution. This document specifies processes for the
development and use of architecture that involves human-made systems including one-of-a-kind
systems, mass-produced systems and customized, adaptable systems either as a complete stand-
alone system or systems embedded and integrated into larger, more complex and complete systems.
— Systems addressed by this document can be configured with one or more of the following kinds
of system elements: hardware, software, data, humans, processes (e.g. processes for providing
services to users), procedures (e.g. operator instructions), facilities, materials and naturally
occurring entities.
— The processes in this document can be used to define the architecture of a system as well as
to independently define the architecture of a system of systems involving that system or the
architecture of an element of that system, such as a software, data or hardware item.
0.5  Reference model for processes
This document provides a process reference model defined according to the ISO/IEC TR 24774
guidelines. This process reference model is characterized by process purpose and process outcomes
that result from the successful execution of the relevant tasks in each of the process activities, and
the creation of relevant work products, following the process constructs of ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 12207. Therefore, this document is useful to support process assessment as specified in
ISO/IEC 33002. ISO/IEC/IEEE 15288:2015, Annex C provides information regarding the use of processes
as a process reference model.
The processes specified in this document are applicable:
— concurrently, iteratively, incrementally and recursively to an architecture entity or its elements; and
— for the management and control of portfolios, programs and projects pertaining to the entities
being architected.
0.6  Intended audience
The architecture processes specified in this document apply in the context of an enterprise or an
extended enterprise, as well as on individual organizations or projects within the enterprise.
This document is applicable to organizations in their roles as both acquirers and suppliers of architected
entities or their elements, and is useful for a single organization in a self-imposed mode or in a multi-
© ISO/IEC 2019 – All rights reserved
viii © IEEE 2019 – All rights reserved

party situation involving agreements between parties. Parties can be from the same organization or
from different organizations and the situation can range from informal agreements to formal contracts.
The principal intended users of this document are architects and others who create, express, evaluate,
communicate and document architectures. Other users include:
— clients, acquirers, designers, service providers, sub-contractors, users and operators of systems
and others who need to understand architectures;
— developers and other stakeholders who need to understand, interpret and analyze architecture
descriptions to establish, maintain and transform enterprises, systems or other entities;
— chief information officers, chief engineers, program/enterprise managers, auditors, independent
assessors and those who oversee and evaluate architecture entities and their development;
— managers of architecting endeavors who establish, plan, monitor and control such undertakings;
— people involved in enterprise-wide activities that span development of multiple systems products,
services and software, including those that seek to establish and codify architecture frameworks,
architecture viewpoints and architecting methods;
— business analysts who need to understand the norms for the architecture process and process
outcome sufficiently in order to verify whether a given architecture description (a) is consistent
with their stakeholder needs, and (b) does not risk leaving any of their needs unsatisfied or
contradicted; and
— developers of tools and methods used in support of architecting practices, architecture governance
and management, and enablement of architecture process implementation.
Additional users include researchers who can use this document to provide a common framework for
expressing their research discoveries related to novel methods or techniques that enable or improve the
practices of architecting, architecture governance and architecture management, as well as improving
the enablement of these practices.
0.7 Benefits from use of this document
This document provides a process framework that:
— contributes to the identification of job roles and responsibilities in the organization, along with
requisite skills and competencies;
— facilitates proper oversight, accountability, consistent governance and management, and alignment
within and between architectures;
— enables proper implementation of architecture governance directives and change management of
architectures; and
— facilitates the effective planning and tracking of the architecture effort.
A set of well-specified architecture activities results in:
— an architecting capability that is applicable to all architecture efforts, irrespective of size and
complexity;
— a framework that provides a consistent approach for developing an architecture based on addressing
stakeholder concerns and for identifying the aspects of the architecture that would be required to
address those concerns;
— standardized architecture approaches that can be adopted by enterprise, system, information
technology, software, product and service architects;
— an effective mechanism that facilitates the understanding and communication of the problem and
corresponding solution to various stakeholders; and
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved ix

— a common vocabulary that facilitates communication between stakeholders.
Various groups and individuals benefit from the use of standardized architecture processes, including:
— solution acquirers in helping them characterize the business context, evaluate providers' proposals,
identify alternatives, make informed decisions, and in facilitating collaboration between providers
who will work together on architecture development and governance;
— solution providers in helping them understand the problem/request, elaborate a proposal in their
solution space, and define and justify their deliveries;
— solution users in helping them express the operational context, characterize their needs and
evaluate providers' proposals in the context of their problem space;
— decision makers and program/project managers in helping them consider a range of options during
creation and usage of architectures which are considered as a source of information and as a basis
for the rationale when decisions are made; and
— other bodies such as legal, safety and security authorities, in helping them assess compliance with
standards, policies, directives, treaties, regulations and laws.
0.8  Limitations
No formal traceability is made between ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207, ISO 15704 and this
document. Consequently, meeting all requirements in this document does not necessarily mean that all
requirements related to architecture processes specified in those other documents are met.
This document does not specify a particular life cycle model to be used when applying these processes.
The ISO/IEC/IEEE 24748 series provides guidance for life cycle definition and application of life
cycle processes. Although this document does not establish a management system, the intent of this
specification is to be compatible with the quality management system provided by ISO 9001, the
service management system provided by ISO/IEC 20000-1 (also published as IEEE Std 20000-1), and
the information security management system provided by ISO/IEC 27000.
This document does not specify detailed information items in terms of format, explicit content and
recording media. ISO/IEC/IEEE 15289 addresses the content for life cycle process information items
(documentation).
This document does not specify any particular architecture framework or architecture documentation
standard.
© ISO/IEC 2019 – All rights reserved
x © IEEE 2019 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 42020:2019(E)
Software, systems and enterprise — Architecture
processes
1 Scope
This document establishes a set of process descriptions for the governance and management of
a collection of architectures and the architecting of entities. This document also establishes an
enablement process description that provides support to these other architecture processes.
The processes defined in this document are applicable for a single project, as well as for an organization
performing multiple projects. These processes are applicable throughout the life of an architecture or a
collection of architectures. These processes are applicable for managing and performing the activities
within any stage in the life cycle of the architecture entities.
Annex D describes the relationships between this document and other standards.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
— IEEE Standards Dictionary Online: available at http: //ieeexplore .ieee .org/xpls/dictionary .jsp
NOTE Definitions for other terms typically can be found in ISO/IEC/IEEE 24765, which provides the
vocabulary for system and software engineering, available at www .computer .org/sevocab.
3.1
activity
set of cohesive tasks (3.23) of a process (3.16)
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.3]
3.2
architecting
conceiving, defining, expressing, documenting, communicating, certifying proper implementation of,
maintaining and improving an architecture (3.3) throughout the life cycle (3.11) for an architecture
entity (3.6)
Note 1 to entry: The entity to be architected can be of several kinds, as illustrated in the following examples:
system, enterprise (3.9), solution, business, data, application, information technology, mission, product, service,
software, etc. See E.4 for more information on this topic.
Note 2 to entry: Certifying the proper implementation of an architecture is sometimes captured as a formal
statement by the architect to the client or user that the system, as built, meets the criteria as ready for use.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 1

[SOURCE: ISO/IEC/IEEE 42010:2011, 3.1 modified — The word “system” has been replaced with
“architecture entity”; the original NOTE has been removed; Notes 1 and 2 to entry have been added.]
3.3
architecture
fundamental concepts or properties of an entity in its environment and governing principles for the
realization and evolution of this entity and its related life cycle (3.11) processes (3.16)
Note 1 to entry: Architecture entity (3.6) is the term used in this document when referring to the entity being
architected or the entity subject to architecture processes. The fundamental concepts or properties of the
architecture entity are usually intended to be embodied in the entity’s components, the relationships between
components, and the relationships between the entity and its environment.
Note 2 to entry: The concept of architecture used in this document applies broadly to the entity being architected
or evaluated. This allows for a more generalized usage when the elements in this document are applied.
Note 3 to entry: The entity to be architected can be of several kinds, as illustrated in the following examples:
enterprise (3.9), organization (3.14), solution, system, subsystem, business, data (as a data element or data
structure), application, information technology (as a collection), mission, product, service, software item,
hardware item, product line, family of systems, system of systems, etc. It also spans the variety of applications
that utilize digital technology such as mobile, cloud, big data, robotics, Internet of things (IoT), web, desktop,
embedded systems and so on.
Note 4 to entry: Representation of the concepts or properties of an entity and governing principles is captured in
architecture models (3.13).
Note 5 to entry: Architectures can address a wide range of concerns (3.8) expressed, for example, through
architecture views (3.24) and models, as illustrated in the following examples associated with particular
kinds of architectures such as: security architecture, functional architecture, physical architecture, resilience
architecture, etc.
3.4
architecture collection
group of architectures (3.3) held by an organization (3.14) that is subject to governance and management
by the organization as a whole
Note 1 to entry: The architectures in the collection can have relationships with each other (as in the case of
product lines). The architectures in the collection can be based on the same reference architecture.
3.5
architecture description
work product (3.26) used to express an architecture (3.3)
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.3, modified — The abbreviated term has been removed.]
3.6
architecture entity
thing being considered, described, discussed, studied or otherwise addressed during the architecting
(3.2) effort
EXAMPLE The following are kinds of architecture entities that can be dealt with by the architecture (3.3)
processes (3.16): enterprise (3.9), organization (3.14), solution, system (3.22) (including software systems),
subsystem, business, data (as a data element or data structure), application, information technology (as a
collection), mission, product, service, software item, hardware item, product line, family of systems, system of
systems, collection of systems, collection of applications, etc.
Note 1 to entry: When referring to the architecture itself of these architecture entities, it is common practice to
place the name of the kind of entity in front of the word architecture. For example, the phrase system architecture
is used when the thing being dealt with during the architecting effort is a system. Likewise, for the other kinds of
entities that are being dealt with during the architecting effort.
© ISO/IEC 2019 – All rights reserved
2 © IEEE 2019 – All rights reserved

3.7
architecture framework
conventions, principles and practices for use by architecture-related (3.3) activities that have been
established within a specific domain of application or community of stakeholders (3.21)
EXAMPLE 1 Generalised Enterprise Reference Architecture and Methodology (GERAM) (see ISO 15704)
includes an architecture description framework (called the GERA Modelling Framework).
EXAMPLE 2 Reference Model of Open Distributed Processing (RM-ODP) is an architecture framework. See the
ISO/IEC 10746 series.
EXAMPLE 3 Department of Defense Architecture Framework (DoDAF), Ministry of Defence Architecture
Framework (MODAF), Department of National Defense/Cana
...