Check it Out
awards
WiWo Award TRUSTEQ
BrandEins Berater 2026 Award
TRUSTEQ kununu awards
TRUSTEQ
CooperativeExcellence

Time to Take Responsibility for Data

Data Mesh

An old adage in computer science says: systems work until they don't.

One of the most common reasons for the failure of proven systems is growth. Especially when dealing with data, it can quickly happen that companies outgrow their existing architectures. This may initially look like a pure scaling problem, but it often stems from a more fundamental issue: context. Data is not just columns and rows; it carries meaning. And when it is unclear who is responsible, that very meaning is lost. In this blog post, you will read about how this problem arises and how companies can solve it.

Centralization as a Bottleneck

Many organizations have invested heavily in central data platforms: data lakes, data warehouses, and dedicated data teams. Data is intended to become the engine of decision-making. Initially, this works well—dashboards are created, reports provide initial insights, and executives leverage the value of data. However, as a company grows, so does the demand:

  • more data sources
  • more complex questions
  • higher frequency of requests

Suddenly, central architectures are overloaded, data teams lose track, and added value is lost. The original enabler—the central data team—becomes a bottleneck.

The Evolution of Modern Data Architectures

Modern data architectures have had to constantly adapt and evolve over time and according to specific needs:

A "Single Source of Truth": curated datasets, reliable reporting. This works well until demand explodes. Every new metric, every new dashboard, and every new data source must pass through the same bottleneck. Time-to-insight increases drastically. Additionally, the complexity of data models grows. More and more custom logic is built in, often grown organically over time and poorly documented. This makes even small changes risky. These problems lead to shadow solutions:

  • Teams export data to Excel
  • Teams build their own pipelines
  • Teams define their own KPIs

As a result, the "Single Source of Truth" is effectively lost, even though it formally still exists.

The "Data Lakehouse" or "Medallion" architecture structures data pipelines into three layers:

  1. Bronze (raw data)
  2. Silver (cleaned and standardized data)
  3. Gold (business-ready data)

Pipelines become more traceable, and data quality increases. In this model, responsibilities are clearly assigned for each processing layer.
Technically, this approach is sound, but organizationally, all data still flows through a central platform or data team. The bottleneck problem remains.

The answer is not less structure, but better distribution.

„How do you distribute responsibility so that data organizations can scale?"

The answer: Ownership.

Data is no longer just "stored"; it is actively shaped and accounted for. Business departments (domain teams) are no longer just data providers; they become owners of Data Products.

This also signifies a fundamental shift in perspective: data is no longer created merely as a byproduct of operational systems but is consciously treated as a product ("Data as a Product"). This works because the business departments understand their data best—they know the business logic, they know what is changing, and they know what decisions need to be made. Ideally, this results in clean, trustworthy, and clearly defined data that is transparently documented and immediately usable by other teams. To achieve this, every data product needs the following:

  • Clear definitions
  • Consistent structures
  • Reliable availability
  • Unambiguous ownership
  • Documented expectations

Data Mesh: How It All Comes Together

In 2019, researcher Zhamak Dehghani first described the approach that conceptually unites many of the previous ideas: the Data Mesh.


The idea: If domains treat their data as their own products, it no longer flows through a central bottleneck but moves freely through a networked system. Data products thus become consumable like internal APIs: other teams can independently discover, understand, and use them without needing to know the underlying operational systems or business processes in detail. While bottlenecks are reduced through distributed responsibility and data can be processed and structured more effectively through targeted domain knowledge, implementing a Data Mesh architecture simultaneously requires profound organizational changes.

Teams and systems must be realigned. Added to this is the challenge of consistent standards: if, for example, "Customer" is defined differently in every domain, new silos emerge at the semantic level. Therefore, strong governance structures and high organizational maturity are crucial. Furthermore, domains remain interdependent, as changes to one data product can impact many other teams. The central data team does not disappear either; instead, it takes on a new focus on infrastructure, platforms, and governance.

A functioning data mesh needs:

Conclusion

The goal of modern data strategies is no longer merely to store or centrally manage data. Rather, it is about treating data as independent products, with clear responsibility, defined quality standards, and a concrete benefit for other teams and corporate decisions. It is about making data usable, trustworthy, and scalable for the entire company. The Data Mesh principle is not just an architectural concept; it is an organizational paradigm shift.

Away from central control, toward distributed responsibility.

In this context, Data Warehouse, Medallion Architecture, and Data Mesh are by no means competing approaches. In reality, they complement each other:

  • Data Mesh (Ownership Model): Domains are responsible for their data products.
  • Medallion Architecture (Processing Model): Structured data pipelines (Bronze, Silver, Gold).
  • Data Warehouse / BI Layer (Consumption Model): Business users access data via dashboards and analytics.
"Which data architecture is ultimately the right one for a company depends significantly on factors such as organizational scale, the number of independent domains, team size, governance requirements, and the desired degree of autonomy. While Data Mesh can resolve central bottlenecks, particularly in highly scaled organizations, decentralization and domain-driven responsibility simultaneously bring higher requirements for governance, platform engineering, and operational efficiency. For smaller companies or manageable data landscapes, more centralized models therefore often remain the more pragmatic choice. At the same time, modern data architectures are continuously evolving—for example, through semantic or metrics layers, data contracts, data platform engineering, and AI- and LLM-native approaches like Agentic Data Mesh—whereby existing concepts are increasingly supplemented and more strongly integrated with one another."

Sotirios Patsos

Consultant Data Solutions

Sounds interesting? Reach out for expert consultation on your data architecture!

Upgrade your data architecture

Personalised solutions for your company's needs

Talk to an expert