Big Bang-Releases
 |
| Bild: Pexels / Rawpixel - Lizenz |
Ferndiagnosen sind in derartigen Situationen immer schwierig, aber die Recherchen der FAZ und der Wirtschaftswoche zeichnen ein eindeutiges Bild: nachdem Liqui Moly jahrzehntelang auf eine immer weniger zeitgemässe und immer stärker veraltende Software gesetzt hatte sollte die letzten Endes abgelöst werden. Der angedachte Ersatz war eine Standardsoftware, die im so genannten "Big Bang-Verfahren" eingeführt werden sollte. Big Bang bedeutet, dass von jetzt auf gleich "mit einem Schlag" von der alten auf die neue Software umgeschaltet wird. Und den Big Bang gab es, siehe oben.
Derartig fehlgeschlagene "Auf einen Schlag-Einführungen" sind kein Einzelfall, erst diesen Frühling gab es einen ähnlichen Fall bei Hertz, letztes Jahr bei Lidl, je weiter man sucht desto mehr werden es. Hinter diesen wiederkehrenden Geschichten verbergen sich erfahrungsgemäss ähnliche Ursachen, die sich in vielen (wahrscheinlich fast allen) Big Bang-Vorhaben wiederfinden lassen. Wegen ihnen ist ein solches Vorgehen mit grösster Vorsicht zu betrachten.
Zunächst sind die meisten älteren Grossanwendungen über die Jahre "kaputtentwickelt" worden. Um die Investitionen klein zu halten werden neue Funktionen irgendwo an bestehende angedockt, selbst wenn dadurch die internen Abläufe so verkompliziert werden, dass sie kaum noch nachvollziehbar sind. Mit der fehlenden Nachvollziehbarkeit wird dann die Dokumentation widersprüchlich, das Wissen wie alles funktioniert besteht irgendwann nur noch in den Köpfen der älteren Mitarbeiter (laut FAZ hielt bei Liqui Moly nur noch ein Entwickler das Altsystem am Laufen).
Für die Ablösungs-Vorhaben bedeutet dass, das in solchen Fällen gar nicht mehr klar ist was da abgelöst werden soll. Die Anforderungen an das Neusystem beruhen auf veralteten und unvollständigen Informationen, schlimmstenfalls auf Vermutungen. Die Folge - selbst wenn das neue System genau so funktioniert wie es konzipiert wurde wird es trotzdem nicht das können was eigentlich notwendig wäre. Eine "kaputtenwickelte" Software wird dann durch eine ersetzt die "kaputt entwickelt" wurde.
Es wird noch schlimmer. Eine weitere Fehlerquelle entsteht dort, wo es sich bei der neuen Anwendung um Standard-Software handelt. Anders als es der Name vermuten lässt ist das keineswegs ein Standard der überall funktioniert. Um mit den Schnittstellen und Prozessen des neuen Einsatzgebietes kompatibel zu sein sind in der Regel umfangreiche Anpassungen nötig. Finden diese unter Zeit- und Kostendruck statt (wo ist das nicht so?) kommt es auch hier zu den sprichwörtlichen "quick and dirty"-Lösungen.
Selbst das ist aber noch nicht alles. Alle gerade genannten Probleme lassen sich nämlich erst dann feststellen wenn es zu spät ist. Genau das ist das grosse Risiko eines Big Bang-Releases: wenn alles erst ganz zum Schluss gleichzeitig auf Produktion geschoben wird, dann ist der früheste Zeitpunkt an dem Realitätskontakt stattfindet und sich Fehlkonzeptionen und -funktionen feststellen lassen genau dann - ganz zum Schluss, wenn alles Live geschaltet ist und alle Mitarbeiter und Kunden bereits betroffen sind.
Wie es besser gehen könnte? Durch einen mehrstufigen Prozess1. Zuerst sollte durch Reverse Engineering herausgefunden werden was die alte Anwendung wirklich tut. Als nächstes sollte versucht werden einen ihrer Teile so zu modifizieren, dass er nur noch durch fest definierte Schnittstellen mit dem restlichen System kommuniziert. Dieser Teil kann dann separat ersetzt werden, mit deutlich überschaubareren Konsequenzen wenn hier etwas schiefläuft. Danach kann das Selbe mit dem nächsten Teil passieren, dem übernächsten, etc.
Häufige Einwände an dieser Stelle sind, dass das doch eine Eigen-Entwicklung von Software wäre. Das wäre doch viel teurer als sich fertige Software zu kaufen. Es wäre interessant zu hören was die Leute von Liqui Moly heute darauf antworten würden.
1Alle Wasserfall-Witze bitte jetzt
