Über die Notwendigkeit der ständigen Optimierung und Weiterentwicklung der IT, die in den letzten Jahren mehr und mehr zum tragenden Geschäftsprozess von Firmen jeglicher Branche geworden ist, braucht heute nicht mehr diskutiert werden.
Dabei geht es nicht nur um Hardware und Netzwerke, sondern insbesondere auch um die Anwendungen, die zum einen die Businessprozesse optimal unterstützen und die zum anderen zügig den sich ändernden Anforderungen der Fachabteilungen angepasst werden müssen. Vor diesem Szenario liegt nichts näher als die Schlussfolgerung, dass jene Firmen im Wettbewerbsvorteil sind, die eine stabile Hardware-Infrastruktur nutzen, zuverlässige Software-Anwendungen betreiben und zudem in der Lage sind, schnell und agil auf Prozess- und Funktionsveränderungen reagieren und diese nachhaltig umsetzen zu können.
Wettbewerbsvorteile
System i bietet mit seinem kompakten Design aus Hardware, Betriebssystem, Datenbank und Programmiersprache seit der Einführung in den achtziger Jahren eine hervorragende Plattform, um genau in diesem Szenario wie ein Fels in der Brandung zu bestehen. Kein Wunder also, dass gerade die Marktführer einer Branche auf diese Plattform setzen. Schade nur, dass in den letzten Jahren viele Modernisierungsund Migrations-Vorhaben von System i- Anwendungen scheiterten, weil einfach nicht das geeignete Werkzeug und auch keine geeignete Zielsprache am Markt verfügbar waren. Alle Migrations-Versuche nach JAVA oder .NET sind letztendlich am Paradigmenbruch zwischen prozeduraler und objektorientierter Welt gescheitert.
Doch das hat sich nun geändert: Mit EGL ist es IBM gelungen, eine ganzheitliche und nachhaltige Modernisierung aufzuzeigen. Hierfür bedient sich IBM einem Expertenteam in Sachen SWEntwicklung aus dem Hause Rational. Außerdem wird die Migrations-Technologie der PKS Software GmbH genutzt, um RPG nach EGL zu migrieren; das heißt dann: IBM Rational Migration Extension for System i (kurz RMEi).
Doch wie funktioniert das Ganze nun? In der EGL-Philosophie herrscht klare Schichtentrennung und saubere Modularisierung vor. Eine Migration von RPG nach EGL muss also aus dem vorhandenen, meist eher monolithischen Bestandssystem eine MVC-Architektur machen. Um dieses "Machen" technisch zu realisieren, sollte entweder über Kapselung und APIs gearbeitet oder die komplette Anwendung zerlegt und neu in EGL geschrieben werden.
Das Konzept, das IBM und PKS gemeinsam ausgearbeitet haben, adressiert beide Varianten und stellt den Kunden somit vor die Qual (oder Chance) der Wahl. Die Migration von RPG-Batch- Programmen, RPG-Services und interaktiven RPG-Programmen wird dabei unterschiedlich unterstützt. RPG-Batch-Programme können entweder einfach per Call von EGLProgrammen aus aufgerufen werden.
Somit ist gar keine Migration von Code im ursprünglichen Sinne nötig. Es wird einfach alles "Neue" in EGL entwickelt und vorhandene RPG-Batches per Call in die Neuentwicklung eingebunden - eine elegante und kostengünstige Lösung, wenn die System i-Plattform Bestand haben soll. Wenn eine plattformneutrale Anwendung angestrebt wird, dann muss der RPG-Batch mit RMEi nach EGL migriert und mittels einer Service Library gekapselt werden.
RPG-Service-Programme können analog dazu auch sehr einfach in eine EGL-Neuentwicklung integriert werden:
Hierzu bietet EGL sogenannte "Wrapper" an). Aber natürlich können auch solche Programme mit RMEi in "native EGL" migriert und somit plattformunabhängig gefahren werden. Bisher ist alles noch recht einfach.
Doch was passiert mit den interaktiven RPG-Programmen? Denn schließlich kommt hier der monolithische Aufbau von RPG-Anwendungen in der Regel richtig zum Tragen. Im ersten Schritt wird mit einem Server Builder Tool die RPG-Anwendung vom 5250 User Interface entkoppelt. Die RPG-Anwendung arbeitet dann über API-Funktionen und bedient direkt ein Web- oder Windows- Frontend. Das Frontend basiert auf einer XML-Konfiguration, bietet zahlreiche Möglichkeiten zur modernen Gestaltung von User Interfaces und ist mit minimalem Aufwand zu realisieren.
Im zweiten Schritt können die RPG-Programme mit RMEi nach EGL migriert werden. Das migrierte EGLProgramm kann auch das API fürs Frontend nutzen wie das ursprüngliche RPG-Programm. Durch eine Bridging- Funktionalität des API ist es darüber hinaus möglich, neue Oberflächen in native EGL zu schreiben und mit APIGUI nahtlos zu integrieren. Die Anwender können nicht sehen, hinter welcher Maske sich "Noch-RPG" oder "Schon- EGL" verbirgt. Gleichzeitig kann durch manuelles bzw. Tool-unterstützes Vorgehen die monolithische Alt-Anwendung in eine "reine SOA" zerlegt und umgebaut werden.
Es bietet sich also eine reiche Vielfalt an Möglichkeiten, die es jedem Kunden ermöglicht, die Modernisierung auf Basis von EGL an seinem Bedarf, seinem Budget und den Zeitvorgaben für ein solches Vorhaben auszurichten.
Aufbauend auf den Erfahrungen der bisherigen Projekte empfiehlt IBM ein Sechsschritt-Vorgehen:
1. Bauen Sie EGL-Know-how im Team auf und sammeln Sie praktische Erfahrung in der EGL-SW-Entwicklung.
2. Konvertieren Sie im Rahmen eines Prototyps ein vorhandenes RPGProgramm nach EGL.
3. Führen Sie eine komplette und umfassende Analyse aller vorhandenen Anwendungen durch.
4. Führen Sie ein Proof-of-Concept für einen kleinen Bereich Ihrer Anwendungen durch.
5. Überführen Sie Ihre Bestandsanwendungen anhand der Ergebnissen aus der Analysephase nach EGL.
6. Nutzen Sie die Vorteile der "Neuen Welt", nachdem es Ihnen gelungen ist, Geschaffenes zu bewahren und in die Zukunft zu überführen.
Unterstützung bei diesem Vorgehen bieten IBM und lokale EGL-Partner online unter
www-949.ibm.com/software/rational/cafe/index.jspa
Dabei geht es nicht nur um Hardware und Netzwerke, sondern insbesondere auch um die Anwendungen, die zum einen die Businessprozesse optimal unterstützen und die zum anderen zügig den sich ändernden Anforderungen der Fachabteilungen angepasst werden müssen. Vor diesem Szenario liegt nichts näher als die Schlussfolgerung, dass jene Firmen im Wettbewerbsvorteil sind, die eine stabile Hardware-Infrastruktur nutzen, zuverlässige Software-Anwendungen betreiben und zudem in der Lage sind, schnell und agil auf Prozess- und Funktionsveränderungen reagieren und diese nachhaltig umsetzen zu können.
Wettbewerbsvorteile
System i bietet mit seinem kompakten Design aus Hardware, Betriebssystem, Datenbank und Programmiersprache seit der Einführung in den achtziger Jahren eine hervorragende Plattform, um genau in diesem Szenario wie ein Fels in der Brandung zu bestehen. Kein Wunder also, dass gerade die Marktführer einer Branche auf diese Plattform setzen. Schade nur, dass in den letzten Jahren viele Modernisierungsund Migrations-Vorhaben von System i- Anwendungen scheiterten, weil einfach nicht das geeignete Werkzeug und auch keine geeignete Zielsprache am Markt verfügbar waren. Alle Migrations-Versuche nach JAVA oder .NET sind letztendlich am Paradigmenbruch zwischen prozeduraler und objektorientierter Welt gescheitert.
Doch das hat sich nun geändert: Mit EGL ist es IBM gelungen, eine ganzheitliche und nachhaltige Modernisierung aufzuzeigen. Hierfür bedient sich IBM einem Expertenteam in Sachen SWEntwicklung aus dem Hause Rational. Außerdem wird die Migrations-Technologie der PKS Software GmbH genutzt, um RPG nach EGL zu migrieren; das heißt dann: IBM Rational Migration Extension for System i (kurz RMEi).
Doch wie funktioniert das Ganze nun? In der EGL-Philosophie herrscht klare Schichtentrennung und saubere Modularisierung vor. Eine Migration von RPG nach EGL muss also aus dem vorhandenen, meist eher monolithischen Bestandssystem eine MVC-Architektur machen. Um dieses "Machen" technisch zu realisieren, sollte entweder über Kapselung und APIs gearbeitet oder die komplette Anwendung zerlegt und neu in EGL geschrieben werden.
Das Konzept, das IBM und PKS gemeinsam ausgearbeitet haben, adressiert beide Varianten und stellt den Kunden somit vor die Qual (oder Chance) der Wahl. Die Migration von RPG-Batch- Programmen, RPG-Services und interaktiven RPG-Programmen wird dabei unterschiedlich unterstützt. RPG-Batch-Programme können entweder einfach per Call von EGLProgrammen aus aufgerufen werden.
Somit ist gar keine Migration von Code im ursprünglichen Sinne nötig. Es wird einfach alles "Neue" in EGL entwickelt und vorhandene RPG-Batches per Call in die Neuentwicklung eingebunden - eine elegante und kostengünstige Lösung, wenn die System i-Plattform Bestand haben soll. Wenn eine plattformneutrale Anwendung angestrebt wird, dann muss der RPG-Batch mit RMEi nach EGL migriert und mittels einer Service Library gekapselt werden.
RPG-Service-Programme können analog dazu auch sehr einfach in eine EGL-Neuentwicklung integriert werden:
Hierzu bietet EGL sogenannte "Wrapper" an). Aber natürlich können auch solche Programme mit RMEi in "native EGL" migriert und somit plattformunabhängig gefahren werden. Bisher ist alles noch recht einfach.
Doch was passiert mit den interaktiven RPG-Programmen? Denn schließlich kommt hier der monolithische Aufbau von RPG-Anwendungen in der Regel richtig zum Tragen. Im ersten Schritt wird mit einem Server Builder Tool die RPG-Anwendung vom 5250 User Interface entkoppelt. Die RPG-Anwendung arbeitet dann über API-Funktionen und bedient direkt ein Web- oder Windows- Frontend. Das Frontend basiert auf einer XML-Konfiguration, bietet zahlreiche Möglichkeiten zur modernen Gestaltung von User Interfaces und ist mit minimalem Aufwand zu realisieren.
Im zweiten Schritt können die RPG-Programme mit RMEi nach EGL migriert werden. Das migrierte EGLProgramm kann auch das API fürs Frontend nutzen wie das ursprüngliche RPG-Programm. Durch eine Bridging- Funktionalität des API ist es darüber hinaus möglich, neue Oberflächen in native EGL zu schreiben und mit APIGUI nahtlos zu integrieren. Die Anwender können nicht sehen, hinter welcher Maske sich "Noch-RPG" oder "Schon- EGL" verbirgt. Gleichzeitig kann durch manuelles bzw. Tool-unterstützes Vorgehen die monolithische Alt-Anwendung in eine "reine SOA" zerlegt und umgebaut werden.
Es bietet sich also eine reiche Vielfalt an Möglichkeiten, die es jedem Kunden ermöglicht, die Modernisierung auf Basis von EGL an seinem Bedarf, seinem Budget und den Zeitvorgaben für ein solches Vorhaben auszurichten.
Aufbauend auf den Erfahrungen der bisherigen Projekte empfiehlt IBM ein Sechsschritt-Vorgehen:
1. Bauen Sie EGL-Know-how im Team auf und sammeln Sie praktische Erfahrung in der EGL-SW-Entwicklung.
2. Konvertieren Sie im Rahmen eines Prototyps ein vorhandenes RPGProgramm nach EGL.
3. Führen Sie eine komplette und umfassende Analyse aller vorhandenen Anwendungen durch.
4. Führen Sie ein Proof-of-Concept für einen kleinen Bereich Ihrer Anwendungen durch.
5. Überführen Sie Ihre Bestandsanwendungen anhand der Ergebnissen aus der Analysephase nach EGL.
6. Nutzen Sie die Vorteile der "Neuen Welt", nachdem es Ihnen gelungen ist, Geschaffenes zu bewahren und in die Zukunft zu überführen.
Unterstützung bei diesem Vorgehen bieten IBM und lokale EGL-Partner online unter
www-949.ibm.com/software/rational/cafe/index.jspa
