Migration des Debeka-Software-Repositorys auf ein RDMBS

Transkript

1 Migration des Debeka-Software-Repositorys auf ein RDMBS Johannes Bach, Martin Schulze Debeka-Hauptverwaltung, Abteilung IE/Q Workshop Software-Reengineering Bad Honnef,

2 Agenda Einsatz und Nutzen des Debeka-Repositorys Migration von Rochade auf Oracle Fazit Fragen & Diskussion Folie 2

3 Aufgaben der Abteilung IE/Q Konzeption, Realisierung und Wartung der Debeka- Entwicklungsumgebung (Prozesse und Werkzeuge) COBOL-Editor, COBOL-Workbench DB-Modellierung, Testumgebung, Versionsverwaltung,... Entwicklung und Betrieb des zentralen Software- Repositorys Evaluation und Auswahl von Methoden und Werkzeugen Vorgaben und Richtlinien für Entwicklung, Dokumentation,... Folie 3

4 Einsatz und Nutzen: Inhalte Abbildung der DV-Landschaft: Bull-Großrechner- Anwendungen (GCOS), dezentrale Systeme (AIX), Web-/Java-Anwendungen Inhalte: insgesamt ca. 2 Mio. Objekte DV-Objekte: Programme, Copybooks, Jobs, Masken, permanente Dateien (ca DV-Objekte) Datenbank-Schemata, Datei-Strukturen, Schnittstellen Entwicklungs-Aufträge, Stammdaten (ca Aufträge) Programm-, System- und Auftragsdokumentation (Verweise auf externe Office-Dokumente) Folie 4

5 Einsatz und Nutzen: Nutzung Tägliche Arbeit Information über DV-Objekte, Datenbanken und Dateien und Analyse von Abhängigkeiten und Schnittstellen Steuerung des Software-Entwicklungsprozesses: Auftragsbearbeitung, Freigabe, Anstoß Produktionsübernahme DB-Administration (Changemanagement) Reengineering-Projekte Jahr 2000, EURO-Einführung, Migration der Großrechner- Software auf Unix-Cluster Projektarbeit: Konsolidierung und Zusammenführung Folie 5

6 Einsatz und Nutzen: Werkzeuge Repository-Browser Zepra (Auftragswesen) PC (Windows) CASE- Werkzeug Repository-Server (Linux) Scanner, Importer DB-Admin-Tools Netzlaufwerk Browser Zepra Repository-Datenbank Großrechner (GCOS) Scanner Programm COBOL- Scanner Job/Task JCL- Scanner FTP Importer SOLD-DB Masken- Scanner Folie 6

7 Migration: Ausgangspunkt Anfang 2005 Repository-System Rochade (Allen Systems Group / ASG) erfüllt nicht mehr die Anforderungen der Debeka nicht ausreichende Flexibilität, Konsistenzsicherung unklare Konzepte, unzureichende Dokumentation proprietäre Technologie, zusätzlicher Administrationsaufwand Zukunft von Produkt und Hersteller unklar Browser, Zepra, DB-Admin-Tools: Visual-Basic-Anwendungen Scanner: C-/COBOL-Programme, diverse Skripte Folie 7

8 Migration: Zielsystem "ZEDER" Austausch der Rochade-Datenbank durch Oracle-DB Übernahme der Modelle, Einführung Vererbungskonzept, Verweiskonzept API zur Konsistenzsicherung für alle Anwendungen Neuimplementierung Browser, Zepra und Importer in Java Weiterbetrieb der Scanner Weiterbetrieb der DB-Admin-Tools auf Rochade, Implementierung eines Synchronisierungswerkzeugs Laufzeit des Vorhabens: 1,5 Jahre (6 Personen) Folie 8

9 Migration: Ablauf Neuscannen aller DV-Objekte, gleichzeitig weiter normale Produktionsübernahme (5 Wochen) Import der gesammelten Scan-Ergebnisse (10 Tage) Umstellungswochenende: Datenmigration (4 Tage) Migration der Entwicklungsaufträge und der Stammdaten Migration der Beziehungen zwischen DV-Objekten und Aufträgen sowie der externen Dokumente Migration manuell eingetragener Attribute Synchronisierung der DB-Informationen (1 Tag) Folie 9

10 Migration: Herausforderungen in der Vorbereitung Datenqualität in Rochade unzureichende Konsistenzchecks "Leichen" manuelle Korrekturen aufgrund der Menge schwierig undokumentierte "Features" Modellierung Erhöhung der Komplexität durch Einführung der Vererbungshierarchie und des Verweiskonzepts Verbesserung der Modellierung bei Beibehaltung der Scanner Folie 10

11 Migration: Herausforderungen bei der Durchführung Nur eingeschränkter Parallelbetrieb von Rochade und ZEDER Problem: Auftragswesen, Produktionsübernahme Rückkehr zu Rochade kaum möglich Lange Laufzeiten der Migrationswerkzeuge, des Importers und des Synchronisierungswerkzeugs Schwer durchschaubare Abhängigkeiten zwischen den Migrationswerkzeugen, dem Importer, den Synchronisierungswerkzeugen und Zepra Folie 11

12 Fazit Schnellere Reaktion auf Anforderungen aus Projekten Höhere Datenqualität Leistungsfähige, zeitgemäße Anwendungen für die Entwickler, bessere Bedienbarkeit (Vererbungskonzept,...) Einfacherer Zugriff auf die Daten Abschaffung eines proprietären Systems, Verminderung des Administrationsaufwandes, Konsolidierung der Systemlandschaft (COBOL, Java, RDBMS, Unix) Sammlung von Erfahrungen und Aufbau von Know-How Folie 12

13 Diskussion Fragen? Vorstellung des ZEDER-Browsers bei der Tooldemo Folie 13