Im weltweiten Handel mit Zinsderivaten muß eine Investmentbank schnell die Preise festlegen können. Dafür braucht sie einerseits externe Marktdaten, zum Beispiel aktuelle Zinssätze, die sie von externen Informationssystemen beziehen kann; andererseits arbeitet sie mit internen Marktdaten aus ihren eigenen Research-Abteilungen. All diese Daten müssen schnell und zuverlässig weltweit in allen Niederlassungen verfügbar sein.

-Klassische Instrumente, wie zum Beispiel Swaps, Optionen und Futures, reichen oft nicht mehr aus, um die komplexen Risikopositionen internationaler Kunden abzusichern. Neue Instrumente werden benötigt, die schnellstmöglich handelbar gemacht werden müssen, das heißt, es muß ein System zur Berechnung und Abwicklung dieser Geschäfte existieren. Hier kommt es darauf an, dem Kunden so schnell wie möglich Instrumente für das Risiko-Management anzubieten.

Aufgrund dieser Anforderungen hat Dresdner Kleinwort Benson mit einem stragegischen Arbitrage- und Risiko- Management-System (Stars++) ein eigenes System für den Handel mit Zinsderivaten entwickelt. Das Front-Office-System wird eingesetzt für Preisbildung, Bewertung, Risiko-Management und Positionsführung von Zinsderivaten. Es ist weltweit in allen Handelslokationen von Dresdner Kleinwort Benson im Einsatz, wobei Markt- und Geschäftsdaten zwischen den Handelslokationen online repliziert werden.

Systemerweiterungen müssen sehr schnell gehen. Hinzu kommen immer neue Anforderungen der Händler. Aus diesen Gründen hat Dresdner Kleinwort Benson ihr Risiko-Management-System von Anfang an objektorientiert entwickelt. Doch das alleine reicht auf Dauer unternehmensweit gesehen nicht aus, denn im Einsatz und in der stetigen Weiterentwicklung dieses Systems, wurde es notwendig, neue Wege zu gehen:

-Programmteile, die in Stars++ enthalten sind - wie zum Beispiel Feiertagskalender und Zinskurven - werden auch in anderen Systemen der Bank benötigt oder sind zum Teil in diesen enthalten, und die anfallenden Daten müssen mehrfach gepflegt werden.

-Ebenso werden aus dem System Daten zu Middle-Office und Back-Office-Systemen exportiert oder abgeglichen. Dies führte dazu, daß für jedes System eine spezielle Schnittstelle implementiert wurde, so daß ein beträchtlicher Aufwand an Implementierung und Wartung entstand.

Diese schwer zu wartende Infrastruktur ist in Abbildung 1 dargestellt. Wie hier leicht zu sehen ist, steigt die Anzahl der benötigten Schnittstellen zwischen den Systemen quadratisch an, sobald jedes System mit jedem kommunizieren soll. Eine solche Infrastruktur ist nicht geeignet, die Bewältigung von Time-to-Market-Anforderungen zu unterstützen. Die Komponententechnologie, das heißt auf einem Netzwerk zur Verfügung stehende "kleine" funktionale Einheiten, bietet die Möglichkeit, Funktionalität über Systemgrenzen (Hardware, Betriebssystem und Programmiersprachen) hinweg wiederzuverwenden. Um die Anzahl der Import-Export-Schnittstellen von Systemen und Komponenten gering zu halten, wurde für den Datentransfer zwischen diesen bei Dresdner Kleinwort Benson ein einheitliches Objektmodell entwickelt. Es baut auf der Common Object Request Broker Architecture (Corba) auf und dient als Information-Bus.

Auf diese Weise bilden die unterschiedlichsten Systeme im Front-, Middle- und Back-Office auf verschiedenen Plattformen eine integrierte IT-Infrastruktur (siehe Abbildung 2).

In der Produktion sind Rechner von Sun (Solaris 2.6), HP (HP-UX 10.20), IBM RS-6000 (AIX 4.1) und Compaq (Windows NT 4.0) für die unternehmensweit verteilten Systeme und Komponenten im Einsatz.

Um die Performance im Einsatz und bei der Entwicklung neuer Komponenten und Systeme zu steigern, setzt Dresdner Kleinwort Benson auch objektorientierte Datenbank-Management-Systeme (ODBMS) ein. In der Entwicklung objektorientierter Systeme bieten ODBMS gegenüber den älteren relationalen Modellen (RDBMS) die Vorteile, daß mit den der jeweiligen Programmiesprache eigenen Mitteln persistente Objekte erzeugt, modifiziert und gelöscht werden können. Somit wird kein spezieller Mapping-Code zwischen Methodenaufrufen und der Abfragesprache SQL benötigt. Das Datenbankschema gleicht dem Objektmodell, das heißt komplexe Datentypen müssen nicht in Tabellen und Relationen zerlegt, beziehungsweise aus diesen zusammengesetzt werden. Das reduziert den Entwicklungs- und Wartungsaufwand und sorgt zudem für besseres Laufzeitverhalten.

Durch die Fähigkeit von einem Objekt andere referenzierte Objekte direkt anzusprechen und somit in dem gesamten Objektbaum ohne weitere Abfragen an die Datenbank zu navigieren, wird zudem durch den Einsatz von ODBMS eine höhere Performanz des Systems erzielt (siehe Kasten "RDBMS - ORDBMS - ODBMS").

Eine große Stärke der Komponententechnologie ist die Fähigkeit, mit den Anforderungen zu wachsen. Muß eine Komponente ihre Daten persistent halten, so darf dies keine Auswirkungen auf die Skalierbarkeit haben - das Datenbank-Management-System muß ebenfalls mit den Anforderungen wachsen können, weshalb sich sich Dresdner Kleinwort Benson für das ODBMS von Versant entschieden hat. Dieses ODBMS baut auf einer skalierbaren Objekt-Server-Architektur auf. Das heißt, nur die tatsächlich benötigten Objekte werden in der Datenbank gesperrt und an den Client übertragen, wodurch der Datenverkehr im Netz verringert und die Nebenläufigkeit der Prozesse erhöht wird. Deshalb und aufgrund der verschiedenen implementierten Transaktionsmodelle ist dieses ODBMS eine gute Ergänzung in der komponentenbasierten Infrastruktur der Bank.

Durch den Einsatz von komponentenbasierter objektorientierter Technologie werden Datenredundanzen vermieden und plattformübergreifende Integration sowie schnellere Entwicklungs- und Wartungszyklen erreicht. Daten von mehrfach verwendeten Komponenten - wie zum Beispiel Feiertagskalender - müssen nur zentral an einer Stelle gepflegt werden und stehen sofort allen angeschlossenen Systemen zur Verfügung.

Die verschiedensten Systeme im Front-, Middle- und Back-Office können über einen definierten Information-Bus Daten untereinander austauschen oder abstimmen, was zu einer plattformübergreifenden Integration führt. Neue Systeme können unter Ausnutzung der Funktionen der unterschiedlichen Komponenten über Hardwaregrenzen hinweg schneller und zuverlässiger entwickelt werden, wodurch die Time-to-Market sinkt.

Der Einsatz dieses Produktes reduziert den Entwicklungs- und Wartungsaufwand und verbessert das Laufzeitverhalten der Komponenten und Systeme. Der Wegfall des für relationale Datenbank-Management-Systeme benötigten Mapping-Codes spart bis zu 30 Prozent an Programmzeilen, was sich in verkürzten Entwicklungs- und Wartungszyklen positiv niederschlägt. Sollte sich das Objektmodell ändern, so können Änderungen an dem Datenbankschema zur Laufzeit vorgenommen werden. Mittels "lazy evaluation", das heißt, wenn Objekte das erste Mal aus dem alten Schema geladen werden, werden von dem ODBMS die Objekte an das neue Schema angepasst. Diese Schema-Evolution erhöht die Flexibilität in den Entwicklungszyklen der Komponenten und Systeme und spart durch Wegfall aufwendiger Wartungsarbeiten an der Datenbank Kosten. Da komplizierte Joins wegfallen, die benötigt werden, um aus RDBMS die Objekte wiederherzustellen, wird das Laufzeitverhalten wesentlich verbessert.

Beispiel

Ein Unternehmen A möchte ab dem 1. Januar 2000 ein neues Werk und benötigt dafür zu diesem Zeitpunkt einen Kredit über 100 Millionen Mark für eine Laufzeit von fünf Jahren. Analysen ergeben, daß bei einem Zinssatz von über sechs Prozent die Investition unwirtschaftlich wird. Das Unternehmen möchte hier das Marktrisiko absichern, einen Zinssatz über dieser Grenze annehmen zu müssen, möchte aber gleichzeitig von eventuell niedrigeren Zinsen vom Markt profitieren.

Dresdner Kleinwort Benson bietet dem Unternehmen eine Option mit einem Strike von sechs Prozent an und übernimmt damit die Risikoposition des Unternehmens A auf den Marktzins am 1. Januar 2000. Sind zu diesem Zeitpunkt die Zinsen niedriger als der vereinbarte Strike von sechs Prozent, so läßt A die Option verfallen und kann von den niedrigeren Zinsen profitieren. Ist die Option für das Unternehmen A "im Geld", das heißt die Marktzinsen liegen über sechs Prozent, so nimmt A die Option in Anspruch, und die Investition bleibt wirtschaftlich.

RDBMS - ORDBMS - ODBMS

Relationale Datenbank-Management-Systeme (RDBMS) sind seit vielen Jahren erfolgreich im Einsatz. Bei komplexen Anwedungen mit stark strukturierten Daten, wie sie in objektorientierten Systemen häufig vorkommen, stößt man jedoch an Grenzen der RDBMS. Datenmodellierung, Anfrageformulierung und -bearbeitung sowie Transaktionskonzepte erfüllen die gestellten Forderungen nicht ausreichend.

Um diese Probleme zu beheben, brachten Hersteller seit Ende der achtziger Jahre objektorientierte Datenbank-Management-Systeme (ODBMS) auf den Markt. Trotz ihres geringen Alters sind sie zum Beispiel bei Finanzinstituten, Telekommunikationsfirmen und Energieversorgern schon gut akzeptiert. Mit dem Ziel einer Standardisierung von ODBMS wurde Anfang der 90er Jahre die ODMG (Object Database Management Group) gegründet, der die meisten Hersteller von ODBMS angehören.

Die RDBMS-Hersteller erkannten die leistungsstarke Konkurrenz zu objektrelationalen Datenbank-Management-Systemen (ORDBMS). Diese ergänzen die grundlegenden Strukturierungsmittel und Datenbanksprachen um objektorienterte Elemente. Diese Weiterentwicklung löst jedoch nur die strukturellen Probleme. Die Navigation im Objektmodell wird nicht unterstützt.

Angeklickt

Eine IT-Infrastruktur auf Komponentenbasis ermöglicht es Dresdner Kleinwort Benson, die Time-to-Market zu verkürzen. Beim Handel mit Zinsderivaten fallen sehr komplexe Daten an, für deren Bearbeitung relationale Datenbank-Management-Systeme nicht schnell genug sind. Die Bank setzt daher auf Objektorientierung.

*Jan Zurek ist Mitarbeiter der TEFKST bei der Dresdner Kleinwort Benson in Frankfurt/M.