COMPUTERWOCHE
Alternatives Drucklayout:
› reiner Text
Link: http://www.computerwoche.de/a/schuldenfallen-im-sourcecode,2532968

Technical Debt Management

Schuldenfallen im Sourcecode

Datum:19.02.2013
Autor(en):Tobias Wendehost
Software altert, wird gewartet und mit neuen Funktionen gefüttert. Damit wird die Wartung komplexer. Mit Technical Debt Management ließe sich das ändern.

Das durchschnittliche Technical Debt beträgt laut Cast Software 3,61 Dollar pro Codezeile.
Foto: S. Gladwell, Fotolia.com

Technical Debt Management1 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 Sourcecode2 kann allerdings das IT-Budget3 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 Cast4 Software5, 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 Systel6, 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 Capgemini7. "Die Anwenderbedürfnisse haben die Funktionalität aber in den Vordergrund gerückt. Dadurch ist Technical Debt ein Stück kritischer geworden", so Aue.

Technical Debt Management

Der Begriff Technical Debt Management wurde erstmals vom US-amerikanischen Programmierer Ward Cunningham verwendet. Er leitet den Begriff aus der Anhäufung von Fehlern im Sourcecode einer Software ab. Ähnlich wie bei physischen Produkten oder in der Finanzindustrie verursachen Fehler Kosten. Werden sie erst zu einem späteren Zeitpunkt behoben, häufen sich "Schulden" an. Technical Debt Management dient zur Messung der Schulden, die durch Fehler entstehen. Das Ziel ist ein möglichst fehlerfreier Code, um ein hohes Risko für Anwender zu beseitigen.

 

Balance zwischen Technik und Funktion

Gunnar Rühl von DB Systel: „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.“
Foto: DB Systel

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 Dienstleistern8 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 Offshoring9-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

Thomas Fraenzke musste mit seinen Mitarbeitern die IT bei der Allianz im Zuge von Solvency II neu ausrichten. Ein Bestandteil ist dabei Technical Debt Management.
Foto: Allianz

Einige Abteilungen der Allianz10 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 Programm11-Code12 verbunden sind. Schätzt der Anwender13 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.

Alfred Aue von Capgemini, rät, Anwendungen möglichst unkomplex zu gestalten. So erhöhe man die Effizienz bei der Wartung.
Foto: Capgemini

"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 Release14-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.

Links im Artikel:

1 http://www.computerwoche.de/schwerpunkt/Technical%20Debt%20Management
2 http://www.computerwoche.de/schwerpunkt/Sourcecode
3 http://www.computerwoche.de/schwerpunkt/IT-Budget
4 http://www.computerwoche.de/schwerpunkt/Cast
5 http://www.computerwoche.de/schwerpunkt/Software
6 http://www.computerwoche.de/schwerpunkt/DB%20Systel
7 http://www.computerwoche.de/schwerpunkt/Capgemini
8 http://www.computerwoche.de/schwerpunkt/Dienstleister
9 http://www.computerwoche.de/schwerpunkt/Offshoring
10 http://www.computerwoche.de/schwerpunkt/Allianz
11 http://www.computerwoche.de/schwerpunkt/Programm
12 http://www.computerwoche.de/schwerpunkt/Code
13 http://www.computerwoche.de/schwerpunkt/Anwender
14 http://www.computerwoche.de/schwerpunkt/Release

IDG Business Media GmbH
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium in Teilen oder als Ganzes bedarf der schriftlichen Zustimmung der IDG Business Media GmbH. dpa-Texte und Bilder sind urheberrechtlich geschützt und dürfen weder reproduziert noch wiederverwendet oder für gewerbliche Zwecke verwendet werden. Für den Fall, dass auf dieser Webseite unzutreffende Informationen veröffentlicht oder in Programmen oder Datenbanken Fehler enthalten sein sollten, kommt eine Haftung nur bei grober Fahrlässigkeit des Verlages oder seiner Mitarbeiter in Betracht. Die Redaktion übernimmt keine Haftung für unverlangt eingesandte Manuskripte, Fotos und Illustrationen. Für Inhalte externer Seiten, auf die von dieser Webseite aus gelinkt wird, übernimmt die IDG Business Media GmbH keine Verantwortung.