Data as a product
By the end of this module you will be able to:
- Explain Dehghani's data mesh principles
- Describe data contracts and their purpose
- Evaluate when data-as-product thinking applies
Data product as producer, contract, and consumer triple
A data product is only a product where a promise is written down: the contract between producer and consumer names the schema, the freshness, the quality objectives and the support route, and without it consumers re-discover the schema and copy the data defensively.
A data product is a producer, a consumer, and a binding contract between them. The contract names schema, freshness, quality SLOs, and support. Without the contract, the data is a dump; with it, the data is a product. Bitol ODCS v3.1.0 is the published shape; data mesh frames the same model architecturally.
Three SLOs every data product must carry
Freshness bounds how old the data may be, quality bounds how much of it may fail its rules, availability bounds how slowly it may answer, and the objective nobody writes down becomes a promise with no limit under which last month's data passes for live.
A data product binds three SLOs: freshness (data is no older than X), quality (pass rate is at least Y percent), availability (read latency is under Z). Bitol ODCS v3.1.0 carries all three machine-readably; Google SRE Workbook defines the SLO discipline they implement.
Contract change as a four-step migration with overlap
A consumer migrates in its own time only when all four steps run, propose with notice, deprecate the old version, serve both through an overlap, then retire it; drop the overlap and every consumer has to re-engineer on the same day.
Contract changes follow a four-step migration: propose with notice window, deprecate old version, serve both during overlap, retire old after every consumer migrates. Bitol ODCS v3.1.0 codifies this sequence; breaking changes without the overlap window are how producer-consumer trust collapses.
Zhamak Dehghani asked: what if data teams operated like product teams?
In 2019 and 2020, Zhamak Dehghani set out data mesh as a sociotechnical pattern for scaling analytical data. The core argument was that centralised data platforms create bottlenecks because one team cannot understand every domain's data, context, and change cadence.
Data mesh is a pattern and operating lens, not a universal target architecture. It asks domain teams to own data products with documentation, quality expectations, versioning, and consumer feedback loops. The previous module covered how to structure data. This module covers how to treat it as a product without turning every dataset into a product theatre exercise.
Centralised data teams become bottlenecks at scale. What if the teams that produce data also owned it as a product, with SLAs, documentation, and quality guarantees?
Treating data as a product means applying product management principles: who are the consumers? What do they need? How do we measure satisfaction? This shift changes data teams from cost centres (infrastructure providers) to value creators (product owners delivering reliable, documented, discoverable data).
Data mesh is useful only when its four principles are treated as operating commitments.
19.1 The four principles of data mesh
Dehghani's data mesh framing has four principles. Each is an operating commitment, not a label to add to a slide:
- Domain-oriented ownership: the team closest to the business process owns the analytical data it produces. Ownership includes meaning, quality, change control, and consumer support.
- Data as a product: domain teams treat data outputs as products with consumers. A product has documentation, quality service levels, versioning, discoverability, and a route for feedback.
- Self-serve data platform: a shared platform gives domain teams safe tooling for storage, pipelines, cataloguing, access control, observability, and deployment without each team rebuilding infrastructure.
- Federated computational governance: global policies are defined centrally but enforced through code, tests, contracts, and platform controls.
“Domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance”
Zhamak Dehghani, Martin Fowler site - Data Mesh Principles and Logical Architecture
This is the clearest source-backed statement of the four mesh principles. The course treats them as a pattern to evaluate, not as a default destination for every organisation.
The four principles are easy to name and easy to claim, so the question that follows is what an organisation actually changed.
19.2 Ownership is the change, not infrastructure or headcount
The leadership test is whether accountability changed. If central data teams still fix every issue while domain teams only attend workshops, the organisation has adopted mesh vocabulary but not the operating model.
Two beliefs get in the way of that shift, one about infrastructure and one about scale.
Common misconception
“Data mesh means every team builds its own data infrastructure.”
Data mesh separates domain ownership (who is responsible for the data) from platform infrastructure (the shared technology layer). The self-serve platform principle explicitly provides shared compute, storage, and tooling. Domain teams own the content and quality; the platform team owns the infrastructure. Duplicating infrastructure across teams is the opposite of data mesh.
Common misconception
“Data mesh only works for large organisations with hundreds of engineers.”
The principles scale down. A team of 20 can apply domain ownership (the marketing analyst owns marketing data), data-as-product thinking (documented, quality-checked datasets), and shared infrastructure (a single cloud warehouse with access controls). You do not need a platform team of 50 to benefit from treating data as a product.
Product thinking becomes operational when the product promise is written as a contract.
19.3 The contract as the product specification
A data contract is the interface between a data product and its consumers. Module 13 introduced contracts conceptually. In the data-as-product context, the contract is the product specification: it defines what consumers receive and what guarantees the producer makes.
The Open Data Contract Standard provides a practical shape for this promise: fundamentals, schema, references, data quality, support, pricing, team, roles, service level, infrastructure, and custom fields. Not every organisation needs every field, but every critical data product needs enough structure to make expectations testable.
“Keys and values expected in a YAML data contract”
Open Data Contract Standard v3.1.0 - Executive Summary
The ODCS structure turns the promise of a data product into fields that can be reviewed, versioned, tested, and enforced.
Those fields only bite when a team fills them in for a dataset that several departments already read differently.
19.4 What a contract has to pin down
Worked example: a revenue data product should define what counts as revenue, which refunds or credits are excluded, the currency and rounding rules, how late-arriving orders are handled, the freshness target, the owner, and the breaking-change process. Without those details, different teams can all be "using revenue" while making incompatible decisions.
Whenever a report looks wrong, domain teams raise a ticket against the central data platform team. That team did not generate the data and cannot say what a field is meant to mean, so it guesses, and quality problems recur. Which data mesh principle most directly addresses this?
A data product has a freshness SLA of 60 minutes. Data has not been updated for 3 hours. What should happen?
A startup with 15 employees wants to adopt data mesh. A consultant says they need a dedicated platform team, domain data teams, and a governance council. Is this advice correct?
The dim_customers contract above records an owner, a freshness target and completeness thresholds, which is most of what a reviewer assessing the same dataset for AI use will ask for, though it says nothing about the licence the material was acquired under or where each row came from. Those two omissions are the gates that hold such reviews up in Data for AI foundations, which also picks the contract back up as the substitute for a feature store when one definition is computed once for training and again for live prediction.
Product checks to carry forward
- Data mesh is a sociotechnical pattern, not a universal architecture. Use it when domain ownership and platform support solve a real scaling problem.
- A data product must have consumers, an owner, documented meaning, quality expectations, service levels, versioning, and a support route.
- A data contract is the verifiable layer of the product promise. It should make schema, semantics, freshness, quality, ownership, and change policy explicit.
- Small teams can apply product thinking without creating mesh bureaucracy. The useful test is whether accountability and consumer trust improve.
Standards and sources cited in this module
Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale
Chapters 3-6
Foundational text defining the data mesh operating model.
Open Data Contract Standard v3.1.0
Definition and schema sections
Open YAML standard for defining schema, quality, role, service-level, support, and infrastructure fields in data contracts.
Full article
Original article introducing data mesh. The opening case study references this publication.
Dehghani, Z. (2020). 'Data Mesh Principles and Logical Architecture'
Core principles
Source-backed statement of the four data mesh principles used in Section 19.1.
Data Governance knowledge area
Governance principles that data mesh extends with computational enforcement.
Module 28 of 52 · Engineering and platforms