Data mesh success hinges on hybrid implementation

Where decentralized data mesh encounters limits

Some early versions of data mesh assumed that pushing ownership to domains would eliminate downstream integration problems, since well-governed data products could replace messy pipelines, said Jitender Aswani, senior vice president of engineering at Starburst.

That prediction was partially right. What it got wrong was that data products don't eliminate the need for a governed layer above them; it's required for coherent cross-domain analytics. Pure mesh architectures break down when they support data workflows for decision-making, which don't neatly stay within domains.

For example, a credit risk model might draw on customer and transaction data, macroeconomic indicators and fraud signals. Those data types may be owned by different domains, each with its own data contract and access rules.

"Pulling all of that into a coherent query without a central access and governance layer is an engineering project, not a data product exercise," Aswani said.

Domains can also drift when left fully autonomous. Data contracts can become inconsistent or outdated, access policies can diverge to make the existing catalog unreliable.

"The mesh produces data product sprawl faster than a central team ever could, and without governance teeth, quality follows," Aswani said.

Another failure point is performance, particularly in agentic workflows. While federated access across distributed data products looks architecturally elegant, it glosses over problems with a slow query engine. A delay that isn't problematic for a patient human can stall an AI agent's multi-step workflow.

These factors make a hybrid approach inevitable, whether adopted through deliberate choice or accidental friction, Aswani said.

Accidental hybrid architectures result when an organization commits to the mesh idea but does not clearly define governance responsibilities. So, they end up calling what they build "hybrid" because the centralized management team never lets go. The result can be two governance regimes, unclear ownership and a central team that continues to approve decisions nominally assigned to domains.

Organizations with deliberate hybrid mesh accept that enterprise data estates are inherently distributed, which guides governance development, Aswani said.

"The distinction matters because deliberate hybrids tend to improve over time, and accidental ones tend to get worse," he added.

How enterprises build a hybrid approach

Thota recalled a Kearney engagement in which a major logistics provider kept the enterprise data platform, catalog, data quality standards, security, architecture and AI governance central while business-aligned hubs across freight, network, retail and corporate functions owned their data products and use-case roadmaps. According to Thota, the split avoided a costly rebuild of the existing cloud platform and preserved common controls, improved pricing decisions and accelerated analytics delivery.

Aswani pointed to a large financial institution with regional operations across multiple continents. Each region ran its own data architecture, cloud stack and, sometimes, on-premises infrastructure, due to a combination of local regulations and legacy technology decisions. When the central analytics team tried to implement consistent reporting, they instinctively implemented a single cloud warehouse. They couldn't retire the regional systems because of data residency requirements, data-use agreements and latency constraints.

What forced the split was a compliance constraint that would never lift, paired with a speed requirement that consolidation couldn't satisfy.

"The deadline for getting every source into the central warehouse was functionally infinite, and the business had AI projects that needed to start in months," Aswani said. But pure-play consolidation added a tier when they needed one removed, he added.

The resolution came from separating centrally managed governance and data contracts from locally managed quality controls and analytics product development.

How to define central and domain responsibilities

Aswani said effective implementations start by identifying what can be centrally managed versus remain under domain control.

Centrally managed

• Access policy. Who can see what, under what conditions, at what granularity.
• Shared definitions and data contract standards. Common identifiers, semantics and interface requirements for entities, such as a customer, transaction or risk event reduce cross-domain reconciliation work.
• Audit and lineage. Audit logs record access and administrative events, while data lineage traces movement and changes from source to consumption.
• Catalog authority. The agreed-upon register of existing  data products and their contents.

"These four have network effects," Aswani said. "They compound in value as more domains connect to them, and collapse the moment individual domains maintain their own versions."

Domain managed

• Subject matter expertise. The people who use data best understand its intended purpose.
• Data quality at source. The domain that generates the data usually has the required perspective to troubleshoot problems near the source. For example, the fraud team understands suspicious transactions and is best equipped to fix data quality problems.
• Local use case development. People who understand the data are best positioned to see where and how it supports other use cases.
• Pace of innovation. Domain expertise helps manage reuse so it doesn't introduce unexpected problems, such as adjacent teams misinterpreting data in a different context.

The most common mistake is pushing schema governance down to the domains under the banner of autonomy, Aswani said. Domains understand their own data best, but if each domain builds a schema optimized for its own use cases, the definitions may not reconcile when the organization needs a cross-domain view.

"Finance's customer is not sales's customer is not risk's customer," Aswani said.

But by the time a cross-domain view is necessary, data products are in production, consumers depend on them and migration is a multi-year program. Thus, organizations make the second mistake: pulling data ownership back to the center. While that fixes consistency, it also recreates the bottleneck the mesh removed.

Thota described a parallel version of the same error. Teams distribute the tools while keeping the decisions, funding and accountability at the center.

Why hybrid data mesh matters for AI

Each enterprise must find the right balance between centralized governance and distributed management. The precise separation varies across industries, data estates, innovation priorities and risk appetites. The operating model should evolve as those conditions change.

The right architecture creates value when it makes trusted business context easier and cheaper for AI to consume, Thota said. A hybrid mesh can support that by combining common controls with domain-owned meaning. Data and analytics leaders should evaluate each choice against the time, cost and risk of producing the next AI use case.

A well-done hybrid mesh can streamline the path to broader AI plans, Aswani said. The right governed and federated layer built for human analysts to query across a distributed estate provides a good foundation for AI agents using similar authentication, role-based access controls and audit trails.

However, agents can introduce additional latency, policy enforcement and observability requirements. The useful question isn't whether to accept those costs, but which ones the organization can measure and manage, Aswani said. Federated access makes some of those costs visible and can be addressed.

"The overhead of unmanaged data sprawl, where every AI team builds its own ingestion pipeline to every source it needs, is invisible until it becomes catastrophic," he said.

Data and analytics leaders should look at their data estate to assess whether full consolidated is realistic, Aswani said. The ones that struggle treat a distributed state as a temporary problem on the way to a central platform.

"Every wave of infrastructure investment over the past twenty years has added a tier without removing one," Aswani said. "AI is no different, and its scale means the cost of not adapting is higher than it's ever been."

George Lawton is a journalist based in London. Over the last 30 years, he has written more than 3,000 stories about computers, communications, knowledge management, business, health and other areas that interest him.