# Viewpoint Catalogue: [Organisation or architecture practice]

> Organisation-wide library of the architecture viewpoints and model kinds
> that architects reuse across projects, with the stakeholders, concerns,
> perspectives and aspects each one addresses, the view methods used to
> build and check them, and the correspondence rules that keep views
> consistent. Structure aligned with ISO/IEC/IEEE 42010:2022, *Software,
> systems and enterprise: Architecture description* (second edition,
> November 2022), in particular its concepts of viewpoints, model kinds,
> view methods and correspondences, and its guidance on specifying
> viewpoints. In 42010 terms, a catalogue like this is the core of an
> organisation's own architecture description framework. Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use
> an invented mid-size insurer.

<!--
Guidance: How to use this template
- Individual architecture descriptions (`architecture/architecture-description-42010`)
  pick viewpoints from this catalogue instead of inventing their own. The
  catalogue is the shared vocabulary; each description is one use of it.
- Build it bottom-up from what architects already draw: collect the
  diagrams and tables of the last ten architecture descriptions, group
  them into model kinds (section 6), then name the viewpoints that use
  those model kinds (section 7). A catalogue designed top-down from a
  framework poster usually goes unused.
- Keep it small. Ten to fifteen approved viewpoints cover most
  organisations; every additional viewpoint is something reviewers must
  learn.
- Every viewpoint must name the concerns it frames and at least one view
  method (how to build and check the view). A viewpoint without a method
  cannot be reviewed.
- Section numbers of the standard are given for orientation only. The
  wording here is original; obtain the standard for its normative text.
-->

## Document control

<!-- Guidance: The catalogue is a controlled asset of the architecture practice. Version it like a standard: projects state which catalogue version they used, so a later change does not silently invalidate approved descriptions. -->

| Field | Value |
|---|---|
| Document ID | [ARCH-VPC-001] |
| Catalogue version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@chief-architect] |
| Maintainers | [@architecture-practice-lead], [@domain-architects] |
| Approvers | [Architecture board] |
| Applies to | [All solution and enterprise architecture descriptions from YYYY-MM-DD] |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Related documents | Architecture Process Plan and Records (`architecture/architecture-practice-42020`), Architecture Governance Charter (`architecture/architecture-governance-charter`), Architecture Principles (`architecture/architecture-principles`) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief architect | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Architecture board chair | [@name] | [Decision] | YYYY-MM-DD |
| Head of security architecture | [@name] | [Decision] | YYYY-MM-DD |
| Head of engineering | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record every added, changed, deprecated or retired viewpoint and model kind by ID, so projects can see what moved between versions. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial catalogue harvested from existing architecture descriptions |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added MK-07 (data flow diagram) and VP-06 (Security and trust) |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the architecture board; VP-01 to VP-08 approved, VP-09 on trial |
| [x.y] | YYYY-MM-DD | [@name] | [Change by ID] |

## Contents

1. [Purpose, scope and use](#1-purpose-scope-and-use)
2. [Catalogue governance](#2-catalogue-governance)
3. [Stakeholder classes](#3-stakeholder-classes)
4. [Perspectives and concern library](#4-perspectives-and-concern-library)
5. [Aspects](#5-aspects)
6. [Model kind library](#6-model-kind-library)
7. [Viewpoint catalogue](#7-viewpoint-catalogue)
8. [Viewpoint specifications](#8-viewpoint-specifications)
9. [View methods](#9-view-methods)
10. [Correspondence rules](#10-correspondence-rules)
11. [Selection guide](#11-selection-guide)
12. [Coverage checks](#12-coverage-checks)
13. [Mapping to established viewpoint sets](#13-mapping-to-established-viewpoint-sets)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and use

<!-- Guidance: Say why the organisation keeps a shared catalogue, who must use it and what happens when a project needs something that is not in it. Pitfall: a catalogue that is "recommended" with no rule about deviations; projects then ignore it. -->

### 1.1 Purpose

[Purpose statement. *Example:* Architecture descriptions at the insurer
used 40 different diagram styles for the same questions, which made
reviews slow and comparisons between systems impossible. This catalogue
fixes a small set of viewpoints and model kinds so that every description
answers the same stakeholder questions in the same way, and so that
reviewers know what "complete" looks like.]

### 1.2 Scope and rules of use

- **In scope**: [solution architecture descriptions, enterprise segment
  architectures, architecture review submissions].
- **Out of scope**: [low-level design documents, runbooks, product
  roadmaps].
- **Rule 1**: every architecture description names the catalogue version
  it uses and lists the viewpoints it applies (by ID).
- **Rule 2**: the viewpoints marked mandatory in section 11 for the
  engagement type must be present, or the description records why they
  are not needed.
- **Rule 3**: a project that needs a viewpoint not in the catalogue
  specifies it in its own description using the structure of section 8
  and proposes it to the catalogue owner (section 2.3).

### 1.3 Relationship to ISO/IEC/IEEE 42010:2022

The table maps the parts of this catalogue to the clauses of the standard
that cover the same concept. Clause numbers are from the second edition
(2022); headings are paraphrased.

| Catalogue section | Concept | 42010:2022 clause (orientation only) |
|---|---|---|
| 3 | Stakeholders and concerns | 5.2.3 (concepts), 6.2 and 6.4 (identification in an AD) |
| 4 | Stakeholder perspectives | 5.2.4, 6.3 |
| 5 | Aspects | 5.2.5, 6.5 |
| 6 | Model kinds, legends and view components | 5.2.8, 8.2 |
| 7 and 8 | Architecture viewpoints | 5.2.7, 6.6, 8.1; informative guidance in Annex B |
| 9 | View methods | 5.2.10, 8.3 |
| 10 | Correspondences and correspondence methods | 5.2.11, 6.9 |
| Whole catalogue | Architecture description framework | 5.4, 7.1; informative examples in Annex F |

A catalogue that also states its stakeholders, concerns and conformance
rules can be presented as the organisation's own architecture
description framework (ADF). Check clause 7.1 of the standard before
claiming that status, because it lists what an ADF specification has to
contain.

## 2. Catalogue governance

<!-- Guidance: Treat viewpoints like reusable products with a life cycle. Name who can propose, who approves, and how a viewpoint is retired without breaking descriptions that still use it. -->

### 2.1 Roles

| Role | Responsibility | Assigned to |
|---|---|---|
| Catalogue owner | Accountable for content and versioning; chairs change reviews | [@chief-architect] |
| Viewpoint steward | Owns one or more viewpoints; keeps specification, examples and templates current | [Named per viewpoint in section 7] |
| Contributor | Any architect who proposes a new or changed viewpoint or model kind | All architects |
| Approver | Accepts or rejects changes | [Architecture board] |

### 2.2 Life cycle states

| State | Meaning | Allowed in new descriptions? |
|---|---|---|
| Proposed | Submitted with a draft specification; not yet reviewed | No |
| Trial | Approved for use on named pilot projects to gather feedback | Only on pilot projects |
| Approved | Part of the catalogue; may be mandatory per section 11 | Yes |
| Deprecated | Being replaced; a successor is named | Only with a recorded reason |
| Retired | No longer supported; kept for reference by old descriptions | No |

### 2.3 Change process

1. The contributor raises a change with the problem it solves, the
   concerns involved and a draft specification in the format of
   section 8.
2. The catalogue owner checks for overlap with existing viewpoints and
   model kinds. Overlap is the most common reason for rejection.
3. The proposal runs as Trial on at least [two] projects, with the
   steward collecting feedback from authors and reviewers.
4. The architecture board approves, asks for changes or rejects. The
   decision is recorded in the revision history.
5. Deprecations name a successor and a date after which the old
   viewpoint may no longer be chosen.

### 2.4 Catalogue metamodel

The diagram shows how the elements of this catalogue relate. It mirrors
the conceptual relationships described in clause 5.2 of the standard, in
simplified form.

```mermaid
flowchart LR
  SC["Stakeholder class (SC)"] -->|"has"| CN["Concern (CN)"]
  PS["Perspective (PS)"] -->|"groups"| CN
  AS["Aspect (AS)"] -->|"relates to"| CN
  VP["Viewpoint (VP)"] -->|"frames"| CN
  VP -->|"uses"| MK["Model kind (MK)"]
  VP -->|"applies"| VM["View method (VM)"]
  CR["Correspondence rule (CR)"] -->|"links"| MK
  VP -->|"governs, in each description"| VIEW["View"]
```

## 3. Stakeholder classes

<!-- Guidance: List classes of stakeholder, not named people: each description fills in the real names. Keep the list short and stable; a new class is a catalogue change. -->

| ID | Stakeholder class | Typical roles | Main interest |
|---|---|---|---|
| SC-01 | *Example:* Business owner | Product owner, line-of-business head | Value, scope, cost, time |
| SC-02 | *Example:* Delivery team | Developers, testers, tech lead | What to build and how parts fit |
| SC-03 | *Example:* Operations | SRE, service desk, infrastructure | Running, recovering and scaling the system |
| SC-04 | *Example:* Security and privacy | Security architect, data protection officer | Threats, controls, personal data |
| SC-05 | *Example:* Risk, audit and compliance | Internal audit, compliance officer, regulator liaison | Evidence of control and conformance |
| SC-06 | *Example:* Enterprise architecture | Domain and enterprise architects | Fit with strategy, standards and roadmap |
| SC-07 | *Example:* Data and analytics | Data owner, data steward, analytics lead | Data meaning, quality and lineage |
| SC-08 | *Example:* Suppliers and partners | Vendors, integration partners | Interfaces and responsibilities |
| [SC-NN] | [Class] | [Roles] | [Interest] |

## 4. Perspectives and concern library

<!-- Guidance: A perspective is a way of looking at systems shared by several stakeholders, used to group concerns. The concern library is the set of standard questions every description may need to answer. Phrase each concern as a question; projects add their own specific concerns on top. -->

### 4.1 Perspectives

| ID | Perspective | Stakeholder classes | Concerns grouped |
|---|---|---|---|
| PS-01 | *Example:* Business | SC-01, SC-06 | CN-01, CN-02, CN-03 |
| PS-02 | *Example:* Engineering | SC-02, SC-06 | CN-04, CN-05, CN-06 |
| PS-03 | *Example:* Operations | SC-03 | CN-07, CN-08 |
| PS-04 | *Example:* Assurance | SC-04, SC-05 | CN-09, CN-10, CN-11 |
| PS-05 | *Example:* Information | SC-07, SC-04 | CN-12, CN-13 |
| [PS-NN] | [Perspective] | [SC IDs] | [CN IDs] |

### 4.2 Concern library

| ID | Concern (as a question) | Perspective | Raised by |
|---|---|---|---|
| CN-01 | *Example:* What business outcome does the system support, and for whom? | PS-01 | SC-01 |
| CN-02 | *Example:* Which business capabilities and processes does it change? | PS-01 | SC-01, SC-06 |
| CN-03 | *Example:* What does it cost to build and run, and over what period? | PS-01 | SC-01 |
| CN-04 | *Example:* What are the main parts, and who owns each one? | PS-02 | SC-02 |
| CN-05 | *Example:* How do the parts interact to deliver the key scenarios? | PS-02 | SC-02 |
| CN-06 | *Example:* How easily can the system change, and where are the seams? | PS-02 | SC-02, SC-06 |
| CN-07 | *Example:* Where does it run, and how is it deployed and scaled? | PS-03 | SC-03 |
| CN-08 | *Example:* How is it monitored and recovered after failure? | PS-03 | SC-03 |
| CN-09 | *Example:* Which threats apply, and which controls address them? | PS-04 | SC-04 |
| CN-10 | *Example:* Which regulations apply, and where is the evidence of compliance? | PS-04 | SC-05 |
| CN-11 | *Example:* Which external parties connect, and under which agreements? | PS-04 | SC-05, SC-08 |
| CN-12 | *Example:* What data does it hold, what does it mean and who owns it? | PS-05 | SC-07 |
| CN-13 | *Example:* Where does personal data flow and where is it stored? | PS-05 | SC-04, SC-07 |
| [CN-NN] | [Question] | [PS ID] | [SC IDs] |

## 5. Aspects

<!-- Guidance: An aspect is a characteristic of the system that cuts across several views, such as availability or privacy. Record it once here and say which viewpoints must address part of it, so cross-cutting qualities are traced through views instead of being parked in one "quality" chapter. -->

| ID | Aspect | Related concerns | Viewpoints that must address it | Steward |
|---|---|---|---|---|
| AS-01 | *Example:* Availability and resilience | CN-07, CN-08 | VP-03, VP-04, VP-05 | [@sre-lead] |
| AS-02 | *Example:* Security | CN-09 | VP-03, VP-05, VP-06 | [@security-architect] |
| AS-03 | *Example:* Privacy | CN-13 | VP-07, VP-06 | [@privacy-lead] |
| AS-04 | *Example:* Cost | CN-03 | VP-01, VP-05 | [@finops-lead] |
| AS-05 | *Example:* Changeability | CN-06 | VP-03, VP-08 | [@principal-engineer] |
| [AS-NN] | [Aspect] | [CN IDs] | [VP IDs] | [@steward] |

## 6. Model kind library

<!-- Guidance: A model kind is a reusable type of model, with its notation and conventions: a context diagram, a sequence diagram, a capability map, a data classification table. Define each once, with a legend that tells readers how to read it, and reuse it across viewpoints. Pitfall: two model kinds that differ only by tool or colour scheme; merge them. -->

| ID | Model kind | Category | Notation and legend | Default tool or format | Starter template | Status |
|---|---|---|---|---|---|---|
| MK-01 | *Example:* System context diagram | Diagram | Boxes for system and neighbours, people as actors, labelled arrows for purpose; legend required | Mermaid flowchart or C4 context level | `architecture/c4-architecture` | Approved |
| MK-02 | *Example:* Container and component diagram | Diagram | C4 container and component levels with technology labels | Mermaid flowchart | `architecture/c4-architecture` | Approved |
| MK-03 | *Example:* Scenario sequence diagram | Diagram | One diagram per key scenario; numbered messages; actors from MK-01 | Mermaid sequence diagram | `architecture/domain-message-flow` | Approved |
| MK-04 | *Example:* Deployment diagram | Diagram | Environments, nodes, zones and replicas; trust boundaries dashed | Mermaid flowchart | `dev/arc42` section 7 | Approved |
| MK-05 | *Example:* Capability map | Diagram or table | Levelled capabilities, heat map by investment or maturity | Table with heat column | `architecture/business-capability-map` | Approved |
| MK-06 | *Example:* Threat and control table | Table | Threat ID, element, category, control ID, residual risk | Markdown table | `security/threat-model` | Approved |
| MK-07 | *Example:* Data flow diagram | Diagram | Processes, stores, external entities, flows; personal data flows marked | Mermaid flowchart | `security/threat-model` | Approved |
| MK-08 | *Example:* Information model with classification | Diagram and table | Entities and relationships; each entity carries an owner and a classification | Mermaid ER diagram and table | `architecture/data-dictionary` | Approved |
| MK-09 | *Example:* Decision record | Text | Context, options, decision, consequences | ADR file per decision | `architecture/adr-full` | Approved |
| MK-10 | *Example:* Cost model | Table | Cost lines per year, one-off and recurring, with assumptions | Spreadsheet or table | `architecture/tco-analysis` | Trial |
| [MK-NN] | [Model kind] | [Diagram / Table / Text] | [Notation and legend] | [Tool] | [Template] | [State] |

## 7. Viewpoint catalogue

<!-- Guidance: One row per viewpoint. The concern and stakeholder columns must use IDs from sections 3 and 4; the model kind column must use IDs from section 6. A viewpoint without at least one concern and one model kind is incomplete. -->

| ID | Viewpoint | Concerns framed | Stakeholder classes | Model kinds | View methods | Steward | State |
|---|---|---|---|---|---|---|---|
| VP-01 | *Example:* Business context | CN-01, CN-02, CN-03 | SC-01, SC-06 | MK-01, MK-05, MK-10 | VM-01 | [@business-architect] | Approved |
| VP-02 | *Example:* Integration and partners | CN-11 | SC-02, SC-05, SC-08 | MK-01, MK-03 | VM-02 | [@integration-architect] | Approved |
| VP-03 | *Example:* Structure | CN-04, CN-06 | SC-02, SC-06 | MK-02 | VM-02 | [@principal-engineer] | Approved |
| VP-04 | *Example:* Behaviour | CN-05 | SC-02, SC-03 | MK-03 | VM-02, VM-04 | [@principal-engineer] | Approved |
| VP-05 | *Example:* Deployment and operations | CN-07, CN-08 | SC-03 | MK-04 | VM-03 | [@sre-lead] | Approved |
| VP-06 | *Example:* Security and trust | CN-09 | SC-04 | MK-07, MK-06 | VM-05 | [@security-architect] | Approved |
| VP-07 | *Example:* Information | CN-12, CN-13 | SC-07, SC-04 | MK-08, MK-07 | VM-06 | [@data-architect] | Approved |
| VP-08 | *Example:* Decisions | CN-06, CN-10 | SC-05, SC-06 | MK-09 | VM-07 | [@chief-architect] | Approved |
| VP-09 | *Example:* Cost | CN-03 | SC-01 | MK-10 | VM-08 | [@finops-lead] | Trial |
| [VP-NN] | [Viewpoint] | [CN IDs] | [SC IDs] | [MK IDs] | [VM IDs] | [@steward] | [State] |

## 8. Viewpoint specifications

<!-- Guidance: Write one specification per viewpoint in the same structure. The fields below follow the kinds of information the standard expects a viewpoint specification to carry (clause 8.1, with informative guidance in Annex B), expressed in this template's own words. Keep each specification to about one page and include a small example view or a link to one. -->

Each specification uses these fields:

- **Overview**: what the view shows, in two or three sentences.
- **Concerns framed**: concern IDs, and the specific questions the view
  answers.
- **Typical stakeholders**: stakeholder class IDs.
- **Perspectives and aspects**: which perspectives it serves and which
  aspects it must address in part.
- **Model kinds**: model kind IDs, and any viewpoint-specific rules on
  how they are used.
- **View methods**: how to build the view and how to check it.
- **Correspondence rules**: rules that tie this view to others.
- **Sources and examples**: where the viewpoint comes from and a link to
  a good example view.

### 8.1 VP-01 Business context viewpoint

- **Overview**: places the system in its business setting: the outcome it
  serves, the capabilities it changes, the people and organisations
  around it and the cost envelope. Read first by sponsors and by the
  architecture board.
- **Concerns framed**: CN-01 (outcome and users), CN-02 (capabilities and
  processes changed), CN-03 (cost envelope).
- **Typical stakeholders**: SC-01, SC-06.
- **Perspectives and aspects**: PS-01; addresses part of AS-04 (cost).
- **Model kinds**: MK-01 system context diagram at business level (no
  technology labels); MK-05 capability map with the changed capabilities
  highlighted; MK-10 cost model summary for the first three years.
- **View methods**: VM-01 (build from the business case and a stakeholder
  interview; check that every actor on MK-01 maps to a capability on
  MK-05 or is marked external).
- **Correspondence rules**: CR-01 and CR-04 in section 10.
- **Sources and examples**: organisation-specific; informed by the
  TOGAF Architecture Vision (`architecture/togaf-architecture-vision`)
  and the Business Capability Map (`architecture/business-capability-map`).
  *Example* view: [link to the claims portal description, section 2].

### 8.2 VP-06 Security and trust viewpoint

- **Overview**: shows where data and requests cross trust boundaries,
  which threats apply to each crossing and which controls answer them.
- **Concerns framed**: CN-09 (threats and controls).
- **Typical stakeholders**: SC-04, with SC-03 and SC-05 as readers.
- **Perspectives and aspects**: PS-04; addresses part of AS-02 (security)
  and AS-03 (privacy).
- **Model kinds**: MK-07 data flow diagram with trust boundaries; MK-06
  threat and control table keyed to the elements of MK-07.
- **View methods**: VM-05 (structured threat modelling over MK-07, one
  pass per trust boundary; check that each threat has a control or an
  accepted risk with an owner).
- **Correspondence rules**: CR-02 and CR-03 in section 10.
- **Sources and examples**: Threat Model (`security/threat-model`) and
  Security Architecture (`security/security-architecture`).

### 8.3 VP-02 to VP-09

[Repeat the structure above for every viewpoint in section 7. Keep the
fields in the same order so reviewers can compare specifications
quickly.]

## 9. View methods

<!-- Guidance: A view method says how to produce and check a view: the steps, the inputs, the analysis or review technique and the completion criteria. Methods make views reviewable. -->

| ID | View method | Inputs | Steps in brief | Done when |
|---|---|---|---|---|
| VM-01 | *Example:* Business context build and check | Business case, stakeholder interviews | Draft MK-01 and MK-05 together; walk through with the sponsor | Sponsor confirms actors and changed capabilities |
| VM-02 | *Example:* Structural walkthrough | Requirements, key scenarios | Draw containers; trace each key scenario through them | Every scenario passes through named owners |
| VM-03 | *Example:* Operability review | Service level objectives, platform standards | Map containers to nodes; check redundancy and recovery paths | Each objective has a mechanism and a test |
| VM-04 | *Example:* Scenario sequence analysis | Key scenarios, MK-02 | One MK-03 per scenario; check timeouts and failure paths | Failure path drawn for each external call |
| VM-05 | *Example:* Threat modelling session | MK-07, data classification | Enumerate threats per boundary; assign controls | No threat without control or accepted risk |
| VM-06 | *Example:* Data ownership review | MK-08, records of processing | Assign owner and class to each entity; trace personal data flows | Every entity has an owner and a class |
| VM-07 | *Example:* Decision review | Open questions, options analyses | Record each significant choice as MK-09 | No significant choice without a record |
| VM-08 | *Example:* Cost estimate review | Sizing, price lists | Build MK-10 with assumptions; review with finance | Finance accepts assumptions |
| [VM-NN] | [Method] | [Inputs] | [Steps] | [Criterion] |

## 10. Correspondence rules

<!-- Guidance: A correspondence rule states a relationship that must hold between elements of different views or models, so that the description stays consistent. Write rules that a reviewer can check by looking at two views side by side. Pitfall: rules so general ("views must be consistent") that nobody can test them. -->

| ID | Rule | Between | How to check | Severity if broken |
|---|---|---|---|---|
| CR-01 | *Example:* Every external actor or system on the business context diagram appears on the structure view as a connection | VP-01 MK-01 and VP-03 MK-02 | Compare the two diagrams name by name | Major |
| CR-02 | *Example:* Every flow that crosses a trust boundary on MK-07 corresponds to a connection on MK-02 | VP-06 and VP-03 | Trace each crossing to a container connection | Major |
| CR-03 | *Example:* Every control in MK-06 that runs in infrastructure appears on the deployment view | VP-06 and VP-05 | Look up each control in MK-04 | Minor |
| CR-04 | *Example:* Cost lines in MK-10 cover every runtime node in MK-04 | VP-09 and VP-05 | Match nodes to cost lines | Minor |
| CR-05 | *Example:* Every entity marked personal data in MK-08 appears on at least one flow in MK-07 | VP-07 and VP-06 | Search MK-07 for each entity | Major |
| [CR-NN] | [Rule] | [VP / MK IDs] | [Check] | [Major / Minor] |

## 11. Selection guide

<!-- Guidance: Tell authors which viewpoints are mandatory (M), recommended (R) or optional (O) for each type of engagement. Keep the mandatory set small so a description can be complete in reasonable time. -->

| Engagement type | VP-01 | VP-02 | VP-03 | VP-04 | VP-05 | VP-06 | VP-07 | VP-08 | VP-09 |
|---|---|---|---|---|---|---|---|---|---|
| *Example:* New customer-facing system | M | M | M | R | M | M | M | M | R |
| *Example:* Internal tool, no personal data | R | O | M | O | M | R | O | M | O |
| *Example:* Integration project | R | M | R | M | R | M | R | M | O |
| *Example:* Infrastructure or platform change | O | O | R | O | M | M | O | M | R |
| *Example:* Enterprise segment architecture | M | R | O | O | O | R | M | M | M |
| [Engagement type] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] | [M/R/O] |

## 12. Coverage checks

<!-- Guidance: Use these checks when the catalogue changes. Every concern in the library should be framed by at least one approved viewpoint, and every aspect addressed by at least two, or the catalogue has a gap. -->

### 12.1 Concern coverage

| Concern | Framed by | Approved viewpoints framing it | Gap? |
|---|---|---|---|
| CN-01 to CN-02 | VP-01 | 1 | No |
| CN-03 | VP-01, VP-09 | 1 (VP-09 on trial) | No |
| CN-04 | VP-03 | 1 | No |
| CN-05 | VP-04 | 1 | No |
| CN-06 | VP-03, VP-08 | 2 | No |
| CN-07, CN-08 | VP-05 | 1 | No |
| CN-09 | VP-06 | 1 | No |
| CN-10 | VP-08 | 1 | *Example:* Partly: evidence of compliance needs a dedicated table; candidate model kind for next version |
| CN-11 | VP-02 | 1 | No |
| CN-12, CN-13 | VP-07 | 1 | No |

### 12.2 Catalogue health checklist

- [ ] Every viewpoint frames at least one concern from section 4.
- [ ] Every viewpoint names at least one model kind and one view method.
- [ ] Every model kind is used by at least one approved viewpoint.
- [ ] Every aspect is addressed by at least two viewpoints.
- [ ] No two viewpoints frame exactly the same concerns for the same
      stakeholders (merge candidates).
- [ ] Every Trial viewpoint has a named pilot and an end date.
- [ ] Deprecated viewpoints name a successor.

## 13. Mapping to established viewpoint sets

<!-- Guidance: Many architects already know one of the published viewpoint sets. Show how the catalogue lines up with them so people can transfer what they know. Names of the published sets are used for orientation only. -->

| Catalogue viewpoint | C4 diagram | 4+1 view model | arc42 section | Related template |
|---|---|---|---|---|
| VP-01 Business context | System context (business level) | Scenarios (use case view) | 3 Context and scope | `architecture/togaf-architecture-vision` |
| VP-02 Integration and partners | System context | Scenarios | 3 Context and scope | `architecture/integration-design` |
| VP-03 Structure | Container and component | Logical and development views | 5 Building block view | `architecture/c4-architecture` |
| VP-04 Behaviour | Dynamic diagram | Process view | 6 Runtime view | `architecture/architecture-4plus1` |
| VP-05 Deployment and operations | Deployment diagram | Physical view | 7 Deployment view | `dev/arc42` |
| VP-06 Security and trust | No direct equivalent | No direct equivalent | 8 Cross-cutting concepts | `security/threat-model` |
| VP-07 Information | No direct equivalent | Logical view (in part) | 8 Cross-cutting concepts | `architecture/data-dictionary` |
| VP-08 Decisions | No direct equivalent | No direct equivalent | 9 Architecture decisions | `architecture/adr-full` |
| VP-09 Cost | No direct equivalent | No direct equivalent | No direct equivalent | `architecture/tco-analysis` |

Organisations using an enterprise framework can add a column for its
viewpoint names, for example the TOGAF Standard or the Unified
Architecture Framework (`architecture/uaf-architecture-description`).
The Zachman Classification (`architecture/zachman-classification`) is a
classification scheme rather than a viewpoint set, but it can be used to
check that the catalogue covers the questions the organisation cares
about.

## 14. Glossary and references

<!-- Guidance: Define terms in your own words and keep the definitions consistent with how the catalogue uses them. Point to the standard for normative definitions. -->

### 14.1 Glossary

- **Architecture description (AD)**: the work product that expresses an
  architecture for a given system and its stakeholders.
- **Viewpoint**: the reusable recipe for a view: the concerns it frames,
  for whom, and with which model kinds and methods.
- **View**: one application of a viewpoint to a particular system.
- **Model kind**: a reusable type of model with its notation, legend and
  conventions.
- **View method**: a defined way of producing and checking a view.
- **Perspective**: a shared way of looking at systems, used to group
  related concerns.
- **Aspect**: a characteristic of the system that cuts across views.
- **Correspondence rule**: a relationship that must hold between elements
  of different views or models.
- **Architecture description framework (ADF)**: the conventions,
  principles and practices for writing architecture descriptions in a
  given community; a catalogue like this one is its core.

### 14.2 References

| ID | Reference | Use in this catalogue |
|---|---|---|
| REF-01 | ISO/IEC/IEEE 42010:2022, *Software, systems and enterprise: Architecture description*, second edition, 2022-11 (cancels and replaces the 2011 edition) | Concepts and clause map in section 1.3 |
| REF-02 | Architecture Description (`architecture/architecture-description-42010`) | Template that consumes this catalogue |
| REF-03 | Architecture Process Plan and Records (`architecture/architecture-practice-42020`) | Practice that owns this catalogue |
| REF-04 | C4 Architecture (`architecture/c4-architecture`), 4+1 View Model (`architecture/architecture-4plus1`), arc42 (`dev/arc42`) | Established viewpoint sets in section 13 |
| REF-05 | Threat Model (`security/threat-model`), Data Dictionary (`architecture/data-dictionary`), Architecture Decision Record (`architecture/adr-full`) | Starter templates for model kinds |

Official text: ISO/IEC/IEEE 42010:2022 is a paid standard published by
ISO, IEC and IEEE; purchase or licensed access at
https://www.iso.org/standard/74393.html (also sold by IEEE and national
standards bodies). Clause numbers in this template were checked against
the publicly available table of contents of the second edition on
2026-10-30.

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 42010:2022, *Software, systems and
enterprise: Architecture description* (second edition, November 2022):
stakeholders, concerns, perspectives, aspects, viewpoints, model kinds,
view methods, correspondences and architecture description frameworks.
Only the standard's name, edition, concept names and clause numbers are
used; clause wording, definitions and tables are not reproduced, and all
explanations, tables and examples here are original text written for this
collection. Obtain the standard for its normative requirements and check
the current edition before claiming conformance. Official text: ISO, IEC
and IEEE, purchase or licensed access at
https://www.iso.org/standard/74393.html. C4, 4+1 and arc42 are named for
orientation only. Template licence: MIT.