Erfolgsfaktoren von Data Vault

Data Vault bietet viele Vorteile. Die Probleme bei der Adaption sind bekannt und führen häufig zu lautstarken Diskussionen. Darüber wird oft vergessen, dass es sich um eine Veränderung handelt. Bekannte Muster müssen aufgegeben werden und neue Wege etabliert werden. Mit der Erfahrung aus vielen Einführungsprojekten werden hier die Herausforderungen dieser Veränderung beleuchtet und konkrete Maßnahmen benannt, mit denen Sie die Vorteile von Data Vault erreichen werden.

Data Vault hat hohe Ziele und verspricht viele Verbesserungen:

• Nachhaltig: Das Core Warehouse bleibt stabil durch die Datenintegration über Geschäftsobjekte/Business Keys
• Erweiterbar: Hub, Link und Satellit sorgen für ein leicht erweiterbares Modell, das die Folgeänderungen auf Grund von Modelländerungen reduziert
• Schnelle Ergebnisse: Durch das Laden von unkonsolidierten Daten in den Raw Mart, können Daten sofort ausgewertet werden
• Minimaler Änderungsaufwand: Die Konsolidierung nur im Business Vault erlaubt schnelle Änderungen von Businessregeln ohne komplettes, erneutes Laden aller Daten
• Diversität: Im Business Vault können auf Basis derselben Fakten unterschiedliche Sichtweisen bzw. Business Regeln implementiert werden
• Geschwindigkeit: Die konsequente Umsetzung der Data Vault Architektur erlaubt einen hohen Grad an Automation
• Durchsatz und Parallelität: Hashkeys sorgen für eine hohe Nutzung von parallelen Prozessen

Leider können nicht alle Data Vault Initiativen diese Vorteile umsetzen. Was fehlt?

Data Vault ist ein anderes Vorgehen für BI. Je nachdem, welche Erfahrungen ein Mitarbeiter bereits gemacht hat, hat er eine eigene Wahrnehmung darüber, was anders ist. Das Wort ‚Wahrnehmung‘ trifft es hier, oft werden Aspekte von Data Vault nicht als neu wahrgenommen. So oder so ähnlich macht man es ja bereits seit Jahren und übersieht dabei Details. Wichtige Details. Hierzu später mehr.

Somit wird eine Data Vault Initiative zum Change Prozess. Für die erfolgreiche Umsetzung von Veränderungsprozessen gibt es eine einfache Formel: Ausbildung, Unterstützung durch Entscheidungsträger und gezielte Einsatz Data Vault erfahrener Mitarbeiter. Als Lösung ist das jedoch zu einfach. Deshalb: Was sind denn genau die Herausforderungen beim Umstieg auf Data Vault?

Herausforderung 1: Data Vault ist anders

Data Vault ist anders. Eine Mischung aus Neuem und Altbekanntem, dass in eine feste Struktur eingefügt wurde. Alle Tätigkeiten von der Stage bis zum Data Mart sind als Ganzes zu betrachten und aufeinander abgestimmt. Mitunter können lokale Vorteile nicht genutzt werden, weil ansonsten Vorteile auf einer anderen Schicht im Warehouse verloren gehen.

Doch weil vieles bekannt ist und manches davon in vergangenen Projekten ein echter Lebensretter war, kommt es oft zum ‚Ich habe da eine Verbesserung an Data Vault‘ Effekt. Noch bevor die Methode komplett verstanden ist. Erste Veröffentlichungen zu Data Vault gab es bereits in Jahr 2000. Auch wenn es in Deutschland noch recht neu ist, es gibt eine Vielzahl erfolgreicher Umsetzungen. Es funktioniert.

Und ja, es wird beständig weiterentwickelt: Dennoch sollte man sich am Anfang einer Data Vault Karriere vor allem fragen: Wie kann ich das Problem mit reinen Data Vault Mitteln lösen? Das ist ein sehr gutes Mittel, um Data Vault wirklich schnell zu lernen. Auch wenn man bereits 20 Jahre BI Erfahrung hat. Der Blick sollte immer sein: Wie löse ich das im Data Vault? Wie optimiere ich es in diesem Rahmen? Und bin ich auf der richtigen Schicht?

Diese Zeit sollte man sich bei den ersten Umsetzungen mit Data Vault nehmen. Es lohnt sich.

Herausforderung 2: Verschiedene Dialekte oder Glaubensgrundsätze

Der Drang Data Vault zu verbessern ist sehr groß und hat zu vielen Dialekten, Abweichungen und Glaubensgrundsätzen geführt. Der Indikator hierfür sind mit fast religiösem Eifer geführte Diskussionen über den richtigen Weg. In diesen Diskussionen werden häufig absolute Aussagen getroffen (‚keine n-ären Links‘, ‚keine Satelliten an Links‘). Leider gibt es wenig absolute Wahrheiten in der BI.

Zum Glück hat jede Maßnahme im Rahmen der Datenintegration klare Auswirkungen und damit Vor- und Nachteile. Absolute Aussagen erinnern stark an Populismus, einfache Wahrheiten, die in einer komplexen Welt ihr Versprechen von Einfachheit nicht halten können. Darum jeden Lösungsansatz mit Vor-/Nachteilen sowie den Auswirkungen auf die späteren Schichten beurteilenund dann die Lösung wählen. Dieses Vorgehen hat zudem den Vorteil, dass es das Verstehen von Data Vault massiv beschleunigt.

Herausforderung 3: Data Vault ist nur an der Oberfläche einfach

Beim Blick auf Hub, Link und Satellit entsteht schnell der Eindruck, dass Data Vault eine Simplifizierung des Datenmodells ist. Und dennoch ist es strikter als 3NF. Darunter verbirgt sich also eine hohe Komplexität und klassische Datenmodellierung, die sich vor allem beim Umsetzen der Links bemerkbar macht. Es gibt nur m:n Beziehungen. So wird verhindert, dass man Beziehungen im Zeitverlauf ändern muss. Ein Wechsel von 1:n zu m:n hat keine Änderung im Datenmodell zur Folge. Zudem werden aus 1:n Beziehungen durch die historische Speicherung sowieso automatisch m:n Beziehungen.

Dennoch muss beim Zugriff auf die Daten geachtet werden, dass es zu einem Zeitpunkt nur eine 1:n Beziehung ist. Die Gültigkeit von Links, also die Abbildung der Zeit, erhält eine höhere Bedeutung. Passieren hier Fehler, kann es beim Join über diese Links zu einer magischen Vervielfachung der Daten kommen.

Ein weiteres Problem sind Daten, die an einer echten m:n Beziehung hinterlegt sind. Handelt es sich hierbei um ein relevantes Business Objekt und sollte deshalb in einem Hub hinterlegt sein? Wirklich deutlich wird das oft erst später, wenn andere Transaktionen auch Daten zu dieser m:n Beziehung liefern.

Erstaunlicherweise lassen sich oft Performanceprobleme lösen, wenn man den Link besser schneidet, in dem man das Datenmodell in Punkto Normalisierung überarbeitet. Mit Data Vault wird mehr Fokus auf die Datenmodellierung und das inhaltliche Verständnis der Daten gelegt. Das wird gerade an der Modellierung der Links deutlich.

Neben dem Link gibt es noch weitere herausfordernde Themen im Data Vault, die unter der Oberfläche schlummern. Welche das sind, hängt jeweils vom aktuellen Wissensstand ab. Neben den Data Vault Schulungen mit Zertifizierung von scalefree oder genesee academy gibt es im Netz eine Vielzahl von Quellen für Data Vault. Eine Zusammenstellung findet sich unter https://datavaultusergroup.de/data-vault/links/. Der aktivste Blog zum Thema Data Vault ist http://roelantvos.com/blog.

Herausforderung 4: Adaption der Data Vault Architektur

Während also auf der einen Seite die Sicht deutlich fachlicher wird, erweitert sich die Sicht der Dinge gleichzeitig auch mehr in Richtung der Technik. Es gilt die Architektur von Data Vault auf den eigenen Technologiestack anzuwenden.

In der Architektur von Data Vault gilt es, die konkreten Aktionen genau an der dafür vorgesehenen Stelle zu platzieren. In der Stage werden nur Hard Business Rules umgesetzt, die Daten werden unverändert in den Raw Vault geladen. Soft Business Rules – die Änderungen an den Daten – finden ihre Anwendung im Business Vault genauso wie Datenbereinigung, Maßnahmen zur Datenqualität und die Berechnung der Basiskennzahlen. Im (Data/Raw/Information) Mart werden die Daten in der gewünschten Form bereitgestellt. Das führt dazu, dass alle komplexen Tätigkeiten in den Business Vault verlagert wurden. Wie wird dort der Überblick gehalten?

Eine Architektur in Data Vault sollte nicht nur die Verteilung der Schichten auf die jeweiligen Systeme enthalten, sondern auch festlegen, welche Aktionen in welcher Reihenfolge in welcher Schicht stattfinden. Innerhalb von Data Vault gibt es hier gewisse Freiheiten. Für eine optimale Ausnutzung der verwendeten Systeme braucht es genau diese Freiheiten. Es gibt nicht den einen Weg, der überall gleich optimal abläuft.

Diese Architektur und die Dokumentation der Implementierung sind in Entwicklungsrichtlinien festzulegen. Auf diese Weise wird eine Entwicklungsumgebung für das Data Warehouse geschaffen, und das Entwicklungsteam muss nicht für jede Datenquelle alles neugestalten und bedenken. Für die Adaption der Architektur und den Aufbau einer Entwicklungsumgebung braucht es zudem ein eigenes Budget – innerhalb eines Projektes oder übergreifend.

Herausforderung 5: Data Warehouse Automation

Unabhängig, ob ein Werkzeug zur Data Warehouse Automation eingesetzt wird oder ob eine eigene Generierung der Ladepattern entwickelt wird: Die Data Warehouse Automation ist nur dann erfolgreich, wenn das Vorgehen – die Implementierung – standardisiert ist.

Aus der Industrie wissen wir, nur was standardisiert ist, kann auch automatisiert werden. In der Industrie ist Standardisierung und Automatisierung auch bei hohem Variantenreichtum möglich. Innerhalb der BI ist dieser Prozess zäh. Es gibt eine langjährige Tradition des Pragmatismus. Mache so wenig wie möglich und löse nur das aktuelle Problem. Geboren wurden dieses Mindset aus einer Tradition der knappen Ressourcen und des hohen Bedarfs. Dieser Pragmatismus ist ein hohes Gut, führt aber leider auch zu hoher Diversität im Data Warehouse und ist damit eine der zentralen Quellen für die hohen Wartungsaufwände.

Das Laden des Raw Vault kann ein solcher standardisierter Prozess sein, der dann schnell und einfach automatisiert werden kann. Der darauf aufbauende Business Vault liefert Varianten. Doch dies ist erst der Anfang. Andere stark automatisierte Schritte können folgen. Dafür müssen zusätzliche Prozessschritte vereinheitlicht und standardisiert werden. Mit dem bisher geschilderten Lösungsansätzen lassen sich diese Prozesse weiter standardisieren. Die Basis hierfür ist Ausbildung (Herausforderung 1-3) und Vereinheitlichung (Herausforderung 2-4).

Im Übrigen gilt dies auch bei Einsatz eines Automatisierungswerkzeugs. Gerade hier ist es wichtig, die Entwicklungsprozesse einheitlich und optimiert auf das Werkzeug festzulegen. Nur so wird das Optimum aus der Investition erzielt. Wenn jeder eigene Zusätze und Sonderlösungen anbringt, verlangsamt das nicht nur die Implementierung, sondern resultiert dann später auch in einen größeren Wartungsproblem. Die Zusätze und Sonderlösungen sind auf jedes neue Release zu übertragen.

Maßnahmen: Die einfache Antwort wird konkret

Zu Beginn hieß es die einfache Antwort sei wie immer in solchen Fällen: Ausbildung, Unterstützung durch Entscheidungsträger und gezielte Nutzung Data Vault erfahrener Mitarbeiter. Wenn wir den vorliegenden Artikel Revue passieren lassen, dann lassen sich daraus Maßnahmen ableiten, die eine Data Vault Initiative erfolgreich machen.

Maßnahme 1: Ausbildung

Nach erfolgter Schulung, egal ob im Selbststudium oder mit einer der zertifizierten Schulungen, gilt es Data Vault umzusetzen, d.h. für einen konkreten Anwendungsfall im Unternehmen eine Implementierung in die Produktionsumgebung zu bringen.

Hierbei sollte der Fokus immer auf ‚Wie geht es mit Data Vault?‘ liegen. Es gibt eine 20-jährige Data Vault Tradition, in der sich Lösungen finden lassen. Schnelle, eigene Erweiterungen von Data Vault scheitern meist an unerwünschten Nebeneffekten in anderen Schichten.

Für Lösungsvarianten braucht es ein Für und Wider, Aufwand und Nutzen. Auf dieser Basis fällt die Implementierungsentscheidung leicht und unnötiges Re-Design wird vermieden.

Für die Implementierungsentscheidungen braucht es einen einfachen und schnellen Abstimmungsprozess. Wenn erst langwierig ein Termin mit allen Beteiligten angesetzt werden muss, bremst dies leider allzu oft die Entwicklung, die Begeisterung und den Arbeitswillen. Die gute Beschreibung der Lösungsvarianten macht diese Abstimmung einfach, reicht jedoch allein oft nicht aus.

Gezielte Experimente sind ein guter Weg, um Alternativen gegeneinander aufzuwiegen. Lange Diskussionen werden durch klare Parameter ersetzt und am Ende steht ein Machbarkeitsbeweis. Zudem liefern Experimente die notwendigen pro und contra Argumente. Andrew Hunt spricht in seinem Buch ‚Der pragmatische Programmierer‘ von Leuchtspurmunition. Wir machen einen ersten einfachen Schuss in die Richtung und beobachten, ob die Lösung tragfähig ist. So lassen sich beispielsweise zwei Muster im direkten Vergleich in einer einfachen Implementierung gegeneinander messen.

Die Ergebnisse aus diesen Experimenten sollten auf einer Projektwebsite oder in einem Wiki erfasst werden. So müssen diese Experimente nicht laufend neu erdacht werden. Ein regelmäßiger Austausch darüber, was hilfreich war und welche Lösungen verworfen wurden, hilft bei der Wissensverbreitung. Das kann ein einfacher Wissensaustausch sein oder eine regelmäßige Retrospektive. Die Dokumentation dieser Sitzungen ist kein Selbstzweck. Häufig reicht es, die Agenda, die Vortragenden, die Teilnehmer und die verwendeten Folien bzw. die abfotografierten Whiteboards/Flip Charts zu dokumentieren. Dann ist klar, wen man hierzu befragen kann und es braucht keine wasserdichte Dokumentation. Der Erfahrungsaustausch als lebendiger Prozess des experimentellen Lernens ist wichtiger als die vollständige Dokumentation.

Diese Aktivitäten sollten in eine gemeinsame Entwicklungsumgebung münden. Jetzt wird die Dokumentation wichtig. Die Entwicklungsumgebung muss gut dokumentiert sein. Sie dient als Nachschlagewerk und hilft neue Mitarbeiter einzuführen. Die Entwicklungsumgebung mit den jeweiligen Richtlinien wird auf Grund der getroffenen Entscheidungen gebildet. Den Entwicklungsprozess nachvollziehbar und wiederholbar zu machen, erspart späteren Projekten wieder bei null anzufangen und der Fokus kann so – mit deutlich geringerem Aufwand – auf der Weiterentwicklung des Entwicklungsprozesses liegen.

Maßnahme 2: Management

Die Aufgabe im Management ist es, ein Budget für die Entwicklungsumgebung zu erhalten und dieses bei Projektschwierigkeiten zu verteidigen. Die Entwicklungsumgebung sichert eine steile Lernkurve, wird dies aufgegeben, sind auch künftige Projekte nicht schneller. Und letztlich rechnet jeder beim ersten Mal mit Extrakosten, auch wenn das nicht zugegeben wird. Wenn die Folgeprojekte gut laufen, sind Anfangsschwierigkeiten bald vergessen.

Für die Ausbildung und das Ausprobieren ist ein Budget auch nicht schlecht. Viel wichtiger ist es jedoch diesen Austausch und die Experimente möglich zu machen; Eine Stimmung im Team zu generieren, die einlädt Dinge mit hoher Zielorientierung auszuprobieren. Diese Aufgabe fällt in Scrum dem Scrum Master zu. Es braucht jemand, der sich explizit um alle Hindernisse kümmert, die dem Projektziel und der neuen Entwicklungsumgebung entgegenstehen.

Maßnahme 3: Erfahrene Mitarbeiter

Ein erfahrener Mitarbeiter weiß wie die Implementierung auszusehen hat. Wenn er lediglich mitteilt, wie die Lösung auszusehen hat, mutieren seine Kollegen zu willigen Erfüllungsgehilfen. Ein guter Coach zeigt bekannte Lösungen auf und hilft die Vor- und Nachteile in diesem Umfeld zu bewerten. Er beschleunigt die Lernkurve in dem er Hilfe zur Selbsthilfe anbietet.

Fazit

Data Vault bietet viele Vorteile. Die Probleme bei der Adaption sind bekannt und führen häufig zu lautstarken Diskussionen. Darüber wird oft vergessen, dass es sich um eine Veränderung handelt. Bekannte Muster müssen aufgegeben werden und neue Wege etabliert werden. Besonders schwierig sind solche Änderungen, wenn der Erfahrungsschatz bereits groß ist.

Eine erfolgreiche Data Vault Initiative braucht einen großen Fokus auf das Erforschen des Neuen. Die Erkenntnisse fließen in ein Entwicklungsvorgehen und dieses Vorgehen ist als neue Entwicklungsumgebung festzulegen und zu dokumentieren. Nur so stehen die gewonnenen Erkenntnisse den nächsten Projekten zur Verfügung. Diese Entwicklungsumgebung wird sich mit Folgeprojekten weiterentwickeln.

Im Management muss dafür gesorgt werden, dass das Team lernen kann. Idealerweise sichert man das über eine Rolle, die sich der Probleme im Tagesgeschäft annimmt und – natürlich – über ausreichende Budgets.

Sie möchten wissen, wo Sie mit der Einrichtung Ihres Projektes stehen? Füllen Sie einfach unseren Fragebogen aus und erhalten Sie eine kostenfreie Ersteinschätzung mit Handlungsempfehlungen.