Im Zuge der Digitalisierungsstrategien von Organisationen steht das Thema Software-Modernisierung auf der Agenda der meisten IT-Verantwortlichen. Im Interview verdeutlicht Don Fitzgerald, Geschäftsführer von EasiRun Europa, gegenüber Midrange Mail (MM), wie wichtig dieser Komplex ist.
MM: Was sind die definitiven Anzeichen, dass eine IT-Lösung modernisiert werden muss?
Fitzgerald: Wie so oft gibt es nicht das eine Anzeichen, sondern eine Reihe von Anzeichen, die aber nicht bei jeder IT-Lösung zu finden sind bzw. nicht in gleicher Ausprägung vorhanden sind. Generell wird eine Modernisierung nötig, wenn das Risiko und die Kosten beim Betrieb einer Anwendung vom Ausmaß her an den eigentlichen Wert der IT-Lösung heranreicht bzw. diesen übersteigt. Hohe Kosten für Personal und Infrastruktur, für Soft- und Hardware, können mögliche Anzeichen für eine fällige Modernisierung sein. Die Risiken durch eine Vernachlässigung der Modernisierung können viele Auswirkungen haben.
MM: Können Sie dazu einige Beispiele aufführen?
Fitzgerald: Die Komplexität der Wartung nimmt zu, Know-how Träger und erfahrene Arbeitskräfte sind nicht mehr in ausreichender Anzahl vorhanden und dadurch entstehen Engpässe bzw. Bottlenecks. Oder auch die Einführung neuer Erweiterungen und Features dauert immer länger, andererseits kann es dazu kommen, dass die Motivation der Mitarbeiter abnimmt, die Kundenzufriedenheit nachlässt und dass letztendlich Innovationen blockiert werden.
MM: Modernisierung versus komplette Neukonzeption – was sprich für eine Modernisierung der bestehenden Anwendung?
Fitzgerald: Wenn eine IT-System-Modernisierung ansteht, dann ist die Versuchung zunächst groß, das vorhandene System aufzugeben und durch ein vermeintlich moderneres und effizienteres System zu ersetzen. Jedoch besitzen vorhanden Systeme eine Historie, die über viele Jahre hinweg gewachsen ist. Die mit einer Ablösung verbundene Herausforderung ist somit sehr groß, da man aus den vergangenen Fehlern lernen, aktuelle Benutzeranforderungen erfüllen und zukünftige Anforderungen vorausahnen muss.
MM: Was sind Ihre konkreten Erfahrungen in diesem Bereich?
Fitzgerald: Innerhalb einer Vielzahl von Projekten, in denen wir hinzugezogen wurden, konnten die Ziele der Auftraggeber durch die komplett neu entwickelten Umgebungen nicht zufriedenstellend erreicht werden und es mussten erneut Audits durchgeführt werden. Dafür gab es verschieden Gründe. Anwender waren unzufrieden und legten eine ablehnende Haltung gegenüber Neuerungen an den Tag. Die Performance konnte anfänglich nicht mit der des Altsystems mithalten. Budgets und Fristen wurden deutlich überschritten. Zahlreiche Funktionen des Altsystems waren nicht implementiert. Es gab große Unterschiede zwischen dem Verhalten des Altsystems und des neuen Systems durch Lücken in der Spezifikation.
MM: Was folgern Sie aus diesen Erfahrungen?
Fitzgerald: Die komplette Neuentwicklung eines Systems erweist sich in vielen Fällen nicht als die beste Vorgehensweise. Generell sollte genau abgewogen werden, ob eine Modernisierung nicht doch die bessere und sichere Lösung für die eigenen Unternehmensbedürfnisse ist, bzw. dass es in vielen Fällen, einfacher, günstiger und schneller zum Erfolg führt, sein Legacy-System iterativ und sukzessiv zu modernisieren. Zudem ist klar, dass Schlagworte und neue Technologien für Architekten wichtig sind, aber für Endnutzer nur wenig Bedeutung haben, wenn in Ihrem Arbeitsalltag keine Vorteile daraus ersichtlich sind. Zudem läuft ein Unternehmen während der Neuentwicklung Gefahr, keine Weiterentwicklung an der Bestandsanwendung vorzunehmen und durch Mangel an neuen Features und Funktionen echte Geschäftsmöglichkeiten zu verpassen oder gegenüber der Konkurrenz zurückzufallen. Dazu kommt noch, dass die Wartung der Alt-Anwendung, während der Neuentwicklung leidet und dadurch ein Sicherheitsrisiko erzeugt wird und dass der Eindruck von schlechtem Design oder schlechter Code-Qualität oft sehr subjektiv ist und keine inkrementellen Verbesserungen verhindert.
MM: Was spricht für eine inkrementelle Modernisierung?
Fitzgerald: Wird sie gut ausgeführt, stellt sie die kostengünstigste und sicherste Variante dar, um eine Geschäftsanwendung auf den neuesten Stand zu bringen. Zudem erhält dieses Vorgehen den Wert Ihrer jahrelang gepflegten und organisch gewachsenen Anwendung, deswegen sagen wir „Take Advantage of your Legacy“. Es erfordert sowohl Experten für die Wartung von Legacy-Systemanwendungen, als auch gute Kenntnisse spezialisierter Architektur-Refactoring-Tools, damit der Betrieb effektiv ist, dafür erhalten Sie aber ein über die Jahre erprobtes System, welches auch gegen aktuelle und zukünftige Herausforderungen bestens gewappnet ist.
MM: Was muss bei einer Modernisierung heutzutage alles enthalten sein?
Fitzgerald: Vor Beginn einer Modernisierung müssen die Herausforderungen identifiziert werden, da Anwendungen und Systeme zwar grundsätzlich auf standardisierten Regelwerken basieren, diese Regeln jedoch unterschiedliche Möglichkeiten der Umsetzung und Implementierung zulassen. Entscheidend ist, die richtige Vorgehensweise für jedes System individuell im Hinblick auf die individuelle Zielsetzung des Unternehmens und die spezifischen Besonderheiten des Bestandssystems zu betrachten. Darüber hinaus reden wir oft nicht über „die“ Software und „das“ System, sondern von einer Vielzahl unterschiedlicher Software-Produkte unterschiedlichster Lösungsanbieter, die in Symbiose zueinanderstehen.
MM: Mit welchen Herausforderungen ist im Umfeld „Modernes Legacy“ zu rechnen?
Fitzgerald: Da lassen sich einige Punkte aufführen. Zum einen die Identifikation und Abbildung anwendungsspezifischer Besonderheiten, dann der Aufbruch bestehender Datenstrukturen, die Identifikation und Definition belastbarer Testverfahren. Aber auch die technologischen Herausforderungen im Zusammenhang mit produktspezifischen Abbildungen sowie die menschlichen Herausforderungen in Hinblick auf Akzeptanz und Wissenstransfer von Beteiligten sind zu nennen. Interessant wird es, wenn wir über die Lösungen und Methodiken sprechen, da die Ansätze in diesem Zusammenhang äußerst vielfältig sind. Sie reichen von Screenscraper Lösungen über moderne Entwicklungsumgebungen und der Migration von Programmiersprachen bis hin zur Verteilung von Anwendungen in hybride Architekturen.
MM: Gibt es eine Pauschalaussage zu einer konkreten Vorgehensweise, und was in einem spezifischen Fall als sinnvoll zu betrachten ist?
Fitzgerald: Das hängt von einer Vielzahl an Faktoren ab. Als Ausgangsbasis für Lösungsansätze dienen konkrete Assessments, anhand derer man die Ist-Situation, die Ziele und Wünsche des Kunden sowie kaufmännische und strategische Entscheidungen aufnimmt und konkrete Lösungsvorschläge unterbreitet.
MM: Wie könnten Lösungsansätze für verschiedene Szenarien aussehen?
Fitzgerald: Da fallen mir die Anbindung oder Bereitstellung von Anwendungen und Daten an externe Systeme via REST-Services ein, aber auch die Umstellung der Datenhaltung von IMS/ VSAM/ ISAM auf RDBMS mit expliziter Extraktion einer Datenzugriffsschicht für bessere Performance, einfacherer Wartbarkeit und vereinfachte Weiterentwicklung. Beim Betrieb einer Mainframe-Anwendung in einer Hybridarchitektur (z.B. mit Cloudkomponenten) kann es sinnvoll sein, die Ablösung von PL/I durch Java im Rahmen einer Java-Strategie voranzutreiben oder die Ablösung von Produkten der SAG Produktfamilie, z.B. NATURAL und ADABAS, zu forcieren.
MM: Warum reicht kein neues Benutzer-Interface auf verschiedenen Endgerätetypen aus?
Fitzgerald: Die Benutzeroberfläche ist das Erste, was man von einer Altanwendung sieht und oft als ein zu modernisierendes Objekt betrachtetet wird. Dennoch sind wir der Meinung, dass eine Modernisierung, wie bereits erwähnt, weit über einen Austausch von Benutzeroberfläche hinausgeht. Die Modernisierung verstehen wir als einen Prozess, der sich immer wieder mit neuen Herausforderungen beschäftigt. Deswegen sollte eine Modernisierung Türen öffnen und Brücken bauen, um einen erfolgreichen Modernisierungsprozess zu etablieren.
MM: Wie aufwändig ist eine Modernisierung vor dem Hintergrund, dass Sourcecode und Programmieren der alten Lösung nur schwer zugängig sind?
Fitzgerald: Aus unserer Erfahrung heraus sind Source Code Dokumentationen gerade bei Altanwendungen sehr problematisch. Deswegen ist der Source Code umso wichtiger, denn die Wahrheit bzw. was die Anwendung macht und machen soll, steckt im Source Code. Deswegen kann man, aus unserer Sicht, ohne detaillierte Einblicke in den Source Code keine Modernisierung vorantreiben und ohne greifbare Knowhow-Träger wird es noch einmal deutlich schwieriger. Tiefgehende und gezielte Analysen gepaart mit der richtigen Vorgehensweise können das ausgleichen.
MM: Wie können Modernisierungs-Framework speziell für IBM i/AS400 helfen, den Modernisierungsaufwand zu reduzieren?
Fitzgerald: Im Grunde genommen sollte das Framework den Know-how-Träger entlasten, um bestimmte Modernisierungsschritte mit weniger Aufwand umzusetzen. Es muss deswegen in der Lage sein, wiederholbare Aufgaben zu automatisieren und in eine Continuous Integration bzw. einen Continuous Delivery Prozess zu integrieren. Zusätzlich sollte es für IBM i/AS400 bestimmte Features bereitstellen, die die Interaktion zwischen alt und neu in Bereichen, in denen wenig Expertise vorhanden ist, verfügbar machen. Darüber hinaus sollte ein nativer und direkter Zugriff auf die Funktionalität von IBM i/AS400 gegeben sein.
MM: Haben Sie dazu konkrete Beispiele?
Fitzgerald: Beispiele für die Interaktion bzw. Integration von alter und neuer Umgebung sind SOA, RPA, IA, Smartphones und Pads, HTML5 Responsive Design, Bootstrap / AngularJS, REST APIs und Web-Services, die auf IBM i/AS400 Ressourcen zugreifen. Beispiele für IBM i/AS400 Funktionalitäten sind Aufrufe von IBM i Programmen und Befehlen, der Zugriff auf die verschiedensten Ressourcen wie Libraries, Objects und Members, aber auch der Zugriff auf Dateisystem, Dateien und Datenbanken.
MM: Welche Programmiersprachen und Software-Tools sind nötig, um alte COBOL- oder RPG-Programme auf einen modernen Stand zu bringen?
Fitzgerald: Abhängig von den kaufmännischen, den technologischen und den strategischen Zielen sind Sprachen wie COBOL, Java und .Net mit den entsprechenden Entwicklungsumgebungen, SDKs und Transpilern im Vordergrund, aber auch andere Sprachen wie Python, Ruby, PhP, Node.js, C/C++ und Delphi kommen zum Einsatz. Darüber hinaus sind selbstverständlich auch Tools, wie z.B. die Mainframe Integrator Suite, Analysewerkzeuge und Automatisierungstools unabdingbar.
MM: Welche Features zeichnen die Mainframe Integrator Suite for IBM i aus?
Fitzgerald: Die Mainframe Integrator Suite ermöglicht die Modernisierung der IT durch die Bereitstellung von agilen Services und benutzerfreundlichen Webanwendungen, ohne die Integrität und Zuverlässigkeit des bestehenden Mainframe-Kerns zu beeinträchtigen. Die Mainframe Integrator Suite erweitert auf einfache Weise Ihre IBM i- (Power, iSeries, AS/400), IBM z- und UNIX-Legacy-Anwendungen um moderne Technologien für Smartphones und Tablets (siehe folgende Tabelle). (rhh)
Eigenschaften der Mainframe Integrator Suite
• HTML5, RESTful API und Sprachassistenten (Alexa, Google Assistant, IBM Watson Assistant).
• Enterprise Studio: Grafikdesign-IDE für Java-Entwickler
• Smart Publishing & Smart Publishing Advanced: Greenscreen Modernisierung und Revamping /Überarbeitung für Webbrowser
• AccessObject: Workflow-Modernisierung
• Call-Out: Aufruf externer Web-Services aus COBOL- und RPG-Legacy-Sprachen
• DataMapper: Direkter Zugriff auf Legacy-Geschäftslogik zur Entwicklung von Java Anwendungen. Dies funktioniert unter Verwendung eines CICS-Connectors
• Traffic Player: Aufzeichnen und Wiedergeben von Telnet-Streams TN5250
• MXi-Wrapper: MXi bietet Entwicklern eine Middleware und eine Reihe von High-Level-Wrappern über eine native Verbindung oder über APIs für den Zugriff auf verschiedene Funktionen der IBM i.