ISO / IEC / IEEE 42010 and decision records

What the standard is

• System of interest — the product or platform whose architecture is being described.
• Environment — context (organizational, technical, legal) the system must fit.
• Architecture — the fundamental properties of the system in that environment, often captured as a set of models and rationale.

Conformance is about the quality of the architecture description (completeness, consistency, and suitability for stakeholders), not about a single file naming scheme.

Core ideas you will see in 42010

Stakeholders

People, roles, or groups with an interest in the system (users, SRE, security, finance). Decisions that ignore stakeholders fail even when “technically correct.”

Concerns

Interests that matter in the architecture: security, cost, time-to-recovery, data residency, modifiability. 42010 expects an architecture description to be framed in terms of relevant concerns, not an undifferentiated feature list.

Views and viewpoints

A viewpoint is a perspective (e.g. deployment, or security); a view is a concrete set of models or diagrams from that viewpoint. Your ADR might say “from the operations viewpoint, we will …”

How 42010 relates to ADRs

A classic Nygard ADR (context, decision, consequences) is a narrow slice: one decision, one moment in time. 42010 describes a whole description set that may include many decision records, diagrams, and quality analyses.

They meet when you need the decision to be legible in both registers: the ADR for speed in Git, and 42010 language when you are aligning the decision with a documented set of views and stakeholder concerns. Our ISO-inspired record makes that hand-off explicit; it is still Markdown in your repo, not a full architecture description deliverable.

When to use the ISO-inspired record

• Regulated or audited environments where you must name stakeholders and show traceability to requirements or SLOs.
• When the “decision” and the “view of the system that changes” (network, data flow, team boundary) are the same work item.
• When a pure Y-Statement is too short and a full arc42 document is not justified yet.

Lightweight template (same as generator)

Copy or switch to the generator with the ISO format preselected.

# <short title>

> **Architecture description record (ISO/IEC/IEEE 42010–inspired).** Not a full conformity assessment—use to align *concerns* and *views* with a decision.

**Record ID / cross-ref:** <ADR-42010-0001 or your scheme>

## System / subject scope
<what system of interest is described>

## Stakeholders and roles
<who may be affected or who must read this description>

## Stakeholder concerns
<reliability, cost, lawfulness, modifiability, … as relevant to this view>

## View and viewpoint
<name the viewpoint, e.g. security / deployment, and the view, e.g. C4 L2, cluster map>

## Decision
<one clear architecture decision the description must reflect>

## Rationale
<reference alternatives or constraints, tied to the concerns above>

## Architectural impact
<what in the as-built or to-be design changes>

## Traceability
<links: requirements, policies, SLOs, other ADRs>

Format guide + template · Open generator

Nygard ADR vs. this record (short)

Nygard ADR optimizes for a fast narrative: status, context, decision, consequences. ISO 42010–inspired adds explicit stakeholder, concern, and view language so a reviewer can see how the change sits in a wider architecture story. Use whichever matches your governance load—many teams use Nygard for most work and 42010-style for boundary decisions.