Technical Debt

BSH-Vorstand: Riesenthema in reifen Unternehmen

07.12.2012 von Ursula Pelzl
Veraltete Architekturen und Fehler im Code von Applikationen beeinträchtigen Business und Ergebnis. Wer regelmäßig aufräumt, vermeidet große Modernisierungen.
Alexander Lichtenberg, IT-Vorstand der Bausparkasse Schwäbisch Hall (BSH): "Wir müssen weg von singulären Modernisierungsvorhaben und hin zu rollierenden Modernisierungsprozessen."
Foto: Bausparkasse Schwäbisch Hall

Technical Debt Management? Noch immer zucken viele IT-Leiter und CIOs mit den Schultern: Was soll das sein? Mit dem Begriff "Technical Debt" beschreiben immer mehr Experten die Beseitigung aufgelaufener Fehler in der Applikationsentwicklung. Nur wer regelmäßig fehlerhafte Altlasten sucht und bereinigt, kann mit optimaler Verfügbarkeit der IT-Infrastruktur, zuverlässiger Time-to-Market und Stabilität der Applikationen rechnen.

Alexander Lichtenberg, IT-Vorstand der Bausparkasse Schwäbisch Hall (BSH), ist einer der Pioniere in diesem Bereich. Bereits seit den neunziger Jahren hat die Bausparkasse im genossenschaftlichen FinanzVerbund das Technical Debt Management auf dem Radar, erklärt Lichtenberg im Gespräch mit cio.de am Rande eines Expertenforums des auf Softwareanalyse und -messung spezialisierten IT-Anbieters CAST.

"Seit den Neunzigern bearbeiten wir dieses Feld systematisch, wobei die Intensität in den letzten drei bis fünf Jahren deutlich zugenommen hat", sagt Lichtenberg und verweist auf die Historie der mit 6,8 Millionen Sparern kundenstärksten Bausparkasse in Deutschland.

Bereits in den frühen sechziger Jahren hat das Institut auf die Industrialisierung seiner Prozesse durch den intensiven Einsatz von IT gesetzt. "Deshalb hat uns das Thema Technical Debt deutlich früher als andere Unternehmen eingeholt. Die Technologie hat in den vergangenen zehn Jahren große Sprünge gemacht - aber wir konnten nicht auf der grünen Wiese neu anfangen. Also haben wir genau überlegt, in welcher Abfolge wir Modernisierungsvorhaben angehen."

Rollierende Modernisierungsprozesse statt Einzelprojekte

"Wir haben dabei gelernt, dass es ohne eine enge Verzahnung mit der fachlichen Mittelfristplanung nicht geht", beschreibt Lichtenberg seine Erfahrungen. "Wir müssen deshalb weg von singulären Modernisierungsvorhaben und hin zu rollierenden Modernisierungsprozessen."

Aktuell modernisiert Lichtenberg die über Jahrzehnte gewachsenen dispositiven und unternehmenssteuernden Systeme der Bausparkasse. Sie haben einen respektablen Komplexitätsgrad erreicht und sollen nicht nur technisch modernisiert, sondern vor allem auf die neuen regulativen Anforderungen zugeschnitten werden.

"Das ist eine Landschaft, die sich über Jahrzehnte entwickelt hat und in der wir auch über viele Jahre einen recht stabilen Zustand hatten. Es wurde immer wieder etwas angedockt, perfekt zugeschnitten auf die Anforderungen, die sich langsam entwickelt haben. Doch im Ergebnis war dies dann ein sehr komplexes System. Zuletzt waren wir kaum noch in der Lage, auf die regulatorischen Anforderungen zu reagieren, die in den vergangenen fünf Jahren praktisch im Jahresrhythmus auf uns zugerollt sind. Abgeltungssteuer, Verbraucherrichtlinie, jetzt Single European Payment Area (SEPA), Foreign Account Tax Compliance Act (FATCA) - die Anforderungen aus diesen Richtlinien lassen sich mit unseren über Jahrzehnte gewachsenen Systemen nur mit erheblichem Aufwandabbilden."

Bis 2014 soll die Neuaufstellung abgeschlossen sein - wo möglich, mit Standardsoftware. "Es gibt aber auch Komponenten, bei denen wir mit Standardsoftware Wettbewerbsvorteile verspielen würden. Es ist immer eine Frage der Abwägung. Würden wir mit Standardsoftware beispielsweise Prozesseffizienz in signifikantem Maße einbüßen, dann wären wir mit einem Wechsel schlecht beraten."

Neu, räumt Lichtenberg ein, ist das Thema ,Technical Debt Management‘ nicht, doch es habe bisher ein eher stiefmütterliches Dasein gefristet. Der Grund dafür liegt laut Lichtenberg in den Anforderungen, die an die IT gestellt werden: "Primär geht es darum, funktionale Anforderungen abzubilden. Marketing und Vertrieb wünschen sich beispielsweise neue Produkte: In der Umsetzung und der Time-to-Market wird die Leistungsfähigkeit der IT gemessen. Aber was darunter liegt, die nicht-funktionalen Anforderungen, also das Housekeeping, die Bereitstellung einer sauberen Architektur, das wird regelmäßig wegpriorisiert, wenn es mit fachlichen Anforderungen konkurriert."

Den Begriff ,Technical Debt Management‘ findet Lichtenberg gut. Wenn das Wort "Debt" falle, also von Schulden gesprochen werde, "zucken alle zusammen". So erhalten das "Aufräumen" und die heute mögliche Messbarkeit der technischen Schulden mit innovativen Messverfahren nicht nur eine neue Qualität. Die nicht-funktionale Arbeit am IT-System kann so auch einfacher in ihrer Kostendimension, in ihrer technischen Dimension und auch im Hinblick auf die Lösungsansätze beschrieben werden.

Erst aufräumen, dann automatisiert messen

"Bevor Sie in die Effizienzthemen anpacken, müssen Sie erst einmal die Effektivitätsthemen lösen", erklärt Lichtenberg und ergänzt, dass es wenig hilfreich ist, mit Software-Tools auf drei Kommastellen genau zu messen, ob und in welchem (veralteten) Zustand Applikationen sind. "Wenn Druck aus einem Kessel entweicht, dann muss man in jedem Fall handeln." Automatisierte Messungen in Bereichen, in denen größere Aufräum- und Automatisierungsarbeiten anstünden, könne man sich ganz sparen.

"Die Stabilität der IT-Infrastruktur ist eine Voraussetzung, um aus der automatisierten Messung auch wirklich tragfähige Ergebnisse ablesen zu können. Automatisierung setzt einen halbwegs stabilen Zustand voraus, damit diese Tools ihre größte Wirkung entfalten können. Ist dies der Fall, sind automatisierte Messungen eine ausgezeichnete Methode für das Monitoring in sehr kurzen und häufig wiederkehrenden Intervallen. Wenn man auf Knopfdruck die Technical Debts kontinuierlich messen kann, ist das sehr hilfreich."

Automatisierte Messungen der Software-Qualität setzt Lichtenberg bislang noch nicht ein. Doch Technical Debt ist für ihn ein Thema, das dauerhaft auf die To-Do-Liste gehört: "Wenn man eine Standardsoftware einsetzt, ist die regelmäßige Wartung im Vertrag inbegriffen. In den meisten Häusern mit individuell entwickelter und zugeschnittener Software sind jährliche Wartungen dagegen meistens nicht budgetiert. Dort wird unter Wartung nur operative Fehlerbehebung verstanden, nicht aber nicht das regelmäßige Housekeeping."

Regelmäßiges Housekeeping statt Riesen-Modernisierungsprogramm

Wenn sich hingegen die Fach- und Businessseite daran gewöhnten, dass auch für das Housekeeping selbst entwickelter Software 20 Prozent des IT-Budgets bereitstehen muss, ließen sich millionenschwere Modernisierungsprogramme vermeiden, ist Lichtenberg überzeugt. "Das billigste IT-Projekt ist das, das man nicht durchführen muss."

Ein Fazit, das auch der Konferenzteilnehmer und Experte Dr. Bill Curtis, Chef Scientist von CAST und Direktor von CISQ (Konsortium fort IT Software Quality) bestätigt. Die Analyse und Beseitigung vorhandener Technical Debts entlaste Entwicklungsbudgets, die heutzutage zu einem sehr großen Teil in die Wartung bestehender Anwendungen fließen, ohne dass im Kern verborgene Fehler geortet und ausgemerzt werden.

"Am besten ist es, von Anfang an mehr Sorgfalt in der Softwareentwicklung walten zu lassen und systemkritische Fehler erst gar nicht mitzuschleifen.", ist Curtis überzeugt. Die Mess- und Analyseverfahren von CAST zeigen die neuralgischen Punkte auf und tragen damit von vornherein zu einer sehr hohen Qualität von Applikationen bei.