I have been thinking about a deceptively simple question lately:
What is the actual purpose of architecture?
Not what artefacts an architect produces. Not what modelling notation we use. Not whether the architecture is documented in a Solution Architecture Document, an ArchiMate model, a collection of diagrams, or a set of PowerPoint slides.
What is the purpose of architecture?
The question became particularly interesting to me when I started thinking about what happens after an architecture has been produced.
At some point, a group of engineers has to take that architecture and turn it into a working system. They need to understand what they are building, how the pieces fit together, what needs to happen and in what order, where the boundaries and responsibilities lie, what dependencies exist, and what work is actually involved.
And ultimately, they need to be able to answer a very practical question:
"How much work is this going to take?"
That question led me to a conclusion that seems obvious in hindsight, but is surprisingly easy to lose sight of:
The purpose of architecture is to make a solution sufficiently understandable and actionable that engineering can realise it.
Architecture is more than documentation
I have never been particularly convinced by the idea that the primary output of an architect is a document.
A document is an artefact. Architecture is a model.
The distinction matters.
A beautifully formatted architecture document can still leave an engineering team with fundamental unanswered questions. Conversely, a relatively small set of well-chosen models can communicate an enormous amount of information if they capture the right things.
The architecture needs to communicate the significant structure of the solution, the behaviour of that solution, and the decisions and constraints that govern it.
In other words, it needs to answer two fundamental questions:
What exists?
and
What happens?
The architecture has a structural dimension
The structural view describes the things that make up the solution.
What are the significant components?
Where are the boundaries?
What responsibilities belong to each component?
How do the components depend upon and communicate with one another?
Where does data originate, where does it flow, and where is it persisted?
These are architectural questions.
A structural model might show that a Digital Experience interacts with a Customer API, which in turn interacts with a Customer Master Data platform and downstream services.
That gives engineering an understanding of the landscape.
But it doesn't yet tell them how the solution behaves.
And this is where the second dimension becomes important.
The architecture has a temporal dimension
Systems do not merely exist.
They do things.
They receive requests. They publish events. They wait. They retry. They change state. They fail. They recover. They invoke other systems. Sometimes they do these things synchronously. Sometimes asynchronously.
Understanding this behaviour requires modelling the solution over time.
A sequence diagram can therefore communicate something fundamentally different from a component diagram.
A component diagram might tell us:
"These systems interact."
A sequence diagram can tell us:
"This is how they interact, in what order, under what conditions, and what happens when something goes wrong."
That distinction is critical.
Consider a seemingly simple requirement:
"Expose customer information through an API."
That statement tells an engineer almost nothing about the actual solution.
What happens when the request arrives?
Who authenticates it?
Who authorises access?
Which system is the source of truth?
Is the call synchronous?
Does the API wait for downstream processing?
Is an event published?
What happens if the downstream system is unavailable?
Is the request retried?
What happens if the request succeeds but the response is lost?
What state does the customer move into?
Which systems need to be notified?
These aren't merely implementation details. Collectively, they define the behaviour of the solution.
And behaviour happens over time.
Architecture should reduce ambiguity
This leads to what I think is one of the most important responsibilities of an architect:
reducing ambiguity.
Engineering teams shouldn't have to reverse-engineer the intended solution from a collection of vague boxes and arrows.
Nor should they need a series of meetings with the architect to discover what the architecture actually means.
Of course, there will always be engineering decisions that need to be made during implementation. Architecture cannot, and should not, prescribe every implementation detail.
The architect doesn't need to specify every class, method, database index or configuration parameter.
But the significant decisions need to be made explicit.
The important boundaries need to be clear.
The important behaviour needs to be understood.
The important constraints need to be known.
And the important trade-offs need to be visible.
If those things are missing, engineering is left to fill in the gaps.
At that point, the engineering team isn't simply implementing the architecture.
It is designing the architecture that wasn't there.
Architecture should enable estimation
There is another useful test.
Can engineering estimate the work?
I'm not suggesting that an architect should produce the engineering team's backlog or dictate its estimates.
That's not the point.
The point is that a sufficiently elaborated architecture should allow engineers to understand the implementation implications of the solution.
If the architecture tells us that we need a new API, a new integration, an event-driven workflow, changes to an existing system, new security controls and new observability capabilities, engineering can start identifying the work.
They can identify dependencies.
They can identify unknowns.
They can identify risks.
And they can estimate.
That doesn't mean the estimate will be perfect. It means that the architecture has provided enough information for a meaningful estimate to exist.
This gives me a useful way of thinking about the architect's role:
Architecture should reduce ambiguity to the point where engineering can determine what needs to be built.
That is a very different objective from simply producing architecture documentation.
But isn't that engineering design?
This is where the boundary between architecture and engineering becomes important.
If I say that architecture needs to be sufficiently detailed for engineering to estimate the work, someone might reasonably ask:
"Aren't you just describing detailed design?"
No.
There is a distinction between defining the significant characteristics of a solution and prescribing its implementation.
Architecture should establish the significant structure, behaviour, boundaries, decisions, constraints and non-functional requirements.
Engineering then determines how those things are realised within those boundaries.
For example, architecture might establish that a service must be stateless, horizontally scalable, independently deployable and communicate asynchronously with another domain.
Engineering might then decide whether to implement that using a particular framework, messaging client, internal library or deployment configuration.
The first is an architectural concern.
The second is an engineering implementation decision.
There will inevitably be some overlap between the two. Architecture and engineering are not two completely isolated disciplines.
But there is a difference between giving engineering enough information to build something and telling engineering exactly how to build it.
The former is the architect's responsibility.
The latter is generally not.
When everything becomes architecture, architecture means nothing
This also leads to another observation.
I've encountered situations where discussions about database tables, individual file formats, field mappings or implementation-level configuration are described as "architecture".
Sometimes those things genuinely have architectural significance.
But sometimes they don't.
The fact that a particular database table has twelve columns is not automatically an architectural decision.
The fact that an API uses a particular JSON property name is not automatically architecture.
The fact that a file contains a particular delimiter is certainly not automatically architecture.
The question should be:
Does this decision have significance beyond the local implementation?
Does it affect system boundaries?
Does it establish a dependency?
Does it constrain future change?
Does it affect scalability, security, resilience, regulatory compliance or operational behaviour?
Does it represent an important architectural trade-off?
If the answer is no, perhaps it belongs in engineering design rather than architecture.
Otherwise, we risk turning "architecture" into a synonym for "everything technical".
And when everything is architecture, architecture effectively means nothing.
The architect as the bridge between intent and execution
Ultimately, I think the architect occupies an interesting position between two worlds.
On one side is intent.
- Business outcomes.
- Capabilities.
- Requirements.
- Constraints.
- Risk appetite.
- Regulatory obligations.
- Strategic direction.
On the other side is execution.
- Components.
- Interfaces.
- Data flows.
- Interactions.
- Infrastructure.
- Code.
- Testing.
- Deployment.
- Operations.
Architecture connects these two worlds.
It takes intent and turns it into a model of a viable solution that engineering can actually realise.
That is why I increasingly think of architecture not as documentation, but as a communication and reasoning mechanism.
The models we create are tools for thinking.
They expose ambiguity.
They reveal dependencies.
They force decisions.
They expose missing behaviour.
They make trade-offs visible.
And, importantly, they give engineering something from which the implementation work can be derived.
So, what is the actual purpose of architecture?
I don't think the answer is to produce a particular document.
It isn't to produce the most sophisticated ArchiMate model.
It isn't to create the most detailed collection of diagrams.
And it certainly isn't to demonstrate that the architect understands every implementation technology.
The purpose is much simpler.
Architecture should make a solution understandable enough to reason about and actionable enough to build.
I see an architect’s role as making a solution sufficiently understandable and actionable for the engineering teams responsible for realising it. This means modelling the solution both structurally and temporally: defining its significant components, boundaries, responsibilities, dependencies and data flows, while describing how it behaves over time through interactions, state transitions, sequencing and failure scenarios. The architecture should also make the significant decisions, constraints, trade-offs and non-functional requirements explicit. Done well, architecture reduces ambiguity to the point where engineering can understand what needs to be built, identify the implementation work and dependencies, and produce meaningful estimates, without the architect needing to prescribe every implementation detail.
In that sense, architecture is not simply documentation of a solution.
It is the model that connects intent and design to engineering execution.
Perhaps that is a better measure of good architecture than the size of the architecture document:
When the engineers receive it, do they understand what needs to be built?
