Ventana Research Analyst Perspectives

Data mesh is the latest trend to grip the data and analytics sector. The term has been rapidly adopted by numerous vendors — as well as a growing number of organizations —as a means of embracing distributed data processing. Understanding and adopting data mesh remains a challenge, however. Data mesh is not a product that can be acquired, or even a technical architecture that can be built. It is an organizational and cultural approach to data ownership, access and governance. Adopting data mesh requires cultural and organizational change. Data mesh promises multiple benefits to organizations that embrace this change, but doing so may be far from easy.

The term data mesh was coined by Zhamak Dehghani, a principal technology consultant at Thoughtworks in 2019. It was proposed as a new tactic to shift away from centralized approaches to analytics built around monolithic analytic data platforms (such as data warehouses or data lakes) and adopt distributed ownership of data and metadata. Data mesh can be thought of as doing for analytical data what microservices did for functionality: distributing ownership and responsibility to domain experts, who make it available to be consumed by others across the organization. The data mesh concept is based on four key principles: domain-oriented ownership, data as a product, self-serve data infrastructure and federated governance. Domain-oriented ownership gives responsibility to business departments or units to manage the data generated by their applications, including preparing and enriching it for analysis. The principle of data as a product means that those business domains are also responsible for making data available to users in other domains. Data sharing is enabled by self-serve data infrastructure, which allows domains across an organization to share, discover and access data products. Distributed data ownership and sharing requires adherence to agreed standards that ensure usability and enforce data quality, which is supported by a federated approach to governance that involves individual domains as well as regulatory and security subject matter experts and infrastructure platform specialists.

There are multiple benefits that could be accrued from the data mesh approach, including empowerment of business decision-makers, encouragement of collaboration between business units, facilitation of data governance and alleviation of data silos as well as the reduction of data duplication and reinforcement of consistent policies and standards. There are also numerous barriers to adoption, including the definition and strict enforcement of interoperability standards, data quality benchmarks and service levels and the codification and administration of data security and governance policies. The latter would require many organizations to fundamentally adjust the approach to data stewardship. More than one-third (36%) of respondents to Ventana Research’s Data Governance Benchmark Research report that centralized IT staff serve as data stewards, compared to 23% line-of-business IT, and 30% line-of-business staff.

In addition to making organizational and cultural changes, many organizations also need to make technological changes to facilitate the adoption of data mesh. While the approach can be seen as diametrically opposed to centralized analytic platform projects such as data warehouses and data lakes, investment in these data platforms does not need to be abandoned to embrace data mesh. Data warehouse or data lake platforms can still serve a role as data repositories used by individual domains as part of a data mesh. Meanwhile there is some conflation of data mesh with data fabric, which is a technology-driven approach to managing data across distributed environments. Discussing the relationship between data mesh and data fabric is the focus of a separate Analyst Perspective, but certainly technological investment and evolution may be required to facilitate the management and sharing of domain-oriented data products.

There will likely be multiple products involved in enabling data access depending on the nature of the data and how often other domains need to access it. There are two key approaches, which can be summarized as push and pull. Data product changes can be distributed (pushed) as events to subscribing domains, or they can be published to be queried (pulled) via SQL query engines. The two approaches are not mutually exclusive. A single data product could be pushed to one domain and pulled by another, depending on needs. Additionally, an event can be a notification that triggers query-based access. While data mesh does not require organizations to adopt either distributed SQL query engines or event-driven architecture, we do see that both have a role to play in facilitating consideration and adoption of data mesh. I assert that through 2026, approaches to data operations will continue to evolve as organizations adapt cultural and organizational approaches to data ownership in the context of event-driven architecture and microservices.

Data mesh cannot be delivered through adoption of a single product or data platform. Consequently, one of the benefits of the data mesh is a shift away from defining data strategy in terms of data platforms. Your data warehouse, data lake or data lakehouse is not your data strategy, and is only one part of an organizational and cultural approach to data. Organizations should beware of vendors trying to sell a data mesh platform. That said, I recommend that all organizations consider the potential advantages of data mesh, while also being cognizant of the significant organizational and cultural changes that will be associated with its adoption.

Regards,

Matt Aslett