Data Mesh

Data mesh changes who is responsible for analytical data. In a traditional setup, a central data team collects data from across the organization into a warehouse or lake, cleans it and serves it to analysts. As demand grows, that team becomes a bottleneck, and its members often lack the business knowledge to understand the data they manage. Data mesh moves responsibility to the business domains that create the data, such as sales, logistics or finance, which publish it as well-defined data products for others to use.

The approach was described by Zhamak Dehghani in 2019 and has since been widely discussed and adopted, in full or in part, by large organizations with many data sources and teams. It is as much an organizational change as a technical one. For enterprise architecture and IT finance, data mesh offers a way to scale data use without a single central bottleneck, but it requires investment in platforms, skills and governance, and it shifts data costs from a central budget to the domains that own the data.

Definition of Data Mesh

Data mesh is a sociotechnical approach to data architecture for analytical data. It distributes ownership of data to business domains while providing shared infrastructure and standards so that data from different domains can be combined.

It contrasts with centralized patterns such as a single enterprise data warehouse, and is often compared with data fabric, which uses metadata and automation to connect data without necessarily changing who owns it.

The Four Principles

Domain ownership means the teams closest to the data, who understand its meaning and quality, are responsible for making it available for analysis.

Data as a product means each domain treats its published data as a product with users. Data products should be easy to find, well documented, reliable and accompanied by clear quality commitments.

A self-serve data platform provides shared tools for storage, processing, publishing and access, so that domains can build data products without each creating its own infrastructure.

Federated computational governance sets common standards, such as security, privacy, interoperability and definitions, agreed across domains and enforced automatically by the platform where possible.

What a Data Product Includes

A data product contains the data itself, along with the code and pipelines that produce it and the infrastructure that serves it.

It also includes metadata, such as definitions, owners, quality measures and update schedules, usually published in a data catalog so other teams can find it.

Each data product has an owner responsible for its quality and for responding to the needs of the teams that use it. Clear interfaces let other domains use the product without depending on its internal details.

Importance of Data Mesh in Enterprise Architecture

Data mesh addresses the scaling limits of centralized data teams. As the number of sources and users grows, distributing ownership allows more work to happen in parallel.

It improves data quality by placing responsibility with the people who understand the data best and who are closest to the processes that create it. Problems can be fixed at the source rather than patched by a central team further downstream.

It also aligns data with business architecture. Data products are organized around business domains, which makes them easier to relate to capabilities and value streams.

Cost and Organizational Implications

Data mesh moves effort and cost from a central team to domain teams. Domains need data engineering skills and budget to build and maintain their products.

The shared platform requires significant investment, and without it, each domain may build its own tools, raising costs and fragmenting the architecture.

Costs become more visible to domains, since they own the storage and processing for their products. This can encourage efficiency but requires clear cost allocation rules for shared platform costs.

Organizations with few data sources or small data teams may find the overhead of data mesh greater than its benefits.

Common Challenges

Domains may lack the skills or motivation to treat data as a product, especially if their main focus is running operational systems. Incentives and recognition for data product owners help, as does measuring how widely each product is used.

Without strong governance, data products may use inconsistent definitions, making it hard to combine data across domains.

Some data, such as customer or product data used by many domains, does not fit neatly into a single domain and may still need central management through practices such as master data management.