Data Architecture
Building a Modern Enterprise Data Platform
The architectural decisions that determine whether a data platform becomes a durable foundation or another silo.
6 min read
Start with the decisions, not the tooling
Most data platform programmes begin with a technology selection. In practice, the platform's long-term success is decided by a smaller set of architectural choices: how data is ingested, where the contract between producer and consumer sits, how history is preserved, and who is accountable for a dataset once it is published.
A useful discipline is to write these down as architecture decision records before procurement. They outlive the tooling and give delivery teams something concrete to design against.
A workable reference shape
Regardless of vendor, most enterprise platforms settle into the same layers: source systems, ingestion, a raw landing zone, curated and conformed layers, published data products, and consumption through BI, analytics and AI workloads.
- Ingestion: batch, CDC and event-based paths with consistent metadata capture
- Storage: open table formats to avoid re-platforming later
- Modelling: a conformed layer with defined grain, keys and business definitions
- Data products: versioned, documented, owned and monitored
- Governance: catalogue, lineage, access control and quality checks as platform services, not project add-ons
Common failure modes
Platforms typically fail for organisational rather than technical reasons: no clear ownership of published data, modelling deferred until after ingestion is complete, and governance treated as a later phase. Each of these can be addressed in architecture rather than discovered in delivery.
Working through this in your own environment?
We help organisations make these decisions with the constraints they actually have.