IT-Sanierung mit TNG: So wird Software wieder heil

Herr Stock, als Partner einer IT-Beratung werden Sie häufig mit Unternehmenssoftware konfrontiert, die sanierungsbedürftig ist. Was sind aus Ihrer Erfahrung die häufigsten Ursachen dafür, dass eine Anwendung für Ihre Kunden zum Sanierungsfall wird?

Technische Schulden der IT sind hier der häufigste Grund. In der Softwareentwicklung erleben wir häufig einen enorm hohen Zeitdruck auf die Entwicklerteams. Oft muss das Entwicklerteam bestimmte dringende Features schneller abschließen als es mit einer sauberen Implementierung möglich wäre. Dann werden technische Schulden gemacht. 

Wenn die Entwickler nicht die Gelegenheit bekommen, diese Schulden durch Nachbesserung wieder "abzubezahlen", ist schon der erste Schritt in den Sanierungsfall getan. Die technischen Schulden werden immer größer, bis irgendwann der Punkt erreicht ist, an dem neue Features zu teuer werden und nicht mehr implementiert werden können. 

Eine Software wird aber selten über Nacht zum Sanierungsfall, es ist ein schleichender Prozess, den man oft erst bemerkt, wenn es schon zu spät ist.

Was können Sie Unternehmen raten, damit sie diesen Prozess schon früh erkennen?

Wichtige Indikatoren sind steigende Aufwandsschätzungen für neue Features sowie häufige Probleme im Produktivbetrieb. Einen weiteren Hinweis gibt ein Blick auf den Issue-Tracker. Wenn sich die Anzahl der offenen Issues häuft und gerade komplexe Issues oft lange unbearbeitet bleiben oder als "Won't fix" geschlossen werden, ist dies kein gutes Zeichen. Hier sollten die Verantwortlichen eingreifen.

Eine gute, vollständige Dokumentation sollte in einem gesunden Projekt genauso vorhanden sein wie eine Auflistung der technischen Schulden. Das Projektteam muss immer auch genügend Zeit bekommen, um bereits aufgehäufte technische Schulden wieder abzuarbeiten.

Merkt man, dass die Auflistung der technischen Schulden nicht mehr gepflegt wird oder dass die Pflege einer Gesamtdokumentation zugunsten einer Delta-Dokumentation pro Release aufgegeben wurde, sind das schon sehr klare Alarmzeichen.

Gibt es weitere Anhaltspunkte?

Des Weiteren sollten Best Practices bei der Softwareentwicklung eingesetzt werden, wie etwa automatisierte Builds, Tests und Continuous Integration. Ebenso sollte es jedem Entwickler leicht möglich sein, eine eigene Testumgebung aufzusetzen. Das Deployment der Software sollte umfassend und einfach, am besten automatisiert erfolgen.

Aufhorchen sollte man auch, wenn Fachbereiche oder Mitarbeiter der IT sagen "… das gefällt uns auch nicht, das ist aber historisch so gewachsen …" Schließlich gibt es noch den Punkt, an dem man wirklich merkt, dass es so nicht mehr weitergehen kann: Wenn Releases nicht abgenommen werden, weil die Qualität nicht mehr stimmt und wichtige Features nicht implementiert werden konnten.

Welche Wege gibt es, aus einer solchen Situation herauszukommen? Wann kann man die Software noch retten und wann muss ich einen Austausch planen?

Das ist die Frage, die wir von unseren Kunden immer zuerst gestellt bekommen. Eine pauschale Antwort darauf gibt es leider nicht.

Wer seine Software neu schreiben will, muss sich Fragen stellen wie: Kann ich die Anforderungen an das System umfänglich beschreiben? Kann ich längere Zeit auf Feature-Entwicklung verzichten? Möchte ich ein Projekt mit vielen sich ändernden Schnittstellen zu Nachbar-Applikationen haben? Traue ich mir eine gegebenenfalls komplexe Datenmigration zu? Gibt es eine Standardsoftware, zu der ich migrieren kann?

Wenn man die meisten Fragen nicht bejahen kann, bleibt eigentlich nur die Sanierung. Immerhin hat die Alt-Software den Vorteil, dass sie mit den beteiligten Nachbar-Applikationen, deren Schnittstellen und den Daten in der Datenbank trotz aller Datenkorruption umgehen kann.

Wie sieht ein Sanierungsprozess in der Praxis aus? Was sind die wesentlichsten Schritte?

In der Anfangsphase wird der Fokus auf Stabilisierungsmaßnahmen und das Beseitigen von drängenden Softwareproblemen gelegt. Neue Features müssen hinten anstehen und sollten in der ersten Zeit eine große Ausnahme sein. 

Die Automatisierung von Build- und Deploy-Prozessen und der Aufbau einer Continuous Integration läuft parallel zu dieser ersten Phase. Sind diese Grundlagen gelegt, werden automatisierte Softwaretests geschrieben, um Schritt für Schritt die Testabdeckung zu erhöhen. 

Hierbei gehen wir typischerweise nach einem Top-down-Ansatz vor. Zuerst werden Integrationstests geschrieben, die große Teile der Applikation inklusive der simulierten Schnittstellen abprüfen. Parallel dazu wird pro beseitigtem Softwarefehler auch immer ein entsprechender automatisierter Test geliefert, um Regression zu verhindern. Damit bekommt man schnell die Sicherheit, um auch große Sanierungsaufgaben anzugehen.

Woran können IT-Verantwortliche erkennen, ob ein Sanierungsprojekt auf dem richtigen Weg ist?

Kurioserweise ist ein Merkmal einer erfolgreich laufenden Sanierung, dass die Anzahl der gemeldeten Fehler steigt. Dies mag verwundern, aber man muss bedenken, dass gerade wenn die Sanierung sehr akut war, oft ganze Teile der Anwendung nicht funktioniert haben. 

Statt eines Fehlers "Workflow X funktioniert nicht" hat man nun zehn Fehlermeldungen "In Workflow X tritt für Fall Y ein Fehler auf". Das sind Fehler, die auch vorher schon vorhanden waren, aber von anderen Fehlern verdeckt wurden. Mit fortschreitender Sanierung geht die Anzahl der Fehler dann aber schnell wieder zurück.

Und wann würden Sie sagen, ist eine Softwaresanierung beendet?

Je weiter die Sanierung fortschreitet, umso mehr können neue Features eingebaut werden. Wenn die Weiterentwicklung wieder problemlos möglich ist und die Stabilität im Betrieb wiederhergestellt wurde, kann die Software wieder im ausgesetzten, regulären Prozess weiterentwickelt werden. Aber auch dann sollte immer genug Zeit für das proaktive Angehen von technischen Schulden eingeplant werden, sonst wird die Software nur allzu schnell wieder zu einem Sanierungsfall.

Wie können IT-Verantwortliche überhaupt vermeiden, dass eine Softwareanwendung zum Sanierungsfall wird?

Die Entwickler sollten genug Zeit haben, um technische Schulden wieder abzubauen. Zudem ist es sehr vorteilhaft, wenn man das Team in die Abschätzung von Projektplänen involviert. 

Gerade agile Methoden sind hier von großem Wert, da man den Entwicklern die Möglichkeit gibt, selbst festzulegen, wie viel Arbeit sie in einer Iteration schaffen. Wir erleben, dass immer mehr große Unternehmen auf agile Entwicklungsmethoden umstellen. Das ist aus unserer Sicht ein großer Trend in der Branche. 

Ein sehr interessantes Konzept, gerade für große IT-Landschaften, ist auch die Auftrennung von IT-Projekten in Core IT und Fast IT. Mit der Fast IT werden Ideen auf Businesstauglichkeit hin geprüft, bei der Architektur und den Prozessen im Betrieb werden aber keine großen Vorgaben gemacht. So können hier schnell und einfach Ergebnisse bewertet werden. 

Wenn eine Idee nicht funktioniert, dann wird die entsprechende Software auch schnell wieder verworfen. Nur die erfolgreichen Projekte werden in die Core IT überführt, wo dann strengere Prozesse vorgeschrieben sind. So hat man seine technischen Schulden immer im Griff und kann Innovation weiter treiben, ohne die Gesamtstabilität zu gefährden.