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