# Architecture Process Plan and Records: [Organisation or architecture collection]

> Plan and working records for an architecture practice, organised on the six architecture
> processes of ISO/IEC/IEEE 42020:2019 (*Software, systems and enterprise: Architecture
> processes*): Governance, Management, Conceptualization, Evaluation, Elaboration and Enablement.
> The 2019 edition is current; ISO lists it as "to be revised" (stage 90.92 since 2026-01-08), and
> a second edition, *Enterprise, systems and software: Architecture processes*, is registered as
> work item AWI 42020 since 2026-05-22 (IEEE project P42020, PAR approved 2026-09-25). Use it to set up how a team or enterprise governs its
> collection of architectures and how each architecture effort is conceptualised, evaluated,
> elaborated and supported. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Fill sections 1 to 3 once for the practice and review them yearly. Sections 4 to 9 hold one
  block of records per process; add rows as architecture efforts run.
- 42020 describes processes (purpose, outcomes, activities, work products), not a method or a
  framework. Plug your own methods in: TOGAF ADM phases, arc42, C4, ATAM, or an internal method.
  Map them to the six processes in section 3.3.
- Governance and Management act on the whole architecture collection; Conceptualization,
  Evaluation and Elaboration act on one architecture at a time; Enablement supports all of them.
  Keep that split visible, or the practice ends up managing documents instead of architectures.
- Clause numbers refer to ISO/IEC/IEEE 42020:2019. Activity labels are short paraphrases in
  original wording; obtain the standard for its normative outcomes and tasks.
-->

## Document control

<!-- Guidance: Identify the practice and the collection it governs. The owner is usually the chief architect or head of the architecture office. -->

| Field | Value |
|---|---|
| Document ID | [ARCH-PROC-001] |
| Organisation unit | [Enterprise / Business unit / Programme / Product line] |
| Architecture collection | [Name of the set of architectures governed, for example "Group digital architectures"] |
| Process standard | ISO/IEC/IEEE 42020:2019 |
| Conformance case | [Full conformance / Tailored conformance] |
| Version | [0.1] |
| Status | [Draft / Approved / In use / Superseded] |
| Owner | [@chief-architect] |
| Approvers / reviewers | [@cio], [@architecture-board-chair], [@head-of-portfolio] |
| Review cycle | [Yearly, and after each major reorganisation] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor (CIO or CTO) | [@name] | [Approved / Approved with conditions] | YYYY-MM-DD |
| Architecture board chair | [@name] | [Approved] | YYYY-MM-DD |
| Portfolio management lead | [@name] | [Reviewed] | YYYY-MM-DD |
| Quality or process owner | [@name] | [Reviewed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to the process design separately from routine record updates; routine entries in sections 4 to 9 do not need a new version. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of the process plan |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the executive sponsor; tailoring record agreed |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Evaluation process now requires ATAM for platform decisions (EVL-POL-02) |

## Contents

1. [Purpose, scope and context](#1-purpose-scope-and-context)
2. [Conformance and tailoring](#2-conformance-and-tailoring)
3. [Process overview and responsibilities](#3-process-overview-and-responsibilities)
4. [Architecture Governance](#4-architecture-governance)
5. [Architecture Management](#5-architecture-management)
6. [Architecture Conceptualization records](#6-architecture-conceptualization-records)
7. [Architecture Evaluation records](#7-architecture-evaluation-records)
8. [Architecture Elaboration records](#8-architecture-elaboration-records)
9. [Architecture Enablement](#9-architecture-enablement)
10. [Work products register](#10-work-products-register)
11. [Process metrics](#11-process-metrics)
12. [Interfaces with other processes](#12-interfaces-with-other-processes)
13. [Review and improvement](#13-review-and-improvement)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and context

<!-- Guidance: Say why the organisation runs architecture as a set of processes and what the collection contains. Pitfall: a scope that lists every system, which nobody can govern; scope the collection to architectures that carry decisions. -->

### 1.1 Purpose

[*Example:* "This plan defines how the Group Architecture Office governs and manages the group's
collection of enterprise, segment and solution architectures, and how each architecture effort
is conceptualised, evaluated and elaborated. It aims to make investment decisions faster and
better informed, reduce duplicate platforms, and keep architectures current enough to be used."]

### 1.2 Architecture collection in scope

| ID | Architecture | Level | Entity of interest | Owner | Status |
|---|---|---|---|---|---|
| ARC-001 *(Example)* | Group enterprise architecture | Enterprise | Retail group | [@chief-architect] | Current, reviewed yearly |
| ARC-002 *(Example)* | Customer and commerce segment architecture | Segment | Online and store commerce capabilities | [@domain-architect-commerce] | Current |
| ARC-003 *(Example)* | Order Management Platform solution architecture | Solution | Order capture and fulfilment system | [@solution-architect-omp] | In conceptualization |
| ARC-004 *(Example)* | Data platform reference architecture | Reference | Analytical data platform | [@data-architect] | Elaboration |
| [ARC-nnn] | [Architecture] | [Enterprise / Segment / Solution / Reference / Product line] | [Entity] | [@owner] | [Status] |

### 1.3 Context and relationship to other life cycle processes

Architecture processes do not replace life cycle processes; they inform them. Clause 5.2 relates
architecture to other processes and information elements, and clause 5.6 separates architecture
(fundamental concepts and properties) from design (realisation detail). Record the life cycle
standards and internal processes this practice connects to.

| Related process or standard | Relationship |
|---|---|
| ISO/IEC/IEEE 15288 and 12207 Architecture Definition process *(Example)* | Solution efforts in the delivery life cycle call Conceptualization, Evaluation and Elaboration for their architecture work |
| ISO/IEC/IEEE 42010:2022 *(Example)* | Elaboration produces architecture descriptions conforming to 42010 |
| ISO/IEC/IEEE 42030:2019 *(Example)* | Evaluation uses the 42030 framework for objectives, factors and results |
| Investment and portfolio process *(Example)* | Governance decisions feed stage gates; portfolio priorities set collection objectives |
| [Process] | [Relationship] |

## 2. Conformance and tailoring

<!-- Guidance: Clause 4 allows full conformance or tailored conformance; tailoring follows the normative tailoring process in Annex A. Record every omitted or modified outcome and why. -->

### 2.1 Conformance claim

[*Example:* "The Group Architecture Office claims tailored conformance to ISO/IEC/IEEE 42020:2019
for the six architecture processes. Tailoring is listed in section 2.2. Conformance is reviewed at
the yearly process review (section 13)."]

### 2.2 Tailoring record

| ID | Process | Tailoring decision | Rationale | Affected outcomes | Approved by |
|---|---|---|---|---|---|
| TLR-01 *(Example)* | Conceptualization | Small changes (below USD 250,000 and no new platform) skip tradespace characterisation | Proportionate effort; the architecture board handles exceptions | Candidate architectures limited to one plus "do nothing" | [@board-chair] |
| TLR-02 *(Example)* | Evaluation | Lightweight checklist review allowed for solution architectures without new platforms | ATAM is reserved for platform and high-risk decisions | Evaluation depth | [@board-chair] |
| TLR-03 *(Example)* | Enablement | Tool acquisition handled by the group IT procurement process, not by this practice | Avoid duplicate procurement | Acquisition activity | [@cio] |
| [TLR-nn] | [Process] | [Decision] | [Rationale] | [Outcomes] | [@name] |

## 3. Process overview and responsibilities

<!-- Guidance: Show how the six processes interact (clauses 5.3 to 5.5) and who performs each. Pitfall: assigning all six processes to the same architect, which removes the independence of evaluation. -->

### 3.1 Process map

The map shows which processes act on the whole collection, which act on one architecture effort,
and how Enablement supports all of them. Arrows show the main information flows.

```mermaid
flowchart TB
  subgraph Collection[Acts on the architecture collection]
    GOV[Architecture Governance] --> MGT[Architecture Management]
    MGT --> GOV
  end
  subgraph Effort[Acts on one architecture at a time]
    CON[Architecture Conceptualization] --> EVL[Architecture Evaluation]
    EVL --> CON
    CON --> ELB[Architecture Elaboration]
    ELB --> EVL
  end
  MGT --> CON
  MGT --> ELB
  EVL --> MGT
  ENB[Architecture Enablement] -.supports.-> GOV
  ENB -.supports.-> MGT
  ENB -.supports.-> CON
  ENB -.supports.-> EVL
  ENB -.supports.-> ELB
```

### 3.2 Process summary

| Process | 42020:2019 clause | Purpose in this organisation (original wording) | Process owner |
|---|---|---|---|
| Architecture Governance | 6 | Set direction for the collection, make governance decisions, and check that directives are followed | [@architecture-board-chair] |
| Architecture Management | 7 | Plan, resource and run the architecture work, keep the collection current, and measure how well architecting works | [@head-of-architecture-office] |
| Architecture Conceptualization | 8 | Understand the problem, set architecture objectives, and form candidate architectures | [@lead-architect per effort] |
| Architecture Evaluation | 9 | Judge architectures against objectives and stakeholder value and report findings | [@evaluation-lead, independent of the effort] |
| Architecture Elaboration | 10 | Describe the chosen architecture in viewpoints, models and views fit for its users | [@lead-architect per effort] |
| Architecture Enablement | 11 | Provide and improve the methods, tools, repository, skills and services the other processes need | [@architecture-practice-lead] |

### 3.3 Mapping of local methods to processes

<!-- Guidance: Map each local method to the process it serves, so gaps and overlaps are visible. Annex H (informative) of the standard maps the processes to architecture frameworks; compare your mapping with it, and note where your method covers a process only partly. Pitfall: treating a framework's phase list as if it covered all six processes. -->

| Local method or framework | Governance | Management | Conceptualization | Evaluation | Elaboration | Enablement |
|---|---|---|---|---|---|---|
| Architecture board and principles *(Example)* | Yes | | | Partly | | |
| TOGAF ADM phases A to H *(Example)* | Phase G | Preliminary, H | A, B to D (options) | Checkpoints | B to D, F | Preliminary |
| ATAM *(Example)* | | | | Yes | | |
| arc42 and C4 *(Example)* | | | | | Yes | Templates |
| Architecture repository *(Example)* | | Yes | | | | Yes |
| [Method] | | | | | | |

### 3.4 Responsibility matrix

| Activity | Board | Architecture office | Lead architect | Evaluation lead | Delivery team | Portfolio |
|---|---|---|---|---|---|---|
| Set collection objectives | A | R | C | I | I | C |
| Approve governance decisions | A | R | C | C | I | I |
| Plan architecture work | I | A | R | C | C | C |
| Conceptualize an architecture | I | C | A | C | C | I |
| Evaluate an architecture | I | A | C | R | C | I |
| Elaborate an architecture | I | C | A | I | R | I |
| Provide tools and skills | I | A | C | C | C | I |

R responsible, A accountable, C consulted, I informed.

## 4. Architecture Governance

<!-- Guidance: Governance sets direction and checks compliance for the whole collection (clause 6). Record objectives, directives, decisions and compliance results. Pitfall: governance that only approves documents and never checks whether delivered systems follow the decisions. -->

### 4.1 Governance plan

| Item | Value |
|---|---|
| Governance body | [*Example:* Group Architecture Board, monthly, chaired by the CTO] |
| Decision rights | [*Example:* Approve new platforms, principles, standards and exceptions; recommend investments] |
| Escalation path | [*Example:* Board to CIO; CIO to executive committee for decisions above USD 5 million] |
| Charter | [Link to Architecture Governance Charter (`architecture/architecture-governance-charter`)] |
| Activities covered | Plan and monitor governance (6.4.1, 6.4.2); set collection objectives (6.4.3); make decisions (6.4.4); monitor compliance (6.4.5); review implementation of directives (6.4.6) |

### 4.2 Collection objectives

| ID | Objective | Measure | Target | Business driver | Review date |
|---|---|---|---|---|---|
| GOV-OBJ-01 *(Example)* | Reduce overlapping commerce platforms | Number of order management systems | From 4 to 1 within three years | Cost and customer experience | YYYY-MM-DD |
| GOV-OBJ-02 *(Example)* | Make every new solution cloud-hosted on the group landing zone | Share of new solutions on landing zone | 100% | Security and run cost | YYYY-MM-DD |
| GOV-OBJ-03 *(Example)* | Keep architectures usable | Share of current architectures reviewed in the last 12 months | >= 90% | Decision quality | YYYY-MM-DD |
| [GOV-OBJ-nn] | [Objective] | [Measure] | [Target] | [Driver] | YYYY-MM-DD |

### 4.3 Governance directives

| ID | Directive | Type | Applies to | Source |
|---|---|---|---|---|
| GOV-DIR-01 *(Example)* | Reuse an existing platform before building a new one | Principle | All solution architectures | Architecture Principles (`architecture/architecture-principles`) |
| GOV-DIR-02 *(Example)* | All public APIs follow the group API guidelines | Standard | Solution architectures with external APIs | API Design Guidelines (`architecture/api-design-guidelines`) |
| GOV-DIR-03 *(Example)* | Platform decisions require an independent evaluation | Policy | New or replaced platforms | EVL-POL-02 |
| [GOV-DIR-nn] | [Directive] | [Principle / Standard / Policy / Guidance] | [Scope] | [Source] |

### 4.4 Governance decision log

| ID | Date | Decision | Architecture | Basis | Conditions | Status |
|---|---|---|---|---|---|---|
| GOV-DEC-001 *(Example)* | YYYY-MM-DD | Approve candidate A as target for the Order Management Platform | ARC-003 | Evaluation EVL-001 | Regional failover rehearsed before go-live | Approved with conditions |
| GOV-DEC-002 *(Example)* | YYYY-MM-DD | Grant a 12-month exception to GOV-DIR-02 for the legacy loyalty API | ARC-002 | Exception request | Retire API by YYYY-MM-DD | Exception granted |
| [GOV-DEC-nnn] | YYYY-MM-DD | [Decision] | [ARC-nnn] | [Basis] | [Conditions] | [Status] |

### 4.5 Compliance monitoring

| ID | Architecture or project | Directive | Check method | Result | Action |
|---|---|---|---|---|---|
| GOV-CMP-01 *(Example)* | Order Management Platform build | GOV-DIR-02 | Automated API lint in pipeline | Compliant | None |
| GOV-CMP-02 *(Example)* | Store inventory service | GOV-DIR-01 | Architecture compliance review | Non-compliant: new search engine introduced | Raise exception request or migrate by YYYY-MM-DD |
| [GOV-CMP-nn] | [Scope] | [GOV-DIR-nn] | [Method] | [Result] | [Action] |

Use Architecture Compliance Assessment (`architecture/architecture-compliance-assessment`) for the
detailed review record and Architecture Contract (`architecture/architecture-contract`) where
delivery teams sign up to conditions.

## 5. Architecture Management

<!-- Guidance: Management runs the architecture work and keeps the collection in shape (clause 7). Record the management approach, plan, collection register and effectiveness measures. Pitfall: a repository full of outdated models with no owner and no review date. -->

### 5.1 Management approach

| Item | Value |
|---|---|
| Planning horizon | [*Example:* Rolling 12 months, reviewed quarterly with the portfolio] |
| Intake | [*Example:* Requests via Request for Architecture Work (`architecture/request-for-architecture-work`)] |
| Prioritisation | [*Example:* Business value, risk, and dependency on collection objectives] |
| Configuration control | [*Example:* Architectures versioned in the repository; baselines approved by the board] |
| Activities covered | Plan and monitor management (7.4.1, 7.4.2); develop approach (7.4.3); manage the collection (7.4.4); monitor architecting effectiveness (7.4.5); prepare completion of the plan (7.4.6) |

### 5.2 Architecture work plan

| ID | Effort | Architecture | Processes invoked | Start | End | Lead | Status |
|---|---|---|---|---|---|---|---|
| MGT-WRK-01 *(Example)* | Order Management Platform target architecture | ARC-003 | Conceptualization, Evaluation, Elaboration | YYYY-MM-DD | YYYY-MM-DD | [@solution-architect-omp] | In progress |
| MGT-WRK-02 *(Example)* | Yearly refresh of group enterprise architecture | ARC-001 | Conceptualization, Elaboration, Evaluation | YYYY-MM-DD | YYYY-MM-DD | [@chief-architect] | Planned |
| MGT-WRK-03 *(Example)* | Data platform reference architecture v2 | ARC-004 | Elaboration, Evaluation | YYYY-MM-DD | YYYY-MM-DD | [@data-architect] | In progress |
| [MGT-WRK-nn] | [Effort] | [ARC-nnn] | [Processes] | YYYY-MM-DD | YYYY-MM-DD | [@lead] | [Status] |

### 5.3 Collection health

| Architecture | Last baseline | Last review | Next review | Open evaluation findings | Health |
|---|---|---|---|---|---|
| ARC-001 *(Example)* | v4.0, YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | 2 | Green |
| ARC-002 *(Example)* | v2.3, YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | 5 | Amber: review overdue by two months |
| ARC-003 *(Example)* | Draft | Not yet | YYYY-MM-DD | 3 | In progress |
| [ARC-nnn] | [Version, date] | YYYY-MM-DD | YYYY-MM-DD | [n] | [Green / Amber / Red] |

### 5.4 Management risks and issues

| ID | Risk or issue | Impact | Response | Owner |
|---|---|---|---|---|
| MGT-RSK-01 *(Example)* | Two senior architects leave in the same quarter | Effort MGT-WRK-02 slips | Pair junior architects now; contract interim support | [@head-of-architecture-office] |
| MGT-RSK-02 *(Example)* | Delivery teams bypass intake for urgent work | Architectures diverge from decisions | Fast-track intake with a five-day decision target | [@head-of-architecture-office] |
| [MGT-RSK-nn] | [Risk] | [Impact] | [Response] | [@owner] |

## 6. Architecture Conceptualization records

<!-- Guidance: Conceptualization turns a problem into candidate architectures (clause 8). Keep one record per effort. The key outputs are objectives with critical success criteria and a characterised tradespace. Pitfall: jumping to one favoured solution and calling it "the" architecture. -->

### 6.1 Activity record for effort MGT-WRK-01 *(Example)*

| 42020 activity (clause) | Record | Evidence |
|---|---|---|
| Plan and monitor the effort (8.4.1, 8.4.2) | Two-month effort, three architects, weekly checkpoint | Effort plan |
| Characterize problem space (8.4.3) | Four order systems, inconsistent stock, 9 s checkout at peak | Current State Assessment (`architecture/current-state-assessment`) |
| Establish objectives and critical success criteria (8.4.4) | CON-OBJ-01 to CON-OBJ-04 below | Section 6.2 |
| Synthesize potential solutions (8.4.5) | Five options from workshop, including package and build | Solution Options Analysis (`architecture/solution-options-analysis`) |
| Characterize solutions and tradespace (8.4.6) | Cost, time to market, availability and change effort plotted per option | Section 6.3 |
| Formulate candidate architectures (8.4.7) | Candidates A and B carried forward | Section 6.3 |
| Capture concepts and properties (8.4.8) | Key concepts and properties per candidate recorded | Concept notes, decision log |
| Relate to other architectures and affected entities (8.4.9) | Depends on ARC-004 data platform and the landing zone | Section 6.4 |
| Coordinate use by intended users (8.4.10) | Candidates presented to product, operations and security | Workshop minutes |

### 6.2 Architecture objectives and critical success criteria

| ID | Objective | Critical success criterion | Stakeholder |
|---|---|---|---|
| CON-OBJ-01 *(Example)* | One order platform for all channels | All channels on one order model by YYYY-MM | Head of e-commerce |
| CON-OBJ-02 *(Example)* | Peak-season resilience | Order capture availability >= 99.95% in peak months | Operations director |
| CON-OBJ-03 *(Example)* | Faster channel onboarding | New channel in <= 6 person-weeks | Chief digital officer |
| CON-OBJ-04 *(Example)* | Contained run cost | Three-year run cost <= USD 4.2 million | Chief financial officer |
| [CON-OBJ-nn] | [Objective] | [Criterion] | [Stakeholder] |

### 6.3 Tradespace and candidates

| Candidate | Summary | CON-OBJ-01 | CON-OBJ-02 | CON-OBJ-03 | CON-OBJ-04 | Carried forward |
|---|---|---|---|---|---|---|
| A *(Example)* | Event-driven modular monolith | Strong | Likely | Likely | Strong | Yes |
| B *(Example)* | Microservices on managed Kubernetes | Strong | Uncertain | Strong | Uncertain | Yes |
| C *(Example)* | Commercial order management package | Strong | Likely | Weak (vendor roadmap) | Weak (licences) | No |
| D *(Example)* | Keep four systems, add integration layer | Weak | Uncertain | Weak | Strong | No (baseline only) |
| [Candidate] | [Summary] | [Rating] | [Rating] | [Rating] | [Rating] | [Yes / No] |

### 6.4 Relationships to other architectures

| From | To | Relationship | Consequence |
|---|---|---|---|
| ARC-003 *(Example)* | ARC-004 | Publishes order events consumed by the data platform | Event contract must follow the data platform's schema policy |
| ARC-003 *(Example)* | ARC-002 | Realises the order capabilities of the segment architecture | Capability map updated when candidate is chosen |
| [ARC-nnn] | [ARC-nnn] | [Relationship] | [Consequence] |

## 7. Architecture Evaluation records

<!-- Guidance: Evaluation judges architectures against objectives and value (clause 9). Keep a register here and the full plan and report per evaluation in the 42030 template. Independence matters: the evaluation lead should not be the lead architect of the effort. -->

### 7.1 Evaluation policy

| ID | Policy | Applies to |
|---|---|---|
| EVL-POL-01 *(Example)* | Every architecture is evaluated before a governance decision on it | All |
| EVL-POL-02 *(Example)* | New or replaced platforms use ATAM as the analysis method | Platform decisions |
| EVL-POL-03 *(Example)* | Evaluation results and open findings are reported to the board each quarter | All |
| [EVL-POL-nn] | [Policy] | [Scope] |

### 7.2 Evaluation register

| ID | Architecture | Objectives (summary) | Method | Evaluation lead | Date | Result | Report |
|---|---|---|---|---|---|---|---|
| EVL-001 *(Example)* | ARC-003 candidates A and B | Availability, cost, card data scope, channel onboarding, skills | ATAM plus cost model and value scoring | [@evaluation-lead] | YYYY-MM-DD | A recommended with conditions | Architecture Evaluation Plan and Report (`architecture/architecture-evaluation-42030`), AE-YYYY-001 |
| EVL-002 *(Example)* | ARC-004 v2 | Scalability, data governance, cost | Checklist review and fitness functions | [@evaluation-lead] | YYYY-MM-DD | Fit for purpose, 4 findings | AE-YYYY-002 |
| [EVL-nnn] | [ARC-nnn] | [Objectives] | [Method] | [@lead] | YYYY-MM-DD | [Result] | [Link] |

### 7.3 Activity coverage

| 42020 activity (clause) | Where performed |
|---|---|
| Plan and monitor the evaluation (9.4.1, 9.4.2) | 42030 template, sections 6 and 12 |
| Determine objectives and criteria (9.4.3) | 42030 template, sections 3 and 4 |
| Determine methods and integrate with objectives (9.4.4) | 42030 template, section 5; ATAM record in Architecture Evaluation Report (ATAM) (`architecture/atam-evaluation`) |
| Establish measurement techniques and tools (9.4.5) | Load test harness, cost model, Architecture Fitness Functions (`architecture/fitness-functions`) |
| Collect and review information (9.4.6) | 42030 template, evidence register |
| Analyze concepts and properties, assess value (9.4.7) | 42030 template, sections 7 and 8 |
| Characterize architectures from results (9.4.8) | 42030 template, section 9 |
| Formulate findings and recommendations (9.4.9) | 42030 template, section 10 |
| Capture and communicate results (9.4.10) | Board pack; register above |

## 8. Architecture Elaboration records

<!-- Guidance: Elaboration describes the chosen architecture so its users can work with it (clause 10). Record the viewpoints chosen, the views produced and the checks on them. Pitfall: elaborating every viewpoint for every audience; choose viewpoints from stakeholder concerns. -->

### 8.1 Elaboration record for ARC-003 *(Example)*

| 42020 activity (clause) | Record | Evidence |
|---|---|---|
| Plan and monitor the effort (10.4.1, 10.4.2) | Six weeks after GOV-DEC-001 | Effort plan |
| Identify or develop viewpoints (10.4.3) | Context, container, deployment, data and security viewpoints chosen from the concern map | Architecture description section 4 |
| Develop models and views (10.4.4) | Five views, C4 notation for structure | Architecture description section 5 |
| Relate to other architectures and affected entities (10.4.5) | Correspondences to ARC-002 capability map and ARC-004 event catalogue | Architecture description section 6 |
| Assess the elaboration (10.4.6) | Peer review of views against concerns; two gaps fixed | Review notes |
| Coordinate use by intended users (10.4.7) | Walk-through with delivery teams; views published in the repository | Repository link |

### 8.2 Architecture descriptions produced

| ID | Architecture | Description | Template | Version | Users |
|---|---|---|---|---|---|
| ELB-AD-01 *(Example)* | ARC-003 | Order Management Platform architecture description | Architecture Description (`architecture/architecture-description-42010`) | v1.0 | Delivery teams, operations, security |
| ELB-AD-02 *(Example)* | ARC-003 | C4 model | C4 Architecture (`architecture/c4-architecture`) | v1.0 | Developers |
| ELB-AD-03 *(Example)* | ARC-004 | Reference architecture | Reference Architecture (`architecture/reference-architecture`) | v2.0-draft | Data product teams |
| [ELB-AD-nn] | [ARC-nnn] | [Description] | [Template] | [Version] | [Users] |

## 9. Architecture Enablement

<!-- Guidance: Enablement provides and improves what the other processes need (clause 11): methods, frameworks, tools, repository, skills, training and services. Treat it as a product with a backlog. Pitfall: buying a modelling tool before deciding the viewpoints and methods it must support. -->

### 9.1 Enabler inventory

| ID | Enabler | Type | Supports | Owner | State |
|---|---|---|---|---|---|
| ENB-01 *(Example)* | Architecture repository and modelling tool | Tool | Management, Elaboration | [@practice-lead] | In use |
| ENB-02 *(Example)* | Template set (this plan, 42010, 42030, ATAM, ADR) | Method | All | [@practice-lead] | In use |
| ENB-03 *(Example)* | Architecture principles and standards catalogue | Guidance | Governance | [@chief-architect] | In use |
| ENB-04 *(Example)* | Evaluation facilitator pool (four trained leads) | Skill | Evaluation | [@practice-lead] | Building |
| ENB-05 *(Example)* | Architect competency framework and training path | Skill | All | [@practice-lead] | Planned |
| [ENB-nn] | [Enabler] | [Tool / Method / Guidance / Skill / Service / Data] | [Processes] | [@owner] | [Planned / Building / In use / Retiring] |

### 9.2 Enablement backlog

| ID | Item | Activity (clause) | Benefit | Priority | Due |
|---|---|---|---|---|---|
| ENB-BL-01 *(Example)* | Train two more ATAM evaluation leads | Acquire and develop capabilities (11.4.4) | Removes evaluation bottleneck | High | YYYY-MM-DD |
| ENB-BL-02 *(Example)* | Publish the repository to delivery teams with read access | Deploy capabilities (11.4.5) | Architectures used, not just stored | High | YYYY-MM-DD |
| ENB-BL-03 *(Example)* | Retire the old drawing tool and migrate diagrams | Improve capabilities (11.4.6) | One source of truth | Medium | YYYY-MM-DD |
| ENB-BL-04 *(Example)* | Review enabler inventory against process needs | Manage enablers (11.4.3) | Gaps visible | Medium | YYYY-MM-DD |
| [ENB-BL-nn] | [Item] | [Activity] | [Benefit] | [H / M / L] | YYYY-MM-DD |

## 10. Work products register

<!-- Guidance: List every work product the processes produce, with its template and owner. Each process clause ends with a work products subclause (6.5, 7.5, 8.5, 9.5, 10.5, 11.5); use this register to show what your organisation produces for each. -->

| ID | Work product | Process | Template or location | Owner | Retention |
|---|---|---|---|---|---|
| WP-01 | Governance charter and collection objectives | Governance | Architecture Governance Charter (`architecture/architecture-governance-charter`); section 4.2 | [@board-chair] | Current plus 5 years |
| WP-02 | Governance decision log | Governance | Section 4.4; Architecture Decision Log (`architecture/architecture-decision-log`) | [@board-secretary] | Permanent |
| WP-03 | Architecture work plan and collection health | Management | Sections 5.2 and 5.3 | [@head-of-architecture-office] | Current plus 3 years |
| WP-04 | Problem statement, objectives, candidate architectures | Conceptualization | Section 6; Solution Options Analysis (`architecture/solution-options-analysis`) | [@lead-architect] | Life of the entity |
| WP-05 | Evaluation plans and reports | Evaluation | Architecture Evaluation Plan and Report (`architecture/architecture-evaluation-42030`) | [@evaluation-lead] | Life of the entity |
| WP-06 | Architecture descriptions and decision records | Elaboration | Architecture Description (`architecture/architecture-description-42010`); ADR (`architecture/adr-full`) | [@lead-architect] | Life of the entity |
| WP-07 | Enabler inventory and backlog | Enablement | Section 9 | [@practice-lead] | Current |
| [WP-nn] | [Work product] | [Process] | [Template] | [@owner] | [Retention] |

## 11. Process metrics

<!-- Guidance: Annex B of the standard gives informative guidance on defining metrics for architecture processes. Choose a few metrics per process that lead to action; measure outcomes as well as activity. The thresholds below are examples, not normative values. -->

| ID | Process | Metric | Definition | Target *(Example)* | Current | Trend |
|---|---|---|---|---|---|---|
| MET-01 | Governance | Decision lead time | Median days from complete request to board decision | <= 15 days | [n] | [Up / Down / Flat] |
| MET-02 | Governance | Directive compliance | Share of compliance checks rated compliant | >= 85% | [n%] | [Trend] |
| MET-03 | Management | Collection currency | Share of current architectures reviewed in the last 12 months | >= 90% | [n%] | [Trend] |
| MET-04 | Conceptualization | Options considered | Median number of candidate architectures per effort above the tailoring threshold | >= 2 plus baseline | [n] | [Trend] |
| MET-05 | Evaluation | Finding closure | Share of evaluation recommendations closed by their due date | >= 80% | [n%] | [Trend] |
| MET-06 | Elaboration | Description use | Share of delivery teams that consulted the architecture description in the last quarter | >= 75% | [n%] | [Trend] |
| MET-07 | Enablement | Enabler satisfaction | Average rating by architects and delivery teams, scale 1 to 5 | >= 3.5 | [n] | [Trend] |
| [MET-nn] | [Process] | [Metric] | [Definition] | [Target] | [Current] | [Trend] |

## 12. Interfaces with other processes

<!-- Guidance: Annex C of the standard (normative) covers how architecture processes interact with other processes and uses of architecture. Record each interface with its inputs and outputs so hand-offs do not depend on individuals. -->

| Other process | Input to architecture | Output from architecture | Interface owner |
|---|---|---|---|
| Strategy and portfolio *(Example)* | Strategic goals, investment priorities | Collection objectives, roadmaps, investment recommendations | [@head-of-portfolio] |
| Requirements engineering *(Example)* | Stakeholder needs, quality attribute scenarios (Quality Attribute Workshop Report, `architecture/qaw-workshop-report`) | Architecture objectives, derived requirements | [@lead-business-analyst] |
| Design and implementation *(Example)* | Design constraints discovered, technical debt | Architecture descriptions, decisions, guardrails | [@engineering-lead] |
| Risk management *(Example)* | Enterprise risk appetite | Architecture risks and risk themes from evaluations | [@risk-manager] |
| Configuration management *(Example)* | Baseline policy | Baselined architectures and descriptions | [@configuration-manager] |
| Operations *(Example)* | Incident trends, capacity data | Operability requirements and runbook inputs | [@operations-lead] |
| [Process] | [Input] | [Output] | [@owner] |

## 13. Review and improvement

<!-- Guidance: Review the process plan yearly against metrics, audit results and feedback. Record the improvement decisions so the next review can check them. -->

### 13.1 Review schedule and inputs

| Review | Frequency | Inputs | Chaired by |
|---|---|---|---|
| Process review | Yearly | Metrics (section 11), tailoring record, compliance results, feedback survey | [@chief-architect] |
| Collection review | Quarterly | Collection health (section 5.3), evaluation register (section 7.2) | [@head-of-architecture-office] |
| Health check | As needed | Architecture Health Check (`architecture/architecture-health-check`) | [@practice-lead] |

### 13.2 Improvement log

| ID | Observation | Decision | Owner | Due | Status |
|---|---|---|---|---|---|
| IMP-01 *(Example)* | Decision lead time 28 days, target 15 | Delegate standard exceptions to the architecture office | [@board-chair] | YYYY-MM-DD | Open |
| IMP-02 *(Example)* | Evaluation findings closed late (62%) | Add findings to programme risk registers automatically | [@head-of-architecture-office] | YYYY-MM-DD | Open |
| [IMP-nn] | [Observation] | [Decision] | [@owner] | YYYY-MM-DD | [Status] |

### 13.3 Readiness checklist for a new architecture practice

- [ ] Collection scope and owners are listed (section 1.2).
- [ ] Conformance case and tailoring are approved (section 2).
- [ ] Each of the six processes has an owner and a local method mapping (sections 3.2 and 3.3).
- [ ] Governance decision rights and escalation path are written down (section 4.1).
- [ ] At least one evaluation lead is independent of delivery (section 7).
- [ ] The repository and templates are available to delivery teams (section 9).
- [ ] Three to seven metrics have baselines (section 11).

## 14. Glossary and references

<!-- Guidance: Define terms in your own words. Keep references to sources actually used. -->

| Term | Meaning in this document |
|---|---|
| Architecture collection | The set of architectures an organisation governs and manages together |
| Entity of interest | The thing whose architecture is considered: enterprise, system, software, service, product line |
| Architecture effort | A bounded piece of work that conceptualises, evaluates or elaborates one architecture |
| Governance directive | A principle, standard, policy or guidance that architectures must follow |
| Tradespace | The set of possible solutions and the tradeoffs among them on the objectives that matter |
| Critical success criterion | A measurable condition an architecture must satisfy to meet an objective |
| Enabler | A method, tool, repository, skill, service or data source that supports the architecture processes |
| Tailored conformance | Conformance in which some outcomes or activities are modified or omitted with recorded justification |

| ID | Reference | Version | Use |
|---|---|---|---|
| REF-01 | ISO/IEC/IEEE 42020, *Software, systems and enterprise: Architecture processes* | 2019, first edition (stage 90.92, to be revised since 2026-01-08; AWI 42020 *Enterprise, systems and software: Architecture processes* registered 2026-05-22) | Process structure (clauses 4 to 11, Annexes A to C; informative Annexes D to H not used, except Annex H as a check in section 3.3) |
| REF-02 | ISO/IEC/IEEE 42010, *Software, systems and enterprise: Architecture description* | 2022 | Elaboration work products |
| REF-03 | ISO/IEC/IEEE 42030, *Software, systems and enterprise: Architecture evaluation framework* | 2019, first edition (stage 90.92, to be revised since 2026-01-08; AWI 42030 registered 2026-05-22) | Evaluation work products |
| REF-04 | IEEE P42020 project (active PAR approved 2026-09-25), standards.ieee.org | 2026 | Status of the revision |
| REF-05 | INCOSE, *Guidance to ISO/IEC/IEEE 42020: Architecture Processes* | Released March 2025 | Background reading on applying the standard |
| [REF-nn] | [Title] | [Version] | [Use] |

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 42020:2019, *Software, systems and enterprise: Architecture
processes* (clause 4 conformance, clause 5 process overview, clauses 6 to 11 for the Governance,
Management, Conceptualization, Evaluation, Elaboration and Enablement processes, Annex A tailoring,
Annex B metrics and Annex C interactions). Only clause numbers, process names and short activity
labels are used; all explanations, tables and examples are original text written for this
collection, and no text, definition or table of the standard is reproduced. ISO lists the 2019
edition as "to be revised" (stage 90.92 since 2026-01-08), and a second edition is registered as
work item AWI 42020 (2026-05-22, reordered title *Enterprise, systems and software: Architecture
processes*; IEEE P42020); check the current edition in the ISO catalogue before claiming
conformance. TOGAF is a registered trademark of The
Open Group; this template uses only the names of TOGAF ADM phases, and all text is original.
Template licence: MIT.