Size the data foundation to the use case, not the roadmap

9 June 2026 · Data · 7 min read

The platform that serves every future use case serves none of them yet. Build for the decision in front of you, and build it so the next one is cheaper.

There is a version of the data conversation that every executive team has had. The use cases are agreed. Someone points out that the data is not ready. Someone else proposes a foundational programme — a platform, a governance layer, a canonical model — that will make the data ready for all of them at once. It is sequenced first, because it is a dependency. It is scoped for eighteen months.

The reasoning is sound and the outcome is usually poor. It is worth being precise about why, because the failure is not a design failure.

The problem is duration, not architecture

An eighteen-month programme has to survive eighteen months of an organisation that is not standing still. In that time the sponsor may change, the operating model may be redrawn, the budget will be re-examined at least twice, and the priorities that justified the platform will have moved.

More importantly, it produces no usable output until late. That means for most of its life it can only be defended on the basis of the plan rather than the result — and a plan is a weak thing to defend in a budget round, particularly against proposals that can point at something working.

So these programmes tend to be cut, not because anyone decided they were wrong, but because at every decision point they are the item with the least evidence attached.

What "sized to the use case" means

The alternative is not to skip the foundation. It is to build it in increments that each end in something being used.

Take the first decision you intend to improve. Ask what data it actually needs: which entities, at what granularity, at what freshness, from which system of record. The answer is almost always narrower than the canonical model — a handful of entities, a few attributes each, and a latency requirement that is hours rather than seconds.

Build that. Build it properly: with the lineage documented, the ownership assigned, and the quality checks in place, because those are the parts that make it reusable rather than another extract. Then deploy the use case on top of it.

You have now delivered a working capability and a piece of foundation, and the foundation exists in the only form that has ever been reliably maintained — one that something depends on.

Why the increments compound

The objection is that this produces a patchwork. It does, if each increment is built in isolation and nobody is looking at the whole.

It does not if two disciplines are held constant. First, every increment registers its entities and definitions in one place, so the second use case discovers what already exists before it builds its own version. Second, someone holds the architectural view and is empowered to say "that entity already has an owner and a definition; use it".

Under those two conditions the increments accumulate. The third use case takes less data work than the second, and the sixth takes very little, because most of what it needs is already there, already owned, and already trusted. The foundation gets built. It just gets built as a by-product of things that shipped, rather than in advance of them.

The freshness question

One place teams consistently over-build is latency. Real-time is expensive, architecturally and operationally, and it is frequently specified because it sounds more capable rather than because the decision requires it.

The test is simple: how often does the decision get made, and how much does the underlying reality move between those moments? A decision made once a day against data that changes weekly does not need streaming. Ask the question explicitly and the requirement often drops by an order of magnitude, taking a large amount of cost and fragility with it.

What to hold firm on

Sizing to the use case is not an argument for cutting corners. A few things should be non-negotiable in every increment, because they are what makes the work reusable rather than disposable:

• One system of record per entity, written down, with a named owner.
• Lineage from source to consumption, so the answer to "where did this number come from" takes minutes.
• Quality checks that run continuously and alert an owner, not a dashboard.
• Definitions agreed with the business function that uses them, not inferred from a schema.

Those four are cheap when done alongside a use case and expensive when retrofitted across a platform.

The sequencing argument, in one line

A foundation built ahead of demand is a bet on a roadmap that will change. A foundation built underneath each use case is paid for by something that works, and it is still there when the roadmap moves.