Glaubt man einer Studie von Computer Associates (CA), dann bleiben 44 Prozent aller Mainframe-Anwender dem Großrechner nur aus einem einzigen Grund treu: Sie scheuen die Kosten beim Wechsel auf eine verteilte IT-Landschaft. Und genau hier beginnt schon der erste und vor allem entscheidende Irrtum. Das zumindest ist die Meinung bei den IT-Verantwortlichen der Soka-Bau in Wiesbaden.

Migrationskosten? Kein Problem!

"Die Migrationskosten sind nicht das Problem. Ganz im Gegenteil", sagt Wolfgang Moze. Der Abteilungsdirektor bei Soka-Bau sieht bei der Ablösung eines Mainframes eine ganz andere Herausforderung: die systematische Bewältigung der Umstellungsrisiken.

Moze muss es eigentlich wissen. Denn sein Unternehmen hat gerade die Ablösung einer BS2000-Mainframe-Umgebung erfolgreich abgeschlossen und auf Unix-Server umgesattelt. Wesentliches Ergebnis dieses Plattformwechsels: Innerhalb von 1,4 Jahren haben sich die Investitionen in dieses Projekt bezahlt gemacht. Den - neudeutsch - Return on Invest (ROI) kann Soka-Bau nachweisen.

Daneben gab es aber beim Wechsel der Plattformen auch andere Ergebnisse: "Die jährlichen Betriebskosten konnten von 2,5 auf 0,7 Millionen Euro reduziert werden. Das sind immerhin 72 Prozent", berichtet Wolfgang Moze, Abteilungsdirektor bei Soka-Bau.

Die Hauptersparnis habe Soka bei den Lizenzkosten für BS2000 erreicht. "Sie machen allein 89 Prozent der Einsparungen aus", sagt Moze. Die Bedenken der CA-Studie zu den Kosten eines Wechsels weg vom Mainframe kann er nicht nachvollziehen. Und er belegt seine Zweifel mit Zahlen. Er beziffert die Gesamtkosten des 36-monatigen Projekts auf 2,477 Millionen Euro. Bei jährlichen Einsparungen in Höhe von 1,8 Millionen Euro berechnet sich somit ein RoI von 1,4 Jahren. Personaleinsparungen sind hier nicht eingerechnet. Der interne IT-Dienstleister SOKA-IT berichtet außerdem von deutlichen Performance-Verbesserungen bei den unternehmens- und zeitkritischen Anwendungen.

Moderner, einfacher, einheitlicher

Das IT-Projekt der Soha-Bau verfolgte mehrere Ziele: Zum einem sollte der BS2000-Mainframe komplett abgelöst, die gesamte Großrechner-Hardware abgebaut werden. Das Vorhaben verstand sich als "Generalaufräumung". Hierbei sollte das Systemumfeld modernisiert, eine aktuelle Entwicklungsumgebung eingeführt, die Batch-Steuerung auf den neuesten Stand gebracht und auch das Softwareumfeld aktualisiert werden. Außerdem wollte Soka-Bau seine Prozesse vereinfachen und die Vielzahl der Produkte im Haus reduzieren und vereinheitlichen.

Zur Qualitätsabsicherung wurde das Projekt von Anfang an durch die Wirtschaftsprüfer von PricewaterhouseCoopers begleitet. So wollte Soka-Bau sicher stellen, dass einem anschließenden Testat nichts im Wege steht.

Das Projekt wurde mit dem vorhandenen Personal der IT, der Innenrevision und Mitarbeitern aus allen Fachbereichen parallel zum Tagesgeschäft vorbereitet und umgesetzt - insgesamt etwa 100 Personen. "Das Engagement unserer eigenen Leute war uns für die Akzeptanz der neuen Umgebung und für einen reibungslosen Übergang sehr wichtig. Von den Entwicklern sind in der neuen Umgebung alle dabei geblieben und auch von der BS2000-Systemgruppe sind anschließend nur wenige in andere Abteilungen gewechselt", zeigt sich Moze zufrieden mit dem Vorgehen.

Die größten Herausforderungen

Die Vielzahl der Anforderungen war das größte Problem bei der Ablösung des Mainframe. Denn alle Schichten der bisherigen Großrechnerwelt mussten gleichzeitig neu entwickelt, umgestellt, migriert oder angepasst werden. Eine grundlegende Schwierigkeit bestand darin, zunächst die mit dem Projekt verbundenen erheblichen Risiken zu identifizieren. Deren gab es eine ganze Menge. Denn auf dem Mainframe der Soka-Bau wurden rechnungswesenrelevante Systeme betrieben, "die von der Bundesanstalt für Finanzdienstleistungsaufsicht, der Bafin also, kontrolliert werden", beschreibt Projektleiter Facca die Ausgangssituation.

Um die Risiken beherrschbar zu machen, wurden in einer Vorstudie die zehn wesentlichen Problemfelder definiert . Für diese leiteten die Projektverantwortlichen dann passende Lösungsstrategien ab (siehe Kasten "Zehn zentrale Projekt-Aufgaben"). Bei jedem dieser Teil-Projekte galt es, zahlreiche Stolperfallen zu überwinden.

Geringer Aufwand für die Infrastruktur

Die Ablösung der Hardware war dabei noch das geringste Problem. An Stelle des BS2000-Großrechners ("SX150-40C") traten Unix-Server unter dem Betriebssystem Solaris: eine Fujitsu "PW-900 Ultrasparc" als passive und ein Sun-Sparc-Enterprise "M5000" als aktive Maschine. Beide besaßen jeweils zwei Domänen für die Entwicklungs-, für die Abnahme- sowie für die Produktionsumgebung. Für die Ausfallsicherheit sorgen zweimal zwei Domänen sowie die Möglichkeit von Cluster-Schwenks mit allen installierten Komponenten.

Auch der Aufwand für den Austausch der BS2000-Systemsoftware-Komponenten durch Unix-Versionen war eher gering. Eine Reihe von Komponenten musste allerdings ersetzt werden, weil es für sie keine Unix-Version gab oder die Produkte veraltet waren. Hierzu zählten "Predict Case", "Connect", "Entire Output Management" (NOP), "Natural Document Management", ein strategisches Informationssystem (SIS), Terminal-Emulation usw. Von den Projektbeteiligten wurde dieses Manko aber sogar eher als Vorteil bewertet. Auf diese Weise war man gezwungen, Systemkomponenten notabene zu modernisieren.

Automatisierte Migration der Datenbanken

Auf dem Mainframe wurden 21 Datenbanken betrieben, rund 250 Datenbank-Files und etwa 200 Millionen Datensätzen. Die System- und Anwendungs-Datenbanken wurden von "Adabas-BS2000" automatisiert via Codeumwandlung nach "Adabas-Unix" migriert. Hierbei trat ein gravierendes Problem auf: Im Verlauf der über Jahre betriebenen Weiterentwicklungen hatten Anwendungsentwickler einige Datenfelder zweckentfremdet und Alphafelder für numerische und binäre Daten genutzt. Bei etwa zehn Prozent der Datenbankfiles musste der Datenbestand deshalb durch eigens dafür entwickelte Tools migriert werden.

Umfangreiche Anwendungs-Migration

Die Anwendungs-Migration von "Natural-BS2000" nach "Natural-Unix" unter Solaris realisierten die Projektverantwortlichen, indem sie alle plattformabhängigen Code-Abschnitte anpassten. Als gravierende Effizienzsteigerung Die Einführung eines Kernbibliotheken-Konzeptes für die Wartung, Pflege und Weiterentwicklung der Natural-Anwendungen erwies sich als signifikante Effizienzsteigerung. Hierbei konnten ursprünglich 248 Natural-Bibliotheken mit zirka 100.000 Modulen auf 27 mit etwa 43.000 Modulen reduziert werden.

Ein Schritt mit großer Nachwirkung war die Ablösung der bisher verwendeten Entwicklungsumgebung. Auf dem Mainframe wurde "Predict Case" mit rund 60.000 Objekten eingesetzt. Da Predict Case unter Unix nicht lauffähig ist, wurde die Entwicklungsumgebung in einem Parallelprojekt komplett durch "InnoWake Natclipse" ersetzt und alle Entwicklungsdaten migriert. Ziel war, eine grundlegend modernisierte, vereinfachte und vereinheitlichte Umgebung (Natural und Java) zu realisieren.

Zur neuen Entwicklungsumgebung gehört zum einen ein Eclipse-Plugin, um Naturalprogramme zu editieren. Teil der Umgebung ist zudem eine Versionierung aller Objekte mit Subversion (SVN) sowie ein Life-Cycle-Manager, der Objekte von der Entwicklungs- in die Produktionsumgebung transportiert und installiert. Der Life-Cycle-Manager ermöglicht eine automatische Parallelversorgung der BS2000- und der Unix-Plattform, so dass die Code-Konsistenz jederzeit sichergestellt ist. Im Projekt stellte dies einen erheblichen Vorteil dar.

Aufwand: Umstellung der Batch-Steuerung

Mit erhöhtem Aufwand verbunden war auch die Umstellung der Batch-Steuerung. Unter BS2000 waren ca. 1.500 Batch-Jobs für ungefähr 300 Batchprogramme im Einsatz. Hier wurde noch unter BS2000 die Batch-Steuerung von Entire Natural Operation auf "UC4" (Job Scheduling und Workload-Automatisierung )umgestellt, da UC4 sowohl unter BS2000 als auch unter Unix universell einsetzbar ist. Im zweiten Schritt mussten die BS2000-Jobs schließlich manuell durch Unix-Shell-Skripte ersetzt werden.

Ein größeres Volumenproblem stellte die Ablösung des alten Massendruckverfahren BS2000-Druck durch das Standard-Textverarbeitungssystem "M/Text" dar, denn das unter BS2000 eingesetzte Druckverfahren war nicht auf Unix übertragbar und entsprach auch nicht mehr dem Stand der Technik. Hier musste der Druck aller Schreiben umgestellt werden. Außerdem mussten insgesamt rund 20 Millionen archivierte Korrespondenzschreiben in eine Archiv-Anwendung unter Unix übertragen werden. Die Migration selbst war zwar relativ einfach realisierbar. Die Batch-Verarbeitungslaufzeit für den Export der Briefe dauerte allerdings ein halbes Jahr.

Schließlich wurde die alte Oberfläche der "Log-TE"-Terminalemulation durch die Web-Anwendung "LogWeb-Unix" abgelöst. Dies geschah zunächst unter BS2000, dann unter Unix. Hierbei gab es allerdings teilweise Akzeptanzprobleme bei den Anwendern. Das zeichenorientierte Unix bietet nicht die gleiche Funktionalität wie BS2000. So gingen einige Komfortmerkmale verloren. Hier erging in der Folge bereits der Auftrag, die Web-Anwendung im Anschluss an die Migration nachzubessern.

Risiken minimieren und Prozesse absichern

Die Testphase war ein besonders kritisches Teilprojekt. Entwickler-, Integrations- und fachliche Tests sprengen nämlich schnell den Kostenrahmen. Projektleiter Tobias Facca erläutert die Teststrategie der Soka-IT so: Um zu ergründen, welche Prüfungen wie wichtig sind, habe man unterschieden zwischen einerseits unproblematischen Anpassungen mit geringem Testbedarf und andererseits kritischen Komponenten. Migrierte plattformunabhängige Anwendungen beispielsweise - die die Masse der zu prüfenden Anpassungen darstellten -, seien unproblematisch gewesen. "Größeren Testbedarf gab es hingegen bei Code-Abschnitten, die wegen der Plattformabhängigkeit ersetzt werden mussten".

Bereits 1,5 Jahre vor Produktionsstart baute die Soka-IT eine Unix-Parallelwelt auf. Mit maschinellen Verfahren wurden dabei alle Anpassungen gleichzeitig zur BS2000-Welt getestet und verglichen. Fehlerfreie Ergebnis bestätigten die Korrektheit der Programme und machten teure und zeitaufwändige Fachtests überflüssig.

Um kritische Codezeilen zu erkennen und plattformabhängige Inhalte zu identifizieren, kamen maschinelle Qualitätssicherungen mit intelligenten Mustererkennungsverfahren zum Einsatz. Hier mussten mehrere zehntausend Treffer gesichtet und nach den Kriterien "nicht relevant", "müssen angepasst werden" und "genauer prüfen" sortiert werden. Besonders dieser Testschritt führte aus Sicht der SOKA-IT zu einem großen Sicherheitsgewinn und sorgte für eine hohe Qualität der migrierten Anwendungen. Trotz zigtausender Codeumstellungen wurden bei diesem Prozedere nur drei fehlerhafte Datenbankzugriffe übersehen.

Nach 36 Monaten der Big-Bang

Nach 36 Monaten war es soweit. Die Umstellung erfolgte von Freitag bis Sonntag. Zunächst wurden in der alten Welt noch alle Abschlüsse durchgeführt, dann der Dialog- und Batch-Betrieb gestoppt und alle Außen-Verbindungen gekappt. In den nächsten 24 Stunden wurden die Daten umgestellt, so wie es vielfach getestet worden war. Alle Schnittstellen wurden auf die neue Welt umgestellt und anschließend unter Unix hochgefahren. Am Sonntag war nochmals Zeit, die Ergebnisse kritisch zu sichten und zu überprüfen. Das Ergebnis: grünes Licht für die Produktion.

Am Montag um 06:30 Uhr lief der Betrieb wieder normal an - jetzt aber unter Unix. Alles funktionierte, wenn auch mit ein paar Anlaufschwierigkeiten. Ein Problem zeigte sich sofort: Die Performance der Datenbanken war zunächst viel zu schlecht, denn im Produktivbetrieb nutzten wie eh und je eine großen Zahl von Benutzern das System. Nachdem einige Parameter angepasst wurden, war dieses Problem behoben. Auch beim Start des Batch-Betriebs zeigte sich ein Fehler, der bereinigt werden musste. Dafür musste die Produktion für insgesamt drei Stunden unterbrochen werden, um die Korrekturen und Optimierungen zu implementieren. Danach waren keine weiteren Unterbrechungen mehr erforderlich. (jm)