A Conceptual Model of Architecture Description

ISO/IEC/IEEE 42010 is based upon a conceptual model – or “meta model” – of the terms and concepts pertaining to Architecture Description. The conceptual model is presented here using UML class diagrams to represent classes of entities and their relationships.

The Core Ontology: ISO/IEC/IEEE 42010:2022 (second edition)

Here we provide a brief overview of changes and new concepts in the 2nd edition of ISO/IEC/IEEE 42010. The new edition abandons a UML-based meta model, but due to popular demand and to enable comparison with the previous edition, a UML class diagram is used here. Items in purple are new or changed from the previous edition. Discussion of some of the changes follows the diagram.

Architecture Description (42010 2nd edition)

The 2nd edition (2022) generalizes the subject of an architecture description from System of Interest to Entity of Interest. In the previous edition, an Architecture View is comprised of one or more Architecture Models. In the new edition, Architecture Model is changed to View Component. This 2nd edition introduces Stakeholder Perspectives as a means to group Concerns and therefore to organize Viewpoints framing those Concerns. This edition also introduces Architecture Aspects: characteristics of the Entity of Interest that are reflected in Architecture Views. Among other uses, Aspects can be used to refine the traceability between Concerns and Views.

For historical perspective, the conceptual models in the first edition (2011) are shown below.

For further comparison, its predecessor, the conceptual framework used in the original IEEE 1471-2000™, can be found [here].

Context: ISO/IEC/IEEE 42010:2011 (first edition)

The first diagram captures terms and concepts of systems and their architectures, as a context for understanding Architecture Description.

Context of Architecture Description

Referring to the diagram:

Systems exist. A System is situated in its Environment. That environment could include other Systems.

Stakeholders have interests in a System; those interests are called Concerns. A system’s Purpose is one very common Concern. (Note: In the original edition of the Standard, systems were said to have missions; in the revision, Purpose was chosen as a more general replacement to this term.)

Systems have Architectures. An Architecture Description is used to express an Architecture of a System.

The Standard takes no position on the question, What is a system?
In the Standard, the term system is used as a placeholder – e.g., it could refer to an enterprise, a system of systems, a product line, a service, a subsystem, or software. Systems can be man-made or natural. Nothing in the Standard depends upon a particular definition of system. Users of the Standard are free to employ whatever system theory they choose.
The premise of the Standard is, For a system of interest to you, the Standard provides guidance for documenting an architecture for that system.
Every System inhabits its Environment. A System acts upon that Environment and vice versa. A system’s Environment determines the range of influences upon the system. In the Standard, Environment is intended in the widest possible sense to include developmental, operational, technical, political, regulatory, and all other influences which can affect the architecture. These influences are categorized as Concerns.
Systems have architectures. In the Standard, the architecture of a system is defined as:
“fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. The definition was chosen (1) to accommodate the broad range of things listed above under System: the architecture of X is what is fundamental to X (whether X is an enterprise, system, system of systems, or some other entity); and (2) to emphasize (via the phrase “concepts or properties”) that a system can have an architecture even if that architecture is not written down.
For more about the definition, see [Defining “architecture”].
Architecture Description
An Architecture Description (AD) is an artifact that expresses an Architecture. Architects and other system stakeholders use Architecture Descriptions to understand, analyze and compare Architectures, and often as “blueprints” for planning and construction. ADs are the primary subject of ISO/IEC/IEEE 42010 (and the focus of the next diagram).

The Core of Architecture Description: ISO/IEC/IEEE 42010:2011 (first edition)

The Standard is organized around the terms and concepts of the diagram below. It depicts the contents of an AD and the relations between those content items when applying the Standard to produce an Architecture Description to express an Architecture for some System of Interest.

Architecture Description
An Architecture Description is a work product used to express the Architecture of some System Of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System Of Interest. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard).
See [Architecture Descriptions] for further details and requirements on ADs.
Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect.
A Concern is any interest in the system. The term derives from the phrase “separation of concerns” as originally coined by Edsgar Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.
Architecture Viewpoint
An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information.
Architecture View
An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.
Architecture Model
A view is comprised of Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view.
Model Kind
A Model Kind defines the conventions for one type of Architecture Model.

AD Elements and Correspondences

Architecture Descriptions are comprised of AD Elements. Correspondences capture relationships between AD Elements. Correspondences and Correspondence Rules are used to express and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation within or between ADs.

Elements and Correspondences

AD Element
Any item in an AD is considered an element. Every Stakeholder, Concern, Viewpoint, View, Model Kind in an AD is an AD Element. When a Viewpoint or Model Kind introduces constructs, these too are considered AD Elements.
Correspondences express a relation between AD Elements. Correspondences are used to express architecture relations of interest within an Architecture Description or between Architecture Descriptions. Correspondences can be governed by Correspondence Rules.
Correspondence Rule
Correspondence Rules enforce relations within an Architecture Description or between Architecture Descriptions.

Architecture Decisions and Rationale

Creating an Architecture involves making Architecture Decisions. ISO/IEC/IEEE 42010 specifies requirements for capturing key decisions within an AD in terms of the concepts shown in the next diagram.

Picture of conceptual framework

An Architecture Decision affects AD Elements and pertains to one or more Concerns. By making a Decision, new Concerns may be raised.

Architecture Rationale
Architecture Rationale records the explanation, justification or reasoning about Architecture Decisions that have been made and architectural alternatives not chosen.

Architecture Frameworks and Architecture Description Languages

Architecture frameworks and architecture description languages (ADLs) are two mechanisms widely used in architecting. Instances of each can be specified by building on the concepts of Architecture Description presented above.

The diagram below depicts the contents of an Architecture Framework.

Architecture framework

Architecture Framework
An architecture framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain of application or stakeholder community. Examples of Architecture Frameworks: MODAF, TOGAF, Kruchten’s 4+1 View Model, RM-ODP.
See [Architecture Frameworks] for requirements and long list of examples.
Architecture Description Language (ADL)
An ADL is any form of expression for use in Architecture Descriptions. An ADL might include a single Model Kind, a single viewpoint or multiple viewpoints. Examples of ADLs: Rapide, SysML, ArchiMate, ACME, xADL.

The diagram below depicts the contents of an ADL.

Architecture description language.

Resources for the ISO/IEC/IEEE 42010 website provided by Olimpia.com. Comments, corrections, suggestions on this site to: Webmaster.