Für viele Unternehmensdatenplattformen ist bisher noch ein zentrales Team zuständig, welches Anforderungen der Fachabteilungen entgegennimmt und umsetzt. Dabei bildet das zentrale Team häufig einen Flaschenhals.
Deshalb fällt die Idee von Data-Mesh, die Verantwortung der Datenplattform für die einzelnen Fachdomänen auf mehrere dezentrale fachliche Teams zu verlagern, auf fruchtbaren Boden.
Data Mesh basiert auf 4 Grundprinzipien:
- Domain Ownership
- Data as a Product
- Self Service Data Platform
- Federated Computational Governance
Dabei sind verschiedene Teams für bestimmte Datenbereiche eigenständig zuständig und übernehmen die volle Verantwortung für diese Datenprodukte.
Trotzdem müssen die verschiedenen Datenprodukte wie die Zahnräder eines Uhrwerks zusammenarbeiten. Erst dadurch entstehen im ganzen Unternehmen nutzbare Datenprodukte und nicht ein Datensilo pro Team.
Wie kann eine Automatisierungsplattform hier unterstützen?
Im folgenden Beispiel nutzt das Unternehmen den DataVault-Generator (DVG) von crossnative. Herr Müller vom Team A möchte die Berechnung einer Kennziffer anpassen. Wie geht er vor?
1. Impact-Analyse
Er nutzt das vom DVG automatisch erstellte Data Lineage und ermittelt alle Felder, welche direkt oder indirekt von dieser KPI abhängen. Er sieht, dass darunter auch Felder sind, welche vom Team B verantwortet werden. Deshalb informiert er Herrn Schulze vom Team B und bitte ihn, am nächsten Tag Zeit für die Bewertung der Testergebnisse einzuplanen.
2. Source-Analyse
Für die geänderte Berechnung der KPI benötigt Herr Müller neue Eingangswerte. Er durchsucht den vom DVG erstellten Datenkatalog und findet diese Eingangswerte in einem Datenprodukt des Teams C.
3. Umsetzung der Anforderung
Im DVG sind die Teamzuständigkeiten sehr einfach geregelt. Das Datenmodell inklusive Beladungsregeln sowie die fachlichen Geschäftsregeln zur Berechnung von KPI’s sind in Modelldateien hinterlegt, welche in einer Ordnerstruktur abgespeichert sind. Jedes Team hat „seinen“ Ordner, in dem es eigenständig und voll verantwortlich handeln kann
Herr Müller ändert in „seinem“ Teamordner die Geschäftsregel zur Berechnung der KPI. Da der alte Feldname der KPI jetzt irreführend wäre, ändert er auch den Feldnamen und die Felddokumentation. Die geänderte Geschäftsregel verwendet jetzt auch die zusätzlich benötigten Eingangswerte des Teams C.
4. Entwicklertest
Herr Müller führt einen „kleinen“ Entwicklertest durch. Dabei nutzt es das Multienvironment-Feature des DVG. Die Multienvironment ermöglich Herrn Müller, auf der bereits existierenden Datenplattform seine eigene „private“ Entwicklungsumgebung parallel und unabhängig zu anderen Umgebungen zu installieren und dabei die vorhandenen Liefersystemdaten zu nutzen.
Damit sein Test nicht unnötig viele Daten verarbeitet nutzt er das Teildeployment-Feature des DVG. Dabei legt er einfach fest, welche Zieltabelle(n) er testen möchte. Der DVG erkennt automatisch, welche Datenplattform-Komponenten zur Befüllung benötigt werden und installiert nur diesen Teil der Datenplattform.
Beim Entwicklertest stellt Herr Müller noch einen Fehler fest. Daher korrigiert er die Geschäftsregel und führt den Entwicklertest erneut durch.
5. Integrationstest
Um alle direkten oder indirekten Auswirkungen seiner Änderungen auf sämtliche Datenprodukte zu testen, führt Herr Müller einen vollständigen Integrationstest durch.
Dazu startet er in einer weiteren Umgebung eine komplette Datenplattform-Beladung. Der DVG generiert dazu sämtlichen Code, das Data-Lineage, Steuerungsinformationen und Dokumentationen neu. Dabei wird auch der Code „fremder“ Teams an den geänderten Feldnamen der KPI angepasst. Inhaltliche Änderungen in „fremdem“ Code erfolgen nicht. Manuelle Anpassungen an der Steuerung der Ladeprozesse muss er nicht machen, da der DVG automatisch die zusätzliche Abhängigkeit der KPI-Berechnung von den neuen Quelldaten des Teams C erkennt und berücksichtigt.
6. automatisierter Vergleich der Testergebnisse
Herr Müller startet die im DVG integrierte automatisierte Analyse der Testergebnisse. Diese Analyse vergleicht die „alten“ ohne die Änderung von Herrn Müller erzeugten Daten mit den „neuen“ Daten. Dabei werden alle direkten Änderungen sowie indirekten Folgeänderungen, welche sich durch die neu berechnete KPI ergeben, detailliert aufgelistet (alle Tabellen, Spalten und Zeilen).
Da durch die Namenskonventionen des DVG die Tabellennamen jeweils mit dem Domänenkürzel des zuständigen Teams beginnen, kann er sofort sehen, welche Änderungen er selbst prüfen und welche Änderungen Herr Müller vom Team B beurteilen muss.
7. Produktivsetzung
Nachdem Herr Müller und Herr Schulze alle vom jeweiligen Team verantworteten Änderungen als korrekt erkannt haben stößt Herr Müller die automatische risikolose Produktivnahme an.
Fazit
Herr Müller konnte die gewünschte Änderung der KPI eigenständig vornehmen und damit der Verantwortung des Teams A im Data-Mesh nachkommen.
