Architecture as Decision Memory: Why Systems Lose Fidelity Before They Fail

A Statement That Would Not Let Go

I recently gave a presentation on architecture and systems engineering. During the discussion, I found myself saying something that I had not quite said in the same way as before

“Architecture is the cognitive object formed by the causal set of the decisions we make.”

That sentence has stayed with me.

It suggests a useful shift in how we think about architecture. We often describe architecture as a system of components, relationships, interfaces, behaviors, constraints, and context. That description is not wrong. It is the usual language of architecture, and it is consistent with the long software-architecture tradition of treating architecture as structure, elements, relations, and externally visible properties [PW92]. But it may not be the deepest description.

Before there are components, someone has decided that there will be a system.

Before there are interfaces, someone has decided what must be separated and what must be joined.

Before there are requirements, someone has decided what matters, who matters, what problem is worth solving, what success looks like, and what failures are unacceptable.

Before there is a system architecture, there is a decision architecture.

The visible architecture of a system is therefore not the primitive object. It is a projection of prior decisions.

Systems Begin as Decisions

A system does not begin as a bill of materials, a block diagram, a SysML model, a requirements database, or an interface control document. Those artifacts come later. The system begins when a community of people makes consequential commitments.

• They decide that something should exist
• They decide what it is for
• They decide what environment matters
• They decide what stakeholders count
• They decide what behaviors are required
• They decide what risks are intolerable
• They decide what technologies are admissible.
• They decide which future options are worth preserving and which may be sacrificed

Some of these decisions are explicit. Others are implicit. Some are written down. Others live only in conversations, assumptions, habits, policies, contracts, or the memories of experienced engineers.

But whether explicit or implicit, these decisions constrain the possible future of the system. That is why they are architectural.

An architectural decision is not simply any decision made during a project. It is a decision

• That changes the future design space
• It constrains downstream choices
• It protects or violates important invariants
• It creates coupling
• It allocates responsibility
• It determines what evidence will later be needed
• It changes the cost of future change

This view has direct support in the software-architecture decision literature, where architecture has been treated not merely as components and connectors but as a set of architectural design decisions [JB05, TA05]. It also aligns with broader decision-based engineering design, which treats engineering design as decision-making under uncertainty, preference, consequence, and value [Haz98].

In this sense, architecture is the causally ordered memory of consequential decisions.

Components Are Projections of Decisions

It is common, even according to INCOSE and IEEE cf., [ISO11], [INC18], to say that architecture is about components and relationships in context. That formulation is useful, but incomplete.

Consider a simple statement:

The compressor is connected to the evaporator through this interface.

That may be structurally true. But architecturally, it is only the visible surface of a deeper decision structure.

Behind that interface are prior decisions about

• Thermodynamic cycle
• Performance envelope
• Manufacturability
• Serviceability
• Reliability
• Cost
• Control behavior
• Installation environment
• Safety
• Regulatory requirements
• Supplier capability
• Maintenance strategy
• Acceptable failure modes

The interface is not just a connection. It is a compressed record of decisions. The component is not just a part. It is a stabilized consequence of decisions. The context is not just the environment. It is the set of conditions that earlier decisions assumed would matter.

This does not mean that components, interfaces, and context are unimportant. Quite the opposite. They are critically important because they are where prior decisions become operationally real. But they are not self-explanatory. A component diagram can show what was chosen while hiding why it was chosen, what alternatives were rejected, what invariants were protected, and what future possibilities were closed off.

The architectural-knowledge literature makes this point in another vocabulary: design knowledge which includes not only structures and solutions, but the decisions, assumptions, rationale, and contextual knowledge that explain why those solutions exist [KLvV06]. Design-rationale methods make a related claim by preserving the issues, alternatives, criteria, and arguments that shape design outcomes [KR70, MC96, MYBM91].

When the organization loses that rationale, it may still possess the architectural artifact while losing access to the architecture.

Architecture Is Not a Flat List of Decisions

If architecture is decision memory, it is tempting to imagine it as a list such as decision one, decision two, decision three, and so on.

This is insufficient.

Architectural decisions are not merely accumulated. They are causally structured

• Some decisions precede and constrain others
• Some decisions remain independent for a while and then collide during integration
• Some decisions are provisional
• Some harden into commitments
• Some are reversible
• Others become nearly impossible to unwind once procurement, certification, tooling, supplier agreements, software structure, organizational roles, or test programs form around them.

Architecture is therefore better understood as a partially ordered set of consequential decisions.

• The decision to pursue a particular mission constrains the concept of operations
• The concept of operations constrains system boundaries
• System boundaries constrain interfaces
• Interfaces constrain component allocation
• Component allocation constrains verification strategy
• Verification strategy constrains evidence production
• Evidence production constrains schedule, cost, staffing, and governance.

And architectural decisions are not necessarily commutative. Two decisions may both be reasonable in isolation, yet produce substantially different architectural futures depending on their order. Choosing  before  may open one frontier of possibilities, while choosing  before  may close that frontier and open another. This is why architecture cannot be understood as a checklist of decisions made. It must be understood as a causal history of commitments whose order changes the reachable future of the system.

Not every decision is upstream of every other decision. Many decisions exist side by side for a time. But the ordering matters. A later decision often only makes sense because an earlier decision created the conditions under which it became meaningful.

This is where the language of causal structure becomes useful. Architecture is not just what the system is. It is the remembered causal structure by which the system became what it is and can become. It is also the mechanism by which its future possibilities are constrained.

Vertical Layers and Architectural Influence

This decision structure is not only horizontal. It is also vertical.

Architecture operates across layers: mission, business, operational, functional, physical, software, verification, regulatory, manufacturing, service, and organizational layers. These layers are not merely viewpoints. They exert influence on one another.

• A mission-layer decision may determine what operational behaviors are necessary
• An operational decision may determine which functions must exist
• A functional decision may determine what physical or software elements must be created
• A regulatory decision may determine what verification evidence must be produced
• A manufacturing decision may constrain what physical architectures are feasible
• A service decision may constrain modularity, accessibility, diagnostic behavior, and lifecycle cost.

These vertical dependencies are architectural because they transmit constraint and shape both the admissible and plausible futures.

Higher-layer decisions create fields of influence for lower-layer decisions. They determine what counts as acceptable, relevant, efficient, safe, certifiable, affordable, maintainable, or strategically valuable. Lower-layer decisions then push back upward by revealing feasibility limits, cost barriers, verification burdens, integration risks, supplier constraints, and unexpected coupling. The influence is bidirectional, but not symmetric.

Mission, business, regulation, safety, and governance often set boundary conditions. They define what must be preserved. Lower layers discover what those boundary conditions cost. When the cost becomes too high, the organization must either change the lower-level design, revisit the higher-level decision, or accept a distortion in the architecture.

This is one reason architecture is difficult to preserve. The decision structure is distributed across vertical layers, and each layer tends to remember only the decisions expressed in its own language.

• The business layer remembers value propositions and market commitments
• The operational layer remembers use cases and workflows
• The engineering layer remembers functions, interfaces, components, and tests
• The regulatory layer remembers compliance evidence
• The manufacturing layer remembers process capability and production constraints.
• The service layer remembers maintainability and field failure patterns.

The architecture is the cross-layer decision structure that ties those memories together. When the ties weaken, fidelity is lost.

Fidelity Loss Is Decision Loss

Architectural fidelity is often treated as a representational problem. Does the model match the system? Does the drawing match the implementation? Does the requirement match the test? These questions matter. But they are not enough.

A representation may match the visible system and still have low architectural fidelity if it fails to preserve the decision structure that made the system meaningful.

Fidelity is lost when the team no longer shares the same understanding of what was decided, why it was decided, which decisions dominate others, which assumptions were active, which alternatives were rejected and why, which invariants were protected, and which decisions are still open.

This produces several recognizable failure modes

• The team may retain the decision but lose the rationale.
• The team may retain the rationale but lose the original context.
• The team may remember the context but forget which constraints were essential and which were merely convenient.
• The team may agree on the artifact but disagree on what the artifact means.
• The team may preserve the interface but forget the invariant the interface was designed to protect.
• The team may preserve the requirement but forget the stakeholder concern that generated it.
• The team may preserve the design but forget the alternatives that were rejected.
• The team may preserve the architecture deck but lose the architecture.

This is why architecture can decay before the system visibly fails.

At first, the degradation appears as confusion. Different groups make locally reasonable decisions that do not compose. Meetings become longer. Interfaces require more negotiation. Requirements become less explanatory. Verification becomes more defensive. Integration reveals surprises that should have been predictable. The architecture has not necessarily broken in a physical sense.

Instead, the shared decision memory has fragmented.

This connects directly to team cognition. Shared mental models, transactive memory, and team cognition research all point to the same practical problem: groups act coherently only when the relevant knowledge is sufficiently shared, distributed, and retrievable for coordinated action [Weg87, CBSC93, DMM10].

The Problem of Agreement

Successful architecture depends on shared cognition with high fidelity. A decision does not become architecturally effective merely because it appears in a document. It becomes effective when the relevant community understands it sufficiently to act coherently under it.

There are several distinct pathologies here.

In the first case, the decision was never actually made. Different groups proceed under different assumptions, each believing the architecture supports them. The disagreement is latent until integration or review forces it into the open.

In the second case, the decision was made but not understood. The organization has made a formal decision but only a small number of people understand its rationale, priority, and consequences. This creates brittle dependence on tacit knowledge.

In the third case, the decision was made and understood but not accepted. People comply superficially while creating local workarounds. The architecture erodes through rational local adaptation.

In the fourth case, the decision was once valid but its context has changed. The team continues to preserve the artifact because the decision has become institutionalized, even though the conditions that justified it are no longer present.

These are not merely communication problems. They are architectural problems since they change the causal effectiveness of the decision structure.

• A decision that is not understood cannot reliably constrain action
• A decision that is not accepted will be locally bypassed
• A decision whose context has been forgotten cannot be intelligently revisited
• A decision whose priority is unknown cannot be traded against other decisions

Architecture as Organizational Memory

This view also explains why architecture is partly cognitive and partly institutional.

Architecture is not only in the minds of engineers. It is distributed across people, models, documents, contracts, standards, tests, tools, procedures, suppliers, reviews, and governance mechanisms. It is a form of organizational memory.

But organizational memory is not automatically coherent. Different parts of the organization remember different pieces of the architecture and some pieces are remembered differently by those disparate parts of the organization.

• Some memories are formal and controlled
• Others are informal and tacit
• Some are current
• Others are stale
• Some are accessible
• Others are trapped in expert heads, old presentations, obsolete assumptions, someone’s personal hard drive, or abandoned trade studies

Organizational-memory and sensemaking research help explain this problem. Organizations preserve knowledge not only in records but also in roles, routines, culture, transformations, and interpretive practices [WU91, Wei95]. Professional practice also depends on reflective interpretation under changing conditions, not merely the execution of stored procedures [Sch83].

A healthy architecture program therefore does more than produce representations. It maintains the coherence of decision memory across layers. This is why design rationale matters. It is also why architecture decision records, trade studies, interface rationale, verification rationale, and review histories matter. Their purpose is not bureaucratic completeness. Their purpose is to preserve the causal meaning of the system.

• Without rationale, the organization may know what it built but not why it built it that way
• Without causal ordering, the organization may know the decisions but not which ones depend on which
• Without vertical traceability, the organization may know local decisions but not how they transmit constraint across mission, operation, function, implementation, verification, and governance
• Without shared cognition, the organization may possess the architecture and still be unable to act architecturally

What This Means for Systems Engineering

Systems engineering is often described as the discipline that translates stakeholder needs into requirements, architectures, designs, verification programs, and delivered systems. That remains true. But this decision-memory view clarifies what must be preserved during that translation.

The essential object is not the requirement document, the model, the review package, the interface specification, or the test plan. Those are necessary projections. The essential object is the causally ordered decision structure that links stakeholder concern to system behavior, system behavior to architectural commitment, architectural commitment to implementation, and implementation to evidence.

A systems team loses fidelity when that linkage is broken.

This can happen even in a well-documented program.

• Documentation can preserve statements while losing meaning
• A model can preserve structure while losing rationale
• A requirement can preserve wording while losing stakeholder intent
• A test can preserve procedure while losing the architectural invariant it was meant to protect

When these things happen, the organization begins to reason from artifacts rather than through architecture. The artifact becomes authoritative precisely when its causal connection to the original decision structure has weakened.

This is a dangerous moment.

The Role of Systems Engineering in Preserving Institutional Memory

All of this clarifies the role of the systems engineer. The systems engineer is not merely the person who checks artifacts, coordinates disciplines, manages interfaces, or translates between engineering and management. Those tasks matter, but they are projections of a deeper responsibility. The systems engineer helps preserve the cross-layer decision memory of the system. That means keeping mission decisions connected to operational decisions, operational decisions connected to functional and physical decisions, implementation decisions connected to verification decisions, and all of them connected to governance, regulation, manufacturing, service, and lifecycle consequences. Good systems engineering protects the causal continuity of the architecture.

Thus, the systems engineer adds value by helping the organization remember why the system is becoming what it is.

Toward Architecture Reviews as Fidelity Recovery

This view also changes the purpose of architecture reviews.

If architecture is primarily components and relationships, then an architecture review checks whether the components and relationships are correct, complete, consistent, and feasible.

This is necessary, but not sufficient.

If architecture is decision memory, then an architecture review must also ask

• What decisions generated this structure?
• Which decisions are upstream of others?
• Which decisions are still provisional?
• Which decisions have hardened into commitments?
• Which decisions protect mission, safety, security, regulatory, verification, modularity, or lifecycle invariants?
• Which decisions are understood by the whole team, and which survive only as expert memory?
• Where do different vertical layers carry incompatible interpretations of the same decision?
• Where has the artifact preserved structure but lost rationale?
• Where has the lower-level design discovered evidence that should propagate upward and reopen a higher-level decision?
• Where is the team treating a projection of architecture as if it were the architecture itself?

These questions point toward architecture review as a fidelity recovery mechanism. The review is not merely an inspection of diagrams. It is a disciplined attempt to recover, test, and realign the decision structure that gives those diagrams meaning.

This will be the subject of the next post.

Closing

Architecture is often drawn as structure: boxes, lines, layers, interfaces, allocations, and flows. But those drawings are shadows of something deeper.

Architecture is the cognitive and organizational memory of consequential decisions. It is the layered causal structure that determines what the system is, why it is that way, what it must preserve, what it may become, and what future paths have already been made easier or harder.

When a team loses that memory, it may still have the documents. It may still have the model. It may still have the components. It may still have the interfaces.

But it has begun to lose the architecture.

References

[CBSC93] Janis A. Cannon-Bowers, Eduardo Salas, and Sharolyn Converse. Shared mental models in expert team decision making. In N. John Castellan Jr., editor, Individual and Group Decision Making: Current Issues, pages 221–246. Lawrence Erlbaum Associates, 1993.

[DMM10] Leslie A. DeChurch and Jessica R. Mesmer-Magnus. The cognitive underpinnings of effective teamwork: A meta-analysis. Journal of Applied Psychology, 95(1):32–53, 2010.

[Haz98] George A. Hazelrigg. A framework for decision-based engineering design. Journal of Mechanical Design, 120(4):653–658, 1998.

[JB05] Anton Jansen and Jan Bosch. Software architecture as a set of architectural design decisions. In Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, pages 109–120. IEEE, 2005.

[KLvV06] Philippe Kruchten, Patricia Lago, and Hans van Vliet. Building up and reasoning about architectural knowledge. In Christine Hofmeister, Ivica Crnkovic, and Ralf Reussner, editors, Quality of Software Architectures, volume 4214 of Lecture Notes in Computer Science, pages 43–58. Springer, 2006.

[KR70] Werner Kunz and Horst W. J. Rittel. Issues as elements of information systems. Technical report, Institute of Urban and Regional Development, University of California, Berkeley, 1970.

[MC96] Thomas P. Moran and John M. Carroll, editors. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, 1996.

[MYBM91] Allan MacLean, Richard M. Young, Victoria M. E. Bellotti, and Thomas P. Moran. Questions, options, and criteria: Elements of design space analysis. Human-Computer Interaction, 6(3–4):201–250, 1991.

[PW92] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17(4):40–52, 1992.

[Sch83] Donald A. Schön. The Reflective Practitioner: How Professionals Think in Action. Basic Books, 1983.

[TA05] Jeff Tyree and Art Akerman. Architecture decisions: Demystifying architecture. IEEE Software, 22(2):19–27, 2005.

[Weg87] Daniel M. Wegner. Transactive memory: A contemporary analysis of the group mind. In Brian Mullen and George R. Goethals, editors, Theories of Group Behavior, pages 185–208. Springer, New York, 1987.

[Wei95] Karl E. Weick. Sensemaking in Organizations. SAGE Publications, 1995.

[WU91] James P. Walsh and Gerardo Rivera Ungson. Organizational memory. Academy of Management Review, 16(1):57–91, 1991.