Data governance: the unglamorous part that matters most

Data governance rarely gets budget attention until it's the reason a dashboard shows two different revenue numbers to two different executives — at which point it becomes urgent.

What breaks without it, specifically

The failure mode isn't dramatic — it's a slow accumulation of small inconsistencies that eventually erode trust in data entirely. Different teams calculating "active customer" slightly differently. A metric that changed definition eighteen months ago with no record of when or why, so historical comparisons are quietly comparing two different things. Nobody quite sure which of three tables is the current source of truth for customer records. None of these are catastrophic on their own; together, they mean people stop trusting the data and fall back to gut instinct or, worse, their own private spreadsheet with its own private definitions.

The three pieces of governance that actually prevent this

A data dictionary — a single documented source defining every key metric and dimension, with the actual calculation logic, not just a vague description, so "active customer" has one tested, referenced definition rather than three implicit ones scattered across different teams' queries. Ownership assignment — every key dataset and metric has a named owner responsible for its accuracy and any changes to its definition, so changes go through someone accountable rather than happening silently in whoever's query touched it last. Change tracking — when a metric's definition or calculation changes, that change is documented and versioned, so historical reports can be understood in the context of which definition was in effect at the time.

How this gets implemented technically, not just as policy

We build the data dictionary as living documentation directly tied to the transformation layer (typically dbt, where metric definitions live as tested, version-controlled code rather than a separate Word document that drifts out of sync with reality). This means the documentation and the actual calculation logic are the same artifact — they can't drift apart the way a policy document and the actual implemented code often do over time.

A concrete example

A SaaS client had three different reported figures for "monthly active users" circulating across different teams' dashboards — product used one definition, marketing another, and finance a third, none of them documented, each team unaware the others differed. This surfaced during a board meeting when two slides in the same deck showed different MAU numbers, which was, understandably, an uncomfortable moment. We ran a governance engagement establishing one tested definition, in dbt, with clear ownership assigned to the analytics team, and migrated all three teams' dashboards to reference the single source. We also implemented a lightweight change-request process — any proposed change to a core metric definition requires the owning team's sign-off and gets logged with a date and rationale, so future discrepancies are traceable rather than a repeat mystery.

Where teams get stuck

Governance work often gets deprioritized because it doesn't produce a visible new feature — it's invisible when working correctly. We frame it to clients not as a compliance exercise but as the thing that determines whether every other data investment (dashboards, ML models, automated reporting) can actually be trusted.

How Ndakum approaches it

Governance is a foundational piece of our Data Engineering & AI work — we build metric definitions as tested code in your transformation layer, not as a separate document that drifts out of date.