Data Product Architecture
Published: January 12th, 2026
Published: January 12th, 2026
If you’ve ever worked with a modern data platform that should have delivered value but didn’t, the problem probably wasn’t the technology.
A great data platform can’t compensate for poor data products. If the products don’t deliver business value, the technology is largely irrelevant. A clear data product architecture is what turns data into something the business can actually use - and only then does it make sense to design the platform and data fabric in order to support it.
One thing we have to accept early is that there is no single “right” data product for a business concept - and there never will be. Just as banking products are built from the same underlying constructs but tailored to different customer needs, data products should be built from the same trusted data foundations, shaped to meet specific business use cases.
The real challenge isn’t creating reusable data products. It is creating use‑case‑specific data products that all draw from the same truth - without each one re‑implementing history, logic or governance. That is where a well‑designed Information System Layer, as per below, becomes critical.
From a data perspective, no single physical data model can satisfy every use case. Different application data model types exist for a reason - each is optimised for specific behaviours, access patterns and performance needs. The key requirement is that, regardless of how a data product is structured, it draws from the same underlying data. Structure can vary; truth cannot.
To make this work at scale, the Information System Layer must clearly separate three concerns:
raw data capture
enterprise truth
use‑case delivery
- without duplicating effort.
This is where a modelling approach such as Data Vault plays an important role. It provides a temporal, immutable source of truth from which many different data products can be created. With history safely preserved in the Data Vault, data products no longer need to maintain their own complex history. They retain only what their use case requires, knowing they can always be accurately recreated for any point in time.
The shift this enables is subtle but powerful. Data products become lightweight, disposable, and easy to evolve - rather than long‑lived assets burdened with trying to serve too many use cases and gradually becoming fragile and expensive to maintain.
Let's now look at components in a bit more detail to better understand how this works
This is implemented using the Medallion Architecture, but the key is not the labels - it is what each zone is responsible for:
The Bronze Zone is the landing area for raw, untransformed application data before it is loaded into the Data Vault.
Its role is intentionally narrow:
capture data safely
preserve it exactly as it arrived
enable replay or reprocessing when needed
The Silver Zone is where data becomes enterprise truth.
This is where the Data Vault sits - a temporal, immutable Enterprise Data Warehouse that separates how data is produced from how the business understands it.
Data Vault does this using a simple, modular structure:
Data Vault Spine - defines business keys (Hubs) and relationships (Links) shared by the Raw and Business Vaults
Raw Vault - records temporal context (Satellites) for each source system
Business Vault - applies business rules to create curated, business-aligned temporal context (Satellites)
The Business Vault reflects enterprise meaning rather than application‑specific design. This keeps it closely aligned to the Business Concept Model and Enterprise Data Model and, with the right patterns, allows Hubs, Links and Satellites to be derived directly from them.
Data Vault allows the model to evolve while preserving full history and lineage - even when upstream data is imperfect. That imperfection is expected. No organisation has perfect source systems, and waiting for “perfect” data before ingestion only slows progress. Data quality should ideally be fixed at source, with improvements naturally flowing downstream.
It’s also important to be clear about what the Silver Zone is not.
It is not a consumption layer. It is not optimised for analytics, dashboards nor is it a data product - and it is rarely queried directly. Instead, Gold Zone data products are built from the Business Vault, which provides the most stable, business‑oriented view of data.
This design significantly reduces the impact of system change. When source applications are replaced, data products remain stable because they depend on enterprise truth - not system‑specific structures.
And because the implemented Data Vault model is bi‑temporal and immutable, data products can always be recreated accurately for any point in time, without maintaining their own complex history.
The Gold Zone is where data finally turns into business value.
Data products are built using the application data model type best suited to the use case - relational, dimensional, wide‑table, graph, time‑series or others.
Each data product:
aligns to a specific business domain or value stream
uses business‑friendly semantics
is optimised for its intended consumption pattern
Because full history is preserved in the Silver Zone, Gold Zone products retain only the history they actually need. This leads to lower storage costs, better performance, and simpler products that are easier to rebuild and evolve.
Data products are shared only when a single product genuinely serves multiple use cases - not as a compromise that satisfies none.
This architecture splits the responsibility into 3 distinct areas, each with their own set of responsibilities, that must work together to ensure success. They are described in more detail below:
The Data Vault is organised into domain‑aligned subsets, each owned by a data domain owner who is accountable for both structure and meaning.
Domain owners are accountable for:
defining domain Hubs, Links, and Business Vault Satellites
agreeing business rules and reference data
ensuring end‑to‑end lineage exists for downstream consumers
guaranteeing data remains bi‑temporal and immutable
Where data spans multiple domains, domain data architects collaborate to model the required Links and Satellites.
This operating model balances strong enterprise governance with domain autonomy - preserving consistency without creating a central bottleneck.
Producers are the teams that build and operate source systems - and they are the experts in the data those systems create. That makes them best placed to publish data into the Data Vault.
Producer teams work closely with data domain owners to understand which Hubs, Links and Satellites their data populates. They are responsible for loading Raw Vault Satellites, capturing data values exactly as they were produced. Where a producer is the sole source for records in a Business Vault Satellite, the domain owner may authorise them to load it directly.
When new attributes appear, they are loaded immediately into the Raw Vault so nothing is lost. Producers work with the domain owner so those changes are then reflected in the Business Vault.
Producers are accountable for:
publishing immutable data
correcting errors using bi‑temporal records, not overwrites
completing lineage for the data they load
Depending on the ingestion pattern, the Bronze Zone - and in some cases even the Raw Vault - may be bypassed, for example when consuming pre‑curated event data.
Consumers are experts in how data is used - not necessarily in how it is created.
In this architecture, they don’t need deep knowledge of source systems. All consumption happens from the Business Vault, where data is already cleansed, conformed and curated.
Consumers focus on:
creating data products aligned to business outcomes
choosing the right type of application data model for each use case
delivering insights quickly
Consumers are billed for the compute and storage they use, encouraging them to retain only the history their use cases genuinely require.
They are accountable for being able to recreate their data products at any point in time, relying on the immutable, bi‑temporal Data Vault as the source of truth.
The result is a portfolio of data products that are lightweight, disposable and able to scale with demand.
The Information System Layer and its data products rely on the hosting and tooling provided by the Technology Layer.
Platform choices should follow the needs of the Information System Layer - how data is modelled, governed, ingested, transformed, and published. Too often, technologies are selected before there is a clear understanding of how data will actually be published and consumed.
Get the high-level architectural design of the Information System Layer right first, and technology choices become far clearer - and far more effective.
The detailed platform design is a specialist topic in its own right, and the responsibility of a Data Platform Architect, but at a high level the Technology Layer provides:
Infrastructure and tools for tenants to manage, process, store, govern and deliver data products
Tooling that provides unified data management capabilities across distributed data platforms, simplifying access and control for users
A good data product architecture isn’t about choosing the perfect platform or enforcing a single data model. It is about creating the conditions where many different data products can exist - all drawing from the same source of truth.
By clearly separating raw capture, enterprise meaning and use‑case delivery, teams can move quickly without breaking consistency and evolve without rewriting history.
The result is a data ecosystem where data products are easy to build, safe to change and simple to retire - and where trust is established once, not rebuilt for every new use case.