Data governance

What it is about

Data governance defines who owns, maintains and may use which data. The purpose is not order for its own sake but dependability. Every report, every model and every automation rests on data, and if its origin, definition and ownership are unclear, the result cannot be verified.

The most common trigger for the topic is an argument about numbers. Two reports show different revenue and nobody can explain why. The cause is rarely an error but almost always two calculations using the same term differently.

The four rule areas

• Ownership: Every data source has a named responsible person, not a department. Without that mapping nothing gets maintained.
• Definition: Metrics are fixed once, with formula, period and base, and documented in one place.
• Quality: Which fields must be filled, which checks run and who is informed about deviations.
• Access: Who may read and write, with what justification and with what logging.

What is recorded per dataset

A register does not have to be complete to be useful. Six entries suffice in most cases: where the data comes from, what it is used for, who is responsible, how long it is stored, who may access it and to whom it is passed on.

The value of this register shows in three situations. With a complaint, because it is quickly clear which data is affected. With a system replacement, because it is known what must be migrated. And when creating a new report, because the definition already exists instead of being reinvented.

Why it fails without owners

Experience from many efforts is unambiguous: rulebooks without a named owner age within months. Distributing responsibility across a department is practically the same as no responsibility, because every department assumes another is looking after it.

The second reason for failure is scope. A programme with a hundred rules will not be implemented. What works are a few rules that are actually enforced, such as mandatory fields in the system, a check before publication and a fixed metric list. Anything beyond that is documentation without effect.

A third point concerns change. Data models change because systems are replaced, fields renamed and processes adjusted. Without a fixed reason to review, for instance once a quarter, the register is wrong after a year and therefore worse than none, because it creates trust it does not deserve. Anyone introducing data governance should start small but set the maintenance rhythm from the beginning, because that rhythm decides the benefit, not the first version of the rules.