DevOps ist als agile Methode zur Software- und Prozessoptimierung in aller Munde. Wie sehen Sie die Entwicklung bei Ihren Kunden?

TOBIAS LEICHER: Viele unserer Großrechner-Kunden mit einer IBM Z haben sich inzwischen dem DevOps-Ansatz gegenüber geöffnet. Das gilt auch für die Banken und Versicherer, auch wenn bei Letzteren die Mühlen immer etwas langsamer mahlen. Man darf ja nicht vergessen, dass hier die Software-Entwicklung über Jahrzehnte hinweg in einer reinen Großrechner-Umgebung stattgefunden hat. Und wir reden hier über signifikante Kernanwendungen wie Zahlungsverkehr und Bestandsverwaltungssysteme, die behutsam angefasst werden müssen. Hinzu kommt: Diese gewachsenen Silos müssen zunächst auch aus den Köpfen der Mitarbeiter verschwinden. Aber: Wir sehen auch in diesen beiden Branchen zunehmend die Planung und Umsetzung von DevOps-Projekten.

DENNIS BEHM: In der Tat muss man sich hier einen längeren Prozess anschauen. Als vor 30 Jahren die heute noch laufenden Mainframe-Programme entwickelt wurden, gab es keine agilen Methoden - kein DevOps und auch noch nicht die Idee von Continuous Integration und Continuous Delivery (CI/CD). Aber die Unternehmens-IT denkt um, denn die heutige Generation der Entwickler ist mit diesen Verfahren geschult und groß geworden.

Junge Entwickler unterstützen

Wie sieht es denn in anderen Branchen aus?

LEICHER: Ähnlich. Wir sehen vor allen Dingen auch in der Automobilindustrie und im Handel ein großes Interesse, mit DevOps-Projekten zu starten. Dieser Trend wird allerdings stark durch den Fachkräftemangel gebremst. Aber überall dort, wo junge Entwickler eingestellt werden, lässt man sie mit den für sie gewohnten Tools und Methoden arbeiten. Setzt sie also nicht gewissermaßen einem "3270-Schock" aus und beschränkt die Lernkurve auf die wichtigen fachlichen Themen, statt auf Tools und Werkzeuge.

BEHM: Ich denke, man wird dem Thema DevOps nicht gerecht, wenn man es nur auf den Plattform-Gedanken reduziert. Nehmen Sie als Beispiel eine Banking-App. Die muss einerseits für die Mobile Device des Konsumenten entwickelt und designed werden, der eigentliche Prozess des Zahlungsverkehrs läuft aber nach wie vor über den Banking-Core auf dem Großrechner. Es geht als darum, die Silos zwischen der Mainframe- und dezentralen Entwicklung aufzulösen.

Die Modernisierung von Legacy-Anwendungen, deren Synchronisation mit cloud-nativen Applikationen und das viel zitierte "Lift & Shift" in die Cloud sind ja seit geraumer Zeit die wichtigsten Themen für Entwickler und IT-Infrastruktur-Verantwortliche. Welchen Beitrag kann DevOps hier leisten?

LEICHER: Grundsätzlich sollte vor einer Migration in die Cloud immer die Frage nach dem gewünschten IT-Betriebsmodell geklärt sein. Und die Grundsatzentscheidung: Will ich möglichst wenig IT im Haus, muss ich noch selbst entwickeln? Wenn ein Unternehmen beispielsweise seine Mainframe-Anwendungen in die Cloud verlagern will, ist dies natürlich möglich.

Man muss sich aber immer fragen, ob die eingesetzten Ressourcen auch einem geschäftlichen Vorteil dienen. Der Aufwand ist insofern entsprechend zu bewerten - auch wenn die IBM hier seit Jahren Innovationen auf die Z-Plattform bringt, die hier helfen. Gleiches gilt für die Entwicklung cloud-nativer Applikationen in einer eigenen dedizierten Umgebung, welche auch auf IBM Z betrieben werden kann. Dies erleichtert den Wechsel von Cobol zu Java und ermöglicht so dann auch den Wechsel auf eine X86-Architektur.

Aber ein "Big Bang"-Ansatz bei der Modernisierung funktioniert nicht. Es geht nur schrittweise, und dabei hilft ein DevOps-Prozess und -Tooling ungemein. Ich empfehle daher meinen Kunden immer die folgende Reihenfolge: Erstens die Prozesse umstellen, dazu gehört insbesondere auch ein automatisiertes Software-Testing. Dann folgt die Umstellung der Programmiersprachen und erst danach sollte man über Containerisierung und Hosting-Konzepte konkret nachdenken.

Ein Repository für alle

Welche Tools unterstützten die Verankerung von DevOps in der Entwicklung?

BEHM: Wichtig für den Erfolg eines DevOps-Ansatzes ist wirklich die Überwindung von Grenzen und Mauern. Und zwar nicht nur bezogen auf Development und Operations, sondern auch zwischen bislang getrennt voneinander arbeitenden Entwicklerteams. Viele unserer Kunden wollen im Übrigen auch bei einer DevOps-Strategie mit ihren bewährten Sprachen weiter entwickeln.

Wichtig in diesem Kontext ist allerdings die Einrichtung eines unternehmensweiten Repositories, in dem alle Artefakte bereitgestellt werden können. Darüber hinaus auch zentrale CI/CD-Pipelines für die unterschiedlichen Anwendungstypen, die manuelle Arbeitsschritte reduzieren und für die Automatisierung von Build, Packing und Deployment sorgen.

Es ist nicht entscheidend, ob etwa mit Cobol oder Java entwickelt wird. Der Entwickler kann wählen, ob er mit einer Eclipse-basierten Entwicklungsumgebung für den Mainframe wie IBM Developer for z/OS arbeitet, oder doch klassisch über ein Terminal. IBM Developer for z/OS bietet darüber hinaus Funktionen für automatisierte Builds in offenen und modernen CI/CD-Pipelines, oder ein Unit Testing Framework für die klassischen Mainframe-Sprachen Cobol und PL/1 und hilft somit bei der technischen Umsetzung von DevOps.

Und man muss noch eines betonen: Dreh- und Angelpunkt für die Gewährleistung von Geschwindigkeit und Stabilität ist CI/CD - also das Prinzip des automatisierten Testens und des kontinuierlichen Rückflusses von Ergebnissen in die laufende Entwicklung.

"Nicht fertig, wenn es funktioniert"

Spielt die klassische Wasserfall-Methode Ihrer Ansicht heutzutage in der Softwareentwicklung noch eine Rolle?

BEHM: Ich kenne kein Unternehmen, dass noch so arbeitet.

LEICHER: Methodisch sicher nicht, da hat sich über die Jahre hinweg doch entscheidendes verändert. Die berühmten Chinese Walls sind ja auch Stück für Stück durchlässiger geworden. Vor allem, weil der Betrieb gesagt hat, ich kann kein Programm einsetzen, wo ich vorab keinen Einfluss auf die Qualität nehmen konnte. Insofern gab es immer schon einen Austausch mit den Entwicklern. DevOps institutionalisiert und professionalisiert diesen Austausch.

Gelegentlich wird dies aber fälschlicherweise so interpretiert, als würde dieser Austausch nun weitgehend automatisiert erfolgen können. Das Gegenteil ist der Fall: Agile Software Entwicklung und DevOps bedeuten nicht unbedingt, dass es schneller und automatisierter wird, sondern dass man ständig in einem strukturierten Prozess miteinander redet. Im Kern geht darum, bei der Softwareentwicklung Flexibilität, Stabilität und Geschwindigkeit in Einklang zu bringen. Und auch heute gilt: Ein Programm ist nicht dann fertig, wenn es funktioniert, sondern wenn es in seiner Funktionsfähigkeit und vor allem Wartbarkeit auf die gesamte zu erwartende Lebensdauer ausgelegt ist. DevOps ist insofern kein Produkt, das man kaufen kann, sondern Bestandteil der Unternehmenskultur. Es geht als nicht in erster Linie um Plattformen und Tools, sondern um das "große und gemeinsame Wollen".