Ein Begriff aus der Softwareentwicklung hat die Chefetagen erreicht, wurde dabei jedoch missverständlich übernommen. Technical Debt und Architecture Debt klingen verwandt, wirken aber auf unterschiedlichen Ebenen. Technical Debt verlangsamt IT-Delivery, Architecture Debt blockiert Unternehmensstrategie.
Wer beide gleich behandelt, investiert ins Richtige, am falschen Ort. Und genau aus diesem Grund scheitern die meisten Transformationsprogramme selten an Code, sondern an Strategie und Kultur.
Wenn Führungskräfte das Wort «Debt» hören, denken sie an gestresste Entwickler, an veraltete Libraries, schnelle Workarounds und fehlende Tests. Technical Debt ist ein etablierter Begriff, messbar in Zeit und Geld. Er beschreibt kurzfristige Abkürzungen, die langfristig Komplexität und Mehraufwand erzeugen und die Stabilität von IT-Systemen beeinträchtigen.
Doch es existiert eine zweite Form von Debt, die sich dieser Logik entzieht. Sie entsteht nicht im Quellencode und lässt sich auch dort nicht beheben. Sie wirkt auf der Ebene der Unternehmensarchitektur, dort, wo Systeme, Daten und Organisation zusammenkommen.
Man nennt sie Architecture Debt.
Wer hier nicht sauber unterscheidet, diagnostiziert das falsche Problem und investiert entsprechend am falschen Ort.
Zwei Ebenen, zwei Probleme
Technical Debt entsteht auf Systemebene, etwa durch unzureichende Codequalität, veraltete Infrastruktur oder fehlende Abstraktion. Die Konsequenzen sind lokal, etwa langsamere Delivery, steigende Komplexität und Bugs. Die Wirkung ist unmittelbar spürbar und meist klar zuordenbar.
Architecture Debt entsteht auf Unternehmensebene, etwa durch fragmentierte Applikationslandschaften, fehlende Datenintegration oder widersprüchliche Strategien. Die Konsequenzen sind strukturell, etwa blockierte Transformation, Redundanzen und explodierende Betriebskosten. Die Wirkung entfaltet sich verzögert und bleibt lange unsichtbar.
Der Unterschied ist grundlegend.
Wie Architecture Debt entsteht, ein Beispiel aus der Praxis
Zwanzig Gebäudeleitsysteme, entstanden nicht durch Fahrlässigkeit, sondern durch zwanzig lokal rationale Entscheidungen über zehn Jahre. Jedes System wurde für einen konkreten Zweck eingeführt und für einen klar abgegrenzten Kontext optimiert.
Jedes System funktioniert für sich genommen. Jedes verwaltet seine Gebäude, technische Anlagen, Sensoren. Die Daten sind vorhanden, Gebäudeautomatisation funktioniert, Nutzer zufrieden.
Alles funktioniert, solange keine systemübergreifenden Anforderungen gestellt werden.
Doch plötzlich entsteht ein neuer Bedarf, etwa aus dem Bereich von Treibhausgas-Reporting, man wünscht sich eine konsolidierte Sicht auf Energieverbräuche und Betriebsmesswerte aller Gebäude im Eigentum. Fachlich gesehen klare Sache. Technisch aber nicht so einfach: Die verschiedenen Systeme haben unterschiedliche Datenstrukturen, Berechtigungen werden nicht zentral verwaltet, keine APIs. Die Risse in der bestehenden Landschaft werden offenbart, mit grossen, disruptiven Konsequenzen.
Aus einer Reporting-Aufgabe wird plötzlich ein Migrationsprojekt. System 21 entsteht, nicht als Lösung, sondern als Symptom.
Das ist Architecture Debt in Reinform, keine einzelne Fehlentscheidung, sondern die kumulierte Wirkung fehlender Gesamtarchitektur. Im Alltag bleibt diese Form von Debt unsichtbar. Sichtbar wird sie erst, wenn die Unternehmensarchitektur als Ganzes funktionieren soll.
Was gemessen wird, wird gemanagt
Technical Debt ist heute gut messbar und in vielen Organisationen operationalisiert. Tools wie SonarQube quantifizieren Technical Debt direkt, etwa über den Technical Debt Ratio. Ergänzend machen DORA Metriken wie die Change Failure Rate oder Lead Time for Changes die Auswirkungen auf Stabilität und Delivery sichtbar.
Für Architecture Debt existieren ebenfalls messbare Indikatoren, auch wenn sie weniger standardisiert sind. Enterprise Architecture Tools wie LeanIX oder Ardoq erfassen strukturelle Kennzahlen wie Applikationsredundanz, Integrationsdichte oder technologische Fragmentierung.
Der Unterschied liegt oft nicht im Fehlen von Metriken, sondern in ihrer Verankerung im Management.
Technical Debt wird regelmässig gemessen und aktiv gesteuert. Architecture Debt wird seltener quantifiziert und bleibt dadurch oft implizit.
Was systematisch gemessen wird, wird gemanagt. Was nicht gemessen wird, akkumuliert, meist über Jahre hinweg.
Die falsche Diagnose führt zur falschen Investition
Wird Architecture Debt als Technical Debt behandelt, folgt ein bekanntes Muster. Systeme werden modernisiert, Code wird bereinigt und Plattformen erneuert. Diese Massnahmen sind sinnvoll, greifen jedoch zu kurz.
Der erwartete strategische Effekt bleibt aus.
Der Grund liegt nicht im einzelnen System, sondern im Zusammenspiel der Systeme. Solange die Architektur fragmentiert bleibt, bleibt auch die Organisation fragmentiert. Die erhoffte Wirkung geht nicht auf. Lokale Optimierungen können strukturelle Defizite nicht kompensieren.
Architecture Debt muss geführt werden
Architecture Debt entsteht nicht nur durch fehlende Messbarkeit, sondern auch durch fehlende explizite Entscheidungen. Wo keine klare Zielarchitektur existiert, entstehen zwangsläufig inkonsistente Strukturen.
Deshalb muss Architecture Debt sichtbar gemacht und aktiv gesteuert werden, ähnlich wie finanzielle Verbindlichkeiten. Es geht nicht darum, jede Abweichung zu vermeiden, sondern auf die Gaps bewusst einzugehen und transparent zu halten.
Ein Architecture Debt Register hält fest, welche strukturellen Kompromisse eingegangen wurden, warum sie akzeptiert wurden, welche Kosten und Risiken daraus entstehen und wann sie adressiert werden sollen. Es schafft eine Grundlage für informierte Entscheidungen.
Nicht als Dokumentation, sondern als verbindliches Führungsinstrument.
Denn ohne explizite Führung passiert etwas anderes. Organisationen treffen keine Architekturentscheidungen mehr, sie erben sie.
Fazit
Technical Debt ist ein Delivery Problem. Architecture Debt ist ein Führungsproblem.
Wer beides gleich behandelt, optimiert lokal und verliert global.
