Was das Two-Loops-Modell über Systemablösung verrät und welche Patterns aus der Softwareentwicklung den Übergang tragen
In Projektplänen sieht eine Systemablösung sauber aus. Bestandsaufnahme, Migration, Go-live, Betrieb. Eine Linie mit einem klaren Übergabepunkt, an dem das Altsystem verschwindet und das neue System übernimmt.
In der Praxis passiert etwas anderes. Nach dem Go-live existieren beide Systeme weiter, wenn nicht technisch, dann in den Köpfen. Es gibt die Schattenprozesse, die Excel-Tabelle für den Notfall, die Kollegin, die den alten Weg immer noch schneller findet. Die meisten Projekte behandeln das als Übergangsproblem, das sich mit genügend Schulungen erledigt. Meistens erledigt es sich nicht.
Vom regulatorischen Druck zur klaren Umsetzung
- Warum Systemablösungen scheitern, obwohl die Technik funktioniert
- Das Two-Loops-Modell: Zwei Kurven statt einer Linie
- Drei Patterns aus der Softwareentwicklung, gelesen als Kulturwerkzeug
- Strangler Fig Pattern
- Feature Flags
- Adapter Pattern
- Drei Rollen, die im Parallelbetrieb gebraucht werden
- Häufige Fragen zur Ablösung von Altsystemen
- Kein weiteres Framework
Warum Systemablösungen scheitern, obwohl die Technik funktioniert
Die deutschsprachige Literatur zur Ablösung von Altsystemen ist umfangreich und fast durchgehend technisch. Es geht um Migrationsstrategien, Datenübernahme, Schnittstellenanalyse, um die Frage, ob rehostet, refactored oder neu gebaut wird. Alles davon ist notwendig. Nichts davon erklärt, warum ein fachlich fertiges System nach dem Go-live nicht genutzt wird.
Der Grund liegt darin, dass eine Organisation nicht zu einem Stichtag wechselt. Sie verändert sich langsamer als ihre Software. Und während sie sich verändert, lebt sie in zwei Systemen gleichzeitig.
Das Two-Loops-Modell: Zwei Kurven statt einer Linie
Einen brauchbaren Rahmen dafür liefert das Two-Loops-Modell, entwickelt von Margaret Wheatley und dem Berkana Institute. Es beschreibt Wandel nicht als Linie, sondern als zwei sich überlappende Kurven.
Die erste Kurve ist das bestehende System. Es hat einmal gut funktioniert, ist über Jahre gewachsen, hat seinen Zenit überschritten und verliert an Wirksamkeit. Die zweite Kurve ist das Neue. Es beginnt klein, unfertig, an den Rändern der Organisation, und wächst.
Entscheidend ist der Bereich dazwischen. Die Phase, in der beide Kurven gleichzeitig existieren, ist genau der Parallelbetrieb, den jede seriöse Migrationsstrategie ohnehin einplant. Technisch ist er selbstverständlich. Organisatorisch wird er fast nie mitgedacht.
Für IT-Projekte folgt daraus etwas Unbequemes. Der Widerstand, der in dieser Phase entsteht, ist kein Zeichen dafür, dass etwas schiefläuft. Er ist ein Zeichen dafür, dass der Wandel tatsächlich stattfindet.
Drei Patterns aus der Softwareentwicklung, gelesen als Kulturwerkzeuge
Das Interessante daran: Die Softwareentwicklung hat für genau dieses Problem längst Antworten. Sie werden nur selten als organisatorische Werkzeuge gelesen.
Strangler Fig Pattern
Das bekannteste Muster für die schrittweise Ablösung von Legacy-Systemen beschreibt, wie ein Altsystem Funktion für Funktion ersetzt wird, bis es keine Last mehr trägt und abgeschaltet werden kann. Der Name stammt von der Würgefeige, die einen Baum langsam umwächst.
Übertragen auf die Organisation heißt das: evolutionär wachsen statt revolutionär ersetzen. Jede abgelöste Funktion ist ein kleiner, überprüfbarer Beweis dafür, dass das Neue funktioniert. Dieser Beweis wirkt stärker als jede Ankündigung im Intranet.
Feature Flags
Technisch schalten Feature Flags Funktionen für ausgewählte Nutzergruppen frei. Organisatorisch sind sie ein Instrument, um Early Adopters zu identifizieren und früh einzubinden. Wer als Erster Zugang bekommt und dessen Rückmeldung sichtbar einfließt, wird selten zum Gegner eines Projekts.
Adapter Pattern
In der Architektur übersetzt ein Adapter zwischen zwei Schnittstellen, die nicht zueinander passen. Zwischen Fachbereich und IT ist diese Übersetzungsleistung genauso nötig und wird genauso oft vergessen. „Wir setzen auf Microservices“ ist keine Aussage, mit der eine Sachbearbeitung etwas anfangen kann. „Ihre Abteilung kann künftig releasen, ohne auf ein anderes Team zu warten“ schon.
Drei Rollen, die im Parallelbetrieb gebraucht werden
Das Two-Loops-Modell beschreibt außerdem, wer in dieser Phase welche Aufgabe übernimmt.
Der Illuminator macht das Neue sichtbar. In technischen Teams ist diese Rolle meist gut besetzt, weil Prototypen und Demos ihr natürliches Terrain sind.
Der Connector verbindet Altsystem und neues System auf der menschlichen Ebene. Er sorgt dafür, dass die Leute aus dem alten Ablauf einen Weg in den neuen finden. Diese Rolle fehlt in vielen Projekten, weil sie in keinem Projektstrukturplan vorgesehen ist.
Der Hospiziar begleitet das Alte. Er sichert das Wissen, das über Jahre in ein System und in die Workarounds drumherum geflossen ist, und sorgt dafür, dass die Menschen, die es aufgebaut haben, ihre Arbeit nicht entwertet sehen. Diese Rolle wird am häufigsten übersehen und zahlt sich am deutlichsten aus. Wer das Altsystem respektvoll verabschiedet, gewinnt genau die Verbündeten, die den Wechsel im Alltag tragen müssen.
Häufige Fragen zur Ablösung von Altsystemen
Warum wird ein neues System nach dem Go-live oft nicht genutzt?
Weil die Organisation den Wechsel langsamer vollzieht als die Technik. Solange das alte Vorgehen noch funktioniert und schneller vertraut ist, bleibt es in Gebrauch. Nutzung entsteht nicht durch Abschaltung, sondern dadurch, dass das neue System in kleinen, sichtbaren Schritten die bessere Option wird.
Wie lange sollte der Parallelbetrieb von altem und neuem System dauern?
Technisch so kurz wie möglich, organisatorisch lang genug, dass die Fachbereiche mitkommen. Ein fester Abschalttermin hilft, weil unbefristeter Parallelbetrieb doppelte Kosten erzeugt und die Migration erfahrungsgemäß bei den letzten Prozent stehen bleibt.
Was hat das Strangler Fig Pattern mit Change Management zu tun?
Es beschreibt schrittweise Ablösung statt hartem Schnitt. Dieselbe Logik gilt für Menschen: Schrittweise Übernahme gibt der Organisation Zeit, sich anzupassen, und liefert unterwegs Belege dafür, dass das Neue funktioniert.
Für wen ist das Two-Loops-Modell relevant?
Für alle, die eine Systemablösung nicht nur technisch verantworten, also Projektleitungen, Requirements Engineers, Berater und Führungskräfte in IT-Projekten.
Kein weiteres Framework
Das Two-Loops-Modell ersetzt keine Migrationsstrategie. Es ist ein Orientierungsrahmen, mit dem sich einordnen lässt, an welchem Punkt ein Projekt gerade steht und wo der größte Hebel liegt.
Genau das machen wir im zweiten Teil unserer Webinar-Serie konkret. Oliver Goetz, Head of Requirements Engineering bei BREDEX, führt durch das Modell, übersetzt die Patterns und ordnet mit Ihnen ein reales Projekt ein. Mit dabei sind drei Methoden, die Sie direkt im nächsten Sprint einsetzen können: Empathy Mapping, erweitertes Risk Storming und Stakeholder-Interviews.
Zwischen altem und neuem System: Wie Patterns aus der Softwareentwicklung den Übergang steuerbar machen
Donnerstag, 8. Oktober 2026, 11:00 Uhr · online via Microsoft Teams · ca. 45 Minuten inkl. Q&A · kostenfrei
Ihr Ansprechpartner
Gerne erzählen wir Ihnen mehr zu diesem Thema.
Jobs
Newsletteranmeldung
Jetzt keine Neuigkeiten mehr verpassen.
