Im Bankenbereich sind zirka 80 Prozent aller Dienstleistungen von Software gestützt. Die Beratung der Kunden findet heute teilweise direkt vor dem Bildschirm der Kundenbetreuer statt. Das Erscheinungsbild und die Stabilität der Software prägen somit die Qualität der Kundenbetreuung entscheidend mit.

Seit Anfang der 90er Jahre wurden neue Herausforderungen an Konfigurations-Management gestellt: Mit der verteilten Client-Server-Architektur stieg die Komplexität der Systeme. Aus einer homogenen, zentral ausgerichteten Landschaft wurde ein buntes, flexibles und benutzerfreundliches Mosaik, das zugleich schwerer zu beherrschen ist.

So laufen bei der Dresdner Bank weiterhin Hostanwendungen (MVS), die von Unix/NT-Servern und Windows NT-Clients ergänzt werden. Die Synchronisation dieser Plattformen während des Entwicklungs- und Wartungsprozesses stellt eines der Schlüsselprobleme heutiger Software-Entwicklung dar. Betrachtet man die eingesetzten Programmiersprachen, wird die Komplexität offensichtlich: Neben der klassischen Sprache des Host-Bereiches, Cobol, stehen heute Java, C++ oder Power Builder.

Diese Komplexität bekommt die Dresdner Bank mit systematischem Software-Konfigurations-Management in den Griff. Systematisch bedeutet hier, daß Dienstleistungen für die IT-Infrastruktur von einer zentralen Stelle im Hause zur Verfügung gestellt und organisiert werden. Dieser Service wird weltweit an allen Standorten der Dresdner Bank (London, Paris, Tokio etc.) aktiv angeboten. Durch Verbesserung der Infrastruktur wird die Software-Entwicklung transparenter. Das Software-Konfigurations-Management spielt hierbei eine Schlüsselrolle und wird weltweit als "Basis-Technologie" eingesetzt.

Der Nutzen von Konfigurations-Management (KM) wird in den zwei Normentexte ISO 9003 und 9004/7 beschrieben: Transparenz und Beherrschbarkeit. KM soll komplexe Prozesse und Systeme steuerungsfähig halten, indem es durch Dokumentation Transparenz schafft.

Es beantwortet beispielsweise Fragen wie: "Wer hat dieses Dokument zuletzt geändert?", "Wurde dieser Fehler nicht schon lange behoben?" oder "Welche Komponenten gehören zum aktuellen Softwarestand?". Projektleiter behalten den Überblick über ihre Projekte und können auch präzise Aussagen über deren Verlauf und den Zeitpunkt der Produktauslieferung treffen. Die Kommunikation mit dem Kunden wird zuverlässiger.

Das Software-KonfigurationsManagement (SCM) wurde bei der Dresdner Bank in zwei Schritten, die projekthaft durchgeführt wurden, etabliert. Im ersten Schritt wurde ein Werkzeug ausgewählt und entsprechende Verfahren entwickelt. Über Pilotprojekte wurde SCM in ausgewählte Projekte eingeführt und dann in der Bank verbreitet.

Die zunehmende Globalisierung im Bankwesen und auch bei der Dresdner Bank erforderte einen zweiten Schritt: Die Unterstützung verteilter Software-Entwicklung in den weltweiten Entwicklungsstandorten des Hauses. Neben der Einführung des Produktes Distributed Configuration Management (DCM) mußte auch die entsprechende Verfahrenstechnik aufgebaut werden.

Der entstehende erweiterte Supportbedarf, die Projekteinführung und deren Administration mußte international ausgerichtet werden, damit alle Entwicklungsstellen des Konzerns und der SW-Häuser mit internationalen Standorten unterstützt werden.

Es wurde beschlossen, die neutrale Auswahl geeigneter Werkzeuge und die Einführung von Konfigurations-Management in einem Projekt durchzuführen. Dazu wurde eine KM-Gruppe aus drei Mitarbeitern gebildet, darunter auch Berater der SQS Gesellschaft für Softwarequalitätssicherung mbH.

Die KM-Gruppe stellte keine Liste mit Dutzenden von Anforderungen zusammen, deren Überprüfung von Qualität und Disziplin der Mitarbeiter abhing, sondern entwarf ein standardisiertes Szenario, in dem wenige, aber typische Anwendungsfälle der Software-Entwicklung zusammengefaßt wurden.

Besonderen Wert legten die DV-Spezialisten auf Ausschlußkriterien: Funktionen, welche die Tools abdecken mußten und die auf jeden Fall in die Testläufe miteinflossen. Auf diese Weise stellten sie sicher, daß die Werkzeuge alle Hauptanforderungen erfüllten. Während die Dauer der Auswahl auf drei Monate begrenzt werden konnte, mußte die Qualität und die Herstellerunterstützung der ausgewählten Produkte für eine Einsatzdauer von drei bis fünf Jahren ausgelegt sein.

Die Entscheidung fiel auf das Tool Continuus, da es aus Sicht der Dresdner Bank das beste Preis-Leistungs-Verhältnis aufwies; zudem stellte es eine Integration der bestehenden Host-Welt (IBM-MVS) in Aussicht. Dies bedeutet, das nur noch ein Tool für alle Betriebssystem-Plattformen benötigt wird. Der existierende und erfahrene deutsche Support war ebenfalls ein wichtiges Kriterium für die Entscheidung. Weiterhin bietet das Werkzeug mit der Komponente DCM ein wichtiges Instrument zur Unterstützung geographisch verteilter Software-Entwicklung. Mit dem Management-Ansatz kann Konfigurations-Management und Versionierung mit Änderungs-Management verknüpft werden.

Das Ende 1996 aufgesetzte Einführungsprojekt bestand aus einem insgesamt fünfköpfigen Team, drei davon vom Softwarelieferanten. Während der Einführung wurde großer Wert auf Praxisnähe gelegt. Die Verfahrens- und Werkzeugleitfäden wurden innerhalb von drei Pilotprojekten erstellt, also gleichzeitig quasi auf Praxistauglichkeit hin getestet.

Anfang 1997 wurde durch ein Kundenprojekt der Investmentbank die Unterstützung von geographisch verteilter Software-Entwicklung gefordert. Damit wurde wiederum in Zusammenarbeit mit Continuus die erste verteilte KM-Umgebung in den Standorten Frankfurt, Paris und London prototypisch implementiert und auf Tauglichkeit geprüft. Parallel erfolgte ein "Run" auf das definierte Verfahren und auf das Tool Continuus. Es folgte eine umfangreiche Abnahme einer Unternehmenslizenz.

Um den immensen Schulungsbedarf decken zu können, entwickelte das KM-Team, zusammen mit Medialine in Berlin, ein Computer Based Training (CBM). Parallel dazu wurde eine Schulungsreihe aufgesetzt, die ebenfalls international ausgerichtet war.

Mit der Verbreitung von KM wuchs die Erkenntnis, daß bereits bestehende Verfahren stärker als bisher integriert werden sollten. Integration bedeutete hier, daß die Positionierung der einzelnen Verfahren im Software-Management, wie KM-, Test-, QS, Übergabeverfahren und das Änderungs-Management eingebunden werden müssen. Diese Aufgabe wurde in einem zweiten Einführungsprojekt abgewickelt. Hier wird auch die Integration von Web- und KM-Technologie verfolgt. Dabei laufen auch Tests neuer Web-Produkte.

Die Einführung neuer Werkzeuge, insbesondere in einem heterogenen Umfeld, ist immer aufwendig und lehrreich. Rückblickend haben sich folgende Kriterien für einen Einführungserfolg als wichtig erwiesen:

-Es sollte darauf geachtet werden, Aufwände realistisch einzuschätzen. Weiterhin kann ruhig das "big picture" im Auge behalten werden. Zwar wird am Anfang die Benutzeranzahl kleiner sein, Konzepte und Werkzeuge sollten aber auch mitwachsen können.

-Eine Positionierung des KM-Verfahrens zu anderen existierenden Methoden muß unbedingt vor der Einführung erfolgen, da ansonsten Zuständigkeitsfragen die Einführung behindern. Ebenso sind dann auch Arbeiten vom zuständigen Supportteam zu leisten, die nicht originär mit KM zu tun haben wie zum Beispiel die Übernahme von Aufgaben, die eigentlich im Projekt- oder im Testmanagement liegen.

-Die Unterstützung der Projekteinführung durch ein CBT ist bei einer Größenordnung von über hundert Anwendern lohnend und notwendig. Geeignete Schulungs- und Supportkonzepte sind ein wichtiger Bestandteil und sollten, auch in Zusammenarbeit mit dem Hersteller, bereits zu Beginn der Einführung entwickelt werden.

Besonders wichtig für die Dresdner Bank war die Erstellung einer eigenen Supportdatenbank. Damit konnten Kennzahlen über die Qualität des eigenen Supports und des Produktes und somit gesicherte Rückschlüsse auf den Erfolg der Einsatzstrategie gewonnen werden.

Fazit: Mittlerweile arbeiten zirka 500 Entwickler mit Continuus, Tendenz stark steigend. Damit verdeutlicht die Dresdner Bank AG ihre Strategie, das Verfahren flächendeckend einzusetzen. Bereits im kommenden Jahr sollen alle Entwickler damit arbeiten, das heißt über 1200 interne und externe Mitarbeiter.

Bereits jetzt wird sichtbar, daß sich wiederholende Tätigkeiten wegfallen beziehungsweise deutlich vereinfacht werden, zum Beispiel bei der Übernahme von Entwicklungsergebnissen weiterer Projektmitarbeiter. Ebenso bei Weitergabe fertiger Ergebnisse an andere, insbesondere bei Projektübergabe und Auslieferung. Nicht zu vergessen die Pflege von bereits ausgelieferten Produkten beziehungsweise schon produktiven Anwendungen. Bislang war die Wiederherstellung einer Konfiguration nur mit großen Einschränkungen möglich.

Die Bank

Die Dresdner Bank mit Hauptsitz in Frankfurt ist weltweit tätig. Allein in Deutschland verfügt sie über zehn Niederlassungen mit zirka 1500 Geschäftsstellen, wo das eigentliche Bankgeschäft abgewickelt wird; im Ausland wird sie durch 20 Niederlassungen und über 40 Repräsentanten vertreten. Die Frankfurter Zentrale gliedert sich in Geschäftsbereiche (Bankgeschäfte) und in Konzernstäbe. Die Leitung der Geschäftsbereiche ist international ausgelegt.

Zum Konzernstab Organisation gehört die zentrale IT. Zusätzlich befinden sich IT-Abteilungen in London, New York, San Francisco, Tokio und Singapur. Von den weltweit zirka 46.000 Mitarbeitern der Dresdner Bank Gruppe sind zirka 2000 alleine für den Konzernstab Organisation tätig.

Angeklickt

Konfigurations-Management (KM) spielt heute eine zentrale Rolle bei der Dresdner Bank. Dies kommt insbesondere bei Projekten zum Jahr 2000 und der Europäischen Währungsunion zum Tragen. Auch aus Gründen der Revisionssicherheit ist KM aus vielen Projekten nicht mehr wegzudenken. Bei der Verwaltung von Fremdsoftware hält es beispielsweise den juristischen Bestand. Bereits vor Abschluß des Projektes stellt die Bank eine Produktivitätssteigerung von zwei bis fünf Prozent fest.

*Mathias Brück arbeitet im Konzernstab Organisation IT-Infrastruktur der Dresdner Bank.