Der common-Vorsitzende Burkhard Fertig beschrieb in einem Beitrag für die „common-News“ den modernen IT-Leiter als „Business Enabler“. Damit trifft er es wohl sehr anschaulich auf den Punkt, wie sich die Rolle des IT-Leiters gewandelt hat. Heute werden nicht mehr nur die Anwendungen verwaltet, sondern es ist die IT ins Herz der Unternehmen gerückt. Dort, wo Geld verdient wird, steht sie inzwischen an vorderster Front, und ihr Funktionieren – oder auch Nichtfunktionieren – entscheidet mit über das Wohl und Wehe der Firma. Die IT „enabled“ Unternehmen.

Organisationen, die sich auf das System IBM i und die darauf laufenden, erprobten, zuverlässigen Anwendungen verlassen, sind immer gut damit gefahren.

Warum sollte sich das ändern? Um diese Frage beantworten zu können, lohnt es sich, einen Blick auf die Änderungen zu werfen, die im IT-Umfeld stattgefunden haben. Sicher, es gibt vermutlich kaum ein anderes Feld mit mehr Veränderungen als die IT. Im Bereich AS/400 – IBM i“ können jedoch fünf zentrale Punkte genannt werden, die die Art und Weise, wie gearbeitet wird, dramatisch verändern:

1. Keine IBM i ist mehr eine Insel. Die Zeiten von Twinax sind lange vorbei. IBM-i-Systeme sind nicht nur physisch in große Netzwerke eingebunden, nein, auch die Anwendungen arbeiten mit anderen Programmen auf anderen Plattformen zusammen. Diese anderen Programme können lokale Client-Programme, über das Internet angebundene SOAP-Anwendungen oder Anwendungen in einer wie auch immer gearteten Cloud sein. Wenn es früher reichte zu sagen: „Meine Anwendung läuft unter Version 5.4“, so muss heute mindestens der Technology-Refresh-Level mitgegeben werden. Und spätestens dann, wenn die Benutzeroberfläche mit einer Web-Anwendung aufpoliert wird, sind auch die verschiedenen Versionen und Patch-Level von Java, des Web Server- und des Application Server an der Reihe. Damit werden komplexe Zusammenhänge zwischen den verschiedenen Komponenten bzw. Artefakten erhalten, die weit über die Querbezüge von Programmen sowie Bildschirm- und Druckerdateien hinausgehen. Die bewährten Anwendungsentwicklungswerkzeuge auf IBM i – PDM, SEU und SDA – sind in diesem Umfeld nicht mehr hinreichend.

2. Die Schlagzahl geht nach oben. Dies ist wohl der für alle Beteiligten spürbarste Effekt der digitalen Transformation. Und zwar für die Entwickler, die permanent mit der Überarbeitung der Anwendungen beschäftigt sind, oft auch auf Kosten der Sorgfalt oder zumindest der Dokumentation. Und auch für die Tester und Qualitätssicherer, weil sie sich der Flut von Änderungen ausgesetzt sehen, die alle „am besten gestern“ in Produktion genommen werden sollten. Aber auch für die Anwender, die sich viel zu häufig mit unerwartetem Verhalten ihrer Software auseinandersetzen müssen. Das tägliche Deployment von Programmänderungen ist inzwischen alltäglich geworden.

3. Jede Firma ist eine Softwarefirma. Dieser Satz soll deutlich machen, wie stark inzwischen alle Organisationen vom reibungslosen Funktionieren ihrer IT abhängig sind. Ein Ausfall von Anwendungen kann heutzutage nicht mehr von den Benutzern dadurch ausgeglichen werden, dass sie einige Stunden Ablage machen. Er kostet Geld und in vielen Fällen auch Kunden. Deshalb sind die Sicherheit und die Verlässlichkeit der Programmänderungen von enormer Wichtigkeit – auch und gerade angesichts der hohen Schlagzahl dieser Änderungen. Damit rückt die Geschwindigkeit, mit der fertige Programme getestet werden können – also das automatisierte Testen –, in den Mittelpunkt jeder IT-Strategie.

4. Der Generationenwechsel. Der Mangel an Nachwuchs wird seit einiger Zeit allerorten beklagt. Für das IBM-i-Umfeld bedeutet dies nicht nur, dass dringend neue Leute für die Systemverwaltung (Operatoren) benötigt werden, sondern auch, dass das Know-how bei der Anwendungsentwicklung – der Programmierung in RPG – an die neue Generation weitergegeben werden muss. Das Hauptproblem hierbei ist, dass mit RPG enorm effizient programmiert werden kann – allerdings nur mit dem sehr wichtigen Nachsatz: wenn das schon einige Jahre getan wurde. Wer diese jahrelange Erfahrung nicht hat, tut sich zum Teil extrem schwer. Durch dieses Dilemma rückt die Frage nach der Programmiersprache in den Mittelpunkt. Einfach global alle Programme durch eine andere Programmiersprache zu ersetzen, mit der die junge Entwicklergeneration vertraut ist, ist nicht unbedingt die optimale Strategie. Alle Projekte dieser Art machen in puncto Termin- und Budgettreue sogar der Hamburger Elbphilharmonie Konkurrenz. Die Lösung des Generationenwechsels muss daher anders aussehen.

5. Basel II & Co. kosten Geld – wenn sie nicht erfüllt werden. Die „Compliance“ ist in angelsächsischen Ländern bereits seit vielen Jahren ein wichtiges IT-Thema. Hierzulande ist es in vielen Bereichen noch nicht so wichtig, gegenüber Behörden oder Zertifizierungsorganisationen zu beweisen, dass eine nachhaltige Strategie und Architektur bei der Anwendungsentwicklung existiert. Die Basel-Regelungen zeigen aber, dass auch hier der Zug in diese Richtung läuft und dass es sinnvoll ist, die Anwendungsentwicklung zu formalisieren und zu dokumentieren. Es ist nicht anzunehmen, dass diese Entwicklung im Laufe der Zeit nachlässt.

Diese fünf Punkte machen deutlich, dass es Zeit wird, von vielen bewährten Traditionen Abschied zu nehmen. Die Entwicklungsumgebung, bestehend aus PDM, SEU und SDA, hat 30 Jahre lang gute Dienste erwiesen, war effizient und zuverlässig. Doch den modernen Multiplattformarchitekturen kann sie nicht mehr gerecht werden. Sie durch den natürlichen Nachfolger RDi zu ersetzen, ist unumgänglich. Immerhin ist RDi auch schon lange seinen Kinderschuhen entwachsen und inzwischen eine reife, verlässliche Anwendungsentwicklungsumgebung.

Doch RDi alleine reicht nicht. Es fehlen die so wichtigen Komponenten des automatisierten Testens und der intelligenten Verteilung auf den verschiedenen Plattformen.

Hierfür gibt es eine Reihe von reifen, nachhaltig eingeführten Produkten, die sich bei guter Planung sogar „unter rollendem Rad“ einführen lassen. Sie alle steigern die Produktivität der Entwickler/innen vom ersten Tag an zu mindestens 30 Prozent.

Diese Produkte tragen verschiedene Gattungsnamen, zum Beispiel Change Management (CM), Application Lifecycle Management (ALM) und neuerdings Continuous Integration/Continuous Deployment (CI/CD) oder Application Release Automation (ARA).

Unter ihnen sticht das favorisierte Produkt der Firma ARCAD, das ARCAD Pack for DevOps, dadurch hervor, dass es alle Teile integriert hat und mit den modernen Source-Code-Management- und Deployment-Tools, wie zum Beispiel git, Subversion und Jenkins, zusammenarbeitet. Letzteres bekommt im Lichte des Generationenwechsels eine ganz besondere Wichtigkeit. Junge Programmierer/innen sind den Umgang mit diesen Produkten gewöhnt und würden es bedauern, wenn sie sie auf ihrer Arbeitsstelle nicht vorfänden.

Selbst dann, wenn geplant wird, seine Eigenentwicklung durch irgendetwas anderes zu ersetzen, ist der Wechsel zu einem modernen Entwicklungs-Tool wie dem ARCAD Pack for DevOps wohl unverzichtbar. Denn erfahrungsgemäß dauern solche Wechsel mehrere Jahre, und in dieser Zeit des Übergangs können die Wünsche von Anwendern, Kunden oder Lieferanten nicht ignoriert werden. Denn die Aufgabe, das Business zu „enablen“, kann nicht für ein paar Monate – oder Jahre – abgeschaltet werden.

Modernisierung

In den letzten 20 Jahren wurde unter dem Begriff „Modernisierung auf IBM i“ vorrangig die Einführung einer grafischen Benutzeroberfläche verstanden. Besonders gut war diese dann, wenn sie an den Programmen und der Arbeitsweise der Entwickler möglichst wenige Änderungen erforderte.

Dies sieht heute anders aus. In der Zeit der agilen Entwicklung ist die zeichenorientierte Benutzeroberfläche zwar nach wie vor ein Problem, jedoch nicht mehr das wichtigste.

Heute besteht wohl die größte Herausforderung im Generationenwechsel, ein echter „Killer“. Denn selbst die beste Anwendung, die in den vergangenen 30 Jahren optimal auf die Unternehmensabläufe abgestimmt wurde, ist dem Tode geweiht, wenn es niemanden gibt, der deren Programme pflegen kann. Diese Situation zeigte sich bisher leider schon häufig bei den Kunden, bei denen die erfahrenen Programmierer in den Ruhestand gingen und keine Nachfolger für diese gefunden werden konnten. Diese Anwendungen mussten zwangsläufig und für sehr viel Geld gegen Standardanwendungen (mit ganz, ganz viel Customization) ersetzt werden. Angesichts der Bedeutung, die die IT heutzutage für das Wohlergehen einer Firma hat, kann so etwas zu einem gefährlichen Vabanquespiel werden.

Eine Anwendung, die in spaltenorientiertem RPG geschrieben ist, wird in fünf, allerspätestens in sieben Jahren nicht mehr pflegbar sein und damit abgelöst werden müssen. Egal, ob sie den Anforderungen des Unternehmens genügt oder nicht. Und egal, wie teuer und kompliziert eine Ablösung sein mag. Deshalb ist das absolute Minimum an Initiative, wenn die Anwendung überhaupt noch über das Jahr 2020 hinaus eingesetzt werden soll, die Konvertierung der Quellen in Freeform RPG.

Der zweitwichtigste Teil einer Modernisierungsstrategie ist die Einführung einer Anwendungsentwicklungsumgebung, die die Anforderungen in einem agilen Umfeld bewältigen kann. Sie muss die Kenntnisse, Talente und Erfahrungen der Entwickler/innen voll zur Geltung bringen. Nur so kann die IT das Business „enablen“. Die Merkmale einer solchen Umgebung sind einerseits die vollständige Integration von der im Impact Analysis über die Entwicklung und das Testen bis zum Deployment. Das alles plattformübergreifend für IBM i und alle anderen gängigen Anwendungsplattformen. Und andererseits die Integration mit den aktuellen Source-Code-Management-Tools, wie zum Beispiel Git oder Subversion.

Diese beiden Merkmale sind zwingend erforderlich. Mit spaltenorientiertem RPG oder einer unvollständigen Anwendungsentwicklungsumgebung kann keine Anwendung im kommenden Jahrzehnt mehr unterhalten werden.

Darüber hinaus gibt es noch vielfältige Möglichkeiten. Was im Einzelfall sinnvoll ist, hängt von der individuellen Situation der Anwendung ab.

Hier stellt sich die Frage, wie diese individuelle Situation aussieht. Ist die Anwendung überhaupt modernisierbar? Oder ist es sinnvoller, das Geld in eine komplette Neuentwicklung oder in den Wechsel zu einer Standardsoftware zu investieren? Bevor über die beiden erforderlichen Schritte Konvertierung in Freeform RPG und Einführung einer integrierten Multi-Plattform-Anwendungsentwicklungsumgebung hinausgegangen wird, sollte der aktuelle Stand der Anwendung analysiert werden. Das Ergebnis dieser Analyse sollte dann Grundlage der Entscheidung sein, wie weiter vorgegangen wird.

Statistisch gesehen ist der Weg der Modernisierung einer bestehenden Anwendung in den meisten Fällen der erfolgreichste. In einer Untersuchung von Professor Mulders von der Universität Antwerpen wurden 91 Prozent der Modernisierungsprojekte erfolgreich abgeschlossen, wohingegen die Wege der kompletten Neuentwicklung oder der Migration zu einer Standardsoftware nur zu 80 Prozent zum Erfolg führten.

Diese statistische Erhebung dient natürlich nur als Anhaltspunkt. Die individuelle Situation für eine Anwendung kann völlig anders aussehen. Es zeigt sich aber, dass die Flucht in eine Standardsoftware wohlüberlegt sein will und keineswegs als Allheilmittel angesehen werden kann.

Wie im Einzelfall weiter vorgegangen wird, hängt also von dem ab, was bei der Analyse in Erfahrung gebracht wird. Ein gutes Tool, wie zum Beispiel das ARCAD Pack for Application Analysis, hilft dabei. Damit wird eine Anwendungsdokumentation produziert, die in jedem Fall weiterhilft. Sollte die Entscheidung auf die Neuentwicklung oder den Wechsel zu einer Standardanwendung fallen, dann sind in der Dokumentation viele wichtige Informationen zu finden, die diesen Schritt erleichtern und beschleunigen. Fällt die Entscheidung jedoch auf die Modernisierung, dann ist eine solche Dokumentation selbstverständlich unverzichtbar.

Im Falle einer Modernisierung der bestehenden Anwendung gilt: Viele Anwendungen sind noch nach dem alten Paradigma geschrieben, das große, monolithische Programme bevorzugt hat. Für eine leichtere Pflege ist zu überlegen, ob nicht eine Modularisierung der Programme sinnvoll ist. Mit den Konzepten von ILE gibt es heutzutage sehr gute Möglichkeiten, die Architektur einer Anwendung auf neue Beine zu stellen und sie erheblich leichter und sicherer pflegbar zu machen. Ein gutes ALM-Tool (wie zum Beispiel das ARCAD Pack for DevOps) hilft dabei.

Die Umstellung der DDS-beschriebenen Datenbank nach DDL (also SQL) ist ein weiterer Schritt, der in Erwägung gezogen werden kann. Die Vorteile einer DDL-beschriebenen Datenbank liegen zum Teil in der größeren Performance bei Batch-Anwendungen. Auch kommt das Thema Generationenwechsel hier zum Vorschein, denn junge Entwickler/innen sind mit SQL deutlich vertrauter als mit DDS.

Wichtig kann auch Folgendes werden: Der Zugriff auf die Datenbank erfolgt in vielen Umgebungen nicht mehr nur mit RPG- oder Cobol-Programmen, sondern auch über ODBC oder JDBC. In diesen Fällen kann es sinnvoll sein, bestimmte Teile der Logik aus den Programmen in die Datenbank – also in Trigger, Stored Procedures und Constraints – zu verlagern. Das ist in einer DDL-beschriebenen Datenbank leichter und konsistenter zu erreichen als in einer DDS-beschriebenen. Hierfür liefert die ARCAD-Software das Produkt ARCAD Transformer DB.

Die Einführung von SOAP- oder REST-Services kann ein weiterer Schritt zur Modernisierung sein. Insbesondere dann, wenn die Kommunikation mit Externen – also Kunden, Lieferanten oder Behörden – wichtig ist.

Die Einführung einer MVC-Architektur (Model View Controller) ist sicherlich die umfangreichste Modernisierung einer gewachsenen IBM-i-Anwendung. Die Aufteilung der monolithischen Programme in drei Ebenen – Präsentation, Logik, Datenbankzugriff – bringt enorme Freiheiten bei der Anwendungsgestaltung, ist jedoch ziemlich aufwändig. Aber auch wenn „nur“ zwei Ebenen eingeführt werden – also lediglich die Präsentationsschicht isoliert –, kann einiges gewonnen werden.

Bleibt noch die grafische Benutzeroberfläche. Hier sind wohl einige Abwägungen erforderlich. Auf der einen Seite steht der enorme Aufwand, der für deren Einführung betrieben werden muss. Die dafür erforderlichen Komponenten, egal, ob es Standard-Webserver oder von den Lieferanten selbst gestrickte Anwendungen sind, sind in jedem Fall mit vermehrtem Pflegeaufwand verbunden. Dieser Aufwand kann sich lohnen. Zum Beispiel dann, wenn die Anwendungsbedienung über eine Weboberfläche dem Unternehmen große Vorteile bringt oder wenn in der Anwendung besondere Funktionen in den Smartphones der Anwender (Kamera, GPS-Empfänger etc.) genutzt werden sollen.

Für die Modernisierung der Benutzeroberfläche stehen „einfache“ Tools zur Verfügung, wie zum Beispiel das WOPiXX der Firma Toolmaker, oder auch komplexere, wie zum Beispiel das Produkt iNext von ML-Software.

WOPiXX hat den großen Vorteil, dass Anwendungen lediglich mit RPG-Know-how erstellt werden können. Der Aufbau oder der Einkauf von Kenntnissen über HTML, CSS, Java, C etc. ist hier nicht erforderlich. Allerdings gibt es die Einschränkung, dass Anwendungen lediglich Browser-basierend erfolgen. Der Zugriff auf die Anwendung vom PC und vom Smartphone ist damit realisierbar, nicht jedoch der Zugriff auf spezielle Komponenten des Smartphones, wie zum Beispiel die Kamera oder den GPS-Empfänger.

Bei Produkten wie iNext sind solche Zugriffe möglich, sie erfordern jedoch auch Kenntnisse in anderen Programmiersprachen als RPG.

Zusammenfassung

Grundsätzlich ist für eine IBM-i-Anwendung heute zu prüfen, ob sie den Anforderungen der IT – der digitalen Transformation – gerecht werden kann.

Unbedingt erforderlich, egal, wie die weitere IT-Strategie in einem Unternehmen aussieht, sind:

1. Die Einführung eines Application-Lifecycle-Management-Systems

a. mit automatisiertem Test und Deploy

b. mit einer Multiplattform

c. mit der Integration in git, Subversion, Jenkins etc.

2. Die Konvertierung der Quellen nach RPG

3. Die Analyse der Anwendung

Fällt die Entscheidung auf eine Modernisierung der bestehenden Anwendung, dann ist zu prüfen, welche Modernisierungsschritte gegangen werden sollen und in welchem Umfang:

• Modularisierung der Programme

• Konvertierung der Datenbank nach DDL

• Einführung von SOAP-/REST-Services

• Einführung einer MVC-Architektur

• Einführung einer grafischen Benutzeroberfläche

Für alle diese Schritte und Optionen gibt es sehr gute Tools, die die Entwickler/innen bei der Arbeit unterstützen.

www.arcadsoftware.de