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 %.
Anwendungssicht
Was CICS, DB2 und MQ über eine Applikation verraten
Die Partitionssicht sagt, was eine Applikation kostet. Die Subsystemsicht sagt, woraus sie besteht und woran sie hängt — gemessen am laufenden Betrieb statt geschätzt aus dem Quellcode. Dargestellt sind CICS, DB2 und MQ; für IMS und WebSphere gilt dasselbe Vorgehen.
Aus dem Transaktionsmonitor
- Programmsicht statt Transaktionscode — welche Programme laufen wie oft, mit welcher Prozessorzeit je Aufruf. Die gemessene Bausteinliste der Anwendung.
- Zugriffszähler je Transaktion — Datei-, Datenbank- und Messaging-Aufrufe. Eine Transaktion mit vierstelliger Zahl von Datenbankaufrufen ist ein Migrationsrisiko ersten Ranges: Auf einer verteilten Zielplattform wird jede Netzlatenz mit dieser Zahl multipliziert.
- Kopplung zwischen Regionen — der Verkehr zwischen den Regionen zeigt, welche Anwendungsteile faktisch zusammengehören und wo ein Schnitt teuer wird.
- Zugangswege — wie viel Last kommt über klassische Masken, wie viel über Sockets und Dienste. Ein direkter Indikator für Kapselbarkeit.
- Regionsgebundene Zustände — Zwischenspeicher, Zähler und Sperren binden Transaktionen an eine bestimmte Region. Genau diese Bindungen verhindern heute schon Verteilung — und sie verhindern sie auf jeder Zielplattform erneut.
Aus der Datenbank
- Verbrauch je Anwendung statt je Subsystem — wer nur den Adressraum auswertet, schreibt die gesamte Datenbanklast der Datenbank zu statt den Applikationen, die sie auslösen.
- Zugriffsprofil — Lese- gegen Schreiblast, Anteil sequentieller Zugriffe, Commit-Verhalten. Das sagt mehr über die Portierbarkeit aus als jede Zeilenzählung im Code.
- Objektkopplung im Data Sharing — welche Objekte haben Interesse aus mehreren Mitgliedern. Das sind die Nahtstellen, an denen eine Trennung aufwendig wird.
- Sperrkonflikte zwischen Anwendungen — sie zeigen fachliche Kopplung, die im Quellcode nicht sichtbar ist, weil sie erst zur Laufzeit entsteht.
- Anteil auf Spezialprozessoren — wie viel der Datenbanklast heute verlagert läuft. Dieser Anteil verändert die tatsächlich entfallenden Kosten erheblich und wird in Business Cases regelmäßig übersehen.
Aus der Nachrichtenkopplung
- Die Systemgrenzen, die wirklich existieren — jede Warteschlange ist eine gemessene Schnittstelle zwischen zwei Anwendungsteilen. Kein Architekturbild ist so aktuell wie diese Liste.
- Wer stellt ein, wer holt ab — die Richtung des Verkehrs zeigt, welcher Teil Auftraggeber und welcher Auftragnehmer ist. Das entscheidet, welche Seite zuerst umziehen kann.
- Persistent oder nicht — persistente Nachrichten bedeuten Protokollierung, Wiederanlauffähigkeit und harte Zusagen. Sie sind der teuerste Teil einer Migration und der am häufigsten unterschätzte.
- Verkehr nach außen — was über Kanäle das System verlässt, hängt an einem Partner, der nicht mit umzieht. Diese Verbindungen bestimmen den Zeitplan mit.
- Nachrichtengrößen und Spitzen — Durchsatz allein sagt wenig. Erst Größe und zeitliche Verteilung zeigen, welche Bandbreite und welche Zwischenspeicher eine Zielplattform braucht.
Die Subsystemsicht ersetzt keine Quellcode-Analyse. Sie ist deren Gegenprobe: Was im Code zusammenhängt, muss zur Laufzeit nicht teuer sein — und was zur Laufzeit teuer ist, steht selten im Code.
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.