Gründe für die Modernisierung

Gründe für die Modernisierung

0:00 Willkommen. Drei Tage lang beschäftigen wir uns mit Anwendungen, die es eigentlich gut machen: Sie laufen, sie rechnen richtig, sie sind seit Jahren im Einsatz. Und trotzdem stehen sie zur Diskussion. Bevor wir über Jakarta EE 11, Container oder Quarkus sprechen, klären wir deshalb die unbequemere Frage: Warum überhaupt anfassen, was funktioniert?

0:20 Dieses Modul liefert die Antworten, die später jede technische Entscheidung tragen müssen. Wir sehen uns an, woran gewachsene Anwendungen tatsächlich kranken, was Herstellerabhängigkeit im Alltag kostet, und wie aus einem diffusen Unbehagen messbare Ziele werden. Ohne diese Ziele wird jede Modernisierung zu einer Geschmacksfrage.

Gründe für die Modernisierung

0:40 Der erste Tag ist der Tag der Analyse und der Entscheidung. Wir sammeln zunächst die Gründe, nehmen dann die bestehende Anwendung vollständig auf, sehen uns den Weg von Java EE zu Jakarta EE 11 an, vergleichen die Modernisierungsoptionen und schauen uns zwei mögliche Ziele genauer an: den modernen Application Server im Container und Quarkus.

0:59 Am Ende des Tages steht eine begründete Wegwahl — noch keine Zeile migrierten Codes, aber eine Entscheidung, die trägt.

Typische Ausgangslagen gewachsener Anwendungen

1:06 Beginnen wir mit einer ehrlichen Bestandsaufnahme. Denn die Anwendungen, um die es geht, sind selten schlecht geschrieben. Das Problem sitzt fast immer woanders — und genau dort schauen die meisten Modernisierungsprojekte zuletzt hin. Stellen Sie sich ein Haus vor, das solide gebaut ist, aber keinen Stromanschluss mehr bekommt, weil die Leitungen von damals niemand mehr wartet.

1:29 Der Bau ist in Ordnung — die Infrastruktur drumherum nicht. Genauso verhält es sich hier: Der Code einer gewachsenen Enterprise-Java-Anwendung ist meist gar nicht das Problem. Das Problem ist die Kette darum: eine Java-Version, für die es keine Sicherheitsupdates mehr gibt, ein Application Server ohne Support, ein Deployment, das genau eine Person beherrscht.

1:49 Wer das trennt, trennt auch die Lösungen — und merkt, dass sich einiges davon erstaunlich billig reparieren lässt. Diese Kette ist der eigentliche Gegenstand der Modernisierung. Jede Änderung muss durch sie hindurch: bauen, ausrollen, testen, freigeben. Entscheidend ist nicht, wie lang eine einzelne Station dauert, sondern wie lang die Kette insgesamt ist — denn diese Zeit steht zwischen einer Idee und ihrer Wirkung.

2:14 Wenn dieser Weg vierzig Minuten dauert, wird aus jedem Versuch eine Entscheidung. Man probiert dann nicht mehr eben etwas aus. Man plant. Und Software, in der niemand mehr etwas ausprobiert, wird nicht besser, sondern vorsichtiger. Das Interessante an diesen vier Punkten ist: Keiner davon steht in einem Fehlerbericht. Sie tauchen nie als Bug auf, sie kosten trotzdem jeden Tag.

2:37 Fehlende Sicherheitsupdates verschieben Risiko aus der Anwendung heraus in den Betrieb — dort muss es dann mit Firewalls und Netzsegmenten eingefangen werden. Wer nur quartalsweise ausliefert, liefert große Pakete aus, und große Pakete brechen häufiger als kleine. Und das Wissen über den Server steckt in Köpfen statt in Dateien.

2:56 Das ist der teuerste Punkt, denn er wird erst sichtbar, wenn der Kopf im Urlaub oder in Rente ist. Der Wert dieser Aufteilung liegt darin, dass sie ein großes, unlösbares Gefühl in vier kleine, lösbare Aufgaben zerlegt. Und diese vier Spuren hängen weniger zusammen, als es zunächst wirkt. Sie können den Build beschleunigen, ohne den Server anzufassen.

3:17 Sie können das Deployment reproduzierbar machen, ohne eine Zeile Fachlogik zu ändern. Sie können die Java-Version heben, ohne über die Zielarchitektur entschieden zu haben. Genau darin liegt die gute Nachricht dieses Seminars: Modernisierung ist kein Alles-oder-nichts. Es ist eine Reihe unabhängiger Schritte, von denen einige schon nächste Woche Wirkung zeigen.

3:39 Diese vier Fehler haben eine gemeinsame Wurzel: Ungeduld. Alle Beschwerden landen in einem Topf, der Topf wird groß und unlösbar, und am Ende steht der Satz „Wir müssen das neu machen". Dabei ist meist nicht die Anwendung das Problem, sondern der Weg, auf dem sie in Betrieb kommt. Und der zweite große Fehler: Es wird beschrieben statt gemessen.

3:59 Wenn Sie später beweisen wollen, dass die Modernisierung etwas gebracht hat, brauchen Sie den heutigen Wert. Den bekommen Sie nur jetzt — hinterher ist er für immer verloren.

Herstellerabhängigkeit und Betriebsdruck

4:10 Kommen wir zu dem Teil, der einen Serverwechsel wirklich teuer macht. Er steht selten im Anwendungscode — und deshalb taucht er in den ersten Aufwandsschätzungen fast nie auf. Wir sehen uns an, wo diese Bindungen entstehen, woran man sie erkennt — und welcher Druck von außen kommt, ganz unabhängig davon, was die Technik sagt.

4:29 Herstellerabhängigkeit ist ein bisschen wie ein Möbelstück, das exakt in eine bestimmte Nische gebaut wurde. Solange die Wohnung dieselbe bleibt, ist alles gut. Beim Umzug merkt man, dass es nirgendwo sonst hineinpasst. Technisch entsteht sie überall dort, wo eine Anwendung Funktionen nutzt, die nur ein bestimmter Application Server anbietet: eigene Deskriptoren neben den standardisierten, herstellerspezifische Server-APIs, besondere Klassenlader-Regeln oder eine Konfiguration, die ausschließlich über die Administrationskonsole entstanden ist.

5:00 Das Tückische daran: Nichts davon sieht im Code auffällig aus. Es funktioniert ja. Diese vier Punkte sind die üblichen Verdächtigen — und der letzte ist der unangenehmste. Wenn eine Anwendung Ressourcen über feste JNDI-Namen sucht, dann steht die Verbindung zwischen Anwendung und Server als Zeichenkette im Code. Kein Compiler prüft sie, keine Typprüfung schlägt an, keine Suche nach Klassen findet sie. Sie merken es erst zur Laufzeit, meist in der Abnahme, gelegentlich in Produktion.

5:28 Ähnlich verhält es sich mit Klassenlader-Reihenfolgen: Die Anwendung verlässt sich stillschweigend darauf, dass eine bestimmte Bibliotheksversion zuerst gefunden wird. Auf dem neuen Server gilt eine andere Reihenfolge — und plötzlich verhält sich Code anders, den niemand angefasst hat. Diese Gegenüberstellung ist die wichtigste Sortierung dieses Kapitels.

5:49 Alles auf der linken Seite ist portabel: Jakarta REST, CDI, JPA, Transaktionen — für all das gibt es mehrere Implementierungen, und das Wissen darüber steht in einer Spezifikation, die jeder nachlesen kann. Alles auf der rechten Seite bindet Sie an einen Hersteller, und der Wechsel bedeutet dort nicht Konfiguration, sondern Umbau.

6:08 Der Aufwand einer Migration lässt sich deshalb ziemlich gut abschätzen, sobald man weiß, wie viel Anwendung auf welcher Seite steht. Genau das machen wir im nächsten Modul. Bis hierhin waren die Gründe technisch. Diese vier sind es nicht — und deshalb sind sie im Zweifel die stärkeren. Ein Support-Ende ist ein Datum, über das sich nicht verhandeln lässt; es steht fest, ob es jemandem passt oder nicht.

6:32 Lizenzkosten wachsen mit Kernen und Instanzen, nicht mit dem Nutzen, den die Anwendung stiftet. Und Betrieb wie Sicherheit verlangen heute Container, reproduzierbare Stände und nachweisbare Patchstände. Das Bemerkenswerte: Diese Gründe überleben jeden Technologiewechsel. Deshalb tragen sie ein Budget auch dann noch, wenn die technische Begeisterung längst abgeflaut ist.

6:55 Der häufigste dieser Fehler ist der zweite. Die Administrationskonsole zeigt den aktuellen Zustand eines Servers — aber sie erklärt nicht, warum er so ist, seit wann, und wer ihn gesetzt hat. Sie ist eine Momentaufnahme, keine Dokumentation. Wenn dieser Zustand die einzige Quelle der Wahrheit ist, dann ist die Serverkonfiguration nicht versioniert, nicht überprüfbar und nicht reproduzierbar.

7:18 Und der vierte Punkt ist fast tragisch: Der Support-Endtermin ist in aller Regel bekannt. Er steht nur in keinem Plan — bis er in zwei Monaten eintritt und aus einem Projekt eine Notfallaktion wird.

Ziele und Kriterien festlegen

7:30 Jetzt wird es konkret. Wir haben Gründe gesammelt — aus Gründen werden jetzt Ziele. Und ein Ziel unterscheidet sich von einem Wunsch durch genau eine Eigenschaft. Diese Eigenschaft ist auch der Grund, warum das Kapitel so früh kommt: Ohne sie lässt sich am Ende nicht sagen, ob sich der Aufwand gelohnt hat. Ein Ziel, das man nicht messen kann, ist ein Wunsch.

7:51 Das klingt hart, ist aber praktisch gemeint: Ein Modernisierungsziel benennt eine Eigenschaft der Anwendung, die sich nach dem Umbau anders verhält — und die Zahl, an der man das sieht. Wichtig ist die Unterscheidung zweier Zielarten. Technische Ziele beschreiben den Weg: schnellerer Build, weniger Speicher, neuere Laufzeit.

8:10 Geschäftliche Ziele beschreiben den Grund: schneller auf Marktanforderungen reagieren, Betriebskosten senken, Risiko reduzieren. Beide gehören auf denselben Zettel — aber nicht in dieselbe Zeile. Sonst verkauft man am Ende eine Technologie als Nutzen. Achten Sie auf die dritte Spalte, sie ist die eigentliche Arbeit. Ein Kriterium wie „schneller ausliefern" klingt gut, bis jemand fragt: gemessen wovon bis wann?

8:36 Erst der Messpunkt macht daraus eine überprüfbare Aussage — die Zeit von Merge bis Produktion etwa, gemessen über zwanzig Änderungen. Und beschränken Sie sich. Vier Kriterien reichen. Wer zehn misst, verhandelt am Ende über die Messung statt über das Ergebnis, weil sich immer irgendeine Zahl in die gewünschte Richtung deuten lässt.

8:56 Wenige, klare Zahlen sind unbequemer — und genau deshalb nützlicher. Der erste Punkt ist der entscheidende: Geschäftliche Ziele überleben einen Technologiewechsel, technische nicht. Wenn Ihr Ziel „Umstieg auf Quarkus" heißt und sich in Modul 4 herausstellt, dass ein aktualisierter Application Server im Container die bessere Wahl ist, dann ist Ihr Ziel weg — und mit ihm das Budget.

9:18 Heißt das Ziel dagegen „Vorlaufzeit unter einem Tag", dann bleibt es gültig, egal welchen Weg die Analyse empfiehlt. Und der letzte Punkt wird gern überlesen: Ein Abbruchkriterium ist kein Pessimismus. Es ist die Erlaubnis, einen falschen Weg zu verlassen, ohne dass jemand das Gesicht verliert. Der rote Faden dieser fünf Schritte ist eine Übersetzung: von Beschwerden über Ursachen zu Zahlen.

9:41 Beachten Sie Schritt zwei — jede Beschwerde bekommt eine Ursache zugeordnet, keine Lösung. Das ist ungewohnt, weil Entwicklerinnen und Entwickler beim Zuhören sofort Lösungen sehen. Aber wer zu früh in Lösungen denkt, sortiert die Ursachen nach der Lösung, die er ohnehin bevorzugt. Und Schritt vier ist der Schritt, den fast alle überspringen: den heutigen Wert messen.

10:03 Er kostet einen Nachmittag und ist die einzige Grundlage, auf der Sie in einem halben Jahr einen Erfolg belegen können. Der erste Punkt ist der klassische: Als Ziel wird eine Technologie genannt statt einer Eigenschaft. „Wir wollen auf Quarkus" ist kein Ziel, das ist eine Wegbeschreibung ohne Angabe des Reiseziels. Der zweite Punkt ist der teuerste: Ohne Ausgangswert bleibt der Erfolg für immer unbeweisbar — und unbeweisbare Erfolge finanzieren keine zweite Projektphase.

10:32 Und dann der letzte: Der Nutzen wird versprochen, das Risiko aber nirgends festgehalten. Damit ist ein Projekt nicht abgesichert, sondern nur optimistisch. Halten Sie beides fest, im selben Dokument, am selben Tag.

Übung

10:45 Damit sind wir bei der ersten Übung. Sie ist keine Fingerübung — was Sie hier festhalten, begleitet uns durch alle achtzehn Module. Nehmen Sie sich die Zeit, die Ausgangswerte wirklich zu erheben. Geschätzte Zahlen helfen später niemandem — und ein zweites Mal messen können Sie den heutigen Zustand nicht. Unser Begleitprojekt heißt Zählwerk.

11:07 Es verwaltet Stromzähler, Ableseaufträge und Netzanschlüsse eines regionalen Netzbetreibers — technisch ein WAR-Deployment auf einem Application Server, mit Enterprise Beans, JPA, JMS und rollenbasierter Sicherheit. Also genau die Art Anwendung, um die es geht. Ihre Aufgabe ist es, aus den vorliegenden Beschwerden drei messbare Ziele abzuleiten.

11:27 Das Lernziel ist dabei nicht die Zielliste selbst, sondern die Fähigkeit, von einer Beschwerde auf ihre Ursache zurückzuschließen, statt gleich zur Lösung zu springen. Erfolgreich sind Sie, wenn zu jedem Ziel eine Zahl, ein heutiger Messwert und ein Abbruchkriterium stehen. Vier Schritte, und der Sprung passiert zwischen Schritt eins und zwei.

11:48 Sie haben eine Sammlung von Klagen — der Fachbereich wartet zu lange, der Betrieb kann nicht patchen, die Entwicklung traut sich nicht an einen Bereich heran. Jetzt fragen Sie zu jeder: Was ist die technische Ursache? Oft landen mehrere Beschwerden bei derselben Ursache, und das ist das wertvollste Ergebnis dieser Übung.

12:06 Aus den häufigsten Ursachen werden drei Ziele. Und ganz zum Schluss halten Sie fest, wie gemessen wird — nicht nur was, sondern womit und wie oft. Der erste Punkt wird Ihnen in dieser Übung sehr wahrscheinlich passieren: Auf der Zielliste steht plötzlich Quarkus. Das ist verständlich — wir haben es im Titel des Seminars stehen. Aber die Entscheidung fällt erst in Modul vier, und sie könnte anders ausfallen.

12:30 Halten Sie die Liste technologiefrei. Der zweite Fehler ist, dass Beschwerden gesammelt, aber nie einer Ursache zugeordnet werden; dann bleibt die Liste ein Stimmungsbild. Und das fehlende Abbruchkriterium: Es fehlt fast immer, weil ein Scheitern im Plan nicht vorgesehen ist. Genau deshalb sollten Sie es aufschreiben, bevor irgendjemand emotional investiert ist.