National foreword

This British Standard is the UK implementation of ISO/IEC/IEEE 42020:2019.

The UK participation in its preparation was entrusted to Technical Committee IST/15, Software and systems engineering.

A list of organizations represented on this committee can be obtained on request to its secretary.

This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 July 2019.

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.

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

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

3 Terms and definitions

4 Conformance

4.1 General

4.2 Approach to conformance

4.3 Full conformance cases

4.4 Tailored conformance

5 Process overview and application

5.1 General

5.2 Relationship of architecture to other processes and information elements

5.3 Architecture Governance and Management processes

5.4 Architecture Conceptualization, Evaluation and Elaboration processes

5.5 Architecture Enablement process

5.6 Relationship of architecture to design

5.7 Architecture adaptation

5.8 Process application

6 Architecture Governance process

6.1 Purpose

6.2 Outcomes

6.3 Implementation

6.4 Activities and tasks

6.5 Work products

7 Architecture Management process

7.1 Purpose

7.2 Outcomes

7.3 Implementation

7.4 Activities and tasks

7.5 Work products

8 Architecture Conceptualization process

8.1 Purpose

8.2 Outcomes

8.3 Implementation

8.4 Activities and tasks

8.5 Work products

9 Architecture Evaluation process

9.1 Purpose

9.2 Outcomes

9.3 Implementation

9.4 Activities and tasks

9.5 Work products

10 Architecture Elaboration process

10.1 Purpose

10.2 Outcomes

10.3 Implementation

10.4 Activities and tasks

10.5 Work products

11 Architecture Enablement process

11.1 Purpose

11.2 Outcomes

11.3 Implementation

11.4 Activities and tasks

11.5 Work products

Bibliography

BS ISO/IEC/IEEE 42020:2019

Software, systems and enterprise. Architecture processes

Current, Under Review

Published:

31 Jul 2019