Was ist ein Big Ball of Mud?

„Big Ball of Mud“ gehört nicht gerade zu den Begriffen, mit denen man ein Architektur-Assessment vor einem Lenkungskreis eröffnet. Der Name klingt nach Entwickler-Slang, vielleicht sogar nach Polemik. Wer sein eigenes System so bezeichnet, muss zumindest mit Rückfragen rechnen.

Ganz aus der Luft gegriffen ist der Begriff trotzdem nicht. Er stammt aus der Softwarearchitektur- und Pattern-Literatur. Brian Foote und Joseph Yoder stellten ihre Arbeit Big Ball of Mud 1997 auf der Pattern Languages of Programs Conference vor; später erschien sie in Pattern Languages of Program Design 4. Seitdem wird der Begriff auch in wissenschaftlicher Software-Engineering-Literatur weiter aufgegriffen, unter anderem in Arbeiten zu Architecture Erosion und Design Erosion.

Das macht ihn allerdings nicht zu einer formal standardisierten Diagnose. Es gibt keine ISO-Definition, keinen allgemein akzeptierten Messwert und keinen Schwellenwert, ab dem eine Anwendung objektiv vom „normalen“ Legacy-System zum Big Ball of Mud wird.

Der Begriff funktioniert vielmehr als erstaunlich präzise Beschreibung eines strukturellen Zustands.

Und vor allem beschreibt er etwas anderes als „Monolith“.

Was Foote und Yoder mit dem Big Ball of Mud meinten

Foote und Yoder fassen ihre Beschreibung mit einem Satz zusammen:

“A BIG BALL OF MUD is a casually, even haphazardly, structured system.”

Gemeint ist ein System, dessen Struktur eher beiläufig oder ungeplant entstanden ist. Seine Organisation wird stärker durch kurzfristige Zweckmäßigkeit als durch einen konsistenten Entwurf bestimmt.

Foote und Yoder beschreiben Systeme, die durch unreguliertes Wachstum und wiederholte pragmatische Reparaturen geprägt sind. Informationen werden über weit voneinander entfernte Teile des Systems geteilt oder mehrfach vorgehalten. Die übergreifende Struktur war entweder nie besonders klar definiert oder ist im Laufe der Zeit so stark erodiert, dass sie kaum noch erkennbar ist.

Dabei ist wichtig, was die Autoren nicht tun.

Sie beschreiben den Big Ball of Mud nicht einfach als Beweis schlechter Softwareentwicklung und auch nicht als moralisches Versagen einzelner Entwickler. Ein wesentlicher Teil ihrer Arbeit beschäftigt sich gerade mit der Frage, warum solche Systeme so häufig entstehen.

Denn kurzfristig können die Entscheidungen, aus denen sie hervorgehen, ausgesprochen vernünftig erscheinen.

Eine pragmatische Änderung ist häufig schneller als eine strukturell saubere Lösung. Eine bestehende Grenze zu umgehen kann günstiger erscheinen, als sie zunächst zu verändern. Ein Prototyp kann seinen Zweck erfüllen und anschließend weiterleben. Eine Anwendung kann über Jahre wachsen, ohne dass zu jedem Zeitpunkt eine umfassende Architekturentscheidung notwendig oder wirtschaftlich sinnvoll wäre.

Das Problem ist deshalb nicht, dass jede einzelne Entscheidung offensichtlich falsch gewesen sein muss.

Problematisch ist, was aus der Summe solcher Entscheidungen für die innere Struktur des Systems wird.

Genau diese Ambivalenz macht den Begriff für mich bis heute interessant.

Wenn Architektur ihre Aussagekraft verliert

Spätere Forschung beschreibt einen verwandten Prozess unter Begriffen wie Architecture Erosion oder Design Erosion.

Li, Liang, Soliman und Avgeriou untersuchten, wie Praktiker Architecture Erosion wahrnehmen. Vereinfacht gesagt beschreibt Architecture Erosion einen Prozess, bei dem sich die tatsächlich implementierte Struktur eines Systems zunehmend von seiner beabsichtigten Architektur entfernt.

Eine mögliche Extremform verbinden die Autoren ausdrücklich mit dem Big Ball of Mud: einem System, dem schließlich eine noch wahrnehmbare, eine perceivable architecture, fehlt.

Diese Formulierung trifft einen wichtigen Punkt.

Architektur verschwindet nicht notwendigerweise physisch aus dem Repository.

Es gibt weiterhin Verzeichnisse. Module. Komponenten. Klassen. Services. Vielleicht existieren sogar aktuelle Architekturdiagramme. Bereiche tragen fachliche Namen. Layer sind im Dateisystem sichtbar.

Das System sieht strukturiert aus.

Nur erklärt diese sichtbare Struktur immer weniger zuverlässig, wie das System tatsächlich funktioniert.

Auch Baum, Dietrich, Anslow und Müller betrachten diesen Prozess aus der Perspektive der Design Erosion. Sie untersuchen, wie sich Verletzungen von Designprinzipien während der Evolution eines Systems entwickeln und ausbreiten können. Der Big Ball of Mud erscheint dabei nicht als Zustand, der plötzlich an einem Dienstagmorgen vorhanden ist, sondern als mögliches Ergebnis fortschreitender struktureller Verschlechterung.

Wie genau dieser Prozess entsteht, ist eine eigene Frage. Darum geht es im nächsten Artikel.

Für die Definition reicht an dieser Stelle zunächst eine andere Beobachtung:

Ein Big Ball of Mud beschreibt nicht die äußere Form eines Systems, sondern den Zustand seiner inneren Struktur.

Oder etwas genauer formuliert:

Ein Big Ball of Mud ist ein Zustand, in dem die sichtbare oder beabsichtigte Struktur des Systems immer weniger zuverlässig erklärt, wie das System tatsächlich organisiert ist.

Diese Formulierung ist keine Definition von Foote und Yoder. Sie ist eine Arbeitsdefinition dieser Serie, abgeleitet aus ihrer ursprünglichen Beschreibung und der späteren Forschung zu Architektur- und Designerosion.

Eine Architektur kann auf dem Papier weiterhin existieren, obwohl ihre Grenzen in der Implementierung immer weniger Wirkung besitzen.

Eine Arbeitsdefinition für Frontends

Auf Frontend-Systeme übertragen bedeutet das zunächst nicht, nach einzelnen Technologien oder einer bestimmten Größe zu suchen.

Eine Codebasis wird nicht deshalb zum Big Ball of Mud, weil sie groß ist, lange existiert, gemeinsam ausgeliefert wird oder viele Entwickler daran arbeiten.

All diese Eigenschaften können sowohl bei hervorragend strukturierten als auch bei vollkommen erodierten Systemen vorkommen.

Entscheidend ist, welche strukturierende Wirkung die Architektur tatsächlich noch besitzt.

Fachliche Grenzen sollten Zuständigkeiten voneinander trennen. Slices sollten begrenzen, welche Teile des Systems voneinander wissen müssen. Layer sollten Verantwortlichkeiten und Abhängigkeitsrichtungen festlegen. Schnittstellen sollten kontrollieren, welche Informationen solche Grenzen passieren.

In einem Big Ball of Mud verlieren diese Grenzen zunehmend ihre Wirkung.

Fachliche Zuständigkeiten vermischen sich. Slice-Grenzen existieren vielleicht weiterhin im Verzeichnisbaum, begrenzen tatsächliche Abhängigkeiten aber immer weniger. Layer besitzen Namen, ihre Abhängigkeitsrichtung wird jedoch nicht mehr zuverlässig eingehalten. Verantwortlichkeiten wandern zwischen Bereichen, und für neue Änderungen wird zunehmend dort angesetzt, wo eine Lösung gerade technisch erreichbar erscheint.

Damit verliert die Architektur genau eine ihrer wichtigsten Funktionen:

Sie hilft immer weniger dabei, aus der Struktur des Systems auf Zuständigkeiten und Auswirkungen von Änderungen zu schließen.

Für Frontends verwende ich deshalb in dieser Serie folgende Arbeitsdefinition:

Ein Frontend wird dort zum Big Ball of Mud, wo seine innere Struktur Änderungen, Verantwortlichkeiten und Abhängigkeiten nicht mehr zuverlässig begrenzt oder verständlich macht.

Das Verzeichnis heißt weiterhin orders. Die Komponente liegt weiterhin unter presentation. Ein Bereich wird weiterhin als eigener fachlicher Slice bezeichnet.

Die interessante Frage ist nur:

Bedeutet das noch etwas?

Welche konkreten Symptome daraus im Frontend entstehen, ist eine eigene Frage. Zyklische Abhängigkeiten, God Services, globale Zustände, Cross-Slice-Abhängigkeiten oder Änderungen mit weitreichenden Seiteneffekten verdienen eine deutlich genauere Betrachtung.

Darum geht es später in dieser Serie im Artikel „Erkennen im Frontend“.

Hier geht es zunächst nur darum, den Zustand zu definieren.

Nicht jeder hässliche Code ist ein Big Ball of Mud

Gerade weil der Begriff so bildhaft ist, lässt er sich leicht überdehnen.

Eine Klasse mit zweitausend Zeilen kann ein Problem sein. Eine schlecht geschnittene Komponente kann teuer werden. Ein einzelner God Service kann ein ernsthaftes Architekturproblem darstellen. Technical Debt kann Entwicklungsarbeit über Jahre belasten.

Keiner dieser Befunde reicht für sich genommen aus, um ein gesamtes System sinnvoll als Big Ball of Mud zu bezeichnen.

Auch Alter ist kein ausreichendes Kriterium.

Ein altes System kann technologische Entscheidungen enthalten, die längst überholt sind, und trotzdem fachlich hervorragend strukturiert sein. Seine Grenzen können auch nach vielen Jahren nachvollziehbar bleiben. Umgekehrt kann eine junge Codebasis innerhalb kurzer Zeit eine Struktur entwickeln, in der Verantwortlichkeiten und Abhängigkeiten kaum noch verständlich sind.

Dasselbe gilt für Größe.

Ein großes fachliches Modell darf komplex sein. Komplexität, die aus dem Problemraum stammt, ist nicht automatisch ein Architekturfehler. Eine Codebasis mit tausenden Dateien kann klar organisiert sein, während eine wesentlich kleinere Anwendung ihre inneren Grenzen bereits weitgehend verloren hat.

Auch Legacy Software ist nicht automatisch ein Big Ball of Mud.

Ein Legacy-System kann veraltete Technologien verwenden, erhebliche Technical Debt besitzen und trotzdem aus fachlich sauber getrennten Bereichen mit stabilen Abhängigkeiten bestehen.

Big Ball of Mud sollte deshalb eine strukturelle Diagnose bleiben und kein Schimpfwort für Software werden, an der wir nicht gerne arbeiten.

Das gilt besonders für einen Begriff, der in Architekturgesprächen erstaunlich häufig an seiner Stelle verwendet wird.

Ein Monolith ist kein Big Ball of Mud

„Wir haben leider einen Monolithen.“

Ich habe diesen Satz in verschiedenen Varianten in mehreren Architektur-Assessments gehört. Meist wird er mit einem Unterton ausgesprochen, als wäre damit die Diagnose bereits gestellt.

Technisch sagt der Satz zunächst erstaunlich wenig über die Qualität der inneren Architektur aus.

Ein Monolith beschreibt auf Systemebene zunächst eine Anwendung, die als zusammengehörige Einheit entwickelt und ausgeliefert wird. Wie diese Einheit intern strukturiert ist, bleibt davon weitgehend unberührt.

Ein modularer Monolith kann klare fachliche Slices besitzen, Verantwortlichkeiten sauber trennen, gerichtete Abhängigkeiten erzwingen, konsistente Layer verwenden und über stabile interne Schnittstellen verfügen.

Seine äußere Systemgrenze ist groß.

Seine inneren Architekturgrenzen müssen es nicht sein.

Ein Deployment bedeutet nicht eine Struktur.

Umgekehrt sorgt das Verteilen eines Systems nicht automatisch für eine bessere Architektur. Ein System kann aus vielen unabhängig ausgelieferten Teilen bestehen und trotzdem fachlich eng verflochten sein. Abhängigkeiten können zyklisch, implizit und kaum eingrenzbar bleiben, unabhängig davon, ob sie innerhalb eines Prozesses oder über technische Systemgrenzen hinweg verlaufen.

Verteilung ist keine Architekturqualität. Zentralisierung ebenso wenig.

Oder kürzer:

„Monolith“ beschreibt eine Systemform. „Big Ball of Mud“ beschreibt einen strukturellen Zustand.

Beide Eigenschaften können gemeinsam auftreten. Sie müssen es aber nicht.

Ein hervorragend strukturierter Monolith ist möglich.

Ein monolithisch ausgelieferter Big Ball of Mud ebenfalls.

Und auch ein verteiltes System kann strukturell ein Big Ball of Mud sein.

Deployment-Topologie und innere Architekturqualität liegen auf unterschiedlichen Achsen.

Ob ein System monolithisch oder verteilt ist und wie gut seine innere Struktur funktioniert, sind zwei unterschiedliche Fragen.

Was mit „Monolith“ manchmal eigentlich gemeint ist

Damit wird der Satz „Wir haben leider einen Monolithen“ in Assessments interessanter.

Denn häufig beschreibt die Person damit nicht primär die äußere Systemform.

Nach einigen weiteren Fragen stellt sich möglicherweise heraus, dass mit „Monolith“ etwas anderes gemeint war: Änderungen haben schwer vorhersehbare Seiteneffekte. Fachliche Grenzen sind kaum noch wirksam. Niemand kann sicher sagen, welche Bereiche von einer Änderung betroffen sein werden. Bestimmte Personen besitzen Wissen, ohne das sich große Teile des Systems kaum gefahrlos verändern lassen. Kleine fachliche Änderungen können unerwartet weit durch die Anwendung reichen.

Dann wird „Monolith“ zu einer begrifflichen Verkürzung.

Das ist keine Täuschung. Im Gegenteil: Der Begriff ist innerhalb eines Projekts möglicherweise über Jahre zu einem diagnostischen Ersatzwort für eine ganze Sammlung struktureller Erfahrungen geworden.

Die verantwortliche Person sagt:

„Wir haben einen Monolithen.“

und meint möglicherweise:

Dieses System lässt sich kaum noch in voneinander begrenzte Bereiche zerlegen.

Ein externer Architekt hört dagegen vollkommen korrekt:

Diese Anwendung wird als eine zusammengehörige Einheit entwickelt und ausgeliefert.

Beide verwenden dasselbe Wort.

Sie haben nur vollkommen unterschiedliche Systeme im Kopf.

Für jemanden, der seit Jahren in der Anwendung arbeitet, kann der Begriff „Monolith“ all die Erfahrungen mit problematischen Änderungen, Seiteneffekten und impliziten Abhängigkeiten bereits mittransportieren.

Für einen externen Assessor tut er das nicht.

Aus einem komplexen strukturellen Zustand wird dadurch ein einzelner, technisch weitgehend neutraler Architekturbegriff.

Und genau dabei kann erstaunlich viel Information verloren gehen.

Wenn das richtige Wort zur falschen Diagnose führt

Diese begriffliche Unschärfe wäre nur eine sprachliche Randnotiz, hätte sie keine praktischen Konsequenzen.

Assessments sind fast immer begrenzt.

Zeit ist begrenzt. Budget ist begrenzt. Dokumentation ist unvollständig. Nicht jeder Gesprächspartner ist verfügbar. Nicht jede Codebasis lässt sich innerhalb weniger Tage tief analysieren. Und manchmal liegt der Schwerpunkt eines Assessments bewusst stärker auf Interviews, Architekturunterlagen und organisatorischen Abläufen als auf einer detaillierten strukturellen Codeanalyse.

Wenn unter diesen Bedingungen immer wieder das Wort „Monolith“ fällt, kann daraus eine vollkommen nachvollziehbare Einordnung entstehen:

Ein erfahrener Architekt weiß, dass ein Monolith zunächst kein Architekturproblem darstellt.

Damit liegt er vollkommen richtig.

Er beantwortet möglicherweise nur nicht die eigentlich relevante Frage.

Ich habe diese Situation selbst in einem Assessment erlebt.

Ich hatte bereits eine eigene Einschätzung des Systems, wollte aber bewusst eine zweite Perspektive. Deshalb holte ich einen Principal Architect hinzu, ohne ihm vorher meine Bewertung mitzuteilen. Er sollte das System möglichst ohne meinen Bias betrachten.

Ein wesentlicher Teil seines Assessments bestand aus Interviews mit den beteiligten Gewerken. Die Codebasis und insbesondere ihre tatsächliche Abhängigkeitsstruktur wurden deutlich weniger tief untersucht.

In den Gesprächen fiel immer wieder dasselbe Wort:

„Monolith.“

Die abschließende Einschätzung war sinngemäß:

So schlimm ist es eigentlich nicht.

Und aus der gehörten Beschreibung war diese Einschätzung sogar nachvollziehbar.

Ein Monolith ist schließlich zunächst einmal kein struktureller Notfall.

Eine tiefere Betrachtung der tatsächlichen Abhängigkeiten zeichnete allerdings ein anderes Bild. Hinter den sichtbaren Modulen lag eine massiv verflochtene Struktur mit großen zyklischen Bereichen und sehr vielen Abhängigkeiten. Die Architektur, über die gesprochen wurde, erklärte nur noch begrenzt die Struktur, die im System tatsächlich wirksam war.

Das ist eine persönliche Erfahrung und kein wissenschaftlicher Beleg dafür, dass interviewbasierte Assessments grundsätzlich zu falschen Ergebnissen führen.

Sie illustriert für mich aber ein methodisches Risiko sehr deutlich:

„Monolith“ kann unbeabsichtigt zur falschen Diagnose werden.

Nicht weil der Begriff falsch wäre.

Sondern weil er eine andere Frage beantwortet.

Wenn mehrere Interviewpartner von einem „Monolithen“ sprechen, interessiert mich deshalb nicht zuerst, ob das System in kleinere Deployments zerlegt werden sollte.

Interessanter sind andere Fragen:

• Sind fachliche Grenzen innerhalb des Systems tatsächlich noch wirksam?
• Stimmen dokumentierte und implementierte Architektur überein?
• Folgen Abhängigkeiten nachvollziehbaren Richtungen?
• Lassen sich Verantwortlichkeiten klar lokalisieren?
• Bleiben Änderungen innerhalb erwartbarer Grenzen?
• Existieren große Bereiche gegenseitiger Abhängigkeit?
• Erklärt die sichtbare Struktur, welche Teile des Systems tatsächlich voneinander abhängen?

Erst die Antworten auf solche Fragen erlauben die eigentlich relevante Unterscheidung:

Stehe ich vor einem großen, modularen Monolithen?

Oder vor einem Big Ball of Mud, der zufällig monolithisch ausgeliefert wird?

Wer beides gleichsetzt, unterschätzt möglicherweise den einen und tut dem anderen gleichzeitig Unrecht.

Die äußere Form ist nicht die Diagnose

Der Begriff Big Ball of Mud ist drastisch. Gerade deshalb lohnt es sich, ihn vorsichtig zu verwenden.

Er beschreibt nicht einfach alte Software, viel Code, einen Monolithen oder eine Anwendung mit Technical Debt.

Er beschreibt einen strukturellen Zustand.

Foote und Yoder beschrieben bereits Ende der 1990er-Jahre Systeme, deren Organisation stärker aus pragmatischem Wachstum als aus einem konsistenten Entwurf hervorgegangen war. Forschung zu Architecture und Design Erosion ergänzt diese Perspektive um die Beobachtung, dass sich die tatsächlich implementierte Struktur eines Systems immer weiter von einer ursprünglich beabsichtigten Architektur entfernen kann.

Für Frontends bedeutet das nicht, dass eine verletzte Layer-Regel bereits einen Big Ball of Mud erzeugt. Es bedeutet auch nicht, dass jede große oder lange gewachsene Anwendung zwangsläufig dort endet.

Entscheidend ist, ob die Architektur ihre strukturierende Funktion noch erfüllt.

Begrenzen Slices noch fachliche Verantwortlichkeiten?

Besitzen Layer noch eine verlässliche Bedeutung?

Sind Abhängigkeiten noch nachvollziehbar?

Kann man aus der sichtbaren Struktur des Systems noch ableiten, wo eine Änderung stattfinden sollte und welche Teile davon betroffen sein können?

Wenn diese Aussagen immer weniger zuverlässig werden, verliert die Architektur ihre praktische Bedeutung.

Aus Architektur wird irgendwann nur noch Beschriftung.

Und wenn ein Big Ball of Mud nicht einfach ein Monolith ist und selbst Systeme mit ursprünglich klarer Struktur in diesen Zustand geraten können, stellt sich eine naheliegende Frage:

Wer hat ihn gebaut?

Die Antwort ist häufig weniger befriedigend, als man erwartet.

Niemand ist morgens zur Arbeit gekommen und hat entschieden, heute einen Big Ball of Mud zu bauen.

Genau darum geht es im nächsten Artikel:

„Niemand hat ihn gebaut.“

---

Quellen

Foote, Brian; Yoder, Joseph W.: Big Ball of Mud. Ursprünglich vorgestellt auf der Fourth Conference on Pattern Languages of Programs (PLoP ’97), 1997; später veröffentlicht in: Harrison, Neil; Foote, Brian; Rohnert, Hans (Hrsg.): Pattern Languages of Program Design 4. Addison-Wesley, 2000. Originalfassung: https://www.laputan.org/mud/

Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris: Understanding Architecture Erosion: The Practitioners’ Perceptive. IEEE/ACM International Conference on Program Comprehension (ICPC), 2021. DOI: 10.1109/ICPC52881.2021.00037. Preprint: https://arxiv.org/abs/2103.11392

Baum, David; Dietrich, Jens; Anslow, Craig; Müller, Richard: Visualizing Design Erosion: How Big Balls of Mud are Made. IEEE Working Conference on Software Visualization (VISSOFT), 2018, S. 122–126. DOI: 10.1109/VISSOFT.2018.00022. Preprint: https://arxiv.org/abs/1807.06136