The MetadataOps Cadence

Six recurring practices with a trigger, an owner, and an artifact each, plus the definition incident review template.

Practitioner, Team Lead

The lifecycle says what the work is. It doesn't say when.

Every operations discipline that took hold did it through habits people could name. The review before the merge, the retrospective after the incident, the number reported on the first of the month. The stages became a practice the day they acquired a calendar.

Here are six for the metadata estate. Each has a trigger, an owner, and an artifact it leaves behind, because a ritual with no artifact is a meeting.

PracticeTriggerArtifact it leaves behindDefinition reviewEvery proposed change to a business definitionAn approved diff with a named reviewerBlast-radius reviewEvery schema or pipeline change touching a governed assetA column-level impact list, published before the change shipsDefinition incident reviewEvery time two systems disagree on a number that reached a consumerA one-page review, logged against the five dimensionsReconciliation logWeeklyRunning count of incidents and hours: the reconciliation taxOperating reportMonthlyThe four operating numbers, sent to the data leaderRescore and deprecation sweepQuarterlyIndex rescore with gap list; deprecated definitions retired with a date

Per change: the definition review

Treat a definition like code. It's proposed in a lower environment, diffed against production, reviewed by someone other than the author, and promoted on purpose.

The reviewer checks three things. The binding still resolves to a real asset. The owner is still the owner. The consumers on the impact list have been told, and the ones that matter have signed off.

Forty seconds in a catalog UI becomes twenty minutes in a review. That's the price of being able to answer "what changed" a year later, and it's cheaper than the week it replaces.

Per schema change: the blast-radius review

Impact analysis run after a change is forensics. Run before, it's a review step that gates the change.

Publish the affected consumers at column level and let their owners object. The number you're looking for is three. The number table-level tooling hands you is forty, which is why teams learned to route around it.

Per incident: the definition incident review

Most estates have never run this one, and it changes behavior more than the other five.

When an agent, a report, or an executive surfaces two values for one metric, that's an incident. Hold a short review with the owners of both consumers, on the blameless model software teams use. The question is which dimension failed, and the answer is a system, a binding, or a missing owner. The template is below.

Run this for a quarter and the estate's failure pattern becomes visible. Most organizations find the same two dimensions behind most incidents, which is a roadmap that wrote itself.

Weekly: the reconciliation log

You're already the person who gets pinged when numbers disagree. Keep answering. Log each one against the dimension that caused it and the hours it cost.

Six weeks of that log converts a nuisance everyone tolerates into a pattern with a price on it, and it feeds the reconciliation tax number directly.

Monthly: the operating report

Four numbers to the data leader: definition-change lead time, definition-change failure rate, the reconciliation tax, and time to evidence. They're defined in the operating model, and none of them needs a briefing to read.

The index says where the estate stands. These say whether the practice is running. Send both, and send them on the same day each month so the direction is visible.

Quarterly: the rescore and the deprecation sweep

Rescore the same three metrics against the index, with the day-one baseline beside it.

Then retire every deprecated definition older than a quarter: give it a retirement date, remove it from any consumer still reading it, and record who signed off. Deprecated definitions with no retirement date are how an estate ends up with a fourth version of revenue.

Template: the definition incident review

One page. Fill every line, including the ones that feel obvious.

  1. The metric, and the values observed. Each value, the system that produced it, and the date.
  2. The definition each consumer resolved to. Bound asset, version, and owner, or the word "none" where that's the honest answer.
  3. The dimension that failed. Coverage, resolution, derivation, freshness, or governance state.
  4. The stage that failed. Harvest, Model, Version, Compile, or Verify.
  5. Root cause in one sentence. If it takes two, there are two incidents.
  6. The fix, its owner, and its date.
  7. Estate fix or consumer fix. An estate fix changes the governed definition and every consumer inherits it. A consumer fix patches one system and goes on the roadmap as debt.
  8. Hours spent. Into the reconciliation log.

Where to start

Six practices, and none requires a purchase. Most estates can start three of them on Monday: the log, the incident review, and the monthly report.

The other three arrive with environments and column-level impact analysis, in that order, and the log will tell you which quarter you need them by.

Written by the team at MetaKarta and released under CC BY 4.0: free to use, adapt, and republish with attribution.