In Software, Most of What Matters is Never Visualised—and We Still Call it Architecture.

In civil engineering / construction:

1. Architecture is visual by definition

2. Every definition, dependency, constraint, load, flow, and exception:

   • is drawn

   • is dimensioned

   • is cross-referenced

3. A large project easily has 1,000–6,000 drawings

4. Nothing critical is allowed to live in someone’s head→ because it cannot be executed safely without being visual

In other words:

Visual models are the architecture

---

In software:

1. “Architecture diagrams” usually mean:

   • 5–6 box diagrams

   • one deployment view

   • one integration view

2. Everything else lives in:

   • PowerPoint

   • Word documents

   • Jira tickets

   • emails

   • and people’s heads

3. Roughly 60% of the real architecture is non-visual and tacit
   

So when we say software architecture, we are not talking about the same thing as civil architecture.

That’s the mismatch we are calling out.

---

The real problem

Software calls itself architecture without being fully visual.

Which means:

• definitions are textual

• dependencies are implicit

• interdependencies are inferred

• behaviour is discovered through execution, not drawings

So when a Chief Architect leaves, the organisation doesn’t lose diagrams. It loses unvisualised structure.

---

Why this breaks continuity?

In construction:

• If something is not drawn, it does not exist.

• Execution follows drawings.

In software:

• Things exist even if they are never drawn.

• Execution happens first; understanding comes later.

---

So software “architecture” is closer to:

an oral tradition with some sketches

That’s why it collapses when people leave.

---

So what is missing in software architecture?

Not frameworks. Not tools. Not governance.

What is missing is this:

A need that all logic must be visualised.

Rules, flows, exceptions, timing, ownership, dependencies—they exist, but they are not forced into visual form.

Until that happens, architecture will remain:

• partly visual

• largely textual

• mostly mental

---

This is the real distinction we are making

We are not redefining architecture.

We are just saying:

Software has never completed the journey that civil architecture finished long ago: making structure (Anatomy) fully visual and externalised.

That’s the gap.

---

Where Enterprise Anatomy fits

What we are doing with Enterprise Anatomy is not “another EA framework”.

It is an attempt to do in software what construction already does:

• force implicit structure into explicit models

• make dependencies visible

• reduce reliance on memory

• ensure continuity independent of people

---

In short:

Turn software from a memory-driven discipline into a visual anatomy-driven one.

In construction, nothing is allowed to exist unless it is drawn. In software, most of what matters is never visualised—still exist inside the mind of the people and we still call it architecture.