Technical Debt
Technische Schulden oder im Neu-Deutsch “Technical Debt” - aber was verbirgt sich eigentlich dahinter und wieso ist es viel wichtiger als es oft gelebt wird?
Unsere Welt wird immer digitaler und die meisten Geschäftsmodelle können ohne Technologie gar nicht mehr funktionieren. Technologie wird immer mehr zum Kern-Treiber des Values für das Business. Um so wichtiger ist es eine stabile und zukunftsgerichtete IT Plattform zur Verfügung zu stellen. Die Modernisierung genau dieser Plattformen verschlingt viel Geld und Energie - und dennoch wird dabei oft der Aspekt der “technischen Schulden” vergessen.
Was sind “technische Schulden” (aka “Technical Debt”)?
Jedes Software-System hat einen gewissen Grad an Komplexität welche benötigt wird um die avisierte(n) Aufgabe(n) adressieren zu können. Die meisten Systeme haben darüber hinaus auch Elemente von unnötiger Komplexität oder auch Altlasten. Elemente welche sich über die Zeit als “suboptimal” herausstellen oder aber nicht wirklich in das Design oder den Rest der Software-Komponenten passen.
Man kann sich Software in diesem Kontext auch als Schublade vorstellen - je unordentlicher oder aber chaotischer die Schublade gefüllt ist um so mehr technische Schulden haben wir. Und um so mühsamer wird es etwas in der Schublade zu finden oder aber neue Dinge in der Schublade strukturiert abzulegen.
Wir sprechen hier von Schuld in der Analogie auch zur “finanziellen Schuld”, d.h. es gibt auch sowas wie ein Schuldenberg als Summe all dieser Schulden. Und wie im Finanzsystem bringen die meisten Schulden gewisse Zinsen und Kosten. Analog ist dies in der Software Entwicklung, d.h. technische Schulden führen zu Mehrkosten - nicht nur im täglichen Betrieb, sondern vor allem auch bei neuen Änderungen. Die Schulden führen dazu, dass Systeme sehr viel aufwendiger und schwieriger zu verändern sind. Es braucht mehr Zeit und die Komplexität erhöht sich schneller. Dies wiederum ist ein Teufelskreis und kann nur durchbrochen werden, indem die technischen Schulden reduziert oder abgebaut werden. Oft ist es sogar ratsam technische Schulden vor (grösseren) Änderungen zu reduzieren um danach schneller voranzukommen und auch mit einem deutlich sauberen (und ohne neue technische Schulden verseuchten) Resultat zu enden.
Die Grafik illustriert wie die technischen Schulden bzw. die unnötig eingebaute Komplexität die Weiterentwicklung von Software immer schwieriger macht bzw. immer mehr Aufwand für das Management der Komplexität und der technischen Schulden aufgewendet werden muss. Es gilt aus meiner Sicht zu bemerken, dass auch bei sehr gutem Design und praktisch ohne technische Schulden der Aufwand für neue Funktionen und das damit verbundene Management der Komplexität über die Zeit zu einer Herausforderung wird. Doch gerade durch gutes Software Design lässt sich das Kosten-Nutzen-Verhältnis substanziell besser halten.
Wie entstehen technische Schulden?
Technische Schulden entstehen in der Entwicklung einer Landschaft auf vielfältig Weise und sind meistens auf einzelne oder mehrere Faktoren aus folgender Liste zurückzuführen:
Schlechte Abstimmung zwischen Business und IT und damit schleichende (suboptimale) Veränderung der IT Komponente(n)
Unter investierte IT, vor allem im Bereich Lifecycle Management und betriebliche Stabilität
Exzessive Komplexität in den Prozessen, Produkten und Lösungen
Legacy Probleme welche schwierigen Umgehungslösungen verlangen oder schlecht kapselbar sind
Inflexible Software-Lösungen oder Komponenten mit sehr hohem Level an spezifischen Entwicklungen und Anpassungen
Keine Software-Entwicklungs-Standards oder Einhaltung dieser
Schlechte Software-Architektur und/oder Umsetzung der Lösungen durch wenig talentierte Software Entwickler
Hoher Lieferdruck mit wenig (oder keinem) Fokus auf Qualität
Dabei ist es wichtig zu verstehen, dass Software-Entwicklung nur in hoher Qualität skaliert. Viel zu oft wird die Annahme getroffen, dass Abkürzungen richtig sind um Zeit zu sparen oder aber diese auch später korrigiert werden können. Leider zeigt sich sehr oft, dass ein Investment in gute Software-Qualität vorab viel weniger Zeit benötigt als erwartet und deutlich viel weniger Zeit und Energie als die Probleme zu einem späteren Zeitpunkt zu korrigieren.
Der Chart von Martin Fowler soll genau diesen Umstand illustrieren. Intuitiv und unter Druck wird dabei erwartet, dass die “design payoff linie” viel höher liegt als dies tatsächlich der Fall ist. Gemäss verschiedenen grossen Software-Developers und -Architekten sollte auf einen Design Tradeoff gänzlich verzichtet werden. Oder anders ausgedrückt zahlt sich eine Form von Design upfront (oder auch agil als “emerging design”) sehr wohl aus, da die spätere Weiterentwicklung der Lösung deutlich vereinfacht wird.
Design Stamina (Source: Martin Fowler)
Wie verbreitet sind technische Schulden?
Leider werden technische Schulden in vielen Bereichen nicht systematisch erfasst oder gemessen. Gerade Entwickler und Architekten haben gemäss Umfrage-Resultaten meist auch nur ein begrenztes Gefühl für die “Menge an Schulden” in ihrem System.
McKinsey hat zu diesem Thema im 2020 ein paar spannende Resultate aus einer Umfrage bei 50 CIOs publiziert:
Die Entwicklung der technischen Schulden: Rund 60% der Befragten sind der Meinung, dass technische Schulden in ihrem Bereich in den letzten 3 Jahren zugenommen haben. Der Grossteil der Befragten sagt auch aus, dass weniger als 20% des IT Budgets für die Reduktion von technischen Schulden eingesetzt wird. Spannend aus meiner Sicht, dass sowohl beim Einsatz von rund 20% des IT Budget die technischen Schulden weiterhin steigen.
Technische Schulden in der Bilanz: Spannend auch, dass die technischen Schulden bis zu 40% des IT Asset Vermögens ausmachen.
Einfluss auf Projekte: Fast 70% der befragten CIOs sind der Meinung, dass über 10% an Projektkosten für die Reduktion technischer Schulden eingesetzt werden.
Entwicklung der technischen Schulden (Quelle: McKinsey Umfrage bei CIO’s, Juli 2020)
Anteil der technischen Schulden am Asset-Wert der IT (Quelle: McKinsey Umfrage bei CIO’s, Juli 2020)
Die Umfrage-Resultate von McKinsey sind äusserst interessant, vor allem da zu dem Thema nicht all zu viele Zahlen publiziert werden.
Im Rahmen dieses Artikels bin ich darüber auf einen spannenden Vergleich gestossen: Dabei wurde die technische Schuld in Code abhängig von der verwendeten Technologie gemessen. Dabei wurden substantielle Unterschiede festgestellt. Abap/SAP, COBOL oder auch Python zeigen dabei eher geringe Tendenz zu technischen Schulden während Java, JavaScript, PHP und JSP die Spitzenpositionen einnehmen. Die Zahlen kann ich in der Form nicht validieren, vermutlich bringen komplexere Technologien sehr wohl auch die Gefahr von mehr technischen Schulden. Wie auch Technologien, welche sehr breit eingesetzt werden bzw. auch teilweise durch weniger erfahrene Entwickler. Aber das sind Vermutungen bzw. Interpretationen meinerseits zu den publizierten Zahlen im genannten Vergleich.
Wie können technische Schulden adressiert werden?
Technische Schulden müssen adressiert werden, um nicht irgendwann in einer Paralyse zu enden. Ohne ein aktives Management der technischen Schulden werden diese stetig zunehmen und Veränderungen in der technischen Landschaft zunehmend aufwendiger und teurer werden lassen.
Transparenz: Um technische Schulden adressieren zu können müssen diese erfasst werden. Nur wenn entsprechende Transparenz herrscht, ist es auch möglich die Entwicklung der technischen Schulden auszuweisen und gezielt darauf einwirken zu können. Die Entwicklerteams und Architekten wissen oft nur teilweise in welchen Bereichen und Lösungen Kompromisse eingegangen werden mussten und entsprechende technische Schulden entstanden sind. Idealerweise werden diese mit den geschätzten Kosten für die Behebung methodisch erfasst. Dabei ist es besonders wertvoll die Schulden klar den entsprechenden Lösungen und Business-Services zuweisen zu können.
Herangehensweise: Es muss definiert werden wie die Governance rund um die technischen Schulden aussieht. In welcher Verantwortung steht die Reduktion der technischen Schuld und wie kann diese Arbeit aufgeplant werden. In meinem aktuellen Umfeld zeigt es sich, dass ein agiles Team alleine die Kraft nicht hat grössere technische Schulden abzubauen. Der Druck neue Features immer rascher zu liefern führt fälschlicherweise dazu, dass Themen wie “Technische Schulden” zu stark vernachlässigt werden. Entsprechender Support auf Senior Management Ebene ist notwendig um die technischen Schulden bewusst anzugehen.
Umsetzung: Big Bang Ansätze sind gerade auch bei technischen Schulden schwierig und oft politisch wenig erfolgreich. Vielmehr sollte clever und kontinuierlich auf dieser Ebene gearbeitet werden. Durch entsprechende KPIs (siehe auch Transparenz) lassen sich auf Senior Management Ebene entsprechende Fortschritte ausweisen. Es sollten dabei Bereich mit häufigen Veränderungen priorisiert werden. Technische Schulden tragen in diesen Bereichen meist stärker auf und lassen sich durch die hohe Kadenz an Änderungen auch schneller angehen. Meist lässt sich nach der Beseitigung der entsprechenden Schulden eine entsprechende Liefer-Beschleunigung (und Freude bei den Entwicklern) positiv bemerkbar.
Taktik: Technische Schulden dürfen nicht “alleine als IT Problem” dargestellt werden. Durch die Verknüpfung zu den Business-Services muss das Business mit ins Boot geholt werden und entsprechende Verbesserungen aktiv unterstützen. Aus Erfahrung macht es viel Sinn entsprechenden Aufwand für Schulungen und Transparenz nicht nur bei den Entwicklern, sondern auch auf das Business und Management zu erweitern. Bereiche mit sehr hohen technischen Schulden müssen allenfalls “abgeschrieben” werden, d.h. ein komplettes Re-Factoring oder Neustart auf grüner Wiese muss unbedingt vor aufwendigem Tech-Debt Beseitigungen validiert werden.
Das Thema der technischen Schulden ist vielschichtig und erhält meist zu wenig Beachtung. Nicht mal per-se aus dem Business, sondern auch in der Entwickler-Community. Entsprechende Aufklärungsarbeit muss geleistet werden, um die Schulden aktiv zu managen und damit eine gesunde technische Basis zu schaffen oder zu erhalten.