Strangler Fig: Ein Altsystem schrittweise ablösen

Modernisierung

Strangler Fig

Ein Altsystem schrittweise ablösen

Die Idee und ihr Nutzen

Eine Versicherung will ihre zwanzig Jahre alte Schadenanwendung, das Altsystem, durch ein neues System ersetzen. Alle Funktionen an einem einzigen Tag umzustellen, wäre riskant: Ein Fehler beim Umschalten würde die gesamte Schadenbearbeitung anhalten. Das IT-Team baut deshalb zuerst nur eine Funktion neu, die Schadenmeldung. Vertragsprüfung und Auszahlung bleiben vorerst im Altsystem. Alle Anfragen gehen zuerst an eine „Umleitung“, ein Programm, das jede Anfrage an eines der beiden Systeme weiterleitet. Die „Umleitung“ schickt Anfragen zur Schadenmeldung an das neue System und alle übrigen Anfragen an das Altsystem. Später folgen Vertragsprüfung und Auszahlung, bis das neue System alle Funktionen übernommen hat und das IT-Team das Altsystem abschalten kann. Dieses schrittweise Ablösen heißt Strangler Fig, auf Deutsch Würgefeige: Martin Fowler hat es nach dieser Pflanze benannt, die in der Krone eines Baumes keimt, am Stamm hinab bis in den Boden wächst und den Baum mit der Zeit ersetzt.

Bausteine: Kunde: meldet einen Schaden; Sachbearbeitung: prüft die Deckung; Umleitung: nimmt alle Anfragen an, entscheidet je Funktion; Neues System: schon: Schadenmeldung; Altsystem: noch: Vertragsprüfung, Auszahlung. Verbindungen: Kunde — Umleitung; Sachbearbeitung — Umleitung; Umleitung — Neues System; Umleitung — Altsystem. Die „Umleitung“ schickt jede Anfrage an das System, das für die angefragte Funktion gerade zuständig ist; das neue System übernimmt Schritt für Schritt mehr Funktionen.

Wie funktioniert es?

Ein Kunde öffnet die Schadenmeldung. Die „Umleitung“ schickt diese Anfrage an das neue System, und das neue System legt Fall 4711 an. Danach übergibt das neue System die Falldaten von Fall 4711 über eine vereinbarte Schnittstelle an das Altsystem, damit die Sachbearbeitung den Fall auch im Altsystem findet. Eine Schnittstelle ist die vereinbarte Form, in der ein Programm ein anderes aufruft und ihm Angaben übergibt. Diese Schnittstelle hat das IT-Team für die Übergangszeit festgelegt: Das Altsystem bietet sie an und nimmt darüber Falldaten in einer bestimmten Form an, und das neue System ruft sie für jeden neuen Fall auf. Als Nächstes prüft die Sachbearbeitung die Deckung von Fall 4711, also ob der Vertrag des Kunden den Schaden deckt. Diese Vertragsprüfung läuft vorerst weiter im Altsystem. Deshalb schickt die „Umleitung“ die Anfrage an das Altsystem, und die Sachbearbeitung findet dort Fall 4711. Nach einigen Monaten ist der neue Vertragsdienst fertig, also die im neuen System neu gebaute Vertragsprüfung. Das IT-Team legt fest, wie es die „Umleitung“ für die Vertragsprüfung im Notfall zurück auf das Altsystem stellen kann. Danach stellt das IT-Team die „Umleitung“ um. Von da an schickt die „Umleitung“ die Anfragen der Sachbearbeitung zur Vertragsprüfung an das neue System. Das Altsystem ist nur noch für Auszahlungen zuständig. Ist auch die Auszahlung umgezogen, schaltet das IT-Team das Altsystem ab.

Die „Umleitung“ entscheidet für jede Funktion einzeln, welches System eine Anfrage bearbeitet. Kunden und Sachbearbeitung rufen weiterhin dieselbe Adresse auf und müssen nicht wissen, welches System gerade antwortet. Als erste Funktion hat das IT-Team die Schadenmeldung gewählt, weil sie nur neue Fälle anlegt und weder Verträge noch Zahlungen ändert. Außerdem hat das IT-Team geklärt, welche Daten die Schadenmeldung liest und schreibt. Vor der ersten Umstellung hat das IT-Team für jeden Datenbestand festgelegt, welches System ihn ändern darf und wie das andere System von Änderungen erfährt. So legt nur das neue System neue Fälle an und übergibt jeden neuen Fall über die Schnittstelle an das Altsystem. Festgelegt ist auch, welches System maßgeblich ist, wenn die Angaben in beiden Systemen voneinander abweichen, etwa wenn die Schadenhöhe von Fall 4711 im Altsystem eine andere ist als im neuen System. Die nächste Funktion baut das IT-Team erst neu, wenn die vorige im Alltag zuverlässig läuft.

Zeigt sich nach einer Umstellung ein Fehler im neuen System, stellt das IT-Team die „Umleitung“ für diese eine Funktion zurück auf das Altsystem. Das gelingt nur, solange das Altsystem die Funktion noch enthält und auch die Daten hat, die sich inzwischen im neuen System geändert haben.

Beteiligte: Kunde: meldet einen Schaden; Sachbearbeitung: prüft die Deckung; Umleitung: entscheidet je Funktion, wohin; Neues System: zuerst „Schaden melden“, später mehr; Altsystem: Vertragsprüfung, Auszahlung. Ablauf: 1. Der Kunde öffnet die Schadenmeldung. 2. Die „Umleitung“ schickt die Anfrage zur Schadenmeldung an das neue System. 3. Das neue System legt Fall 4711 an. 4. Das neue System übergibt die Falldaten von Fall 4711 über eine vereinbarte Schnittstelle an das Altsystem, damit die Sachbearbeitung den Fall dort findet. 5. Die Sachbearbeitung prüft die Deckung von Fall 4711. 6. Die „Umleitung“ schickt die Anfrage zur Vertragsprüfung vorerst noch an das Altsystem. 7. Nach einigen Monaten ist der neue Vertragsdienst fertig. Das IT-Team legt fest, wie es die „Umleitung“ für die Vertragsprüfung im Notfall zurück auf das Altsystem stellen kann. Danach stellt das IT-Team die „Umleitung“ um. 8. Die „Umleitung“ schickt die Anfragen zur Vertragsprüfung jetzt an das neue System. Das Altsystem ist nur noch für Auszahlungen zuständig. Ist auch die Auszahlung umgezogen, wird das Altsystem abgeschaltet.

Wann ist es sinnvoll und wann nicht?

Das Strangler-Fig-Vorgehen lohnt sich

Ein großes, langlebiges System soll ersetzt werden, und seine Funktionen lassen sich einzeln herauslösen. Im Altsystem der Versicherung sind das Schadenmeldung, Vertragsprüfung und Auszahlung. Das Altsystem ist technisch veraltet, Änderungen daran dauern lange, und nur noch wenige Entwickler kennen es. Ohne Strangler Fig bleiben alle drei Funktionen im Altsystem, bis das neue System vollständig fertig ist. Mit Strangler Fig ändern die Entwickler die Schadenmeldung schon nach dem ersten Schritt im neuen System.
Das Altsystem muss während des Umbaus weiterlaufen, und ein einziger Stichtag für die Umstellung aller Funktionen wäre zu riskant. Ein Neubau aller Funktionen dauert Jahre, und in dieser Zeit müsste das Altsystem trotzdem weiter angepasst werden. Geht beim Umschalten an einem Stichtag etwas schief, steht die gesamte Schadenbearbeitung still, und Tausende Kunden warten auf ihr Geld. Beim schrittweisen Umzug betrifft ein Fehler nur die Funktion, die gerade umgezogen ist.
Für den Umbau stehen mehrere Monate oder Jahre zur Verfügung. Ohne Strangler Fig arbeitet in dieser Zeit niemand mit dem neuen System, und seine Fehler zeigen sich erst am Stichtag alle auf einmal. Mit Strangler Fig läuft die neue Schadenmeldung schon Monate vor dem Abschalten des Altsystems im Alltag.
Kunden sollen neue Funktionen früh nutzen können. Die neue Schadenmeldung steht nach dem ersten Schritt bereit und nicht erst nach Jahren des Neubaus.

Das Strangler-Fig-Vorgehen ist nicht das Richtige

Die Funktionen des Altsystems hängen so eng voneinander ab, dass sich keine einzelne herauslösen lässt. Das ist etwa der Fall, wenn jede Funktion direkt die Daten der anderen Funktionen ändert oder niemand weiß, welche Daten wo geändert werden. Beim schrittweisen Umzug würden dann beide Systeme dieselben Daten ändern, ohne dass klar ist, welches System maßgeblich ist. Das IT-Team baut das neue System deshalb vollständig und stellt alle Funktionen an einem Stichtag um. Von diesem Tag an ändert nur noch das neue System die Daten.
Das Altsystem hat nur wenige Funktionen, oder es muss bis zu einem nahen Termin abgeschaltet sein. Bei wenigen Funktionen gibt es kaum Schritte, auf die sich das Risiko verteilen ließe, und bei einem nahen Termin reicht die Zeit nicht für eine Übergangszeit von mehreren Monaten. Dann baut das IT-Team das neue System vollständig und stellt alle Funktionen an einem Stichtag um. Von diesem Tag an rufen Kunden und Sachbearbeitung direkt das neue System auf. Die „Umleitung“ und die Schnittstelle für die Übergangszeit entfallen, und das IT-Team betreibt nicht über Monate zwei Systeme nebeneinander.
Die Anfragen an das Altsystem lassen sich nicht abfangen und umleiten. Das ist zum Beispiel der Fall, wenn andere Programme der Versicherung keine Anfragen an das Altsystem schicken, sondern direkt in seine Datenbank schreiben. Diese Zugriffe kämen nie bei der „Umleitung“ an, und die anderen Programme würden auch nach der Umstellung einer Funktion weiter nur die Datenbank des Altsystems füllen. Auch dann baut das IT-Team das neue System vollständig und stellt am Stichtag alle Funktionen und die anderen Programme gleichzeitig auf das neue System um. Eine „Umleitung“, an der diese Zugriffe vorbeigehen, muss das IT-Team dann nicht bauen.
Programmiersprache, Datenbank und Server des Altsystems werden von ihren Herstellern noch mit Updates versorgt, und nur der Code ist schwer zu verstehen geworden. Ein neues System würde dann nichts beheben, was sich nicht auch im Code des Altsystems beheben lässt. Das IT-Team ersetzt das Altsystem deshalb nicht, sondern verbessert seinen Code Schritt für Schritt. Ein zweites System, die „Umleitung“ und der Abgleich der Daten zwischen zwei Systemen entfallen.

Nachteile und typische Fehler

Während der Übergangszeit betreibt und pflegt das IT-Team zwei Systeme, und das kostet über lange Zeit Geld. Oft brauchen beide Systeme dieselben Daten, und das IT-Team muss diese Daten bei jedem Schritt abgleichen. Die Schnittstelle, über die das neue System Fälle wie 4711 an das Altsystem übergibt, ist zusätzlicher Code, der nach der Ablösung wieder entfällt. Die „Umleitung“ ist ein zusätzliches Programm, durch das alle Anfragen laufen. Die „Umleitung“ muss so ausfallsicher und schnell sein wie die beiden Systeme, an die sie die Anfragen weiterleitet.

Typische Fehler und woran man sie erkennt:

Doppelte Datenpflege: Beide Systeme dürfen dieselben Falldaten ändern, ohne dass festgelegt ist, welches System maßgeblich ist. Die Sachbearbeitung korrigiert bei der Vertragsprüfung im Altsystem die Schadenhöhe von Fall 4711. Das neue System erfährt davon nichts und behält die alte Schadenhöhe. Erkennbar ist das an Fällen wie 4711, die im neuen System und im Altsystem unterschiedliche Angaben haben.
Fehlende Übergabe: Das neue System legt Fall 4711 an, übergibt ihn aber nicht an das Altsystem. Die Sachbearbeitung findet den Fall dort nicht und kann die Deckung nicht prüfen. Erkennbar ist das an Schadenmeldungen, die im neuen System vorhanden sind und im Altsystem fehlen.
Keine Rückkehr vorbereitet: Das IT-Team stellt eine Funktion um, ohne festzulegen, wie es im Notfall zur alten Funktion zurückkehrt. Danach entfernt das IT-Team die Funktion zu früh aus dem Altsystem. Tritt im neuen System ein Fehler auf, kann die „Umleitung“ die Anfragen zu dieser Funktion an kein funktionierendes System mehr schicken, und die Funktion steht still. Erkennbar ist das daran, dass ein Zurückstellen der „Umleitung“ auf Fehler im Altsystem stößt.
Stillstand auf halber Strecke: Der Umbau bleibt stehen, und die Versicherung betreibt dauerhaft zwei Systeme. Ein Grund kann sein, dass das Budget ausgeht. Erkennbar ist das an einem Altsystem, dessen Funktionsumfang über lange Zeit unverändert bleibt.
„Umleitung“ als Engpass: Alle Anfragen laufen durch die „Umleitung“, die nur einmal vorhanden ist oder nicht genug Anfragen gleichzeitig bearbeiten kann. Fällt die „Umleitung“ aus, sind neues System und Altsystem gleichermaßen nicht erreichbar. Erkennbar ist das an Störungen, die beide Systeme gleichzeitig betreffen.

Weiterführend

Quellen

Martin Fowler: Strangler Fig: Herkunft des Namens und Begründung, warum eine schrittweise Ablösung weniger riskant ist als ein vollständiger Neubau.
Microsoft: Strangler Fig Pattern: beschreibt ein vorgeschaltetes Programm, das Anfragen umleitet, den Umgang mit gemeinsam genutzten Daten, dieses Programm als möglichen Engpass und Fälle, in denen das Vorgehen nicht passt.