Transformation Under Scale on Andrew Hunter — Systems Architect & Builder

Transformation Under Scale — Part III: Read the Estate

Thu, 17 Sep 2026 00:00:00 +0000

Part II settled who owns what, and it settled it by accountability rather than by merit. That ruling names an owner for each capability, but it does not tell you what is running underneath the claim. An owner can be named for a capability that turns out to be four separate systems, or for a fact that is written in a hundred places. Naming the owner does not surface either one. The only way to know what you actually own is to read the estate.

You cannot bound what you have not read. Part I turned objectives into constraints and held them over the estate, and a constraint is only as honest as the reading behind it. Reading honestly means ranking what you find. Evidence is what the builders left behind: the schemas, the foreign keys between them, a count of what is actually deployed. Inference is everything said about that: the diagrams, the names, the stories teams tell. When the two disagree the evidence wins, and an inference with nothing under it is a finding to chase, not a conclusion to build on.

Even ranked, evidence has to be read at the right depth. Reading where the calls go is one depth; whether the data’s meaning has traveled with them is another, and the second can reverse the first. Stop at the first and the plan you write is confident, survives review, and solves a problem the estate does not have. The reading has to go deep enough that the plan is sized to what is actually there. Reading at that depth is half the work. The other half is laying the operating model you decided in Part II over what you read, and that is what the rest of this essay is about.

Transformation Under Scale — Part II: Transform the Company, Not the Technology

Wed, 09 Sep 2026 00:00:00 +0000

Part I of this series turned the company’s objectives into constraints and held them over the estate. That is where a transformation starts, but it is not the first decision it makes. Before you can constrain the technology, you have to settle something older and more contested: who owns what.

A transformation re-draws the company’s operating model: the map of the business capabilities and, for each one, who is accountable for it. That is a business decision, and often a legal one. The technology comes after. The systems express the ownership the business decided; they do not decide it.

This is why the work transforms the company, not the technology. Skip the re-draw and go straight to the stack, and you rebuild the old company in cleaner code. Every ownership question the business left open gets decided by the systems instead, by default and out of sight. Better platform, same company. A migration wearing a transformation’s name.

Transformation Under Scale — Part I: Constrain the Possible, Not the Ideal

Wed, 02 Sep 2026 00:00:00 +0000

When a transformation begins, the instinct is to draw the target: a clean picture of the system as it should be, planned backward from. Over an existing estate, that is the wrong first move.

You do not design the ideal system. You constrain the possible one, and the constraints come from what the company is trying to do, not from taste. Each objective, taken seriously, becomes a constraint that rules some designs out.

That is what I mean by architecture as practiced constraint. A transformation is that practice at estate scale: a set of limits drawn from the company’s objectives and held over the estate you have, not a picture to build toward. Get the limits right and the program follows from them. Reach for a picture and you spend three years learning it was a wish.

The examples in this series come from one program: an architecture-led transformation at a national wireless carrier serving millions of subscribers, on a fifteen-year estate that had grown without a central architecture function. Everything concrete is genericized, but the decisions are real.