Was in der Softwareprojekten bereits seit mehreren Jahren propagiert wird, scheint jetzt mit einiger Verzögerung auch bei Datenprojekten zunehmend relevanter. Der Schwenk von eher monolithischen Strukturen zu lokalen und autonomeren Strukturen.
Ein Beispiel für eine monolithische Struktur ist ein zentrales Datawarehouse (DWH) oder ein Data
Lake. Oft mit technischen Experten gespickt, soll das Datawarehouse die eine Sicht über die
gesamten Datenobjekte des Unternehmens enthalten.
Doch in der Realität ergeben sich diverse Probleme dieses Ziel zufriedenstellend zu erreichen.
Oft sind die DWH-Teams zentral organisiert. Da sie die Daten nicht selbst produzieren, sind sie stark von den Produzenten der Daten abhängig. Davon gibt es in der Regel mehrere, verteilt auf
verschiedene Teams.
Strukturelle oder logische Änderung der Daten können sich dabei voll auf den Konsumenten, hier
also das Datawarehouse durchschlagen.
Ein Beispiel aus einem meiner Projekte:
Das Datawarehouse-Team lud in der Rolle des Konsumenten zu einem Treffen mit einem
Applikationsteam in der Rolle des Produzenten. Ziel war es Löschungen und Änderungen an
Datensätzen im Quellsystem zuverlässig zu identifizieren. Dazu sollte das Applikationsteam dem
Datawarehouse Informationen zu gelöschten oder geänderten Datensätzen liefern. Für das
Applikationsteam hätte dies Zusatzaufwände beschert. Aufgrund fehlender Kapazität und der
Urlaubszeit konnte diese Anforderung nicht schnell genug umgesetzt werden.
Ein Problem für das Datawarehouse-Team! In mehrfacher Hinsicht: Das DWH-Team ist sehr stark von Zulieferungen von Dritten abhängig. Je mehr Zulieferungen benötigt wurden, umso mehr wurde das Team ausgebremst. Was hilft hier? Nun, sicherlich mehr Autonomie.
Die Lösung bei diesem Problem war noch relativ einfach. Das Datawarehouse-Team entschied sich
für ein Software Design Pattern mit dem Namen Slowly Changing Dimension (SDC). Damit konnte
unabhängig von den Quellsystemen logische Änderungen an Daten auf Seiten des DWH identifiziert werden.
Doch damit ist nur ein Problem gelöst. Ein Datawarehouse-Team steht regelmäßig vor der
Herausforderung Daten aus Quellen, die sie nicht selbst verantworten zu verstehen, aufzubereiten,
zu bereinigen und in eine passende Zielstruktur zu bringen. Als „vorgeschalteter Endpunkt“ für den
Datenkonsum konsolidieren sich nicht nur die Daten im Datawarehouse, sondern importieren auch
alle einhergehenden Schwierigkeiten mit der Interpretation, Mehrdeutigkeit, Datenqualität oder
auch der Änderungen in Logik oder Struktur.
Das sorgt innerhalb der Organisation für Frust. Bei den Datawarehouse-Teams, den Applikationsteams und dem Management. Eine klassische Lose-Lose-Situation.
Dieses Muster kennen wir doch. In der Softwareentwicklung etwa gab es in der Vergangenheit immer wieder Reibungspunkte zwischen den Entwicklungsteams und den Betrieb. Die Entwicklung wirft Änderungen über den Zaun und der Betrieb musste damit klarkommen. Die Entwicklung war permanent unter Druck und saß bereits am nächsten dringenden Projekt, während der Betrieb sich
mit der Stabilität der Zulieferungen herumquälte.
Die Lösungen sind bekannt. Zunächst wurde mit DevOps ein neues Mindset in die
Entwicklungsprozesse etabliert („You build it, you run it“). Dies entwickelte sich zu Produktteams
weiter, die für den gesamten Lebenszyklus einer Software von der Konzeption, der Entwicklung, den Betrieb bis zur Abschaltung verantwortlich waren.
Diese organisatorischen Anpassungen in der Verantwortung führten häufig – wenn denn gut
umgesetzt – zu deutlich besseren Ergebnissen, da die Teams über mehr Autonomie verfügten und
Abhängigkeiten reduzieren konnten.
Unter dem Begriff „Data Mesh“ zeichnet sich ein ähnlicher Trend bei Datenvorhaben ab, die in der Vergangenheit auch bei Softwareumsetzung vollzogen wurde: Weg von zentralen „Single Source of Failure“ zu flexiblen domainspezifischen dezentralen Teams, die ihre Datenverantwortung vollumfänglich wahrnehmen können.
Dabei bekommen die zentralen Datenteams eine neue Rolle zugewiesen. Sie sind nunmehr nicht
mehr für die Konsolidierung aller Domain-Daten zuständig, sondern stellen Services zur Verfügung, um diese Datenkonsolidierung in den jeweiligen Domänen zu ermöglichen.
Ziel ist es die Daten dort zu konsolidieren und konsumieren, wo sie auch produziert werden.
Natürlich agieren die Domänen nicht auf einsamen Inseln und es gibt Abhängigkeiten zu anderen
Domänen. Ihre eigenen Business Objekte kennen sie aber in und auswendig und können daher viel
effektiver agieren als zentrale Datenteams.
Ähnlich wie bei Produktteams in der modernen Softwareentwicklung, werden Daten als Produkte
behandelt. Ein zentrales Ziel bei Produkten sind zufriedene Kunden. Bei Datenprodukten sind es die zufriedenen Konsumenten.
Data Mesh ist meines Erachtens der nächste logische Schritt in Datenvorhaben. Dort wo zentrale
Datenteams zu einem Bottleneck werden, kann Data Mesh zu einer Win-Win-Situation führen.
Bei Fragen kontaktieren Sie uns über unsere Webseite qurix Tech oder direkt per E-Mail andree.deboer@qurix.tech.
