Big Ball of Mud – Architektur unter Realbedingungen

Es gibt keinen Mangel an Büchern und Artikeln über Softwarearchitektur.

Wir wissen, wie eine saubere Architektur aussehen kann. Wir kennen Schichten, Ports und Adapter, fachliche Schnitte, modulare Monolithen, Microservices, Event-driven Architecture, Domain-driven Design und eine kaum noch überschaubare Zahl weiterer Muster und Prinzipien.

Auf dem Papier beginnt Softwarearchitektur erstaunlich oft mit einem weißen Blatt.

In der Realität beginnt sie häufig mit einem Repository.

Und dieses Repository ist zehn Jahre alt.

Es hat mehrere Generationen von Entwicklern gesehen. Unterschiedliche Architekturstile. Unterschiedliche Frameworks. Zeitdruck. Reorganisationen. Strategiewechsel. Abgekündigte Produkte. Deadlines, die wichtiger waren als die nächste Wartungsrunde. Provisorien, die nie wieder angefasst wurden. Und selbstverständlich jene eine Übergangslösung, die seit sieben Jahren produktiv ist.

Diese Serie handelt von solchen Systemen.

Nicht davon, wie Architektur aussehen sollte.

Sondern davon, was passiert, wenn sie es nicht mehr tut.

Die Architektur, über die wir erstaunlich wenig sprechen

Brian Foote und Joseph Yoder beschrieben den Big Ball of Mud bereits 1997. Ihre Beobachtung war bemerkenswert nüchtern: Während sich die Softwarearchitektur intensiv mit wohlgeordneten Architekturstilen beschäftigt, ist eine der in der Praxis häufig anzutreffenden Formen gerade diejenige ohne klar erkennbare Struktur.

Ein Big Ball of Mud ist nicht einfach alte Software.

Er ist auch nicht automatisch ein Monolith.

Ein großer Monolith kann hervorragend strukturiert sein. Er kann klare fachliche Grenzen besitzen, konsistente Abhängigkeiten und wiederkehrende Lösungsprinzipien.

Beim Big Ball of Mud geht etwas anderes verloren:

die erkennbare innere Struktur.

Grenzen verschwimmen. Verantwortlichkeiten überlappen. Ursprünglich lokale Entscheidungen breiten sich aus. Abhängigkeiten entstehen dort, wo vorher keine waren. Gemeinsame Services werden immer gemeinsamer. Ausnahmen werden zu Regeln. Wissen darüber, was gefahrlos geändert werden kann, befindet sich irgendwann weniger in der Architektur als in den Köpfen einzelner Menschen.

Das geschieht selten in einem großen Knall.

Ein Big Ball of Mud entsteht meistens schrittweise.

Und gerade deshalb ist er so gefährlich.

Das ist kein theoretisches Problem für mich

Der größte Teil meiner beruflichen Arbeit begann nicht auf einer grünen Wiese.

Wenn ich grob zurückblicke, waren wahrscheinlich 90 Prozent der Systeme, mit denen ich intensiver zu tun hatte, bereits in irgendeiner Form architektonisch erodiert.

Diese Zahl ist selbstverständlich keine Statistik. Sie ist meine persönliche Stichprobe — und vermutlich deutlich verzerrt. Gerade in den letzten Jahren wurde ich häufig dann in Projekte geholt, wenn es bereits Probleme gab. Wer als Feuerwehr gerufen wird, sollte sich nicht wundern, überdurchschnittlich viele Brände zu sehen.

Trotzdem fällt es mir zunehmend schwer, meine Erfahrungen nur als persönliche Ausreißer abzutun.

Die Forschung liefert dafür zumindest einige interessante Hinweise.

Besker, Martini und Bosch untersuchten, wie viel Entwicklungszeit durch Technical Debt verloren geht. In ihrer empirischen Untersuchung berichteten Entwickler im Durchschnitt von rund 23 Prozent verlorener Arbeitszeit durch Technical Debt. Besonders viel zusätzliche Arbeit entstand unter anderem durch weiteres Testen und zusätzliche Analyse des bestehenden Codes.

Eine Folgestudie von Besker, Ghanbari, Martini und Bosch beschäftigte sich ausdrücklich mit dem menschlichen Aspekt. Technical Debt wurde mit fehlendem Fortschritt und Zeitverschwendung verbunden; die Ergebnisse weisen darauf hin, dass er die Moral von Entwicklern beeinträchtigt, während aktives Technical-Debt-Management den gegenteiligen Effekt haben kann.

Das ist bemerkenswert.

Denn über Technical Debt sprechen wir meistens in Geld.

Oder in Story Points.

Oder in Lead Time.

Sehr viel seltener sprechen wir darüber, was es mit den Menschen macht, die jeden Tag darin arbeiten müssen.

Das Problem kennt keine einzelne Branche

Ich habe besonders problematische Systeme im medizinischen Umfeld und im Public Sector erlebt. Aus Gesprächen und Berichten entsteht schnell der Eindruck, bestimmte Branchen seien für Legacy besonders anfällig.

Eine seriöse Rangliste der „schlimmsten Branchen” habe ich allerdings nicht gefunden.

Und ich halte wenig davon, eine interessante Anekdote durch eine erfundene Statistik aufzuwerten.

Was sich belegen lässt, ist bereits deutlich genug.

Eine empirische Untersuchung dreier realer Automotive-Systeme zeigte eine erhebliche Vernetzung ihrer Features. Weniger als zwölf Prozent der untersuchten Architekturkomponenten waren für mehr als neunzig Prozent der Feature-Abhängigkeiten verantwortlich. Gleichzeitig waren sich Entwickler eines großen Teils dieser Abhängigkeiten nicht bewusst.

Im Public Sector ist das Problem noch direkter dokumentiert.

Die britische Regierung schätzte 2025, dass rund 28 Prozent der Systeme zentraler Regierungsbehörden Legacy-Technologie darstellen. Bei einzelnen NHS-Organisationen und Polizeibehörden schwankten die gemeldeten Anteile je nach Organisation zwischen ungefähr zehn und sechzig bis siebzig Prozent.

Das US Government Accountability Office untersuchte 2025 wiederum 69 Legacy-Systeme von Bundesbehörden. Die elf kritischsten waren zwischen etwa 23 und 60 Jahre alt und kosteten zusammen rund 754 Millionen US-Dollar pro Jahr für Betrieb und Wartung. Mehrere liefen mit veralteten Programmiersprachen, nicht mehr unterstützter Hard- oder Software oder bekannten Sicherheitslücken.

Das bedeutet nicht, dass jedes Legacy-System ein Big Ball of Mud ist.

Das ist eine wichtige Unterscheidung.

Aber es zeigt, dass wir nicht über ein exotisches Randproblem der Softwareentwicklung sprechen.

Wir bauen neue Systeme.

Und gleichzeitig verbringt ein erheblicher Teil unserer Branche seine Zeit damit, bestehende Systeme am Leben zu halten.

Fass einen Knoten an

Der folgende Graph stammt aus einem realen Frontend, an dem ich gearbeitet habe.

Die Bezeichnungen wurden für die Veröffentlichung vollständig anonymisiert und in die fiktive Domäne einer ACME Factory übertragen. Die Struktur dagegen wurde nicht verändert: Nodes, Abhängigkeiten, Größen und Topologie entsprechen dem analysierten System.

Versuche nicht, ihn zunächst zu verstehen.

Greife einfach irgendeinen Knoten und bewege ihn.

Interaktiven Dependency Graph öffnen ↗

Greife einen beliebigen Knoten und bewege ihn. Beobachte nicht nur, was sich bewegt, sondern auch, wie lange das System nach dem Loslassen weiter reagiert.

Das Interessante an dieser Visualisierung ist für mich inzwischen gar nicht mehr ihre Größe.

Es ist die Bewegung.

Es spielt nahezu keine Rolle, welchen Knoten man greift. Die Bewegung setzt sich durch das gesamte System fort. Lässt man ihn wieder los, beruhigt sich der Graph nicht sofort. Er schwingt lange nach.

Natürlich ist das zunächst nur Physik einer D3-Force-Simulation. D3 versucht, eine große Menge miteinander verbundener Nodes neu anzuordnen.

Aber als Metapher für die Arbeit an einem stark gekoppelten System könnte ich mir kaum eine bessere Visualisierung wünschen.

Eine lokale Änderung ist lokal abgeschlossen.

Ihre Auswirkungen müssen es nicht sein.

Du änderst heute einen Service.

Der Code kompiliert. Die Tests laufen. Das Feature funktioniert.

Tage später fällt an einer völlig anderen Stelle etwas auf.

Die Person, die den Fehler findet, kennt die ursprüngliche Änderung vielleicht nicht. Die Person, die sie durchgeführt hat, stellt keinen Zusammenhang mehr her. Ursache und Wirkung liegen nicht nur strukturell, sondern inzwischen auch zeitlich auseinander.

Das System schwingt nach.

Irgendwann wird technische Kopplung menschlich

An diesem Punkt reicht es mir nicht mehr, nur über Clean Code zu sprechen.

In einem stark erodierten System steigen nicht ausschließlich Wartungskosten.

Der notwendige mentale Kontext wächst.

Eine Änderung erfordert Wissen über immer größere Teile des Systems. Entwickler verbringen mehr Zeit mit Analyse. Änderungen werden vorsichtiger. Reviews schwieriger. Tests umfangreicher. Fehler schwerer zuzuordnen.

Gleichzeitig konzentriert sich Wissen.

Einige Menschen verstehen bestimmte Bereiche noch.

Also werden genau diese Menschen immer häufiger gefragt.

Sie unterstützen Kollegen. Analysieren Seiteneffekte. Reparieren Produktionsprobleme. Übernehmen Reviews. Erklären historische Entscheidungen. Und sollen nebenbei jene strukturellen Probleme beseitigen, aufgrund derer sie überhaupt ständig gebraucht werden.

Damit beginnt ein Kreislauf:

Je problematischer die Architektur wird, desto stärker wird die Organisation von einzelnen Wissensträgern abhängig.

Je stärker sie von diesen Menschen abhängig wird, desto weniger Zeit haben diese Menschen, das eigentliche Problem zu lösen.

Und wenn einer von ihnen geht, verschwindet nicht nur Entwicklungskapazität.

Es verschwindet Architekturwissen.

Ich habe erlebt, was solche Systeme mit Menschen machen können.

Ich habe in einem Projekt innerhalb von zwei Jahren zwölf Kündigungen erlebt. Zwei Entwicklungsleiter gingen. Drei Entwickler, mit denen ich unmittelbar gearbeitet habe, fielen mit Burnout aus.

Ich habe Menschen daran verzweifeln sehen.

Und ich bin selbst an diesem Projekt gescheitert.

Nicht daran, einen besseren technischen Entwurf zu finden.

Sondern an Organisation, Verständnis, Prioritäten und Widerstand.

Irgendwann reicht es nicht mehr, technisch recht zu haben.

Ein Big Ball of Mud ist kein Refactoring-Ticket

Genau deshalb möchte ich in dieser Serie nicht so tun, als ließe sich ein Big Ball of Mud mit einigen Architekturregeln reparieren.

Natürlich werden wir über technische Handlungsmöglichkeiten sprechen.

Sehr ausführlich sogar.

Wir werden uns ansehen, wie man Grenzen wieder sichtbar machen kann. Wie man Abhängigkeiten analysiert. Wo sich Schnitte anbieten. Wann ein Strangler-Ansatz sinnvoll sein kann. Wann man stabilisieren sollte, bevor man umbaut. Wie man Risiken begrenzt und Veränderungen überhaupt wieder lokal möglich macht.

Aber das kommt später.

Denn zunächst müssen wir uns mit einer unangenehmeren Wahrheit beschäftigen:

Ein Big Ball of Mud ist kein rein technisches Problem.

Seine Architektur ist über Jahre gemeinsam mit seiner Organisation entstanden.

In ihm stecken Priorisierungen, Teamstrukturen, Budgetentscheidungen, Zeitdruck, Personalwechsel, Releaseprozesse, fehlendes Wissen, Verantwortungsgrenzen und politische Entscheidungen.

Wer nur den Code verändern will, verändert deshalb häufig nur einen Teil des Systems.

Und manchmal den kleineren.

Die wirtschaftliche Perspektive

Technical Debt heißt nicht ohne Grund Debt.

Schulden sind zunächst nicht zwangsläufig irrational.

Es kann vollkommen sinnvoll sein, heute eine pragmatische Lösung zu wählen und dafür später höhere Kosten in Kauf zu nehmen.

Problematisch wird es, wenn niemand mehr weiß, wie hoch die Schulden sind.

Wenn niemand mehr weiß, wer sie aufgenommen hat.

Wenn keine Tilgung geplant ist.

Und wenn immer neue Kredite aufgenommen werden, nur um die Zinsen der alten bedienen zu können.

Die wirtschaftlichen Folgen erscheinen dann oft zunächst als Entwicklungsproblem:

Features dauern länger.

Tests werden teurer.

Fehleranalysen dauern länger.

Releases werden riskanter.

Doch irgendwann werden daraus Unternehmensprobleme.

Modernisierungen werden so teuer, dass sie immer wieder verschoben werden. Neue Produkte müssen mit alten Strukturen kompatibel bleiben. Sicherheitsrisiken können nicht lokal beseitigt werden. Fachliche Änderungen benötigen technische Großprojekte.

Das System beginnt, Entscheidungen über das Unternehmen zu treffen.

Nicht umgekehrt.

Die soziologische Perspektive

Mich interessiert in dieser Serie deshalb mindestens genauso sehr, was auf der anderen Seite des Repositories passiert.

Was passiert mit einem Team, wenn niemand mehr zuverlässig abschätzen kann, welche Auswirkungen eine Änderung haben wird?

Was passiert mit Verantwortung, wenn Fehler kaum noch eindeutig einem Bereich zugeordnet werden können?

Was passiert mit neuen Entwicklern, wenn sie Monate benötigen, um überhaupt zu verstehen, wo sie gefahrlos arbeiten können?

Was passiert mit erfahrenen Entwicklern, wenn aus Erfahrung irgendwann permanente Zuständigkeit wird?

Was passiert mit einer Organisation, wenn diejenigen, die am deutlichsten vor strukturellen Problemen warnen, gleichzeitig als diejenigen erscheinen, die Veränderungen langsamer und teurer machen?

Und was passiert, wenn alle Beteiligten wissen, dass etwas grundsätzlich nicht funktioniert, aber niemand mehr einen realistischen Weg heraus sieht?

Das sind keine Fragen über Angular.

Es sind Fragen über Organisationen.

Nicht jedes System lässt sich retten

Auch das gehört für mich zu einer ehrlichen Betrachtung.

Es gibt immer Handlungsmöglichkeiten.

Aber nicht jede davon lautet:

Wir reparieren das System.

Man kann versuchen, es zu verändern.

Man kann lernen, mit ihm zu arbeiten und seine Risiken zu begrenzen.

Man kann einzelne Bereiche ablösen.

Man kann neu bauen.

Man kann akzeptieren, dass bestimmte Strukturen bleiben werden.

Und als Entwickler kann man irgendwann auch entscheiden, dass man selbst nicht mehr Teil dieses Systems sein möchte.

Welche Entscheidung sinnvoll ist, hängt nicht nur von Codequalität ab.

Sie hängt von Kosten, Risiken, Menschen, Zeit, Produktstrategie und vor allem davon ab, ob eine Organisation Veränderung tatsächlich ermöglicht.

Eine technische Analyse kann zeigen, wo das Problem liegt.

Sie kann nicht erzwingen, dass eine Organisation es lösen will.

Worum es in dieser Serie geht

Diese Serie wird deshalb keine Sammlung von Horrorgeschichten.

Und sie wird auch kein Katalog mit zwölf einfachen Schritten vom Big Ball of Mud zur perfekten Architektur.

Wir werden zunächst untersuchen, was ein Big Ball of Mud eigentlich ist.

Wie er entsteht.

Woran man ihn erkennt.

Warum ein Monolith noch lange kein Big Ball of Mud ist.

Warum solche Systeme erstaunlich lange funktionieren können.

Welche technischen, wirtschaftlichen und menschlichen Gefahren entstehen.

Warum Organisationen auf erkennbare Probleme häufig trotzdem nicht reagieren.

Und welche Handlungsmöglichkeiten bleiben, wenn man selbst mitten in einem solchen System sitzt.

Dabei wird es technische Werkzeuge geben.

Architekturmuster.

Analysemethoden.

Migrationsstrategien.

Aber sie stehen nicht am Anfang.

Am Anfang steht etwas anderes:

das Problem ernst zu nehmen.

Nicht nur für den Code.

Sondern für die Menschen, die ihn jeden Tag verändern müssen.

Quellen

Brian Foote, Joseph W. Yoder: Big Ball of Mud. Pattern Languages of Program Design 4, Ursprung 1997.

Terese Besker, Antonio Martini, Jan Bosch: Software Developer Productivity Loss Due to Technical Debt – A Replication and Extension Study Examining Developers’ Development Work. Journal of Systems and Software 156, 2019, S. 41–61. DOI: 10.1016/j.jss.2019.06.004.

Terese Besker, Hadi Ghanbari, Antonio Martini, Jan Bosch: The Influence of Technical Debt on Software Developer Morale. Journal of Systems and Software 167, 2020, 110586. DOI: 10.1016/j.jss.2020.110586.

Jesper Olsson, Erik Risfelt, Terese Besker, Antonio Martini, Richard Torkar: Measuring Affective States from Technical Debt: A Psychoempirical Software Engineering Experiment. 2020.

Andreas Vogelsang: Feature Dependencies in Automotive Software Systems: Extent, Awareness, and Refactoring. Journal of Systems and Software, 2019. DOI: 10.1016/j.jss.2019.110458.

UK Department for Science, Innovation and Technology / Government Digital Service: State of Digital Government Review. 2025.

U.S. Government Accountability Office: Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems. GAO-25-107795, Juli 2025.