Aber es funktioniert doch

Die Software läuft.

Sie läuft nicht nur. Sie sieht gut aus. Kunden melden sich an. Geschäftsprozesse funktionieren. Das Dashboard lädt. Ein weiteres Feature wurde ausgeliefert. Vielleicht existieren Monitoring, CI/CD, automatisierte Tests, Sonar und eine moderne Benutzeroberfläche. Releases finden statt. Verträge werden erfüllt. Umsatz hängt an diesem System. Und dann sagt ein Architekt:

„Wir haben ein massives strukturelles Problem.“

Die naheliegende Frage lautet:

Wie kann etwas kaputt sein, das funktioniert?

Bei einem Gebäude ist dieser Widerspruch leichter aufzulösen. Risse im Mauerwerk, Feuchtigkeit, Korrosion, Setzungen oder beschädigte tragende Elemente sind zumindest prinzipiell beobachtbar. Man muss kein Bauingenieur sein, um zu verstehen, dass ein gebrochener Träger ein Problem darstellt. Software besitzt diese Form der Sichtbarkeit nicht.

Ein marodes Gebäude zeigt Risse. Ein marodes Softwaresystem zeigt weiterhin die Login-Maske.

Das ist keine perfekte Analogie. Ein Softwaresystem ist kein Gebäude, und Code unterliegt anderen Veränderungsmechanismen als Beton oder Stahl. Die Analogie macht aber einen entscheidenden Unterschied sichtbar: Strukturelle Probleme in Software müssen den unmittelbar beobachtbaren Nutzen des Systems nicht zerstören. Genau deshalb ist ein Big Ball of Mud aus der Perspektive eines Stakeholders schwerer zu erkennen, als es für einen Entwickler erscheinen mag. Im vorherigen Artikel dieser Serie stand eine technische Frage im Mittelpunkt:

Wo kann ich mit hinreichender Sicherheit aufhören, über diese Änderung nachzudenken?

Dieser Artikel wechselt die Perspektive. Nicht mehr: Was sieht der Entwickler? Sondern:

Was sieht eigentlich der Stakeholder?

Zwei Eigenschaften desselben Systems

Ein Product Owner, Projektleiter oder Auftraggeber beurteilt ein System zunächst anhand vollkommen legitimer Fragen:

• Funktioniert der Geschäftsprozess?
• Können Kunden arbeiten?
• Ist die Anwendung verfügbar?
• Werden Anforderungen umgesetzt?
• Werden Verträge und Lieferverpflichtungen erfüllt?

Der Architekt betrachtet zusätzlich andere Eigenschaften:

• Lassen sich Änderungen zuverlässig begrenzen?
• Sind Verantwortlichkeiten klar?
• Sind Abhängigkeiten nachvollziehbar und gerichtet?
• Ist relevantes Wissen lokal oder über das gesamte System verteilt?
• Können mehrere Teams unabhängig voneinander arbeiten?
• Wie viel System muss verstanden werden, um eine lokale Änderung sicher vorzunehmen?
• Wie groß ist die mögliche Regression Surface einer Änderung?
• Bleiben diese Eigenschaften auch bei weiteren Jahren der Entwicklung erhalten?

Beide Perspektiven beschreiben dasselbe System. Sie beantworten aber unterschiedliche Fragen.

Ein Softwaresystem kann heute zuverlässig Wert liefern und gleichzeitig immer schlechter darin werden, morgen verändert zu werden.

Damit verschwindet der scheinbare Widerspruch vom Anfang. Die Aussage des Stakeholders – „Das System funktioniert“ – kann korrekt sein. Die Aussage des Architekten – „Wir haben ein strukturelles Problem“ – kann gleichzeitig korrekt sein. Der Konflikt entsteht nicht zwischen Vernunft und Unvernunft. Er entsteht zwischen zwei unterschiedlichen Arten von Evidenz.

Funktionale Stabilität und strukturelle Veränderungsfähigkeit sind zwei unterschiedliche Eigenschaften eines Softwaresystems.

Der Stakeholder sieht den Wert. Der Architekt sieht zusätzlich die Steigung

Der Unterschied ist auch ein Unterschied im Zeithorizont. Ein Stakeholder muss wissen, was das System heute leistet. Kunden warten nicht auf eine zukünftige Architekturqualität. Budgets gelten für konkrete Perioden. Verträge haben Termine. Features besitzen Markt- oder Projektrelevanz. Der Architekt interessiert sich ebenfalls für diesen aktuellen Zustand. Zusätzlich beobachtet er aber, wie sich das System unter Veränderung verhält. Als Metapher könnte man sagen:

Der Stakeholder sieht den aktuellen Wert. Der Architekt sieht zusätzlich die Steigung.

Diese Steigung ist keine empirisch sauber definierte Kurve, die in jedem Projekt Jahr für Jahr monoton nach oben zeigen müsste. Gemeint ist etwas Einfacheres: Strukturelle Erosion kann sich weniger im heutigen Output als in der Entwicklung zukünftiger Veränderungskosten zeigen. Eine Änderung erfordert plötzlich mehr Exploration. Ein Release benötigt mehr Absicherung. Immer mehr Bereiche können von einer lokalen Änderung betroffen sein. Bestimmte Personen müssen häufiger konsultiert werden. Zwei fachlich unabhängige Teams kollidieren technisch miteinander. Neue Mitarbeiter benötigen länger, bis sie sicher verändern können.

Keine dieser Beobachtungen bedeutet zwangsläufig, dass das System morgen zusammenbricht. Das ist gerade das Problem. Die Software kann weiterhin zuverlässig ihren Zweck erfüllen, während ihre Fähigkeit, auf zukünftige Anforderungen zu reagieren, schrittweise schlechter vorhersehbar wird. Das System funktioniert heute, während der Architekt vor den Kosten und Risiken von morgen warnt.

Das Messproblem der Softwareentwicklung

Für einen Entscheider entsteht damit ein praktisches Problem: Wie soll man etwas bewerten, das nur indirekt sichtbar ist? Viele aus klassischer Fertigung und dem Controlling vertraute Messlogiken lassen sich auf Softwareentwicklung nur begrenzt übertragen. Auch industrielle Fertigung ist selbstverständlich komplex. Trotzdem existieren dort häufig vergleichsweise stabile und physisch beobachtbare Größen:

• Stückzahlen,
• Durchsatz,
• Ausschuss,
• Materialverbrauch,
• Maschinenlaufzeiten,
• Stückkosten,
• Margen.

In vielen Fertigungsprozessen lässt sich Output in vergleichsweise stabile Einheiten übersetzen. Produktionsmengen, Materialverbrauch oder Ausschuss können unter definierten Bedingungen beobachtet und über Zeit verglichen werden. In der Softwareentwicklung beginnt die Schwierigkeit bereits mit der Frage, was überhaupt als Einheit des Outputs gelten soll: ein Feature, ein geschlossenes Ticket, ein Story Point, eine neue API, eine Zeile Code, Business Value, ein verhinderter Produktionsfehler, eine erfolgreiche Migration oder eine Woche, in der vorhandener Code vereinfacht wurde. Keine dieser Größen ist für sich genommen eine stabile Entsprechung zum „Stück“ in einer Fertigung.

Auch der Input ist nicht stabil vergleichbar. Zwei Entwicklerstunden sind ökonomisch nicht automatisch zwei identische Produktionseinheiten. Der notwendige Aufwand hängt unter anderem vom vorhandenen Wissen, der Codebasis, der Teamstruktur, dem Tooling, der fachlichen Komplexität, externen Abhängigkeiten und der bestehenden Architektur ab. Eine allgemeingültige Kennzahl wie

„Ein Settings-Dialog benötigt branchenweit durchschnittlich 13,7 Entwicklerstunden“

wäre deshalb kaum sinnvoll. Die Forschung zur Softwareproduktivität spiegelt dieses Problem wider. Petersen zeigt in seiner systematischen Kartierung und Literaturübersicht, wie unterschiedlich Produktivität in Softwareentwicklung gemessen und vorhergesagt wird. Das später entwickelte SPACE-Framework formuliert das Problem noch expliziter: Entwicklerproduktivität ist multidimensional und lässt sich nicht sinnvoll auf eine einzelne Aktivitätskennzahl reduzieren. Produktivität umfasst dort unter anderem Zufriedenheit und Wohlbefinden, Performance, Aktivität, Kommunikation und Zusammenarbeit sowie Effizienz und Flow. Das ist für die Architekturfrage entscheidend.

Natürlich besitzt Softwareentwicklung sehr wohl belastbare Kennzahlen. Verfügbarkeit, Fehlerraten, Durchlaufzeiten oder Deployment-Frequenz können wichtige Eigenschaften eines Systems und seines Lieferprozesses sichtbar machen. Das Problem liegt nicht darin, dass Software grundsätzlich unmessbar wäre. Es liegt darin, dass keine einzelne dieser Größen unmittelbar beantwortet, wie viel zusätzliche Veränderungsarbeit eine bestimmte innere Struktur verursacht.

Wenn schon Softwareproduktivität als Ganzes keine stabile Stückzahl besitzt, wird es noch schwieriger, den Produktivitätseffekt einer schwer direkt beobachtbaren strukturellen Eigenschaft zu isolieren.

Langsam – verglichen womit?

Angenommen, ein Feature benötigt sechs Wochen. Ist das langsam? Vielleicht war die fachliche Anforderung außergewöhnlich komplex. Vielleicht waren Anforderungen lange unklar. Vielleicht wartete das Team auf einen externen Dienstleister. Vielleicht war der verantwortliche Entwickler mit dem Bereich noch nicht vertraut. Vielleicht war die ursprüngliche Schätzung schlicht falsch. Vielleicht war die Anwendung strukturell so stark gekoppelt, dass für eine kleine Änderung große Teile des Systems verstanden, angepasst und getestet werden mussten. Die unmittelbar beobachtbare Tatsache lautet nur:

Das Feature hat sechs Wochen gedauert.

Was der Organisation fehlt, ist das Gegenexperiment. Wie lange hätte exakt dieselbe Anforderung mit demselben Team, denselben Kunden, denselben fachlichen Randbedingungen und derselben Qualitätsanforderung in einer anders strukturierten Codebasis benötigt? Dieses zweite System existiert normalerweise nicht.

Performanceprobleme in Software besitzen häufig kein sichtbares Counterfactual.

Wir sehen, wie teuer eine Änderung in unserem System war. Wir sehen nicht, wie teuer dieselbe Änderung in einem strukturell gesunden Vergleichssystem gewesen wäre. Das unterscheidet Architekturprobleme beispielsweise von einem Produktionsschritt, bei dem zwei Maschinen unter hinreichend ähnlichen Bedingungen direkt miteinander verglichen werden können. Auch deshalb kann ein Entwickler vollkommen überzeugt sein, dass eine Änderung „viel zu teuer“ war, während ein Stakeholder dafür keine eindeutige Vergleichsbasis besitzt. Beide können anhand der jeweils verfügbaren Evidenz vernünftig argumentieren.

Software besitzt keine einfache Stückkostenrechnung

Das Problem wird noch deutlicher, wenn Aktivität und Ergebnis verwechselt werden. Ein Entwickler kann 2.000 Zeilen Code löschen und damit enormen Wert schaffen. Ein anderer kann 10.000 Zeilen hinzufügen und dadurch zukünftige Änderungen verteuern. Ein Team kann eine Woche lang kein einziges sichtbares Feature ausliefern und dadurch eine wiederkehrende technische Hürde beseitigen, die sonst jahrelang Aufwand erzeugt hätte. Ein anderes Team kann zehn Tickets abschließen und dabei zusätzliche Kopplung erzeugen, die erst bei späteren Änderungen sichtbar wird.

Aktivität ist nicht dasselbe wie Produktivität, und Outputmenge ist nicht automatisch Business Value.

Genau davor warnt auch das SPACE-Framework: Aktivitätsmetriken können eine Dimension der Arbeit sichtbar machen, dürfen aber nicht als vollständiges Maß individueller oder organisatorischer Produktivität interpretiert werden.

Für Stakeholder entsteht daraus ein unangenehmes Steuerungsproblem. Geld lässt sich sehr präzise messen. Headcount lässt sich präzise messen. Arbeitszeit lässt sich präzise messen. Die dadurch produzierte nachhaltige Veränderungsfähigkeit eines Softwaresystems lässt sich wesentlich schlechter in eine einzelne Zahl übersetzen.

Das zusätzliche Messbarkeitsproblem der Architektur

Architektur verschärft dieses Problem noch einmal. Ihr Wert besteht häufig gerade nicht in einer heute sichtbaren zusätzlichen Funktion. Er kann darin bestehen, dass eine spätere Änderung nur drei statt zwölf Dateien berührt. Dass ein Entwickler einen fachlichen Slice verstehen kann, ohne zuvor fünf globale Services analysieren zu müssen. Dass zwei Teams tatsächlich unabhängig voneinander arbeiten können. Dass ein Fehler auf einen begrenzten Bereich beschränkt bleibt. Dass für eine neue Anforderung kein bestimmter Mitarbeiter benötigt wird, der als Einziger die historischen Seiteneffekte kennt. Oder schlicht darin, dass eine bestimmte Klasse von Problemen gar nicht erst entsteht.

Gute Architektur produziert häufig keine sichtbare Leistung. Sie verhindert unsichtbare Zusatzarbeit.

Der ökonomische Wert liegt damit teilweise in einem Ereignis, das gerade nicht eingetreten ist. Ein komplizierter Regressionstest war nicht notwendig. Eine dreiwöchige Analyse war nicht notwendig. Ein Abstimmungstermin zwischen vier Teams war nicht notwendig. Ein Produktionsfehler trat nicht auf. Eine Änderung musste nicht durch einen der letzten beiden Systemexperten geprüft werden. Das ist wertvoll – aber schwierig zu beobachten.

Der Wert guter Architektur liegt häufig in Problemen, die nie entstehen.

Daraus folgt ausdrücklich nicht, dass jede Architekturinvestition wirtschaftlich sinnvoll wäre. Auch Refactorings können unnötig, schlecht priorisiert oder riskanter als der bestehende Zustand sein.

Das Messproblem bleibt trotzdem bestehen: Die Kosten der Investition sind unmittelbar sichtbar. Ein erheblicher Teil ihres möglichen Nutzens besteht dagegen aus vermiedener zukünftiger Arbeit.

Der asymmetrische Business Case

Ein neues Feature besitzt häufig einen vergleichsweise gut kommunizierbaren Business Case: Es gibt einen Scope und einen Kundenwunsch, vielleicht auch eine Deadline, einen Vertrag oder erwarteten Umsatz. Architekturarbeit sieht aus Entscheidungsperspektive anders aus. Ihre Kosten entstehen heute, während Entwickler in dieser Zeit nicht an anderen Features arbeiten; eine Migration kann Fehler verursachen und ein Umbau einen Release gefährden. Der Nutzen zeigt sich dagegen möglicherweise erst bei den nächsten zehn, fünfzig oder hundert Änderungen – und ein erheblicher Teil davon besteht aus Kosten, die anschließend gerade nicht entstehen und deshalb auch nicht beobachtet werden.

Das erzeugt eine fundamentale Asymmetrie:

Ein Stakeholder lehnt Architekturarbeit nicht unbedingt ab, weil er Technik nicht versteht. Er lehnt möglicherweise eine Investition ab, deren Kosten sicher und deren Nutzen schwer messbar ist.

Für jemanden, der reales Budget, reale Kunden und reale Lieferverpflichtungen verantwortet, ist diese Skepsis nicht überraschend. Überraschend wäre eher das Gegenteil.

Organisationen können nur steuern, was sie beobachten können. Gerade strukturelle Veränderungskosten sind jedoch oft nur indirekt sichtbar.

„Aber es funktioniert“ ist reale Evidenz

Es wäre deshalb zu einfach, den Satz „Aber es funktioniert doch“ als Ausrede abzutun. Dass das System funktioniert, ist reale Evidenz: Kunden können arbeiten, Umsatz wird erwirtschaftet und geschäftskritische Prozesse laufen. Vielleicht erfüllt das System seit Jahren seine Verfügbarkeitsziele oder hat gerade erst wieder einen erfolgreichen Release erlebt. Diese Beobachtungen müssen ernst genommen werden; sie beantworten nur nicht jede relevante Frage.

„Es funktioniert“ beantwortet die Frage nach funktionaler Korrektheit. Es beantwortet nicht automatisch die Frage nach struktureller Veränderungsfähigkeit.

Aus einem stabilen Betrieb folgt nicht, dass die nächste Änderung günstig ist. Aus einem erfolgreichen Release folgt nicht, dass zwei weitere Teams unabhängig entwickeln können. Aus einer professionellen Oberfläche folgt nicht, dass State Ownership eindeutig ist. Und aus zehn Jahren erfolgreichem Betrieb folgt nicht, dass relevantes Wissen ausreichend im System selbst abgebildet ist.

Umgekehrt folgt aus einer Warnung des Architekten auch nicht automatisch, dass dieser recht hat. Technische Experten können Risiken überschätzen, Alternativen falsch beurteilen oder ihre eigenen Präferenzen mit wirtschaftlicher Notwendigkeit verwechseln. Der Stakeholder steht damit zwischen zwei unvollständigen Informationslagen: Das funktionierende System ist sichtbar, der strukturelle Schaden dagegen zunächst eine Diagnose.

Mehr Menschen lösen das Problem nicht automatisch

Eine klassische Reaktion auf Kapazitätsprobleme lautet, zusätzliche Kapazität zu beschaffen – etwa durch mehr Maschinen, zusätzliche Schichten oder mehr Personal. Auch in Softwareentwicklung funktioniert das grundsätzlich. Ein gut strukturiertes System kann von zusätzlichen Entwicklern und Teams erheblich profitieren. Aber zusätzliche Entwickler erzeugen nur dann zusätzliche unabhängige Entwicklungsleistung, wenn es genügend Arbeit gibt, die tatsächlich unabhängig durchgeführt werden kann. In einem stark entgrenzten System kann genau das schwierig werden. Neue Entwickler müssen zunächst große Teile des Gesamtsystems verstehen, mehrere Teams verändern denselben globalen State, gemeinsame Services werden zu Konfliktpunkten und Changes besitzen überlappende Regression Surfaces. Gleichzeitig werden dieselben wenigen Experten für Reviews und Rückfragen benötigt, während fachlich unabhängige Anforderungen technisch miteinander kollidieren. Damit verändert sich die Kapazitätsgleichung.

Das System besitzt zu wenig unabhängige Veränderungsräume, um zusätzliche Entwickler vollständig in unabhängige Produktivität zu übersetzen.

Die Software-Engineering-Forschung beschäftigt sich seit Langem mit dieser Verbindung zwischen technischen Abhängigkeiten und organisatorischer Koordination. Cataldo et al. formulieren auf Basis empirischer Projektanalyse den grundlegenden Zusammenhang, dass Aufgabenabhängigkeiten Koordinationsbedarf erzeugen. MacCormack, Baldwin und Rusnak fanden in ihrer Untersuchung zudem deutliche Zusammenhänge zwischen Produktarchitektur und Organisationsstrukturen – die sogenannte Mirroring Hypothesis. Beide Arbeiten rechtfertigen keine einfache Kausalformel, sie zeigen aber, warum technische Modularität und organisatorische Unabhängigkeit nicht vollständig voneinander getrennt betrachtet werden können.

Koordinationskosten sind dabei kein spezielles Merkmal eines Big Ball of Mud. Auch in gut modularisierten Systemen wächst produktive Kapazität nicht linear mit jedem zusätzlichen Entwickler. Der hier relevante Punkt ist enger: Wenn technische Grenzen fachlich unabhängige Arbeit nicht mehr zuverlässig trennen, können zusätzliche Personen auf dieselben Abhängigkeiten, Wissensengpässe und Regression Surfaces treffen. Strukturelle Entgrenzung kann vorhandene Koordinationskosten damit zusätzlich verstärken. Umgangssprachlich:

Man kann das Problem irgendwann nicht mehr einfach mit mehr Entwicklern erschlagen.

Nicht weil zusätzliche Menschen grundsätzlich nichts bringen. Sondern weil zusätzliche Menschen zusätzliche Kommunikation und Koordination erzeugen, während die Anzahl unabhängig bearbeitbarer Veränderungsräume möglicherweise kaum wächst.

Gute Architektur skaliert deshalb nicht nur technisch. Sie kann auch organisatorische Parallelität ermöglichen, weil fachlich getrennte Änderungen tatsächlich getrennt bearbeitet werden können.

Das ist keine Empfehlung für Microservices, Microfrontends oder irgendeine andere konkrete Architekturform. Entscheidend ist etwas Grundsätzlicheres: Können Änderungen unabhängig stattfinden?

Zusätzliche Entwicklungskapazität hilft nur begrenzt, wenn das System nicht genügend unabhängige Arbeitsräume besitzt.

Mehr Entwickler, kaum mehr Durchsatz

Für einen Stakeholder wird dieser Mechanismus erst über seine Auswirkungen sichtbar. Angenommen, eine Organisation beschäftigt zehn Entwickler. Die Produktentwicklung wächst, deshalb werden zehn weitere eingestellt. Die Kosten dieser Entscheidung sind leicht beobachtbar. Die zusätzlichen Personalkosten sind unmittelbar sichtbar und lassen sich vergleichsweise gut beziffern. Der Feature-Durchsatz muss sich deshalb aber nicht annähernd verdoppeln. Vielleicht steigt er deutlich weniger als erwartet. Die Organisation benötigt eine Erklärung. Für den geringeren Durchsatz gibt es viele naheliegende Erklärungen: Vielleicht wurden die falschen Entwickler eingestellt, das Recruiting funktioniert nicht, es gibt zu viele Meetings, Führung fehlt, Anforderungen sind schwieriger geworden oder die neuen Mitarbeiter sind schlicht noch nicht eingearbeitet. Jede dieser Erklärungen kann im konkreten Fall stimmen. Es existiert aber noch eine andere mögliche Erklärung: Die zusätzlichen Entwickler konkurrieren um dieselben technischen Engpässe, benötigen dieselben Experten und verändern dieselben globalen Strukturen. Mit der Zahl gleichzeitig laufender Changes steigt damit auch die Zahl möglicher Überschneidungen.

Die Organisation hat ihre personelle Kapazität erhöht, ohne dass die Anzahl unabhängig bearbeitbarer Veränderungsräume entsprechend gewachsen ist. Von außen sieht das zunächst nicht nach Architektur aus. Es sieht nach einem Produktivitätsproblem aus.

„Das waren halt noch gute Entwickler“

Ähnlich schwierig ist die Interpretation individueller Produktivität. Ein Entwickler arbeitet seit acht Jahren am System. Er kennt historische Entscheidungen, ungewöhnliche Seiteneffekte, versteckte Abhängigkeiten und Stellen, die man besser nicht verändert. Er erledigt eine bestimmte Klasse von Aufgaben vergleichsweise schnell. Dann verlässt er das Unternehmen. Seine Nachfolger benötigen für ähnliche Änderungen deutlich länger. Eine plausible Erklärung lautet:

„Die früheren Entwickler waren einfach besser.“

Das kann korrekt sein. Erfahrung und individuelle Kompetenz spielen selbstverständlich eine Rolle. Es existiert jedoch eine zweite Hypothese. Der langjährige Mitarbeiter hatte über Jahre ein mentales Modell aufgebaut, das fehlende explizite Systemstruktur kompensierte. Er wusste nicht nur, was im Code stand. Er wusste, welche Teile entgegen ihrer Bezeichnung zusammengehörten, welche Abhängigkeit historisch entstanden war und welcher scheinbar lokale Change an einer ganz anderen Stelle Konsequenzen hatte. Dann misst die Organisation mit vermeintlicher individueller Produktivität teilweise etwas anderes: die Menge impliziten Systemwissens, die eine Person über Jahre akkumuliert hat.

Was wie außergewöhnliche individuelle Produktivität aussieht, kann teilweise die Fähigkeit sein, eine strukturelle Schwäche durch außergewöhnliches Systemwissen zu kompensieren.

Das macht die frühere Leistung nicht weniger real, verändert aber die Diagnose dafür, warum sie sich nicht ohne Weiteres durch eine andere Person ersetzen lässt.

Das KPI-Vakuum

Wenn strukturelle Qualität schwer direkt beobachtbar ist, muss eine Organisation trotzdem steuern. Dafür greift sie auf Größen zurück, die verfügbar und wiederholbar erfassbar sind: Tickets, Velocity, Lead Time, Deployment Frequency, Defect Counts, Code Coverage, Sonar Issues, Budget oder Headcount. Diese Kennzahlen sind nicht grundsätzlich schlecht; viele beantworten wichtige Fragen. Problematisch wird es erst, wenn eine gut messbare Proxy-Metrik zur vollständigen Beschreibung eines wesentlich schlechter messbaren strukturellen Problems wird.

Ein anschauliches Beispiel ist die Aussage:

„Wir haben jetzt Sonar. Fixt die Sonar Issues.“

SonarQube kann wertvolle statische Qualitätsinformationen liefern. Der interessante Punkt liegt deshalb nicht im Werkzeug, sondern in der unterschiedlichen organisatorischen Verwertbarkeit zweier Aussagen. Ein Architekt kann sagen:

„Wir haben strukturelle Entgrenzung, unklare Ownership und schwer begrenzbare Changes.“

Damit entsteht sofort ein Übersetzungsproblem: Wie viel davon haben wir, wie erkennen wir eine Verbesserung und welcher Zielwert könnte überhaupt in einem Management-Dashboard stehen? Ein Werkzeug kann dagegen beispielsweise melden:

8.432 Issues.

Diese Zahl lässt sich erfassen, vergleichen, reporten und mit einem Zielwert versehen. Genau dadurch wird der Proxy organisatorisch attraktiv, auch wenn er das eigentliche strukturelle Problem nur teilweise repräsentiert.

Organisationen benötigen beobachtbare Größen, um Entscheidungen zu treffen. Architekturprobleme sind aber häufig nur indirekt beobachtbar.

Was sich gut messen lässt, ist deshalb nicht automatisch das, was am wichtigsten ist. Umgekehrt sollten Lead Time, Deployment Frequency oder Defect Counts nicht abgewertet werden, nur weil sie keine vollständigen Architekturmetriken sind. Sie messen reale Eigenschaften des Systems und seines Lieferprozesses – sie erzählen nur nicht die ganze Geschichte.

Jedes Symptom besitzt eine lokale Erklärung

Damit entsteht eine weitere Schwierigkeit. Ein Big Ball of Mud produziert nicht notwendigerweise ein eindeutiges Symptom mit der Aufschrift:

„Ursache: fehlende Systemstruktur.“

Stattdessen sieht eine Organisation viele einzelne Ereignisse: Features dauern länger als erwartet, Releases werden anstrengend, Firefighting und Kundendeeskalationen häufen sich, ein Team wirkt resigniert, einzelne Experten werden ständig gebraucht, neue Mitarbeiter benötigen lange zur Einarbeitung, zusätzlicher Headcount erzeugt weniger Durchsatz als erwartet oder Menschen verlassen das Unternehmen. Für jedes dieser Ereignisse existiert eine plausible lokale Erklärung – von einer Fehlbesetzung über Recruiting, Führung und unklare Anforderungen bis hin zu schwierigen Kunden, langsamer QA oder ungeeigneten Prozessen. Auch hier gilt: Jede einzelne Erklärung kann korrekt sein. Die systemische Gefahr entsteht nicht dadurch, dass lokale Erklärungen grundsätzlich falsch wären.

Sie entsteht, wenn jedes Symptom ausschließlich lokal erklärt wird und dadurch nie geprüft wird, ob mehrere dieser Beobachtungen möglicherweise einen gemeinsamen strukturellen Hintergrund besitzen.

Ein systemisches Problem kann erstaunlich lange unsichtbar bleiben, wenn jedes seiner Symptome eine plausible lokale Erklärung bekommt.

Lost in Translation

Dazu kommt ein Kommunikationsproblem. Der Stakeholder sagt:

„Wir brauchen das Feature bis Oktober.“

Der Architekt antwortet:

„Dafür müssten wir eigentlich zuerst State Ownership und Slice Boundaries stabilisieren.“

Beide Aussagen können sachlich korrekt sein. Sie gehören nur zu unterschiedlichen Kausalmodellen. Der Stakeholder beschreibt die Situation vor allem über Kosten, Nutzen, Termine, Verträge, Kunden und Risiken; der Architekt über Kopplung, Zuständigkeiten, Änderungsradien, Abhängigkeiten, Regression und langfristige Änderbarkeit. Die Schwierigkeit besteht nicht darin, dass eine Seite „das System versteht“ und die andere nicht.

Technische und fachliche Führungskräfte beobachten dasselbe System durch unterschiedliche Modelle.

Business-IT-Alignment-Forschung behandelt genau diese Schnittstelle seit Jahrzehnten. Luftman, Lyytinen und Ben-Zvi beschreiben Alignment nicht als einzelne technische Fähigkeit, sondern unter anderem über Kommunikation zwischen IT und Business, gemeinsame Governance, Partnerschaft und die Fähigkeit, IT-Wert zu verstehen und zu bewerten. Ihre Arbeit basiert auf einer großen organisationsübergreifenden Datengrundlage und zeigt gerade deshalb, dass Alignment mehr als die technische Qualität eines Systems umfasst.

Auch aktuelle Forschung zu Technical Debt zeigt diesen Übersetzungsbedarf sehr konkret. Wiese und Borowa untersuchten die Perspektive von IT-Managern anhand von 16 semi-strukturierten Interviews und einer ergänzenden Fokusgruppe. Die Befragten verstanden Technical Debt grundsätzlich und betrachteten dessen Management als wichtig. Schwierigkeiten lagen unter anderem in der Kommunikation zwischen technischen und fachlichen Akteuren, in der Etablierung eines systematischen Umgangs damit und bei alten Systemen, die trotz erheblicher Altlasten weiterhin geschäftlichen Wert liefern. Die Autorinnen schlagen deshalb unter anderem ein Modell vor, das Ursachen- und Wirkungsketten von Technical Debt für Business-Stakeholder sichtbarer machen soll.

Das ist ein bemerkenswerter Befund. Das Problem ist nicht zwingend fehlende Bereitschaft, technische Qualität ernst zu nehmen. Schon die gemeinsame Beobachtbarkeit des Problems ist schwierig.

Stakeholder und Architekt sehen dasselbe System. Sie beobachten jedoch unterschiedliche Eigenschaften und Zeithorizonte.

Wenn technische Warnungen ihre Signalwirkung verlieren

Die Kommunikation kann durch eine weitere Erfahrung erschwert werden. Ein Stakeholder hört im Laufe eines Projekts möglicherweise Aussagen wie „Das geht technisch nicht“ – und später geht es doch. Vielleicht heißt es, vor einem Feature müsse zunächst refactort werden, und das Feature wird trotzdem gebaut. Oder jemand warnt, das System halte „nicht mehr lange aus“, während es drei Jahre später weiterhin läuft. Daraus kann ein nachvollziehbares organisationales Lernmuster entstehen. Technische Warnungen werden irgendwann nicht mehr ausschließlich als Prognosen verstanden, sondern möglicherweise auch als Teil einer Priorisierungs- oder Ressourcenverhandlung. Das bedeutet nicht, dass Entwickler bewusst übertreiben. Es bedeutet ebenso wenig, dass ein Stakeholder technischen Aussagen grundsätzlich misstraut. Aber Warnungen besitzen eine Kommunikationsgeschichte.

Wenn frühere Aussagen sehr absolut formuliert wurden und das angekündigte Ereignis nicht eintrat, kann die nächste ernsthafte Warnung schlechter von einer früheren vorsichtigen, interessengeleiteten oder schlicht falschen Prognose unterschieden werden. Gerade ein Big Ball of Mud verstärkt dieses Problem, weil die Warnung selten so konkret lautet wie „Am 17. Oktober wird das System ausfallen“. Häufiger heißt sie: „Die zukünftige Veränderbarkeit wird zunehmend riskant.“ Eine solche Aussage ist erheblich schwieriger zu falsifizieren – aber auch erheblich schwieriger zu beweisen.

Veränderung besitzt reales Risiko

Bis hierhin könnte der Eindruck entstehen, die Organisation müsse lediglich den strukturellen Schaden korrekt erkennen. Aber selbst dann verschwindet der Konflikt nicht. Der Architekt sieht die Risiken des Status quo; der Stakeholder muss zusätzlich die Risiken der Veränderung berücksichtigen. Kunden müssen während eines Umbaus weiterarbeiten, Umsatz und Verträge laufen weiter und regulatorische Verpflichtungen verschwinden nicht. Gleichzeitig kann eine Migration scheitern, ein Refactoring Regressionen verursachen, Features können sich verschieben und Budgets bleiben begrenzt. Ein großer Umbau oder Rewrite kann Monate oder Jahre dauern – ohne eigene Erfolgsgarantie.

Der Status quo besitzt bekannte Probleme. Veränderung besitzt unbekannte Probleme.

Damit schlägt der Architekt nicht vor, Risiko gegen Sicherheit einzutauschen. Er schlägt häufig vor, ein bekanntes Risiko gegen ein anderes Risiko einzutauschen. Diese Perspektive verändert die Bewertung fundamental. Aus technischer Sicht kann ein System offensichtlich schwer veränderbar sein.

Aus wirtschaftlicher Sicht kann es trotzdem rational erscheinen, ein bekanntes geschäftskritisches System weiter zu betreiben, solange die Risiken einer Alternative nicht hinreichend gut beurteilt werden können.

Too big to fail – ohne Finanzkrisenanalogie

Bei besonders großen Bestandssystemen entsteht daraus ein Paradox. Ein solches System kann über Jahrzehnte gewachsen sein, zahlreiche andere Systeme integrieren, zentrale Geschäftsprozesse abbilden, Tausende Kunden bedienen und regulatorische Anforderungen implementieren. Gerade deshalb wäre eine hohe strukturelle Veränderungsfähigkeit besonders wertvoll. Gleichzeitig macht genau dieselbe Geschäftskritikalität einen tiefgreifenden Umbau besonders riskant.

Je wichtiger ein System ist, desto wertvoller wäre seine strukturelle Gesundheit – und desto größer können zugleich die unmittelbaren Risiken einer tiefgreifenden Veränderung sein.

„Too big to fail“ beschreibt hier deshalb keine direkte Analogie zur Finanzkrise, sondern lediglich diese organisatorische Zwangslage: Ein System kann so bedeutend werden, dass selbst erkannte strukturelle Probleme nicht automatisch eine tiefgreifende Intervention rechtfertigen.

Erst jetzt kommen psychologische Mechanismen hinzu

Bis zu diesem Punkt braucht es weder Irrationalität noch Ignoranz, Veränderungsfeindlichkeit oder psychologische Verzerrungen. Die Entscheidung ist bereits unter rein wirtschaftlichen Gesichtspunkten schwierig:

• Der heutige Nutzen ist sichtbar.
• Der strukturelle Schaden ist nur indirekt beobachtbar.
• Ein Counterfactual fehlt.
• Die Kosten einer Veränderung sind real.
• Ein Teil ihres Nutzens liegt in vermiedenen zukünftigen Kosten.
• Die Alternative besitzt eigene Risiken.

Erst auf diese bereits unsichere Entscheidungssituation können zusätzliche psychologische und organisationale Mechanismen wirken. Ein klassisches Beispiel ist der Status Quo Bias. Samuelson und Zeckhauser zeigten in unterschiedlichen Entscheidungssituationen eine systematische Präferenz für den bestehenden Zustand. Das bedeutet nicht, dass jede Entscheidung für ein Bestandssystem irrational wäre. Der Befund zeigt lediglich, dass der bestehende Zustand selbst die Entscheidung beeinflussen kann.

Ähnlich ist der Sunk Cost Effect. Arkes und Blumer beschrieben die erhöhte Bereitschaft, ein Vorhaben fortzuführen, nachdem bereits Geld, Zeit oder Aufwand investiert wurde. Auch dieser Effekt macht aus jedem langjährigen Bestandssystem noch keinen irrationalen Fall von Sunk-Cost-Denken. Noch vorsichtiger muss mit Escalation of Commitment umgegangen werden.

Ein altes System weiterzubetreiben ist nicht automatisch Escalation of Commitment. Der Begriff wird dann relevant, wenn trotz negativer Rückmeldungen an einem problematischen Verlauf festgehalten und weiteres Commitment aufgebaut wird.

Berente et al. analysierten dafür 15 veröffentlichte Fälle eskalierter großer Informationssystemprojekte. Ihre qualitative Meta-Analyse zeigt, dass die Persistenz solcher Projekte nicht allein als individuelle Fehlentscheidung verstanden werden kann. Institutionelle Logiken und Rechtfertigungen verändern sich im Verlauf eines Projekts und können die Fortsetzung mittragen. Frühere Arbeiten von Keil et al. untersuchten Eskalationsverhalten speziell bei Softwareprojekten ebenfalls als organisatorisches Entscheidungsproblem. Diese Forschung erklärt nicht, warum ein Big Ball of Mud entsteht oder warum ein bestimmter Stakeholder eine Veränderung ablehnt. Sie zeigt etwas Begrenzteres:

Eine bereits schwer bewertbare Entscheidung kann durch bekannte Entscheidungs- und Organisationsmechanismen zusätzlich in Richtung Fortführung des Bestehenden verschoben werden.

Defensive Routines statt „die wollen das Problem nicht sehen“

Noch schwieriger wird es, wenn ein strukturelles Problem Verantwortungsfragen berührt. Eine strukturelle Diagnose wirft schnell unangenehme Anschlussfragen auf: Warum wurde jahrelang so entwickelt, warum benötigen wir plötzlich mehr Personal, warum dauern Änderungen so lange, warum gehen erfahrene Mitarbeiter und warum wurde das Problem früher nicht gelöst? Solche Fragen sind nicht neutral. Sie können Entscheidungen, Zuständigkeiten und professionelle Identität berühren.

Die Organisationsforschung beschreibt in diesem Zusammenhang Defensive Routines: wiederkehrende Verhaltensweisen, mit denen Individuen oder Organisationen bedrohliche oder konfliktbeladene Situationen verarbeiten.

Eine aktuelle zweijährige ethnografische Action-Research-Studie von Auqui-Caceres und Furlan untersucht, warum solche defensiven Routinen in einem Unternehmen fortbestehen konnten. Die Studie unterscheidet in ihrem untersuchten Kontext unter anderem das Zuschreiben von Problemen an äußere Kräfte, das Ausweichen vor authentischem Dialog und das Vermeiden direkter Konfrontation. Als qualitative Untersuchung eines einzelnen organisationalen Kontexts ist die Arbeit keine diagnostische Checkliste für andere Unternehmen. Sie liefert aber eine nützliche Sprache für Verhaltensmuster, die ansonsten leicht vorschnell als persönliche Schwäche interpretiert würden. Aussagen wie „Die waren eh nicht gut genug“, „Da wurde beim Recruiting Mist gebaut“ oder „Du musst als Teamleiter die Leute besser motivieren“ können im Einzelfall vollkommen korrekt sein. Ein Recruitingprozess kann schlecht sein. Ein Mitarbeiter kann für eine Aufgabe ungeeignet sein. Führung kann unzureichend sein. Problematisch wird erst ein wiederkehrendes Muster, in dem lokale Erklärungen systematisch verhindern, dass eine mögliche gemeinsame strukturelle Ursache überhaupt noch betrachtet wird. Dasselbe gilt für das umgangssprachliche „Probleme weglächeln“.

Eine Organisation kann Belastungen normalisieren, Schwierigkeiten positiv reframen, Konflikte entschärfen oder bestehende Entscheidungen verteidigen. All das kann kurzfristig sogar funktional sein. Organisationen müssen handlungsfähig bleiben und können nicht jede Warnung sofort zum strategischen Krisenfall erklären. Langfristig kann dieselbe Fähigkeit aber dazu beitragen, dass ein problematischer Zustand zur Normalität wird.

Sichtbare Ziele konkurrieren mit unsichtbarer Struktur

Diese Mechanismen treffen auf eine weitere organisatorische Realität. Führungskräfte werden in großen Organisationen häufig an sichtbaren Ergebnissen wie Budget, Terminen, Headcount, Releases, Umsatz, Kundenzielen und operativer Stabilität gemessen. Diese Größen sind nicht oberflächlich. Sie sind zentral für das Funktionieren einer Organisation. Architekturqualität konkurriert mit ihnen jedoch um Aufmerksamkeit, obwohl sie erheblich schwieriger unmittelbar zu beobachten und zu reporten ist.

Architekturqualität konkurriert mit Größen, die kurzfristiger, sichtbarer und leichter reportbar sind.

Auch Technical-Debt-Forschung zeigt, dass Entscheidungen darüber nicht ausschließlich technisch getroffen werden. Eine aktuelle qualitative TOSEM-Arbeit von Bittencourt et al. untersucht anhand von elf erfahrenen Softwarepraktikern, welche Wertkriterien in Entscheidungen über das bewusste Eingehen von Technical Debt einfließen. Die identifizierten Kriterien umfassen nicht nur technische Aspekte, sondern unter anderem Beziehungen zu Kunden und Stakeholdern, Zeit- und Lieferdruck, Wahrnehmungs- und Framingeffekte sowie organisationale und politische Rahmenbedingungen. Aufgrund der kleinen qualitativen Stichprobe ist daraus kein universelles Entscheidungsmodell abzuleiten. Die Arbeit verdeutlicht aber, wie stark solche Entscheidungen in reale organisatorische Zielkonflikte eingebettet sind.

Auch Besker, Martini und Bosch untersuchten explizit Managementstrategien und Anreizstrukturen rund um Technical Debt. Schon die Existenz dieser Forschung zeigt, dass Technical Debt nicht sinnvoll als rein technische Eigenschaft des Codes verstanden werden kann. Es ist zugleich eine Frage davon, welche Konsequenzen sichtbar werden, wer Entscheidungen treffen kann und welche Ziele eine Organisation priorisiert. Das erklärt, warum „Architektur ist wichtig“ organisatorisch kein hinreichendes Argument ist. Die konkurrierenden Größen sind ebenfalls wichtig.

Wenn der Widerspruch verschwindet

Über längere Zeit kann sich noch ein weiterer Effekt einstellen. Am Anfang sagt ein Entwickler vielleicht: „Wir müssen darüber sprechen.“ Später heißt es nur noch: „Das haben wir schon mehrfach angesprochen.“ Und irgendwann bleibt davon lediglich: „Mach einfach das Ticket.“

Von außen kann dieser Verlauf wie Beruhigung aussehen: Die Diskussionen werden weniger, Architekturprobleme eskalieren seltener in Meetings und der Widerstand gegen neue Anforderungen nimmt ab. Das System scheint organisatorisch stabiler geworden zu sein. Weniger Widerspruch ist jedoch kein eindeutiges Signal.

Weniger Widerspruch bedeutet nicht automatisch weniger Probleme. Manchmal bedeutet er nur weniger Voice.

Die Forschung zu Employee Silence beschäftigt sich mit genau dieser Unterscheidung zwischen vorhandenen Problemen und der Bereitschaft, sie anzusprechen. Hao et al. werteten in einer Meta-Analyse 168 unabhängige Stichproben mit insgesamt mehr als 63.000 Personen aus. Die Ergebnisse zeigen Employee Silence als eigenständiges organisationales Phänomen mit einer Vielzahl von Bedingungen und Folgen; unter anderem spielt psychologische Sicherheit eine relevante Rolle.

Für Softwareentwicklung existiert inzwischen auch spezifischere Forschung. Sánchez-Gordón et al. untersuchten Voice und Silence in Softwareentwicklungsteams anhand von 158 gültigen Befragungen und einem Strukturgleichungsmodell. In ihrer Stichprobe war psychologische Sicherheit stärker mit Silence als mit Voice verbunden; Voice und Silence standen zudem unterschiedlich mit Task Performance und Rückzugsverhalten in Beziehung. Die Arbeit erschien im 2026er Band von Information and Software Technology und wurde bereits 2025 online veröffentlicht. Auch hier handelt es sich um beobachtete Zusammenhänge, nicht um den Nachweis, dass eine bestimmte Architektur unmittelbar Silence verursacht.

Für die Wahrnehmung eines Big Ball of Mud ist dennoch eine einfache Konsequenz wichtig: Ein Stakeholder kann nur auf Informationen reagieren, die ihn erreichen. Wenn technische Warnungen über Jahre ihre Wirkung verlieren und anschließend seltener ausgesprochen werden, kann die Organisation ein trügerisches Stabilitätssignal erhalten.

Und dann gehen Menschen

Auch Fluktuation ist kein eindeutiger Architekturindikator. Menschen wechseln Unternehmen aus vielen Gründen: weil der Markt besser bezahlt, Erwartungen oder Rollen nicht passen, Führung schwierig ist, sich private Prioritäten ändern oder beim Recruiting tatsächlich Fehler gemacht wurden. Deshalb wäre die Aussage

„Der Big Ball of Mud verursacht Kündigungen“

viel zu stark. Eine Häufung aus Unzufriedenheit, geringer Voice, konzentriertem Wissen, schwieriger Einarbeitung und Fluktuation kann jedoch Teil eines größeren sozio-technischen Problems sein.

Besonders problematisch wird Wissensverlust dort, wo die Struktur des Systems selbst wenig Orientierung bietet. Verlässt dann eine Person mit umfangreichem implizitem Systemwissen das Unternehmen, verschwindet nicht nur Entwicklungskapazität. Es kann auch ein Teil des bislang unsichtbaren Navigationssystems verloren gehen. Der Nachfolger sieht dieselbe Codebasis. Er besitzt aber nicht dieselbe Landkarte. Auch dieses Ereignis lässt sich von außen leicht als individuelles Personalproblem interpretieren. Vielleicht ist es das. Vielleicht ist es zusätzlich ein strukturelles.

Es gibt hier keinen offensichtlichen Bösewicht

Damit bleibt eine unbequeme Erkenntnis. Der Entwickler kann seine technische Diagnose ehrlich meinen. Der Architekt kann realen strukturellen Schaden sehen. Der Product Owner kann gleichzeitig eine reale Lieferverpflichtung erfüllen müssen. Ein Bereichsleiter kann ein begrenztes Budget verantworten. Ein Auftraggeber kann vollkommen zu Recht erwarten, dass ein funktionierendes System nicht ohne belastbaren Grund einem tiefgreifenden Umbau unterzogen wird. Management kann unter unvollständiger Information eine nachvollziehbare Entscheidung treffen. Und trotzdem kann das Gesamtsystem in einem schlechten Gleichgewicht verharren. Dafür braucht es weder ignorante Stakeholder noch unfähige Manager, faule Entwickler oder böse Architekten. Es reichen unterschiedliche Informationslagen, unterschiedliche Zeithorizonte, reale wirtschaftliche Risiken und ein System, dessen wichtigste strukturelle Eigenschaften nur indirekt sichtbar sind. Psychologische und organisationale Mechanismen können diese Situation anschließend stabilisieren. Sie erzeugen den Ausgangskonflikt aber nicht.

Das Problem ist nicht offensichtlich

Aus Sicht eines Entwicklers kann ein Big Ball of Mud unmittelbar strukturell erfahrbar sein. Er öffnet ein Ticket und muss zunächst herausfinden, welcher von mehreren Services tatsächlich zuständig ist, entdeckt beim Ändern eines lokalen Zustands weitere Writer, repariert Regressionen in fachlich entfernten Bereichen oder wartet auf den einzigen Kollegen, der einen bestimmten Teil des Systems versteht. Für ihn ist das Architekturproblem unmittelbar real. Der Stakeholder sieht dagegen ein funktionierendes Asset, dessen operative Probleme zunächst getrennt erscheinen: Manche Änderungen dauern lange, Releases sind schwierig, Teams benötigen bestimmte Experten, Kunden müssen gelegentlich deeskaliert werden, neue Mitarbeiter werden langsamer produktiv als erwartet und zusätzlicher Headcount erzeugt weniger zusätzlichen Durchsatz als erhofft. Keine dieser Beobachtungen beweist für sich allein ein Architekturproblem. Für jede existieren plausible alternative Erklärungen.

Und nun soll dieser Stakeholder reales Geld investieren, Features verschieben und reales Projektrisiko eingehen, um eine technische Ursache zu behandeln, deren Schaden nur indirekt sichtbar ist und deren vermiedene zukünftige Kosten sich kaum beweisen lassen.

Widerstand gegen Veränderung ist nicht automatisch ein Mangel an Einsicht. Er kann eine rationale Reaktion auf ein Problem sein, dessen Kosten sichtbar, dessen Ursache schwer beobachtbar und dessen Alternative mit erheblicher Unsicherheit verbunden ist.

Status Quo Bias, Escalation of Commitment, Defensive Routines und Employee Silence können diese Situation verstärken. Sie erklären aber nicht allein, warum Veränderung so schwer wird. Der Konflikt beginnt bereits früher: bei der Frage, was eine Organisation überhaupt sehen und messen kann.

Das System läuft. Genau das macht es so schwer zu erklären, warum es trotzdem ein Problem ist.

Forschungsliteratur

• Arkes, H. R. & Blumer, C. (1985): The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1), 124–140. DOI: 10.1016/0749-5978(85)90049-4.
• Auqui-Caceres, M.-V. & Furlan, A. (2026): Why do defensive routines persist in organizational contexts? Results from a two-year ethnographic action research. European Management Review. DOI: 10.1111/emre.70055.
• Berente, N., Salge, C. A. de L., Mallampalli, V. K. P. & Park, K. J. (2022): Rethinking Project Escalation: An Institutional Perspective on the Persistence of Failing Large-Scale Information System Projects. Journal of Management Information Systems, 39(3), 640–672. DOI: 10.1080/07421222.2022.2096545.
• Besker, T., Martini, A. & Bosch, J. (2022): The use of incentives to promote technical debt management. Information and Software Technology, 142, 106740. DOI: 10.1016/j.infsof.2021.106740.
• Bittencourt, J. P., Spínola, R. & Maciel, R. S. P. (2026): Stakeholder Value Criteria for Technical Debt Acquisition Decisions: An Empirical Analysis. ACM Transactions on Software Engineering and Methodology. DOI: 10.1145/3808227.
• Cataldo, M., Wagstrom, P. A., Herbsleb, J. D. & Carley, K. M. (2006): Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools. Proceedings of CSCW 2006. DOI: 10.1145/1180875.1180929.
• Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B. & Butler, J. (2021): The SPACE of Developer Productivity: There’s more to it than you think. ACM Queue, 19(1), 20–48. DOI: 10.1145/3454122.3454124.
• Hao, L., Zhu, H., He, Y., Duan, J., Zhao, T. & Meng, H. (2022): When Is Silence Golden? A Meta-analysis on Antecedents and Outcomes of Employee Silence. Journal of Business and Psychology, 37, 1039–1063. DOI: 10.1007/s10869-021-09788-7.
• Keil, M., Tan, B. C. Y., Wei, K. K., Saarinen, T., Tuunainen, V. & Wassenaar, A. (2000): A Cross-Cultural Study on Escalation of Commitment Behavior in Software Projects. MIS Quarterly, 24(2), 299–325. DOI: 10.2307/3250940.
• Luftman, J., Lyytinen, K. & Ben-Zvi, T. (2017): Enhancing the measurement of information technology (IT) business alignment and its influence on company performance. Journal of Information Technology, 32(1), 26–46. DOI: 10.1057/jit.2015.23.
• MacCormack, A., Baldwin, C. & Rusnak, J. (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.
• Petersen, K. (2011): Measuring and predicting software productivity: A systematic map and review. Information and Software Technology, 53(4), 317–343. DOI: 10.1016/j.infsof.2010.12.001.
• Samuelson, W. & Zeckhauser, R. (1988): Status quo bias in decision making. Journal of Risk and Uncertainty, 1, 7–59. DOI: 10.1007/BF00055564.
• Sánchez-Gordón, M., Colomo-Palacios, R., Sanchez Gordon, A. & Hubin, A. (2026): The role of voice and silence behaviors in software development: a structural equation modeling analysis. Information and Software Technology, 190, 107972. DOI: 10.1016/j.infsof.2025.107972.
• Wiese, M. & Borowa, K. (2023): IT managers’ perspective on Technical Debt Management. Journal of Systems and Software, 202, 111700. DOI: 10.1016/j.jss.2023.111700.