The advice you already know is correct. Name an owner. Start small. Tie it to a business problem. Buy software that fits.
None of that is where programs die. They die in the mechanics underneath: the specific moment a catalog entry goes wrong and nobody fixes it, the meeting where two departments discover they mean different things by "customer," the invoice that arrives when your data volume triples. This piece is about those moments, because that is where a data governance implementation is actually won or lost.
The Prediction Worth Reading Carefully
Gartner predicts that by 2027, 80% of data and analytics governance initiatives will fail. It gets quoted everywhere, usually stripped of the part that matters. It is a forecast, not a measured result, and Gartner gives a specific cause: the programs fail because they lack a real or manufactured crisis to organize around.
Read that as a diagnosis. Governance set up to satisfy an audit has no crisis behind it, so it produces policy nobody enforces. Governance set up to stop a problem that is currently costing someone money gets used, because someone is watching.
The often-repeated figure that bad data costs an organization $12.9 million a year is worth treating with the same care. It is a 2020 estimate, still recited as current, with no published methodology behind the round number. Use it to set direction, not to size a budget. Your own duplicate rate and rework hours are better evidence than a five-year-old average, and gathering them is the first useful thing a program does.
The Staleness Loop That Kills Catalogs
Here is the failure I described in one line last time, shown in full, because the line hides the whole problem.
A catalog is a set of claims about your data: what a field means, where it comes from, who owns it. Those claims go out of date the moment a source system changes. A new column appears. A definition shifts. A pipeline gets rerouted. To stay true, every one of those changes has to be reflected in the catalog.
If that reflection is manual, someone has to notice the change, open the tool, and edit the entry. That work competes with everything else on their plate, and it has no deadline. So it slips. A few entries go stale. People hit a wrong entry, lose trust, and stop checking the catalog. Once they stop checking, nobody notices the next wrong entry, and the drift accelerates. By month six, the catalog describes a system that no longer exists.
A catalog does not fail all at once. It fails one unattended entry at a time, and the first wrong entry a user hits is the one that teaches them to stop trusting it.
The fix is automation: metadata harvesting, schema-change detection, entries that update themselves when the source moves. That costs money. Money needs a sponsor. And a sponsor only appears when the program is tied to a crisis someone cares about. This is why the Gartner prediction and the stale catalog are the same problem wearing two faces. No crisis, no sponsor. No sponsor, no automation. No automation, manual upkeep. Manual upkeep lapses in the first busy quarter.
So do not buy a catalog you will maintain by hand. Buy the ability to keep it current, or govern a smaller scope you can actually keep true.
When Two Departments Both Own "Customer"
This meeting decides whether governance is real, and most rollouts never plan for it.
Sales means an account, a company that buys from you, while finance means a legal entity that pays invoices, which might be a parent company covering three of Sales' accounts. Marketing means a person, a named contact who opened an email. The same word carries three definitions across three systems, and each one is correct inside the department that uses it.
The conflict surfaces the day someone builds a report across all three and the customer counts do not match. Or a deduplication run merges two records that were never the same thing, because the rule assumed one definition of "customer" and the data held three.
An owner does not resolve this by declaring a winner. The mechanism is narrower and more useful. The owner forces the definitions into writing, which alone ends half the confusion, since the three teams usually did not know they disagreed. Then the owner makes a structural call: is "customer" one concept with a type attribute, or three separate entities linked by relationships, an account that belongs to a paying entity and contains contacts? That modeling decision is the actual governance. Everything downstream, like deduplication, reporting, and access, follows from it.
Governance is not the policy document. It is having one person with the authority to end an argument that would otherwise return every quarter.
The reason to settle this before you buy software is that the answer shapes what you need the software to do. Three linked entities need a tool with a flexible relational data model. One flat concept needs far less. Buy first, and you may buy a tool that cannot represent the structure your own business runs on.
In work we have seen on product and supplier data, the same pattern shows up a level down: a "supplier" in procurement is a "vendor" in finance and a "manufacturer" on the product record, and the three were maintained in separate spreadsheets that quietly disagreed. Consolidating them onto one data model with defined relationships is less a software task than a decision about which of those three views is the source of truth. The tool only enforces the decision once it is made.
Read The Pricing Model, Not The Feature List
Feature lists converge. Pricing models are where the long-term cost hides, and they punish you in a specific way: nearly every model taxes the thing that means your program is working.
Governance succeeds by covering more data, connecting more systems, and getting more people to participate. Look at what each pricing axis does to that success.
- Per record.
As a worked example, suppose a tool costs a flat rate per 10,000 managed records, and you start at 40,000 product records. The bill is small. Governance works, so you fold in customer data and absorb an acquisition's catalog, and you are now at 400,000 records. The cost is ten times what you signed up for, and by then your workflows and integrations sit on top of the tool, so leaving is expensive. - Per source or connector.
You start governing four systems. Success means extending governance across the estate, and two years later you are paying for twenty connectors. - Per seat.
Looks cheap until you remember governance only works when stewards in every department can act. The more the program spreads, the more seats you buy.
Each axis charges you more precisely as you succeed. The move is not to find a model with no cost. It is to pick the axis you can predict and control. If your record count is volatile and your source list is stable, per-source pricing is safer, and the reverse holds too.
On the software itself, the market splits in two. Large enterprise suites like Collibra and Informatica handle wide cataloging and lineage across complex estates, with pricing and staffing to match. For master data such as products, suppliers, and reference data, open-source platforms are a lighter entry point. AtroCore is one, with a configurable data model, role-based access, and change history that cover the core governance mechanics without an enterprise contract; it sits alongside options like Apache Atlas and OpenMetadata, each stronger at a different job. Shortlist two or three and put them through the test below before you commit to any pricing model.
What A Pilot Exposes That A Demo Hides
A vendor demo runs on the vendor's data, and the vendor's data is clean. That is the whole reason the demo looks flawless and tells you almost nothing.
Run the pilot on your worst records instead. For deduplication, that means feeding the tool your real customer or supplier list, the one with "Acme Inc," "Acme, Inc.," and "ACME INCORPORATED" as three rows, plus the typos, the missing country codes, and the one company that legitimately trades under two names. Then hand-label a few hundred of those rows yourself so you know the right answer, and measure the tool against them.
Two numbers come out. How many real duplicates it caught, and how many distinct records it wrongly merged. A false merge is the dangerous one, because it destroys data by combining two customers who were never the same, and a clean demo will never surface it. Those two numbers tell you whether the matching engine works on your data. Nothing the vendor shows you will.
Do the same for whatever mechanic matters most in your case: a schema change the catalog has to catch, an approval workflow under a realistic load, an access rule with a real edge case. Pilot the thing that will break, not the thing that demos well.
Data governance implementation comes down to a handful of these mechanics. Keep the catalog true, settle the definitions before you model, price for the growth you expect, and pilot on your dirtiest data. Get those right, and the generic advice takes care of itself.