Die Frage, wie viele Mitarbeiter in das "Re-Architecture Program" involviert sind, entlockt Stephan Murer ein Schmunzeln. "Fragen Sie lieber, wie viele nicht davon betroffen sind", antwortet der Leiter IT-Architektur, der auf der Geschäftsleitungsebene der Schweizer Großbank Credit Suisse angesiedelt ist. Einen substanziellen Teil seiner IT-Ressourcen - für die Entwicklung und den Betrieb der Schweizer Bankplattform sind das mehrere hundert Millionen Franken im Jahr - wendet der in Zürich beheimatete Finanzdienstleister auf, um seine IT-Architektur zu modernisieren.
Diesem Aufwand entspricht der Gegenstand des Vorhabens. Es geht - einfach ausgedrückt - darum, die überwiegend auf mächtigen OS/390-Mainframes mit dem hierarchischen Daten-Management-System IMS und der Programmiersprache PL/1 basierende IT-Umgebung in eine moderne Entwicklungs- und Anwendungswelt hinüberzugeleiten, ohne die erprobten und funktionstüchtigen Systeme zu ersetzen oder einen unentwirrbaren Applikations-Dschungel zu schaffen.
Um die Hintergründe für dieses Mammutprojekt zu schildern, bemüht Murer die Firmengeschichte: Nach turbulenten Geschäftsjahren, während derer diverse Mergers zu verkraften waren, konnte die Credit Suisse 1997 endlich wieder über den Tellerrand der notwendigen taktischen Erwägungen hinaussehen und strategische Positionen beziehen. Dabei richtete sie ihr Augenmerk insbesondere auf den IT-Bereich, wo sie einen gewissen Nachholbedarf festgestellt hatte: "Die traditionellen Lösungen mit einem zentralisierten Host-System und Tausenden von Terminals reichten für neue Anwendungen nicht mehr aus; moderne grafische User-Interfaces machten es notwendig, mehr Rechnerkapazität beim Anwender vorzuhalten; zudem hatten Spezialisierung und Automation zu Dutzenden von Spezialsystemen (Geldausgabeautomaten, Telefon-Banking, Handelssysteme etc.) mit Hunderten spezieller Schnittstellen geführt", bekannte Murer im vergangenen Herbst anlässlich der IEEE-Konferenz "Enterprise Distributed Object Computing".
Kurzfristig anberaumte Reengineering-Vorhaben und Restrukturierungen hätten die Flexibilität der existierenden Systeme bis an die Grenzen ausgereizt, so der Credit-Suisse-Manager weiter. Die unausweichliche Konsequenz seien Projektverzögerungen, riesige Ausgaben für winzige Systemänderungen und - last, but not least - auch Qualitätsprobleme gewesen. Die Bank war also hin- und hergerissen zwischen dem Wunsch, ihr Geschäft mit neuer Technologie zu unterstützen, und der Notwendigkeit, die erforderliche Stabilität für den täglichen Betrieb zu gewährleisten.
Eine Lösung für dieses Problem hätte vielleicht darin bestanden, das gesamte System durch ein neues zu ersetzen. Doch nach drei Jahrzehnten der Weiterentwicklung hatten die Programme einen Grad von Integration und Spezialisierung erreicht, der sich kurzfristig nicht wiederherstellen ließ - weder durch gekaufte Standardanwendungen noch durch eine Eigenentwicklung.
Tatsächlich zog die Credit Suisse letztere Option ernsthaft in Erwägung. Doch am Ende der Aufwandsberechnung stand ein niederschmetterndes Ergebnis: Die dafür notwendige Investition läge in der Größenordnung von einer Milliarde Franken, die Projektdauer zwischen fünf und sieben Jahren. "Das ist schlicht nicht praktikabel", konstatiert Murer; "wir können heute nicht wissen, wie das Bankgeschäft in fünf Jahren aussehen wird - ganz zu schweigen vom Projekt-Management-Aufwand und der zusätzlichen Manpower, die dafür notwendig wären."
Kunden-Applet muss mit Mainframe-System redenDas IT-Personal quasi vollständig zu ersetzen ist sogar für einen attraktiven Arbeitgeber wie die zweitgrößte Schweizer Bank unmöglich. Hier liegt der Hauptgrund dafür, warum die Credit Suisse für Neuentwicklungen im Mainframe-Bereich auch heute noch auf PL/1 zurückgreift. Außerhalb der IBM-Großrechnerwelt sind aber auch die objektorientierten Sprachen Smalltalk und immer häufiger Java im Einsatz.
So hat der Finanzdienstleister die Züricher Softwareschmiede Ergon Informatik AG beauftragt, neue Internet-Banking- und Direkt-Brokerage-Systeme zu entwickeln, die dem Anwender den Zugriff via Java-Client ermöglichen (siehe nebenstehenden Artikel). Das Java-Applet auf dem Kunden-PC sollte jedoch in der Lage sein, mit den PL/1-Programmen auf dem Mainframe-System zu kommunizieren. Wie an diesem Beispiel plausibel wird, muss das Re-Architecture-Programm deshalb auch darauf abzielen, in unterschiedlichen Sprachen und Betriebssystemen entwickelte Anwendungen miteinander zu verbinden.
Das Gesamtvorhaben unterteilt sich also in eine Reihe von Teilprojekten. Dazu gehört das Bestreben, die 40 Millionen Codezeilen, aus denen sich die zentralen Systeme zusammensetzen, bis zum Ende des kommenden Jahres kräftig auszudünnen. Die Anzahl der Einzelprogramme soll sich dabei um 70 Prozent verringern. Laut Murer lässt sich auf diese Weise nicht nur die Komplexität der Systeme reduzieren, sondern auch der 7x24-Stunden-Betrieb erleichtern und die Skalierbarkeit erhöhen. Bis heute haben die Systemanalytiker immerhin schon ein knappes Drittel der Programme aussortiert.
Ähnliche Ziele verfolgt ein anderes Teilprojekt; es beschäftigt sich damit, die Auswertungsprozesse von den Online-Transaktions-Systemen zu trennen und auf einer Plattform zu konzentrieren. Am Ende dieser Anstrengungen will die Credit Suisse über ein sauber von den operativen Daten abgegrenztes Data Warehouse verfügen.
Die Bestandteile eines IT-Systems leben unterschiedlich lang. Kernanwendungen wie die Datenzugriffslogik bleiben jahrzehntelang unverändert, während sich die Geschäftslogik etwa alle zehn Jahre grundlegend ändert und die Präsentationsschicht möglicherweise alle paar Monate erneuert werden muss. Deshalb predigen IT-Gurus schon seit Jahren, dass die einzelnen Komponenten möglichst durch exakte Schnittstellen voneinander getrennt werden müssen.
Das hört sich allerdings einfacher an, als es ist, erläutert Thomas Koch, Technical Director Consulting beim IT-Dienstleister Interactive Objects GmbH (IO), Freiburg im Breisgau. Koch begleitet die Credit Suisse seit Beginn des Re-Architecture-Programms und weiß, wie schwierig es ist, jahrzehntelang modifizierte, immer weiter ausgebaute und vielfältig miteinander verwobene Programme zu isolieren: "Das Ziel heißt: unabhängige Schnittstellen. Aber das ist nicht immer möglich", lautet sein ernüchterndes Fazit. Im Zweifelsfall sei also zu überlegen, ob gewisse Teile des Systems möglicherweise doch neu entwickelt werden müssen.
Die Entflechtung der bestehenden Systeme ist eine Voraussetzung für das wohl wichtigste Teilprojekt. Es widmet sich der Aufgabe, die bereits angesprochene Brücke über unterschiedliche Betriebssysteme und Sprachen hinweg zu bauen. Am Ende dieses Wegs lockt - in Murers Worten - ein "Service-Layer", der es den Schweizern ermöglicht, ihr vorrangiges strategisches Ziel zu erreichen: "Managed Evolution" oder auf Deutsch: den allmählichen, disziplinierten Übergang von der bestehenden auf eine künftige IT-Architektur.
Dabei macht Murer deutlich, dass es ihm keinesweg um eine Ablösung der Großrechnersysteme zu tun ist, für die er derzeit keine Alternative sieht. Auslöser für die Entwicklung des Service-Layer sei vielmehr der Wunsch gewesen, neue E-Commerce-Applikationen, die sich im Rahmen der bestehenden Systemwelt nicht mehr realisieren ließen, mit den vorhandenen Host-Anwendungen zu integrieren.
Der Service-Layer basiert weitgehend auf dem Integrationsstandard Common Object Request Broker Architecture (Corba), wie ihn die Object Management Group (OMG) für den Aufbau und Betrieb von Schnittstellen zwischen unterschiedlichen Systemwelten spezifiziert hat. Konkret entschied sich die Credit Suisse für die Corba-Implementierung "Orbix" des Softwareanbieters Iona Technologies Inc., Dublin.
Mit Hilfe der in Corba enthaltenen Interface Definition Language (IDL) gingen die Credit-Suisse-Entwickler gemeinsam mit externen Spezialisten daran, die bereinigten Anwendungen in "Servicemodulen" zu kapseln. Diese Systembausteine zeichnen sich dadurch aus, dass sie sowohl Daten als auch die darauf operierenden Funktionen enthalten und mit der Außenwelt lediglich über exakt definierte Schnittstellen kommunizieren. Für seinen Renommierkunden war Iona auch bereit, Orbix um einen IDL-Compiler für PL/1 zu erweitern.
Im Schnitt wird jedes Interface zweimal genutztBei der Credit Suisse sind derzeit etwa 100 solcher Interfaces definiert. Wo genau die Grenzen zwischen den Services verlaufen, behält Murer für sich; die Antwort auf diese Frage sei geschäftskritisch, so seine Begründung. Lieber berichtet er davon, dass es dem aus rund zwei Dutzend Entwicklern bestehenden Team gelang, viele Schnittstellen mehrfach zu verwenden; im Schnitt werde jedes Interface zweimal genutzt. Das ist keineswegs trivial: Jede Wiederverwendung spart der Bank Entwicklungskosten in Höhe von 100 000 Franken und fällt damit auch bei einem jährlichen Projektetat von mehreren Millionen Franken ins Gewicht.
Verbunden werden die Servicemodule über einen "Information Bus", der sich aus unterschiedlichen Middleware-Produkten zusammensetzt. Neben Orbix verwendet die Credit Suisse den "Smalltalk-Broker" von Promia Inc., San Franzisko, sowie die für einen asynchronen Nachrichtenaustausch ausgelegte IBM-Middleware "MQ Series" , aber auch - innerhalb der Java-Welt - die von Sun stammenden "Enterprise Javabeans" (EJB). Über das in Corba integrierte Internet Inter ORB Protocol (IIOP) greifen die Clients auf die Servicemodule zu.
Ein solches Konstrukt erzeugt einen gewissen Overhead. So wusste auch die Credit Suisse zunächst nicht genau, wie sich ein großes Transaktionssystem verhielte, wenn es über Corba-Schnittstellen betrieben würde. Im Frühling dieses Jahres fuhr sie deshalb einen ersten Testbetrieb im Servicebereich Kundeninformationen, wobei sie Zugriffe von 6500 Clients auf ein einziges IMS-System simulierte. Der damals erreichte Durchsatz von durchschnittlich 30 Transaktionen pro Sekunde wurde in der Zwischenzeit noch erheblich verbessert. Den Verantwortlichen erscheint er durchaus annehmbar.
GEWALTIGE DIMENSIONENMit einem Marktanteil von rund 20 Prozent ist die Credit Suisse nach der UBS die zweitgrößte Bankgesellschaft der Schweiz. Ihre IT-Umgebung entspricht dieser Bedeutung; sie besteht unter anderem aus 19 OS/390-Mainframes mit insgesamt 11 000 Mips sowie aus 1000 weiteren Servern und 40 000 aktiven Terminals, die auf ein Datenvolumen von 40000 GB zugreifen. Pro Tag werden rund 16 Millionen IMS-Transaktionen aufgerufen. Das zentrale System umfasst 40 Millionen Codezeilen; mehr als 100 selbstentwickelte Client-Server-Applikationen sind im Einsatz; die 1500 IT-Mitarbeiter arbeiten gleichzeitig an mehreren hundert kleinerer Projekte, die zu 30 bis 40 Prozent direkt von dem großangelegten Re-Architecture-Programm abhängen. Das IT-Budget liegt bei mehreren hundert Millionen Franken im Jahr.
Abb.1: Disziplinierte Evolution
Vorrangiges Ziel ist die "Managed Evolution", der disziplinierte Übergang auf eine künftige IT-Architektur. Quelle: Credit Suisse
Abb.2: Ziel: saubere Interfaces
Die Servicemodule sind nur über ihre Schnittstellen mit dem umgebenden System gekoppelt. Quelle: Credit Suisse