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.
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
Use operational evidence to keep architecture current.
Reference: Architectural decision record process · OGEA-102; TOGAF Standard, 10th Edition