Understanding a Data Mesh

Only 18% of organisations have the governance maturity to adopt a data mesh architecture successfully, and a McKinsey survey from October 2025 found pure data mesh implementations meet their objectives within 24 months just 38% of the time, against 52% for teams that plan a hybrid approach from the outset. Data mesh isn't hype and it isn't a technology purchase. It's an organisational redesign that happens to touch data, and most of what determines success or failure has nothing to do with which platform you pick.

Self-service business intelligence sits at the top of most transformation roadmaps, and the importance of data keeps climbing with it. Companies increasingly call themselves data-first, but few can honestly say they run an open, scalable data architecture. Every data team knows the pattern: more sources to integrate through a single ETL pipeline, an endless queue of ad hoc requests, and a central IT function that becomes the bottleneck for every business question, however small.

This is the disconnect a data mesh is built to close. Data Mesh is a process, not a technology, and the distinction matters more than it sounds. The organisations that treat it as a platform to install typically end up with the same centralised bottleneck wearing a new architecture diagram. The ones that treat it as a redistribution of ownership, IT stops being the single point of both delivery and blame, get the outcome the concept actually promises.

Four Principles That Define a Working Data Mesh

• Domain-Oriented Decentralised Ownership puts each business domain in charge of its own data pipelines, schemas, and quality, instead of routing every request through a central team.
• Data as a Product treats each domain's data output as something built for consumers, with clear ownership, documentation, and quality standards, not a by-product of someone else's system.
• Self-Serve Data Platform gives domain teams the infrastructure to build and manage their own pipelines without needing platform engineers for every task.
• Federated Computational Governance keeps standards, security, and interoperability consistent across domains, so decentralisation doesn't collapse into a hundred incompatible data silos.

1. Domain-Oriented Decentralised Ownership

The disconnect between IT and business teams is one of the most persistent frictions in enterprise data. IT complains that requirements never arrive complete; business complains that every requirement needs an IT ticket. Domain-oriented decentralised ownership is the principle that ends that standoff by handing data management back to the teams who actually understand the domain, sales, marketing, finance, or any other business unit generating and consuming its own data.

Why This Matters for the Business

Centralised data teams create a structural bottleneck that gets worse as the organisation grows, not better. Every new data source, every schema change, every ad hoc query competes for the same limited pool of central engineers, and domain context gets lost in translation somewhere between the business requirement and the pipeline that eventually ships. Decentralising ownership puts the people with the deepest domain knowledge closest to the data, which shortens the distance between a business question and an answer, and makes each team accountable for the quality of the data it actually understands best.

Key question: How many of your last ten data requests waited on a central team that had no domain context for what was actually being asked?

What Decentralised Ownership Actually Looks Like

In practice, each domain manages its own data pipelines, infrastructure, and schemas independently, rather than submitting requirements to a shared backlog. A large multinational is a useful mental model: Sales, Marketing, and Finance each run their own data team, managing pipelines, schemas, and analytics specific to their domain, while standardised APIs and a shared data catalogue allow cross-domain insight without forcing every team through the same central pipeline. Ownership here means more than access, it means the domain team is accountable for the accuracy, timeliness, and documentation of what it produces, the same way a product team owns the quality of a feature it ships.

The risk that comes with this freedom is real: decentralised ownership without shared standards produces data silos, inconsistent definitions, and a fractured view of enterprise data that's arguably worse than the bottleneck it replaced. Decentralisation is a starting condition, not the whole solution, which is exactly why the other three principles exist.

2. Data as a Product

Most enterprise data is a by-product: an export nobody designed for reuse, a table with no documentation, an API that changes without warning. Data as a Product inverts that. It asks each domain to treat the data it produces the way a product team treats a feature, built with a defined consumer in mind, held to a quality bar, and supported after release rather than abandoned the moment it ships.

Why This Matters for the Business

Analytics and AI initiatives fail more often on data quality than on model quality. Gartner has found that a significant share of generative AI projects are abandoned after proof of concept, and that a substantial proportion of enterprise AI pilots never reach production, in both cases because the underlying data, not the model, wasn't ready. A product mindset applied to data addresses this at the source: if a domain's data has an owner, a consumption contract, and a quality standard before anyone builds on top of it, downstream teams and AI initiatives inherit something usable instead of something they have to clean up first.

Key question: If another team started consuming your domain's data tomorrow, would they need to ask you what half the fields mean?

What Data as a Product Actually Requires

Treating data as a product means promoting self-service data platforms for domain teams, with clear ownership, defined consumption APIs, and explicit quality standards attached to every dataset, the same discipline applied to a public-facing feature. Every unit acknowledges it's providing a data service to other teams, and makes that service discoverable and usable through APIs rather than expecting consumers to reverse-engineer a schema. This is where technologies like Snowflake Data Cloud earn their place in a data mesh strategy: they let different teams create and manage their own databases independently while retaining the ability to share data across domains for cross-functional use cases, without forcing every team onto one shared, centrally managed schema.

3. Self-Serve Data Platform

Decentralised ownership only works if domain teams can actually operate independently, and that depends on infrastructure they don't need a platform engineer to use. A self-serve data platform is what makes domain-level autonomy realistic instead of aspirational: without it, "every team owns its own data" quietly becomes "every team files a ticket with the platform team instead of the analytics team," which solves nothing.

Why This Matters for the Business

The whole aim of distributing data infrastructure is enabling domain-specific teams to manage their own pipelines, schemas, and governance without becoming infrastructure specialists first. A self-serve platform is what turns that aim into something operational: provisioning, pipeline tooling, storage, and access controls need to be available on demand, with sensible defaults, so a domain team can stand up a new data product in days rather than escalating through a central request queue. Get this layer wrong, and decentralisation adds organisational complexity without removing the original bottleneck.

Key question: Could a domain team on your team stand up a new data pipeline this week without opening a ticket with a central platform group?

What a Working Self-Serve Platform Looks Like

A mature self-serve layer provides domain teams with the building blocks, ingestion tooling, storage, compute, access management, observability, as configurable infrastructure rather than bespoke engineering for each new use case. It abstracts away the underlying complexity of the cloud and data infrastructure so that domain teams can focus on their data products, not on managing Kubernetes clusters or hand-rolling data pipelines. This is also where organisations most often underinvest: the appeal of data mesh is decentralisation, but decentralisation without genuine self-service infrastructure just relocates the bottleneck instead of removing it.

4. Federated Computational Governance

Decentralised ownership, product thinking, and self-serve infrastructure all increase a domain team's autonomy. Federated computational governance is the principle that stops that autonomy from fragmenting into a hundred incompatible standards, by keeping a shared, lightweight layer of policy that every domain implements consistently.

Why This Matters for the Business

Maintaining global data governance and adherence to standards becomes measurably harder in a distributed architecture, and this is where most data mesh initiatives that fail actually fail, not on the technology, but on governance that was either too centralised to let domains move, or too absent to keep them consistent. Federated governance threads that needle: security policy, interoperability standards, and compliance requirements are defined centrally and enforced computationally, through automated policy checks embedded in the self-serve platform, rather than manually by a central team reviewing every domain's output before it ships.

Key question: If two domains published a dataset with the same customer ID field tomorrow, would it mean the same thing in both?

What Federated Governance Actually Requires

This is increased emphasis on data sharing and collaboration across organisational boundaries, coupled with self-service functionality that supports many business roles rather than only specialist data engineers. In practice, that means common standards for interoperability, discoverability, and access control are defined once, then enforced automatically as domains publish new data products, rather than negotiated fresh in every cross-domain project. Governance here is federated, not absent: domains retain autonomy over their own data, but not over the baseline rules that let another domain's systems trust and consume what they publish.

How This Looks in Practice: A Global Investment Firm's Data Mesh Journey

Tarento partnered with a global investment firm as its implementation partner to bring Data-as-a-Product principles to life through a full data mesh implementation. The starting position will be familiar to most enterprise data leaders: a centralised IT team was taking months to integrate new datasets needed for analytics, and data quality issues were surfacing regularly because the central team lacked the domain understanding to catch problems the business teams would have spotted immediately.

The data mesh implementation addressed both problems directly. Speed improved because domain teams no longer had to wait in a shared queue for a central team with no context on their specific data; they could build and ship their own pipelines against a common set of standards. Collaboration improved for the same reason in reverse: once each domain's data was published as a well-documented product with a stable API, other data teams within the organisation could discover and consume it without needing a meeting to understand what it meant first.

The result was faster time-to-delivery for analytics and business intelligence, and a measurable improvement in the organisation's ability to collaborate across data teams rather than route every cross-domain need back through IT. This is what data mesh delivers when the four principles are implemented together rather than selectively: not a new technology stack, but a different relationship between the teams that produce data and the teams that need it.

Data Mesh vs. Data Fabric: An Honest Read

The debate between data mesh and data fabric has largely settled, and the honest answer is less exciting than either camp originally argued. Data mesh is an organisational and ownership model: it distributes data ownership to domain teams and treats datasets as products. Data fabric is a metadata and integration layer: it connects disparate systems using active metadata and automated pipelines. These solve different layers of the same problem, and current research suggests most enterprises now recognise that rather than picking a side.

By 2025 and 2026, an estimated 60 to 70% of large enterprises are adopting hybrid models that combine both rather than committing to a pure approach in either direction, and Gartner's own research suggests that organisations already running one are likely to adopt the other within two to three years. The practical implication for anyone starting this journey now: treat data mesh as the organisational and ownership model, and expect to pair it with a metadata and integration layer rather than expecting the ownership model alone to solve discoverability and interoperability across every domain.

What This Adds Up To

A data mesh is a company-focused analytics architecture in which each business unit owns its own analytics infrastructure and data team, operating inside company-wide governance rather than outside it. It empowers domains to build data products tailored to their own needs, but it comes with real costs: the risk of data silos reappearing under a decentralised structure, the added complexity of maintaining consistent governance across a distributed architecture, and the cultural shift required to get domain teams to genuinely own their data rather than treat ownership as an unfunded mandate. None of the four principles fixes the others' weaknesses on its own, decentralisation without governance fragments, governance without self-service infrastructure recentralises, and a product mindset without either just produces well-documented silos. Together, they're what separates a data mesh that speeds up delivery from one that quietly rebuilds the old bottleneck with more moving parts.

---

Frequently Asked Questions About Data Mesh

1. Is data mesh a technology we can buy? No. Data mesh is an organisational and architectural approach to decentralising data ownership. Technologies such as Snowflake, data catalogues, and self-serve platform tooling support it, but no single product implements a data mesh on its own.

2. Do we need a data fabric as well as a data mesh? Increasingly, yes. Most enterprises now run both: the mesh model for ownership and accountability, and a fabric-style metadata and integration layer for discoverability and interoperability across domains. Treating them as competing choices is largely an outdated framing.

3. What's the biggest reason data mesh initiatives fail? Governance maturity, not technology. Organisations that decentralise ownership without a working federated governance layer tend to end up with data silos and inconsistent standards, which is often worse than the centralised bottleneck they were trying to fix.

4. How long does a data mesh implementation typically take to show value? It varies by organisational readiness and domain count, but the Tarento engagement with a global investment firm saw faster analytics delivery and improved cross-team collaboration once the first domains were fully onboarded to the shared standards and self-serve platform, rather than as an overnight change.

5. Which team should own the self-serve data platform? A central platform team should still own the shared infrastructure and tooling, but not the pipelines built on top of it. The platform team's job is to make it easy for domain teams to self-serve, not to become the bottleneck the mesh was designed to remove.

---

Ready to move from centralised bottlenecks to domain-owned data products?

Whether it's a central data team drowning in requests, analytics that take months to reach the business, or data quality issues nobody can trace back to a source: this is exactly what Tarento's Data & Analytics practice and DataVolve are built to solve, starting with the organisational model, not just the platform underneath it.