Architecture Viewpoint Catalogue Template (ISO/IEC/IEEE 42010)

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.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and use
2. Catalogue governance
3. Stakeholder classes
4. Perspectives and concern library
5. Aspects
6. Model kind library
7. Viewpoint catalogue
8. Viewpoint specifications
9. View methods
10. Correspondence rules
11. Selection guide
12. Coverage checks
13. Mapping to established viewpoint sets
14. Glossary and references

1. Purpose, scope and use

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.

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

2.1 Roles

2.2 Life cycle states

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.

3. Stakeholder classes

4. Perspectives and concern library

4.1 Perspectives

4.2 Concern library

5. Aspects

6. Model kind library

7. Viewpoint catalogue

8. Viewpoint specifications

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

10. Correspondence rules

11. Selection guide

12. Coverage checks

12.1 Concern coverage

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

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

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

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.