Der Big Ball of Mud ist ein organisatorisches Problem

Der Code ist das kleinste Problem

In einem besonders schwierigen Bestandssystem wurde irgendwann ein umfangreiches technisches Assessment durchgeführt. Ein erfahrener Principal Architect analysierte über längere Zeit die Architektur, die Abhängigkeiten und die Entwicklungsprozesse. Technisch gab es mehr als genug zu finden: Das System bestand aus tausenden Dateien, zyklische Abhängigkeiten durchzogen große Teile der Codebasis, Zustände und Verantwortlichkeiten waren über das System verteilt, und globale Mechanismen verbanden fachlich eigentlich unabhängige Bereiche miteinander. Bei vielen Änderungen war nur schwer vorhersehbar, welche Teile des Systems tatsächlich betroffen sein würden.

Es hätte nahegelegen, genau diesen Big Ball of Mud ganz oben auf der Problemliste zu erwarten. Dort stand er jedoch nicht. Der Principal Architect fasste seine Einschätzung sinngemäß so zusammen:

„Der Code ist das kleinste Problem.“

Das ist eine Erfahrung aus einem konkreten Projekt, kein wissenschaftlicher Befund. Der Satz bedeutete auch keineswegs, dass der technische Zustand harmlos gewesen wäre. Im Gegenteil: Die Architektur war erheblich erodiert. Der Code hatte jedoch eine Eigenschaft, die viele der anderen Probleme nicht hatten: Man konnte ihn analysieren. Dependencies ließen sich visualisieren, Zyklen identifizieren, Module neu schneiden, Tests ergänzen und technische Grenzen schrittweise wieder aufbauen. Zumindest prinzipiell existierte dafür ein technisches Instrumentarium. Die schwierigere Frage lautete deshalb:

Welche Organisation soll diese Veränderung eigentlich über mehrere Jahre tragen?

Die Geschäftsführung des betroffenen Bereichs arbeitete unter erheblichem wirtschaftlichem und operativem Druck. Die Product Ownership konnte die fachliche und organisatorische Komplexität des bestehenden Systems nur unzureichend abfangen; Anforderungen erreichten die Entwicklung teilweise ohne ausreichendes Verständnis dafür, welche fachlichen Zusammenhänge und historischen Entscheidungen bereits im System verankert waren. In Teilen der Entwicklung war deutliche Resignation wahrnehmbar, während Entwickler, technische Führungskräfte und Verantwortlichkeiten häufig wechselten.

Keine dieser Beobachtungen erklärt für sich genommen einen Big Ball of Mud, und aus einem einzelnen Projekt lässt sich keine allgemeine Theorie über Softwareorganisationen ableiten. Die Szene eröffnet aber eine andere Perspektive auf Architektur: Ein Big Ball of Mud liegt im Repository, doch die Kräfte, die ihn entstehen lassen und über Jahre reproduzieren können, liegen nicht ausschließlich dort.

Der Big Ball of Mud liegt im Repository – seine Ursachen nicht nur dort

Dependencies werden von Entwicklern geschrieben. Entwickler erweitern Shared Services, führen globale Zustände ein, umgehen vorhandene Schnittstellen oder hängen weitere Sonderfälle an bestehende Mechanismen. Diese technische Verantwortung verschwindet nicht dadurch, dass Deadlines, Budgets oder organisatorische Probleme existieren. Solche Entscheidungen entstehen aber auch nicht im luftleeren Raum.

Stellen wir uns ein Team vor, das kurzfristig Daten aus einem anderen fachlichen Bereich benötigt. Die strukturell sauberere Lösung würde bedeuten, eine bestehende Schnittstelle zu erweitern, Verantwortlichkeiten mit einem anderen Team zu klären, möglicherweise Datenmodelle anzupassen und die Änderung gemeinsam zu testen. Die Alternative ist ein direkter Zugriff auf einen Service, der die benötigten Daten bereits kennt. Die erste Variante benötigt Abstimmung, die zweite ist in zwei Tagen fertig, und der Release ist nächste Woche. Entscheidet sich das Team für den direkten Zugriff, entsteht technisch eine neue Kopplung. Organisatorisch kann die Entscheidung trotzdem nachvollziehbar sein.

Die falsche Dependency besitzt häufig eine technische Form und eine organisatorische Vorgeschichte.

Damit ist nicht gesagt, dass organisatorischer Druck jede schlechte Architekturentscheidung entschuldigt oder zwangsläufig hervorruft. Unterschiedliche Entwickler und Teams können unter denselben Bedingungen unterschiedliche Entscheidungen treffen; Architekturkompetenz, Erfahrung und technische Führung bleiben relevant. Organisationale Bedingungen verändern aber den Entscheidungsraum. Sie beeinflussen, welche Alternativen realistisch erscheinen, wie teuer Abstimmung ist, welche Zeiträume berücksichtigt werden und wer spätere Folgen trägt.

Genau an dieser Grenze zwischen technischer Entscheidung und organisatorischem Kontext wird der Big Ball of Mud zu einem sozio-technischen Problem. Conways ursprüngliche Beobachtung wird häufig auf die griffige Formel reduziert, ein Organigramm bilde sich direkt in der Architektur eines Systems ab. Sein Argument war differenzierter: Die Aufteilung von Designarbeit erzeugt Kommunikations- und Koordinationsbeziehungen, und diese Bedingungen beeinflussen, welche Systemstrukturen eine Organisation hervorbringen kann. Spätere Forschung zur Mirroring Hypothesis und zur Socio-Technical Congruence hat diesen Zusammenhang empirisch weiter untersucht. Technische Abhängigkeiten erzeugen Koordinationsbedarf; die organisatorische Fähigkeit, diesen Bedarf zu bedienen, beeinflusst wiederum Entwicklungsarbeit und Systementwicklung. Das ist keine deterministische Gleichung zwischen Organigramm und Architektur, aber ein belastbarer Hinweis darauf, dass beide Ebenen nicht unabhängig voneinander betrachtet werden können.

Die Organisation schreibt an der Architektur mit, auch wenn sie keine Zeile Code schreibt.

Lokal rational, global teuer

Ein besonders wichtiger Mechanismus entsteht dadurch, dass eine Architekturentscheidung aus unterschiedlichen Perspektiven gleichzeitig sinnvoll und problematisch sein kann. Sie kann für einen Entwickler rational sein, weil sie das aktuelle Ticket löst, für ein Team, weil sie einen zugesagten Release ermöglicht, für eine Business Unit, weil ein wichtiger Kunde auf die Funktion wartet, oder für ein Projekt, dessen Budget in drei Monaten endet. Für das Gesamtsystem kann dieselbe Entscheidung langfristig teuer werden.

Nehmen wir wieder den direkten Zugriff zwischen zwei fachlichen Bereichen. Team A spart heute mehrere Tage Abstimmung, und die neue Abhängigkeit fällt zunächst kaum auf. Monate später muss Team B seine interne Struktur verändern und entdeckt, dass mittlerweile mehrere andere Bereiche implizit davon abhängen. Ein weiteres Jahr später arbeitet Team C an einer Migration und muss eine Kopplung verstehen, an deren Entstehung niemand aus dem aktuellen Team beteiligt war. Der Nutzen der ursprünglichen Entscheidung entstand unmittelbar bei Team A; die Kosten entstehen später und möglicherweise bei Team C.

Kosten und Nutzen einer Architekturentscheidung fallen häufig weder zur selben Zeit noch an derselben organisatorischen Stelle an.

Genau dieses Auseinanderfallen erschwert langfristige Architekturentscheidungen. Die Einheit, die heute die Kosten einer sauberen Schnittstelle tragen müsste, ist nicht zwangsläufig die Einheit, die später von ihr profitiert. Umgekehrt trägt die Einheit, die heute durch eine Abkürzung Zeit gewinnt, möglicherweise nur einen kleinen Teil ihrer zukünftigen Folgekosten.

Forschung zu Technical Debt beschreibt einen ähnlichen zeitlichen Mechanismus: Kurzfristig vorteilhafte Entscheidungen können spätere Änderungen verteuern. Eine internationale Survey-Familie mit 653 gültigen Antworten aus sechs Ländern identifizierte Zeitdruck beziehungsweise Deadlines als den am häufigsten genannten Auslöser für Technical Debt; zu den häufig genannten Folgen gehörten spätere Lieferverzögerungen, schlechtere Wartbarkeit und Rework. Wiese und Borowa zeigen aus der Perspektive von IT-Managern zusätzlich, dass Zeit, Budget, Sichtbarkeit und Managementprozesse wesentliche Bestandteile des Umgangs mit Technical Debt sind.

Das macht die ursprüngliche Entscheidung nicht automatisch richtig. Es zeigt lediglich, warum die Erklärung „Die Entwickler hätten es halt sauber bauen müssen“ analytisch zu kurz greift.

Der Nutzen einer Abkürzung kann lokal und unmittelbar entstehen, während ihre strukturellen Kosten später und an anderer Stelle anfallen.

Drei Organisationslogiken, derselbe technische Endzustand

Besonders deutlich wird dieser Mechanismus, wenn man drei sehr unterschiedliche Organisationskontexte betrachtet. Ein Konzern, ein Startup und ein externer Auftragnehmer arbeiten unter anderen Rahmenbedingungen und verfolgen andere legitime Ziele. Trotzdem können sie langfristig bei erstaunlich ähnlichen technischen Strukturen ankommen.

Der Big Ball of Mud im Konzern

In einem größeren Unternehmen werden Führung und Organisation nicht primär daran gemessen, ob eine Dependency in fünf Jahren noch gut geschnitten ist. Relevant sind unter anderem Budgets, Ergebnisziele, Kunden, Projekte, Lieferfähigkeit, Umsatz und operative Stabilität. Das ist weder überraschend noch grundsätzlich problematisch: Softwareentwicklung ist kein Selbstzweck, und Architektur muss wirtschaftlichen Zielen dienen.

Schwierig wird es, wenn sich die Zeitachsen voneinander entfernen. Eine Architekturentscheidung kann sich erst nach mehreren Jahren auszahlen, während Rollen deutlich früher neu besetzt werden, Budgets jährlich oder quartalsweise geplant sind, Bereiche reorganisiert werden und strategische Schwerpunkte wechseln. In einer Business Unit aus dem beschriebenen Projektumfeld wechselte die Entwicklungsleitung über ungefähr acht Jahre so häufig, dass die durchschnittliche Verweildauer grob bei neun Monaten lag. Das ist eine einzelne Beobachtung und keine Aussage darüber, wie Entwicklungsorganisationen in Konzernen generell funktionieren. Sie führt aber zu einer relevanten Frage:

Welche langfristige Architekturstrategie kann organisatorisch entstehen, wenn die verantwortliche Rolle schneller wechselt als die Architekturinvestition sich auszahlt?

Der Punkt ist nicht, dass die jeweiligen Führungskräfte kurzsichtig gewesen wären oder ihnen Architektur egal war. Das Problem liegt bereits in den unterschiedlichen Zeithorizonten. Eine Führungskraft kann vollkommen rational die nächsten zwölf Monate stabilisieren, während die Architektur eine konsistente Richtung über mehrere Jahre benötigt. Wenn die organisatorische Verantwortung schneller wechselt als eine Architekturentscheidung ihren Nutzen entfalten kann, entsteht daraus ein strukturelles Anreizproblem.

Der Big Ball of Mud im Startup

Im Startup kann derselbe technische Endzustand unter fast gegenteiligen Voraussetzungen entstehen. Ein junges Unternehmen muss möglicherweise zunächst herausfinden, ob überhaupt ein tragfähiges Produkt existiert, ob Kunden das adressierte Problem besitzen, ob sie für die Lösung bezahlen und ob die Finanzierung lange genug reicht, um die nächste Entwicklungsstufe zu erreichen. Unter solchen Bedingungen kann es wirtschaftlich rational sein, eine Lösung innerhalb von zwei Wochen zu bauen, obwohl eine langfristig sauberere Variante sechs Wochen benötigen würde.

Technical Debt ist deshalb nicht automatisch ein Fehler. Unter Unsicherheit kann die bewusste Aufnahme technischer Schulden eine wirtschaftliche Entscheidung sein, sofern tatsächlich ein Trade-off getroffen wird und die kurzfristige Optimierung zu den aktuellen Unternehmenszielen passt. Studien zu Software-Startups beschreiben genau diese Spannung zwischen knappen Ressourcen, schneller Markterprobung und Engineering-Qualität. Besonders interessant ist der Übergang: Mit zunehmender Reife verschieben sich Engineering-Ziele von Time-to-Market stärker in Richtung Wartbarkeit und nachhaltiger Produktentwicklung. Klotins, Unterkalmsteiner und Gorschek fanden diesen Übergang in ihrer Analyse von 88 Startup-Erfahrungsberichten ausdrücklich wieder.

Problematisch wird es, wenn sich das Produkt weiterentwickelt, die zugrunde liegende Entwicklungslogik aber unverändert bleibt. Der Prototyp gewinnt Kunden, das Unternehmen wächst und aus einer vorläufigen Implementierung wird ein Kernprodukt, während weiterhin nach den Regeln einer frühen Explorationsphase entwickelt wird.

Ein Startup kann zum Big Ball of Mud werden, wenn eine für Unsicherheit optimierte Entwicklungsweise eine Phase überlebt, in der das System längst auf Dauerhaftigkeit angewiesen ist.

Was den Prototypen erfolgreich gemacht hat, muss das Produkt nicht langfristig gesund halten; die Erfolgslogik der frühen Phase kann in einer späteren Phase zur strukturellen Belastung werden.

Der Big Ball of Mud beim externen Auftragnehmer

Noch einmal anders sieht die Situation bei einem externen Dienstleister aus. Der Auftrag kann klar definiert sein: Feature X, Budget Y, Termin Z. Während der Umsetzung wird sichtbar, dass für eine strukturell gute Lösung zunächst ein bestehender Bereich umgebaut werden müsste, was zusätzliche drei Wochen benötigt. Der Kunde weist darauf hin, dass diese Arbeit nicht im Scope liegt; der Dienstleister setzt daraufhin das beauftragte Feature innerhalb des vereinbarten Rahmens um. Beide Seiten können damit vollkommen rational handeln.

Der Kunde verwaltet ein Budget und benötigt ein zugesagtes Ergebnis. Der Auftragnehmer besitzt einen Vertrag und muss dessen Leistungsumfang erfüllen. Eine zusätzliche Architekturinvestition, deren Nutzen vielleicht erst Jahre später sichtbar wird, lässt sich nicht automatisch einer der beiden Seiten zuordnen. Die technische Folge kann trotzdem langfristig im System verbleiben.

Derjenige, der die Kosten guter Architektur heute tragen müsste, ist nicht zwingend derjenige, der morgen von ihr profitiert.

Bei lang laufenden Systemen kann sich dieser Effekt vervielfachen. Dienstleister A entwickelt die erste Version, Dienstleister B erweitert sie, Dienstleister C übernimmt den Betrieb und Dienstleister D erhält Jahre später den Auftrag zur Modernisierung. Jeder Beteiligte kennt nur einen Ausschnitt der Geschichte; die Codebasis trägt jedoch die technischen Spuren aller Phasen weiter.

Verträge enden. Projekte werden abgeschlossen. Dienstleister wechseln. Dependencies bleiben.

Empirische Arbeiten zu Technical Debt zeigen ebenfalls, dass dessen Entstehung und Management nicht allein innerhalb eines Entwicklungsteams erklärt werden können. Nielsen und Madsen konnten in einer eingebetteten Fallstudie zweier Systeme einer dänischen Behörde zeigen, dass auch nichttechnische interne und externe Stakeholder Technical-Debt-Entscheidungen beeinflussen. Neuere Forschung zu Entscheidungskriterien bei der Aufnahme von Technical Debt betrachtet entsprechend nicht nur technische Konsequenzen, sondern unter anderem Deadlines, Erwartungen von Stakeholdern, verfügbare Ressourcen und organisatorische Autorität. Solche Studien liefern keine allgemeine Theorie für jedes Vertragsmodell. Sie zeigen aber, dass die relevante Entscheidungseinheit größer sein kann als das Team, das am Ende den Code schreibt.

Unterschiedliche organisatorische Logiken können jeweils lokal rationale Entscheidungen erzeugen, deren technische Folgen länger bestehen als der ursprüngliche Kontext.

Software besitzt ein längeres Gedächtnis als Organisationen

Organisationen verändern sich: Teams werden zusammengelegt oder aufgeteilt, Bereiche reorganisiert, Führungskräfte wechseln, Produkte erhalten neue Owner, Dienstleister verlassen ein Projekt und andere übernehmen. Projekte enden, Budgets verschwinden und neue Programme beginnen. Der Code vollzieht diese organisatorischen Veränderungen nicht automatisch mit.

Eine Dependency verschwindet nicht, weil zwei Teams organisatorisch getrennt wurden. Ein globaler State erhält keinen neuen fachlichen Owner, nur weil sich das Organigramm verändert hat, und ein Workaround verliert nicht seine Wirkung, weil der ursprüngliche Kunde nicht mehr existiert. Dadurch kann Software zu einer Art Sediment früherer Organisationsformen werden.

Die heutige Software kann noch Organisationsgrenzen von gestern enthalten.

Das ist eine vorsichtigere und für langlebige Systeme nützlichere Lesart von Conway’s Law als die populäre Formel „Org Chart = Architektur“. Conway argumentierte bereits 1968, dass die Verteilung von Designarbeit Kommunikationsbeziehungen erzeugt und Organisationen dadurch in ihren möglichen Systementwürfen beeinflusst werden. Untersuchungen der Mirroring Hypothesis fanden später Zusammenhänge zwischen organisatorischer Kopplung und Produktarchitektur. Forschung zur Socio-Technical Congruence konzentriert sich wiederum darauf, ob die durch technische Dependencies entstehenden Koordinationsanforderungen durch tatsächliche organisatorische Kommunikation und Koordination abgedeckt werden.

Keine dieser Arbeiten rechtfertigt die Behauptung, eine bestimmte Teamstruktur erzeuge zwangsläufig eine bestimmte Softwarearchitektur. Menschen können bewusst gegen solche Kräfte gestalten, und Architektur kann Organisationsgrenzen abstrahieren oder stabilisieren. Genau das benötigt jedoch Kontinuität, denn während eine Organisation ihre Struktur innerhalb eines Meetings ändern kann, müssen die technischen Spuren ihrer bisherigen Struktur anschließend explizit verändert werden.

Software besitzt häufig ein längeres Gedächtnis als Organisationen.

Organisationen verändern Verantwortlichkeiten, Teams und Personen. Die Software behält die technischen Entscheidungen ihrer Vorgänger.

Ownership ist mehr als ein Name im Organigramm

An dieser Stelle wird der Begriff Ownership wichtig. In vielen Organisationen scheint die Zuordnung zunächst eindeutig: Ein Team besitzt einen Bereich, ein Product Owner ein Produkt, ein Lead verantwortet die Architektur und eine Führungskraft die Entwicklung. Für langfristige Architektur reicht diese nominelle Zuordnung jedoch nicht aus.

Entscheidend ist, wer eine fachliche Grenze tatsächlich schützen darf, wer eine problematische Dependency ablehnen kann, obwohl dadurch ein zugesagtes Feature später geliefert wird, wer strukturelle Arbeit priorisieren darf und wer über ein Shared Model entscheidet, das von zehn Teams verwendet wird. Ebenso relevant ist, wer die Konsequenzen einer Entscheidung über mehrere Jahre trägt und nach einer Reorganisation die historischen Verpflichtungen eines Bereichs übernimmt.

Damit zerfällt Ownership in mehrere Dimensionen: fachliche Ownership, technische Ownership, nominelle Verantwortung, reale Entscheidungsrechte und die Frage, wer langfristig für Konsequenzen einstehen kann. Diese Dimensionen müssen nicht bei derselben Person oder Rolle liegen. Problematisch wird es, wenn sie so weit auseinanderfallen, dass zwar jemand verantwortlich gemacht werden kann, aber niemand die notwendigen Entscheidungen treffen darf.

Verantwortung ohne ausreichende Entscheidungsfähigkeit ist keine belastbare Ownership.

Das erklärt auch, warum Architekturregeln allein keine organisatorische Grenze erzeugen. Eine Regel kann dokumentieren, dass Bereich A nicht direkt auf Bereich B zugreifen soll. Sobald eine wichtige Deadline erreicht werden muss, stellt sich jedoch eine andere Frage: Wer besitzt das Mandat, diese Regel auch dann durchzusetzen, wenn ihre Einhaltung kurzfristig Geld oder Zeit kostet?

Aktuelle empirische Forschung zu Technical-Debt-Entscheidungen nimmt deshalb neben technischen Auswirkungen auch organisatorische Autorität und Stakeholderinteressen in den Blick. Wiese und Borowa zeigen aus Managementperspektive zusätzlich, wie stark Technical-Debt-Management mit Budget, Deadlines, Kommunikation und etablierten Entscheidungsprozessen verbunden ist. Eine Architektur kann auf dem Papier einen Owner besitzen und praktisch trotzdem führungslos sein.

Wenn fachliche Unklarheit im Code landet

Ownership besitzt außerdem eine fachliche Seite. Im eingangs beschriebenen Projekt erreichten die Entwicklung immer wieder Anforderungen, deren Entstehung das bestehende System und seine fachlichen Zusammenhänge nur teilweise berücksichtigte. Gleichzeitig fehlte eine ausreichend stabile Product Ownership, die solche Anforderungen konsequent in ein fachlich kohärentes Modell hätte übersetzen können.

Auch das ist zunächst nur eine Beobachtung aus einem konkreten Projekt. Die Verallgemeinerung darf nicht lauten, schlechte Anforderungen verursachten zwangsläufig schlechte Architektur. Komplexe Domänen besitzen reale Ausnahmen, Geschäftsmodelle verändern sich, gesetzliche Vorgaben erzeugen Sonderfälle und Produkte müssen historische Prozesse unterstützen. Nicht jede zusätzliche Bedingung im Code ist ein Symptom organisatorischen Versagens.

Schwieriger wird es, wenn grundlegende fachliche Fragen dauerhaft ungeklärt bleiben: Wem gehört ein bestimmter Zustand? Welcher Prozess ist führend? Welche Regel ist verbindlich? Ist eine Ausnahme tatsächlich fachlich notwendig oder nur historisch gewachsen? Welche Domäne darf welchen Zustand verändern? Wenn die Organisation diese Fragen nicht beantworten kann, verschwinden sie nicht – die Entwicklung muss trotzdem Software bauen.

Fachliche Unsicherheit kann dann technisch kompensiert werden, etwa durch zusätzliche Flags und Parameter, mehrere Writer für denselben Zustand, duplizierte Regeln, fachfremde Querverbindungen, Shared State oder Sonderpfade, deren Zuständigkeit niemand mehr eindeutig erklären kann.

Unklare fachliche Ownership bleibt nicht außerhalb des Codes. Irgendwann kann sie zu unklarer technischer Ownership werden.

Forschung zum Requirements Engineering zeigt seit Langem, dass unklare Anforderungen und Kommunikationsprobleme zu den wiederkehrenden Herausforderungen realer Entwicklungsprojekte gehören. Auch Untersuchungen der Product-Owner-Rolle beschreiben diese Rolle gerade als Verbindung zwischen geschäftlichen Anforderungen, Stakeholdern und Umsetzung, wobei ihre Wirksamkeit wiederum vom organisatorischen Kontext abhängt. Das liefert keinen einfachen kausalen Pfad von „schlechtem Product Owner“ zu „schlechter Architektur“. Es erklärt aber, warum fachliche Klärung und technische Struktur nicht vollständig voneinander getrennt werden können: Ein System kann nur begrenzt klare fachliche Grenzen ausdrücken, wenn die Organisation hinter diesen Grenzen selbst keine stabile Antwort auf ihre Zuständigkeiten besitzt.

Überlebensmodus verkürzt den Zeithorizont

Im beschriebenen Projekt stand die Geschäftsführung zeitweise vor deutlich unmittelbareren Problemen als der langfristigen Architekturqualität. Kritische Kunden mussten bedient werden, Budgets waren knapp, Lieferverpflichtungen bestanden weiter, und gleichzeitig stand die wirtschaftliche Zukunft des Bereichs selbst zur Diskussion. Aus technischer Perspektive ist leicht zu sagen, dass gerade in einer solchen Situation langfristige Strukturarbeit notwendig wäre. Aus organisatorischer Perspektive konkurriert diese Arbeit jedoch mit Problemen, deren Konsequenzen morgen eintreten können.

Überlebensmodus macht langfristige Entscheidungen nicht unwichtig. Er kann sie organisatorisch nahezu unmöglich machen.

Das ist kein Vorwurf an Führung, sondern beschreibt einen Zeithorizont. Eine sauberere technische Grenze erzeugt ihren Nutzen möglicherweise erst nach mehreren Releases, während ein eskalierender Kunde heute eine Antwort verlangt. Die Reduktion struktureller Kopplung kann sich über Jahre amortisieren, während das Budgetproblem im aktuellen Quartal existiert. Unter solchen Bedingungen verschiebt sich die Attraktivität von Entscheidungen.

Genau hier kann ein Rückkopplungseffekt entstehen: Kurzfristiger wirtschaftlicher Druck macht kurzfristig attraktive technische Entscheidungen wahrscheinlicher. Einige davon können zukünftige Änderungen verteuern. Höhere Änderungskosten erhöhen wiederum den Lieferdruck, wodurch langfristige Strukturarbeit noch schwerer zu priorisieren ist. Technical-Debt-Forschung beschreibt solche Ketten und Zyklen ausdrücklich als relevante Betrachtungsweise. Wiese und Borowa modellieren aus ihren Interviews mit IT-Managern unterschiedliche Sichtbarkeitsebenen sowie Ketten und Kreisläufe von Ursachen und Konsequenzen; die bereits erwähnte internationale Survey-Familie zeigt zugleich, wie prominent Zeitdruck als berichteter Entstehungskontext technischer Schulden ist.

Das bedeutet nicht, dass wirtschaftlicher Druck zwangsläufig einen Big Ball of Mud produziert. Er kann den Entscheidungsraum aber systematisch zugunsten der Gegenwart verschieben.

Architektur braucht eine Zukunft, für die sich Investition lohnt

Dieser Zeithorizont betrifft nicht nur Managemententscheidungen. In dem beschriebenen Projekt fielen aus der Entwicklung wiederholt Aussagen, die sinngemäß darauf hinausliefen, man warte nur noch darauf, dass der Bereich geschlossen werde. Auch das ist eine persönliche Beobachtung; daraus lässt sich weder eine psychologische Diagnose ableiten noch behaupten, der Big Ball of Mud habe diese Haltung verursacht.

Für Architektur entsteht daraus trotzdem eine nüchterne ökonomische Frage: Warum sollte jemand heute drei Wochen in eine technische Grenze investieren, deren Nutzen sich erst über die nächsten drei Jahre verteilt, wenn er nicht davon ausgeht, dass das Produkt in drei Jahren noch existiert?

Langfristige Architekturarbeit ist eine Investition. Sie verursacht Kosten in der Gegenwart, damit spätere Änderungen günstiger, sicherer oder überhaupt erst möglich werden. Eine solche Investition benötigt deshalb zumindest einen hinreichend langen Erwartungshorizont.

Architekturinvestitionen setzen zumindest die Erwartung voraus, dass das System eine Zukunft besitzt, in der sich diese Investition auszahlen kann.

Das ist kein Appell an Optimismus, sondern eine Eigenschaft der Investitionslogik. Ein Team, das seine gesamte Zukunft nur noch in Wochen betrachtet, wird andere Entscheidungen treffen als eines, das davon ausgeht, dieselbe Codebasis noch fünf Jahre weiterzuentwickeln. Wenn gleichzeitig Rollen, Budgets und Produkte unsicher sind, entsteht dadurch ein weiterer Mechanismus, der lokal rationale Kurzfristentscheidungen begünstigen kann.

Wenn Verantwortung schneller wechselt als das System

Mit jeder personellen Veränderung geht nicht automatisch Wissen verloren. Gut dokumentierte Systeme, klare Modelle, starke Teams und explizite Entscheidungsprozesse können erhebliches Wissen unabhängig von einzelnen Personen erhalten. Vollständig dokumentieren lässt sich jedoch nicht alles: Warum wurde eine Schnittstelle genau so gebaut? Welcher Kunde benötigte einen Sonderfall? Warum darf ein Zustand nur an einer bestimmten Stelle geändert werden? Welche Alternative wurde damals verworfen und weshalb?

Ein Teil dieser Informationen lebt in Tickets, Dokumentation und Architecture Decision Records, ein anderer in Menschen. Forschung zu turnover-induced knowledge loss zeigt, dass das Ausscheiden von Entwicklern relevantes technisches und implizites Wissen aus Projekten entfernen kann. Untersuchungen an Chrome und einem Avaya-Projekt sowie spätere Arbeiten zur praktischen Wahrnehmung dieses Problems beschreiben Wissen über Implementierungen und historische Zusammenhänge als Ressource, deren Verlust spätere Entwicklungsarbeit erschweren kann. Daraus folgt nicht, dass Fluktuation einen Big Ball of Mud verursacht. Hohe personelle Instabilität erschwert aber die kontinuierliche Weitergabe jener Entscheidungsgründe, die zur Erhaltung langfristiger Strukturen notwendig sind.

Entwickler, Teamleads und Entwicklungsleiter wechseln, Zuständigkeiten werden neu zugeschnitten, die Codebasis jedoch nicht zwangsläufig. Dadurch entsteht ein asymmetrischer Prozess: Historische Entscheidungen bleiben erhalten, während das Wissen über ihre Gründe langsam ausgetauscht wird.

Wer verfolgt eine Architekturstrategie über drei Jahre, wenn die dafür verantwortlichen Rollen innerhalb dieser Zeit mehrfach wechseln?

Auch die Besetzung von Führungsrollen sollte dabei nicht moralisch betrachtet werden. Gerade in instabilen Organisationen werden Rollen aus vielen pragmatischen Gründen übernommen: weil jemand verfügbar ist, kurzfristig eine Lücke geschlossen werden muss, bestehende Beziehungen hilfreich sind oder die Organisation schnell handlungsfähig bleiben muss. Architektonisch relevant ist nicht die moralische Bewertung einer solchen Entscheidung, sondern ob Rolle, Erfahrung, Legitimation und tatsächliche Entscheidungsfähigkeit anschließend zusammenpassen.

„Müsste mir das nicht eigentlich der Geschäftsführer melden?“

In einem späteren Termin mit CTO und Lead Architect wurde der Zustand des Systems einschließlich der strukturellen Probleme, eines möglichen Zielbilds und des notwendigen Veränderungsbedarfs vorgestellt. Ziel des Termins war ausdrücklich, organisatorisches Enablement für Veränderungen zu erhalten, die längst über einzelne Refactorings innerhalb eines Teams hinausgingen. Im Verlauf des Gesprächs fiel sinngemäß die Frage:

„Müsste mir das nicht eigentlich der Geschäftsführer melden?“

Es wäre leicht, diesen Satz als Desinteresse an Technik zu interpretieren. Das wäre zu einfach. Aus Governance-Perspektive steckt darin eine nachvollziehbare Frage: Wer besitzt das Mandat, ein Problem dieser Größenordnung zu eskalieren? Wer darf daraus Prioritäten ableiten? Wer kann entscheiden, dass mehrere Teams, Budgets und Verantwortlichkeiten betroffen sein werden?

Gerade darin liegt jedoch der interessante Mechanismus. Eine technische Diagnose kann korrekt sein und trotzdem organisatorisch wirkungslos bleiben.

Ein technisches Problem wird nicht allein dadurch organisationswirksam, dass es korrekt diagnostiziert wurde. Jemand muss auch legitimiert sein, aus dieser Diagnose Konsequenzen abzuleiten.

Technische Evidenz und organisatorische Autorität sind zwei verschiedene Dinge. Ein Entwickler kann nachweisen, dass Zyklen existieren, ein Architect kann zeigen, dass eine Dependency den Change Radius vergrößert, und ein Team kann demonstrieren, dass eine bestimmte Struktur regelmäßig Änderungen verteuert. Keine dieser Rollen besitzt dadurch automatisch das Recht, Zuständigkeiten zu verändern, Budgets umzuschichten oder andere Bereiche zu verpflichten.

Damit erreicht Architektur einen Punkt, an dem technische Kompetenz allein nicht mehr genügt – nicht weil Technik unwichtig wird, sondern weil die Entscheidung, technische Grenzen zu verändern, selbst organisatorische Grenzen berühren kann.

Wenn technische Entkopplung organisatorische Kontrolle berührt

In demselben Projekt wurde eine angestrebte technische Veränderung in einer Diskussion sinngemäß als „feindliche Übernahme“ bezeichnet. Auch das ist eine einzelne Erfahrung und kein Muster, das Organisationen allgemein unterstellt werden sollte. Interessant an der Formulierung war jedoch, was eigentlich verändert werden sollte: Es ging nicht um eine Unternehmensübernahme, sondern um technische Grenzen, Ownership, Zuständigkeiten, Schnittstellen und die Frage, welcher Bereich künftig welche Entscheidungen treffen sollte.

Aus technischer Perspektive kann eine Entkopplung ausgesprochen unspektakulär aussehen. Ein Shared Service wird aufgeteilt, eine fachliche Zuständigkeit erhält eine klar definierte Schnittstelle, ein globales Datenmodell wird durch mehrere explizite Modelle ersetzt oder die Schreibrechte auf einen Zustand werden reduziert. Organisatorisch kann sich damit mehr verändern: Ein Team kann nicht mehr direkt in einen anderen Bereich eingreifen, eine Rolle verliert informelle Kontrolle über einen Prozess, oder Entscheidungen, die früher innerhalb einer Einheit getroffen wurden, benötigen plötzlich Abstimmung. Eine technische Schnittstelle macht sichtbar, wem etwas gehört – und damit möglicherweise auch, wem es nicht mehr gehört.

Was technisch als Entkopplung erscheint, kann organisatorisch als Verlust von Kontrolle erlebt werden.

Das bedeutet nicht, dass Widerstand gegen eine Architekturänderung automatisch ein verdeckter Machtkampf ist. Technische Vorschläge können schlecht sein, bestehende Verantwortlichkeiten können gute Gründe haben und eine vermeintlich saubere Trennung kann operative Abläufe verschlechtern. Architektur besitzt aber eine organisatorische Dimension, sobald technische Grenzen mit Entscheidungsräumen zusammenfallen.

Architektur verändert nicht nur Dependencies. Sie kann auch Zuständigkeiten, Einfluss und Kontrolle verändern.

Forschung zu organisatorischen Veränderungen liefert hierfür zumindest einen passenden Interpretationsrahmen. Eilam und Shamir zeigen in ihrer theoretischen und empirischen Arbeit, dass Veränderung unter anderem dann anders wahrgenommen werden kann, wenn sie Selbstbestimmung, Kontinuität oder die eigene professionelle Rolle berührt. Das erlaubt keine Ferndiagnose konkreter Personen und beweist nicht, dass eine bestimmte Architekturänderung als Identitätsbedrohung erlebt wurde. Es zeigt aber, warum Veränderungen an Zuständigkeiten nicht ausschließlich anhand ihrer technischen Qualität bewertet werden müssen.

Wenn die Vergangenheit plötzlich mit zur Debatte steht

Eine grundlegende Architekturdiagnose beschreibt außerdem nie nur die Gegenwart. Wenn ein System über zehn oder fünfzehn Jahre gewachsen ist und eine Analyse zu dem Ergebnis kommt, dass seine Grenzen neu aufgebaut werden müssen, besitzt diese Aussage zwangsläufig eine historische Dimension. Sie kann implizieren, dass frühere Investitionen zwar Funktionen, Kunden oder Umsatz erzeugt haben, aber nicht die strukturelle Substanz hinterlassen haben, die für die nächste Entwicklungsphase benötigt wird.

Damit stehen plötzlich mehr Dinge im Raum als Code. Frühere Strategien, Budgets, Architekturentscheidungen und Führungskonzepte werden aus einer neuen Perspektive betrachtet. Menschen können viele Jahre professioneller Arbeit mit diesen Entscheidungen verbinden, und Organisationen besitzen eigene Erfolgserzählungen darüber, warum bestimmte Projekte aufgebaut wurden und welche Entscheidungen sie erfolgreich gemacht haben.

Die entscheidende Frage lautet deshalb nicht, ob Beteiligte „groß genug“ sind, einen Fehler einzugestehen. Das wäre psychologisch und organisatorisch zu einfach. Interessanter ist eine andere Frage:

Kann eine Organisation ihre bisherige Erfolgserzählung korrigieren, ohne diese Korrektur als persönliche Anklage zu erleben?

Organizational-Learning-Forschung beschäftigt sich seit Langem mit Mechanismen, durch die Organisationen ihre eigenen Annahmen nur schwer hinterfragen und defensive Routinen stabilisieren können. Forschung zu Selbstkonzept und organisationaler Veränderung ergänzt, dass Veränderungen nicht nur sachlich verarbeitet werden, sondern auch Kontinuität und professionelle Identität berühren können. Diese Perspektiven erklären keine konkrete Reaktion in einem Softwareprojekt. Sie machen aber verständlich, warum eine technisch plausible Neubewertung früherer Entscheidungen organisatorisch wesentlich schwerer sein kann als eine Analyse des Repositorys.

Eine Architekturdiagnose kann fachlich richtig formuliert sein und trotzdem wie ein Urteil über die Vergangenheit klingen. Je größer das System und je länger seine Geschichte, desto wichtiger wird diese Unterscheidung.

Der Big Ball of Mud als Rückkopplungssystem

Bis hierhin lassen sich mehrere Mechanismen erkennen: Zeitdruck, wechselnde Verantwortlichkeiten, fachliche Unklarheit, unterschiedliche Entscheidungshorizonte, Wissensverlust, Vertragsgrenzen und fehlende Entscheidungsrechte. Entscheidend ist, dass sie nicht unabhängig voneinander auftreten müssen, sondern sich gegenseitig verstärken können.

Ein möglicher Kreislauf beginnt mit wirtschaftlichem Druck. Dadurch werden lokal und kurzfristig attraktive Lösungen wahrscheinlicher; manche davon erhöhen die technische Kopplung. Höhere Kopplung vergrößert später Koordinationsbedarf und Change Radius, Änderungen werden teurer und der Lieferdruck steigt weiter. Unter diesem zusätzlichen Druck werden kurzfristige Lösungen erneut attraktiver.

Ein anderer Kreislauf kann bei personeller Instabilität beginnen. Mit häufigen Wechseln verschwinden Teile des impliziten Wissens. Bestimmte Bereiche werden dadurch schwerer verständlich und stärker von wenigen verbliebenen Experten abhängig, Veränderungen benötigen mehr Zeit und Einarbeitung, und die organisatorische Belastung steigt weiter. Ein dritter Kreislauf kann aus unklarer fachlicher Ownership entstehen: Fehlende fachliche Entscheidungen werden technisch durch zusätzliche Sonderfälle und mehrere Zuständigkeiten kompensiert, wodurch die Systemgrenzen weniger eindeutig werden. Das erschwert wiederum zukünftigen Product Ownern und Entwicklern, das fachliche Modell aus dem bestehenden System zu rekonstruieren.

Diese Kreisläufe sind analytische Modelle, keine universellen Naturgesetze, und sie werden nicht in jedem System identisch auftreten. Sie zeigen aber, warum ein Big Ball of Mud mehr sein kann als die Summe vergangener schlechter Codeentscheidungen.

Organisatorische Bedingungen können immer wieder genau jene lokalen Entscheidungen attraktiv machen, durch die strukturelle Entgrenzung weitergetragen wird.

In diesem Sinne kann sich ein Big Ball of Mud organisatorisch reproduzieren – nicht weil „die Organisation“ bewusst schlechte Architektur erzeugt, sondern weil dieselben Rahmenbedingungen wiederholt ähnliche lokale Optimierungen nahelegen.

Strukturelle Erosion kann sich selbst verstärken, wenn steigende Änderungskosten zusätzlichen kurzfristigen Druck erzeugen und dadurch lokale Abkürzungen erneut attraktiver werden.

Was die Forschung zeigt – und was nicht

Die Forschung liefert kein Modell, mit dem sich aus einer bestimmten Organisationsstruktur zuverlässig ein Big Ball of Mud vorhersagen ließe. Dafür ist Softwareentwicklung zu kontextabhängig. Conway beschreibt einen Zusammenhang zwischen Kommunikationsstruktur und Systemdesign, die Mirroring Hypothesis untersucht empirisch Beziehungen zwischen Produkt- und Organisationsarchitektur, und Socio-Technical Congruence betrachtet den Koordinationsbedarf, den technische Abhängigkeiten erzeugen. Technical-Debt-Forschung zeigt unter anderem die Bedeutung von Zeitdruck, Budget, Stakeholdern, Management und Entscheidungsprozessen. Arbeiten zu Turnover untersuchen den Verlust von Entwicklungswissen, während Requirements- und Product-Owner-Forschung sichtbar macht, wie stark fachliche Klärung von Kommunikation und organisatorischer Einbettung abhängt.

Keine dieser Forschungsrichtungen sagt, Management erzeuge schlechte Architektur. Ebenso wenig rechtfertigt sie die Gegenposition, Entwickler seien lediglich Opfer ihrer Organisation. Technische Entscheidungen bleiben technische Entscheidungen; Entwickler, Architekten und Teams besitzen Handlungsspielräume und Verantwortung.

Die empirische Literatur legt jedoch nahe, den Kontext dieser Entscheidungen ernst zu nehmen. Eine Softwareorganisation bestimmt mit, wie teuer Abstimmung ist, verteilt Entscheidungsrechte, definiert Budget- und Planungshorizonte, ordnet Verantwortlichkeiten zu, entscheidet über beteiligte Stakeholder und schafft die Rahmenbedingungen, unter denen langfristige und kurzfristige Ziele gegeneinander abgewogen werden. Sie bewahrt Wissen oder verliert es.

Damit bestimmt sie nicht jede Codezeile. Aber sie verändert den Raum, in dem diese Codezeile entsteht.

Warum der Code trotzdem „das kleinste Problem“ sein konnte

Damit lässt sich die Aussage des Principal Architects vom Anfang anders einordnen. Der Code war keineswegs „klein“: Die tausenden Dateien, zyklischen Dependencies, globalen Zustände, fehlenden Grenzen und schwer nachvollziehbaren Wirkungszusammenhänge blieben reale technische Probleme. Für sie existierten jedoch zumindest technische Operationen. Man kann Code analysieren, Dependencies visualisieren, Tests aufbauen, Verantwortlichkeiten neu schneiden, Module extrahieren und Zustände entkoppeln. Selbst ein sehr schlechter technischer Zustand besitzt grundsätzlich Ansatzpunkte für technische Veränderung.

Eine solche Veränderung benötigt allerdings mehr als eine richtige Zielarchitektur. Sie braucht ausreichend Kontinuität, damit eine Richtung über mehrere Jahre verfolgt werden kann, fachliche Klarheit, damit neue technische Grenzen sinnvoll definiert werden können, und Entscheidungsfähigkeit, wenn kurzfristige Interessen mit langfristigen Strukturzielen kollidieren. Sobald technische Grenzen bestehende Zuständigkeiten berühren, benötigt sie außerdem organisatorische Legitimation und einen Zeithorizont, in dem sich die Investition in Struktur überhaupt auszahlen kann.

Eine technische Sanierungsstrategie kann deshalb korrekt sein und trotzdem scheitern, wenn die Organisation sie nicht lange genug tragen kann. Damit verschiebt sich die Diagnose: Der Big Ball of Mud ist technisch sichtbar, seine Entstehungsgeschichte reicht jedoch durch viele Ebenen einer Organisation.

Literatur

• Besker, Terese; Martini, Antonio; Bosch, Jan (2022): The use of incentives to promote technical debt management. Information and Software Technology, 142, 106740. DOI: 10.1016/j.infsof.2021.106740.
• Cataldo, Marcelo; Herbsleb, James D.; Carley, Kathleen M. (2008): Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity. ESEM 2008. DOI: 10.1145/1414004.1414008.
• Conway, Melvin E. (1968): How Do Committees Invent? Datamation.
• Eilam, Galit; Shamir, Boas (2005): Organizational Change and Self-Concept Threats: A Theoretical Perspective and a Case Study. The Journal of Applied Behavioral Science, 41(4), 399–421. DOI: 10.1177/0021886305280865.
• Klotins, Eriks; Unterkalmsteiner, Michael; Gorschek, Tony (2019): Software engineering in start-up companies: An analysis of 88 experience reports. Empirical Software Engineering, 24(1), 68–102.
• MacCormack, Alan; Baldwin, Carliss Y.; Rusnak, John (2012): Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309–1324. DOI: 10.1016/j.respol.2012.04.011.
• Nielsen, Mille Edith; Madsen, Christian Østergaard (2022): Stakeholder influence on technical debt management in the public sector: An embedded case study. Government Information Quarterly, 39(3), 101706. DOI: 10.1016/j.giq.2022.101706.
• Ramač, Robert et al. (2022): Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry. Journal of Systems and Software, 184, 111114. DOI: 10.1016/j.jss.2021.111114.
• Rigby, Peter C.; Zhu, Yue Cai; Donadelli, Samuel M.; Mockus, Audris (2016): Quantifying and mitigating turnover-induced knowledge loss: Case studies of Chrome and a project at Avaya. Proceedings of ICSE 2016, 1006–1016. DOI: 10.1145/2884781.2884851.
• Robillard, Martin P. (2021): Turnover-induced knowledge loss in practice. Proceedings of ESEC/FSE 2021, 1292–1302. DOI: 10.1145/3468264.3473923.
• Wiese, Marion; Borowa, Klara (2023): IT managers’ perspective on Technical Debt Management. Journal of Systems and Software, 202, 111700. DOI: 10.1016/j.jss.2023.111700.

Conclusion

Als der Principal Architect den technischen Zustand sinngemäß mit „Der Code ist das kleinste Problem“ zusammenfasste, meinte er nicht, dass die Architektur harmlos war. Sie war massiv erodiert. Der Code hatte jedoch eine Eigenschaft, die viele der anderen Probleme nicht hatten: Er ließ sich analysieren und mit technischen Mitteln verändern. Schwieriger war die Frage, welche Organisation diese Veränderung über einen langen Zeitraum tragen sollte.

Dependencies und globale Zustände werden von Entwicklern implementiert, und technische Verantwortung bleibt deshalb bei denjenigen, die technische Entscheidungen treffen. Die Bedingungen, unter denen diese Entscheidungen entstehen, reichen jedoch weiter. Anforderungen beeinflussen sie ebenso wie wirtschaftlicher Druck; Verträge definieren Grenzen, Teamstrukturen bestimmen Koordinationswege, Verantwortlichkeiten wechseln, Wissen geht verloren oder muss neu aufgebaut werden. Führung setzt Zeithorizonte und Prioritäten, während Entscheidungsrechte bestimmen, wer eine technische Grenze auch dann schützen kann, wenn ihre Einhaltung kurzfristig unbequem wird.

Ein Big Ball of Mud entsteht deshalb nicht entweder technisch oder organisatorisch. Die Ebenen greifen ineinander. Lokale Entscheidungen werden im Code dauerhaft, während die Organisation sich weiter verändert. Neue Teams übernehmen technische Entscheidungen ihrer Vorgänger und treffen unter neuen Rahmenbedingungen weitere Entscheidungen. So kann eine Codebasis über Jahre die Spuren vieler Anforderungen, Budgets, Projekte, Führungen, Teamgrenzen und Verträge akkumulieren.

Der Big Ball of Mud ist im Repository sichtbar. Seine Ursachen liegen nicht ausschließlich dort.

Wenn technische, fachliche, organisatorische und wirtschaftliche Kräfte gemeinsam an den Bedingungen beteiligt waren, unter denen dieser Zustand entstanden ist, wird auch eine nachhaltige Veränderung mehr als eine rein technische Perspektive benötigen. Wie diese Kräfte zusammengebracht werden können, ist eine andere Frage.

Die Architektur lebt im Code. Aber die Kräfte, die sie formen, reichen weit darüber hinaus.