Cobol-Modernisierung im Fokus

Sollte die Modernisierung vernachlässigt werden, häufen sich im Laufe der Jahre technische Schulden an, die dann nur noch per Kraftakt aus der Welt geschafft werden können – oder gar eine kostspielige und riskante Ablösung prinzipiell guter, maßgeschneiderter Anwendungssysteme zur Folge haben. 

Die fatalen Folgen mangelhafter Modernisierung sind vielfältig. Die Anwendungen sind dann oft weder in Bedienung noch Betrieb zeitgemäß – und aktuelle Anforderungen aus dem Markt oder des Gesetzgebers sind nur sehr aufwendig umzusetzen. Außerdem wird die Integration mit neuen Anwendungen und Plattformen ebenso diffizil und komplex wie die immer enger werdende digitale Zusammenarbeit mit Kunden, Lieferanten und Partnern, wie etwa Speditionen und anderen Dienstleistern.

Die gute Nachricht lautet: Es gibt am Markt sehr viele Werkzeuge und Methoden, mit denen sich IBM-i-Anwendungen in Eigenregie modernisieren lassen. Und es gibt darüber hinaus auch zahlreiche kompetente Software- und Systemhäuser, die Modernisierung als Dienstleistung anbieten. 

Viele dieser Dienstleister haben wir in der Vergangenheit bereits vorgestellt, etwa Broadcom (CA/Synon), CNX, Fresche, Lansa, Magic, ML, MRC, Profound (Task Force), PKS, Rocket oder die Vogelbusch GmbH. Das Geschäftsumfeld all dieser Anbieter entwickelt sich schnell weiter. KI, die Cloud, „Open Source“ oder auch „Big Data“ verändern die Art und Weise, wie solche Modernisierer arbeiten. Die Technologie auf dem neuesten Stand zu halten und die Zuverlässigkeit zu verbessern, ist daher ein entscheidender Faktor.

Dass gutes Design, verschlankte Prozesse und intuitive Bedienung ausschlaggebende Kriterien sind, ist Konsens. Um all das zu erreichen, will die PKS GmbH neue Wege bahnen – und hat mit iOpen ein UI/UX-Konzept für 5250-Anwendungen vorgestellt. Außerdem kümmern sich die Ravensburger Software-Fachleute nicht nur um die Modernisierung der in der Midrange-Welt populären Programmiersprache RPG, sondern explizit auch um Cobol. Dazu befragten wir Stephan Urban, Head of IBM i Software Solutions bei PKS, in der Banking-Metropole Frankfurt. Dort finden Alt und Neu zusammen – nicht nur im Stadtbild, sondern auch in den Cobol-Landschaften der Banker.

Dies ist ein Artikel aus unserer Print-Ausgabe 7-8/2022. Bestellen Sie ein kostenfreies Probe-Abo.

Cobol, die Sprache für den speziellen Bedarf

Herr Urban, IBM i gilt ja als Domäne für die Programmiersprache RPG. Wie verbreitet ist Cobol im Midrange-Markt?

Stephan Urban: Cobol führt auf der IBM i ein Nischendasein deutlich hinter RPG, CL und Java, ist aber dort laut der aktuellen Umfrage von Helpsystems genauso stark genutzt wie das populäre Node.js und liegt nur knapp hinter PHP und Python. C#/C++, Ruby, Perl und andere Sprachen können mit Cobol auf IBM i nicht mithalten.

Häufig trifft man auf Cobol-Applikationen im Bereich der Finanzinformatik. Aber auch bei Zeiterfassungssystemen oder in der Logistik ist Cobol anzutreffen. Es gibt außerdem immer noch einige Low-Code-Generatoren, die Cobol-Programme erzeugen. Auch viele unserer RPG-Kunden nutzen innerhalb ihrer Anwendungen seit jeher Cobol für den speziellen Bedarf.

Was sind die typischen Einsatz-Szenarien für Cobol auf IBM i? Oder anders gefragt: Wofür eignet sich Cobol besser als RPG?

Urban: Cobol ist eine sehr einfache, wenig technische Programmiersprache. Die Sprache ist leicht zu lernen und wurde schon zu Beginn der IT von Quereinsteigern verwendet, die eigentlich aus dem Fachbereich kommen. Von Personen also, die einen hohen fachlichen Bezug zu dem haben, was sie in Software gießen. Keine schlechten Voraussetzungen, damit der Endanwender das bekommt, was er braucht. So war es bei mir übrigens auch: ich bin nach einer Bankausbildung zum Software-Entwickler geworden.

Die Verwendung von Cobol liegt schon im Namen selbst begründet: COmmon Business Oriented Language. Der Fokus beim Einsatz von Cobol lag und liegt also auf der Bereitstellung von Software-Funktionalität, um die Anforderungen des Business zu bedienen. Das ist ein Unterschied zu RPG, was ja für Report Program Generator steht, der am weitesten verbreiteten Sprache auf der Plattform IBM i. RPG war ursprünglich eher dafür gedacht, vorhandene Daten in Form von sinnvoll aufgebauten Berichten aufzubereiten, um für die Anwender eine einheitlich strukturierte Darstellung von Inhalten aus Datenbeständen auf Papier oder in beliebiger elektronischer Form (Bildschirminhalt, PDF ,…) bereitzustellen.

Cobol eignet sich dagegen nach wie vor hervorragend für Anwendungsentwicklung im business-orientierten Umfeld, vor allen Dingen im Finanzbereich.

Sind lupenreine Cobol-Umgebungen die Regel auf IBM i? Oder gibt es eher heterogene Umgebungen – mit RPG, Java, PHP oder auch C/C++?

Urban: In der Regel findet man im Umfeld von Cobol-Anwendungen immer auch Teile, die in anderen Sprachen geschrieben sind. So ist Cobol z. B. die falsche Wahl für eine Prüfung gegen Embargo-Listen, weil diese sehr komplex sind und u.a. Varianzen beinhalten müssen. Dafür eignen sich andere Sprachen – und mittlerweile auch schon verfügbare KI-basierte Systeme – deutlich besser. 

Auch das Parsen von XML/JSON ist in Cobol mühsam. Sehr gut dafür eignen sich dagegen die integrierten Funktionen der Db2 oder auch andere Programmiersprachen, wie z.B. Java. Ebenso werden Cobol-Anwendungen bei der Arbeit mit Schnittstellen und auch der Anbindung an moderne Benutzeroberflächen in aller Regel mit anderen Sprachen kombiniert.

In jedem Fall finden wir Cobol heute aber auch immer wieder integriert in RPG-Anwendungen, falls typischerweise sehr spezifische, fachbezogene Lösungen mit Cobol umgesetzt wurden und bis heute ihre guten Dienste leisten.

Sie leiten bei PKS das „Cobol Survival“-Team für IBM i. Das hört sich ja erst einmal bedrohlich an. Wie ist es um die Zukunft dieses Teams bestellt?

Urban: Das Cobol-Survival-Team besteht aus knapp einem Dutzend Kollegen, mit teils jahrzehntelanger Erfahrung. Wir haben aber auch sehr junge Kollegen mit Mitte/Ende 20, die sich nach der Ausbildung zum Fachinformatiker für Cobol begeistert haben. Das ist sicherlich (noch?) die Ausnahme und gleichzeitig das größte Problem im Markt. 

Aus diesem Grund haben wir intern eine Initiative ins Leben gerufen, damit all unsere Auszubildenden im IBM-i-Bereich bereits ab dem zweiten Lehrjahr auch Cobol lernen. So stellen wir sicher, zukünftigen Bedarf in diesem Bereich abdecken zu können. Denn diesen wachsenden Bedarf nehmen wir aktuell massiv war: Die Anwendungen, die bis heute in Cobol implementiert laufen, haben einen hohen Nutzwert für die Unternehmen und können nicht so einfach abgelöst werden. Somit sind die Unternehmen darauf angewiesen, den Lebenszyklus dieser Systeme abzusichern, bis klar ist, wohin die Reise geht. Und genau hier unterstützen wir seitens PKS mit dem dedizierten Cobol-Survival-Team. Wir wollen verhindern, dass Unternehmen mit ihren Cobol-Anwendungen plötzlich im Regen stehen.

Was sind die wichtigsten Ursachen dafür, dass Cobol auf dem Midrange-Server eine gefährdete Spezies ist?

Urban: Der fehlende Nachwuchs aufgrund geburtenschwacher Jahrgänge generell in Kombination mit der derzeit laufenden Verrentung der bisherigen Systemkenner. Hinzu kommt das bei jungen Entwicklern wenig populäre Image von Cobol. Das sind in meinen Augen die Hauptgründe.

Noch bis kurz nach der Jahrtausendwende war es gang und gäbe, IT-affine Kollegen aus dem Fachbereich als Quereinstiger in die Anwendungsentwicklung zu ziehen, weil schon damals in diesem Bereich mit dem Fachkräftemangel gekämpft wurde. Eine Sprache wie Cobol bot bzw. bietet sich gerade für Quereinsteiger mit Fach-Knowhow optimal an, weil sie leicht zu lernen und der Code dank seiner „sprechenden“ Befehle gut zu lesen ist. Die eigentliche Herausforderung bei der Entwicklung von Fachanwendungen liegt ja nicht in der Programmiersprache und technischen Themen, sondern darin, die fachlichen Anforderungen wirklich zu verstehen und gut strukturiert im Code umzusetzen.

Was unterscheidet das von der Situation auf anderen Plattformen. Beispielsweise war ja davon zu hören, dass Cobol-Rentner reaktiviert werden mussten, um während Corona wichtige Anwendungssysteme schnell genug anpassen zu können, z.B. an Gesetzesänderungen…

Urban: Die Situation im Software-Entwicklungsumfeld ist aktuell auf allen Plattformen nahezu gleich: Gute Entwickler, und die Betonung liegt hier auf fachlich versiert, kommunikativ kompetent und technologisch breit aufgestellt, sind schwer zu finden – und kaum ein Entwickler hat sich all diese Fähigkeiten schon von Jugend an angeeignet. Wir bei der PKS haben zum Glück zahlreiche gute Entwickler, aber leider aufgrund der hohen Nachfrage im Markt immer noch zu wenige – obwohl das Team inzwischen auf über 35 Personen angewachsen ist. Daher bilden wir auch weiterhin jedes Jahr aus und setzen gern auch auf Quereinsteiger. 

Backend-Programmierung erscheint jungen Leuten zunächst einmal oft nicht so attraktiv wie Frontend-Entwicklung. Erschwerend kommt hinzu: IBM ist bei Studenten und Auszubildenden häufig leider nicht so bekannt wie Microsoft oder Google. Demzufolge sind auch die beiden traditionellen Programmiersprachen Cobol und RPG beim Nachwuchs häufig völlig unbekannt, zumal sie weder in der Universität noch bei der Ausbildung zum Fachinformatiker gesetzte Themen sind. 

Viele Anwenderunternehmen haben zudem die Lebensdauer ihrer Cobol-Kernsysteme massiv unterschätzt und sich demzufolge zu wenig um den Aufbau von Nachwuchskräften gekümmert. Die Rechnung kassieren sie jetzt: Die Teams sind ausgeblutet und überaltert; oft bleibt nur noch die Möglichkeit, die bisherigen Cobol- und RPG-Entwickler so lange wie möglich zu halten, auch über den Ruhestand hinaus. Solch eine Personalpolitik ist bei geschäftskritischen Anwendungen nicht ideal – und gerade im regulierten Umfeld von Finanzinstituten, Behörden usw. häufig auch mit der Gefahr hoher Strafen für die verantwortlichen Manager verbunden.

Was können Sie und Ihr Team dazu beitragen, dass bewährte Cobol-Anwendungen auf IBM i wieder langfristig gute Zukunftsaussichten erhalten? Welche Vorteile hat der IT-Chef davon?

Urban: Wir betrachten Anwendungen auf der IBM i, unabhängig von der Sprache, ganzheitlich und immer mit einem Blick auf aktuelle Technologie- und Architekturstandards. Modernisierung gewachsener Code-Strukturen steht dabei ebenfalls im Fokus. Cobol und Modernisierung schließen sich ja überhaupt nicht aus. Cobol ist zwar schon 60 Jahre alt und der heutige Cobol-Standard auf IBM i mag bereits 1985 fixiert worden sein: Trotzdem bietet IBM die Möglichkeit, das ILE-Konzept zu nutzen, Embedded SQL zu verwenden und über SQL oder IWS/AXISC-basierte Webservices bereitzustellen bzw. zu konsumieren. 

Die Möglichkeiten sind hier leider nicht ganz so weitreichend wie bei RPG. Wir stellen jedoch immer wieder fest, dass bei Anwendungen, die vor 20 oder 30 Jahren entwickelt wurden, nicht in Modernisierung geschweige denn in House-Keeping investiert worden ist. Und selbst seit langem verfügbare Möglichkeiten, wie z.B. das ILE-Konzept, Embedded SQL oder die intensive Nutzung des modernen (bei IBM i integrierten) Datenbank-Managementsystems Db2 werden oft nicht genutzt.

Das zeigen wir auch in Software-Assessments und Health-Checks auf und geben unseren Kunden konkrete Handlungsempfehlungen, wie die Anwendung fit für die Zukunft gemacht werden kann. Für den IT-Chef hat das den primären Vorteil, in Zeiten knapper Personalressourcen das Rad nicht komplett neu erfinden zu müssen, sondern durch gezielte Wiederverwendung bewährter Cobol-Assets, die verstanden werden und unter Kontrolle sind, viel schneller als auf anderen Wegen neue Anwendungen und Front-Ends für die Anwender – intern wie extern – bereitstellen zu können. Das spart zum einen natürlich Geld, macht aber durch den aktuellen „War for Talents“ noch mehr Sinn und ist fast schon unumgängliche Notwendigkeit.

Wie gehen Sie dabei vor? 

Urban: Die IBM macht es den Entwicklern auf der IBM i sehr leicht, unterschiedliche Programmiersprachen – egal ob RPG und Cobol oder Cobol und Java – zu kombinieren: Schon Mitte der 90er Jahre wurde dazu mit dem „Integrated Language Environment“ (ILE) eine mächtige Weiterentwicklung der vorhandenen Programmiersprachen auf der IBM i bereitgestellt. Damit waren auch schon die Weichen in Richtung einer modularen Programmierung gestellt, bei der es kein Problem ist, verschiedene Programmiersprachen miteinander zu mischen.

Wir finden heute bei unseren Kunden recht oft einen Mix aus Cobol und RPG. Hier ist lediglich dann darauf zu achten, dass das klassische OPM – das „Original Program Model“– nicht mit dem ILE-Konzept vermengt wird. Außerdem ist bei einer Mischung aus OPM und ILE sehr genau auf technische Aspekte zu achten, weswegen wir von einer Vermischung abraten. 

Immer häufiger treffen wir auch auf Programmteile, die in Java entwickelt wurden. Auch wenn hier die nahtlose Integration wie zwischen Cobol und RPG nicht „out of the box“ gegeben ist, funktioniert diese Integration hervorragend, z.B. über Systemobjekte oder die Datenbank. Diese Art der Integration zwingt gleichzeitig auch zu Schichtentrennung und Service-Orientierung, was zu einer besseren Anwendungsarchitektur und einfacheren Wartbarkeit führt. 

Cobol ist ja seit 60 Jahren standardisiert. Wie einfach oder schwierig ist es, Cobol-Programme von anderen Plattformen auf IBM i zu portieren – oder den umgekehrten Weg zu beschreiten?

Urban: Natürlich gibt es Rehosting-Tools weg von der IBM-i-Plattform schon genauso lange wie es die IBM i selbst gibt. Fakt ist, dass solch ein Schritt wenig an wirklicher Innovation bringt und sich daher aus Business-Sicht nur in sehr seltenen Fällen lohnt. Und unserer Erfahrung nach wird dann die Modernisierung eben auf der Zielplattform fortgesetzt bzw. begonnen. Ich habe also zunächst Kosten für das reine „Lift & Shift“ und danach zusätzlich die Aufwände der Modernisierung. Aus meiner Sicht ist das nicht wirklich sinnvoll.

Unterstützen Sie mit Ihrem Ihrem Team auch das Re-Development von Cobol-Anwendungen? 

Urban: Ja, selbstverständlich! Wenn es Sinn macht, Anwendungen in Cobol zu implementieren, machen wir das. Es gibt heute so viele Technologien und Programmiersprachen im Markt. Die große Kunst ist es, die für den jeweiligen Anwendungsfall und das verfügbare Entwicklerteam optimale Sprache auszuwählen. Dazu müssen die verantwortlichen Architekten sich aber eben auch mit den Stärken und Schwächen der einzelnen Sprachen und Frameworks auskennen, um nicht alten Wein in neuen Schläuchen zu produzieren oder gar nur um der Technologie willen hohe Transferkosten und operative Risiken in Kauf zu nehmen.

Gibt es Ihrer Erfahrung nach Projekte, Cobol-Anwendungen „in die Cloud“ zu migrieren? Falls ja: Worauf ist dabei besonders zu achten, damit das auch klappt?

Urban: Aus meiner Erfahrung heraus gibt es bei einigen Unternehmen aktuelle Bestrebungen, Cobol-Anwendungen mit der Cloud zu verbinden. Dabei ergeben sich einige technische Herausforderungen, da Cobol als prozedurale Sprache ein völlig anderes Konzept verfolgt als es eine native Cloud-Architektur verlangt. Hier bietet sich z.B. ein gutes API-Management an, mit dem die Schnittstelle zwischen der Cobol-Anwendung und den Cloud-Diensten erfolgen kann. 

Der Betrieb einer Cobol-Anwendung auf IBM-i-Systemen, die in der Cloud betrieben werden, ist hingegen überhaupt kein Problem. Das wird ja längst von Managed-Service-Providern im Rahmen ihrer Private-Cloud-Offerings angeboten. Von emulierten IBM-i-Systemen, die große Cloud-Provider in den letzten Jahren vermehrt anbieten, raten wir aktuell ab. Hier sind alle uns bekannten Proof-of-Concepts bisher gescheitert. Spannend sind aktuell die Bemühungen seitens der IBM, über Power-Systems-Virtual-Server für Kunden den Weg in die Hybrid-Cloud zu ebnen.

Sind die modernisierten Cobol-Anwendungen auch überlebensfähig in künftigen IT-Welten, in denen vielleicht Technologien wie Container, Web- und Mikroservices sowie Rest-APIs gefragt sind – oder auch Methoden wie Dev-Ops und agile Software-Entwicklung?

Urban: Ja, absolut! Ich sehe der Zukunft aus dieser Fragestellung heraus sehr gelassen entgegen. Besonders bei der Anbindung von Cobol mit Webservices, sei es Rest, Soap oder XML, gibt es mit Cobol keine Probleme. Cobol-Programme können Webservices über IWS, AXISC oder über die Datenbank bedienen. Hier liegt die Wahl der Methode lediglich bei der Frage nach der Performance. Die Implementierung über die Datenbank ist bequem, aber nicht hoch performant. Bei großer Last bieten sich eher IWS und AXISC an. Eine weitere propagierte Möglichkeit ist selbstverständlich die Implementierung über Java oder RPG.

Auch bei Dev-Ops und agiler Software-Entwicklung sehe ich mit Cobol keinerlei Probleme, da insbesondere auch auf den systemkritischen Mainframe-Umgebungen Cobol nach wie vor die wichtigste Programmiersprache ist. Deshalb wird sowohl die Sprache selbst weiterentwickelt als auch der Kontext zu ihrer Nutzung in neuen Modellen, Frameworks und Konzepten. 

Herr Urban, vielen Dank für das Interview!