Most data dictionaries are documentation projects that die on delivery. Someone writes a comprehensive spreadsheet of field definitions, it gets shared once to a mailing list, and within six months it’s out of date and nobody can find it. The whole exercise consumed weeks of someone’s time and changed nothing.
The failure isn’t the format. It’s the design assumption: that a data dictionary is a document to be written and filed rather than a living system connected to the reporting layer it describes, owned by the people who use it daily.
What a Useful Data Dictionary Actually Is
A data dictionary that gets used has three properties that a documentation project usually doesn’t: it’s linked to the reports it defines, it has a defined owner for every field, and it has a process for staying current.
Linked to reports. When a business stakeholder sees “ARR” in a dashboard and has a question about whether it’s calculated pre- or post-discount, they need to get to the definition in one click. The dictionary should live as close to the reporting layer as possible: embedded in Tableau as a tooltip, linked from the dashboard header, or at minimum accessible from a well-known URL that appears on every report.
Owned by the people who use it. “Owned by the data team” is how dictionaries go stale. The data team didn’t define what “qualified opportunity” means — Sales did. Assign a business owner to every domain. That person’s job is to flag when the definition has changed or is being interpreted inconsistently.
Connected to a change process. Metric definitions change. When finance redefines how deferred revenue is recognised, the reports and the dictionary need to change simultaneously. A data dictionary without a change management process accumulates drift until it’s less reliable than no dictionary at all.
The Minimum Viable Field Definition
Every field needs at least these six properties. Fewer and the definition isn’t precise enough to prevent misinterpretation:
| Property | What it answers | Why it matters |
|---|---|---|
| Field Name | What is this called in the report/system? | Ties the definition to the artifact |
| Business Definition | What does this measure, in plain language? | The “why” the technical definition doesn’t provide |
| Technical Calculation | How is this computed? From which source fields? | Reproducibility — someone else should produce the same number |
| Source System | Where does the underlying data come from? | When a number looks wrong, you need to know where to look |
| Business Owner | Who is responsible for this definition? | Accountability for accuracy and change management |
| Last Reviewed | When was this definition last confirmed accurate? | Tells you whether to trust the definition or verify it |
The Governance Model That Actually Works
Three components: a quarterly review cycle, a change request process, and a dedicated channel for in-flight questions.
Quarterly review: Once per quarter, business owners confirm whether their definitions are still accurate. A templated email, a two-week response window, and “no change” is a valid response. The discipline of asking the question quarterly catches the metric definition that changed because of a pricing model update six months ago and nobody updated the dictionary.
Change request process: When a metric definition changes: business owner submits the change, data team validates the technical impact, reports are updated, dictionary is updated, announcement goes to the teams who use that metric. Material changes to how a metric is calculated require stakeholder sign-off before the reports change.
In-flight questions channel: Questions about metric definitions arise between quarterly reviews. A dedicated channel — monitored by the data governance lead and relevant business owners — means questions get answered quickly, and recurring questions surface candidates for better documentation. If the same question gets asked three times, the definition needs work.
The data dictionary is not a project. It’s infrastructure. You don’t complete infrastructure — you maintain it. Organisations that treat data governance as a one-time effort are always surprised when the dictionary is out of date six months later.
Where to Start When You Have Nothing
Start with the metrics that appear in executive dashboards. Those are the definitions that matter most, generate the most disagreement, and create the most organisational cost when they’re wrong. Don’t try to document everything at once. A focused dictionary of 20 fields that’s 100% accurate and connected to the reports that use them is worth more than a complete dictionary that’s 60% accurate. And before you write a single definition, decide where it will live — a dictionary in a SharePoint folder that nobody bookmarks is already a failed dictionary.