What data products are, how to build them, governance, composability
Data as a product is not a tool you buy. It is a shift in how you treat data: as something with an owner, a contract, consumers, and a promise, rather than a byproduct of some other system. Here is what the principle actually asks of you, and why it is suddenly urgent.
Data mesh and data fabric answer the same problem from opposite directions: mesh reorganises people and ownership, fabric automates the technical integration layer. Here is how they compare and why most real architectures borrow from both.
A data contract is a formal, versioned agreement between a data producer and its consumers about a dataset''s schema, meaning, quality and service levels. It is enforced automatically so upstream changes cannot quietly break everyone downstream.
Data mesh is a decentralised operating model where business domains own their data and publish it as products for the rest of the organisation. This guide explains the four principles, the problem it solves, and who it genuinely suits.
A data product is a governed, owned, API-served unit of data built for reuse. Here is what separates a real data product from a warehouse, a dashboard, or a pile of ETL output.
Data lineage is the traceable map of where a figure came from, how it moved and transformed, and everywhere it is used. It is what lets you answer "what will this change break" and "where did this number come from" with confidence.
A data product owner is one named, accountable person responsible for a data product''s quality, availability, contract, and roadmap. This guide explains the role, how it differs from stewards and engineers, and the failure modes to avoid.
Data product governance is the set of controls that make a data product safe to consume: approvals, field-level access, lineage, and an audit log on every read and change.
Governed data products. Enterprise search as a byproduct. No six-month implementation.