Architecture Descriptions in ISO/IEC/IEEE 42010

ISO/IEC/IEEE 42010 defines architecture description (AD) and specifies requirements on architecture descriptions. See the [Conceptual Model] on which the requirements are based. For templates and guidance for creating ADs see [Templates].

architecture description (AD)
work product used to express an architecture

Just as building architects distinguish the architecture they have in mind from the sketches, drawings and blueprints they use to convey that vision, it is helpful to distinguish the architecture of a system or enterprise from the artifacts created to document that architecture – the architecture description.

The Standard does not prescribe the form that an AD takes, as long as it meets certain requirements. (These are the requirements found in Clause 5 of the Standard.) An architecture description might take the form of a document, hypertext or a wiki, a collection of models, a repository, or some other medium. When we say, "an AD includes contents X" below, that can mean either by physical inclusion or by reference (in a manner not defined by the Standard).

An architecture description conforms to ISO/IEC/IEEE 42010:2011 when it meets the requirements in Clause 5. The items below provide an informal overview; please see the original text for the actual requirements. Also, for insight into the terms used below, please refer to the conceptual model.

AD Identification and Overview

• An AD identifies the system-of-interest whose architecture is being expressed.

  In the Standard, system is used as a placeholder for a wide variety of possible subjects. An AD can be produced for any of the following: a man-made system comprised of hardware, software, data, humans, processes and procedures facilities, materials and naturally occurring entities; software products and services; individual applications, subsystems, systems of systems, product lines, product families, whole enterprises, or other aggregations of interest.

• An AD includes supplementary information as determined by the project or organization producing it.

  Examples of this information might be: authors, reviewers, approving authority, issuing organization; change history; configuration management information; context; date of issue and status; glossary; overview; references; scope; summary; and version control information.

• An AD includes the results of any architecture evaluations conducted on this architecture.

Stakeholders and Concerns

• An AD identifies the stakeholders of the system-of-interest whose concerns are considered fundamental to the architecture (i.e., "architecturally significant").

  When identifying stakeholders, the following are to be considered and included when applicable: 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 AD identifies the concerns considered fundamental to the architecture of the system-of-interest.

  When identifying concerns, the following are to be considered and included when applicable: 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 AD associates each identified concern (above) with the identified stakeholders (above) having that concern.

Architecture Viewpoints in an AD

• An AD includes each architecture viewpoint used therein.
• Each identified concern (above) must be framed by at least one viewpoint. This is so that that all identified concerns are covered.

  We say "a viewpoint frames a concern" when the viewpoint gives the architect the means to express that concern. E.g., the formalism of Gantt charts frames concerns about project activities, schedule and dependencies, whereas other notations, such as UML use case diagrams, would not be helpful for modeling these concerns. Associating concerns with viewpoints contributes to architects "using the right tool for the job" when modeling the architecture.

• Each architecture viewpoint is specified by:
  • the concerns framed by this viewpoint;
  • the stakeholders interested in this viewpoint;
  • the model kinds used in this viewpoint;

    A model kind captures conventions for a type of modeling. To adequate frame a set of concerns, a viewpoint can use one or more model kinds.

  • For each model kind that is part of the viewpoint, define the languages, notations, conventions, modelling techniques, analytical methods and/or other operations useful on models of this kind;
  • references to sources on this viewpoint in the literature or previous work.

In addition, a viewpoint might define any of the following to aid the architect:

• correspondence rules, criteria and methods for checking completeness (of views) or consistency (between views);
• methods for evaluation or analysis of views;
• methods, heuristics, metrics, patterns, design rules or guidelines, best practices and examples to aid in view creation and synthesis.

Architecture Views in an AD

• An AD includes exactly one architecture view for each architecture viewpoint used (above). (This is called the view's governing viewpoint.)
• Each architecture view adheres to the conventions specified by its governing viewpoint (above).
• Each architecture view includes:
  • identifying and supplementary information as specified by the organization and/or project;
  • identification of its governing viewpoint;
  • one or more architecture models that address all of the concerns framed by its governing viewpoint; and cover the whole system from that viewpoint. Each model:
    • includes version identification as specified by the organization or project;
    • identifies its governing model kind and adheres to the conventions of that model kind;
    • may be a part of more than one architecture view.
  • a record of any known issues within a view with respect to its governing viewpoint. (Such as unresolved issues, known conflicts, etc.)

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