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; and both work 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. The tracking team (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 uses reference models, capability maps, and target-state diagrams to describe what should exist, 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 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