The Problem With Ordinary Architecture Reviews
Many organizations conduct architecture reviews as if the purpose were to display the architecture. A team prepares slides. A board asks questions. Diagrams are shown. Risks are noted. Actions are assigned. The meeting ends.
This can be useful, but it is not enough.
- A design can be presented clearly and still be architecturally misunderstood
- A model can be syntactically correct and still causally stale
- A decision can be approved and still lose the rationale that once made it valid
- A review can verify that artifacts exist conforming to the creation guidelines without verifying that those artifacts still preserve the meaning of the decisions that shaped the system
The deeper purpose of an architecture review is not presentation. It is recovery.
An architecture review is a decision memory recovery mechanism. It tries to recover the chain of reasoning that links current system form to past architectural commitments and future lifecycle consequences.
This matters because architecture is not merely the arrangement of components. Architecture is the structure of consequential commitments that constrain the future. That idea is consistent with long-standing systems architecting traditions that treat architecture as the organizing structure of system purpose, concept, form, and lifecycle consequence [Rec91, MR09, CCS15]. It is also consistent with Herbert Simon’s view that complex artifacts are shaped by purposeful decomposition, hierarchy, and bounded rationality [Sim96].
But once a system is under development, those commitments become harder to see. The architecture is no longer represented only in the diagrams (which are just projections of the architecture as a cognitive object, anyway). It is distributed across interfaces, tests, supplier choices, code structures, verification arguments, manufacturing assumptions, regulatory interpretations, organizational authority, and inherited constraints.
An architecture review is the attempt to make that distributed memory visible again for examination.
If Architecture Is Decision Memory, Reviews Test Its Fidelity
The previous post framed architecture as decision memory: the preserved memory of consequential design, integration, verification, and governance decisions. This post takes the next step.
If architecture is decision memory, then an architecture review asks
Can the organization still recover the decisions that made the architecture what it is and can the organization still justify those decisions under current conditions?
That question is different from asking whether the architecture is documented. Documentation is necessary, but not sufficient. A system can be extensively documented and still be architecturally opaque. The documentation may show what exists without preserving why it exists, what alternatives were considered, what invariants were protected, or what future costs were accepted.
A useful architecture review therefore tests decision memory fidelity along several dimensions:
- Decision recovery – What decision created this architectural shape?
- Rationale recovery – Why was that decision made?
- Invariant recovery – What had to remain true across the decision?
- Alternative recovery – What options were rejected, deferred, or preserved?
- Assumption recovery – What had to be true for the decision to remain valid?
- Evidence recovery – What evidence still supports the decision?
- Consequence recovery – What verification, integration, operational, and governance burdens did the decision create?
In this sense, an architecture review is less of an inspection of static artifacts and more of a test of institutional memory.
The Review as a Causal Reconstruction
Architecture reviews should reconstruct causal structure.
The simplest review question is
What does the architecture look like?
The more important question is
What decisions made it look this way?
The deeper question is
What future possibilities did those decisions enable, constrain, preserve, or destroy?
A review should therefore move across three layers:
- Current Artifacts – models, diagrams, interfaces
- Recovered Decisions – choices, rationale, assumptions
- Future Cone – options, burdens, risks, recover project update evidence
The first layer is representational: what artifacts exist? The second is historical and causal: what decisions do those artifacts encode? The third is prospective: what future paths do those decisions make easier, harder, or impossible?
This is where architecture reviews differ from ordinary design reviews. A design review may ask whether a design satisfies stated requirements. An architecture review asks whether the structure of decisions, constraints, interfaces, and invariants remains adequate for the future the system must enter.
What the Review Must Recover
A good architecture review should recover at least six kinds of memory.
1. Decision Memory
What was actually decided?
While this sounds obvious, in real programs it is often unclear. Some architectural decisions are explicit. Others are implicit consequences of supplier selection, platform inheritance, interface reuse, verification strategy, procurement timing, regulatory interpretation, or staffing constraint.
The review should distinguish between:
- Deliberate decisions
- Accidental decisions
- Inherited decisions
- Deferred decisions
- Abandoned decisions
- Decisions that were never recognized as architectural
This distinction matters because each type carries different future risk.
2. Rationale Memory
Why was the decision made?
A decision without rationale is brittle. It can be repeated when it should be revised, reversed when it should be preserved, or defended for reasons that were never true. Rationale is not decoration. It is a part of the architecture’s recoverability. Design rationale has long been recognized as important because complex engineering decisions are difficult to interpret after their original context has disappeared [Lee97]. Architecture reviews should therefore ask whether rationale remains available, credible, and current.
3. Invariant Memory
What had to remain true?
Architectural decisions are not merely choices among components. They are transformations that should preserve required invariants. These may include mission, safety, security, semantic interface meaning, regulatory compliance, verification strategy, modularity, operational resilience, manufacturability, serviceability, or future option value.
The review should ask
What invariant was this decision protecting?
and also
Is that invariant still protected?
If a decision no longer protects the invariant that justified it, then the architecture has drifted even if the diagram has not changed.
4. Alternatives Memory
What options were rejected, deferred, or preserved?
A trade study does not merely pick an alternative. It transforms an architectural frontier. Before selection, alternatives form a set of mutually unresolved options. After selection, some options are committed, some are rejected, some are deferred, and some are preserved as future paths.
This is where antichain language is useful. An architectural frontier is often an antichain – a set of options not yet causally ordered by commitment, i.e., not comparable according to the causal relation. A decision, review, integration result, or governance action can act as a join event that places multiple previously incomparable options into the causal past of a common downstream state.
The review should ask:
What antichain did this decision join, and what future cone did the join create?
That question exposes whether the organization understands the option structure it has collapsed or preserved.
5. Assumption Memory
What had to be true for the decision to be valid?
Architectural decisions are conditional. They depend on assumptions about technology maturity, supplier capability, interface stability, operating environment, verification feasibility, regulatory interpretation, organizational authority and will, market timing, and cost of change.
The review should identify assumptions that have become stale. A decision can remain unchanged while its justification expires.
6. Evidence Memory
What evidence still supports the decision?
Evidence ages. Tests become less representative. Models become stale. Interfaces drift. Suppliers change. Mission priorities evolve. Regulations are reinterpreted. Operational environments become more demanding.
A review must therefore distinguish between evidence that once supported a decision and evidence that still supports it.
This is one reason architecture reviews should be linked to verification and validation. The INCOSE Systems Engineering Handbook emphasizes the lifecycle role of technical reviews, decision gates, verification, validation, and technical management in maintaining coherence across system development [INC23]. Architecture reviews should not be isolated from that lifecycle evidence chain.
Architecture Reviews and Representational Drift
A central danger in complex systems is that representations become institutionally authoritative as they become causally stale.
- A diagram may continue to circulate long after the system has changed
- A model may preserve an earlier interface concept while the implemented interface has evolved
- A requirement may remain formally approved while the operational need has shifted
- A verification plan may still point to evidence that no longer tests the most important risk.
This is representational drift.
Representational drift occurs when an artifact remains authoritative after its causal connection to the system has changed or been invalidated. Architecture reviews should detect this before failure does.
The review should ask
- What does this artifact claim to represent?
- What part of the system or decision history does it actually represent now?
- What has changed since it became authoritative?
- What evidence connects it to current system behavior?
- Who would notice if it became wrong?
This creates a connection which I explore in the next post – representation fidelity.
Reviews as Controlled Recovery Operations
Architecture reviews are often very passive. A team presents what it already knows, and reviewers ask whether anything seems wrong.
A stronger review actively tries to recover missing causal structure. It asks
- Where did this structure come from?
- What decision produced it?
- What alternatives were available at the time?
- What assumption made this acceptable?
- What invariant did it protect?
- What verification burden did it create?
- What future option did it preserve?
- What future option did it close?
- What changed since then?
- What would make this decision invalid now?
This kind of review is not adversarial. It is diagnostic. The purpose is not to embarrass the team for forgetting. The purpose is to prevent the system from being governed by forgotten commitments.
Beneficial and Pathological Reviews
Not every architecture review improves architecture.
A beneficial review strengthens decision memory. It recovers rationale, clarifies invariants, identifies stale assumptions, protects useful options, and reconnects artifacts to evidence.
A pathological review does the opposite. It rewards polished artifacts over causal understanding. It collapses options without preserving rationale. It treats dissent as delay. It pushes unresolved uncertainty into downstream integration. It creates the appearance of control while increasing future cost.
This connects directly to technical debt. As I said in an earlier post, technical debt is not merely deferred work. It is accumulated unresolved architectural constraint. A weak review can increase total technical debt by allowing decisions to proceed without recovering their future consequences. A strong review can reduce debt interest by clarifying why the architecture has its current shape and what must be watched as it evolves.
Review Questions That Matter
The following table can be used as a practical review worksheet.
| Review Question | Purpose |
| What decision created this architectural shape? | Recover decision memory |
| What invariant was the decision intended to protect? | Recover architectural intent |
| What alternatives were rejected, deferred, or preserved? | Recover antichain/frontier history |
| What assumptions made the decision valid? | Detect stale rationale |
| What evidence still supports the decision? | Test representational fidelity |
| What has changed since the decision was made? | Detect drift |
| What verification burden did the decision create? | Expose downstream evidence cost |
| What future options were preserved or destroyed? | Assess future-cone deformation |
| Who now owns the decision memory? | Prevent institutional memory loss |
| What would invalidate this decision? | Identify watchpoints and probes |
These questions are simple, but they change the posture of the review. The goal is no longer to ask whether the architecture can be explained. The goal is to ask whether the architecture can still explain itself through recoverable decision memory.
A Small Example
Suppose a product team chose a shared communications bus early in development. The decision reduced cost and simplified integration among early prototypes. The architecture diagram still shows the bus. The interface control document still describes it. The verification plan still assumes it.
Years later, the system has grown. More subsystems have been added. Safety functions now share the same communication path as noncritical functions. Latency margins are tighter. Cybersecurity requirements have changed. Supplier components have evolved. The original decision and its consequences are still present, but the conditions that justified it may not be.
A weak architecture review, if it cares at all after the decision has been made, asks
Is the bus documented?
A stronger architecture review asks
Why did we choose this bus, what invariant did that decision protect, what alternatives did we reject, what assumptions made the decision valid, and do those assumptions still hold?
It also asks
What verification burden has this decision created now that the system has changed?
The issue is not whether the bus was a bad decision. It may have been exactly right at the time. The issue is whether the decision memory remains faithful enough to govern the current system.
The Systems Engineer’s Role
The systems engineer has a distinctive role in architecture reviews.
The systems engineer is not merely a meeting facilitator, requirements custodian, or translator between engineering teams and management. A core systems engineering function is to preserve, test, transmit, and reconcile cross-layer architectural decision memory across mission, business, operational, functional, physical, software, verification, manufacturing, service, regulatory, and governance layers.
This is why systems engineering matters so much in architecture reviews. The review is where cross-layer memory is tested.
- Can the software team explain the verification consequence of a physical architecture choice?
- Can the hardware team see the operational consequence of an interface decision
- Can management understand the future option cost of schedule-driven convergence?
- Can the verification team identify which architectural invariants its evidence is supposed to protect?
If not, the architecture may still be documented, but its decision memory is already fragmenting.
Conclusion: Review Before the System Fails
Architecture reviews should not wait until the system is obviously in trouble. By the time integration fails, certification stalls, interfaces break, or change cost explodes, the decision memory may already have been lost.
A good architecture review asks whether the organization can still recover the causal meaning of its architecture.
- What did we decide?
- Why did we decide it?
- What did it preserve?
- What did it cost?
- Does it still hold?
That is the real work of architecture review.
Not ceremony. Not artifact presentation. Not compliance theater.
Decision memory recovery.
The Next Post
The next question I explore is whether the representations used in architecture reviews remain faithful to the system they claim to describe. This leads to the notion of representation fidelity – the problem of maps, models, diagrams, and requirements that remain authoritative after becoming causally stale.
References
[CCS15] Edward Crawley, Bruce Cameron, and Daniel Selva. System Architecture: Strategy and Product Development for Complex Systems. Pearson, 2015.
[INC23] INCOSE. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Wiley, 5 edition, 2023.
[Lee97] Jintae Lee. Design rationale systems: Understanding the issues. IEEE Expert, 12(3):78–85, 1997.
[MR09] Mark W. Maier and Eberhardt Rechtin. The Art of Systems Architecting. CRC Press, 3rd edition, 2009.
[Rec91] Eberhardt Rechtin. Systems Architecting: Creating and Building Complex Systems. Prentice Hall, 1991.
[Sim96] Herbert A. Simon. The Sciences of the Artificial. MIT Press, 3 edition, 1996.
Leave a Reply