Over the past several years, many organizations have deliberately evolved their architectures around domains and microservices. In my current project environment – online retail – examples of such domains include Search, Discovery, and Purchase.
As a result, teams have become more autonomous, gained a deeper understanding of their business processes, and are able to deliver features more quickly. They also own their data and data storage, eliminating the need to rely on centralized databases and the coordination overhead that comes with them.
However, this decentralization introduces a new challenge when it comes to sharing data for enterprise-wide analytics: Who is responsible for the data? How should it be shared? And how can organizations derive insights across domains without recreating central bottlenecks, such as a dedicated central data platform team?
Having worked across multiple teams for the same client, I have encountered these questions repeatedly. What quickly became clear is that the answers depend less on specific tools and more on how organizations think about data ownership – and how well that mindset aligns with their existing architecture.
One possible approach is Data Mesh, which focuses on the provision and consumption of analytical data. However, the concept can be taken a step further: data does not have to be used solely for analytics. Once enriched and transformed, it can also be fed back into operational systems to create additional business value. I will explore this idea in more detail later in the talk.
Data Mesh
Data Mesh is a socio-technical approach to decentralized data architectures. “Socio-technical” means that it combines technical solutions with team collaboration and ownership. The core idea is that domains (teams) take responsibility for their own data (Domain Ownership), provide it as products (Data as a Product), and are supported by a shared platform (Self-Serve Data Platform). Governance is not imposed centrally but organized in a federated manner (Federated Governance).
A practical example of a data product from my own experience is the provision of newsletter subscription and unsubscription data. Other teams can combine this data with order information, for example, to determine the conversion rate of specific campaigns – that is, how many purchases were actually generated by a newsletter campaign.
For organizations that are already structured around domains, Data Mesh initially appears to be a natural evolution. After all, the knowledge about the data already resides within the teams that generate it. At the same time, organizations often underestimate how significantly the process of integrating and analyzing data changes in practice.
Data Mesh is not merely a different technical architecture; it also introduces new expectations for teams. Data must be actively curated, documented, and made consumable for others. At this point, the theoretical concept quickly becomes a very real organizational challenge.
Starting Point: Decentralized Systems, Central Challenges
In modern architectures, teams own and evolve their services and databases independently. Data is intentionally not shared directly; instead, it is exposed through APIs (synchronously) or events (asynchronously). This principle promotes loose coupling and clear ownership and has become the standard approach for operational systems.
However, when it comes to analytical use cases, a challenge emerges. Data is distributed across numerous systems, its meaning varies from one domain to another, and cross-domain analyses require it to be integrated first. At the same time, new analytical requirements arise continuously and at increasingly shorter intervals. These demands are often driven by business stakeholders who need to make decisions more quickly.
In traditional setups, responsibility for this integration is frequently assigned to a central data platform team. This can quickly create bottlenecks: limited domain knowledge, long lead times for changes, and a growing gap between operational development and analytical consumption.
It is precisely this tension that has motivated the emergence of approaches such as Data Mesh.
The Journey to Data Mesh Is a Learning Process
What I have observed across my teams is that the path toward actively working within and with a Data Mesh is rarely a fully planned process; instead, it evolves step by step. This development can be well described as a journey through multiple stages and is therefore often used as a common pattern in the Data Mesh context (see Data Mesh Architecture).
At the beginning, there is a system with no analytical intent (Level 0 – No Data Analytics). The focus here is on delivering functionality and operating the system reliably and at scale. Analytical data plays only a minor role at this stage. This is typically the first MVP of a product that a team builds.
With or shortly after go-live, initial questions arise – marking the transition to Level 1 – Operational Database Queries. Teams begin to analyze production data directly within operational databases. This is a pragmatic and important first step toward building an understanding of their own data. However, since analytical access to production databases can impact system performance, this approach is not sustainable in the long run.
At Level 2 – Analyze Own Data, the way of working changes: teams start using a dedicated data platform for the first time. They store and analyze their own data in a structured way, implicitly creating their first (internal) data product. Decision-making becomes increasingly data-driven. By moving analytics workloads off the production system onto a separate data platform, potential performance issues are avoided.
The next step, Level 3 – Analyze Cross-Domain Data, emerges almost naturally once internal data is no longer sufficient. At this stage, either the team itself or connected business stakeholders require broader insights across domains. Teams begin integrating data from other domains. In our case, use cases included A/B testing and evaluating marketing campaigns across multiple systems – analyses that were not possible using only our own data. This is where the true value of a Data Mesh becomes visible for the first time.
At Level 4 – Publish Data Contract, collaboration becomes formalized. Data is no longer just consumed but intentionally provided for others. Key aspects include well-defined interfaces, clear semantics, and explicit agreements around freshness, update frequency, and expectations. Data contracts and governance become increasingly important.
These four stages essentially describe what Data Mesh is: a gradual shift of data ownership into the domains, supported by a platform and shared principles.
In my first team, we went through exactly these four stages. A key shift in mindset was no longer treating analytical data as a byproduct of a service. Instead, data products meant actively providing valuable data for other teams – with clear semantics, defined access methods, and the expectation that other teams would be able to use them effectively.
In practice, adopting Data Mesh also led us to new – and significantly faster – business decisions based on data analyses that were previously difficult or not flexible enough to perform.
When Data Flows Back Into the Product
In the original Data Mesh approach, feeding data back from the analytical domain into operational systems is explicitly out of scope or at least not intended as part of the core concept. However, in one of my teams I observed that once data products are established and actively used across domains, a new need can emerge: insights should not only be analyzed, but also reintegrated into operational systems.
This becomes particularly relevant for more complex scenarios, such as fraud detection, where the perspective of a single domain is no longer sufficient. Only the combination of multiple data points across several sources (data products) produces meaningful and actionable results. These insights are typically generated in the analytical domain. Especially with the use of AI in data analysis, new capabilities emerge that are not available within operational systems alone. The real value is only realized when these results are fed back into operational systems and used to support decisions. In fraud detection, for example, customers can be alerted when unusual activity is detected in their accounts – such as sudden address changes or unusually large orders compared to their normal behavior patterns – based on analytical signals.
From my perspective, this introduces a new Level 5 – Re-integrate Data, which goes beyond the traditional scope of Data Mesh.
The shift from the analytical back into the operational world also changes – and in many cases significantly increases – the requirements for data products.
- Data must not only be available, but also sufficiently up to date.
- Data contracts become critical for operational use cases.
- Integrations need to be standardized and designed for reuse across systems.
- Within a Data Mesh, data must also be protected against manipulation to avoid introducing new attack vectors into production systems.
Above all, however, the role of data shifts once again: it is no longer only a foundation for decision-making – it becomes part of the product logic itself.
What Is Often Overlooked
Data Mesh is less a technical topic and more a question of responsibility and collaboration. While building a platform is important, the key factor is that teams truly understand and treat their data as a product they own. The path to a functioning Data Mesh is a journey. Teams evolve step by step, and the stages cannot be skipped. It is also completely fine for different teams to be at different stages of this journey. However, teams can and should learn from each other’s experiences.
The real value often only becomes visible later – not in the first analyses, but when data is used across domain boundaries and, as in my case at Level 5, potentially even reintegrated into products.
This approach also becomes particularly interesting in the context of AI. Through a well-maintained data catalog, Data Mesh can provide the foundation for intelligent systems or agents to autonomously identify suitable data products, combine them, and use them for a wide range of use cases.
Conclusion
Data Mesh is a possible response to the challenges introduced by decentralization in building systems for analytical use cases. It is not a quick architectural shift, but rather a continuous learning process. In a Data Mesh architecture, each team must go through this journey on its own.
The central shift lies in responsibility: data is maintained and provided where it is generated. Over time, this leads to clear benefits, including higher data quality, faster decision-making, and systems that not only produce data but also make effective use of it.
Whether this remains purely within the analytical domain or, as in my case, extends back into operational systems must be evaluated and decided on a case-by-case basis.
