Data Mesh: Wann lohnt sich dezentrale Datenverantwortung?

Dein zentrales Datenteam liefert zuverlässig, trotzdem wächst die Warteschlange: Der Vertrieb braucht eine neue Umsatzsicht, die Produktion eine Qualitätsauswertung und der Einkauf belastbare Lieferantendaten. Ist Data Mesh die passende Antwort? Vielleicht. Entscheidend ist nicht die Zahl der Anfragen, sondern ob Deine Fachdomänen Daten dauerhaft verantworten können – fachlich, technisch und im Betrieb.

Kurz gesagt: Data Mesh lohnt sich, wenn mehrere eigenständige Fachdomänen ihre Daten besser verstehen als ein zentrales Team und verlässlich nutzbare Datenprodukte betreiben können. Fehlen dafür Kapazität, gemeinsame Standards oder eine unterstützende Plattform, genügt häufig ein zentrales oder hybrides Modell. Ein Data Lakehouse ist dabei keine Gegenposition: Es kann die technische Grundlage für Data Mesh bilden.

Was ist Data Mesh und welches Problem löst es?

Data Mesh ist ein Organisations- und Architekturansatz, bei dem Fachdomänen die Verantwortung für ihre Datenprodukte übernehmen. Er soll verhindern, dass ein zentrales Datenteam zum dauerhaften Übersetzer und Engpass zwischen Datenquellen und Datennutzern wird.

Eine Domäne ist ein fachlich zusammenhängender Bereich, beispielsweise Einkauf, Produktion oder Vertrieb. Sie muss nicht exakt einer Abteilung entsprechen. Entscheidend ist, dass ihre Daten und Geschäftsregeln sinnvoll zusammengehören.

Der Ansatz verbindet vier Prinzipien:

• Domänenorientierte Verantwortung: Fachlich zuständige Teams verantworten die bereitgestellten Daten über deren Lebenszyklus.
• Daten als Produkt: Datenangebote werden für konkrete Nutzer entwickelt, dokumentiert und verlässlich betrieben.
• Self-Service-Datenplattform: Gemeinsame Werkzeuge erleichtern Bereitstellung, Tests, Zugriff und Monitoring.
• Föderierte Governance: Domänen arbeiten eigenständig innerhalb verbindlicher, domänenübergreifender Regeln.

Data Mesh bedeutet deshalb nicht, dass jede Abteilung ihre eigene Plattform beschafft. Ohne gemeinsame Infrastruktur und überprüfbare Standards entstehen lediglich neue Datensilos.

Wann lohnt sich Data Mesh für den Mittelstand?

Data Mesh lohnt sich, wenn fachliche Vielfalt und Abstimmungsaufwand die zentrale Datenorganisation dauerhaft überfordern und die Domänen Verantwortung tatsächlich übernehmen können. Unternehmensgröße oder eine bestimmte Datenmenge allein rechtfertigen den Ansatz nicht.

Teamreife: Können Domänen mehr als Anforderungen formulieren?

Prüfe nicht nur, ob Fachbereiche ihre Kennzahlen kennen. Ein datenproduktfähiges Team muss außerdem Änderungen priorisieren, Datenqualität beurteilen und auf Störungen reagieren können. Data Engineering muss dafür nicht vollständig in jeder Domäne sitzen; gemeinsam genutzte Spezialisten sind möglich.

Wichtige Prüffragen sind:

• Gibt es dauerhaft reservierte Kapazität für Entwicklung und Betrieb?
• Versteht das Team Quellen, Geschäftsregeln und typische Qualitätsprobleme?
• Kann es Anforderungen verschiedener Datennutzer gegeneinander abwägen?
• Sind automatisierte Tests, Monitoring und ein geregelter Änderungsprozess umsetzbar?

Wenn Verantwortung nur zusätzlich zum Tagesgeschäft vergeben wird, ist Dezentralisierung meist ein Etikett statt einer belastbaren Arbeitsweise.

Zentral oder hybrid: Was reicht zunächst aus?

Ein zentrales Modell genügt häufig, wenn wenige Teams ähnliche Auswertungen benötigen und gemeinsame Definitionen schnell abstimmen können. Es bündelt knappe Spezialkenntnisse und vermeidet mehrfach aufgebaute Betriebsprozesse.

Ein hybrider Einstieg ist sinnvoll, wenn einzelne Domänen bereits reif sind, andere aber Unterstützung brauchen. Dann können Fachbereiche Definitionen und Prioritäten verantworten, während ein zentrales Team die technische Umsetzung übernimmt. Dezentrale Verantwortung muss nicht überall gleichzeitig beginnen.

Wie müssen Domänenschnittstellen für Data Mesh aussehen?

Domänenschnittstellen müssen Bedeutung, Struktur, Qualität und Änderungsverhalten der bereitgestellten Daten eindeutig beschreiben. Ein freigegebener Tabellenzugriff allein ist noch keine belastbare Schnittstelle.

Betrachte ein hypothetisches Beispiel: Der Vertrieb stellt Auftragsdaten bereit, die Produktion nutzt sie zur Kapazitätsplanung. Beide Teams müssen wissen, ob ein stornierter Auftrag enthalten bleibt, wann eine Mengenänderung sichtbar wird und welche Kennung einen Auftrag eindeutig identifiziert.

Ein Datenvertrag, häufig als Data Contract bezeichnet, hält solche Erwartungen fest:

• Inhalt: Welche Geschäftsvorgänge und Attribute umfasst das Produkt?
• Semantik: Was bedeuten Status, Zeitstempel und Kennzahlen?
• Qualität und Aktualität: Welche Zusagen gelten, und wie werden sie geprüft?
• Zugriff: Wer darf welche Daten zu welchem Zweck nutzen?
• Änderungen: Wie werden Versionen, Übergangsfristen und Abkündigungen behandelt?

Besonders wichtig sind gemeinsame Schlüssel und domänenübergreifende Begriffe. Wenn Vertrieb und Finance Umsatz unterschiedlich definieren, darf diese Differenz bestehen – sie muss aber sichtbar und für Nutzer verständlich sein. Data Mesh ersetzt diese Abstimmung nicht.

Welchen Aufwand verursachen Datenprodukte?

Der Aufwand eines Datenprodukts umfasst nicht nur seine Entwicklung, sondern auch Betrieb, Support und Weiterentwicklung. Wirtschaftlich sinnvoll wird es, wenn sein wiederkehrender Nutzen diese dauerhafte Verantwortung rechtfertigt.

Eine Tabelle wird nicht dadurch zum Datenprodukt, dass sie einen Namen und einen Verantwortlichen erhält. Dazu gehören ein klarer Nutzerkreis, ein beschriebener Zweck, dokumentierte Schnittstellen und überprüfbare Qualitätszusagen.

Was in die Aufwandsschätzung gehört

Berücksichtige neben Datenanbindung und Transformation auch Tests, Zugriffsmanagement, Dokumentation, Monitoring, Fehlerbehebung und Änderungen an Quellsystemen. Hinzu kommen gemeinsame Plattformleistungen und die Abstimmung mit anderen Domänen.

Eine pauschale Kostenzahl wäre deshalb wenig hilfreich. Schätze stattdessen für ein konkretes Produkt den einmaligen Aufbau und den laufenden Kapazitätsbedarf getrennt. Prüfe anschließend, welche wiederkehrenden manuellen Arbeiten entfallen und welche Entscheidungen damit besser unterstützt werden.

Nicht jede Ad-hoc-Auswertung braucht ein eigenständiges Datenprodukt. Werden Produkte zu kleinteilig geschnitten, steigen Schnittstellen- und Betriebsaufwand. Sind sie zu breit, entsteht innerhalb der Domäne erneut ein schwer steuerbarer Sammelbestand.

Data Mesh vs Data Lakehouse: Alternative oder Ergänzung?

Data Mesh und Data Lakehouse sind keine direkten Alternativen: Data Mesh beschreibt vor allem die Organisation von Datenverantwortung, ein Data Lakehouse die technische Datenarchitektur. Ein Lakehouse kann zentral betrieben werden und gleichzeitig Datenprodukte mehrerer eigenständig arbeitender Domänen unterstützen.

Ein Data Lakehouse verbindet die flexible Speicherung unterschiedlicher Daten mit Verwaltungs- und Analysefunktionen, wie sie aus dem Data Warehouse bekannt sind. Für Data Mesh kann es gemeinsame Dienste bereitstellen: Katalogisierung, Zugriffskontrolle, Verarbeitung und die Bereitstellung von Daten für Analytics oder Machine Learning.

Plattformen wie Databricks oder Microsoft Fabric können Teile dieser Grundlage abdecken. Ihr Einsatz erzeugt jedoch noch kein Data Mesh. Fachlich tragfähige Domänen, nutzbare Datenprodukte und verbindliche Schnittstellen bleiben organisatorische Aufgaben.

Die Architekturfrage lautet daher nicht „Mesh oder Lakehouse?“, sondern: Welche Aufgaben zentralisieren wir, damit Domänen sicher und effizient eigenständig arbeiten können? Speicher, Identitätsverwaltung und Betriebsstandards müssen dafür nicht pro Domäne neu aufgebaut werden.

So gehen wir vor

Wir prüfen zuerst, wo dezentrale Verantwortung einen konkreten Engpass löst. Erst danach entscheiden wir, welche organisatorischen und technischen Änderungen dafür nötig sind.

1. Engpass sichtbar machen: Gemeinsam verfolgen wir einen konkreten Datenbedarf von der Quelle bis zur Nutzung. Dabei unterscheiden wir fehlende Kapazität, unklare Definitionen und technische Hindernisse.
2. Domänen und Reife prüfen: Wir untersuchen fachliche Grenzen, Abhängigkeiten und verfügbare Betriebsfähigkeit. Daraus ergibt sich, ob ein zentrales, hybrides oder dezentrales Modell passt.
3. Ein Datenprodukt erproben: Wir wählen einen begrenzten Anwendungsfall mit echten Nutzern. Schnittstelle, Qualitätszusagen und Änderungsprozess werden von Anfang an mitgedacht.
4. Plattformbedarf ableiten: Wir klären, welche gemeinsamen Dienste fehlen und was die vorhandene Plattform bereits leistet. So vermeiden wir eine vorschnelle Neuanschaffung.
5. Betrieb bewerten: Wir prüfen Nutzbarkeit, Zuverlässigkeit, Abstimmungsaufwand und laufenden Kapazitätsbedarf. Erst wenn der Ansatz trägt, übertragen wir ihn auf weitere Domänen.

Erst Verantwortung klären, dann Architektur ausbauen

Data Mesh ist dann sinnvoll, wenn dezentrale Verantwortung bessere Datenangebote ermöglicht – nicht, wenn sie lediglich Arbeit vom zentralen Team in Fachbereiche verschiebt. Ein gut betriebenes zentrales Modell ist oft wertvoller als ein organisatorisch überforderndes Mesh.

Du möchtest prüfen, welches Modell zu Deinen Teams und Deiner bestehenden Architektur passt? Ailio unterstützt Dich aus Bielefeld und Hamburg dabei, eine passende Datenplattform aufzubauen – mit klaren Schnittstellen und einem Betriebsmodell, das Deine Organisation tragen kann.