Both and Neither: What the Master Data Project Builds, and When It Reopens

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

The most damaging argument I have seen over master data management was not about what to build. It was about whose budget the building came out of. Two groups needed the same thing, one holding the money set aside for building things and the other holding the money for running them, and each fought to have it paid for out of the other's budget. Neither side disputed the need. They disputed the category, and a category is a label.

The trade has a sentence it offers as the correction: "MDM is a business program, not an IT project." It has been the standard correction since at least 2011. It is aimed at a real failure, the system installed, the project closed and the discipline gone with the contractors. I think it is wrong in both directions, and I think it is one of the things that starts the argument above. Master data management is both a program and a project, and it is neither one alone. Two different things share the name. They cooperate and they are funded differently. One of them builds what the other runs on, and a single question decides when the builder has to come back.

This piece is about the builder: the capital project, what it is for, where its edge sits, and what the label does to it. The ongoing program it hands over to is real and it is the business's to carry. How that program gets its money is a different question with a different answer, and I leave it alone here.

Where the slogan came from, and what it gets right

The correction has good parents. In a list reported in February 2011, Gartner's Andrew White named ten misconceptions about master data management, and the second of them, as Le Monde Informatique reported it, was "le MDM est un projet" [1]. In reality, the list went on, it is much more than a project: it is implemented as a program "qui change à jamais la manière dont l'entreprise gère ses bases de données", one that changes for good how the enterprise manages its data [1]. The first misconception on the same list was that MDM is about implementing a technology [1]. Gartner's own definition still carries the point in its first clause: master data management is "a technology-enabled business discipline in which business and IT work together" [2]. Vendors and practitioners took it up. A data management blog at SAS put it as a title in 2016, "MDM is a journey, not a project," and argued for phasing the work one piece of the business at a time rather than "trying to tackle too many MDM-related matters in one massive initiative" [3].

The argument has stronger relatives outside the discipline. Sriram Narayan's case for funding products rather than projects describes the project model exactly: work "funded on a case-by-case basis on the basis of benefits projected in a business case," staffed by temporary teams who "build a version of the solution over one or more releases, hand it over to a team in the 'run' organization and move on to the next project" [4]. His alternative is a team funded "to work on a particular business problem or offering over a period of time" [4]. Zhamak Dehghani's data mesh takes the same view of analytical data and gives it persistent owners, with a "domain data product owner" in each domain and developers "responsible for building, maintaining and serving the domain's data products" [5]. Neither of them is writing about master data in particular. Both are saying that the thing which keeps data right is a standing responsibility, not a delivery that ends.

On that much I agree with all of them. The stewardship never stops, and nothing about master data is ever finished. Any goal that amounts to being done, every record matched automatically, every source clean, a model that covers everything, is one I have long regarded as false rather than merely optimistic. Data keeps growing, and no completion target survives that without continuous review by people, so the honest target is good enough, kept good enough, indefinitely. A project that closes and takes that work away with its contractors has failed, however well the software was installed. The slogan exists to stop that, and it is right to.

Look again at what the original correction said, though. The same paragraph that denied MDM was a project ended with this: "L'adopter exigera de nombreux projets distincts" [1]. Adopting it will require many distinct projects. The corrective carried its own qualification, and the qualification fell off as the slogan travelled. What arrives in a funding meeting today is the first half only, and the first half, said to the people who hold the capital budget, means "not yours."

Asked where "MDM is a business program, not an IT project" goes wrong, or where saying it does harm, I answered:

The reason people get it wrong is it’s both and neither. Calling it one or the other is an attempt to conflate two distinctly different and cooperative things we call ‘MDM.’

The MDM business program is ongoing operational load that needs to be assumed and maintained by the business going forward. This involves ongoing data stewardship, data governance and data monitoring/cleansing activities.

The MDM IT project is a capital project that needs to be funded and implemented to create the superstructure that facilitates the ongoing MDM business program. This project will need to have additional phases and be reopened when new data sources or CDEs are added to the Enterprise Data Library.

Both labels are true of something, and calling either one the whole is the conflation. The program is the standing load: stewardship, governance, the monitoring and cleansing that never end. The project is a piece of construction, with a start, a budget and a finish, and it produces the structure the program runs on. The slogan picks one of the two and announces that it is the whole, and the opposite label does the same thing from the other side. Call master data an IT project and the business hears that it has nothing to carry once the system is live. Call it a business program and the people with the capital budget hear that it is an operating cost, so it belongs to someone else. Each label is a correct description of half the thing and an argument for moving the bill.

There is a second confusion buried in the word. When the Project Management Institute defines a program, it means "related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually" [6]. A program in that sense is made of projects. A project, in the same lexicon, is "a temporary endeavor undertaken to create a unique product, service, or result" [6]. The "business program" of the slogan is neither of these. It is operations, the ongoing running of a capability, and it borrows the word that project managers use for a coordinated set of projects. Read in the institute's sense, the slogan's own source is right: master data management is a program, made of many distinct projects. Read in the business sense, it is an operating responsibility that something has to be built for first. Neither reading leaves the project out.

What the project builds

Before I argue for funding the construction half, a disclosure. The practice behind this publication is a Profisee partner and holds a referral agreement with Profisee. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Our services revenue depends on this category of software being bought, and on exactly the kind of capital project this piece describes being funded. That interest runs toward praise of the category and of the project, so weigh anything I say in their favour below my criticism of them. No vendor's product is assessed here, Profisee's included.

The project's output is what I call the superstructure. It is not the work. It is the frame the work is done on. Concretely, it is the master data entities and domains, customer or supplier or product, modelled once for the enterprise; the paths by which each source system's records reach those entities; the matching and survivorship rules that decide when two records are one; the platform they run on; and the record of what every data element means.

That last part has a name in my vocabulary, the Enterprise Data Library, and I do not claim to have coined it. It is a library of data at the scale of the enterprise. It should hold every data element the organization stores and tracks, and for each one its lineage, classification, type, usage, description and domain, whether it counts as a critical data element or a key performance indicator, and, for anything derived, the formula that produces it and a reference to each upstream element it is built from. It is not a product. The field has a standard for the general idea, ISO/IEC 11179 on metadata registries, which treats metadata as "descriptions of data" and provides a framework for recording them [7]. What matters for this argument is narrower than either the standard or the catalogue software sold around it: the library is where the scope of the superstructure is written down. When I say the project reopens as sources and critical elements are added to it, the library is the ledger in which that growth is recorded.

"Capital" needs one more sentence, because it can be heard as a claim about accounting. Here it means the budget an organization sets aside for building things, as distinct from the budget for running them, and the argument in this piece is about which of those two a piece of master data work should be asked of. It is not a claim about how anything is booked. Whether a given cost is capitalized, and how a cloud subscription or a hosted platform is classified, are questions for the reader's accountant, and I am not one. The accounting standard-setters have their own vocabulary in this neighbourhood: a 2021 request to the IFRS Interpretations Committee distinguished configuring hosted software, "the setting of various 'flags' or 'switches' within the application software, or defining values or parameters," from customising it, "modifying the software code in the application or writing additional code" [8]. Those words will come back below in an operational sense. The rules that hang off them in the accounts are not mine to state.

Neither: program work inside the project, project work inside the program

"Both" is the easy half of the answer. "Neither" is the harder one, and I was pressed on what it meant:

Neither label alone describes it and a core component of the implementation plan is the initial work of Stewardship and Classification of data. As part of ongoing operational responsibilities, it is expected that the existing support structure--think an MDM equivalent of a DBA--will be able to add new data sources into the existing Master Data Entities without capital expense. So there is an operational/program component to the Project and a capital/expansion component to the Program.

The labels fail at both edges, and each failure is useful.

At the project's edge, the plan has to carry program work. Nobody can steward a superstructure that does not yet hold anything, and nothing goes into it until someone has classified what the data is, decided which elements are critical, settled the first round of survivorship and owned the first exceptions. That is stewardship and classification, the very activities the slogan assigns to the business program, and it has to be done on the project's money, by the project's deadline, because the project cannot be said to have delivered a working superstructure until it has been done once. A plan that leaves it to "the business, after go-live" has delivered an empty frame and named it finished.

At the program's edge, the operating side has to be able to grow the thing. A new source system of customer records will turn up, and when it fits an entity that already exists, a capable operating role should be able to connect it without anyone opening a capital request. The comparison I reach for is the database administrator. Nobody reopens a capital project to add a table to a database that was built to take tables; a competent administrator does it as ordinary work. Master data needs the equivalent role, and the superstructure needs to have been built so that role can do that job.

So "neither" is not a shrug. It is a claim that the project contains a piece of the program and the program contains a piece of what looks like construction, and that a budget built on either label will be wrong in a predictable place: the project budget will miss the initial stewardship, and the operating budget will be asked to fund what is really new building, or will refuse to fund what is really just operations.

The line that decides when the project reopens

My own two answers, set side by side, appear to disagree. The first says the project reopens "when new data sources or CDEs are added." The second says new data sources go into existing entities "without capital expense." Both cannot govern. I was asked which applied when, and whether the line was simply that a new source fitting an existing master data entity is operational work while a new entity or domain reopens the capital project. My answer:

That's exactly the line. It could also be opened when there's a new ingestion method that needs to be implemented to mesh source data to Master Data ingestion--think opening a new line of direct, natural language input. That would require creation of new infrastructure to support the new ingestion methodology and, potentially, platform changes. Fundamentally, if there are infrastructure changes necessary to support the ask, that's Capital. If configuration changes can handle it, that's Operational. Which is why I focus on trying very hard to make as much as I can configurable so Operational resources can handle changing and additional business requirements.

That settles it in favour of my second answer. The first was stated too broadly: a new source does not by itself reopen anything. The project reopens when the ask needs new building, superstructure that does not exist yet, and in practice that means one of two things. Either the business needs a master data entity or domain that does not exist yet, so there is nothing for the new records to go into, or it needs a new way for data to get in, a method of ingestion the platform was not built to accept. Direct natural-language input is my example, and it is exactly the kind of request the next few years will produce: somebody wants records created or corrected by people typing or speaking in ordinary sentences, and taking that in safely needs new ingestion machinery, not a new setting.

Everything else is configuration, and configuration is operational. Three asks make the line concrete. A newly acquired business brings its own customer system, whose records map onto the customer entity you already have: configure the source, map the attributes, tune the match rules, and the operating role does it. The business decides it now needs supplier master data, which has never been modelled: that is a new domain, a new entity and its rules and stewardship, and it is a capital ask. The business wants records to come in through a conversational interface: that is a new ingestion method and very likely platform change, and it is a capital ask. The first is the database administrator adding a table. The second and third are new building.

The line has a consequence for how the project is built, and it is why I push configurability as far as I can. If infrastructure is capital and configuration is operational, then every capability the project makes configurable is a future change that will not need a capital request. That is the reason for building the superstructure to bend. I want to build for the demand of years rather than months, and I tend to over-engineer for needs that have not arrived yet; I am also expensive. This is the place where that habit pays. What the project is really selling the business is the capacity to adjust: something good enough now, and adjustable enough that the next requirement is a configuration change made by the operating side rather than a new budget fight.

The obvious objection is that configurability is not free and does not stay simple, and the objection is correct. Mike Hadlow's "configuration complexity clock" traces the familiar arc: values move out of code into a configuration file, then into hierarchies of structured configuration, then into a database with its own interface so that business users can change the rules, then into a domain-specific language, until "there's little difference in the length of time it takes between changing a line of code and changing a line of configuration," and the team is "back where we started four years ago, hard coding everything, except now in a much crappier language" [9]. His conclusion is that "at a certain level of complexity, hard-coding a solution may be the least evil option" [9]. Alex Papadimoulis made the blunter version of the same case years earlier, naming the anti-pattern soft coding, "the practice of removing 'things that should be in source code' from source code and placing them in some external resource" [10]. Google's site reliability engineers, who run more configuration than almost anyone, put the discipline in one sentence: "you should add configuration knobs only when motivated by a real need" [11].

I accept all three, and they bound the aim without reversing it. My own record leans the other way from the engineers' sentence: I make as much configurable as I can, and I over-engineer for needs that have not arrived. The two meet at the word "predictable." A need the business will predictably have, a new source for an entity that already exists, a match rule that will want tuning, a threshold that will move, is exactly what I build for before anyone asks, and it is a real need before it arrives. So the superstructure should make configurable, generously, which sources feed an existing entity and how their attributes map, the match and survivorship rules, thresholds, reference values and the stewardship workflow. The bound sits further out, and it is my reading of Hadlow and Papadimoulis rather than anything in my record: the point where making a thing configurable means writing a language for it. When configuring a change has become as hard and as risky as building it, the change was building all along, and the line puts it on the capital side.

That bound is not what puts a new domain on the capital side, and it would be the wrong reason. A new master data entity or domain is capital because it is new building. It needs modelling that has never been done, its own first round of stewardship and classification, and its own governance: the same work this piece has already placed inside the project, because nothing can be run until it has been done once. That holds whether or not a server moves. Read that way, the line I agreed to runs between running what has been built and building more of it, and the infrastructure in question is the superstructure itself, not only the machinery under it.

So the narrower rule still rules something out in each direction. It rules out funding a new domain or a new ingestion method out of the operating budget by calling it "just configuration," which is how a capital need gets starved. And it rules out reopening the capital project, with its approvals and its months, every time a new source turns up that fits an entity already built, which is how a working superstructure gets treated as permanently unfinished.

What the label does to the budget

The line matters because of what happens without it. Asked what harm I had actually seen from the label, I said:

The biggest harm is an argument between two different groups (capital and operating) who both need the project but want to try to classify the expense as coming out of the other's budget. When it comes to unbudgeted expenses--of which MDM frequently is, or has been--business units fight aggressively to ensure costs are allocated to other groups. When the budget allows, though, they can be just as aggressive about getting an agreement closed as quickly as possible because they're primarily worried about delivering in the expected timeframe tied to those budgetary dollars.

Two harms, and they mirror each other. The first is the one this piece opened on. Master data work is often nobody's line item, and an unbudgeted need with two plausible payers is an invitation to argue about which one pays. The slogan arms both sides. The operating group can say it is a technology project, so capital. The capital group can say the industry agrees it is a business program, so operating. Each is quoting a respectable half of the truth, and the argument is about the label, not the work.

The second harm is quieter. When the money does exist, it usually exists inside a period, and the people holding it are judged on spending it on time. That pushes toward closing the agreement fast and delivering inside the window, which is precisely the condition under which the initial stewardship gets cut and the configurability gets traded for a go-live date. The best evidence I know for the mechanism is not about master data at all. Jeffrey Liebman and Neale Mahoney studied procurement by the United States federal government, whose budgets expire at the end of the fiscal year, and found that "spending in the last week of the year is 4.9 times higher than the rest-of-the-year weekly average, and year-end information technology projects have substantially lower quality ratings" [12]. A federal agency is not a business unit, and that is a finding about expiring budgets in one government, which I have read at the abstract only. It is the shape of the third sentence of my answer all the same: money tied to a timeframe buys speed, and the quality is paid for later.

There is a third consequence, and I name it only to mark where this piece stops. When the capital budget pays for the project and nobody budgets the program, the operating cost does not disappear. In many organizations I have seen, it is simply expected to be absorbed, by people who already have jobs, taking on stewardship on top of them. That is the program's problem, and how to fund it properly is another argument. It belongs here only because a project that closes onto a program nobody resourced has built a superstructure nothing runs on, and that is the failure the slogan was invented to prevent. The slogan's answer was to deny that the project exists. The better answer is to fund the project as a project, with the program's starting work inside it and the line written down, and to name the program it hands over to.

What I would write into the project's charter

From here the warrant changes, from what the sources show to what my own record shows, stated as pattern rather than law.

Name both halves, and say which one this budget is for. A master data case that says "program" when it is asking for capital, or "project" when it is quietly assuming the business will run the result, has already started the argument. Say plainly that the request is for a capital project that builds a superstructure, name the operating program it hands over to, and say that the program is the business's to carry. Saying so does not settle how the program is funded. It stops the project's own case from being used against it in the other budget's meeting.

Put the first round of stewardship and classification in the project plan. It is the program's work, and it has to be done once on the project's money before the superstructure can be called delivered. Leaving it to the business after go-live is how an empty frame gets signed off as finished.

Write the line into the charter. New building is capital and reopens the project: a new master data entity or domain, with its new modelling, its own first round of stewardship and classification and its governance; a new ingestion method; platform change. Configuration changes are operational and belong to the role that runs the system: a new source into an existing entity, new mappings, new rules and thresholds. Written down before the money is signed, the line turns every later request from a negotiation into a classification. It also gives the operating side something to hold the project to: the charter promises that the listed configuration changes will not need capital.

Make the library the record of scope. If every data element the superstructure handles is in the Enterprise Data Library, with its domain, lineage and status, then whether a new request needs a new entity is a question with a documented answer rather than an opinion, and the phases of the project can be read off the library's growth.

Build configurability generously, including for needs that have not arrived yet. Sources into existing entities, mappings, match and survivorship rules, thresholds, reference values and workflows: each one is a future change kept off the capital agenda, and predictable future need is exactly what to over-engineer for. Stop only where making something configurable starts to look like writing a language for it; there, build it.

Do not let the timeframe close the project early. Money tied to a period pushes toward a fast agreement and a fast go-live. The two things a rush cuts first are the ones this charter depends on, the initial stewardship and the configurability, and losing either one means the operating side cannot absorb the next change and the capital project reopens for something that should have been routine.

Both, and neither, and one question

The slogan was a correction to a real failure, and the failure is still real: a master data system installed, its project closed, and its discipline left to nobody. But the correction took the wrong part out. It denied that the project exists, when what was missing was the program that should have followed it, and in doing so it gave each budget a respectable reason to point at the other. None of this makes the superstructure an asset to be valued in place of a cost and a return to be argued (An Asset Is Not a Return), or master data the thing that transforms a business rather than what enables it (On the Funding List, Off the Post-Mortem).

What the record taught me is that master data management is two cooperating things under one name. The capital project builds the superstructure, and it does the first round of the program's work because there is nothing to steward until it has. The operating program runs on that superstructure and grows it, within the limits the project built in. The question that decides which of them a given request belongs to is not whether master data is strategic or technical, or a program or a project. It is whether the request needs new building or can be carried by configuration. Ask that, write the answer into the charter before the money is signed, and build the superstructure so that the answer is "configuration" as often as it honestly can be.

References

[1] Nathalie Moreau, "Les 10 fausses idées du MDM pointées par le Gartner," Le Monde Informatique, 1 February 2011. Read 2026-10-04 through a rendering fetch; not stored locally (egress refused). A trade report of a list by Andrew White, Gartner vice president of research; the underlying Gartner research note was not read. Only the first page (myths 1 to 5) was read. Cited for myth 1 (MDM as implementing a technology) and myth 2, quoted in French in the body. https://www.lemondeinformatique.fr/actualites/lire-les-10-fausses-idees-du-mdm-pointees-par-le-gartner-32783.html

[2] Gartner, "Master Data Management: Definition, Process, Framework and Template," Gartner topic page, undated. The former glossary address (https://www.gartner.com/en/information-technology/glossary/master-data-management-mdm) now redirects here. Read 2026-10-04 in a browser render; not stored locally. Cited for the definition's first clause, quoted in the body. https://www.gartner.com/en/data-analytics/topics/master-data-management

[3] Dylan Jones, "MDM is a journey, not a project," SAS Data Management blog, 20 June 2016. Read 2026-10-04 through a rendering fetch; not stored locally. Vendor-hosted blog. Cited for the title and the warning against one massive initiative, quoted in the body. https://blogs.sas.com/content/datamanagement/2016/06/20/mdm-journey-not-project/

[4] Sriram Narayan, "Products Over Projects," martinfowler.com, 20 February 2018. Read 2026-10-04 through a rendering fetch; not stored locally. Cited for the description of project-mode funding and handover and the product-mode alternative, quoted in the body. https://martinfowler.com/articles/products-over-projects.html

[5] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read 2026-10-04 through a rendering fetch; not stored locally. Cited for the domain data product owner and data product developer roles, quoted in the body. https://martinfowler.com/articles/data-mesh-principles.html

[6] Project Management Institute, PMI Lexicon of Project Management Terms, version 4.0, 2024. Read 2026-10-04 through a rendering fetch of a copy hosted by Colorado College; not stored locally. Cited for the definitions of "project" and "program," quoted in the body. https://www.coloradocollege.edu/offices/its/pmi-lexicon-pm-terms-compressed.pdf

[7] ISO/IEC 11179-1:2023, Information technology — Metadata registries (MDR) — Part 1: Framework, 4th edition, standard page. Read 2026-10-04 at the abstract only, through a rendering fetch; the standard itself was not read. Cited for the scope statement that metadata in the series means "descriptions of data" and that the series is a framework for metadata registries. https://www.iso.org/standard/78914.html

[8] IFRS Foundation, IFRIC Update, March 2021, item "Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38 Intangible Assets)." Read 2026-10-04 through a rendering fetch; not stored locally. Cited ONLY for the request's descriptions of configuration and customisation, quoted in the body; the article states no accounting treatment and relies on nothing in the Committee's conclusion. https://www.ifrs.org/content/ifrs/home/news-and-events/updates/ifric/2021/ifric-update-march-2021.html

[9] Mike Hadlow, "The Configuration Complexity Clock," Code Rant (blog), 7 May 2012. Read 2026-10-04 through a rendering fetch; not stored locally. Cited for the clock's sequence and the two sentences quoted in the body, and for the conclusion quoted. http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

[10] Alex Papadimoulis, "Soft Coding," The Daily WTF, 10 April 2007. Read 2026-10-04 through a rendering fetch; not stored locally. Cited for the definition quoted in the body. https://thedailywtf.com/articles/Soft_Coding

[11] Štěpán Davidovič with Niall Richard Murphy, Christophe Kalt and Betsy Beyer, "Configuration Design and Best Practices," chapter 14 of The Site Reliability Workbook (O'Reilly, 2018), online edition. Read 2026-10-04 through a rendering fetch; not stored locally. Cited for the sentence quoted in the body. https://sre.google/workbook/configuration-design/

[12] Jeffrey B. Liebman and Neale Mahoney, "Do Expiring Budgets Lead to Wasteful Year-End Spending? Evidence from Federal Procurement," American Economic Review 107(11), 2017, pp. 3510-3549; NBER Working Paper 19481. Read 2026-10-04 at the abstract only, through a rendering fetch of the NBER page; the paper was not read. Cited for the two findings quoted in the body. https://www.nber.org/papers/w19481