Hardly any company ever designed its application landscape on a drawing board. It has grown, year after year, project after project, system after system. Whether SAP or non-SAP hardly matters anymore, because almost nobody operates in a technologically homogeneous world today. In this article, we show how to turn this sprawl into a viable data strategy: with Data Mesh as a method and a pragmatic starting point that has proven itself in practice.
An ERP here, a specialist system there, plus a data warehouse, custom-built applications, and the odd Excel world. Each system had its reason for being at the time. Together, they form a landscape that will look familiar to many:
Duplicate maintenance: The same data is maintained in several systems in parallel. This means double the effort and diverging versions.
Lack of transparency: Nobody can say with certainty which system is the leading one for which data object.
Outdated tools and complex scripts: Grown transformation logic that only a few people truly understand.
Interface sprawl: Many different interfaces, some of which do not work reliably.
Unclear responsibility: Responsibilities for data are not clearly defined.
The result: One and the same data object lives in several systems and shows a different truth in each. The problem is rarely the individual systems, but the lack of continuity across system and process boundaries. The consequences are little transparency, high coordination effort, and an increased risk of making decisions based on incomplete or faulty data.
A pattern we encounter again and again in practice: Various tools exist in the company that partly offer the same functionality, and it is not clear who is responsible for what. The classic example is the “SAP BI stack” alongside a “non-SAP BI stack.” There are two tools for data warehousing and reporting, and it remains unclear which one should be used when.
How this comes about varies:
Partly intentional: A second stack was deliberately introduced because it suits certain use cases better. But a clear functional separation is missing, meaning a rule for what belongs where.
Partly grown: Business units needed answers quickly, the central solution was too slow or too cumbersome, and over the years “shadow IT” emerged.
Same consequences from the symptoms above: Data is stored and maintained twice, figures diverge, and nobody can say which number is correct. The real problem is not the many tools, but the missing distribution of tasks and responsibilities.
The central question is: How do we deal with this? Do we focus on one technology stack, or do we deliberately run two?
Regardless of how the answer turns out: A further tool alone does not solve the problem.
At worst, it would just be one more system in the landscape. What is missing is a shared understanding of data. A data strategy clarifies which data exists, who is responsible for it, under which rules it is provided, and where to find it. This is exactly what Data Mesh is suited for: not as a technology, but as a method for data management.
Data Mesh is an approach to data management that shifts responsibility for data to where the business knowledge resides: the business units. Instead of collecting and managing all data in one central unit, data is organized in business domains. Each domain owns its data and provides it to others as a reliable product. Shared rules and a technical platform make sure everything fits together.
It is important to note that Data Mesh is neither a product nor a specific technology. It is a method that considers organization, responsibility, and architecture together, and it can be implemented with different tools, in the SAP world as well as outside it.
Data Mesh in four principles
Domain ownership: The business domain knows its data best and is responsible for it. Responsibility is distributed in a decentralized way instead of sitting with a central IT.
Data as a product: Data is provided so that others can use it: understandable, reliable, and of good quality.
Self-serve data platform: A technical platform makes domains less dependent on IT when they provide data independently.
Especially in a two-stack scenario, Data Mesh is attractive because it is technology-agnostic. One data product can live in the SAP stack, another in Databricks. What matters are responsibility, quality, and clear agreements.
Our project and practical experience has shown: start small, take a close look at individual parts and pilot there.
1. Clarify expectations and select one or two domains
Start with areas that have high business value, touch many systems and processes, and whose data problems are visible. They later serve as a blueprint. Before the first conversations, clarify the ground rules: This is not an audit, not an assessment of individual people or teams, and not about deciding on system replacements in the workshop. It is about a joint inventory in which known problems are named openly and prioritized together. This creates the openness you need for good results.
Conversations reveal what cannot be seen in systems alone. Per data object, the following set of questions has proven useful:
In which application and in which process does the data object reside?
Is it an as-is or to-be entity, a primary or secondary source, of internal or external origin?
What is the quality and completeness, and how many records are there?
Who is responsible from a business perspective (data owner), who maintains it (data steward), who uses the data?
Are redundancies known?
It is also worth looking at the lifecycle: Where does the data object originate? Which systems does it pass through afterwards? Where are there disconnects between systems, duplicate maintenance, and missing responsibility? What are the biggest pain points today, from both a business and a technical perspective?
On this basis, a lean dashboard is created. It shows systems and data objects as a network, filterable by domain, as-is/to-be state, data authority, and much more.
At a glance, you can see where data objects are maintained in several systems, where an owner is missing, and which domain is a good starting point. What-if questions can also be answered: What happens if we switch off a system? Which data objects would then have no source?
This way, decisions on stack focus, prioritization, and piloting are based on a shared picture instead of gut feeling. If you also want to measure where the organization stands, you can use a maturity model and compare the current maturity level with the desired ambition level. Measures can in turn be derived from this.
There are three typical paths for further expansion:
Sequential expansion: Domain by domain, with a full analysis. The risk is low and the business foundation is solid, but implementation is slow and the technical benefit is delayed.
Parallel build-up (our recommendation): The three pillars (domains with roles, data hub, enterprise data catalog) are built simultaneously with two domains as pioneers. This delivers visible value quickly, reduces pain points such as duplicate data entry early on, and enables iterative learning. The price: The remaining domains have not yet been analyzed in depth.
Full transformation: All domains at once. This immediately delivers a holistic target picture, but means high initial effort, high risk, and little flexibility.
For the technical implementation, the approach depends on how far the requirements and the technology selection have already been defined. If open questions remain, a proof of concept (PoC) can help to test possible solutions such as SAP Datasphere or Databricks, as well as an enterprise data catalog, under realistic conditions. If the requirements and the technology stack are already defined, it may make more sense to start implementation directly.
For the first data domain, interviews form the basis of the analysis. When transferring the approach to further domains, the effort can be reduced: An already established enterprise data catalog can provide a first overview of data assets and relationships through the available metadata, and thus specifically support the subsequent analysis.
We presented this approach in a presentation at the DSAG Annual Congress 2026 - you can find the key takeaways from the congress in our recap of the DSAG Annual Congress 2026. From our project experience, one thing is clear: start small, take a close look at individual parts and pilot there.
Data hub instead of patchwork: A data hub is more than a classic data warehouse: It integrates data from the decentralized domains, provides a unified view, and supports modern patterns such as lakehouse and data products. Important in the Data Mesh context: The hub is the technical platform, not the central owner. Responsibility remains in the domains. Whether SAP Business Data Cloud, Databricks, Microsoft Fabric, or Dremio is the right foundation depends on your situation.
In our exclusive whitepaper, we compare four platforms across 18 dimensions. Get your free copy here.
Enterprise data catalog as a central point of orientation: While the dashboard from the as-is analysis (see above) shows the current state, an enterprise data catalog creates a long-term overview of the data landscape. It helps answer three key questions: Where can which data be found? What does it mean from a business perspective? And who is responsible for it?
This includes technical and business metadata, a business glossary, the assignment of data responsibilities, and the tracking of data flows across system boundaries (data lineage). In addition, functions for data quality monitoring, governance processes, and role-based access control can be used.
While a data hub primarily aims to bring data together, reduce redundant data storage, and avoid manual interfaces, the enterprise data catalog creates transparency about data assets, responsibilities, and their relationships. This reduces coordination effort and makes it easier to find and use data in a targeted way.
Our recommendations
Think transformation and data management together. If a system migration, such as an ERP changeover, is coming up anyway, it is the best time to plan the data foundation alongside it.
Start with business-relevant domains. This is where the benefit is visible and the learning effect is greatest.
Think governance, transparency, and platform together. Modern data management emerges from the interplay of architecture (data hub), organization (domains, roles, governance), and transparency (enterprise data catalog), not from individual measures.
Historically grown application landscapes cannot be replaced overnight and they do not have to be. Whether one stack or two: Those who analyze systems and organization honestly and start small make their decision on a solid foundation. Data Mesh provides the methodological framework for this, with clear responsibility in the business units, data as products and shared rules of the game, regardless of whether your systems come from the SAP world or not.
Would you like to structure your grown data landscape, or are you unsure how to deal with a second stack in your business units? Whether inventory, data strategy, governance, or a PoC with SAP Datasphere, Databricks, or an enterprise data catalog: Our team of experts is happy to support you.