Start/Applikations-Analyse
Applikations-Analyse und Migrationsbewertung z/OS
Ergebnisoffen und rechenbar: Was verbraucht eine Applikation wirklich, wovon hängt sie ab, und wie viel Kosten entfallen tatsächlich, wenn sie geht?
Die Ausgangsfrage
„Migration" ist keine Entscheidung, sondern vier
Für jede Applikation gibt es mehrere sinnvolle Wege. Welcher es ist, hängt von zwei Größen ab, die man messen kann — und die in den meisten Häusern nicht vorliegen.
Retain
Bleiben und modernisieren: Schnittstellen öffnen, Entwicklungsprozesse erneuern, gezielt Verbrauch senken.
Rehost
Lift-and-Shift auf eine andere Plattform. Schnell, aber die technische Schuld zieht mit um.
Refactor
Automatisierte Konvertierung plus Handarbeit. Realistisch sind Konvertierungsquoten deutlich unter 100 %.
Replace / Retire
Standardsoftware oder Stilllegung. Wird regelmäßig unterschätzt und ist oft der wirtschaftlichste Hebel.
Die beiden Größen, die die Entscheidung tragen: der gemessene Ressourcenverbrauch und die Abhängigkeitsstruktur. Ohne die erste ist der Business Case nicht rechenbar, ohne die zweite ist der Migrationsschnitt nicht bestimmbar.
Der Kern
Anteil an der Last ist nicht Anteil an den Kosten
Der intuitive Ansatz — „diese Applikation macht 15 % der CPU-Arbeit, also sparen wir 15 % der Kosten" — ist beim klassischen Sub-Capacity-Modell schlicht falsch.
Entscheidend ist nicht das Volumen, sondern der Beitrag zum monatlichen Peak. Und nach Entfernung einer Applikation setzt oft eine andere Last den neuen Peak: Der Effekt sättigt, er ist nichtlinear. Deshalb rechnen wir iterativ, nicht additiv.
- Verbrauchszeitreihe je Applikation in Intervallgranularität aufbauen
- Kandidat aus der Zeitreihe der Partition subtrahieren
- 4h Rolling Average neu berechnen, Monats-Peak je Maschine neu ermitteln
- Peak-Shifting berücksichtigen und mehrere Kandidaten iterativ durchrechnen
- Zweitrundeneffekte prüfen: Prozessorauslastung, Fremdlizenzen, mögliche Modellreduktion
Zuordnung
Wie wir Verbrauch überhaupt einer Applikation zurechnen
Wer nur die Adressraum-Sicht auswertet, ordnet die gesamte Datenbanklast dem Datenbanksystem zu — statt den Applikationen, die sie verursachen. Das ist ein häufiger und folgenschwerer Fehler.
Applikationsmodell in der Policy
Der methodisch saubere Weg: das Applikationsmodell in den Klassifizierungsregeln abbilden. Dann liegt der Verbrauch je Applikation fortlaufend vor — ohne nachträgliche Rekonstruktion. Der Aufwand ist gering, die Steuerung wird nicht beeinflusst.
Sicht in die Subsysteme
Transaktionsmonitore und Datenbanken liefern Verbrauch je Transaktion und je Zugriffspfad. Erst damit landet die Last bei der verursachenden Applikation statt beim Subsystem.
Nicht zurechenbarer Anteil
Die Summe der applikationsseitig gemessenen CPU-Zeit ist systematisch kleiner als der Gesamtverbrauch der Partition. Ein Verrechnungsmodell muss festlegen, wie dieser Overhead umgelegt wird — sonst summiert sich nichts auf 100 %.
Der bestdokumentierte Warnfall
Bei einer britischen Bank gelang 2018 die Datenmigration technisch — und die neue Plattform versagte anschließend unter Produktionslast. Fünf Millionen Kunden waren betroffen, über 225.000 formale Beschwerden folgten, die Aufsicht verhängte ein Bußgeld von 48 Millionen Pfund; hinzu kamen Entschädigungen von rund 33 Millionen Pfund.
Die Lehre daraus ist keine Warnung vor Migration, sondern eine vor unzureichender Kapazitäts- und Lastvalidierung. Genau die lässt sich vorher rechnen.
Auch das ist ein Ergebnis
Manchmal lautet die Antwort: bleiben und modernisieren
Wir sind nicht dafür da, ein vorher feststehendes Ergebnis zu belegen. Wenn die Zahlen für einen Verbleib auf z/OS sprechen, sagen wir das — und zeigen den Modernisierungspfad, der dann Sinn ergibt.
- Schnittstellen öffnen — bestehende Anwendungen als moderne Dienste bereitstellen, ohne den Kern anzufassen
- Selektives Refactoring statt Gesamtumstellung, priorisiert nach Verbrauch und Änderungsfrequenz
- Verlagerung auf Spezialprozessoren — realistisch bewertet: die Rechnung geht nur bei ausreichender Kapazität auf
- Stilllegen zuerst — ungenutzte Programme und Jobs kosten Wartung, Test und Rechenzeit
Häufige Fragen
Fragen zur Migrationsanalyse
Unsere Applikationen sind in der Policy nicht abgebildet. Geht es trotzdem?
Ja. Wir rekonstruieren die Zuordnung aus Namensmustern, Serviceklassen und der Subsystemsicht und bilden daraus virtuelle Applikationen — inklusive Hinweis auf Doppelzählungen, wo eine Klasse mehreren Applikationen zugeordnet ist. Parallel empfehlen wir, das Modell dauerhaft in den Klassifizierungsregeln zu verankern, damit die Zuordnung künftig ohne Rekonstruktion vorliegt.
Rechnen Sie auch den Zielplattform-Aufwand?
Wir liefern die Ist-Seite: gemessener Verbrauch, Lastprofil, Abhängigkeiten und die tatsächlich entfallenden Plattformkosten. Die Zielplattform-Kalkulation gehört zum jeweiligen Zielarchitekturprojekt — unsere Zahlen sind dessen Eingangsgröße.
Warum nennen Sie keine Erfolgsquoten für Mainframe-Migrationen?
Weil die kursierenden Zahlen sich nicht bis zur Primärquelle belegen lassen. Wir argumentieren lieber mit Mechanismen, die überprüfbar sind, und mit dokumentierten Einzelfällen. Das ist belastbarer als eine eingängige Prozentzahl.
Wie hängt das mit der Kostenanalyse zusammen?
Eng. Die Migrationsanalyse nutzt dieselbe Datenbasis und dieselbe Zeitreihenlogik wie die Performance- und Kostenanalyse. Wenn beides zusammen beauftragt wird, entsteht der Aufwand für die Datenaufbereitung nur einmal.
Bevor Sie entscheiden — messen.
Wir zeigen Ihnen, welche Datenlage Sie bereits haben und was daraus schon heute ableitbar wäre.