Who Owns the Data Model When Six Programmes Need It

The question that decides whether an AI programme ships is almost never a modelling question. It is whether the word customer means the same thing in the claims workstream as it does in the distribution workstream, and if it does not, who is allowed to say so.

Most portfolios answer it by accident. Each programme gets a budget, a board and a delivery date, and each one quietly builds the entity definitions it needs to hit that date. Nobody forks the data model on purpose. They fork it because the alternative is waiting for a decision that has no named owner, and no delivery manager has ever waited.

I keep returning to one artefact because it gets this right in a way I rarely see written down. It is a proposed programme structure for an international health insurance group with six parallel transformation workstreams running at once. All six sit under a single programme board, accountability is devolved to each project, and a separate function is carved out whose remit begins with data model management. Beside it sits a six-by-six dependency matrix, filled in cell by cell. The two pages together make an argument the industry still mostly declines to make: shared definitions need a single owner, and the matrix is how you prove which definitions are shared.

The matrix tells you which nouns are shared

A dependency slide is usually decorative. This one is not, because somebody filled in every cell and let the pattern fall out rather than asserting it in a bullet.

Read down the column belonging to the single-product-platform workstream and every other workstream names an analytics and reporting solution as something it needs. Read across the transposed row and the platform names analytics and reporting requirements back at all five. Ten cells, ten appearances, the only capability sitting on both sides of every pairing with the platform. Read down the column belonging to the global service model and process standardisation appears in all five cells, which makes standardised process the precondition nobody could start without.

That is a measurement rather than an opinion. It was not the conclusion of the slide, it is what the filled-in grid happens to say. And the practical reading is uncomfortable: two capabilities are load-bearing for the entire portfolio, and neither of them belongs to any single workstream. Analytics and reporting is what the platform team calls a downstream concern and what everybody else calls an input. Process standardisation is what the service-model team calls its deliverable and what everybody else calls a starting condition.

There is a smaller tell on the same page, and it is the failure in miniature. In the distribution row, two different cells carry byte-identical text about needing one complete view of the customer, regardless of whether a partner or an internal team is executing the process. Two dependencies, one sentence, copied. Somebody working at pace reached for a phrase that sounded right for both. That is how a shared definition becomes an unexamined one, inside a document whose whole purpose was to examine dependencies.

A design authority is not a review board

The part I want people to copy is the split.

Four functions sit across the six workstreams rather than inside any one of them. One handles business change, from communication and training through to stakeholder management. One handles process as a standing capability: design, monitoring, ownership, lifecycle management. One is the coordination office, holding planning, reporting, risk, change control and dependency management. And one, the design authority, holds the data model, the architecture blueprint, design review, the change board, the benefit case and the total cost of ownership view.

Notice what is on each side. The coordination office owns the plan and the dependency register. The design authority owns what the thing actually is. Most programmes fuse these, and when they fuse them the plan wins, because a plan has dates and a data model has opinions. An office owning both the schedule and the semantics will trade the semantics away in the last week of a phase, and it will be right to, given what it is measured on.

The other half of the split is where the blame sits. Each of the six workstreams gets its own board and leads on its own outcomes. Programmes usually invert this. They keep accountability central, where it becomes an office that owns the reporting and none of the work, and they devolve architecture, where six competent teams each produce a design that is locally correct and globally incompatible. Push accountability down, keep integrity central. That ordering is not obvious and it is not decorative.

Contracted, not logged

The dependency handling is where the proposal stops being a diagram and starts being a mechanism, and it is the detail I would take to any programme running more than two workstreams.

In the design, every dependency is contracted between a named provider and a named receiver, with the coordination office accountable for orchestrating the process. Then the types are separated and governed differently. Solution dependencies that span workstreams go through the design authority, so an end-to-end solution is assessed as one thing. Requirements dependencies go to a named requirements manager and a traceability matrix. Scheduling dependencies are driven into an integrated plan. And benefit dependencies are documented and monitored through change control specifically so they are not eroded by incremental change.

That last one is the sharpest sentence on the page. A benefit dependency dies quietly, and no single change request kills it. Twenty small descopes, each individually reasonable and individually approved, and the benefit that justified the programme is gone without anyone deciding to remove it. Putting benefit dependencies under change control admits that the erosion is the normal case rather than the exception.

6

Parallel transformation workstreams under one programme board

29 of 30

Off-diagonal cells populated in the dependency matrix

10 of 10

Cells touching the platform workstream naming analytics and reporting

4

Dependency types governed through separate mechanisms

Where the forks are discovered

Six teams working from six versions of the same entity do not collide during design. They collide at integration, which is the worst possible place, because by then each version has code, tests, a migration and a delivery manager who has already reported green.

The cost is not the reconciliation. It is that reconciliation at that stage is a negotiation between two teams with sunk work and separate incentives, refereed by nobody, and the outcome is usually a mapping layer rather than a decision. Mapping layers are how a fork becomes permanent. Both definitions survive, a translation sits between them, and every model built on top inherits a branch nothing downstream can see. Lineage stops being answerable at exactly the moment somebody wants to ask it.

There is one more prerequisite buried in the matrix cells rather than in any headline. Two separate workstreams, independently, name the same blocker: somebody has to define which services will be supported globally, which locally, and which regionally. Neither could proceed without it, and it belongs to neither. That classification is not a hub-count decision or an org-chart decision. It is a statement about which definitions are permitted to be uniform worldwide, and it has to be made by someone whose job is the whole, not the part.

A shared definition with no owner is not shared. It is six definitions that have not met yet, and they meet at integration, which is the most expensive room in the building.

What we would put in place

None of this needs a data scientist, which is the awkward part, because all of it has to land before one is worth hiring.

Fill in the dependency grid for every initiative in flight, in both directions, and let it tell you which entities are shared rather than deciding in advance. Name one function that owns those entities, with the architecture blueprint and the change board attached to it, kept separate from whoever owns the plan. Give each shared definition a single named person rather than a standing committee. Contract every dependency between a provider and a receiver, and govern the kinds through different mechanisms, because a schedule dependency and a benefit dependency fail in completely different ways. Then classify each service as global, local or regional before anyone argues about structure.

That opening block is what a RealAI Platform engagement does first, and it is why we ask which definitions your programmes disagree about before we ask which use case you want to run. The modelling end has never been cheaper. Retrieval over your own documents stands up in weeks, copilots reach a pilot in days, and the first carefully scoped autonomous experiments are already sitting in evaluation sets on somebody's laptop. All of it reads from an entity model. If six programmes each hold a different one, you have built six things that cannot be evaluated against each other, and no amount of retrieval quality repairs that.

The agreed European rules on AI will eventually make lineage a matter of record rather than a matter of engineering taste. That is a reason to fix the ownership question early, while it is still cheap and still yours to design.

Structure, dependency cells and governance mechanisms are as set out in a consulting proposal to an international health insurance group covering two of its declared transformation priorities. A proposal is a recommendation, not a delivered outcome: what is described here was designed and offered, and the counts are read from its own matrix. Reading that structure as a data ownership argument is ours.