Quick Wins oder was Sie in einem DWH Projekt vermeiden sollten

Stellen Sie sich vor, Sie möchten ein Haus bauen. Wie würden Sie vorgehen? Vermutlich bauen Sie nicht für sich alleine, sondern werden das Haus zusammen mit Ihrer Familie bewohnen. Sie fragen die Familienmitglieder, was ihnen im neuen Haus wichtig ist, was sie möchten, was sie brauchen. Sie treffen nicht sofort und alleine eine Entscheidung, Sie diskutieren und suchen nach der optimalen Lösung. Das kostet Zeit und ist nicht immer einfach, aber Sie tun es. Warum? Weil Sie sonst eine unzufriedene Frau und nörgelnde Kinder in Ihrem neuen Haus haben werden, die im schlimmsten Fall gar nicht darin wohnen möchten.
Jetzt haben Sie einen Plan und beauftragen eine Baufirma, die Ihr Vorhaben umsetzen soll. Sie achten darauf, dass qualitativ hochwertig gearbeitet wird, auch wenn es mehr Zeit kostet. Sie sind vorausschauend, über alles muss nachgedacht werden – Sie wollen doch in ein paar Jahren nicht wieder alles neu machen! So ein Haus kostet immerhin viel Geld: 300 Tausend? 500 Tausend? Sie vertrauen dem Bauleiter, dass bestimmte Arbeiten durchgeführt werden müssen, auch wenn Sie dabei keinen sichtbaren Mehrwert erkennen. Und Sie lassen jeden Schritt dokumentieren, damit Sie später leichter ausbauen können. Klingt das logisch?
Was hat dies mit einem Data Warehouse zu tun?
Passen Sie auf! Ersetzen Sie das Wort „Haus“ durch „Data Warehouse“, „Familie“ durch „Fachanwender“ und „Baufirma“ durch „IT Dienstleister“. Und erhöhen Sie den Preis um Faktor 10. Sollte sich nichts ändern, oder? Wenn Sie den oberen Text jetzt noch einmal lesen, werden Sie erkennen, dass dies Prinzipien für jedes gute Data Warehouse sind: Homogenität, Qualität, Nachhaltigkeit, Wartbarkeit, Dokumentation… Die Erfahrung zeigt aber, dass es in der Realität meistens ganz anders aussieht. Kann nicht so schlimm sein? Hier kommen fünf extreme Beispiele aus echten Kundenprojekten, die ich persönlich miterlebt habe.
Konventionen kosten doch nur Zeit und Nerv
Selten habe ich erlebt, dass neue Projekte mit dem Aufsetzen von Regeln und Vorgehensmethoden beginnen. Und noch seltener, dass diese (wie z.B. Entwicklungsrichtlinien und Namenskonventionen) auch im weiteren Verlauf des Projekts kontrolliert und eingehalten werden. Ist auch nicht einfach – Geschmäcker sind bekanntlich verschieden. Jeder neue Entwickler bringt frischen Wind rein und weiß es sowieso besser. Und wer macht schon heutzutage ein Projekt von Anfang bis Ende mit? Nach mir die Sintflut – ich mache es, wie ich es gewohnt bin! Und dann kommt natürlich die Frage aller Fragen: Was bringt das überhaupt? Die Erklärungen überzeugen meistens nicht. Ich kann Ihnen aber sagen was passiert, wenn Sie es nicht tun. Nach 3 Jahren Freiheit ohne Regeln ist Ihr System nicht mehr wartbar, da keiner mehr den Durchblick hat. Es ist unmöglich für neue Kollegen sich einzuarbeiten oder Erweiterungen zu implementieren. Und dann bleibt nur eins: Neuentwicklung. Kein schönes Gefühl, die Arbeit von drei Jahren wegzuwerfen, oder?
Hauptsache schnell
Ich kam ins Projekt bei einem Energiekonzern. Meine Aufgabe war, das alte zentrale System nach und nach abzuschalten bzw. zur Ablösung vorzubereiten, da es durch ein neues Data Warehouse ersetzt werden sollte. Zu diesem Zeitpunkt lief das Data Warehouse Projekt bereits seit fast zwei Jahren. Von Anfang an sollte es schnell gehen! Aus den ersten Vorschlägen wurde direkt die günstigste Lösung ausgewählt, die dann auch umgesetzt werden sollte. Das Team hatte keine Zeit bekommen Alternativen zu eruieren. Man startete mit einem Quellsystem. Es wurde auch nicht darüber nachgedacht, welche weiteren Systeme zukünftig an das neue Data Warehouse angebunden werden könnten. Ergebnis? Kurz nachdem ich angefangen habe wurde das Projekt erstmalig gestoppt und das gesamte Team komplett ausgetauscht. Es kamen neue Leute rein, neues Geld wurde investiert. Die Aufgabe war, das bereits geleistete zu retten bzw. neuen Gegebenheiten anzupassen. Das alte Team war schuld! Nach einem weiteren Jahr war endlich allen klar: es ist nicht zu retten. Nach insgesamt drei Jahren wurde das Projekt für gescheitert erklärt. Schnell ist eben nicht immer gut!
Über Performance denken wir später nach
Es war ein Unternehmen aus dem Bereich Forderungsmanagement. Ich wurde hinzugezogen, um die Performance der Ladeläufe im Data Warehouse zu verbessern. Die nächtliche Verarbeitung dauerte damals 13 Stunden. Warum? Weil es am Anfang natürlich darum ging, erstmal Daten zu bewegen. Es war ja auch nur eine Quelle, die Anforderungen waren übersichtlich, Designüberlegungen in Richtung Performance erschienen damals nicht notwendig. Vielleicht wird es ja auch so reichen. Und wenn nicht, kann man später immer noch Verbesserungen implementieren. Richtig, kann man: es waren 5 Monate nötig, um die Laufzeit von 13 auf 7 Stunden zu reduzieren, weitere Maßnahmen ausstehend. Man hätte aber insgesamt viel Zeit und Kosten sparen können, wenn man über Skalierbarkeit des Systems direkt am Anfang nachgedacht hätte. Prävention ist bekanntlich besser als Reaktion!
Logging – was ist das?
Wieviele Entwickler kennen Sie, die gerne in jede Funktion die Logging Routinen einbauen? Für die meisten ist es das notwendige Übel, aber man sieht nicht wirklich einen Sinn dahinter. Da schaut doch eher keiner rein, die Tabellen werden nur vollgeschrieben. Und ja, es gibt viel wichtigere Aufgaben. Nun, ich war im Projekt bei einer Bank. Als ich mal morgens zur Arbeit kam, stand die produktive Datenbank still. Keiner konnte sich anmelden, das System war überlastet. Als die DBAs endlich in das System schauen konnten, haben sie festgestellt, dass unwarscheinlich viele Aufräumjobs aktiv waren (wie z.B. Verschieben oder Löschen alter Partitionen), aber sie hatten keine Idee wo diese herkamen. Die Rettung war das gute Gedächtnis eines Kollegen, der sich dunkel an einen Logon-Trigger erinnern konnte, der solche Jobs früher initiiert hat. Der Trigger war aber schon seit längerer Zeit inaktiv. Durch ein fehlerhaftes Release wurde dieser aber tatsächlich reaktiviert. Bei einem existierendem Logging hätte man nur in die Tabelle schauen müssen und wüsste sofort die Quelle des Problems. Hier war es aber eher ein glücklicher Zufall, dass das Problem am gleichen Tag noch gefunden werden konnte. Die Aufgaben müssen leider erledigt werden, auch wenn sie keinen Spaß machen!
Wie lange kann Dokumentation schon brauchen?
Haben Sie schon mal einen Projektleiter oder Projektsponsor gesehen, der die Notwendigkeit der umfangreichen Dokumentation gesehen hat bzw. die Aufwände von sich aus bezahlen wollte? Ja, Dokumentation bräuchte man schon, aber wir haben dafür kein Budget. Außerdem, man kann doch immer die Kollegen fragen. Und seien wir mal ehrlich, wird sie je einer lesen? Diesmal geht es um ein Handelskonzern. Der externe Hostbetreiber, der für die gesamte Steuerung der Warenwirtschaft und Datenbelieferung der Filialen zuständig war, war ein älterer Mann in einem Ein-Mann-Betrieb. Und eines Tages hat er einen Herzinfarkt erlitten. Es gab keine Dokumentation, eine schnelle Einarbeitung einer Ersatzperson war nicht möglich. Man konnte nichts tun und das eine Woche lang, bis es ihm zum Glück wieder einigermaßen besser ging. Spielen Sie nicht auf Risiko! Zumindest nicht in der Arbeit.
Viele von Ihnen werden die Situationen erkannt haben, jeder von uns hat so etwas bereits erlebt. Warum wiederholen wir dann immer wieder die gleichen Fehler? Lassen sie sich auch vermeiden? Kann man was tun, damit die Probleme gar nicht erst auftreten? Einsicht ist der erste Schritt zur Besserung… Ein möglicher Weg ist Data Warehouse Automatisierung bzw. Industrialisierung. Dazu mehr in meinen anderen Blog-Artikeln.