Über unsMediaKontaktImpressum
Christoph Papenfuss 14. August 2024

Drei Ansätze zum Aufbau eines resilienten Data Warehouse

Datenhaltung gibt es auf verschiedenen Ebenen: im Data Lake zur flexiblen Speicherung bloßer Rohdaten, mittels Datenbanken für schnelle Transaktionen und Abfragen über strukturierte Daten oder aber im Data Warehouse (DWH) – dem zentralen Repository, das Daten aus verschiedenen Quellen integriert, speichert und für die Analyse aufbereitet, oft optimiert für Abfragen und Berichte. Dies ist zugleich der entscheidende Zusatznutzen eines DWH gegenüber Datenbanken.

Wenn Data Warehouses nun aber durch ihre Analysefähigkeiten dazu beitragen können, bessere Geschäftsentscheidungen zu fällen, warum verfallen die meisten von ihnen schon nach kurzer Zeit in einen Dornröschenschlaf? In der Tat gelten viele Data Warehouses als gescheitert. Anfangs noch hochfunktional, verkommen sie über die Zeit immer mehr und werden nach zwei Jahren schon nicht mehr richtig verwendet. 

Wenn das Vertrauen in die Daten verloren geht

Das hat verschiedene Gründe. In der Regel scheitern DWH-Projekte an mangelnder Anpassungsfähigkeit, zu hoher Komplexität, Ressourcenmangel, der Tatsache, dass neue Datenquellen nicht zeitnah angebunden werden sowie steigender technischer Schuld, d.h. den Konsequenzen schlechter technischer Umsetzung – meist auch an einem Mix aus allen. Er führt dazu, dass niemand mehr mit dem System arbeitet, weil das  grundsätzliche Vertrauen in die Daten verloren gegangen ist.
Um dieser Falle zu entkommen und aus seinem DWH langfristig Nutzen zu ziehen, muss man es resilient machen gegen die ständigen äußeren Einflüsse: Änderungen der Datenquellen, Anbindung neuer Datentypen, wesentliche Strukturänderungen durch Reorganisationen oder Akquisitionen sowie ständig neue und angepasste Anforderungen der Beschäftigten. Mit anderen Worten, das DWH muss so flexibel aufgebaut sein, dass es Veränderungen und Störungen bewältigt, anstatt zusammenzubrechen und unwartbar zu werden. Dafür gibt es unterschiedliche Best-Practice-Ansätze:

1. Gemischte Teams

Top-Spezialisten mögen das ganze Datenkonstrukt in Eigenregie programmieren können. Das birgt aber die Gefahr, dass man vollständig von ihnen abhängig wird. Besser ein ausgewogenes Team aus Profis und Einsteigern zusammenstellen, in dem sich einer mit Datenarchitekturen auskennt, die nächste mit öffentlichen Plattformen usw. 

Das Verschmelzen von Entwicklung und Support in einem Team bezeichnet man auch als DataOps, Kurzform von Data Operations. Es verbindet Data Science mit DevOps, d.h. der Automatisierung und Integration von Prozessen zwischen Softwareentwicklung und IT. DataOps beschreibt also automatisierte, prozessorientierte, agile Methoden, mit denen Datenteams die Qualität und die Zykluszeit von Datenanalysen verkürzen können. 

Erforderlich sind ferner Data Modelling Standards. Hier kann man den Modellierungsansatz Data Vault nutzen, um sich robust aufzustellen. Gegenüber älteren Konzepten tut sich Data Vault leichter mit Änderungen im Unternehmen wie beispielsweise bei Reorganisation, neuen Quellsystemen etc. Allerdings ist Data Vault nicht leicht zu beherrschen. Ohne spezialisierte Data-Warehouse-Automatisierungstools dürfte es schwierig werden, Data Vault zu implementieren und zu betreiben.

2. Continuous Delivery

Continuous Delivery bedeutet das permanente Einspielen neuer Features in das Data Warehouse, seien es Produktverbesserungen oder Bug Fixes im Wochen- oder Tagesrhythmus. Früher waren diese Abstände wesentlich größer – die Motivation, in ein Produktivsystem einzugreifen, war nicht gerade ausgeprägt. Das in die Jahre gekommene Wasserfallmodell ist heute nicht mehr tragfähig. Anwender:innen wollen und können nicht Wochen oder Monate auf Verbesserungen warten. Eine Version-Management-Software für sein Data Warehouse einzusetzen, bedeutet noch nicht Continuous Delivery. Es geht vielmehr um kleine, permanente Entwicklungen, die automatisch stattfinden, wie ein Uhrwerk. 

Das große Data Warehouse wird dafür modulartig zerlegt und darauf basierend der Entwicklungs-Flow optimiert. Hier bieten sich agile Methoden an, wie sie das Framework Agile Data Engine verwendet,  und die Verbindung vom iterativen mit dem inkrementellen Entwicklungsansatz: Auf jeder iterativen Stufe gibt es die Gelegenheit zur Überprüfung und Verbesserung, wobei neue Funktionen ergänzt werden. Man kann hier auch gut "Trunk-based Development" betreiben, wobei Entwicklungsteams jede neue Funktion, Fehlerkorrektur oder andere Codeänderung in einen zentralen Zweig ("trunk", "mainline" oder in GitHub "main") im Versionskontrollsystem einbringen. 

Insgesamt erlaubt dies eine schnelle Anpassung an sich ändernde Anforderungen und kontinuierliche Verbesserung. Die Zufriedenheit der Anwender:innen steigt und die technische Schuld kann dadurch oftmals reduziert werden.

3. Continuous Improvement

Um Datenqualität zu gewährleisten und die Anforderungen der User effizient zu erfüllen, sollte das Data Warehouse kontinuierlich verbessert werden. Aber nicht nur das Produkt selber – sondern auch das Data-Team muss seine Arbeitsweise fortlaufend anpassen und verfeinern. Recht häufig wird dieser Aspekt vernachlässigt. Gut funktionierende Teams sind leistungsfähiger und tragen auch zu einem positiven Betriebsklima bei. Dazu sollte die Effizienz und Effektivität der eigenen Arbeit gemessen und analysiert werden. Das DORA Framework aus dem DevOps Bereich liefert hier einige gute Vorschläge und Beispiele.

Metriken wie Deployment Frequency, Deployment Failure Rate oder Failure Recovery helfen dem Team, Prozesse und Arbeitsweisen zu verbessern. Mit Automatisierungswerkzeugen wie Agile Data Engine kann man diese Kennzahlen regelmäßig überprüfen und aktualisieren. Darin enthalten sind auch Tools zur Echtzeit-Überwachung der Systemperformance und -verfügbarkeit. Regelmäßige Berichte und Dashboards zeigen wichtige Kennzahlen und Trends im Data Warehouse auf.

Fazit

Iterative Entwicklungen, Automatisierung, kontinuierliche Überwachung der Datenqualität, flexible Skalierung und Einbindung von Benutzerfeedback – Mit diesem Maßnahmenbündel kann es Unternehmen gelingen, ihr Data Warehouse endlich zu einem starken und verlässlichen Instrument zu machen, mit dem die Beschäftigen gern arbeiten, weil sie ihm vertrauen. Die katastrophale Erfolgsquote der DWH-Projekte gehört damit künftig hoffentlich der Vergangenheit an.

Autor

Christoph Papenfuss

Christoph Papenfuss ist Spezialist für Data Analytics. Als Unternehmensberater hat er im Silicon-Valley-Büro von KPMG mit Unternehmen wie Apple, Electronic Arts und Daimler an Datenprojekten gearbeitet.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben