Wie kommt man aus einem Big Ball of Mud wieder heraus?

Martin Fowler zeigt mit Refactoring, wie bestehender Code durch kleine, verhaltenserhaltende Veränderungen strukturell verbessert werden kann. Michael Feathers zeigt in Working Effectively with Legacy Code, wie sich schwer veränderbarer Code überhaupt wieder unter Kontrolle bringen lässt: durch Tests, durch das Aufbrechen problematischer Abhängigkeiten und durch Seams, an denen Veränderungen möglich werden. Beides gehört weiterhin zum wichtigsten Handwerkszeug für die Arbeit an gewachsenen Systemen.

Bei einem ausgewachsenen Big Ball of Mud kommt jedoch eine weitere Grenze hinzu:

Ein Big Ball of Mud sollte niemals von einer einzelnen Person gerettet werden.

Das ist keine empirische Naturregel. Es ist eine Architekturhaltung.

Denn irgendwann betrifft die strukturelle Erosion nicht mehr nur einzelne Klassen, Services oder Module. Sie betrifft gleichzeitig fachliches Verhalten, historische Anforderungen, technische Abhängigkeiten, Organisationsgrenzen, Verantwortlichkeiten, Tests, Wissen sowie Release- und Betriebsprozesse.

Eine einzelne Person besitzt typischerweise weder das vollständige Wissen noch die fachliche Entscheidungshoheit, die organisatorische Legitimation und die notwendige Zeit, um all diese Dimensionen alleine neu zu ordnen.

Du kannst einen Big Ball of Mud nicht alleine retten. Und schon gar nicht nebenbei.

Das bedeutet nicht, dass einzelne Entwickler nichts bewirken können. Im Gegenteil: Häufig beginnt Veränderung genau damit, dass jemand eine problematische Struktur erkennt, eine bessere Grenze vorschlägt oder einen ersten kontrollierbaren Einstiegspunkt schafft.

Aber aus einer individuellen Beobachtung muss irgendwann eine gemeinsame Entscheidung werden.

Ein systemisches Problem benötigt irgendwann eine gemeinsame Entscheidung.

Gerade bei einem Big Ball of Mud ist das entscheidend. Wenn der Ausweg erneut davon abhängt, dass ein außergewöhnlicher Architekt das gesamte System versteht, alle wesentlichen Entscheidungen trifft und persönlich dafür sorgt, dass niemand vom neuen Pfad abweicht, entsteht bereits das nächste Wissensmonopol.

Die Architektur wäre vielleicht besser, das strukturelle Abhängigkeitsproblem jedoch nicht.

Drei Verantwortungen statt eines Helden

„Gemeinsam“ bedeutet dabei nicht einfach, mehr Entwickler auf das Problem anzusetzen. Zehn Entwickler ohne gemeinsame Richtung können eine inkonsistente Struktur schneller erzeugen als zwei.

Für eine nachhaltige Rekonstruktion müssen mindestens drei Perspektiven vorhanden sein: technische, fachliche und organisatorische Verantwortung.

Technische Verantwortung

Die technische Perspektive definiert die Richtung der Rekonstruktion. Sie beantwortet beispielsweise:

• Wo sollen fachliche Verantwortlichkeiten künftig liegen?
• Welche Abhängigkeiten sind zulässig?
• Wie werden fachliche Slices voneinander getrennt?
• Welche Integrationsmechanismen werden verwendet?
• Wo liegt fachlicher Zustand?
• Welche wiederkehrenden Patterns sollen neue Strukturen prägen?
• Welche heute problematischen Patterns sollen nicht weiter entstehen?

Dabei geht es nicht darum, jede Implementierungsentscheidung zentral vorzugeben. Ziel ist vielmehr, Regeln zu schaffen, die verschiedene Entwickler unabhängig voneinander zu kompatiblen Lösungen führen.

Fachliche Verantwortung

Technische Analyse kann helfen zu rekonstruieren, was ein System heute tut. Sie kann daraus jedoch nicht zuverlässig ableiten, was es künftig tun soll.

Dafür braucht es Menschen, die fachliche Entscheidungen treffen können.

Sie müssen unter anderem beantworten:

• Welche Business Rules gelten weiterhin?
• Welche Sonderfälle sind fachlich notwendig?
• Welche historischen Eigenschaften dürfen verschwinden?
• Welche heute beobachtbaren Ergebnisse sind verbindlich?
• Welche Verhaltensweisen sind lediglich Folgen alter technischer Einschränkungen?

Bei einem lange gewachsenen System ist diese Verantwortung besonders wichtig, weil Code und Fachlichkeit nicht mehr sauber voneinander zu trennen sein müssen.

Organisatorische Verantwortung

Schließlich benötigt Rekonstruktion einen organisatorischen Handlungsspielraum.

Jemand muss ermöglichen, dass Zeit investiert werden darf, Entscheidungen getroffen werden können und Menschen über bestehende Zuständigkeitsgrenzen hinweg zusammenarbeiten.

Das bedeutet nicht zwangsläufig ein eigenes Modernisierungsprogramm. Aber auch eine kleine taktische Rekonstruktion benötigt zumindest die Legitimation, tatsächlich durchgeführt zu werden.

Diese drei Perspektiven müssen nicht zwingend bei drei unterschiedlichen Personen oder Rollen liegen. In kleineren Organisationen können sich Verantwortlichkeiten überschneiden.

Sie müssen jedoch vorhanden sein.

Ein Big Ball of Mud ist zu einem gemeinsamen Problem geworden. Deshalb kann auch seine Rekonstruktion keine private Initiative eines einzelnen Entwicklers bleiben.

Die Rekonstruktion eines Big Ball of Mud benötigt technische, fachliche und organisatorische Verantwortung. Keine dieser Perspektiven kann die anderen dauerhaft ersetzen.

Einen Big Ball of Mud räumt man nicht auf

Lokale Refactorings bleiben in einem Big Ball of Mud sinnvoll. Fowler beschreibt Refactoring als eine disziplinierte Veränderung der internen Struktur unter Beibehaltung des von außen beobachtbaren Verhaltens. Gerade die kleinen Schritte und die dadurch entstehende Rückkopplung machen diese Technik wertvoll.

Auch Feathers’ Techniken bleiben relevant. Ein problematischer Service kann entkoppelt werden. Eine Klasse kann unter Tests gebracht werden. Eine schwer kontrollierbare Abhängigkeit kann einen Seam erhalten. Ein lokaler Bereich kann verständlicher werden.

Ein ausgewachsener Big Ball of Mud besitzt jedoch eine zusätzliche Dimension: Die Struktur des Gesamtsystems erklärt seine tatsächlichen Verantwortlichkeiten und Abhängigkeiten nicht mehr ausreichend.

Das Problem besteht damit nicht nur darin, dass vorhandener Code „unschön“ ist.

Es fehlt eine belastbare Antwort darauf, welcher Teil des Systems wofür verantwortlich sein soll.

Deshalb ist „Aufräumen“ für die notwendige Arbeit ein zu schwacher Begriff.

Einen Big Ball of Mud räumt man nicht auf. Man rekonstruiert ihn schrittweise.

Mit Rekonstruktion ist kein vollständiger Ersatz des gesamten Systems gemeint.

Es geht auch nicht um die Vorstellung:

alt weg → neu bauen → umschalten.

Gemeint ist etwas wesentlich unspektakuläreres und gerade deshalb häufig realistischeres:

Ein weiterhin produktives System erhält schrittweise wieder fachliche und technische Grenzen.

Wie das praktisch aussehen kann, hängt wesentlich davon ab, welchen Handlungsspielraum das Team besitzt.

Zwei unterschiedliche Ausgangslagen

Für den Umgang mit einem Big Ball of Mud lohnt es sich, zwei Situationen klar voneinander zu unterscheiden.

In der ersten gibt es kein explizites Mandat für eine umfassendere Rekonstruktion. Das Team muss weiterhin Features liefern und kann strukturelle Verbesserungen nur dort einbringen, wo sie wirtschaftlich mit der laufenden Produktentwicklung vereinbar sind.

In der zweiten hat die Organisation das strukturelle Problem bewusst akzeptiert und ist bereit, Rekonstruktion als geplante Produktarbeit zu finanzieren.

Die technischen Möglichkeiten unterscheiden sich erheblich.

Situation 1: Es gibt kein explizites Modernisierungsmandat

Dies dürfte in vielen Organisationen die gewöhnlichere Situation sein.

Das Produkt wird benötigt. Kunden warten auf Funktionen. Budgets sind begrenzt. Vielleicht ist unklar, wie lange das System überhaupt noch betrieben wird. Vielleicht gibt es andere strategische Investitionen mit höherem erwarteten Nutzen.

Dass Stakeholder kein eigenständiges Modernisierungsprogramm finanzieren, ist deshalb nicht automatisch irrational.

Für das Entwicklungsteam bedeutet das allerdings, dass es kein verborgenes zweites Projekt beginnen sollte.

Featurebudgets systematisch für eine heimliche Rekonstruktion des Gesamtsystems zu verwenden, ist weder transparent noch besonders nachhaltig. Spätestens wenn die ersten größeren Aufwände sichtbar werden, fehlt der Arbeit die organisatorische Grundlage.

Die interessantere Frage lautet deshalb:

Kann eine ohnehin notwendige Produktänderung zu einem sinnvollen Schnittpunkt für taktische Rekonstruktion werden?

Angenommen, eine neue fachliche Anforderung betrifft einen besonders problematischen Bereich. Dann können zwei reale technische Wege existieren.

Variante A: Das Feature wird entlang der bestehenden Struktur implementiert.

Variante B: Der betroffene fachliche Ausschnitt wird ausreichend abgegrenzt oder rekonstruiert, sodass das Feature anschließend innerhalb einer belastbareren Struktur umgesetzt werden kann.

Beide Varianten müssen ehrlich geschätzt werden.

Wenn die Erweiterung der bestehenden Struktur etwa 20 Personentage kostet, eine sinnvolle Rekonstruktion jedoch 60, ist die wirtschaftliche Antwort in vielen Situationen vollkommen nachvollziehbar: Das Feature wird zunächst im Bestand umgesetzt.

Architektur besitzt keinen Anspruch darauf, jede andere Produktpriorität zu überstimmen.

Anders sieht es aus, wenn beide Varianten ungefähr im selben Aufwandkorridor liegen. Vielleicht benötigt die direkte Erweiterung 25 Tage und eine kontrollierte Abgrenzung mit anschließender Implementierung 30 oder 35.

Dann existiert eine echte Entscheidung.

Für den Stakeholder bleibt das primäre Ziel weiterhin dasselbe: Das benötigte Feature soll zuverlässig in einem vertretbaren Zeitraum geliefert werden. Wenn aber für einen ähnlichen Aufwand zusätzlich eine belastbare fachliche Grenze entstehen kann, sollte diese Option bewusst geprüft werden.

Und zwar nicht allein am Schreibtisch eines einzelnen Entwicklers.

Wenn Erweiterung und Rekonstruktion wirtschaftlich nahe beieinanderliegen, sollte der verantwortliche Kreis sehr bewusst entscheiden, welche Variante gewählt wird.

Gerade hier gehören erfahrene Entwickler beziehungsweise technisch verantwortliche Personen zusammen. Nicht um ein Architekturkomitee für jede Codezeile zu etablieren, sondern weil aus vielen solchen Einzelentscheidungen allmählich die zukünftige Struktur des Systems entsteht.

Wenn ohnehin eine Änderung notwendig ist, kann es sinnvoll sein, Erweiterung und taktische Rekonstruktion als zwei reale Implementierungswege zu vergleichen.

Architecture Guidelines vor opportunistischer Rekonstruktion

Taktische Rekonstruktion besitzt eine offensichtliche Gefahr: Viele lokale Verbesserungen ergeben nicht automatisch eine bessere Gesamtarchitektur.

So kann Entwickler A einen neuen fachlichen Store einführen, während Entwickler B auf Services setzt, Entwickler C einen Event Bus etabliert und Entwickler D eine zusätzliche Facade-Schicht ergänzt. Jede einzelne Lösung kann lokal plausibel sein; zusammengenommen entsteht trotzdem das nächste System, dessen Regeln niemand präzise erklären kann.

Ein Big Ball of Mud wird nicht dadurch gesund, dass jeder Entwickler seine persönliche Vorstellung guter Architektur hineinbaut.

Deshalb sollte möglichst früh ein kleines, gemeinsam getragenes Zielbild existieren.

Damit ist keine 100-seitige Enterprise-Architecture-Dokumentation gemeint. Gerade in einem System mit hoher Änderungsdynamik würde eine solche Dokumentation schnell selbst zum historischen Artefakt.

Benötigt werden wenige Regeln, die bei konkreten Entscheidungen tatsächlich helfen. Beispielsweise:

• Wo liegen fachliche Verantwortlichkeiten?
• In welche Richtung dürfen Abhängigkeiten laufen?
• Wie kommunizieren fachliche Slices miteinander?
• Wo liegt fachlicher Zustand?
• Welche Integrationsmechanismen werden bevorzugt?
• Welche Patterns sollen in neuen Bereichen nicht mehr entstehen?
• Wie werden externe Systeme angebunden?
• Welche Regeln müssen unabhängig vom konkreten Entwickler reproduzierbar sein?

Diese Guidelines dürfen sich weiterentwickeln. Sie müssen auch nicht von Beginn an sämtliche Sonderfälle abdecken.

Entscheidend ist ihre Funktion:

Taktische Rekonstruktion benötigt eine gemeinsame Richtung. Sonst entstehen aus einem Big Ball of Mud nur mehrere neue Inseln.

Das Ziel darf gerade nicht darin bestehen, einen neuen Architekturhelden zu schaffen, der jeden Pull Request persönlich kontrollieren muss.

Eine belastbare Architekturregel ist eine Regel, die mehrere Menschen verstehen und reproduzieren können.

Wenn nur eine Person weiß, warum die neue Struktur funktioniert, ist das System zwar möglicherweise technisch sauberer, aber organisatorisch weiterhin fragil.

Neue Features entlang des Zielbildes – wenn eine echte Grenze möglich ist

Grundsätzlich sollte neue Funktionalität nicht automatisch weiter in dieselben alten Strukturen hineinwachsen.

Wenn eine belastbare fachliche Grenze wirtschaftlich und technisch hergestellt werden kann, bietet ein neues Feature eine gute Gelegenheit, diese Grenze tatsächlich zu etablieren.

Dieser Rat lässt sich allerdings leicht missverstehen.

„Legacy nicht mehr anfassen und neuen Code einfach sauber danebenbauen“ klingt attraktiv. In einem ausgewachsenen Big Ball of Mud kann genau das unmöglich sein.

Vielleicht liegt fachlicher Zustand global verteilt in mehreren Services. Vielleicht greifen Workarounds quer durch unterschiedliche Bereiche. Vielleicht teilen vermeintlich unabhängige Features dieselben Datenstrukturen. Vielleicht löst ein implizites Event an drei anderen Stellen Verhalten aus, das niemand dokumentiert hat.

Dann kann ein neuer Ordner namens

features/new-feature

eine schöne Struktur suggerieren, ohne tatsächlich eine neue Grenze zu erzeugen.

Eine Grenze, die auf der neuen Seite sauber aussieht, aber für jede fachliche Operation tief in den Big Ball of Mud greifen muss, ist noch keine belastbare Grenze.

In solchen Fällen besteht der erste sinnvolle Rekonstruktionsschritt möglicherweise gar nicht darin, einen vollständigen neuen Slice zu implementieren.

Zunächst braucht das Team vielleicht nur einen kontrollierbaren Integrationspunkt.

Hier wird Feathers’ Konzept des Seam interessant: ein Punkt, an dem Verhalten beeinflusst beziehungsweise eine Abhängigkeit getrennt werden kann, ohne den gesamten umliegenden Code gleichzeitig verändern zu müssen. Das Konzept entstand im Kontext von Legacy-Code und Testbarkeit, lässt sich aber auch als hilfreiches Denkmodell für kontrollierbare Übergänge lesen.

Manchmal ist das erste Ergebnis der Rekonstruktion noch kein neuer Feature-Slice. Es ist lediglich die erste belastbare Grenze, an der später einer entstehen kann.

Auch das ist Fortschritt, nur weniger spektakulär als eine neue Verzeichnisstruktur anzulegen.

Situation 2: Die Stakeholder tragen die Rekonstruktion bewusst mit

Die zweite Ausgangslage verändert den Handlungsspielraum grundlegend.

Management, Product Management oder andere verantwortliche Stakeholder haben akzeptiert, dass das System ein strukturelles Problem besitzt und weitere Veränderung trotzdem notwendig bleibt. Die Rekonstruktion darf bewusst geplant, priorisiert und finanziert werden.

Dann wäre es zu wenig, einfach „mehr Refactoring“ zu betreiben.

Behandelt die Rekonstruktion wie Produktentwicklung.

Das bedeutet insbesondere, nicht von technischen Dateien oder Schichten auszugehen, sondern von fachlich nachvollziehbaren Ausschnitten.

Für einen solchen Ausschnitt werden Requirements bestätigt, das relevante bestehende Verhalten verstanden und abgesichert, eine Zielgrenze definiert und anschließend Verantwortung kontrolliert auf eine neue Implementierung verschoben.

Erst wenn der neue Pfad trägt, kann der alte verschwinden; danach folgt der nächste Ausschnitt. Das klingt langsamer als die Vorstellung, ein großes neues System neben dem alten aufzubauen, doch genau diese Begrenzung ist der entscheidende Vorteil.

Strangler Fig: Nicht die gesamte Unsicherheit auf einmal übernehmen

Martin Fowler beschrieb 2004 die Strangler Fig Application als Alternative zu einer vollständigen Ablösung in einem einzigen Cut-over. Das Bild stammt von Würgefeigen, die um bestehende Bäume wachsen und deren Rolle schrittweise übernehmen. Fowler betonte bereits in seiner ursprünglichen Beschreibung vor allem die Möglichkeit, Risiko durch kleinere Schritte und häufigere produktive Zwischenstände zu reduzieren. Seine 2024 überarbeitete Darstellung ordnet das Prinzip heute ausdrücklich in den größeren Kontext inkrementeller Legacy-Modernisierung ein.

Für einen Big Ball of Mud ist Strangler Fig deshalb weniger als konkretes Implementierungsrezept interessant als als grundlegendes Denkmodell:

Begrenze den Umfang jeder einzelnen Wette.

Ein Ausschnitt sollte klein genug sein, dass das Team sein fachlich relevantes Verhalten verstehen kann. Die Requirements müssen bestätigbar sein. Das Ergebnis muss testbar werden. Die Übernahme muss überprüfbar sein. Und ein Fehler sollte nicht automatisch das gesamte Modernisierungsvorhaben gefährden.

Strangler Fig ist kein Erfolgsversprechen. Es begrenzt aber den Umfang der Unsicherheit, die ein Team gleichzeitig übernehmen muss.

Das ist ein entscheidender Unterschied zu einem Ansatz, bei dem Alt und Neu über Jahre als zwei vollständige Welten nebeneinander existieren.

Beim Strangler wird nicht darauf gewartet, dass irgendwann das komplette neue System fertig ist. Stattdessen gilt:

Verantwortung wird Slice für Slice verschoben.

Das kann beispielsweise bedeuten, dass zunächst ein fachlicher Prozess über eine neu geschaffene Schnittstelle auf eine neue Implementierung geleitet wird. Nach erfolgreicher Übernahme besitzt das Legacy-System für diesen Prozess keine Verantwortung mehr; anschließend kann dessen alter Pfad entfernt werden. Erst dann folgt der nächste Slice. Das Prinzip besitzt allerdings eigene Kosten.

Alte und neue Strukturen existieren zeitweise parallel. Routing oder andere Integrationsmechanismen werden notwendig. Daten müssen möglicherweise synchronisiert oder schrittweise migriert werden. Übergangszustände können kurzfristig sogar mehr Komplexität erzeugen als vorher.

Diese Kosten verschwinden nicht dadurch, dass das Verfahren einen Namen besitzt.

Strangler Fig ist deshalb keine universell ideale Lösung. Manche technischen oder fachlichen Systeme lassen sich nur schwer sinnvoll unterteilen. Manche Datenmigrationen besitzen harte Konsistenzanforderungen. Manche Produkte sind so kurz vor ihrem Lebensende, dass eine größere strukturelle Investition wirtschaftlich schlicht keinen Sinn mehr ergibt.

Für einen Big Ball of Mud ist das Prinzip trotzdem besonders wertvoll, weil es eine problematische Grundannahme vermeidet: dass das gesamte System zuerst verstanden und anschließend in einem einzigen großen Schritt neu geordnet werden müsse.

Beim Strangler-Fig-Prinzip wird Verantwortung schrittweise verschoben. Jeder erfolgreich übernommene Slice reduziert den verbleibenden Legacy-Anteil.

Warum ich bei einem großen Cut-over sehr vorsichtig wäre

Eine vollständige Ablösung in einem großen Cut-over ist nicht unmöglich. Es gibt Situationen, in denen sie technisch oder organisatorisch begründbar sein kann.

Bei einem Big Ball of Mud sollte sie jedoch eine bewusst begründete Ausnahme sein, nicht das Standardvorgehen.

Der stärkste Grund dafür ist zunächst kein statistischer.

Ein vollständiger Ersatz muss einen Funktionsumfang rekonstruieren, während das produktive Altsystem weiterhin lebt.

Das bestehende Produkt wird während der Arbeiten normalerweise nicht eingefroren.

Es benötigt weiterhin Security Fixes und Bugfixes, regulatorische Änderungen können auftreten, Kunden benötigen dringende Anpassungen und unter Umständen entstehen sogar neue Features. Jede dieser Änderungen erzeugt ein Synchronisationsproblem.

Wird eine neue Anforderung ausschließlich im Legacy-System umgesetzt, driften Alt und Neu auseinander; wird sie in beiden Implementierungen umgesetzt, entsteht zumindest teilweise doppelte Arbeit; wird sie ausschließlich für das zukünftige System entwickelt, profitiert das heutige Produktionssystem nicht davon.

Ein Big-Bang-Ersatz muss nicht nur den bekannten Zustand eines Systems rekonstruieren. Er muss ein System einholen, das währenddessen weiterlebt.

Je länger eine vollständige Ablösung dauert, desto stärker kann sich dadurch ihr fachlicher Zielzustand verschieben.

Eine aktuelle empirische Untersuchung liefert dazu interessante, aber bewusst eng zu interpretierende Daten. Jørgensen, Nereng und Torrissen befragten 76 norwegische Softwarefachleute zu ihrem jeweils jüngsten Decommissioning-Vorhaben. Die untersuchten Ablöse- beziehungsweise Stilllegungsvorhaben dauerten im Durchschnitt 5,5 Jahre. Unter den Vorhaben, deren Ziel die vollständige Ablösung eines bestehenden Systems war, gelang es in 44 Prozent der berichteten Fälle nicht, das Altsystem tatsächlich außer Betrieb zu nehmen; Alt und Neu wurden anschließend parallel weiterbetrieben. Die Autoren berichten außerdem, dass Fehlschläge eng mit der Ablösung mehr als 20 Jahre alter COBOL-Systeme durch einen Big-Bang-Ansatz zusammenhingen. Ein schrittweiser, ersetzender Decommissioning-Prozess war in der untersuchten Stichprobe ebenfalls mit höheren Erfolgsraten verbunden.

Diese 44 Prozent sind keine allgemeine Scheiterquote für Big-Bang-Projekte. Die Studie betrachtet eine konkrete Stichprobe, ein bestimmtes Land und Decommissioning-Vorhaben mit sehr unterschiedlichen Kontexten. Sie passt jedoch zu dem strukturellen Problem: Je mehr Verantwortung gleichzeitig verschoben werden muss, desto größer wird die Menge an Unsicherheit, die ein Programm gleichzeitig beherrschen muss.

Deshalb ist meine Empfehlung zurückhaltender, aber deutlich:

Bei einem Big Ball of Mud sollte Big Bang eine bewusst begründete Ausnahme sein, nicht das Standardvorgehen.

Requirements Engineering ist kein Nebenthema

Die vielleicht schwierigste Frage einer Rekonstruktion lautet nicht:

Wie implementieren wir den neuen Slice?

Sondern:

Was soll er eigentlich tun?

Ein Big Ball of Mud enthält nicht einfach „die Anforderungen“.

Der vorhandene Code kann gleichzeitig aktuelle Business Rules, historische Regeln, obsolete Regeln, Bugs, Workarounds, technische Einschränkungen und zufällig entstandenes Verhalten enthalten.

Hinzu kommt eine unangenehme Kategorie: Verhalten, das ursprünglich vielleicht niemals vorgesehen war, auf das Kunden, andere Systeme oder betriebliche Prozesse inzwischen aber trotzdem angewiesen sind.

Deshalb reicht bei einer Rekonstruktion die Anforderung nicht:

„Baut es einfach genau so nach.“

Der alte Code ist eine wertvolle Quelle, beantwortet aber primär die Frage:

Was macht das System heute?

Er beantwortet nicht zuverlässig:

Was soll das System morgen tun?

Diese Unterscheidung ist in der Forschung zu Requirements Recovery nicht neu. Bereits Liu, Alderson und Qureshi beschrieben Requirements Recovery für Legacy-Systeme als Untersuchung des beobachtbaren Systemverhaltens unter Einbeziehung unterschiedlicher Stakeholder und des geschäftlichen Kontexts. Ihre Arbeit ist inzwischen alt und kein allgemeingültiges Modernisierungsverfahren, unterstreicht aber einen bis heute wichtigen Punkt: Die fachliche Bedeutung eines Legacy-Systems lässt sich nicht allein aus seinen technischen Artefakten ableiten.

Für eine Rekonstruktion bedeutet das:

Die Fachseite muss wieder Verantwortung für die fachliche Wahrheit übernehmen.

Sie muss entscheiden, welche Regeln weiterhin gelten, welche Sonderfälle tatsächlich fachlich relevant sind, welche Eigenschaften verschwinden dürfen und welche Ergebnisse verbindlich bleiben.

Der Code darf dabei Beweismaterial sein.

Er darf aber nicht automatisch zur Spezifikation erklärt werden.

Wer Legacy-Code rekonstruiert, braucht zwei Wahrheiten: die technische Wahrheit darüber, was das System heute tut, und die fachliche Wahrheit darüber, was es künftig tun soll.

Diese beiden Wahrheiten können übereinstimmen, müssen es aber nicht.

Genau deshalb ist Requirements Engineering bei einer Rekonstruktion keine Dokumentationsarbeit am Rand. Es ist Teil der eigentlichen Architekturarbeit.

Denn bevor eine neue Grenze dauerhaft Verantwortung übernehmen kann, muss klar sein, welche Verantwortung sie überhaupt übernehmen soll.

Fachliches Verhalten schützen, nicht die alte Implementierung

Damit wird auch die Teststrategie wichtig.

Dieser Abschnitt ist ausdrücklich kein Argument gegen Unit Tests.

Neu rekonstruierter Code sollte selbstverständlich dort mit Unit-, Integration- oder Component-Tests abgesichert werden, wo diese Tests sinnvoll sind. Eine saubere neue Domainlogik profitiert weiterhin davon, kleine Regeln schnell und präzise testen zu können.

Für die Ablösung eines Legacy-Slices besitzt jedoch eine andere Art von Test strategisch häufig mehr Wert: ein Test, der das fachlich relevante Verhalten unabhängig von der konkreten internen Struktur verteidigt.

Denn genau diese interne Struktur soll möglicherweise verschwinden.

Klassen werden entfernt. Services werden anders geschnitten. State Management verändert sich. Modulgrenzen verschieben sich. Algorithmen werden ersetzt.

Tests, die stark an diese Implementierungsdetails gebunden sind, dürfen dann gemeinsam mit ihnen verschwinden.

Was nicht versehentlich verschwinden darf, ist das bestätigte fachliche Verhalten.

Deshalb sind für die Vorbereitung einer Rekonstruktion fachliche End-to-End- beziehungsweise Acceptance-Tests besonders wertvoll.

Mit „End-to-End“ ist dabei ausdrücklich nicht zwangsläufig eine gigantische Selenium-, Playwright- oder Cypress-Suite gemeint, die jede Mausbewegung durch die Benutzeroberfläche automatisiert.

Gemeint ist:

Ein fachlich relevantes Szenario wird von einer stabilen Eingangsgrenze bis zu einem beobachtbaren fachlichen Ergebnis geprüft.

Angenommen, ein System verarbeitet Verträge.

Gegeben sei ein fachlicher Ausgangszustand X.

Wenn der Vorgang Y ausgeführt wird, muss anschließend Zustand Z entstehen, das entsprechende Ergebnis persistiert werden und gegebenenfalls eine fachlich relevante äußere Wirkung A beobachtbar sein.

Für ein Frontend-Feature kann die geeignete Eingangsgrenze tatsächlich der Browser sein; für einen fachlichen Backend-Prozess kann ein sinnvoller Test dagegen eher so aussehen:

API → fachliche Verarbeitung → Persistenz / beobachtbares Ergebnis

Entscheidend ist nicht das Werkzeug, sondern die Grenze.

Der Test soll den Feature-Slice verteidigen, nicht seine bisherige Implementierung.

Characterization ist noch keine Acceptance

Hier hilft erneut eine Unterscheidung aus der Legacy-Arbeit.

Feathers verwendet Characterization Tests, um das tatsächliche Verhalten eines vorhandenen Systems festzuhalten. Das ist besonders wertvoll, wenn die ursprünglichen Anforderungen fehlen oder niemand mehr sicher weiß, welche Randfälle tatsächlich auftreten. Sein Buch stellt solche Tests in den größeren Zusammenhang, bestehende Systeme zunächst unter Kontrolle zu bekommen, bevor riskantere Veränderungen vorgenommen werden.

Bei einer Rekonstruktion sollte Characterization jedoch nicht automatisch zu Acceptance werden.

Characterization beantwortet:

Was tut das bestehende System tatsächlich?

Acceptance beantwortet:

Welches Verhalten soll fachlich auch nach der Rekonstruktion gelten?

Dazwischen liegt eine fachliche Entscheidung.

Das ist wichtig, weil ein historischer Bug nicht allein dadurch zur Business Rule wird, dass er seit zwölf Jahren produktiv ist.

Andererseits kann selbst ungewöhnliches Verhalten inzwischen Teil eines externen Vertrags geworden sein. Ein Kunde, ein angeschlossenes System oder ein betrieblicher Prozess kann sich darauf verlassen.

Deshalb führt ein sinnvoller Weg nicht direkt von Legacy-Code zu neuer Implementierung.

Er sieht eher so aus:

Legacy-Code → beobachtetes Verhalten → Characterization → fachliche Bewertung → bestätigtes Requirement → Acceptance-/E2E-Test → neue Implementierung

E2E-Tests ersetzen kein Requirements Engineering. Sie machen bestätigte Requirements ausführbar.

Genau dadurch können sie zur äußeren Klammer der Rekonstruktion werden.

Die Rekonstruktion sollte nicht die alte Implementierung konservieren, sondern das fachlich bestätigte Verhalten.

Die Absicherung entsteht vor der Rekonstruktion

Der Zeitpunkt ist dabei entscheidend.

Fachliche Acceptance-Tests entfalten ihren größten Wert nicht erst, nachdem eine neue Implementierung fertiggestellt wurde.

Dann lautet die Frage nur noch:

Haben wir ungefähr dasselbe gebaut?

Für eine kontrollierte Rekonstruktion sollten die relevanten Szenarien möglichst vor dem eigentlichen Herausschneiden des Slices feststehen.

Dadurch entsteht ein Schutzzaun, bevor die alte Struktur verändert wird.

Das bedeutet nicht, dass jede letzte Regel vorab vollständig bekannt sein muss. Gerade bei einem Big Ball of Mud werden während der Arbeit weitere Sonderfälle sichtbar werden.

Aber bevor ein Slice Verantwortung übernimmt, sollte möglichst klar sein, welches fachliche Verhalten er verteidigen muss.

Diese Szenarien müssen von der Fachseite bestätigt werden.

Erst dadurch entsteht etwas, das tatsächlich als Vertrag zwischen alter und neuer Implementierung dienen kann.

Bevor ein Slice rekonstruiert wird, sollte möglichst klar sein, welches fachliche Verhalten die neue Implementierung verteidigen muss.

So verhindert das Team gleichzeitig zwei Extreme.

Es konserviert nicht blind jede historische Eigenheit.

Es ersetzt aber auch nicht versehentlich fachlich relevantes Verhalten durch eine technisch elegantere Interpretation.

Nicht nach Ordnern schneiden

Der nächste Slice sollte nicht danach ausgewählt werden, welcher Ordner im Repository besonders hässlich aussieht.

Technische Strukturen sind bei einem Big Ball of Mud gerade kein verlässlicher Hinweis darauf, wo fachliche Grenzen liegen.

Ein guter Kandidat besitzt möglichst einen nachvollziehbaren Business Purpose, eine erkennbare Eingangsgrenze und ein beobachtbares fachliches Ergebnis.

Er sollte klein genug sein, damit das Team ihn tatsächlich verstehen und kontrolliert übernehmen kann.

Bei der Auswahl können unterschiedliche Faktoren eine Rolle spielen:

• aktuelle Featurearbeit,
• wirtschaftlicher Nutzen,
• Änderungsfrequenz,
• bekannte Schmerzpunkte,
• technisch verfügbare Seams,
• Risiken,
• Abhängigkeiten zu anderen Bereichen.

Daraus sollte kein universelles Scoring-Modell konstruiert werden.

Welcher Slice zuerst sinnvoll ist, hängt stark vom konkreten System ab.

Und manche Big Balls of Mud besitzen zunächst überhaupt keine ausreichend belastbaren fachlichen Grenzen.

Dann ist genau das die erste Aufgabe: einen Bereich so weit kontrollierbar zu machen, dass ein späterer Schnitt überhaupt möglich wird.

Rekonstruktion als Folge kleiner Produktentscheidungen

Mit einem expliziten Mandat kann daraus ein wiederkehrendes Arbeitsmodell entstehen.

Nicht als universelle Methode, sondern als Denkrahmen:

1. Fachlichen Ausschnitt identifizieren. Nicht von Dateien ausgehen, sondern von einer fachlichen Verantwortung, die sinnvoll übernommen werden kann.
2. Requirements mit der Fachseite bestätigen. Klären, welche Regeln, Ergebnisse und Sonderfälle künftig tatsächlich gelten sollen.
3. Aktuelles relevantes Verhalten verstehen. Code, Logs, bestehende Tests, Dokumentation, Nutzerwissen und beobachtbares Produktionsverhalten können dafür gemeinsam notwendig sein.
4. Fachliche Acceptance-/E2E-Tests vorbereiten. Das bestätigte Soll-Verhalten wird möglichst unabhängig von der zu ersetzenden internen Struktur ausführbar gemacht.
5. Zielgrenze anhand gemeinsamer Architecture Guidelines bestimmen. Der neue Slice soll nicht nur lokal ordentlich aussehen, sondern Teil derselben zukünftigen Architektur werden wie die übrigen rekonstruierten Bereiche.
6. Benötigte Seams und Integrationspunkte herstellen. Nur so viel Legacy-Struktur verändern, wie nötig ist, um Verantwortung kontrolliert verschieben zu können.
7. Neue Implementierung rekonstruieren. Innerhalb der neuen Grenze können passende technische Patterns und Tests verwendet werden.
8. Kontrolliert auf den neuen Pfad umleiten. Der Wechsel sollte beobachtbar und möglichst reversibel beziehungsweise begrenzt sein.
9. Verhalten beobachten und validieren. Automatisierte Tests sind wichtig, ersetzen aber nicht die Beobachtung des realen Systems.
10. Alten Pfad entfernen. Die alte Verantwortung darf nicht dauerhaft als zweite Wahrheit weiterleben.
11. Nächsten Slice auswählen. Erst dann wird die nächste Wette eingegangen.

Die Reihenfolge kann im konkreten Projekt variieren. Manche Schritte überlappen sich, während der Characterization kann deutlich werden, dass der ursprünglich geplante Slice zu groß ist, oder eine technische Abhängigkeit erzwingt zunächst eine andere Grenze. Entscheidend ist nicht die exakte Prozessfolge, sondern dass jeder Schritt einen überschaubaren, überprüfbaren Zwischenzustand erzeugt.

Der alte Pfad muss irgendwann verschwinden

Gerade bei strangler-artiger Modernisierung lässt sich ein unangenehmer Schritt leicht aufschieben: das tatsächliche Entfernen der alten Implementierung.

Das neue Feature funktioniert, der neue Service läuft und der neue Slice ist produktiv. Warum also noch einmal Risiko eingehen und den alten Code löschen?

Weil sonst keine Verantwortung verschoben wurde.

Es wurde lediglich Verantwortung dupliziert.

Bleiben beide Pfade dauerhaft bestehen, entstehen neue Fragen:

• Welche Implementierung ist jetzt die maßgebliche?
• Müssen beide geändert werden?
• Sind ihre Daten weiterhin synchron?
• Wer besitzt welche Variante?
• Welche Tests gelten für welchen Pfad?
• Wann darf der alte wirklich verschwinden?

Auf diese Weise kann eine Modernisierung paradoxerweise die Menge an System erhöhen, ohne den Legacy-Anteil nennenswert zu reduzieren.

Eine Rekonstruktion ist erst abgeschlossen, wenn die alte Verantwortung tatsächlich verschwunden ist.

Nicht jede temporäre Brücke kann unmittelbar entfernt werden. Manche Übergangsstrukturen müssen mehrere Releases überleben.

Aber ihre Entfernung muss zum Arbeitspaket gehören.

Sonst ist „später“ lediglich ein anderer Name für „wahrscheinlich nie“.

Was „nicht nebenbei“ wirklich bedeutet

An dieser Stelle scheint ein Widerspruch zu entstehen.

Einerseits lautet die Leitthese:

Du kannst einen Big Ball of Mud nicht alleine retten. Und schon gar nicht nebenbei.

Andererseits wurde für Organisationen ohne eigenes Modernisierungsprogramm empfohlen, ohnehin notwendige Features als mögliche Schnittpunkte für taktische Rekonstruktion zu nutzen.

Beides widerspricht sich nicht.

„Nicht nebenbei“ bedeutet nicht:

Jede strukturelle Verbesserung benötigt ein eigenes Millionenbudget.

Es bedeutet:

Strukturelle Rekonstruktion darf nicht als unsichtbare private Zusatzaufgabe einzelner Entwickler behandelt werden.

Wenn ein Feature als Gelegenheit für Rekonstruktion genutzt wird, muss diese Entscheidung sichtbar sein.

Sie muss gemeinsam getragen werden.

Der zusätzliche Aufwand muss wirtschaftlich in den Featurekontext eingeordnet sein.

Und die entstehende Struktur muss gemeinsamen Regeln folgen.

Das ist etwas grundsätzlich anderes als:

„Ich refactore abends noch ein bisschen das System.“

Ein Big Ball of Mud kann gerade deshalb lange überleben, weil außergewöhnliche Einzelne strukturelle Probleme immer wieder kompensieren.

Wenn dieselbe Form der Kompensation nun zur Modernisierungsstrategie wird, hat sich das Prinzip nicht geändert.

Nur die Richtung der Heldentat.

Und wenn die Organisation nicht mitzieht?

Existiert kein Mandat für ein größeres Sanierungsprogramm, bleiben trotzdem technische Handlungsmöglichkeiten.

Das Team kann kleine taktische Arbeitspakete identifizieren. Erfahrene Entwickler können gemeinsame Guidelines festlegen. Notwendige Featurearbeit kann als möglicher Schnittpunkt verwendet werden. Erweiterung und Rekonstruktion können als reale Alternativen geschätzt werden. Neue Änderungen können klein und überprüfbar gehalten werden.

Dieser Handlungsspielraum ist nicht bedeutungslos: Über Jahre können aus solchen Entscheidungen tatsächlich neue belastbare Bereiche entstehen. Aber auch dieser Weg besitzt eine Grenze.

Es gibt keinen Refactoring-Trick, mit dem ein Entwicklungsteam dauerhaft fehlendes organisatorisches Mandat kompensieren kann.

Wenn strukturelle Arbeit grundsätzlich nicht zulässig ist, keine zusätzliche Lieferzeit akzeptiert wird und jede Änderung ausschließlich nach dem kurzfristig billigsten Implementierungsweg bewertet werden muss, ist auch der technische Handlungsspielraum begrenzt.

Das ist zunächst keine Bewertung der Organisation.

Möglicherweise sind ihre Prioritäten wirtschaftlich nachvollziehbar.

Es ist lediglich eine Diagnose dessen, was unter diesen Bedingungen technisch realistisch erreichbar ist.

Eine einzelne Person kann dieses Mandat jedenfalls nicht ersetzen.

Und genau damit schließt sich der Kreis.

Fazit

Lokale Refactorings sowie die Techniken von Fowler und Feathers bleiben wichtige Werkzeuge für die Arbeit an gewachsenen Systemen. Ein Big Ball of Mud erreicht jedoch irgendwann eine Größenordnung und systemische Verflechtung, bei der viele voneinander unabhängige Verbesserungen nicht automatisch wieder zu einer konsistenten Gesamtarchitektur werden.

Dann braucht es eine schrittweise Rekonstruktion entlang fachlicher Slices, eine bestätigte Vorstellung davon, welches Verhalten erhalten werden soll, sowie Acceptance- beziehungsweise E2E-Tests, die dieses Verhalten unabhängig von der alten Implementierung verteidigen. Gemeinsame Architecture Guidelines sorgen dafür, dass unterschiedliche Entwickler kompatible Teile derselben zukünftigen Struktur erzeugen. Hinzu kommen organisatorische Zeit und Legitimation in dem Umfang, den die jeweilige Situation tatsächlich zulässt.

Strangler Fig liefert dafür ein besonders wertvolles Denkmodell: nicht die gesamte Unsicherheit auf einmal übernehmen, sondern einen Ausschnitt verstehen, fachlich bewerten, absichern, rekonstruieren, die Verantwortung auf den neuen Pfad verschieben, den alten Pfad entfernen und erst dann die nächste Wette eingehen. Modernisierung wird dadurch nicht automatisch einfach, aber der Umfang dessen, was gleichzeitig verstanden und beherrscht werden muss, bleibt begrenzter.

Damit führt die Argumentation zurück zur Ausgangsthese:

Ein Big Ball of Mud sollte niemals von einer einzelnen Person gerettet werden.

Das liegt nicht daran, dass eine einzelne Person zwangsläufig zu wenig wissen oder leisten könnte. Vielleicht gibt es tatsächlich jemanden, der das alte System außergewöhnlich gut versteht, Grenzen schneller erkennt als andere und zum wichtigsten Ausgangspunkt der Rekonstruktion wird. Problematisch wäre vielmehr, wenn das zukünftige System erneut von genau dieser außergewöhnlichen Person abhängig bliebe.

Ein System, dessen Architektur nur funktioniert, solange ein einzelner Mensch alle Zusammenhänge im Kopf hält, reproduziert bereits einen Teil des Problems, aus dem es eigentlich herauskommen sollte.

Die neue Architektur darf nicht nur im Kopf des Menschen existieren, der den alten Big Ball of Mud am besten verstanden hat.

Der Ausweg aus einem Big Ball of Mud ist deshalb keine Heldengeschichte. Er ist eine gemeinsam getragene Rekonstruktion.

Literatur

• Feathers, Michael C. (2004): Working Effectively with Legacy Code. Prentice Hall / Pearson, ISBN 978-0-13-117705-5. Das Buch behandelt unter anderem Characterization Tests, das Seam Model und Techniken zum kontrollierten Verändern schwer testbarer Legacy-Systeme. Pearson
• Fowler, Martin (2004): Original Strangler Fig Application. Ursprüngliche Beschreibung der schrittweisen Ablösung als Alternative zu einem großen Cut-over. martinfowler.com
• Fowler, Martin (2024): Strangler Fig. Aktualisierte Einordnung des Strangler-Fig-Prinzips in inkrementelle Legacy-Modernisierung. martinfowler.com
• Fowler, Martin (2018): Refactoring: Improving the Design of Existing Code, 2. Auflage. Addison-Wesley. Ergänzend: Definition of Refactoring.
• Jørgensen, Magne; Nereng, Johan; Torrissen, Tobias (2026): A survey of the decommissioning of IT systems. Journal of Systems and Software, 241, 113016. DOI: 10.1016/j.jss.2026.113016.
• Liu, Kecheng; Alderson, Albert; Qureshi, Zubair (1999): Requirements recovery from legacy systems by analysing and modelling behaviour. Proceedings of the International Conference on Software Maintenance, S. 3–12. DOI: 10.1109/ICSM.1999.792485.