In den 90er Jahren begann in der Dresdner Bank die Umstrukturierung der IT-Architektur in eine dezentrale Systemstruktur: Die Terminals an den Endstellenrechnern wurden durch intelligente Unix- und NT-Workstations ersetzt. Heute stehen in den rund 1500 Geschäftsstellen etwa 20000 Sinix- und NT-Workstations, die mit AIX-Servern auf Geschäfts- beziehungsweise Niederlassungsebene lokal verbunden sind. Um diese komplexe und heterogene Systemumgebung effizient zu managen und die Anwendungsentwicklung zu entlasten, damit sie sich auf die Geschäftslogik konzentrieren kann, entschloß sich die Dresdner Bank zum Einsatz einer Middleware.
Sie erfüllt mehrere Aufgaben: Zum einen werden durch die Entkoppelung von Anwendungs- und Systemebene Investitionen langfristig geschützt, denn bestehende Anwendungen können an neue Technologien rasch angebunden werden. Zum anderen erlaubt die Middleware die Bank in die Lage zu versetzen, übergreifende funktionale Komponenten und Dienste, die nicht anwendungsspezifisch sind, modular in eine neutrale Schicht zu betten und allgemein zur Verfügung zu stellen.
Ziel war es dabei, auf Workstations mit unterschiedlichen Betriebssystemen ein effektives Standardkommunikationsmittel einzusetzen. Damit sollte die Möglichkeit geschaffen werden, zwischen Applikationen aus dem "Partnerdatensystem" (PAD), einem Grunddatensystem, das die bisherige auf Stammnummern bezogene Systematik ablöst, und dem "Privatkunden-Instrumente-System" (PKI) nachrichtenorientiert Daten auszutauschen und gezielt in Benutzerdialoge zu verzweigen. Sofern eine PAD-Applikation noch nicht gestartet war, sollte dies implizit beim Aufruf mitgetriggert werden. Eine Vereinheitlichung der Benutzeroberflächen sollte unter anderem dadurch erreicht werden, daß für gleiche Aufgaben stets wieder in die gleichen Benutzerdialoge verzweigt werden kann. Daraus ergibt sich zusätzlich noch der Vorteil der Wiederverwendbarkeit auf Komponentenebene. Informationen sollten so für die Kundenberater schneller verfügbar sein und Aufträge rascher bearbeitet werden können.
Die Ausgangssituation war wie folgt: Die Kommunikation verlief über unidirektionale Aufrufe. Dabei bestand nicht die Möglichkeit, dem Aufruf unmittelbar einen Bearbeitungskontext (Kundendaten) mitzugeben.
Diese Daten wurden in einen Notizblock geschrieben und mußten dann von der gerufenen Applikation ausgelesen werden, mit dem Manko, daß eine parallele Bearbeitung von Kunden dabei nicht möglich war. Bei Abschluß von Transaktionen, wie zum Beispiel der Bereitstellung eines Privatkredits, konnten diese Informationen nicht automatisch in einen Informations-Pool auf der Workstation (PKI-Kundenübersicht) münden. Vielmehr mußte der Berater diesen Prozeß eigenverantwortlich anstoßen und eine Aktualisierung der Daten vom Zentralsystem anfordern. Außerdem konnte man nicht direkt in Teilfunktionen der Applikationen einsteigen, zum Beispiel den Änderungsdienst zum Extra-Sparen, sondern mußte die Gesamtapplikation Extra-Sparen aufrufen.
Diese Form des Informationsflusses war zum Teil schwerfällig und für die Berater vor Ort zeitaufwendig. Gefragt war daher eine Lösung, in der Anwendungen wie Server und Clients fungieren. Anwendungen sollten effizient miteinander kommunizieren können, um Informationen dynamisch auszutauschen und zu nutzen. Eine weitere Anforderung an die neue Lösung war das Ordnen der Informationen in Themenkomplexe, so daß die solche Nachrichten erhalten, mit denen sie etwas anfangen können. Es sollte ermöglichen, bestimmte "Themenrubriken" zu "abonnieren".
Im Rahmen einer Studie wurden die Anforderungen strukturiert und die Konzeption des Kommunikationsbusses erarbeitet. Dabei entschied sich die Dresdner Bank, den "Application Bus Service" (ABS) als neuen Service in Erweiterung der Middleware "Distributed Application Platform"( DAP) von der Münchner Norcom Informationstechnologie und Unternehmensberatung GmbH entwickeln zu lassen. Er basiert auf der Idee, daß Anwendungen gleichberechtigt im Netz miteinander kommunizieren und Daten austauschen können, um die Informationsverfügbarkeit zu erhöhen. Dieses Prinzip ist vergleichbar mit der Kommunikation von Hardware-Einheiten über die Busleitung von Computern. Die Einbettung in die Middleware DAP stellt dabei sicher, daß der Informationsbus für die gesamte heterogene IT-Umgebung mit allen Unix- und NT-Workstations verfügbar ist und damit Anwendungen Informationen empfangen und abrufen.
Ein Beispiel: Verschiedene Anwendungen aus dem Privatkundengeschäft nutzen den umfassenden Grunddatenbestand des Partnerdatensystems. Der Einstieg in die verschiedenen Anwendungen verlief bisher über den ehemaligen "Service-Manager". Heute steht dem Kundenberater dafür der neue "Dresdner Bank Desktop" zur Verfügung. Seine Kommunikationsbasis setzt auf den Application Bus Service auf, um die Anwendungen so zu koppeln, daß Informationen direkt ausgetauscht werden können. Der Kundenberater, der seine Desktop-Anwendung aufruft, sieht zunächst seinen Produktbaum. Er holt sich seinen Kunden oder Geschäftspartner durch einen einfachen Suchdialog über Stammnummer oder Name auf den Desktop und wählt dann im Produktbaum eine entsprechende Anwendung aus, beispielsweise Sparbrief oder Extra-Sparen. Benötigt er nun weitere Informationen aus anderen Anwendungen, braucht er nur im Produktbaum zu navigieren und die an ABS angeschlossene Anwendung per Mausklick zu öffnen. Da die Kontextdaten, zum Beispiel Stammnummerninformationen, gleich mitgeliefert werden, entfällt eine erneute Stammdatensuche, so daß der Kundenberater direkt die Informationen des Kunden vor sich hat. Damit kann sich der Berater schnell einen Gesamtüberblick über die Geschäftsbeziehung verschaffen, die der Kunde oder Partner mit der Bank pflegt, denn er ist nur einen Mausklick von allen relevanten Informationen aus anderen bankfachlichen Anwendungen entfernt. Sofern es die jeweilige Applikation erlaubt, können auch spezielle Funktionen, zum Beispiel eine Prolongation des Extra-Sparens, direkt aufgerufen werden. Diese Services der einzelnen Applikationen werden dem Berater auch im Desktop angezeigt.
Umständliches Wechseln zwischen verschiedenen DV-Anwendungsbereichen, beispielsweise in ein anderes bankfachliches Themengebiet, und jeweiliges Zurückschreiben und Abgleichen von Informationen gehören damit der Vergangenheit an. Wird eine Transaktion abgeschlossen, zum Beispiel der Kauf eines "Extra-Sparen-Vertrags", erfolgt über ABS automatisch eine Aktualisierung der Konten- und Vertragsübersicht im Desktop.
Die Funktionsweise des ABS baut dabei auf das Modell von Publisher (Sender) und Subscriber (Abonnent oder Empfänger) von Informationen auf, wobei jede Anwendung sowohl Publisher als auch Subscriber sein kann. Das Bussystem ist in einem permanenten Bereitschaftsmodus und sendet und empfängt von und an Anwendungen Informationen und Nachrichten, die damit allen angeschlossenen Anwendungen gleichzeitig zur Verfügung stehen.
Als ständig laufender Prozeß vermittelt die Lösung Nachrichten und Informationen zwischen Anwendungen und generiert Ereignisse über Zustandsveränderungen. Der Bus-Service bietet dabei ein fein differenziertes Message-System, das zwischen drei verschiedenen Kommunikationsmodi unterscheidet: Message, Information und Event. Alle angeschlossenen Anwendungen können diese drei anwendungsbezogenen Nachrichtentypen individuell für ihren Informationsbedarf nutzen.
Unter "Message" versteht der Dienst dabei einen Nachrichtenaustausch oder Funktionsaufruf, der an eine konkrete Anwendungsadresse im Netz geschickt wird, also eine gerichtete Eins-zu-eins-Kommunikation. So können beispielsweise gezielt entfernte Anwendungen und Anwendungsteilfunktionen aufgerufen werden. Die Adressierung basiert dabei nicht auf physikalischen, sondern auf logischen Adressen.
"Info" ist in ABS dagegen eine Meldung, die quasi "anonym" denjenigen "Abonnenten" oder Gruppen automatisch zur Verfügung stehen, die an diesem Themenkomplex Interesse angemeldet haben. Diese themenbezogene Steuerung von Informationen entlastet Netz und Anwendungen, denn die Adressaten erhalten nur die für sie relevanten, "gefilterten" Meldungen und werden nicht von allen Informationsbewegungen im Netz überflutet.
Automatischer Neustart-Mechanismus
Die Message-Form "Event" sorgt dafür, daß Nachrichten allgemeiner Art als "Systemereignisse" generiert werden und damit alle, die sich hierfür angemeldet haben, automatisch benachrichtigt werden. Das An- und Abmelden einer Anwendung wird beispielsweise automatisch als "Event" erfaßt. Über diesen Kommunikationsmechanismus unterstützt der Kommunikationsbus außerdem die Ausfallerkennung: Stürzt beispielsweise eine Anwendung ab, registriert ABS dies als Event oder Systemereignis, über das alle im System Beteiligten und Interessierten informiert werden. Als Absicherung der Arbeitsprozesse kann der Dienst zusätzlich einen automatischen Neustart-Mechanismus für geschäftskritische Anwendungen auslösen.
Neben dem Mitgeben von Anwendungsinformationen direkt an der Schnittstelle der Lösung kann über eine Verknüpfung zusätzlich festgelegt werden, ob zu einem Themengebiet noch weitere themenbezogene Daten oder "Kontexte" im Hintergrund bereitstehen. Dies bedeutet, daß dem Informationsverbund indirekt neben Anwendungen auch Datenhaltungen zur Verfügung stehen, soweit sie sich in einem bestimmten, thematisch passenden Kontext befinden und mit der Anwendung entsprechend verknüpft sind. Diese Vorgehensweise empfiehlt sich zum Beispiel bei größeren Datenmengen und wenn mehrere Applikationen unmittelbar über eine Veränderung der Datenbasis informiert werden müssen.
ABS stellt sicher, daß mehrere Arbeitsvorgänge gleichzeitig stattfinden können und der Anwender zwischen ihnen frei wechseln kann. So können zum Beispiel mehrere Kundenanfragen gleichzeitig erledigt werden.
Die Aufspaltung in kleine, unabhängige Dialogeinheiten und die Kopplung über den Kommunikationsbus sorgt darüber hinaus für eine höhere Wiederverwendbarkeit der einzelnen Komponenten und bessere Wartbarkeit. Da ABS von vorneherein in die Middleware DAP eingebettet wurde, bietet es der Anwendungsebene eine Entkopplung von der Betriebssystem-Ebene. Einmal entwickelte Anwendungen laufen auf allen Systemen. Zahlreiche Funktionen und Dienste sind damit für unterschiedliche Anwendungen wiederverwendbar und müssen nur einmal programmiert werden. Umgekehrt ist es nicht notwendig, Veränderungen an Funktionen für jede Anwendung einzeln nachzuziehen. Das reduziert den Aufwand für Wartung und Administration. Das Bussystem vereinfacht so auch die Anwendungsentwicklung.
Aber auch die Endanwender der Dresdner Bank profitieren von der neuen Anwendungskommunikation, denn sie unterstützt und beschleunigt die Arbeitsabläufe: Einheitliche Oberflächen im Rahmen des auf ABS aufsetzenden Desktops sorgen dafür, daß für gleiche Aufgaben in unterschiedlichen Anwendungen einheitliche Dialogschritte gelten. Die Lösung ist durch die Einbeziehung ihrer Oberfläche, ihrer Funktionalität und durch Datenaustausch die Basis für die Verarbeitung von Informationen aus mehreren Anwendungen.
Die Bank
Der Dresdner-Bank-Konzern ist mit rund 1500 Geschäftsstellen und knapp 49000 Mitarbeitern in über 70 Ländern der Welt - darunter in allen großen Finanzzentren - tätig und gehört hinsichtlich Bilanzsumme, Marktkapitalisierung und Kundenzahl zu den führenden Banken Europas. Der Konzern ist mit seiner Produktpalette in vier Sparten organisiert - Firmenkunden, Privatkunden, Investment-Banking und Institutional-Asset-Management. Zum Konzern gehört die Ad- vance Bank als beratungsintensive Direktbank. Für Dienstleistungen und Produkte im Investment-Banking steht der Name Dresdner Kleinwort Benson, ein führender Akteur im europäischen Investment-Banking mit zunehmend internationalem Aktionsradius.
Angeklickt
Die Dresdner Bank setzt für ihre dezentralen Systeme in den inländischen Filialen ein Bussystem für die Anwendungskommunikation ein. Verlief diese bisher in einer klassischen Rollenaufteilung zwischen "Sendern" und "Empfängern", so können sich Anwendungen mit dem "Application Bus Service" (ABS) jetzt wechselseitig mit Daten versorgen, und zwar unabhängig vom jeweiligen Betriebssystem. Informationen sind schneller verfügbar, davon profitieren Bankangestellte und Kunden.
*Volker Waldenburger gehört bei der Dresdner Bank zum Konzernstab Organisation und Informatik, Bereich IT-Research und Standards, und ist Leiter Middleware-Produkte.