← TOGAF Practitioner: architecture and transformation decisions
06 / 8 · 40 MIN

Architecture change and monitoring

Assess when to adapt decisions and restart work.

Concept and mechanism

Architecture must respond to business, technology, and operational changes. Phase H observes the situation and evaluates change requests to keep architecture useful. Not every change requires a complete new cycle, but an apparently small change may affect principles, interfaces, or shared constraints. Classify by impact and applicable governance rather than code line count alone. Retain the relationship between intended and implemented architecture. Repeated incidents may show that a design assumption was wrong even when every incident was resolved within its support deadline.

Guided application

Imagine that a supplier announces support withdrawal for a component. Assess dependent applications, alternatives, cost, risk, and timing before choosing a response. An urgent operational fix may stabilize service without closing the architecture need. If an earlier decision becomes invalid, retain its history and replacement rationale. The AWS ADR process illustrates this principle: a newly accepted decision can supersede the previous one without erasing context. This is a practice example rather than a specific exam requirement. Define signals for reviewing a decision, such as volume, cost, or recovery failures. Monitoring availability alone can hide significant deterioration in capacity or operational sustainability.

IN PRACTICE

Closing three similar incidents may leave the recovery assumption uncorrected.

Common pitfalls

Measuring change by patch size; erasing decisions; confusing recovery with structural correction.

Related topics: Context, mandate, and value · Stakeholders, conflicts, and views · Vision, scope, and feasibility

Take this idea with you

Use operational evidence to keep architecture current.

Create account

Reference: Architectural decision record process · OGEA-102; TOGAF Standard, 10th Edition