Rules of Decreasing Strictness: What Each Tier of a Governance Operating Model Owes the Others, and Master Data

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

The operating-model question arrives as a menu: should data governance be centralised, federated, or some hybrid of the two? I have refused the menu before. Asked to choose, I said it should be all three (A Distance From Perfect, Owned by Domain carries that answer and the reasoning around it). Asked the harder question, what a domain actually has to do to publish to the enterprise standard, I gave the answer a shape:

There need to be governing rules of decreasing strictness that are applied at each level.

That sentence changes the question. The menu treats centralised, federated and hybrid as three alternatives, of which an organisation picks one and lives with its weaknesses. Rules of decreasing strictness treat them as three tiers of one model, stacked, each with its own obligations, and each looser than the one above it. The interesting part is the middle. When I first said it should be all three, I described two working parts: a central standard and the domains that publish to it. The answer above has three, and the one in the middle is not a compromise between the other two. It is a tier of its own, whose whole job is to say where the walls are.

This piece takes the tiers one at a time, says what each owes the others as lines a reader can check against their own domains, and then asks what the arrangement does for master data, which is where an operating model is tested hardest because master data is the one thing every domain shares.

What the field says the choice is

The menu is not a straw man. It is how the choice is usually presented, including by the vendors who sell the platforms it runs on.

A disclosure before the vendors speak, because what follows assesses their products and pages. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on master data management being bought at all. That interest runs toward praise of the category and of Profisee, whose own article on implementation styles is cited below: weigh anything favourable I say about either below my criticism of them. Profisee is aligned with Microsoft's data platform, so the same interest runs toward Microsoft's products, two of which are described below; weigh what I say in their favour with that in mind. Snowflake sells a data platform that competes with Microsoft's, which gives me a reason to be hard on it; discount my criticism of it accordingly.

Snowflake's own explainer sets out three models, centralised, decentralised and federated, and the failure each is known for. Centralise and "A central team can become a bottleneck when many domains need approvals, policy exceptions and stewardship support." Decentralise and "Definitions can drift, policies can get interpreted differently and cross-functional reporting can be harder when each domain governs on its own terms." Federate, and a quieter failure appears: "If roles are vague or escalation paths are weak, federated governance can blur accountability" [5]. Its hybrid is not a fourth model but a blend over time: start central, move toward federation as the domains mature [5]. That is a fair summary of the received view, and it frames the hybrid as a waypoint between two destinations.

Zhamak Dehghani's account of data mesh framed it differently, and closer to the tiers. Her federated computational governance is "a decision making model led by the federation of domain data product owners and data platform product owners, with autonomy and domain-local decision making power" [1], and the governance problem she names is one of "maintaining an equilibrium between centralization and decentralization" [1]. Her example draws the line where a master data practitioner would: how the podcast domain models its own data "must be left to the 'podcast domain' team", while "the decision around how to identify a 'podcast listener' is a global concern" [1]. Identity is global; the domain's own model is local. An earlier piece set her split beside mine and found that the two draw the central layer in different places; I will not repeat that comparison here.

What happened when organisations tried it is the more useful evidence. Jan Bode, Niklas Kühl, Dominik Kreuzberger and Sebastian Hirschl interviewed fifteen industry experts involved in data mesh transformations, most of them still in the early phases. Their headline finding: "We identify the shift from centralized toward federated data governance as the main challenge for professionals" [2]. The interviewees reported that "the lack of a central unit results in insufficient prioritization of use cases and projects across domains" [2], and the authors' remedy was not to abandon federation but to add back a "cross-domain steering unit responsible for strategic planning, use case prioritization" and "the enforcement of specific governance rules—especially concerning security, regulatory, and privacy-related topics" [2]. The researchers' answer to federation's main challenge was to rebuild a narrow, strict centre on top of it. That is the top tier of the ladder, arrived at the hard way.

The enterprise tier: three obligations

From here the argument rests more on my own practice than on the studies: what each tier owes, and why.

At the top of the ladder the rules are fewest and hardest:

At the Enterprise/centralized level, systems compatibility, naming standards and documentation requirements need to be enforced.

Three obligations, and each can be checked. Systems compatibility means a domain's systems can exchange data with the rest of the estate without a translation someone has to maintain by hand. Naming standards mean that an element is called the same thing wherever it appears, and that the rule for forming names is written down; the international standard for metadata registries has a whole part on exactly this, providing "principles and rules by which naming conventions can be developed" [9]. Documentation requirements mean the enterprise says what must be recorded about a rule, a data set or a decision, and the domain records it. Elsewhere I have listed the same layer in slightly different words: the forms communication takes, which decisions get written down, what metadata is collected, and who holds which role.

What the list leaves out matters as much as what it holds. It does not say what Finance's numbers must be, how Marketing categorises a campaign, or what quality threshold a domain must hit. It constrains what crosses between domains, the names, formats and records, and, for master data, the shared values that cross with them, not what stays inside a domain. That is why the top tier can be strict without being the command-and-control centre that governance programmes are rightly warned against.

The warning is real, and it comes with a forecast. Gartner predicted in 2024 that "By 2027, 80% of data and analytics (D&A) governance initiatives will fail due to a lack of a real or manufactured crisis", and its analyst Saul Judah advised chief data and analytics officers to "stop taking a center-out, command-and-control approach to D&A governance, and instead, rescope their governance to target tangible business outcomes" [4]. A model whose strictest rules sit at the centre looks, at first glance, like exactly the thing being warned against.

It is not, and the difference is scope. A command-and-control centre governs content: it decides the definitions, approves the exceptions and owns the outcomes, which is how it becomes Snowflake's bottleneck. A strict enterprise tier governs only what no domain can decide alone, because it only means anything across domains. A naming standard one domain follows and another ignores is not a standard. Nothing in the top tier makes a domain wait for a central team's approval to change its own rule; it only makes the domain write the rule down in the agreed form and keep its systems able to talk to everyone else's. Strictness about a small surface is what buys freedom everywhere else.

There is a second objection, and it is about people rather than design. Robert Seiner, arguing for what he calls non-invasive governance, puts the cost of any new layer bluntly: "People are often already busy more than 100% of the time, and if they feel you're adding to their work effort, they're going to push back" [8]. Three tiers of rules can look like three times the work. I take the point, and I have said before that every governance structure, councils and stewardship models included, is right and oversold, and fails without a champion with real weight behind it. The tiers do not escape that. What they change is what the champion is asked to defend: a short list of interface rules at the top, rather than every definition in the enterprise.

The hybrid tier: the map of where the walls are

The middle tier is the one the menu leaves out, and the one I would least want to:

At the hybrid level, there needs to be clarity of domains of responsibility and enforcement such that the systems know where they're constrained and where they're free to establish and enforce their own rules.

This tier is not a set of rules about data. It is a statement about rules: which domain is responsible for which data, who enforces what at each boundary, and, for each domain, where it is constrained by the enterprise and where it is free to set and enforce its own rules. Without it, the top tier and the bottom tier cannot meet. A domain cannot publish to the enterprise standard if nobody has said which parts of its data the standard reaches, and the enterprise cannot enforce a standard on data whose owner is in dispute. If this sounds like an ownership matrix, or like data mesh's principle of domain ownership, it contains both, and goes further. An ownership matrix names who answers for a data set. Domain ownership says the domain decides. This tier also records, boundary by boundary, which rules the enterprise binds and which the domain may set itself. Dehghani gives that decision to her federated governance group [1]; this tier writes it down where every domain can read it. One row of it names the data, an entity or an attribute; the domain that answers for it; the enterprise rules that bind it; what the domain may set for itself; and who enforces at the boundary.

The platform vendors have started to build this tier into their products. Microsoft Fabric lets an administrator delegate some settings from the tenant to a domain, so that "some tenant-level settings for managing and governing data can be delegated to the domain level"; the same page describes the aim as "enabling each business unit/department to define its own rules and restrictions according to its specific business needs" [6]. Microsoft Purview defines a governance domain as "a boundary that enables the common governance, ownership, and discovery of data products and business concepts" [7]. Both are tools for drawing the map. Neither draws it. The list of settings Fabric lets a domain override is short [6], and which business unit owns customer data is not a setting.

When the tier is skipped, the reason is not technical. Drawing the map means deciding who owns what, and ownership of data is ownership of territory. I have argued before that territorial fights over budgets and areas of responsibility have not changed in twenty years, because nothing has changed how tightly those things are tied to position and power, and that senior executives who are peers on paper sit in a real hierarchy set by the size of what they control (Before It Had a Name makes that case in full). A written map of domains of responsibility is a document about exactly that hierarchy. Nobody wants to be the one to write it, so it stays implicit, and the operating model runs on assumptions about who owns what that nobody has tested.

Who draws it, then, and what happens when two executives both claim the customer record? Asked that, I pointed back to my answer about who settles a contested definition:

This is stupidly axiomatic, but, the 'decider' decides. What I mean by that is the person with the authority and, more importantly, the enforcement power is the one who makes the ultimate decision and the other group(s) have to deal with and accept it.

That does not wish the politics away; it says where they end. The map is drawn by whoever holds the enforcement power over the domains it divides, and the other groups accept it because they have to, not because they agreed. Authority without enforcement draws a map nobody follows. Where nobody with the power to enforce one will draw it, the map stays implicit, and that is a vacuum, which is where master data comes in below.

The cost of leaving it implicit is the failure Snowflake names, accountability blurred because roles are vague [5], and it shows up long before anything breaks. The early sign that a governance programme is failing, in my experience, is people disowning problems: not mine, not my group, not my responsibility. Each of those answers is only available because no map says otherwise. A hybrid tier that states, domain by domain, where each one is constrained and where it is free does not stop the territorial fight, but it moves the fight to one place and one time, when the map is drawn, and takes "not my group" away as a daily defence.

The local tier: what, why and how

At the bottom of the ladder the rules are the domain's own, and the obligation is not to any particular rule but to clarity about them:

At the local/Federated level, they need to be very clear about what the individual system/group will enforce, why and how.

This is the least strict tier and the most demanding of honesty. A domain may enforce whatever its business needs, and the needs differ: Finance cannot work without hard numbers, while Marketing has a far looser relationship with precision. What the domain may not do is leave its rules unstated. The obligation has three parts, and each is a checkable line: what the group will enforce, why it enforces it, and how.

The industry has a vocabulary for the what and the how. A data contract, in the open standard now maintained under the Linux Foundation's AI and data foundation, "defines the agreement between a data producer and consumers" [10], and its sections cover the schema, data quality rules, service levels, roles and the team responsible [10]. A domain that publishes a contract for each data set it shares has stated what it enforces and how. The standard records a data set's intended purpose and, for each quality rule, the business impact of its failing, but not why the rule was set or the circumstance it was written for, and that reason is the part I would least want a domain to skip. A rule recorded without its why cannot be judged when circumstances change, because nobody can tell whether the circumstance it was written for still holds. The same gap sits under the semantic layers that AI tools now read, which carry what a number means far more often than why it was defined that way (What the Model Cannot Infer argues it for business intelligence).

Put the three answers together and the operating model is a ladder: a short list of strict interface rules at the top, a map of responsibility in the middle, and at the bottom each domain's own rules, as strict or as loose as its business needs, stated with their reasons.

What the ladder does for master data

Master data is where the tiers are tested hardest, because it is the data no single domain owns outright and every domain uses.

The relationship I hold between the two is simple to state. Governance is the set of rules and the framework within which master data management operates; without it, MDM is reactive and shapeless, and with it, MDM produces consistent and predictable results (Before It Had a Name quotes it in full). The ladder says which rules, from which tier.

The definition of the discipline already points at the top tier. Gartner describes master data management as a discipline that ensures "the uniformity, accuracy, stewardship, governance, semantic consistency and accountability of the enterprise's official shared master data assets" [12]. Uniformity and semantic consistency across the enterprise are exactly what the top tier's naming and documentation obligations exist to secure, and Dehghani's global identifier, the decision about how to identify a listener across every domain, is master data by another name [1].

I learned where the top tier stops for master data the hard way. Early on I tried to put the entire enterprise on a single standard, and it did not hold. I am still for one enterprise-wide standard for attributes such as client type, product line or inventory category; what I conceded was that segments of the business need to be shown alternatives and different values for backward compatibility or their own reporting, and the pushback to keep each department's downstream reports matching its expectations has not stopped (Before It Had a Name tells it). Read through the ladder, that is the tiers working as designed. The standard value of a master attribute belongs to the enterprise tier. The alternative presentations belong to the local tier, stated as the domain's own rule, with what it shows, why and how. And the map of which department may present which alternative, and which data it is responsible for, is the hybrid tier. My early failure was trying to run all three from the top.

The vendor side of the category says something compatible from the other direction. Profisee's own explanation of implementation styles notes that "Some implementation styles require a greater level of data governance maturity than others", and describes the centralised style, where the hub is the only place master data can be changed, as "typically very difficult to implement" [11]. The style that takes the most control demands the most governance, which is the expected result if governance is what makes control workable. It also fits the research on failure: Panagiotis Lepeniotis's doctoral study of why MDM implementations fail, built on a literature review, two data audits and eighteen interviews, names among the jeopardising factors "no practical commitment from senior management" and "no compliance with any data governance policies" [3]. The second is the bottom tier missing; the first is the top tier without a champion.

The tier I would expect to decide MDM success, though, is the middle one, because master data is shared data and shared data is where ownership is in dispute. Asked for a case where a missing map decided how a master data programme turned out, I answered with the pattern instead:

That's tied into vacuums and group(s) that decide to try to fill them paired with how successful they are at getting their authority respected once they've done so. If the business derives significant value from their actions and that value is recognized as the senior level--the level that can bless and enshrine the authority--things tend to go well. It's where there's a struggle that things tend to go... less well.

A missing map is exactly that kind of vacuum, and a master data programme is a natural candidate to step into it, because it is the one place where every domain's version of the customer meets. Whether the programme then succeeds tends to turn on whether its authority is respected: whether the business gets significant value from what it does, and whether that value is recognised by the senior level that can make the authority stick. That is the senior commitment Lepeniotis lists among the reasons MDM implementations fail [3], seen from the other side: the champion the top tier needs and the authority that makes the map stick are the same senior backing. A customer record is created in sales, corrected in service, billed in finance and analysed in marketing. Without a map, each of those domains can plausibly say the record is someone else's, and the mastering programme becomes the place where every unowned problem lands. With a map, the programme knows which domain answers for which attribute, where the enterprise standard binds, and where a domain may present its own view. That is the difference between a mastering programme that settles disputes and one that inherits them.

What to check, tier by tier

These are the obligations as lines. Each can be answered yes or no against a real domain.

Enterprise tier.

• Can each domain's systems exchange data with the rest of the estate without hand-maintained translation?
• Is there a written naming standard, and do the domain's elements follow it?
• Is there a written documentation requirement, and has the domain met it for every rule and data set it shares?
• Does the enterprise standard for each shared master attribute exist in one place?

Hybrid tier.

• Is there a written map of which domain is responsible for which data, including each master data entity and, where it is split, each attribute?
• For each domain, does the map say where it is constrained by the enterprise and where it is free?
• For each boundary, does it say who enforces what?
• When two domains claim the same data, is there a named place where that is decided?

Local tier.

• For each rule the domain enforces, has it stated what is enforced, how, and why?
• Where it presents master data differently from the enterprise standard, is the alternative declared as its own rule, with its reason?
• Could someone outside the domain read those statements and predict what the domain will accept and reject?

One model, three tiers

The menu asks an organisation to choose between a strict centre that becomes a bottleneck and free domains that drift apart, with a hybrid offered as the road from one to the other. The ladder refuses the choice. Strictness belongs at the top, on a short list of rules that only mean anything across domains. Freedom belongs at the bottom, where each domain sets its own rules and owes only an honest statement of them. And between the two sits the tier that the menu leaves out: the map of who is responsible for what, which is political to draw and therefore easy to leave implicit.

Master data shows why the middle cannot be skipped. It is the data every domain shares and no domain owns outright, so it is where an operating model without a map leaves a vacuum, and where the outcome tends to turn on who fills it and whether the senior level backs them. The research on organisations that federated concluded they needed a strict centre back. The tiers suggest they will need the map next. Drawing it is the hard part, and I would expect it to be the part that decides whether a master data programme settles disputes or collects them.

References

[1] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read 2026-10-07 through a rendering fetch; not stored locally. Cited for the definition of federated computational governance, the "equilibrium" phrase and the podcast-listener example, quoted in the body. https://martinfowler.com/articles/data-mesh-principles.html

[2] Jan Bode, Niklas Kühl, Dominik Kreuzberger and Sebastian Hirschl, "Towards Avoiding the Data Mess: Industry Insights from Data Mesh Implementations," arXiv:2302.01713, version 4 (the HTML of v4 carries "VERSION 1.0 as of 31/01/2024"). Read 2026-10-07 through a rendering fetch of the v4 HTML (the last ~5% of the text was not read); not stored locally. Method: fifteen semi-structured interviews with industry experts, November 2022 to January 2023. Cited for the four passages quoted in the body. https://arxiv.org/html/2302.01713v4

[3] Panagiotis Lepeniotis, Master data management: its importance and reasons for failed implementations, doctoral thesis, Sheffield Hallam University, 2020. Read 2026-10-07 (repository abstract) through a rendering fetch; not stored locally. Method: literature review, two data audits as case studies, eighteen interviewees. Cited for the two failure factors quoted in the body. https://shura.shu.ac.uk/27370/

[4] Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," press release, 28 February 2024. Read 2026-10-07 through a rendering fetch; not stored locally. A prediction; the release states no method or sample. Cited for the prediction and Saul Judah's advice, quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

[5] Snowflake, "Data Governance Models Explained: 3 Approaches," Snowflake (undated explainer). Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page (a competitor of the platform our partner is aligned with). Cited for the three sentences quoted in the body and its hybrid-as-sequence description. https://snowflake.com/en/data-governance/models

[6] Microsoft, "Domains," Microsoft Fabric documentation, Microsoft Learn, updated 1 May 2025. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor documentation (Microsoft is aligned with our partner). Cited for the delegation passages quoted in the body and the list of delegable settings (domain default sensitivity label; certification settings). https://learn.microsoft.com/en-us/fabric/governance/domains

[7] Microsoft, "Governance domains in Unified Catalog," Microsoft Purview documentation, Microsoft Learn, updated 3 October 2025. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor documentation (Microsoft is aligned with our partner). Cited for the definition quoted in the body. https://learn.microsoft.com/en-us/purview/unified-catalog-governance-domains

[8] Peter Spotts, "Why noninvasive data governance is the best approach to use," TechTarget, 12 December 2023 (interview with Robert S. Seiner). Read 2026-10-07 through a rendering fetch; not stored locally. Cited for Seiner's sentence quoted in the body. https://www.techtarget.com/searchdatamanagement/feature/Why-non-invasive-data-governance-is-the-best-approach-to-use

[9] ISO/IEC 11179-5:2015, Information technology — Metadata registries (MDR) — Part 5: Naming principles. Read 2026-10-07 (the ISO catalogue abstract; the standard itself is not free and was not read). Cited for the phrase quoted in the body. https://www.iso.org/standard/60341.html

[10] Bitol project, LF AI & Data Foundation, "Open Data Contract Standard (ODCS)," GitHub repository README (v3.1.0 on the day read). Read 2026-10-07 through a rendering fetch; not stored locally. Cited for the definition quoted in the body and the list of the standard's sections. https://github.com/bitol-io/open-data-contract-standard

[11] Benjamin Bourgeois, "Master Data Management (MDM) Implementation Styles, Explained," Profisee blog, 12 February 2024. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page (the vendor we partner with). Cited for the two phrases quoted in the body. https://profisee.com/blog/master-data-management-implementation-styles/

[12] Gartner, "Master Data Management: Definition, Process, Framework and Template," Gartner topic page, undated. Gartner's former glossary address for MDM now redirects here; the definition quoted in the body appears on this page, in its FAQ "What is master data management?". Read 2026-10-07 through a rendering fetch; not stored locally. https://www.gartner.com/en/data-analytics/topics/master-data-management