Moderne Ansätze für Data-Platforms

Einleitung

Mit zunehmender Komplexität organisieren Unternehmen ihre Tätigkeiten in unterschiedlichen Fachbereichen, so genannten Domains. Beispiele sind Logistik, Kundenbeziehungsmanagement, Auftragsabwicklung, … Eigentümer von operativen Daten ist jeweils die Domain, die diese Daten für die Ausführung ihrer Geschäftsprozesse benötigt. Beispielsweise ist die Domain CRM Eigentümer von Kundendaten. Andere Beispiele sind Bestellungen im Online-Handel, Bewegungen von Gütern in und aus einem Lager, oder Aktivitäten auf einer Webseite. Daten akkumulieren über die Zeit und werden zu historischen Daten.

Historische beziehungsweise analytische Daten haben große Bedeutung für Unternehmen. Sie unterstützen strategische Entscheidungen, helfen, das Verhalten von Kunden zu verstehen und das Kundenerlebnis zu verbessern, können die Preisgestaltung automatisieren oder Betrugsversuche erkennen – um nur ein paar Beispiele zu nennen.

Datengetriebene Unternehmen treffen Entscheidungen auf der Basis analytischer Daten – von strategischen über taktischen Entscheidungen bis hin zu Abläufen in operativen Systemen. Dafür ist es nötig, dass geeignete analytische Daten leicht gefunden und mit minimalem Aufwand genutzt werden können. Es erfordert aber auch, dass Fehlentscheidungen aufgrund von Missverständnissen über Datenqualität oder Bedeutung analytischer Daten vermieden werden.

In diesem Artikel diskutieren wir die Herausforderungen, vor denen Unternehmen mit komplexen Geschäftsprozessen und Technology-Stacks bei der Entwicklung einer Data-Platform stehen. Wir vergleichen die klassischen und sich konzeptionell gegenüberstehenden Ansätze von

• Data-Warehouse und
• Data-Lake.

Schließlich vergleichen wir die drei neueren Ansätze,

• Data-Lakehouse,
• Data-Fabric und
• Data-Mesh,

die auf unterschiedliche Weise versprechen, die Probleme von Data-Warehouses und Data-Lakes zu lösen.

Herausforderungen für Data-Platforms

Das Design einer Data-Platform für ein datengetriebenes Unternehmen birgt viele Herausforderungen.

• Wie werden analytische Daten über Domain-Grenzen hinweg integriert und verwaltet?
• Wie wird garantiert, dass die von komplexer und veränderlicher Geschäftslogik abhängige Bedeutung analytischer Daten nicht verloren geht?
• Wie werden heterogene Technologien zur Speicherung und Verarbeitung von analytischen Daten für verschiedene Anwendungsfälle unterstützt?
• Wie werden Legacy-Komponenten integriert? Und wie wird die Data-Platform auf einen sich weiter entwickelnden Technologie-Stack vorbereitet?

Es ist wichtig, eine Balance zwischen Standardisierung und Kontrolle auf der einen Seite, und Offenheit, Flexibilität, sowie dem verteilten Charakter des Expertenwissens in den Domänen auf der anderen Seite zu finden. Nur so kann der größte Nutzen aus analytischen Daten gezogen werden. Anderenfalls riskiert die Data-Platform, entweder die Wertschöpfung aus analytischen Daten zu bremsen oder umgangen zu werden.

Ein wesentlicher Aspekt jeder Data-Platform sind Metadaten, d.h., Daten über analytische Daten. Metadaten garantieren, dass analytische Daten über Domain-Grenzen und Technologien hinweg gefunden und verstanden werden können, und dass Zugriffskontrolle und regulatorische Anforderungen korrekt angewendet werden.

Domain-übergreifende analytische Daten

Analytische Daten werden oft über Domain-Grenzen hinweg genutzt. Beispielsweise kann eine Domain analytische Daten einer anderen Domain benötigen, um ein Machine-Learning-Model zu trainieren. Auch Entscheidungsträger kombinieren oft analytische Daten verschiedener Domains, um mittels Business-Analytics zu neuen Erkenntnissen zu gelangen.

Der Austausch analytischer Daten über Domain-Grenzen hinweg bringt jedoch einige Herausforderungen mit sich. Diese müssen berücksichtigt werden, um eine langfristige und verlässliche Nutzung analytischer Daten sicherzustellen.

• Analytische Daten kommen potenziell aus sehr verschiedenen Quellen wie operativen Systemen oder externen Partnern. Diese können unterschiedlichste Technologien und Datenstrukturen nutzen.
• Die Bedeutung analytischer Daten hängt von Details der Geschäftsprozesse der jeweiligen Domain ab. Beispielsweise kann eine Bestellung im Online-Handel eine komplexe Folge von Zuständen durchlaufen.
• Die verwendeten Technologien, Datenstrukturen, und auch die Bedeutung der Daten können sich – abhängig von den Anforderungen der Geschäftsprozesse und operativen Systeme der Domain – über die Zeit verändern.
• Verschiedene Domänen benutzen gelegentlich dieselben Namen für unterschiedliche Konzepte. Dies kann leicht zu Missverständnissen führen.

Data-Governance

Das Ziel von Data-Governance ist es, Produzenten und Konsumenten Vertrauen in analytische Daten und ihre Nutzung zu geben. Erst dadurch wird eine breite Verfügbarkeit analytischer Daten und eine Selbstverständlichkeit in ihrer Nutzung ermöglicht. Im Fall von personenbezogenen Daten sind auch die Interessen der Subjekte dieser personenbezogenen Daten, beispielsweise der Kunden eines Online-Handels, zu berücksichtigen.

Für Produzenten ist es wichtig, dass ihre analytischen Daten nur von den richtigen Personen und für die richtigen Zwecke genutzt werden können, dass sie in Übereinstimmung mit regulatorischen Anforderungen, z.B. der DSGVO, und Unternehmensinteressen gespeichert und geteilt werden, und dass sie von potenziellen Konsumenten in ihrer Bedeutung und Datenqualität nicht missverstanden werden.

Für Konsumenten muss es leicht sein, geeignete analytische Daten für ihre Anwendungsfälle zu finden. Zudem müssen diese analytischen Daten verständlich und in Bezug auf ihre Datenqualität transparent sein. Konsumenten müssen auch sicher sein können, dass sie analytische Daten nicht versehentlich auf eine Weise nutzen, die im Konflikt mit regulatorischen Anforderungen oder Unternehmensinteressen steht.

Die Subjekte personenbezogener Daten sind nur bereit, ihre Daten zu teilen, wenn sie die Autonomie über diese Daten behalten. Damit ist gemeint, dass sie sich darauf verlassen können, dass diese Daten nur für von ihnen genehmigte Zwecke verwendet werden, und dass ihre Daten – entsprechend den Anforderungen der DSGVO – bei Bedarf korrigiert und auf Anfrage sogar gelöscht werden.

Heterogene Technologien für Analytische Daten

Die Komplexität und Vielfalt von Geschäftsprozessen nimmt in vielen Unternehmen immer weiter zu. Hiermit geht einher, dass auch die Komplexität und Vielfalt der in Geschäftsprozessen gesammelten und genutzten analytischen Daten immer weiter zunimmt.

Aber auch die Landschaft von Strategien und Technologien zur Speicherung und Integration analytischer Daten wächst in ihrer Komplexität und Vielfalt. Einige Strategien priorisieren Skalierbarkeit und Flexibilität, nehmen aber ein geringes Maß an initialer Datenmodellierung in Kauf. Andere betonen die Wichtigkeit eines konsistenten und integrierten Datenmodells, um die leichte Nutzbarkeit analytischer Daten für bestimmte Anwendungsfälle zu garantieren. Zudem wächst auch die Vielfalt an Technologien für analytische Daten immer weiter – sogar im selben Unternehmen können diese über eine hybride Cloud-Umgebung aus On-Premise Komponenten und Komponenten in der Public-Cloud verteilt sein.

Datenformate

Für verschiedene Anwendungsfälle sind unterschiedliche Strategien geeignet, analytische Daten zu strukturieren und zu speichern. Relationale Tabellen in einem sogenannten Stern-Schema sind für Business-Analytics mit typischen Business-Intelligence-Tools besonders gut geeignet. Anwendungen wie Betrugserkennung, die eine besonders zeitnahe Verarbeitung analytischer Daten erfordern, können besonders gut mit Event-Streams verwirklicht werden. Andere Anwendungsfälle von Data-Analytics und insbesondere Machine-Learning können am besten mit einfachen “flachen” Dateiformaten wie CSV umgehen. Teils können diese sogar von Daten in ihrer ursprünglichen, von den Quellen vorgegebenen unstrukturierten oder semi-strukturierten Form profitieren.

Damit stellt sich die Frage ob analytische Daten

• in einer gesäuberten und kanonisch strukturierten Form (Schema-On-Write) oder
• als Rohdaten in einer potenziell unstrukturierten und durch die Quelle vorgegebenen Form (Schema-On-Read)

gespeichert werden sollte. Im ersten Fall ist das Risiko für Missverständnisse in der Interpretation und Nutzung der analytischen Daten geringer, da vorbereitende Transformationen nahe der Quelle und durch ihre Experten stattfinden. Auf der anderen Seite führt eine frühe Festlegung darauf, welche Daten in welcher Form aufbewahrt werden, zu einem Verlust an Flexibilität und potenziell sogar zu einem Verlust von historischen Daten. Im zweiten Fall verbleiben analytische Daten vorerst in ihrer Rohform – bereit dafür, für neue Anwendungsfälle geeignet aufbereitet zu werden. Dies setzt allerdings voraus, dass Konsumenten die Feinheiten der analytischen Daten in ihrer, ggf. durch operative Systeme vorgegebenen, Rohform verstehen. Missverständnisse können leicht geschehen, und der Aufwand zur Säuberung und Aufbereitung der analytischen Daten wiederholt sich für jeden Anwendungsfall.

Hybrid-Cloud-Umgebungen

Es ist nicht ungewöhnlich, dass analytische Daten in einem Unternehmen über verschiedene Technologien hinweg gespeichert und verarbeitet werden. Ein Grund dafür kann sein, dass sich der Technologie-Stack aufgrund neuer Anwendungsfälle weiterentwickelt. Ein anderer möglicher Grund sind aber auch organisatorische Veränderungen, etwa durch die Fusion mit oder die Akquise von anderen Unternehmen. Analytische Daten können auf diese Weise sogar über private Cloud-Umgebungen und IaaS- und PaaS-Anbieter in der Public-Cloud verteilt sein. Es ist zu erwarten, dass sich diese Landschaft von Technologien im Laufe der Zeit weiter diversifiziert.

Eine Datenstrategie muss absichern, dass analytische Daten über verschiedene Technologien hinweg gefunden und miteinander kombiniert werden können, und dass sie den gleichen Richtlinien der Data Governance folgen.

Die Gefahr von Schattenkopien

Eine Data-Platform, die die verteilte Natur analytischer Daten, ihrer Quellen, Experten und Anwendungsfälle, nicht berücksichtigt, wird schnell zu einem Flaschenhals. Sie riskiert, das Onboarding neuer Datenquellen oder Anwendungsfälle zu behindern, oder erschwert die Kommunikation von – über die Zeit hin unvermeidlichen – Veränderungen zwischen Produzenten und Konsumenten analytischer Daten. Eine Data-Platform kann sich auch als zu unflexibel herausstellen, um neue Technologien, Datenformate, oder neue Anforderungen an Data-Governance zu integrieren, z.B. aufgrund von Anforderungen der DSGVO.

In solchen Fällen riskiert das Unternehmen, dass aus pragmatischen Gründen Schattenkopien analytischer Daten entstehen, beispielsweise wenn ein Anwender einen Datensatz nicht selbst in der Data-Platform finden kann, oder wenn der Datensatz für ihn nicht oder nicht im richtigen Format verfügbar ist. In solchen Fällen sind Anwender versucht, sich auf inoffiziellen Wegen Kopien von Daten zu besorgen, beispielsweise von einem Kollegen, der selbst die Daten finden, benutzen und aufbereiten kann. Solche Kopien sind außerhalb der Kontrolle der Data-Governance und auch ihre Bedeutung und Aktualität wird schnell unklar.

Eine Data-Platform kann also leicht zu einem Kontrollverlust führen, wenn sie zu rigide ist für die Dynamik der Anwendungsfälle für analytische Daten im Unternehmen.

Klassische Ansätze für das Management Analytischer Daten

Data-Warehouses und Data-Lakes sind zwei klassische und weit verbreitete Ansätze, analytische Daten zu speichern und für die Analyse zugänglich zu machen. Ihr Vergleich ist interessant, weil die Ansätze durch sehr verschiedene Anwendungsfälle für analytische Daten geprägt sind. Zudem reflektiert der Data-Lake Ansatz die wachsende Komplexität und Dynamik der IT-Landschaften von Unternehmen seit der Einführung von Data-Warehouses.

Data-Warehouse

Data-Warehouses wurden in den 1980er Jahren eingeführt. Analytische Daten werden in ihnen auf eine hochgradig strukturierte und integrierte Weise gesammelt. Üblicherweise gibt es ein zentrales Data-Warehouse-Team. Dieses Data-Warehouse-Team ist der Eigentümer eines strukturierten, aufbereiteten und verknüpften Modells aller Datenquellen über alle Domains hinweg und ist auch verantwortlich für Data-Governance und ETL-Pipelines (Extract, Transform, Load), die analytische Daten aus den Systemen der Domains extrahieren. Data-Warehouses sind üblicherweise relational und werden mit Hilfe von SQL ausgewertet.

Data-Warehouses sind besonders gut für Anwendungen im Bereich der Business-Intelligence geeignet. Ein weiterer Vorteil ist die einfache Durchsetzung von Data-Governance.

Auf der anderen Seite fehlt Data-Warehouses die Agilität, die für eine domain-orientierte und dynamische IT-Landschaft nötig ist. Datenquellen in verschiedenen Domains können sich schnell verändern, wodurch zentralisierte ETL-Pipelines unzuverlässig werden. In Bezug auf Bedeutung und Qualität von analytischen Daten kann das Data-Warehouse-Team leicht zu einem Flaschenhals zwischen Domains und Business-Analytikern werden.

Ein Data-Warehouse kann sich auch als zu beschränkt für komplexere Anwendungen von Data-Analytics herausstellen. Ein Beispiel dafür ist KI – solche Anwendungsfälle profitieren oft von Daten, die nicht bereits anhand von eventuell vorschnellen Annahmen über zukünftige Nutzungsmuster vorstrukturiert und vorgefiltert sind. Ein Data-Warehouse hat auch nur begrenzte Unterstützung für sehr zeitkritische Anwendungsfälle, für die Event-Streams potenziell besser geeignet sind.

Data-Lake

Data-Lakes entstanden etwa 30 Jahre nach den ersten Data-Warehouses und sind ihnen konzeptuell gegenübergestellt. Ein Data-Lake ist ein hochgradig skalierbarer zentralisierter Speicher für unstrukturierte, semi-strukturierte und strukturierte Daten. Im Gegensatz zu einem Data-Warehouse sind analytische Daten aus verschiedenen Domains nicht notwendigerweise in ein kohärentes Modell integriert, sondern stattdessen in Rohform gespeichert. Sie werden jedoch potenziell später für konkrete Anwendungsfälle oder Klassen von Anwendungsfällen in ein geeignetes integriertes Modell transformiert. Im Vergleich zu Data-Warehouses sprechen wir in Data-Lakes also nicht über ETL-Pipelines, sondern über ELT-Pipelines (Extract, Transform, Load).

Zu den Vorteilen von Data-Lakes über Data-Warehouses gehört ihre größere Skalierbarkeit und Flexibilität. Neue Quellen analytischer Daten können leicht hinzugefügt werden, da erst einmal keine Integration in ein kohärentes Modell nötig ist. Neue Anwendungsfälle für analytische Daten erfordern dadurch auch keine Änderungen an einem bereits bestehenden integrierten Modell sondern können nötigenfalls auf analytische Daten in ihrer Rohform zurückgreifen.

Aus technischer Perspektive ist eine Trennung zwischen Speicherung und Verarbeitung typisch für einen Data-Lake. Auf diese Weise sind neue Anwendungsfälle für analytische Daten nicht gezwungen die gleiche Anfragesprache wie bereits bestehende Anwendungsfälle zu nutzen, wie dies in einem Data-Warehouse der Fall wäre. Stattdessen können für verschiedene Anwendungsfälle unterschiedliche Technologien zur Verarbeitung der analytischen Daten genutzt werden, die die zu verarbeitenden Daten alle aus dem Data-Lake beziehen.

Ein Nachteil eines Data-Lake ist jedoch, dass Bedeutung und Qualität analytischer Daten leicht verloren gehen – sogar bereits bevor diese im Rahmen eines konkreten Anwendungsfalls transformiert oder verarbeitet werden. Zudem führt die nötige Vorverarbeitung für jeden Anwendungsfall potenziell zu einem hohen und redundanten Mehraufwand. Dies wird dadurch verschärft, dass analytische Daten, die über eine lange Zeit gesammelt werden, unvermeidlich Veränderungen in ihrer Struktur, Bedeutung, Aktualität oder statistischen Verteilung durchlaufen. Die Verarbeitung von analytischen Daten in einem Data-Lake wird auch dadurch erschwert, dass ein Data-Lake oft keine Transaktionen unterstützt oder ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) garantiert. Im Gegensatz zu einem Data-Warehouse, bei dem ein zentrales Data-Warehouse-Team Überblick über die im Data-Warehouse integrierten Daten hat, erfordert ein Data-Lake wesentlich mehr Aufwand, um einen Überblick über die vorhandenen Daten zu behalten und Data-Governance auszuüben.

Es gibt ein substanzielles Risiko, dass ein Data-Lake in einen so genannten Data-Swamp von schwer zu nutzenden und sich eventuell sogar widersprechenden Daten mit unklarer Bedeutung und Datenqualität degeneriert.

Neue Ansätze

In den letzten 15 Jahren sind neue Ansätze für das Management analytischer Daten entstanden. Diese versuchen, die Vorteile von Data-Warehouses und Data-Lakes zu kombinieren und eine wachsende Vielfalt an Anwendungsfällen und Technologien für analytische Daten in hochgradig agilen, dezentralisierten und domain-orientierten IT-Landschaften mit wachsenden Ansprüchen an Data-Governance zu unterstützen.

Technologie: Data-Lakehouse

Ein Data-Lakehouse setzt auf einem Data-Lake auf und erlaubt einen strukturierten Zugriff auf seine Daten unter Berücksichtigung von Data-Governance. Es kann sogar vereinheitlichte Anfragen über den Data-Lake und verschiedene genutzte Datenformate hinweg mit einer einzigen Anfragesprache wie SQL ermöglichen. Ein Data-Lakehouse wird als eine zusätzliche Ebene von Metadaten über dem Data-Lake realisiert, die Metadaten über analytische Daten bereitstellt, eine strukturierte Sicht auf unstrukturierte und semi-strukturierte Daten bietet und sogar ACID-Eigenschaften unterstützen kann.

Data-Lakehouses kombinieren die Vorteile von Data-Warehouses und Data-Lakes: Daten können in strukturierter und integrierter Form genutzt werden. Gleichzeitig bleiben Skalierbarkeit, Flexibilität und Offenheit eines Data-Lake erhalten. Eine zusätzliche Ebene von Metadaten über analytischen Daten ermöglicht eine vereinheitlichte Data-Governance.

Allerdings basiert ein Data-Lakehouse weiterhin auf einem einzelnen zentralisierten Speicher für analytische Daten und hat dadurch Schwierigkeiten, heterogene Technologien und sogar Legacy-Komponenten zu integrieren. Ein Data-Lakehouse gibt außerdem keine Orientierung in Bezug auf den Umgang mit dem unvermeidlichen und autonomen Wandel in dezentralen Domains, ihrer Geschäftslogik, analytischen Daten und Anwendungsfällen für analytische Daten.

Data-Fabric und Data-Mesh versuchen diese Fragen mit einer neuen Architektur und einer neuen Kultur für das Management analytischer Daten zu beantworten.

Architektur: Data-Fabric

Data-Fabric ist eine Architektur, die eine dezentrale und nur lose gekoppelte Data-Platform vorschlägt. Daten werden in einem Netz aus verteilten Services geteilt und konsumiert, welches sowohl Quellen von Rohdaten in operativen Systemen als auch Services für spezialisierte und kuratierte analytische Daten für spezifische Anwendungsfälle einschließt. Im Gegensatz zu einem einzelnen Data-Warehouse oder Data-Lake, können Services in einem Data-Fabric ganz unterschiedliche Technologien verwenden und sogar über eine hybride Multi-Cloud-Umgebung verteilt sein, wodurch auch die Integration von Legacy-Komponenten erleichtert wird.

Ein wichtiger Aspekt eines Data-Fabric ist eine Metadaten-Ebene die es ermöglicht, Services zu finden und miteinander zu verbinden, sowie Data-Governance über alle Services hinweg anzuwenden.

Ein Risiko eines Data-Fabric ist, dass es für Eigentümerschaft und Abhängigkeiten zwischen den verteilten Services im Data-Fabric keine klaren Regeln gibt und deshalb Wissen über analytische Daten und Zuverlässigkeit leicht verloren gehen.

Kultur: Data-Mesh

Der Data-Mesh-Ansatz wurde 2019 von Zhamak Dehghani eingeführt. Er setzt voraus, dass die Geschäfte eines Unternehmens bereits in Domains organisiert sind, die jeweils von funktionsübergreifenden Software-Entwicklungsteams unterstützt werden. Der Data-Mesh-Ansatz schlägt ein dezentralisiertes und verteiltes Netz aus analytischen Daten vor, die klar einzelnen Domains zugeordnet sind und in so genannten Data-Products geteilt werden.

Offensichtlich hat der Data-Mesh-Ansatz Überschneidungen mit Data-Fabric. Im Kontext des Data-Mesh-Ansatzes verschiebt sich jedoch der Fokus von Architektur auf eine Kultur im Umgang mit Daten, die durch die Ideen von Domain-Driven-Design und Product-Thinking geprägt.

Die Grundideen des Data-Mesh-Ansatz können in den folgenden vier Prinzipien zusammengefasst werden:

1. Domain-Ownership: Die Eigentümerschaft und Verwaltung von analytischen Daten liegt bei den gleichen funktionsübergreifenden Software-Entwicklungsteams, die auch die operativen Systeme und ihre operativen Daten entwickeln und warten. Beispielsweise kann der Eigentümer von analytischen Daten der Experte für die operativen Systeme sein, aus denen die Rohdaten extrahiert werden. Der Eigentümer kann aber auch durch einen bestimmten Anwendungsfall für die analytischen Daten bestimmt werden, der die Anforderungen an ihre Struktur, Bedeutung und Qualität festlegt.
2. Data-As-A-Product: Services für analytische Daten werden unter Berücksichtigung einer dauerhaften Nutzung durch eine Vielzahl lose gekoppelter Konsumenten mit verschiedenen Anwendungsfällen entwickelt und gewartet. Aus diesem Grund sind Data-Products dokumentiert und versioniert und garantieren bestimmte SLAs in Bezug auf ihre Verfügbarkeit und Datenqualität. Ihre APIs sind so gestaltet, dass sie von verschiedenen gegenwärtigen und zukünftigen Konsumenten wiederverwendet werden können.
3. Federated-Computational-Governance: Eine vereinheitlichte Data-Governance wird automatisch auf dezentrale Data-Products in den einzelnen Domains angewendet. Sie muss eine Balance zwischen domainübergreifenden Anforderungen, wie beispielsweise den Richtlinien der DSGVO, und der Autonomie und dem Expertenwissen in den einzelnen Domains finden.
4. Self-Serve-Data-Platform: Eine Self-Serve-Data-Platform stellt nicht nur Endanwendern analytische Daten zur Verfügung, sondern ermöglicht auch die standardisierte und interoperable Entwicklung von Data-Products durch die Software-Entwickler in den Domains.
   Ein Risiko des Data-Mesh-Ansatzes sind die notwendigen organisatorischen Veränderungen in Bezug auf Eigentümerschaft und Verantwortung für analytische Daten: Es ist manchmal schwierig, die Grenzen zwischen Domains zu bestimmen und dementsprechend Eigentümer für analytische Daten zu bestimmen. Zudem haben Veränderungen in der Eigentümerschaft an analytischen Daten auch Konsequenzen für die Ressourcenplanung der Domains, Priorisierung von Projekten und die Weiterbildung von Software-Entwicklern.

Zusammenfassung

Das Design einer Data-Platform hängt von vielen Faktoren ab und geschieht selten im luftleeren Raum. Es hängt ab von

bereits im Unternehmen verwendeten Lösungen für die Implementation operativer Systeme und die Verarbeitung analytischer Daten,
gegenwärtigen und zukünftigen Anwendungsfällen für analytische Daten,
der Struktur des Unternehmens und seiner Geschäftsprozesse.
Data-Lakehouses können Data-Governance und Nutzbarkeit eines bereits bestehenden Data-Lakes verbessern. Ein Data-Fabric kann die Grundlage für die Integration heterogener Komponenten bieten – von operativen Systemen zu bereits genutzten Technologien für analytische Daten in Multi-Cloud-Umgebungen. Der kulturelle Wandel, der durch einen Data-Mesh-Ansatz ausgelöst werden kann, ist besonders vorteilhaft für Unternehmen, die Domain-Driven-Design bereits anwenden oder künftig anwenden wollen, um komplexe und veränderliche Geschäftsprozesse zu modellieren.

Natürlich schließen sich Data-Lakehouse, Data-Fabric und Data-Mesh nicht gegenseitig aus. Eine konkrete Datenplattform kann Ideen aus allen drei Ansätzen nutzen. Beispielsweise untersucht dieser Artikel das Design einer neuen Datenplattform für Engelbert Strauss, welche die Architektur eines Data-Fabric mit dem kulturellen Framework eines Data-Mesh kombiniert.

Nehmen Sie Kontakt mit uns auf, wenn Sie nach einer Data-Platform suchen, die auf Ihr Unternehmen zugeschnitten ist. Wir werden Ihre Nutzung analytischer Daten gemeinsam untersuchen und eine maßgeschneiderte Lösung finden, von den eingesetzten Technologien über die Architektur bis hin zu Data-Governance und Data-Culture!

Autor © 2025: Dr. Lucas Heimberg – www.linkedin.com/in/dr-lucas-heimberg-69613638/