We've Made This Case Before: How the Enterprise MDM Business Case Grew Up (original)

Two decades of arguing for master data management — the emphasis kept moving, the arguments never did, and what actually gets one funded never has.

Every couple of years someone slides a fresh business case for master data management across the table and asks whether this is the one that sticks. I read it the way you'd hear a song you're sure you know: new arrangement, same melody.

I've been reconciling the spreadsheets since before the work had a name, when "master data" was just the quiet fact that every report showed a different version of the truth. In that stretch the pitch has been rewritten at least four times, each sure it had found the problem fresh. I grew up around Pittsburgh mills, where every generation was certain its trouble was unprecedented until the next one inherited it.

The compliance case: reconcile it before the auditor does

Master data was an established idea long before anyone sold master data management — MDM, once it reached the slide. Master files and master records were ordinary vocabulary in ERP and in warehouse practice through the 1990s. The named discipline crystallized in the early 2000s, out of fear.

Two forces put it there. The first was accumulation: a decade of ERP and CRM rollouts, plus mergers bolting whole companies together, left the same customer, product and supplier in a dozen systems that quietly disagreed — the problem the discipline exists to answer, and why it defines itself around a single trusted version of them [1]. David Loshin, in one of the first guides to carry the name, framed it through the acronyms that caused it: as ERP, SCM and CRM spread, there emerged "a need for a consolidated view of high-quality representations of every critical instance of a business concept" [2].

The warehouse people hit the same wall from the other side and called it a conformed dimension — one agreed description of a thing, defined once and reused by every report that touches it. Departmental data sets, the Kimball Group warns, "may look like they can be compared and integrated due to similar labels, but the underlying business rules may be slightly different" [3]. Two traditions, one complaint.

The second force was louder, and it came with a date attached. Sarbanes-Oxley arrived in 2002, and its Section 404 directed the SEC to require management to assess and report on internal control over financial reporting [4]. It did not land overnight — the first §404 reports weren't due until late 2004 — giving organizations two years to discover, in writing, that "our systems disagree about who the customer is" was now an audit finding with an executive's signature on it.

Then the money moved, which is what turns a regulation into a budget line. The SEC's own economists put mean annual §404 compliance cost, for the larger companies whose controls an outside auditor had to attest to, at $2.87 million a year before the 2007 reforms eased the testing rules and $2.33 million after. Nobody spent that because the return looked good, and the survey says so: large majorities credited §404 with improving their internal control structure (73%) and their audit committee's confidence (71%); barely half credited it with improving the reporting itself (49%); and most of those answering the optional cost-benefit question called it negative [5]. The arithmetic said no. The work happened anyway.

So the first business case was defensive. You didn't buy master data management to grow; you bought it to stop bleeding. Underneath the architecture diagrams, those programs were redding up — a Pittsburgh word for putting a place back in order — decades of mess nobody wanted to own. A case built on somebody else's deadline buys you a project, and leaves the discipline unbought.

The ROI case: putting a number on the mess, and what came with it

Compliance gets you through the door once, and the usual telling has the argument growing up into money after that. I told it that way myself. It's wrong, and the document that refutes it is the one I was about to lean on.

The number that anchored the early decks landed in February 2002 — five months before Sarbanes-Oxley was signed, and three years before the first §404 report came due. The Data Warehousing Institute told readers that data quality problems were costing U.S. businesses more than $600 billion a year. Two pages later the same report gives a precise figure for poor-quality customer data — $611 billion, in postage, printing and staff overhead — and hangs the only derivation in the document off it [6]. The report never reconciles the two, and the most economical reading is that they are one estimate, the rounder number written for the executive summary. Take that reading or leave it; what you cannot do is treat the pair as two independent findings that corroborate each other, which is how it has circulated for twenty years.

That report is the money argument already finished, not an early sighting of it. Beside the headline figure sits a worked funding case — $130,000 in annual savings on a $70,000 outlay, a 188 percent internal rate of return, payback in months — respondents naming "a single version of the truth" among the benefits they got, and a warning that HIPAA and the Bank Secrecy Act were "upping the ante" on customer data [6]. Three of my four arguments, in one document, before the statute that supposedly opened the first.

So these were never stages. Compliance, cost and capability are three faces of one case that was already assembled by February 2002, and the two decades since have re-weighted them rather than added to them — whichever driver carried that year's deadline went to the front of the deck. We have made this case before, all of it at once. It didn't grow up. It got re-argued. I take them here in the order they are easiest to explain, which is not the order they arrived — they mostly arrived together.

I raise it with affection rather than to score off a twenty-year-old report: it showed its arithmetic. A footnote derives the estimate from savings reported by respondents who had cleaned up name-and-address data, scaled by Dun & Bradstreet counts of U.S. businesses by headcount [6]. You can disagree with that method; more to the point, you can check it.

The genre it launched is still running, the slide still built the same way with a fresher figure. Gartner puts the cost of poor data quality at an average of at least $12.9 million a year per organization [7]. Different decade, identical rhetorical job — the emphasis had moved from "the auditor will punish us" to "the mess is already costing us, today."

Quantified waste is a more honest argument than vague risk. It is also where the industry picked up the habit it has never shaken: treating the headline number as the argument rather than the doorway.

The third face is capability, and it is the one that flatters us most. Digital made a single view of the customer worth money at the top of the income statement rather than savings at the bottom — you cannot cross-sell on four contradictory versions of one person — and e-commerce turned a bad product master into a broken catalog and a lost sale. Later, too: a 2013 design-science paper from the University of St. Gallen's corporate data quality program still lists regulatory compliance, reporting "in the sense of a 'single version of the truth'," and the demand for a 360-degree view of the customer as concurrent drivers [8]. Eleven years on, the same three, still concurrent — confirmation rather than news; the 2002 document had already settled it.

The underlying bet does appear to pay, at one remove: Brynjolfsson, Hitt and Kim, from survey data on 179 large publicly traded firms, reported output and productivity 5–6% higher among adopters of data-driven decision-making than their other investments would predict [9]. That is a finding about deciding from data, not about master data management, and I'll leave it there. The claim that buyers themselves moved from exposure to capability is one I've watched happen and cannot source for you: the figures that circulate trace back through a trade write-up [10] to a 2021 Magic Quadrant [11] — Gartner's ranked survey of vendors in a category, the artifact a market uses to tell itself who is winning — which, read in full, doesn't contain them.

And capability carried a tax. The harder you sell the platform as the enabler of every new initiative, the easier it is to assume the software carries the ownership work. The pitch got more exciting and the discipline got easier to skip.

The AI case: mostly the same work, on a louder deadline

Those three are settled material, and I've given them the space settled material deserves: their arguments are made and their bills are known. What follows gets more room than all three together — because it's the only one still being argued, and priced right now in proposals I'm reading this month. The weight belongs where the thinking isn't finished.

Everyone now needs data that is "AI-ready" — and a model is only as trustworthy as the master data it stands on. Feed one four versions of your biggest customer and it answers with the serene confidence of one.

But look hard at what Gartner's own account of AI-ready data actually asks for. Reliable sources and pipelines. Lineage — "transparency about data origins and transformations." Stewardship policies applied "throughout the data life cycle." Validation and verification "during development and operations." Observability of data health, timeliness and accuracy [12]. Most of it is the master-data business case — the same governance work the previous three drew from. AI didn't invent the argument; it inherited it and stapled a deadline to it.

Notice what is not on that list: nowhere does it ask you to resolve those four versions into one. That absence is where the bill comes due.

Most of them, and the remainder deserves naming: it genuinely was not in the first three. Gartner's own account declines to call any dataset AI-ready in the abstract: readiness "depends on how the data will be used," and there is "no way to make data AI-ready in general or in advance" [12]. Stack on the labeling, the versioning against model drift, the regression testing and the bias measures, and you have real work, none of it master data management and none handed to you by a golden record.

There is a sharper point against me in the same place. High-quality data, judged the traditional way, "does not equate to AI-ready data," because an algorithm needs data representative of what it will meet — and that "may include poor-quality data, too" [12]. Survivorship is the work I have spent a career defending, and for a training set it is also a way of deleting the very variance the model was supposed to learn from. The golden record is the right artifact for a payment run and the wrong one for a sample. That doesn't undo the case; it means this fourth argument has a second half that belongs to somebody else.

Where I want to push back is on the bill, and I owe this one to my co-author, who put it more plainly than I had:

I haven't read the Gartner report, but any report that says 'AI ready data' is (functionally) unchanged from your source systems isn't asking for any work to 'prepare' the data for AI. They're just asking that the AI be fed garbage data and expected to correct it. That's expensive in tokens when compared to basic MDM pre-processing.

He flagged that he hadn't read it, and he's right to say so — and having read it, I owe the page more than he gives it. It asks for real work, as that list shows; "(functionally) unchanged from your source systems" is too strong. What survives is the half of his objection aimed at what the page never asks for, and it survives because the page reaches further than he knew. Where it argues representativeness at length, the case is about training: "when training an algorithm, the algorithm will need representative data" [12]. Its definition, though, goes past its argument. Data must be representative "to train or run an AI model for a specific use" [12]. Run, not just train. And the enterprise AI work I actually see is running, not training — inference: a model reading your systems to answer a question. At inference nothing is being fitted, so the four versions of your biggest customer teach nobody anything. They arrive in the context window, and something has to reconcile them — every query, at token prices, forever — or not reconcile them and answer confidently from whichever one came first.

Notice what the page does that its market does not: it defines its terms. What gets sold downstream of it is "advanced AI processing," and I have yet to be handed two proposals that meant the same thing by it. That is my experience rather than a census — nobody has surveyed the vocabulary, and I am not going to pretend the absence of a survey is evidence of one. But the asymmetry survives either way, because it only takes one undefined term to do the damage: you cannot cost an undefined thing, scope it, or hold anyone to it — so what arrives dressed as a comparison between two approaches is a priced line item on one side and a phrase on the other. Ask for the definition before the quote.

That is the trade I would put in front of a committee, and the bill is only its most-argued half. Resolve the entity once — upstream, or in the view that serves the model, but once and deterministically — and you pay for it once, you can read the rule that decided it, and you can change it and see what moved. A rule is an artifact you can read, version and argue with; a reconciliation performed inside a context window leaves no such artifact — you can prompt it differently, but you cannot diff what changed, and nobody governs what they cannot see. That is control, and worth more than the saving.

The obvious objection is that prompts version too, traces log, and an eval harness will diff a whole run for you. All true, and none of it is the same artifact. A trace tells you what went in and what came back; it does not tell you which rule decided these two records were one person, because no rule did — the decision happened inside the answer and left no separable account of itself. An eval scores the aggregate and stays silent on the individual merge. What a survivorship rule gives you is a decision you can read before it runs and argue with without running it. That is what a joint gives a limb, in the anatomical sense: motion, load, and both only within a range you can name. Unbounded motion is dislocation.

Answer quality is the other half, and my co-author has the image for it — an analogy, not an anecdote. Train a model on raw sewage and you do get a lift; the lift is real. But the defense of feeding it the mess rests on the mess being representative of what the model will meet, and sewage is not representative of drinking water. That is the narrow claim I'll defend: not that a resolved entity always answers better, but that "representative" has not earned its keep here — an unresolved customer record is not a truer sample of your business, it is the same fact four times, weighted by whichever system was chattiest.

Ship the mess downstream and call it representativeness, and you have converted a fixed preprocessing cost into a variable per-query one, on a unit price you neither set nor forecast. I can't hand you the crossover figure — it depends on your query volume, your model and a token price that moved twice while this piece was edited, and I'm not going to invent one to win a paragraph. But the shape of the two costs is different, and a case that ignores the difference is not a case about money at all.

Two objections belong here, this being the part likeliest to be wrong. The page is not silent on cost: it asks that data meet operational service levels "including response time and cost efficiency" [12]. That names the bill without saying who pays it down, but it is there, and I'd rather quote it than pretend otherwise. The second is aimed at me. A model handed all four versions can notice they disagree; a survivorship rule cannot — it picks one, records the win, and the disagreement stops being visible downstream. Reconciling per query is expensive, but expensive in the open, and if your merge logic is quietly choosing wrong that may be the cheaper error. The answer is that a conflict surfaced fresh on every query is still a conflict nobody owns.

There's a wrinkle the enthusiasm hides: a lot of AI spending isn't a return-on-investment argument at all. In the ones I've sat in, the return is negative and the room knows it; the case is a response to market and competitor pressure — a legitimate reason to spend money, and a different argument. Regulatory work has always lived there, and the §404 figures above measure exactly that: real reported benefits, a majority verdict that the trade-off was negative, the program going ahead anyway [5].

What held, whichever argument was in front

Back to the argument. Stand back far enough and the durable lessons were sitting there the whole time.

• It's an organizational problem wearing a technology costume. Every version of this case has blamed the tools, and every version has been mostly wrong. Master data breaks in the org chart, not the diagram — as I learned watching two databases everyone swore were spotless merge into one memorable mess. The clean data model saved nobody; the unanswered question of who decides did the damage. It's the one lesson the outside sources reach independently — the St. Gallen researchers, naming early programs as technology-driven at the cost of organizational work [8], and the Kimball Group, from data modeling, concluding that shared reference data "requires organizational consensus and commitment to data stewardship" [3]. Everyone who gets there gets there by exhaustion.
• The golden record is a verb, not a noun. Survivorship runs forever, because the world keeps changing your customers, products and suppliers whether you watch or not.
• Budget for the tending; the build is the cheap part. I keep bees, and here is the part that maps: a colony does its own work. It forages, raises brood and gets through most weeks without me. What it cannot do is decide when to split, when to feed, or whether the queen is failing — and a hive nobody decides for looks perfectly well from the outside right up until it is gone.

The question I'm handing off

Which leaves the question I'll hand off rather than settle: how much of this can a platform carry? Tomorrow, Isabel takes the same business case into a real MDM platform — Profisee — showing what it looks like once the argument stops being a slide and becomes software. The disclosure above covers her too, and it is why she can write about that platform at the depth she does: she knows it from the inside.

She and I disagree, amiably, about exactly this seam. She's made her peace with letting a good platform shoulder a real share of the load, and she's usually right to; I get twitchy trusting any tool to save me from a decision the organization hasn't made. But we've never disagreed about what held through all of it. A good platform carries the work, and it will carry it beautifully while the ownership question underneath goes unanswered — showing you nothing at all until the day it shows you everything.

Master data isn't a project you finish. It's a hive you keep.