What is Architecture?

Constraint, Causality, and the Shape of Thought

In the previous post, I defined a system as something that maintains identity through interactions with its environment but that definition leads to a deeper question:

• What determines how a system can evolve?

The answer is architecture.

But to understand architecture, we need to move beyond the usual descriptions.

Architecture Is Not the Diagram

Architecture is often described in terms of:

• components
• interfaces
• layers
• diagrams
• models

For example, the INCOSE Guide to the Systems Engineering Body of Knowledge (SEBoK) defines architecture as:

“…a conceptual model that defines the structure, behavior, and relationships of a system…”

This definition is useful and widely practiced through artifacts.

But those artifacts are not the architecture itself.

They are representations—projections of something deeper, in the same sense that early computer architecture distinguished externally visible behavior from internal realization.

But they are not the architecture itself.

A Note on Architectural Tradition

This perspective is not entirely new.

Christopher Alexander, in his work on buildings and urban environments, argued that architecture is not fundamentally about diagrams or components, but about the generation of coherent structure over time.

In A Pattern Language¹ and later in The Nature of Order², he emphasized that:

• architecture emerges through sequences of decisions
• those decisions are shaped by context and use
• good structure reflects deep alignment with its environment

In this view, architecture is not merely something described after the fact.

It is something that guides what can be built next.

The modern engineering use of the term architecture did not originate in systems engineering, but in computing.

In the 1960s, work on the IBM System/360, led in part by Gene Amdahl³⁴ and later articulated by Frederick P. Brooks Jr.⁵, introduced a critical distinction: architecture was defined as the aspects of a system visible to the user, independent of its internal implementation.

This was a fundamental shift.

Architecture was no longer the physical structure itself, but an abstraction that constrained behavior while remaining independent of realization.

The discussion here extends the Christopher Alexander idea further:

architecture is not only what is visible or specified,
but the full set of constraints that governs how a system can evolve, from conception to retirement or disposal.

This aligns with a more general principle:

Architecture is not just a representation of structure.
It is a set of constraints that shapes how structure can evolve.

Where this discussion extends Alexander’s work is in making that idea more explicit through:

• framing architecture in terms of causal structure
• distinguishing admissible and inadmissible paths
• and recognizing that these constraints operate whether or not they are intentionally designed

Architecture as Constraint

At its core, architecture is the set of constraints that determine:

• what changes are possible
• what sequences of changes are allowed
• what system states are reachable

In other words:

Architecture defines the space of possible futures.

This does not replace the SEBoK definition. Rather, it grounds it

What engineers call the problem space is, more precisely:

The set of reachable future states under architectural constraint.

Intentional and Incidental Architecture

Not all architecture is designed.

Some architecture is intentional:

• explicitly defined
• deliberately structured
• guided by stated principles and decisions

But much of architecture is incidental:

• emerges from accumulated decisions
• shaped by constraints, history, and local optimizations
• often undocumented or even unrecognized

Both forms impose constraints.

Both define what futures are reachable.

The difference is not necessarily in their effect, but in our awareness of them.

Intentional architecture is:

• reasoned about
• communicated
• (ideally) aligned with system goals

Incidental architecture is:

• discovered after the fact
• revealed through failures and limitations
• often misaligned with current needs

A system always has architecture, whether you choose to design it or not.

The only questions that matter then is:

Is the architecture understood and guided,
or is it simply the result of everything that has happened so far?

If you don’t intentionally create an architecture, can you live with the consequences of what you’ve created unintentionally?

The Missing Piece: Causal Structure

Those constraints are not arbitrary.

They are governed by causal relationships.

Every system evolves through sequences of cause and effect:

• a decision enables certain outcomes
• those outcomes constrain what can happen next
• each step builds on what came before

This creates a structure:

• some states must precede others
• some transitions are possible
• others are not

This is the system’s causal structure.

And architecture does not merely describe this structure: it constrains and organizes which causal paths are admissible.

Admissible and Inadmissible Futures

Because of causal structure, not all futures are equally accessible.

Some are:

• direct continuations of current decisions
• easy to reach

Others require:

• undoing prior work
• overcoming constraints
• or are effectively unreachable

This leads to an critical distinction:

• Admissible paths — sequences of changes that can be realized
• Inadmissible paths — sequences that cannot be realized

This distinction is rarely made explicit, but it governs everything.

Architecture as a Cognitive Construct

A subtle but critical point:

Architecture is not only embodied in the system, it also exists in how we understand the system.

An architect:

• does not manipulate the entire system directly
• operates through abstractions and models

So architecture exists in two forms:

1. Embodied: in physical / operational structure
2. Conceptual: in mental and conceptual models

These are not always aligned.

And when they diverge, problems emerge.

Projection and Loss of Fidelity

Every architectural projection or representation:

• simplifies
• omits detail
• emphasizes certain relationships

This is necessary.

But it introduces risk.

A model may:

• preserve some causal relationships
• distort or hide others
• completely miss others

So two people can:

• look at the same system
• using different cognitive models
• and reach different conclusions

This is not merely disagreement.

It is a difference in projected causal structure.

The Shape of the Future

The space of possible futures is extremely large—often effectively unbounded.

Reasoning over that space directly is intractable.

Architecture makes this tractable by imposing structure.

It gives the future a shape:

• some regions are close and easily reachable
• others are distant or blocked
• some transitions are natural
• others require significant effort

This shape is not random but emerges from

• causal structure
• constraints
• prior decisions

And it determines how the system actually evolves.

A Consequence

If architecture defines the structure of possible futures, and if our understanding of that structure is imperfect, then a critical question follows:

What happens when:

• the easiest paths lead somewhere undesirable
• and different stakeholders see different paths as “best”?

We’ll explore that next.

Core Idea

Architecture is not just structure.

It is:

the constraint on what can happen and our understanding of that constraint.

FOOTNOTES:

1. Alexander, C., Ishikawa, S., & Silverstein, M. (1977). A pattern language: Towns, buildings, construction. Oxford University Press. ↩︎
2. Alexander, C. (2002). The Nature of Order: An Essay on the Art of Building and the Nature of the Universe. Book One: The Phenomenon of Life. Center for Environmental Structure. ↩︎
3. IBM Corporation (1964), IBM System/360 Principles of Operation. ↩︎
4. Amdahl, Gene M., Blaauw, Gerrit A., and Brooks, Frederick P. (1964). Architecture of the IBM System/360. IBM Journal of Research and Development, vol. 8, no. 2, pp. 87-101. ↩︎
5. Brooks, Frederick P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. ↩︎