Reinforce Is the Wrong Word: What an AI Roadmap Actually Does to an MDM Roadmap (original)

The tell is not that master data management is underfunded. It is that master data management gets funded to exactly the depth the AI roadmap needs, and the rest of it is never built.

There is a slide in nearly every enterprise data strategy deck that puts two roadmaps side by side — one headed AI, one headed master data management (MDM) — with arrows running both ways between them and a sentence underneath about how the two reinforce each other. It is a good slide. It is usually true as a statement of intent.

I put the word to my co-author and asked what actually happens between those two roadmaps. He declined the word:

That's simple: MDM gets ignored while AI sucks up all the oxygen and the budget. AI is the current 'next big thing' in the industry, therefore everything has 'AI' attached to the project proposal. Unfortunately, that tends to draw all the attention and the status reports to the lightning rod that is 'AI-enhancement.' So, instead of reinforcement, the MDM roadmap exists solely to enable the AI roadmap and that's the only portion of the MDM roadmap that gets implemented or funded.

Read the last clause twice, because it is not the complaint you are expecting.

Not underfunded. Funded to the wrong shape.

“Master data is underfunded” is a thirty-year-old sentence. It is about an amount, everyone in the room already agrees with it, and nobody's behaviour changes when you say it again.

What he described is narrower and worse. It is a claim about the shape of what gets funded: the parts of the master data roadmap that feed the AI initiative get built, and the parts that do not, do not. The budget line may be the largest it has ever been. The programme is still being carved to somebody else's outline.

It helps to be concrete about what a master data programme contains, because the list is longer than the part an AI pilot touches. Take a platform's own documentation of the work it expects you to do — models and the entities inside them; free-form and domain-based attributes; attribute groups; business rules that set defaults, change values and raise notifications when a record fails validation; validation of a whole version against those rules; derived hierarchies and explicit hierarchies; collections; user-defined metadata; version locking, committing and flagging so subscribing systems know which version to trust; subscription views; and a user and group permission model [1]. That is one vendor's enumeration of ordinary master data work, and it is representative rather than exotic.

Now hold an enrichment pilot up against it. The pilot needs the entity, the handful of attributes it is filling, and a way to read the result back out. Three items. It has no opinion about hierarchies, no use for collections, no interest in whether the version is flagged, and no reason to care who is allowed to edit what — until the day it does, which is a different article.

So the subordination is not that the other items get rejected. It is that they never get proposed, because the proposal that gets written is the one with the sponsor attached. And here is why this is harder to see than plain underfunding: a programme funded to the wrong shape hits its milestones. It delivers on time. Its status is green. A starved programme looks starved and anyone can tell; a subordinated one looks like a healthy programme, right up until somebody asks it to do something the AI initiative never needed. In the woods I would call these two a lookalike pair — identical from above, and you only separate them by checking a feature you cannot see from where you are standing.

The feature to check is this: which items on the master data backlog would still be funded if the AI programme were cancelled on Monday? If the honest answer is none of them, the roadmaps are not reinforcing. One is a dependency of the other, and it will be defunded on the same day.

The chain runs through attention, not malice

The mechanism he names is not that anybody is acting in bad faith. It is that AI is the lightning rod — it draws attention, and attention is what the status reports are made of. That chain has four links and each one is somewhere you could intervene:

Does labelling actually move money? Outside the enterprise, where the flows can be measured, the evidence says it does. A 2025 working paper builds two separate measures for U.S. public companies from 2016 to 2024 — AI talk, taken from forward-looking claims about in-house AI investment in quarterly earnings calls, and AI walk, taken from AI-related expertise in employee résumés — and finds that walk predicts subsequent AI patent quantity and quality while talk does not; that within a firm, past talk does not forecast future walk; and that the market rewards talk in the short run but discounts it in the long run. The share of firms saying the word AI on a call went from close to zero in 2016 to roughly 20% by mid-2024 [2].

Two honest limits on that. It is a working paper rather than a peer-reviewed publication, and it is about capital markets, not internal budget committees. It does not prove that the same thing happens inside your company. What it establishes is that the label is worth something on its own, independent of the work behind it — which is the assumption the four-link chain runs on.

It is also worth noticing where the label is policed. In March 2024 the U.S. Securities and Exchange Commission settled charges against two investment advisers for what its chair called AI washing, with $400,000 in total civil penalties, over marketing claims about AI capabilities the firms did not have [3]. That September the Federal Trade Commission announced five actions under the banner Operation AI Comply, its chair stating that there is no AI exemption from the laws on the books [4]. Both regimes govern claims made to outsiders. Nobody audits the label on an internal project proposal, which is exactly where the four-link chain starts.

The case against this, and what survives it

The strongest disagreement is straightforward: spending on the data foundation is going up, not down. A January 2026 survey of 600 global data leaders reports 86% increasing their data management investment for the year, with the top drivers named as improving data privacy and security (43%), enhancing data and AI governance (41%), and upskilling employees in data and AI fluency (39%) [5]. If money is flowing into the foundation, subordination looks like the wrong diagnosis.

It is a vendor-sponsored survey of self-reported intent, and “data management” is a much wider category than master data. But take it at face value and look at what it actually measures: an amount, and three named drivers, every one of which is a service to the AI programme. Privacy and security for AI. Governance of AI. Literacy so people can use AI. Not one of those is a master data backlog item that exists on its own account. The survey is the best available evidence about the amount, and on the shape it points the same way he does.

A second 2026 survey, of 1,000 C-suite executives across the U.S., U.K. and France, gets closer to master data specifically and lands in the same place: exactly half of organizations have adopted master data management as a foundation for AI, and data management now ranks above cost and talent as the primary obstacle to scaling it [14]. That is a finding in master data's favour, and I would use it. Notice the preposition anyway. Even the report making the strongest case for the discipline defines its adoption by the thing it is a foundation for.

I went looking for a study that measures the shape directly — master data funding split by whether the funded scope serves an AI initiative — and came back empty-handed. What is above this line is sourced where a source exists and reasoned where none does, and the shape claim is in the second category: a practitioner's read, offered so you can test it against your own backlog in about a minute.

The order of operations, and the reason it is not an AI one

So I asked the obvious follow-up: what is the right order of operations for aligning an AI roadmap with a master data roadmap? The answer refused the question before it answered it. It is the same order of operations, he said, irrespective of which roadmaps he is asked to implement:

1. Determine what the business really needs
2. Determine what's critical path
3. Determine what's the 'low-hanging fruit'
4. Determine WSJF priorititization

WSJF is Weighted Shortest Job First — a prioritization formula that ranks work by the cost of delaying it divided by how long it takes, so that short jobs with expensive delays rise and long jobs with cheap delays sink. The framework that popularized it defines it as relative cost of delay over relative job duration and opens its own guidance with Don Reinertsen's line, If you only quantify one thing, quantify the Cost of Delay [6]. Notice what is not an input: novelty, technology, or the name of the sponsoring initiative.

He then flattens three disciplines into one, and this is the sentence in the whole conversation I would push back on: roadmap implementation, he says, is exactly the same as project management, which is exactly the same as product ownership. Twice “exactly.” That is too strong, and I would rather narrow it than defend it. Product ownership owns what and why against a market, and can move the destination when the market moves. Project management owns delivery against a plan, and moving the destination is the thing it exists to prevent. Those are different jobs with different failure modes.

What is genuinely common to all three — and what the rest of his answer supports — is the prioritization discipline: value, duration, and nothing else in the ranking function. That narrower claim still forbids something specific, which is the test of whether a narrowing is worth anything. It forbids ranking a master data backlog by how close each item sits to the AI initiative. And the violation is observable: take your backlog, cover the initiative names, rank it, and see whether the order changes.

The counter-example a careful reader will reach for is that AI-specific method does exist and is not merely vendor material. ISO/IEC 42001:2023 is a published international standard for an artificial intelligence management system [7], and NIST's AI Risk Management Framework, released in January 2023 with a companion playbook and a generative-AI profile, is free to download [13]. Both are real and both should be named rather than waved away. What they govern is how an organization manages AI risk and responsibility — NIST's four functions are govern, map, measure and manage. Neither is a sequencing rule that replaces value and duration, and neither tells you which of eleven master data backlog items to build first. Managing AI risk and ranking a backlog are answers to different questions, and having a good answer to one does not excuse you from the other.

Which leaves the part he calls the hardest, and it is a social problem rather than a methodological one:

The hardest part is pushing back against other groups playing buzz-word bingo instead of prioritizing based upon business value and time to deliver.

The practical form of that pushback is procedural rather than rhetorical. Rank every proposal on one list, with the labels off. If the AI work still comes out on top, fund it first with a clear conscience. If it drops four places once the word is put back, you have just measured the lightning rod.

The ten-second test

The most useful thing he said about roadmaps is also the shortest, and it is a question to ask of any AI initiative on the plan:

Does [it] have a token costing budget attached and is there a pre-full-implementation phase for validating that token budget?

Two clauses. Almost everyone asks the first one now. Almost nobody asks the second, and the second is where the answer lives.

A token budget with no phase behind it is a number somebody estimated, and an estimate of consumption for a workload nobody has run at volume is a guess wearing a currency symbol. The validation phase converts it into a measurement: a scheduled block of work, before full implementation, whose deliverable is a cost per record actually observed on your data. Making it a phase rather than an activity is what turns this into a ten-second test rather than an audit — a phase appears on the roadmap document, so you can look for it while the deck is still on the screen.

The reason it cannot be skipped is that the instrument most teams point at when challenged does not do what they think. Cloud spending budgets are, by their own documentation, alerting devices: when a threshold is exceeded, Resources aren't affected, and your consumption isn't stopped. The same page records that cost and usage data is typically available within 8 to 24 hours, that budgets are evaluated against it every 24 hours, and that a threshold notification normally arrives within an hour of that evaluation [9]. Read those together and the fastest honest discovery of an overrun is measured in hours of continued spending, on a pipeline that is meanwhile still processing records. A budget is a smoke alarm, not a circuit breaker. The validation phase is how you find out what the room is made of before you fill it.

A companion piece last week made the operational version of this point — ask what happens on the day the cap is hit, and refuse “we'll get an alert” as an answer (Load-Bearing, August 26). This is the planning version, one artifact earlier. The operational question is about behaviour under a limit; this one is about whether the limit was ever a number anyone measured. You want both, and only one of them is visible on a roadmap.

“AI will replace matching, and the stewards too”

The last myth on the list is the one that gets said at conferences, and his answer to it is the most structurally interesting thing in this conversation:

AI will replace every existing matching strategy and Data Stewards, too. Again, that may be true with an unlimited budget, but running everything through AI not only exhausts your budget before your data, it also introduces an external dependency and an external cost center to your data processing system that will be extremely costly to disconnect or replace.

He does not say the claim is false. He says it is true under a condition nobody states, and the condition is the objection. That is worth borrowing as a habit. The phrase unlimited budget is a device he reaches for — this is its second outing in three weeks — and what it does is take price off the table so the argument has to stand on something else. Used once, it is clarifying. So: once, and then the three costs it exposes, which are usually mushed into one and are better kept apart.

The first is exhaustion: you run out of money before you run out of records. This is the claim in the whole conversation I would put the most pressure on, because there is now a measurement pointing the other way. A 2026 benchmark ran 46 model configurations across eight entity-resolution datasets under a fixed protocol and quantified API-equivalent token cost alongside accuracy. An open-weight model reached 92.10 F1 at roughly twenty times less cost than the strongest proprietary configuration, and several ultra-budget configurations under $0.10 reached up to 89 F1 [12]. Ten cents does not exhaust anything.

The sweeping form does not survive that, and the accuracy objection is answered too: the best models match about as well as encoder models fine-tuned on thousands of labelled examples, with no or only a few examples, and hold up better on entities they have not seen [10]. What survives is narrower and more useful. Those are the costs of running a benchmark, on curated datasets whose candidate pairs have already been selected. Your bill is the per-comparison cost multiplied by however many comparisons your blocking strategy actually emits against your record count — a figure the benchmark does not contain and could not. That the scaling half is the hard half is visible in the literature's own frontier, which describes the prevailing approach as a binary matching paradigm and treats getting its cost down as a contribution worth a paper [11].

So the narrowed version, which still forbids something specific: nobody has published a per-comparison cost for language-model matching inside a governed master data estate at production volume, so a business case quoting benchmark accuracy and benchmark cost has not priced your deployment. Ask for the figure at your blocking output. If it does not exist yet, you have just found the deliverable of the validation phase from two sections ago.

The second is dependency, and the third is a cost centre you do not control. Those two are the argument the companion piece is built on — a cost you cannot decline is a dependency whose price someone else sets — and I will not re-derive it here. What this adds is the switching cost, and the switching cost has a date on it.

Managed model platforms publish their lifecycles, and one major platform's is specific: a generally available model has its retirement date set programmatically at launch, eighteen months out; at twelve months it is closed to new customers; the official replacement is named roughly 90 to 120 days before retirement, deliberately not sooner; after retirement, inference returns 410 Gone. Provisioned deployments are not auto-upgraded and must be migrated by hand. And the frequently-asked-questions entry on extending a retirement date answers in one word: No. [8] That is a transparent, well-run lifecycle, published in public by people with no incentive to overstate it — which is what makes it usable as a planning input rather than a grievance. Put a matching strategy on that platform and your master data roadmap has acquired an eighteen-month clock it did not set and cannot extend. Every retirement is a revalidation of every match rule you tuned.

As for the stewards: look again at that list of master data work in the first section. Matching is one line on it. The steward's job is not to execute comparisons — it is to decide the policy the comparison implements, which is to say what counts as the same customer in your business, what survives when two records disagree, and which of those decisions is allowed to be automatic. A system that resolves entities has taken over one task and has been handed the policy. At the right price, buying an imitation of a steward for the matching portion is a perfectly rational trade, and I would make it. What you cannot buy is somebody accountable for the rule — and if you think you have, ask the obvious question of the next merge it proposes: at what confidence, and checked against what?

So can the two roadmaps reinforce each other?

Yes — but not by default, and not for free. Reinforcement is a thing you have to build and pay for, and the reason the slide is so often wrong is that it draws an outcome as though it were an arrangement.

What it costs is the four items in the box above, and none of them is exotic. All of it is the ordinary discipline his four steps describe, applied to work that has been getting an exemption because of what it is called. The exemption is the whole problem, and it is not granted by anyone in particular — it is granted by attention, which is why nobody has to be at fault for the outcome to be reliable.

So if there is one sentence to take into the next planning meeting, make it the survival test: which parts of our master data roadmap would still be funded if the AI programme were cancelled on Monday? Whatever the answer is, that is the roadmap you actually have. Everything else is a slide.