ISO 42010 in a
nutshell
This page is published under the terms of the licence summarized in the footnote.
Abstract
This paper – a short extract from the ISO 42010 standard – is presented to inform those reading commentary on the standard at avancier.website.
It lists essential requirements for compliance to the standard, using the section numbers in the standard.
5.2 Architecture description identification and
overview
5.3 Identification of stakeholders and concerns
6 Architecture frameworks and architecture
description languages
6.2 Adherence of an architecture description to an
architecture framework
6.3 Architecture description languages
The Standard defines
contents expected of a good (Standard-compliant) Architecture Description (AD)
and how those contents should be related
The Standard can be
read as recommending that:
·
A model is a thing that instantiates a named
model kind (e.g. data model)
·
In turn, that named model kind instantiates the meta type called "model kind" in the standard.
·
A view is a thing that instantiates a particular
viewpoint (e.g. data architecture)
·
In turn, that particular viewpoint instantiates
the standard’s meta type named "viewpoint".
The table below
shows these and other types and meta types in the
standard.
|
This thing |
instantiates this type |
itself a thing that instantiates this meta type |
|
A Model (e.g. one
flowchart) |
A Model Kind
(e.g. flowchart) |
“Model Kind” in
ISO 42010 |
|
A View (e.g. one
behaviour view) |
A Viewpoint (e.g.
behaviour viewpoint) |
“Viewpoint” in
ISO 42010 |
|
A Requirement
(e.g. available 24 * 7) |
A Concern (e.g.
availability) |
“Concern” in ISO
42010 |
|
A System of
Interest |
An Architecture
Description |
The requirements
in section 5 of ISO 42010 |
The table below
lists four type-instance relations you may detect the standard.
|
This complex type |
contains types used by actors to govern |
these things |
|
The ISO 40210
Standard |
the instantiation
by documentation of |
Architecture
Descriptions |
|
An Architecture
Description |
the instantiation
by building of |
Operational
Systems |
|
A Viewpoint |
the instantiation
by definition of |
Views |
|
A Model Kind |
the instantiation
by drawing of |
Models |
Other requirements the Standard imposes on a conformant AD are listed in section 5, as follows.
This clause specifies the characteristics of architecture descriptions that enable the uses listed in 4.4.
Architecture descriptions include the following contents, as specified in the remainder of this clause:
· architecture description identification and overview information (see 5.2);
· identification of the system stakeholders and their concerns (see 5.3);
· a definition for each architecture viewpoint used in the architecture description (see 5.4);
· an architecture view and architecture models for each architecture viewpoint used (see 5.5 and 5.6);
· applicable AD correspondence rules, AD correspondences and a record of known inconsistencies among the architecture description’s required contents (see 5.7);
· rationales for architecture decisions made (see 5.8);
The verb include when used in Clause 5 indicates that either the information is present in the architecture description or reference to that information is provided therein.
An architecture description shall identify the system-of-interest and include supplementary information as determined by the project and/or organization.
The detailed content of identifying and supplementary information items shall be as specified by the organization and/or project.
Results from any evaluations of the architecture or its architecture description shall be included.
An architecture description shall identify the system stakeholders having concerns considered fundamental to the architecture of the system-of-interest.
The following stakeholders shall be considered and when applicable, identified in the architecture description:
· users of the system;
· operators of the system;
· acquirers of the system;
· owners of the system;
· suppliers of the system;
· developers of the system;
· builders of the system;
· maintainers of the system.
An architecture description shall identify the concerns considered fundamental to the architecture of the system-of-interest.
The following concerns shall be considered and when applicable, identified in the architecture description:
· the purposes of the system;
· the suitability of the architecture for achieving the system’s purposes;
· the feasibility of constructing and deploying the system;
· the potential risks and impacts of the system to its stakeholders throughout its life cycle;
· maintainability and evolvability of the system.
An architecture description shall associate each identified concern with the identified stakeholders having that concern.
An architecture description shall include each architecture viewpoint used therein.
Each included architecture viewpoint shall be specified in accordance with the provisions of Clause 7.
Each concern identified in accordance with 5.3 shall be framed by at least one viewpoint.
An architecture description shall include exactly one architecture view for each architecture viewpoint used.
Each architecture view shall adhere to the conventions of its governing architecture viewpoint.
Each architecture view shall include:
a) identifying and supplementary information as specified by the organization and/or project;
b) identification of its governing viewpoint;
c) architecture models that address all of the concerns framed by its governing viewpoint and cover the whole system from that viewpoint;
d) recording of any known issues within a view with respect to its governing viewpoint.
An architecture description may include information not part of any architecture view.
An architecture view shall be composed of one or more architecture models.
Each architecture model shall include version identification as specified by the organization and/or project.
Each architecture model shall identify its governing model kind and adhere to the conventions of that model kind (see 5.4).
An architecture model may be a part of more than one architecture view.
5.7.1 Consistency within an architecture
description
An architecture description shall record any known inconsistencies across its architecture models and its views.
An architecture description should include an analysis of consistency of its architecture models and its views.
Correspondences and correspondence rules, as specified in 5.7.2 and 5.7.3, may be used to express, record, enforce and analyze consistency between models, views and other AD elements within an architecture description.
5.7.2 Correspondences
Each correspondence in an architecture description shall be identified and identify its participating AD elements.
AD elements may be instances of any construct introduced in 4.2 (stakeholders, system concerns, architecture viewpoints, architecture views, model kinds, architecture models, architecture decisions and rationale).
When viewpoints and model kinds are defined, additional kinds of AD elements may be introduced.
Each correspondence in an architecture description shall identify any correspondence rules governing it (see 5.7.3).
5.7.3 Correspondence rules
An architecture description shall include each correspondence rule applying to it.
For each identified correspondence rule, an architecture description shall record whether the rule holds or otherwise record all known violations.
A correspondence rule holds if an associated correspondence can be shown to satisfy the rule.
A correspondence rule is violated if an associated correspondence can be shown not to satisfy the rule or when no associated correspondence exists.
5.8.1 Rationale recording
An architecture description shall include a rationale for each architecture viewpoint included for use per 5.4 in terms of its stakeholders, concerns, model kinds, notations and methods.
An architecture description shall include rationale for each decision considered to be a key architecture decision (per 5.8.2).
An architecture description should provide evidence of the consideration of alternatives and the rationale for the choices made.
5.8.2 Decision recording
An architecture description should record architecture decisions considered to be key to the architecture of the system-of-interest.
It is not practical to record every architecture decision about a system.
A decision recording and sharing strategy should be applied by the organization and/or project to establish criteria for selecting key decisions to be recorded and supported with rationales in the architecture description. Criteria to consider are:
· decisions regarding architecturally significant requirements;
· decisions needing a major investment of effort or time to make, implement or enforce;
· decisions affecting key stakeholders or a number of stakeholders;
· decisions necessitating intricate or non-obvious reasoning;
· decisions that are highly sensitive to changes;
· decisions that could be costly to change;
o decisions that form a base for project planning and management (for example, work breakdown structure creation, quality gate tracking);
o decisions that result in capital expenditures or indirect costs.
When recording decisions, the following should be considered:
· the decision is uniquely identified;
· the decision is stated;
· the decision is linked to the system concerns to which it pertains;
· the owner of the decision is identified;
· the decision is linked to AD elements affected by the decision;
· there is rationale linked to the decision in accordance with 5.8.1;
· constraints and assumptions that influence the decision are identified;
· alternatives that have been considered, and their potential consequences, are recorded;
o consequences of the decision (relating to other decisions) are recorded;
o timestamps record when the decision was made, when it was approved and when it was changed;
o citations to sources of additional information are provided.
An architecture framework shall include:
a) information identifying the architecture framework;
b) the identification of one or more concerns (per 5.3);
c) the identification of one or more stakeholders having those concerns (per 5.3);
d) one or more architecture viewpoints that frame those concerns (per 7);
e) any correspondence rules (per 5.7).
The verb include when used in Clause 6 indicates that either the information is present in the architecture framework or reference to that information is provided therein.
An architecture framework should include conditions on applicability.
An architecture framework shall establish its consistency with the provisions of the conceptual model in 4.2.
An architecture description adheres to an architecture framework when:
· each applicable stakeholder identified in the architecture framework has been considered and identified in the architecture description (per 5.3);
· each applicable concern identified in the architecture framework has been considered and identified in the architecture description (per 5.3);
· each applicable viewpoint specified by the architecture framework (per 6.1) is included (per 5.4) in the architecture description;
· each applicable correspondence rule specified by the architecture framework is included in the architecture description (per 5.7.3); and
· the architecture description conforms to the requirements of Clause 5.
Applicable means when conditions of applicability (see 6.1) are met.
An architecture framework may establish additional rules for adherence.
An architecture description language shall specify:
a) the identification of one or more concerns to be expressed by the ADL (per 5.3);
b) the identification of one or more stakeholders having those concerns (per 5.3);
c) the model kinds implemented by the ADL which frame those concerns (per Clause 7, d));
d) any architecture viewpoints (per Clause 7).
An architecture viewpoint shall specify:
a) one or more concerns framed by this viewpoint (per 5.3);
b) typical stakeholders for concerns framed by this viewpoint (per 5.3);
c) one or more model kinds used in this viewpoint;
d) for each model kind identified in c), the languages, notations, conventions, modelling techniques, analytical methods and/or other operations to be used on models of this kind;
e) references to its sources.
An architecture viewpoint should include information on architecting techniques used to create, interpret or analyze a view governed by this viewpoint, such as:
· correspondence rules, criteria and methods for checking consistency (see 5.7.1) and completeness (see 5.5 d);
· evaluation or analysis methods;
o methods, heuristics, metrics, patterns, design rules or guidelines, best practices and examples to aid in view creation and synthesis.
An architecture viewpoint could be defined as a part of an architecture description (Clause 5), as a part of an architecture framework (Clause 6) or individually using the requirements of this Clause.
A library viewpoint is an architecture viewpoint produced outside of the context of a single architecture description such that it can be used in many architecture descriptions.
Copyright conditions
ISO own the copyright to the full standard.
This paper – a short extract from the ISO 42010 standard – is presented to inform those reading commentary on the standard at avancier.website.