Business Case:

Grundsätzliche und technologische Probleme durch den Einsatz von veralteten Technologien und das fehlende Know-How.

Ursprungsarchitektur:

COBOL und Fortran

Zielarchitektur:

ORACLE, PL/SQL, aber weiterhin auch COBOL, teilweise Fortran, C

Lösung:

Migration der Daten nach ORACLE. Die alten DB Prozeduren wurden nach PL/SQL migriert. Die ursprünglichen COBOL und Fortran Call Syntax blieb bestehen.

Herausforderung:

DIe ursprünglichen RDB Aufrufe waren in ORACLE nicht einsetzbar. Diese wurden mit C ersetzt und aus den C-Programmen wurden die PL/SQL Prozeduren aufgerufen.

Unsere Rolle:

Die Analyse des Systems, das Erstellen des Konzepts und der Architektur. Anschließend die Durchführung der Transformation.

Business Case

Auf AS400 liefen in RPG 5 Millionen LOC (Lines of Code).
Das gesamte Geschäft basierte auf diesen Programmen, und zur Betreuung standen nur wenige externe RPG Programmierer zur Verfügung. Es entstand eine enorme Abhängigkeit und es gab keine Anwendung und Programmdokumentation. Bei Vorgaben durch den Gesetzgeber mussten Änderungen im Programm gemacht werden, die nur mit einem enormen Aufwand hätten durchgeführt werden können.

Ursprungsarchitektur:

Teilweise AS 400 und zum Teil RPG.

Zielarchitektur:

Technische Spezifikationen und teilweise Technologien bleiben auf Kundenwunsch geheim.
Das System musste dokumentiert werden.  Entstehung einer Repository. Bereitstellung von verschiedenen Informationen aus der Repository für dynamische Abfragen.

Herausforderung:

Durchführung der Analyse mit dem Application Understanding für RPG. Verfolgung der Lifecycles von Input bis Output.

Lösung:

Anpassung des Application Understanding Analyzers an RPG. Danach eine Ablösung des Systems durch eine Standardsoftware und eine Transformation des Altprogramms.

Ziel war außerdem die Durchführbarkeit von Changes und die Instandhaltung  zu vereinfachen. Im Rahmen dessen wurde eine Anpassung des Change & Maintenance-Prozesses durchgeführt.
Die  Ablösung der alleinigen Wissensträger wurde im Rahmen des Prozesses  angestrebt, die Verlagerung des Know-Hows war für den Kunden ebenfalls ein must-have.

Unsere Rolle:  

Durchführung der Analyse mit dem Application Understanding. Das einbringen von weiteren RPG Entwicklern. Die Dokumentation des Systems. Die Erstellung eines Pflichten -und Lastenheftes anhand der durchgeführten Analyse. Empfehlungen und Beratung zur Anpassung des Change & Maintenance-Verfahrens.

Business Case

Zu hohe Lizenzkosten für bestehende Systeme und veraltete Technologie. Das fehlende Know-How für bestehende Systeme.

Ursprungsarchitektur:

Informix Datenbanken und Applikationen basierend auf Informix 4GL

Zielarchitektur:

ORACLE Datenbanken und Java Applikation.

Lösung:

Eine Datenbanktransformation und eine automatisierte Applikationskonvertierung.

Herausforderung:

Die Erstellung des Informix 4GL nach Java Konverters.

Unsere Rolle:  

Durchführung der DB Transformation und der Applikationskonvertierung.

Business Case:

Die Lizenzkosten waren  zu hoch. Der Kunde hatte hier zusätzlich die Anforderung zur einer Managementberatung mit einem POC.

Ursprungsarchitektur:

Mainframe DB2/DWH. ETL Prozess in COBOL.

Zielarchitektur:

ORACLE/UNIX. Neue DWH Architektur, mit  DATAMART. COBOL als Sprache ist geblieben.

Lösung:

Ein POC mit den COBOL ETL Programmen, die mit unserem Precompiler nach ORACLE migriert wurden. Dies beinhaltete die Datenbank und Datenmigration.

Herausforderung:

Anpassung der Precompiler Technologie an DB2 aus der ursprünglichen INFORMIX Precompiler Technologie.

Unsere Rolle:

Analyse und Beratung des Kunden, die Konzepterstellung und die Planung der neuen Architektur, die Datenmigration und ETL (Extract Transform and Load) Migration.

Business Case:
Drei Bereiche beim Kunden mussten organisatorisch getrennt werden. Anforderung war ein einheitlicher IT-Support, der alle drei Bereiche unabhängig bedienen kann.

Ursprungsarchitektur:

Das Stammdatensystem wurde von allen IT-Systemen genutzt. Dies beinhaltete dynamische IDMS Tabellen.  Die CiCS COBOL/IDMS/DB2 Anwendungen liefen auf einer zOS Mainframe.

Zielarchitektur:

CiCS COBOL, Websphere (WOLA), Remote DB2 Access, Java.

Lösung:

Die CiCS COBOL / IDMS /DB2 Anwendung auf einem zOS Mainframe mussten dividiert werden, so dass die original Anwendung CiCS COBOL geblieben ist.

Das IDMS/DB2 Zugriffsmodul musste getauscht werden, so dass kein Zugriff auf die IDMS/DB2 Datenbanken passiert, sondern das auf alles über Websphere (Optimal Local Adapter / WOLA) Remote DB2 zugegriffen wird. Die Maintenance wurde von Java Applikationen durchgeführt und der Datenzugriff passierte über ein persistency layer.

Herausforderung:

Der Tausch des Zugriffsmoduls mit Zugriff über Websphere.

Unsere Rolle:
Die Erstellung des technischen Konzepts, das Design und die Durchführung.

Es waren nicht mehr unterstützte Datenbanken im Einsatz, die eine technologische Begrenzung darstellten. Geschäftliche Anforderungen konnten nicht implementiert werden. Die eingesetzte Technologie verhinderte das Geschäftswachstum.

Ursprungsarchitektur:

4.000 COBOL Programme mit Zugriff und Schnittstellen auf Informix Datenbanken. PHP Frontend, Shell Skripte, Online und Batch processing.

Zielarchitektur:

ORACLE Datenbanken, 4.000 COBOL Programme mit Zugriff und Schnittstellen auf die ORACLE Datenbanken. PHP Frontend, Shell Skripte, Online und Batch processing.

Die abteilungsspezifischen Anwendungen griffen nach wie vor auf die Informix Datenbanken zu. Es wurden nur die operativen Informix Datenbanken abgelöst. Nicht servicekritische und abteilungsspezifische Informix Datenbanken wurden nicht  abgelöst.

Lösung:

Eine Datenmigration von Informix nach ORACLE.

Erstellung einer zusätzlichen ORACLE Datenbank Zugriffsschicht mit Runtime Parsing. Basierend auf OCI und geschrieben in C.

Eine Master-Master Replikation.

Herausforderung:

Das Schreiben des Runtime Parsers, die Master-Master Replikation. Die JDBC Java Lösung mit Multi-Threading 

Unsere Rolle:

Analyse der IT-Komponenten inklusive der Applikationen. Die Erstellung des Runtime Parsers und des Replikationstools. Das Schreiben des Precompilers für die COBOL Programme. Die Datenbankanalyse/Architektur  und die Datenbankmigration.

Business Case:

Diverse Abteilungen des Kunden hatten eigene Mission Critical Anwendungen, die auf Informix Datenbanken basierten. Das zentrale und operative System wurde bereits auf ORACLE umgestellt. Für die Informix Datenbanken bestand kein Support mehr. 

Eine künstliche Schnittstelle zwischen ORACLE und Informix musste geschaffen werden. Diese Umformung wurde nötig, weil ein neues Datawarehouse (DWH) System entwickelt wurde, das von diesen Fachabteilungen mit Informationen beliefert werden musste, welches aber eigentlich nur aus der ORACLE Architektur heraus möglich war.

Ursprungsarchitektur:

Informix Datenbanken, SQL Skripte, SQL Reports, Shell Skripte, Cronjobs.

Zielarchitektur:

ORACLE Datenbanken, ORACLE SQL, PL/SQL, ORACLE scheduler und UNIX Shellskripte.

Lösung:

Automatisierte Konvertierung der SQL Skripte. Einrichtung der Shell Skripte und ORACLE Scheduler. Ein Parallelbetrieb mit automatisierten Testfällen, die anhand eines vorgefertigten Templates der Fachabteilung generiert wurden. Vollautomatisierte Auswertung der Testergebnisse, eine Überprüfung ob die ORACLE Ergebnisse den Informix Daten entsprechen.

Herausforderung:
Eine Betriebs -und Geschäftsdowntime waren nicht erlaubt.

Der Testcase und SQL Konverter mussten angepasst werden. Der automatisierte Test-Result-Abgleich. Bei jedem neuen Lauf und bei jedem neuen Ergebnis mussten während des Parallelbetriebes täglich 4.000 Testfälle automatisch durchgeführt werden. Die Schritte bestanden aus Erstellen, Ausführen und Ergebnisse/Abweichungen überprüfen.

Unsere Rolle:

Die Analyse, das Design und die komplette Durchführung. Die Erstellung des SQL Konverters, des Testfallgenerators und die Ergebnisauswertung.

Ausgangspunkt waren technologiebasierte Probleme mit der Applikation und der IT-Infrastruktur. 

Der Kunde hatte ein Buchungssystem, das nicht dem neuesten technologischen Standard entsprach und dadurch nicht performant war.

Die neue Zielarchitektur war Oracle, mit einer Zugriffsschicht die mit PL/SQL generiert wurde.

Der ISAM Zugriff, die Files und der Datenzugriff mussten alle mit ORACLE ersetzt werden. Der ORACLE Zugriff wurde mit einer PL/SQL Zugriffsschicht gelöst. Hierbei wurde der Datenzugriff nicht Konvertiert, sondern in den neuen Quellcode generiert.

Es wurde eine neue Datenzugriffsschicht angelegt. Diese Schicht wurde aus Templates generiert und statt des ISAM Zugriffs wurde eine ORACLE Zugriffsschicht mit PL/SQL angelegt. Damit wurden im COBOL Programm die Calls dieser PL/SQL Zugriffsschichten aufgerufen. Der Aufruf dieser Zugriffsschicht wurde ebenfalls in das COBOL Programm generiert.

Downtimes im Betrieb und in der Applikation waren nicht erlaubt. Die bekannten ISAM Strukturen mussten in der selben Form erhalten bleiben. Das Verhalten musste ganz genau auf die relationalen Tabellen abgebildet werden. Das Verhalten der alten COBOL Applikation musste exakt dem Originalverhalten entsprechen.

Diverse Abteilungen des Kunden hatten eigene Mission critical Anwendungen, die auf Informix Datenbanken basierten. Das zentrale und operative System wurde bereits auf ORACLE umgestellt. Für die Informix Datenbanken bestand kein Support mehr. Eine künstliche Schnittstelle zwischen ORACLE und Informix musste geschaffen werden. Diese Umformung wurde nötig, weil ein neues Datawarehouse (DWH) System entwickelt wurde, das von diesen Fachabteilungen mit Informationen beliefert werden musste, welches aber eigentlich nur aus der ORACLE Architektur heraus möglich war.

Automatisierte Konvertierung der SQL Skripte. Einrichtung der Shell Skripte und ORACLE Scheduler. Ein Parallelbetrieb mit automatisierten Testfällen die anhand eines vorgefertigten Templates der Fachabteilung generiert wurden. Vollautomatisierte Auswertung der Testergebnisse, eine Überprüfung ob die ORACLE Ergebnisse den Informix Daten entsprechen.

Die Benutzung einer konsolenbasierten Lösung führte zu technischen und prozessualen Problemen bei Benutzern und dem IT-Betrieb.

Die Applikation wurde in ADABAS/NATURAL geschrieben und damit war es schwierig geeignete Entwickler für die weitere Entwicklung der Applikation und IT-Landschaft zu finden. Daneben waren die Lizenzkosten sehr hoch. Die Anmeldung für die Mitarbeiter sollte über ein Portal passieren und nicht über eine veraltete Konsole.

Analyse, Ausarbeitung von Transformationsalternativen und Strategien im Step-by-Step Approach. Durchführung der Transformation. Erstellung und Realisierung eines Fallback und Master/Master Replikationskonzepts.

Die Transformation der COBOL und RPG Programme nach Java. Die Migration der DB2 Datenbanken nach ORACLE.

Erwünscht war eine ROI von maximal einem Jahr. Die toolbasierte COBOL-Java Transformation an sich war eine große Herausforderung und die Umgebung war extrem komplex. Es wurde ebenfalls eine externe Software über eine Schnittstelle angesprochen, die Betrugsfälle analysierte und fand. Diese Integration musste ebenfalls  durchgeführt werden und die neue Applikation und neuen Programme mussten die Schnittstelle einwandfrei bedienen können.

Analyse der bestehenden IT-Landschaft.  Ausarbeitung von Migrationsstrategien im Step-by-Step Approach. Durchführung der Transformation mit maximal einem ROI von einem Jahr.