Legacy-Systeme sind oft die DNA des Unternehmens!

Dass IBM i zwar modern ist, aber als veraltet gilt, hat viele Ursachen. Die Plattform wird oft von Leuten beurteilt, die sie gar nicht richtig kennen. IBM als Hersteller tut zu wenig, um die Vorteile und Alleinstellungsmerkmale von IBM i herauszuarbeiten. Außerdem macht die Konkurrenz IBM i ständig schlecht – und die Verfechter der Plattform sind zu leise und schüchtern. 

Der Hauptgrund dafür, dass die Plattform als veraltet gilt, ist aber wohl eine ihrer größten Stärken: die Stabilität und Langlebigkeit dieser Systemarchitektur. Das „Technology Independent Machine Interface“ (TIMI) sorgt ja dafür, dass auch heute noch S/38-Programme aus den 70er Jahren auf Power10-Hardware ablaufen können, die gleichzeitig als beste Plattform für modernste Software wie SAP S/4 Hana gilt. Denn IBM i (und jede Anwendung auf der Plattform) arbeitet nicht direkt mit der Hardware zusammen, sondern läuft als virtuelle Maschine auf eben diesem TIMI.

Diese stabile, weil zukunftsorientiert gestaltete Architektur hat die Umstellung von S/38 auf die AS/400 und den Wechsel von 48-Bit-CISC-Prozessoren auf 64-Bit-Risc-Prozessoren ebenso abgefedert wie die Zusammenführung der damaligen iSeries mit der Unix-Rechnerfamilie pSeries zum Power-System im Jahr 2007. Das bedeutet im Vergleich zur Windows- oder Unix-Welt einen unglaublichen Investitionsschutz. 

Dies ist ein Artikel aus unserer Print-Ausgabe 5-6/2024. Das kostenfreie E-Paper finden Sie hier.

Diese enorme Stabilität verführt aber auch dazu, nach dem Motto „Never touch a running System“ die bewährten Anwendungen überhaupt nicht zu modernisieren. Das Ergebnis: gute Anwendungen auf einem ultramodernen Server werden auch heute noch mit einem Green-Screen-Terminal bedient. Das mag für Routiniers vielleicht sogar ergonomischer und effizienter sein als die aktuellen GUI- und Web-Oberflächen, wirkt aber altbacken und angestaubt – und ist damit letztlich Wasser auf die Mühlen der Kritiker. Abhilfe schaffen können Modernisierungs-Experten wie Mirco Beck, „Deputy Head of IBM i Software Solutions“ bei PKS Software.

„Realistische Zeitplanung gefragt!“

Herr Beck, Sie sind „Deputy Head of IBM i Software Solutions“ bei PKS Software und leiten seit Jahresbeginn 2023 auch den Standort Hannover. Was sind Ihre Hauptaufgaben?

Mirco Beck: Als Teamleiter am Standort Hannover bin ich aktuell für fünf Software-Entwickler verantwortlich – und darf dieses Team weiter ausbauen! Außerdem bin ich als Projektverantwortlicher für aktuell vier IBM-i-Transformationsprojekte bei unseren Kunden zuständig. Darüber hinaus bin ich der Vertreter für die beiden IBM-i-Bereichsleiter Stephan Urban und Roland Müller. Hier liegt der Schwerpunkt auf der strategischen Planung, Außendarstellung, Pre-Sales-Unterstützung und Ressourcen-Management.

Sie sind ganz offensichtlich kein „Silver Ager“, wie viele sich einen Experten für IBM i und die Midrange-Welt vorstellen. Wie sind Sie zu dieser Server-Plattform gekommen – und was halten Sie davon?

Beck: Um ehrlich zu sein, die genaue Bedeutung des Begriffs „Silver Ager“ musste ich erst nachschlagen. Aber ja, dazu kann ich mich mit Mitte 30 noch nicht zählen, wenn auch die grauen Haare bereits durchkommen. 

Meine ersten Berührungspunkte mit IBM hatte ich in der Versicherungsbranche als Informatikkoordinator für den Mainframe, anschließend als Nutzer und Datenanalyst eines großen deutschen Drogeriemarktes mit Verwendung der IBM i. Hier wechselte ich dann intern in die IT und war als „Product Owner“ und Tester für die logistische Auftragsverwaltung verantwortlich. In dieser Zeit konnte ich hautnah miterleben, wie modern die IBM-i-Plattform ist, wenn die richtigen Architekturen, Visionen und Ideen von IT und Fachbereich gemeinsam verfolgt und priorisiert werden. 

Auch während der Corona-Pandemie blieb das Unternehmen handlungsfähig, da die zentralen Prozesse in Eigenentwicklung auf der IBM i umgesetzt wurden und somit kurzfristig den Gegebenheiten angepasst und erweitert werden konnten. Hier kristallisierte sich ganz klar der Wettbewerbsvorteil einer Eigenentwicklung heraus. 

Was reizt Sie an Legacy-Systemen und dem „Software-Erbe“?

Beck: Hier möchte ich gerne mit dem Frontend beginnen – und da bin ich ganz ehrlich. Ich bin kein Fan des „Green Screens“. Aussagen wie „Im Green Screen bin ich aber viel schneller“ kann ich nicht unterstützen oder nachvollziehen. Ich habe selbst miterlebt, dass die Zeit des reinen Sachbearbeiters, der manuell Aufträge ins System eingibt, nicht mehr der Realität entspricht. Die Plattform ermöglicht es beispielsweise, über ein modernes Frontend validierte Massendaten einzuspielen. 

Die heutigen Sachbearbeiter kontrollieren somit nicht mehr einzelne Buchungen, Artikel oder Aufträge, sondern überwachen das System mit gezielten Anwendungen oder Auswertungen im Zusammenspiel mit BI-Lösungen.

Doch die positiven Aspekte überwiegen deutlich, denn im Endeffekt tragen die sogenannten „Legacy-Systeme“ wesentlich zum Erfolg unserer Kunden bei und sind einer ihrer Wettbewerbsvorteile – sozusagen die DNA des jeweiligen Unternehmens. Diese zum Teil Jahrzehnte alten Anwendungen enthalten die Grundlogiken der Unternehmensprozesse, sind aber leider häufig gar nicht oder schlecht dokumentiert, sodass wir gerne sagen: „die Wahrheit liegt im Code“. 

Bei der Modernisierung und Bearbeitung dieser Prozesse dürfen keinerlei Fehler auftreten. Hier reizt es mich persönlich besonders, unsere Kunden auf dem Weg zu einem neuen System oder bei der Modernisierung des Bestandssystems beratend zur Seite zu stehen.

Spielen denn auch die Hype-Themen der IT – DevSecOps, Low-Code, KI, Blockchain oder Cybersicherheit – eine Rolle in ihrem Berufsalltag?

Beck: Tatsächlich kommen diese Buzzwords natürlich auch in meinen Projekten vor – jedoch, wie das Wort „Hype“ schon sagt, spielen diese in Bezug auf die wirklichen Kernsysteme des Unternehmens, mit denen wir uns befassen, nicht ganz so rasant eine Rolle. 

Natürlich bedenken und beachten wir jedoch die neuen Trends und Möglichkeiten: Sei es die Modernisierung der DevOps-Pipeline mit Tools wie RDi, VS Code oder CMOne, Low-Code-Werkzeuge wie Valence oder die Nutzung von KI im Rahmen der Code-Analyse und -Modernisierung mit eXplain. Nur beim Thema Blockchain muss ich passen: Dieser Trend hat sich unserer Wahrnehmung nach nicht großartig in realen Use-Cases bei den Unternehmen durchgesetzt.

Momentan sind Sie ja auch Leiter von vier Transformationsprojekten, bei denen auf unterschiedliche neue Plattformen umgezogen wird. Gibt es da Gemeinsamkeiten?

Beck: Die Projekte ähneln sich so sehr, wie sie sich zeitgleich auch unterscheiden. Wesentliche Faktoren sind dabei die Größe des Unternehmens sowie der Umfang und die Komplexität der Anwendung. Wer technologische Schulden im Altsystem hat, wird auch schwerer in eine neue Lösung migrieren können.

Was sich aber bei allen Projekten deutlich zeigt: Es braucht eine realistische Zeitplanung! Die Ära, in der man Bestandssysteme noch innerhalb weniger Jahre komplett ablösen und mittels eines Go-Live an einem einzigen Wochenende agieren konnte, sind längst vorbei. Die Kunden realisieren immer mehr, dass es eher Jahrzehnte braucht, um solche Transformationen wirklich erfolgreich zum Abschluss zu bringen. Solche Umstellungen spielen sich oft im Bereich „10 Jahre plus“ ab.

Umso wichtiger ist es, in den Bestandssystemen handlungsfähig zu bleiben, auch hier weiter „Housekeeping“ zu betreiben und sinnvolle Brückenlösungen und -technologien zu implementieren, die in den Jahren der Koexistenz Mehraufwand oder Sollbruchstellen vermeiden und Fehlerketten unterbinden. 

So nutzen wir z.B. bei einem Sanitärgroßhändler aktuell das Produkt-Bundle iOpen, um genau das zu ermöglichen. Denn obwohl der Kunde seit vielen Jahren Richtung SAP marschiert, braucht es aufgrund der weiteren Zeitplanung für die Anwender durchgängige User-Interfaces, Apps und vieles mehr. Ein Code-Freeze im Bestandssystem ist über derart lange Transformationszeiten ja schlicht und ergreifend nicht möglich. Genau das ist unser Kompetenzprofil bei PKS: Wir sichern unseren Kunden die Handlungsfähigkeit ab und begleiten sie während der Transformation mit Manpower, aber auch mit Architektur- und Lösungskompetenz.

Wo sehen Sie größten Unterschiede, etwa bei den Zielen oder bei den Vorgehensweisen?

Beck: Die Ziele sind meist identisch: Der Kunde ist auf dem Weg hin zu einer modernen Anwendungslandschaft, von der er sich Innovationskraft und Zukunftsfähigkeit erwartet.

Meistens werden zuerst die Quick-Wins erzielt und hoch standardisierte Unternehmensprozesse migriert, beispielsweise im Finanzwesen. Erst im Anschluss macht man sich Gedanken über die Kernprozesse und dann kommt der große „Oha“-Effekt. Folgende Punkte kommen dann zum Vorschein:

• Keine oder veraltete Dokumentation vorhanden

• Key-Entwickler gehen demnächst in Rente

• Keine Prozessdokumentation vorhanden

• Welcher Code wird tatsächlich noch verwendet bzw. was muss wirklich noch migriert werden?

• last but not least: Wie erzeuge ich Akzeptanz im Unternehmen für die Umstellung und binde auch den Fachbereich konstruktiv ein?

Am Anfang all dieser Projekte stand ja offenbar nach der IST-Analyse die bewusste Entscheidung gegen eine langfristige Fortführung der vorhandenen Systeme und auch gegen deren Neuentwicklung als komplette Individuallösung. Ähnelten sich die Argumente für die strategische Neuausrichtung in diesen Fällen – oder gab es da Unterschiede?

Beck: Wenn diese Entscheidungen getroffen werden, bevor wir an Bord sind, ähneln sich die grundlegenden Argumente häufig: 

• Verrentung der Bestandsentwickler 

• Keine passenden neuen Entwickler auf dem Markt vorhanden

• Technische Schulden, oftmals auch ein Grund, warum keine neuen Entwickler gefunden werden.

Dabei stellt sich für uns immer die Frage: Sind das wirklich Gründe, die ein millionenschweres und Jahrzehnte dauerndes Ablöseprojekt rechtfertigen - oder gibt es bessere Alternativen? Hierfür bieten wir unser „IBM i Software Assessment“ an, und häufig fällt der Blick dann wesentlich differenzierter aus. 

Aus unserer Sicht ist aktuell eine Best-of-Breed-Lösung, also ein intelligenter und an den Firmenbedürfnissen ausgerichteter Mix aus Eigenentwicklung und Standard-Software, häufig der ideale Weg für die Unternehmen. Dies sowohl aus Risikosicht, aber auch aus Kosten- und Laufzeitgründen. 

Besonders betonen möchte ich an der Stelle, dass dies alles Themen sind, die völlig losgelöst von der IBM i als Hardware-Plattform stehen! Es geht bei uns immer um die Anwendungen, denn die Plattform selbst ist eine der modernsten im Markt – davon muss man also sicher in den meisten Fällen nicht auch noch weg.

Wie leicht oder schwer fällt der Abschied von den „Sonderlocken“, mit denen eine Individualsoftware oder eine stark angepasste Standardsoftware betriebstypische Besonderheiten abbildet? Gibt es auch gute Gründe, die Anpassungen auch in die neue Welt mitzunehmen?

Beck: Diese Frage zielt weniger auf uns als Entwicklungsdienstleister ab als vielmehr auf die Nutzer und das Unternehmen selbst. Aus meiner persönlichen Erfahrung kann ich sagen, dass die vollkommene Standardisierung der Kernprozesse keine Wettbewerbsvorteile erzeugen kann. Gerade die „Sonderlocken“ und „betriebstypischen Besonderheiten“ sind es, welche das jeweilige Unternehmen von seinen Konkurrenten unterscheidet. Auf der anderen Seite muss jedoch abgewogen werden, ob wirklich jede Besonderheit weiterhin Bestand haben muss. Insbesondere aufgrund des Fachkräftemangels in der IT muss hier nochmal genauer überlegt werden, was wünschenswert und was leistbar ist. In jedem Fall muss hier ein Redesign stattfinden, um die zukünftigen Funktionalitäten gemeinsam zwischen IT, Fachbereich und Management zu definieren. Somit ist es ein Zusammenspiel aus der Beurteilung der „Sonderlocken“, der Funktionalität der Standardsoftware und ­notwendigen Updates.

Die Herausforderung ist dabei häufig, in einen konstruktiven Dialog aller relevanten Gruppen im Unternehmen zu gelangen. Dieser Dialog wurde häufig über Jahre nicht wirklich geführt bzw. gepflegt, sodass die Projekte insbesondere zu Beginn auch eine anspruchsvolle kommunikative Herausforderung darstellen – und auch daran ist schon so manches Ablöseprojekt in den vergangenen Jahren gescheitert oder zum Erliegen gekommen. Wir haben zum Glück auch hierfür speziell geschulte Kommunikations- und Change-Berater, die gute Impulse geben können, damit die Weichen von Anfang an gut gestellt sind und alle Kompetenzen des Unternehmens konstruktiv mit einfließen können.

Bei der Ablösung ist die Plattform IBM i ja nicht zwingend gesetzt, sondern es kann ja auch in Richtung Windows oder Linux gehen. Welche Chancen und Risiken sehen Sie in einem Plattformwechsel bei Ablöseprojekten?

Beck: Ich würde noch mal einen Schritt zurückgehen und die Frage stellen: Warum die Power-Plattform verlassen? Das ist ja heute die Betriebsumgebung für IBM i, aber auch für Linux und Unix. Bei Linux-Anwendungen kann man also einfach weiter auf die bewährte, moderne und kostengünstige Plattform setzen und hat zudem für den Zeitraum der Transformation alles in einer Box, was Latenzen und andere plattformübergreifenden Probleme minimiert. Bei Windows muss man sich die Frage stellen, ob diese Plattform strategisch den Anforderungen gerecht werden kann, insbesondere in Bezug auf Security- und Performance-Anforderungen.

Welche Vorteile bringt es denn typischerweise, wenn nach dem Modernisierungsprojekt weiterhin mit der Plattform IBM i gearbeitet wird?

Beck: Die Plattform bringt alles mit, um State oft the Art Individualprogrammierung durchzuführen. Somit können Prozesse gezielt in Zusammenarbeit mit der Fachabteilung neu designt und modernisiert werden. Dies ermöglicht eine sukzessive, aber spürbare Optimierung des Systems für IT und Fachbereich. Die IT kann die Entwicklung modernisieren, wodurch die Überwachung und das Fehlerhandling optimiert werden und der Fachbereich erhält neue Features, um die tägliche Arbeit zu entlasten. 

Was ist zu beachten, wenn bei dem Modernisierungsprojekt auch der Schritt in die Cloud erfolgen soll?

Beck: Auch die IBM-i-Plattform ist ja via Power Virtual Server in der IBM Public Cloud verfügbar. Daneben bietet auch Google mit „Power for Google Cloud“ diese Option an. Und nicht zuletzt betreiben nahezu alle IBM-Infrastrukturpartner private Cloud-Lösungen für die Kunden.

Wichtig beim Schritt in die Cloud ist bei den unternehmenskritischen Anwendungen sicher immer das Thema Performance sowie die Anbindung von Satellitensystemen – das muss man im Rahmen eines „Proof of Concept“ absichern, sonst erlebt man unschöne Überraschungen.

Stichwort Cloud oder Plattformwechsel: Worauf ist zu achten, damit im Zuge der Modernisierung nicht die seit AS/400-Zeiten gewohnten Plattform-Eigenschaften wie Zuverlässigkeit und Sicherheit nicht leiden?

Beck: Bei Nutzung der zuvor genannten Cloud-Optionen ist man da sicher noch ganz gut aufgestellt. Bei einem Plattformwechsel Richtung Windows oder Linux muss man in der Tat häufig in zusätzliche Software-, Hardware- und Monitoring-Komponenten investieren, um die Zuverlässigkeit und Stabilität der heutigen On-Prem-Umgebung abzubilden. 

Welche Vorteile sehen Sie, wenn es den Kunden gelingt, Kauf- und Individual-Software sinnvoll und effizient in Kombination zu nutzen?

Beck: Die Best-of-Breed-Lösung ist heutzutage der Standard, den wir bei Kunden sehen und den wir auch empfehlen. Für viele Unternehmensbereiche gibt es sehr gute Standardlösungen, welche sich problemlos mit den Individualentwicklungen auf der IBM i verbinden lassen. So lassen sich Investitionsschutz vorhandener Software-Assets, limitiert verfügbare Ressourcen und Nutzung von Standards optimal für den Erfolg des Unternehmens nutzen. 

Herr Beck, vielen Dank für das Interview!

Fotograf: Nicholas Veerhoff