Enterprise architecture that survives a reorganisation

Open an enterprise system that has been running for eight years and you can usually date it from the module names. They match a slide from a leadership deck of a particular year: three divisions, a shared services function, a regional structure that has since been redrawn twice. Two of those divisions have merged. One region no longer exists. The code still carries all of them, because something in reporting depends on the old shape and nobody can establish which of those reports is still read.

Reporting lines change every eighteen months or so. Capabilities change every decade. A boundary drawn on the first will be wrong long before the system is retired, and the wrongness is expensive because it is structural.

The test is simple and slightly uncomfortable

For any boundary in the architecture, ask whether it would still make sense if the organisation reorganised next quarter. Order capture, pricing, identity, billing, inventory and settlement all pass that test. A module called Commercial Team Tools does not. Neither does a service whose responsibilities are precisely the current responsibilities of one director.

The tell is usually in the naming. Components named after what they do age well. Components named after who owns them acquire a second, undocumented purpose within a year of the owner changing, because the new owner has different work and the component has their name on it.

Make the organisation shape data

The structural error we are most often asked to unpick is a hierarchy baked into the schema. Territory encoded in a column name. A fixed three-level regional structure. Permissions that assume one manager sits above exactly one region.

On the field CRM we built for Würth, regional managers see only their own territory across thirty thousand representatives. That rule has to hold absolutely, and territory boundaries get redrawn on a normal commercial cycle. Where the hierarchy lives in data (a node table, an edge table, effective dates) redrawing a region is an afternoon and a backfill. Where it lives in the schema and in every query that reads it, the same change is a migration with a full regression pass behind it. The two designs cost roughly the same to build and differ by an order of magnitude to change.

Effective dates are the part teams skip. An organisation that reorganises in March still has to report on February under February's structure, and a hierarchy with no time dimension forces someone to choose between correct history and a correct present.

Where the org chart legitimately belongs

Some things genuinely have to track the current structure: service ownership, on-call routing, approval chains, access rights. The discipline is to read those from a directory the organisation already maintains rather than encoding them. When HR moves a person between teams, the system should follow without a release and without a ticket.

The dead branch problem

Structures outlive their reason and then survive because nobody can say with confidence what depends on them. That is a measurement failure more than an architectural one. Instrument reports, endpoints and modules for last use, and keep the record for longer than one financial cycle so the annual processes show up. Something with no reads in fourteen months can be switched off behind a flag, and the two complaints that follow will teach you more about the real dependency graph than any discovery workshop.

We have carried dead branches ourselves for longer than we should have, on systems we still maintain, because the cost of proving a thing is unused was higher than the cost of leaving it. That calculation is fine once. Repeated for a decade, it produces the eight-year-old system described at the top of this piece.

Designs that survive a reorganisation tend to be unremarkable ones, where somebody at the start declined to name a module after a department that had existed for six months. It reads as pedantry in the design review and as foresight for the next ten years, which is roughly the exchange rate on this kind of decision.