Die bestehende Anwendung inventarisieren

Die bestehende Anwendung inventarisieren

0:00 Im ersten Modul haben wir Ziele formuliert. Jetzt kommt der Teil, den viele Projekte überspringen — und den sie später bereuen: die vollständige Bestandsaufnahme. Man kann nur migrieren, was man gefunden hat. Alles Übrige taucht trotzdem auf, nur eben später und zu einem schlechteren Zeitpunkt, meistens im Betrieb. In diesem Modul erfassen wir zuerst die Struktur der Deployments und ihre Abhängigkeiten, dann die genutzten Spezifikationen und die Ressourcen, die vom Server erwartet werden, und schließlich verbinden wir das Ganze mit der fachlichen Sicht.

0:31 Am Ende steht ein Dokument, das die Entscheidung in Modul vier und die Pilotauswahl in Modul sieben trägt.

Die bestehende Anwendung inventarisieren

0:37 Wir bleiben im Analyseteil des ersten Tages. Dieses Modul ist der Handwerkskasten dafür: Wo schaut man hin, womit sucht man, und was macht man mit dem Gefundenen. Das Ergebnis ist bewusst kein Bericht für die Ablage, sondern ein Arbeitsdokument, das in jedem weiteren Modul ergänzt wird.

Deployments und Abhängigkeiten erfassen

0:55 Fangen wir bei dem an, was tatsächlich auf dem Server liegt. Nicht bei dem, was im Repository steht — das ist nämlich nicht dasselbe. Zwischen beidem liegen Bibliotheken, die der Server beisteuert, und Konfiguration, die nie eingecheckt wurde. Genau diese Differenz macht eine Migration teuer. Ein Inventar ist wie die Aufstellung vor einem Umzug: Man geht durch jedes Zimmer und schreibt auf, was da ist — ohne schon zu entscheiden, was mitkommt.

1:23 Genau diese Trennung ist wichtig. Das Inventar beschreibt, was tatsächlich ausgeliefert wird: welche Archive auf dem Server liegen, was darin steckt, welche Bibliotheken mitkommen und welche der Server beisteuert. Es ist eine Bestandsaufnahme, keine Bewertung. Die Bewertung folgt in Modul vier, und sie wird deutlich besser, wenn sie sich auf eine vollständige Liste stützen kann statt auf eine Erinnerung.

1:46 Diese Schichtung erklärt, warum eine Anwendung im Archiv oft kleiner aussieht, als sie ist. Das EAR bündelt Module und gemeinsame Bibliotheken, darin liegen Webmodul und EJB-Modul — und darunter, unsichtbar im Archiv, steht der Beitrag des Servers. Genau diese unterste Schicht ist bei einer Migration der kritische Teil, denn sie verschwindet als Erstes.

2:06 Alles, was die Anwendung heute geschenkt bekommt — Logging-Bibliotheken, JSON-Verarbeitung, Transaktionsverwaltung —, muss danach entweder mitgebracht oder ersetzt werden. Wer nur nach oben schaut, unterschätzt die Migration systematisch. Diese vier Aufrufe sind bewusst unspektakulär — sie kosten zehn Minuten und liefern die Grundlage für alles Weitere. Zwei Dinge sind hier entscheidend.

2:30 Erstens: Sehen Sie sich das ausgelieferte Archiv an, nicht nur das Build-Verzeichnis. Zweitens, und das ist der eigentliche Punkt: Die Trennung nach Scope. Was mit dem Scope compile kommt, bringt die Anwendung selbst mit. Was als provided markiert ist, erwartet sie vom Server. Diese zweite Liste ist Ihre Migrationsliste.

2:50 Jeder Eintrag darauf braucht später eine Antwort — mitliefern, ersetzen oder streichen. Hier steckt der unangenehmste Teil dieses Kapitels. Bibliotheken aus der Laufzeit stehen in keiner Abhängigkeitsdatei der Anwendung — und ihre Versionen entscheiden trotzdem über Verhalten. Ein Beispiel, das Sie in fast jedem Projekt finden: Die Anwendung verlässt sich auf eine bestimmte Version einer JSON-Bibliothek, die der Server mitbringt.

3:15 Nach dem Wechsel liegt eine neuere Version vor, Datumsfelder werden anders serialisiert, und irgendwo bricht ein Abrechnungslauf. Noch schwerer zu finden sind Java-Agenten aus dem Start-Skript: Sie verändern Bytecode zur Laufzeit und tauchen in keinem Deployment auf. Der letzte Punkt ist der, den ich am häufigsten sehe. Ein Java-Agent steht im Start-Skript des Servers — für Monitoring, für Profiling, manchmal für eine Lizenzprüfung.

3:40 Er verändert das Verhalten der Anwendung, aber niemand sucht dort, weil es weder Code noch Konfiguration im üblichen Sinn ist. Und der erste Punkt kostet meist einen kompletten Tag: Man betrachtet nur das WAR, obwohl die Anwendung als EAR ausgeliefert wird — und wundert sich, warum die halbe Fachlogik fehlt. Beides ist leicht zu vermeiden, wenn Sie am ausgelieferten Artefakt beginnen statt im Projektverzeichnis.

Genutzte Spezifikationen und Serverressourcen

4:05 Jetzt geht es eine Ebene tiefer. Nicht mehr, was ausgeliefert wird, sondern was die Anwendung während des Betriebs vom Server erwartet. Das sind die Ressourcen, die auf der neuen Laufzeit niemand mehr bereitstellt. Für jede davon brauchen Sie am Ende eine Entscheidung. Denken Sie an eine Küche in einer Mietwohnung: Manches gehört Ihnen, manches ist fest eingebaut und bleibt beim Auszug da. Genauso verhält sich eine Anwendung zu ihrem Server.

4:31 Für jede Migration zählt, welche Jakarta-EE-Spezifikationen sie wirklich verwendet und welche Ressourcen sie vom Server erwartet: Data Sources, JMS-Ziele, Mail-Sessions, Timer, Realms. Jede dieser Ressourcen wird später entweder konfiguriert, ersetzt oder gestrichen. Diese drei Wörter sind die eigentliche Arbeit dieses Kapitels — und sie sollten neben jedem Eintrag stehen, bevor Sie das Modul verlassen.

4:55 Die Logik dieser Tabelle ist ein Suchplan: Für jeden Bereich gibt es einen Ort, an dem man nachsieht, und ein Erkennungsmerkmal. Beachten Sie besonders die letzte Zeile. Die herstellerspezifischen Zusatzdeskriptoren sind der teuerste Fund, weil sie in keiner Spezifikation eine Entsprechung haben — für alles Übrige gibt es einen dokumentierten Weg, für diese Dateien gibt es nur eine Fallentscheidung.

5:18 Und noch etwas: Suchen Sie immer an beiden Orten, in den Annotationen und in den Deskriptoren. Viele gewachsene Anwendungen nutzen beides gleichzeitig, teils sogar widersprüchlich. Diese vier Suchen liefern in wenigen Minuten ein erstaunlich vollständiges Bild. Die erste ist mehr als eine Suche: Sie ist Ihre Grundlinie.

5:37 Die Zahl der Dateien mit javax-Bezug sagt Ihnen, wie groß der Namensraumwechsel in Modul drei tatsächlich wird — und nach dem Wechsel misst dieselbe Zeile den Fortschritt. Die zweite Suche zielt auf JNDI-Zugriffe. Die sind deshalb besonders wichtig, weil sie als Zeichenketten im Code stehen: Kein Compiler, keine Typprüfung und keine Suche nach Klassen findet sie.

5:59 Nur eine Textsuche — oder ein Fehler zur Laufzeit. Der erste Punkt ist der Kern: Eine Suche von Hand findet, was man kennt. Sie findet nicht, was man vergessen hat. Genau dafür gibt es Werkzeuge wie das Migration Toolkit for Applications, die gegen gepflegte Regelsammlungen prüfen — Regeln, die aus vielen realen Migrationen entstanden sind.

6:19 Der zweite große Vorteil ist die Wiederholbarkeit: Ein Lauf, der jede Woche dieselbe Messung anstellt, zeigt Fortschritt. Eine Liste in einem Textdokument zeigt nur, was jemand an einem Dienstag im September aufgeschrieben hat. Werkzeuge sehen wir uns in Modul achtzehn im Detail an. Der letzte Punkt ist der klassische blinde Fleck.

6:39 Timer und Batch Jobs fehlen im Inventar, weil sie niemand aufruft — sie laufen nachts, sie gehören keinem Team, und im Code sieht man ihnen nicht an, dass sie ein Geschäftsprozess sind. In Zählwerk ist genau das der nächtliche Ableselauf. Er taucht in keiner Schnittstelle auf und ist trotzdem der kritischste Vorgang der Anwendung.

6:59 Und der zweite Punkt: JNDI-Namen entgehen jeder Suche nach Typen, weil sie Zeichenketten sind. Suchen Sie nach Text, nicht nach Klassen — sonst fehlen sie im Inventar.

Fachliche Sicht und Risikobild

7:09 Bis hierhin war alles technisch. Jetzt kommt die Ebene, die aus einer Liste eine Entscheidungsgrundlage macht: Nicht jeder Codeteil ist gleich viel wert. Wir verbinden das Inventar mit Änderungsfrequenz, Testabdeckung und Geschäftswirkung — und bekommen daraus eine Reihenfolge für die Arbeit der nächsten Monate. Das Risikobild verbindet zwei Sichten, die in Projekten meist getrennt bleiben: das technische Inventar und die fachliche Bedeutung.

7:35 Welche Geschäftsprozesse laufen über welchen Code, wie oft ändert er sich, und wie gut ist er getestet? Erst diese Verbindung macht aus einer Liste eine Grundlage für Entscheidungen. Denn eine Liste von zweihundert Fundstellen sagt Ihnen nicht, wo Sie anfangen sollen. Ein Risikobild sagt es Ihnen. Und es sagt Ihnen auch, wo Sie ganz sicher nicht anfangen sollten — was mindestens genauso wertvoll ist.

7:59 Diese vier Felder sind eine Landkarte für die Reihenfolge Ihrer Arbeit. Unten links, gut getestet und unkritisch, ist das Übungsfeld — dort baut man die Werkzeugkette auf, ohne Schaden anrichten zu können. Oben rechts, kaum getestet und geschäftskritisch, liegt der Bereich, der niemals Pilot sein darf; dort muss zuerst Testabdeckung entstehen.

8:19 Das eigentlich Interessante ist das Feld unten rechts: kaum getestet, aber unkritisch. Hier lohnt sich die Reihenfolge erst Tests, dann Umbau — und man lernt dabei, wie viel Zeit Characterization Tests in dieser Anwendung wirklich kosten. Vier Fragen, und die letzte ist die unbequemste: Wer würde einen Fehler bemerken, und wie schnell?

8:39 In vielen gewachsenen Anwendungen ist die ehrliche Antwort: der Fachbereich, am Monatsende, beim Abgleich. Das ist eine Rückmeldeschleife von vier Wochen — und sie bestimmt, wie schnell Sie migrieren dürfen. Die Änderungsfrequenz aus der Versionsverwaltung ist übrigens die einzige dieser vier Angaben, die Sie nicht schätzen müssen.

8:58 Sie steht in der Historie, sie ist objektiv, und sie überrascht regelmäßig: Häufig wird ein ganz anderer Bereich angefasst als der, den alle für den aktiven halten. Der rote Faden hier: von der Technik zur Fachlichkeit und wieder zurück zu einer Einordnung. Zwei Schritte verdienen besondere Aufmerksamkeit. Schritt zwei holt die Änderungsfrequenz aus der Versionsverwaltung — das ist harte Datenlage statt Bauchgefühl und dauert eine halbe Stunde.

9:24 Und Schritt drei sagt ausdrücklich: messen, nicht schätzen. Geschätzte Testabdeckung fällt in der Messung fast immer um die Hälfte niedriger aus, weil ausgeführter Code mit geprüftem Code verwechselt wird. Am Ende steht die Einordnung in die vier Felder — und damit haben Sie den Kandidaten für Modul sieben schon fast bestimmt.

9:43 Der dritte Punkt ist subtil und deshalb häufig: Die Änderungsfrequenz wird über die ganze Anwendung gemittelt. Dann kommt heraus, dass Zählwerk „mäßig aktiv" ist — und diese Aussage ist wertlos, weil sie einen eingefrorenen Bereich mit einem täglich geänderten verrechnet. Messen Sie je Bereich. Und der letzte Punkt betrifft die Kritikalität: Sie wird gern nach Codegröße bewertet, weil die leicht zu messen ist.

10:05 Aber die Tarifrechnung von Zählwerk ist vielleicht dreihundert Zeilen lang und entscheidet trotzdem über jeden Euro, der in Rechnung gestellt wird.

Übung

10:14 Jetzt setzen wir das zusammen. Diese Übung ist die längste des ersten Tages — und ihr Ergebnis begleitet uns durch alle weiteren Module. Sie ist überwiegend Fleißarbeit. Der Denkanteil steckt in der letzten Spalte, in der jede einzelne Fundstelle eine Entscheidung bekommt. Sie erstellen für Zählwerk ein vollständiges Inventar: Deployment-Struktur, eingesetzte Spezifikationen, Data Sources, Queues, Timer und die Schnittstellen zum Abrechnungssystem.

10:41 Das Lernziel ist die Fähigkeit, eine Anwendung so zu erfassen, dass keine Serverbindung übersehen wird — denn übersehene Bindungen sind es, die eine Migration später aus dem Zeitplan werfen. Erfolgreich sind Sie, wenn neben jeder gefundenen Serverbindung eines von drei Wörtern steht: konfigurieren, ersetzen oder streichen.

11:00 Und wenn jeder fachliche Bereich einem der vier Quadranten zugeordnet ist. Das ist mehr Fleißarbeit als Denksport — aber es ist die Grundlage für jede Entscheidung, die danach kommt. Die Reihenfolge hat einen Grund: Sie arbeiten sich von außen nach innen und von der Technik zur Fachlichkeit vor. Erst das Archiv, dann die Deskriptoren, dann die Ressourcen, dann die fachliche Zuordnung — und ganz zum Schluss die Entscheidung je Bindung.

11:26 Wichtig ist Schritt fünf, denn dort entsteht der Wert des Dokuments. Ein Inventar ohne Markierung ist eine Liste; ein Inventar mit Markierung ist ein Plan. Und behandeln Sie das Ergebnis als Arbeitsdokument, nicht als Bericht. Wir werden es in fast jedem Modul wieder öffnen und ergänzen. Der zweite Punkt ist der wichtigste: Die Markierung ersetzen wird vergeben, ohne den Ersatz zu benennen.

11:49 Damit ist nichts gewonnen — Sie haben das Problem nur mit einem Wort zugedeckt. Schreiben Sie dazu, wodurch ersetzt wird, und wenn Sie es noch nicht wissen, schreiben Sie genau das hin. Offene Fragen sind bessere Einträge als vage Zusagen. Und der dritte Punkt: Realm und Rollen fehlen, weil Sicherheit ja erst in Modul zwölf drankommt.

12:09 Sie gehören trotzdem jetzt ins Inventar — sonst fehlen sie in der Aufwandsschätzung, die in Modul vier gebraucht wird.