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.
Evidence before judgment
Reading an estate honestly is a discipline, and it is the same three moves every time.
Rank the sources by how hard they are to fake. Data ranks first. The schemas, the foreign keys, and the row counts are what the system persisted and enforced over years, and a constraint that has held in production is not an opinion. Code ranks second. It shows what the system can do, which is real, but it also carries dead paths and branches that never run, so it describes the possible rather than the actual. Documentation ranks last. Diagrams, names, and written descriptions are claims about the first two, usually written once and rarely revised, so they capture a moment and then drift from it. When the sources disagree, trust them in that order: data over code, code over documentation.
Label the inferences, and keep them visible. Most of what you produce while reading is inference: a guess at a boundary, a name for a cluster, a story about what a service is for. Inference is not a sin, it is a step. The sin is letting a guess harden into a conclusion without ever admitting it was a guess. Write each one down as a finding, with the evidence it still needs, so a wrong one is caught instead of built upon.
Validate the method before you build on it. The step that turns evidence into a judgment is itself a hypothesis. A heuristic that clusters tables into domains by their names is a guess about the estate until it is checked against something harder, and it has to be checked before a single boundary is drawn on its output. Until then the method is another inference, and it should be labeled like one.
The verdict deeper reading overturned
Coupling is not a single fact. It has layers, and a reading is only as true as the layer it stops at. At the transport layer, coupling is about where the calls go. At the meaning layer, it is about whether one system’s data shapes have spread into another. A coupling can be tidy at the first layer and pervasive at the second, so a plan graded at the wrong layer is confidently wrong.
The examples in this essay come from one carrier’s transformation, where we read the estate this way before sizing any plan. The clearest case was a coupling everyone had already priced. The channels talked to the back end through one integration package, and the first read graded it the obvious way: centralized in a single place, cheap to re-point. That was true at the transport layer. Every call did route through the one package.
We read it again at the layer of meaning. A team of 16 agents worked the channel code as an adversarial audit, each high-tier finding refuted first against file and line before it was allowed to stand. Of 106 findings, 91 survived. The verdict held for transport and failed for meaning: the vendor’s data shapes had traveled with the data into about 43 UI bind points per repository, into browser storage, and into the analytics events. The calls were centralized. The coupling was not.
Read at the transport layer alone, the plan would have re-pointed the one package, declared the channels decoupled, and shipped a migration that left the real coupling untouched in the roughly 43 bind points per repository where it had actually spread. The deeper reading is what turned a confident, wrong estimate into a correct one.
The names are not the system
A name is a label people put on the estate, not a description of it, and plans get built against the label. That makes a wrong name expensive, and names fail in two directions. A single name can sit on top of several independent systems and hide them. Or a name can assert a structure the system does not actually have and invent one. The correction is the same both ways: replace the name with a count, and check the boundary the name claims against the evidence before planning against it.
On that program, the first failure showed up in the application everyone paged about, the one named in every incident channel. It was not an application. Automated discovery found four separate deployables that had worn one name for years, and a census counted 365 .NET deployables across the estate, re-counted daily so the boundary was evidence rather than memory. You cannot carve a target state around a thing that four teams each half-own under one label.
The second failure ran the other way, inventing structure that was not there. An early read declared that the system wanted to be an event bus, and the story was attractive enough to survive several meetings. The messaging census found one true bus consumer; the three services everyone called event receivers were HTTP webhooks with a queue drawn beside them on a diagram. The correction went into the record in place, next to the claim it replaced, because a hypothesis that quietly disappears teaches no one.
Names are neither of the two things that matter. What you actually hold is the evidence you read and the operating model Part II decided, and the architecture is what happens when you lay one over the other.
The enterprise estate
Reading the raw estate gives you the truth and not yet the architecture. A schema census, a deployable count, a foreign-key graph are all true and all evidence, and all still inventory. They tell you what exists, not what any of it is for. The step that turns inventory into architecture is to lay the business model over it.
Part II produced that model: the capabilities the company runs and the single owner of each. Reading gives you the raw estate, what the systems actually are. Lay the operating model over that evidence, mapping every schema, deployable, and flow to the capability it serves and the owner accountable for it, and you have the enterprise estate. That projection is the work. Enterprise architecture is not a diagram of the systems; it is the systems read through the operating model.
The projection is also where the findings are. A capability the model gives one owner, written across three owners’ schemas, is not a labeling problem; it is the transformation backlog, stated precisely. One deployable serving three capabilities is a split the model demands and the evidence prices. Where the model and the evidence line up there is no work. Where they conflict is the plan.
Doing the overlay honestly is what the reading discipline was for: the model proposes the boundaries, and the evidence says whether the estate can hold them. On the carrier program the clearest conflict was the customer. Part II had named a single owner for customer identity, which was the right operating-model decision. Laying that decision over the data told a harder story. A census of where customer identity was actually written found it spread across more than a hundred tables holding hundreds of millions of rows, and the heaviest were not the system everyone called the customer master but the shopper and quote stores, which also carried the most regulated personal data. The model named one owner; the estate showed the identity that owner was accountable for living in a dozen systems that answered to other teams. That gap was not a diagram to redraw. It was the migration, scoped and priced.
The boundaries held up better than the customer did, and the overlay measured where. Tested against the foreign keys before anyone planned against them, 67 percent of more than 1,500 edges fell inside the model’s boundaries. The remaining third marked the exact places an intended boundary would cut through live wiring, and those cuts were the rest of the backlog.
How to read an estate
The method behind all of this is small enough to run on a schedule, and running it on a schedule is the point.
Start from the schemas, because they are the ground truth. Extract the structure across the whole schema estate, every table and key, in a form you can diff. The tool is not the point and the options are interchangeable: Redgate SQL Doc on SQL Server, SchemaSpy or SchemaCrawler over any JDBC database, the database’s own information_schema as the universal fallback. What matters is that the schema is evidence, pulled from the running system rather than described from memory. Then build the dependency graph the same way, from what the code declares rather than what the wiki claims: the dependency manifests (the .csproj files in a .NET estate, the equivalent build files elsewhere), the connection strings, and the outbound API calls, resolved into what actually talks to what.
Then lay the operating model over what the reading produced. Agent swarms read the raw schemas and the dependency streams and surface the de-facto structure; the operating model from Part II is projected over that evidence to produce the enterprise estate, and every place intended ownership and actual data disagree is recorded as a finding. The machine finds the structure; the operating model supplies the meaning. The order matters: the machine reads the estate first, and the model is laid over the reading, never asserted in place of it.
The move that keeps the map honest is operational. The entire pipeline runs in CI as a weekly job, so the estate map, raw and enterprise, re-derives itself from the current source every week. A picture drawn once starts drifting from the estate the moment it is saved. A picture that regenerates cannot drift far, because the run after a change shows the change.
The check is one question. Take the coupling you are most certain is cheap to undo, and name the depth you graded it at. If you graded where the calls go and called it decoupling, you have not read the estate. You have read its cover, and the plan you are about to size is a plan for a system you have not seen.
Closing
You cannot bound what you have not read, and reading is not one act but a depth you have to reach. On this program the estimates that cost the most were the confident ones, built on a first reading that was true at the surface and wrong underneath. I have learned to distrust an estimate that arrived before the second reading did.
Once the estate is read at depth, the next question is where one capability’s authority ends and the next begins, and who is allowed to write what. Drawing those boundaries, with a single writer for every fact, is the subject of the next essay.