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

Status
Published
Publication Date
06-Nov-2022
Current Stage
6060 - International Standard published
Due Date
21-Feb-2022
Completion Date
07-Nov-2022
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC/IEEE 42010:2022 - Software, systems and enterprise — Architecture description Released:7. 11. 2022
English language
62 pages
sale 15% off
Preview
sale 15% off
Preview

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

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

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

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