Wie technische Schulden die digitale Souveränität beeinflussen

Die wilden Wochen des Wahlkampfs haben uns im Winter 24/25 lange auf Trab gehalten.  Ein großes Thema im Wettstreit der Parteien war dabei die Schuldenbremse. In dieser Diskussion standen auf der einen Seite die Verfechter der schwarzen Null. Die häufig mit der (armen) schwäbischen Hausfrau im Schlepptau dafür plädierten, das man auf keinen Fall Schulden machen dürfe, denn diese belasteten vor allem die nächsten Generationen. Auf der anderen Seite gab es jedoch ein sehr schönes Argument, welches uns diese Analogie für -auf unserem Tech-Blog ermöglicht.        

Nach Aussagen derjenigen, die sich für die Abschaffung der Schuldenbremse einsetzten, hieß es: Wir haben zwar die Schuldenbremse, aber natürlich machen wir Schulden! Wie soll das denn bitte ohne gehen? Die These war folgende: Die Schulden tauchen zwar nicht finanziell im Haushalt auf, werden aber in die bestehende Infrastruktur ausgelagert. Zum Beispiel durch schlechte Brücken oder die verspätete Bahn. Und genau so kann sich auch ein IT-System verhalten. 

In der Softwareentwicklung verstehen wir technische Schulden, als Aufwände, die in die Zukunft verlagert werden. Dabei ergründen sich diese Aufwände oft aus Designentscheidungen die zwar kurzfristig einen Vorteil, wie zum Beispiel einem schnelleren Release ermöglichen, aber auf längere Sicht Mehraufwände bedeuten – sich der Aufwand also verzinst.  Dabei ist es wichtig zu verstehen, dass diese technischen Schulden eines IT-Systems nicht nur im Code entstehen können´, sondern auch bei Entscheidungen zu den eingesetzten Systemkomponenten, der Softwaretests oder schlechter Dokumentationen führen ebenfalls zu technical Debt.

Die konkreten Gründe für die Entstehung von technischen Schulden können dabei vielseitig sein. Nachfolgend ein paar Beispiele:       

1. Mangelhafte Konventionen: Wenn die Artefakte der Software ohne Struktur benannt werden, haben es Entwickler in der Zukunft schwerer, Bugs zu fixen oder neuen Funktionalitäten zu ergänzen. 
2. Outdated Components: In einem System wird ein Framework als Plattform für die Implementierung verwendet und stellt eine Abstraktion für ein Datenbanksystem bereit. Das Framework wird länger nicht aktualisiert. Bei einem Update der Datenbanksoftware muss nun zuerst das Framework meiner Anwendung aktualisiert werden, bevor sich der Datenbank gewidmet werden kann.
3. Keine passende Gesamtarchitektur: Im Kontext der Gesamtarchitektur gilt es immer wieder abzugleichen, ob die Gesamtstruktur noch der Strategie und Vision meines Systems entspricht. Oftmals werden Services initial als kleines Stück Software entwickelt, die nach und nach um weitere Funktionen ergänzt werden. Wenn sich nun das Prozess- und Nutzendenverhalten ändert, sollte sich die Gesamtarchitektur ebenfalls anpassen. Das ermöglicht dauerhaft die Implementierung neuer Features ohne große Abhängigkeiten.
4. Schlechte Wissensmanagement: IT-Systeme können schnell eine hohe Komplexität annehmen. Wenn ich diese Komplexität nicht durch angemessenes Wissensmanagement reduziere, erhöhen sich meine technischen Schulden rapide. Den Fall, dass erst Kollege oder Kollegin A gefragt werden muss, wenn man an einem neuen Feature arbeiten will, müssten viele von uns schon erlebt haben. Diese Abhängigkeit stellt technische Schulden dar.

Die Folgen von technischen Schulden können sich auf verschiedenen Wegen bemerkbar machen. In der Regel merkt man, dass sich technische Schulden angesammelt haben, wenn die Innovationsfähigkeit im IT-System schwindet.  PRs für die Entwicklung neuer Funktionalitäten dauern immer länger und deren Implementierung wird immer komplexer.  Weiterhin ist die Einarbeitungszeit für Mitarbeitende ein guter Indikator. Durch steigende Komplexität und viele Abhängigkeiten ist es für neue Mitarbeiter schwieriger, sich im System zurecht zu finden. Nach kurzfristigen Erfolgen führt ein schlechter Umgang mit technischen Schulden zu langsamerer Entwicklung eines IT-Systems.

Nach dem wir uns das Problem nun aus verschiedenen Perspektiven angeschaut haben, bleibt eigentliche eine Frage: Was tun? Wie bereits mehrfach ausgeführt wurde, können technische Schulden an verschiedenen Stellen und auf verschiedenen Ebenen auftreten. Dementsprechend gibt es auch eine Anzahl an Gegenmaßnahmen. Und auch diese wirken an verschiedenen Stellen und auf verschiedenen Ebenen.

Die Gesamtstruktur eines Systems bietet auch hier eine gute Grundlage, um effizient technische Schulden zu vermeiden. Wenn ich mein System in sinnvolle Module (oder Microservices) schneide, kann Komplexität reduziert werden. Kurzfristig hilft es Entwicklern dabei, sich im Code zurecht zu finden und die Funktionalität bestimmte Komponenten schneller zu begreifen. Weiterhin hilft eine saubere Modularisierung auch bei der Testbarkeit des Systems. Zum einen lassen mich moderne CI/CD Strukturen vollautomatisch überprüfen, wie gut die Testabdeckung eines Modules ist und, logischerweise, lassen sich diese Tests dann auch auf als Unit, E2E-, oder Regressionstest automatisch ausführen.

Eine weitere Funktion zu Reduzierung technischer Schulden in einer CI/CD-Pipeline ist die statische Codeanalyse. Etablierte Services geben Organisationen die Möglichkeit automatisch zu überprüfen, ob sich ein Entwickler an die Konventionen meiner Entwicklung gehalten hat. Hat er das nicht, wird das Artefakt nicht released.

Neben den Elementen innerhalb des Releases spielt auch die Plattform eine Rolle bei der Entstehung technischer Schulden. Wenn die Organisationen ihr IT-System auf einer Public Cloud entwickelt und die Architektur mit PaaS-Diensten unterstützt, hat es keine Möglichkeit aber auch keine Verantwortungen bestimmte Komponenten zu aktualisieren. Sie verlassen sich darauf, dass ihr Provider die Updates zeitnah durchführt. Die Aufgaben bleiben aber auch nicht im Backlog.

Die bisher aufgezeigten Lösungsansätze stellen verschiedene Möglichkeiten dar, um in spezifischen Situationen technische Schulden zu vermeiden. Wenn wir in der Betrachtung des Systems jedoch etwas rauszoomen, gibt uns der Blick auf den klassischen Softwarentwicklungsprozess noch einen viel größeren Hebel, um technische Schulden zu vermeiden. Bei der Planung meines nächsten Sprints geht es um nämlich um: Priorisierung. Und hier lassen sich auch am effektivsten bestehende technische Schulden vermeiden. Hierbei muss in einem ersten Schritt ein Bewusstsein für technische Schulden bei allen beteiligten Personen geschaffen werden. Dabei geht es darum, insbesondere die langfristigen Folgen transparent zu machen. Im nächsten Schritt geht’s dann darum, einen Kompromiss zu finden. Dabei müssen für die Entwicklungsplanung sowohl Kapazitäten für die Vermeidung technischer Schulden reserviert werden, aber natürlich muss auch geschaut werden, wie neue Funktionalitäten umgesetzt werden können, um weiter attraktiv für die Nutzenden zu bleiben. In einem dritten Schritt muss dieser Kompromiss dann zuverlässig in den Entwicklungsprozess übergeben werden. Sei es agil – oder in einem Wasserfallmodell. 

Digitale Souveränität ist für Arvato Systems die Selbstbestimmtheit im digitalen Raum. Sowohl die technischen Schulden als auch die digitale Souveränität beschäftigen sich mit potenziellen Handlungen in der Zukunft. Dabei entwickeln technische Schulden einen Einfluss auf die Selbstbestimmtheit einer Organisation. Wenn Organisation durch technische Schulden in der Zukunft dazu gezwungen werden, bestimmte Tätigkeiten zu einem bestimmten Zeitpunkt durchzuführen oder die Flexibilität eines Systems gesunken ist, schränkt das in Handlungsalternativen ein. Dementsprechend sorgen hohe technische Schulden für eine geringere Souveränität.