Was bedeutet es eigentlich, wenn Unternehmen "data-driven" werden wollen? Sind nicht seit vielen Jahrzehnten Business Intelligence, Analytics und Reporting aus praktisch keinem Unternehmen mehr wegzudenken? Sind wir also nicht alle längst "data-driven"? Die Wahrheit ist, wir sind noch sehr weit davon entfernt. Die meisten etablierten Verfahren sind reaktiv, schauen also nach Gründen und Ursachen, warum etwas passiert ist. Daten sind in diesem Umfeld eher ein hilfreiches Nebenprodukt. 
Unternehmen, die "Data-driven" sind, stellen dagegen Daten in den Mittelpunkt ihrer Entscheidungen. Analysen sind in der Konsequenz überwiegend in die Zukunft gerichtet und beschäftigen sich mit der Frage, "was wäre wenn...". Künstliche Intelligenz und maschinelles Lernen sind allgegenwärtige Werkzeuge. Jeder Einzelne im Unternehmen hat so die Möglichkeit, Prozesse zu verbessern und an Innovationen mitzuwirken. 

Ein Data Mesh verspricht Unternehmen nicht weniger als das, was das Data Warehouse und der Data Lake nie erreicht haben: Endlich "data-driven" zu werden. 

Data Mesh

Data Mesh ist keine Daten-Architektur, kein Betriebsmodell und auch kein Datenmanagementkonzept. Das Data Mesh ist ein soziotechnisches System. In ihm bilden das technische und soziale System eine Einheit. Menschen interagieren im Data Mesh mit Maschinen, Daten und Algorithmen. Alle Komponenten optimieren sich so wechselseitig. Der Erfolg von Unternehmen hängt heute ganz wesentlich davon ab, wie sie als soziotechnisches System funktionieren.
Das Data Mesh wurde entwickelt, um die Verwaltung, Bereitstellung und den Zugriff auf Daten für analytische Anwendungsfälle in und über große Organisationen hinweg zu ermöglichen. Die logische Architektur und das Betriebsmodell des Data Mesh haben zum Ziel, die Wertschöpfung aus Daten in großem Umfang skalierbar zu machen, Agilität auch bei weiterem Unternehmenswachstum sicherzustellen und mit Veränderungen in einem komplexen und sich ständig wandelnden Geschäftsumfeld erfolgreich umzugehen. Die Grundlage eines Data Mesh bilden die folgenden vier Prinzipien.

Dezentrale Domain - Ownership

Die dezentrale Bündelung von Verantwortung an einer Domäne führt zu einer wesentlich höheren Effizienz, da Probleme dort gelöst werden, wo sie entstehen. Bei einer wachsenden Anzahl und Vielfalt von Datenquellen und Anwendungen bleibt das Gesamtsystem so wesentlich besser skalierbar.

Daten als Produkt

Werden Daten selbst zum Produkt, entsteht aus dem Daten - Produzenten - Konsumenten Verhältnis eine Anbieter - Kunden Beziehung mit allen Konsequenzen wie Entscheidungsautonomie und Incentivierung. Datenprodukte sind typischerweise keine fertigen Anwendungen, sondern wiederverwertbare Bausteine.

Self-Service Daten Infrastruktur

Die Infrastruktur-Plattform muss Self-Service-Tools bereitstellen, die es Domänen-Teams ermöglichen, auch ohne spezielle Data-Engineering-Fähigkeiten eigenständig Datenprodukte zu entwickeln und zu pflegen. Dem gegenüber stehen zentrale Werkzeuge, wie bspw. ein Datenkatalog.

 

Föderale Data Governance

Im Idealfall sollte die globale Governance nur entscheiden, was zu regeln ist. Die dezentralen Datenproduktteams entscheiden lokal, wie etwas erledigt wird. Die Self-Service-Dateninfrastrukturplattform stellt die Werkzeuge bereit, um sicherzustellen, dass dies auf zuverlässige, überprüfbare und automatisierte Weise geschieht.

 

Der Datalake ist die richtige Antwort - auf ein anderes Problem

Der Wunsch nach einer einheitlichen Sicht auf alle Unternehmensdaten, nach einer einzigen großen Wahrheit, der "Single source of truth" bestimmte lange die Initiativen im Bereich Data Analytics. In zentralisierten Datawarehouse Systemen entstanden so Use Case um Use Case immer komplexere monolithische Systeme. Datenspezialisten in separierten IT- oder Datenteams kümmerten sich um die Realisierung. Durch die wachsende Zahl der Datenproduzenten und -konsumenten stieg im Laufe der Zeit ganz zwangsläufig die Komplexität und damit Aufwände und Kosten dieser Systeme.  In der Folge standen diese Teams unter enormem Druck, waren sie doch immer mehr damit beschäftigt, entweder das Chaos in der Datenpipeline zu beheben, das durch jede noch so kleine Änderung in den vorgelagerten Anwendungen und ihren Datenbanken verursacht wurde, oder die Bedürfnisse der ungeduldigen Fachbereiche zu befriedigen, die eine Datenlösung meist schneller benötigen als diese sie liefern konnten. 

Viele Unternehmen sehen im Data Lake noch immer den skalierbaren Ausweg aus diesem Dilemma. Doch letztlich bringt ein technischer Umstieg von Business Warehouse auf Data Lake keinen nachhaltigen Erfolg. Gartner hatte schon 2014 vorausgesagt, dass 90% der installierten Data Lakes nutzlos sein werden - und sie behielten recht.

Das ganze Gerede von Daten als dem neuen Öl hat dazu geführt, dass noch immer viel zu viel Aufwand für die Anhäufung und Bereinigung von Daten im Vorfeld von Use Case oder Entscheidungsmodellierung betrieben wird. Nicht wenige Organisationen haben jahrelang versucht, in ihrem Datawarehouse eine vollständige und einheitliche Sicht ihrer operativen Daten als „single source of truth“ abzubilden. Es wurde immenser Aufwand betrieben, die Schlüssel zu finden, um hunderte Tabellen sinnvoll und mit den richtigen Zeitbezügen zusammenzuführen.

Was, wenn für eine Analyse der relevanten Entscheidungswege eine Verknüpfung von nur zwei Tabellen für einen Großteil der benötigten Einsichten ausreichen würde? In vielen besonders volatilen Umgebungen gibt es vielleicht noch gar keine Daten für die aufgetretene Situation, einfach, weil sie brandneu ist.  Hier müssen wir in jedem Fall Annahmen über die Zukunft treffen und mögliche Konsequenzen abschätzen.

Niemandem wäre eingefallen, zuerst so viel Öl wie möglich zu pumpen und danach zu überlegen, wofür es eigentlich zu gebrauchen ist. Es reicht aus, um im Bild zu bleiben, wenn ich weiß, wo das Öl zu finden ist, wenn ich es denn wirklich brauche.


Five1 Datendemokratie

Das Ziel ist Datendemokratie!

Was viele übersehen ist, dass nicht in erster Linie ein technisches Problem gelöst werden muss, sondern ein organisatorisches. Obwohl wir in anderen Bereichen längst gelernt haben, dass komplexe Systeme nur dezentral skalieren können, halten viele Unternehmen und IT-Verantwortliche an zentralen Datenmanagement-Konzepten fest. 

Damit diese Vision Realität werden kann, müssen die Voraussetzungen geschaffen werden. Ein wesentliches Mittel ist sicher die technische Grundlage. Das Ziel ist aber keine Plattform, sondern Datendemokratie. Denn nur wenn die Anwender die Daten finden und verwenden, können sie Nutzen schaffen. Nur durch dezentrale Autarkie schaffen wir die Agilität und Geschwindigkeit für die Herausforderungen, vor denen wir heute und in Zukunft stehen.

In einer Datendemokratie erhält also jeder grundsätzlich freien Zugang zu Informationen, solange dies keinem anderen schadet. Die heute gängige Praxis der Unternehmen dreht sich damit um. Dennoch gelten auch hier bestimmte (Data Governance-) Regeln zur Zusammenarbeit. Analog zu unserem föderalen politischen System in Deutschland sind wir also grundsätzlich frei in unseren Möglichkeiten und Handlungen, aber nicht jeder darf deshalb einfach alles. Es herrscht keine Datenanarchie! 


Domänen-zentriertes Vorgehen

Datendemokratie erreicht man nicht, in dem man "an der Kultur arbeitet", oder ein Change Management Projekt ausruft. Datendemokratie erreicht man aber ebenso wenig, indem man eine neue Software einführt, oder ein Cloud-Projekt initiiert. Die Transformation gelingt nur, wenn man ganzheitlich vorgeht. Der holistische, soziotechnische Ansatz des Data Mesh passt perfekt zu dieser Zielsetzung! 

Das wichtigste Ziel des Data Mesh ist, funktionsübergreifenden Teams die Bereitstellung und Nutzung von Datenprodukten zu ermöglichen. Der beste Weg, um mit der Entwicklung der Plattform zu beginnen, besteht daher darin, die wichtigsten Prozesse Ihrer Plattformnutzer zu verstehen und zu untersuchen, wie Sie es ihnen leicht machen können, ihre Arbeitsabläufe mit Hilfe der Plattform zu optimieren. Domain-driven Design (DDD) ist ein bewährter und sehr erfolgreicher Ansatz, Komplexität von Software zu beherrschen. Im Zusammenspiel mit anderen Hilfsmitteln aus der agilen Softwareentwicklung wie Data Thinking, Scrum, Lean Launchpad, das JTBD Framework u. a. verfügen wir heute über einen mächtigen Werkzeugkasten zur Entwicklung von Datenplattformen, die vor allem auf die Bedarfe des Business einzahlen. 

Five1 Data Mesh Architectur-Grafik

Sie wollen mehr über skalierbare Datenplattformen, das Data Mesh oder Domänen-getriebenes Design erfahren? Sie haben Lust sich einfach einmal unverbindlich auszutauschen? Kontaktieren Sie uns, wir sind gespannt darauf Ihre Sicht kennen zu lernen.

Was können wir für Sie tun?


Five1 Blog - Unsere Artikel zum Thema Data Mesh