Modernisierungsstrategien auswählen

Modernisierungsstrategien auswählen

0:00 Willkommen zum dritten Tag. Bisher ging es um einzelne Umbauten — heute zoomen wir heraus. Die Frage lautet nicht mehr, wie man eine Funktion sauber umstrukturiert, sondern was mit einem System überhaupt geschehen soll. Und da kursiert eine falsche Alternative: Entweder wir lassen alles, wie es ist, oder wir bauen neu. Zwischen diesen beiden Polen liegen mindestens vier weitere Möglichkeiten, und eine davon ist regelmäßig die beste und wird fast nie geprüft.

0:27 In diesem Modul lernen Sie das ganze Spektrum kennen — und einen Entscheidungsweg, der Sie zuverlässig hindurchführt.

Modernisierungsstrategien auswählen

0:34 Der dritte Tag hat drei Themen: Strategie, Sicherheit, Team. Wir beginnen mit der Frage nach dem Antrieb — denn das Motiv bestimmt nicht nur die Wahl, es ist zugleich Ihr Abnahmekriterium. Dann das Spektrum der Möglichkeiten und die schrittweise Ablösung als wichtigstes Muster. Danach zwei Themen, die oft zu früh oder zu spät angegangen werden: Modularisierung vor Trennung und die Beobachtbarkeit vor tiefgreifenden Änderungen.

0:59 Und zum Schluss ein Entscheidungsweg in Frageform. In der Übung entscheiden Sie drei Szenarien und halten die Begründung fest.

Was die Modernisierung antreibt

1:07 Fangen wir mit einer Frage an, die banal wirkt und über den Erfolg entscheidet: Warum eigentlich? Nicht als rhetorische Frage — als Anforderung an die Projektbeschreibung. Vier Motive kommen in der Praxis vor, und sie führen zu unterschiedlichen Entscheidungen. Das ist der praktische Grund, sie zu benennen: Wenn das Motiv Risiko heißt, ist eine Aktualisierung die Antwort.

1:30 Wenn es Änderungsfähigkeit heißt, hilft die Aktualisierung gar nichts. Aber es gibt noch einen zweiten Grund, und der ist wichtiger. Das Motiv ist Ihr Abnahmekriterium. Es sagt Ihnen, wann Sie fertig sind — und ohne das läuft ein Modernisierungsvorhaben so lange, bis das Geld ausgeht. Schauen Sie sich die rechte Spalte an: Jedes Motiv hat ein beobachtbares Zeichen.

1:53 Änderungsfähigkeit zeigt sich daran, dass Anforderungen nicht mehr in vertretbarer Zeit umsetzbar sind — das können Sie an Durchlaufzeiten ablesen. Risiko zeigt sich an fehlenden Sicherheitsaktualisierungen. Kosten zeigen sich in der Rechnung. Und Personal zeigt sich daran, dass Stellen unbesetzt bleiben. Die Fußzeile ist die Konsequenz aus alledem: Ein Vorhaben, das sein Motiv nicht benennen kann, hat keinen Punkt, an dem es fertig ist.

2:19 Es läuft ewig oder wird irgendwann abgebrochen — meist zu drei Vierteln fertig. Der erste Punkt ist der häufigste: Das Motiv wird als technisches Unbehagen formuliert — „die Architektur ist nicht mehr zeitgemäß“. Damit können Sie nicht abnehmen und niemanden überzeugen, der das Geld freigibt. Der dritte beschreibt die verbreitete Reihenfolge: Erst steht die Technologie fest, dann wird das Motiv nachgereicht.

2:44 Und der vierte ist die organisatorische Gedächtnislücke — halten Sie das Motiv schriftlich fest. In zwei Jahren fragt jemand, warum dieses Vorhaben eigentlich läuft, und dann sollte es eine Antwort geben.

Die Handlungsmöglichkeiten im Überblick

2:56 Jetzt das Spektrum. Sechs Möglichkeiten zwischen Nichtstun und Neubau — und die sechste ist die günstigste von allen und wird am seltensten geprüft. In den meisten Diskussionen werden nur die beiden Enden verhandelt: alles lassen oder alles neu. Das ist ungefähr so, als hätten Sie bei einem alten Haus nur die Wahl zwischen Nichtstun und Abriss.

3:16 Dazwischen liegt praktisch alles, was sinnvoll ist — sanieren, umbauen, einen Teil abtrennen, einen Anbau setzen, einen Raum schließen. Genau diese Zwischenschritte schauen wir uns jetzt an. Aus ihnen kommen in der Praxis die meisten guten Entscheidungen. Die Reihenfolge ist eine Steigerung nach Eingriffstiefe — von oben, wo nichts am Code passiert, bis unten, wo etwas verschwindet.

3:39 Stabilisieren heißt: nichts umbauen, nur absichern. Kapseln kennen Sie aus Modul sieben. Refaktorieren aus Modul sechs. Migrieren tauscht Technologie und erhält Fachlichkeit. Ersetzen baut einen abgegrenzten Teil neu. Und Stilllegen heißt schlicht: feststellen, dass ein Teil nicht mehr gebraucht wird, und ihn abschalten.

3:59 Die Fußzeile sagt das Entscheidende: Diese letzte Möglichkeit wird am seltensten geprüft und ist die günstigste von allen. Deshalb steht diese Frage vor allen anderen: Welcher Teil des Systems wird eigentlich noch benutzt? Ich habe das in mehreren Projekten erlebt, und die Antwort ist regelmäßig überraschend — ganze Berichtsbereiche, die seit Jahren niemand aufruft, Importschnittstellen für ein Nachbarsystem, das abgeschaltet wurde.

4:25 Wichtig ist der dritte Punkt: Beantwortet wird das durch Beobachtung, nicht durch Nachdenken. Und der vierte ist die schlichte Rechnung dahinter — ein stillgelegter Teil verursacht keine Modernisierungskosten mehr. Kein Test, kein Umbau, keine Aktualisierung.

Schrittweise Ablösung statt großem Wurf

4:40 Jetzt zum wichtigsten Muster der Modernisierung. Es trägt den Namen einer Würgefeige — einer Pflanze, die an einem Baum emporwächst, ihn allmählich ersetzt und am Ende allein stehenbleibt. Das Bild ist präzise: Das Neue wächst am Alten empor und übernimmt Stück für Stück dessen Aufgaben. Praktisch setzen Sie eine Weiche vor das Bestandssystem, die Anfragen entweder ans Alte oder ans Neue leitet.

5:04 Sie beginnen mit einem kleinen, gut abgegrenzten Bereich, führen den vollständig neu aus und schalten um — mit der Möglichkeit zurückzuschalten. Dann den nächsten. Sie erkennen das Prinzip aus Modul sieben wieder: Es ist Branch by Abstraction, nur eine Etage höher. Fünf Schritte, und der erste ist der, bei dem viele es sich zu schwer machen: Wählen Sie einen kleinen, gut abgegrenzten Bereich.

5:28 Nicht den wichtigsten, nicht den schlimmsten — den, an dem Sie das Verfahren lernen können. Schritt drei ist die Qualitätssicherung: Vergleichen Sie das neue Verhalten gegen das alte, mit den Mitteln aus Modul acht. Und Schritt vier enthält die Eigenschaft, die alles trägt: die Rückschaltmöglichkeit. Die Fußzeile fasst den Vorteil gegenüber dem Neubau zusammen — Nutzen ab dem ersten Bereich und Umkehrbarkeit an jedem Punkt.

5:53 Damit das nicht zu schön klingt: Dieses Muster hat einen Preis, und der ist real. Sie haben eine lange Phase mit zwei Systemen nebeneinander. Sie haben einen gemeinsamen Datenbestand mit zwei Zugriffswegen — das ist der technisch unangenehmste Teil. Und Sie pflegen doppelt, auch bei Fehlerkorrekturen. Der vierte Punkt ist der ehrliche: Dieser Preis verschwindet nicht dadurch, dass man ihn im Plan wegläßt. Er ist trotzdem da.

6:18 Der Unterschied zum Neubau ist nicht, dass die Doppelpflege entfiele — sie entfällt dort auch nicht — sondern dass Sie hier ab dem ersten Bereich etwas davon haben.

Monolithen modularisieren, bevor man trennt

6:28 Jetzt zu einem Wunsch, der in fast jedem Modernisierungsgespräch auftaucht: das große System in eigenständige Dienste zerlegen. Meist wird er zu früh umgesetzt — und der Grund dafür ist lehrreich. Die nüchterne Reihenfolge lautet: erst Modulgrenzen im bestehenden System ziehen und stabilisieren, dann prüfen, ob eine Trennung überhaupt nötig ist.

6:48 Der Grund steckt in einem einfachen Unterschied: Eine falsch gezogene Grenze innerhalb eines Systems ist eine Unbequemlichkeit — Sie verschieben ein paar Klassen. Dieselbe falsche Grenze zwischen zwei Systemen ist ein dauerhaftes Problem, denn zwischen den beiden Teilen stehen plötzlich Netzwerk, Versionierung, Datenkonsistenz und getrennter Betrieb.

7:08 Der erste Punkt beschreibt, was Sie sich einhandeln — vier Problemklassen, die vorher nicht existierten. Der zweite ist die Diagnose: Wenn nach der Trennung jede Änderung beide Seiten berührt, war die Grenze falsch. Nicht die Auslieferung war das Problem, sondern der Schnitt. Der dritte Punkt ist der praktische Vorteil der richtigen Reihenfolge: Im Bestand können Sie eine Grenze noch verschieben.

7:30 Und der vierte ist die häufigste Überraschung: Nach einer sauberen Modularisierung stellt sich oft heraus, dass die Trennung gar nicht mehr gebraucht wird. Der erste Punkt ist der Kern: Trennung ist ein Mittel, kein Ziel. Wenn im Vorhaben steht „wir zerlegen den Monolithen“, fehlt die Begründung. Der zweite ist der häufigste Schnittfehler — Grenzen nach Technik statt nach Fachlichkeit zu ziehen, also alle Datenzugriffe hierhin und alle Oberflächen dorthin.

7:57 Danach berührt jede fachliche Änderung beide Teile. Und der dritte beschreibt, warum die Modularisierung übersprungen wird: Sie ist nach außen unsichtbar. Man kann keine Architekturgrafik mit neuen Kästchen zeigen.

Technische Aktualisierungen und Abhängigkeiten

8:10 Kommen wir zu einem großen Teil der Modernisierungsarbeit, der gar keine Modernisierung ist, sondern Pflege — die nur zu lange unterblieben ist. Hier sind Agenten übrigens besonders wirksam. Wenn Sie ein Bestandssystem übernehmen, ist ein erheblicher Teil der Arbeit schlicht Nachholen: Laufzeitumgebung, Framework, Bibliotheken.

8:30 Das ist wenig glamourös und oft der wirksamste Hebel — besonders wenn das Motiv Risiko heißt. Dafür gibt es drei Erfahrungswerte, die sich in vielen Projekten wiederholen, und einen Vorbehalt, der für alle gilt. Den Vorbehalt nenne ich gleich vorweg: Ohne Tests ist jede Aktualisierung ein Blindflug, gleichgültig wer sie ausführt.

8:50 Die ersten beiden Schritte gehören zusammen und werden am häufigsten verletzt: kleine Schritte statt eines Sprungs über mehrere Hauptversionen. Der Grund ist praktisch — die Zwischenversionen tragen die Übergangshilfen und die Warnungen, die Ihnen sagen, was sich ändern wird. Wer sie überspringt, verliert genau diese Hinweise und steht vor einem Wall von Fehlern ohne Anleitung. Schritt drei sorgt dafür, dass ein Fehlschlag zuordenbar bleibt.

9:15 Und die Fußzeile benennt die Rolle des Agenten: Diese Arbeit ist mechanisch und wiederholt, also genau sein Feld — aber die Absicherung ersetzt er nicht. Der zweite Punkt ist der, den ich am häufigsten sehe, und er ist gut gemeint: Aktualisierungen bündeln, um einmal Ruhe zu haben. Wenn dann etwas bricht, wissen Sie nicht, welche der acht Änderungen es war.

9:35 Der dritte beschreibt die Ausgangslage vieler Projekte: Der Rückstand wächst, bis der Sprung nicht mehr planbar ist — und dann wird er zum eigenen Vorhaben mit eigenem Budget. Und der vierte ist die häufigste Selbsttäuschung im agentischen Umfeld: Ein Agent kann eine Aktualisierung durchführen. Ob sie funktioniert hat, sagt Ihnen nur ein Testlauf.

Beobachtbarkeit vor tiefgreifenden Änderungen

9:56 Jetzt eine Voraussetzung, die regelmäßig übersprungen wird und sich zuverlässig rächt. Sie hat eine seltene Eigenschaft: Sie ist für sich genommen risikofrei. Bevor Sie ein System tiefgreifend verändern, müssen Sie sehen können, wie es sich verhält. Das klingt selbstverständlich und wird trotzdem ausgelassen, weil es nach Vorarbeit aussieht.

10:16 Ohne diese Sicht können Sie nach einer Umstellung nicht beurteilen, ob es besser oder schlechter geworden ist — Ihnen fehlt der Vorher-Wert. Und Verschlechterungen merken Sie dann erst, wenn sich jemand beschwert. Das ist in einem produktiven System eine schlechte Meldekette: Sie erfahren es spät, über Umwege, und meist von der falschen Person.

10:36 Drei Fragen, und alle drei zahlen direkt auf das ein, was wir in den letzten Tagen gebaut haben. Wie oft wird welcher Teil aufgerufen — und welcher gar nicht? Das ist die Nutzungsfrage von vorhin und zugleich die Frage nach totem Code aus Modul sechs. Wie lange dauern die kritischen Vorgänge? Das ist die Vorher-Messung aus Modul acht.

10:57 Und welche Fehler treten wie häufig auf? Das ist die Kritikalitätsachse aus Modul drei. Eine Maßnahme, drei offene Fragen beantwortet. Diese Tabelle zeigt, warum Beobachtbarkeit so hoch im Kurs stehen sollte: Sie liefert Antworten für Fragen, die Sie an drei verschiedenen Stellen gestellt haben. Aufrufzahlen je Codepfad beantworten die Frage nach totem Code, ohne dass Sie dafür eine eigene Untersuchung starten müssen.

11:22 Die Vorher-Messung brauchen Sie ohnehin für jeden späteren Vergleich. Und Fehlerhäufigkeiten machen aus der Kritikalitätsachse eine Zahl statt einer Einschätzung. Die Fußzeile nennt das Besondere: Beobachtbarkeit ändert das Verhalten nicht. Deshalb ist sie der einzige Schritt, den Sie vor der Absicherung guten Gewissens machen können.

Der Entscheidungsweg

11:41 Zum Abschluss bringen wir alles in eine Reihenfolge. Kein Entscheidungsbaum mit Punkten und Gewichten — sieben Fragen, die Sie der Reihe nach stellen und meistens gar nicht zu Ende gehen müssen. Der Zweck dieses Wegs ist nicht, Ihnen das Urteil abzunehmen. Er soll verhindern, dass die naheliegendste Antwort die einzige geprüfte bleibt.

12:00 In den meisten Diskussionen steht die Lösung nämlich schon fest, bevor die Analyse beginnt — jemand hat eine Idee, und alles Weitere wird zur Begründung. Der Entscheidungsweg stellt die billigen Fragen zuerst. Und die billigen Fragen sind hier auch die, die am häufigsten die günstigste Antwort ergeben. Frage eins ist die günstigste: Wird der Teil überhaupt noch gebraucht? Wenn nein, sind Sie fertig.

12:24 Frage zwei greift den Gedanken aus Modul eins auf — ohne Änderungsdruck lassen Sie es in Ruhe, unabhängig vom Zustand. Frage drei ist die Weiche zu Tag eins: Ist es absicherbar? Wenn nein, stabilisieren Sie zuerst. Frage vier und fünf führen zu Refactoring beziehungsweise Migration. Und die Fußzeile schließt den Bogen: Das schrittweise Ersetzen kommt, wenn die Fachlichkeit selbst überholt ist — und der Neubau steht ganz am Ende, nicht am Anfang.

12:52 Zum Schluss die Bitte, das Ergebnis festzuhalten. Diese Entscheidungen werden in zwei Jahren hinterfragt, meist von Personen, die heute nicht im Raum sind. Ohne Begründung wirkt jede getroffene Wahl im Rückblick beliebig — und dann wird sie neu diskutiert, mit demselben Aufwand. Der dritte Punkt ist der wichtigste: Die verworfenen Alternativen sind der wertvollste Teil der Notiz.

13:15 Sie zeigen, dass geprüft wurde, und sie verhindern, dass jemand in zwei Jahren mit einem Vorschlag kommt, den Sie damals schon durchgerechnet haben. Vier Punkte genügen: Kontext, Entscheidung, Alternativen, Konsequenzen.

Übung: Drei Szenarien entscheiden und begründen

13:28 In der Übung entscheiden Sie drei Szenarien aus dem Fahrtenbuch. Und es gibt eine Zusatzregel, die Sie bei allen dreien anwenden — sie ist der eigentliche Test dieses Moduls. Drei Szenarien, drei verschiedene Motive. Die veraltete Datumsbibliothek ohne Sicherheitsunterstützung ist ein Risikofall. Die Abrechnung mit hohem Änderungsdruck und ohne Tests ist ein Fall für die Reihenfolge aus Modul drei.

13:52 Und der kaum genutzte Berichtsteil in einer Technologie, die niemand mehr beherrscht, ist der interessanteste — hier ist Stilllegen die naheliegende Antwort, und sie wird trotzdem fast nie zuerst genannt. Achten Sie darauf, ob sie in Ihrer Gruppe fällt, und wie lange es dauert. Gehen Sie je Szenario den Entscheidungsweg wirklich von oben durch, auch wenn Sie die Antwort zu kennen glauben.

14:15 Schritt drei wird oft übersprungen und ist wesentlich: Welche Voraussetzungen müssen erfüllt sein, bevor die gewählte Strategie überhaupt starten kann? Bei der Abrechnung ist das ein Testnetz. Die Notiz in Schritt vier ist kein Formalismus — sie ist in zwei Jahren das Einzige, was von Ihrer Abwägung übrig ist. Und Schritt fünf ist die Zusatzregel: Prüfen Sie bei allen drei ausdrücklich, ob Stilllegen möglich gewesen wäre. Auch dort, wo es offensichtlich nicht geht.