Two Models and a Seam: Governing Master Data and Analytical Data at Enterprise Scale

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

When I was asked whether an enterprise should run one governance operating model for its master data and its analytical data, or two joined at the definitions they share, I did not split the difference. I went back to the federated model I have argued for on this beat and started with who owns the data:

I refer back to my perspective on Federation. The User of the Data is the Ultimate Owner of the Data. To my mind, the ‘proper’ Domain of Master Data Governance is Enterprise Standards, Policies and Procedures. Analytical Data Governance, on the other hand, is Directly tied to End-User Reports and Data Consumers.

The first sentence is the one a governance office will push back on. On my account, the people who own an analytical data set are the people who use it. That does not make every analyst the owner of the customer master. It means the governance that serves analysts has to be organised around them, and the governance that keeps the enterprise's systems talking to each other has to be organised around those systems. Those are different organising principles. Run both through one model and, I would argue, analytical governance turns into a slow copy of master data governance, while master data governance ends up arguing about report layouts.

Some terms first. Master data, here, is the shared reference data the enterprise's systems pass between them: customers, products, suppliers, locations and the categories they sit in. Master data governance is the set of rules, roles and routines that keep that data consistent as it moves. Analytical data is what gets assembled from operational and master data so that someone can measure, report and decide: the warehouse, the marts, the semantic models behind the dashboards. Analytical data governance is the set of rules, roles and routines that decide what goes into those data sets, what their measures mean and who may rely on them. An operating model is who does that work, with what authority, through which routine.

Two jobs that share a vocabulary

Pressed on where the line falls between the two, I was blunter than the question:

These are two entirely different and only vaguely connected Domains. Each has different Operating Conditions and Success Criteria. Where there are Shared Definitions, there’s overlap in deliverables and structure. However, what’s good for the Marketing Reports is rarely good for the Finance reports or the Inventory reports.

"Only vaguely connected" is a strong phrase, and I mean it. The connection is real but narrow: where a report and a master record use the same term, the two have to agree on what it means, and that agreement is a joint deliverable. Everywhere else they are doing different work, for different people, under different conditions, and they should be judged differently.

The Marketing, Finance and Inventory line in that answer is not new on this beat. Describing the federated model in A Distance From Perfect, Owned by Domain, I set a Finance department that cannot function without hard numbers beside a Marketing department that has almost none. From the master data side, that difference is why every domain owns its own rules and still publishes them to an enterprise standard. From the analytics side, it is why one report specification fits almost nobody: the revenue figure Finance needs reconciled to the ledger is a figure Marketing needs directionally right by Monday, and the stock position Inventory needs by location and lot is a number neither of the others will ever look at in that shape.

The governance literature mostly answers the question the other way.

What the field says the operating model should be

The reference frameworks put both kinds of data under one governance function. DAMA International's body of knowledge, which calls itself "the globally recognized framework for data management", sets data governance, reference and master data, and data warehousing and business intelligence side by side as knowledge areas of one discipline, with governance at the centre [1]. McKinsey's prescription is a single central data management office, governance roles organised by data domain, and a data council that "brings domain leaders and the DMO together" [2]. Gartner's own framing is broader still: governance programmes "specify decision rights and accountability to ensure data is properly valued, created, consumed and controlled", and Gartner criticises leaders who "pin their hopes for improvements on acquiring a new master data management solution" [3]. The Data Governance Institute defines the whole subject as one "system of decision rights and accountabilities for information-related processes" [4].

Even the dimensional-modelling tradition, which built the analytical estate one business process at a time, asked for a strong centre. A Kimball Group column on choosing an approach to master data called "strong, centralized data governance" the "mandatory foundation" for conformed enterprise information [5]. And the classic case for a central model is the one every reporting manager has lived: two departments bring two numbers for the same thing to the same meeting. A 2008 Aberdeen-sourced piece for TDWI put "the absence of a common naming process for data elements" among the causes and prescribed master data, metadata and a formal stewardship role [6].

I accept the part of this that is right. There is one enterprise, and one set of definitions has to bind wherever the two kinds of data meet. Nothing I am arguing lets a report redefine a customer. Where I part company is on the inference that one set of binding definitions requires one operating model. The frameworks are describing a scope (everything governance touches). An operating model is a routine (who does the work, under what authority, judged how), and the evidence that the routines differ is in the same literature.

Gartner itself has moved there. Saul Judah describes four governance styles rather than one: a Control style of "rules, policies, standards, and directives", with master data management and compliance with requirements such as GDPR as his examples, and an Agility style built on "empowering roles and teams" to make distributed decisions [7]. A later Gartner abstract says "traditional one-size-fits-all approaches to data and analytics governance cannot deliver the value, scale and speed" now expected; only its abstract is public [8]. Two styles, with different owners, different routines and different measures of success, are two operating models in everything but the organisation chart. Gartner keeps the umbrella. I would keep the umbrella too, as a budget line and a reporting line. I would not pretend it is one model.

What follows is my own record, offered as a pattern I have watched repeat rather than as a law.

What master data governance is for

Asked what each side should concentrate on, I gave two short lists. The master data list:

Master Data Governance needs to focus on Systems Interoperability, Integration Pipelines, Process Enforcement and Data Security.

Every item on that list is about systems, not readers. Interoperability means a customer created in the order system arrives in billing as the same customer. Integration pipelines are the routes that make that happen, and governance there means knowing which pipeline may write which attribute. Process enforcement means the creation and change of a master record follows a defined path, with the checks done before the record is published rather than after a report shows it is wrong. Data security means the master record carries its classification with it, wherever it goes.

This is the enterprise tier of the model I set out in Rules of Decreasing Strictness: a short list of hard rules (systems compatibility, naming standards, documentation) enforced across every domain, a map of who is responsible for what, and each domain's own stated rules at the bottom. That piece argued that centralised, hybrid and federated governance are tiers of one model rather than three alternatives, and I still hold it. The ladder is how master data governance is built. Analytical governance is not a fourth rung on it. It is a second model beside it.

Gartner's definition of master data fits that reading closely. Master data is "the least number of consistent and uniform sets of identifiers and extended attributes" an enterprise needs, and master data management is the discipline that ensures the "uniformity, accuracy, stewardship, governance, semantic consistency and accountability" of "the enterprise's official shared master data assets" [9]. "Least number", "official" and "shared" are the words of a model whose job is to keep a small, common core identical everywhere. Nothing in that definition is tailored to a reader.

The success criterion follows from the job. Master data governance is working when nothing downstream breaks because of a disagreement about what a record is, and when the systems that exchange records stop needing hand-built translations between them. That is a measure set by systems and pipelines. A report that nobody reads is not a master data failure.

What analytical data governance is for

The other list was shorter:

Analytical Data Governance needs to focus on Targeted Deliveries of Tailored Data Sets.

"Targeted" and "tailored" are the operative words, and they are the opposite of "least number" and "official". An analytical data set is built for a decision and a consumer. The governance questions it raises are about fitness for that use: what goes in, what each measure means for this reader, how fresh it has to be, who may rely on it and for what, and when it should be retired.

A word on interest before I lean on vendor documentation. We are a Profisee partner: clients pay us for deployment work, a licence sale we refer earns us a referral fee, and our services revenue depends on master data management being bought. That interest runs toward the category, so weigh anything here that favours master data governance below my criticism of it. Profisee markets itself as a native master data workload inside Microsoft Fabric, so our interest also runs toward Microsoft: weigh what I say in favour of Microsoft's products with that in mind.

The platforms already run analytics this way. Microsoft's adoption guidance for Fabric and Power BI describes three patterns of content ownership. In business-led self-service "all content is owned and managed by the creators and subject matter experts within a business unit". In managed self-service, the data is owned by a central team "whereas business users take responsibility for reports and dashboards", which Microsoft sums up as "discipline at the core and flexibility at the edge". Enterprise content is owned by a central team, and Microsoft lists highly sensitive or regulated data among the conditions that suit it [10]. Microsoft's endorsement scheme then separates two things that a single model would merge. Certified content has been confirmed by "an organization-authorized reviewer" as reliable and authoritative for reuse; a separate master data label marks an item as "a core source of organizational data", the "authoritative, single source of truth" for things like product codes or customer lists, and only users a Fabric administrator names can apply it [11]. Two badges, with different meanings and different people allowed to apply them, though Fabric administrators control who may apply each, and certification can be delegated to domain administrators. The tool makers have drawn the content line I am drawing, inside one platform; who runs each side they leave to the customer.

Microsoft's middle pattern is also the strongest version of the objection to my first sentence. In managed self-service the data stays central and only the reports belong to the business. Data mesh puts the default owner at the other end, with the domain that produces the data. Neither puts ownership of the data with the people who use it by default. In Who Owns the Data, Really? I conceded two things to the frameworks: that the owner of data belongs where the data is made, and that the fix belongs at the source. I keep the second. The first I no longer hold as a general rule:

It's owned where the Data is Used because it's the Use of the Data that drives Business--not the Generation of the Data.

That is the end state, and it moves me off the first concession. It is also what that earlier piece found when it looked at history rather than at the frameworks: the fix often went first to whoever the error hurt, usually the people using the data, even when it was later pushed back up the pipe. Ownership by use reads that pattern as ownership doing its job: the owner takes the problem, and the fix goes back up the pipe to where it must be made; ownership by origin reads it as escalation after the fact. It also explains the two models. An analytical data set is used by a consumer for a decision, so it is owned there: its shape, grain, measures and filters are that consumer's to set and to defend. Master data is used by every system that exchanges a customer or a product, so its owner is the enterprise as a whole, acting through its standards. That last step is the rule I give for any shared data, set out below. It is why the proper domain of master data governance is enterprise standards and not any one department's preferences. Owning data in this sense means setting what it has to be; where a correction belongs upstream of the owner, in a providing system or a transformation step the owner cannot touch, it still runs there, on the owner's demand. The fix at the source is the concession I kept, and I hold it as a rule: the fix must be made at the source, which is the providing system when the data is unmodified and the transformation step when the value is calculated. Made anywhere downstream, it is a patch, not a fix; that is the Suite/Suites case in Heads Up: The Data Steward's Job After the Routine Work Goes. That it runs on the owner's demand follows from ownership by use.

Data mesh gives the sharpest version of the challenge, and it partly agrees. Zhamak Dehghani's original argument assigns analytical data to the business domains rather than to a central team, and distinguishes data sets that "naturally align with the source, where the data originates" from consumer-oriented ones that "transform the source domain events to aggregate views and structures that fit a particular access model" [12]. In her later statement of principles the default owner follows "the seams of organizational units", that is, the producing domain, and the global layer of governance exists for one purpose, "creating interoperability" [13]. On ownership she and I disagree, and the disagreement is the one above: the mesh puts it with the producer and asks the producer to serve the consumer, while I put it where the data is used, and move it up to the provider only when more than one consumer group relies on it. On consumer-oriented data sets and on what the global layer is for, we agree. Kiran Prakash, writing on data product design for the same site, works the way my answer does: start from the consumers' use cases rather than the sources, and give each data product exactly one owner, because "no single data product should be owned by multiple domains" [14]. Asked who owns a data set that several consumer groups rely on, I said they all do, which in practice moves ownership up the chain to whoever provides it: federation pushes ownership down as far as it will go, and shared data cannot be pushed down, so it is owned one level higher. That is also where Prakash's rule of one owner for each data product is met: not among the consumers, but one level above them. For shared data that lands close to Microsoft's managed self-service and to the mesh's shared consumer data sets [12]; the difference is the ground: the provider holds it because its consumers share it, not because it made it.

So the analytical side's success criterion is not the master side's. It is working when the consumer can make the decision in front of them from the data set built for them, and can say what each number means. A finance data set that reconciles to the ledger and a marketing data set that is directionally right by Monday can both be governed well, and they will not look alike.

The seam is the shared definitions

If the two models are only vaguely connected, the connection has to be exact. The analytical tradition has known where it is for thirty years. In Kimball's terms, dimensions conform when they "have the same column names and domain contents", they are "defined once in collaboration with the business's data governance representatives", and they are "the essence of integration in an enterprise DW/BI system" [15]. The bus matrix makes the seam visible: its rows are business processes, its columns are the shared dimensions [16]. The columns are where the two models meet. The rows are where each department builds what it needs. Margy Ross put the boundary in one sentence: "any special dimensional attributes unique to a single business process do not have to be discarded during the conforming process" [17].

Read across, that is a description of my answer. The shared dimensions (customer, product, location, the calendar) are master data or derive from it, and their definitions belong to the master side's enterprise standard. Everything else in the analytical estate (the measures, the department-specific attributes, the roll-ups, the grain) belongs to the analytics side and its consumers.

My own record has a sharper version of the same boundary, and it took me a failure to see it. As I described in A Distance From Perfect, Owned by Domain, early on I tried to put the whole enterprise on a single standard. I still want one enterprise-wide standard for things like client type, product line and inventory category, but I learned that some parts of the business need to be shown alternative values, for backward compatibility or for their own reporting, and the pushback to make downstream reports match each department's expectations has never stopped. That is the seam working as it should, not failing. The enterprise standard is kept; the department's view of it is a mapped alternative; the mapping is the governed artefact.

The tools for the seam exist on both sides. On the analytics side, a semantic layer such as dbt's lets teams "define metrics on top of existing models", and "by centralizing metric definitions" keeps them consistent wherever they are used: change the definition once and it is "refreshed everywhere it's invoked" [18]. That is centralisation, but centralisation inside analytics, owned by the people who build for consumers; it does not need the master data team's approval queue. On the catalogue side, Microsoft Purview's business glossary creates terms under governance domains, and says plainly that "both sales and marketing might use the same term to mean different things", with the domains there to tell them apart [19]. A glossary that expects one word to carry two meanings is a glossary built for two models.

When two domains each claim the same master attribute and will not agree, the master side already has an answer, which comes back below. The harder case is a report that disagrees with a master record that has one owner.

When the report and the master disagree

The question I was asked ended there: who decides when a definition used in a report disagrees with the mastered one? Asked directly whether the report wins, I said:

Usually, yes. However, only when the process behind both numbers is clearly understood. If the Marketing Department wants a different number and they can articulate Why and How that number needs to be different from the Accounting number, then they not only can keep it, they can defend it and they've proven they Understand their Business. Marketing gets their number and Accounting gets their number while the Enterprise gets access to Both and can choose to Standardize on Either--or a Third.

The question was about definitions and the answer is about numbers. Asked afterwards whether the rule also holds when the dispute is over a master classification itself, I said it does: anyone relying on a number has to be able to say why it is what it is and how it got there. A report's number departs from the enterprise's when the report groups, filters or labels the mastered records by its own definition, so the accounting number in that answer is taken here as the figure built on the mastered definitions. Product categories are the usual case: a marketing grouping of products and the mastered category hierarchy give different revenue by category from the same records.

"Usually, yes" is the headline, and the condition is the whole of the rule. A department does not keep its own number because it owns its reports. It keeps it because it can say why its number has to differ from the accounting number and how it is produced, which is the same as showing that it understands the process behind both. A department that can do that has a number it can defend in any meeting. A department that cannot has a preference.

Three things about the rule are worth drawing out. First, the test is not an approval. Nobody on the master side signs the marketing number off; the department either can explain the difference or it cannot, and the explanation is the governed artefact, written down next to the number where both sides can read it. That keeps the analytical model's own routine intact: no second approval queue, only an obligation to explain. Second, both numbers survive. Marketing reports its figure, Accounting reports its own, and neither is overwritten to make a meeting tidier. Third, the enterprise keeps the last word on the standard without having to use it. It sees both numbers, and it may choose to standardise on either or to adopt a third, at its own level. Standardising does not retire the department's figure; the department has to agree to that.

That last step is the same shape as the rule I gave for master data with two owners, in Mastered by the Domain, Republished by the Hub: when two domains will not agree on an attribute, split it into two columns and let the enterprise pick one standard or adopt a third. The conflict I meet at almost every client is over product category hierarchies, because Marketing, Sales, Production and Accounting so rarely group products the same way. The report-versus-master case is the same rule one level up. The master side holds the enterprise's standard; a department's number sits beside it with its reasons; the enterprise decides whether, and when, to standardise.

A department that cannot explain its number has, on the same rule, to find out, because the business is running on a number nobody can justify. Until it can, the number has not met the condition, so it has no claim to stand beside the enterprise's figure as an alternative. If the department still insists, the disagreement is no longer about definitions; it is a conflict, and conflicts go to the rule I gave in Rules of Decreasing Strictness: the decider decides. Whoever holds the authority, and above all the power to enforce it, makes the call, and the other side lives with it. I would not soften that into a council vote. On paper the executives are peers, but budgets and responsibilities make a real hierarchy, and the decision goes to whoever sits at the top of it.

The condition does a second job that is easy to miss. Because the difference usually comes from grouping, filtering or labelling the same mastered values, a department asked to explain it will often find that the explanation reduces to a mapping. That is the cheap outcome. A definitions dispute that turns out to be a grouping needs a written mapping, not an escalation.

What would show this is wrong

The claim can be put narrowly. An enterprise that runs its analytical governance through its master data operating model (one approval queue, one certification authority, one set of success measures for both) will deliver analytics more slowly without getting more consistent definitions, because the consistency it wants lives only at the shared definitions, and those can be governed without governing everything else. The narrow claim rules something out: it says a single routine covering both kinds of data does not buy consistency that a governed seam would not.

Three kinds of evidence would count against it. A body of work showing that unified programmes produce more consistent reporting than split ones would. So would evidence that the shared definitions cannot be governed separately, because report-level choices leak back into master data whatever the seam says. And so would the vendors and frameworks treating master and analytical governance as one routine in their own designs.

The first finds no support either way. This article's search of the frameworks' public pages, the analyst and consulting material above, and the practitioner research with stated samples found no study that compares a single governance operating model with two for these outcomes; that absence is scoped to what was searched, and I would not read it as evidence for either side. What the search did find is suggestive and no more. In a 2024 survey of more than 565 data and analytics professionals run with Drexel University's LeBow College of Business, inconsistent data definitions and formats were a top concern for 45%, while 71% of organisations reported having a data governance programme [20]. Having a programme has not made the definitions consistent. That fits my reading, but it fits several others too, and I would not lean on it.

The second is the serious one, and my own record supplies a version of it. Once the business relies on a number, even a wrong one, correcting it gets harder, because forecasts are built on it and regulatory reports may have to be restated; I made that point about master data in Mastered by the Domain, Republished by the Hub, and it applies here. A report definition that drifts from the master for long enough becomes a fact the business defends. That does not argue for one model. It argues for governing the seam early and keeping the mapping honest, which is what the first case asks for.

The third is not what the designs cited here show. The platforms distinguish the two, even inside one product: Microsoft gives master data and certified analytical content different badges, with separate lists of who may apply each [11], Purview offers functional-unit domains such as sales or finance and data domains for organisation-wide entities such as customers as different kinds of governance domain [21], and the semantic-layer tools centralise metric definitions inside analytics without reaching into the master record [18]. Gartner, which keeps one umbrella, gives the two sides different styles of governance under it [7].

Building the two at enterprise scale

None of this needs a new framework. It needs two charters and one dictionary, and the discipline to keep each in its place. These are my recommendations, drawn from the model; they are not a programme I have watched an enterprise run end to end:

1. A master data charter built on the ladder. Enterprise rules for systems compatibility, naming and documentation; a map of which domain answers for which attributes; each domain's own rules stated. Success is measured in what does not break downstream.
2. An analytics charter built on consumers. Every governed data set has an owner (the consumer group that uses it or, where several groups rely on it, the provider one level above them), a stated use and a stated meaning for each measure, and an endorsement level that says who may rely on it for what. Success is measured in decisions made from data people can explain.
3. One dictionary at the seam. A short, explicit list of shared definitions (the conformed dimensions, in Kimball's terms), owned by the master side, with every departmental alternative recorded beside it with its reasons, and retired only when the department agrees to migrate off it and understands the implications.
4. An explanation beside every departmental number. Why it differs from the enterprise's figure and how it is produced, kept where both sides can read it; that explanation is what lets the department keep the number.
5. A named decider for the conflicts that remain. Written down before the first one, and with the power to enforce the call, not only the title.
6. No second approval queue. The analytics side does not wait on the master side for anything that does not touch the dictionary.

Two models, one dictionary

I started with a sentence a governance office will resist: the user of the data owns it. It holds up, and it holds on both sides once ownership follows use rather than origin. The consumer owns the analytical data set they use to decide; the master record, used by every system the enterprise runs, is owned by the enterprise through its standards. Those are two kinds of ownership, run by two routines and judged by two measures, and putting them under one routine has not been shown to make the definitions more consistent; the consistency it seeks lives at the seam. What one routine does, I would argue, is make analytics slower and master data governance busier with things that are not its job.

What the two models share is narrow and has to be exact: the definitions both use, governed once on the master side, with every departmental alternative mapped back to them. Where a report and the master disagree, the report usually wins in its own reports, on one condition: the department can say why its number differs and how it is made. Then both numbers stand and the enterprise may choose between them. Where the department cannot say, the number has not earned its place, and anything still contested goes to the decider.

References

[1] DAMA International, "DAMA Data Management Body of Knowledge (DMBOK)" learning-resource page and "DMBOK2R Infographics," dama.org, undated. Read 2026-10-28; the book text itself is paywalled and was not read. https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/

[2] Bryan Petzold, Matthias Roggendorf, Kayvaun Rowshankish and Christoph Sporleder, "Designing data governance that delivers value," McKinsey & Company, 26 June 2020. Read in full 2026-10-28. https://www.mckinsey.com/capabilities/quantumblack/our-insights/designing-data-governance-that-delivers-value

[3] Gartner, "Adopt a Data Governance Approach That Enables Business Outcomes" (data governance topic page), gartner.com, undated. Public page read in full 2026-10-28. https://www.gartner.com/en/data-analytics/topics/data-governance

[4] Data Governance Institute, "Defining Data Governance," datagovernance.com, 5 August 2020 (modified 25 November 2024). Read in full 2026-10-28. https://datagovernance.com/defining-data-governance/

[5] Warren Thornthwaite, "Kimball University: Pick the Right Approach to MDM," InformationWeek, 7 February 2007. Read in full 2026-10-28; the page's byline is InformationWeek Staff and its author note names Warren Thornthwaite. https://www.informationweek.com/it-sectors/kimball-university-pick-the-right-approach-to-mdm

[6] David Hatch, "Is One Version of the Truth Still Achievable?," TDWI, 8 October 2008. Read in full 2026-10-28; it reports an Aberdeen Group survey of over 200 professionals from 155 companies (August–September 2008). https://tdwi.org/articles/2008/10/08/is-one-version-of-the-truth-still-achievable.aspx

[7] Saul Judah, "Choose Adaptive Data Governance Over One-Size-Fits-All for Greater Flexibility," CDO Trends, 25 May 2022. Read in full 2026-10-28; a Gartner analyst's byline in a trade outlet. https://www.cdotrends.com/story/16475/choose-adaptive-data-governance-over-one-size-fits-all-greater-flexibility

[8] Saul Judah and Remi Gulzar, "How D&A Leaders Can Use Adaptive Governance to Drive Better Business Outcomes," Gartner, 29 August 2024. The abstract read 2026-10-28; the report is paywalled and was not read. https://www.gartner.com/en/documents/5716651

[9] Gartner, "Master Data Management" topic page, gartner.com, undated. Public page read in full 2026-10-28. https://www.gartner.com/en/data-analytics/topics/master-data-management

[10] Microsoft, "Microsoft Fabric adoption roadmap: Content ownership and management," Microsoft Learn, updated 30 December 2024. Read in full 2026-10-28. https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-content-ownership-and-management

[11] Microsoft, "Endorsement overview," Microsoft Fabric documentation, Microsoft Learn, updated 11 July 2024. Read in full 2026-10-28. https://learn.microsoft.com/en-us/fabric/governance/endorsement-overview

[12] Zhamak Dehghani, "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh," martinfowler.com, 20 May 2019. Read in full 2026-10-28. https://martinfowler.com/articles/data-monolith-to-mesh.html

[13] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020. Read in full 2026-10-28. https://martinfowler.com/articles/data-mesh-principles.html

[14] Kiran Prakash, "Designing data products," martinfowler.com, 10 December 2024. Read in full 2026-10-28. https://martinfowler.com/articles/designing-data-products.html

[15] Kimball Group, "Conformed Dimensions," Kimball Dimensional Modeling Techniques, undated. Read in full 2026-10-28. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/conformed-dimension/

[16] Kimball Group, "Enterprise Data Warehouse Bus Matrix," Kimball Dimensional Modeling Techniques, undated. Read in full 2026-10-28. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/enterprise-data-warehouse-bus-matrix/

[17] Margy Ross, "Design Tip #135: Conformed Dimensions as the Foundation for Agile Data Warehousing," Kimball Group, 1 June 2011. Read in full 2026-10-28. https://www.kimballgroup.com/2011/06/design-tip-135-conformed-dimensions-as-the-foundation-for-agile-data-warehousing/

[18] dbt Labs, "dbt Semantic Layer," dbt documentation, updated 29 September 2026. Read in full 2026-10-28. https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl

[19] Microsoft, "Glossary terms in Unified Catalog," Microsoft Purview documentation, Microsoft Learn, updated 24 April 2026. Read in full 2026-10-28. https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms

[20] Precisely, "New Global Research Points to Lack of Data Quality and Governance as Major Obstacles to AI Readiness," press release, 18 September 2024, on research run with Drexel University's LeBow College of Business. Press release read in full 2026-10-28; the full report was not read. https://www.precisely.com/press-release/new-global-research-points-to-lack-of-data-quality-and-governance-as-major-obstacles-to-ai-readiness/

[21] Microsoft, "Governance domains in Unified Catalog," Microsoft Purview documentation, Microsoft Learn, updated 3 October 2025. Read in full 2026-10-28. https://learn.microsoft.com/en-us/purview/concept-governance-domain