Viele Unternehmen schätzen, dass 20%-50% der Systeme nicht mehr gebraucht werden.
Ein Grund sind Probleme beim IT Business Case.

Technical Debt baut sich immer mehr auf, wenn Features verfrüht geliefert werden müssen.
Regulatorische Anforderungen, die umzusetzen waren, sind ein IT-Lackmustest, SOx oder SEPA. Für manche kleine Projekte zur Anpassung, für andere Riesenprojekte.
Schatten-IT ist doppeltes Vorhalten von IT, z.B. in Cloud Services.
Bei zu viel technischer Schuld wird sogar der Business Case für Ersetzung positiv.

Es werden veraltete Technologien und Methoden verwendet, in alte Technologien investiert und abgelöstes weiter verwendet.
Featureentwicklung wird immer aufwändiger. Es gibt hohe Test- und Einarbeitungsaufwände. Es gibt keine automatisierten Softwaretests.
Viele Workarounds und schlechte Stabilität. Ein Indikator: täglicher Neustart.
Fehler werden akzeptiert und nur einfache Fehler werden gelöst. Die eigentlich relevanten bleiben in der Software.

Wie kann man diese Probleme angehen?
Man muss immer argumentieren, warum man sanieren und nicht neu schreiben soll. Gründe sind Datenbankinhalte, Schnittstellen zu Nachbarapplikationen, die unklaren Anforderungen und die weiterlaufende Entwicklung.

Drei Schritte: Stabilisierung, Sanierung, Regelbetrieb

Erstes Ziel ist die Virtualisierung, um die Software auf Entwicklerlaptops zum Laufen zu bekommen. Dann muss der Build und das Deployment automatisiert werden.
TNG verwendet als Werkzeuge Stash, Confluence, Jira, usw.

Umsetzung wird agil durchgeführt. Am Anfang großes Kanban-Team. Für konkrete Stories werden dann Scrum-Teams verwendet. Der Kunde muss überzeugt werden, dass am Anfang eines Sanierungsprojekts nicht viele neue Features realisiert werden können.
Am Anfang ist das Fixen offensichtlicher Fehler eine große Gefahr, weil noch keine automatisierten Tests existieren. Vielleicht ist er später im Code durch einen Workaround aufgefangen.

Die ersten Codeänderungen ohne Tests sollten mit Pair Programming und/oder mit formalisierten Codereviews geprüft werden. Refactorings nur minimalistisch und möglichst mit Werkzeugunterstützung.

Dann initialer Testaufbau von automatisierten Integrationstests. Dies braucht Schnittstellensimulatoren. Damit ist die Testausführung langwierig. Die Definition of Done enthält, dass ein neuer Test pro Fehler geschrieben werden muss.
Behaviour-Driven Development Reverse mit JGiven und Testdatengenerierung mit EntityBuilder. JGiven generiert aus automatisierten Tests menschenlesbare Testspezifikationen.

Wie lerne ich, was die Applikation tut?
Quellen sind Exceptions und Log Files. Evtl. müssen diese noch mit weiteren Informationen angereichert werden. Außerdem gibt es Informationen aus dem Monitoring und Performance-Messungen. Wenn nicht klar ist, wer Interfaces verwendet, dann kann eine Firewall davor eingebaut werden. Wenn sich dann niemand beschwert, dann scheint man alle Aufrufer zu kennen.

Mit kleinen Releases kann man in kleinen Schritten verbessern, aber es werden auch Dinge kaputt gehen.

Dokumentation wird in einem Wiki aufgebaut. UML Sequenzdiagramme mit PlantUML um Szenarien zu beschreiben. Release Notes mit Testberichten sollten automatisiert werden.

Bei hoher Testabdeckung können getrennte Teilsysteme wieder zusammengeführt werden.

Wann ist meine Sanierung erfolgreich?
Ein KPI sind Fehler pro Zeit. Aber es werden am Anfang nicht weniger Fehler pro Zeit, weil viele neue Fälle genutzt und getestet werden. Wenn die Weiterentwicklung wieder möglich ist, kann die Software wieder in den Regelbetrieb überführt werden.

Wie vermeide ich Sanierungsfälle?
Man kann die IT in Fast IT und Core IT aufteilen. Fast IT zur schnellen Validierung von Ideen. Falls es funktioniert, wird es mit allen Qualitätsanforderungen in die Core IT überführt.