Skip to content
Software Architecture Guide

ISO/IEC/IEEE 42010 Architecture Description Model

Explanation

Section titled “Explanation”

The standard rests on a conceptual model. A conceptual model is a small map of ideas and how they connect. This one keeps two things apart: the architecture of a system, and the architecture description that records it. The description is a document. The architecture is what the document talks about.

The main links

  • An architecture description is formed from one or more architecture views. See Architecture View.
  • A viewpoint frames one or more stakeholder concerns. A stakeholder is a person or group with an interest in the system. A concern is something they care about. See Stakeholder, Concern and Architecture Viewpoint.

So the chain runs from concerns, to a viewpoint that frames them, to a view, to the description that collects the views.

What a viewpoint is

A viewpoint is a set of conventions. It is not a direction from which you look at the system, like a camera angle. It states how to build and read a kind of view.

A similar model

Rozanski and Woods build their book on three key concepts: stakeholders, viewpoints and perspectives. They also provide a template for an architecture description. The Architectural Perspective article covers perspectives.

Why it helps

The model gives teams shared words. Two people who say “view” or “viewpoint” can mean the same thing.

Edition note

The TRAK method was designed to comply with the 2011 edition of the standard. Its authors had not assessed the 2022 edition, though they did not expect the results to differ.

Example

Section titled “Example”

A team documents an online shop. The operations staff care about where the software runs. The product owner ccares about how an order moves through the system. The team defines one viewpoint for each concern, with its own conventions. They then draw one view per viewpoint. Together, the views form the architecture description of the shop. The shop’s architecture exists whether or not this description is written.

Trade-offs

Section titled “Trade-offs”

The model only supplies vocabulary and relationships. It does not say which viewpoints to choose or how many views you need. Teams must decide that from their own stakeholders and concerns. Terms from different sources, such as Rozanski and Woods, overlap but are not identical.

How stakeholders, concerns, viewpoints, views and the description relate.

Diagram source 
flowchart LR
  S[Stakeholder] -->|has| C[Concern]
  VP[Viewpoint] -->|frames| C
  V[View] -->|conforms to| VP
  AD[Architecture description] -->|formed from| V

Checks

Section titled “Checks”
  • The architecture description consists of at least one architecture view.
  • Each viewpoint used states which stakeholder concerns it frames.
  • The document separates the system’s architecture from the description of it.
  • Viewpoints are written as conventions for building views, not as vague viewing angles.
Section titled “Related”

Sources

Section titled “Sources”