The Data Dictionary That Survives Year Two
Data dictionaries fail for lack of process, not documentation. Seven attributes a field definition needs, and a change flow worth using.
Data dictionary projects do not fail because nobody wrote the document. They fail because the document has no process behind it: fields have no owner, definition changes have no approval path, versions have no effective dates, and nothing maps the dictionary to external reporting exits. A dictionary in that state passes review, gets bypassed during build, and six months later is a file nobody opens again. The working test is three questions: who is accountable for this figure in this period’s report, who approved the last change to its formula, and can you reconstruct the definition used in a calculation three years ago. If all three answer, the dictionary is live.
Seven attributes every field definition must carry
| Attribute | Requirement | Consequence when missing |
|---|---|---|
| Business definition | One decidable sentence, no “and related”, no “in principle” | Definitions live in meeting memory and die with the person |
| Formula | Numerator, denominator, exclusions, currency, unit, rounding | Two reports each hold internally; the gap cannot be attributed |
| Source object | Which business action produces it, and in which table and field | No origin means no entry point for fixing anomalies |
| Owner | Definition owner and change approver, named by role | Nobody accountable for accuracy; errors coexist indefinitely |
| Usage scope | Which reporting exits and which metrics reference it | One edit silently changes three already-submitted external figures |
| Version and effective dates | Version number, start and end, change basis document | Historical periods cannot be recomputed under the definition then in force |
| Quality rules | Null policy, mandatory conditions, validation equations, escalation target | A missing value reads as zero, and the metric drifts quietly |
The two most commonly dropped are usage scope and version with effective dates. Dropping the first shows up in reporting season: a field referenced by three external reports, edited once, invalidates three submissions. Dropping the second shows up at an audit: the current definition is applied unconsciously to historical periods, the recomputation disagrees with what was disclosed, and nobody can say which change caused it.
What three signatures actually mean
The three parties we require are the business owner of the data, risk and compliance, and the reporting function (in state-owned and guidance-fund settings, often the group office or finance department). They sign three things, and only three:
- Single exit. Once a field is confirmed as the source of an external figure, no other department may publish a parallel definition; a genuine difference of need goes through change control, not a private spreadsheet.
- Changes follow this path. Any definition edit requires the named approver, a cited basis document and an effective date.
- Named arbiter. When two departments disagree on a value, one person decides within a stated time.
Sign those three and the dictionary has force. Ask the same three people to “confirm every field definition” and the project dies at that step: with several hundred fields, a full confirmation cycle takes months, and the business does not wait.
Tier the change flow or nobody will use it
We split changes by blast radius, which is what makes the process actually used:
- New field. Requested by the consuming team; ships once owner and source object are set, reported in a periodic summary. Low friction, so additions come through the front door.
- Definition change. Formula, exclusions or source object altered. Requires approver sign-off, an explicit choice between prospective application and retrospective recalculation, and a list of affected external exits.
- Retirement. Requires the full reference list and a retention policy. Historical data is deactivated, never physically deleted.
If definition changes face the same ceremony as new fields, the outcome is that nobody files anything. Tiering is not looser control; it concentrates control where a change would break an externally reported number.
Start with two chains, not the whole estate
The sequence we use in assessment and blueprint phases (method in digital strategy and business blueprint):
- Pick two chains: one external reporting exit, and one valuation or distribution calculation. These two punish definition errors hardest, so the benefit shows first.
- Define only the fields those chains reference — typically tens to a hundred, closable in one review.
- Assign an owner and a change approver to each field on the spot. Fields without an owner go to a queue instead of being filled in anyway.
- Complete the mapping: field to report template cell, field to metric formula, with no gaps.
- Record the first version and effective date, even if version one covers a single field.
- Hold a quarterly definition review after go-live, working through trigger counts, disputes and retirement proposals. That meeting is the dictionary.
On this order a usable first version lands in three to four weeks. Attempts to cover everything usually stop at review.
When we advise against starting a dictionary now
Three cases. The organisation has not yet listed its external reporting exits: the dictionary degrades into a naming convention, and naming conventions do not resolve definition conflicts. A single person does all data work and there is no approval mechanism: better to put three to five core metric formulas and their sources on one page confirmed by management than to maintain a dictionary nobody can change. And treating publication as the finish line: projects that mark “dictionary released” as complete expire quietly in year two because no changes are ever filed — what they needed was the quarterly review meeting, not a PDF.
The value of a data dictionary is not exhaustive field coverage. It is that a small number of critical fields can be recomputed and explained at any date and any tier. A hundred definitions that answer “who owns it, who approved the change, what was the rule three years ago” outperform two thousand unsigned specifications. The productised form of these controls sits in data governance and metrics; the sequencing in a three-tier supervision programme appears in provincial SOE supervision consolidation, and the procurement-stage questions in investment system selection.