Chapter 2
If architecture creates value through clarity, then clarity must have a place to live.
Most organisations struggle not because architecture is absent, but because no one is clear about which layer is responsible for which decisions. Enterprise architecture, solution architecture, and technical architecture collapse into one another. The result is familiar: more documents, more meetings, and less movement.
This is not a maturity problem.
It is a separation problem.
Architectural layers are not a hierarchy of authority. They are distinct decision engines, each operating at a different scope and timescale. When those engines overlap, clarity degrades into volume.
Layers Are About Decisions, Not Status
The most persistent misunderstanding in architecture is treating layers as levels of seniority.
Enterprise architecture is not “above” solution architecture.
Solution architecture is not “above” technical architecture.
They are orthogonal, not vertical.
Each layer exists to answer a different question:
Enterprise architecture answers what must be true for the organisation to succeed
Solution architecture answers what choice we make in this context
Technical architecture answers what the system actually does
When these questions are answered in the wrong place, architecture stops working.
Enterprise Architecture: Declaring Direction
Enterprise architecture exists to declare intent, not to design systems.
Its primary responsibility is to make explicit what the organisation is optimising for, and what it is willing to sacrifice. This is not abstract vision. It is operational direction.
Enterprise architecture answers questions like:
What outcomes override others when trade-offs are required?
What constraints are non-negotiable?
What risks are acceptable, and which are not?
The outputs of enterprise architecture should be few and sharp:
principles that constrain choice
guardrails that bound behaviour
explicit trade-offs stated in plain language
What enterprise architecture must not do:
prescribe solution patterns
mandate technologies
describe system structure
Its failure mode is expansion. When enterprise architecture tries to represent the entire portfolio in detail, it replaces direction with noise. Teams stop seeing constraints and start seeing bureaucracy.
A simple test applies:
Does this help teams make faster decisions — or does it ask them to wait for permission?
If it is the latter, enterprise architecture has overreached.
Solution Architecture: Making the Choice
Solution architecture exists to choose.
Given enterprise intent and real constraints, solution architecture decides how a specific problem will be solved at a specific point in time. This is where trade-offs become real.
Solution architecture answers questions like:
Which option do we take now?
What do we gain, and what do we give up?
What risks are we consciously accepting?
The defining characteristic of good solution architecture is decisiveness. It narrows possibilities and commits to a direction delivery can act on.
What solution architecture must not do:
restate enterprise principles
defer decisions through neutral analysis
attempt to future-proof everything
Its failure mode is indecision disguised as rigour. Option lists, comparison tables, and endlessly qualified recommendations allow teams to proceed without clarity while believing they are aligned.
A simple test applies:
Can delivery begin immediately, without interpretation?
If not, the decision has not been made.
Technical Architecture: Exposing Reality
Technical architecture exists to expose truth.
It is concerned with what is built, what runs, and what breaks. Unlike other layers, it cannot negotiate with reality.
Technical architecture answers questions like:
Does the system behave as expected?
Where do assumptions fail under load?
What constraints are real, not theoretical?
Its outputs are executable and observable:
code
tests
metrics
runtime behaviour
What technical architecture must not do:
redefine organisational intent
override solution decisions without escalation
diverge silently from declared direction
Its failure mode is invisibility. When technical reality is not surfaced, divergence accumulates quietly until it becomes catastrophic.
A simple test applies:
Does the system confirm our assumptions — or force us to revisit them?
When technical architecture feeds reality back upstream, the system stays coherent.
Where Overlap Destroys Clarity
Architectural dysfunction appears when layers substitute for one another.
Enterprise architecture starts solving delivery problems.
Solution architecture avoids commitment.
Technical teams compensate for unclear direction.
Documents grow because decisions shrink.
Monolithic artefacts emerge not from complexity, but from avoidance. They allow contradictions to coexist and accountability to blur.
When everyone owns everything, no one owns the decision.
The Discipline of Separation
Healthy architecture enforces separation deliberately.
Enterprise forums test alignment with intent.
Solution forums test quality of choice.
Technical forums test truth in execution.
No forum does all three.
This is not bureaucracy. It is respect for the different kinds of thinking required at different layers.