Data governance framework: the practical version

The reason governance stalls is almost never a missing framework. It is that the scope was never bounded, so the work has no end and no visible progress.

This is a way to bound it. Three parts: a short list of what you govern, three tiers of control matched to how much a mistake would cost, and a table of who decides what.

What to take away

Part one: bounding the scope

A concept qualifies only if it meets at least one of these three grounds:

For each candidate, name the decision, commitment, or potential harm that supports inclusion. If you cannot point to one, leave the concept off the governed list.

Run that filter over your reporting estate and you will typically get somewhere between ten and forty concepts. That is the governed list. Everything else is ungoverned by an explicit decision, which is a very different state from being ungoverned by neglect, and the difference matters when something goes wrong.

Publish the list. A concept's presence or absence on it answers most of the questions people would otherwise ask a committee.

Use a shared catalog such as Microsoft Purview for the governed records and lineage; if that is not in place, start with a controlled spreadsheet and move the same fields later. Each entry should capture the concept, qualifying ground and evidence, concept owner, approved definition, source and lineage, test, tier, decision and change log, and next review.

Part two: three tiers of control

The label on the open tier is the piece that carries the most weight. People misuse ungoverned data because nothing told them it was ungoverned, and a one-line marker on the artifact prevents more incidents than any policy.

Apply the same test at each review: Governed concepts meet at least one of the three grounds above. Managed concepts are shared and need a consistent definition, but do not meet those grounds; Open concepts are local or exploratory and should be labeled so others know not to rely on them. Promote a concept when its use or consequences meet a Governed ground, and demote it when the evidence no longer supports its tier, recording the reason. A concept whose annual review has not happened in two years should drop a tier automatically, which is uncomfortable and effective.

Part three: who decides what

Two properties make this table work. Every row has exactly one decider, and every decision has a place it is recorded. A row with two deciders is a row where nothing gets decided.

The roles, kept to three

Concept owner. Sits in the business, not in the data team, and would have to change something if the definition changed. Owns the definition and the restatement decision.

Data steward. Sits close to the systems and maintains the records: definitions written down, lineage current, tests running. DAMA International's Data Management Body of Knowledge (DAMA-DMBOK) is a named professional reference for data management roles; the formal description of a data steward covers this well, and the role is often part of somebody's week rather than a job.

Governance group. A small standing group with the authority to name owners, ratify definitions, and grant exceptions. It should meet briefly and decide something every time. Keep membership to the smallest group that covers the business areas whose concepts it governs, data stewardship or engineering, and risk or compliance where applicable. An executive sponsor appoints the standing members and resolves gaps in representation.

Larger structures exist and most organizations do not need them. The general discipline is well described in Data governance: an overview of the field, and the federal Federal Data Strategy 2021 Action Plan is a useful public example of how a large body states its principles without turning them into a program.

A twelve-month sequence that works

Quarter one: draft the governed list, publish it, and settle one contested concept end to end.

For example, suppose sales and product dashboards both use “active customer” to guide resource allocation. It qualifies because it changes a consequential decision. The business concept owner proposes a definition, such as a customer with at least one completed purchase in the reporting period; the steward records its source, lineage, and a test that excludes canceled orders; then the governance group approves the definition and records its decision.

Quarter two: settle three more, and stand up the role-based access model so that access stops consuming the group's time.

Quarter three: add quality tests to the governed concepts, one meaningful test each, and start the change notice habit.

Quarter four: run the first annual reviews, demote what has gone stale, and publish what changed.

By the end you have a small number of properly governed concepts and a working process. What you will not have is a catalog of the whole estate, and that is the correct trade.

Related reading on this site

Governance substance is in data governance, and its failures are in nine governance mistakes. The build order sits inside the six layer model.

For definition work at the governed tier's center, see writing a metric definition; for parallel tiering of published artifacts, see the three publication tiers.

Common questions

How do we choose between ten governed concepts and forty?

Take the ten that cause arguments this quarter. Forty is achievable later and unachievable as a starting point, and a list that is never completed teaches everyone that the list does not matter.

Our data team wants to own the definitions. Is that wrong?

It is wrong in the sense that it will not hold. A definition owned by the data team gets overridden the first time a business leader disagrees, because the data team cannot decide what the business means by its own concepts.

What happens when nobody in the business will take ownership?

Escalate once, with the specific concept named and the consequence stated. If it still finds no owner, drop it off the governed list and label it openly as ungoverned. That is honest and it usually produces an owner within a month.

Should the framework be documented before we start?

One page, published, and revised as you learn. A framework written in full before any concept has been settled is a prediction rather than a description, and it will be wrong in the parts that matter.