{"id":81174,"date":"2024-10-16T11:34:24","date_gmt":"2024-10-16T09:34:24","guid":{"rendered":"https:\/\/intellias.com\/?post_type=blog&p=81174"},"modified":"2025-07-10T10:47:43","modified_gmt":"2025-07-10T07:47:43","slug":"data-mesh-vs-data-fabric","status":"publish","type":"blog","link":"https:\/\/intellias.com\/data-mesh-vs-data-fabric\/","title":{"rendered":"Data Mesh vs. Data Fabric: Choosing the Right Approach for Your Enterprise"},"content":{"rendered":"
This article details the key difference between the data fabric and the data mesh\u2014their unique design concepts, architectures, philosophies, and use cases. Understanding these approaches is essential if you’re looking to optimize your organization’s data strategy<\/a> and harness the full potential of your data assets. To that end, we\u2019ll break down their key characteristics, compare their strengths, and provide guidance on when to implement each.<\/p>\n When you finish reading, you’ll understand how data mesh and data fabric can transform your data management practices.<\/p>\n Data-driven decision-making becomes accessible with the right partner. Let Intellias guide you through your data journey.<\/p>\n A data mesh is a decentralized approach to managing and integrating data. It distributes data ownership to domain-specific teams, such as human resources, sales, finance, and legal. This approach follows a principle called domain-oriented data ownership, which distributes data ownership to the teams closest to it.<\/p>\n Data mesh takes a federated approach to data governance. That means that although different domains own the data, there are universal, standardized governance policies that every domain must follow. Think of it like the United States. Federal laws govern the entire country and trade between states, but most governance is left up to individual states.<\/p>\n It\u2019s more accurate to say that data mesh is a methodology rather than a technology. While implementing a data mesh may involve adopting new tools, it primarily represents a shift in data management processes, organizational structure, and culture. Data mesh is built around four core principles:<\/p>\n Data ownership is decentralized, with specific business domains (marketing, finance, etc.) taking responsibility for the data they generate. Each domain is accountable for managing, sharing, and governing its data, ensuring that it meets the needs of data consumers across the organization. This structure encourages domain experts to curate and steward data, leading to higher quality and relevance.<\/p>\n Each domain treats its data as a product, emphasizing usability, quality, and discoverability. Data should be designed to meet the needs of its users, with clear documentation, defined SLAs, and intuitive interfaces. Like any product, data should be continuously improved based on feedback, ensuring it remains valuable and accessible to a broad range of stakeholders, including cross-functional teams.<\/p>\n Data mesh promotes a self-service approach, enabling teams to access, use, and analyze data without needing to rely on a centralized data team. This requires robust, scalable, and user-friendly infrastructure that makes it easy for users to explore and use data with minimal friction. Tools for data discovery, lineage, and transformation are essential to making this principle a reality.<\/p>\n Although data ownership is distributed across domains, there is still a need for overarching governance to ensure consistency and compliance<\/a> across the organization. Federated governance establishes enterprise-wide standards and policies while allowing domains the flexibility to adapt to their specific needs. This balance helps maintain data quality and security without stifling innovation and agility at the domain level.<\/p>\n By focusing on these four principles, data mesh shifts the paradigm from centralized data management to a decentralized, domain-oriented approach to align data strategy more closely with business needs.<\/p>\n In the context of data mesh, a business domain is a specific function, operation, or area of responsibility within an organization. Every organization may define its domains as it sees fit, but domains are often organized by department (e.g. customer service) or function (e.g. order management).<\/p>\n Identifying suitable domains is critical for developing a data mesh because it is the basis for delegating responsibility for data.<\/p>\n One of the fundamental tenets of data mesh is that the teams within each domain have the best understanding of their data. So they are the best positioned to manage the data so it suits their needs. If the domains are poorly chosen, it\u2019s more difficult to build an effective data mesh.<\/p>\n Domain-driven data is a data management concept inspired by a software development concept called domain-driven design (DDD), popularized by Eric Evans<\/a>.<\/p>\n Domain-driven design and domain-driven data share a few commonalities, which include:<\/p>\n Where domain-driven data is distinct from domain-driven design in its scope, artifacts, and stakeholders.<\/p>\n Domain-driven data focuses on data modeling, governance, and management, is implemented in data storage systems, and involves data engineers, data scientists, business analysts, and domain experts.<\/p>\n A cloud-native infrastructure is ideal for data mesh but isn\u2019t technically required. It\u2019s possible to implement a data mesh using on-premise infrastructure, though it will require significantly more effort and expense.<\/p>\n The benefits of using a cloud-native infrastructure to implement a data mesh are numerous and compelling. These benefits include:<\/p>\n Zalando, a European e-commerce company, built a data mesh to manage complex, distributed data. They organized their data around business domains such as Order Management, Product, and Customer.<\/p>\n And while there were company-wide standards for data security, interoperability, and quality, each team had autonomy in implementation. Based on these standards, each team created data products that other teams could consume from the self-serve infrastructure Zalando built. Dr. Alexander Borek, Director of Data Analytics at Zalando, details their approach on The Data Chief podcast<\/a>.<\/p>\n To make this example more concrete, imagine Zalando\u2019s data science team wanted to better predict customer churn.<\/p>\n Under the old paradigm, they had to collect data from different departments including interaction history, purchase history, engagement data, and browsing data. They\u2019d then need to prepare and clean the data before they could even start building and deploying their churn prediction model.<\/p>\n With the data mesh, the data science team can access data products from each department for interaction, purchase history, engagement, and browsing data. And because each data product adheres to company-wide standards, there\u2019s no need for a lengthy integration process. Zalando can now update and deploy churn prediction models much faster and more frequently to better inform customer retention activities.<\/p>\n Data fabric is also a relatively new, continuously emerging data integration and management design concept. It uses advanced data technologies, like knowledge graphs and AI\/ML on active metadata to create scalable, augmented data integration pipelines that support different use cases on multiple data platforms.<\/p>\n Despite what many organizations may be led to believe, data fabric is not a single solution. Unfortunately, because most organizations can\u2019t clearly define data fabric, they purchase technology that only solves specific problems. This exacerbates the issue data fabric aims to solve because it results in new, additional data silos.<\/p>\n Essentially, the data fabric processes active metadata from various systems and offers automated alerts and recommendations to improve data integration, enhancing the user experience. Some mature enterprises have achieved this effect without data fabric, but maintaining it relies on manual efforts, which is unsustainable.<\/p>\n Data fabric is not a single technology, or even a group of technologies. It\u2019s a design approach to data management that is metadata-driven. This is in contrast to traditional data management paradigms which are driven by static data models and manual processes.<\/p>\n In fact, implementing data fabric can be done without removing or replacing existing systems. Instead, existing systems supply the data fabric with their metadata which is analyzed to provide insights and recommendations on data management. These recommendations automate data management decisions, such as what integration process to use and how and where to store data.<\/p>\n A centralized data integration layer is the hub that collects, processes, and combines data from various systems.<\/p>\n This layer is not unique to data fabric. It\u2019s present in every data management architecture. In traditional architectures, the data warehouse serves as the centralized data integration layer. Some enterprises use data lakes<\/a> as the centralized integration layer.<\/p>\n The key distinction in a data fabric is that its data integration layer is enhanced by active metadata, automation, and AI\/ML.<\/p>\n It bears repeating that there is no single data fabric solution you can buy. Obtaining a data fabric requires assembling and combining different tools from different vendors. Not only that, you\u2019ll need data engineers with the skills to make everything work<\/a>.<\/p>\n That said, according to Gartner<\/a>, there are several capabilities you\u2019ll need to implement a data fabric. These capabilities include:<\/p>\n Examples of vendors who provide solutions for implementing a data fabric include Denodo, IBM, TopQuadrant, Qlik, Informatica, and Cambridge Semantics.<\/p>\nWhat is data mesh?<\/h2>\n
Is data mesh a technology or a methodology?<\/h3>\n
\n
Domain-oriented data ownership<\/h4>\n<\/li>\n<\/ol>\n
\n
Data as a product<\/h4>\n<\/li>\n<\/ol>\n
\n
Self-serve data access<\/h4>\n<\/li>\n<\/ol>\n
\n
Federated data governance<\/h4>\n<\/li>\n<\/ol>\n
What is a business domain?<\/h3>\n
What is domain-driven data?<\/h3>\n
\n
Why does data mesh need a cloud-native infrastructure?<\/h3>\n
<\/p>\n\n
Example of data mesh in action<\/h3>\n
What is data fabric?<\/h2>\n
Is data fabric a technology or a methodology?<\/h3>\n
What is a centralized data integration layer?<\/h3>\n
Examples of data fabric solutions<\/h3>\n
\n
Data mesh vs. data fabric at a glance<\/h3>\n