Implement Data Mesh: ADLC as the Great Enabler

Over the past few years, data mesh has attracted significant attention. Organisations adopt it to address slow delivery, central bottlenecks, and unclear ownership in their data landscape. However, turning this ambition into practice can prove challenging.

The difficulty lies not only in designing the right technical architecture, but also in leading the organisational change, especially where technology, processes, and team responsibilities intersect.

In this article, we focus on the Developer Experience Plane, an enablement plane within a data mesh architecture that provides the shared capabilities, standards, and tooling that domain teams rely on to build, publish, and maintain data products effectively.

We also explore two key methodologies, the Analytics Development Lifecycle (ADLC) and Governance as Code, and show how they help translate data mesh from a conceptual model into a practical operating approach.

If you want to move beyond isolated pilots and scale adoption across domains, you need to design this enablement plane deliberately to support consistent, scalable delivery. This article will show you how.

The problem with implementing data mesh

The core concepts of data mesh are clear and the challenges it addresses have already been widely discussed. We touch upon these in our blog post “Data Mesh Adoption: A Business Leader's Perspective on the Benefits and Challenges”, which you can read on the Infinite Lambda Blog.

Yet many organisations still struggle to adopt and scale data mesh in practice.

In her article “Data Mesh Principles and Logical Architecture”, Zhamak Dehghani defines four core principles of this methodology as:

1. Domain ownership
2. Data as a Product
3. Self-serve platform
4. Federated governance

These principles do provide a coherent and practical foundation but prove difficult to put into action.

In our experience, organisations do not fail because they lack vision, motivation, or investment. They struggle because they underestimate the organisational and architectural changes it takes to implement data mesh.

Zhamak Dehghani describes a multi-plane data platform that supports data mesh across three distinct planes:

• Plane 1: infrastructure provisioning, including cloud infrastructure, storage, and compute
• Plane 2: developer experience, covering how teams build data products through shared processes, standards, and tooling
• Plane 3: consumer experience, including discovery, catalogue, access, and practical use cases

In practice, many organisations start with Plane 1 because they need infrastructure before anything else can function.

They invest significant time and resources in building this foundation. Business stakeholders expect visible outcomes, so attention then shifts to Plane 3, such as catalogue, discovery, and business use cases.

However, teams often neglect Plane 2, the developer experience. This plane demands deliberate work on engineering standards, delivery processes, platform capabilities, and day to day execution. When organisations treat it as secondary, they limit their ability to scale.

Without a well-designed and well-aligned developer experience plane, data mesh becomes a collection of loosely connected data domains supported by documentation and governance policies. When organisations invest properly in this plane, teams can build and deliver reliable data products independently and at scale.

The missing middle

As discussed earlier, many organisations approach data mesh from two extremes. At the top, they define governance frameworks. At the bottom, they provision infrastructure such as Snowflake accounts, other cloud resources, and sometimes a Kubernetes cluster.

But they often overlook the middle. This is where teams transform, test, curate, document, contract, and share data products. In many cases, teams leave this layer to evolve without clear standards or shared practices.

This middle layer determines if domain ownership works in practice. If a finance team owns finance data, that ownership must extend beyond access rights. The team needs clear processes, supported by appropriate tooling, that enable them to build, maintain, and publish data products in a consistent and scalable way.

These processes should enable a domain team to:

• Describe what their data product supports, including metrics, intended use, and freshness
• Define its structure clearly, including schema, data types, and field descriptions
• Set and enforce quality standards, such as preventing null values in critical columns
• Manage change and promote deployments across environments in a controlled way
• Publish the data product so other teams can discover and use it reliably
• Understand who depends on it and assess the impact of proposed changes

Without these capabilities, domain ownership quickly loses structure. Teams build pipelines in isolation, adopt inconsistent standards, ignore data contracts, and manage changes in an ad hoc way. Naturally, interoperability declines and trust erodes.

As we explained in our blog post “From Central to Mesh: How to Transform Governance Right?”, the challenge combines organisational and technical aspects. Teams need effective development practices and DevOps and DataOps support, or federated governance risks becoming disorganised and ineffective.

The Developer Experience Plane connects domain specific raw data with consumable data products. It forms the operational core of the mesh. Organisations that want their domain teams to build and share data products at scale must invest deliberately in this plane, developing it step by step with careful attention to processes, tooling, and execution.

What the Developer Experience Plane actually does

Before we define the specifics, it helps to clarify what a data product actually is in a data mesh.

What qualifies as a data product? In a data mesh context, a data product is not just data exposed as tables or views. It is a self-contained, governed, and consumable data asset owned by a domain team and delivered through a well-defined interface.

The contract for a data product can enforce:

• The schema (what columns exist, what types they are)
• Quality guarantees (e.g. ("This field is never null," "Values must be between X and Y")
• Freshness SLAs (e.g. ("Data is updated every 2 hours")
• Documentation (what it means, how to use it)
• Lineage (where it comes from, what it depends on)
• Access policies (who can see it)

Requirements

Dehghani sets out specific requirements for this plane:

Declarative data product definitions

Domain teams define their data product in code, including schema, data types, descriptions, and ownership. Defining products in code allows version control, testing, and controlled deployment.

Contracts as APIs

The interface between producer and consumer acts as an explicit contract. For example, if the Sales team changes their “customer” table schema while Marketing relies on it, the system should catch the breaking change during build, not when dashboards fail the next day.

Embedded quality

Tests and assertions are part of the data product definition and run on every build. Failed tests block deployment, embedding quality into the system rather than treating it as an afterthought.

Versioning and lifecycle management

Data products require versioning, deprecation, and eventual retirement. Consumers depend on a version, not a specific implementation.
When producers introduce breaking changes, they publish a new version and provide a clear migration path for consumers.

Domain boundaries in code

Ownership groups, access modifiers (public, protected, private), and naming conventions must be expressed in the architecture. The platform should enforce these domain boundaries automatically.

Automatic lineage

Lineage is generated from the code itself and remains accurate across time. It can track dependencies within and across domains without relying on separate, error-prone systems.

Cross-domain interoperability

One domain’s data product can be referenced by another without copying data, rewriting logic, or losing governance. References function as first-class dependencies.

So, how do you enable these capabilities?

Modern transformation tools like dbt provide many of these capabilities natively.

Declarative models, contracts, built-in testing, automatic lineage, and cross-project references make them ideal for building the Developer Experience Plane.

The key insight is that the transformation layer forms the centre of gravity of this plane, where all these requirements converge.

The ADLC for data products

Many data mesh discussions overlook a critical gap. Organisations rarely struggle because of missing technology. They struggle because teams lack mature development practices.

Consider software engineering. Developers use version control, CI and CD pipelines, code reviews, automated testing on every pull request, structured environment promotion from development to staging to production, and rollback mechanisms. Teams treat these practices as standard.

No responsible software team deploys to production without them.

In contrast, many domain teams that produce data products do not apply the same discipline. Teams often apply weak version control practices, skip CI and CD for data transformations, avoid structured code review for SQL logic, and run few automated tests on pull requests. Many teams also lack systematic environment promotion.

When teams operate this way, data mesh cannot scale reliably.

The Analytics Development Lifecycle brings established software engineering discipline into data product development. In practice, this means the following:

Version control

Every data product definition lives in Git. Teams track, review, and reverse every change. Anyone can see who changed what, when, and why, just as in software engineering.

Branch-based development

Developers work in isolated branches, separate from production. They merge changes through pull requests. Multiple contributors can develop features in parallel without interfering with each other.

CI on pull requests

Automated builds and tests run on every proposed change. If contracts break or tests fail, the system blocks the merge before it reaches production. Teams detect issues early rather than after dashboards fail.

Environment promotion

Teams promote changes through development, staging, and production environments in a controlled sequence. They validate data products at each stage before exposing them to consumers.

Impact analysis

Before merging a change, teams can assess which downstream consumers, including those in other domains, depend on the data product. This visibility reduces unexpected side effects.

Rollback

If anything breaks in production, teams can revert to a previous stable state through Git and established DevOps processes within minutes.

Why does this matter for data mesh?
Domain autonomy without the Analytics Development Lifecycle creates inconsistency and risk. The ADLC provides the structure and discipline that allow teams to operate independently while maintaining reliability across domains.

The dbt ecosystem has advanced these practices in analytics engineering. dbt Platform offers built in CI and CD, pull request based workflows, and environment management. These capabilities form the foundation that makes domain ownership sustainable in practice.

Governance as Code

Governance plays a central role in data mesh. It is not primarily about control. It enables interoperability at scale. The key question is clear: how can domains operate independently while still working together effectively?

Organisations should not treat governance as a separate system that sits outside delivery. They should embed it directly into the Analytics Development Lifecycle. As we discussed in our article on transitioning from central to mesh governance, teams must balance domain autonomy with organisation wide standards. The Developer Experience Plane operationalises this balance by building automated guardrails into the development workflow.

This plane should make governance seamless and largely automated. In practice, this means the following.

Naming conventions

Teams enforce naming standards through linting and CI rules. If a model does not follow the agreed convention, the build fails.

Data contracts

The system validates contracts at build time. If a developer introduces a breaking schema change, the build fails before deployment.

Lineage

The platform generates lineage directly from the code. It does not rely on a separate catalogue that can drift from reality. The lineage graph reflects actual dependencies.

Access boundaries

Teams define domain groups and access modifiers such as public, protected, and private in the architecture itself. Governance does not rely solely on warehouse permissions. The code expresses structural boundaries.

Meta-tagging

Developers embed PII flags, data sensitivity levels, and retention policies in the data product definition. Governance metadata lives alongside the code, not in a separate system.

In practice, governance flows as follows:

• A developer proposes a change through a pull request.
• CI runs tests, contract validation, linting, and impact analysis automatically.
• The system verifies cross domain dependencies and identifies potential downstream impact.
• Domain peers review the code.
• The team merges to production, having enforced governance during development rather than after deployment.

The Developer Experience Plane integrates governance into CI and CD pipelines instead of treating it as a separate bureaucratic layer.

Tools such as dbt support this approach through access modifiers and contract enforcement. Teams can define boundaries directly in code and combine them with CI and CD to achieve automated governance that scales with the organisation.

Cross-domain interoperability minus the chaos

A major practical risk in data mesh arises when domains build in isolation. The organisation then ends up with disconnected and incompatible data products rather than a coherent mesh. Preventing this outcome requires deliberate design.

Contracts as stable interfaces

Domains expose data products with enforced schemas and clear versioning. Consumers depend on the contract rather than the internal implementation. When a producer needs to introduce a breaking change, they release a new version and provide a defined migration path. This creates predictability and trust.

Cross-project references

One domain can reference another domain’s published data product without copying data or duplicating transformation logic. The reference acts as a first class dependency and appears in lineage and impact analysis.

For example, in dbt, teams can create cross project references to models in another project. A Marketing domain can reference the Sales “customer” model directly, without copying it. This approach reduces drift and maintains a governed dependency.

Cross-domain lineage

Lineage spans domains end to end. When a producer changes a data product, downstream consumer domains see the impact automatically. The system provides visibility without relying on manual coordination.

Independent deployment, connected execution

Each domain manages its own CI and CD pipeline and release cadence. At the same time, cross references ensure coherence at query time while preserving autonomy and coordination.

A mesh does not require separate infrastructure per domain. It requires clear ownership boundaries, independent deployment boundaries, and well defined contract interfaces. An organisation can operate a single data warehouse with multiple independently managed projects connected through cross references and still achieve a valid mesh architecture.

Recent capabilities such as cross platform Mesh in dbt extend this model further. One domain can operate on Snowflake while another runs on Google BigQuery, connected through open table formats such as Apache Iceberg. This approach reinforces the importance of open data infrastructure in enabling interoperability across platforms.

Do this Monday morning

Enough theory. Here are concrete steps you can take right now:

1. Start with domain boundaries
   Identify two or three domains that are ready to own their data products.
   A domain is ready when it has clear scope, a team that understands its data, and motivation to take responsibility for outcomes. Do not impose ownership on teams that lack capacity or commitment.
2. Adopt the ADLC as your standard
   Establish version control, CI and CD, automated testing, and pull request based workflows for data transformations before you roll out data mesh. This foundation enables domain autonomy without creating inconsistency.
3. Define contracts before building pipelines
   Clarify interfaces upfront. Specify column types, not null guarantees, freshness SLAs, and downstream dependencies. Identify who needs notification when changes occur. Contracts create trust between producers and consumers.
4. Invest in the Developer Experience Plane as platform infrastructure
   Treat this plane as the factory that produces data products, not just SQL transformations. Provide domain teams with a standardised, self serve toolkit that includes project templates, CI pipelines, linting rules, and contract patterns. The platform team should focus on enabling domains rather than building transformations for them.
   Tools such as dbt provide declarative models, built in testing, contracts, and structured projects. Combined with dbt Platform CI and CD capabilities, teams can implement an end to end Analytics Development Lifecycle.
5. Automate governance into the build process
   Embed naming conventions, contract validation, access modifiers, and impact analysis into CI and CD. Enforce these rules automatically on every pull request.
6. Do not boil the ocean
   Treat mesh as a spectrum rather than a binary shift. Move one domain at a time, iterate, refine, demonstrate value, and then scale.
7. Measure data product quality, not just uptime
   Track freshness, accuracy, coverage, adoption, and consumer satisfaction. These are product metrics. If no one uses or trusts a data product, it does not deliver value.

Ready to implement data mesh?

Most data mesh challenges stem from execution rather than intent.

Data mesh succeeds or fails in the Developer Experience Plane, the connective layer where teams actually build, test, version, and publish data products. This plane must provide declarative product definitions, enforceable contracts, embedded quality checks, CI and CD, accurate lineage, and structured lifecycle management. Teams need to embed these capabilities into daily delivery, not treat them as optional enhancements.

The Analytics Development Lifecycle and governance as code translate federated governance into enforceable guardrails. Together, they enable domains to operate independently while maintaining reliable, scalable cross domain interoperability.

If you are ready to explore how dbt can help enable data mesh at your organisation, request a demo.

____

More on data mesh:

• From Central to Mesh: How to Transform Governance Right
• Event-Driven Data Mesh: Understanding the Fundamentals
• Data Mesh Adoption: A Business Leader's Perspective on the Benefits and Challenges
• Data Mesh Principles and Logical Architecture

Visit the Infinite Lambda blog for more insights on leveraging cutting-edge data and AI technology.