Commercial data platforms are operating infrastructure

Too many platform programmes are justified with architecture language and funded with hope. The business is promised a modern stack, but not always a clear explanation of which decisions will improve and how value will be measured.

A commercial data platform has a different centre of gravity. It is designed around the decisions that move revenue, margin, retention, pricing, exposure, cost, capital, or regulatory confidence. The platform matters because it makes those decisions faster, more reliable, and more repeatable.

Build, buy, and the question that decides it

That framing changes build versus buy decisions. Proprietary data value may justify bespoke pipelines and modelling. Commodity capability may be better bought. A catalogue, warehouse, lakehouse, BI layer, or orchestration tool is only strategic when it changes what the business can know and do.

The question that decides each choice is whether the capability is a source of differentiation or a cost of participation. Identity resolution across a proprietary customer base is differentiation. A managed warehouse is participation. Confusing the two produces the familiar failure modes: a bespoke orchestration layer that three engineers understand, or a bought catalogue that nobody populates because the decisions it should serve were never named.

Layer	Default posture	Build only when
Storage and compute	Buy managed	Data residency or cost at scale makes the managed option untenable
Ingestion and orchestration	Buy, configure	Source systems are proprietary and change faster than the vendor can follow
Identity and entity resolution	Build the rules, buy the engine	Matching logic encodes commercial knowledge competitors do not have
Metric layer and semantic model	Build	Always; the definitions are the business
Catalogue, lineage and quality	Buy, but own the Critical Data Element list	Never build the tool; always build the list
Models and decisioning	Build where proprietary	The model's edge comes from data nobody else holds

Sequencing is where programmes fail

The strongest platforms also respect sequencing. A CEO may want predictive analytics, but the first tranche may need identity resolution, data quality scoring, source integration, or metric definition. A CFO may want performance insight, but margin reporting may depend on customer, product, and operational data being joined in a way the organisation has never trusted before.

The pattern that works is to name the first three decisions the platform will improve, work backwards to the data those decisions need, and fund only the foundations that serve them. A platform that promises everything in year one delivers a data lake and a backlog. A platform that promises three decisions in six months delivers a habit of trust that funds the fourth.

Cost is a design decision

Cloud data platforms are metered, and a platform whose consumption is not governed will consume its own business case. The controls are unglamorous: workload tagging that maps spend to decisions, query and job budgets with owners, storage tiers that expire data nobody reads, and a monthly review where the platform lead can say which decisions the spend served. Sequencing and cost governance are the same discipline seen from two sides. Both ask which decision this is for.

The platform is now a resilience concern

For regulated firms, 2026 has added a supervisory dimension that platform leaders cannot delegate to procurement. In July 2026 HM Treasury designated Amazon Web Services, Google Cloud, Microsoft and Oracle as the UK's first Critical Third Parties, with the Bank of England, PRA and FCA overseeing them jointly from 13 July. The designation puts obligations on the providers, but it also confirms what supervisors already believed: concentration on a small number of cloud platforms is a financial stability question.

Alongside it, the PRA's PS7/26 and the FCA's PS26/2, both published on 18 March 2026, establish operational incident and material third-party reporting regimes aligned with the EU's DORA and the Financial Stability Board's incident reporting format. The FCA rules take effect on 18 March 2027. Firms will need to report the material third parties that support their important business services and the ICT assets those services depend on. A data platform that supports regulatory reporting, pricing or customer servicing is squarely within scope.

The practical consequence is that the platform's dependency map, its exit plan and its impact tolerances need to exist as maintained documents, not as diagrams drawn for a programme board. A platform lead who can show which important business services run through the platform, which cloud services and sub-processors sit beneath them, and how long each could be lost before the tolerance is breached, is doing resilience work and commercial work at the same time.

The leadership the platform needs

This is why platform leadership needs commercial fluency and technical depth. The technical leader has to understand ingestion, modelling, lineage, governance, and cloud cost. The executive leader has to explain how those choices turn into better decisions. When those are two people, the programme needs a shared scorecard: decisions improved, time to trusted answer, cost per decision, and the resilience evidence supervisors will ask for.

The platform is not the destination. It is the operating infrastructure for decision quality.

Sources

• Bank of England, PS7/26 Operational resilience: operational incident and third-party reporting, March 2026
• Norton Rose Fulbright, FCA, PRA and BoE issue policy statements on operational resilience, March 2026
• Bank of England, PS16/24 Critical third parties to the UK financial sector
• Bank of England, SS2/21 Outsourcing and third party risk management