Part II — Understanding Flow · Chapter 14 · First Public Draft
Architecture
The friction of decisions that have to travel to reach the judgement they need.
I helped build the reputation architecture still carries in some organizations. Ownership has the story: a board created to review significant decisions, which people stopped bringing decisions to, which slowed everything down while seeing less than before.
The lesson I drew took longer than it should have. The problem was not that we reviewed too much or too little. The problem was that architecture had been made into a place.
Architecture is a competence, not a role.
And it is worth being exact about what the competence is for, because the field has spent thirty years defining itself by its instruments rather than its purpose.
Architecture is the practice of reducing structural friction.
It is not primarily the design of technology. Nor is it the design of organizations. It is the continuous cultivation of the conditions under which value gets created.
Diagrams, target states, standards, reference models, governance forums — all of those are instruments architecture may reach for, and each is useful in the narrow case where it earns its cost. None of them is what architecture is. A beautiful landscape model of an organization that still cannot decide anything is the instrument delivered and the job skipped.
The moment it becomes a role, three things follow automatically. Decisions have to travel to reach it, which adds delay. The people who make decisions daily stop developing the judgement to make them well, because someone else is responsible for that. And the architects, now at a distance, start optimizing for consistency — the only thing visible from a distance — rather than for whether the organization can change.
That last one is the quiet damage. Consistency is not a bad goal, but it is the goal you drift toward when you can see the shape of things and not the cost of changing them.
Here is the standard I’d use instead, and it’s the only one I’ve found that survives contact with a real organization:
Architecture should make the organization, and what it builds, easier to change.
Not more consistent. Not more compliant. Easier to change — because the one thing you can predict about any organization is that it will eventually face something it didn’t plan for, and everything else it optimized for will matter less than how fast it can move once it knows.
That standard is unusually testable. Take any architectural decision, in the broad sense this paper uses — a system choice, a team boundary, a reporting line, a funding structure — and ask what it makes harder to reverse. Then ask whether the thing being made irreversible is one you’re confident enough about to be stuck with.
Most bad architecture isn’t wrong so much as premature — a reasonable decision made irreversible before anyone knew enough to make it permanent.
And this is where the competence has to live in the teams rather than above them, because the person closest to the work is usually the only one who can see which decisions are cheap to change and which quietly aren’t. That judgement doesn’t transfer through a review meeting. It has to be grown where the decisions are made.
Which brings the chapter to the claim underneath all of this, and the one Part III is built on: architecture is not the practice of designing solutions. It is the practice of cultivating the conditions where good solutions keep emerging. If architecture is cultivation rather than design, it was never going to be a place solutions get sent to.
One boundary is worth drawing before this goes any further, because a chapter this expansive about architecture invites the wrong conclusion. Architecture can influence Organizational Flow. It cannot own it. Flow is produced by the organization as a whole — through decisions made in leadership, in teams, in how capabilities are funded and who is trusted to decide. Architecture is one competence among several that shape those conditions, and a paper that let it stand in for the whole would be making the same mistake as the board in the story at the top of this chapter.
Governance asks was this decision approved. Architecture, done as a competence, asks are the people making these decisions equipped to make them well — and the slow work of making that true is what Part III is for.
Editor's Notes
The standard this chapter settles on — that architecture should make things easier to change — has a much more rigorous statement elsewhere. *Building Evolutionary Architecture* (Neal Ford, Rebecca Parsons and Patrick Kua) makes guided, incremental change the first property an architecture should have, and then does the part I do not: it operationalizes it, through fitness functions that make the properties you care about continuously and automatically verifiable. What I am doing here is applying the same standard one level out, to organizational decisions — team boundaries, reporting lines, funding structures — where there is nothing to automate and no equivalent of a fitness function to lean on. That makes this chapter weaker as engineering and, I think, useful anyway, because the decisions that most often make an organization hard to change are not the ones in the codebase. Anyone applying the idea to systems should go to them for the mechanics.