ISO/IEC 42010

ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.


ISO/IEC/IEEE 42010:2011 defines requirements on the description of system, software and enterprise architectures. It aims to standardise the practice of architecture description by defining standard terms, presenting a conceptual foundation for expressing, communicating and reviewing architectures and specifying requirements that apply to architecture descriptions, architecture frameworks and architecture description languages.

Following its predecessor, IEEE Std 1471, the standard makes a strict distinction between Architectures and Architecture Descriptions.

The description of ISO/IEC/IEEE 42010 in this article is based upon the standard published in 2011.[1]


ISO/IEC 42010 defines a number of terms:

  • architecting: architectural design—the process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle (i.e., "designing")
  • architecture: fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
  • architecture description (abbreviation 'AD'): work product used to express an architecture
  • architecture description language (abbreviation 'ADL'): any form of expression for use in architecture descriptions
  • architecture framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders
  • architecture viewpoint: work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns
  • architecture view: work product expressing the architecture of a system from the perspective of specific system concerns
  • concern: interest in a system relevant to one or more of its stakeholders. A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
  • model kind: conventions for a type of modeling. An architecture view consists of multiple models, each following one model kind.
  • stakeholder : individual, team, organization, or classes thereof, having an interest in a system

Conceptual Foundations

ISO/IEC/IEEE 42010 has a conceptual model that underpins the standardisation requirements. In particular the conceptual model describes how the key concepts involved in architecture description relate to each other. In the standard, the model is presented as a set of class diagrams.[2]

The ISO/IEC/IEEE 42010 conceptual model utilizes the following concepts:

  • AD Element
  • Architecture
  • Architecture Decision
  • Architecture Description
  • Architecture Description Language
  • Architecture Framework
  • Architecture Model
  • Architecture Rationale
  • Architecture View
  • Architecture Viewpoint
  • Concern
  • Correspondence
  • Correspondence Rule
  • Environment (of a System)
  • Model Kind
  • (System) Stakeholder
  • (System) Concern
  • System
  • System of Interest

Conceptual Model - Architecture Description

In the ISO/IEC/IEEE 42010 conceptual model, an architecture description:

  • expresses an architecture
  • identifies a system of interest
  • identifies 1 or more stakeholders
  • identifies 1 or more concerns (about the system of interest)
  • includes 1 or more architecture viewpoints and 1 or more architecture views
  • includes 0 or more correspondence(s)
  • includes 0 or more correspondence rules
  • includes 1 or more architecture rationales

The conceptual model states that an architecture description must have a stakeholder, system of interest, identified concern(s), architecture viewpoint(s), architecture view(s) and architecture rationale(s). It states that an architecture description may have correspondences and correspondence rules.

Conceptual Model - Architecture View

In the ISO/IEC/IEEE 42010 conceptual model, an architecture view:

  • is part of an architecture description
  • is governed by exactly 1 architecture viewpoint
  • addresses one or more concerns held by the stakeholder(s)
  • is composed of 1 or more architecture models

Conceptual Model - Architecture Viewpoint

In the ISO/IEC/IEEE 42010 conceptual model, an architecture viewpoint:

  • is part of an architecture description
  • frames 1 or more stakeholder concerns (about the system of interest)
  • governs exactly 1 architecture view
  • is composed of 1 or more model kinds

An architecture viewpoint is in effect a specification for an architecture view - the architecture view has to conform to its architecture viewpoint.

Conceptual Model - Concern

In the ISO/IEC/IEEE 42010 conceptual model, a concern:

  • is held by 1 or more stakeholder(s) in the system of interest
  • is addressed by an architecture view
  • is identified by an architecture description
  • is framed by an architecture viewpoint

Conformance to ISO/IEC/IEEE 42010

ISO/IEC/IEEE 42010 defines four cases of conformance to the standard:

  1. architecture description (AD)
  2. architecture viewpoint
  3. architecture framework
  4. architecture description language (ADL)

Architecture Description

An architecture description is an artifact describing the architecture for some system of interest. In ISO/IEC/IEEE 42010, system refers to man-made and natural systems, including software products and services and software-intensive systems. Architecture descriptions have a variety of uses. Per ISO/IEC/IEEE 42010, an architecture description conforming to the standard is expected to include:

  • identification and overview information of the architecture being expressed;
  • identification of the system stakeholders and their concerns;
  • definitions for each architecture viewpoint used in the architecture description and a mapping of all concerns to those viewpoints;
  • an architecture view and its architecture models for each architecture viewpoint used;
  • correspondence rules and correspondences and a record of known inconsistencies among the architecture description’s required contents;
  • architecture rationale (explanation, justification, reasoning for decisions made about the architecture being described).

ISO/IEC/IEEE 42010 organizes an architecture description into multiple architecture views. An architecture view addresses one or more concerns held by stakeholders of the system being described. An architecture view describes the architecture of the system of interest in accordance with the rules and conventions defined in its architecture viewpoint. Each architecture view must have an architecture viewpoint.

Architecture Viewpoint

A viewpoint formalizes the idea that there are different ways of looking at the same system. Viewpoints have a long history in software and systems engineering, dating back at least to the 1970s in Ross' Structured Analysis. In ISO/IEC/IEEE 42010, viewpoints play an integral part of architecture descriptions, architecture frameworks and ADLs, and may also be separately specified.

In ISO/IEC/IEEE 42010 an architecture viewpoint is expected to:

  • frame one or more concerns held by the stakeholders about the system of interest
  • establish the conventions for one kind of architecture view.

Viewpoint conventions include modeling languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other operations on views. Viewpoints establish the rules of conformance for views (such as well-formedness, completeness, interpretability). In framing the stakeholder concerns, a viewpoint defines the means by which architecture views of that type address these concerns.

IISO/IEC/IEEE 42010 requires an architecture viewpoint to include:

  • identified stakeholder concerns that are framed by the viewpoint (to be addressed by views of that type)
  • an identified set of stakeholders holding these concerns
  • the model kinds used (means of representing the relationships/information e.g. N-squared)
  • languages, notations, conventions, modelling techniques, operations used on these model kinds

An architecture viewpoint should include:

  • techniques used to create, interpret and analyse
  • correspondence rules and means of checking consistency
  • heuristics, metrics, patterns, examples

Architecture Framework

An architecture framework establishes a common practice for using, creating, interpreting, and analyzing architecture descriptions within a particular domain of application or stakeholder community. ISO/IEC/IEEE 42010 formalizes a framework as a set of predefined, interconnected viewpoints.

An architecture framework conforming to the standard includes:

  1. identification of the relevant stakeholders in the domain;
  2. the concerns arising in that domain;
  3. architecture viewpoints framing those concerns and
  4. correspondence rules integrating those viewpoints.

Frameworks conforming to the standard often include processes, methods, tools and other practices beyond those specified above.

Examples of architecture frameworks: Zachman’s information systems architecture framework, UK Ministry of Defence Architecture Framework (MODAF), The Open Group’s Architecture Framework (TOGAF), Kruchten’s 4+1 view model, Siemens’ 4 views method, Reference Model for Open Distributed Processing (RM-ODP) and Generalized Enterprise Reference Architecture and Methoodology (GERAM). ISO/IEC JTC1/SC7 WG42 has developed a working catalog and classification of architecture frameworks.[3]

Architecture Description Language

ISO/IEC 42010 requires an architecture description language (ADL) conforming to the standard to specify:

  • the concerns framed by the ADL
  • the typical stakeholders who hold these concerns
  • the model kinds implemented by the ADL that frame these concerns
  • any correspondence rules linking those model kinds

An architecture description language may specify one or more architecture viewpoints, but need not have any.

Examples of architecture description languages are: Architecture Analysis & Design Language, Acme, ArchiMate, BPMN, Rapide, SBC Architecture, SysML, UML, Wright, and the five viewpoint languages of RM-ODP.

The concerns framed by an ADL are not necessarily aligned with those addressed by a particular architecture framework. The suitability of the ADL for use with an architecture framework will depend on how well it is able to frame the concerns that the framework and its viewpoints.

History of ISO/IEC/IEEE 42010

The origin of the standard was the fast track international standardization of IEEE 1471:2000. The standard was originally balloted as ISO/IEC DIS 25961. It was subsequently adopted and published as ISO/IEC 42010:2007 which was identical with IEEE 1471:2000.

In 2006, ISO/IEC JTC1/SC7 WG 42 and IEEE Computer Society launched a coordinated revision of this standard to address: harmonization with ISO/IEC 12207 and ISO/IEC 15288; alignment with other ISO architecture standards (e.g. ISO/IEC 10746 Reference Model Open Distributed Processing); the specification of architecture frameworks and architecture description languages; architecture decision capture; and correspondences for model and view consistency.[4]

In July 2011, the Final Draft International Standard was balloted and approved (21-0) by ISO member bodies. The corresponding IEEE version, P42010/D9, was approved as a revised standard by the IEEE-SA Standards Board on 31 October 2011. ISO/IEC/IEEE 42010:2011 was published by ISO on 24 November 2011.[1]


  1. ^ a b "ISO/IEC/IEEE 42010:2011 - Systems and software engineering - Architecture description". 2011-11-24. Retrieved 2013-08-06.
  2. ^ "ISO/IEC/IEEE 42010: Conceptual Model". Retrieved 2013-08-06.
  3. ^ "Survey of Architecture Frameworks". Retrieved 2013-08-06.
  4. ^ David Emery and Rich Hilliard (2008-02-21). "Updating IEEE 1471: Architecture Frameworks and Other Topics". doi:10.1109/WICSA.2008.32. Retrieved 2013-08-06.

External links

Applications architecture

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).An applications architecture describes the behavior of applications used in a business, focused on how they interact with each other and with users. It is focused on the data consumed and produced by applications rather than their internal structure. In application portfolio management, the applications are usually mapped to business functions and to application .

The applications architecture is specified on the basis of business and functional requirements. This involves defining the interaction between application packages, databases, and middleware systems in terms of functional coverage. This helps identify any integration problems or gaps in functional coverage. A migration plan can then be drawn up for systems which are at the end of the software life cycle or which have inherent technological risks.

Applications architecture tries to ensure the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available and manageable.

Applications architecture means managing how multiple applications are poised to work together. It is different from software architecture, which deals with technical designs of how a system is built.One not only needs to understand and manage the dynamics of the functionalities the composite architecture is implementing but also help formulate the deployment strategy and keep an eye out for technological risks that could jeopardize the growth and/or operations of the organization.

Capella (engineering)

Capella is an open-source solution for model-based systems engineering (MBSE). Hosted at, this solution provides a process and tooling for graphical modeling of systems, hardware or software architectures, in accordance with the principles and recommendations defined by the Arcadia method. Capella is an initiative of PolarSys, one of several Eclipse Foundation working groups.

Department of Defense Architecture Framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means.

This Architecture Framework is especially suited to large systems with complex integration and interoperability challenges, and it is apparently unique in its employment of "operational views". These views offer overview and details aimed to specific stakeholders within their domain and in interaction with other domains in which the system will operate.

Eclipse Sirius

Sirius is an open-source software project of the Eclipse Foundation. This technology allows users to create custom graphical modeling workbenches by leveraging the Eclipse Modeling technologies, including EMF and GMF. The modeling workbench created is composed of a set of Eclipse editors (diagrams, tables and trees) which allow the users to create, edit and visualize EMF models.

IEEE 1471

IEEE 1471 is a superseded IEEE Standard for describing the architecture of a "software-intensive system", also known as software architecture.

In 2011 it was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

List of International Organization for Standardization standards

This is a list of published International Organization for Standardization (ISO) standards and other deliverables. For a complete and up-to-date list of all the ISO standards, see the ISO catalogue.The standards are protected by copyright and most of them must be purchased. However, about 300 of the standards produced by ISO and IEC's Joint Technical Committee 1 (JTC1) have been made freely and publicly available.

Live, virtual, and constructive

Live, Virtual, & Constructive (LVC) Simulation is a broadly used taxonomy for classifying Models and Simulation (M&S). However, categorizing a simulation as a live, virtual, or constructive environment is problematic since there is no clear division between these categories. The degree of human participation in a simulation is infinitely variable, as is the degree of equipment realism. The categorization of simulations also lacks a category for simulated people working real equipment.

Software architecture

Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.Software architecture is about making fundamental structural choices which are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of software. For example, the systems that controlled the space shuttle launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate real-time computing language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.

Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Software architecture description

Software architecture description is the set of practices for expressing, communicating and analysing software architectures (also called architectural rendering), and the result of applying such practices through a work product expressing a software architecture (ISO/IEC/IEEE 42010).

Architecture descriptions (ADs) are also sometimes referred to as architecture representations, architecture specifications

or software architecture documentation.


TRAK is a general enterprise architecture framework aimed at systems engineers based on MODAF 1.2.

View model

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of a whole system from the perspective of a related set of concerns.Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures. These recent efforts define a set of views (or viewpoints). They are sometimes referred to as architecture frameworks or enterprise architecture frameworks, but are usually called "view models".

Usually a view is a work product that presents specific architecture data for a given system. However, the same term is sometimes used to refer to a view definition, including the particular viewpoint and the corresponding guidance that defines each concrete view. The term view model is related to view definitions.

ISO standards by standard number
802 series
IEC standards
ISO/IEC standards

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.