Jahr 2000, Europäische Währungsunion, rechtliche Vorgaben - nicht nur diese Herausforderungen setzen die Banken unter Zugzwang. In den Blickpunkt strategischer DV-Entscheidungen rückt der gesamte Übergabekreislauf von Neuentwicklungen und Änderungen.

Immer kürzere Änderungszyklen erfordern erstens ein verbessertes Management der Softwaresysteme. Die Vielzahl eingesetzter Change-Management-Werkzeuge zieht zweitens einen hohen Aufwand für Infrastruktur, Schulung und Betreuung nach sich. Die zunehmende Vielfalt von Komponententypen (zum Beispiel DB2, SAP, SAS) verlangt drittens größeres technisches Know-how der Anwendungsentwickler.

Auch die BHF-Bank, mit einem Konzerngeschäftsvolumen von rund 88 Milliarden Mark die siebtgrößte börsennotierte deutsche Geschäftsbank, sah sich mit dem Problem konfrontiert, die historisch gewachsene Infrastruktur auf Dauer nicht mehr effizient organisieren und verwalten zu können. Eine Vielzahl unterschiedlicher Oberflächen, Prozeduren, Parameter und Zielbibliotheken belastete die Kapazitäten der über einhundert Entwickler aufs äußerste. Qualität und Sicherheit für die Produktion zu garantieren, schien ein schwieriges Unterfangen.

Im Jahre 1993 entschied man sich für die Einführung neuer Change-Management-Tools. Dabei handelte es sich um Eigenentwicklungen wie "Elektronischer Programmauftrag" (ELP) und Produktionsübernahme-Verfahren (PPE).

Als jedoch mit der Konversion auf Cobol 2 ein großes Umstellungsprojekt auf die Entwickler zukam, zeigten sich die Grenzen der Werkzeuge. Die erforderlichen Änderungen zwangen die Tools in die Knie: Eine maschinelle Sicherstellung der Konsistenz überstieg ihr Leistungsvermögen. Auch die anfallenden Mengen konnten sie nicht bewältigen.

Das DV-Management der BHF-Bank faßte deshalb 1995 einen weitreichenden Entschluß. Gesucht wurde eine Change-Management-Plattform mit folgendem Anforderungsprofil:

- Höhere Transparenz über Objekte (Programme, Copies etc.) und deren Interdependenzen,

- Verbesserung der Kommunikation zwischen Entwicklung und Produktion,

- maschinelle Sicherstellung der Konsistenz,

- Vereinfachung der Arbeit für den Entwickler,

- Unterstützung beim Auf- und Abbau von Testumgebungen,

- schnelle Implementierbarkeit,

- weder proprietäre Sprachen noch eigene Datenhaltung, sondern Ausrichtung an Standards sowie

- leichte Erlernbarkeit des Werkzeugs.

Die Diskussion "Make or buy?" und eine Sichtung des Angebots am Markt führten zu dem Ergebnis, daß der Erwerb eines Werkzeugs die bessere Wahl ist. Auf Basis eines Kriterienkatalogs wurden mehrere Produkte evaluiert, wobei in der Endausscheidung "Change Man" von Interchip die Nase vorn behielt. Ausschlaggebend waren die Offenheit des Werkzeugs und seine gute Integrierbarkeit in die IBM-Welt.

Seit zweieinhalb Jahren steuert die BHF-Bank den gesamten Übergabekreislauf von Neuentwicklungen bis hin zu Änderungen im Host-Bereich über die neue Plattform. Allerdings war der Projektstart von einigen Vorbehalten auf seiten der Entwickler geprägt: Man befürchtete die Einschränkung oder gar den Verlust wichtiger Aufgabenbereiche.

Täglich anfallende Arbeitsschritte sollte nunmehr automatisch das Change-Management-Werkzeug abwickeln. Dazu gehören das Zusammenstellen der Komponenten eines Änderungsauftrags, die Umwandlung und der Aufbau von Testumgebungen, die Übergabe in die Produktion, Backup und Install.

Sicherlich fiel es nicht leicht zu akzeptieren, daß die Update-Berechtigung auf Entwicklungsbibliotheken entfällt. Inzwischen haben private Bibliotheken ausgedient - für die Sicherheit der Infrastruktur eine unabdingbare Voraussetzung. Ist ein Programm erst einmal kompiliert, läuft der weitere Bearbeitungsprozeß automatisch über das Tool.

Für alle Entwicklungs- und Teststufen, Freigabeverfahren und Installationen bis hin zur Archivierung älterer Versionen werden die Regeln und Standards für Übergaben automatisch und sicher eingehalten. Wichtig ist das vor allem für die Integrität der Anwendungen sowie ihre Qualität und Verfügbarkeit.

Ein weiterer elementarer Faktor der Einführung ist die schnelle Einweisung der Entwickler in das neue Werkzeug. Auf Basis eigens erstellter Schulungsunterlagen lernten gut 100 Spezialisten in Seminaren die Grundlagen der neuen Verfahren kennen.

Zur Akzeptanz des Werkzeugs trugen gezielte Ergänzungen bei. Beispielsweise stellt das Tool automatisch die Rekompilierung von Programmen bei Änderung von Copy-Strecken sicher. Die zugehörigen Reports wurden um eine "Management Summary" ergänzt, was die Verständlichkeit erhöhte. Die Integration des altvertrauten "Smartedit" als Cobol-Editor trug außerdem zur Akzeptanz des Werkzeugs bei.

In Change Man integrierbare, selbstdefinierbare Online-Formulare dienen der exakten Statusverfolgung einzelner Sachgebiete und reduzieren damit den Koordinationsaufwand für die Änderung zentraler Copy-Strecken erheblich. Beim Drucken des Formulars werden die Sachgebiete per Memo über den Teststatus sowie anhand der Audit Summary über die erforderlichen Maßnahmen informiert. Auch Änderungen an der produktiven Job Control Language sind über eigene Formulare anzufordern.

Um die Konsistenz zu sichern, wurden wesentliche Komponenten in der ersten Einführungsphase gemeinsam in die neue Umgebung transferiert. Dazu zählen Cobol, PL/I, Copies, MFS und PSB. Aus heutiger Sicht ist die Übergangszeit allerdings sehr lang ausgefallen. So gestaltete sich der Konsolidierungsaufwand für den Parallelbetrieb zwischen den alten Systemen (zirka 3500 Programme) und dem neuen Werkzeug recht schwierig. Trotz einiger Bedenken hätte man Programme aus alten Systemen sofort in die neue Umgebung übernehmen sollen.

Bei dem sukzessive realisierten Transfer wurde die vorhandene Infrastruktur nachhaltig vereinfacht. Heute unterteilt sie sich in 75 Applikationen und Sachgebiete, 57 Komponententypen (Cobol, PL/1, Copies, PSB etc.) sowie sechs Prozeduren (MFSGEN, Compile etc.).

Seit Juni 1995 werden pro Monat zwischen 300 und 500 Pakete übernommen. Ihre Ausprägungen reichen von normalen Aufträgen mit fünf bis zehn Komponenten über die Änderung von Copy-Strecken und zentralen Schnittstellen bis zur Einspielung von Fremdsoftware mit 2000 und mehr Komponenten. Bei über 25000 Änderungen entfielen für die Dauer eines Jahres 8784 auf den JCL-Bereich (34 Prozent) und 5644 auf Cobol (22 Prozent). Angesichts dieser Zahlen rechnen sich die Investitionen für das Produkt in sechsstelliger Höhe und der Einführungsaufwand von etwa zwei Mitarbeiterjahren sehr schnell.

Nach nunmehr gut zweijährigem Einsatz des neuen Change-Management-Verfahrens läßt sich eine positive Bilanz ziehen. Inzwischen werden fast alle Großrechnerkomponenten mit dem Werkzeug verwaltet. Das System ist ohne einen einzigen Ausfall stabil gelaufen. Das für eine Bank typische Volumen von Übernahmen und Änderungen nimmt deutlich weniger Zeit in Anspruch.

An die Stelle komponentenorientierter Übernahmen und Änderungen tritt nun die paketorientierte Lösung. Ebenso wie die Verwaltung aller Komponententypen (Programme, Texte, Masken etc.) sorgen auch Online- beziehungsweise Batch-Abfragen für hohe Transparenz. Nur ein Mitarbeiter ist für den Betreuungs- und Weiterentwicklungsaufwand erforderlich.

Eine weitere spürbare Verbesserung bringt die maschinelle Sicherstellung der Konsistenz mit sich. Dazu zählen die eindeutige Identifizierung von Source und Lademodul, ferner die automatische Änderung von Hauptprogrammen bei Änderung statisch "gelinkter" Unterprogramme sowie die gleichzeitige Änderung von Copy-Strecken und nutzender Programme. Gut gelöst ist auch der Aufbau von Testumgebungen. Sie sind einfach definierbar und können dann von den Entwicklern bestückt werden. Letztlich tragen zahlreiche Kompetenzregelungen zu weitreichender Sicherheit bei.

Euro- und Jahreszahlenumstellung sowie schnellere Produktzyklen bedeuten nicht nur für die BHF-Bank Herausforderungen und erhöhen den Druck auf die Entwickler. In den nächsten Jahren sind viele Programme mehrmals parallel zu ändern und zu testen. Zusätzliche Testumgebungen sind erforderlich.

Spätestens jetzt muß die Software komplett inventarisiert und die Zuordnung von Sourcen zu Lademodulen eindeutig sein. Bereits eingesetzte und für den Euro angepaßte Komponenten dürfen nicht einfach durch Änderungen für das Jahr 2000 überschrieben werden. Mehr noch als für den Euro ist für das Problem 2000 die Fehlerfreiheit der Applikationen der wichtigste Faktor für den Projekterfolg. DV-Change-Management stellt daher immer höhere Ansprüche an das Entwicklerteam.

Change-Management ist für die BHF-Bank zum wichtigen Instrument avanciert, um die Herausforderungen zu bestehen.

DV der BHF-Bank

- ein Host mit IMS/DC, IMS/DB und DB/2

- Unix für Handelssysteme

- zirka 2000 PCs

- rund 160 Mitarbeiter in der Systemtechnik und DV

- rund 140 Mitarbeiter in der Anwendungsentwicklung

Angeklickt

Schon vor etlichen Jahren standen Systemadministratoren der Frankfurter BHF-Bank vor dem Problem, mit der hohen Zahl von Änderungen in der DV nicht mehr Schritt halten zu können. Es wurde ein Tool gesucht und gefunden, das Change-Management weitgehend automatisiert. Ein solches Werkzeug stieß allerdings anfangs auf Widerstände, weil es Funktionen übernimmt, die DV-Spezialisten als ihr ureigenes Revier betrachten. Im Rückblick zeigt die insgesamt sehr positive Einschätzung der Automatisierung auch auf, wo damals Fehler gemacht wurden.

*Heinz Langenfelder war Leiter Methoden, Standards und Technik im Bereich Systemtechnik und Datenverarbeitung bei der BHF-Bank in Frankfurt am Main und ist jetzt als freier Berater tätig.