Agile Entwicklung im Data Warehousing: Ausgangslage
Agile Methoden bringen Flexibilität und Anpassungsfähigkeit ins Data Warehousing und passen daher hervorragend zu modernen Ansätzen wie Data Vault 2.0. Ein häufiges Problem bei Data-Warehouse-Projekten ist das Fehlen eines klar definierten Scopes sowie nicht optimierte Prozesse – etwa beim gesteuerten Zugriff, beim Umgang mit der DSGVO (GDPR), bei der Revisionssicherheit (Auditability), der Dokumentation oder der Infrastruktur. Zudem starten Data-Warehouse-Projekte selbst bei vorhandenem Scope oft ohne echten Fokus auf den geschäftlichen Mehrwert (Business Value). Dies liegt meist daran, dass die Anwendungsfälle (Use Cases) nicht klar kommuniziert werden und Datenarchitekten der konkrete Ansatzpunkt fehlt. In der Folge bleibt der erhoffte Mehrwert für das Unternehmen aus.
Data-Vault-2.0-Methodik
Es wird häufig fälschlicherweise angenommen, dass Data Vault 2.0 lediglich eine Modellierungstechnik sei. Data Vault 2.0 umfasst jedoch weit mehr: eine Modellierungstechnik, eine Referenzarchitektur und eine eigene Methodik. Diese Methodik integriert etablierte Projektmanagement-Werkzeuge wie CMMI, Six Sigma und Scrum, um die beschriebenen Herausforderungen zu lösen. Während CMMI und Six Sigma übergeordnete Projektmanagement-Themen abdecken, kommt Scrum vor allem im Entwicklungsteam zum Einsatz und bildet den Rahmen für einen kontinuierlichen Verbesserungsprozess. Der Einsatz agiler Entwicklung in Data-Vault-2.0-Projekten wird im Folgenden näher erläutert.
Der Scope eines Sprints
Der erste Schritt beim agilen Aufsetzen eines Data-Warehouse-Projekts besteht darin, das Projektziel prägnant auf ein bis zwei Seiten zu definieren. Im Gegensatz zu klassischen Wasserfall-Projekten ist es das Ziel, in kontinuierlichen Iterationen (Sprints) funktionierende und nutzbare Teilergebnisse – wie Berichte oder Dashboards – zu erzeugen. Das bedeutet, dass nicht das gesamte Projekt vorab im Detail geplant werden muss. Stattdessen lässt sich das Data Warehouse rund um ein zentrales Zielbild aufbauen, bevor die ersten Sprints konkret geplant werden. Um den genannten Problemen entgegenzuwirken, muss der Schwerpunkt der Sprints konsequent auf dem geschäftlichen Mehrwert liegen. Dafür ist es entscheidend, im Sinne eines kontinuierlichen Verbesserungsprozesses fortlaufend Feedback von den Fachanwendern (Business Usern) einzuholen.
Definition des Projekts
Sowohl der Scope eines Sprints als auch die Architektur folgen einem Business-Value-getriebenen Ansatz, der vertikal statt horizontal aufgebaut ist. Das bedeutet, dass die Entwicklung nicht Schicht für Schicht, sondern Feature für Feature erfolgt. Eine bewährte Vorgehensweise ist hierbei der Tracer-Bullet-Ansatz: Ausgehend vom geschäftlichen Mehrwert, der durch einen Bericht, ein Dashboard oder einen Information Mart definiert wird, werden die benötigten Quelldaten identifiziert, durch alle Schichten modelliert und geladen.
Wie in Abbildung 1 dargestellt, wird nicht von Anfang an die gesamte Staging-Area-Schicht aufgebaut, sondern nur der Teil, der für die Daten im aktuellen Scope benötigt wird – in diesem Fall für den SalesReport.
Agile Entwicklung
Bevor eine neue Funktionalität in einem Sprint implementiert werden kann, muss sie klar definiert werden.
Diese Aufgabe liegt beim Product Owner, der für das Verfassen und Priorisieren der User Stories verantwortlich ist.
Wie bereits erläutert, besteht das Ziel eines Sprints darin, funktionierende und nutzbare Teilergebnisse (Features) bereitzustellen.
Darüber hinaus müssen technische Themen (Tech Topics) berücksichtigt werden. Zur Unterstützung der Sprint-Planung existieren verschiedene Methoden wie Planning Poker oder die Function-Point-Analyse, auf die in einem separaten Artikel näher eingegangen wird.
Ein wichtiger Indikator für den Projektverlauf ist die Evaluierung des laufenden Sprints. Gelingt es dem Entwicklungsteam nicht, ein Feature innerhalb eines Sprints umzusetzen, deutet dies häufig darauf hin, dass der Scope zu groß gewählt wurde.
Um dem vorzubeugen, sollten alle Arbeitspakete entfernt werden, die für das jeweilige Feature nicht zwingend erforderlich sind. Aus Sorge vor Verlust zögern Fachanwender jedoch oft, diese Arbeitspakete zu streichen.
Um dieser Sorge zu begegnen, sollte den Fachanwendern verdeutlicht werden, dass diese Arbeitspakete nicht verworfen, sondern lediglich in spätere Sprints verschoben und vorübergehend im Backlog geführt werden.
Dank des flexiblen und skalierbaren Data-Vault-Modells lassen sich die Schichten beim nächsten Feature mit minimalem bis gar keinem Re-Engineering erweitern. Dies ist möglich, da Data Vault aus einem Raw-Data-Vault- und einem Business-Vault-Modell besteht. Es kombiniert somit die logische Architektur mit der Perspektive der Datenmodellierung. Der Raw Data Vault wird datengetrieben modelliert, indem die Daten über Business Keys integriert werden. Hierbei werden ausschließlich Hard Business Rules wie Datentypkonvertierungen oder Hash-Key-Berechnungen angewendet. Sämtliche Soft Business Rules kommen erst im Business Vault zum Tragen.
Hier werden Daten in wertvolle Informationen verwandelt. Aus diesem Grund erfordert der Raw Data Vault kaum Refactoring und lässt sich unbegrenzt erweitern.
Review in der agilen Entwicklung
Ein wesentlicher Erfolgsfaktor agiler Projekte ist die regelmäßige Überprüfung und Optimierung. Vor dem Start des nächsten Sprints stehen für das Team folgende Meetings an:
- Das Sprint-Review-Meeting: Hier werden die gelieferten Features überprüft. In der Regel nehmen das Entwicklungsteam, der Product Owner, der Scrum Master und die Endanwender daran teil
- Das Retrospektive-Meeting: Dieses Meeting schließt meist direkt an das Review-Meeting an und dient dazu, Verbesserungspotenziale im Arbeitsprozess zu identifizieren.
- Das Backlog Refinement: Zur Priorisierung der User Stories und zur Klärung der anstehenden Aufgaben für das Team.
- Das Sprint Planning: Um auf Basis von Aufwandsschätzungen festzulegen, welche User Stories im kommenden Sprint umgesetzt werden.
Die konsequente Durchführung dieser Meetings ist essenziell, um Fehlerquellen frühzeitig zu erkennen. So lassen sich die Projektergebnisse kontinuierlich verbessern und die Entwicklungsprozesse iterativ optimieren.
Fazit
Data Vault 2.0 ist nicht nur eine skalierbare und flexible Modellierungstechnik, sondern eine ganzheitliche Methodik zur Umsetzung der Unternehmensvision im Data Warehousing und der Informationsbereitstellung (Information Delivery). Durch die Verbindung agiler Prinzipien mit einem klaren Fokus auf den geschäftlichen Mehrwert (Business Value) stellt Data Vault 2.0 sicher, dass Data-Warehouse-Projekte verlässliche, nutzbringende und hochwertige Ergebnisse für das Unternehmen liefern.
