FallstudienFallstudie Dlaufend

Ablösung einer Integrationsplattform

Laufend. Bestand automatisiert erfasst: 99 geplante Prozesse, 1.278 Jobs, rund 8.200 Verarbeitungsschritte mit Abhängigkeitsgraph und Risikoklassen. Erster Prozess migriert und gegen das Original geprüft: 501.546 Zeilen identisch.

Rolle: Verantwortlich für Bestandsaufnahme, Zielbild und Migration
Zeitraum: laufend
Umfeld: Mittelständischer Konzern der Fleischwirtschaft, drei Standorte

geplante Prozesse automatisiert erfasst: 99
Wie gemessen
Maschinell aus der Integrationsplattform ausgelesen, nicht per Befragung.
Jobs im Bestand: 1.278
Wie gemessen
Maschinell aus der Integrationsplattform ausgelesen, mit Abhängigkeitsgraph und Risikoklasse je Prozess.
Verarbeitungsschritte, gerundet: 8.200
Wie gemessen
Maschinell aus der Integrationsplattform ausgelesen und gerundet.
Zeilen im ersten migrierten Prozess, identisch mit dem Original: 501.546
Wie gemessen
Zeilenweiser Vergleich des Ergebnisses des migrierten Prozesses mit dem Ergebnis der alten Plattform: null Abweichungen.

Ausgangslage

Der Konzern betreibt eine Integrationsplattform, die Daten zwischen Systemen bewegt und Verarbeitungen zeitgesteuert ausführt. Sie ist über Jahre gewachsen. Ein vollständiger Überblick über das, was darin läuft und wovon es abhängt, lag nicht vor.

Meine Aufgabe ist die Ablösung. Das Zielbild ist dieselbe Orchestrierung, die in der Datenplattform aus der dritten Fallstudie läuft, auf einer aktuellen Datenbankplattform. Diese Fallstudie steht im Präsens, weil das Vorhaben läuft. Ich beschreibe, was vorliegt, und behaupte nichts, was noch nicht vorliegt.

Entscheidung

Erstens: Bestand automatisiert erfassen, nicht durch Befragung. Ich lese die Plattform maschinell aus. So entsteht ein Bestand, der vollständig ist und sich wiederholen lässt, statt einer Liste aus dem Gedächtnis der Beteiligten.

Zweitens: Risikoklassen vor Reihenfolge. Jeder Prozess bekommt eine Risikoklasse aus seinen Abhängigkeiten und seiner Wirkung. Die Reihenfolge der Migration folgt der Risikoklasse, nicht dem Zuruf.

Drittens: Jeder migrierte Prozess läuft gegen das Original. Ein Prozess gilt erst als abgelöst, wenn sein Ergebnis Zeile für Zeile mit dem Ergebnis der alten Plattform übereinstimmt. Ohne diesen Nachweis wird nichts abgeschaltet.

Umsetzung

Der Bestand ist erfasst: 99 geplante Prozesse, 1.278 Jobs, rund 8.200 Verarbeitungsschritte. Dazu der Abhängigkeitsgraph, der zeigt, welcher Prozess welchen voraussetzt, und die Risikoklassen je Prozess.

Der erste Prozess ist migriert. Ich habe sein Ergebnis gegen das Original geprüft: 501.546 Zeilen, identisch, null Abweichungen.

Die weiteren Prozesse folgen nach Risikoklasse. Jeder durchläuft dieselbe Prüfung gegen das Original, bevor er die alte Plattform ersetzt.

Ergebnis mit Messung

Stand	Wert
Geplante Prozesse erfasst	99
Jobs erfasst	1.278
Verarbeitungsschritte erfasst	rund 8.200
Prozesse migriert und geprüft	erster Prozess
Zeilen im Vergleich mit dem Original	501.546, null Abweichungen

Mehr liegt nicht vor. Ein migrierter Prozess von 99 ist ein Anfang, kein Ergebnis. Was ich belegen kann, ist die Methode: Der Bestand ist vollständig, die Reihenfolge ist begründet, und der Nachweis gegen das Original funktioniert.

Was ich anders machen würde

Den Vergleich gegen das Original als festen Baustein bauen, den jeder Prozess automatisch durchläuft, bevor der erste Prozess migriert wird. Beim ersten Prozess habe ich ihn eigens aufgesetzt. Für die nächsten soll er Teil des Weges sein, nicht Teil der Arbeit.

Den Bestand nicht nur erfassen, sondern von Anfang an mit der Fachseite je Prozess klären, ob er noch gebraucht wird. Ein Prozess, den niemand mehr braucht, wird nicht migriert. Er wird abgeschaltet. Das ist die billigste Migration.

Die Risikoklassen früher gegen die Fachseite prüfen. Meine Klassen kommen aus Abhängigkeiten und Wirkung im System. Die Fachseite weiß, welcher Prozess morgens um sechs jemandem fehlt. Beides zusammen ergibt die richtige Reihenfolge.

Technik

Python
Dagster
SQL Server 2022