Einen geeigneten Migrationspiloten auswählen

Einen geeigneten Migrationspiloten auswählen

0:00 Der zweite Tag beginnt mit einer Auswahl. Wir haben entschieden, welche Wege für welche Teile von Zählwerk gelten — jetzt bestimmen wir, wo wir anfangen. Und das ist keine Nebensache: Der Pilot beweist nämlich gar nicht so viel über die Technik. Die Technik funktioniert, das wissen wir. Er beweist etwas über das Team, über den Weg und über die Aufwände.

0:20 In diesem Modul sehen wir uns an, wie man Kandidaten bewertet, welche technischen Hürden den Schnitt bestimmen und wie ein Pilot geplant wird, der ein Ende hat.

Einen geeigneten Migrationspiloten auswählen

0:30 Der zweite Tag ist der Tag der Umsetzung. Wir wählen einen Piloten aus, übertragen seine HTTP-Schnittstelle, bauen die Enterprise Beans um, übernehmen den Datenzugriff, migrieren das Messaging und stellen die Sicherheit auf Token um. Am Abend läuft ein fachliches Modul von Zählwerk auf der neuen Laufzeit — mit allem, was dazugehört.

Kandidaten bewerten

0:51 Fangen wir mit der Auswahl an. Die Anforderung an einen Piloten klingt widersprüchlich: klein genug zum Scheitern, groß genug zum Lernen. Vier Kriterien helfen bei der Auswahl, und eines davon führt regelmäßig zu einer Antwort, die man nicht erwartet hätte. Ein Migrationspilot ist ein fachlich abgegrenzter Teil der Anwendung, der als erster auf die neue Laufzeit wechselt.

1:13 Wichtig ist das Wort vollständig: Er soll den ganzen Weg durchlaufen — Code, Tests, Betrieb, Rückweg — und dabei so wenig Schaden anrichten können wie möglich. Denken Sie an eine Generalprobe: Die ist nicht deshalb wertvoll, weil sie leicht ist, sondern weil sie alles einmal in der richtigen Reihenfolge durchspielt. Ein Pilot, der beim Code aufhört und nie in Produktion geht, ist keine Generalprobe. Er ist ein Experiment ohne Ergebnis.

1:39 Die Logik dieser Tabelle ist ein Ausschlussverfahren: Für jedes Kriterium gibt es eine Seite, die für einen Piloten spricht, und eine, die dagegen spricht. Besonders lehrreich ist die zweite Zeile, die Änderungsfrequenz. Man würde intuitiv einen eingefrorenen Bereich wählen — da kommt einem niemand in die Quere. Aber wie die Fußzeile sagt: Ein eingefrorener Teil taugt nicht als Pilot, denn niemand merkt hinterher, ob er besser änderbar geworden ist.

2:05 Sie hätten dann etwas migriert, dessen Verbesserung sich nie zeigt. Mittlere, aktiv gepflegte Bereiche sind die richtige Wahl. Der erste Punkt ist der entscheidende: Den ganzen Weg zeigen, nicht nur den angenehmen Teil davon. Der angenehme Teil ist das Übertragen des Codes — das geht oft überraschend schnell und erzeugt trügerischen Optimismus.

2:26 Der unangenehme Teil kommt danach: Betrieb, Tests, Rollout, Rückweg. Genau dort liegen die Aufwände, mit denen Sie den Rest hochrechnen. Und Punkt vier ist der menschliche: Der Pilot gibt dem Team Sicherheit, bevor kritische Teile folgen. Diese Sicherheit ist keine Nettigkeit — sie entscheidet darüber, ob das Team beim zweiten Modul schneller wird oder vorsichtiger.

2:49 Punkt eins und zwei sind die beiden Enden desselben Fehlers. Wird das einfachste Stück gewählt, lehrt der Pilot nichts — es gibt keine Transaktionsgrenze, keine Integration, keine echte Last. Wird das kritischste gewählt, traut sich niemand, es auszurollen, und der Pilot bleibt im Testsystem stecken. Das ist Punkt drei, und er ist der häufigste: Migriert, aber nie in Produktion genommen. Damit fehlt genau die Aussage, für die man den Piloten gemacht hat.

3:16 Nehmen Sie sich vor der Auswahl vor, dass dieses Modul produktiv geht — und wählen Sie dann eines, bei dem das realistisch ist.

Technische Hürden erkennen

3:24 Jetzt zur technischen Seite. Und hier gilt eine Regel, die viele überrascht: Der Umfang des Codes ist fast egal. Es kommt auf die Bindungen an. Vier Bindungen bestimmen, ob ein Schnitt hält — und die erste davon ist technisch nicht verhandelbar. Die Machbarkeit eines Piloten hängt weniger am Umfang seines Codes als an seinen Bindungen: gemeinsame Transaktionen mit dem Rest der Anwendung, geteilte Tabellen, JNDI-Zugriffe auf Serverressourcen, herstellerspezifische Funktionen ohne Entsprechung.

3:54 Stellen Sie sich vor, Sie wollten ein Zimmer aus einem Haus herauslösen. Die Größe des Zimmers ist nicht das Problem — die Frage ist, wie viele Leitungen, Rohre und tragende Wände hindurchlaufen. Genau diese Leitungen haben wir in Modul zwei inventarisiert. Jetzt zählen wir sie je Kandidat. Vier Fragen, die Sie an jeden Kandidaten stellen. Teilt er eine Transaktion mit dem Bestand? Schreiben beide dieselben Tabellen? Hängt er am Sicherheitskontext des Servers?

4:21 Nutzt er Serverfunktionen ohne Ersatz? Wenn Sie viermal Nein sagen können, haben Sie einen sauberen Schnitt gefunden — und das ist selten genug, dass es sich lohnt, danach zu suchen, statt den erstbesten Kandidaten zu nehmen. Wenn Sie mehrfach Ja sagen müssen, ist das kein Ausschlusskriterium, aber es verschiebt den Aufwand: Dann migrieren Sie nicht nur Code, sondern lösen zuerst eine Kopplung auf.

4:45 Diese Frage steht deshalb ganz vorn, weil sie technisch am wenigsten verhandelbar ist. Eine Transaktion über zwei Laufzeiten hinweg gibt es nicht ohne Weiteres, und Quarkus unterstützt keine verteilten Transaktionen über mehrere Ressourcen. Das heißt nicht, dass es keine Lösung gibt — es heißt, dass die Lösung ein Entwurf ist und keine Konfiguration.

5:06 Und Punkt drei ist der, der in der Praxis weh tut: Wer die Grenze nicht zieht, findet sie später als sporadischen Fehler wieder. Sporadisch heißt: unter Last, in Produktion, schwer nachzustellen. Die gute Nachricht steht in Punkt vier — der fachlich richtige Schnitt ist meist auch der transaktionale. Der rote Faden: Sie folgen den Verbindungen über die Kandidatengrenze und fragen bei jeder, wie fest sie ist.

5:30 Beachten Sie die Fußzeile, sie ist eine klare Ansage: Ein Kandidat, der Schritt drei nicht besteht — also gemeinsame Tabellen ohne geklärte Hoheit hat —, ist kein Pilot, sondern eine Datenmigration. Das ist ein völlig anderes Vorhaben mit anderem Aufwand und anderem Risiko. Und Schritt fünf ist die eigentliche Entscheidung: Hält der Schnitt, oder muss er verschoben werden?

5:51 Manchmal ist die richtige Antwort, den Schnitt um eine Ebene zu verlagern, statt die Kopplung zu ignorieren. Punkt eins beschreibt genau den Fehler, den Punkt elf verhindern soll: Die gemeinsame Transaktion wird erst beim ersten Rollback entdeckt. Bis dahin funktioniert alles — Rollbacks sind ja selten. Genau deshalb fällt es so spät auf.

6:12 Punkt drei ist der leise: Der Sicherheitskontext des Servers wird stillschweigend vorausgesetzt. Der Code fragt nach der Rolle und bekommt sie, ohne dass jemand aufgeschrieben hätte, woher sie kommt. In der neuen Laufzeit kommt sie aus dem Token — und das muss erst einmal jemand hinschicken. Wir behandeln das in Modul zwölf.

Den Piloten planen

6:32 Wir haben einen Kandidaten. Jetzt planen wir ihn — und zwar so, dass er ein Ende hat. Ein Spike mit Zeitrahmen, Akzeptanz- und Abbruchkriterien ist etwas anderes als ein Vorhaben, das läuft, bis es irgendwann fertig ist. Der Pilot wird als zeitlich begrenzter Spike geplant: mit einem Ziel, einem Zeitrahmen, Akzeptanzkriterien und einem Abbruchkriterium.

6:54 Das Abbruchkriterium ist der Teil, der ihn von einem Projekt ohne Ende unterscheidet. Und es ist der Teil, der fast immer fehlt — nicht aus Nachlässigkeit, sondern weil niemand ein Vorhaben beginnt und dabei über sein Scheitern spricht. Genau deshalb muss es vorher aufgeschrieben werden, in Ruhe, bevor jemand emotional investiert ist. Hinterher ist jede Abbruchdiskussion eine Schuldfrage.

7:18 Die Logik dieser Tabelle steht in der dritten Spalte: Jeder Punkt braucht eine Prüfmöglichkeit. Ein Ziel, das man nicht prüfen kann, ein Zeitrahmen ohne Kalender, Akzeptanzkriterien ohne Test — das sind gute Absichten, keine Planung. Und die Fußzeile enthält die Erfahrung aus vielen Projekten: Wer den Abbruch nicht vorher beschreibt, verlängert im Zweifel immer. Denn im Zweifel ist man ja fast fertig.

7:41 Man ist es dann noch drei Wochen später auch. Zwei Wochen und ein Paar sind übrigens ein realistischer Zuschnitt — lang genug für einen vollständigen Durchlauf, kurz genug, um nicht zum Projekt zu werden. Der erste Punkt ist die Verbindung zu Modul eins: Ohne Messwerte bleibt der Vergleich mit dem Bestand eine Behauptung.

8:00 Und Behauptungen überzeugen niemanden, der über das nächste Budget entscheidet. Der Pilot liefert die Grundlinie, an der alle folgenden Module gemessen werden — Antwortzeit, Fehlerrate, Speicherbedarf. Das lohnt sich doppelt, weil Sie diese Instrumentierung später ohnehin brauchen; Sie ziehen sie nur vor. Und Punkt drei ist praktisch: Fehler in der neuen Laufzeit fallen sonst erst dem Fachbereich auf. Das ist die teuerste aller Rückmeldeschleifen.

8:27 Punkt eins und zwei gehören zusammen und sind der klassische Selbstbetrug: Der Spike wird verlängert, weil das Ergebnis fast erreicht ist, und die Akzeptanzkriterien werden nachträglich an das Ergebnis angepasst. Beides passiert nicht aus Unehrlichkeit, sondern aus Optimismus — und beides zerstört die Aussagekraft. Wenn Sie die Kriterien anpassen wollen, schreiben Sie wenigstens dazu, dass Sie es getan haben und warum.

8:51 Punkt vier ist der wirtschaftlichste: Das Ergebnis wird nicht dokumentiert und muss beim zweiten Modul neu erarbeitet werden. Ein Pilot ohne Protokoll ist ein halber Pilot.

Übung

9:01 Jetzt entscheiden Sie. Drei Kandidaten, ein Pilot — und zwei Kriterien, die den Ausschlag geben. Welche das sind, ergibt sich aus den beiden vorigen Kapiteln: die Transaktionsgrenze und die Testbarkeit. Die Kandidaten sind Ableseauftrag, Tarifrechnung und Anschlussverwaltung. Das Lernziel ist die begründete Auswahl anhand von Abhängigkeiten, Kritikalität, Testbarkeit und Transaktionsgrenzen — nicht das Finden der einen richtigen Antwort.

9:28 Erfolgreich sind Sie, wenn ein Kandidat gewählt ist, die beiden anderen mit Grund verworfen sind und für den Spike Zeitrahmen sowie je zwei Akzeptanz- und Abbruchkriterien feststehen. Die Bewertung stützt sich auf das Risikobild aus Modul zwei — nehmen Sie es also mit in die Übung, sonst diskutieren Sie über Eindrücke statt über Daten.

9:48 Fünf Schritte, und Schritt drei enthält die eigentliche Empfehlung: Wählen Sie den Kandidaten mit der klarsten Transaktionsgrenze. Nicht den kleinsten, nicht den interessantesten, nicht den, dessen Code am hässlichsten ist — den mit der klarsten Grenze. Denn alles andere lässt sich mit Aufwand lösen; eine unklare Transaktionsgrenze bleibt eine offene Wunde durch das ganze Projekt.

10:10 Schritt fünf ist der, den man gern vergisst: festhalten, welche Messwerte der Spike liefern muss. Wenn Sie das erst am Ende überlegen, haben Sie den Ausgangswert nicht mehr. Punkt eins ist menschlich und häufig: Gewählt wird nach Sympathie für die Fachlichkeit. Die Tarifrechnung ist interessanter als die Anschlussverwaltung — das ist wahr und trotzdem kein Kriterium.

10:32 Punkt zwei ist die konkrete Falle in dieser Übung: Die Tarifrechnung teilt mit dem Bestand eine Transaktion, und genau deshalb ist sie ein schlechter Pilot, so reizvoll sie ist. Punkt drei ist der kulturelle: Abbruchkriterien fehlen, weil ein Scheitern als Gesichtsverlust gilt. Kehren Sie das um — ein Pilot, der rechtzeitig abgebrochen wird, hat seine Aufgabe erfüllt. Er hat nämlich etwas herausgefunden.