The Doppler Quarterly (DEUTSCHE) Frühjahr 2017 | Page 24

tem in Frage zu stellen, das zu einem unzähmbaren Kraken geworden ist.
Unserer Erfahrung nach kommt es nicht oft vor, dass die Modernisierung des
Data Warehouse ohne eine entscheidende Zäsur vorangetrieben wird. Dies
kann z. B. die Verlängerung/Anpassung einer Unternehmenslizenz oder das
anstehende Lebensende einer zentralen Technologie sein. In diesen Situatio-
nen ist es nicht allzu schwer, überzeugende Argumente vorzubringen. Eine
ROI-Analyse zeigt häufig, dass sich die Gesamtbetriebskosten (TCO) durch
jährliche Kosteneinsparungen in Millionenhöhe möglicherweise erheblich
senken ließen.
Starke Verankerung
Die vielen großen Teams und hoch qualifizierten Mitarbeiter, die sich um das
krakenartige Data Warehouse kümmern, haben kein echtes Interesse daran,
unbekanntes Terrain zu betreten. Dem obersten und mittleren Management
ist unwohl dabei, ein enormes Unterfangen namens „Data-Warehouse-Moder-
nisierung“ in die Wege zu leiten. Ohne sorgfältige Aufklärungsarbeit, Sensibi-
lisierung und Change Management wird es schwierig sein, diesen Widerstand
im Unternehmen zu überwinden.
Angst vor Unterbrechungen
Seit Jahren haben sich die Arme des krakenartigen Data Warehouse selbst in
die entferntesten Ecken des Unternehmens ausgestreckt. Wichtige Prozesse
wie die arbeitsintensive, mehrwöchige Erstellung von Finanzberichten wurden
rund um die Einschränkungen des Data Warehouse aufgebaut. Ohne eine klare
Strategie bekommen selbst die erfahrensten IT-Leiter weiche Knie, wenn sie
vor diesem Hintergrund auch nur an mögliche Veränderungen und die damit
verbundenen Unterbrechungen denken.
Unternehmen, die sich mit uns auf diesen Weg gemacht haben, nehmen sich
erst einmal Zeit für strategische Überlegungen und investieren dann in eine
sorgfältige Roadmap, die potenzielle Herausforderungen und die Möglichkei-
ten zur Risikominimierung umfasst.
Argumente für die Modernisierung: ein Blick über den
Tellerrand hinaus
Gerry Fierling, ein Kollege aus meiner Zeit als Microsoft Senior Product Mana-
ger for Business Intelligence, hatte die Gabe, eine komplexe Situation mit einem
einzigen Satz kurz und prägnant zu beschreiben. Er sagte immer:
„Der Hauptgrund für das
Scheitern eines Data Warehouse ist sein Erfolg.“
Was Gerry damit ausdrücken wollte: Je mehr Menschen die Berichte und Feeds
des Data Warehouse nutzen, desto mehr steigt die Notwendigkeit der innova-
tiven Nutzung. Viele dieser neuen Notwendigkeiten lassen sich durch unseren
unzähmbaren alten Kraken nicht mehr unterstützen, da es fast ein Ding der
Unmöglichkeit ist, ein Data Warehouse zu entwerfen, das alle möglichen
Zugriffsmuster der Zukunft vorhersieht. In dem Moment, in dem Sie sich einer
Struktur – konkret: einem relationalen Datenmodell – verschreiben, haben Sie
schon die Saat für zukünftige Unzufriedenheit der Benutzer ausgelegt. Deren
Anforderungen lassen sich nicht mehr erfüllen, ohne die Lösung an verschie-
denen Ecken und Enden auszubessern.
„Schema-on-Read“ statt „Schema-on-Write“
Das Konzept „Schema-on-Write“ bedeutet, sich vorab einer Struktur für die
Datenspeicherung zu verschreiben. Es ist damit beschränkt auf eine Reihe von
22 | THE DOPPLER | FRÜHJAHR 2017