Data governance gives business meaning an accountable owner

Finance and sales bring different active-customer totals to the same meeting. Both reports may be technically correct. One counts invoiced customers; the other counts accounts in an active commercial relationship. The disagreement becomes a governance problem when the label hides the distinction and nobody can decide which measure the meeting needs.

For a data leader, governance is the work of making those decisions explicit and sustainable. Ownership, quality and access matter because someone relies on the data to act. A catalogue can support that work, but it cannot supply the business judgment behind it.

Tool coverage and business authority are separate questions

Microsoft Purview’s source matrix lists metadata, classification, policy and lineage capabilities separately, with availability varying by source. That illustrates a practical buying issue: connecting a source does not imply every governance capability is available for it.

Even where the technical capability exists, somebody must decide what a field means and which uses are appropriate. A lineage view can help explain where a number came from; it cannot decide whether that number answers the commercial question. Treat those as complementary capabilities rather than substitutes.

When evaluating a tool, choose a real disagreement or change request and follow it through the proposed workflow. The interesting result is whether the right owner can settle the issue and whether consumers can find the answer afterwards.

Governance needs to accommodate legitimate difference

Standardisation is useful when teams need to compare the same thing. It becomes counterproductive when it erases distinctions their work genuinely requires. An account can be commercially active while having no invoice in a particular period; forcing one label may simply move the ambiguity into private spreadsheets.

Give different measures precise names and retain the rule behind each. Where a common executive measure is needed, agree it explicitly and show how it is derived. That creates a shared language without pretending every team has the same operational purpose.

Treat ownership as decision authority

The UK Government’s data ownership model distinguishes accountability for data from its day-to-day stewardship and technical custody. It is government guidance, not a private-sector legal obligation, but that separation offers a useful way to examine enterprise responsibilities.

For an enterprise team, the practical question is who can settle a dispute about meaning, permitted use or acceptable quality. A database administrator may keep the service available without having authority to define what counts as an active customer. A business owner may define the term without knowing how a pipeline transforms the records.

Choose a dataset with a real consequence

Start with data that supports an important decision or workflow. It might drive invoices, inventory replenishment or eligibility for a service. Name the people who rely on it and describe what happens if it is late, incomplete or wrong. That gives the governance work a clear purpose.

Do not begin by trying to catalogue every field across the organisation. Establish a repeatable method on one important dataset, then expand it. The first exercise should expose the questions the organisation struggles to answer, not produce a long inventory of unanswered questions.

Test what happens when a definition changes

Return to the active-customer example. If finance changes the invoice window from twelve months to six, the headline total may fall even though no customer relationship has changed. Consumers need to distinguish a commercial movement from a change in measurement.

The owner should agree when the new rule takes effect, which reports need updating and whether historical figures will be recalculated. That decision connects business meaning to the pipelines and reports that implement it. A glossary entry alone would leave the change unfinished.

Make quality checks actionable

A quality rule needs an owner and a response. “Customer data must be complete” provides little direction. A more useful internal rule identifies which fields must be present for a specific process, where the check runs and what happens when it fails. Thresholds should reflect that process rather than a generic percentage target.

Also distinguish a broken pipeline from an unsuitable dataset. A perfectly functioning pipeline can deliver data that is too old or too loosely defined for a new AI use case. Technical success does not establish fitness for every downstream purpose.

Keep exceptions visible. If a team accepts incomplete data temporarily, record the affected use, the person accepting the limitation and the review trigger. Otherwise a temporary compromise can become an undocumented dependency.

Buy tools against the work they must support

Once ownership and workflow are understood, evaluate whether a catalogue, lineage capability or quality platform makes the work easier. Ask teams to find a definition, identify a downstream consumer and route an issue using representative data. Judge the result by the task completed, not by the number of metadata fields available.

Plan how the information will stay current. If every entry depends on a busy specialist remembering to update it, the operating cost and failure risk belong in the buying decision.

The conflicting-dashboard guide works through that semantic problem, while the data catalogue evaluation turns it into a buying test. Start where a data decision changes an outcome, then scale the method the organisation can actually maintain.