Änderungsflächen und Risiken bestimmen

Änderungsflächen und Risiken bestimmen

0:00 Sie haben das System jetzt erkundet und wissen ungefähr, wie es funktioniert. Die nächste Frage klingt harmlos und ist es nicht: Was passiert eigentlich, wenn wir hier etwas ändern? Wie weit reicht das? In Bestandssystemen ist diese Frage deshalb schwer, weil die Verbindungen nicht alle im Code stehen. Manche laufen über Konfiguration, manche über die Datenbank, manche über die schlichte Annahme, dass ein nächtlicher Lauf allein läuft.

0:25 In diesem Modul lernen Sie, diese Änderungsfläche systematisch abzugehen — und daraus eine Arbeitsreihenfolge abzuleiten, die das Risiko dorthin schiebt, wo Sie es beherrschen.

Änderungsflächen und Risiken bestimmen

0:35 Wir gehen die Änderungsfläche in Kreisen ab, von innen nach außen. Zuerst der fachliche Ablauf, der sich ändern soll. Dann die Abhängigkeiten im Code — und die wichtigere Frage, welche davon eine Suche gar nicht findet. Dann alles, was nach außen zeigt: Verträge, Formate, Daten. Dann eine Kategorie, die nirgends steht und trotzdem trägt: zeitliche Annahmen. Und am Ende ordnen wir das Ganze in eine Bewertung, aus der eine Reihenfolge folgt.

1:03 Die Übung führt beides zusammen: eine Impact Map und eine Risikomatrix für ein konkretes Vorhaben.

Änderungsziel und betroffener Ablauf

1:10 Beginnen wir mit einem Schritt, der so selbstverständlich klingt, dass er regelmäßig übersprungen wird. Bevor irgendjemand über Dateien redet, muss klar sein, welcher fachliche Ablauf sich eigentlich ändern soll. Warum wird dieser Schritt übersprungen? Weil die technische Frage konkreter wirkt. „Welche Klassen sind betroffen“ fühlt sich nach Arbeit an, „welcher fachliche Ablauf ändert sich“ nach Vorgeplänkel. Tatsächlich ist es umgekehrt.

1:36 Wer den Ablauf benennt, kann ihn im System verfolgen — genau wie in Modul zwei — und dabei feststellen, welche Teile wirklich berührt sind. Die Alternative ist, von der Ordnerstruktur auf Betroffenheit zu schließen. Nähe im Dateisystem und Betroffenheit im Ablauf sind aber zwei völlig verschiedene Dinge, und die Verwechslung ist teuer.

1:56 Der Ertrag dieser Mühe zeigt sich meistens sofort, und zwar in Form einer Überraschung. Der Ablauf führt durch Stellen, die niemand auf der Rechnung hatte: eine nächtliche Verarbeitung, ein Bericht, den einmal im Quartal jemand zieht, eine Schnittstelle zu einem Nachbarsystem. Und ausgerechnet diese Stellen sind die, an denen Änderungen später unangenehm auffallen — weil sie niemand getestet hat und weil sie erst mit Verzögerung sichtbar werden.

2:20 Ein Fehler in der Maske fällt am selben Tag auf. Ein Fehler im Monatslauf fällt am Monatsersten auf, wenn niemand mehr an die Änderung denkt. Der zweite Punkt ist der teuerste und der verbreitetste: Betroffenheit aus der Ordnerstruktur ableiten. Das funktioniert in sauber geschnittenen Systemen ganz gut — und Sie arbeiten hier gerade nicht in einem solchen.

2:40 Der dritte Punkt hat mich selbst schon Zeit gekostet: Berichte und Auswertungen werden nicht als Ablauf wahrgenommen, weil sie niemand bedient. Sie greifen aber auf dieselben Daten zu und brechen genauso. Und der vierte: Wenn Sie den Ablauf an der ersten Schichtgrenze abbrechen, haben Sie den bequemen Teil erkundet und den interessanten ausgelassen.

Statische und dynamische Abhängigkeiten

3:00 Jetzt kommt eine Grenze, die für Bestandssysteme besonders wichtig ist — und die ein Agent nicht sieht, weil er sie prinzipiell nicht sehen kann. Es geht um alles, was erst zur Laufzeit entsteht. Die Suche nach Verwendungsstellen findet zuverlässig, was im Code steht. Sie findet nicht, was zur Laufzeit entsteht: Aufrufe über einen Namen aus einer Konfigurationsdatei, über zusammengesetzte Bezeichner, über Ereignismechanismen, über Reflexion.

3:27 Für ältere Systeme ist das ein ernstes Problem, denn gerade die nutzen solche Mechanismen gern — sie galten lange als elegant. Und jetzt kommt der unangenehme Teil: Ein Agent unterliegt derselben Beschränkung, meldet sein Ergebnis aber als vollständig. Er sagt nicht „soweit ich das im Text sehen kann“. Er sagt „wird an drei Stellen verwendet“.

3:49 Der rote Faden hier ist: Wissen, wo die eigene Blindheit sitzt — und dann etwas dagegenhalten, das anders funktioniert. Schritt eins und zwei sind Bewusstseinsarbeit: Inventarisieren Sie einmal, welche dynamischen Mechanismen dieses System überhaupt nutzt, und denken Sie diese Liste bei jeder Suche mit. Schritt drei ist das eigentliche Werkzeug: Eine laufende Anwendung mit Protokollierung sagt Ihnen, was tatsächlich aufgerufen wird — und das ist eine Beobachtung, keine Analyse.

4:15 Schritt vier und fünf machen aus der Differenz zwischen beiden Mengen eine Aufgabe statt eines Bauchgefühls. Punkt eins ist der Kern: Ein Suchergebnis ist eine Untergrenze, keine vollständige Liste. Wer das einmal verinnerlicht hat, formuliert automatisch vorsichtiger. Punkt drei ist die gefährliche Anwendung davon — Löschungen auf eine rein statische Analyse zu stützen.

4:37 Dazu kommen wir in Modul sechs ausführlich, weil es der Umbau mit der höchsten Irrtumsquote überhaupt ist. Und Punkt vier beschreibt den üblichen Ablauf in der Praxis: Man inventarisiert die dynamischen Mechanismen nach dem ersten Ausfall. Das funktioniert auch — es ist nur die teure Variante.

Verträge und Rückwärtskompatibilität

4:56 Kommen wir zu dem, was nach außen zeigt. Jede Grenze Ihres Systems ist ein Versprechen an jemand anderen — und Versprechen kann man nicht einseitig ändern. Die Liste dieser Grenzen ist länger, als die meisten vermuten. Bei Schnittstellen denkt jeder sofort an einen Vertrag. Bei einem Datenbankschema schon seltener, obwohl vielleicht drei Auswertungen direkt darauf zugreifen.

5:18 Bei einer Exportdatei fast nie. Und bei Fehlermeldungen praktisch niemand — dabei gibt es genügend Nachbarsysteme, die auf den Text einer Fehlermeldung reagieren, weil es damals keinen besseren Weg gab. Die Faustregel lautet: Alles, was Ihr System verlässt, ist potenziell ein Vertrag. Und ob es einer ist, entscheidet nicht Ihre Absicht, sondern die Frage, ob sich jemand darauf verlassen hat.

5:42 Diese Tabelle liest sich am besten von unten nach oben, denn die Überraschung sitzt unten. Dass eine öffentliche Schnittstelle ein Versprechen ist, weiß jeder. Dass jemand den Text Ihrer Fehlermeldung auswertet, weiß niemand — bis es bricht. Das Musterbeispiel ist beim Fahrtenbuch der Monatsexport. Im Code sieht der aus wie ein internes Detail: eine Datei wird geschrieben, fertig.

6:04 In Wirklichkeit liest die Buchhaltung diese Datei seit Jahren in eine Tabelle ein, die eine feste Spaltenreihenfolge erwartet. Eine zusätzliche Spalte in der Mitte ist technisch eine Kleinigkeit und fachlich ein Ausfall. Das ist der methodisch wichtigste Punkt dieses Kapitels, und er begrenzt alles, was ein Agent für Sie tun kann: Wer sich auf ein Format verlässt, steht nicht in Ihrem Quellcode.

6:27 Sie können das Repository beliebig gründlich durchsuchen lassen — die Antwort ist dort nicht enthalten. Sie steht in der Organisation. Deshalb gehört die Frage „wer verlässt sich darauf“ an den Anfang jeder Änderungsanalyse, und sie geht an Menschen: an die Buchhaltung, an den Betrieb, an das Nachbarteam. Genau solche Fragen gehören ins Unknowns Register — sie brauchen Vorlauf.

Daten, Schema und Migrationen

6:49 Jetzt zur Kategorie mit dem schlechtesten Rückweg. Code können Sie zurückrollen. Daten nicht — jedenfalls nicht so einfach. Deshalb verlangt dieser Bereich die größte Sorgfalt, und deshalb hat er sein eigenes Vorgehen. Es gibt einen Satz, den man sich für Bestandsdaten merken sollte: Was das Schema erlaubt, ist irgendwann auch vorgekommen.

7:10 Wenn ein Feld fachlich nie leer sein sollte, technisch aber leer sein darf, dann finden Sie im Bestand garantiert Zeilen, in denen es leer ist — aus einem Import von 2019, aus einer Fehlerbehebung, aus einer Ausnahme, die jemand einmal von Hand eingetragen hat. Ihre Migration muss mit all dem umgehen. Und Sie kennen diese Fälle erst, wenn Sie im echten Datenbestand nachgesehen haben.

7:33 Diese drei Aspekte sind alles Fälle, in denen die Entwicklungsumgebung Sie in Sicherheit wiegt. Die Datenqualität: Ihr Entwicklungsbestand ist sauber, weil er erzeugt wurde — der echte ist es nicht. Die Dauer: Was auf tausend Zeilen Sekunden braucht, kann auf zehn Millionen Zeilen Stunden dauern und dabei die Tabelle sperren, also den Betrieb anhalten.

7:54 Und die Umkehrbarkeit: Eine gelöschte Spalte ist weg, ein überschriebener Wert ist weg. Alle drei haben dieselbe Gegenmaßnahme — vorher am echten Bestand nachsehen statt am eigenen. Der rote Faden dieser fünf Schritte ist: Nie zwei Dinge gleichzeitig ändern. Sie fügen zuerst nur hinzu — das kann nichts kaputt machen, weil niemand das neue Feld kennt.

8:15 Dann schreiben Sie beide Wege, lesen aber noch alt. Dann ziehen Sie die Bestandsdaten nach, im Hintergrund, mit einer messbaren Abdeckung. Dann stellen Sie das Lesen um. Und das Entfernen kommt erst viel später. Jede dieser Phasen ist für sich lauffähig und einzeln zurücknehmbar — genau das ist der Zweck. Wir sehen dieses Muster in Modul sieben als Parallel Change wieder.

Zeitliche Kopplung und Nebenläufigkeit

8:39 Jetzt eine Klasse von Abhängigkeiten, die Sie in keinem Code finden werden, weil sie dort nicht steht. Sie ist unsichtbar, solange sie hält — und produziert Fehler, die man kaum reproduzieren kann, sobald sie bricht. Es geht um Annahmen über Reihenfolge und Zeit. Irgendwann hat jemand gewusst, dass der Monatslauf nach dem Nachtragen der Fahrten läuft — und hat das nicht aufgeschrieben, weil es damals offensichtlich war.

9:03 Der Code funktioniert seitdem korrekt, und zwar nicht wegen einer Vorkehrung, sondern weil die Reihenfolge zufällig stimmt. Solche Annahmen sind komplett unsichtbar, bis jemand sie bricht — zum Beispiel durch eine Parallelisierung, die eigentlich nur schneller machen sollte. Danach haben Sie sporadische Fehler, die sich nicht reproduzieren lassen.

9:23 Drei konkrete Beispiele aus unserem System, und alle drei haben dieselbe Struktur: Etwas setzt etwas anderes voraus, ohne es zu prüfen. Der Monatslauf setzt voraus, dass die Fahrten vollständig sind. Der nächtliche Abgleich setzt voraus, dass er allein läuft. Eine Berechnung setzt voraus, dass zwischen zwei Schritten niemand dazwischenfunkt. Der vierte Punkt ist der praktische: Diese Annahmen brechen nicht von selbst.

9:49 Sie brechen, wenn jemand etwas verbessert — parallelisiert, verschiebt, beschleunigt. Genau das, was in einem Modernisierungsvorhaben ständig passiert. Der erste Punkt ist die Falle: Sie können im Code nach zeitlichen Voraussetzungen suchen, so lange Sie wollen — sie stehen dort nicht. Der zweite beschreibt, was dann in der Praxis geschieht: Sporadische Fehler werden als Umgebungsproblem abgetan, weil sie sich nicht reproduzieren lassen.

10:15 Genau diese Nicht-Reproduzier‐ barkeit ist aber das Erkennungszeichen. Und der letzte Punkt sagt Ihnen, wo die Antwort liegt: bei den Menschen, die den Betrieb kennen. Diese Frage stellen Sie nicht einem Agenten, sondern der Person, die seit acht Jahren die Nachtläufe beobachtet.

Blast Radius und Umkehrbarkeit

10:32 Wir kommen zur Bewertung. Und ich fange mit einer guten Nachricht an: Sie brauchen dafür keine Skala von eins bis fünf und kein Punktesystem. Zwei Fragen ordnen das Risiko besser als jedes Bewertungsverfahren. Die erste Frage: Wie weit reicht der Schaden, wenn es schiefgeht? Betrifft es einen Nutzer, einen Standort, alle, oder auch Nachbarsysteme?

10:53 Die zweite: Wie schnell ist es rückgängig zu machen? Ein Rücksprung auf den vorigen Stand, ein Datenbankrückbau, oder gar nicht? Diese beiden Fragen wirken banal und sind deshalb so brauchbar — man kann sie in jeder Besprechung stellen, ohne ein Verfahren einzuführen. Und aus der Kombination folgt die Vorgehensweise unmittelbar. Sie müssen nicht erst über Prozesse verhandeln.

11:16 Die Logik hinter dieser Tabelle: Die beiden Achsen wirken verschieden. Ein großer Wirkungsbereich verlangt sorgfältige Vorbereitung. Schwere Umkehrbarkeit verlangt Phasen. Wo beides zusammenkommt — unten rechts — brauchen Sie das ganze Programm: Phasen, Freigaben, einen erprobten Rückfallweg. Und der eigentliche Punkt steht in der Fußzeile.

11:37 Der teure Fehler ist nicht, ein zu schweres Verfahren zu wählen. Der teure Fehler ist, ein einziges Verfahren über alles zu legen: Dann werden Kleinigkeiten unnötig aufwendig, und das wirklich Riskante bekommt zu wenig Aufmerksamkeit. Meistens passiert beides gleichzeitig. Der erste Punkt ist der wichtigste und der am leichtesten zu behebende: Umkehrbarkeit annehmen, ohne den Rückweg je gegangen zu sein.

12:02 Ein Rückfallplan, den niemand ausprobiert hat, ist eine Vermutung. Probieren Sie ihn einmal aus, außerhalb des Ernstfalls. Der letzte Punkt ist der subtile: Wenn Sie ein schweres Verfahren über alles legen, wird es nicht befolgt, sondern umgangen — und dann haben Sie gar keine Kontrolle mehr, sondern nur noch das Gefühl davon.

12:20 Das ist schlechter als ein leichtes Verfahren, das tatsächlich gilt.

Risikomatrix aus Kritikalität, Unsicherheit und Testbarkeit

12:25 Zum Abschluss bringen wir alles zusammen. Drei Achsen genügen — und das Ergebnis ist keine Empfehlung, ob Sie etwas tun sollen, sondern eine Reihenfolge, in der Sie es tun. Die gefährlichste Ecke ist die Kombination aus hoher Kritikalität, hoher Unsicherheit und schlechter Testbarkeit. Und jetzt kommt die Pointe: Genau dort sitzt in den meisten Bestandssystemen der Teil, den Sie ändern möchten. Das ist kein Zufall.

12:50 Der Teil ist kritisch, deshalb wurde er über Jahre erweitert. Er wurde erweitert, deshalb ist er unübersichtlich geworden. Er ist unübersichtlich, deshalb hat ihn niemand getestet. Die drei Achsen korrelieren, und deshalb hilft Ihnen die Matrix nicht bei der Frage ob, sondern bei der Frage wann. Was diese drei Achsen auszeichnet: Jede hat eine Frage, die man tatsächlich beantworten kann.

13:13 Kritikalität ist ausdrücklich eine fachliche Größe, keine technische — beim Fahrtenbuch wiegt eine falsche Abrechnung deutlich schwerer als eine unschöne Fahrzeugliste, obwohl der Code beider gleich schlecht sein mag. Bei der Unsicherheit haben Sie sogar eine Zahl: die Einträge im Unknowns Register aus Modul zwei. Und die Testbarkeit ist die Achse, die Sie als Einzige direkt verändern können.

13:35 Genau deshalb steht sie in der Arbeitsreihenfolge an erster Stelle. Hier ist der eigentliche Ertrag der Matrix. Sie sagt nie, dass Sie etwas lassen sollen — sie ordnet. Erst Testbarkeit herstellen, denn ohne die merken Sie Schäden nicht. Dann Unsicherheit senken, indem Sie die offenen Fragen tatsächlich stellen. Und erst dann ändern.

13:56 Schritt vier ist der psychologisch schwierige: Beginnen Sie mit dem Teil, der kritisch, aber gut testbar ist — nicht mit dem, der am meisten wehtut. Und Schritt fünf sagt es deutlich: Kritisch und unsicher zugleich bleibt liegen, bis Schritt eins und zwei dort erledigt sind. Genau das ist der Weg ins nächste Modul.

Übung: Impact Map und Risikomatrix

14:15 In der Übung machen Sie beides: die Analyse selbst und den Vergleich mit einem Agenten. Der interessante Teil ist nicht, wo Sie übereinstimmen — sondern wo nicht, und in welche Richtung. Das Vorhaben klingt nach einer Kleinigkeit: Fahrten sollen auch nach der Freigabe der Monatsabrechnung noch korrigiert werden können. Wenn Sie den Ablauf verfolgen, merken Sie schnell, dass hier fast alles aus diesem Modul zusammenkommt.

14:40 Es berührt Daten, die bereits exportiert wurden — also einen Vertrag nach außen. Es bricht eine zeitliche Annahme, nämlich dass eine freigegebene Abrechnung endgültig ist. Und es wirft die Frage auf, was mit der bereits verschickten Datei geschieht. Genau solche Vorhaben landen im Alltag als Einzeiler im Ticketsystem. Die ersten vier Schritte sind Ihre Analyse, Schritt fünf ist die Gegenprobe. Achten Sie darauf, dass Sie den Agenten erst danach ansetzen — sonst prägt sein Ergebnis Ihres.

15:09 Die Auswertung hat zwei Richtungen, und beide sind lehrreich. Erstens: Was hat er gefunden, das Sie übersehen hatten? Das sind meistens mechanische Dinge, Fundstellen, Verwendungen. Zweitens, und darauf kommt es an: Welche seiner Aussagen halten der Prüfung am Quellcode nicht stand? Das sind meistens die selbstbewusst formulierten Einschätzungen — und genau davor schützt die Belegpflicht aus Modul zwei.