STRATEGIE19. Februar 2018

Hoffnung ist keine Strategie: Der gefährliche Ansatz mit dem einen letzten Mainframe‑Experten

Mainframe-Experte
Peter Monien, TEAM 4MTEAM 4M

Es sind zu wenige Spezialisten verfügbar, die die alten Mainframe Systeme beständig so lange sicher pflegen können, bis diese zugunsten einer güns­ti­ge­ren Al­ter­na­ti­ve ab­ge­schal­tet wer­den. Durch die ste­ti­ge al­ters­be­ding­te Ab­nah­me ver­füg­ba­rer Spe­zia­lis­ten steigt das Ri­si­ko, dass Sys­te­m­aus­fäl­le nicht zü­gig be­ho­ben wer­den kön­nen.

von Peter Monien, TEAM 4M

In vielen Fällen ist nur noch ein Spe­zia­list vor­han­den, der sich mit der Pfle­ge der haus­ei­ge­nen Sys­te­me aus­kennt. Die­ser ist meist An­ge­stell­ter. Hat das Un­ter­neh­men nie­man­den zur Fest­an­stel­lung ge­fun­den, ist er  Fre­e­lan­cer oder wird von ei­nem an­de­ren Un­ter­neh­men über Ar­beit­neh­mer­über­las­sung aus­ge­lie­hen.

Während die IT (aus gutem Grund) in praktisch allen Bereichen einen redundanten Ansatz fährt, wird bei der Pflege der Mainframe Anwendungssoftware die Abhängigkeit von einer Person hingenommen. Dabei sind die damit verbundenen Risiken nicht zu vernachlässigen“

Risiko 1: Ausfälle während des Urlaubs und einer Krankheit oder …

Unternehmen, die Mainframe Systeme einsetzen, sind meistens größer und geben Angestellten einen Jahresurlaub von 30 Tagen. Die meisten Mainframe-Spezialisten sind um die 60. Diese Altersgruppe fällt durchschnittlich betrachtet an ca.  20 Tagen im Jahr wegen Krankheit aus.

Zusammen sind es ca. 50 Arbeitstage im Jahr, die der Spezialist nicht verfügbar ist.“

Das Chance, dass der Spezialist an einem  Tag nicht verfügbar ist, ist ca. 1:5. Die gleichzeitige Besetzung der Wochentage und der Wochenenden durch einen einzigen Angestellten ist ebenfalls problematisch. Tritt ein Systemstillstand zum Anfang des Urlaubs des letzten Spezialisten ein oder wird der letzte Mohikaner für längere Zeit krank, dann kann der Systemstillstand nicht durch diesen behoben werden. Es muss schnell ein externer Spezialist gefunden und engagiert werden, der das System wieder zum Laufen bringt.

Es klingt hart, aber der Extremfall ist der Tod des Spezialisten. Verstirbt dieser, so ist (neben einem lieben Kollegen) auch sein implizites Wissen für das Unternehmen verloren. Wurde durch ihn kein explizites Wissen (Dokumentation) aufgebaut, so fängt der Nachfolger wieder bei Null an.

Autor Peter Monien, TEAM 4M
Peter Monien, 49, ist geschäftsführender Gesellschafter der TEAM 4M. Von 2014 bis 2017 hat er als Vorstand die mit über 500 Mitgliedern größte deutsche deutsche Freelancer Genossenschaft aufgebaut. Davor war er als Key Account und Sales Manager für den Vertrieb von komplexen Produkten und Services in mehreren Unternehmen tätig.

TEAM 4M ist ein auf Mainframe spezialisierter Dienstleister. Neben einem Mainframe-Notfallservice und der Dokumentation von Mainframe Systemen bietet TEAM 4M auch das Outsourcing und die Pflege kompletter Funktionspakete an.

Risiko 2: Der letzte Mainframe-Mohikaner kündigt

Der Stresspegel eines Spezialisten, der ein monolithisches, schlecht dokumentiertes System am Laufen halten muss, steigt bei einem Ausfall schnell auf ein extremes Niveau.“

Die Frustrationstoleranz des Spezialisten muss bei unzureichender Dokumentation sehr gut ausgeprägt sein. Auf der einen Seite muss der Fehler schnell behoben werden. Auf der anderen Seite ist der  Spezialist gezwungen, sich auf der Basis weniger Hinweise als Detektiv zu betätigen und die Spur des Täters aufzunehmen. Teilweise muss er sich wegen der mangelnden Dokumentation an andere Mitarbeiter des Unternehmens wenden, um den Sollzustand des Systems zu verstehen.

Es ist dem Mainframe-Spezialisten nicht zu verdenken, dass er sich wünscht, ein besser strukturiertes System zu warten und eine bessere Dokumentation zu haben. Ist die Situation im Unternehmen zu frustrierend, so kann dieses dazu führen, dass er das Unternehmen verlässt. Ob ein anderes Unternehmen ihm mehr Geld und weniger frustrierende Bedingungen bietet, sich gleich ganz genervt in den Ruhestand verabschiedet oder aber im Lotto gewinnt, ist dabei für das Unternehmen sekundär.

Ist die Kündigung einmal ausgesprochen, wird es schwierig. Selbst ein Sonderbonus, eine Art ‚Schmerzensprämie‘ für den Spezialisten vermag dann nur wenig auszurichten.“

Geht der letzte Experte, so verlässt mit ihm sein implizites Wissen das Unternehmen und muss von seinem Nachfolger neu erarbeitet werden.

Risiko 3: Wird ein Feuerwehrmann verfügbar sein, wenn man ihn braucht?

Da viele Unternehmen das Risiko des Betriebs mit nur einem Spezialisten eingehen und das Angebot an Mainframe-Spezialisten am Markt beständig sinkt, ist vorauszusehen, dass die Anzahl an ‚Feuerwehreinsätzen‘ zunehmen wird.

Dabei ist zu bedenken, dass nur wenige Mainframe-Spezialisten sich für den Job des „Feuerwehrmanns“ eignen bzw. diesen Service überhaupt anbieten. Es ist nicht nach jedermanns Geschmack, sich bewusst in eine Stresssituation zu begeben, in der der Einsatz hoch ist und die zur Verfügung gestellten Hilfen minimal sind.

Der Feuerwehrmann muss ein umfassendes Mainframe-Wissen haben, die Ruhe bewahren und strukturiert nach dem Problem im extrem komplexen und in den meisten Fällen nur minimal dokumentierten System suchen. Die Übertragung der Nervosität seiner Auftraggeber auf ihn darf er nicht zulassen. Diese würde die Effektivität seiner Arbeit massiv gefährden.

Es gibt nicht viele Spezialisten, die diesen extrem hohen Ansprüchen genügen. Ist gerade keiner dieser verfügbar, so ist das Unternehmen gezwungen, einen Spezialisten zu engagieren, der geringere Qualifikationen und nur wenig Erfahrung als Feuerwehrmann hat. Das verlängert in der Regel die Zeit bis zur Problemlösung erheblich.“

Mainframesysteme werden eingesetzt, um Massendaten zu verarbeitet. Fällt ein Mainframesystem aus, so steht ein wichtiger Bereich des Unternehmens still. Abhängig von dem einzelnen System bedeutet ein Tag Stillstand einen Schaden in fünf-, sechs-, sieben- oder sogar achtstelliger Höhe. Das Horrorszenario, dass das System für mehrere Wochen steht,  ist undenkbar. Besonders für die Unternehmen, bei denen ein so langer Ausfall existenzgefährdend ist.

Die (nicht allzu vielfältigen) Alternativen

Die Hoffnung, dass das eigene Unternehmen in den nächsten fünf bis sechs Jahren keiner der oben beschriebenen Szenarien treffen wird, ist nur bedingt tragfähig.  Selbst wenn das eigene System recht stabil ist, sind Fehler und Stillstände nicht komplett auszuschließen.

Aufgrund der damit verbundenen hohen Kosten planen die meisten Unternehmen keine Entflechtung der Mainframe-Monolithen. Dies ist insbesondere dann der Fall, wenn die einzelnen zusammenwirkenden Funktionalitäten so verwoben sind, dass der Monolith nur mit massiven Anstrengungen aufgeteilt werden kann.

Wird das alte Mainframesystem noch bis Auslauf des letzten Vertrags neun Jahre lang „zu Tode gepflegt“? Oder wird es nach einem Parallelbetrieb mit dem neuen Java-basierten System in fünf Jahren abgeschaltet?

Die allgemeine Begeisterung, noch Geld in Systeme zu investieren, die bald abgeschaltet werden, ist nicht sehr hoch. Dies betrifft auch die Dokumentation.“

Die relevanteste Alternative: Verstärkung der Abwehrkräfte

Es geht darum, die Chancen zu erhöhen, das System bei einem eintretenden Stillstand möglichst zügig wieder zum Laufen zu bringen. Die Chancen kann das Unternehmen in einem ersten Schritt verbessern, indem es nicht erst nach einem Ersatz zu suchen beginnt, wenn das System ausgefallen ist.

kgtoh/bigstock.com

Das Unternehmen kann selber die Zeit investieren und eine Datenbank mit Dienstleistern und Freelancern erstellen und diese aktuell halten. Oder es geht über ein auf Mainframe spezialisiertes Unternehmen, das den Kontakt zu diesen Spezialisten hält. Dabei ist aber unbedingt darauf zu achten, dass diese Unternehmen mehr leisten, als jeden anzuschreiben, der COBOL- und DB2- und Versicherungskenntnisse hat. Wie beschrieben ist bei weitem nicht jeder ein guter Feuerwehrmann, der die Grundfähigkeiten beherrscht.

Ein zweiter noch wichtigerer Schritt ist die vorbereitende Verbesserung der Dokumentation.“

Im Idealfall kann sich der sachkundige Experte die Fehlermeldung und ggf. das ABEND-Protokoll ansehen und sich mit Hilfe der Dokumentation schnell orientieren und die richtige Spur aufnehmen. Ist dann auch noch eine gute technische und fachliche Dokumentation vorhanden, so versteht er schnell, wie der Soll-Zustand sein sollte und wie der Ist-Zustand davon abweicht. Er kann sich erheblich schneller mit der Behebung des Problems befassen statt noch lange nach dem Auslöser zu suchen.

Je spärlicher die Dokumentation ist, desto höher sind die Ansprüche an den Experten, den es für eine schnelle Behebung des Störfalls braucht. Ist zum Störfall kein Experte verfügbar, der alle Qualifikationen mitbringt, so wird sich die Zeit bis zum Neustart des Systems erheblich ausdehnen und damit auch die Kosten des Störfalls.

Risiko-Kosten-Matrix Mainframeausfall

Eine ideale Dokumentation kann eine Beschleunigung der Fehlerbehebung um den Faktor 10 – 20 bewirken.

LevelBeschreibung des Dokumentationslevels
0Keine Dokumentation
 

1

Wenig technische und fachliche Dokumentation, kein Bindeglied
evtl. Datenmanager vorhanden mit allen in den einzelnen Programmen verwendeten Variablen
 

2

Notfallbuch für jedes Programm (Beschleunigung um den Faktor 2-4):
Eine strukturierte Beschreibung der Einflussfaktoren und des Ablageorts verbunden mit dem Verweis auf den fachlichen Hintergrund.
 

3

Notfallbuch
+ schlüssige technische und fachliche Dokumentation der Programme mit verbindener Beschreibung inkl. Use Cases vorhanden

Eine nähere Beschreibung der Aufgaben und Inhalte eines Notfallbuchs ist hier zu finden.

Fazit

Unternehmen, die in den nächsten Jahren noch alte monolithische und schlecht dokumentierte Mainframe Programme laufen haben, sollten bald aktiv werden. Noch sind ausreichende Ressourcen am Markt vorhanden, um die Dokumentation nachzuholen und die Zeiten der zukünftig zu erwartenden Systemstillstände erheblich zu verkürzen. Natürlich können die Unternehmen auch einfach hoffen, dass sie keiner der oben beschriebenen Szenarien trifft.

Aber Hoffnung ist eben keine Strategie…

 

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/66085
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (4 Stimmen, Durchschnitt: 5,00 von maximal 5)
Loading...

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

COBOL-Tests für den Mainframe: Code-Tests per ‚Code Coverage‘ vereinfachen

Compuware und SonarSource haben ihre Lösungen integriert: Damit sol­len Main­frame-De­v­Ops-Teams...

Schließen