Wenn eine Anwendung in die Jahre gekommen ist, lautet die schnellste Antwort oft: alles neu. Sie klingt entschlossen und verspricht einen sauberen Neuanfang. In der Praxis ist sie selten die beste. Die Frage ist nicht, ob die Technik veraltet ist, sondern welcher Weg das Geschäft mit dem geringsten Risiko weiterbringt.
Welche Optionen gibt es?
| Option | Wann sinnvoll | Risiko | Aufwand | Nutzen ab |
|---|---|---|---|---|
| Weiterbetreiben und absichern | Die Anwendung erfüllt ihren Zweck, es gibt wenige Änderungen | niedrig | niedrig | sofort |
| Schrittweise modernisieren | Die Anwendung wird weiterentwickelt, die Technik ist veraltet | niedrig bis mittel | mittel, verteilt | jeder Etappe |
| Teile ersetzen | Einzelne Bereiche tragen nicht mehr, der Rest schon | mittel | mittel | jedem ersetzten Teil |
| Neu bauen | Prozesse haben sich grundlegend geändert, die Technik ist nicht mehr betreibbar | hoch | hoch | dem Umstieg |
Die ersten drei Optionen lassen sich kombinieren: zuerst absichern, dann modernisieren, einzelne Teile ersetzen. Der Neubau ist die einzige Option, bei der der Nutzen erst am Ende kommt.
Warum Neubauten so oft länger dauern als geplant
Joel Spolsky hat den kompletten Neubau schon im Jahr 2000 als einen der schlimmsten strategischen Fehler eines Softwareunternehmens bezeichnet. Sein Argument gilt bis heute: Alter Code sieht chaotisch aus, weil er Jahre an Fehlerkorrekturen und Sonderfällen enthält. Wer neu baut, wirft dieses Wissen weg und muss es mühsam wieder erarbeiten. Dazu kommt der sogenannte Second-System-Effekt, den Fred Brooks beschrieben hat: Ein Nachfolgesystem wird gern mit allen Ideen überladen, die beim ersten Mal keinen Platz hatten.
Das Strangler-Fig-Prinzip
Martin Fowler beschreibt mit der Strangler Fig Application einen Mittelweg: Das neue System wächst schrittweise um das alte herum. Funktion für Funktion wird neu gebaut und umgeleitet, bis das alte System abgeschaltet werden kann. Der Vorteil: Jede Etappe bringt sofort Nutzen, das Risiko bleibt klein, und die Firma kann jederzeit anhalten, wenn der Rest gut genug ist.
Sieben Fragen für die Entscheidung
- Erfüllt die Anwendung ihren fachlichen Zweck noch?
- Läuft sie auf unterstützten Versionen, oder lässt sie sich dorthin bringen?
- Wie oft muss sie geändert oder erweitert werden?
- Wie viel Wissen steckt im Code, das nirgends sonst festgehalten ist?
- Gibt es Tests, die Änderungen absichern?
- Was kostet ein Ausfall pro Tag?
- Wer betreut die Anwendung danach, egal welcher Weg gewählt wird?
Typische Fehler
- Neu bauen, weil der Code unschön ist. Unschöner Code ist kein Geschäftsrisiko, unbekannter Code schon.
- Neubau ohne Parallelbetrieb. Ein Big-Bang-Umstieg an einem Stichtag verlagert alle Risiken auf einen einzigen Tag.
- Anforderungen aus dem alten System vergessen. Die Sonderfälle, die niemand aufgeschrieben hat, fallen erst nach dem Go-live auf.
- Die Analyse vom Anbieter des Neubaus machen lassen. Wer am Neubau verdient, empfiehlt selten etwas anderes.
Wie finde ich heraus, welcher Weg passt?
Eine belastbare Entscheidung braucht eine Bestandsaufnahme: Technik, Risiken, Abhängigkeiten, Betrieb. Das Übernahme-Assessment liefert sie zum Fixpreis, mit einer Empfehlung für einen der vier Wege. Der Grundsatz dabei: Stabilisieren vor Neubau. Welcher Weg der richtige ist, entscheidet die Analyse, nicht mein Umsatz.
Quellen
- [1]Strangler Fig Application · Martin Fowler
- [2]Things You Should Never Do, Part I · Joel Spolsky, 2000
- [3]Second-system effect · Wikipedia