Viel wurde in den letzten Jahren um die Zukunft der bewährten Sprachen der 3. Generation (3GL) - also Cobol, RPG, VAGen u.ä. - spekuliert. Java hieß die Marschrichtung für alle neu zu entwickelnden Anwendungen. Fakt ist aber, dass bis heute weltweit Milliarden an Lines of Code in 3GL-Sprachen die Geschäftsprozesse von vielen Kunden sicherstellen.
Wohin aber die bewährten und stabilen Alt-Anwendungen überführen? Und die Entwickler mit dazu! Die Migration nach Java war oft mehr als ernüchternd - aus einem simplen Grund: dem Paradigmenbruch zwischen prozeduraler und objektorientierter Welt. Viele sagen: Eine Brücke zwischen diesen Welten sei überhaupt nicht zu bauen. Und trotzdem oder gerade deswegen stehen zahlreiche CIOs auch im Jahre 2008 vor der Herausforderung, die in die Eigenentwicklung getätigten Investitionen in die Zukunft zu retten, und eben nicht auf Standard-Software umzusteigen. Denn gerade die Marktführer vieler Branchen beweisen, dass sie sich nur durch das strategische Festhalten an der Individualsoftware maßgeblich vom Mitbewerb differenzieren, schneller auf neue Marktanforderungen reagieren und somit langfristig vom Mainstream absondern können.
Ein Werkzeug das diese vielschichtigen Bedarfe adressiert muss heute also mehr bieten als native Java und "etwas anderes" als die klassischen 3GLs. Es muss eine Business-Sprache sein, die sowohl den Client- als auch den Server-seitigen Bedarf bei der Entwicklung von Geschäftsanwendungen adressiert: Moderne Frontends müssen ebenso erstellt werden können wie performante Batch-Programme. Natürlich sollten die erstellten Anwendungen auf der heute gängigen Model-View-Controller-Architektur basieren und damit die ideale Voraussetzung für die Umsetzung einer Service-orientierten Architektur (SOA) bieten. Und auch die vorhandenen Entwicklerteams - sowohl ältere Legacy-Programmierer als auch junge Java-Freaks - müssen von dem Werkzeug begeistert sein um schon nach wenigen Wochen gemeinsam und produktiv damit arbeiten zu können.
Wenn man eine Sprache und Entwicklungsumgebung gefunden hat, die den genannten Anforderungen gerecht wird (wie dies z.B. die Enterprise Generation Language der IBM tut), dann muss ein sicherer Weg gefunden werden, um die vorhandenen Legacy-Anwendungen in die neue Welt zu bringen. Jedoch gilt zu beachten, dass eine "Big Bang" Migration selten im Tagesgeschäft integriert werden und somit von vornherein zum Scheitern verurteilt ist. Gefragt ist daher ein sehr sanftes und doch nachhaltiges Konzept: vom Wrapping vorhandener Programme bis hin zur tatsächlichen Code-Migration und sogar bis zum Re-Factoring muss ein kundenindividueller Mix gewählt werden. Tools sollten zudem das Vorhaben unterstützen, um die Testaufwände auf Kunden- und Anwenderseite im Griff behalten zu können. Zu Beginn jedes Migrationsprojekts steht daher eine ausführliche Analysephase um aus den verschiedenen Komponenten die Vorgehensweise festzulegen. Folgende Komponenten sind dabei zu betrachten:
- Nutzung von Bridging-Technologien für die Integration auf Ebene des User-Interfaces. Dies ist angeraten wenn:
o Der Anwender sehr schnell ein neues Frontend erhalten soll und keinen Unterschied im Workflow sowie im Look-and-Feel spüren soll zwischen Alt- und Neu-System o Im zweiten Schritt kann dann die Sprache der Anwendung migriert werden und abschließend kann auch das User-Interface komplett neu geschrieben werden, falls dies gewünscht wird
- Integration von alter und neuer Anwendung auf Datenbank-Ebene und über Program-Calls. Dies ist angeraten wenn:
o zusätzliche Business-Anforderungen sehr schnell umgesetzt werden müssen und keine Zeit bleibt, die Alt-Anwendung zu migrieren. Mit "Wrappern" kann dann sehr elegant eine Kopplung realisiert werden auf Basis des WebServices-Standards o für die Alt-Anwendung kaum greifbare Dokumentation besteht und diese ohnehin schrittweise neu entwickelt werden muss
- Migration auf Ebene der Programmiersprache und der Datenbank Dies ist angeraten wenn:
o Die zu migrierenden Anwendungsbereiche noch ständig angepasst, gewartet und weiterentwickelt werden müssen, es aber aufgrund von Knowhow-Verfügbarkeit in der "Alt-Sprache" sehr aufwendig geworden ist o Die Anwendung schnell plattformunabhängig zur Verfügung gestellt werden soll o Eine einheitliche Code-Basis benötigt wird, um z.B. die Weiterentwicklung auszulagern o Kosteneinsparungen durch die optimierte Nutzung spezieller Hardware-Varianten erzielt werden sollen (insb. im Mainframe-Umfeld)
Durch einen nachhaltigen Migrationsprozess kann die Lebensdauer einer Anwendung typischerweise um 10 bis 15 Jahre verlängert werden. Das wiederum ergibt sehr attraktive Rechnungen hinsichtlich des Return on Asset, also der Investitionen, die schon in die Anwendungsentwicklung geflossen sind und die durch die Migration nicht verloren gehen sondern geschützt werden.
Wohin aber die bewährten und stabilen Alt-Anwendungen überführen? Und die Entwickler mit dazu! Die Migration nach Java war oft mehr als ernüchternd - aus einem simplen Grund: dem Paradigmenbruch zwischen prozeduraler und objektorientierter Welt. Viele sagen: Eine Brücke zwischen diesen Welten sei überhaupt nicht zu bauen. Und trotzdem oder gerade deswegen stehen zahlreiche CIOs auch im Jahre 2008 vor der Herausforderung, die in die Eigenentwicklung getätigten Investitionen in die Zukunft zu retten, und eben nicht auf Standard-Software umzusteigen. Denn gerade die Marktführer vieler Branchen beweisen, dass sie sich nur durch das strategische Festhalten an der Individualsoftware maßgeblich vom Mitbewerb differenzieren, schneller auf neue Marktanforderungen reagieren und somit langfristig vom Mainstream absondern können.
Ein Werkzeug das diese vielschichtigen Bedarfe adressiert muss heute also mehr bieten als native Java und "etwas anderes" als die klassischen 3GLs. Es muss eine Business-Sprache sein, die sowohl den Client- als auch den Server-seitigen Bedarf bei der Entwicklung von Geschäftsanwendungen adressiert: Moderne Frontends müssen ebenso erstellt werden können wie performante Batch-Programme. Natürlich sollten die erstellten Anwendungen auf der heute gängigen Model-View-Controller-Architektur basieren und damit die ideale Voraussetzung für die Umsetzung einer Service-orientierten Architektur (SOA) bieten. Und auch die vorhandenen Entwicklerteams - sowohl ältere Legacy-Programmierer als auch junge Java-Freaks - müssen von dem Werkzeug begeistert sein um schon nach wenigen Wochen gemeinsam und produktiv damit arbeiten zu können.
Wenn man eine Sprache und Entwicklungsumgebung gefunden hat, die den genannten Anforderungen gerecht wird (wie dies z.B. die Enterprise Generation Language der IBM tut), dann muss ein sicherer Weg gefunden werden, um die vorhandenen Legacy-Anwendungen in die neue Welt zu bringen. Jedoch gilt zu beachten, dass eine "Big Bang" Migration selten im Tagesgeschäft integriert werden und somit von vornherein zum Scheitern verurteilt ist. Gefragt ist daher ein sehr sanftes und doch nachhaltiges Konzept: vom Wrapping vorhandener Programme bis hin zur tatsächlichen Code-Migration und sogar bis zum Re-Factoring muss ein kundenindividueller Mix gewählt werden. Tools sollten zudem das Vorhaben unterstützen, um die Testaufwände auf Kunden- und Anwenderseite im Griff behalten zu können. Zu Beginn jedes Migrationsprojekts steht daher eine ausführliche Analysephase um aus den verschiedenen Komponenten die Vorgehensweise festzulegen. Folgende Komponenten sind dabei zu betrachten:
- Nutzung von Bridging-Technologien für die Integration auf Ebene des User-Interfaces. Dies ist angeraten wenn:
o Der Anwender sehr schnell ein neues Frontend erhalten soll und keinen Unterschied im Workflow sowie im Look-and-Feel spüren soll zwischen Alt- und Neu-System o Im zweiten Schritt kann dann die Sprache der Anwendung migriert werden und abschließend kann auch das User-Interface komplett neu geschrieben werden, falls dies gewünscht wird
- Integration von alter und neuer Anwendung auf Datenbank-Ebene und über Program-Calls. Dies ist angeraten wenn:
o zusätzliche Business-Anforderungen sehr schnell umgesetzt werden müssen und keine Zeit bleibt, die Alt-Anwendung zu migrieren. Mit "Wrappern" kann dann sehr elegant eine Kopplung realisiert werden auf Basis des WebServices-Standards o für die Alt-Anwendung kaum greifbare Dokumentation besteht und diese ohnehin schrittweise neu entwickelt werden muss
- Migration auf Ebene der Programmiersprache und der Datenbank Dies ist angeraten wenn:
o Die zu migrierenden Anwendungsbereiche noch ständig angepasst, gewartet und weiterentwickelt werden müssen, es aber aufgrund von Knowhow-Verfügbarkeit in der "Alt-Sprache" sehr aufwendig geworden ist o Die Anwendung schnell plattformunabhängig zur Verfügung gestellt werden soll o Eine einheitliche Code-Basis benötigt wird, um z.B. die Weiterentwicklung auszulagern o Kosteneinsparungen durch die optimierte Nutzung spezieller Hardware-Varianten erzielt werden sollen (insb. im Mainframe-Umfeld)
Durch einen nachhaltigen Migrationsprozess kann die Lebensdauer einer Anwendung typischerweise um 10 bis 15 Jahre verlängert werden. Das wiederum ergibt sehr attraktive Rechnungen hinsichtlich des Return on Asset, also der Investitionen, die schon in die Anwendungsentwicklung geflossen sind und die durch die Migration nicht verloren gehen sondern geschützt werden.
