BACK TO ARTICLES
Practical Guides

Data Mesh as an Operating Model: Define One Usable Data Product

Data Mesh as an Operating Model: Define One Usable Data Product
Datta Sable
Datta Sable
BI & Analytics Expert

Start with a consumer need

A fictional finance team needs a daily view of fulfilled orders to reconcile revenue. Instead of announcing an enterprise-wide data mesh, define one product that can serve that need. Write who owns the source meaning, who operates the pipeline and who consumes the result. A set of separately hosted tables is not automatically a useful product or a coherent governance model.

Describe the contract

For a fulfillment table, state that each row represents one shipment line and identify the stable key. Document how partial shipments, cancellations and late updates appear. Include the reporting cutoff and the meaning of a missing row. Without these definitions, a consumer can easily treat an unshipped order as a data failure or count a split shipment twice.

Product: daily_fulfillment
Grain: one shipment line
Owner: fulfillment operations
Consumers: finance reconciliation and operations reporting
Contract: schema, key, update semantics, freshness, access and incident contact

Offer self-service with boundaries

Provide sample queries, a data dictionary and an authorized access path. Consumers should be able to discover whether the product suits a task without receiving unrestricted access to personal records. Make access requests and ownership visible. Shared conventions for identifiers, classifications and incident handling help independently maintained products work together without pretending that every domain has the same business rules.

Practice a schema change

Suppose the producer wants to rename shipped_quantity to fulfilled_quantity. Identify existing consumers before making the change, publish a migration window and define how compatibility is handled. Test a downstream reconciliation during the transition. A breaking rename is an operating event, not merely a code refactor. Keep a versioned contract and a record of which consumers have migrated.

Choose complexity deliberately

A small team with a few stable reporting needs may not benefit from introducing multiple domain platforms and governance forums. Review ownership clarity, consumer support burden and the ability to maintain common controls before expanding. The success criterion for the example is a trusted, usable fulfillment feed with a recoverable change process, not the number of domains renamed as data products.

Primary references

Technical References & Standards

Datta Sable
Author

Datta Sable

Senior BI Developer & Data Architect with over 10 years of experience in engineering high-fidelity analytics systems. Specialized in Tableau, Power BI, SQL, and Python-driven automation for enterprise-grade decision clarity.