The Illusion Was Rational

Chapter 5: Splitting the System Without Splitting the Problem

The system was split into independently deployable services, but the business processes were not decomposed into genuinely owned units. A two-day change takes six weeks because of dependencies that decomposition was supposed to eliminate.

A logistics company needs to add a new delivery status, “held at customs,” to the tracking flow visible to customers. The status already exists in the customs clearance system; it needs to propagate to the shipment tracking service, which feeds the customer-facing portal.

In a system with real boundaries and owned contracts, this is two days of work: one team adds the status to its published event contract, the consuming team reads the new event and renders it, both on their own release schedules, with a versioned contract governing the interaction.

In the logistics company, none of those conditions apply. The shipment tracking service does not own its data model; it reads from a shared database maintained by a “data platform” team whose change process requires approval from three service owners, because any change to the structure affects all consumers. Team A submits a change request, and the data platform team finds the new status value conflicts with a field used by the returns service, opening a discussion with Team B (returns), which is mid-cycle on a different priority and cannot engage for two weeks. Weeks pass; four teams are involved across seven meetings before the work can begin. The two-day change takes six weeks. The six-week delay on a two-day change is not an engineering failure but the cost of a structural decision: the system was split without splitting the problem. The board sees a change-velocity problem; the cause is ownership. The shared database at the centre of the vignette is the structural equivalent of a ledger that five departments report from: any modification to its structure requires the consent of every reader, whether or not the modification affects them.

Microservices were adopted to enable independent deployment inside an organisational structure that could not otherwise move: split the system into many smaller pieces, each deployed on its own schedule, and teams would move faster while changes stayed contained. Consider a bus: it carries everyone using one driver, one maintenance schedule, one parking space. Replace it with twenty separate cars and you feel autonomous until you notice the six tow ropes bolted to your chassis that permanently couple you to every car around you. The split was made by vehicle type rather than by destination, so no car carries everything it needs to complete a journey alone, and you end up with the maintenance cost of a fleet and the manoeuvrability of a bus. Splitting the code let teams ship without coordinating releases, but it did not decompose business processes into genuinely owned units: the cars were separated, but the convoy remained intact.

The distinction that matters is between advisory and binding architecture. Advisory architecture describes what should exist, reference models, capability maps, target-state diagrams, and can be updated without touching the system. Binding architecture embeds decisions in code, interfaces, and data contracts, so that an engineer knows, without asking anyone, what she can change independently and what requires coordination. In large software-dependent corporates, architecture is almost always advisory: the system evolves according to its own logic, the artefacts according to theirs, and the two diverge. The architecture review board at a European car leasing company meets every second Thursday. A team presents a proposal to extract the residual value calculation from a monolith into a dedicated service. The board evaluates it against a reference model last updated eight months ago, and forty-five minutes are spent debating which area of the system the service belongs in. In the code, sixty-three services follow a team structure from a reorganisation that predates the reference model by two years, so the reference model describes nothing real. The board grants conditional approval, the team lead nods, and she will name the service to match the model, update the wiki, and build exactly what she originally proposed. The approval is the last time the board will think about the service.

The organisation has distributed deployment without distributing ownership. True autonomy requires that a team own a business process end to end, that the data it produces is owned locally and accessed only through published contracts, and that some duplication is tolerated. Centralised data models optimise for reporting coherence; distributed ownership optimises for change velocity. These organisations chose coherence for finance and sacrificed autonomy for engineering, producing simulated autonomy: teams deploy independently but cannot evolve independently, the condition Chapter 10 calls false autonomy.

...

See also: Full contents · Preview chapters · Illusions of Work