What the Machines See
Architecture in software-dependent corporates often functions as a source of avoidance rather than control. Organisations adopt the vocabulary of modern architectural styles without adopting the structural commitments that give those concepts force.
The architecture review board meets every second Thursday. A team presents a proposal to extract a pricing calculation from a monolith into a dedicated service. The board evaluates it against a reference model last updated eight months ago. Forty-five minutes are spent debating which bounded context the service belongs in. In the codebase, sixty-three services follow a team structure from a reorganisation that predates the reference model by two years. The reference model describes nothing real.
The board grants conditional approval. The team lead will name the service to match the model, update the Wiki, and build exactly what she originally proposed. The board will not verify the implementation. Both parties are aware of this. In software-dependent corporates, architecture is often presented as a source of control. Diagrams promise clarity. Reference models suggest foresight. In practice, much of this architectural activity exists to avoid accountability.
Architecture, in these organisations, is asked to perform a task it cannot fulfil: to impose coherence without changing the underlying structure of responsibility.
When the business is separated from engineering, architecture becomes a compensatory discipline. It is expected to reconcile abstract intent with concrete systems without having authority over either. It is asked to produce order in a system whose disorder is organisational, not technical. The result is an architecture that looks deliberate while encoding avoidance.
The most prominent symptom is the proliferation of architectural artefacts that possess no executable counterpart.
System landscapes, capability maps, target state diagrams, and integration views proliferate. They are reviewed, approved, and socialised. They describe what should exist, how things are supposed to connect, and where responsibilities are meant to lie. They are often beautiful: clean, symmetrical, colour-coded with precision. They bear no relationship to the system they describe.
These artefacts exert no constraint on how the system actually changes.
A real architecture makes some changes easy and others hard. It expresses trade-offs. It embeds decisions in code, interfaces, and data contracts. It can be felt by engineers because it limits what can be done without friction. An engineer working within a real architecture knows, without asking anyone, what she can change independently and what requires coordination. It says: “You can change this freely. If you want to change that, you will need to talk to this team, because their contract depends on it.” This communication happens through the code, through the deployment pipeline, through the test suite, not through a document that can be ignored.
...
Continue reading in the interactive reader
Read this chapterSee also: Full contents · Preview chapters · Illusions in the Boardroom