Data Mesh vs. Data Warehouse: Which Model Do Banks Need?

Data Mesh is a decentralised architectural paradigm for analytical data, coined in 2019 by Zhamak Dehghani at Thoughtworks. The approach breaks radically with the tradition of centralised Data Warehouses and shifts responsibility for data to where it originates and is best understood: the business domains. For the German banking sector, shaped by regulatory complexity and deep-rooted legacy structures, the concept holds enormous potential – but also considerable challenges.

Architecture Comparison in Detail

The paradigm shift from Data Warehouse to Data Mesh affects not only the technical architecture but fundamentally the question of who in an organisation is responsible for data – and how that responsibility scales.

Dimension	Data Warehouse	Data Mesh
Topology	Centralised – a monolithic repository	Decentralised – distributed, domain-specific data products
Ownership	Central BI/data team owns and maintains all data	Business domains own and are responsible for their own data
Scaling	Technical (more storage, more compute)	Organisational (more teams can deliver in parallel)
Governance	Top-down, centrally controlled	Federated, through policies and automation
Bottleneck	Central team becomes the bottleneck	Coordination overhead between domains increases
Technology	Unified platform (Snowflake, Redshift, BigQuery)	Technology-agnostic – each domain selects its own tools

A Data Warehouse remains the right choice when the organisation is manageable in size, few domains exist and a central team can handle the data workload. It is proven, well understood and supported by a mature tooling ecosystem. A Data Mesh becomes relevant when an organisation grows so large and complex that the central data team becomes a bottleneck – typically with dozens of domains and independent development teams.

In practice, hybrid approaches are common: a Data Warehouse or Lakehouse as the technical foundation, combined with Data Mesh principles such as Domain Ownership and Data-as-a-Product at the organisational level.

Domain Modelling for Banks

Banks have grown organically over time, are regulatorily complex and often organised along product silos – which does not necessarily yield the right domain structure for a Data Mesh. The methodological foundation is provided by Domain-Driven Design (DDD) as defined by Eric Evans.

DDD Concepts in a Banking Context

Bounded Contexts define clear boundaries within which a specific domain model applies. In a bank, "credit" in the corporate banking domain may mean something different from "credit" in the retail banking domain – and precisely this ambiguity must be made explicit.

Ubiquitous Language ensures that a consistent domain-specific vocabulary exists within each domain. Particularly in banking, where terms like "position", "exposure" or "settlement" vary depending on context, this is critical.

Context Mapping describes the relationships between domains – who supplies data to whom, where overlaps exist, and where dependencies lie.

Methods for Domain Identification

1. Event Storming — In facilitated workshops, business events along a process are captured: "Trade captured", "Settlement initiated", "Regulatory report generated". The natural clusters of these events reveal domain boundaries.

2. Business Capability Mapping — Maps the bank's capabilities independently of the organisational structure. The guiding question is: "What must the bank be able to do?" rather than "Who does what?".

3. Value Stream Mapping — Traces the path from customer need to value delivery and identifies natural hand-off points – these often mark sensible domain boundaries.

4. Data Lineage Analysis — Leverages existing data flows as an empirical basis. Where data is tightly coupled, it belongs in the same domain. Where clear interfaces exist, a domain boundary is likely.

Bank-Specific Challenges

Cross-cutting regulatory requirements such as BCBS 239, AnaCredit, DORA and MaRisk cut across all domains. The art lies in modelling regulatory requirements as consuming domains that place clearly defined data demands on the supplying domains – rather than building a centralised "regulatory database".

Shared Entities present a particular challenge: a customer, a security or a counterparty exists across many domains simultaneously. This calls for the concept of a Polysemantic Data Product – each domain maintains its own view of the entity, but there are agreed identifiers and core attributes as a Golden Source, standardised through Federated Governance.

Legacy systems at many German banks lack clear domain boundaries. A pragmatic approach: introduce Anti-Corruption Layers (a DDD concept) between legacy systems and the new domain data products.

A Pragmatic Approach: Implementation Roadmap

Rather than a big-bang approach, an iterative strategy has proven effective. The following roadmap outlines the recommended path for introducing Data Mesh at a German bank:

Phase 1 – Identify pilot domains: Select two to three clearly delineated domains with motivated teams – for example, securities settlement and market data.

Phase 2 – Define initial data products: Clarify interfaces, establish quality standards and agree on SLAs. Build Anti-Corruption Layers to legacy systems.

Phase 3 – Build the self-serve platform: Provide infrastructure that enables domain teams to independently create and operate data products.

Phase 4 – Establish Federated Governance: Translate lessons learned from the pilot domains into cross-cutting governance standards. Enforce interoperability, security and compliance through automation.

Phase 5 – Scale to further domains: Gradually onboard additional domains based on established standards and the platform. Secure organisational anchoring through a mandate from senior management.