Data Mesh Architecture: Von zentralen zu dezentralen Data Warehouses

Die Zahlen sind ernüchternd: Laut Gartner hat sich die durchschnittliche Bearbeitungszeit für neue Datenanfragen in Unternehmen von 18 Tagen im Jahr 2020 auf 34 Tage in 2025 fast verdoppelt. 67% der Unternehmen berichten, dass ihre zentralen Data Teams überlastet sind und mit der wachsenden Datennachfrage nicht mehr mithalten können. Für IT-Verantwortliche in KMU, die ihre Datenarchitektur zukunftsfähig gestalten wollen, wird die Frage immer drängender: Gibt es eine Alternative zum traditionellen Data Warehouse?

Das Problem zentraler Data Warehouses

Traditionelle zentralisierte Data Warehouses führen zu drei kritischen Engpässen: Erstens wird das zentrale Data Team zum Flaschenhals – jede neue Datenanfrage landet in einer wachsenden Warteschlange. Zweitens fehlt den zentralen IT-Teams oft die fachliche Expertise: Was bedeutet "aktiver Kunde" im Vertrieb konkret? Welche Produktionsmetriken sind wirklich geschäftskritisch? Drittens entstehen Skalierungsprobleme: Je mehr Datenquellen, Abteilungen und Anfragen hinzukommen, desto stärker wird der Engpass.

Diese Probleme verschärfen sich gerade jetzt, da 64% der deutschen KMU bereits moderne Datenmanagementsysteme einsetzen und gleichzeitig KI-Anwendungen Daten in neuer Qualität und Geschwindigkeit benötigen.

Data Mesh: Die dezentrale Alternative

Data Mesh ist ein seit 2019 von Zhamak Dehghani entwickelter Architekturansatz, der das zentrale Data Warehouse-Modell auf den Kopf stellt. Statt einer zentralen IT-Abteilung übernehmen die Fachabteilungen selbst die Verantwortung für ihre Daten. Das Konzept basiert auf vier Kernprinzipien:

• Domain-Oriented Decentralized Data Ownership: Vertrieb, Produktion oder Service managen ihre eigenen Daten als eigenständige "Datenprodukte"

• Data as a Product: Jeder Datensatz wird wie ein Produkt behandelt – mit Owner, SLAs, Dokumentation und Qualitätsmetriken

• Self-Serve Data Infrastructure: Eine zentrale Plattform stellt Tools bereit, mit denen Domain-Teams eigenständig Datenprodukte erstellen können

• Federated Computational Governance: Standards werden zentral definiert, aber dezentral in den Domains automatisiert durchgesetzt

Der Vorteil: Die Teams, die ihre Daten am besten verstehen, sind direkt dafür verantwortlich. Bottlenecks werden aufgelöst, Datenqualität steigt, und fachliche Expertise fließt direkt in die Datenmodellierung ein.

Die Herausforderung für KMU

So überzeugend Data Mesh in der Theorie klingt – für viele KMU ist die Umsetzung unrealistisch. Die größte Hürde ist organisatorisch: Data Mesh setzt voraus, dass jede Fachabteilung ein eigenes Engineering-Team hat. In Unternehmen unter 500 Mitarbeitern ist das selten der Fall. Hinzu kommt, dass IT in produzierenden Unternehmen oft kein wertschöpfender Kernprozess ist – große Transformationen werden daher schwer legitimiert.

Weitere Stolpersteine: Daten sind in KMU meist nicht fachlich geschnitten ("Kunde", "Produkt"), sondern nach Systemen organisiert (SAP, Salesforce). Viel Datenwissen steckt in den Köpfen einzelner Mitarbeiter und ist nicht dokumentiert. Und laut Gartner haben nur 18% der Organisationen die nötige Governance-Reife für Data Mesh. Eine vollständige Transformation dauert 12-24 Monate – ohne Garantie auf Erfolg.

Pragmatischer Einstieg: Minimum Viable Data Mesh

Die gute Nachricht: Es gibt einen Mittelweg. Experten wie INNOQ schlagen einen "Minimum Viable Data Mesh"-Ansatz vor, der die Kernideen übernimmt, aber organisatorische Überforderung vermeidet:

• Was übernommen wird: Data as a Product mit klaren Ownern, fachliche Verantwortung in den Abteilungen, automatisierte Governance statt Komitees

• Was vereinfacht wird: Zentrale IT übernimmt die technische Umsetzung, gemeinsamer Data Store statt Polyglot Persistence, kuratierte Views über bestehende Systeme

Der evolutionäre Einstieg könnte so aussehen: Start mit einem Cloud Data Warehouse für die wichtigsten Reports, schrittweise Lakehouse-Erweiterung bei unstrukturierten Daten und KI-Use-Cases, Data Mesh-Prinzipien inkrementell in 1-2 Pilot-Domains einführen. Erst wenn mehrere Datenprodukte existieren, wird eine Self-Service-Plattform aufgebaut.

Fazit: Evolution statt Revolution

Data Mesh ist für IT-Verantwortliche in KMU hochrelevant – aber kein Allheilmittel und schon gar kein Produkt, das man kaufen kann. Es ist ein organisatorischer Wandel, der Zeit, kulturelle Reife und realistische Erwartungen erfordert. Die Empfehlung nach Unternehmensgröße: Bis 100 Mitarbeiter genügt ein Cloud Data Warehouse, zwischen 100-500 Mitarbeitern eignet sich ein Data Lakehouse, ab 500 Mitarbeitern wird Data Mesh auf Lakehouse-Basis mit Pilot-Domains realistisch.

Entscheidend ist: Beginnen Sie evolutionär, nicht revolutionär. Lösen Sie konkrete Schmerzpunkte, bauen Sie fachliche Daten-Ownership schrittweise auf, und nutzen Sie bewährte Tools statt komplexer Plattform-Projekte. So holen Sie die Vorteile von Data Mesh – ohne Ihre Organisation zu überfordern.