What the Machines See

Chapter 5: Architecture That Avoids Accountability

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, after which the team lead names the service to match the model, updates the wiki, and builds exactly what she originally proposed. The board will not verify the implementation. Both parties are aware of this. In software-dependent corporates, architecture is presented as control. Diagrams promise clarity. Reference models suggest foresight. Much of this activity exists to avoid accountability.

Architecture, in these organisations, is asked to perform a task it cannot fulfil: to impose coherence without changing the structure of responsibility. When the business is separated from engineering, it becomes a compensatory discipline, expected to produce order in a system whose disorder is organisational rather than technical, without authority over either. The result looks deliberate while encoding avoidance.

Compensatory architecture announces itself first through 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. They bear no relationship to the system they describe.

A real architecture makes some changes easy and others hard. It expresses trade-offs, embedding decisions in code, interfaces, and data contracts. It can be felt, because it limits what can be done without friction: an engineer working within it 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.” That communication happens through the code, the deployment pipeline, and the test suite, not through a document that can be ignored.

Binding architecture would require confronting the organisational split at the heart of the system: aligning ownership with behaviour, collapsing translation layers, and giving engineers authority where the work happens. It would require saying, out loud, that the system landscape diagram is wrong and has been wrong for two years, and that the people who approved it must now change the structure of their organisations.

The gap between the diagram and the system explains why so many of these organisations appear to have embraced modern architectural styles while retaining fragile systems.

...

See also: Full contents · Preview chapters · Illusions in the Boardroom