Die Modernisierungsoptionen vergleichen

Die Modernisierungsoptionen vergleichen

0:00 Dieses Modul ist das Scharnier des Seminars. Wir haben Ziele formuliert, die Anwendung inventarisiert und den Weg nach Jakarta EE 11 kennengelernt. Jetzt kommt die Frage, um die es die ganze Zeit ging: Was machen wir eigentlich mit dieser Anwendung? Und die ehrliche Antwort lautet: Das hängt ab — von der Restlaufzeit, vom Änderungsdruck, von der Testabdeckung und vom Team.

0:22 Wir sehen uns die Wege an, die im Bestand bleiben, die Wege, die die Architektur ändern, und ein Entscheidungsmodell, das aus der Analyse eine Wahl macht. Die teuerste Entscheidung ist nämlich die, die vor der Analyse schon feststand.

Die Modernisierungsoptionen vergleichen

0:36 Wir sind am Wendepunkt des ersten Tages. Bis hierhin haben wir Material gesammelt; ab hier wird entschieden. Wichtig ist: Es geht nicht um eine Entscheidung für die ganze Anwendung. Es geht um eine Entscheidung je Anwendungsteil — und genau das macht den Unterschied zwischen einem Migrationsprojekt, das trägt, und einem, das nach sechs Monaten neu diskutiert wird.

Im Bestand bleiben

0:58 Beginnen wir mit den Wegen, die in Präsentationen selten vorkommen, weil sie unspektakulär sind — und die trotzdem in vielen Fällen die wirtschaftlichste Wahl darstellen. Sie haben zudem einen Vorteil, den kein anderer Weg bietet: Man kann sie beginnen, bevor die große Entscheidung überhaupt gefallen ist. Im Bestand bleiben heißt: Die Anwendung behält ihre Architektur, und modernisiert wird alles darum herum. Die Serverversion, die Java-Version, die Art der Auslieferung.

1:24 Der Code ändert sich wenig, der Betrieb erheblich. Das ist ungefähr so, als würden Sie in Ihrer Wohnung die Elektrik erneuern, ohne Wände zu versetzen — es sieht hinterher fast gleich aus, aber es ist sicher, es ist wartbar, und Sie können weiter darin wohnen, während gearbeitet wird. Für Anwendungen mit langer Restlaufzeit und geringem Änderungsdruck ist das oft genau die richtige Antwort.

1:47 Diese drei Stufen bauen aufeinander auf, und jede einzelne hat für sich einen Wert. Aktualisieren bringt Support und Sicherheitspatches zurück. Containerisieren macht die Auslieferung reproduzierbar — dasselbe Artefakt, jedes Mal, ohne Handbuch. Und Externalisieren trennt Anwendung von Umgebung, sodass ein Image durch Test, Abnahme und Produktion wandern kann, statt je Umgebung neu gebaut zu werden.

2:11 Das Schöne daran: Sie können nach jeder Stufe aufhören. Keine dieser Stufen verpflichtet Sie zur nächsten, und keine verbaut Ihnen einen späteren Architekturwechsel. Der zweite Punkt ist derjenige, der in der Projektpolitik zählt: Diese Wege sind in Wochen messbar, nicht in Quartalen. Wenn Sie in Modul eins Ziele mit Zahlen formuliert haben, dann bewegen sich einige dieser Zahlen bereits nach der ersten Stufe — und das finanziert die zweite.

2:37 Der dritte Punkt ist der strategische: Diese Schritte schaffen die Grundlage, auf der eine spätere Zerlegung überhaupt erst möglich wird. Man kann einen Dienst schlecht aus einer Anwendung herauslösen, die niemand reproduzierbar ausliefern kann. Und der vierte: Weil das Artefakt dasselbe bleibt, ist jeder dieser Schritte rücknehmbar.

2:56 Achten Sie auf die Fußzeile, sie ist die eigentliche Aussage dieser Tabelle: Keiner dieser Schritte verlangt eine Entscheidung über die Zielplattform. Das ist strategisch wertvoll, weil Sie damit anfangen können zu arbeiten, bevor die große Frage geklärt ist. In vielen Projekten steht die Modernisierung monatelang still, weil über Quarkus oder Application Server diskutiert wird — während Java 8 weiter ohne Sicherheitsupdates läuft.

3:20 Diese vier Schritte lösen Sie aus dieser Blockade. Sie bringen messbaren Nutzen und halten sich gleichzeitig alle Türen offen. Der erste Punkt ist wichtig für die ehrliche Kommunikation: Containerisierung wird gern als Modernisierung verkauft, ändert aber nichts an der Änderbarkeit der Anwendung. Der Build dauert weiterhin vierzig Minuten, der Code bleibt so verflochten wie zuvor. Was sich ändert, ist die Auslieferung — und das ist wertvoll, aber es ist etwas anderes.

3:47 Wer hier zu viel verspricht, hat beim nächsten Budgetgespräch ein Problem. Und Punkt drei ist die häufigste technische Falle dabei: Zugangsdaten landen im Image, weil sie in der Serverkonfiguration standen und einfach mitgewandert sind.

Umbauen und zerlegen

4:01 Kommen wir zu den Wegen, die die Architektur verändern. Sie reichen von einer behutsamen Modularisierung bis zur vollständigen Neuentwicklung — und sie unterscheiden sich vor allem im Risiko. Dazwischen liegen mehr Abstufungen, als in Projekten üblicherweise diskutiert werden. Und genau in der Mitte liegen die interessanten Optionen.

4:20 Wer die Architektur ändert, hat mehrere Abstufungen zur Wahl, und das ist die gute Nachricht dieses Kapitels. Es gibt nicht nur „so lassen" oder „neu bauen". Dazwischen liegen die Modularisierung im Bestand, die Extraktion einzelner Dienste und die Migration ausgewählter Module auf eine andere Laufzeit. Diese mittleren Wege sind in der Praxis die interessantesten, weil sie das Risiko portionieren. Und die vollständige Neuentwicklung?

4:47 Die bleibt eine Option — aber als letzte, nicht als erste. Warum, sehen wir uns gleich an. Die Logik dieser Tabelle liegt in der letzten Spalte, und die Fußzeile enthält den eigentlichen Rat: Die Risiken addieren sich nicht, sie multiplizieren sich, wenn mehrere Wege gleichzeitig laufen. Genau das passiert in Projekten regelmäßig — man hebt die Java-Version, wechselt den Server, schneidet die Fachlogik neu und führt nebenbei Container ein.

5:13 Jeder Schritt für sich wäre beherrschbar. Zusammen entsteht eine Lage, in der bei einem Fehler niemand mehr sagen kann, welche Änderung ihn verursacht hat. Ein Weg zur Zeit, mit einem stabilen Zustand dazwischen — das ist der ganze Trick. Diese vier Punkte sind seit Jahrzehnten dieselben, und sie sind immer noch wahr. Am wichtigsten ist der zweite: Die Spezifikation des Bestands existiert nur im Code und in den Köpfen.

5:37 Niemand kann sagen, was die Anwendung in jedem Sonderfall tut — und diese Sonderfälle sind es, an denen ein Nachbau scheitert. Der dritte Punkt ist die bittere Pointe: Vieles im Bestand wird gar nicht mehr gebraucht, aber sicherheitshalber nachgebaut, weil niemand entscheiden mag, was wegkann. So entsteht ein Ersatz, der genauso schwer ist wie das Original — nur jünger.

5:59 Der erste Punkt ist der häufigste Konstruktionsfehler bei Zerlegungen: Man schneidet an der technischen Schicht — Oberfläche hier, Fachlogik dort, Datenzugriff wieder woanders. Das Ergebnis sind Dienste, die für jeden Geschäftsvorfall gegenseitig aufeinander warten. Der fachliche Schnitt ist unbequemer zu finden, aber er ist der einzige, der später Unabhängigkeit bringt.

6:20 Und der letzte Punkt begegnet uns in Modul siebzehn wieder: Ein Umbau ohne beschriebenen Rückweg ist kein Umbau, sondern eine Wette. Schreiben Sie den Rückweg auf, bevor Sie den Hinweg gehen.

Entscheiden statt vorfestlegen

6:31 Jetzt bringen wir die Analyse und die Wege zusammen. Und die erste Regel lautet: Die Entscheidung fällt je Anwendungsteil, nicht je Anwendung. Denn eine gewachsene Anwendung ist selten homogen — und eine einzige Antwort für alle Teile ist fast immer entweder zu teuer oder zu billig. Das ist der zentrale Gedanke dieses Moduls. Eine gewachsene Anwendung ist selten homogen: Ein Teil wird täglich geändert, ein anderer seit vier Jahren nicht mehr angefasst.

6:58 Für beide dieselbe Antwort zu wählen, verschenkt Geld — im einen Fall zu wenig, im anderen zu viel. Werkzeuge wie das Migration Toolkit for Applications helfen dabei, weil sie die üblichen Wege als Zielpfade abbilden und eine Anwendung gegen Regeln prüfen: von WebLogic oder WebSphere nach JBoss EAP, nach Open Liberty, auf aktuelle OpenJDK-Versionen, in Richtung Cloud-Readiness oder eben nach Quarkus.

7:22 Diese vier Felder sind ein Entscheidungsmodell im Kleinformat. Zwei Achsen genügen: Wie stabil ist der Teil, und wie oft wird er geändert. Stabil und selten geändert heißt: aktualisieren, containerisieren, fertig — jede weitere Investition zahlt sich nicht aus. Instabil und oft geändert ist der Bereich, in dem sich eine Migration wirklich lohnt, denn dort zahlt jede Verbesserung der Änderbarkeit täglich zurück.

7:48 Und instabil bei seltener Änderung? Da lautet die Antwort: erst Tests, dann entscheiden. Denn ohne Tests ist jede Entscheidung eine Wette. Der erste Punkt wird am häufigsten vergessen und ist der wichtigste: die Restlaufzeit. Für eine Anwendung, die in fünf Jahren ohnehin durch eine Standardlösung ersetzt wird, lohnt sich etwas völlig anderes als für eine, die noch zwanzig Jahre trägt.

8:11 Diese Information hat übrigens niemand in der IT — die hat der Fachbereich. Holen Sie sie sich, bevor Sie rechnen. Und der vierte Punkt ist der, den Technikprojekte gern übersehen: Können und Kapazität des Teams, das den Betrieb danach trägt. Eine Architektur, die niemand betreiben kann, ist keine Verbesserung. Der rote Faden hier ist Nachvollziehbarkeit. Vier der fünf Schritte sind Handwerk — Teile übernehmen, Zielpfad benennen, schätzen, aufschreiben.

8:39 Der interessante ist Schritt vier: Markieren Sie die Annahme, die die Entscheidung trägt. Zum Beispiel: „Wir gehen davon aus, dass die Tarifrechnung keine gemeinsame Transaktion mit dem Bestand braucht." Das ist die Stelle, an der die Entscheidung kippt, wenn sich die Annahme als falsch erweist. Wer sie benennt, kann sie prüfen — und muss die Entscheidung nicht komplett neu führen, wenn sich etwas ändert.

9:04 Der erste Punkt ist die Kernbotschaft dieses Moduls, negativ formuliert: Die Zielplattform steht vor der Analyse fest und sucht sich Argumente. Das ist keine böse Absicht, das passiert von selbst — man hat gelesen, gehört, ausprobiert und ist überzeugt. Genau deshalb ist die geschriebene Begründung so wichtig. Und Punkt drei ist der teuerste im Projektalltag: Die Entscheidung wird nicht dokumentiert und ein halbes Jahr später erneut geführt, mit anderen Beteiligten und anderem Ergebnis.

9:32 Eine Seite Text erspart Ihnen zwei Wochen Diskussion.

Übung

9:36 In der Übung treffen Sie diese Entscheidung für Zählwerk. Und Sie schreiben auf, woran sie hängt. Diese eine Zeile — die tragende Annahme — ist es, die Ihre Entscheidung auch in einem halben Jahr noch verteidigbar macht. Sie bewerten für Zählwerk vier Wege — Server aktualisieren, unverändert containerisieren, ein Modul extrahieren, neu entwickeln — anhand von Aufwand, Nutzen und Risiko.

9:58 Das Lernziel ist die Fähigkeit, Wege gegeneinander abzuwägen und die Entscheidung nachvollziehbar zu begründen; nicht, die richtige Antwort zu treffen, denn die hängt von Ihrem Kontext ab. Erfolgreich sind Sie, wenn für jeden Anwendungsteil ein Weg feststeht, jeweils mit Begründung und mit der Annahme, deren Widerlegung die Entscheidung kippen würde.

10:18 Grundlage ist das Inventar aus Modul zwei — ohne es bleibt die Bewertung ein Meinungsbild. Vier Schritte, und der letzte ist der ungewöhnliche: Legen Sie ein Datum fest, an dem die tragende Annahme überprüft wird. Das ist eine kleine Geste mit großer Wirkung, denn sie verwandelt eine Entscheidung in etwas Lebendiges. Annahmen veralten — der Fachbereich ändert Pläne, eine Bibliothek bekommt doch eine Jakarta-Variante, ein Support-Termin verschiebt sich.

10:45 Wenn dafür ein Termin im Kalender steht, merken Sie es. Wenn nicht, arbeitet das Projekt womöglich noch ein Jahr auf einer Annahme weiter, die längst nicht mehr gilt. Das Ergebnis der Übung ist eine Seite — mehr braucht es nicht. Der zweite Punkt ist der, auf den ich Sie besonders hinweisen möchte: Quarkus wird gewählt, ohne dass ein Kriterium darauf zeigt.

11:07 Das Seminar heißt so, wir behandeln es ausführlich, und trotzdem ist es in dieser Übung eine Option unter mehreren — und für manche Teile von Zählwerk mit ziemlicher Sicherheit die falsche. Punkt drei ist der Klassiker aus Projektpräsentationen: Der Nutzen wird beziffert, das Risiko nur benannt. Beziffern Sie beides, wenigstens grob.

11:25 Und Punkt vier fasst das Modul zusammen: Eine Entscheidung ohne Annahme ist nicht überprüfbar — und damit nicht wirklich eine Entscheidung.