Enterprise data architecture, AI governance, and the gap between what an organization’s documentation says and what its systems actually do.
The problem
Where your documentation and your systems disagree — and who owns the difference.
Every large organization has an architecture diagram, and every large organization has a second architecture that actually runs. The distance between them is where integration breaks, where duplicate systems quietly multiply, and where nobody can say who owns a given dataset without starting an argument.
This is not a documentation problem. It is a discovery problem. Nobody sat down and decided that three business units would each maintain their own definition of “customer.” It happened one reasonable decision at a time, over a decade, and no single person was ever in a position to see all of it at once.
Which is also why it doesn’t get fixed internally. When an architect says another team’s data is redundant, that’s heard as a territorial claim, and the room starts calculating what he wants. The same finding, produced by a tool and backed by evidence, is just a fact. Nobody has to lose.
The method
Code proposes. Schema constrains. Runtime confirms.
Code is the strongest signal, because it is the only one that carries intent. A pipeline does not merely join two tables; it filters, coalesces, handles the nulls, and encodes the business rule that exists nowhere else — active customer means status in (1,3) and not test_flag — in a WHERE clause somebody wrote in 2019. It is also versioned, so you get when it changed and who changed it.
But code says what was intended. Schema says what is structurally possible. Only runtime tells you what is still true. Any one of the three, read alone, produces a confident and misleading picture.
What it answers
What actually talks to what? Not what the diagram claims. Which systems genuinely exchange data today, through which path, and which of those paths has been dead for two years while still costing money to maintain.
Who really owns this? Every catalog product asks people to declare ownership. People don’t. Ownership inferred from behavior — who writes to it, who is paged when it breaks, whose name is on the change — is the version that survives contact with reality.
Where does the same thing exist twice? Under two names, with two definitions, maintained by two teams who have never met. This is the one that funds the project, because it is the one with a number attached.
Run once, this is an assessment. Kept running against a baseline, it becomes something more useful: notice when a pipeline appears that nobody registered, when a documented relationship stops being exercised, when one team’s definition of member quietly stops matching another’s, or when someone new starts reading a sensitive dataset.
Background
Twenty-five years in enterprise architecture, data, and cloud — fifteen of them at Oracle Corporation as Senior Principal Consultant and then Principal Engineer, across more than a hundred engagements in financial services, manufacturing, retail, telecommunications, energy, aerospace, and government.
Most of that work was governance rather than construction: chairing enterprise design authorities and architecture review boards, ruling on competing designs across teams I did not manage, and being the person who had to explain afterwards why. I have spent a lot of time in rooms where the real obstacle was not that the answer was unknown, but that saying it out loud would cost somebody something.