Data Mesh im SAP-Kontext
Stand 2026-09-03
Data Mesh verspricht, den zentralen Team-Engpass zu beheben, der die meisten SAP-Analytics-Programme ausbremst — doch in einer SAP-Landschaft ist die eigentliche Frage organisatorisch, nicht technisch: Können Einkauf, Finanzen und Logistik tatsächlich ein Data Product besitzen, oder bleibt das zentrale Team standardmäßig auf Abruf? S/4HANA liefert bereits über 8.000 CDS-Views als Rohmaterial, und Datasphere Spaces geben jeder Domäne bereits Isolation; die Lücke ist eine Self-Service-Plattform (typischerweise 3-5 fest zugeordnete Engineers) und ein an MDG verankertes kanonisches Schlüsselregister, ohne das domänenübergreifende Joins lautlos fehlschlagen. Die meisten SAP-Kunden sind 2026 — mit einem zentralen Team von 10-30 Personen und Domänenteams ohne Data-Engineering-Fähigkeit — für ein vollständiges Mesh noch nicht bereit, sodass die vertretbare Empfehlung ein gestufter, mesh-inspirierter zentralisierter Aufbau ist, der jetzt schon das Ownership-Vokabular übernimmt und die Umsetzung später verteilt. Berater, die diese Reifelücke diagnostizieren können — nicht nur Spaces konfigurieren —, besetzen eine enge Nische — SAP-Plattformtiefe plus Data Engineering plus Beratung zum organisatorischen Wandel — die bei Global-500-Multi-Domänen-Kunden zu Senior-/Experten-Tagessätzen bepreist wird.
Was Sie lernen
- Die Kernkonzepte von Data Mesh im SAP-Kontext verstehen
- Data Mesh in einem typischen SAP-Analytics-Projekt anwenden
- Die 3-5 häufigen Fehler erkennen und wissen, wie man sie vermeidet
- Diese Fähigkeit in der eigenen Personal Brand und im Tagessatz-Gespräch positionieren
Data Mesh im SAP-Kontext
Data Mesh ist ein architektonisches und organisatorisches Paradigma, das Daten als Produkt behandelt, die Datenverantwortung an die Business-Domänen-Teams verteilt, die sie am besten verstehen, und eine Self-Service-Infrastrukturplattform bereitstellt, damit diese Teams Daten unabhängig liefern, auffinden und konsumieren können — ohne jede Anfrage über ein zentrales Datenteam zu leiten. 2019 von Zhamak Dehghani vorgeschlagen, hat es sich von einer theoretischen Provokation zu einer Produktionsrealität in einer Teilmenge großer Unternehmen entwickelt. Für SAP-Praktiker wirft es eine konkrete und ehrliche Frage auf: Was bedeutet Data Mesh tatsächlich für eine SAP-Landschaft, und welche organisatorischen Vorbedingungen entscheiden darüber, ob es funktionieren kann?
Die vier Prinzipien und ihre SAP-Übersetzung
Prinzip 1 — Domänenorientierte, dezentrale Datenverantwortung.
In einem Data Mesh besitzt das Team, dem eine Business-Domäne gehört — die Einkaufsdomäne, die Finanzdomäne, die Logistikdomäne —, auch die Daten, die diese Domäne erzeugt, einschließlich ihrer Qualität, ihres Schemas, ihrer Dokumentation und ihres SLA. In einer klassischen zentralisierten Data-Warehouse-Architektur besitzt das zentrale BI-Team alle Datenprodukte. Im Mesh ist die Verantwortung verteilt.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung in SAP-Analytics-Projekten
- Zuerst die Kernkonzepte wiederholen: C090, C008, C087
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Eine europäische Versicherungsgruppe möchte die Schadenkosten nach Mitarbeiterregion und Policentyp analysieren — eine Abfrage, die Finance (S/4HANA) und HR (SuccessFactors) überspannt.
- Das Anti-Pattern erkennen und vermeiden: Mesh ausrufen, ohne Verantwortung zu verteilen — Für jede Domäne werden Datasphere Spaces gebaut, aber das zentrale SAP-Team liefert und pflegt weiterhin jedes Datenprodukt.
- Die Kernentscheidung des Moduls anwenden: Mesh, Fabric oder gestufter Hybrid.
- Die Beherrschung mit dem KPI verfolgen: Abdeckung der domänenbezogenen Datenprodukt-Eigentümerschaft.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.