Build vs. Buy: Off-the-Shelf Governance Tools
Every governance product ships the same empty slot: the place where your rules go.
At some point in every data initiative, the build-vs-buy question arrives, and for governance tooling it usually gets answered the comfortable way: buy. There's a mature category to buy from — catalogs, quality monitors, observability suites — with strong demos and analyst quadrants. Eighteen months later, the firm owns an excellent inventory of its data chaos, a dashboard of alerts nobody triages, and reports that still don't agree.
The purchase didn't fail. It shipped exactly what the category sells.
The purchase didn't fail because the software was bad. It failed because of what the category ships and what it can't. You can buy software. You cannot buy your own judgment.
What does off-the-shelf governance actually ship?
Connectors, catalogs, lineage graphs, and alert queues — an inventory with a watchdog on top. That's genuinely useful plumbing, and none of it is the hard part. Look closely at any governance product and you'll find the same empty slot: the place where your rules go. Which of your five customer records is the real one. What "revenue" means at your firm. What happens when two systems disagree. The product hosts those answers; it does not contain them. It can't — they aren't software features. They're decisions only your firm can make.
The category's quiet assumption is that the decisions are the easy part and the tooling is the hard part. Eighteen months of unresolved conflicts says it's the other way around.
Why can't you buy the hard part?
Because the hard part is firm-specific judgment: the accumulated knowledge of which numbers to trust, currently living in the heads of a few tenured people. A tool can give that judgment a place to live, but someone still has to extract it, resolve the contradictions in it — the interesting work is discovering that finance and ops have never actually agreed on what a "customer" is — and encode the result where the data flows. Generic rule libraries don't survive contact with a real portfolio; a rule written for a generic company enforces a generic company's reality, and you don't run one.
This is Post 2's argument extended to the whole category: every vendor sells an inventory because inventories generalize and ship. Resolution doesn't generalize. It's built, per firm, on purpose.
Buy the plumbing. Build the judgment layer — and own it in-house no matter who helps.
So — build or buy?
Both, split correctly. Buy the plumbing: storage, movement, compute, even cataloging — solved problems, commodity prices, no differentiation in rebuilding them. Build the judgment layer: your entity definitions, your encoded rules, your conflict policies — and own it in-house no matter who helps you build it. The test isn't whose logo is on the software. It's whether, a year from now, your own team can change a rule without a change order, and whether the rules fire in the pipeline rather than waiting in a queue for a human to notice an alert.
Get the split backwards — build commodity plumbing, buy generic judgment — and you pay twice: once for the engineering nobody needed, and once more, indefinitely, for the disagreements no product ever resolved.
"You can buy software. You cannot buy your own judgment."
How do you tell which one a vendor is selling?
We've published the tests separately: the category distinction in The Difference Between a Data Catalog and a Data Foundation [link at publish], and the seven procurement criteria in our Data Platform RFP buyer's guide [link at publish]. The one-question version: ask where your rules will live, and who owns them in a year. If the answer is a documentation module and a support contract, you've found the empty slot.
The payoff for splitting it right is the same one this whole series is about: numbers that go into board decks unchecked, acquisitions that onboard on a timeline, and a stack your own people can change — fewer barriers between a good idea and trusted execution, with your judgment doing the constraining instead of a generic library doing the alerting.
