An insurance company with $400 million in premium volume adopted data mesh two years ago. The central data team had become a bottleneck. Every business unit — claims, underwriting, actuarial, and distribution — submitted data requests to a single queue. The queue was six months long. Business units were building shadow data pipelines in spreadsheets and Access databases because the central team could not serve them fast enough.

The CDO read the data mesh paper, consulted with two firms, and committed to the four principles: domain ownership of data, data as a product, self-serve data platform, and federated computational governance. The central data team was restructured. Each business unit was assigned a data product owner. The platform team built self-service tooling for data publishing, discovery, and access control.

Two years in, the organization has clear wins, clear failures, and a set of trade-offs that were not in the original vision.

What worked

Domain ownership eliminated the queue. Each business unit now owns its data products and publishes them on its own timeline. Claims publishes settlement data within one business day of transaction. Underwriting publishes risk score distributions weekly. Actuarial publishes loss ratio tables monthly. Before data mesh, all of these went through the central team, which processed them in priority order based on who had the most urgent request.

Data quality improved in an unexpected way. When the claims team owned their data products, they started caring about data quality in their source systems. Under the old model, the central team cleaned claims data as part of the ETL pipeline. The claims team had no incentive to fix data quality issues at the source, because the central team would catch and correct them. Under data mesh, the claims team publishes their own data products. If the data is wrong, their downstream consumers notice, and the claims team gets the support tickets. The feedback loop from consumer to producer created accountability that the centralized model never achieved.

Data discovery improved. The self-serve platform included a data catalog where each team registered their data products with schemas, descriptions, and quality metrics. Business analysts who previously spent days tracking down the right dataset could now search the catalog, read the data product documentation, and request access in minutes. The catalog became the most used tool in the data platform.

What did not work

Federated governance was the principle that came closest to failing. The original vision was that governance policies — data quality standards, access control rules, retention policies — would be defined centrally and enforced computationally at the platform level. In practice, the computational governance tooling was immature. Access control worked. Quality enforcement did not. Teams published data products that did not meet the centrally defined quality standards, and the platform had no mechanism to block publication.

The result was a two-tier data catalog. Seventy percent of data products met the quality standards and were trusted by consumers. Thirty percent did not, and consumers learned to check the quality metrics before using a data product. This created a manual quality assessment step that the self-serve platform was supposed to eliminate.

The second failure was skill distribution. The data mesh model assumes that each domain team has the skills to build and maintain data products. The claims team did. The underwriting team partially did. The distribution team did not. They had business analysts who could use data tools but not build data pipelines. The central data team ended up building the distribution team’s data products for them, which recreated the bottleneck that data mesh was supposed to eliminate.

The third failure was cross-domain data products. Some of the most valuable analytics spanned multiple domains — a combined view of claims, underwriting, and actuarial data for loss ratio analysis. Under the centralized model, the central team built these cross-domain views. Under data mesh, no single domain owned the cross-domain product. The original design called for “virtual domain teams” that would assemble cross-domain data products. In practice, these teams were never staffed because no business unit wanted to assign their people to a team they did not control.

What we learned

Data mesh works when the domains are genuinely independent. Claims data, underwriting data, and actuarial data have natural boundaries. Each domain has its own source systems, its own consumers, and its own quality standards. Domain ownership for these products is natural and sustainable.

Data mesh struggles when the domains are interdependent. Cross-domain analytics, shared entity resolution, and enterprise-wide reporting do not fit neatly into domain ownership. These capabilities require either a central team or a collaborative model that the federated structure does not naturally support.

The practical compromise: a thin central team that focuses exclusively on cross-domain data products and governance tooling. This team is small — four people, compared to the eighteen-person central team before data mesh. Their mandate is narrow: build and maintain the cross-domain data products that no single domain can own, and invest in governance tooling that makes the federated model self-enforcing rather than self-policed.

Results at year two

Data request fulfillment time dropped from six months average to two weeks average for domain-specific requests. Cross-domain requests still take four to eight weeks because they require coordination between domains, but this is still faster than the old centralized queue.

Data quality incidents increased in the first year as domains took ownership and discovered issues that the central team had been silently correcting. By year two, incident rates dropped below pre-mesh levels because the source systems improved. The first-year spike was painful but necessary — it surfaced quality debt that had been hidden by the centralized cleaning pipeline.

Annual data platform cost decreased by fifteen percent, primarily because the central team was smaller and the domains absorbed data engineering costs into their own budgets. Total organizational spend on data increased by eight percent, reflecting the investment in domain data teams. Net effect: the organization spent slightly more on data but delivered significantly more data products.

The decision heuristic

Adopt data mesh when your bottleneck is the central team’s capacity to serve domain-specific requests, and when your domains have genuinely independent data sources and consumers. Do not adopt data mesh when your primary analytics workload is cross-domain, when your domains lack data engineering skills, or when your governance tooling cannot enforce quality standards computationally. Data mesh trades central coordination costs for distributed coordination costs. If your organization cannot absorb the distributed coordination overhead, the central team may actually be the more efficient model, despite the queue.