ISO/IEC/IEEE 42010:2022
(Main)Software, systems and enterprise — Architecture description
Software, systems and enterprise — Architecture description
This document specifies requirements for the structure and expression of an architecture description (AD) for various entities, including software, systems, enterprises, systems of systems, families of systems, products (goods or services), product lines, service lines, technologies and business domains. This document distinguishes the architecture of an entity of interest from an AD expressing that architecture. Architectures are not the subject of this document. This document specifies requirements for use of the architectural concepts and their relationships as captured in an AD. It does not specify requirements for any entity of interest or its environment. This document specifies requirements for an architecture description framework (ADF), an architecture description language (ADL), architecture viewpoints and model kinds in order to usefully support the development and use of an AD. This document specifies conformance to the requirements for an AD, ADF, ADL, architecture viewpoint and model kind. This document does not specify the processes, architecting methods, models, notations, techniques or tools by which an AD is created, utilized or managed. This document does not specify any format or media for recording an AD.
Logiciel, systèmes et entreprise — Description de l'architecture
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/
STANDARD IEC/IEEE
42010
Second edition
2022-11
Software, systems and enterprise —
Architecture description
Logiciel, systèmes et entreprise — Description de l'architecture
Reference number
ISO/IEC/IEEE 42010:2022(E)
© ISO/IEC 2022
© IEEE 2022
---------------------- Page: 1 ----------------------
ISO/IEC/IEEE 42010:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2022
© IEEE 2022
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
ii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC/IEEE 42010:2022(E)
Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 5
5 Conceptual foundations. 5
5.1 General . 5
5.2 Conceptual models of an architecture description . 6
5.2.1 Context of architecture description . 6
5.2.2 Architectures and architecture descriptions . 6
5.2.3 Stakeholders and concerns . 7
5.2.4 Stakeholder perspectives . 8
5.2.5 Aspects . 8
5.2.6 Architecture considerations . 9
5.2.7 Architecture views and architecture viewpoints . 9
5.2.8 Model kinds, legends and architecture view components . 11
5.2.9 Architecture description (AD) elements .12
5.2.10 View methods .12
5.2.11 AD element correspondence . 13
5.2.12 Architecture decisions and rationale . 14
5.3 Architecture description in the life cycle . 15
5.4 Architecture description frameworks and languages . 15
5.4.1 General .15
5.4.2 Architecture description frameworks . 15
5.4.3 ADF utilization . 17
5.4.4 Architecture description languages . 18
6 Specification of an architecture description .19
6.1 Architecture description identification and overview . 19
6.2 Identification of stakeholders .20
6.3 Identification of stakeholder perspectives . 20
6.4 Identification of concerns . 20
6.5 Identification of aspects . 21
6.6 Inclusion of architecture viewpoints . 21
6.7 Inclusion of architecture views . 21
6.8 Inclusion of view components . .22
6.9 Recording of architecture correspondences . 23
6.9.1 Consistency within an architecture description .23
6.9.2 Correspondences . 23
6.9.3 Correspondence methods. 23
6.10 Recording of architecture decisions and rationale . 24
6.10.1 Decision recording . 24
6.10.2 Rationale recording . 25
7 Architecture description frameworks and architecture description languages .25
7.1 Specification of an architecture description framework . 25
7.2 Specification of an architecture description language . 27
8 Architecture viewpoints and model kinds .27
8.1 Specification of an architecture viewpoint . 27
8.2 Specification of a model kind .28
8.3 View methods .28
Annex A (informative) Notes on terms and concepts .29
iii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC/IEEE 42010:2022(E)
Annex B (informative) Guidelines to specification of architecture viewpoints .40
Annex C (informative) Relationship to other standards . 44
Annex D (informative) Uses of architecture descriptions .51
Annex E (informative) Architecture and architecture description life cycles .53
Annex F (informative) Architecture description frameworks .55
Bibliography .59
IEEE Notices and Abstract.63
iv
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC/IEEE 42010:2022(E)
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/IEC 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 or
www.iec.ch/members_experts/refdocs).
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 https://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. In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 42010 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Software and Systems
Engineering Standards Committee of the Computer Society of the IEEE, under the Partner Standards
Development Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 42010:2011), which has been
technically revised.
The main changes are as follows:
— The term used to refer to the subject of an architecture description is changed from “system of interest”
to “entity of interest” (EoI) to be compatible with ISO/IEC/IEEE 42020 and ISO/IEC/IEEE 42030
standards and to allow for its application in non-system architecture situations. The term “entity”
is also used in this document when entities are considered as surrounding things in an environment
of an EoI.
— The term “architecture description framework” (ADF) replaces “architecture framework” in
the previous edition. It is defined in order to differentiate ADFs from other kinds of architecting
frameworks like architecture evaluation frameworks specified in ISO/IEC/IEEE 42030.
v
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC/IEEE 42010:2022(E)
— Architecture description element, introduced in the 2011 edition (see ISO/IEC/IEEE 42010:2011,
4.2.6, 5.7 and A.6) is now defined in Clause 3 as identified or named part of an architecture description
allowing representing at least stakeholders, concerns, perspectives, and aspects identified in an AD,
and views, view components, viewpoints, and model kinds included in an AD.
— Aspect and stakeholder perspective concepts ―already introduced in the 2011 edition (See 3.5, note
1 of 5.6, Annex A and B) are defined and described to accommodate current practice where these
ideas are prevalent.
— A correspondence defines an identified or named relation between AD elements, as in Clause 4.2.6
of the 2011 edition. But, to clarify the relationship between AD and correspondence, a note 1 to the
definition is added to state that for the purpose of correspondences, an architecture description
can be considered as an AD element in another architecture description. This correspondence
between ADs is necessary because an architecture can be described by more than one AD and these
alternatives of architectures have related for activities like trade-off analysis and decision making.
— The term “architecture view component” is introduced as a separable portion of one or more
architecture views, replacing “architecture model” in the 2011 edition. This change is to account for
the fact that some parts of a view are model-based while others may not be. View components can
be derived from an information source, which can sometimes be a model.
— Model-based view components are governed by model kinds and documented by legends. Non-
model-based view components are documented by legends.
— Model kinds are identified as a new conformance case to encourage model-based architecting.
— The concept of architecture viewpoint is updated to accommodate current practice where a
viewpoint governs one or more architecture views within an AD.
— The definition of “model kind” given by the 2011 edition is extended to include categories of models
as used by ADF like UAF.
— The figures use an informal entity-relationship diagram notation replacing UML class diagrams in
the 2011 edition, to facilitate comprehension by users of this document. The multiplicities of the
relationships are explained in the text when necessary.
— Annex E illustrates a few concepts pertaining to architecture life cycles and architecture description
life cycles.
— Annex F shows examples of how some architecture description frameworks can conform to
requirements of this document.
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 and
www.iec.ch/national-committees.
vi
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC/IEEE 42010:2022(E)
Introduction
The complexity of human-made entities has grown to an unprecedented level. This has led to new
opportunities, and also increased challenges for organizations that create and use these entities.
Architecting is increasingly applied by organizations, teams and individuals, to help manage the
complexity faced by stakeholders of these entities.
Examples of entities include the following: Enterprise, organization, solution, system (including
software systems), subsystem, process, business, data (as a data item 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.
An architecture of an entity, expressed in one or more architecture descriptions (AD), assists in
understanding the fundamental concepts or properties of the entity, pertaining to its structure,
behaviour, design and evolution, such as feasibility, utility and maintainability and fundamental concepts
for its development, operation, employment, external impacts, utilization and decommissioning.
ADs are used by the parties that create, use and manage human-made entities to improve communication
and cooperation, enabling all parties, organizations, teams and individuals to work together in an
integrated and coherent fashion.
NOTE ISO/IEC/IEEE 42020 specifies a set of processes for architecting which can be employed in support of
creating one or more ADs. The architecture elaboration process in ISO/IEC/IEEE 42020 is especially relevant for
creation of ADs.
Whereas an AD is a tangible work product, an architecture is intangible and abstract, understood
through its concepts, properties and principles.
Architecture description frameworks (ADF) are used to codify the conventions and common practices
of architecture description. Architecture description languages (ADL) are used to codify the description
of architectures within different communities and domains of application.
ADs have many uses, such as design, development, documentation, analysis, evaluation, maintenance,
risk mitigation, downstream user specifications, tool specification, communication, planning, guidance,
life cycle support, decision support, review, training, design validation, solution trade studies, cost
comparison and analysis, by a variety of stakeholders throughout the life cycles of their entities of
interest. Annex D describes more uses of an AD.
This document provides terms, definitions and relationships for best practices in ADs. The provisions
of this document serve to specify desired properties of ADs. This document also gives provisions that
specify desired properties of ADFs and ADLs in order to usefully support the development and use of
ADs. This document provides a basis for considering and comparing ADFs and ADLs by providing a
common ontology for specifying their contents.
This document can be used to establish a coherent architecting practice for developing ADs, ADFs
and ADLs within an organization, in the context of an entity of interest (EoI) or its architecture. The
provisions of this document can be used to assess conformance of specifications of ADs, ADFs, ADLs,
viewpoints and model kinds.
The intent of this document is to enable a range of consistent and coherent approaches to describing an
architecture including document-centric and model-based techniques.
This document also provides motivations for use of architecture-related terms and concepts in other
documents such as guides and standards.
Users of this document are advised to consult Clause 5 to gain appreciation of the conceptual
foundations, along with the concepts and principles associated with an AD work product.
This document does not explicitly address completeness or correctness regarding the inclusion of
particular elements in an AD. Nevertheless, completeness and correctness of an AD can be partially
checked, for example, through the consistency of the AD elements established, whether relationships
vii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC/IEEE 42010:2022(E)
are transitive, and whether AD elements are shown in the views. Consistency rules can also be defined
by showing whether the same particular AD element has correspondences with an AD. In addition,
specifications that appear as elements within an AD are expected to be complete, precise and verifiable
with respect to the subject of the specification.
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission.
viii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 8 ----------------------
INTERNATIONAL STANDARD ISO/IEC/IEEE 42010:2022(E)
Software, systems and enterprise — Architecture
description
1 Scope
This document specifies requirements for the structure and expression of an architecture description
(AD) for various entities, including software, systems, enterprises, systems of systems, families of
systems, products (goods or services), product lines, service lines, technologies and business domains.
This document distinguishes the architecture of an entity of interest from an AD expressing that
architecture. Architectures are not the subject of this document.
This document specifies requirements for use of the architectural concepts and their relationships as
captured in an AD. It does not specify requirements for any entity of interest or its environment.
This document specifies requirements for an architecture description framework (ADF), an architecture
description language (ADL), architecture viewpoints and model kinds in order to usefully support the
development and use of an AD.
This document specifies conformance to the requirements for an AD, ADF, ADL, architecture viewpoint
and model kind.
This document does not specify the processes, architecting methods, models, notations, techniques or
tools by which an AD is created, utilized or managed.
This document does not specify any format or media for recording an AD.
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 terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp/ ui
— IEC Electropedia: available at https:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at https:// dictionary .ieee .org/
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and is publicly accessible at www .computer .org/ sevocab.
3.1
architecting
conceiving, defining, expressing, documenting, communicating, certifying proper implementation of,
maintaining and improving an architecture (3.2) throughout the life cycle of an entity of interest (3.12)
1
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC/IEEE 42010:2022(E)
3.2
architecture
fundamental concepts or properties of an entity in its environment (3.13) and governing principles for
the realization and evolution of this entity and its related life cycle processes
[SOURCE: ISO/IEC/IEEE 42020:2019, 3.3, modified — The notes to entry have been removed.]
3.3
architecture description
AD
work product used to express an architecture (3.2)
Note 1 to entry: A work product is an artifact produced by a process (see ISO/IEC 20246:2017, 3.18).
Note 2 to entry: An AD is a tangible representation of information provided to the stakeholders (3.17). An AD is
considered an information part (3.14).
3.4
architecture description element
AD element
identified or named part of an architecture description (3.3)
Note 1 to entry: AD elements include stakeholders (3.17), concerns (3.10), stakeholder perspectives (3.18), and
aspects (3.9) identified in an AD (3.3), ADLs (3.6), ADFs (3.5) and correspondences (3.11) and correspondence
methods used in an AD, and architecture views (3.7), view components (3.19), architecture viewpoints (3.8), and
model kinds (3.15) included in an AD (3.3).
Note 2 to entry: For the purpose of correspondences (3.11), an AD (3.3) can be considered as an AD element in
another AD (3.3).
3.5
architecture description framework
ADF
conventions, principles and practices for the description of architectures (3.2) established within a
specific domain of application or community of stakeholders (3.17)
EXAMPLE Generalized Enterprise-Referencing Architectures Modelling Framework (GERAM)
[2]
(ISO 15704:2019, Annex B), Reference Model of Open Distributed Processing (RM-ODP), Unified Architecture
[48] [44]
Framework (UAF) , and NATO Architecture Framework (NAF) .
Note 1 to entry: Architecture description frameworks promote structured organization, consistency of
description, greater potential for reuse, and completeness of architecture views (3.7) and models.
3.6
architecture description language
ADL
means of expression, with syntax and semantics, consisting of a set of representations, conventions,
and associated rules intended to be used to describe an architecture (3.2)
[57] [61] [49] [47]
EXAMPLE Architecture Analysis and Design Language (AADL), ArchiMate, UML, SysML, UAF
[48]
Profile .
3.7
architecture view
information part (3.14) comprising portion of an architecture description (3.3)
EXAMPLE An Information or Data View addresses information-relevant concerns framed by an Information
viewpoint. It contains as view components (3.19), a conceptual data model, a data management model and a data
access model and correspondences linking those components together.
2
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC/IEEE 42010:2022(E)
3.8
architecture viewpoint
set of conventions for the creation, interpretation and use of an architecture view (3.7) to frame one or
more concerns (3.10)
Note 1 to entry: In this document, “to frame” concerns means “to shape, compose, give expression to” those
concerns. It is used to distinguish the stages of framing concerns by a viewpoint from addressing those concerns
in a resulting view. This is analogous to the distinction between “framing a problem” and “solving that problem”.
Note 2 to entry: A viewpoint is a frame of reference for the concerns determined by the architect as relevant to
the purpose of the architecture description (3.3).
Note 3 to entry: The conventions of an architecture viewpoint are documented in a specification (3.16) of that
viewpoint. In some communities and architecture description framewor
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.