Data Mesh: Decentralization Without the Anarchy

Over the years I have worked across telcos, banks, and consumer goods companies. But you do not even need to cross industry boundaries to run into the problem. Inside a single telco, the word "Service" already means different things depending on which room you are sitting in. To the network operations team, a Service is a configured capability on the infrastructure, a VPN tunnel, a voice bearer, a data path. To the product team, a Service is a commercial offering in the catalogue, a broadband package or a roaming add-on. To billing, a Service is a billable line item on an invoice. To provisioning, it is a workflow that activates something for a subscriber. Same word. Completely different entity.

What I kept running into was a version of the same problem in every engagement. Domains needed genuine autonomy to model data in ways that made sense for their business context. A network operations team should not have to contort their Service entity to satisfy a definition written by someone who has never read a network inventory schema. But without shared naming conventions, common modeling patterns, and agreed principles for how core concepts relate to each other across the organization, you end up with a data landscape that nobody can navigate. Four incompatible Service models. A data lake that is really just a data swamp with better marketing.

The answer is to agree on the patterns, principles, and canonical names for shared concepts, then let each domain apply them with the context they need. A Service stays a Service across the telco, but the network domain adds infrastructure and topology attributes while the product domain adds commercial and pricing attributes. The entity name is shared. The domain context is preserved. This is the core tension that data mesh, when done well, is actually trying to resolve.

This is the paradox of modern data architecture. We centralize for consistency, then watch as the central team becomes a bottleneck that slows everyone down. We decentralize for agility, then wake up to discover we have built four incompatible definitions of "Service" across the same organization. The promise of data-driven decision making crashes headlong into the reality of data-driven frustration.

The Great Centralization Experiment

For years, the answer to data chaos was simple: build a bigger warehouse, hire a bigger team, centralize everything. One source of truth. One team to rule them all. One pipeline to bind them.

The problem? Domain experts in network operations understand infrastructure topology. Domain experts in product management understand commercial catalogue dynamics. But the central data team? They understand SQL and ETL pipelines. They're translators without fluency in the native languages they're translating between.

As Zhamak Dehghani observed in her foundational work on data mesh, this creates a fundamental mismatch. The people who understand the data best (domain teams) don't own it. The people who own the data (central teams) don't understand its nuanced business context. The result is a game of telephone where "active service" means something different depending on which meeting you're in.

Data mesh proposes a radical alternative: what if domain teams owned their data as products? What if we treated data with the same architectural principles we've learned from microservices? What if decentralization didn't have to mean chaos?

Six years on from those foundational ideas, the evidence is in. According to Thoughtworks' 2026 state-of-the-art assessment, data mesh has moved from industry hype into hard-won maturity. Data products and self-serve data platforms are becoming foundational commodities for the modern enterprise. But the path there has been harder than the early literature suggested.

Think of It Like a Railway Network

Imagine a rail network where every train operator gets to run their own routes, set their own schedules, and brand their own carriages. One operator serves the commuter belt. Another runs long-distance intercity lines. A third handles freight. Each knows their segment of the network intimately and makes decisions about it without needing approval from a central committee that has never seen a timetable.

But here is the constraint that makes it all work: every train uses the same track gauge. Every platform is built to the same height. Every signal follows the same protocol. No operator gets to decide that their trains will run a bit wider than everyone else's because it suits their rolling stock. Those standards are not up for negotiation, and they are enforced at the infrastructure level, not by a bureaucrat with a clipboard.

This is data mesh with federated computational governance. Each domain owns and operates its own data products (its own routes and services), but does so on a shared infrastructure of standards and principles (the track gauge and signaling system). The network benefits from local expertise at every node. But a train from the network operations domain can still connect to a station managed by the billing domain because they both speak the same underlying language. You get genuine autonomy across the mesh without the nightmare scenario where data from one domain simply cannot be joined with data from another because nobody ever agreed on what a Service identifier should look like.

The Four Pillars of Organized Chaos

Data mesh rests on four foundational principles, but it's the fourth one, federated computational governance, that prevents your decentralized utopia from becoming a decentralized nightmare.

Domain Ownership of Data as a Product

Each domain team owns their data end-to-end. Network operations owns infrastructure and topology data. Product management owns catalogue and commercial offering data. Finance owns transaction data. But here's the critical part: they don't just dump raw data into a lake and walk away. They treat it as a product with consumers, SLAs, documentation, and versioning.

This aligns perfectly with Domain-Driven Design's concept of bounded contexts. Your Service entity in the network operations context might emphasize physical topology, configuration state, and availability metrics. Your Service in the product context focuses on commercial terms, pricing tiers, and eligibility rules. Both are valid. Both use anti-corruption layers to translate between the canonical Service concept and their domain-specific model without polluting each other's schema.

Traditional Approach	Data Mesh Approach
Central team owns all data	Domain teams own their data products
Domain teams submit requests	Domain teams publish and maintain
One-size-fits-all data models	Context-specific models with interoperability
Bottleneck at central team	Distributed ownership and accountability

One pattern that has emerged from real-world implementations as a failure mode: re-badging old IT teams as "data domain owners" without giving them genuine business ownership or authority. Thoughtworks calls this "lip service domains." The organizational change has to be real, or the architecture is just rearranging deck chairs.

Self-Serve Data Infrastructure as a Platform

Decentralization fails spectacularly if every domain team has to build their own data infrastructure from scratch. You need a platform that makes it easy to create, publish, discover, and consume data products. Think of it as the shared rail infrastructure from our railway analogy: the tracks, the signaling systems, and the station platforms that every operator depends on but no single operator has to build themselves.

This platform provides:

• Standard tooling for data product creation
• Automated data quality checks
• Discovery and catalog services
• Access control and security frameworks
• Monitoring and observability

By 2026, the most successful implementations have converged on a complementary pattern: a data lakehouse as the core analytics and AI platform for unified storage and performance, with data mesh principles applied on top to assign domain ownership, accountability, and data product contracts. Data fabric and data mesh solve different problems, one technical integration, the other organizational ownership, and using both together is increasingly the practical approach rather than a compromise.

Federated Computational Governance

Here's where it gets interesting. Governance in data mesh is a federated function, meaning domain teams participate in creating and evolving the standards they'll follow. And it's also computational, meaning those standards are encoded in the platform and automatically enforced.

Think of it as the track gauge and signaling protocol from our railway analogy: each operator chooses their own routes and timetables, but the standards that make the whole network interoperable are non-negotiable and enforced at the infrastructure level. You can't publish a data product without proper documentation. You can't expose personally identifiable information without encryption. You can't create a "Service" entity without adhering to the agreed-upon canonical model for core business concepts.

The governance team includes representatives from each domain plus platform and architecture specialists. They collectively decide:

Data Standards and Principles

• Naming conventions and semantic models, including how canonical entity names like Service, Customer, and Product are defined and how domain contexts extend them
• Data quality thresholds
• Security and privacy requirements
• Metadata and documentation standards

Interoperability Requirements

• Common information models for shared concepts, with explicit rules for which attributes belong to the canonical definition versus the domain extension
• Standard protocols and formats
• API design patterns and anti-corruption layer conventions
• Schema evolution policies

Compliance and Security

• Data classification frameworks
• Access control patterns
• Audit and lineage requirements
• Regulatory compliance checks

The governance council's role has also evolved. The most effective pattern seen in practice is moving the central data office from a gatekeeper role to a center of excellence, one that owns the practice of data rather than the data itself. It onboards new domains through dojos and templates, then steps back. Standards imposed from above fail. Standards negotiated among peers with skin in the game, and then automatically enforced by the platform, succeed.

Product Thinking Applied to Data

Each data product needs an owner, a roadmap, and a commitment to consumer success. This is a practical stance with concrete implications:

• Versioning: Breaking changes require migration paths
• SLAs: Uptime and freshness guarantees, increasingly formalized as service level objectives measurable on a dashboard
• Documentation: Not just what the data is, but how to use it
• Support: Someone to contact when things break

A maturing trend in 2026 is LLM integration with data products. When domain data products are well-structured, documented, and accessible through a self-serve platform, they become the grounding layer for AI assistants that allow business users to query complex domain data in natural language without needing SQL skills. The quality investment you make in your data products pays compound interest when AI consumption is added on top.

Rolling Out the Welcome Wagon

Implementing data mesh is a gradual shift that requires both technical and organizational change. Research consistently shows that implementations take years, not quarters, and require sustained executive commitment. The steps below are sequenced the way a solution architect would actually work through this: start with the organizational design questions that no platform can answer for you, build toward a concrete pilot, and only then introduce tooling.

Step 1: Map Your Domains Before You Touch Anything Else

The most common mistake in a data mesh engagement is starting with a platform decision. The first question is an organizational one: what are the actual domains, who owns them, and do those owners have enough autonomy and accountability to act as data product publishers?

Draw your domain map before any technical discussion. For each candidate domain, answer:

• What is the bounded context? What does this domain know that no other domain does?
• Who is the accountable business owner, not the IT lead, the business owner?
• What data does this domain produce that other domains depend on?
• What data does this domain consume from others?
• Does this team currently have the maturity and capacity to treat data as a product, or would onboarding them now set them up to fail?

In a telco, network operations, product management, billing, provisioning, and customer care are usually the natural domain boundaries. But the map will surprise you. You will find teams that look like domains but are actually shared services, and teams that look like shared services but are sitting on business-critical data that three other domains depend on.

The output is a list of decisions: which domains are ready to pilot, which need capability building first, and which should stay on centralized tooling for now. That list is the foundation for everything that follows.

Step 2: Negotiate the Canonical Entity Model

Before any governance framework, any platform, or any data product contract, you need the most important architectural artifact in a data mesh: the canonical definition of the entities that cross domain boundaries.

In a telco, Service is the hardest one. Do this exercise with representatives from at least two domains in the same room.

Ask each domain to write their own definition of Service independently: what it represents to them, its key identifier, its most important attributes, and what lifecycle states it goes through. Then compare the two definitions side by side. The gaps between them reveal your canonical model problem. The attributes that appear in both, with the same semantics, are your canonical core. The attributes that differ or appear in only one are domain extensions.

Your canonical Service definition needs to make these decisions explicit:

• Identifier: One agreed format for service_id that every domain uses as the join key. In practice this is often the hardest negotiation in the entire program.
• Lifecycle states: A small shared vocabulary, for example planned, active, suspended, terminated, that all domains map their internal states to, even if they maintain richer internal state machines.
• System of record: Which domain owns the authoritative version of each attribute. Network owns topology. Product owns commercial terms. Billing owns rated event linkage. Ambiguity here causes data quality incidents downstream.
• Extension rules: Any domain may add attributes beyond the canonical core, but may not redefine canonical attributes or identifier formats.

Document each decision as an architecture decision record. The reasoning matters as much as the outcome, because six months from now someone will want to change the identifier format and the ADR is what reminds the council why that negotiation was hard.

Step 3: Assess Domain Readiness Honestly

Not every domain is ready to own a data product. Onboarding a domain that lacks the capability or the mandate leads to the most common failure pattern in data mesh: a team that is re-badged without any real ownership transfer and produces a data product that nobody trusts or maintains.

Use a readiness assessment before committing to a pilot with any domain:

Readiness criterion	Question to ask
Business ownership	Can you name the business leader accountable for data quality, not just the technical team?
Consumer awareness	Does the domain team know who depends on their data and what they use it for?
Data knowledge	Can the team describe the lineage and meaning of their key datasets without asking someone else?
Change authority	Can this team make schema changes without a central team approving each one?
Capacity	Does the team have bandwidth to take on data product ownership alongside their operational work?
SLA readiness	Can this team commit to and measure freshness and uptime for their data?

Score each criterion as green, amber, or red. A pilot domain should be green or amber across all six. A domain with one or more red criteria needs a capability-building plan before it is ready for the mesh, not a platform ticket.

Step 4: Design the Governance Rules as Constraint Statements

Before encoding governance in any tool, write it out as constraint statements. The discipline of expressing rules as constraints forces precision. "Data must be good quality" is not a constraint. "Every data product must declare a freshness SLA and measure against it daily" is.

Work through these constraint categories with your governance council:

Interoperability constraints define what makes data products joinable across domain boundaries. In a telco: all Service entities must use the canonical service_id format. All domain extensions must be additive. No domain may reuse a canonical field name with a different semantic meaning.

Quality constraints define the minimum bar for publication. Examples: completeness of mandatory canonical attributes must exceed 99%. Freshness SLA must be declared and measured. Any field classified as PII must be flagged and access-controlled before the product is published.

Discoverability constraints define what metadata every data product must carry so consumers can evaluate it without asking the producing team. Examples: owner contact, list of consuming domains, schema reference, classification label, changelog.

Evolution constraints define the rules for change. Breaking schema changes require a new major version and a transition period. Canonical attribute changes require governance council approval via ADR. Deprecation requires 90 days notice to declared consumers.

Write these in plain language first. If a domain team member cannot understand a governance rule without technical help, it is too complex to enforce reliably. Platform enforcement comes after the rules are clear, not before.

Step 5: Build the Platform Foundation Around the Constraints

Once the governance constraints are clear, the platform question has a concrete specification: build or buy a platform that makes compliance with these constraints the path of least resistance for domain teams.

The key capabilities you need are a schema and contract registry, a data catalog with lineage, access control at the data product level, automated quality monitoring, and policy enforcement. In 2026, Databricks with Unity Catalog is one of the most practical ways to address this stack for organizations already running analytics workloads on Databricks or evaluating a lakehouse architecture.

Unity Catalog provides a three-level namespace, catalog, schema, and table, that maps naturally onto the data mesh ownership model. One catalog per domain, schemas per data product family, tables per version. Access control is defined at the catalog level and automatically inherited, so the network domain catalog is by default inaccessible to the billing domain unless explicitly granted. Cross-domain sharing uses Delta Sharing, which lets the network domain publish a read-only share of their Service inventory to the billing domain without copying data or managing a separate pipeline.

For governance enforcement, Unity Catalog's lineage tracking and tag-based classification let you attach canonical classification labels and PII flags directly to columns. When a network engineer adds a column that the canonical model does not recognize, that surfaces in the catalog as an untagged attribute rather than silently flowing downstream. This is computational governance in practice: the constraint from Step 4 becomes an automated check in the platform.

Databricks is not the only option, and this governance design is platform-agnostic. But if your organization is evaluating platforms, Unity Catalog's alignment with the data mesh ownership and governance model is worth serious consideration when you are scoring alternatives.

Step 6: Run a Pilot with a Clearly Framed Business Case

With domains mapped, a canonical model negotiated, readiness assessed, governance constraints drafted, and a platform direction chosen, you are ready to pilot. In a telco, network inventory is usually the strongest starting point: the data is internally consumed, the domain team understands it well, and a failed pilot has limited customer-facing risk.

Frame the pilot as a business case before you start. The one-page version answers:

• What problem does this pilot solve for the consuming domains?
• What does success look like after ninety days, in measurable terms?
• What does the network domain commit to in terms of SLA, schema stability, and support?
• What does the platform team commit to in terms of tooling and onboarding support?
• What will the governance council learn from this pilot that shapes the rollout to the next domain?

In Databricks terms, the pilot deliverable is a Unity Catalog catalog for the network domain, containing the Service inventory as a Delta table tagged with canonical classification labels, shared via Delta Sharing with provisioning and billing, and monitored for freshness using a Databricks workflow that alerts the domain owner when the SLA is at risk.

Schedule a retrospective at four weeks and again at ninety days. The four-week retrospective surfaces friction in the platform and the governance process. The ninety-day retrospective reveals whether consuming domains are actually using the data product and whether the SLA commitments are realistic.

Step 7: Expand Incrementally and Establish Governance Rhythms

Expand domain by domain rather than migrating everything at once. After each domain onboards, feed findings back into the governance charter, the canonical entity definitions, and the platform configuration. Build a community of practice among data product owners so patterns and anti-patterns are shared, not rediscovered independently.

Not every domain belongs on the mesh. If a domain's data is simple, internally consumed, and served well by existing tooling, forcing it into the framework adds overhead without benefit.

Sustain the program through regular cadences:

Monthly Governance Council Meetings review proposed changes to canonical entity definitions, each backed by an ADR, discuss interoperability issues surfaced by consuming domains, and review readiness assessments for the next wave of domains.

Quarterly Common Model Reviews assess the canonical entity models, particularly high-contention concepts like Service, evaluate whether the constraint statements from Step 4 are being enforced or worked around, and deprecate canonical attributes that no domain is actively using.

Continuous Automated Monitoring tracks SLA compliance across published data products, surfaces orphaned data products where the declared owner has changed roles, and reviews Unity Catalog lineage reports to identify undeclared cross-domain dependencies before they become incidents.

The Balancing Act

Data mesh is a genuine architectural commitment, and federated governance adds complexity even as it provides structure. The 2026 picture is clearer than the early hype suggested: only around 18% of organizations have the governance maturity to successfully adopt data mesh in its full form. That doesn't mean others can't benefit from its principles, but it does mean honest assessment matters more than architectural fashion.

Autonomy vs. Consistency You're constantly balancing domain autonomy with the need for interoperability. Too much central control and you've just recreated the bottleneck. Too little and you have four definitions of "Service" that can't be joined in any meaningful query. The governance council is where these tensions get negotiated. The canonical model for Service names the shared concept and its core attributes. Each domain then extends it with their context-specific attributes, using their own domain dictionary to document local terminology.

Platform Investment Building a self-serve platform that makes governance automated and invisible requires significant upfront investment. You're trading central team headcount for platform engineering capability. Organizations that planned for this hybrid from the start achieved faster time to value and lower total cost of ownership than those that tried to bolt the platform on later.

Cultural Shift Domain teams need to think like product managers. This requires training, coaching, and often a shift in how performance is measured and rewarded. Your network operations team needs to care about the quality and discoverability of the data products they publish. This is the hardest part, and it takes years, not sprints.

Common Information Model Governance Your canonical models for core business concepts need to evolve without breaking existing consumers. For a telco this is acute: the Service concept spans network, product, billing, and provisioning, and changes to the canonical definition ripple across all four. This requires:

• Clear versioning strategies
• Backward compatibility requirements
• Deprecation policies with transition periods
• Active communication channels between domains

Organizational Readiness Data mesh assumes domain teams have the capability to own data products. If your teams are small, resource-constrained, or lack technical depth, you may need to build capability before you can truly decentralize. Re-badging existing IT teams without transferring genuine ownership and accountability is the most common failure pattern observed in practice.

The New Rules of Engagement

• Decentralize ownership, standardize interfaces. Let domains own their data, but enforce common patterns for how they expose and document it.
• Make governance computational. Encode standards in the platform so compliance is automated, not a checkbox exercise.
• Invest in the platform that enables autonomy. Self-service only works if the service is actually good enough to serve yourself with.
• Treat common models as living contracts. Your canonical definitions of Service, Customer, Product, and Order need governance processes that allow evolution without chaos. Domain extensions are expected and healthy. Incompatible redefinitions are not.
• Build the governance council as a collaborative forum. Standards imposed from above fail. Standards negotiated among peers with skin in the game succeed.
• Match the approach to the domain's maturity. Not every team needs the full mesh. Apply the principles where they create value and resist the temptation to boil the ocean.

One telco I worked with eventually made the shift. The central data team stopped trying to be the translators between network operations, product, billing, and provisioning, and became platform builders and a center of excellence instead. Network operations now owns and publishes infrastructure service data products. Product management owns catalogue and commercial service data products. Billing owns rated event data products. All four domains follow a common canonical definition of what a "Service" is at its core, how it is identified, and how quality is measured. When provisioning activates a Service, every domain can trace that entity through its lifecycle without anyone having to pick up the phone to ask which Service they actually mean.

The debates still happen, but now they are about improving the shared standards, not about whose definition of "Service" is the correct one.

What would federated governance look like in your organization? Which domains are ready to own their data as products?