Composable Data Architectures: From Platform Modernisation to Enterprise Readiness

Platform replacement can improve scale, performance, access and automation. It does not, by itself, decide what customer, revenue or a service case means. It does not assign ownership. It does not stop a project team from copying a transformation because they cannot find, or do not trust, the last one.

Organisations can move from an on-premise warehouse to a cloud platform and carry the same problems with them: report-specific logic, weak lineage, ungoverned extracts and a semantic layer that exists more in people's heads than in the architecture. The disappointment that follows is predictable. The technology is newer. The information is still fragmented.

A platform can host reusable data capabilities. It cannot define what should be reusable, who owns it, what quality is acceptable, or how a consumer should use it. Those are architectural and operating questions. Treating them as implementation details is how modernisation programmes under-deliver.

In practice, composability means designing data capabilities as modules with known boundaries: a domain, an information asset, a shared definition, a consumption pattern, a quality expectation. The test is straightforward. Can another team use this without reconstructing it? Is the meaning clear? Is someone accountable when it changes?

Those questions sound simple. They are not, because most organisations already have pieces of the answer in implicit form. Definitions live in reports. Quality rules sit inside pipelines. Ownership depends on informal knowledge. Data products are created by projects and then left without a lifecycle. Implicit foundations are hard to scale because they cannot be found, compared or governed.

Composable architecture is the work of making those foundations explicit enough to reuse — and connected enough that changing one part does not quietly break another.

Composability is not a universal solution. Modular design introduces its own complexity. Every boundary has to be maintained. Every shared definition has to be agreed. Every reusable asset creates a dependency: if finance, service and risk all consume the same customer information, a poorly managed change can affect all three.

There is also a political cost. Reuse requires someone to own a capability on behalf of others, and others to accept that they will not build a private version. That is harder than buying a new platform. It asks teams to trade local speed for shared meaning.

Used well, the trade-off is worthwhile. Used badly, composability becomes a catalogue of unused modules, or a central model so ambitious that delivery teams work around it. The useful question is not “are we composable?” It is “which capabilities are expensive enough, and reused often enough, to justify the discipline?”

A coherent enterprise data architecture still has to separate concerns. Source systems remain systems of record. Integration patterns decide how change moves between them. Shared models reduce dependence on source-system structures. Metadata and lineage tell a consumer whether they can trust what they have found. Access patterns decide how data is used safely.

Ownership sits across those layers. Someone must be accountable for the meaning and quality of important assets. Someone must decide what is governed centrally and what can be owned closer to a domain. Without that, interoperability remains a technical hope rather than an operating fact.

None of this requires labelling every dataset a data product. It does require knowing which information the organisation cannot afford to keep rebuilding — and designing those assets so they can survive a new system, a new reporting need or a new operating model.

Enterprise data architecture is not a one-time design. Structures change. Regulations change. Teams merge. A composable approach is useful only if the architecture can evolve with those shifts without forcing every consumer to renegotiate meaning.

That is why lifecycle matters as much as publication. An asset that cannot be improved, versioned or retired will become another form of debt. An integration pattern that cannot be reused will be reinvented. A definition that cannot be challenged will quietly lose credibility.