Data Governance Operating Model Template (Data Mesh)

Data Governance Operating Model: [Organisation name]

Operating model for governing data across an organisation that runs, or is moving towards, domain-owned data products: the principles, the domain map and ownership, the roles (data owner, data steward, data product owner, platform team, governance council), decision rights as a RACI matrix, federated computational governance with policies written as code, the standards register that links each data standard, the metrics that show whether governance works, and a maturity roadmap. The vocabulary is compatible with the Data Governance knowledge area of DAMA-DMBOK (2nd Edition Revised) and with the four data mesh principles described by Zhamak Dehghani, both cited by name only. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

• 1. Purpose, scope and context
• 2. Principles
• 3. Domain map and ownership
• 4. Roles and responsibilities
• 5. Decision rights (RACI)
• 6. Federated computational governance
• 7. Standards register
• 8. Governance forums and processes
• 9. Metrics
• 10. Maturity assessment and roadmap
• 11. Risks and dependencies
• 12. Glossary and references
• Standard and licence note

1. Purpose, scope and context

1.1 Purpose

[State the business outcomes the model serves, in two to four sentences.]

Example: Corvid Commerce has grown from one central analytics team to six product domains that publish their own data. Definitions of an order and of net revenue now differ between finance and marketing reports, access requests take three weeks, and nobody can say which datasets contain personal data. This operating model assigns ownership to domains, sets a small number of organisation-wide standards enforced by the platform, and gives the governance council clear decision rights.

1.2 Scope

1.3 Current state summary

Summarise the starting point in a few lines and link the full assessment in section 10. Name the top three problems the model must fix, in business terms.

2. Principles

The first four principles reflect the four data mesh principles named by Zhamak Dehghani (martinfowler.com, 2020): domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance. The others are organisation-specific. Adapt the wording; keep the structure of statement, rationale and implication.

3. Domain map and ownership

3.1 Domain map

The diagram shows the business domains, their main data products and the dependencies between them. Arrows point from the provider to the consumer: Orders reads Products and FX rates and serves Checkout and Revenue reporting; the dotted line shows that Orders carries only the pseudonymous customer key issued by the Customer domain, not customer master data. The platform provides shared capabilities to every domain but owns no business data.

3.2 Domain register

3.3 Ownership rules

• Every dataset that is shared outside its producing team belongs to exactly one domain and has a named domain data owner.
• Master and reference data shared across domains (customers, products, currencies) has one owning domain; the design follows Master Data Management Design (architecture/master-data-management-design).
• When a dataset has no obvious owner, the governance council assigns one within 30 days (Example); until then it may not be published as a data product.
• Ownership changes are recorded in the domain register and in each affected Data Product Specification (data/data-product-specification).

4. Roles and responsibilities

Record named holders in a separate roster, linked here, so that people changes do not require a new version of the model. Link each domain team's Team API (architecture/team-api) for how to contact them.

5. Decision rights (RACI)

R = Responsible (does the work), A = Accountable (decides, one per row), C = Consulted, I = Informed. Columns: Spon = executive sponsor, CDO = chief data officer, Cncl = governance council, DOwn = domain data owner, Stew = data steward, Prod = data product owner, Plat = platform team, Priv = data protection officer (DPO), Sec = information security, Cons = consumers.

Check the matrix row by row: each row has exactly one A, at least one R, and no role is consulted on so many decisions that it becomes a bottleneck. Where personal data is involved, the DPO gives advice; accountability for the processing stays with the business owner.

6. Federated computational governance

6.1 Global versus local

Federated governance divides rules into a small global set, agreed by the council and enforced by the platform for every domain, and a local set that each domain decides. Use the test below to place a rule.

6.2 Policy register

Each global policy has a human-readable statement, an automated check and an enforcement point. Keep the code in a version-controlled policy repository and reference it here by identifier.

6.3 Example policy definition

The format below is illustrative, for an organisation's own policy repository; adapt it to the policy engine your platform uses.

id: POL-003
title: Every column has a classification
version: 1.2.0
owner: governance-lead
scope:
  artefact: odcs-contract
  paths: ["contracts/**/*.yaml"]
rule:
  for_each: schema[].properties[]
  require: classification in [public, internal, confidential, restricted]
severity: blocking
exception_process: DR-011
references:
  - data/data-classification-policy

6.4 Enforcement flow

The sequence shows where global policies run for a typical change: in the pull request, at publication to the catalogue, and at query time in the warehouse.

6.5 Exceptions

Exceptions follow DR-011. Each exception names the policy, the scope, the compensating control, the risk owner and an expiry date no longer than 12 months (Example). Expired exceptions fail the check again automatically. Report open exceptions to the council every month.

7. Standards register

8. Governance forums and processes

8.1 Forums

8.2 Core processes

Keep a decision register with an ID, date, decision, rationale, decision right used and review date for each council decision.

9. Metrics

Governance metrics use the GOVM- prefix so they are never confused with business metrics, which carry MET-<AREA>-NNN IDs in a Metric Definition (data/metric-definition). Baselines and targets above are illustrative. Measure the baseline before agreeing a target, and keep survey and usage measurement aggregate and free of personal identifiers.

10. Maturity assessment and roadmap

10.1 Maturity scale

This scale is generic and original to this template; it is not a certified maturity model.

10.2 Assessment

10.3 Roadmap

11. Risks and dependencies

12. Glossary and references

12.1 Glossary

12.2 References

Standard and licence note

Structure aligned with the data governance concepts named in DAMA-DMBOK (2nd Edition Revised, 2024) and with the four data mesh principles as named by Zhamak Dehghani (martinfowler.com, 2020, and the O'Reilly book, 2022). These works are copyrighted and are cited by name only; no text, figure, table or framework content from them is reproduced. ISO/IEC 38505-1 is named only; check its current edition at iso.org. The Bitol ODPS and ODCS specifications are Apache-2.0 and referenced by name and URL. The maturity scale, RACI, policies and examples are original, and Corvid Commerce is fictional. This template is original text written for this collection. Check the current official versions of the works cited before use. Template licence: MIT.