Architecture Change Request: [ACR-YYYY-NN] [Change title]

An Architecture Change Request proposes a change to an approved architecture: its target, a Transition Architecture, a requirement, a principle or standard, or an Architecture Contract. It belongs to Phase H (Architecture Change Management) of the Architecture Development Method (ADM) in The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1), where the Architecture Board assesses each change and decides whether it is a simplification change, an incremental change or a re-architecting change that needs a new ADM cycle. This template records the driver, the affected architecture, the classification, the impact, the options, the recommendation, the decision and the follow-through. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Change summary
2. Change driver and source
3. Description of the proposed change
4. Affected architecture
5. Change classification
6. Impact assessment
7. Options considered
8. Recommendation
9. Decision
10. Implementing the change
11. Communication
12. Monitoring and closure
13. Glossary and references

1. Change summary

2. Change driver and source

2.1 Driver type

2.2 Evidence

3. Description of the proposed change

3.1 Current and proposed position

3.2 Why now

Example: The data hub contract (AC-02) has a TA-1 checkpoint in about three months (2027-08-30). Deciding now lets the team build the interim feed in parallel with the hub configuration; deciding after the checkpoint would add the build time to the delay.

3.3 Out of scope of this request

Example: the choice of change data capture product (left to the platform team within the approved standards), and any change to policy systems B and C.

4. Affected architecture

5. Change classification

5.1 Classes and routes

The three class names come from Phase H; the descriptions, examples and routes below are this template's suggestions. Set your own routes in the Architecture Board charter.

5.2 Classification questions

5.3 Result

6. Impact assessment

6.1 Cost arithmetic

Example check: adding USD 175,000 on top of the committed USD 2,415,000 would give USD 2,590,000, which breaks CNS-01 by USD 90,000. Funding the change from contingency keeps the commitment inside the cap; option A (USD 255,000) would leave only USD 60,000 of contingency for the rest of the programme.

7. Options considered

7.1 Option evaluation notes

Example: Option A looks cheapest only if the cost of delay is ignored; once the extended CRM support and nine months of dual running are counted, it costs more than option B and delivers later. Option C solves the root cause but turns a supplier delay into a new architecture cycle; it remains the fallback if the vendor's database terms forbid change data capture.

8. Recommendation

Example: Approve option B as an incremental change, with these conditions:

1. C1: The vendor confirms in writing that read-only database access for change data capture is within support terms, before build starts.
2. C2: The interim feed passes the same contract tests as the target API (ARS-INT-04) before it feeds the hub in production.
3. C3: The security architect approves the service account design and monitoring before go-live.
4. C4: The interim feed is retired within three months of the vendor API going live; the AP-01 exception ends on that date or on YYYY-MM-DD, whichever is earlier.
5. C5: If C1 fails, the assessing architect returns with option C as a new Request for Architecture Work.

9. Decision

9.1 Conditions

9.2 Decision outcomes available

10. Implementing the change

10.1 Repository and document updates

10.2 Delivery actions

Record decisions in the architecture decision log (architecture/architecture-decision-log) and full records with the ADR template (architecture/adr-full). Project-level changes to scope, cost and schedule follow the project change control process (project/change-control).

11. Communication

12. Monitoring and closure

12.1 Monitoring

12.2 Closure criteria

• All conditions in section 9.1 met or formally closed
• All updates in section 10.1 done and versioned
• Interim component retired, or its retirement scheduled with an owner and the principle exception end date confirmed
• Post-change review held and lessons recorded (project/lessons-learned)
• Change register entry set to Closed

12.3 Post-change review

Example: Review held YYYY-MM-DD. The interim feed met contract tests from week two. TA-1 exited five weeks late against six planned. Lesson: add a supplier API readiness check to the design checkpoint of every contract that depends on a vendor interface.

12.4 Change register entry

13. Glossary and references

13.1 Glossary

13.2 References

Standard and licence note

Structure aligned with The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1), published by The Open Group: Phase H (Architecture Change Management) of the Architecture Development Method, with its classification of changes as simplification, incremental or re-architecting, and links to the Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap and Architecture Contracts. TOGAF and ArchiMate are registered trademarks of The Open Group. This template uses only the names of phases, deliverables and change classes; all text is original. It was written from general professional practice, without reading, quoting, paraphrasing or summarising the text of the standard, and it reproduces no definitions, tables or lists from it. The class descriptions, routes, classification questions and decision outcomes are suggestions of this template, not requirements of the standard. Check the current edition and any technical corrigenda at opengroup.org and obtain the standard for its own guidance. Template licence: MIT.