All writing

Running a data team

Governance without a governance programme

Most of what a governance initiative is meant to produce can be derived rather than documented — and derived facts do not go stale.

1 minute read

Data governance usually arrives as a programme: a council, a glossary, a stewardship model, and a documentation effort. The artefacts are real on the day they are finished and decay from the following week, because they are maintained by people whose actual job is something else.

The things a programme is trying to establish

  • What data exists and where it came from.
  • Who uses it and who depends on it.
  • Whether it is correct, and how anybody would know.
  • What may be done with it, and by whom.
  • What changed, when, and on whose authority.

Four of those five are derivable. Existence and provenance come from the catalogue and lineage. Usage and dependency come from access history and the transformation graph. Correctness comes from tests and their results, plus drift. Change comes from version control and an audit log. All four are computed from systems already running, and none of them needs a meeting to stay current.

The fifth one is the actual work

What may be done with this data, and by whom, is a policy decision. It cannot be derived, it requires people with authority, and it is the part most governance programmes spend the least time on because the other four consume the budget. Automating the derivable four is not a substitute for governance — it is what makes the fifth affordable.

Document only what cannot be computed. Everything else should answer for itself.

Run this against your own estate

Gecko reads metadata and query history — never the rows in your tables — and tells you what it found.

Get started