DER NEUE GOLDSTANDARD?
DATA MESH

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 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.

Klingt spannend? Lassen Sie uns sprechen!

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. 

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 Data Warehouse 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.

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.