DeusterDevelopment
← Zurück zur Übersicht

Der Strangler Fig und andere ehrliche Strategien (6/8)

Inkrementelle Ablösemuster — Strangler Fig, Anti-Corruption Layer, Parallel Run, Branch by Abstraction — funktionieren, weil jeder Zwischenschritt produktionsfähig bleibt und das Risiko pro Schritt begrenzt ist. Auf Folien wirken sie ineffizient, in der Realität sind sie die einzigen Varianten, die zuverlässig ankommen. Disziplin, nicht Geschwindigkeit, ist das knappe Gut.

Der Strangler Fig und andere ehrliche Strategien (6/8)

Einleitung

Martin Fowler schrieb 2004 einen kurzen Text: „StranglerFigApplication”.

Der Name stammt von einer Pflanze.

Sie legt sich um einen bestehenden Baum und ersetzt ihn über Jahre,

bis am Ende nur noch sie übrig ist.

Der Text beschreibt eine Methode, wie man ein altes System ablöst,

ohne es am Stück zu kippen.

Die Methode ist langweilig.

Das ist ihre wichtigste Eigenschaft.


Die Methode

Sie geht in etwa so:

  1. Man legt eine Fassade vor das alte System.
  2. Alle Clients sprechen ab jetzt mit der Fassade, nicht mehr direkt mit dem System.
  3. Zunächst leitet die Fassade einfach weiter — nichts ändert sich.
  4. Dann beginnt man, einzelne Funktionen in einem neuen System zu implementieren.
  5. Die Fassade entscheidet pro Request, welches System antwortet.
  6. Über Monate oder Jahre wandert Funktion nach Funktion ins neue System.
  7. Irgendwann sagt das alte nichts mehr.

Das ist nicht spektakulär.

Es lässt sich nicht in einem Launch-Event verkaufen.

Es hat keinen Tag X.

Genau das ist der Grund, warum es funktioniert.


Folien vs. Realität

In Folien wirken inkrementelle Strategien ineffizient.

„Wir ersetzen das System in zwölf Phasen über 36 Monate.”

klingt nach Bürokratie.

„Wir schreiben alles neu und schalten in Q4 um.”

klingt nach Aufbruch.

Das Problem ist:

Aufbruch lässt sich auf Folien verkaufen.

Inkrementalität lässt sich nur in der Realität liefern.


Weitere Muster

Anti-Corruption Layer

Eine Schicht zwischen altem und neuem Domänenmodell, die übersetzt.

Damit das neue System nicht die Konzepte des alten in sich zieht.

Parallel Run

Beide Systeme laufen eine Zeit lang in Produktion.

Man vergleicht die Ausgaben.

Unterschiede werden untersucht, bevor umgeschaltet wird.

Branch by Abstraction

Eine Abstraktionsschicht wird eingezogen, hinter der die alte Implementierung weiterläuft.

Eine neue Implementierung entsteht daneben, per Feature-Flag zuschaltbar.

Die Umschaltung ist ein Konfigurationseintrag — kein Release.


Die gemeinsame Eigenschaft

Jedes dieser Muster hat dasselbe Profil:

  • jeder Zwischenschritt ist produktionsfähig
  • an jeder Stelle kann man anhalten, das System läuft trotzdem
  • das Risiko ist pro Schritt begrenzt, nicht über die gesamte Projektlaufzeit aufgetürmt

Rechnet man so, ist der Strangler Fig nicht langsam.

Er ist die einzige Variante, die zuverlässig ankommt.


Warum es so selten gemacht wird

Diese Muster verlangen Disziplin.

Zwei Implementierungen parallel pflegen. Manchmal monate-, manchmal jahrelang.

Code schreiben, der irgendwann weggeworfen wird — die Fassade, der Anti-Corruption Layer, die Abstraktion.

Das fühlt sich ineffizient an.

Es ist lokal ineffizient.

Global ist es überlegen.

Denn der Vergleich lautet nicht:

„inkrementelle Strategie vs. keine Strategie”.

Er lautet:

„inkrementelle Strategie vs. gescheiterter Rewrite”.


Die ehrliche Kehrseite

Diese Strategien können festfahren.

Ich habe Projekte gesehen, in denen der Zwischenzustand so lange bestand,

dass er selbst zum Legacy wurde.

Das passiert, wenn die Migration ihr Momentum verliert

und das Team sich an den Zwischenzustand gewöhnt.

Der Ausweg ist nicht, zum Big-Bang-Rewrite zurückzukehren.

Der Ausweg ist eine explizite Vereinbarung:

wann welcher Teil migriert wird — und die Disziplin, sie einzuhalten.


Zentrale Beobachtung

Disziplin, nicht Geschwindigkeit, ist das knappe Gut.

Wer einen großen Rewrite leitet, wird sichtbar.

Wer eine zwölfphasige Migration über drei Jahre durchführt, wird es nicht.

Das ist unfair.

Und es ist einer der Gründe, warum wir kollektiv weniger liefern, als wir könnten.


Abschlussgedanke

Lernt, die langweilige Strategie ernster zu nehmen als die spektakuläre.

In Software ist „langweilig” oft der genaueste Ausdruck von Qualität,

den wir haben.

Verwandte Beiträge

Warum COBOL 2026 immer noch läuft (2/8)

Warum COBOL 2026 immer noch läuft (2/8)

COBOL läuft in Banken und Versicherungen nicht aus Nostalgie, sondern aus nüchterner Kalkulation: deterministisches Verhalten, keine Dependency-Drift, belegbare Stabilität. Ablöseprojekte scheitern selten an der Sprache, sondern an jahrzehntealten, undokumentierten Geschäftsregeln, die erst beim Umzug sichtbar werden. Die Alternative zu Legacy ist nicht Modernität, sondern Risiko.

Systeme für das Altern entwerfen (8/8)

Systeme für das Altern entwerfen (8/8)

Systeme, die altern sollen, müssen ohne ihre Autoren funktionieren — das verlangt langlebige Schnittstellen, vorsichtige Versionierung, ehrliche Dokumentation und das bewusste Vermeiden ephemerer Abhängigkeiten. Legacy ist kein Scheitern, sondern Erfolg, der lange genug angehalten hat, um außer Mode zu kommen. Die Frage beim nächsten Projekt lautet nicht „wird das modern sein?", sondern „kann ich mir vorstellen, dass das in zwanzig Jahren noch läuft, ohne dass mich jemand dafür verflucht?".