Bildquelle: Pexels / Brett Sayles / Netzwerkkabel als Symbol für gewachsene Abhängigkeiten, technische Schulden und Betriebsrisiken / https://www.pexels.com/photo/close-up-photography-of-network-cables-1148820/
Technische Schulden verschwinden nicht, nur weil sie im Backlog der Entwicklung liegen. Im Betrieb werden sie zu Wartezeit, Störungen, Umwegen und schwer erklärbaren Prioritäten.
Technische Schulden entstehen, wenn ein Team eine Lösung bewusst oder unbewusst schneller, einfacher oder enger baut, als langfristig gesund wäre. Das kann sinnvoll sein, wenn ein Zeitdruck real ist und später nachgearbeitet wird. Kritisch wird es, wenn die Nacharbeit nie sichtbar geplant wird. Dann zahlen nicht nur Entwickler den Preis, sondern auch Service Desk, Betrieb, Fachbereiche und Nutzer.
Für ITSM-Generalisten ist der Begriff deshalb praktischer, als er zunächst klingt. Er beschreibt keine abstrakte Codequalität, sondern eine Betriebsfrage: Welche alten Abkürzungen machen einen Service langsamer, fragiler, teurer oder schwerer änderbar? Sobald diese Frage beantwortet wird, gehört technische Schuld nicht nur in ein Entwicklerboard. Sie gehört auf eine Betriebsliste mit Besitzer, Risiko, Nutzerwirkung und nächster Entscheidung.
Die Rechnung kommt im Servicealltag an
Technische Schulden zeigen sich selten als sauber beschrifteter Fehler. Häufig wirken sie wie normale Reibung. Ein Release braucht länger, weil Tests fehlen. Ein Service Desk kann eine Störung nicht sauber erklären, weil Protokolle unvollständig sind. Eine kleine Änderung wird groß, weil Abhängigkeiten nicht dokumentiert sind. Ein Lieferant kann eine Schnittstelle nicht anfassen, weil niemand mehr genau weiß, welche Nebenwirkung droht.
Martin Fowler beschreibt technische Schuld als Bild für den Preis späterer Nacharbeit. Atlassian erklärt ähnlich, dass schnelle Entscheidungen kurzfristig Tempo bringen können, aber später Aufwand, Risiko und Qualitätsprobleme erzeugen. Für ITSM ist daran wichtig: Der Zins dieser Schuld wird im Betrieb sichtbar. Er zeigt sich in längeren Durchlaufzeiten, mehr Rückfragen, schlechterer Wiederherstellung, mehr manueller Kontrolle und höherer Angst vor Änderungen.
Darum reicht es nicht, technische Schulden nur nach Codekomplexität zu sortieren. Ein kleiner Altbestand kann betrieblich gefährlich sein, wenn er einen kritischen Service betrifft. Ein großer Umbau kann dagegen weniger dringend sein, wenn Nutzerwirkung, Störungsrisiko und Änderungshäufigkeit gering sind. ITSM bringt genau diese Einordnung in die Diskussion.
Eine Betriebsliste macht aus Bauchgefühl eine Entscheidung
Eine gute Betriebsliste für technische Schulden muss nicht kompliziert sein. Sie sollte pro Eintrag festhalten, welcher Service betroffen ist, welche Nutzerwirkung droht, welche Störungen oder Verzögerungen bereits sichtbar wurden, wer die Schuld technisch versteht und welche Entscheidung als Nächstes nötig ist. Dazu gehört auch eine Einschätzung, ob die Schuld nur lästig ist oder ein echtes Servicerisiko erzeugt.
Der Unterschied zu einem reinen Entwicklerbacklog liegt in der Sprache. Statt nur Module, Klassen oder Plattformdetails zu nennen, beschreibt die Liste den Betriebseffekt. Kann der Service Desk schneller erklären, was passiert? Wird ein Wiederanlauf sicherer? Sinkt die Zahl manueller Eingriffe? Wird eine Änderung wieder planbar? Solche Fragen verbinden technische Arbeit mit Servicequalität.
Damit entsteht auch ein fairerer Prioritätenprozess. Entwicklung, Betrieb und Management streiten dann nicht nur über unsichtbare Aufräumarbeit. Sie sehen, welche Schuld ein Risiko für Verfügbarkeit, Änderbarkeit, Supportkosten oder Nutzerzufriedenheit ist. Das macht technische Nacharbeit nicht automatisch wichtiger als neue Funktionen. Es macht aber transparent, was passiert, wenn sie wieder vertagt wird.
Nicht jede Schuld muss sofort weg
Der Begriff verleitet schnell zu einer falschen Forderung: Alles Alte muss bereinigt werden. Das ist weder realistisch noch wirtschaftlich. Manche technische Schuld ist bekannt, stabil und akzeptiert. Sie wird beobachtet, aber nicht sofort abgebaut. Andere Schuld ist akut, weil sie jede Änderung bremst, Störungen verlängert oder Sicherheits- und Compliance-Fragen berührt.
Eine Betriebsliste hilft dabei, diese Unterschiede sichtbar zu machen. Sie trennt tolerierte Schuld von gefährlicher Schuld. Toleriert heißt nicht vergessen. Es bedeutet, dass Risiko, Besitzer und Beobachtung klar sind. Gefährlich wird ein Eintrag, sobald er wiederholt Störungen auslöst, kritische Änderungen blockiert, Wissen auf einzelne Personen verengt oder den Service Desk in Erklärungsnot bringt.
Das SRE-Buch von Google betont an mehreren Stellen den Wert von Einfachheit und beherrschbarer Systemkomplexität. Für den ITSM-Alltag lässt sich daraus eine einfache Regel ableiten: Je schwerer ein Service zu verstehen, zu ändern und wiederherzustellen ist, desto stärker muss die technische Schuld in Betriebsentscheidungen auftauchen.
Service Owner brauchen eine klare Sicht
Service Owner können technische Schulden nur steuern, wenn sie in ihrer Sprache erklärt werden. Ein Hinweis wie veraltete Bibliothek oder fehlende Testabdeckung bleibt zu abstrakt, solange die Folge fehlt. Besser ist eine Übersetzung in konkrete Wirkung: Änderungen an diesem Service dauern länger, weil automatische Tests fehlen. Eine Störung lässt sich schlechter eingrenzen, weil zentrale Ereignisse nicht protokolliert werden. Ein Lieferantenwechsel ist riskant, weil Schnittstellenverträge fehlen.
Diese Übersetzung ist eine typische ITSM-Aufgabe. Sie verbindet technische Befunde mit Incident Management, Problem Management, Change Management und Service Portfolio Management. Technische Schulden werden dadurch nicht politisiert, sondern entscheidbar. Der Service Owner sieht, ob eine Nacharbeit die nächste Störung verkürzt, eine Änderung absichert oder eine wiederkehrende Supportlast senkt.
Besonders wichtig ist die Verbindung zu echten Ereignissen. Wenn eine Schuld nur theoretisch wirkt, bleibt sie schwer zu priorisieren. Wenn sie aber mit Tickets, Störungen, Verzögerungen, manuellen Workarounds oder abgebrochenen Änderungen verbunden wird, entsteht eine belastbare Begründung. Dann wird aus Aufräumen eine Serviceverbesserung.
Der Start gelingt mit drei Feldern
Wer neu beginnt, kann die Liste klein halten. Drei Felder reichen für den ersten Nutzen: betroffener Service, sichtbare Betriebsfolge und nächste Entscheidung. Dazu kommen Besitzer und Datum der letzten Prüfung. Schon diese einfache Struktur verhindert, dass technische Schulden als vage Klage in Gesprächen verschwinden.
Danach kann die Liste in bestehende Routinen eingebaut werden. Wiederkehrende Störungen liefern neue Hinweise. Größere Changes prüfen betroffene Schulden vor der Freigabe. Problem Reviews halten fest, ob eine Ursache nur repariert oder dauerhaft abgebaut wurde. Service Reviews zeigen, welche Nacharbeit im nächsten Zeitraum wirklich Priorität bekommen soll.
Technische Schulden sind damit kein Sonderthema für schlechte Tage. Sie werden Teil der normalen Serviceführung. Der Betrieb sieht früher, wo alte Abkürzungen teuer werden. Entwicklung bekommt bessere Begründungen für Nacharbeit. Management versteht, welche Risiken hinter scheinbar unsichtbarer Arbeit stehen. Genau deshalb gehört technische Schuld auf die Betriebsliste und nicht nur in ein entferntes Entwicklerboard.
Quellen und Einordnung: Martin Fowler zum Bild der technischen Schuld, Atlassian zur Wirkung von Technical Debt, IBM zur Rolle von IT Service Management, Google SRE Book zur Bedeutung einfacher und beherrschbarer Systeme. Stand der Quellenprüfung 23.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.
