Software Modernisierung: Überbegriff für: die Migration von Legacy-Anwendungen auf eine neue Plattform, Erneuerung/Ersatz von Datenzugriffs- und Präsentations-Layer, Architektur-Überarbeitung und Modularisierung für die Integration in eine service-orientierte Architektur (SOA, Service Enablement, Datenintegration), (Teil-)Ersatz mit Standard-Software und/oder neuen Programmiersprachen.

Modernisierung hat viele Gesichter

Wir gliedern Modernisierungs-Vorgaben in folgende Gruppen auf:

• Migration/Portierung von bestehenden Anwendungen auf eine neue Plattform
  
• Erneuerung der Präsentations-Schicht (Presentation Layer)
  
• Auslagerung der Datenzugriffs-Schicht, Ersatz des Datenhaltungs-Systems (Data Access Layer)
• Modularisierung von monolithischen Anwendungen (Reengineering, Refactoring)
• Einbindung von (Teil-)Anwendungen in eine service-orientierte Architektur (Service Enablement)

Oft ist es so, dass man aufs Mal mehr als einen Aspekt der Anwendung modernisiert; dass z.B. die Plattform ausgetauscht wird und - dadurch bedingt - das Datenhaltungs-System ersetzt werden muss. Was in einer Modernisierung gemacht wird, ist von Fall zu Fall verschieden. Die Kunst der Modernisierung besteht darin, sichere und optimale Wege zum Ziel zu finden, ohne sich zu übernehmen.

Mit unserem Lösungs-Ansatz der «In-Place» Migration können Anwendungen während der laufenden Modernisierung normal weiter gewartet werden (no freeze), es gibt keinen «Big Bang», Sie bestimmen den Zeitpunkt des Wechsels auf eine neue Ziel-Plattform. Die Modernisierung hat keinen Einfluss auf das produktive System und der Testaufwand kann erheblich gesenkt werden.

Plattform-Migration (Migration/Portierung)

Eine Anwendung soll - ohne Erweiterung der bestehenden Funktionalität - von einer Hardware-Plattform auf eine Andere migriert werden. Selbst bei dieser im ersten Moment 'einfach' erscheinenden Migration stossen wir bei genauerem Hinsehen auf grosse, wenn auch nicht unlösbare Probleme, denn: Plattform-spezifische, proprietäre Zugriffe auf Middleware, TP Monitore, Datenhaltung und Bildschirm-Ein- und Ausgabe müssen ausgewechselt werden.

Beispiele:

• von UNISYS Mainframe auf Windows
• von IBM z/OS auf Unix oder Linux

Anforderungen an die Transformation / Was muss geändert werden?

• Systemspezifische Funktionen mit Zugriff auf die Hardware, z.B. in Assembler, muss für die neue Ziel-Plattform in einer anderen Programmiersprache implementiert werden.
• Aufrufe des systemspezifischen Transaktions-Monitors.
• Anpassungen an den Programmiersprachen-Dialekt der Ziel-Plattform.
• Migration der Job-Control.
• eventuell: Wechsel auf die vom Zielsystem unterstützten Datenhaltungs-Systeme.
• eventuell: Wechsel auf den vom Zielsystem unterstützten Presentation Layer.

Datenbank-Migration (Data Access Layer)

Datenhaltungs-System auswechseln

Klassische Beispiele sind: der Wechsel von IMS [IBM], CODASYL [DMS 1100, DMS 2200] auf Oracle, DB2 oder MS SQL oder die Migration von «Flat files» auf eine relationale Datenbank.

Anforderungen an die Transformation / Was muss geändert werden?

• Vorhandene Datenzugriffe werden durch den Aufruf von Datenzugriffen, die das gleiche Resultat liefern, ersetzt.
• SQL nach SQL: Das kann beim Ersatz eines SQL-Dialekt-Statement durch einen anderes SQL-Dialekt-Statement (noch) relativ einfach sein. Probleme können hier auftauchen bei der Deklaration von Statusfeldern, beim Error-Handling, bei Datenfeldern, die als Interface zum jeweiligen Datenbank-System deklariert sind.
• Viel schwieriger wird die Umstellung von einer hierarchischen oder Codasyl-Datenbank oder von «Flat files» auf eine relationale Datenbank.
• In den meisten Fällen erscheint es sinnvoll, die Daten-Zugriffe in eigenständige Datenzugriffs-Module auszulagern und Datenzugriffe im Anwendungsprogramm zu 'neutralisieren' durch eine «In-Place» Migration.

Datenzugriffe als Services auslagern

In vielen Anwendungen sind Datenbank-Zugriffe eingebettet in den prozeduralen Ablauf innerhalb der Business-Logik. Durch eine Auslagerung in eigenständige Datenzugriffs-Module kann die Wiederverwendung von Datenzugriffen als eigentliche Datenzugriffs-Services implementiert werden, auch aus heterogenen Umgebungen unterstützt werden. Bei einem absehbaren Wechsel des Datenhaltungs-Systems ist ausserdem der Wechsel bedeutend einfacher, weil an der Business-Logik nichts geändert werden muss.

Anforderungen an die Transformation / Was muss geändert werden?

• Datenzugriffe suchen, klassifizieren (lesend, schreibend), als Operationen und zugehörige Operations-Parameter in einem ausgelagerten (generierten) Datenzugriff-Moduls zur Verfügung stellen.
• Vorhandene Datenzugriffe werden durch den Aufruf der entsprechenden Operationen und zugehörige Operations-Parameter des Datenzugriff-Moduls ersetzt bzw. 'neutralisiert.

Durch die Ausprägung als eigentliche Datenzugriffs-Services kann darauf aus anderen Applikationen (Datenintegration), aus heterogenen Umgebungen und mit anderen Programmiersprachen zugegriffen werden (Service Enablement).

User-Interface-Migration (Presentation Layer)

Presentation Layer ersetzen

Konventionelle Ein- und Ausgabemasken («green screen», 3270-Terminal-Layout) werden durch ein GUI («Grafical User Interface») oder ein Web-Interface ersetzt.

Anforderungen an die Transformation / Was muss geändert werden?

• Masken-Definitionen, Layout-Namen und die zugehörigen Datenfelder ermitteln und in das von der Ziel-Plattform unterstützte Format konvertieren.
• Aufrufe des Display Processing System suchen, Funktion ermitteln (Ein-/Ausgabe), Funktionen kapseln.

Presentation Layer migrieren

Konventionelle Ein- und Ausgabemasken («green screen», 3270-Terminal-Layout) müssen an das Display Processing System der Ziel-Plattform angepasst werden.

Anforderungen an die Transformation / Was muss geändert werden?

• Wechsel auf den vom Zielsystem unterstützten Presentation Layer
• Anpassungen an den Programmiersprachen-Dialekt der Ziel-Plattform
• Masken-Definitionen in das von der Ziel-Plattform unterstützte Format konvertieren.
• Aufrufe des Display Processing System suchen, Funktion ermitteln (Ein-/Ausgabe)
• Layout-Name und die zugehörigen Datenfelder ermitteln und in das von der Ziel-Plattform unterstützte Format konvertieren.

Software-Architektur-Migration (Reengineering, Service Enablement)

Ein neues Standard-Softwarepaket oder neue, im heterogenen Umfeld neu erstellte Software soll auf bestehende und bewährte Teile bzw. Funktionen einer Legacy-Anwendung zugreifen können (Service Enablement). Die Tatsache, dass viele dieser Anwendungen als monolithische Programme erstellt sind, verhindert einen 'einfachen' Zugriff und liefert daher ein wichtiges Argument um ein monolithisches Programm in die heute in der Software-Entwicklung üblichen Schichten Präsentation (Presentation Layer), Verarbeitung (Business Logic) und Datenzugriffe (Data Access Layer) aufgeteilt werden soll. Ein weiterer Vorteil ist sicher die einfachere Wartung.

Anforderungen an die Transformation / Was muss geändert werden?

• Anpassungen an den Programmiersprachen-Dialekt der Ziel-Plattform
• Migration der Job-Control
• eventuell: Wechsel auf die vom Zielsystem unterstützten Datenhaltungs-Systeme
• eventuell: Wechsel auf den vom Zielsystem unterstützten Presentation Layer

Modernisierung automatisieren

Automatisierung ist das beste Mittel zur Produktivitäts- und Quali­täts­verbesserung und den Testaufwand erheblich zu senken.

Ein Grossprojekt bei RDW, der nationalen Kraftfahrzeugverwaltung der Niederlande, hat gezeigt: eine 100%-ige Automation der Änderungen konnte den Testaufwand um mehr als 90% reduzieren.