Rules
Part of Data governance as answers, not a program: ownership, definitions and access
Data governance mistakes: who owns the number and who can decide
Data governance mistakes around ownership and decision rights: councils that cannot decide, owners assigned to systems, unowned reference data and lost history.
Governance work fails in public and slowly. A program is announced, a committee meets, documents accumulate, and two years later the same two numbers still disagree in the same meeting.
The mistakes below share one cause: nobody with authority owns the contested number. Each section names what goes missing and the decision that fixes it.
What to take away
- Governance produces an agreement only when a named owner defends the definition and a named group can decide.
- Assign ownership to the concept, in the part of the business that would have to change its behavior if the definition changed.
- A group that cannot decide is a forum. Give it decision rights, or call it a forum.
- Settle one contested number first, write the policy afterwards, and scope any catalog to the concepts the business argues about.
- Measure the disputes that stopped, not the documents produced.
Decision rights at a glance
Seven decisions recur in governance work, and each one needs a person rather than a document. The table lists who should make each decision and what the work produces when nobody does.
| Decision | Who makes it | Without one |
|---|---|---|
| Which definition of a contested number wins | A named owner in the business | The same two numbers disagree in the same meeting |
| What the council may decide | Set when the council is formed | Meetings end in action items |
| Who owns a concept | The part of the business that would change behavior | Ownership defaults to whoever runs the database |
| Whether history is restated | The definition's owner, before the change lands | Whoever writes the query decides |
| Who maintains a reference table | A named owner with a change log | A file with one maintainer and no history |
| Who gets access | A role model reviewed on a calendar | Tickets consume the whole function |
| Whether any of it worked | Disputes that stopped | Output counts climb regardless |
Settle one number before writing any policy
A policy document is the natural first deliverable, and it commits nobody to anything. DAMA International's DAMA-DMBOK is the reference book for data management practice, and an EDM Council DCAM assessment scores capability without settling which revenue figure is correct. Neither resolves a dispute, and the disputes continue.
Settle the number first
- Take the most argued-about number
- Name a single owner
- Write the definition
- Switch everything to it
- Write the policy afterwards
Take the number that causes the most arguments, name an owner, write the definition, and switch everything to it. Put it where queries read it: a dbt metric, a Looker LookML measure, or a Cube model. Then write the policy afterwards, describing what you did. It will be shorter and it will be true.
Scope the catalog to what people argue about
Inventorying the whole estate feels like the responsible start. Collibra, Alation, Atlan and Informatica will ingest tens of thousands of tables, and Apache Atlas, LinkedIn DataHub and Lyft's Amundsen cost only engineering time. Most entries describe tables nobody queries, owned by nobody.
Catalog everything vs catalog the disputes
Catalog everything
- Scope
- Every table
- Size
- Thousands of entries
- Maintenance
- Nobody
- Trust
- Stale on day one
Catalog the short list
- Scope
- Argued concepts
- Size
- A short list
- Maintenance
- Owner per concept
- Trust
- Relied on
Catalog the short list of concepts the business argues about, and leave the rest undocumented until somebody needs it. Twenty or thirty entries with named owners beat ten thousand without.
Entries go stale from the day they publish, and a catalog nobody trusts is worse than no catalog, because it invites people to rely on stale entries. The sponsor-side version of this error is in business intelligence mistakes.
Give the council decision rights
A cross-functional group meets monthly, reviews issues, and escalates. Nothing is decided, because deciding would mean one department losing its version of a number. ISO/IEC 38500, the governance-of-IT standard, expects a governing body to evaluate, direct and monitor, and to hold the authority for all three.
Council or forum?
Can the group name an owner and ratify a definition?
It is a council; every meeting ends in a decision
It is a forum; call it one
The fix is to give the group the power to name an owner and to ratify a definition, and to make the outcome of every meeting a decision rather than an action item. If it cannot decide, it is a forum, and it should be called one.
If a council has met for a year and decided nothing, change the agenda to one contested number per meeting, with the requirement that the meeting ends with an owner named. If that still produces nothing, the group lacks authority and the fix is above it.
Own the concept, not the system
Ownership gets assigned to whoever runs the database. That person can tell you what the field contains and cannot tell you what it means or whether it should change. DAMA-DMBOK separates the data owner, the system owner and the data steward for this reason.
Assign ownership to the concept, in the part of the business that would have to change its behavior if the definition changed. A revenue definition belongs to finance, not to the warehouse team. The system owner is a separate and also necessary role.
For a dataset you inherit with no owner on record, the inherited dataset questions are a practical place to start.
Own the roles, not the tickets
Approving access requests is visible, constant, and satisfying, and it consumes the entire capacity of a small governance function. Access matters, but the rule is simple enough to automate: default closed, granted by role, reviewed on a schedule.
Default closed is the principle of least privilege: a system should restrict the access privileges of users to the minimum necessary to accomplish assigned tasks.
Once the roles exist it should require almost no meetings. NIST SP 800-53 carries least privilege as control AC-6, and the NIST role-based access control project records that the NIST model for RBAC was adopted as American National Standard 359-2004 and later revised as INCITS 359-2012.
Turn access into a role model and a review calendar, then spend the freed time on definitions. Snowflake, BigQuery and AWS IAM all grant by role, and Okta and SailPoint run the review cycle.
Decide what happens to history
A definition is corrected. Somebody has to decide whether prior periods are restated or the change applies forward only, and that decision is usually made by whoever writes the query.
The pattern of handling this well is old and well described. Ralph Kimball's The Data Warehouse Toolkit sets out slowly changing dimensions as Type 1, which overwrites the old value, and Type 2, which adds a dated row. dbt snapshots implement type-2 slowly changing dimensions over mutable source tables.
A written definition and a change log are the same discipline that analytics foundations metrics describes for rates, averages and cohorts.
Decide explicitly, announce before the change lands, annotate the charts on the date, and keep the prior figure recoverable.
Give reference data an owner
Customer hierarchies, product groupings, region mappings: the small tables everything joins to. They live in a file, maintained by one person, with no history and no review. Handling them properly is what master data management means, and most organizations need a very small amount of it rather than a program.
Informatica MDM, Reltio, Stibo Systems and SAP Master Data Governance sell the full version, with matching rules, survivorship and a change history.
Move the two or three that matter into a versioned, owned place with a change log, and leave the rest alone.
Measure the disputes that stopped
Policies written, entries cataloged, issues logged. All countable, all easy to increase, none connected to whether anything got better. A DCAM score or a catalog coverage percentage climbs whether or not the revenue number stops disagreeing.
Measure the disputes that stopped: concepts with a single agreed definition in use everywhere, and the count of numbers still calculated two ways. DataHub, Alation and the dbt lineage graph will show whether old dashboards still read the retired field. Those numbers are hard to move and hard to fake.
Which to fix first
If the function is new, settle one contested number and do nothing else for a quarter. One number, settled properly, with an owner and a written definition and every downstream use switched over, buys more credibility than any document.
If the function already exists and is stalled, look at the council. A group that cannot decide is the usual reason a governance effort produces artifacts instead of agreements. The fuller account of what governance consists of is in data governance as answers.
Common questions
Leadership has asked for a governance policy. Can we refuse?
Write a short one, then spend the quarter settling a number and use it as the worked example. You get the document and something real, and the document is better for having a case behind it.
How small can a governance function be?
One person part time can run a short list of concepts, a role-based access model, and a review calendar. What one person cannot do is catalog an estate, which is a good reason not to try.
Who decides when two departments both insist their definition is correct?
Someone senior to both, once, in a documented decision. Governance cannot resolve a disagreement about whose calculation wins; it can only make sure the question reaches a person who can.
