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.