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.
Document control
| 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
| 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.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
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
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.
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
| 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
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
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
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
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
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
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
| 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
| 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
| 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
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
14. Glossary and references
| 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.