Java-EE-Anwendung aus 2008, und keiner versteht sie mehr
Die Ausgangslage
Ein Maschinenbauunternehmen aus Baden-Württemberg, rund 180 Mitarbeitende, betreibt seit 2008 eine Auftragsplanungsanwendung in Java EE 5 auf einem Apache Tomcat 6, dahinter eine Oracle-Datenbank 11g. Die Anwendung steuert die Werkstattplanung, druckt Begleitscheine, rechnet Termine gegen Verfügbarkeiten, und ist über JDBC mit dem ERP verbunden. Sie läuft. Seit 16 Jahren. Aber:
- Der ursprüngliche Entwickler ist 2017 in den Ruhestand gegangen.
- Sein Nachfolger hat das Unternehmen 2021 verlassen.
- Es gibt ein altes SVN-Repository, aber keinen aktuellen Build-Server.
- Die letzten Änderungen wurden direkt auf dem Tomcat in der entpackten WAR-Datei vorgenommen und nicht ins SVN zurückgespielt.
- Eine Architekturdokumentation existiert in Form von drei handgemalten Whiteboardfotos aus 2014.
Die Geschäftsführung hatte zwei Optionen erwogen: ein neues ERP-Modul für rund 250.000 Euro, oder „das alte irgendwie weiterbetreiben". Was fehlte, war ein Mittelweg: das alte System verstehen, sicher betreiben, kontrolliert weiterentwickeln.
Was wir gemacht haben
Phase 1, Reverse Engineering (4 Wochen). Wir haben die laufende WAR-Datei vom Tomcat gezogen und sie mit dem letzten SVN-Stand verglichen. Differenzen: 47 Klassen, zwei zusätzliche JSPs, ein modifiziertes web.xml. Diese Änderungen haben wir manuell rekonstruiert und in ein neues Git-Repository überführt. Der Build wurde mit Maven nachgebaut und auf einem identischen Tomcat-Setup verifiziert: Byte-Vergleich der erzeugten WAR mit der produktiven WAR, bis auf Build-Timestamps identisch.
Phase 2, Architekturbild (3 Wochen). Wir haben die Anwendung in Subsysteme zerlegt: Stammdaten, Planung, Druck, ERP-Schnittstelle, Reporting. Jedes Subsystem wurde mit einer Seite Markdown dokumentiert: Was tut es, welche Klassen sind beteiligt, welche Tabellen werden gelesen/geschrieben, welche externen Aufrufe gibt es. Dazu ein Komponentendiagramm und eine ER-Skizze der relevanten Oracle-Schemata.
Phase 3, Stabilisierung (5 Wochen). Tomcat 6 ist seit 2016 End-of-Life. Wir haben die Anwendung schrittweise auf Tomcat 9 und Java 11 portiert, getrennt vom Produktivsystem, mit identischer Datenbankanbindung gegen eine Kopie. Inkompatibilitäten: zwei JSP-Tags, eine Servlet-API-Änderung, ein veraltetes Oracle-JDBC-Treiber. Drei Wochen Arbeit, sauber getestet, dann Cutover über ein Wochenende.
Phase 4, Wartungsvertrag (laufend). Monatliche Patches für Tomcat und JDK, vierteljährliche Library-Audits, Sentry für Fehler, ein Backup-Konzept mit getestetem Restore. Die Geschäftsführung hat einen festen Ansprechpartner und ein dokumentiertes System.
Das Ergebnis
Aus einer Blackbox wurde eine Anwendung, die man versteht. Die Dokumentation umfasst 38 Seiten, knapp, aber präzise, mit Diagrammen und konkreten Hinweisen für die typischen Fehlerfälle (zum Beispiel: Was tun, wenn nachts die ERP-Schnittstelle stehen bleibt). Tomcat und JDK sind aktuell, die Sicherheitslage ist deutlich besser, und das System läuft messbar stabiler: die Anzahl der nächtlichen Hänger ist von durchschnittlich drei pro Monat auf null gesunken.
Die Geschäftsführung hat das ERP-Neukauf-Projekt zurückgestellt. Mit der jetzt gesicherten Codebasis lässt sich gezielt weiterentwickeln: Schritt für Schritt, ohne Risiko, ohne Big Bang. Die angesammelten Schulden werden über die nächsten zwei Jahre kontrolliert getilgt.