ISO/IEC/IEEE 42010: ISO/IEC/IEEE 42010 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 42010 is the international standard for describing architectures. It does not tell you how to design a system. It tells you what a good description of an architecture must contain so that people can understand it, review it and trust it. Architects, systems engineers, enterprise architects, solution designers, reviewers and the authors of architecture frameworks use it as a shared vocabulary and a checklist. After this tutorial you will be able to explain its core concepts, read and write an architecture description that conforms to it, judge whether a framework or a template fits it, and connect it to the methods your teams already use.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC/IEEE 42010:2022, the second edition, titled "Software, systems and enterprise – Architecture description". It was prepared by ISO/IEC JTC 1/SC 7 (Software and systems engineering) together with the IEEE Computer Society. IEEE lists it as an active standard, approved by its Standards Board in September 2022 and published on 2022-11-07; national standards bodies such as SIS (Sweden) list it as valid. It cancels and replaces ISO/IEC/IEEE 42010:2011, which is now withdrawn. No newer edition had been announced when this course was checked. Like every ISO standard it is subject to periodic systematic review, so check the catalogue entry before citing an edition in a contract. The course title names no edition; this tutorial teaches the 2022 edition. Verified 2026-10-29 against the IEEE Standards Association listing, the SIS catalogue entry and the publisher's preview of the standard (foreword, introduction, scope and table of contents); the ISO catalogue page could not be fetched automatically on that date, but the ISO project record mirrored by a national standards body showed stage 60.60 (published) with no systematic-review stage open.

Copyright note: the standard is a paid, copyrighted document; this tutorial explains its ideas in its own words and does not reproduce its definitions or requirements.

Who it is for: software, solution and enterprise architects; systems engineers; technical leads who write design documents; reviewers and quality staff who assess architecture work; procurement and programme people who receive architecture deliverables from suppliers; and authors of architecture templates and frameworks.

Prerequisites: none. It helps if you have seen at least one architecture diagram or design document and wondered who it was written for.

Learning objectives. After this course you will be able to:

Explain the difference between an architecture and an architecture description, and why the standard is about the second one.
Define and use the core concepts: entity of interest, stakeholder, concern, perspective, aspect, viewpoint, view, view component, model kind, correspondence, decision and rationale.
Describe the structure of the 2022 edition and the five kinds of thing that can claim conformance to it.
Plan and produce an architecture description that is driven by stakeholders and concerns rather than by favourite diagrams.
Explain how conformance is judged and why there is no organisational certificate for this standard.
Apply the concepts step by step to a realistic project and check the result for gaps.
Relate the standard to ISO/IEC/IEEE 42020, 42030 and 15288, to frameworks such as TOGAF, and to practitioner approaches such as C4, arc42 and architecture decision records.

How to use this tutorial: read the seven lessons in order, study the five diagrams, then answer the reflection questions with a system you know in mind.

Lesson 1 – Origins, purpose and scope

The problem the standard solves

Think of the last time you joined a project and asked for "the architecture". Perhaps you received a single box-and-line diagram with no key, a slide deck from a sales pitch, or a wiki page last edited three years ago. Each says something, but you cannot tell who it was for, what the boxes mean, or why the design looks the way it does.

These problems come from missing structure, not from poor drawing. A security officer, an operations engineer, a finance controller and a developer all need different information about the same system. A single diagram cannot serve all of them, and a pile of diagrams without a plan leaves gaps and contradictions. ISO/IEC/IEEE 42010 gives that plan. First name the people with a stake in the thing and what they care about; then choose conventions for addressing each matter; then produce views that follow them; finally show how the views relate and why key decisions were made.

Architecture versus architecture description

The single most important idea in the standard is the distinction between an architecture and an architecture description. An architecture is abstract: the essential ideas and properties of a thing in its surroundings – how it is organised, how its parts relate, and the principles behind how it is built and changed. You cannot hold it in your hand. Every real system has one, whether or not anybody ever wrote it down.

An architecture description is the tangible work product that expresses an architecture: a document, a set of models in a tool, a wiki space, a repository of diagrams and decision records. The standard is explicit that architectures themselves are not its subject. It sets no rules for what makes an architecture good, secure or efficient. It sets rules for how a description must be organised so that it can do its job. That is why it applies equally to an embedded device and to a national rail network.

A short history

The ideas first appeared in IEEE 1471, published in 2000 as a recommended practice for describing the architecture of software-intensive systems. It introduced the now-familiar notions of stakeholders, concerns, viewpoints and views, and it made the key move of separating a view (the content) from a viewpoint (the conventions for producing that content). In 2007 ISO and IEC adopted the same text as ISO/IEC 42010:2007.

A joint revision by ISO/IEC JTC 1/SC 7 and the IEEE Computer Society followed. The result, ISO/IEC/IEEE 42010:2011, turned the IEEE recommended practice into a joint international standard, harmonised it with the systems and software life-cycle process standards ISO/IEC/IEEE 15288 and 12207, and added requirements for architecture frameworks, architecture description languages, correspondences between parts of a description, and the recording of decisions and rationale. It also introduced model kinds.

The second edition, ISO/IEC/IEEE 42010:2022, widened the scope beyond systems to any human-made entity, including enterprises, products, services, missions and business domains. It renamed several concepts, added others, made model kinds a separate conformance case, and replaced the UML diagrams of the previous edition with simpler entity-relationship figures. Figure 1 summarises this timeline.

Figure 1 – How the standard evolved from IEEE 1471 to the 2022 edition, and the main ideas each step added.

What the 2022 edition covers

The scope of the current edition can be summarised in five points:

It states how a description must be organised and what it must express, for almost any kind of human-made entity – from software and systems to enterprises, systems of systems, product lines, services, technologies and business domains.
It sets requirements for the use of architectural concepts and their relationships inside a description, but not for the entity itself or its environment.
It sets requirements for architecture description frameworks, architecture description languages, architecture viewpoints and model kinds.
It defines what it means for each of those five things – a description, a framework, a language, a viewpoint and a model kind – to conform.
It has no normative references, so it can be read and applied on its own.

What it deliberately leaves out

Equally important is what the standard does not do. It does not prescribe a process or method for architecting, a modelling notation, a technique, a tool, or a format or medium for recording the description. UML, ArchiMate, C4 diagrams or plain prose, in Word, a wiki, Git or a modelling tool, are all acceptable. It also does not judge whether a description is complete or correct in an absolute sense, although it notes that consistency checks and correspondences help you find gaps. Processes and evaluation are covered by companion standards (Lesson 7).

Lesson 2 – Key concepts and vocabulary

The standard's power lies in a small set of precisely related concepts. The definitions below are paraphrases written for beginners; the standard's own wording is more exact.

Architecting – the whole set of activities around an architecture across the life of an entity: conceiving it, defining it, expressing and documenting it, communicating it, checking that it is implemented properly, and maintaining and improving it.
Architecture – what is essential about an entity in its surroundings: its key ideas and properties and the principles that steer how it is realised and how it changes. It is abstract and exists whether or not anyone describes it.
Entity of interest (EoI) – the thing whose architecture is being described: a software product, a system, an enterprise, a service, a mission, a product line and so on. The 2011 edition said "system of interest"; "entity" lets the standard reach beyond systems engineering. Things in the surrounding environment are also called entities.
Architecture description (AD) – the work product that expresses an architecture of an entity of interest. One architecture can be expressed in more than one description, for example a current-state and a proposed description, or two competing options.
Stakeholder – a person, group or organisation with an interest in the entity of interest: users, operators, owners, acquirers, developers, maintainers, regulators, security teams and so on.
Concern – a matter of interest to one or more stakeholders about the entity: for example, "Can it handle peak load in December?", "How is personal data protected?", "What will it cost to run?" or "Can we replace the payment provider later?". Concerns are the drivers of the whole description.
Stakeholder perspective – a way of thinking about the entity that a group of stakeholders shares, shaped by their role and their concerns. A regulator's perspective differs from an operator's even when both look at the same system.
Aspect – a part of the character of the entity that relates to a particular set of concerns, such as its structure, its behaviour, its information, its security, its cost or its risk. Aspects let you organise concerns by the kind of property they are about.
Architecture viewpoint – a reusable specification of conventions for constructing, interpreting and analysing a kind of view: which concerns it frames, which stakeholders it is typically for, which model kinds or notations it uses, and which methods or rules apply. A viewpoint is like a template plus instructions.
Architecture view – the content that expresses the architecture of the entity of interest from one viewpoint, addressing the concerns that viewpoint frames. A viewpoint is the recipe; the view is the dish made for this particular entity.
Architecture view component – a separable part of one or more views, such as a deployment model, a data-flow diagram, a table of interfaces or a section of explanatory text. This 2022 term replaces "architecture model" because not every part of a view is a formal model.
Model kind – the conventions for one type of model: its language or notation, its modelling rules and how to read it. "UML sequence diagram", "data-flow diagram", "queueing model" and "C4 container diagram" are examples. Model kinds govern the view components that are based on models.
Legend – the explanation that accompanies a view component and tells the reader how to interpret it: what the shapes, lines and colours mean, or what conventions a table or text follows. In the 2022 edition both model-based and non-model-based view components are documented by legends.
AD element – any identified or named part of a description: each stakeholder, concern, perspective, aspect, viewpoint, view, view component and model kind is an AD element. Naming them makes it possible to refer to them and relate them.
Correspondence – an identified relation between AD elements, used to express and check consistency, traceability, refinement or dependency. A whole description can itself act as an element in a correspondence with another description, which supports comparing alternatives.
Correspondence method – a rule or technique that states which correspondences should hold, so that they can be checked: for example, "every component in the functional view is allocated to at least one node in the deployment view".
Architecture decision – a choice that shapes the architecture and affects one or more concerns, such as choosing an event-driven integration style or a particular cloud region.
Architecture rationale – the explanation of why a decision was made: the reasoning, the options considered, the trade-offs and the evidence.
Architecture description framework (ADF) – a set of conventions, principles and practices for describing architectures within a domain or community, typically a set of predefined viewpoints, model kinds and correspondence rules. The 2022 edition replaces the older term "architecture framework" to distinguish description frameworks from evaluation frameworks.
Architecture description language (ADL) – any form of expression used in descriptions, usually providing one or more model kinds. ArchiMate, SysML and many domain-specific languages are examples.

Reading the concepts as a story

The concepts form one chain. Stakeholders have concerns about an entity of interest. For each group of concerns the description uses a viewpoint that frames them; each viewpoint governs views; views are made of view components with legends and, where model-based, model kinds. Correspondences tie elements together, and decisions with rationale explain the design. Figure 2 shows this chain.

Figure 2 – The core concepts of an architecture description and how they relate: concerns drive viewpoints, viewpoints govern views, and views are built from view components.

Viewpoint versus view: the most misunderstood pair

Beginners often use "view" and "viewpoint" as synonyms. In this standard they are different things, and the difference is the key to reuse. A viewpoint is generic: you can write a "deployment viewpoint" once, stating that it serves operations staff and security reviewers, frames concerns about hosting, availability zones and network boundaries, and uses a deployment diagram model kind with a defined legend. The deployment view of your billing system is specific: it shows which billing services run on which clusters in which regions. Another team can reuse the viewpoint for a different entity, and a reviewer knows what to expect in every view it governs.

Concerns are the heart of the matter

The standard is stakeholder- and concern-driven: every view exists because it addresses concerns, and every identified concern should be framed by at least one viewpoint. This rule removes diagrams nobody needs and questions nobody answered, and it makes trade-offs between conflicting concerns visible, so the decision that resolves them can be recorded with its rationale.

Lesson 3 – Structure of the standard

The 2022 edition is around sixty pages long. Its main body has eight clauses, followed by six informative annexes. Knowing what lives where helps you find answers quickly and helps you explain conformance to others. Figure 3 shows the layout.

Figure 3 – The structure of the 2022 edition: concepts in Clause 5, normative requirements in Clauses 6 to 8, and guidance in the annexes.

Clauses 1 to 4: the frame

Clause 1 sets the scope described in Lesson 1. Clause 2 states that there are no normative references. Clause 3 defines the terms; the vocabulary in Lesson 2 paraphrases the most important ones. Clause 4 explains conformance: what has to be true for a description, a framework, a language, a viewpoint or a model kind to claim that it conforms. The standard uses the usual verbal forms: "shall" for a requirement, "should" for a recommendation and "may" for a permission. Only the "shall" statements count for conformance.

Clause 5: conceptual foundations

Clause 5 explains the concepts and how they relate, using simple entity-relationship figures. Its subclauses cover the context of an architecture description; architectures and descriptions; stakeholders and concerns; stakeholder perspectives; aspects; architecture considerations, which brings these drivers together; views and viewpoints; model kinds, legends and view components; AD elements; view methods; correspondence between elements; and decisions and rationale. It then places descriptions in the life cycle and introduces frameworks and languages. Readers are advised to study it before the requirements.

Clause 6: what an architecture description must contain

Clause 6 is the part most practitioners care about. Paraphrased, its subclauses ask a conforming description to:

Identify itself and give an overview: which entity of interest it describes, its scope, its context, its version and status, and any framework it follows (6.1).
Identify the stakeholders (6.2), the stakeholder perspectives (6.3), the concerns (6.4) and the aspects (6.5) that matter for the entity.
Include the viewpoints it uses (6.6), either by defining them or by referring to an existing definition, for instance in a framework.
Include the views (6.7), each governed by a viewpoint and addressing that viewpoint's concerns.
Include the view components that make up the views (6.8), with their model kinds and legends as applicable.
Record correspondences and the methods used to check them, and say how consistency within the description is handled, including known inconsistencies (6.9).
Record the key architecture decisions and their rationale (6.10).

Notice what is not here: no required chapter order, no required diagram types, no required tool. The standard sets requirements on content and relationships, not on form. A description that is a set of linked wiki pages can conform just as well as a formal document.

Clause 7: frameworks and languages

Clause 7 specifies what a conforming architecture description framework must define and what a conforming architecture description language must provide. In summary, a framework identifies the concerns and stakeholders it serves, the viewpoints and model kinds it offers, the correspondence rules that link them, and the conditions under which it applies. A language identifies the concerns it can express, the stakeholders it is meant for, and the model kinds it supports, together with any correspondence rules among them. This gives a common basis for comparing them.

Clause 8: viewpoints, model kinds and view methods

Clause 8 sets out what a viewpoint specification and a model kind specification must contain. A viewpoint specification typically names the viewpoint, gives an overview, lists the concerns it frames and the stakeholders it typically serves, identifies the model kinds and legends it uses, and describes methods for creating and analysing views, including any correspondence rules and sources. A model kind specification describes the conventions for one type of model: its language, its rules and how to interpret it. View methods describe the techniques used to construct, interpret or analyse views.

The informative annexes

Annex A – notes on terms and concepts, with background and examples.
Annex B – guidelines for specifying viewpoints, which are very useful if you write your own.
Annex C – the relationship to other standards.
Annex D – uses of architecture descriptions, from design and analysis to training, planning and cost comparison.
Annex E – life cycles of architectures and of their descriptions.
Annex F – examples of how some existing description frameworks can conform.

The five conformance cases

Conformance can be claimed for five kinds of thing: an architecture description, an architecture description framework, an architecture description language, an architecture viewpoint and a model kind. The 2022 edition added model kinds to this list to encourage model-based architecting. A tool vendor, a framework author and a project can each make a claim, judged against a different part of the standard.

What changed from 2011, in one place

"System of interest" became "entity of interest", aligning with ISO/IEC/IEEE 42020 and 42030.
"Architecture framework" became "architecture description framework".
"Architecture model" became "architecture view component", because some parts of a view are not models.
AD element, stakeholder perspective and aspect are now defined terms.
A viewpoint may govern more than one view in the same description.
Model kinds became a conformance case, and their definition was extended to cover model categories used by frameworks such as the Unified Architecture Framework.
A note clarifies that a whole description can take part in correspondences, for example between alternative descriptions.
Annexes E and F were added.

Lesson 4 – How it works in practice

Because the standard does not prescribe a process, every organisation must decide how to produce descriptions. The steps below are a common practical sequence, consistent with the standard but not taken from it; ISO/IEC/IEEE 42020 offers a fuller process model. Figure 4 shows the flow.

Figure 4 – A practical, iterative sequence for producing and maintaining a concern-driven architecture description.

Step 1 – Define the entity of interest and the scope

Write down exactly what you are describing and what you are not. "The customer portal" is vague; "the customer portal web application, its APIs and its data store, excluding the shared identity platform" is clear. State the purpose – investment decision, tender, accreditation, build or maintenance – because it sets the level of detail. Record the version and status of the description so readers know whether they are looking at a proposal or an approved baseline.

Step 2 – Identify the stakeholders and their perspectives

List the people and groups with a stake in the entity. Start with the obvious ones – users, owners, acquirers, developers, testers, operators, maintainers – and then look for the less obvious: regulators, auditors, data protection officers, suppliers, neighbouring teams, and the people who will retire the system one day. Group them by shared perspective. Talk to them; a list invented at a desk misses the people who later block the project.

Step 3 – Elicit and prioritise concerns

For each stakeholder group, collect their concerns as questions or statements. Good concerns are specific enough to be answered: "Can a regional outage take down checkout?" is better than "resilience". Typical concerns cover purpose and suitability, feasibility, risks, cost, performance, security, privacy, maintainability and evolution. Link each concern to its stakeholders, group concerns by aspect, and prioritise them. Concerns behind high-risk decisions deserve the most depth.

Step 4 – Select or define viewpoints

Now decide which viewpoints will frame the concerns. If your organisation uses a framework such as TOGAF, the Unified Architecture Framework or a company-specific template, start from its viewpoints. If you use an approach such as C4 or the 4+1 views, treat each of its diagram types as a candidate viewpoint, and write down what concerns it frames. Where no existing viewpoint fits a concern, define your own using the guidance in Annex B. The test is simple: every identified concern should be framed by at least one viewpoint, and every viewpoint should frame at least one concern.

Step 5 – Produce the views and their components

For each viewpoint, produce the view for this entity of interest. A view is often a mixture of view components: a diagram, a table, a short narrative, perhaps the result of an analysis such as a capacity model. Each model-based component follows a model kind; each component has a legend so a reader can interpret it without guessing. Keep each view focused on its viewpoint's concerns.

Step 6 – Record correspondences and check consistency

Different views describe the same entity, so they must not contradict each other. Define correspondences between elements: this functional component is deployed on that node; this data entity is owned by that service; this concern is addressed by those views; this decision affects these components. Where possible, state rules that can be checked, ideally automatically in a modelling tool or by scripts over diagrams-as-code. The standard expects a description to say how consistency is handled and to record any known inconsistencies rather than hide them.

Step 7 – Record decisions and rationale

Capture the significant decisions: the ones that are costly to reverse, affect many concerns or resolve a conflict between stakeholders. For each, note the concerns it addresses, the options considered, the chosen option, the reasons and the consequences, including risks accepted. Many teams use lightweight architecture decision records (ADRs) for this. The format does not matter; decisions and rationale must be present and traceable to concerns and elements.

Step 8 – Review with the stakeholders

Walk each stakeholder group through the views that address their concerns. Ask whether their concerns are recorded correctly and whether the views answer them. Unanswered or new concerns send you back to Step 3. Reviews are also where architecture evaluation, for example under ISO/IEC/IEEE 42030, uses the description.

Step 9 – Maintain the description across the life cycle

Entities and architectures change; an outdated description becomes a liability. Decide who owns the description, how changes are proposed and approved, and how versions are kept. Annex E of the standard discusses how architecture life cycles and description life cycles relate. A practical rule is to update the relevant views and decision records as part of the change that alters the architecture, not months later.

Roles and artefacts

The standard does not define job roles, but in practice you will see these: an architect or architecture team who owns the description; stakeholder representatives who supply and confirm concerns; reviewers who check conformance and quality; and a framework or practice owner who maintains organisation-wide viewpoints, model kinds and templates. Typical artefacts are a description overview, a stakeholder and concern register, a viewpoint catalogue (often inherited from a framework), the views themselves, a correspondence or traceability matrix, and a decision log. Small teams keep all of this in one repository; large programmes use a modelling tool and a governance board. The requirements are the same at every scale; the effort is not.

Lesson 5 – Assessment, certification and compliance

No certificate for organisations or people

ISO/IEC/IEEE 42010 is not a management system standard. It contains no requirements for an organisation's processes, so there is no accredited third-party certification of companies against it, comparable to ISO 9001 or ISO/IEC 27001 certification. ISO and IEEE do not certify architects against it either. A training certificate, such as this course's, shows study, not conformance. Be wary of offers to "certify your organisation to 42010".

What conformance means

Conformance is a property of a specific work product. Clause 4 lets five kinds of work product claim it: an architecture description, a framework, a language, a viewpoint and a model kind. Each is judged against its own requirements: a description against Clause 6, frameworks and languages against Clause 7, viewpoints and model kinds against Clause 8. A conformance claim says, in effect, "this work product satisfies all the 'shall' requirements that apply to it". Recommendations ("should") improve quality but are not needed for the claim.

Who assesses conformance

Conformance is usually assessed in one of three ways:

Self-assessment. The architect or team checks the description against a checklist derived from Clause 6 and states the result in the description overview.
Peer or governance review. An architecture review board, a design authority or quality staff checks the description before an approval gate. This is the most common form inside organisations.
Second-party assessment. An acquirer requires conformance in a contract and checks the supplier's deliverables, sometimes with the help of an independent reviewer. Government and defence acquisitions often specify a framework whose viewpoints and terminology are aligned with the standard.

A conformance checklist

A practical review checklist for a description, built from the structure of Clause 6, asks questions such as:

Is the entity of interest identified, with scope, context, purpose, version and status?
Are stakeholders, perspectives, concerns and aspects identified and linked?
Is every viewpoint used either defined in the description or referenced from a source that defines it?
Does each view follow exactly one governing viewpoint, and does it address that viewpoint's concerns?
Are all identified concerns framed by at least one viewpoint?
Do view components have legends, and do model-based ones follow identified model kinds?
Are correspondences and their checking methods recorded, and are known inconsistencies listed?
Are significant decisions recorded with rationale and linked to concerns?

When you use such a checklist, remember that it tests the presence and linking of content, not the quality of the design. A beautifully conforming description can describe a poor architecture. Judging the architecture itself is the job of architecture evaluation, for which ISO/IEC/IEEE 42030 provides a framework.

Conformance of frameworks and templates

Framework authors and tool vendors sometimes state that their product conforms or is aligned. Treat "aligned with" as a weaker claim: often it means shared vocabulary, not that every Clause 7 requirement is met. When you evaluate a framework or template, check whether it identifies the concerns and stakeholders each viewpoint serves, whether its viewpoints specify model kinds and legends, and whether it defines correspondence rules. Annex F shows examples of how some existing frameworks can conform.

Lesson 6 – Worked example

This example is fictional but realistic. NordCargo, a mid-sized logistics company, plans to replace its ageing parcel-tracking system with a new cloud-based tracking platform. The board must approve it, security must accredit it, a supplier will build parts, and operations will run it. The chief architect, Amira, decides to produce a description that conforms to ISO/IEC/IEEE 42010:2022.

Step 1 – Identification and overview

Amira defines the entity of interest as "the NordCargo Track platform: event ingestion from scanners and partner carriers, the tracking service, the customer notification service, public tracking APIs and the tracking data store". She explicitly excludes the warehouse management system and the company-wide identity platform, which appear only as entities in the environment. The overview states the purposes (approval, accreditation, supplier briefing, maintenance), marks version 1 as a draft, and names the company's internal framework – C4 diagrams plus extra viewpoints – as the one followed.

Step 2 – Stakeholders and perspectives

After workshops, Amira's register lists these stakeholder groups: customers and recipients; customer service agents; partner carriers; the board and the finance controller; the information security officer and the data protection officer; the operations team; the internal development team and the supplier's developers; and the national postal regulator, which sets rules for some parcel services. She groups them into four perspectives: business (board, finance, customer service), customer and partner (customers, carriers), assurance (security, privacy, regulator) and engineering and operations (developers, supplier, operations).

Step 3 – Concerns and aspects

The register records concerns as questions, each linked to its stakeholders and an aspect. A few examples:

Finance controller – What will the platform cost to run at current and doubled volumes? (aspect: cost)
Customers – How quickly does a scan appear in the tracking page? (aspect: behaviour and performance)
Partner carriers – How do we send events, and what happens if our feed is late? (aspect: interfaces)
Data protection officer – Which personal data is stored, where, and for how long? (aspect: information and privacy)
Operations team – How do we detect and recover from a regional cloud outage? (aspect: resilience)
Developers and supplier – How is the work split into services, and who owns which data? (aspect: structure)

She marks the cost, privacy and resilience concerns as high priority, because they drive the investment and the accreditation decisions.

Step 4 – Viewpoints

From the company framework Amira reuses four viewpoints: system context, containers, deployment and data. She checks the concern register and finds two gaps. No existing viewpoint frames the finance controller's running-cost concern, and none frames privacy in enough depth for the data protection officer. She therefore defines two new viewpoints following Annex B: a cost viewpoint (stakeholders: board and finance; concerns: running cost and its drivers; model kind: a cost table per component and volume scenario, with a legend explaining the assumptions) and a privacy viewpoint (stakeholders: data protection officer and regulator; concerns: personal data categories, locations, retention and access; model kinds: a personal-data flow diagram and a retention table). Figure 5 shows part of the resulting chain.

Figure 5 – Part of the NordCargo description: stakeholders' concerns are framed by viewpoints whose views address them, and a correspondence links the privacy and deployment views.

Step 5 – Views and view components

Amira's team produces six views. The context view shows the platform, its users and external systems. The container view shows six services and the data store, with an interface table. The deployment view shows two cloud regions in an active–passive arrangement, the managed message broker and the network boundaries. The data view shows the main data entities and which service owns each. The cost and privacy views hold the tables and diagrams their viewpoints define. Every diagram carries a legend; the team discovers during this step that two engineers had used dashed lines with different meanings and fixes the legend for the container model kind.

Step 6 – Correspondences

The team records several correspondence rules and checks them. Every container in the container view must be placed in the deployment view; every data entity in the data view must have exactly one owning container; every flow of personal data in the privacy view must match a flow in the container view and stay within the regions allowed by the retention table. The check finds one inconsistency: the notification service sends recipients' phone numbers to an SMS provider outside the permitted region, which the privacy view did not show. The team records the inconsistency, adds the flow to the privacy view, and raises a decision.

Step 7 – Decisions and rationale

The decision log contains eight entries. Two examples:

Decision 3 – Event-driven ingestion through a managed broker. Concerns: scan-to-display time, partner feed delays, operating effort. Options: direct API calls, managed broker, self-hosted broker. Rationale: the managed broker absorbs bursts and late partner feeds, and costs less to operate than a self-hosted one; the accepted risk is dependence on one cloud provider's service.
Decision 7 – Use an in-region SMS provider. Concerns: location of personal data, notification cost. Options: keep the current provider with a data transfer agreement, switch to an in-region provider. Rationale: switching removes a cross-border transfer at a small extra cost per message; the data protection officer agreed.

Step 8 – Review and approval

Amira holds three reviews. The board reviews the context, cost and deployment views and approves the investment with a condition about the doubled-volume cost. The security and privacy officers review the deployment, privacy and container views; they accept the design after Decision 7. The supplier's lead developer raises a new concern about test environments, which goes back into the register. Before approval, a review board member runs the Clause 6 checklist and confirms that every concern is framed, every viewpoint is defined or referenced, and the inconsistency is resolved and recorded.

Step 9 – Living description

The description lives in the same repository as the platform's infrastructure code, with diagrams as code and decision records as text files. Pull requests that change the architecture must update the affected views or add a decision record. Six months later, when NordCargo adds a parcel-locker partner, the team updates the context and container views, adds a concern from the locker operator, and records two new decisions without a large rewrite.

What the example shows

The standard did not choose NordCargo's architecture; engineering judgement did. It contributed discipline: a full list of who cares about what, two viewpoints that would otherwise have been missing, a consistency check that caught a privacy problem before go-live, and a decision log that explains the design to the next person.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC/IEEE 42010 sits in a small family of architecture standards and is used by many frameworks and methods.

The 420x0 family

Three ISO/IEC/IEEE standards work together. ISO/IEC/IEEE 42010 says what an architecture description contains. ISO/IEC/IEEE 42020 (architecture processes) describes processes for architecting, such as architecture governance, management, conceptualisation, evaluation and elaboration; its elaboration process is the one most directly concerned with producing descriptions. ISO/IEC/IEEE 42030 (architecture evaluation framework) describes how to evaluate architectures against objectives and stakeholder concerns. The 2022 edition of 42010 adopted the term "entity of interest" so that all three use the same language.

Life-cycle process standards

ISO/IEC/IEEE 15288 (system life-cycle processes) and ISO/IEC/IEEE 12207 (software life-cycle processes) include an architecture definition process. They say that architecture work happens and what it achieves; 42010 says what the resulting description should contain.

Frameworks and languages

Enterprise and defence frameworks such as the TOGAF Standard from The Open Group and the Unified Architecture Framework (UAF) from the Object Management Group use the stakeholder, concern, viewpoint and view concepts. In 42010 terms they are architecture description frameworks: they provide ready-made viewpoints and model kinds. Languages such as ArchiMate and SysML are architecture description languages: they provide model kinds and notations. The RM-ODP reference model (ISO/IEC 10746) offers a classic set of five viewpoints. Practitioner approaches fit too: Philippe Kruchten's 4+1 view model (logical, process, development and physical views tied together by scenarios) predates IEEE 1471 and is often presented as a viewpoint set; the C4 model by Simon Brown offers context, container, component and code diagrams, which can be documented as viewpoints with model kinds; and the arc42 template provides a document structure into which concern-driven views fit easily.

Comparison table

Standard or framework	Main question it answers	Relationship to ISO/IEC/IEEE 42010
ISO/IEC/IEEE 42020 – Architecture processes	Which processes should an organisation run for architecting?	Supplies the "how to work"; 42010 supplies the "what the description contains". Shares the entity-of-interest vocabulary.
ISO/IEC/IEEE 42030 – Architecture evaluation framework	How do we judge whether an architecture meets its objectives and concerns?	Evaluates the architecture, often using a 42010 description as input. 42010 itself does not judge design quality.
ISO/IEC/IEEE 15288 and 12207 – Life-cycle processes	Which processes run across a system or software life cycle?	Their architecture definition process produces architecture descriptions; 42010 sets the content rules for those outputs.
TOGAF Standard (The Open Group)	How do we develop and govern enterprise architecture?	Provides a method plus content and viewpoints; uses 42010 concepts. Acts as a description framework within a broader method.
C4 model, arc42, 4+1 views	How do teams communicate software architecture simply?	Practitioner viewpoint sets and templates; can be used in a 42010-conforming description once concerns, stakeholders and legends are made explicit.
ISO/IEC 25010 – Product quality model	Which quality characteristics should a product have?	A source of concerns (performance, security, maintainability and others) that viewpoints and views then address.

How the pieces fit

In short: processes (42020, 15288) decide when architecture work happens; quality models and requirements suggest concerns; frameworks and languages provide viewpoints and model kinds; 42010 defines how it all comes together in a description; and evaluation (42030) judges the described architecture. Beware the word "perspective": some books use it for cross-cutting quality concerns applied to many views, while 42010 uses "stakeholder perspective" for a stakeholder group's way of looking at the entity.

Common pitfalls and best practices

Common pitfalls

Diagram-first documentation. Teams draw the diagrams they like and only afterwards wonder who needs them. Concerns without views and views without concerns follow.
Confusing view and viewpoint. Without written viewpoints, every view invents its own conventions, reviewers cannot tell what to expect, and reuse is impossible.
Missing legends. Boxes and arrows with no key mean different things to different readers; this is one of the most frequent causes of misunderstanding.
A thin stakeholder list. Only developers and the product owner are named, so operations, security, privacy, finance and regulators discover their concerns late and expensively.
No rationale. Decisions are visible in the design but the reasons are not, so later teams repeat old debates or undo good decisions.
Treating conformance as a quality grade. A conforming description proves the content is complete and linked, not that the architecture is good.

Best practices

Start with stakeholders and concerns. Build the register first and keep it in the description; let it drive which viewpoints you need.
Reuse viewpoints, and write the missing ones. Maintain an organisation-wide viewpoint catalogue with concerns, stakeholders, model kinds and legends; add new viewpoints using Annex B guidance when a concern has no home.
Make traceability explicit. Keep a simple matrix from concerns to viewpoints to views and from decisions to concerns and elements, and use it in reviews.
State and check correspondence rules. Prefer rules that a tool or script can check; record known inconsistencies openly.
Record decisions as they happen. Lightweight decision records written at the time are more accurate than a history reconstructed later.
Treat the description as a living asset. Store it with the code or in a governed repository, version it, and update it with every architectural change.
Specify what the standard leaves open in contracts. Name the framework, viewpoints, format and update rules alongside the conformance requirement.

Summary and key takeaways

ISO/IEC/IEEE 42010:2022 is the current, second edition of the international standard for architecture descriptions; it replaced the 2011 edition.
It distinguishes an abstract architecture from the tangible description that expresses it, and sets requirements only for descriptions and their building blocks.
Descriptions are driven by stakeholders and their concerns; viewpoints frame concerns, views follow viewpoints, and views are made of view components with legends and, where model-based, model kinds.
Correspondences keep views consistent, and recorded decisions with rationale explain why the architecture is the way it is.
Clause 6 holds the requirements for a description, Clause 7 for frameworks and languages, and Clause 8 for viewpoints and model kinds; Clause 5 explains the concepts.
Five kinds of work product can claim conformance: descriptions, frameworks, languages, viewpoints and model kinds; there is no organisational certification.
The standard is method-, notation- and tool-neutral, so it works with TOGAF, UAF, ArchiMate, SysML, C4, arc42 and decision records.
It works best alongside ISO/IEC/IEEE 42020 for processes and ISO/IEC/IEEE 42030 for evaluation.

Reflection questions

Pick a system you work on. Who are its five most important stakeholder groups, and which of their concerns are not answered by any existing document today?
Take one diagram your team uses often. Write the viewpoint it implicitly follows: which concerns it frames, who it is for, its model kind and its legend. What did you have to invent?
Which correspondence rules between two of your views could you check automatically, and what kind of inconsistency would the check most likely reveal?
Think of a past architecture decision that was later questioned. What rationale would have helped, and where should it have been recorded?
If you had to write a contract clause requiring a 42010-conforming description from a supplier, what else would you specify so that the result truly meets your needs?