An architecture is a decision made with incomplete information. It predicts a workload, a change rate, an operating model, and a set of failures worth controlling. Some predictions will be wrong.
The expensive mistake is allowing the original decision to become a fact about the organization. Teams route around it. Operators absorb its failures. New projects inherit its assumptions. The cost of correction rises while the reason for the architecture becomes harder to find.
The architecture should change when its governing assumptions no longer hold. The review has to make that point visible before the cost of correction controls the decision.
Write the bet when making the decision
A design is easier to evaluate when its assumptions are explicit. I record the claims that justify the structure:
- the expected workload and where it will grow;
- the consistency and latency the user outcome requires;
- the failures the operating team can detect and repair;
- the rate and type of product change;
- the ownership model the system depends on.
I also record the strongest rejected option and the evidence that favored the chosen one. This prevents a future review from comparing the real system with an imaginary alternative that has no costs.
The decision needs a review trigger. “Revisit if peak writes exceed this range” supplies one. “Review later” does not.
Look for structural symptoms
Incidents alone do not prove that the architecture is wrong. Every useful system fails. I look for repeated evidence that the structure creates the failure or makes ordinary change unsafe.
| Observed symptom | Question |
|---|---|
| Routine changes cross many services | Do the boundaries match the product’s change boundaries? |
| Operators repair the same inconsistency | Is the consistency model compatible with the user promise? |
| One team approves unrelated releases | Has a technical dependency created an ownership bottleneck? |
| Capacity fixes move the bottleneck | Is the limiting mechanism understood? |
| Exceptions dominate the main path | Was the original model of the workflow incomplete? |
The pattern matters. A local implementation defect should be repaired locally. A structural decision should change when the same class of defect returns through different implementations.
Separate sunk cost from remaining cost
Past investment explains how the system reached its current state. It does not improve the next decision.
I compare the cost of continuing with the cost of correction from today forward. Continuing includes operating load, delayed changes, incident exposure, and the new dependencies that will attach to the current design. Correction includes migration, temporary duplication, retraining, and the risk introduced during transition.
The comparison should use the same time horizon and the same user outcome. Otherwise the current system gets credit for being present while the alternative is charged for every step required to exist.
State the error precisely
“The architecture failed” is too broad to guide a correction. I try to name the claim that no longer holds.
Perhaps the design assumed one source of truth while the product now requires independent regional operation. Perhaps it optimized model inference while tool latency controls the caller’s experience. Perhaps it split services by technical layer while most product changes cut across every layer.
A precise statement protects the parts of the design that still work. It also makes accountability possible. The team can see which evidence was unavailable, which evidence was discounted, and which decision rule should improve.
Correct the decision without creating a second uncontrolled bet
The response to a wrong architecture can become another large, weakly tested architecture. Urgency makes the replacement feel certain.
I use the failed assumption to design the first migration test. If service boundaries do not match change boundaries, move one complete workflow and measure the coordination removed. If short context produces unstable evaluation, compare it with a full-document baseline before redesigning the evaluation stack. If operators cannot determine whether an action completed, instrument one consequential path before replacing the orchestrator.
The correction should produce evidence early. Each stage needs a preserved invariant, a traffic or scope boundary, and an exit condition. The team should be able to stop after a stage and still own a coherent system.
Accountability improves the next architecture
The architect should explain the change in direct terms:
- what decision was made;
- which assumption supported it;
- what evidence now contradicts that assumption;
- which harm will continue if the system stays unchanged;
- how the correction will be tested and bounded.
This account avoids blame theater. It gives the organization a better decision rule. A missing measurement can be added. An ownership assumption can be checked. A review trigger can be made automatic. The value lies in changing how the next decision is made.
Architecture authority includes the obligation to reverse course. When the governing assumptions fail, the decision should change in service of the user-visible result and the team operating the system.