EOModeller EOModeller
Sign in Get started
← All posts

What ISO 42010 says an architecture description is

EOModeller blog · post 004

Most architects have produced an "architecture document" that nobody read. Usually it wasn't badly drawn. It just wasn't written for anyone in particular. ISO/IEC/IEEE 42010 is the international standard for describing architectures, and its answer to that problem fits on one diagram.

The standard grew out of IEEE 1471 (2000). The 2011 edition is the one most often referenced, and a second edition followed in 2022. At its centre is a conceptual model: twelve concepts and the relationships between them. I rebuilt that model in EOModeller from the figure the standard's maintainers publish at iso-architecture.org.

ISO/IEC/IEEE 42010:2011, the core of an architecture description, as a UML class diagram in EOModeller

It looks unfamiliar at first, but it's a UML class diagram, just one with no attributes in the boxes. The lines are associations, read in the direction of the small triangles ("a System-of-Interest exhibits an Architecture"). The numbers are multiplicities, and the hollow diamonds mean "is part of". Read top-left to bottom-right, it tells a short story.

The system and its architecture

Everything starts with a System-of-Interest: whatever you're describing. The standard deliberately doesn't define "system". It could be an enterprise, a product line, a service or a piece of software.

That system exhibits an Architecture: its fundamental concepts and properties. The important idea is that a system has an architecture whether or not anyone has written it down.

An Architecture Description is the thing you write down. It expresses the architecture, and it identifies the system it's about. The distinction matters. The description is a work product, so it can be wrong, out of date, or one of several competing proposals for the same system.

Stakeholders and concerns

Stakeholders have interests in the system: users, owners, operators, auditors, the CFO, the team that will maintain it. Each stakeholder has Concerns: what they care about, such as cost, safety, performance, how it's deployed, or whether it does the job at all.

The description has to identify both. This is the part most architecture documents skip, and the part that makes the rest work. If you can't say who a diagram is for and what question it answers, you can't tell whether it's a good diagram.

Viewpoints, views and models

This is the heart of the standard.

An Architecture Viewpoint is a reusable recipe for one kind of view. It frames a set of concerns, and it says how to address them: which notations, which kinds of model, which analysis. "Deployment", "information" and "C4 context" are all viewpoints.

An Architecture View is the result of applying a viewpoint to your system. The viewpoint governs the view, and the view addresses concerns. A view is built from Architecture Models, and each model is governed by a Model Kind that comes from the viewpoint, so one view can combine several notations.

In other words, the viewpoint is the template and the view is your filled-in copy. It's why C4's System Context, Container and Component levels work. Each is a viewpoint with a clear audience and a clear question, applied to your system.

Correspondences and rationale

Finally, an architecture description holds three more kinds of thing:

  • Correspondences relate elements across views. This container in the deployment view is that component in the logical view.
  • Correspondence Rules say which relations must hold. Every container must be deployed somewhere.
  • Architecture Rationale records why decisions were made, and what was considered and rejected.

These are what turn a stack of diagrams into a description. The views agree with each other, and the reasoning survives the people who did it.

What changed in 2022

The second edition (ISO/IEC/IEEE 42010:2022) keeps the same core. A few changes are worth knowing:

  • Entity of Interest replaces System-of-Interest, so the standard applies to enterprises and other things that aren't really systems.
  • View Components replace architecture models.
  • Stakeholder Perspectives group related concerns, and so the viewpoints that frame them.
  • Architecture Aspects are characteristics of the entity, such as security or performance, that run across views and sharpen the link from concerns to views.

The 2022 edition also stops using a UML meta-model. The diagram here is the 2011 one, which is still the clearest picture of the ideas.

Why I find it useful

You don't need to claim conformance with 42010 to benefit from it. The questions it makes you ask carry over to any architecture work:

  • Who is this view for, and what concern does it address? If the answer is "everyone" and "everything", it's probably a poster, not a view.
  • Which viewpoint is it following? Naming the viewpoint (a C4 container view, a deployment view, a data model) tells readers how to read it before they start.
  • Is it one model, seen many ways? Views drawn from a single model stay consistent, which gives you correspondences for free. In separate drawings, the same box with a different name is a bug waiting to happen.

That last one is why EOModeller works the way it does. Diagrams are views of one model, so an element renamed on one diagram is renamed on all of them. Each diagram also carries its purpose and audience in its metadata: the concern and the stakeholders, in 42010's terms. C4 support is built in the same way. Its levels are viewpoints over UML elements, not separate pictures.

Building the model

The model above was built from the published figure, and it's a nice example of a model doing more than a picture can. Every relationship has a name, a direction and multiplicities, so the diagram can be queried and checked, and an AI assistant can read it.

Building it also showed me two places where EOModeller didn't match the original:

  • The small triangles that show which way to read an association name now turn to follow vertical lines (▲ ▼), as they do in the standard's figure.
  • Each diagram now has a default line style, so a figure drawn with straight lines can be reproduced with one setting instead of eighteen.

References

← All posts