Commercial data platforms

Too many platform programmes are justified with architecture language and funded with hope. The business is promised a modern stack — a lakehouse, a semantic layer, a self-service analytics environment — but the description of value stays technical. When delivery concludes, the leadership team finds that the decisions they make are not materially faster, better evidenced, or more commercially useful than before.

A commercial data platform starts with a different centre of gravity: the decisions that move revenue, margin, retention, pricing, risk, or regulatory confidence. The platform exists to make those decisions faster, more reliable, and more repeatable. That purpose should be visible in every significant architecture and investment choice.

The platform as commercial infrastructure

Infrastructure earns its cost by enabling something the organisation could not otherwise do consistently. A commercial data platform earns its cost by enabling reliable, timely, inspectable answers to the questions that drive commercial and regulatory performance.

That reframing changes the way platform success is defined. The right metrics are not ingestion throughput, query latency, or the breadth of tool coverage. They are: which decisions are now made faster? Which metrics are now trusted where they were previously contested? Which regulatory evidence pack can now be produced in hours rather than days?

When the platform team can answer these questions with specifics, the platform has earned its position as operating infrastructure rather than a technical project that delivered to specification but did not change what the business can do.

Build vs buy, framed commercially

Build vs buy decisions are only strategic when they are framed around proprietary data value and commercial differentiation. A catalogue, warehouse, lakehouse, BI layer, or orchestration tool is not inherently strategic. It becomes strategic when the organisation's proprietary data, use-case requirements, or regulatory obligations make a bespoke approach clearly superior to a commodity solution.

In practice, most organisations overbuild in areas where commodity solutions would serve adequately — ingestion pipelines, generic BI layers, standard transformation logic — and underbuild in the areas where proprietary value is highest: the data models that capture what a specific business's customer, risk, pricing, or margin dynamics actually look like.

The useful analytical question for any build vs buy decision is: does this component touch data or logic that is specific to how our business operates, or is it infrastructure that any organisation of our type would need? The former often justifies investment. The latter is usually better bought, governed, and maintained.

Sequencing matters more than architecture

The most common reason platform programmes take longer and cost more than planned is sequencing failure. A CEO wants predictive analytics. The programme budget is justified against that ambition. But the first tranche of delivery discovers that identity resolution, data quality scoring, source system integration, and metric definition need to be resolved before any predictive model produces a trustworthy output.

Good platform leadership sequences delivery around the dependencies rather than the ambition. The strategic vision may be a unified commercial intelligence environment. The first deliverable may be a reliable, owned, documented view of customer or product data that leadership currently cannot trust.

Sequencing also applies to technology choices. Choosing an advanced modelling platform before the organisation has mastered reliable data ingestion and quality management creates technical debt at the foundation layer. The platform strategy should build upward from the most critical data quality and ownership problems, not downward from the most sophisticated use cases.

Data products for commercial decisions

The platform is the infrastructure. The data products are what the business actually uses. A data product for commercial decisions has the same properties as any decision-grade data asset: explicit ownership, defined lineage, quality thresholds, a clear decision context, and a retirement condition.

In insurance and banking contexts, the data products that most directly affect commercial performance include underwriting data products — exposure, risk concentration, pricing adequacy at portfolio level; customer data products — behaviour, retention propensity, margin by segment; and finance data products — margin, cost allocation, capital adequacy, and regulatory reporting inputs.

Building these products requires the platform team to work closely with the commercial and finance functions — not just to understand data requirements, but to understand the decisions these functions make, the evidence standards those decisions require, and the failure modes that would damage confidence in the product.

Governance inside the platform

A platform without embedded governance creates technical capability and operational risk simultaneously. Governance inside the platform means more than access controls and audit logs. It means that every significant data product has documented lineage from source to consumption, known quality measurement, explicit ownership, and metadata that makes it discoverable and interpretable to someone who did not build it.

For regulated organisations, this is not optional. BCBS239, GDPR, FCA and PRA expectations, and internal audit requirements all reach into the data platform. The evidence that regulators and auditors expect — that data is what it claims to be, that it is governed, that quality is measured and remediated — has to be producible from the platform rather than reconstructed ahead of each review.

Microsoft Purview, Databricks Unity Catalog, and equivalent metadata governance tools are most effective when governance design precedes the tooling deployment. The tool enforces the model; the model has to exist and be well-designed before the tool adds value.

Leadership requirements

Commercial data platform leadership requires an unusual combination of capabilities. Technical depth matters: understanding ingestion patterns, transformation logic, data modelling, lineage, governance tooling, cloud cost management, and the architectural trade-offs between lakehouse, warehouse, and hybrid approaches. Without this depth, a platform leader cannot evaluate vendor claims, challenge architecture decisions, or understand where the programme is building avoidable risk.

Commercial fluency is equally necessary. The platform leader has to be able to explain architecture choices in terms of business outcomes — why this ingestion pattern matters for margin reporting, why this modelling approach is essential for regulatory evidence, why this sequencing decision prevents a commercial decision from being made for another quarter if it is not resolved now.

The combination of technical credibility and commercial relevance is what allows platform leadership to maintain investment confidence through the necessary sequencing work that precedes the strategic use cases, and to earn ongoing commitment to governance and quality control work that does not produce immediately visible features.