Data Fabric vs. Data Mesh vs. Data Lake

Die Datenstrategie ist seit langem ein Kernelement der Geschäftsabläufe von Unternehmen, aber sie kann auch heute zur Belastung und sogar zum Hindernis für Unternehmen werden. Von Jahr zu Jahr setzen Unternehmen mehr Technologien ein, und jede dieser Technologien bietet zahlreiche Möglichkeiten, neue Daten zu erfassen und zu nutzen. Die Notwendigkeit einer umfassenden und zukunftsorientierten Datenstrategie liegt auf der Hand. Wenn Sie sich nach Datenstrategien suchen, werden Sie auf eine vielfältige Auswahl stoßen, von Data Warehouse und Data Lake bis zu Data Fabric und Data Mesh. Woher wissen Sie, welche Option für Ihr Unternehmen und Ihre Pläne am besten ist?

In der Vergangenheit kamen Ihnen bei Unternehmensdaten Begriffe wie "agil" und "flexibel" nicht in den Sinn. Die Gefahr einer außer Kontrolle geratenen Datenerfassung ist bei der enormen Auswahl an unterschiedlichen Systemen zur Erfassung riesiger Datenmengen größer denn je, die durch die relative Einfachheit, neue Systeme zu Ihrem Unternehmens-Ökosystem hinzuzufügen, noch verstärkt wird.

Diese Skalierungsprobleme führen zu einer mangelnden Datenkohärenz, worunter Ihre Geschäftsprozesse und Business Intelligence leiden, die auf diesen Daten basieren. Hier können Ihnen Data Fabric and Data Mesh Approaches with AI helfen.

Eine starke Datenstrategie kann für Unternehmen eine entscheidende Rolle spielen. Sie ermöglicht es Ihnen, schwierige Datenlandschaften in modernen und Legacy-Systemen effizient und effektiv zu verwalten.

Ihre Datenstrategie bildet über Jahre hinweg das Fundament für Ihre Analysen und Arbeitsabläufe.

Sehen wir uns die Optionen Data Warehouse, Data Lake, Data Fabric und Data Mesh einmal etwas genauer an, um einige der aktuellen Datenstrategien besser einordnen zu können.

[ Möchten Sie mehr darüber erfahren, wie Sie Ihre Probleme mit Datensilos lösen und Innovationen voranbringen können? Lesen Sie unser e-Book: Der Vorteil einer Data Fabric. ]

Die älteste (und immer noch beliebte) Methode, mit der Unternehmen versuchen, ihre Daten zu konsolidieren, ist das regelmäßige Verschieben von Daten von bestehenden Systemen in ein neues. Dieses neue System kann ein Data Warehouse oder ein Data Lake sein. Was ist der Unterschied zwischen Data Warehouse und Data Lake? Um diesen besser zu verstehen, sollten Sie den Unterschied zwischen ETL (Extrahieren, Transformieren, Laden) und ELT (Extrahieren, Laden, Transformieren) kennen. Jeder dieser Begriffe beschreibt einen Prozess der Datenmigration und der Aufbereitung der Daten für die Verwendung. Hier eine kurze Definition der drei verschiedenen Schritte:

• Extrahieren: Die Daten werden aus ihrem ursprünglichen Quellsystem extrahiert.
• Transformieren: Die Daten werden bereinigt, dedupliziert und für die Analyse aufbereitet.
• Laden: Die Daten werden in das Zielsystem, d. h. entweder das Data Warehouse oder den Data Lake, geladen.

Sowohl bei Data Warehouses als auch bei Data Lakes steht das Extrahieren an erster Stelle, aber danach unterscheidet sich der Ablauf. Ein Data Warehouse nutzt eine definierte Struktur, so dass die verschiedenen Dateneinheiten und -beziehungen direkt im Data Warehouse kodifiziert werden. Aus diesem Grund müssen die aus dem Quellsystem extrahierten Daten transformiert und aufbereitet werden, damit sie in dieses strukturierte Format geladen werden können. Diese Struktur hat den Vorteil, dass die Aktivierung der Daten einfacher vonstattengeht, da die Daten bereits in ein brauchbares Format gebracht wurden.

Im Gegensatz dazu werden beim Data Lake die Rohdaten des Quellsystems direkt in das Zielsystem geladen. Zum Laden der Daten ist es nicht erforderlich, eine Struktur oder Beziehung zwischen den Daten festzulegen. Dies macht Data Lakes naturgemäß flexibler, da sehr viel weniger Vorarbeit nötig ist, um neue Daten in den Lake zu importieren. Das bedeutet jedoch nicht, dass man sich diese Arbeit sparen kann. Es ist nun die Aufgabe von Dateningenieuren, ausgeklügelte Datenpipelines zu erstellen, die die unzusammenhängenden Daten aus dem Data Lake ziehen und sie in ein Format bringen, das vom Unternehmen genutzt werden kann.

Data Warehouses funktionieren gut mit definierten, geordneten Unternehmensdaten. In der Regel sind diese Informationen in Konzepte strukturiert, sodass die Aufgabe darin besteht, aus dem konzeptionellen Modell ein Data Warehouse sowie Prozesse zur Transformation und zum Laden der Quelldaten zu entwickeln.

Data Lakes besitzen Vorteile bei der Aufbewahrung von Daten mit unklarem Geschäftspotenzial oder mit unklaren Beziehungen oder in Fällen, in denen sich nicht alle Daten für die Analyse eignen. Unternehmen entscheiden sich dann häufig dafür, die Daten einfach in einen Data Lake zu verschieben, wo sie für Dateningenieure verfügbar sind, die später eine Pipeline entwickeln, in der die Daten in ein für einen bestimmten Anwendungsfall brauchbares Format gebracht werden.

Beide Lösungen sind mit mehreren Herausforderungen verbunden. Beide führen zu betrieblichen Gemeinkosten aufgrund zusätzlicher Entwicklung, Wartung und Instandhaltung. Daten wurden zwar aus isolierten Systemen herausgeholt, aber dazu mussten Datenstrukturen und Transformationen entwickelt werden, um sie ordentlich aufzubewahren. Oder aber es mussten ausgeklügelte Datenpipelines entwickelt werden, um lose strukturierte Daten in ein brauchbares Format zu bringen.

Ein weiteres Risiko dieser Strategie besteht darin, dass sie auf Informationsquellen beruht, die anhand einer komplexen Transformationslogik von der ursprünglichen Datenquelle abstrahiert werden. Dies kann die Datenintegrität beeinträchtigen.

Und schließlich müssen Sie bei Data Warehouses und Data Lakes aufgrund der Komplexität der Datentransformation und -übertragung in der Regel auf den Zugriff auf Daten in Echtzeit verzichten. Mit dem Wachstum Ihres Unternehmens und Ihrer Systeme, werden auch die Komplexität, die technischen Schulden und das Fehlerrisiko, das diese Datenstrategien mit sich bringen, zunehmend zum Problem.

Warum sollte man nicht einfach eine direkte Verbindung zu den Datenquellen herstellen, anstatt die Daten aus den Quellsystemen zu extrahieren und sie anderswo zu speichern? Nun, das ist leichter gesagt als getan. Ihre ERP- und CRM-Systeme mögen sich zwar konzeptionell stark überschneiden, werden aber oft von unterschiedlichen Technologien gestützt und verfügen über keine native Möglichkeit zur Verbindung ihrer Datenstrukturen.

In der Vergangenheit haben sich Unternehmen auf einen einzigen Technologieanbieter festgelegt, um diese Lücke bei vernetzten Daten zu schließen, was unweigerlich zu gewissen Abstrichen führt. Selbst wenn Sie Systeme desselben Anbieters für die Speicherung Ihrer Daten wählen, sind sie doch nicht mit anderen modernen oder Legacy-Systemen in Ihrem Unternehmen vernetzt.

Hier kommen Strategien wie Data Fabric und Data Mesh ins Spiel und bieten einen Mehrwert. Data Fabric und Data Mesh sind Architekturansätze, die es Ihnen ermöglichen, Daten in Ihren Quellsystemen zu belassen, in Echtzeit darauf zuzugreifen und sie über verschiedene Systeme hinweg zu verbinden. Bei beiden Strategien gibt es Ähnlichkeiten, aber auch wichtige Unterschiede.

Das Konzept des Data Mesh entstand im Zuge der jüngsten Umbrüche in der Softwarearchitektur. In der Branche geht der Trend dahin, monolithische Dienste in unabhängige Microservices zu zerlegen. Microservices können die Entwicklung agiler machen. Der Nachteil dabei ist jedoch, dass Daten und Aktionen über Microservices hinweg orchestriert, verwaltet und vernetzt werden müssen. Durch die Erstellung von API-Integrationen zwischen den verschiedenen Mikroservices können sie vernetzt bleiben und zusammenarbeiten. Wenn man dieses Konzept auf das gesamte Unternehmen überträgt, können ganze Systeme zu einem Enterprise Data Mesh integriert werden.

Das Data Mesh-Konzept hat jedoch zwei Haken. Erstens: Sie ersetzen anspruchsvolle Aufgaben für Dateningenieure durch anspruchsvolle Aufgaben für Software-Entwickler. Zur Implementierung und Nutzung der APIs werden die richtigen Fähigkeiten, das richtige Wissen über die Funktionsweise der Integrationen und die richtigen Tools für die einzelnen Integrationen benötigt. Die Data Mesh-Architektur ist zwar in hohem Maße effektiv, kann jedoch nur von Spezialisten genutzt werden. Mit anderen Worten: Data Mesh ist ein High-Code-Ansatz, der das Entwicklerwissen und -zeit erfordert.

Der zweite Haken am Data Mesh ist die zentralisierte Governance. Bei Data Warehouses und Data Lakes erhalten Sie einen vollständigen Überblick über Ihre replizierte Datenlandschaft in einem einzigen System. Bei einem Data Mesh sind die API-Integrationen auf verschiedene Systeme verteilt, sodass Sie nur die Muster sehen, die bereits mit dem Data Mesh von Menschen erstellt wurden.

Die Data Fabric bietet überzeugende Möglichkeiten, die beiden Herausforderungen zu meistern.

Eine Data Fabric umfasst eine Virtualisierungsschicht, ein Konzept, das auch als "logisches Data Warehouse" bezeichnet wird. Das bedeutet, dass bei einer Data Fabric unterschiedliche Systemdaten auf einer zentralen Plattform virtualisiert werden, die die Möglichkeit bietet, Daten zu verbinden, zu verknüpfen und zu erweitern. Sie können sich die Data Fabric auch als Abstraktionsschicht für die Verwaltung Ihrer Daten vorstellen. Ein wichtiger Punkt bei der Verwendung einer Data Fabric ist der, dass die Daten dort bleiben, wo sie sind; sie werden nicht aus den Quellsystemen entnommen.

Bei einer Data Fabric ist ein direktes Einklinken in API-Aufrufe von System zu Systeme nicht notwendig, um auf Daten zuzugreifen – die APIs sind nämlich abstrahiert. Dank dieser Abstraktion können die Daten in verschiedenen Systemen genutzt werden, ohne das Quellsystem oder die Verbindungen dazu zu kennen. Die Daten können vor Ort oder in einem Cloud-Dienst wie AWS als Teil Ihrer Hybrid-Cloud-Strategie gespeichert werden.

Während für den Umgang mit dem Data Mesh Softwarespezialisten erforderlich sind, können bei einer Data Fabric nicht nur Entwickler, sondern beliebige Mitarbeitende in Ihren Teams an der Datenmodellierung mitwirken. Das bedeutet, dass nicht nur technische Mitarbeitende Low-Code-Tools für die Datenmodellierung verwenden können, was zu einer höheren Geschwindigkeit und mehr Flexibilität führt.

Was ist mit den Herausforderungen bei der Governance? Wie bereits erwähnt, stellt ein Data Mesh wegen des verteilten Charakters eine Herausforderung bezüglich Beobachtbarkeit und Wartung dar. Im Gegensatz dazu ist die Data Fabric zentralisiert. Da bei einer Data Fabric alle Daten in einem einzigen virtualisierten Datenmodell gespeichert werden, erhalten Sie eine vollständige, einheitliche Sicht auf alle Ihre Systeme. Selbst wenn bestimmte Muster zuvor nicht verwendet wurden, lassen sich neue Arten des Datenzugriffs durch die Verknüpfung der Daten im virtualisierten Modell leicht und auf kontrollierbare Weise implementieren.

Hier ein Tipp für Gespräche über die Data Fabric: Der Begriff "Data Fabric" kann sich entweder auf die Architekturschicht beziehen, auf der die Datenvirtualisierung stattfindet, oder auf das Toolset, das Sie dort einsetzen.

Die Verwendung einer Datenvirtualisierungsschicht bietet schon an sich einen hohen Mehrwert. Dieser Wert erhöht sich jedoch beträchtlich, wenn Sie Ihr virtualisiertes Datenmodell mit Ihren Geschäftsanwendungen auf einer Prozessautomatisierungsplattform mit Low-Code-Funktionen und Sicherheit auf Datensatzebene verbinden. Durch die Verwendung von Low-Code-Sicherheitsregeln können Sie etwa Daten in Ihrem CRM referenzieren, um zu erzwingen, dass bestimmte Datenzeilen aus Ihrem ERP zugänglich sein müssen. Sie können zudem benutzerdefinierte Datenfelder wie SLAs berechnen, indem Sie auf Kunden- und Falldaten verweisen, selbst wenn diese nicht im selben System gespeichert sind. Derartige Funktionen ermöglichen es Ihnen, Ihr Geschäftspotenzial zu maximieren, ohne auf Ihre bestehenden Systeme oder Technologien verzichten zu müssen. Dieser Ansatz bietet auch Flexibilität für die Zukunft.

Bei Unternehmenssystemen ist der Wandel nicht nur konstant, sondern er beschleunigt sich noch. Da Unternehmen digitale Transformation auf immer mehr Bereiche ihres Geschäfts anwenden, müssen die von ihnen verwendeten Technologiestrategien flexibler, skalierbarer und wartbarer sein denn je. Agilität und Schnelligkeit sind wettbewerbsentscheidend.

Während Data Warehouses, Data Lakes und Data Meshes in der Vergangenheit gute Dienste geleistet haben, wird die Data Fabric für Unternehmen in der Zukunft wegweisend sein. Durch die Kombination von virtualisierten Daten, Geschäftsanwendungen und No-Code-Datenmodellierung auf einer einzigen Plattform können Unternehmen ihre Technologielandschaft von einer Belastung in ein Unterscheidungsmerkmal verwandeln.

[ Wie passt eine Data Fabric in eine moderne Automatisierungsstrategie? Laden Sie den Gartner®-Bericht zu den Trends in der Hyperautomatisierung 2022 herunter, um mehr zu erfahren. ]