A data platform

A data platform is a capability for working with data across systems. It need not be one product, one database or one physical location. Depending on the purpose and constraints, the capability can be centralised, distributed or federated, and many organisations use a hybrid.

The word selected matters. Bringing data into a platform creates copies, access paths, retention duties and dependencies. The organisation should first establish why data is needed, which authority applies, how long it should remain and whether querying it at the source would be safer or simpler.

What the reference diagram shows

The diagram is one reference pattern, not a mandatory product list. Data can enter through batch, event or query interfaces. Storage and processing services organise it for approved uses. Metadata records meaning, lineage and ownership. Interfaces can support analytics, operational applications, exchanges and, where appropriate, AI workloads.

Engineering, security and governance operate across those components. They cover such questions as who can change a pipeline, how access is approved, which evidence is retained, how quality is monitored and how a failed service is recovered. The actual implementation may keep some components at source systems or with separate providers.

Operational applications still have their own purposes and records. A platform connects or coordinates selected parts of them; it does not automatically become the authoritative source for every fact.

More than analytics

A platform can support several capabilities:

• shared definitions and discoverable metadata;
• reproducible reporting and analysis;
• governed exchange between systems;
• data quality and lineage controls;
• event-driven or scheduled automation;
• optional model training, retrieval or inference with separately approved data.

The brain image is a visual metaphor for connection and coordination. It does not mean that every decision, dataset or process should move into one technical system. Deliberate separation can improve resilience, minimise data and preserve local authority.

Why sovereignty matters

A platform can increase concentration risk because several teams may depend on the same formats, identity service, metadata catalogue, pipelines or supplier. That risk is specific to the scoped architecture. A federated design can still have a critical shared control plane, while a central platform can have tested independent copies and replacement paths.

Examine the platform from four connected angles:

• Data: Can the customer obtain complete, intelligible and restorable data and evidence for the stated purpose?
• Software: Can it operate, inspect, change or replace the required code, formats, interfaces and dependencies?
• Hardware: Can it obtain and operate suitable capacity and move the workload when the current substrate is unavailable or unsuitable?
• Organisational: Do applicable contracts, licences, policy, decision rights, duties, supplier commitments and governance let the customer exercise the corresponding right?

These questions interact. Technical options matter only when the customer also has the authority, responsibilities and supplier support needed to exercise them; reassuring agreements matter only when the technical path works in practice.

Describe the Organisational layer through data complianceData complianceThe enforceable side of the Organisational layer: the applicable laws, jurisdictions, contracts, licences, policies, decision rights and supplier commitments that set what an organisation may and must do with data.Read more →and data ethicsData ethicsA separate governance perspective on the Organisational layer: asking whether the exercise of scoped authority is proportionate, fair, transparent and justifiable to the people and communities affected.Read more →, with governance operating across both. Keep enforceable requirements, responsible-use considerations and practical-control findings separate so none is mistaken for a score, verdict or certification.

Platform sovereignty is therefore a context-specific claim, not a property of a product category. Record the service or release, deployment, operating model, relevant agreements, customer-control boundary and review date, then exercise the continuity and exit paths that matter.