Wertgetriebenes Vorgehen für DWH-Sanierung

DWH-Sanierungsprojekte zeichnen sich durch eine strukturierte, schrittweise Verbesserung der bestehenden Data Warehouse Umgebung aus. Die Motivation für die Sanierung einer bestehenden (Enterprise) DWH Umgebung kann vielfältig sein: z.B. Kostensenkung, bislang nicht abbildbare, neue Anforderungen oder Performance-Kriterien. Liegt ein „Sanierungsfall“ vor, besteht dringender Handlungsbedarf. Verbesserungsziele müssen zeitnah umgesetzt werden, und stehen so im Konflikt mit längerfristigen Zielen, wie z.B. einer konsequenten Bereinigung der DWH Architektur. Sanierungsprojekte für komplexe DWH Umgebungen können über einen längeren Zeitraum andauern – und so den Rahmen von üblichen Projektgrößen überschreiten. Es besteht so die Gefahr, dass Sanierungsprojekte bereits im Beantragungsprozess stark hinterfragt werden. Bewährt hat sich eine Einteilung in überschaubare Projektabschnitte („Sanierungspakete“) entlang der Größe der Wertgenerierung (Cost/Value Optimierung). Hierbei bilden die Projektabschnitte im Idealfall jeweils einen eigenen positiven Business Case. Der Ansatz des „wertgetriebenen Vorgehens“ wird konkretisiert anhand der Sanierung eines in einem Zeitraum von 14 Jahren teilweise unkontrolliert gewachsenen Data Warehouses bei einem Finanzunternehmen.
Die Grundsteinlegung für eine große Zahl von Data Warehouse Systemen fand vor 15-20 Jahren statt. Die Motivation für eine Sanierung historisch gewachsene Systeme ergibt sich häufig aus gestiegenen Anforderungen oder aus nicht mehr gegebener Flexibilität/Wartbarkeit. Herausforderungen sind dabei u.a.: unklare Ist-Architektur, fehlendes Know-How, veraltete Technologien. In diesem Kontext stellt sich die Frage: Neubau oder Sanierung des bestehenden Systems? (siehe auch: [Die16]) Ergänzend einsetzbare Technologien (z.B. In-Memory Datenhaltung), DWH Automatisierungsverfahren oder Data Vault als Möglichkeit zur schrittweisen Datenmodell-Konsolidierung erleichtern Sanierungsvorhaben erheblich. Es zeigt sich eine Analogie zur Immobilie: es muss also nicht unbedingt ein „Neubau“ sein, um wieder zukunftsfähig zu werden.
Wertgetriebenes Vorgehen
Jedes DWH Sanierungsprojekt adressiert Ziele im Sinne von Verbesserungspotenzialen bzw. der Behebung von Schwachstellen. Eine Unterteilung des Sanierungsprojekts in „Sanierungspakete“, die schrittweise umgesetzt und produktiv gestellt werden, ist dabei sinnvoll. Auf diese Weise können umgesetzte Verbesserungen rasch einen Wertbeitrag leisten – und so Sponsoren als auch Anwender schrittweise und jeweils zeitnah zufrieden stellen.
Die Grundidee eines wertgetriebenen Vorgehens besteht in der Aufstellung einer Metrik bzgl. Kosten und Wert, anhand welcher die Umsetzungsabschnitte zur Erreichung der Sanierungsziele bewertet werden. Anhand einer Cost/Value Bewertung einzelner Maßnahmen können Sanierungspakete sinnvoll geschnitten und in eine „wertgetriebene“ Reihenfolge gebracht werden. Sanierungspakete mit einem besonders hohen Wertbeitrag sollten möglichst früh realisiert und produktiv gesetzt werden – um rasch eine „Verzinsung“ zu erreichen. Je früher Sanierungspakete live gestellt werden, desto länger erwirtschaften sie „Value“ – und tragen so stärker zur Finanzierung des Projekts bei. Sanierungspakete mit einem niedrigen Wertbeitrag sind auf den Prüfstand zu stellen und ggf. gänzlich zu verwerfen.
Die Bewertungsmetrik kann je Sanierungsvorhaben und Priorisierung innerhalb einer Unternehmung individuell ausfallen. Die beiden Tabellen Tab. 1 und Tab. 2 stellen ein Fallbeispiel für eine Cost/Value Metrik vor. Die einzelnen Faktoren werden auf einer Skala von 1..5 bewertet und gemäß ihrer Priorisierung gewichtet. Der Wertbeitrag eines Sanierungspakets stellt sich somit über die Summe der gewichteten „Value“ Faktoren dividiert durch die Summe der gewichteten „Cost“ Faktoren dar.
Durch die Gewichtung im o.g. Beispiel werden Sanierungspakete mit höherem Risiko (z.B. durch Einführung einer neuen Technologie) in der Chronologie der Bearbeitung nach hinten verschoben – und Sanierungspakete mit hoher Kostenersparnis nach vorne. Bei bestimmten Faktoren ist eine Obergrenze sinnvoll z.B. bei Laufzeitreduktion.

Der Prozess zur wertgetriebenen Sanierung eines DWH ist in Abb. 1 in einer Übersicht dargestellt. Nach der Aufstellung der Sanierungsziele sowie der beschriebenen Bewertungsmetrik Cost/Value ist eine Bestandsaufnahme des DWH Systems erforderlich, um Aufwände und Potenziale der Sanierung möglichst vollständig ableiten zu können. Das Ergebnis der Ist-Analyse dient im folgenden Schritt dazu, ein passendes Lösungsdesign für die Sanierung zu finden. Z.B. eine angepasste DWH Architektur oder den Einsatz neuer Technologien bzw. Modellierungsverfahren. Die Bestandsaufnahme kann insbesondere in historisch gewachsenen DWH-Umgebungen zu hohen Aufwänden führen. Dies trifft gerade dann zu, wenn im Laufe der Jahre verschiedene „Unterlassungssünden“ wie fehlende/nicht eingehaltene Architektur- und Entwicklungsvorgaben (z.B. Folge von „Quick Win“-Projekten), fehlende Dokumentation oder Fluktuation von Know-How vorliegen.
Für komplexe DWH Umgebungen kann es sinnvoll sein, die Ist-Analyse ebenfalls abschnittsweise durchzuführen, z.B. entlang fachlicher Domänen oder einzelner DWH-Schichten. Je niedriger der erwartete Cost/Value Beitrag eines Sanierungspakets ist – desto weniger Aufwand sollte nach Möglichkeit in die jeweilige Analyse fließen. Möglichweise findet bei niedrigem Wertbeitrag eine Umsetzung niemals statt. Die Erkenntnisse aus der abschnittsweise Bearbeitung von Sanierungspaketen spielen im Sinne einer inkrementellen Bearbeitung wieder in die vorangegangenen Schritte zurück (siehe Abb. 1). Für eine Bestandsaufnahme ist eine fachliche Analyse der DWH-Prozesse, Schnittstellen, Data Marts usw. zu bevorzugen. Auf dieser Ebene können Optimierungen / Konsolidierungen leichter abgeleitet werden, als dies bei einer technischen Analyse der Fall ist. Stehen Dokumentationen zu Fachkonzepten oder Interviewpartner in fachlichen Abteilungen nicht ausreichend zur Verfügung, kann eine technische Analyse von Metadaten, Data Lineage oder sogar Programmcode das Bild im Sinne eines „Archäologischen Vorgehens“ vervollständigen. Siehe hierzu weiter unten „Projektbeispiel“.
Aus der Klärung des Bestands durch die „Ist-Analyse“ werden im Schritt „Lösungsdesign“ die zur Erreichung der Sanierungsziele notwendige Architekturanpassungen, einzusetzende Technologien, Modellierungsverfahren und Vorgehensweisen abgeleitet. Die Erkenntnisse aus der Ist-Analyse z.B. hinsichtlich standardisierbarer Logik oder wiederverwendbarer zentraler Datenbereiche dienen für späteren Entscheidungen im Lösungsdesign, z.B. ob DWH Automatisierungsverfahren oder Data Mart Virtualisierung sinnvoll für eine Sanierung einzusetzen sind.
Nach dem die Zielarchitektur, einzusetzende Technologien und Methoden feststehen, ist eine handhabbare Einteilung von Sanierungspaketen vorzunehmen. Aus diesen Paketen lassen sich – ja nach Granularität – Projekte, Teilprojekte oder Arbeitspakete ableiten. Die oben vorgestellte Metrik bzgl. Cost/Value ist ein sehr guter Richtwert für die Unterteilung von Paketen sowie als Entscheidungshilfe für Sponsoren und Fachnutzer. In der Praxis sind beim Schnitt der Sanierungspakete neben der Betrachtung von Cost/Value weitere Aspekte zu berücksichtigen, u.a.:

• technische oder fachliche Abhängigkeiten
• Synergien die sich durch eine bestimmte Reihenfolge bei der Bearbeitung von Paketen ergeben

Die Restriktionen, die sich hierdurch in der Praxis ergeben bleiben jedoch beherrschbar (siehe folgender Abschnitt „Wertgetrieben DWH Sanierung in der Praxis“).

Bei der schrittweisen Umsetzung und Inbetriebnahme der Sanierungspakete kommen fortlaufend neue Erkenntnisse hinzu, welche in die Ist-Analyse, Lösungsdesign und sogar Schnitt von folgenden Paketen im Sinne eines inkrementellen Vorgehens reinspielen. Auf Basis der gewonnenen neuen Erkenntnisse ist eine Neubewertung von Cost/Value für nachfolgende Sanierungspakete sinnvoll. Nicht nur bei der Einführung von neuen Technologien oder Methoden findet während des laufenden Sanierungsprozesses ein Lernprozess durch die Projektbeteiligten statt.
Wertgetriebene DWH Sanierung in der Praxis
Nachfolgend stellen wir ein durchgeführtes DWH Sanierungsprojekt bei einem international agierenden Finanzunternehmen als Anwendungsfall vor.  Das DWH bildet verschiedene Datensichten u.a. zu Kunde, Vertrag, Transaktionen und Marketingaktivitäten für mehrere Geschäftsbereiche ab. Bei der „Grundsteinlegung“ des DWH vor 14 Jahren wurden eine Hub&Spoke DWH Architektur sowie Entwicklungsrichtlinien für Datenmodellierung und ETL definiert. Aufgrund von verschiedenen Faktoren (z.B. fehlende Governance, Anforderungsstau, knappen personellen Ressourcen sowie Fluktuation) wurden die Design-Vorgaben häufig nicht eingehalten. Als Resultat stand ein historisch gewachsenes DWH System, am Rande der Wartbarkeit und Kosteneffizienz.
Als Sanierungsziele wurden festgelegt:

• Kostenreduktion Betriebskosten
• Verbesserung Umsetzungsgeschwindigkeit für neue Anforderungen (Time2Market)
• Verbesserung Ladeperformance
• Einführung Near-Realtime Datenbewirtschaftung für ausgewählte Data Marts
• Einführung eines neuen BI Werkzeugs mit spezifischen Anforderungen an dimensionale Modellierung

Ergebnisse der Ist-Analyse
Die vorgefundene DWH-Architektur bestand aus einer klassischen Stage, Core und Mart-Schicht. Die Stage-Tabellen wurden täglich per ETL-Tool mit einem Vollabzug der Quellsystemdaten in einem nächtlichen Batch-Lauf beladen. Alleine für diesen Schritt wurden mehrere Stunden Laufzeit verwendet. Als Besonderheit bestand eine lastbasierte Kostenverrechnung des ETL-Servers. Durch den Umstand, das eine erhebliche Last durch die Delta-Identifizierung erzeugt wurde, fand eine entsprechend hohe Kostenbelastung statt. Das Core-Datenmodell besitzt einen Umfang von etwa 300 historisierten Tabellen. Es stellte sich heraus: die Logik von Historisierung und Datenqualitätsbereinigung war in 95% der Fälle gleichförmig. Dieser Aspekt war eine wichtige Indikation für den Einsatz von DWH Automatisierung – wodurch sich der Parameter „Cost“ bei der Umsetzung der ersten Sanierungspakete deutlich senkte.
Das historische Wachstum des DWH zeigte sich besonders in der Mart-Schicht – eine klare Mart-Struktur war nicht ersichtlich. Abgelegt waren hier etwa 250 „Marts“, die sich als relationale Schnittstellentabellen für nachgelagerte operative, OLAP- und Data Mining Systeme herausstellten. Die Weiter-/Neuentwicklung und Wartung erfolgte im Laufe der Zeit durch unterschiedliche DWH-Backendentwickler – ein verantwortlicher BI-Architekt existierte nicht. Fachliche Stichproben ergaben: neu angeforderte Schnittstellentabellen wurden häufig per „Copy & Paste“ als modifizierte Kopie aus existierenden „Marts“ angelegt. Hierdurch wurde Logik oft redundant berechnet. Neben der den Nachteilen von „kopierter Logik“ in Bezug auf Konsistenz und Wartbarkeit wurde zudem kostenintensive Ladelaufzeit erzeugt (siehe: Verrechnungsmodell).

Während der Ist-Analyse stellte sich u.a. die folgende Frage: wie kann mit vertretbarem Aufwand bei einer Zahl von 250 „Mart“ Tabellen die redundanten Teile der Berechnungslogik identifiziert werden, um im Sinne eines Sanierungsprojekts eine Konsolidierung der Data Mart Layer herbeizuführen? Mangels Dokumentation und ausreichender Data Lineage Report-Fähigkeiten der vormals eingesetzten ETL-Technologie war dies nicht ohne erheblichen Aufwand möglich. Unterstützend zur fachlichen Analyse der Mart Tabellen wurde auf technischem Wege ein „archäologisches“ Verfahren aufgebaut. Auf Basis von Metadaten-Extrakten aus dem ETL-Werkzeug wurden die Zuordnungen zwischen Quell und Zieltabellen in ETL-Jobs anhand einer „Heatmap“ sichtbar gemacht. Hierdurch konnte grafisch abgeleitet werden, welche Quelltabellen besonders häufig in kombinierter Form in mehreren Jobs verwendet werden. „Heiße“ Anwärter für eine Zentralisierung von Logik konnten so identifiziert werden (siehe unten: Distribution-Area).  Weiterhin konnten mit diesem Input logisch zusammenhängende „Mart“-Tabellen identifiziert werden – und damit eine „wertstiftende“ Bündelung für den Schnitt von Sanierungspaketen im Sinne der o.g. Cost/Value Metrik (s.u. „Sanierungspakete“).
Lösungsarchitektur
Aus der Ist-Analyse wurden verschiedene Lösungsmaßnahmen abgeleitet, die sich in Abb. 3 als Lösungsarchitektur darstellen.

Einführung einer Distribution Area (DA)

• • Eine der „Mart“ Schicht vorgelagerte Distribution Area dient zur zentralisierten Ablage von fachlicher Logik (angelehnt: Business Vault)
  • Wiederverwendung der zentralisierten Logik in zahlreichen nachgelagerten Data Marts (virtualisiert / per ELT befüllt)
  • Damit verbunden: Re-Engineering und Komplexitätsreduktion der vorgefundenen Data Mart Schicht
  • Erhöhung Wartbarkeit -> Senkung Betriebskosten

• DWH Automatisierung
  • Metadatengestützte Erzeugung von Replikations- und ELT-Strecken, Erzeugung Datenmodell (Staging und Core Layer)
  • Einsatz eines DWH Automatisierungs-Frameworks
  • Erhöhung Flexibilität und Umsetzungsgeschwindigkeit

• Umstellung des ETL-Tools auf eine ELT Technologie
  • Ausnutzen der vorhandenen Enterprise DWH Technologie durch datenbankbasierte Datenbewirtschaftung (ELT)
  • Erhebliche Performanceverbesserung durch Vermeidung Unload/Load
  • Senkung Betriebskosten

• Einführung eines Werkzeugs zur Datenbankreplikation zwecks Near-Realtime Transport der Quellsystemänderungen in die Stage-Schicht

Sanierungspakete
Mit den Ergebnissen aus Ist-Analyse und Lösungsdesign wurden verschiedene „Schnittvarianten“ für die Sanierungspakete hinsichtlich von Cost/Value bewertet. Im Sinne eines inkrementellen Vorgehens, wurden zunächst die ersten 5 Pakete definiert – die darauf folgenden Pakete wurden im weiteren Projektverlauf festgelegt. Die folgende Tabelle zeigt die Einteilung der Sanierungspakete:

Die Sanierungspakete 1 und 2 sind als „technologische Basispakete“ zu betrachten, die eine hohe respektive gute Wertstiftung erzielen. Eine feinere Unterteilung ist aus technischer Sicht nicht sinnvoll – insbesondere um einen Technologie- bzw. Architekturmix zu vermeiden. Da im Sinne eines DWH-Schichtenmodells (siehe Abb. 3) das Datenmodell der Core Layer beibehalten werden konnte, ergaben sich keine direkten Abhängigkeiten bei der Bearbeitung der nachgelagerten Pakete (Aufbau von Distribution Areas bzw. dem Re-Engineering von Data Marts).
Der Schnitt der Sanierungspakete konnte bei der Konsolidierung der Data Mart Layer mit hohem Freiheitsgrad durchgeführt werden. Die Konsolidierung erfolgte in 5 weitgehend unabhängigen „Streams“, entlang der 5 fachlichen Domänen und damit der fachlichen Nutzerkreise des DWH. Die Sanierungsarbeit wurde zunächst mit denjenigen 2 Domänen gestartet, die ein besonders positives cost/value Verhältnis aufweisen („Partner“ – 35 Data Marts und „Kampagnen“ – 56 Data Marts). Innerhalb dieser „Streams“ wurden wiederum einzelne Data Mart Bündel wiederum gemäß obiger cost/value Metrik gebildet und wertgetrieben in Reihenfolge gebracht (Siehe Abb. 4). Ziel war es, das Re-Engineering jedes Data Mart Bündels innerhalb von <= 4 Wochen bewerkstelligen zu können – um eine Produktivstellung im 4wöchigen Intervall zu ermöglichen. Größere Bündel wurden entsprechend geteilt (siehe Abb. 4). Die Weiterentwicklung der jeweils zugehörigen Distribution Area (DA) geschah inkrementell – mit direktem Feedback durch die Bearbeitung der Data Mart Bündel. Weitere Synergien ergaben sich an vielen Stellen beim Aubau von Distribution Areas durch eine „vorausschauende“ Arbeitsweise, beispielsweise bei der Implementierung von zusätzlichen KPIs in zentralen DA-Objekten – die erst in folgenden (fest geplanten) Data Mart Bündel relevant waren. So ließ sich eine effizientere Arbeitsweise realisieren. Diese Synergien wurden durch die o.g. „Heatmap „(Abb. 2) ermöglicht – die Metrik „Wiederverwendung“ wurde hierdurch abgeleitet.

Learnings
Der Einsatz von DWH Automatisierung hat einen positiven Business Case zur Umsetzung der Sanierungsziele erst ermöglich. Als erstes Ziel für das Sanierungsprojekt stand lediglich der Aspekt „Kostensenkung“ und „Einführung Near-Realtime“ Bewirtschaftung. Auf Basis einer manuell umgesetzten Sanierung wäre ein Budget für die weiteren Sanierungsziele nicht realistisch gewesen.
Als weiteres Learning: während der Konsolidierung der Data Mart Layer wurden einige Inkonsistenzen bei der technischen Umsetzung von fachlichen Anforderungen aufgedeckt. Eine Ist-Analyse hilft dabei den Status Quo noch einmal zu beleuchten.
Fazit
Ein cost/value getriebenes Vorgehen hat sich als tauglich für die Praxis erwiesen. Insbesondere in Situationen, in denen ein „Greenfield“ Ansatz z.B. aus strategischen Gründen für eine Modernisierung nicht in Frage kommt, lassen sich auch bei schwer überschaubaren „Altbestand“ unter Berücksichtigung von Zeit und Budget entsprechend messbare Verbesserungen darstellen. Häufig bestehen Sanierungsvorhaben in der Praxis lediglich aus technischen Änderungen (z.B. Hardwaretausch, Einbeziehung In-Memory Technologie, o.ä.). Der vorgestellte Ansatz bietet einen Mehrwert insbesondere dann, wenn darüber hinaus auch Konsolidierungen bzgl. der „Business Layer“, z.B. fachlicher Datenmodelle, Data Marts auf dem Sanierungsplan stehen.
Die Erfahrung zeigt: wertgetriebenes Vorgehen schafft Vertrauen bei Sponsoren und DWH Anwendern. Vorbehalte werden aufgelöst, da die Prioritäten der Sanierungspakete nicht starr sind, sondern in Zyklen neu bewertet werden. Erkenntnisgewinne aus Produktivnahmen fließen in die Neubewertung mit ein. So wird verhindert, dass Sanierungspakete, die sich plötzlich als unwichtig herausstellen, eine hohe Priorität behalten und „blind“ umgesetzt werden, obwohl kein ausreichender Nutzen mehr besteht. Ein wertgetriebenes Vorgehen erfordert jedoch viel Erfahrung: Lösungsarchitektur, Qualität und Prozesse müssen einen Schnitt von wertgenerierenden Sanierungspakete überhaupt erst ermöglichen.
Dieser Artikel wurde gemeinsam mit Lutz Bauer geschrieben.
Literatur[Die16]  Diekmann, Jens; Besbak, Ursula: Quo Vadis, Data Warehouse? Sanierung statt Neubau als Weg in die Zukunft, in: BI-Spektrum, 11. Jg., Nr. 1, 2016, S. 30 – 33[Pur16] Purwins, Erik; Zeiler, Gregor: DWH Modernisierung – Auslöser, Stoßrichtungen und Potenziale, Vortrag auf der TDWI Jahrestagung, München, 22. Juni 2016