Data Mesh Design Template

Data Mesh Design: [Organisation or data estate]

Architecture design for a data mesh: the decision that a mesh fits, the domains that own data, the data products they publish, the self-serve data platform that makes publishing cheap, the federated computational governance that keeps products interoperable, the interoperability standards, the logical architecture, the operating model, metrics and the adoption roadmap. The structure follows the four data mesh principles named by Zhamak Dehghani (martinfowler.com, 2020), cited by name only. Product and contract metadata use the Bitol Open Data Product Standard (ODPS) v1.1.0 and Open Data Contract Standard (ODCS) v3.2.0 through the linked templates. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose, drivers and fit
2. Current state
3. Domain-oriented ownership
4. Data as a product
5. Self-serve data platform
6. Federated computational governance
7. Interoperability standards
8. Logical architecture
9. Operating model and teams
10. Metrics and economics
11. Adoption roadmap
12. Risks and anti-patterns
13. Decisions and traceability
14. Glossary and references

1. Purpose, drivers and fit

1.1 Drivers

1.2 Fit assessment

A mesh moves data ownership to the teams that know the data. That has a cost: every domain needs data skills, and the organisation needs a platform and shared standards. Answer each question with evidence.

Example: Corvid Commerce answers yes to four questions and "partly" to domain skills. It adopts the mesh for three pilot domains and keeps a central team for the remaining three until their skills plan is funded.

1.3 Out of scope

[Operational databases, transactional integration (see architecture/integration-design), master data management (see architecture/master-data-management-design), and any area left centrally managed.]

2. Current state

Link the platform baseline to architecture/data-platform-architecture if one exists.

3. Domain-oriented ownership

The first principle moves ownership of analytical data to the business domains closest to it. Use the bounded contexts from domain-driven design where they exist (architecture/context-map, architecture/bounded-context-canvas), so operational and analytical ownership line up.

3.1 Domain map

3.2 Ownership rules

4. Data as a product

The second principle treats each published dataset as a product with consumers, a roadmap, quality promises and an owner. Dehghani's 2019 article names qualities such as discoverable, addressable, trustworthy, self-describing, interoperable and secure; the 2020 article adds understandability and explorability, and the book (2022) extends the list with natively accessible and valuable on its own. The table below uses those quality names with original acceptance tests. Specify each product in data/data-product-specification and each output port in data/data-contract.

4.1 Product qualities and acceptance tests

4.2 Product inventory

The type values follow ODPS v1.1.0 (sourceAligned, aggregate, consumerAligned). Product IDs in this document are design references; the ODPS id in each specification is the system identifier.

4.3 Product lifecycle

Every product moves through the same states. The platform records the state in the product specification (ODPS status) and the catalogue shows it to consumers.

5. Self-serve data platform

The third principle provides shared, self-service capabilities so that domain teams can build, publish and run products without specialist infrastructure work. Dehghani describes the platform in planes: the 2020 article names a data infrastructure provisioning plane, a data product developer experience plane and a data mesh supervision plane, and the book (2022) renames them the infrastructure utilisation, data product experience and mesh experience planes. This design groups capabilities by the book's plane names. Treat the platform as a product with its own roadmap (architecture/internal-developer-platform-charter, architecture/platform-golden-path).

Platform service levels:

6. Federated computational governance

The fourth principle combines a federated decision body (domain representatives, platform, security, legal and privacy) with policies that the platform enforces automatically. Membership, decision rights and the RACI belong in data/data-governance-operating-model; this section lists the policies and how each one is enforced.

6.1 Global and local policies

Global policies apply to every product and are few. A policy is global only if inconsistency between domains would break interoperability, security or legal compliance. Everything else is local.

Link retention and classification policies to data/data-retention-deletion-standard and data/data-classification-policy, and quality rules to data/data-quality-standard.

6.2 Exceptions

7. Interoperability standards

Keep the glossary of business terms in architecture/data-dictionary or the catalogue, and refer to it from contracts.

8. Logical architecture

Read the diagram as follows: each product reads its inputs through the output ports of other products (Delivery performance reads Orders and Shipments), never from another domain's internal tables. Dotted lines show platform services the product uses at publish time. Consumers read through the policy engine, which applies POL-G-02.

9. Operating model and teams

Team types follow the vocabulary of Team Topologies (Skelton and Pais), used by name only. Document each team's interfaces with architecture/team-api.

Funding: [domain budgets fund product teams; platform funded centrally; cost reporting per product from PLT-08].

10. Metrics and economics

Example arithmetic: the platform team costs EUR 960,000 a year. With 24 active products that is EUR 960,000 / 24 = EUR 40,000 per product; at the target of 40 products it falls to EUR 24,000. The 24 products are spread across domains as Sales 5, Catalogue 4, Fulfilment 5, Customer 4, Finance 3 and Marketing 3. Use the same figures in every report.

11. Adoption roadmap

12. Risks and anti-patterns

13. Decisions and traceability

13.1 Decisions

13.2 Traceability

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Structure aligned with the four data mesh principles named by Zhamak Dehghani in "Data Mesh Principles and Logical Architecture" (martinfowler.com, 3 December 2020) and her book Data Mesh (O'Reilly, 2022): domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance. The principles, quality names and platform plane names are cited by name only; no text, figures or tables from the article or the book are reproduced. Product and contract metadata refer to the Bitol Open Data Product Standard v1.1.0 and Open Data Contract Standard v3.2.0, published by the Bitol project under the Apache License 2.0. Team type names follow Team Topologies by name only. All explanatory text, tables and examples are original. Corvid Commerce is fictional. Check the current versions of each standard before use. Template licence: MIT.