Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

07.02.1997 - 

Migrationsstrategien für Altsysteme/Nicht revolutionär ersetzen, sondern evolutionär weiterentwickeln

Für das Re-Engineering von Mainframe-Anwendungen

Folgt man den Einschätzungen der Gartner Group aus dem Jahr 1996, so umfassen die kommerziellen Anwendungen der Unternehmen weltweit über 150 Milliarden Zeilen Cobol-Code. 70 Prozent aller Daten, die in diesem Umfeld gespeichert werden, liegen außerdem in nichtrelationaler Form vor.

Diese Anwendungen neu zu entwickeln würde nach Einschätzung der Analysten mehr als 50 Jahre in Anspruch nehmen. Zieht man in Betracht, daß ja die Anwendungen in dieser Zeit weiter betrieben und gewartet werden müssen, könnten auch produktivitätssteigernde Entwicklungs-Tools nicht viel an dieser Dimension ändern. Schon hierin spiegelt sich das Dilemma vieler IT-Verantwortlicher wider.

Man wüßte wohl, wie man seine Anwendungen heute neu entwickeln und wie man es heute "richtig" machen würde, hätte man nur die Möglichkeit dazu. Leider ist dies fast nie der Fall.

Im Gegenteil: In dem Bemühen, mit der Entwicklung Schritt zu halten, werden oft neue Technologien in Teilbereichen und ohne klare Strategie für einen vollständigen Übergang eingeführt. Dabei werden Schnittstellen zu Altsystemen in Kauf genommen, die den Prozeß der Wartung und Weiterentwicklung der Anwendungen dauerhaft aufwendiger machen oder ganz blockieren.

So ist es keine Seltenheit, daß sich IT-Verantwortliche mit fünf oder mehr verschiedenen Datenhaltungssystemen herumschlagen müssen. Was das unter den Aspekten Lizenzgebühren, Wartungsaufwand, Datenkonsistenz, Operating, Schulung der Mitarbeiter etc. bedeutet, bedarf keiner Erläuterung. Wegen der Größe der Anwendungssysteme und der Vielzahl der Schnittstellen und Abhängigkeiten ist es nicht einfach, eine geeignete Migrationsstrategie zu entwickeln. Eine grundsätzliche Möglichkeit wäre der globale Ansatz einer generellen Erneuerung.

Die Befürworter einer solchen Lösung argumentieren meist mit der Hygiene und der historischen Chance, die eine Neuentwicklung mit sich bringt. Es werden sich jedoch nur sehr wenige Unternehmen einen solchen Kraftakt leisten können oder wollen. Die Komplexität der Aufgabe macht eine Realisierung in kurzer Zeit meist unmöglich.

Gerade die kurze Laufzeit ist jedoch ein Erfolgsfaktor für jedes IT-Projekt. Kaum ein Vorhaben, das wesentlich länger als ein Jahr dauert, kann mit den ursprünglich geplanten Ressourcen erfolgreich beendet werden.

Eine zweite Möglichkeit ist die oft geübte Praxis, eine strategische Entscheidung dergestalt zu treffen, daß ab einem Zeitpunkt alle Anwendungen auf Basis einer neuen Technologie zu entwickeln sind. Tatsächlich ist diese Vorgehensweise häufig dafür verantwortlich, daß sich die Mehrzahl der Mitarbeiter einer IT-Abteilung damit beschäftigt, die Altsysteme mit all ihren inhomogenen Schnittstellen am Leben zu erhalten. Es sind nicht nur die vielgescholtenen Mainframe-Architekturen, die diese Aufwände verursachen, sondern auch die gewachsenen Anwendungsstrukturen.

Eine dritte Strategie besteht darin, das Anwendungsportfolio aufzuteilen und nur jeweils eine Anwendung immer zu modernisieren. Das große Problem hierbei ist, die Applikationen voneinander zu isolieren. Wegen der starken Verflechtung sind immer auch Nachbarprogramme von Änderungen betroffen. Insbesondere trifft dies bei Veränderungen der Datenhaltung und des Datenmodells zu.

So werden unweigerlich Provisorien und neue Schnittstellen eingeführt sowie Kompromisse bei den neuen Systemen eingegangen. Die für die zusätzlichen Schnittstellen erforderlichen Aufwände können ein Vielfaches des eigentlichen Re-Engineering beziehungsweise der Migration ausmachen. (Zur Problematik des Schneeballeffekts siehe Abbildung 1).

Ist ein IT-Betreiber einmal zu der Erkenntnis gekommen, daß er seine Anwendungen dringend neuen Erfordernissen anpassen müßte, beginnt leider oft ein Teufelskreis, der in der Folge für einige Jahre jeden wirklichen Fortschritt in der Sache blockieren kann. Er beginnt mit dem Ansatz, daß man ja mittel- bis langfristig alle oder einige existierende Anwendungen ersetzen möchte, weshalb in diese natürlich nicht mehr investiert werden soll.

Auf der Suche nach Alternativen wird meistens auch die Ablösung eigenentwickelter Anwendungen durch Standardsoftware erwogen. Findet man auf dem Markt Systeme, die auch unter den Faktoren Funktionalität, Flexibilität, organisatorische Unabhängigkeit und Wirtschaftlichkeit als geeignet erscheinen, so kann der Einsatz von Standardsoftware ein guter Weg sein.

Es gibt allerdings auch Firmen, die eigenentwickelte Lösungen mit Recht als Wettbewerbsvorteil sehen. Eine vollständige Abdeckung aller Anwendungsgebiete läßt sich mit Standardsoftware ohnehin kaum erreichen. Es bleibt also in fast allen Fällen ein mehr oder weniger großer Anteil an Eigenentwicklungen, für die es eine Perspektive zu finden gilt.

Die Aufgabe besteht also darin, die fachinhaltlich erhaltenswerten Anwendungen zu identifizieren und eine Methode zu finden, sie in nicht zu großen, planbaren und realisierbaren Schritten zu modernisieren und in neue Programme zu integrieren. Dies gilt es als permanenten Prozeß und nicht jeweils als singuläres Ereignis zu verstehen. Entscheidend ist dabei, daß eine Strategie der permanenten Verbesserung durch beherrschbare Schritte schneller zum Erfolg führt als alle anderen geschilderten Strategien.

Es wird in jüngster Zeit viel über objektorientierte Datenbanken als Nachfolgetechnologie der relationalen Datenbanken diskutiert. Dabei sollte man sich einmal in Erinnerung rufen, daß über 13 Jahre nach Einführung und allgemeiner Verfügbarkeit der relationalen Technologie noch immer über 70 Prozent der Daten in älteren Techniken gespeichert werden.

Die Beschäftigung mit der vermeintlich noch fortschrittlicheren Technik kaschiert allein schon nur zu oft, daß man über lange Zeiträume hinweg nicht in der Lage war, die Kernanwendungen auf den gegenwärtigen Stand der Technik zu bringen. Bei den Anwendungen läßt sich der notwendige Schritt der Bereinigung der Datenstrukturen jedoch nicht überspringen. Es ist eine unabdingbare Voraussetzung, die existierenden Daten in eine normalisierte und relationale Form zu bringen.

Sollen (oder müssen) alte und neue Anwendungen parallel betrieben oder sollen zum Beispiel im Zuge der Einführung von Management-Information- oder Decision-Support-Systemen Abfragen auf Anwendungsdaten durchgeführt werden, so stellen die Daten das Bindeglied zwischen den alten und den neuen Applikationen oder Enduser-Tools dar. Nun muß man in der Regel davon ausgehen, daß die Anwendungsdaten in Repräsentationen und Strukturen vorliegen, die beispielsweise für den Zugriff durch Enduser-Tools ungeeignet sind. Hieran kann auch sogenannte Middle- ware nichts ändern, die mancherorts gewachsene Datenstrukturen mit einer SQL-ähnlichen Abfragesprache versehen soll.

In der Praxis finden sich jedoch anwendungsspezifische Datenrepräsentationen (zum Beispiel für das Kalenderdatum), redefinierte Strukturen, multiple Felder oder Feldgruppen, redundante Datenfelder und Fehlbelegungen von Daten. Diese Strukturprobleme lassen sich mit Middleware nicht in den Griff bekommen. Die Aufgabe muß also sein, die Daten tatsächlich zu bereinigen und in normalisierter und relationaler Form zu speichern. Die so erreichte logische und physische Datenunabhängigkeit ermöglicht eine weitergehende Veränderung der Anwendungen ohne den gefürchteten Schneeballeffekt. (zur Vorgehensweise siehe Abbildung 2).

Nun wird diese Strategie nur dann mit vertretbarem Aufwand durchführbar sein, wenn sich die notwendigen Anpassungen der Anwendungsprogramme mit einem sehr hohen Automatisierungsgrad und damit in kurzer Zeit und mit großer Sicherheit durchführen lassen. Derartige Produkte sind jedoch verfügbar und haben sich seit Jahren bewährt.

Die Informationen über das gewünschte Zieldatenmodell werden dabei in einem zum Produkt gehörenden Dictionary definiert. Die Migrationsprodukte erzeugen dann automatisiert die Data Definition Language (DDL) zum Aufbau der entsprechenden relationalen Datentabellen, lesen ebenso automatisiert die Anwendungsdaten und laden sie in restrukturierter Form in die relationale Datenbank.

Die Daten werden wieder transparent

In der Folge werden wiederum automatisch SQL-Server-Module generiert (zum Beispiel in Cobol-Sourcecode), die alle benötigten Datenzugriffe beinhalten und dafür sorgen, daß die Logik der Anwendungsprogramme erhalten bleiben kann. Im Gegensatz zu Middleware ist das hier gewährleistet, da die Anwendungsdaten ja tatsächlich in bereinigter Form gespeichert werden. Abschließend durchlaufen die Anwendungsprogramme eine automatische Änderung dahingehend, daß sie nunmehr über die SQL-Server-Module auf die relationalen Anwendungsdaten zugreifen.

Mit diesem Schritt lassen sich in kurzer Zeit einige wesentliche Ziele erreichen. Zunächst einmal ist die Datenbasis nun homogen relational, mit allen Vorteilen, die sich unter Kostengesichtspunkten, für die Portabilität der Anwendung (zum Beispiel in Richtung Rightsizing), für die Anwendungsentwicklung und für den Systembetrieb ergeben. Die Anwendungsdaten sind restrukturiert und bereinigt.

Das heißt, Data-Warehousing muß nun kein Schlagwort mehr bleiben. Die Daten sind transparent geworden. Neue Anwendungen können über SQL auf vorhandene Daten zugreifen und finden diese in einer sauberen Struktur vor. Die Altanwendungen lassen sich nun auch in bezug auf ihre innere Struktur und Funktionalität hin überarbeiten.

Dabei stehen eine automatisierte vollständige Migration und eine grundsätzliche Überarbeitung beziehungsweise Re-Engineering von Anwendungen nicht im Widerspruch zueinander. Das eine ist eine notwendige Voraussetzung für das andere, wenn ein Re-Engineering überhaupt praktisch durchführbar sein soll.

Eine Vielzahl von Projekten dieser Art wurde bereits erfolgreich abgeschlossen: Anwender wie die Deutsche Bank, Audi, Agrippina Versicherung, Motorola, Alcoa, Sydsvenska Dagbladet, Dresdner Bank und über 160 andere haben erkannt, daß eine automatisierte Migration in kurzer Zeit und mit einer Bereinigung der Datenstrukturen der einzig praktikable Weg ist, um ihre Anwendungen durchgängig auf neue Plattformen zu übertragen.

Die Erfahrungen sind sehr ermutigend. So konnte zum Beispiel die Deutsche Bank Bauspar AG ihre 200-IMS/DB-Segmenttypen und ihre 950-Cobol Programme in nur sechs Monaten mit wenigen Mitarbeitern vollständig auf DB2 umstellen. Motorola stellte auf diese Weise ihre PPS-Anwendung, die in 34 Werken zum Einsatz kommt, in Rekordzeit vollständig auf relationale Technik um. Durch die so gewonnene Portabilität konnten alle Werke auf Unix-Systeme und Client-Server-Technologie umgestellt werden, wodurch Motorola nach eigenen Angaben 40 Millionen Dollar Betriebskosten pro Jahr einspart.

Spektakulär sind auch Rightsizing-Aktivitäten eines großen deutschen Automobilherstellers. In einem Auslandswerk mit zirka 12000 Beschäftigten werden die dortigen Mainframes vollständig durch eine Client-Server-Architektur auf Unix-Basis abgelöst. 5000 bis 6000 Programme müssen auf relationale Datenhaltung umgestellt werden.

Dies ist eine Aufgabe, die ohne Automatisierung bei der Anpassung der Programme auf das definierte Zieldatenmodell nicht durchführbar wäre. Jede andere Vorgehensweise würde auch bei großem Personaleinsatz Zeiträume beanspruchen, die das Projekt unmöglich machen würde.

Der Gesamtaufwand, der für eine automatisierte Migration zu veranschlagen ist, ist dabei oftmals niedriger als der Aufwand, der bis dahin schon in das überflüssige Extrahieren und Kopieren von Daten zu Auswertungszwecken investiert wurde. Berücksichtigt man die Ersparnis an Lizenz-, Wartungs und Betriebskosten für mehrere Datenbanksysteme, so macht sich ein Migrationsprojekt schon allein bei dieser Rechnung in ein bis zwei Jahren bezahlt.

ANGEKLICKT

Permanent von neuesten Rechnerarchitekturen und Software-Entwicklungsmethoden zu schwadronieren macht vielleicht Eindruck, dürfte aber recht häufig nur Defizite kaschieren. Der DV-Alltag wird dagegen nur zu oft von Altanwendungen, veralteten Systemplattformen und inkompatiblen Schnittstellen bestimmt. Der Autor zeigt einen Weg auf, der auf praktikable Weise und mit vertretbarem Aufwand hilft, die Abhängigkeit von Altanwendungen zu reduzieren.

*Dr. Rainer Gerkens ist verantwortlich für Marketing und Sales bei SWS Software Services in Pforzheim