Software Migration einer Mainframe-Anwendung - Ein Praxisbericht. Workshop Software Migration November 2006 Chemnitz Jörg Hahn

Transkript

1 Software Migration einer Mainframe-Anwendung - Ein Praxisbericht. Workshop Software Migration November 2006 Chemnitz

2 Die Deutsche Telekom AG konzentriert sich auf ihre Kunden. T-Systems: Die Marke für Geschäftskunden. Deutsche Telekom AG Mobilfunk Breitband/ Festnetz Geschäftskunden Seite 1

3 Agenda. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 2

4 Ausgangspunkt. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 3

5 Ausgangspunkt. Der Auftraggeber: ActiveBilling GmbH & Co. KG Tochtergesellschaft der Deutschen Telekom AG zuständig für über zwei Millionen fakturierte und gedruckte Rechnungen der T-Com täglich führt rund 42 Millionen Debitorenkonten bezüglich der Themen Billing und Collection Marktführer in Europa Die Anwendung: Rechnungsdienst Auftragslenkungssystem zur maschinellen Übernahme bzw. Weitergabe rechnungsrelevanter Daten aus der Auftragserfassung bestehend aus einem Batch- und einem Dialog-Teil mit Windows-PC zur Nachbearbeitung, Neuerfassung und zum Recherchieren von Geschäftsfällen Unsere Aufgabe: signifikante Senkung der Wartungskosten Übernahme der Verantwortung für die Wartung und Weiterentwicklung durch T-Systems Anfang 2004 als erste Refactoring-Maßnahme sollte der unter IBM Mainframe betriebene Batch-Teil auf die Sun Solaris Plattform des Dialog-Teils dieser Anwendung migriert werden Seite 4

6 Entscheidungsgrundlage. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 5

7 Entscheidungsgrundlage Die Vorstudie. Überprüfung der Machbarkeit und des Business Case im Rahmen einer Vorstudie Vorstudie Go/No Go Migration Inhalte der Vorstudie Erstellung eines Migrationskonzepts Lösungsansätze Abschätzung wesentlicher Aufwände Pilotierung eines Teilprozesses Abschätzung des Hardwarebedarfs (und damit der Kosten) Validieren von Lösungsansätzen Entscheidung erst nach erfolgreichem Abschluss der Konzeption und der Pilotierung fiel die Entscheidung Seite 6

8 Entscheidungsgrundlage Der Pilot. Simulation des Lastprofils anhand Referenzprozess Auswahl der Referenzprozesse anhand Lastverhalten der Anwendung im Betrieb (hinsichtlich CPU-Bedarf und IO-Durchsatz) Portierung dieser Teilprozesse der Anwendung auf die SUN Solaris Plattform Erprobung im Benchmarkcenter von SUN Vermessung des Hardwarebedarfs für die Referenzprozesse und Hochrechnung auf die komplette Anwendung Referenzprozess hinsichtlich CPU-Bedarf Auswahl Verursacher der Hauptlast zwischen 18:30 Uhr und 20:00 Uhr weiteres Kriterium war hohe Abdeckung zu erwartender Portierungsprobleme Tests erfolgten mit wirkbetriebsnahen Daten (hinsichtlich Inhalt und Menge) Relativer CPU-Bedarf 1,00 0,80 0,60 0,40 0,20 UNIX Dialogprozesse UNIX DB Abgleichprozesse Host Batchprozesse 1,00 0,80 0,60 0,40 0,20 0,00 0,00 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 0:00 Uhrzeit Seite 7

9 Prämissen. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 8

10 Prämissen. Rahmenbedingung funktionale Weiterentwicklung darf nicht beeinträchtigt werden Umstellungsstrategie 1:1-Portierung Beschränkung der Anpassungen auf das unumgängliche Minimum die Anwendungsarchitektur bleibt zunächst unverändert die Komplexitätsreduzierung gewährleistet den Projekterfolg im ersten Schritt werden nicht alle Möglichkeiten der Zielplattform ausgenutzt Migration parallel zur fachlichen Weiterentwicklung Entkopplung der Migration von der Realisierung fachlicher Themen Durchführung Parallelbetrieb Sicherstellung der Qualität und Betreibbarkeit der migrierten Anwendung Seite 9

11 Prämissen - Migration parallel zur fachlichen Weiterentwicklung. Fachliche Weiterentwicklung Version 1 Version 2 Version n Frozen Zone Version n+1 Übernahme der Softwarestände Migration Konzeption Umsetzung Systemtest Parallelbetrieb Automaten zur Portierung der fachlichen Änderungen der Sourcen iterative Erweiterung der Automaten Test auf Alt- und Neusystem mit anschließendem Vergleich der Ergebnisse Seite 10

12 Die Migrationsaufgabe. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 11

13 Die Migrationsaufgabe - Ist-Architektur. CoolGen Dialog, Informix DB unter Sun Solaris Dialog 15 LPAR IBM Mainframe, z/os 15x DB/2 DB mit 1,25 TB Plattenplatz Synchronisation der Datenbanken über MQSeries Cobol (ca mit 1,8 Mio LoC), REXX JCL (ca. 600 Jobs) Fachlogik Batch Jobs Scheduler Batch Installation ZEKE Windows PC ca. 70 Schnittstellen zu anderen Anwendungen 5000 MIPS Spitzenlast Seite 12

14 Die Migrationsaufgabe - Ziel-Architektur. z/os Sun Solaris DB/2 (EBCDIC) Cobol Oracle (ASCII) Micro Focus ServerExpress Dialog REXX JCL ZEKE PERL bash UC4 Fachlogik Batch Jobs Scheduler Batch Installation Entwicklung eines eigenen SQL Konverters Generieren zusätzlicher Modulaufrufe in die COBOL- Sourcen Konvertierung der Cobol-Sourcen in Freeformat Ersetzung eines einzelnen CICS-Programmes durch Eigenentwicklung Internes Dateiformat im Wesentlichen Line Sequential Seite 13

15 Der Parallelbetrieb. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 14

16 Der Parallelbetrieb - Ziele. Einsatz des Gesamtsystems unter Echtbedingungen Parallelbetrieb zur Wirkplattform mit Echtdaten aus dem Wirkbetrieb maschineller Vergleich mit Tools für Datenbanken und Schnittstellen Ziele Versionswechsel Überprüfung der Durchführung des Versionswechsels Korrektheit der Datenübernahme des Quellsystems Anwendung Überprüfung der Korrektheit und Stabilität der Anwendung Performancetauglichkeit der Plattform Ermittlung der optimalen Hardware und Drittsoftware-Konfiguration Betrieb Training für die Betriebsmannschaft Überprüfung der Eignung der betrieblichen Verfahren und Werkzeuge Seite 15

17 Der Parallelbetrieb - Architektur. Wirkbetrieb Parallelbetrieb relevante Daten Dialog Änderungen der Anwender nach Konvertierung bzw. Normierung erfolgt Vergleich mit Wirkbetrieb Batch Installation sequentielle Dateien Batch Installation Seite 16

18 Erfahrungen. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 17

19 Erfahrungen. Projekt hat Change-Charakter wenn Betriebsmannschaft noch keine umfangreichen Erfahrungen auf der Zielplattform besitzt hoher Automatisierungsgrad bei der Migration, bei der Neuübernahme von Sourcen und beim Test lässt parallel zur Portierung notwendige Softwareanpassungen zu Parallelbetrieb fördert noch enthaltene Fehler zu Tage und versetzt die Betriebsmannschaft in die Lage, die Anwendung zu betreiben deshalb so wirkbetriebsnah wie irgend möglich durchführen Schnittstellenvereinbarungen mit Partnersystemen erfordern viel Zeit und Aufwand; Quelle für Change Requests; typisches Wadenbeißer -Thema Analyse und Anpassung der Software führt auch automatisch zum Aktualisieren der fachlichen und technischen Dokumentation Plattformlieferanten ins Projekt einbinden: hat ein starkes Interesse am Projekterfolg Ausweichkonzept sinnvoll, falls Abhängigkeiten zu Partnersystemen bestehen (z.b. wegen Anpassung der Schnittstellen von Partnersystemen), um deren Inbetriebnahme vom Zeitpunkt der Wirkbetriebsaufnahme zu entkoppeln Seite 18

20 Fazit. Ausgangspunkt Entscheidungsgrundlage Prämissen Die Migrationsaufgabe Der Parallelbetrieb Erfahrungen Fazit Seite 19

21 Fazit. Erfolgreiche Aufnahme des Betriebs 2006 die Hardware ist ausreichend dimensioniert die Betriebskosten wurden gesenkt die Basis für weitere Modernisierungen wurde damit geschaffen weitere Refactoring-Aufgaben wurden inzwischen umgesetzt Unser Vorgehen hat sich bewährt das hier umgesetzte Vorgehen lässt sich generell auf weitere Migrationsvorhaben bzw. Reengineering-Maßnahmen anwenden Eine Plattformmigration ist eine gute Alternative gegenüber einer Neuentwicklung die Risiken sind kontrollierbar ein sukzessiver Übergang zu neuen Technologien und Paradigmen wird ermöglicht Seite 20

22 Vielen Dank! Senior Project Manager T-Systems GEI GmbH Industry Business Unit Telco, SSC Billing Hausanschrift Clausstraße 3, Chemnitz Telekontakte (Tel.) (Fax) (Mobile) -systems.com Seite 21