Ausgangssituation:

Ein häufiges Problem bei data warehousing-Projekten ist das Fehlen eines Umfangs, und viele der Prozesse wie kontrollierter Zugang, GDPR-Handhabung, Auditierbarkeit, Dokumentation und Infrastruktur sind nicht optimiert. Darüber hinaus beginnen data warehouse-Projekte, die einen Umfang haben, oft ohne einen echten Fokus auf den Geschäftswert. Das liegt meist daran, dass die Anwendungsfälle nicht klar kommuniziert werden und die Datenarchitekten nicht wissen, wo sie ansetzen sollen. Dies hat zur Folge, dass kein geschäftlicher Nutzen erzielt werden kann.

Data Vault 2.0 Methodik

Es wird oft angenommen, dass Data Vault 2.0 nur eine Modellierungstechnik ist, aber das ist nicht richtig. Data Vault 2.0 umfasst die Modellierungstechnik, eine Referenzarchitektur und die Methodik. Die Methodik führt Projektmanagement-Tools wie CMMI, Six Sigma und Scrum ein, um die beschriebenen Probleme zu lösen. Während CMMI und Six Sigma sich mit allgemeinen Fragen des Projektmanagements befassen, wird Scrum meist speziell im Entwicklungsteam eingesetzt und bietet den Rahmen für einen sich ständig verbessernden Entwicklungsprozess. Der Einsatz der agilen Entwicklung in Data Vault 2.0-Projekten wird im Folgenden näher beschrieben.

Der Umfang eines Sprints

Der erste Schritt bei der Einrichtung eines data warehouse-Projekts auf agile Weise ist die Definition des Projektziels auf nur ein oder zwei Seiten. Anders als bei Wasserfall-Projekten besteht das Ziel darin, in kontinuierlichen Iterationen, den so genannten Sprints, funktionierende Stücke mit brauchbaren Ergebnissen zu produzieren, z. B. Berichte oder Dashboards. Das bedeutet, dass wir nicht das gesamte Projekt im Detail planen müssen, sondern stattdessen auf einer allgemeinen Idee oder einem Ziel für das endgültige data warehouse aufbauen können, bevor wir uns dann auf die Planung der ersten Sprints konzentrieren. Um die oben genannten Probleme anzugehen, muss der Schwerpunkt der Sprints auf dem Geschäftswert liegen. Aus diesem Grund ist es wichtig, für einen kontinuierlichen Verbesserungsprozess ständig Feedback von den Geschäftsanwendern zu erhalten.

Definieren Sie das Projekt

Sowohl der Umfang eines Sprints als auch die Architektur folgen einem geschäftswertorientierten Ansatz, der vertikal und nicht horizontal aufgebaut ist. Das bedeutet, dass sie nicht Schicht für Schicht, sondern Funktion für Funktion aufgebaut werden. Ein gängiger Ansatz hierfür ist der Tracer-Bullet-Ansatz. Auf der Grundlage des Geschäftswerts, der durch einen Bericht, ein Dashboard oder eine Funktion definiert ist. Informationsmarktdie Quelldaten werden identifiziert und durch alle Schichten hindurch modelliert und geladen. 

Wie in Abbildung 1 dargestellt, wird zunächst nicht die gesamte Schicht des Bereitstellungsbereichs aufgebaut, sondern nur ein kleiner Teil der jeweiligen Schicht auf der Grundlage von Daten aus dem Anwendungsbereich, in diesem Fall dem SalesReport.

Agile Entwicklung

Bevor eine neue Funktionalität in einem Sprint implementiert werden kann, muss sie definiert werden.
Diese Aufgabe obliegt dem Product Owner, denn er ist es, der die User Stories schreibt und priorisiert.
Wie bereits erläutert, besteht das Ziel eines Sprints darin, brauchbare Ergebnisse, sogenannte Features, zu produzieren.
Darüber hinaus gibt es technische Themen, die berücksichtigt werden müssen. Es gibt verschiedene Methoden zur Unterstützung der Sprint-Planung, wie z.B. Planungspoker oder Function Point Analysis, die in einem anderen Artikel ausführlicher behandelt werden. Artikel.

Ein weiterer guter Indikator ist die Bewertung des Sprints selbst, während der Sprint noch läuft. Wenn es dem Entwicklungsteam nicht gelingt, eine Funktion in einem Sprint zu implementieren, kann dies oft als guter Indikator dafür angesehen werden, dass der Umfang zu groß ist. 

Um dies zu vermeiden, sollten alle Arbeitspakete, die für das Feature nicht relevant sind, entfernt werden. Allerdings werden diese Arbeitspakete aus Angst vor den Geschäftsanwendern oft nicht vollständig entfernt. 

Um diese Befürchtung zu zerstreuen, ist es wichtig, den Geschäftsanwendern zu vermitteln, dass sie zwar geliefert werden, aber erst in einem späteren Sprint und vorübergehend in das Backlog verschoben.

Aufgrund des flexiblen und skalierbaren Data Vault-Modells können diese Schichten mit der nächsten Funktion mit wenig bis gar keinem Re-Engineering erweitert werden. Dies ist möglich, weil Data Vault aus einem Raw Data Vault- und einem Business Vault-Modell besteht, d. h. es enthält sowohl die logische Architektur als auch die Datenmodellierungsperspektive. Die Raw Data Vault wird datengesteuert modelliert, indem die Daten über Geschäftsschlüssel integriert werden. Nur harte Geschäftsregeln wie Datentypkonvertierungen oder Hash-Schlüssel Berechnungen angewendet werden. Alle anderen weichen Geschäftsregeln werden nur im Business Vault angewendet. 

Hier verwandeln wir Daten in Informationen. Aus diesem Grund erfordert das Raw Data Vault weniger Refactoring und kann unbegrenzt erweitert werden.

Review

Ein weiterer wichtiger Erfolgsfaktor für agile Projekte ist eine angemessene Überprüfung und Verbesserung. Noch bevor der nächste Sprint beginnt, muss das Team zwei Sitzungen abhalten:

• Das Sprint-Review-Meeting: Bei diesem Treffen geht es um die Überprüfung der gelieferten Funktionen. Normalerweise nehmen das Entwicklungsteam, der Product Owner, der Scrum Master und die Endbenutzer an diesem Treffen teil.
• Retrospektive Sitzung: Diese Sitzung findet in der Regel direkt nach der Überprüfungssitzung statt und konzentriert sich auf die Ermittlung von Aktivitäten, die verbessert werden müssen.
• Verfeinerung des Backlogs für die Priorisierung der User Stories und um sicherzustellen, dass das Team weiß, was zu tun ist
• Sprint-Planung zu planen, welche User Stories in den nächsten Sprint passen, basierend auf der Schätzung des Aufwands.

Es ist wichtig, dass diese Treffen stattfinden, damit Fehler an der Quelle gefunden werden können. Auf diese Weise kann das Ergebnis eines Projekts verbessert und die Entwicklungsprozesse iterativ optimiert werden.

Schlussfolgerung

Data Vault 2.0 ist nicht nur ein skalierbares und flexibles Modellierungsverfahren, sondern eine vollständige Methodik zur Verwirklichung der Unternehmensvision in Data Warehousing und Informationsbereitstellung durch die Anwendung eines agilen Ansatzes und die Konzentration auf den Geschäftswert. Durch den Einsatz agiler Methoden in data warehousing kann der Schwerpunkt bei Projekten auf dem Geschäftswert und der Bereitstellung nützlicher Produkte für den Kunden liegen.

Updates und Support erhalten

Bitte senden Sie Anfragen und Funktionswünsche an [email protected]. 

Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.

Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.