Technical Debt Management wird für die Unternehmen erst zu einem Thema, wenn fachliche Fehler bei der Arbeit mit einem Programm auftreten. Die frühzeitige Erkennung von Fehlern im Sourcecode kann allerdings das IT-Budget entlasten und das Risiko eines Ausfalls minimieren. Oftmals verschieben Dienstleister und Softwareanbieter jedoch diesen Prozess und häufen so Schulden (Debt) an. Der Begriff Technical Debt Management umschreibt dieses Phänomen. "Unsere Untersuchungen ergaben, dass das durchschnittliche Technical Debt pro Codezeile 3,61 Dollar beträgt", erläutert Bill Curtis, Chief Scientist von Cast Software, das Ergebnis der Studie "Cast Report on Application Software Health".

Abnutzung der Software

Die Ursachen für Technical Debt sind laut Gunnar Rühl, Geschäftsbereichsleiter Development Center bei DB Systel, schnell ergründet: "Anwendungen altern. Das liegt vornehmlich darin begründet, dass man sie mit neuen Funktionen erweitert oder in andere Systeme integriert." Auch der tägliche Gebrauch kann zu Abnutzung und komplizierter Wartung beitragen. "Häufig wird bei neueren Anwendungen nicht über die Archivierung der gesammelten Daten nachgedacht", so Rühl.

Verwaltung und Beseitigung dieser Fehler wird heute unter dem Begriff Technical Debt Management zusammengefasst. "Das Thema ist eine Fokussierung verschiedener Problemfelder, die man immer schon kannte", erklärt Alfred Aue, Vice President Application Lifecycle Services beim IT-Beratungs- und Dienstleistungsunternehmen Capgemini. "Die Anwenderbedürfnisse haben die Funktionalität aber in den Vordergrund gerückt. Dadurch ist Technical Debt ein Stück kritischer geworden", so Aue.

Balance zwischen Technik und Funktion

Das Ungleichgewicht zwischen Funktionen und technischer Weiterentwicklung soll mit Technical Debt Management in eine Balance gebracht werden. Dabei fängt die Kontrolle bereits in der Softwareentwicklung an. Dennoch gibt es für Rühl bei einigen Unternehmern noch Nachholbedarf. "Als wir vor einigen Jahren unseren Dienstleistern gegenüber angekündigt haben, dass wir ein Werkzeug zur Verminderung von Technical Debt einsetzen werden, war das dortige Management erst einmal entsetzt", schildert er seine Erfahrung.

Der Wirtschaftsinformatiker ist mit seinem Team durch ein anderes Projekt auf das Thema aufmerksam geworden. Vor sechs Jahren fragten sich die Mitarbeiter von DB Systel, wie sie eingekaufte Software überprüfen können. Das Unternehmen entschied sich wie viele in der IT-Branche für ein Offshoring-Modell, bei dem Entwickler etwa aus Indien mit der Überprüfung des Sourcecodes beauftragt wurden. Damit diese nach einheitlichen Kriterien vorgehen, führte das Unternehmen "Functionpoints" für die Vergleichbarkeit ein. Diese bewerten Programmierer und Software nach einem einheitlichen Kriterienkatalog. Die Überprüfung des Codes findet durch ein Werkzeug von Cast statt.

Wie die von Rühl angesprochenen Dienstleister hat auch Capgemini an funktionierenden Programmen Interesse. "Wir haben eine lange Tradition in der Softwareentwicklung und müssen immer auf die Qualität achten. Technical Debt Management hilft uns dabei", erläutert Aue. Früher griffen die Programmierer des Dienstleisters manuell in den Code ein und überprüften ihn anhand empirischer Methoden. "Heute gibt es dafür ausgereifte Werkzeuge, die uns Basisdaten und Analysen automatisch liefern", so der promovierte Informatiker. Diese setzen sie aber vor allem bei der Wartung an, da die Sensibilität für eine saubere Softwarearchitektur bei der Neuentwicklung keine Fehler erlaubt.

Beispiel Allianz

Einige Abteilungen der Allianz greifen ebenfalls auf Methoden von Technical Debt Management zurück. Ein Beispiel ist der Bereich Programm-Management Solvency II/ Risk IT. "Wir beschäftigen uns mit Technical Debt Management im Zusammenhang von Solvency II. Das Projekt machte eine Anpassung unserer IT an die Vorgaben des Gesetzgebers nötig", berichtet Thomas Fraenzke, Programm-Manager bei Allianz Managed Operations & Services. Seit die EU-Richtlinie 2009 in Kraft trat, müssen europäische Versicherungen nachweisen, dass sie genug Eigenkapital haben, um ihre Kunden im Schadensfall bedienen zu können. Vor den Anpassungen strukturierte die Allianz ihre Abteilungen neu. Die IT wurde aus den Fachbereichen herausgetrennt und in einen eigenen Bereich überführt. Für diese Aufgabe war Fraenzke zuständig. Mit der Anpassung an die Solvency II-Richtlinie mussten schließlich die verwendeten Programme und Tools modifiziert werden.

"Unsere Abteilung nutzt für Technical Debt Management das Werkzeug eines Dienstleisters, das wir mit mathematischen Formeln gefüttert haben, um die Güte des fremderstellten Sourcecodes unserer Solvency II Anwendungen zu messen", erläutert Fraenzke. Das Werkzeug wurde zusammen mit dem Anbieter unter sechs Kriterien betrachtet. Wichtigster Punkt war nach Angaben des Allianz-Managers die Sicherheit, da diese für das Versicherungsunternehmen von herausgehobener Wichtigkeit ist. Ein zweites Kriterium war die technische Komplexität. Für die Manager der Allianz lautete das Credo: Je einfacher die Software programmiert ist, desto simpler ist die Wartung. Da sich die Vorgaben der Aufsichtsbehörden Bafin (Bundesanstalt für Finanzdienstleistungsaufsicht) und Eiopa (Europäische Aufsichtsbehörde für das Versicherungswesen und die betriebliche Altersversorgung) ändern können, muss auch die Software unkompliziert erweiterbar sein.

Risiken abschätzen

Neben der technischen Komplexität spielte die Transferierbarkeit eine Rolle, da einzelne Komponenten des Programms auch in anderen Softwarearchitekturen integriert werden sollen. Ansonsten musste der Dienstleister die Dokumentation des Sourcecodes beachten, um Änderungen leichter nachvollziehbar zu machen. Gleichzeitig waren das Design der Softwarearchitektur und die sogenannte Naming Convention Conformity wichtig.

Einheitliche Kriterien sind aber nur ein Teil von Technical Debt Management. Grundsätzlich muss ein Unternehmen erst einmal abschätzen, welche Risiken mit einem fehlerhaften Programm-Code verbunden sind. Schätzt der Anwender das Risiko hoch genug ein muss er die Kosten für die Beseitigung berechnen. Eine Firma sollte analysieren, ob sich die Wartung der Software lohnt oder eine Neuanschaffung ratsam ist.

"Wir machen eine 360 Grad Analyse und beurteilen mit unseren Architekten die Dringlichkeit einer Anpassung", erläutert Aue das Problem. Allerdings erscheint es ihm wenig sinnvoll, bestimmte Kriterien bei der Analyse des Sourcecodes zu priorisieren. Die Anwendungslandschaft sei sehr heterogen und für unterschiedliche Lebenszyklen ausgelegt. Aues Tipp lautet ähnlich wie Fraenzkes Erfahrung, die Komplexität einer Anwendung auf niedrigem Level zu halten: "Auf diese Weise erhöht man die Effizienz der Wartung und kann sich mehr Funktionalität für sein IT-Budget leisten."

Fachliche Anforderung hat Vorrang

Verfolgen Softwareanbieter und Dienstleister eine ruhige Politik bei der Beseitigung von Technical Debt, dann lässt sich der Aufwand gegenüber dem Management besser verkaufen. In den meisten Fällen müssen nur einzelne Komponenten innerhalb eines technischen Release-Zyklus angepasst werden, um die Fehlerquote zu verringern. "Wenn sie ein gutes technisches Release gemacht haben, dann funktioniert die Anwendung hinterher genauso wie vorher. Sie bekommen aber bessere Performance, Robustheit, gesteigerte Security sowie eine leichtere Wartbarkeit", ist Gunnar Rühl überzeugt.

Dennoch sprechen für Unternehmen heute noch zwei Dinge gegen den Aufwand von Technical Debt Management. Zum einen setzen viele Firmen bei der Software fast ausschließlich auf funktionale Aspekte, da diese einen kurzfristigen Mehrwert bringen. Ein Argument, dass Rühl nicht verstehen kann: "Wenn ich mein Auto alle 20.000 Kilometer zur Inspektion bringen muss, ist das jedem klar. Das ich das auch bei Software tun muss, ist dagegen vielen unklar." Ein vermiedener Ausfall des Systems sei für Unternehmen schließlich mehr wert als eine überhastete Reaktion, wenn es knallt.

Ein zweites Argument hängt mit den Geschäftsabläufen in vielen Unternehmen zusammen. Stimmen die fachlichen Ansprüche, dann stoppt die IT-Abteilung nicht kurzfristig ein Programm, nur weil sich in der Software Fehler eingeschlichen haben. Hier lautet häufig das Argument: Fachliche Anforderungen gehen vor, IT-Bedürfnisse sind nachrangig. Treten technischen Fehler auf, werden diese dann erst im nächsten Release behoben.