Implementierung eines Data-Mesh für Engelbert Strauss

Einleitung

Die geschäftlichen Prozesse einer Organisation hinterlassen nicht nur eine lange Spur analytischer Daten. Die entstehenden analytischen Daten tragen auch selbst zur Wertschöpfung bei, indem sie Entscheidungen unterstützen und Prozesse optimieren. Für viele Organisationen ist die Verfügbarkeit und Nutzbarkeit von analytischen Daten geschäftsentscheidend.

Von besonderer Bedeutung ist deshalb die Wahl einer Datenplattform, die zur Organisation passt – sowohl in Bezug auf die Organisationsstruktur als auch in Bezug auf die benutzten Technologien und Workflows und die Anwendungsfälle für analytische Daten.

Engelbert Strauss ist ein führender deutscher Markenhersteller für Arbeits- und Schutzbekleidung, der seine Produkte über einen Web-Shop, aber auch über einen Katalog und eigene Geschäfte vertreibt. In den letzten Jahren hat die Entwicklung der operativen Systeme von Engelbert Strauss eine Restrukturierung in dezentralisierte und funktionsübergreifende Entwicklungsteams in den einzelnen Fachbereichen durchlaufen, wodurch die Agilität und Qualität der Software-Entwicklung verbessert wurden.

Dies war der Anlass, auch die Datenplattform von Engelbert Strauss zu überdenken, da der vorhergehende zentralisierte Ansatz nicht mehr zu einer dezentralisierten Verantwortlichkeit für die operativen Systeme passte und Schwierigkeiten hatte, mit neuen Quellen und Anwendungsfällen für analytische Daten in den Fachbereichen zu skalieren. Die Data-Mesh-Architektur wendet Domain-driven Design auf analytische Daten an und stellte sich als ein attraktiver Ansatz für eine neue Datenplattform heraus.

Monolithische Plattformen für analytische Daten

In den letzten Jahrzehnten wurden verschiedene Architekturen für die Bereitstellung und Nutzung analytischer Daten vorgeschlagen.

Data-Warehouses stellen analytische Daten auf eine hoch strukturierte und integrierte Weise zur Verfügung. Sie sind für typische Business-Intelligence-Anfragen sehr gut geeignet, jedoch unflexibel: neue Quellen analytischer Daten müssen aufwendig in das Data-Warehouse integriert werden. Diese Einschränkung trifft insbesondere unstrukturierte Daten, die für Anwendungsfälle wie maschinelles Lernen in ihrer Originalform vorgehalten werden müssen.

Im Fall von Engelbert Strauss wurden analytische Daten lange hauptsächlich für die Erstellung relativ statischer Berichte genutzt. Für diesen Zweck wurden einige wenige monolithische Data-Warehouses verwendet, die von zentralisierten Data-Warehouse-Teams verwaltet wurden.

Data-Lakes sind Data-Warehouses konzeptuell entgegengesetzt. Analytische Daten werden in unaufbereiteter und oft unstrukturierter Form gespeichert. Dies vereinfacht die Integration neuer Quellen analytischer Daten, und Anwendungsfälle für analytische Daten sind nicht durch die rigide Struktur eines Data-Warehouses limitiert. Auf der anderen Seite ist der Mangel an Struktur auch ein Nachteil eines Data-Lake. Das Verständnis für die gespeicherten Rohdaten geht leicht verloren, was die Nutzung der Daten behindert und auch Data-Governance zu einer Herausforderung macht.

Data-Lakehouses versuchen die Vorteile beider Ansätze zu verbinden, indem sie einen Data-Lake durch eine integrierte und strukturierte Sicht auf die analytischen Daten ergänzen, die die Nutzung der analytischen Daten sowie Data-Governance erleichtert.
In den letzten Jahren haben multimodale analytische Daten an Bedeutung gewonnen, um Anwendungsfälle wie zum Beispiel Event-Streaming zu unterstützen. Zudem sind Datenplattformen oft in einer Multi-cloud-Umgebung durch eine Kombination von On-premise-Komponenten und Komponenten in der Public-Cloud realisiert.

Eine Herausforderung für alle drei Architekturen ist die Integration analytischer Daten aus unterschiedlichen Quellen (zum Beispiel operativen Systemen), insbesondere wenn die Bedeutung, Qualität und Evolution verschiedener analytischen Daten dezentral in verschiedenen Bereichen der Organisation bestimmt werden.

In einem Data-Lake liegt die Verantwortung dafür, die Bedeutung und Qualität der Rohdaten für den jeweiligen Anwendungsfall im Blick zu behalten, auf der Seite jedes einzelnen Konsumenten. Konsumenten benötigen genaue Kenntnisse über die Prozesse, die den Rohdaten ihre Struktur und Bedeutung geben und auch die Qualität der Daten bestimmen. Sie müssen Zeit investieren, um die Rohdaten in eine für ihren Anwendungsfall geeignete Form zu bringen. Die Kommunikation mit den Urhebern der Rohdaten kann sich als ein Flaschenhals herausstellen.

Data-Warehouses und Data-Lakehouses haben zentrale Teams, die alle Quellen analytischer Daten verfolgen, um die durch das Data-Warehouse oder Data-Lakehouse bereitgestellte Integration zu gewährleisten, aber auch um Data-Governance und die korrekte Nutzung der analytischen Daten durch Konsumenten abzusichern. Diese zentralen Teams können ebenfalls ein Flaschenhals werden, wenn die Anzahl der Quellen und Anwendungsfälle für analytische Daten zunimmt.

Das zugrundeliegende Problem ist, dass der Eigentümer analytischer Daten nicht der Bereich der Organisation ist aus dem die analytischen Daten stammen und der somit ihre Bedeutung und Qualität bestimmt, sondern ein Team von Spezialisten für eine Datenplattform-Technologie. Dieser Konflikt vertieft sich nur angesichts multimodaler analytischer Daten und Multi-cloud-Datenplattformen.

Für die zentralen Data-Warehouse-Teams von Engelbert Strauss wurde es schwer, die ETL-Pipelines zu warten, die analytische Daten aus den operativen Systeme der verschiedenen Fachbereiche extrahieren. Genauso nahm der Aufwand zu, analytische Daten auf eine Weise zur Verfügung zu stellen, die die Kluft zwischen den Details operativer Systeme und den Erwartungen von zum Beispiel Business-Intelligence überbrückt. Bedeutung und Informationen über die Qualität analytischer Daten gingen verloren, der Aufwand zur Integration neuer Datenquellen war hoch und Polyseme in verschiedenen Fachbereichen sorgten in einer Umgebung mit einem wachsenden Interesse an Self-service-Business-Intelligence für Verwirrung.

Zudem wurden analytische Daten neben Business-Intelligence für Anwendungsfälle wichtiger, die eine multimodale Verfügbarkeit erfordern, wie Event-Streaming, Maschinellem Lernen und Künstlicher Intelligenz.

Mit einer zunehmenden Nutzung analytischer Daten sind auch die Anforderungen an Data-Governance im Unternehmen Engelbert Strauss gewachsen. Ein wichtiges Beispiel ist die europäische DSGVO, die die Kontrolle des Individuums über seine persönlich identifizierbaren Informationen durch Methoden wie Pseudonymisierung und das Recht auf Vergessenwerden sicherstellt. Es wurde offenbar, dass Data-Governance die Dezentralisierung der Quellen analytischer Daten in den operativen Systemen der einzelnen Fachbereiche berücksichtigen muss.

Die Data-Mesh-Architektur

Die Data-Mesh-Architektur wurde 2019 von Zhamak Dehghani eingeführt und schlägt eine dezentrale Datenplattform vor, in der die Eigentümerschaft an analytischen Daten nicht nur durch die jeweils verwendeten Technologien und ihre Spezialisten bestimmt wird. Stattdessen verbleiben analytische Daten unter der Eigentümerschaft (Domain-Ownership) eines geeigneten Fachbereichs und werden von den gleichen funktionsübergreifenden Entwicklerteams gepflegt, die auch die operativen Systeme des jeweiligen Fachbereichs betreuen.

Product-Thinking ist ein Wechsel der Perspektive auf analytische Daten von einem Nebenprodukt der operativen Systeme eines Fachbereichs zu Data-as-a-Product, d.h., analytischen Daten als eigenständigem Produkt. Analytische Daten werden von ihrem Fachbereich intentional auf eine Weise geteilt, die ihre Verwendbarkeit durch Konsumenten maximiert. Ähnlich der API eines Microservices sind sogenannte Data-Products dokumentiert, versioniert, garantieren bestimmte SLAs über ihre Verfügbarkeit und Datenqualität, und entwickeln sich über die Zeit basierend auf den Erfordernissen der Konsumenten.

Auf der einen Seite verhindert Data-Governance beispielsweise durch Zugriffskontrolle und die Berücksichtigung regulatorischer Verordnungen den Missbrauch von analytischen Daten. Auf der anderen Seite sichert Data-Governance aber auch, dass das Data-Mesh mehr ist als die Summe seiner Teile, indem sie analytische Daten über die Grenzen einzelner Fachbereiche hinweg auffindbar macht und absichert, dass analytische Daten verständlich und verlässlich sind und multimodal mit anderen analytischen Daten kombiniert werden können.

Federated-computational-Governance berücksichtigt, dass das Wissen über analytische Daten und ihre Anwendungsfälle dezentral über verschiedene Fachbereiche verteilt ist. Um die Agilität und Skalierbarkeit der Datenplattform sicherzustellen, ist eine Balance zwischen der Notwendigkeit globaler Absprachen und der Autonomie der Fachbereiche nötig. Dies erfordert Automatisierung, das heißt, Richtlinien der Governance müssen automatisiert angewendet und überwacht werden können.

Das Data-Mesh ist als eine Self-serve-Data-Platform implementiert, die APIs zur Verfügung stellt, um einerseits die Komplexität der zugrundeliegenden Technologien zu reduzieren und andererseits die Integration zwischen Data-Products und die Ausübung von Data-Governance abzusichern. Die Self-serve-Data-Platform hilft Entwicklern aus den Fachbereichen, die keine Erfahrung mit Data-Engineering haben, analytische Daten zu teilen und zu konsumieren.

Abbildung 1: Die vier miteinander verknüpften Prinzipien der Data-Mesh-Architektur

Es ist klar, dass ein Data-Mesh nicht einfach eine weitere Datenplattform-Technologie ist. Ein Data-Mesh ist vielmehr eine organisatorische Veränderung im Umgang mit analytischen Daten hin zu einer dezentralisierten Eigentümerschaft durch einzelne Fachbereiche. Allerdings muss diese organisatorische Veränderung durch Standards, Platform-Engineering und Abstraktionen über bereits bestehende Technologien unterstützt werden.

Ein Data-Mesh kann nicht durch eine vorgefertigte Komponente implementiert werden. Es erfordert Wissen über die Organisation und ihre Fachbereiche, über die Arbeitsweise und die CI/CD-Pipelines der Entwicklungsteams in den Fachbereichen und auch über die Technologien, mit denen in der Organisation analytische Daten bereits erzeugt oder verarbeitet werden oder die für die Datenplattform in Betracht gezogen werden. Bereits existierende Implementationen der Data-Mesh-Architektur in Unternehmen wie Zalando und Netflix unterscheiden sich stark in der Art und Weise, wie sie die Prinzipien der Data-Mesh-Architektur umsetzen.

Durch die wechselseitige Abhängigkeit von organisatorischen Veränderungen, Anwendungsfällen und der Entwicklung der Datenplattform und ihrer Standards ist die Einführung eines Data-Mesh kein einmaliger Aufwand. Es ist ein kontinuierlicher und agiler Prozess, in dem sich Weiterentwicklungen und Anpassungen in allen Aspekten des Data-Mesh strategisch abwechseln. Aufgrund der Auswirkungen, die der Wechsel in der Eigentümerschaft von analytischen Daten sowie veränderte Rollen und Verantwortlichkeiten auf die Organisation haben, ist eine langfristige Festlegung und Unterstützung durch Entscheidungsträger wichtig. Ängste der von den Veränderungen Betroffenen müssen ernst genommen und beantwortet werden. Dies betrifft beispielsweise eine Angst vor Kontrollverlust bei den Verantwortlichen für die ursprüngliche zentralisierte Datenplattform. Eine Antwort auf diese Angst ist die Feststellung, dass gerade ein Data Mesh bestimmte globale Richtlinien der Data-Governance erfordert, um seine Versprechen einzulösen, und dass eine Self-serve-Data-Platform neue Möglichkeiten zur Automatisierung von Data-Governance bietet. Es betrifft auch Ängste in den Entwicklungsteams der Fachbereiche, von neuen Aufgaben die neue Fertigkeiten erfordern überlastet zu werden. Diese Ängste können dadurch beantwortet werden, dass Data-Products als gleichberechtigt zu anderen Produkten der Software-Entwicklung verstanden werden. Zudem ist es wichtig, dass die APs der Self-serve-Data-Platform so gestaltet werden, dass sie einfach und flexibel von Entwicklern genutzt und in bereits etablierte Workflows integriert werden können.

Das Data-Mesh bei Engelbert Strauss

Die Entwicklungsteams in den Fachbereichen von Engelbert Strauss nutzen Domain-driven-Design, um moderne Microservice-Architekturen zu entwickeln. Teilweise kommunizieren diese Microservices mittels Event-Sourcing über Apache Kafka. Die Entwicklungsteams nutzen in zunehmendem Maße einen GitOps-Ansatz, um ihre operativen Systeme auf eigenen Kubernetes-Clustern bereitzustellen. Die Kubernetes-Cluster der Entwicklungsteams sind Teil der CID-Cloud.

Die Etablierung von Self-service-Business-Intelligence geschieht bei Engelbert Strauss parallel und koordiniert mit der Entwicklung des Data-Mesh. Hierzu werden die OLAP-Datenbanklösung Snowflake in der Public-Cloud und Business-Intelligence-Tools wie Tableau und ThoughtSpot genutzt.

Die Integration der Self-serve-Data-Platform in die Workflows der Entwicklungsteams in den Fachbereichen vereinfacht das Onboarding neuer Entwicklungsteams und die Mitnutzung bereits existierender Lösungen für Monitoring, Logging und Alerting sowie eine Synchronisation des Lebenszyklus von Data-Products und operativen Systemen. Das Data-Mesh unterstützt erste Anwendungsfälle auf der Basis von Apache Kafka und Snowflake, um die Vertrautheit von Entwicklern und Anwendern mit diesen Technologien zu nutzen. Es kann allerdings wenn nötig auch um neue Technologien für die Speicherung und Verarbeitung analytischer Daten erweitert werden – unabhängig davon, ob diese in der Private-Cloud oder in der Public-Cloud liegen.

Das Data-Mesh von Engelbert Strauss verfügt über kein einheitliches Access-Layer für Daten. Analytische Daten verlassen eine Technologie wie Snowflake nur wenn nötig, und Entscheidungen der Federated-computational-Governance, z.B. die Vergabe von Zugriffsrechten, werden auf die Mittel der einzelnen Technologien abgebildet. Allerdings kann ein einheitliches Access-Layer, zum Beispiel in Form einer Query-Engine, ergänzt werden, wenn es nötig ist.

Analytische Daten werden mittels sogenannter Data-Products zwischen den Fachbereichen geteilt. Ein Data-Product ist eine API, die darauf spezialisiert ist, analytische Daten auf eine standardisierte, auffindbare, verständliche, rekombinierbare und multimodale Weise in sogenannten Output-Ports zu teilen. Ein Data-Product ist als eine Einheit von analytischen Daten, deskriptiven Metadaten und Transformationen implementiert. Seine einzelnen Komponenten können über die Private-Cloud und die Public-Cloud verteilt sein.

Das Data-Mesh hat drei Ebenen beziehungsweise Planes mit verschiedenen Aufgaben.

Developer-Experience-Plane

Das Developer-Experience-Plane stellt die APIs der Self-serve-Data-Platform für die Entwicklungsteams der Fachbereiche zur Entwicklung, Bereitstellung und Wartung von Data-Products zur Verfügung.

Die wesentliche Idee des Developer-Experience-Plane ist es, auf der Erfahrung der Entwicklungsteams mit Kubernetes aufzubauen. Maßgeschneiderte Kubernetes-Operatoren stellen die APIs der Self-serve-Data-Platform als Erweiterungen der API der Kubernetes-Cluster der Entwicklungsteams bereit. Sie stellen eine deklarative und erweiterbare Schnittstelle zur Self-serve-Data-Platform dar, die mit der eingebauten API des Kubernetes-Clusters und weiteren API-Erweiterungen zusammen genutzt werden kann.

Data-Products werden in einem Git-Repository entwickelt, in einem Helm-Chart und zugehörigen Docker-Images verpackt und schließlich mittels GitOps auf dem Kubernetes-Cluster des Entwicklungsteams bereitgestellt.

Infrastructure-Plane

Gegenwärtig speichern Data-Products ihre analytischen Daten in Apache Kafka und/oder Snowflake. Transformationen werden entweder in Snowflake ausgeführt oder auf den Kubernetes-Clustern der Entwicklungsteams unter der Benutzung einer Vielfalt von Stream-Processing-Frameworks und Workflow-Managern.

Snowflake und Apache Kafka sind zentralisiert, jedoch sorgen die API-Erweiterungen der Kubernetes-Cluster der Entwicklungsteams für eine Isolation zwischen Fachbereichen und einzelnen Data-Products.

Mesh-Supervision-Plane

Das Mesh-Supervision-Plane hat eine zentrale Registry aller Data-Products über alle Fachbereiche, die ein einheitliches Metadaten-Modell für die Beschreibung der Data-Products nutzt. Diese Registry wird von einem durchsuchbaren Data-Catalog genutzt und erlaubt es Data Products, sich untereinander zu verbinden und analytische Daten mit den APIs der zugrundeliegenden Technologien voneinander zu konsumieren.

Entwickler von Data-Products benutzen zusätzliche API-Erweiterungen ihres Kubernetes-Clusters im Developer-Experience-Plane, um ihre Data-Products zusammen mit deskriptiven Metadaten bei ihrer Bereitstellung im Mesh-Supervision-Plane zu registrieren, um deklarative Zugriffskontrolle über ihre Data-Products auszuüben und um Verbindungsinformationen von anderen Data-Products über sogenannte Input Ports zu erhalten.

Abbildung 2: Die drei Planes des Data-Mesh

Zusammenfassung

In diesem Artikel wurde demonstriert, dass ein Verständnis der Anforderungen sowie der organisatorischen und technischen Voraussetzungen von Engelbert Strauss die Implementation einer hochgradig skalierbaren und erweiterbaren Datenplattform ermöglicht hat.

Die Datenplattform folgt den Prinzipien eines Data-Mesh und korrespondiert zu der dezentralen organisatorischen Struktur von Engelbert Strauss. Sie verbessert nicht nur die Qualität von analytischen Daten, sondern reduziert auch zentrale Flaschenhälse für die Integration neuer Quellen und Anwendungsfälle für analytische Daten. Die Datenplattform ist hervorragend in operative Systeme und ihre Entwicklungsteams integriert.

Einer der ersten Anwendungsfälle des Data-Mesh von Engelbert Strauss ist ein Data-Mart, der eine übergreifende Sicht auf Lagerbestände ermöglicht und die Integration einer großen Zahl von Datenquellen aus verschiedenen Fachbereichen erforderte.

Was sind die organisatorischen und technischen Bedingungen Ihrer Organisation und wie könnte eine Datenplattform aussehen, die auf Ihre Anforderungen zugeschnitten ist? Kontaktieren Sie uns für eine Diskussion!

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