Anwendungen erneuern, modernisieren und plattformunabhängig machen: Die Zeit läuft

Unter dem Titel „Anwendungserneuerung“ werden jede Menge unterschiedlichster Lösungen angeboten. Es stellt sich die Frage, wann eine Anwendung erneuert ist? Wenn sie eine neue Optik hat, wenn sie zusätzliche Funktionalität anbietet oder erst wenn Sie auf einer neuen Plattform arbeitet? Das Ziel schlechthin ist wohl eine plattformunabhängige Anwendung. Diesen Begriff muss man zuerst genauer unter die Lupe nehmen. Was bedeutet Plattformunabhängigkeit eigentlich?

Gehen wir von Web-Anwendungen aus. Hier sind wir in jedem Fall von der Datenbank und dem Betriebssystem des Servers abhängig. Dann gibt es auch noch den Browser, der das User-Interface darstellt. Schon haben wir drei Plattformen, denen wir unsere Anwendung anvertrauen müssen.
Theoretisch könnte auch eine Windows-Anwendung plattformunabhängig sein. Wenn man unter DotNet oder Java programmiert, hat man zumindest die Chance, sie auf Linux zu portieren. Ob das Programm, das man den Endkunden für Linux in die Hand geben kann, noch dem gleichen Quellcode wie das Windows-Programm entstammt, darf angezweifelt werden.

Uns IT-Profis ist sowieso klar, dass es eine völlige Plattformunabhängigkeit nie geben wird. Obwohl die Plattform-Hersteller das tatsächlich anstreben, wäre es für viele Unternehmen wohl der reine Selbstmord. Warum?

Die Linux-Welt bemüht sich sehr, dem Betrachter den Eindruck zu vermitteln, dass es sich um eine einzige Plattform handelt. Dagegen sprechen die vielen Distributionen. Auch hier ist Vorsicht geboten. Für das Funktionieren eines Programms auf allen verfügbaren Versionen wird wohl niemand garantieren können und wollen.

Standards, die sich am längsten gehalten haben, sind jene, die durch eine Monopolstellung zustande gekommen sind. Diese wurden wieder durch den Markt und letztlich durch den Kunden gesetzt. Früher war das fast ausnahmslos IBM überlassen, heute übernimmt das schrittweise Microsoft. Immerhin gibt es ein Gremium (das W3C), von dem die Standards für Schnittstellen durch Vertreter der führenden Unternehmen definiert werden.

Die Wahl der Zielplattform ist unumgänglich,

sie hängt auch größtenteils von den Möglichkeiten und Anforderungen der Anwendung ab. Es ist unmöglich, eine Anwendung zu migrieren, für die keine Sourcen vorhanden sind. Für diese Fälle ist man mit einer „Maskerade“ gut bedient. Das ist auch die einzige Möglichkeit, um die Anwendung optisch oder in Teilbereichen auch funktionell zu modernisieren. Lösungen, die auf 5250-Datenstrom aufsetzen, sind inzwischen zahlreich am Markt zu finden.

Wenn aber wartbare Sourcen vorhanden sind, ist Webfacing zweifellos ein Ansatz, der nur kurzfristigen Erfolg verspricht. Man kann sich mit teurem Geld über einen Engpass retten, die Anwendung wird dadurch nicht erneuert.

Wenn von der Möglichkeit, die Anwendung am FrontEnd weiterzuentwickeln (die manche Anbieter als Lösung präsentieren), Gebrauch gemacht wird, entsteht in kurzer Zeit eine Parallel-Front, die zu betreuen und zu finanzieren ist. Auf diese Weise wird eine Anwendung über mehrere Plattformen verteilt.

Versucht man später eine Erneuerung, so ist das noch wesentlich schwieriger, als diesen Schritt auszulassen und gleich das Ziel einer Migration anzustreben.

Für substantielle Erneuerung gibt es nur zwei Zielplattformen: Java und DotNet

IBM predigt seit Jahren den Umstieg auf Java und ignoriert dabei, dass dieser Weg für viele ihrer Midrange-Kunden nicht gangbar ist, weil sich die Software-Entwicklung unter Java von der gewohnten RPG-Entwicklung massiv unterscheidet. Um diesen Weg einschlagen zu können, fehlen sehr oft die nötigen Ressourcen. Beispiele – wie das zum Millionengrab gewordene San-Francisco-Projekt der IBM – tragen nicht dazu bei, Java bei den Anwendern populär zu machen. Somit ist klar, dass die Entscheider eher zurückhaltend im alten Stil weitermachen und bestenfalls versuchen, die Anforderungen der Anwender mit Webfacing zu bedienen. Die Erneuerung ist somit abgesagt oder auf später verschoben.

Der Erzfeind als Alternative?

Microsoft wurde in den letzten Jahre zum Feind hochstilisiert. Wie sinnvoll das ist, fragt man sich, wenn man die Vermarktungserfolge der IBM betrachtet. Wo heute Microsoft ist, könnte OS/2 sein, hätten das nicht die Marketingstrategen „vergeigt“.

Inzwischen täuscht die IBM dem Kunden eine Produktlinie vor: Unter dem Namen „Websphere“ finden sich die unterschiedlichsten Produkte, deren einzige Gemeinsamkeit der Name „Websphere“ oder „DB/2“ ist. Bei Microsoft gibt es stattdessen eine einzige Linie, auf der Software entwickelt wird: DotNet. Microsoft lässt über seine Absichten, das Business-Computing endgültig zu dominieren, auch keinen Zweifel aufkommen. In den letzten Jahren wurden eindeutige Zeichen gesetzt. Microsoft lockt Software-Häuser mit Migrations-Software von Kooperationspartnern auf DotNet. Das ist auch durchaus attraktiv, da gegenüber Java wesentliche Vorteile geboten werden. Dazu gehört die Wahlmöglichkeit der Sprache ebenso wie die breite Akzeptanz von DotNet auf den Universitäten, von der man sich eine Entschärfung des Generationswechsel-Problems erwarten darf.

Jede Plattform verlangt Anpassungen

Die Anwendung, eins zu eins von der i5 auf eine andere Plattform ‚rüberzuziehen’, wird wohl mit keinem Werkzeug möglich sein. Man muss sich auch fragen, ob das sinnvoll wäre, denn das würde eine „virtuelle i5“ auf der Zielplattform verlangen. Das geht wiederum am Sinn der Migration vorbei. Ein wichtiger Aspekt ist ja, sich von „Altlasten“ zu befreien und Werte – wie praxiserprobten Code, Daten, Human Capital –, um nur einige zu nennen, auf eine neue Schiene zu bringen, von der aus eine Weiterentwicklung möglich ist.

Eine wesentliche Voraussetzung für eine erfolgreiche Weiterentwicklung ist gegeben, wenn man nach der Migration auf der Zielplattform seinen Code ansieht und die Logik wieder erkennt. Die Chance für dieses Erlebnis gibt es aber nur, wenn die Sprache gleich oder ähnlich der ursprünglichen Sprache ist.
Bei Transliteration (RPG _ Java oder C#) darf grundsätzlich angezweifelt werden, ob man mit dem Code auf der Zielplattform auch noch was anfangen kann.
Der RPG-Programmierer, der den Code kennt, kann höchstwahrscheinlich mit der Sprache nicht viel anfangen, und für den C#- oder Java-Programmierer ist der migrierte Code zweifellos unwartbarer Garbage. Eine Lösung dieses Problems wäre es, den Programm-Code in ein modernes Äquivalent umzusetzen. Die Chance hat man bei COBOL oder RPG. Es gibt Compiler für DotNet sowie auch Migrations-Werkzeuge.

Welcher Anwendungstyp ist der Richtige?

Natürlich Web-Anwendungen. Die sind ähnlich zu betreuen wie unsere i5-Programme. Auf den zweiten Blick gibt es da schon Unterschiede. Die Funktionstasten werden vom Browser abgefangen und die Performance ist zwangsläufig schlechter als am Terminal. Manche Hersteller bieten ihren eigenen Client an. Das wäre ein Lösungsansatz, man muss den aber wie eine Client-/Server-Anwendung auf jedem Arbeitsplatz installieren. In diesem Fall kann man gleich eine Client-/Server-Lösung anstreben. Vorteile sind hohe Geschwindigkeit, angenehme Bedienung und eine große Stabilität.

Proof of Concept

Um einen Eindruck von den Möglichkeiten des Migrations-Werkzeugs zu bekommen, ist der erste Schritt ein Programm zum Test zu migrieren. Das Programm sollte ein repräsentatives Beispiel sein. Natürlich sollte es sich nicht um ein „Monster“ handeln, weil durch Code-Mengen die Übersichtlichkeit leidet. Das ideale Projekt für ein „Proof of Concept“ (PoC) ist ein Dialogprogramm, in dem alle wesentlichen Strategien und Konzepte der gepflegten Programmierkultur enthalten sind.

Für ein Proof of Concept sollte man 2-3 Tage einplanen und bedenken, dass der Migrator jemanden braucht, der sich mit dem Programm in Bezug auf Funktion und Code auskennt. Anhand des Ergebnisses des PoC kann man abschätzen, wie viel Aufwand eine Migration haben wird und was man als Ergebnis erwarten kann.

Ergebnisanalyse

An erster Stelle steht der erzeugte Code. Ist der vom Programmierer, der das Programm auf der i5 geschrieben hat, nicht wieder zu erkennen, so steht der Sinn der Migration bereits in Frage. An zweiter Stelle stehen die Bildschirmmasken. Wurden sie korrekt umgesetzt, so ist ein Erfolg gegeben. Erst nach dem PoC kann eine Machbarkeitsanalyse erstellt und eine grobe Aufwandsschätzung gemacht werden. Ist dieser Punkt positiv beantwortet, werden die Kosten zum Thema.

Kosten

An erster Stelle sind hier nicht die Kosten der Migration zu betrachten, sondern jene Kosten, die entstehen, wenn die migrierte Lösung eingesetzt wird. Das sind die Datenbank und eventuelle Runtime-Lizenzen.

Die Kosten der Migration müssen natürlich auch hereingebracht werden. Daraufhin kann man abschätzen, ob das Projekt am Markt durchsetzbar ist.
Ein Gesichtspunkt relativiert aber jede Kostendiskussion: Green-Screen-Lösungen sind unverkäuflich und eine i5 für Neukunden schwer durchzusetzen. Es geht also ums Überleben!

Schritt für Schritt

Wenn ein Migrationsprojekt in Angriff genommen wird, ist maßvolle Planung angesagt. Die Größe der Schritte ist individuell. Man sollte aber folgende Meilensteine planen:

1. Migration der Dialogprogramme
2. Refactoring der Anwendung auf der Zielplattform
3. Migration der Datenbank

Schritt 1: Die Präsentationsschicht muss migriert und überarbeitet werden, um der Anwendung eine gute Bedienbarkeit zu geben (Stichwort: Portallösung). Zu diesem Zeitpunkt arbeiten die Druck- und Batch-Programme immer noch auf der iSeries. Mit dieser Version sollte man bereits auf den Markt gehen können.

Schritt 2: Hier muss die Programmlogik von der Präsentationsschicht entkoppelt werden. Das ist eine wichtige Voraussetzung, um ein alternatives User-Interface – z. B. ein Client-/Server-Programm – anbieten zu können, ohne die Business-Logik mehrfach mitzuführen. In diesem entscheidenden Schritt geht es darum, die Anwendung in ein Design zu bringen, das dem Objekt-Konzept entspricht.

Schritt 3: Spätestens hier muss man sich von den Features der i5 gelöst haben. Dazu gehören eine Ablöse der Programme, die APIs verwenden, eine Lösung für LIBL, DTAQ, DDM, Druck- und Batchprogrammen, um nur einige der Eigenheiten unserer i5/OS zu nennen. In den meisten Fällen muss auch die Programmlogik im Hinblick auf die Zieldatenbank überarbeitet werden, da es keine andere Datenbank gibt, die z. B. Multiformat-LF unterstützt.

Die Alternative

Angesichts dieser Aufgabenliste fragt man sich natürlich, ob sich der Aufwand der Migration lohnt. Die Alternative wäre eine Neuentwicklung. Hier sind folgende Fragen zu beantworten: