Data mesh can decentralise ownership. It can also decentralise bad data.

ENTERPRISE DATA BUYER INTELLIGENCE

Our buyer intelligence is informed by ongoing conversations with senior enterprise leaders through roundtables and leadership communities.

Data mesh does not remove governance. It relocates responsibility

Data mesh is attractive because it promises to resolve a familiar enterprise problem: a central data team cannot understand, clean and serve every domain quickly enough. Moving ownership closer to the business can improve context, speed and accountability. But recent enterprise discussions also exposed the danger in the slogan. Decentralisation does not automatically create ownership. It can simply distribute ambiguity.

Senior leaders described the need to balance domain autonomy with a common governance framework. The principle that source owners should be accountable for quality is powerful because it reduces the habit of fixing problems only in central analytical layers. Yet it works only if domains know what they own, understand the standards they must meet and have incentives to maintain data for consumers beyond their immediate team.

For vendors, the sales opportunity is not to promise decentralisation. It is to show how the platform makes distributed accountability operational. The buyer wants to know who owns a data product, which enterprise rules still apply, how interoperability is maintained and what happens when one domain�s local decision harms another domain�s downstream use.

The enterprise fear is a mesh becoming a spider web

One roundtable discussion used a useful image: without the right control model, a mesh can turn into a spider web of unmanageable systems. That fear is commercially important. Many large organisations already have decentralised reality even if they do not call it a data mesh. Business units maintain their own pipelines, extracts, definitions and tools. Rebranding that estate does not make it coherent.

Enterprise buyers will therefore challenge vendors that treat mesh as a topology diagram rather than an operating model. A credible implementation needs domain boundaries, product ownership, interface standards, shared metadata, lineage, quality expectations and a way to resolve enterprise-level conflicts. It also needs to recognise that some data is naturally local while other data must be consistent across the company.

The vendor that can explain where autonomy should stop will often sound more mature than the vendor that sells maximum decentralisation as an unquestioned virtue.

Data quality has to move upstream with ownership

The strongest logic behind mesh is that the team closest to data creation is often best positioned to understand its meaning and fix its source process. Central analytics teams can identify issues, but they frequently lack the authority or operational knowledge to prevent recurrence. Data mesh can change that by placing product and quality responsibility within domains.

The risk is that �domain ownership� becomes a label without capacity. If business teams are given accountability but no tooling, quality telemetry, stewardship time or support, the central problem simply becomes distributed. Buyers need evidence that the vendor can make ownership practical: visible quality rules, usage feedback, issue routing, service expectations and clear consumer contracts.

This also affects procurement. Enterprise leaders may prefer technology that supports multiple levels of maturity across domains rather than assuming every team can adopt the same advanced operating model on day one.

A data mesh only improves accountability if ownership moves closer to the source faster than inconsistency spreads across the enterprise.

Common language still has to exist above the domains

Organisations adopt mesh partly because business domains have different needs. But enterprise metrics, customer identity, product hierarchies and regulatory classifications often cross those boundaries. If every domain is free to redefine them, the organisation gains local relevance at the cost of enterprise comparability.

This is why semantic standards and authoritative definitions remain essential. A data product can be owned locally while still conforming to enterprise concepts. The central function does not need to dictate every field, but it does need to define which concepts must be shared, how they are versioned and how disagreements are resolved.

Vendors should show how their architecture supports that layered model. Can domains extend a shared concept without breaking it? Can the enterprise see where two products use conflicting definitions? Can consumers understand which data contract or semantic version they depend on? Those are the details that separate a scalable mesh from a distributed collection of incompatible assets.

Centralisation versus decentralisation is not an ideological choice

The roundtables also showed that architecture choices depend heavily on industry and operating model. A highly regulated pharmaceutical environment may need different boundaries from an asset manager or consumer business. Operational data that must be available in real time may be managed differently from analytical data used across functions. M&A can create another layer of complexity because newly acquired businesses arrive with their own systems, definitions and governance maturity.

Buyers therefore respond poorly to rigid methodology. The stronger vendor asks which capabilities need enterprise consistency and which genuinely benefit from local control. It may be sensible to centralise identity, metadata and policy while decentralising product development. In another organisation, a unified platform may remove enough legacy friction that broader centralisation creates faster value.

Data mesh is a means, not a religion. Vendors that can demonstrate architectural judgement rather than doctrinal purity are more likely to gain executive confidence.

Data products need consumer evidence, not just ownership labels

A domain-owned dataset does not become a product simply because it has an owner. Enterprise buyers increasingly expect product thinking: a defined consumer need, documented meaning, quality expectations, availability commitments, change management and usage evidence.

This is where vendors can differentiate. Show how the platform captures product-level metadata, service expectations and consumer feedback. Show which products are widely reused and which are expensive to maintain but rarely consumed. Help owners understand downstream dependency before they change an interface or definition.

The commercial value of mesh appears when consumers can discover and trust reusable products without negotiating every request manually. If the technology only decentralises pipelines but leaves discovery, trust and interoperability unresolved, the buyer may see more organisational complexity rather than less.

The buyer questions vendors should be ready for

What enterprise buyers will expect vendors to prove

Enterprise buyers will want proof across architecture and operating model. They will ask how ownership is assigned, how data products are certified, how enterprise policies reach domains and how exceptions are handled. They will want lineage across distributed environments, not only inside one platform.

They will also test how the solution handles domain maturity differences. Can a sophisticated domain move faster without leaving less mature teams behind? Can central governance identify where standards are not being met? Can policies apply across Snowflake, Databricks, cloud warehouses and operational systems without forcing all data into one physical location?

A good demonstration should therefore show the lifecycle of a data product from creation through certification, discovery, consumption, change and retirement. The buyer needs to see how mesh behaves when real organisational friction appears, not only when every domain follows the model perfectly.

The proof burden is moving into the sales process

Enterprise data buyers are also changing when they ask for proof. Architecture, governance and operating-model questions increasingly appear before a pilot is approved, not after procurement has selected a preferred supplier. That means sales teams need credible answers early. Product specialists cannot be brought in only when a security questionnaire arrives.

Vendors should prepare a compact evidence pack for the use case: reference architecture, ownership model, permission design, monitoring approach, failure handling, implementation dependencies and the business measures that will show whether value appeared. The objective is not to overwhelm the buyer with documentation. It is to remove the uncertainty that forces an internal champion to spend weeks translating the product into enterprise language.

This matters because many senior data leaders are already carrying transformation debt. A solution that creates another operating model to learn, another set of definitions to reconcile or another control surface to govern can be harder to approve than a less feature-rich product that fits cleanly into the existing environment. Commercially, integration with the buyer�s way of working can be as important as the feature list.

What will slow the deal

Confidence falls when a vendor presents data mesh as an automatic cure for central bottlenecks without explaining who absorbs the work. Buyers will also challenge platforms that require every domain to run a separate stack with little enterprise visibility, because that can increase cost and duplication.

Another warning sign is treating governance as a thin catalogue over distributed systems. Metadata is necessary, but buyers also need enforceable access rules, quality accountability, lineage and change management. A catalogue that tells users where bad data lives does not make the mesh trustworthy.

Finally, avoid assuming the buyer wants decentralisation everywhere. Enterprise leaders are increasingly pragmatic. They will centralise where consistency creates value and federate where local context matters. The vendor needs to support that spectrum.

How vendors can help the internal champion defend the purchase

The internal sponsor needs to show that mesh will reduce bottlenecks without creating fragmentation. Build the case around a small number of domains where central delivery is slow or source quality ownership is weak. Define the product responsibilities that will move closer to the business and the enterprise standards that will remain common.

Measure the outcome through reuse, time to access trusted data, issue resolution time, duplicate pipeline reduction and consumer satisfaction. Show how the platform makes domain performance visible. This gives the champion a governance story and a productivity story at the same time.

The best data mesh proposition is not �decentralise your data�. It is �put accountability where the knowledge lives while preserving the trust the enterprise needs�.

Data contracts only matter if the enterprise can enforce and evolve them

Data contracts are becoming a useful mechanism for making expectations between producers and consumers explicit. They can define schema, freshness, quality thresholds, ownership and change rules. In a mesh environment, that structure helps turn vague domain accountability into something another team can actually rely on. But enterprise buyers will be cautious of vendors that present data contracts as documentation rather than operational control.

The buyer needs to know what happens when a producer breaks the contract. Can the platform detect the change before downstream consumers fail? Can it identify which products, dashboards, models or agents depend on the affected interface? Can an owner approve a breaking change, communicate it and track migration? If the contract is only a static file, it will quickly fall behind the real system.

Vendors should also recognise that contracts need different levels of strictness. A high-risk finance product may require hard quality gates and formal change approval. An exploratory domain asset may need lighter controls. Supporting that spectrum is commercially important because enterprises do not want a governance model so rigid that domains avoid it. The strongest mesh proposition combines explicit expectations with enough flexibility for teams to work at the speed their risk profile allows.

Frequently asked questions

What is data mesh governance?

Data mesh governance is a federated model in which business domains own data products while enterprise standards still govern areas such as access, metadata, critical definitions, quality expectations and interoperability. It is intended to combine local context with organisation-wide trust.

Does data mesh mean all data should be decentralised?

No. Many enterprises centralise some capabilities and federate others. Shared identity, policy, metadata or analytical platforms may remain central while domains own product definitions and source quality. The right boundary depends on risk, regulation and operating model.

Why can data mesh create poor data quality?

If ownership is decentralised without clear standards, capacity and feedback, domains can create conflicting definitions, duplicated pipelines and inconsistent quality. The architecture needs visible accountability and common enterprise concepts, not just distributed technology.

What should enterprises look for in a data mesh vendor?

Buyers should evaluate product ownership, lineage, data contracts, semantic standards, policy enforcement, discovery, quality evidence, cross-platform interoperability and support for domains with different maturity levels.

The vendor implication

Enterprise data buyers are becoming less interested in capability claims that sound impressive in isolation. They are looking for evidence that a solution can fit the operating reality around ownership, governance, risk, adoption and measurable business value. Vendors that arrive with that buyer context already understood are better positioned to earn confidence earlier in the sales process.

The Leadership Board helps solution providers understand what senior enterprise decision-makers are prioritising and creates direct opportunities to meet buyers with active challenges and investment agendas.