Mehr als eine Aufgabe forderte die IT-Techniker der Comdirect-Bank heraus: Der Handel mit Aktien, Optionsscheinen und Fonds sollte attraktiver gestaltet werden. Außerdem konnten die Kunden mit dem vorhandenen Personal nicht adäquat bedient werden, so daß es die Vorgangssteuerung zu verbessern galt. Zudem sollten Softwareprojekte schneller abgeschlossen werden können.
Die vielfältigen Anforderungen erforderten eine Überarbeitung der Architektur. Das Projekt wurde zur Chefsache, die PDV Unternehmensberatung GmbH, Hamburg, zum Projektpartner.
Durchgängige Modularität
Den Bankanwendungen liegt nun ein offenes Datenmodell zugrunde, das zudem einen schnelleren Zugriff auf die Informationen als bisher erlaubt. Alte und neue Anwendungen sind in Komponenten gegliedert. In der neuen Workflow-Applikation funktionieren die Bestandteile der Vorgangsbearbeitung automatisch; alte und neue Applikationen wurden integriert.
Die Client-Server-Architektur ist um Zwischenschichten (siehe Abbildung 1) erweitert. Dabei sind die Zugriffe des Clients als User-Objekte definiert und in "Powerbuilder" implementiert. Sie kommunizieren per External-Function-Call mit einer Client-Zwischenschicht, die aus einer Dynamic Link Library (DLL) mit Application Programming Interfaces (APIs) besteht. Außerdem sind in der Client-seitigen Zwischenschicht das Fehlerhandling und die Datenaufbereitung angesiedelt.
Für die Kommunikation mit den Server-Komponenten wählte die Comdirect-Bank DCE/RPC-Mechanismen und Stub-Funktionen. Die RPC-Stacks treffen auf der Server-Seite ebenfalls auf eine Zwischenschicht. Diese ist der Datenbank vorgelagert und enthält, analog zur Client-Seite, den Stub-Bereich. Darin angesiedelt sind die Daten-Server-Funktionen mit der Zugriffslogik.
Außerdem ist der Daten-Server in einen kontrollierenden Prozeß, den eigentlichen Daten-Server, und einen ausführenden Prozeß, den Slave-Daemon, unterteilt. Je nach Last baut der Daten-Server mehr oder weniger Slave-Daemons auf und ab. Das macht die Datenzugriffe schneller.
Darüber hinaus bietet die Auslagerung der Funktionen und der Schnittstellen-Beschreibung in eine Zwischenschicht Möglichkeiten eines schrittweisen Übergangs von Alt- zu Neuapplikationen. Zudem erlaubt die Bündelung von Datenbankzugriffen, Front- und Back-end-Unabhängigkeit, so daß sich diese Systeme gegebenenfalls auswechseln lassen.
Die Grundlage der API-Komponenten ist ein Geschäftsprozeßmodell (siehe Abbildung 2). Dieses spiegelt die Produktstrukturen wider. Neue Produkte lassen sich somit dynamisch konfigurieren. Es bedarf keines Programmieraufwandes, um Finanzprodukte zu ändern oder neue einzuführen.
Anwendungen sind konfigurierbar
Die Bedieneroberfläche ist ebenfalls konfigurierbar und direkt mit Dialogen im Back-Office-Bereich verknüpft. Zugleich sind für die Masken und Bearbeitungsschritte in der Datenbank Werte hinterlegt. Diese Kennzahlen geben Auskunft über den Bearbeitungsstand des Vorgangs. Indem bestimmte Abläufe und Reihenfolgen vorgegeben sind, fungieren die Arbeitsstati im Gesamtsystem als Steuerungskomponenten.
Bisher mußten die Daten für das Client-Server-System der Comdirect-Bank und noch einmal für die Weiterverarbeitung im Mainframe-System der Muttergesellschaft Commerzbank erfaßt werden. Um diesen Aufwand und diese Fehlerquelle zu vermeiden, wurde die Host-Anbindung derart geändert, daß die Daten von den Mitarbeitern nur noch einmal eingegeben werden müssen. Damit beschleunigten sich zugleich die Antragszeiten zur Kontoeröffnung.
Mit Hilfe der neuen Architektur entstand Ende 1998 als erstes das Finanzprodukt "Get it All". Es gilt bei der Comdirect-Bank als kundenfreundliches Produkt, das zudem in kurzer Zeit installiert werden konnte. Es bündelt günstig mehrere ähnliche Angebote im Aktienbereich.