Verteilte Datenplattformen – eine Verbindung von Subsystemen

Unternehmen setzen sich, wie alle größeren Systeme, aus miteinander verbundenen Teilsystemen zusammen. In Teams, Projekten oder Abteilungen erfüllen Gruppen von Menschen bestimmte Geschäftsfunktionen und setzen dafür individuelle Anwendungen zur Datenverwaltung ein. In den Anwendungen spiegelt sich nach Conway die Unternehmensstruktur wider. Daten bestehen aus persistierten Ereignissen, die von in bestimmten Geschäftsfunktionen eingesetzten Sensoren, Menschen oder Software erzeugt werden. Die Geschäftsfunktionen bilden ein miteinander verbundenes System (die Organisation), weshalb auch Daten an das Conway’sche Gesetz gebunden sind.

Datenmanagement muss mit bestehenden Strukturen arbeiten

Daten müssen dort verwaltet werden, wo sie erstellt bzw. gehalten werden: in einem bestimmten Teilsystem oder einer Geschäftsfunktion. Und die Teilsysteme müssen ihre Informationen über Schnittstellen zugänglich machen, wenn eine organisationsübergreifende Kommunikation funktionieren soll. In der Organisationsstruktur eines Unternehmens spiegelt sich somit die Art der Produkte/der Dienstleistung eines Unternehmens wider. Jedes neue Datenmanagement- oder Governance-Programm stößt auf diese bestehenden Strukturen.

Sind Menschen, Technologie und Daten falsch organisiert, gibt es Spannungen. Durch Einführung neuer Arbeitsweisen und/oder Datenplattformen lassen sich diese nicht ohne weiteres überwinden. Hier bieten sich drei grundlegende Möglichkeiten an, die Organisation zu gestalten: Systeme können durch Netzwerke dargestellt und eine Organisation als Netzwerk von Abteilungen oder Geschäftsfunktionen betrachtet werden. Netzwerke lassen sich grob in drei Typen einteilen: zentralisiert, dezentralisiert und verteilt.

Relativ simpel ist das zentralisierte Netzwerk, das man in der Regel bei kleinen Unternehmen oder Organisationen mit einem starken Einzelbereich findet. Es kennt nur einen einzigen zentralen Punkt für den Austausch von Informationen zwischen seinen Teilsystemen. Wächst das Unternehmen jedoch, bildet dieses Modell einen Single Point of Failure und es kommt zu Engpässen. Im dezentralisierten Netzwerk stellt jede Abteilung ihr eigenes lokales Zentrum dar, das als Knotenpunkt zu anderen fungiert. Im verteilten Netzwerk dann ist jedes Teilsystem ein kleines, autonomes, funktionsübergreifendes Team. Dieses ist für seine Geschäftsfunktion verantwortlich und ist dabei relativ frei eine Ausgestaltung.

Um nun ein Datenmanagement auf die eigene Organisationsstruktur abzustimmen, muss man zunächst die Kommunikationsstruktur ermitteln. Die verschiedenen Netzwerkstrukturen weisen dabei den richtigen Weg. Sobald die Organisation eine gewisse Größe erreicht, wird ein zentralisiertes Datenmanagement nicht mit der Organisationsstruktur übereinstimmen. Die Folge sind Reibungsverluste.

Dezentralisierte, domänenorientierte Datenverwaltung

In größeren Organisationen mit komplexeren Kommunikationsstrukturen widerspricht ein zentralisierter Ansatz dem Conway’schen Gesetz. Hier ist eine dezentralisierte Datenmanagement-Architektur gefragt. Lernen kann man dabei von benachbarten Technologiebereichen. So verfügt die Softwareentwicklung über jahrelange Erfahrung und umfangreiche Forschungsergebnisse bei der Dezentralisierung. Das Konzept einer dezentralisierten, domänenorientierten Datenverwaltung wird auch als Data Mesh bezeichnet.

Der erste Data-Mesh-Grundsatz basiert auf einer bereichsorientierten, dezentralen Dateneigentümerschaft und -architektur. Im Klartext: Jedes Teilsystem/jede organisatorische Funktion muss Eigentümerin der eigenen Daten sein. Im Mittelpunkt der Idee steht ein Konzept aus dem bereichsorientierten Design, der „begrenzte Kontext“. Eine „Domäne“ entspricht dabei im Wesentlichen einer organisatorischen Funktion, hat ihre eigene, eindeutige Sprache und ist am besten in der Lage, ihre Daten zu verwalten.

Daten als ein Produkt zu betrachten und die Informationen der Domäne in einer für andere nutzbaren Form darzustellen, ist der Wesenskern des zweiten Data-Mesh-Grundsatzes. Der dritte definiert die Dateninfrastruktur als eine Plattform, die verschiedene Funktionen in einer Selbstbedienungsweise anbietet, während sich das vierte Prinzip auf die föderale IT Governance konzentriert. Sie vollzieht den Spagat, gerade genug zentrale Kontrolle zu haben, um die Arbeit zu erleichtern, aber die Entscheidungsfindung so lokal wie möglich zu halten. Governance beruht dabei mehr auf Standards und Arbeitsweisen als auf der Kontrolle des Zugangs und dem „Horten“ aller Daten auf einer Plattform.

Eine bereichsorientierte, verteilte Datenplattform baut damit auf der Idee einer Organisation als Verbindung von Subsystemen auf. Der Ansatz besteht darin, Daten in dem organisatorischen Kontext zu halten, zu dem sie gehören und in dem sie erstellt wurden. Ein Data Mesh basiert auf dem Prinzip ausgewählter, zentraler Infrastrukturkomponenten, die es lokalen Teams ermöglichen, Produkte und Dienstleistungen in ihrem eigenen Bereich zu entwickeln – und für ihre eigenen Daten verantwortlich zu sein.

Non-Invasive Data Governance Framework

Die Herausforderung besteht nun darin, sicherzustellen, dass auch Governance-Modelle funktionieren? Gehen diese nicht immer von einem zentralisierten Netzwerk aus? 2008 stellte Bob Seiner seine Überlegungen zum Non-Invasive Data Governance Framework vor, das sich perfekt in Conway’s Law einfügt. Data Governance solle demnach nicht bedrohlich und aggressiv (= invasiv) sein. Problem: Die meisten Data-Governance-Ansätze werden eben doch als bedrohlich wahrgenommen, weil dabei zusätzliche Schichten auf bestehende Organisationsstrukturen aufgesetzt werden.

So wie es bei Data Mesh um den Aufbau von Verbindungen zwischen verschiedenen Teams und Funktionen geht, erkennt man ein nicht-invasives Data-Governance-Rahmenwerk daran, dass im Unternehmen bereits jemand die meiste Governance-Arbeit geleistet hat. Sie muss lediglich noch formal und für alle transparent sichtbar gemacht werden, Beziehungen/Verbindungen müssen aufgebaut werden. Viele große Unternehmen setzen heute auf Community-basierte Datenkataloge, idealerweise mit Crowdsourcing-Aspekten. In ähnlicher Weise erleichtern API-Verwaltungssuites die Vernetzung innerhalb des Unternehmens, indem sie Datenprodukte anderen Nutzern zugänglich machen.

Der Schlüssel zum Erfolg liegt wie immer nicht allein in technologischen Implementierungen, sondern darin, zunächst das aktuelle System und die Netzwerke zu verstehen. Anschließend muss man Daten, Teams, Arbeitsweisen und Technologien mit zwei Hauptzielen entwerfen und organisieren: 1. Bestehende Bereiche können weiterhin das tun, was sie am besten können, und 2. Zentrale Verbindungselemente und Schnittstellen sind zu entwickeln, die das Auffinden, die gemeinsame Nutzung und den Einsatz unternehmensweiter Datenbestände ermöglichen.

Einzelne sind in der Regel gewillt, zu lernen oder mit anderen zu teilen. Die Reibung im Conway’schen Gesetz ist daher vielmehr organisatorischer Natur. Deshalb müssen Unternehmen in allen Bereichen des Data Mesh Communities aufbauen und Gelegenheiten zum Austausch und Lernen bieten – ohne ihnen dabei Kontrolle, Entscheidungsfindung oder Prioritätensetzung aufzuerlegen. Wer sich bei der Organisation seiner Daten daran orientiert, wie das eigene Unternehmen und die Beschäftigten organisiert sind, hat den Grundstein für ein funktioniertes Datennetz gelegt.