Data Mesh vs. Data Fabric vs. Data Lakehouse: What Really Makes Sense

The Starting Point: Three Terms, One Confusion

Anyone serving as a Chief Data Officer and responsible for a data strategy today hears three terms very frequently: data mesh, data fabric, and data lakehouse. Vendors often position them as alternatives. Consultants recommend one one day and the other the next. And the question lingers on the executive board: What kind of data architecture do we actually need?

The honest answer is: The question is framed incorrectly. The three concepts operate on different levels.

Comparing them directly is like comparing an organizational chart to a network diagram and a building. All three are important. But they answer different questions.

In this article, we’ll clearly define these terms. We’ll show when each approach makes sense, where the typical pitfalls lie, and how you can make a decision that will still hold up in five years. In doing so, we’ll also deliberately focus on the aspect that’s missing from most architecture debates: the quality and consistency of the master data that flows through each of these architectures.

What Are Data Mesh, Data Fabric, and Data Lakehouse?

Before we compare them, we need clear definitions. Many misunderstandings arise because the terms are used loosely. The following definitions are based on the primary sources for each concept.

Data Mesh: Definition

Data Mesh is a decentralized, socio-technical organizational model for analytical data. Business domains take responsibility for their data and make it available as data products—on a shared self-service platform and under federated governance.

The term was coined by Zhamak Dehghani, then at Thoughtworks, in May 2019. Her starting point was an observation: centralized data platforms based on a data lake share “common patterns of failure that lead to unfulfilled promises at scale.” A centralized data team becomes a bottleneck because it would need to understand the domain expertise of all domains.

In December 2020, Dehghani formulated four principles:

1. Domain-oriented, decentralized data ownership: The business units that generate data are also responsible for making it available for analysis.

2. Data as a product: Data is treated like a product—with clear consumers, quality commitments, and documentation.

3. Self-service data infrastructure as a platform: A central platform relieves the domains of technical complexity.

4. Federated, automated governance: Global standards are defined collaboratively and enforced within the platform as automatically as possible.

It is important to note: Data Mesh is not software you can buy. It is, above all, a decision about who in the company is responsible for data. The technology follows this decision.

Data Fabric: Definition

Data Fabric is an architectural and design concept that connects distributed data sources via a metadata-driven integration layer. The goal is to provide unified, highly automated access to data—regardless of where it is physically located.

Gartner describes data fabrics as “flexible, resilient integration of data across platforms and business users.” IBM defines the data fabric as a modern data architecture that breaks down silos using “intelligent and automated systems” and optimizes data management at scale.

Metadata is at the core of a data fabric. This refers not only to technical metadata such as table names and data types. It also includes business concepts, data lineage, usage patterns, and quality characteristics. From this metadata, a Data Fabric can derive recommendations, partially automate integrations, and centrally enforce policies.

Unlike Data Mesh, Data Fabric does not primarily focus on the organization. It focuses on the technology. Responsibility for data can remain centralized or be distributed—the Fabric works in both cases.

Data Lakehouse: Definition

A data lakehouse is a platform architecture that combines the low-cost, open object storage of a data lake with the management and performance capabilities of a data warehouse—such as ACID transactions, versioning, indexing, and query optimization.

The concept was described in a 2021 research paper by Michael Armbrust, Ali Ghodsi, Reynold Xin, and Matei Zaharia (Databricks, UC Berkeley, Stanford). The authors define the lakehouse as “a data management system based on cost-effective and directly accessible storage that also offers classic analytical DBMS capabilities.”

The motivation stemmed from a problem with the two-tier architecture—consisting of a data lake and a data warehouse—that was prevalent at the time. According to the paper, it is “difficult and expensive” to keep both systems consistent. New data often took days to reach the warehouse. And companies paid twice for storage because data had to be copied.

In practice, a lakehouse is often organized into layers. Databricks calls this pattern the Medallion architecture: a Bronze layer with raw data, a Silver layer with cleaned and merged data, and a Gold layer with ready-to-use data models. According to Databricks, the Silver layer is intended to provide an “enterprise view” of all core business objects. This is precisely where the consistency of the data is determined—more on that later.

In Comparison: Data Lake and Data Warehouse

To put these three concepts into perspective, it’s worth taking a look at their predecessors.

According to IBM, a data warehouse consolidates data from various sources into a central repository optimized for queries and analysis. The data is cleaned and structured into a fixed schema before being loaded. This makes data warehouses reliable for reporting. However, it also makes them inflexible and expensive when dealing with large, unstructured data sets.

According to IBM, a data lake stores large volumes of raw data “in its original state,” typically in cost-effective cloud object storage. This provides flexibility, for example, for machine learning. However, IBM also warns of the well-known risk: without metadata, structure, and governance, data lakes become “data swamps” where good data can no longer be found.

We’ve described how a data warehouse differs from operational master data management in a separate article: Data Warehouse vs. Multi-Domain Master Data Management.

A Brief History of Data Architecture

These three concepts are responses to the problems faced by their predecessors. Understanding their evolution provides a clearer picture of which problem each concept solves.

The last line is noteworthy. After decades of discussion about storage, platforms, and organization, the question of the significance of data has taken center stage. That is precisely the core of master data management.

Summing it up in one sentence

A simple analogy helps. Imagine your data landscape as a city:

• The Data Lakehouse is the building where data is stored and processed.

• The Data Fabric is the network of streets and utility lines that connects all the buildings.

• The Data Mesh is the city government: it determines which district is responsible for what and ensures that construction follows common rules.

• Master data is the land registry and the city map. Without it, no one knows which property belongs to whom or which street leads where.

This illustration already highlights the central thesis of this article: The question is rarely “Mesh or Fabric or Lakehouse?” Instead, it is: “Which combination fits our organization—and do we have the foundation for it?”

Why Is the Choice of Data Architecture So Important in 2026?

The question of architecture is no longer just a technical detail. It determines whether AI projects can scale, whether regulatory requirements are met, and whether investments in data platforms pay off. Five key metrics explain why.

KPI 1: AI Fails Because of Data, Not Models

Gartner predicts that by the end of 2026, companies will abandon 60% of AI projects that are not supported by AI-ready data. In the same survey of 1,203 data management leaders, 63% stated that they do not have the right data management practices for AI—or are unsure whether they do.

In terms of architecture, this means that a new lakehouse or data fabric does not automatically solve the problem. What matters is whether the data within it is trustworthy, consistent, and semantically understandable.

KPI 2: Successful companies invest in the foundation

A Gartner survey of 353 D&A and AI leaders shows that companies with successful AI initiatives invest up to four times more (as a percentage of revenue) in fundamentals such as data quality, governance, and change management than companies with poor AI outcomes. According to Gartner, companies with the highest maturity in AI-enabled data achieve up to 65% better business results.

KPI 3: Governance Initiatives Fail Without Business Alignment

Gartner expects that by 2027, 80% of data and analytics governance initiatives will fail—whether due to a real crisis or one deliberately engineered. Gartner analyst Saul Judah sums it up: “A D&A governance program that does not enable prioritized business outcomes will fail.”

This is particularly relevant for Data Mesh. Federated governance is one of its four principles. If governance isn’t tied to business objectives, it primarily spreads chaos throughout the mesh.

KPI 4: Semantics Becomes a Cost Factor

In May 2026, Gartner predicted that companies that prioritize semantics in AI-enabled data will increase the accuracy of their agent-based AI by up to 80% and reduce costs by up to 60% by 2027. Gartner recommends establishing a context layer as an integral part of the D&A infrastructure.

Semantics here means that all systems understand “customer,” “company,” or “product” to mean the same thing. It is precisely this shared meaning that is provided by master data and a consistent golden record.

KPI 5: German companies are barely tapping into their data potential

According to a Bitkom study on the data economy, 60% of German companies with 20 or more employees are tapping into their data potential “rather little” or “not at all.” A total of 605 companies were surveyed. The picture is similar at the executive level as well: In the 2026 Deloitte CDAO survey, 95% of the Chief Data and Analytics Officers surveyed stated that their companies were not fully leveraging the value of their data. 61% cited data quality and data access as critical to AI success.

Key metrics at a glance

The message these figures convey is clear. Companies rarely have a storage or computing problem. They have a problem with the accountability, relevance, and quality of their data. Every architectural decision must be judged by whether it solves this problem.

The 4 Root Causes: Why Data Architectures Fail to Deliver on Their Promises

Data warehouse, data lake, data lakehouse—each generation promised to solve the data problem once and for all. Yet many companies today face similar questions as they did ten years ago. This is rarely due to the technology chosen. It stems from four root causes that every architecture inherits if no one actively addresses them.

Root Cause 1: Responsibility Without Domain Expertise

In many companies, a central data or BI team is responsible for all analytical data. This team understands the technology but lacks domain expertise. It knows how to build a pipeline, but it doesn’t always know why the sales department counts a customer differently than the accounting department.

It was precisely this observation that served as the starting point for Data Mesh. Dehghani explains that centralized platforms consolidate data ownership in one place and isolate specialists from data sources and data consumers. The result is long queues and data that is technically correct but semantically ambiguous.

Root Cause 2: Lack of Shared Meaning

The second reason is semantic. Every operational system has its own understanding of key business objects.

In ERP, a customer is a customer ID. In CRM, it is an account with multiple contacts. In investment management, the same company might be an entity with its own legal form and ownership stake.

If this data is loaded into a lakehouse or connected via a fabric, the inconsistencies remain. They simply become visible more quickly—or worse: they are carried over unnoticed into reports and AI models. Gartner warns against exactly this: Without semantics and business context, AI agents operate inaccurately and are prone to hallucinations.

Root Cause 3: Governance as a Document Rather Than a Process

Many governance programs produce policies, role descriptions, and glossaries. What’s missing is their integration into day-to-day operations. A data policy that exists only as a PDF isn’t validated by any pipeline and isn’t put into practice by any business unit.

Gartner confirmed this in September 2026: In a survey of 223 D&A leaders, cultural resistance was the most important reason for the failure of governance initiatives—more important than a lack of budget (60% versus 40%). Gartner analyst Anurag Raj adds: AI-ready data also requires “AI-ready stakeholders.”

Root Cause 4: Architecture as a Substitute for Strategy

The fourth cause is strategic. Companies purchase a platform before they know which business questions they want to answer with it. The architecture decision then becomes a substitute action. They migrate from the warehouse to the lake, from the lake to the lakehouse—and realize that data quality hasn’t changed.

An architecture is a tool. It amplifies what’s already there. Clear accountability, shared terminology, and good master data become more valuable through a modern architecture. Unclear accountability, contradictory terminology, and poor master data only become more costly as a result.

Not an architectural problem, but an ownership and semantics problem

At this point, it’s worth shifting our perspective. The “Data Mesh vs. Data Fabric vs. Data Lakehouse” debate is usually framed as a technological issue. In reality, each of the three concepts answers exactly one of three questions:

None of the three concepts fully answers a fourth question: What do the data mean—and which version is the correct one?

If the sales system counts 1,200 active customers and the ERP counts 1,450, no single architecture can help. Data Mesh assigns responsibility for each number to a separate domain—but which one is correct? Data Fabric connects both sources—but presents two truths. The Lakehouse stores both versions efficiently and with version control—but does not resolve the contradiction.

Master Data Management answers this fourth question. It defines what a customer, a company, or a product is. It merges duplicates and creates a Golden Record—the single, reliable version of a business object. Only this version makes data products in the Mesh comparable, links in the Fabric unambiguous, and the Silver Layer in the Lakehouse consistent.

The necessary shift is therefore this: Your data architecture does not have a storage problem. It has a meaning problem. Whoever first clarifies the meaning of the central business objects can then implement any of the three architectures more successfully.

Our article “Master Data Management: Definition and Practice” offers a detailed introduction to the topic.

Data Mesh vs. Data Fabric vs. Data Lakehouse: The Decision Matrix

Now we’re getting down to business. The following two tables are the heart of this article. The first systematically compares the three concepts—including data lakes and data warehouses for reference. The second translates that comparison into a decision tailored to your specific situation.

Systematic Comparison of Data Architectures

The Decision Table for Your Situation

The recommendations in this table are assessments based on the cited primary sources and our project experience; they are not rigid rules. They are meant to help you ask the right first question.

How to Read the Decision Table

Three patterns stand out.

First: A data mesh is almost never the starting point. It requires that business units be willing and able to take responsibility for data. Where this is not yet the case, a mesh leads to decentralized chaos.

Second: Data Fabric and Data Lakehouse often complement each other. The Lakehouse stores and processes data. The Fabric connects the Lakehouse to systems that cannot be migrated.

Third: One row affects all the others. If key business objects are inconsistent, the architectural decision becomes secondary. In that case, the first step is to establish the Golden Record.

Combinations Instead of Either/Or

In practice, large companies rarely opt for just one of the three concepts. Combinations are more common:

• Lakehouse + Fabric: The Lakehouse serves as the central analytical platform. The Fabric connects operational systems, legacy systems, and external sources without copying everything.

• Fabric + Mesh: The domains are responsible for data products. The Fabric provides the catalog, lineage, and automated policy enforcement. IBM describes precisely this interaction: A Data Fabric provides the capabilities to implement a Data Mesh by automating many tasks involved in creating data products (IBM, 2024).

• Mesh + Lakehouse: Each domain operates its data products on a shared lakehouse platform. The platform embodies the Mesh’s “self-service” principle in technical form.

Gartner also does not view Fabric and Mesh as opposites. In an analysis from January 2025, Gartner recommends combining both approaches—for example, to improve knowledge discoverability, achieve greater governance maturity, and strike a balance between centralized and domain-specific outcomes.

The Three Approaches in Detail: When They Really Make Sense

The tables provide a general direction. But to make an informed decision, you also need the details: What exactly does each approach offer, what does it cost, and how can you tell if you’re ready for it?

Data Mesh: When It Makes Sense—and When It Doesn’t

Data Mesh makes sense if your company consists of several large, functionally independent divisions. Typical examples include conglomerates with multiple business units, banks with separate divisions, or industrial companies with independent plants and product lines. In such organizations, a centralized data team is almost inevitably a bottleneck.

The Benefits:

• Expertise stays where it’s generated. Those who generate the data understand it best.

• The central data team is relieved of some of its workload and can focus on the platform.

• Data products have clearly defined owners, quality commitments, and consumers.

• The organization scales: New domains can be added without requiring a central team to grow along with them.

McKinsey describes the benefits of data products in concrete terms: New use cases could be implemented up to 90% faster, and total cost of ownership could drop by 30%. Important: McKinsey is referring here to the principle of “managing data as a product,” not to Data Mesh as an overall model. Data products are possible even without a complete mesh.

Data Mesh doesn’t make sense if:

• Your company has only a few business domains and a small data team is entirely sufficient.

• The business units lack both the capacity and the expertise to take responsibility for data products.

• There is no shared platform that handles the technical aspects for the domains.

• Central business objects have not yet been uniformly defined.

Many people underestimate the last point. In a mesh, each domain creates its own data products. If the “Sales” domain identifies a customer differently than the “Finance” domain, their data products cannot be reliably linked. Data Mesh therefore requires cross-domain reference data—that is, a shared “golden record” for customers, companies, products, or locations.

Maturity Indicator: You’re ready for Data Mesh if at least one business domain is already operating a data product with a clearly defined owner, documented quality, and actual consumers.

Data Fabric: When It Makes Sense—and When It Doesn’t

Data Fabric makes sense if your data landscape is heterogeneous and will remain so. This applies to most established companies in the DACH region: on-premises ERP systems, CRM in the cloud, line-of-business applications in individual departments, plus legacy systems that no one wants to touch anymore. A complete migration to a central platform is often neither economical nor realistic.

The advantages:

• Data stays where it is. The fabric provides uniform, logical access.

• A central catalog makes data discoverable and understandable.

• Policies—such as those regarding data protection or access rights—can be defined centrally and enforced everywhere.

• Metadata enables automation: from integration suggestions to quality monitoring.

Gartner clearly quantified the potential in 2021: The true value of a data fabric lies in its ability to dynamically improve data usage with built-in analytics—thereby reducing the effort required for data management by up to 70%. This figure should be viewed as an upper limit. It requires a mature metadata foundation.

A data fabric makes no sense if:

• Your metadata is incomplete or out of date. A fabric is only as intelligent as the metadata it operates on.

• You expect the fabric to automatically resolve conflicting data. It connects data; it does not harmonize it.

• Your data landscape is small and homogeneous. In that case, the effort involved outweighs the benefits.

Maturity Indicator: You’re ready for a data fabric if you maintain a data catalog with business terms and know which systems are the leading sources for your core business objects.

Data Lakehouse: When It Makes Sense—and When It Doesn’t

A data lakehouse makes sense if you currently operate two separate environments: a data warehouse for reporting and a data lake for data science. The lakehouse brings both together. It’s particularly attractive when AI and machine learning are playing an increasingly important role and you also want to use unstructured data such as documents, logs, or sensor data for these purposes.

The benefits:

• A single platform for BI, data science, and AI instead of two separate systems.

• Open data formats reduce dependence on individual vendors. The CIDR paper cites open, directly accessible formats such as Apache Parquet as a fundamental principle.

• ACID transactions and versioning ensure reliability and traceability.

• Lower storage costs thanks to cost-effective object storage.

Adoption is growing. In a Dremio-sponsored survey of 500 IT and data leaders from companies with more than 1,000 employees, 65% reported that they already run more than half of their analyses on a data lakehouse. Since the study was commissioned by a lakehouse provider, you should view this figure as an industry benchmark rather than a representative market share.

A data lakehouse doesn’t make sense if:

• Your analyses consist almost exclusively of structured, standard reporting, and your existing data warehouse is working well.

• You expect the platform to automatically ensure data quality. The Medallion layers structure the process—but you still have to perform the business-side data cleansing yourself.

• The migration is driven solely by enthusiasm for the technology, without concrete use cases.

Maturity indicator: You’re ready for a lakehouse if you can clearly identify which business objects are consolidated in the Silver layer as the “enterprise view”—and from which leading source they originate.

The Role of Master Data in Every Architecture

A common pattern runs through all three approaches. Every architecture needs a reliable reference for central business objects at a specific point:

That is why we do not view Master Data Management as a fourth alternative. It is the cross-functional layer that makes all three architectures viable. A multi-domain MDM delivers the Golden Record as a data product to the Mesh, as the leading reference to the Fabric, and as a trusted source to the Silver layer of the Lakehouse.

An Overview of the Most Common Direct Comparisons

Many questions do not revolve around all three concepts at once, but rather around specific pairs. The following sections provide concise answers to the three most common comparisons.

Data Fabric vs. Data Mesh: A Direct Comparison

These two terms are most often confused. Both promise to overcome data silos. However, the approaches to achieving this are fundamentally different.

The short version: The Data Fabric connects data. The Data Mesh distributes responsibility. If you want to quickly make a heterogeneous landscape usable, you’re more likely to start with the Fabric. If you see a central data team as a bottleneck, you’re more likely to lean toward the Mesh. And if you experience both, you combine the approaches.

Data Lakehouse vs. Data Warehouse: A Direct Comparison

The data warehouse has been the backbone of corporate reporting for decades. The lakehouse is emerging to complement or replace it.

The short answer: A data warehouse is ideal for known questions. A lakehouse is ideal when new questions and AI use cases arise. You don’t have to replace a functioning data warehouse just for the sake of it. However, if you’re running a data lake in parallel and copying data between the two, it’s worth considering a lakehouse.

Data Lake vs. Data Warehouse: The Classic Comparison

This comparison is older but important for understanding the concept. It explains why the lakehouse was developed in the first place.

For a long time, many companies operated both systems in parallel. It is precisely this two-tier architecture that the Lakehouse paper describes as costly and error-prone. The Lakehouse is an attempt to combine the strengths of both worlds into a single platform.

What This Means in Practice for CDOs and Data Stewards

An architectural decision affects different roles in very different ways. We summarize the implications for the two most important target audiences of this guide.

For Chief Data Officers

As a CDO, you are responsible for ensuring that the data strategy delivers measurable business value. When it comes to architecture, this means:

• Make decisions at the right level. Separate the questions “Who?”, “How?”, and “Where?”. This makes discussions with IT, business units, and vendors much clearer.

• Anchor the decision in the business. Don’t present an architecture to the executive board; instead, present use cases with expected benefits.

• Secure the foundation. Make master data quality an explicit part of the architecture roadmap, complete with a budget and designated responsible parties.

• Plan in stages. A target architecture featuring a mesh, fabric, and lakehouse can make sense. However, the path to getting there should consist of manageable, demonstrably successful stages.

For Data Stewards

As a data steward, you ensure data quality on a day-to-day basis. For you, each architecture changes your daily work in different ways:

In all three cases, your primary task remains the same: ensuring that a customer remains a customer and a company remains a company—across all systems. Tools with clear workflows for master data maintenance make this task scalable.

Approach: 6 Steps to the Right Data Architecture

How do you move from analysis to decision-making? The following roadmap has proven to be an effective framework. It is intentionally technology-neutral. It guides you from the business question to the architecture—not the other way around.

Step 1: Define Business Goals and Use Cases

Don’t start with the architecture. Start with three to five specific use cases that are intended to create value over the next 12 to 24 months. Examples: an AI assistant for customer service, consolidated group reporting, or automated reporting to regulatory authorities.

For each use case, clarify the following: What data is needed? How up-to-date does it need to be? Who will use the results? These questions will later determine which architecture is appropriate.

Step 2: Identify the Core Business Objects

List the business objects that appear in multiple use cases. There are usually only a few: customer, supplier, product, employee, company, and location. For each object, check the following:

• In which systems does it exist?

• Which system is currently the primary one—and is everyone aware of this?

• Is there a standardized definition?

• What is the percentage of duplicate or conflicting data records?

This step is unspectacular but crucial. It shows you whether your foundation is solid. You can find practical methods for this in our guide to improving data quality.

Step 3: Honestly Assess Your Organization and Maturity Level

Evaluate your organization based on four questions:

1. Are there individuals in the business units who are able and willing to take responsibility for data—such as data owners and data stewards?

2. Is there a governance body that makes and enforces decisions?

3. Are data policies technically implemented or merely documented?

4. How high is the level of data literacy outside of IT?

The answers will determine whether a Data Mesh approach is realistic or if a centrally managed approach is a better fit. The Data Governance Maturity Check, which we’ll introduce below, enables a structured assessment.

Step 4: Map the System Landscape

Take stock of your existing system landscape: What sources are there? Where are they located—on-premises, in the cloud, or with service providers? Which systems will be phased out in the coming years, for example as part of an S/4HANA migration?

If many systems will remain in place, this argues in favor of a Data Fabric. If consolidation is on the horizon anyway, a lakehouse can serve as the new analytical foundation.

Step 5: Design the Target Architecture as a Combination

Now use the decision table. Design the target architecture on three levels:

• Organization: Centralized, federated, or decentralized (mesh)?

• Integration: How are sources connected and metadata managed (fabric functions)?

• Platform: Where is data stored and processed (lakehouse, warehouse, or both)?

Add a fourth, often-overlooked layer: semantics and master data. Define where the Golden Record for each key business object is created and how it is distributed to Mesh, Fabric, and Lakehouse.

Step 6: Start with a lighthouse project and scale incrementally

Don’t implement everything at once. Choose a use case with high business value and manageable risk. Build the necessary components for it: the Golden Record for the relevant business objects, the integration of the sources, and the platform for analysis.

Measure success based on business metrics, not technical milestones. Only once the first use case delivers value should you scale to additional domains. This is how you link governance to business results—exactly what Gartner says determines success or failure.

The Roadmap at a Glance

Checklist: 10 Questions to Ask Before Making an Architectural Decision

Before committing to a data mesh, data fabric, or data lakehouse, you should be able to answer “yes” to the following questions. Every “no” indicates a gap that you should address first.

• Do we have three to five prioritized use cases with measurable business value?

• Are our core business objects defined consistently across the entire company?

• For each of these objects, do we know which system is the primary source of truth?

• Do we know the percentage of duplicate and conflicting data records?

• Are there designated data owners and data stewards in the business units?

• Are governance rules technically verified and not just documented?

• Do we maintain a data catalog with business terms and data sources?

• Do we know which systems will remain in use over the next three years?

• Can we trace the origin of data fed into AI models?

• Has the executive board linked the architectural decision to a business objective?

Fewer than six “yes” answers are a clear signal: Invest first in governance and master data. With seven to eight “yes” answers, a centrally managed lakehouse or fabric is a realistic option. With nine or more “yes” answers, you can also consider a data mesh. These thresholds are a guideline from our perspective, not a scientifically validated model.

Best Practices: What Really Works in Practice

Theory is one thing. What distinguishes data architectures that still deliver value after three years from those that end up as expensive platforms with no users? Seven principles have proven effective.

1. Semantics Before Technology

Clarify the meaning of key business objects before selecting a platform. An enterprise-wide glossary with authoritative definitions is the most cost-effective and powerful building block of any data architecture. It also serves as the foundation for the context layer that Gartner recommends for agent-based AI.

2. Clearly Define Leading Systems

For every business object and every attribute, it should be clear which system is the leading source. Is the ERP the leading source for a supplier’s bank account information? Is the investment management system the leading source for a company’s legal form? This clarification prevents mesh domains, fabric connections, or lakehouse pipelines from propagating conflicting truths.

3. Start Data Products Small and Specific

A data product does not need an enterprise-wide mesh strategy. Start with a product that has a clear consumer. Define responsible parties, quality commitments, update frequency, and documentation. Only once that is working should you move on to the next one.

4. Build governance into the platform

Federated governance only works if rules are checked automatically. Dehghani deliberately refers to “computational governance”—governance that is executed by the platform. This applies equally to Fabric and Lakehouse: access rights, classifications, and quality rules belong in the technology, not just in the manual. Our article on the Data Governance Framework illustrates what a viable framework looks like.

5. Traceability from the Start

Regulatory requirements increasingly demand that companies be able to document the origin and processing of their data. For high-risk AI systems, Article 10 of the EU AI Act requires that training, validation, and test data be subject to “data governance and data management procedures.” They must also be “relevant, sufficiently representative, and, to the extent possible, error-free and complete.”

Lineage in the Fabric, versioning in the Lakehouse, and a historized, reference-date-based master data management system are the technical solutions to these requirements. You can find more information about these obligations in our EU AI Act Guide for Businesses.

6. Use Real-Time Data Strategically

Not every use case requires real-time data. However, timeliness is becoming increasingly important for agent-based AI. Gartner expects the use of data streaming for agent-based AI to rise from less than 15% in 2025 to over 60% in 2028. Design your architecture to enable streaming where it adds value—without building every pipeline around it.

7. Treat Culture as Part of the Architecture

Even the best architecture will fail if no one lives by it. Gartner recommends repositioning data governance as a business enabler and a “team sport” and embedding it directly into business processes. For data stewards, this means their work must be visible and straightforward in day-to-day operations—for example, through clear workflows for approving and correcting master data.

Case Study: How a Central Golden Record Makes 1,400 Companies Manageable

Architecture debates often remain abstract. That’s why we’ll look at an example that shows why the quality of central business objects must precede every architectural decision.

The Initial Situation

PATRIZIA SE is an internationally active investment manager specializing in real estate and infrastructure. The company manages assets totaling over 50 billion euros through approximately 1,400 companies in more than 15 countries.

Employees needed quick access to investment structures. Organizational charts and reports for annual financial statements, bank inquiries, and KYC checks were created manually. This consumed a significant amount of time and resources.

The Solution

PATRIZIA uses the Goldright Legal Entity Manager. All investment data—including documents—is managed centrally and maintained with historical records. Organizational charts and reports are generated automatically at the click of a button. Reports based on specific cut-off dates are possible, and the solution is integrated with external systems.

The Results

Automated organizational charts and reports are now generated as needed. Historical ownership structures can be retrieved with just a few clicks. Data quality across the entire portfolio has improved significantly. Susanne Päsler, Legal Entity Management at PATRIZIA, emphasizes how much the automated ownership organizational charts have simplified her day-to-day work.

What This Case Means for Data Architecture

This case is not a data mesh or lakehouse project. That is precisely why it is instructive. It demonstrates what every data architecture in a company with over 1,400 subsidiaries needs first and foremost: a reliable, historical version of the corporate structure.

Imagine if a company were to build a data mesh without this foundation. The “Funds” domain would map companies differently than the “Finance” domain. A data fabric would connect both views—and reveal two conflicting corporate structures. A lakehouse would store both versions but would not determine which one is correct.

With a point-in-time “Golden Record” for companies, each of these architectures becomes viable. The Golden Record becomes the data product in the mesh, the leading reference in the fabric, and the trusted source in the silver layer of the lakehouse. This classification is our interpretation of the case—it describes the architectural principle, not a specific project at PATRIZIA.

Pitfalls: What to Avoid with Data Mesh, Data Fabric, and Data Lakehouse

Typical mistakes can be identified from the decision matrix. The following eight pitfalls are ones that companies encounter time and again.

Pitfall 1: Data Mesh as a Top-Down Reorganization

A mesh cannot be imposed via an organizational chart. If business units are given responsibility for data without the capacity, expertise, and platform to support it, a data culture will not emerge. Instead, new silos with new names will form.

Better: Start with a domain that is motivated and capable. Let the success speak for itself.

Pitfall 2: Treating Data Fabric as a Magic Tool

A Data Fabric promises automation. This automation is based on metadata. If the metadata is incomplete or contradictory, the fabric automates the gaps and contradictions.

Better: Invest first in a well-maintained catalog and unambiguous business terms.

Pitfall 3: The Lakehouse as a Larger Data Lake

Many lakehouse projects load data into the bronze tier and never achieve a reliable silver tier. The result is a modern data swamp—with better technology, but the same problems.

Better: Before you start, define which business objects will be harmonized in the Silver layer and who is responsible for them.

Pitfall 4: Architecture Without a Business Goal

When platform selection takes precedence over use cases, there is no yardstick for success. The project becomes a technology project.

Better: Link every architectural decision to measurable business outcomes.

Pitfall 5: Treating Master Data as an Afterthought

The most common mistake: Master data is scheduled as a topic for “later.” Later turns out to be too late, because duplicates and inconsistencies have already spread throughout data products, reports, and AI models.

Better: Establish the golden record for the most important business objects before or in parallel with the architecture. Our roadmap to an MDM strategy describes what an MDM strategy looks like.

Pitfall 6: Treating Terms as Synonyms

In project presentations, “data mesh” and “data fabric” are often used interchangeably. This leads to false expectations. Those who expect a mesh plan for organizational changes. Those expecting a fabric are planning for integration technology.

Better: Use the questions “Who?”, “How?”, and “Where?” from this article to clearly distinguish between terms in the project.

Pitfall 7: Underestimating vendor lock-in

Many platforms advertise themselves as “open.” Carefully examine which formats, catalogs, and interfaces are truly open. The Lakehouse concept was explicitly justified on the basis of open data formats.

Better: For each platform, assess how difficult a later switch would be.

Pitfall 8: Forgetting Data Stewards

Architectural decisions are often made between the CDO, IT, and vendors. Data stewards, who ensure data quality on a day-to-day basis, are rarely involved. Yet they are the ones who determine whether data products, fabric metadata, and silver layers remain reliable in production.

Better: Involve data stewards early on and give them tools that make their work easier.

Conclusion: Data Mesh, Data Fabric, or Data Lakehouse—What Really Makes Sense

Data Mesh, Data Fabric, and Data Lakehouse are not competitors. They address three different questions.

Data Mesh clarifies who is responsible for data. Data Fabric clarifies how distributed data is connected. The Data Lakehouse clarifies where and how data is stored and processed.

What really makes sense depends on your organization.

A centralized team with a clear focus on reporting usually starts with a Lakehouse. A heterogeneous, organically grown system landscape benefits from a Data Fabric. Large, autonomous business units with a high level of data maturity can scale with Data Mesh. In most companies, the result is ultimately a combination.

None of the three concepts alone answers one key question: What does the data mean, and which version is the correct one? This question determines whether your investment in a new data architecture creates value or merely makes existing inconsistencies more visible. The answer lies in a consistent “golden record” for your core business objects.

Our recommendation, based on the insights from this guide: Do not make the architectural decision in isolation. First, clarify your business goals, your core business objects, and your level of governance maturity. Then use the decision matrix to find the right combination. And start with a use case that delivers measurable value quickly.

The first step is to take an honest look at where you stand. The Data Governance Maturity Assessment will show you in about 15 minutes where your organization stands—and which data architecture is a realistic fit for you.

Sources

Armbrust, M., Ghodsi, A., Xin, R., Zaharia, M.: Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. - https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

Bitkom e. V.: Data Economy – Studienbericht - https://www.bitkom.org/sites/main/files/2025-09/bitkom-studienbericht-data-economy.pdf

Databricks: Medallion Architecture (Glossar) - https://www.databricks.com/glossary/medallion-architecture

Dehghani, Z.: How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh - https://martinfowler.com/articles/data-monolith-to-mesh.html

Dehghani, Z.: Data Mesh Principles and Logical Architecture - https://martinfowler.com/articles/data-mesh-principles.html

Deloitte: Chief Data and Analytics Officer Survey Finds CDAOs Acting as AI Trailblazers - https://www.deloitte.com/us/en/about/press-room/chief-data-and-analytics-officer-survey-finds-cdaos-acting-as-ai-trailblazers.html

Dremio / Propeller Insights: State of the Data Lakehouse 2024 - https://www.dremio.com/wp-content/uploads/2023/11/whitepaper-2024-state-of-the-data-lakehouse_report.pdf

EU AI Act, Artikel 10: Daten und Daten-Governance - https://artificialintelligenceact.eu/article/10/

Gartner: Gartner Identifies the Top Strategic Technology Trends for 2022 - https://www.gartner.com/en/newsroom/press-releases/2021-10-18-gartner-identifies-the-top-strategic-technology-trends-for-2022

Gartner: Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027 - 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-

Gartner: How Data Leaders Can Complement Fabric and Mesh Approaches - https://www.gartner.com/en/documents/6132959

Gartner: Lack of AI-Ready Data Puts AI Projects at Risk - https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

Gartner: Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations - https://www.gartner.com/en/newsroom/press-releases/2026-04-16-gartner-says-organizations-with-successful-ai-initiatives-invest-up-to-four-times-more-in-data-and-analytics-foundations

Gartner: Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending - https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending

Gartner: Gartner Identifies the Top Trends for Data and Analytics - https://www.gartner.com/en/newsroom/press-releases/2026-06-16-gartner-identifies-the-top-trends-for-data-and-analytics

Gartner: 60% of Organizations That Ignore Data Governance Culture Challenges Will Fail to Govern AI Successfully by 2027 - https://www.gartner.com/en/newsroom/press-releases/2026-09-21-gartner-predicts-60-percent-of-organizations-that-ignore-data-governance-culture-challenges-will-fail-to-govern-ai-successfully-by-2027

IBM: What Is a Data Fabric? - https://www.ibm.com/think/topics/data-fabric

IBM: Data management vs. data fabric vs. data mesh. - https://www.ibm.com/think/topics/data-management-vs-data-fabric-vs-data-mesh

IBM: What Is a Data Lake? - https://www.ibm.com/think/topics/data-lake

IBM: What Is a Data Warehouse? - https://www.ibm.com/think/topics/data-warehouse

McKinsey & Company: Desai, V., Fountaine, T., Rowshankish, K.: How to unlock the full value of data? Manage it like a product. - https://www.mckinsey.com/capabilities/quantumblack/our-insights/how-to-unlock-the-full-value-of-data-manage-it-like-a-product