Automatisierte Modernisierung – Teil 3

Modernisierungen sind aus technischer Sicht hoch spannend. Aus Sicht der Projekt- oder Produktverantwortlichen sieht das allerdings anders aus. Mit Open Rewrite wird in dieser Blog-Reihe ein Werkzeug für reproduzierbare, testbare und effiziente Modernisierungen vorgestellt. Im ersten Beitrag zu diesem Thema wurden die grundsätzlichen Konzepte von Open Rewrite erläutert. Im zweiten Beitrag wurde auf die technische Umsetzung von Rezepten eingegangen und in diesem Beitrag wird der Einsatz von Open Rewrite im Kontext eines Applikationsportfolios einer Organisation diskutiert. Thematisiert wird der Einsatz von internen Bibliotheken, Applikationsportfolios und der effiziente Einsatz als Service.

Rezepte für die Migration interner Bibliotheken

Standards und Best Practices sind Grundpfeiler einer effizienten und homogenen Softwareentwicklung innerhalb einer Organisation. Oft manifestieren sich diese Standards in zentral verwalteten Abhängigkeiten und die Best Practices in kleinen Softwareartefakten. Diese Basisartefakte werden mit den weiteren Abhängigkeiten und der Businesslogik zu einer Anwendung kombiniert. Dieses Vorgehen bewirkt eine hohe Ähnlichkeit in den Anwendungen, die Entwicklerinnen und Entwickler einen Wechsel zwischen Anwendungen vereinfacht.

Ein großer Nachteil an diesem Vorgehen zeigt sich, wenn die Basisartefakte Sicherheitslücken enthalten oder allgemeine Aktualisierungen benötigen. Durch die Verwendung der Artefakte in vielen oder allen Anwendungen entsteht ein hohes Maß an Kopplung. Diese Kopplung bewirkt, dass eine Änderung an den Basisartefakten eine Änderung an allen Anwendungen notwendig macht. Selbst wenn es sich bei der Dauer der Anpassung nur um einige Minuten handelt, summieren sich zusätzliche Aufwand schnell auf. Hier bietet sich der Einsatz von Open Rewrite an, um diese manuellen Anpassungen zu automatisieren. Die notwendigen Rezepte werden idealerweise durch die Entwicklerinnen und Entwickler bereitgestellt, welche auch die Aktualisierungen der Basisartefakte vorgenommen haben. Denn besonders diese Gruppe kennt die Besonderheiten und Fallstricke ihres eigenen Produktes und kann so effizient Anpassungen erarbeiten.

Einen solchen Ansatz verwenden auch die großen Java Enterprise Frameworks wie Spring Boot und Quarkus. Zu jeder neuen Version der Frameworks erarbeitet ein Teil des Kern-Development Teams der Frameworks zusammen mit der Open Rewrite Community Rezepte für die automatisierte Migration von Softwareprojekten. Können oder dürfen die eigenen Rezepte nicht mit der Open Rewrite Community geteilt werden, ist es auch möglich, mit dem Recipe Starter Template ein dediziertes Maven Artefakt für Migrationen zu erzeugen. Dieses Artefakt kann nun durch die Projektteams verwendet werden, um ihre Verwendung der Basisartefakte zu migrieren.

Durch diese Kombination aus internen Bibliotheken und direkten Open Rewrite Migration Recipes können durch Wiederverwendung entstehende Aufwände abgefangen werden.

Modernisierung eines Applikationsportfolios

In vielen Organisationen wird nicht nur eine Anwendung entwickelt, sondern ein ganzes Portfolio an mehr oder weniger aktuellen Anwendungen gepflegt. Durch die Wiederverwendung von bewährten Mustern und Vorgehensweisen sind viele Anwendungen in diesen Portfolios ähnlich aufgebaut.

Durch den zeitlichen Versatz bei der Entwicklung werden nicht selten unterschiedliche alte Bibliotheken verwendet. Soll dieses Portfolio modernisiert werden, müssen bei vielen Anwendungen die gleichen Schritte gemacht werden. Leider kommen mit jeder neuen Version oder Bibliothek weitere Schritte hinzu. Diese lassen sich oft mit Open Rewrite umsetzen und können so in den folgenden Migrationen wiederverwendet werden.

Hier kann Open Rewrite mit seinem großen Fundus an unterstützten Bibliotheken punkten. Es lohnt sich bei der Planung eines Migrationsschritts im Rezepte Katalog nachzuschlagen.

Um die Migration eines kompletten Applikationsportfolios durchzuführen, bedarf es etwas Analyse und Planung vorab. Zuerst sollte zu jeder Anwendung die Priorität erhoben werden. Diese Priorität ist stark abhängig von der Organisation und ihren kurzfristigen Plänen.

Zusätzlich sollte je Anwendung analysiert werden, wie viele Migrationsschritte notwendig sind und ihre grobe Größenordnung ermittelt werden. Mit den Größen Anzahl Migrationsschritte und Summe Größenordnungen kann nun eine Reihenfolge der einzelnen Applikationsmigrationen erstellt werden, mit der die Aufwandsunterschiede zwischen zwei aufeinanderfolgenden Migrationen minimal werden.

Werden die Migrationen mit Open Rewrite durchgeführt und in der gewählten Reihenfolge abgearbeitet, so kann in jeder Migration die vorherige wieder verwendet werden. Hierdurch werden doppelte Aufwände vermieden und der summierte Aufwand über alle Migrationen sinkt. Zusammen mit den Prioritäten der Organisation können hierdurch sehr effiziente Migrationen von kompletten Applikationsportfolios vorgenommen werden, die auf die Bedürfnisse der Organisation zugeschnitten sind. Dieses Vorgehen kann im Anschluss auch kleinschrittig iterativ verwendet werden, um das homogene modernisierte Portfolio auf dem aktuellen Stand zu halten.

Effizienter die Übersicht behalten

Viele Migrationsbemühungen scheitern oder werden im Nachhinein als zu teuer bewertet. Der Grund hierfür ist vor allem die unterschätzte Komplexität und die manuelle Umsetzung. Die manuelle Umsetzung kann mit Open Rewrite automatisiert werden und auch für die unterschätzte Komplexität liefert Open Rewrite Werkzeuge. Mit Data Tables und Search Recipes können automatisiert Daten erhoben und die Komplexität greifbarer gemacht werden. Search Recipes verwenden dieselbe API wie alle anderen Rezepte. Ihre Ergebnisse sind aber nicht veränderter Source Code, sondern Markierungen an Elementen, sogenannte Search Result Marker. So kann unter anderem die Verwendung einer bestimmten Methode oder eines Interfaces analysiert werden. Diese Funde können in sogenannte Data Tables exportiert werden. Hierbei werden die Funde als Zeilen in einer CSV-Datei gespeichert und können zur weiteren Analyse verwendet werden.

Die im vorherigen Abschnitt beschriebene Ordnung von Anwendungen nach Migrationsaufwand kann durch dieses Vorgehen rein datenbasiert entstehen und gewinnt damit an Aussagekraft.

Ein Lauf von Open Rewrite kann nur Daten aus einem Projekt sammeln. Durch diese Einschränkung müssen die Daten für jede Anwendung des Portfolios einzeln erhoben und manuell aggregiert werden. Die Firma hinter Open Rewrite, Moderne Inc, hat mit dem kostenpflichtigen Tool Moderne CLI ein Werkzeug geschaffen, um aus einer CLI heraus mehrere Repositorien gleichzeitig zu analysieren. Durch den Einsatz dieses Werkzeugs wird die mehrfache Ausführung von Open Rewrite überflüssig. Noch einen Schritt weiter geht das SAAS-Produkt Moderne Plattform, welches nicht nur ein automatisiertes Ausrollen auf ein ganzes Portfolio ermöglicht, sondern durch Aggregierungen auch automatisiertes Reporting ermöglicht. Durch den Einsatz von Moderne Plattform werden Aufwand und Notwendigkeit von Migrationen Stakeholdern verständlich aufbereitet.

Fazit

In dieser Blog-Reihe wurden die Grundlagen von Open Rewrite beschrieben und die Möglichkeiten zur Erweiterung mit eigenen Rezepten beschrieben. In diesem letzten Beitrag wurde die mögliche Anwendung in Organisationen beschrieben.

adesso hat in den letzten Jahren viel Kompetenz im Bereich der Modernisierung von Bestandssystemen gesammelt. Dieses Wissen kombiniert mit dem Werkzeug Open Rewrite machen effiziente Migrationen von Anwendungen und ganzen Anwendungsportfolios möglich. Gerne teilen wir mit Ihnen unser Wissen, unterstützen bei der Umsetzung Ihrer Migrationsprojekte oder geben bei Vorträgen und Konferenzen einen tieferen Einblick.

Ihr möchtet gern mehr über spannende Themen aus der adesso-Welt erfahren? Dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.

Auch interessant

• Automatisierte Modernisierung - Teil 1: Open-Rewrite-Grundlagen
• Automatisierte Modernisierung - Teil 2: Eigene Migrationen entwickeln