A Data Platform Is Not Another System to Use

Abstract

Data Platform programmes are often introduced as if they were the deployment of one more application: a new portal, a new warehouse, a new lakehouse, or a new analytics interface. This framing is technically misleading and organisationally dangerous. A platform should not be defined by the screen through which users encounter it, but by the infrastructural contracts through which heterogeneous systems become interoperable, observable, and governable. This essay develops the distinction between application and substrate, using concepts from distributed systems, platform engineering, and the philosophy of technical objects. It proposes a layered model in which the Data Platform functions as a semantic and computational commons rather than a monolithic product. Mathematical formulations are used to describe interface stability, coupling, and the cost of change. The conclusion is that the best Data Platform is often the one most users never have to “use” directly: it quietly changes the quality, consistency, and explainability of the systems they already inhabit.

1. The application fallacy

An application is ordinarily defined through a relatively bounded user purpose: submit a request, inspect a record, schedule an activity, visualise a metric. A Data Platform has a different ontological status. It is not primarily an endpoint of work but a condition under which multiple endpoints can share reliable information.

When the platform is sold internally as “another system,” users reasonably ask: Why should I enter the same information again? Which tool should I trust? Does this replace the existing system? Who owns the new interface? These are not resistance to innovation; they are symptoms of an incorrect architectural metaphor.

Let $A_1,\dots ,A_m$ be applications and $P$ the platform. In the naïve model, $P$ is simply another node in the application graph. In a genuine platform model, $P$ provides services and contracts consumed by the nodes:

where each $C_i$ is a governed contract for data, semantics, identity, policy, or computation. The platform’s role is not to monopolise interaction but to reduce the cost and ambiguity of interactions among applications.

2. Substrate rather than destination

A transport network is not another destination. A language is not another sentence. An operating system is not another document. In each case, the infrastructure enables activities without competing with them at the same semantic level. The Data Platform should be conceived similarly: as a substrate that supports flows of evidence, computation, and policy.

This does not mean the platform has no interfaces. Engineers require operational consoles; stewards require catalogues; analysts require query surfaces; administrators require policy controls. But these are views onto the substrate, not the essence of the platform.

Gilbert Simondon’s philosophy of technical objects is pertinent. A mature technical object becomes more concrete as its components enter into mutually coherent relations rather than remaining an arbitrary assembly. A Data Platform becomes technically concrete when ingestion, contracts, quality, lineage, orchestration, access, and publication reinforce one another. If they are merely purchased as separate tools and connected by convention, the result is an inventory, not a platform.

3. Coupling and the economics of change

The architectural value of a platform can be understood through coupling. Suppose $n$ applications exchange information through pairwise integrations. The maximum number of directed connections is

or $n(n-1)/2$ if direction is ignored. Even when the actual graph is sparse, each new system potentially introduces multiple bespoke mappings, credentials, schedules, and failure modes.

With a stable platform contract, the cost approaches a hub-and-contract model. Each application implements one or a small number of governed interfaces to the platform. The simplistic comparison is $O(n^2)$ versus $O(n)$, but real systems require nuance: domain-specific contracts, bidirectional flows, and non-functional constraints prevent perfect linearity. Nevertheless, the platform changes the topology of change.

Let the expected cost of modifying system $A_i$ be

where $C_i$ is internal change cost, $p_{ij}$ the probability that integration $i,j$ is affected, and $k_{ij}$ the remediation cost.

A stable platform boundary reduces the number and variance of $k_{ij}$ terms. The platform therefore functions as an economic instrument for containing the propagation of change.

4. The platform as a semantic commons

Physical connectivity is only the first layer. If every application publishes its own meanings unchanged, the platform becomes a centralised archive of dialects. A semantic commons requires shared rules for identity, time, units, status, ownership, and data quality.

The term “commons” is deliberate. A commons is neither ownerless nor free of governance. It is a shared resource whose durability depends on rules of contribution and use. Data contracts specify what producers must guarantee and what consumers may assume. They also make asymmetries explicit: a producer owns operational capture, while the platform may own canonicalisation; a domain council may own definitions, while engineering owns execution.

We can model a contract as

where $\Sigma$ is the schema, $\Gamma$ semantic constraints, $\Pi$ policy constraints, $\Lambda$ service expectations, and $\Omega$ ownership. An application-level API that exposes only a schema is therefore an incomplete platform contract.

5. Why invisibility can be a success criterion

Infrastructure is often most successful when it recedes from attention. Users should not need to understand orchestration graphs to receive a consistent indicator, nor should clinicians need to inspect schema registries before consulting a longitudinal view. This is not an argument for opacity. The platform must be explainable to those who need to audit or operate it. It is an argument for progressive disclosure: complexity should be accessible without being imposed on every user.

A platform can be considered non-intrusive when it minimises duplicate interaction. Let $I_u$ be the set of manual interactions required from user $u$ before the platform and $I_u^{\prime }$ after introduction. The platform should aim for

except where new interactions are justified by improved safety or accountability. A platform that demands redundant data entry in order to integrate systems has shifted integration cost onto users.

The correct question is not “How many people logged into the platform?” but “How many existing workflows received better data, fewer reconciliations, and clearer evidence because the platform existed?”

6. Control plane, data plane, and experience plane

A useful architectural separation distinguishes three planes.

The data plane moves and stores observations. It includes connectors, event streams, files, tables, object storage, and computational engines. The control plane governs execution: orchestration, metadata, lineage, quality policies, access policies, versioning, and incident management. The experience plane exposes fit-for-purpose views through applications, APIs, dashboards, notebooks, or operational products.

Confusing these planes produces brittle architectures. If business logic is embedded exclusively in the experience plane, every dashboard becomes a private epistemology. If policy exists only in the data plane as permissions on tables, purpose limitation and semantic constraints disappear. If the control plane is absent, operations depend on tacit knowledge.

Formally, let $D$, $C$, and $E$ denote the three planes. A robust product path is a composition

but with explicit interfaces between them. A consumer should be replaceable without rewriting ingestion; an orchestration engine should be replaceable without redefining clinical or business concepts; storage should evolve without invalidating every application contract.

7. Platform and institution

A Data Platform is a socio-technical institution because it stabilises expectations among groups. Producers promise certain fields, clocks, and quality levels. Consumers promise to use governed definitions. Stewards arbitrate meaning. Security teams encode permitted use. Engineers provide reproducible execution. Leadership funds the shared layer even when its value appears indirectly in other products.

This institutional dimension explains why platforms fail when treated as tool deployments. Tools can be installed without establishing ownership, contribution rules, or conflict-resolution mechanisms. The result is a technologically sophisticated vacuum.

Michel Foucault’s concept of an archive—not merely a store of documents, but the rules governing what can be said and related—offers a useful analogy. A Data Platform establishes conditions under which organisational statements become computable. Which identities may be linked? Which time counts as authoritative? Which event closes a case? Which measurement is current? These are technical rules with institutional consequences.

8. Architecture against monopolisation

The platform should not become a new monopoly over every analytic or operational use. A central team that must implement every query recreates the bottleneck it was supposed to remove. The objective is governed decentralisation: centralise contracts, policy, and reusable computation; decentralise exploration and domain-specific composition.

Let $G$ be the governed core and $X_i$ domain extensions. The architecture should support

where the direct-sum notation indicates that extensions remain distinguishable and do not silently alter the core. Domain teams can innovate without fragmenting fundamental definitions.

This balance resembles constitutional design more than application design. The platform defines stable procedures and rights of composition, not every future outcome.

Conclusion

A Data Platform is not another system to use because its primary product is not an interface. It is a shared computational substrate that reduces coupling, stabilises meanings, governs evidence, and allows existing or future applications to participate in a coherent information environment.

The platform may present catalogues, notebooks, APIs, or dashboards, but none of these alone defines it. Its success is measured by the quality of the contracts it sustains, the change it contains, the questions it enables,

and the operational burden it removes from users. The paradox is that the more mature the platform becomes, the less it needs to advertise itself as a separate destination. It is present in the consistency of every answer and in the absence of many former frictions.

Foucault, M. The Archaeology of Knowledge (1969/1972). Simondon, G. On the Mode of Existence of Technical Objects (1958). Star, S. L., and Ruhleder, K. “Steps Toward an Ecology of Infrastructure” (1996). Baldwin, C. Y., and Clark, K. B. Design Rules (2000).