The most expensive line in most data budgets is not the warehouse invoice. It is the number two teams computed independently, arrived at differently, and now have to reconcile live, in a meeting nobody scheduled for that purpose. Finance built active_customers one way. Product built it another. Both are defensible; both pulled from real sources. And you are about to pay a third time — in the hour three expensive people spend discovering that "active" meant two different things all along.
That is what it costs to treat data as a lake instead of a product. You paid to build the report once, paid again when a second team didn't trust the first one enough to reuse it, and now you pay a standing quarterly tax to reconcile the two. The cloud invoice is the small number. The duplicated pipelines, the reconciliation meetings, and the decisions made on a figure nobody can fully defend — that is the real bill, and it lands on no single line.
Let me be precise about my vantage, because this is a CIO-altitude problem and I am a security and platform leader reasoning up toward it, not a chief data officer inside the seat. But I own the parts a security and DevOps leader always ends up owning — lineage for the auditors, classification for the regulators, access control for everyone. Building AgentOS, our governed internal agent platform, hit it from the other side: an agent is only as trustworthy as the data it reads, and a lake nobody can vouch for turns a confident agent into a liability. From every angle the pattern is identical. The lake was never the strategy. The owner is.
The lake was sold as the strategy, and a lake has no owner
The centralization pitch was seductive and, for a while, universal: pool every source into one warehouse and value will emerge from the aggregate. What emerged, in shop after shop, was a large store of data a central team was nominally responsible for and nobody was actually accountable for. That team inherited tables it did not produce, whose meaning it had to reverse-engineer, whose quality it could not guarantee because it did not control the source. That is not ownership. That is custody of someone else's mess.
Here is the mechanic that turns custody into recurring cost. A consumer — an analyst, a finance team, a product manager — goes to the lake, finds three tables that might hold what they need, cannot tell which is authoritative, cannot find anyone who will stand behind any of them, and does the rational thing. They build their own: a fresh pipeline off the raw source, their own definition of the metric, a number they trust because they made it. Multiply that by every team that has ever distrusted the lake and you have not built a data asset. You have subsidized a hundred private ones. Same report, paid for over and over.
A widely cited reframe — the data-mesh idea associated with Zhamak Dehghani — names the fix: treat each meaningful dataset as a product, owned by the domain that produces it, with a consumer, an interface, and someone accountable for whether it is any good. I am not dogmatic about the full architecture. But the core move is the one that matters, and it is organizational before it is technical. Give the number an owner.
Ownership is a domain, not a data team
The instinct, once leaders decide data needs an owner, is to hand all of it to a central data team and call that ownership. It isn't. A central team can own the platform — the warehouse, the catalog, the pipelines, the standards — but it cannot own the meaning of a number it did not generate. The team that runs billing knows what a charge is, when it is final, and which edge cases make it not final. No amount of central diligence reconstitutes that faithfully. Ownership of the data has to sit where the understanding of the data already sits.
So the model I reason toward looks like this. The domain that produces the data owns it as a product and is accountable for the definition, the quality, and the promises. The central platform team owns the paved road every domain publishes onto, and makes publishing a product cheaper than not publishing one. A light governance function owns the standards that keep every domain's product legible to everyone else's consumers. Break that division and you get one of two failure modes: a central team drowning in data it doesn't understand, or a hundred domains each inventing an incompatible standard. Ownership without a paved road is anarchy; a paved road without ownership is the lake again.
This is also, quietly, a funding conversation — which is where it becomes genuinely a CIO's problem and not mine to own. Treating a domain's data as a product with users outside the domain is real work with no local payoff, and if the operating model rewards teams only for shipping their own features, it is exactly the work that never gets prioritized. That is an operating-model fix, not a tooling purchase, and it has to be made from a seat that controls the incentives.
A data contract is a promise, not a schema
The word "contract" gets thrown around loosely here, so let me be concrete, because the schema is the least of it. A schema tells a consumer the shape of the data. A contract tells them what they can rely on — and what happens when the producer needs to change it. It is the difference between a table you found and a product you were promised.
A contract worth the name specifies, in a form both humans and pipelines can read:
- Semantics, not just types. Not "
customer_idis a string" but "a customer is an entity with at least one funded account; this excludes trial signups and closed accounts." The definition is the thing every reconciliation meeting is secretly fighting about. Write it down once, at the source, and the fight stops recurring. - Freshness and availability. How current the data is guaranteed to be, and by when. "Updated by 06:00, never more than three hours stale" is something a consumer can build on. "Refreshed sometime overnight, usually" is not a promise; it's a hope.
- Quality guarantees. The invariants the producer promises to hold — uniqueness, non-null on the columns that matter, referential integrity, sane ranges — enforced as tests at publish time, not discovered as surprises three joins downstream.
- A versioning and deprecation policy. The single most valuable clause. Breaking changes get treated exactly like breaking changes to an API: a version bump, a migration window, advance notice, a deprecation date. A producer who quietly alters a column's meaning has broken a contract, and it should feel like a broken contract — not a Tuesday.
None of this is exotic. It is the discipline every platform team already applies to a public API, pointed at data instead of endpoints. We version and deprecate service interfaces deliberately; data has the same blast radius and, in most companies, none of that discipline. The contract closes the gap — and it is precisely what lets a consumer reuse a number instead of rebuilding it, because reuse only becomes rational when the thing you reuse comes with a promise attached.
Lineage is how you earn the trust back
Ownership and contracts create trust going forward. Lineage is how you defend it after the fact, and in a regulated business it is not optional. Lineage is the provenance of a number — this figure came from these sources, through these transformations, under this version of this contract, computed at this time. When the number is wrong, lineage tells you where, in minutes rather than across a forensic afternoon.
I care about this from a seat most data conversations forget. When I report a metric to a board, "the dashboard says so" is not a defensible answer; a director who has done this before asks the second question — where does that come from — and I had better have the chain. When a SOC 2 auditor asks how a control figure is produced, "we're confident it's right" is a finding, not an answer. Under GLBA and the FFIEC expectations the 1,500-plus financial institutions we serve live inside, the ones doing real diligence ask you to trace a number end to end and watch what happens. Lineage is the difference between passing that test and improvising through it.
Lineage is also what finally makes the duplication visible. Wire it across the estate and the redundant pipelines light up — three lineage graphs terminating in three slightly different definitions of the same metric, each with its own compute cost and its own quietly wrong edge case. You cannot consolidate what you cannot see. Lineage is how you discover you have been paying for the same report three times, so you can decide, deliberately, which one is the product and retire the rest.
Accessibility is the product, not a favor
Here is the failure that undoes all the rest. You can name owners, write contracts, and wire lineage and still lose — if finding the trusted dataset requires knowing which analyst to Slack. A data product a consumer cannot discover, cannot access without a week of tickets, and cannot understand without a meeting is not a product. It is a well-governed secret, and a rational consumer routes around it by building their own — again. The entire point was to stop paying twice, and inaccessibility puts you right back to paying twice with better metadata.
So accessibility is a first-class feature of the product, not a favor the owning team does when it has spare time. The same data-as-a-product thinking spells the attributes out plainly: a real data product is discoverable through a catalog, addressable at a stable location, self-describing enough to use without a tour guide, and secured with access that is fast to grant to the right person and impossible for the wrong one. That last pairing is where my day job lives: accessible and secure get posed as opposites, but done right they are the same control. A catalog with clear ownership, a classification, and a self-serve access request that resolves in minutes under policy is both more usable and more governed than the ticket queue it replaces. Friction is not a security feature. It is what drives people back to the raw source, the least governed path of all.
Set the SLA on discovery and access as deliberately as you set it on freshness. If the honest time-to-trusted-data is measured in days, you have your answer for why the lake never became the asset — nobody waits days for a number they can approximate themselves by lunch.
Treat data like a product with an owner
The lake was never going to become a strategic asset on its own, because a pile of data with no owner, no contract, no lineage, and no front door is not an asset. It is deferred cost with good intentions. The asset is the number the whole company trusts enough to reuse — and that trust is manufactured, deliberately, by the same product and platform disciplines you already run everywhere else.
So four moves, none of which requires a new platform. Give every number the business decides on a named domain owner, and make that ownership a funded expectation rather than a volunteer shift. Write the contract — semantics, freshness, quality, and a versioning policy — for every dataset that crosses a domain boundary. Wire lineage across the estate so every figure can be traced and every duplicate pipeline is exposed. And publish the catalog with an access SLA, so the trusted path is also the fast path.
I'm curious where others draw the line between central and domain ownership specifically — how thin you can make the central platform team before the standards stop holding, or how much autonomy you can give a domain before its data product stops being legible to everyone else. Tell me how you've split it, and what broke when you got the balance wrong.
