Softwarewartung hat ein Imageproblem. Sie kostet Geld, liefert kein sichtbares Feature und wird deshalb verschoben, bis sie unausweichlich wird. Mit Software passiert dann, was mit mancher deutschen Autobahnbrücke passiert ist: Sie bröckelt, und die Sanierung kostet ein Vielfaches der laufenden Pflege. Unser Anspruch ist ein anderer. Unsere Anwendungen sollen scheckheftgepflegt altern, ohne Sanierungsstau, mit einer Architektur, die auch nach mehr als zehn Jahren hält.
Softwarewartung automatisiert prüfen
Dass das funktioniert, liegt an einer einfachen Maßnahme: Jede verwendete Komponente bleibt im Blick, und die Kontrolle läuft im Hintergrund automatisiert mit. Vier Prüfungen gehören dazu:
- Regelmäßige Sicherheitsprüfungen mit dem OWASP Dependency Check, der die eingesetzten Bibliotheken mit bekannten Schwachstellen abgleicht.
- Automatische Lizenzprüfungen, damit rechtlich keine Überraschungen entstehen.
- Das Maven Versions Plugin, das anzeigt, für welche Komponenten Updates anstehen.
- Berichte über das Alter jeder Komponente.
Damit ist jederzeit klar, welche Komponente ein Update braucht, wo Risiken liegen und was langfristig wartbar bleibt. Niemand pflegt dafür Listen von Hand.
Was Vernachlässigung kostet, zeigt der Beitrag Technische Schulden. Dort geht es darum, den Preis des Aufschiebens in Euro zu beziffern.
Das Problem bei vielen Projekten
Werkzeuge wie Renovate und Dependabot schlagen Updates vor, schauen aber immer auf ein einzelnes Repository, also ein einzelnes Projekt. Wer viele Kundenanwendungen betreut, hat eine andere Frage: Wie sieht der Stand über alle Projekte zusammen aus? Welches Projekt hängt noch auf der alten Spring-Boot-Version, und wer weiß das noch aus dem Kopf?
Dafür haben wir uns ein eigenes Werkzeug gebaut, die Maven-Matrix. Sie liest alle unsere Maven-Projekte aus und stellt sie grafisch dar. Oben steht je Abhängigkeit ein Balken, aufgeteilt nach Versionen. Je länger ein Abschnitt, desto mehr Projekte laufen auf dieser Version. So sieht man sofort, wie weit eine alte Version noch verbreitet ist. Darunter folgt eine Tabelle mit den Projekten in den Zeilen und den Abhängigkeiten in den Spalten, filterbar und mit internen wie externen Komponenten.
Zwei Fragen, die die Matrix beantwortet
Die Übersicht beantwortet zwei Fragen:
- Bei welchen Projekten steht ein Update an? Gemeint sind Java, Spring Boot, Hibernate, Vaadin und die übrigen Bausteine.
- Welche Projekte hängen an einer bestimmten internen Komponente, und in welcher Version? Also: Wen trifft es, wenn wir sie aktualisieren?
Die zweite Frage stellt sich ständig. Wer viele Kundenanwendungen betreut und eine gemeinsame Bibliothek anfassen will, muss vorher wissen, wer daran hängt. Die Matrix urteilt dabei nicht, sie ist eine reine Bestandsaufnahme. Interpretieren muss ein Mensch, aber er sieht sofort, wo er nachhaken muss.
Budgetierte Wartung statt Bauchgefühl
Daraus entsteht der eigentliche Nutzen für Auftraggeber. Steht bei einem Framework ein großes Update an, planen wir es gemeinsam mit dem Kunden. Welches Update wann kommt, lässt sich damit sauber in die Budgetplanung einbauen: budgetierte Wartung statt Bauchgefühl. Der Kunde erfährt rechtzeitig, was auf ihn zukommt, statt von einer Sicherheitslücke oder einem Support-Ende überrascht zu werden. Wann ein teures Update trotzdem keinen Sinn ergibt, weil die Anwendung ihr Lebensende erreicht, steht im Beitrag Software am Lebensende.
Der Vergleich mit Software-as-a-Service liegt nahe. Dort bestimmt der Anbieter, wann sich etwas ändert und was es kostet, und das wichtigste System gehört nicht dem Unternehmen, das damit arbeitet. Bei eigener Software plant das Unternehmen den Zeitpunkt selbst.
Was Entscheider fragen können
Wer eine Anwendung in Auftrag gibt oder betreibt, sollte seinen Dienstleister oder das eigene Team nach drei Dingen fragen:
- Wie wird der Stand aller Komponenten festgestellt, automatisiert oder bei Gelegenheit?
- Wer weiß, welche Anwendungen auf welcher Version laufen, und wie schnell lässt sich das beantworten?
- Steht Wartung als eigener Posten im Budget oder nur als Restkapazität?
Hinzu kommt ein Punkt, der mit KI an Gewicht gewinnt. Wenn Teams mehr Code schneller liefern, wächst auch der Bestand, der gepflegt werden muss. Das Thema behandelt der Beitrag Wartungskosten durch KI.
Fazit
Gute Softwarewartung entsteht aus Sichtbarkeit und Planung. Automatische Prüfungen zeigen, welche Komponente ein Update braucht, eine Übersicht über alle Projekte zeigt, wen es trifft, und die gemeinsame Budgetplanung macht aus dem Update einen Posten statt einer Überraschung. Wer so wartet, wird seltener von Kosten überrascht.
