Menschen von oben fotografiert, die an einem Tisch sitzen.

adesso Blog

Zurück

Rückblick

Wer kennt sie noch, die alten IBM-3270-Bildschirme aus den 70er Jahren? Die Standardmodelle hatten 24 Zeilen / 80 Zeichen mit grüner Schrift auf schwarzem Hintergrund und orientierten sich an den Lochkarten. Sie wurden auch Terminals genannt. Maus, Zeiger und Grafik gab es nicht. Der Einsatz der Terminals war der Beginn der Dialogverarbeitung in den Fachbereichen und der flächendeckenden sogenannten EDV (elektronischen Datenverarbeitung) bei Versicherungen, Banken, Behörden, Automobilherstellern, Fluggesellschaften und anderen großen Unternehmen. Die Entwicklung von Dialog- und Batch-Anwendungen spielte sich zunächst in Assembler ab, einer sehr maschinennahen Programmiersprache. Später kamen höhere Programmiersprachen wie Cobol oder PL/I hinzu – insbesondere für kaufmännische Anwendungen. Das war der weltweite Durchbruch der IBM Mainframes, die heute noch zahlreich existieren.

Mainframe-Verbreitung

Bei 71 Prozent der Fortune 500 Companies sind Mainframes im Einsatz. Weltweit sind Mainframes in

  • 92 von 100 Banken,
  • 6 von 10 Handelsgesellschaften,
  • 10 von 10 Versicherungsunternehmen,
  • 23 von 25 Airlines und
  • 9 von 10 globalen Krankenkassen im Gebrauch.

In Summe existieren sicherlich fast 10.000 Installationen. Der größte Teil befindet sich in den USA, im deutschsprachigen Raum haben wir circa 150 Installationen. Die Tendenz ist allerdings abnehmend (circa drei bis fünf Prozent pro Jahr), was dazu führt, dass die Mainframe-Entwicklungskosten auf immer weniger Schultern verteilt werden. Die Gründe für den Rückgang sind unterschiedlich: Beispielsweise wurden Datacenter im Rahmen von Unternehmensfusionen konsolidiert beziehungsweise outgesourct oder Unternehmen entscheiden sich für Standardsoftware. Eines ist aber bei allen gleich: Die Babyboomer-Generation, die maßgeblich diese Technologie geprägt hat, wird in den nächsten Jahren in den Ruhestand gehen. Das bedeutet, demografisch gesehen werden 75 Prozent der Mainframe-Skills in den nächsten Jahren den Arbeitsmarkt verlassen und vermutlich wird nur die Hälfte ersetzt werden können (Forrester Research in 2021). Für junge Menschen ist Cobol „oldschool“ und nur Java richtig sexy. Das ist sehr dramatisch, denn viele der heutigen Kernanwendungen basieren noch immer auf dem Code der 70er Jahre. Kein Wunder, denn IBM hat mit jeder neuen Rechner- und Softwaregeneration dafür gesorgt, dass stets eine Aufwärtskompatibilität vorhanden ist. So finden wir heute noch sehr viele Assembler- wie auch immens große Cobol-Programme vor (mehr als 100.000 Lines of Code), die über die Jahre gehärtet sind und ihren Dienst sicherlich sehr effizient und zuverlässig verrichten. Hier reden wir von den sogenannten Legacy-Systemen.

Die Begriffsdefinition eines Legacy-Systems:

Der Begriff Altsystem oder Legacy-System und im engeren Sinne Legacy-Code bezeichnet in der Informatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Das englische Wort „legacy“ („Erbschaft“) ist in diesem Zusammenhang ein weitgehend wertfreier Fachbegriff. Er kann aber umgangssprachlich auch negativ im Sinne einer lästigen „Hinterlassenschaft“ oder „Altlast“ in übertragener Bedeutung verwendet werden.
Wikipedia

Der Trend zu Mainframe-Playern für Hard- und Software

In den letzten Dekaden ist eine Konsolidierung der Mainframe-Player zu beobachten. Gab es einmal Plug Compatible Mainframes (PCM) von Comparex oder Amdahl, finden wir heute nur noch die IBM mit ihren zSeries. Im Bereich Platten-Peripherie sehen wir neben der IBM mit ihrer DS8000-Serie nur noch die HDS und DELL/EMC. Bei den Independent Software Vendors (ISV) sieht es nicht anders aus. Broadcom kauft CA, BMC kauft Compuware und so weiter.

Mergers & Acquisitions in der Tech-Branche sind für die Private Equity & Venture Capital Companies wie Thoma Bravo oder KKR ein lohnendes Geschäft. Dies alles führt zu einer Konzentration auf immer weniger Anbieter und somit zu immer weniger Wettbewerb – und in Teilen zu Monopolstellungen und dem bekannten Vendor-Lock.

Der Wandel und Weckruf

Der Markt hat die Situation erkannt, denn Umfragen diverser Analystinnen und Analysten zeigen, dass eine große Anzahl an Mainframe-Anwenderinnen und -Anwendern Modernisierungsmaßnahmen bereits eingeleitet haben. Studien berichten, dass bis zu 90 Prozent der Unternehmen sich des Themas bereits angenommen haben.

An dieser Stelle möchte ich bei der Mainframe-Modernisierung unterscheiden in:

  • Modernisierung der Mainframe-Entwicklungsumgebung
    • Ziel: ein einheitlicher und agiler Software Development Life Cycle (SDLC)
  • Modernisierung der Mainframe-Applikationen
    • Ziele: Unabhängigkeit durch Ablösung alter Programmiersprachen mit Java und Kostenreduzierung

Modernisierung der Mainframe-Entwicklungsumgebung

Über Dekaden wurde nach dem Wasserfall-Prinzip entwickelt. Die Folge waren lange Entwicklungszyklen in den individuell geschaffenen Umgebungen. Auf der Gegenseite forderten die Fachbereiche zunehmend agile Entwicklungsmethoden mit kurzen Produktzyklen wie aus der „offenen“ Welt. Schatten-IT ist entstanden, indem Fachbereiche schnelle Insellösungen eigenständig aufbauten.

In den letzten Jahren haben Modernisierungsmaßnahmen in dem Bereich Mainframe Development Einzug gehalten. Das 3270 TSO ISPF Interface wird zunehmend um Graphical User Interfaces (GUIs) ergänzt – beispielsweise die Eclipse-basierte Workbench IDz oder Topaz. Klassische mainframebasierte Source-Code-Management(SCM)-Systeme werden durch git oder andere gemeinschaftlich genutzte Repositories ersetzt. IBM zUnit oder BMC Compuware Topaz for Total Test werden schrittweise eingeführt, um Unit- und Functional-Tests mit Mocking-Funktionen zu automatisieren. Die Deploy-Prozesse werden mit Jenkins Pipelines automatisiert. Code Coverage und Quality Gates dienen der Qualitätssicherung. Continuous Integration und/oder Continuous Delivery, DevOps und agile Softwareentwicklung sind somit im Bereich Mainframe angekommen.

Allerdings erfordern der Aufbau und die Umsetzung dieser DevOps Tool Chains viel Kraft, Zeit und eine gute Zusammenarbeit mit den Softwarelieferanten. Diesen Aufwand scheuen viele kleine bis mittelgroße Mainframe-Installationen (< 5.000 MIPS mit weniger als 50 Developern), denn ein ROI ist selten realisierbar. Ältere Entwicklerinnen und Entwickler sind häufig schwer für die DevOps-Welt zu begeistern und entwickeln lieber in ihrer gewohnten und auch für die eigenen Bedürfnisse optimierten 3270-Umgebung (REXX- und Clist-Funktionen).

Modernisierung der Mainframe-Applikationen

Hier sieht die Welt ein wenig vielfältiger aus. Unternehmen haben zahlreiche Möglichkeiten zur Modernisierung ihrer Mainframe-Anwendungen. Zunächst sollte aber klar sein, welche IT-Unternehmensstrategie global verfolgt wird, denn die Modernisierung sollte architekturell passen. Im Bereich Mainframe-Applikationsmodernisierung treffen wir auf unterschiedliche Lösungsansätze.

Code Transformation verfolgt die maschinelle Überführung von existierendem Code nach Java. Die Business-Logik bleibt unverändert. Der adesso transformer basiert auf einer Tool Suite, bestehend aus den Komponenten at|analyze, at|convert, at|edit, at|batch und at|test. Auch refaktorierbarer Code kann durch Anpassung auf kundenindividuelle Wünsche im transformer berücksichtigt werden. Der Vorteil der Code Transformation besteht darin, dass die Migration planbar wird. Testaufwände (Use-Cases) lassen sich auf ein Minimum reduzieren. Festpreismigrationen sind nach belastbarer Analyse die Regel.

Replatforming gibt es in den unterschiedlichsten Ausprägungen und es beruht auf dem Lift-and-Shift-Gedanken. Häufig wird auch der Begriff des Rehostings hierfür verwendet. Hier wird zwischen Lösungen mit und ohne Recompile unterschieden. Bei den Compiler-based Solutions wird im Zuge des Replatformings ein Recompile gemacht und die Applikation in eine Java Virtual Machine (JVM) migriert. Bei der Lösung ohne Recompile werden Applikationen, Laufzeitumgebungen und Daten 1 : 1 maschinell migriert. Das EBCDIC-Mainframe-Format bleibt erhalten. Die Anwendungen werden in einer Art Container binärkompatibel auf Linux/x86-Architekturen on premise oder in die Cloud migriert. Das ist sicherlich interessant, wenn man kurzfristig – etwa aus Kostengründen – die zSeries verlassen möchte. Die Anwendungsmodernisierung erfolgt dann im nächsten Schritt. Diese Technologie wird gerne als „Brückentechnologie“ bezeichnet.

Parallel hierzu gibt es Lösungen, die primär den Bereich der Applikationsentwicklung in eine Client- und/oder Server-Technologie dezentralisieren. Produktion und Betrieb laufen jedoch zunächst weiterhin auf dem Host.

Sicherlich ist auch das traditionelle Outsourcing in gewisser Weise als Replatforming/Rehosting zu bezeichnen, wobei hier allerdings Applikationsmodernisierung nicht im Fokus steht.

Replace verfolgt den Ansatz, dass vorhandene Mainframe-Applikationen durch Standardsoftware ersetzt werden. Am Markt sind zahlreiche Lösungen für unterschiedliche Branchen vorhanden – unter anderem auch von adesso. Häufig können aber nicht alle Mainframe-Applikationen durch Standardsoftware ersetzt werden. Sollte das oberste Ziel jedoch die Abschaltung des Mainframes beinhalten, dann werden für die sogenannten „Restanten“ ergänzende Lösungen wie zum Beispiel die Code Transformation verwendet.

Reengineering oder auch Recoding verfolgt den Ansatz der Neuprogrammierung und Neuordnung der Geschäftsprozesse. Es geht hierbei nicht um die Verbesserung der Wartungsqualität der Software. Hier geht es um das ingenieurmäßige Neugestalten bestehender Systeme, basierend auf modernen Frameworks und Programmiersprachen, mit dem Ziel, die alten Systeme zu ersetzen. Der Ansatz der propagierten bimodalen IT von Gartner wird grundsätzlich verworfen, denn das Hauptziel besteht in der Integration in vorhandene moderne Architekturen.

Es gibt nicht „einfach“ die Migration oder die Ablösung eines Systems – jedes System ist gewachsen, ein Kunstwerk und daher auch mit entsprechender Kunstfertigkeit zu behandeln. Bei adesso transformer sprechen wir daher immer von der hybriden Modernisierung.

Fazit

Die Mainframe-Technologie ist nach wie vor eine moderne und etablierte Plattform. Mit der neuen IBM z16 wurde dies erneut unter Beweis gestellt. Der lange totgesagte Dinosaurier wird noch viele Jahre leben. Allerdings muss jedes Unternehmen für sich selbst entscheiden, wie es den Bedürfnissen der Fachbereiche mit welcher Technologie am besten gerecht wird. Der demografische Wandel und der Ersatz von Mainframe-Skills werden eine zentrale Rolle spielen. Es gibt nicht den „einen“ Königsweg für die Legacy-Anwendungsmodernisierung – es wird immer ein Mix unterschiedlicher Ansätze sein.

Das Thema Mainframe-Modernisierung kann sich allerdings schnell zu einer tickenden Zeitbombe entwickeln. Erfahrungen aus aktuellen Projekten zeigen, dass eine Migration je nach Ausgangssituation mehr als fünf Jahre dauern und im zweistelligen Millionenbereich liegen kann. Bis dahin sind die meisten Babyboomer im Ruhestand und das Wissen ist verloren gegangen.

Meine klare Empfehlung: die eigene Ist-Situation mit Unterstützung von neutralen Expertinnen und Experten sowie entsprechenden Tools analysieren (in welchem Grad liegen „Altlasten“ vor?) und die Ergebnisse nach Bewertung durch die internen Architektinnen und Architekten in die eigene IT-Strategie einfließen lassen.

Wir bieten euch ein vollständiges Beratungs- und Lösungsportfolio. Von der Voranalyse über die Konzeption bis zur Umsetzung. Weitere Informationen zu den Leistungen der adesso transformer sind auf unserer Website zu finden.

Bild Ralf Achcenich

Autor Ralf Achcenich

Ralf Achcenich ist bei der adesso transformer Deutschland GmbH als Senior Business Developer tätig. Er besitzt 40 Jahre Berufserfahrung im Bereich Mainframe. Zunächst auf der Seite des Kunden, dann bei unterschiedlichen Systemintegratoren und IBM-Business-Partnern sowie bei diversen internationalen Hard- und Softwareherstellern. Die Themenschwerpunkte bei seinen letzten Arbeitgebern lagen alle in der Mainframe-Modernisierung.

Diese Seite speichern. Diese Seite entfernen.