Den Nutzen von Modernisierung von Legacy-Software insbesondere gegenüber dem Management darzustellen, ist keine triviale Angelegenheit. Letztlich kann es zwar generell meist gut erklärt werden, aber gerade Kosten-Nutzen-Aspekte können oft nicht so gut und griffig dargestellt werden, wie es für Themen aus dem jeweiligen Business möglich ist. Spannend ist die Frage, inwieweit sich Modernisierungsmaßnahmen im Nachhinein bewerten lassen und ob die ursprünglich aufgestellten Hypothesen tatsächlich greifen. Dem gehen wir jetzt anhand eines konkreten Beispiels auf die Spur.

Um was geht es?

Die großen technischen Modernisierungen der letzten zwei bis drei Jahre für unser Kernprodukt lifestream als Ganzes waren:

  • Die Umstellung des Buildsystems von Apache Ant auf Gradle.
  • Die Umstellung der Auslieferung auf Docker-Images und der Betrieb als Container im Kubernetes-Cluster.
  • Die Umstellung der Ausführungsumgebung von einem Application Server auf Spring Boot.

Mit der kürzlichen Umstellung von Java 8 auf Java 11 ist nun erkennbar, wie diese ganzen Modernisierungsvorhaben ineinandergreifen.

Java-Updates kompliziert und aufwändig

In der alten Welt war die Umstellung der Java-Version ein aufwändiges Thema. Es musste in dem Fall beispielsweise der Application Server aktualisiert werden und es musste geschaut werden, inwieweit der API-Stand des Servers zu den eingesetzten Fremdbibliotheken passt. Dies wurde erschwert, da wir mit dem Einsatz von Apache Ant noch viel Handarbeit beim Management von Fremdbibliotheken hatten. Auch die Anpassung aller Umgebungen, auf denen lifestream läuft, wurde erforderlich. Es müssen zudem beide Varianten bereitgestellt werden, da eine Version in Produktion ist, die Nächste ist im Test und die Übernächste ist in der Entwicklung. Dies macht es zusätzlich aufwändig, da entsprechend beide Java-Versionen, beide Versionen des Application Server und natürlich auch jeweils dazu passende Konfigurationen auf den virtuellen Maschinen vorhanden sein sollten. Es waren also zahlreiche Weichen nötig, welche die Komplexität erhöhten und natürlich auch Zeit gekostet haben. Hinzu kommt, dass meist auch team- bzw. abteilungsübergreifend zusammengearbeitet werden musste, da beispielsweise die Konfiguration der virtuellen Maschinen dem Betrieb oblag. Dies hat insbesondere den Kommunikations- und Abstimmungsbedarf erhöht.

Vorteile durch neue Technologie

Mit dem Einsatz von moderner, zeitgemäßer Technologie ist ein Java-Update nun deutlich einfacher. Im Prinzip findet nun alles direkt und ausschließlich beim Entwickler statt. Er muss natürlich auch für Spring Boot die passenden Versionen finden und hier gegebenenfalls dazugehörige Updates durchführen. Aber hier ist es durch Spring Boot Starters viel einfacher möglich, kohärent zusammengehörige Abhängigkeiten zu definieren. Gradle hilft zusätzlich, durch die erreichte Build-Performance deutlich schneller Feedback zu bekommen, wenn etwas noch nicht passt. Durch den Einsatz von Spring Boot muss kein Application Server im Betrieb mehr konfiguriert werden. Außerdem wird durch Docker nun auch die Umstellung der Testumgebungen trivial. Java ist Teil des Images, daher ändert sich darüber hinaus nichts an den Umgebungen. Es braucht nichts separat installiert werden. Auch das nun auf allen Stages exakt die gleiche Software in Form eines Images eingesetzt wird, reduziert die Komplexität und macht es einfacher, Probleme nachzuvollziehen.

Was bedeutet das konkret?

Wir können nun in der Rückschau nicht nur erklären, warum es grundsätzlich besser ist, sondern auch nachweisen, wie viel besser es ist. Wir messen unsere Aufwände und bilden Themen als Aufträge ab. So können wir die Aufwände bei der Umstellung auf Java 11 mit früheren Java-Updates vergleichen:

Die Abbildung zeigt eine deutliche Verbesserung. Es lässt sich auch nicht dadurch schmälern, dass gegebenenfalls die Java-Updates nicht 100-prozentig miteinander vergleichbar sind. Dabei handelt es sich nur um den Aufwand in der Entwicklung. Hinzukommen natürlich eingesparte Aufwände beim Betrieb, die sich leider nicht so trennscharf zuordnen lassen. Hier wäre sonst viel Aufwand nötig gewesen, um den erwähnten zeitweisen Parallelbetrieb zu gewährleisten. Zudem gab es so gut wie keine Abstimmungsaufwände oder Abhängigkeiten, die sich wiederum nicht direkt in Zahlen messen lassen würden. Es ließ sich nur subjektiv beurteilen, dass das Update deutlich reibungsloser lief als bislang.

Weitere konkrete Einsparungen ergeben sich durch den Wegfall der Lizenzierung eines Application Servers. Hier sind jährlich fünf bis sechsstellige Beträge eingespart worden. Dem müsste natürlich noch die Investition gegenüber gestellt werden. Zusätzlich müsste projiziert werden, was es langfristig bringt, da auch zukünftige Umstellungen (nicht nur Java Updates) einfacher werden könnten. Aufgrund der Komplexität, wäre das ein Thema für einen weiteren Blog-Beitrag. Wichtig ist mir hier der Ansatz, Modernisierungen für Personen außerhalb der IT überhaupt anhand von Beispielen greifbar zu machen.

Vertrauen schaffen

Es reicht nicht, dem Management oder anderen Stakeholdern nur von den Vorzügen von anstehenden Modernisierungen vorzuschwärmen. Für weiteres Vertrauen ist es wichtig, im Nachhinein kritisch zu schauen, ob sich die Hypothesen bestätigt haben. So werden auch solche technische Themen greifbarer und es entsteht ein gemeinsames Verständnis davon, was Investitionen in Legacy-Systeme wirklich bringen. Oft wird leider IT primär immer noch als Kostenfaktor gesehen. Das möchte ich ändern. Investitionen in Legacy-Systeme sind lohnenswert und haben dann auch positive Auswirkungen auf die Organisation als Ganzes.