# Governance roles The people responsible for data and what each of them decides: owners, stewards, custodians, consumers and the platform team. > [!NOTE] > > **Before reading** > > [Data products and data mesh]() ## Why it matters Most data problems are, at bottom, questions nobody is assigned to answer. Who decides what "active customer" means? Who approves access to customer emails? Who fixes the table when the numbers are wrong? Governance makes those answers explicit, so that decisions are made once, by the right person, instead of repeatedly and inconsistently by whoever is closest. ## How it works Governance assigns decision rights. The names vary between organisations; the responsibilities are stable. The data owner is accountable for a dataset or a domain. Usually a business leader, not an engineer, the owner decides what the data is for, who may use it, how sensitive it is and what quality it must have. Owners answer for the data when something goes wrong, and they approve changes that affect consumers. The data steward manages the data day to day on the owner's behalf. Stewards maintain definitions and glossary terms, review access requests, follow up on quality issues, and are the first contact for questions about meaning. In small teams the owner and steward can be one person; the responsibilities still differ. The data custodian runs the systems that hold and move the data: pipelines, storage, backups and access control. Custodians are usually engineers in a domain team or the platform team. They implement the owner's decisions but do not make them: an engineer can grant access technically, but the owner decides whether it should be granted. The platform team provides the shared tools and enforces the rules that apply to everyone: the catalog, the access model, the contract checks, naming and classification standards. In a data mesh, these shared rules are agreed together with the domains and checked automatically by the platform. Consumers use the data. They have responsibilities too: using data for the purpose it was granted for, reading the contract instead of assuming, and reporting problems rather than fixing them silently in their own copy. A governance council or working group, with owners from the main domains, decides questions that cross domains: shared definitions such as customer or revenue, classification levels, retention rules. ``` flowchart TB OW[Data owner:
decides purpose, access,
sensitivity, quality targets] ST[Data steward:
definitions, access reviews,
quality follow-up] CU[Data custodian:
pipelines, storage,
implements controls] PT[Platform team:
shared tools and rules,
automatic checks] CO[Consumers:
use as agreed,
report problems] OW -->|delegates daily work| ST OW -->|decisions to implement| CU PT -->|tools and standards| CU ST -->|answers and access| CO CO -->|issues and requests| ST ``` Roles work only when they are recorded where people look. Every published table should show its owner and steward in the business catalog (see [Catalog and lineage]()), and access requests and quality alerts should be routed to them automatically. A table without a named owner is a table nobody will fix. The RACI model is often used to write this down: for each decision, who is Responsible for doing it, who is Accountable, who must be Consulted and who is Informed. ## Key terms - Data owner: accountable for a dataset; makes decisions about its use and quality. - Data steward: manages definitions, access reviews and quality issues day to day. - Data custodian: operates the systems that store and move the data. - Platform team: provides shared tooling and enforces cross-cutting rules. - Consumer: uses data within agreed purposes and terms. - RACI: a matrix of who is Responsible, Accountable, Consulted and Informed per decision. ## Example Who does what for clean\_orders in the shop: | Decision or task | Owner: head of sales operations | Steward: orders analyst | Custodian: orders data engineer | Platform team | | --- | --- | --- | --- | --- | | Define "cancelled order" | Accountable | Responsible | Consulted | Informed | | Decide on marketing's access request | Accountable | Responsible | Informed | | | Fix a failed load | Informed | Informed | Responsible, accountable | Consulted | | Classify the email column as PII | Accountable | Responsible | Informed | Consulted (standard) | | Enforce masking of PII | Informed | | Consulted | Responsible, accountable | When marketing asks for clean\_orders, the request goes to the steward, who checks the purpose with the owner. clean\_orders is private to the orders team, so the owner declines and points marketing to fct\_daily\_sales, the published product, which the platform grants. Nobody in engineering decides alone. ## Pitfalls - Engineers as owners by default. They can run the data but cannot decide what it means or who should use it. - Owners in name only. A role nobody spends time on is worse than none, because people assume it is covered. - Roles recorded in a document nobody reads. Put them in the catalog and route requests to them. - Committees for every decision. Cross-domain questions need a council; most questions belong to one owner. - No owner for shared data, such as customers and products, that every domain uses. ## Learn more - DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition (Technics Publications, 2017), chapter 3, data governance. - Zhamak Dehghani, Data Mesh Principles and Logical Architecture: https://martinfowler.com/articles/data-mesh-principles.html ## Related [Data contracts]() · [Catalog and lineage]() · [Data quality dimensions]() · [PII and data classification]()