Technische Schulden brauchen eine wirtschaftliche Entscheidung

„Wir müssen dringend unsere technischen Schulden abbauen“ klingt wichtig und bleibt häufig folgenlos. Die Geschäftsführung hört eine schwer bezifferbare Modernisierungsforderung. Das IT-Team meint zugleich veraltete Bibliotheken, fragile Schnittstellen, fehlende Tests, manuelle Abläufe und unbeliebte Technologien. Unter einem gemeinsamen Begriff liegen völlig unterschiedliche Probleme.

Technische Schulden werden erst steuerbar, wenn ein konkreter Kompromiss mit seinen Folgen beschrieben wird. Nicht die Abweichung vom technischen Ideal begründet eine Investition, sondern ihre Wirkung auf Kosten, Risiko, Lieferfähigkeit oder Servicequalität.

Die passende Frage lautet deshalb nicht: Wie viel technische Schuld haben wir? Sie lautet: Welche heutige Entscheidung erzeugt welche wiederkehrende Belastung – und wann ist Handeln wirtschaftlicher als weiteres Tragen?

Nicht jede alte Technik ist eine Schuld

Ein System kann alt und dennoch wartbar, sicher genug und für seinen verbleibenden Zweck angemessen sein. Umgekehrt kann eine neue Anwendung bereits technische Schulden enthalten, wenn für einen schnellen Start bewusst auf Tests, Entkopplung oder Dokumentation verzichtet wurde.

Als technische Schuld sollte daher nicht alles bezeichnet werden, was Entwickler gern verbessern würden. Ein belastbarer Schuldenposten braucht:

• eine konkrete technische Ursache oder bewusste Abkürzung,
• eine erkennbare Folge für Änderung, Betrieb, Risiko oder Qualität,
• einen betroffenen Service oder ein Vorhaben,
• wiederkehrenden oder drohenden Aufwand,
• mindestens eine realistische Handlungsoption.

Das Software Engineering Institute beschreibt technische Schulden als Kompromiss, der kurzfristigen Nutzen ermöglichen kann, aber spätere wirtschaftliche Folgen besitzt. Diese Sicht ist hilfreicher als eine moralische Einteilung in „sauberen“ und „schlechten“ Code.

Die Zinsmetapher hilft – aber nur begrenzt

Die bekannte Metapher unterscheidet zwischen dem Aufwand zur Beseitigung einer Schuld und den laufenden „Zinsen“, die durch sie entstehen. Das kann die Diskussion mit nichttechnischen Entscheidern erleichtern:

• zusätzliche Tests bei jeder Änderung,
• manuelle Korrekturen im Betrieb,
• längere Fehleranalyse,
• eingeschränkte Anbieter- oder Personalwahl,
• höhere Ausfallwahrscheinlichkeit,
• verzögerte Produkt- und Prozessänderungen.

Anders als bei einem Kredit sind diese Zinsen jedoch selten exakt bekannt oder regelmäßig. Ein fragiles Modul verursacht möglicherweise lange keine sichtbare Belastung und wird erst bei einer notwendigen Änderung teuer. Deshalb sollte keine Scheingenauigkeit erzeugt werden. Eine belastbare qualitative Einordnung mit belegten Ereignissen ist besser als eine erfundene Eurozahl.

Der Schuldenposten muss eine Entscheidung tragen

Ein einfaches Register ist nur sinnvoll, wenn jeder Eintrag entscheidungsfähig ist. Folgende Felder genügen häufig:

Feld	Leitfrage
Bezeichnung	Welcher konkrete Kompromiss ist gemeint?
Entstehung und Grund	War er bewusst, durch Zeitdruck, fehlendes Wissen oder Veränderung entstanden?
betroffener Service	Welche Leistung, Anwendung oder Roadmap-Initiative wird beeinflusst?
beobachtbare Folge	Welcher Aufwand, welches Risiko oder welche Verzögerung tritt tatsächlich auf?
Exposition	Wie oft und bei welchen Änderungen wird die Folge relevant?
Handlungsoptionen	Akzeptieren, begrenzen, schrittweise verbessern, ersetzen oder stilllegen?
Aufwand und Nebenwirkung	Was kostet die Option und welche neue Risiken erzeugt sie?
Trigger oder Termin	Welches Ereignis erzwingt eine Neubewertung?
Owner	Wer hält die Entscheidung nach und wer darf Budget oder Risiko freigeben?
Nachweis	Woran ist eine Verbesserung oder Erledigung erkennbar?

Ein Backlog-Eintrag wie „Legacy-Code refactoren“ ist zu schwach. Er benennt weder Folge noch betroffene Entscheidung. „Jede Anpassung der Preislogik erfordert manuelle Regression in drei Modulen und verlängert die Freigabe“ macht die Belastung sichtbar und vergleichbar.

Ein Erfahrungsbericht des SEI beschreibt die Arbeit mit einem Register und möglichen Abhilfepfaden. Das ist ein externer Praxisbericht, kein KinOps-Kundenfall. Sein übertragbarer Wert liegt in der expliziten Erfassung: Erst wenn Ursache, Folge und Optionen sichtbar sind, kann technische Schuld gegen andere Arbeit priorisiert werden.

Konstruiertes Beispiel: Die schnelle ERP-Anbindung

Das folgende Beispiel ist konstruiert.

Für eine neue Anwendung wird unter Termindruck eine direkte Leseverbindung zur ERP-Datenbank eingerichtet. Sie ermöglicht einen schnellen Start, obwohl eine entkoppelte Schnittstelle langfristig robuster wäre. Die Entscheidung kann zu diesem Zeitpunkt vernünftig sein.

Später ändern sich Tabellenstrukturen und Berechtigungen. Jede ERP-Aktualisierung verlangt zusätzliche Abstimmung, Tests und gelegentliche Korrekturen. Das Team bezeichnet die Anbindung als technische Schuld und fordert ihren sofortigen Ersatz.

Eine wirtschaftliche Betrachtung prüft genauer: Wie häufig stehen ERP-Änderungen an? Welche Ausfälle oder Verzögerungen traten auf? Wie lange soll die angebundene Anwendung noch bestehen? Kann eine überwachte Exportstruktur die Abhängigkeit günstig begrenzen? Oder ist eine neue API ohnehin Teil der nächsten ERP-Version?

Die Antwort kann vollständiger Ersatz, eine Zwischenmaßnahme oder bewusstes weiteres Tragen sein. Entscheidend ist, dass die direkte Verbindung nicht wegen technischer Unbeliebtheit priorisiert wird, sondern wegen ihrer erwartbaren Wirkung.

Vier legitime Entscheidungen

Für einen Schuldenposten gibt es mehr als „beheben“ oder „ignorieren“.

Akzeptieren

Die Belastung bleibt bestehen, weil ihre Folge gering, selten oder angesichts der Restlebensdauer wirtschaftlich vertretbar ist. Akzeptieren bedeutet nicht vergessen: Owner und Trigger für eine Neubewertung bleiben festgelegt.

Begrenzen

Schutzmaßnahmen reduzieren die Folge, ohne die Ursache vollständig zu beseitigen. Beispiele sind bessere Überwachung, zusätzliche Tests, klare Änderungsverbote, Dokumentation oder eine technische Kapselung.

Schrittweise abbauen

Die Verbesserung wird an ohnehin geplante Änderungen gekoppelt. Dadurch lassen sich Nutzen und Aufwand verteilen. Voraussetzung ist, dass der Zielzustand und die Reihenfolge konsistent bleiben.

Ersetzen oder stilllegen

Wenn die Schulden eng mit einer abzulösenden Plattform verbunden sind, kann eine lokale Sanierung Geld verschwenden. Dann gehört der Posten in die übergeordnete Lifecycle- oder Investitionsentscheidung.

Diese Optionen verhindern die verbreitete Annahme, jede Schuld müsse vollständig „zurückgezahlt“ werden. Das SEI betont in seiner Arbeit zu Automation, Design und Architektur gerade die Abwägung zwischen kurzfristiger Lieferung und langfristiger Änderungsfähigkeit.

Priorität entsteht aus Folge und Exposition

Eine starre Punkteformel wirkt objektiv, kann aber schwache Annahmen verstecken. Für die Priorisierung reichen oft wenige vergleichende Fragen:

1. Welche geschäftliche Leistung ist betroffen?
2. Wie schwer ist die mögliche oder bereits beobachtete Folge?
3. Wie häufig wird die Schwachstelle durch Änderungen oder Betrieb belastet?
4. Wird die Belastung voraussichtlich wachsen?
5. Welche bevorstehende Initiative wird dadurch blockiert oder verteuert?
6. Wie reversibel und aufwendig sind die Handlungsoptionen?
7. Wie lang ist die erwartete Restnutzung?

Ein technisch unschönes, aber selten geändertes internes Werkzeug kann hinter einer unspektakulären Abhängigkeit zurückstehen, die jeden Monat Releases verzögert. Die IT-Roadmap sollte deshalb nicht pauschal einen Topf „technische Schulden“ enthalten. Sie braucht konkrete Entscheidungen mit Wirkung und Abhängigkeit zu geplanten Vorhaben.

Pauschale Modernisierungsbudgets reichen nicht

Manche Teams reservieren einen festen Anteil jeder Iteration für technische Schulden. Das kann kontinuierliche Pflege ermöglichen, ersetzt aber keine Priorisierung. Ohne belegte Posten wird entweder kosmetisch verbessert oder die Zeit bei Projektstress regelmäßig gestrichen.

Tragfähiger ist eine Kombination:

• kleinere, lokale Verbesserungen als Teil der normalen Lieferverantwortung,
• explizite Schuldenposten für team- oder systemübergreifende Folgen,
• Investitionsentscheidungen für größere Ablösungen,
• Review bei Incidents, verzögerten Changes und neuen Roadmap-Vorhaben.

Auch die Kostenbetrachtung muss breiter sein als das Sanierungsangebot. Der Beitrag „IT-Kosten im Mittelstand“ zeigt, warum interne Arbeitszeit und Leistungskennzahlen zur Steuerung gehören. Bei technischen Schulden sind gerade wiederholte Analyse-, Test- und Abstimmungszeiten ein Teil der wirtschaftlichen Wirkung.

Erfolg bedeutet weniger Wirkung, nicht weniger Einträge

Ein sinkender Backlog kann leicht hergestellt werden, indem Einträge geschlossen oder zusammengefasst werden. Aussagekräftiger sind Beobachtungen wie:

• Änderungen am betroffenen Bereich benötigen weniger Sonderaufwand,
• wiederkehrende Incidents oder manuelle Korrekturen gehen zurück,
• eine zuvor blockierte Roadmap-Entscheidung wird möglich,
• die Abhängigkeit von einzelnen Personen oder Anbietern sinkt,
• eine akzeptierte Schuld besitzt weiterhin einen gültigen Owner und Trigger.

Der Business Case nach dem Go-live ist auch hier relevant: Wurde eine größere Bereinigung genehmigt, muss später geprüft werden, ob die behauptete Belastung tatsächlich gesunken ist.

Der erste Schritt braucht kein zentrales Programm. Nehmen Sie die drei technischen Kompromisse, über die Ihr Team am häufigsten klagt. Ergänzen Sie jeweils den betroffenen Service, eine beobachtbare Folge, die Häufigkeit der Belastung, mögliche Optionen und einen Owner. Wenn sich keine Folge benennen lässt, ist der Eintrag noch keine wirtschaftliche Entscheidung – sondern zunächst eine technische Präferenz.