Der Standard-Reflex ist der falsche
Wenn ein Altsystem zur Last wird, ist der erste Impuls oft: alles neu bauen und an einem Stichtag komplett umschalten. Das klingt sauber, planbar, nach einem klaren Schnitt. In der Praxis ist es der riskanteste Weg, ein Legacy-System abzulösen, weil an einem einzigen Tag alles gleichzeitig funktionieren muss: die Datenmigration, die neue Logik, alle Schnittstellen, jede Rolle, die im Altsystem irgendwann mal gebraucht wurde. Wenn an diesem Tag etwas nicht passt, steht der komplette Betrieb still, nicht nur ein Teil davon.
Woran man ein Big-Bang-Risiko erkennt
Die Systeme, bei denen dieses Risiko am größten ist, zeigen fast immer dieselben drei Symptome. Jede Änderung braucht Wochen, weil niemand mehr genau versteht, wie die Teile zusammenhängen. Die Software läuft auf alternder Technologie, für die kaum noch Entwickler zu finden sind. Und ein einzelnes Release dauert zwei Tage und bindet drei Leute, weil es keine verlässliche Deployment-Pipeline gibt. Das System läuft noch, aber es lässt sich nicht mehr bewegen. Genau das macht ein Big-Bang-Vorhaben auf einem solchen System besonders gefährlich: Man verspricht sich einen sauberen Neustart von einem System, dessen tatsächliches Verhalten man selbst nicht mehr vollständig überblickt.
Was Abschnitt für Abschnitt tatsächlich bedeutet
Der Gegenentwurf ist, die Modernisierung in Abschnitte zu zerlegen, die jeweils einzeln ausgeliefert werden können, statt in ein einziges großes Projekt. So gehen wir dabei vor.
Zuerst die Bestandsaufnahme: Wir verstehen, was das bestehende System heute tatsächlich leistet, auch die Teile, die nirgendwo dokumentiert sind. Bei gewachsenen Systemen ist unvollständige oder veraltete Dokumentation der Normalfall, nicht die Ausnahme. Ein Teil unserer Arbeit besteht darin, das tatsächliche Verhalten zu rekonstruieren, nicht nur vorhandene Dokumente zu lesen.
Danach der Schnitt: Wir zerlegen die Modernisierung in Abschnitte, die einzeln ausgeliefert werden können. Wie dieser Schnitt verläuft, ist Teil eines Architektur-Reviews davor. Jeder Systemteil wird einzeln bewertet, nicht pauschal alles über einen Kamm geschert.
Dann der Umbau: Wir bauen Abschnitt für Abschnitt um und stellen dabei sicher, dass Alt- und Neusystem parallel funktionieren. Der Betrieb läuft während dieser Phase durchgehend weiter, weil zu jedem Zeitpunkt ein vollständig funktionierendes System vorhanden ist, egal ob alt, neu oder eine Mischung aus beidem.
Erst am Ende die Ablösung: Wir schalten das Altsystem ab, sobald das neue System den vollen Betrieb zuverlässig trägt. Nicht an einem festen Stichtag, sondern wenn der Beweis erbracht ist, dass es trägt.
Warum das mehr Disziplin braucht, nicht weniger
Ein Missverständnis bei diesem Vorgehen ist, dass es der bequemere Weg sei, weil er weniger dramatisch klingt als ein Big Bang. Das Gegenteil ist der Fall. Alt- und Neusystem parallel zu betreiben bedeutet, dass für eine Weile zwei Systeme gepflegt, überwacht und synchron gehalten werden müssen, statt nur eines. Das braucht mehr Disziplin bei der Planung jedes einzelnen Abschnitts, nicht weniger. Der Unterschied ist, dass ein Fehler in einem Abschnitt nur diesen Abschnitt betrifft, nicht das gesamte Vorhaben, und dass sich jeder Abschnitt einzeln zurückdrehen lässt, wenn er sich in der Praxis anders verhält als erwartet.
Warum der Betrieb nicht stillstehen muss
Der eigentliche Vorteil dieses Vorgehens ist nicht nur, dass es weniger riskant ist. Es ist, dass der Betrieb während der gesamten Modernisierung normal weiterläuft. Alt- und Neusystem laufen parallel, bis die Ablösung sicher ist, statt dass ein einziger Umschalttermin über Erfolg oder Ausfall entscheidet. Wenn ein Abschnitt sich in der Praxis anders verhält als erwartet, lässt sich das an dieser Stelle korrigieren, statt das gesamte Vorhaben zu gefährden.
Was am Ende steht
Am Ende läuft dein Geschäft auf einem System, das dein Team wieder verändern kann, ohne dass jede Änderung Wochen dauert oder eine einzelne Person zwingend gebraucht wird. Das Altsystem ist abgeschaltet, ohne dass der Betrieb dafür jemals stillstand.
Wenn bei euch eine der drei Symptome von oben zutrifft, vor allem, wenn niemand mehr erklären kann, warum bestimmte Entscheidungen im System damals getroffen wurden, ist der erste sinnvolle Schritt nicht der Big Bang, sondern eine Modernisierung, die zeigt, wie sich euer System tatsächlich in Abschnitte zerlegen lässt.