In historisch gewachsenen IT-Landschaften findet sich oft eine kaum mehr überschaubare Zahl von unterschiedlichen Schnittstellen. Änderungen, die an einem System vorgenommen werden müssen, wirken sich so häufig über weite Teile der Unternehmens-IT aus und verursachen einen großen administrativen Aufwand. Auch sind viele Prozesse nicht durchgängig automatisiert, da die notwendigen Schnittstellen aus den verschiedensten Gründen bislang nicht realisiert wurden. Immer mehr Unternehmen gehen nun daran, die Baustellen zu schließen. Das Schlagwort dazu lautet Enterprise Application Integration (EAI).
Im Mittelpunkt der EAI-Plattform steht das Messaging-Tool MQ Series. Quelle: Baden-Württembergische Bank AG
XML als Basistechnologie
Die Baden-Württembergische Bank AG wählte einen ungewöhnlichen EAI-Ansatz. Statt aufwändige und teure Tools zu kaufen, entwickelte die IT-Abteilung der Bank eine eigene Plattform, um die spezifischen Probleme im Haus zu lösen. Vor allem die Kosten schreckten das Unternehmen von der Einführung einer umfangreichen EAI-Plattform ab, erläutert Martin Kraft, Mitarbeiter im Bereich Organisation und EDV. Die Bank habe sich im Vorfeld des EAI-Projekts einige der am Markt angebotenen Lösungen angesehen, diese aber als preislich nicht realisierbar verworfen: „Wenn man einen zentralen Message-Hub oder Message-Broker in die Mitte stellt, ist man bei den Hard- und Softwarekosten sofort im sechsstelligen Bereich“, erläutert Kraft. Die Bank entschloss sich im Frühjahr 2001, eine pragmatische und schlanke Lösung im Haus zu entwickeln.
Als Basistechnologie für das Pilotprojekt wurde XML (Extensible Markup Language) vorgegeben, als zentrales Element der zu entwickelnden Integrations-Middleware wählte das Unternehmen das Messaging-Tool „MQ Series“ von IBM. Die Plattform sollte alle eingehenden Daten in ein gemeinsames neutrales Datenformat umwandeln. Hier entschied sich die Bank für das „Network Trade Model“ (NTM) des amerikanischen Anbieters Sungard. NTM ist ein auf XML-Technologie basierendes Datenformat, das speziell für die Beschreibung von Handelsgeschäften angepasst wurde.
Martin Kraft: "Nicht gleich versuchen, eine große Lösung mit zigtausend Transaktionen in der Stunde aufzubauen."
Das Ziel des Pilotprojekts war, erste Erfahrungen mit diesen Technologien zu sammeln und Grundlagenwissen zu schaffen. Die Integration sollte zuerst im kleinen und überschaubaren Rahmen realisiert werden. Kraft erläutert das Vorgehen: „Nicht gleich versuchen, eine große Lösung mit zigtausend Transaktionen in der Stunde aufzubauen, sondern eine mit vielleicht 50 bis 60 Transaktionen am Tag.“
Da innerhalb der IT-Abteilung bislang kein XML- oder MQ-Series-Know-how vorhanden war, mussten die Mitarbeiter geschult werden. Im Bereich XML und der damit verbundenen Transformationssprache XSLT (Extensible Stylesheet Language Transformation) kam die Stuttgarter Wired Minds Informationssysteme GmbH mit Weiterbildungsmaßnahmen zur Hilfe. Bei MQ Series griff IBM der Bank mit Installations-Support unter die Arme.
Schneller reagieren durch Open Source
Die für XML und XSLT notwendigen Prozessoren (Programme, die Steueranweisungen interpretieren) fand die Bank im Open-Source-Bereich. Das Unternehmen entschied sich für Entwicklungen des im Open-Source-Umfeld renommierten Gnome-Projekts.
Obwohl Open-Source-Technologie bisher nur zögerlich in die kritischen IT-Bereiche der Finanzbranche Einzug gehalten hat, setzt die Baden-Württembergische Bank schon seit einiger Zeit auch quelloffene Software ein, etwa die Programmiersprache Perl. Den Vorteil von Open Source sieht Kraft weniger in den geringen Kosten als in der Tatsache, dass der Quellcode eines Programms im Unternehmen vorliegt. Kleinere Korrekturen oder Änderungen ließen sich so schneller selbst erledigen, als es ein externer Dienstleister könnte.
Um schnell erste Erfolge vorweisen zu können, behob das Projektteam zunächst ein vordringliches Problem: Zwischen dem positionsführenden Handelssystem „Arena“, mit dem ein Händler sein Portfolio im Blick behält, und dem Host-basierenden Backoffice-System klaffte eine Lücke. Handelsgeschäfte mussten manuell aus Arena in das Backoffice übertragen werden. Hier realisierte das Projektteam der Bank eine Eins-zu-eins-Verbindung über XML. Diese Schnittstelle ging schon im Juni vergangenen Jahres in den produktiven Betrieb.
Modularer Aufbau
Im nächsten Schritt wurde diese Schnittstelle um eine zentrale Komponente in Form des Messaging-Tools MQ Series erweitert. Anstatt einzelne Systeme direkt miteinander zu verbinden, werden nun die zu integrierenden Lösungen einfach an diese Plattform angedockt. So ist es möglich, weitere Systeme an die Integrationslösung anzubinden.
Die Integrations-Middleware wurde von den Projektverantwortlichen modular aufgebaut. Das Grundprinzip: Das positionsführende Arena-System schickt seine Daten an ein XSLT-Programm, das sie vom Ursprungsformat in das neutrale XML-Format NTM umwandelt (der Vorgang wird als Mapping bezeichnet). Gelingt das Mapping ohne Probleme, werden die XML-Dokumente in eine „Message Queue“ in MQ Series gestellt. Das Backoffice-System ruft dort in vorgegebenen Zeitabständen die Trades zur Verarbeitung ab. Dabei werden die Daten wiederum über den XSLT-Prozessor vom neutralen in das vom Backoffice geforderte Format überführt.
Plausibilitätsprüfung
Beim Mapping können jederzeit Probleme auftauchen, die im Verarbeitungsprozess abgefangen werden müssen. So passiert es zum Beispiel, dass ein Händler aus Versehen die Stückzahl in das Feld eingibt, in dem der Preis stehen sollte. Oder ein obligatorisches Feld bleibt völlig leer. Solche Dokumente müssen aus der Message Queue herausgefiltert und dem Händler nochmals zur Nachbearbeitung vorgelegt werden. Dazu sind die Daten bereits bei der Eingabe und im Integrationssystem auf ihre Plausibilität zu prüfen. Erst wenn ein Trade offensichtlich einwandfrei ist, steht er zum Abruf durch das Backoffice zur Verfügung. Um fehlerhafte Messages wieder an den Absender zurückzugeben, kann jedes Mapping-Programm auch einen Output in die „In-Queue“, also den Dateneingang, des sendenden Systems liefern.
Das Unternehmen
Die Baden-Württembergische Bank AG mit Sitz in Stuttgart ist nach eigener Aussage die größte private Geschäftsbank in Baden-Württemberg. Der Finanzdienstleister konzentriert sich auf mittelständische Firmen und Privatkunden. Die Bank unterhält 53 Niederlassungen, überwiegend in Deutschland, und vier operative ausländische Tochtergesellschaften. Die Bilanzsumme im Jahr 2000 belief sich auf über 24 Milliarden Euro.
Für den Fall, dass ein Dokument so defekt ist, dass es überhaupt nicht mehr verarbeitet oder zurückgeschickt werden kann, haben die Entwickler ebenfalls vorgesorgt. So ein Dokument würde im schlimmsten Fall die gesamte Message Queue blockieren. Deswegen werden Daten, mit denen im automatischen Prozess nichts anzufangen ist, in einer „Dead Letter Box“ abgelegt. Dort können sie manuell weiterbearbeitet und der Fehler analysiert werden. Auf diese Weise sorgt die Bank dafür, dass auf keinen Fall irgendeine Transaktion verloren geht. Um ganz sicher zu gehen, gleicht sie zusätzlich jeden Tag die Daten in den Systemen ab. Diese Analyse übernimmt ein in C geschriebenes Programm. Damit lässt sich vermeiden, dass ein systematischer Fehler in der Integrationsplattform auch beim Abgleich der Datenbestände auftritt.
Datenanalyse ist unverzichtbar
Bei EAI-Plattformen wird häufig vermieden, die Logik direkt in die Middleware einzubringen. Dennoch entschied sich die Baden-Württembergische Bank dazu, wichtige Datenanalysen dort zu verankern. Aus Krafts Sicht war das für die spezifischen Anforderungen des Finanzdienstleisters die beste Lösung: „Das Mapping ist in diesem Bereich nicht von den Datenflüssen trennbar.“ Es hängt davon ab, wie ein Geschäft aufgebaut ist, um welche Art von Geschäft es sich handelt und in welches System es zur Weiterverarbeitung muss. Deshalb ist für Kraft eine Analyse der Daten beim Mapping unbedingt notwendig. „Bei uns liegen die ganzen Schnittstellen-Beschreibungen, die Dateninhalte der Queues in XML und die Mapping-Regeln in XSLT in der Middleware-Plattform.“
Mit der Lösung zeigt sich Kraft zufrieden. Der XSLT-Prozessor laufe im täglichen Betrieb stabil. Durch den modularen Aufbau stelle die Integration weiterer Systeme keine große Schwierigkeit mehr dar. Es müsse lediglich dafür gesorgt werden, dass die Daten, die ein neu anzudockendes System abschickt, in NTM umgeformt werden, erläutert Kraft.
„Wenn man bei der Umsetzung des neutralen Datenformats sauber gearbeitet hat, ist das Ganze eigentlich erledigt, sobald man die System-Schnittstelle an dieses Format überführt hat.“ Zurzeit arbeiten die IT-Mitarbeiter der Bank daran, ein weiteres positionsführendes System anzubinden. Dieses sei technisch bereits fertig, erläutert Kraft.
Auch Systemänderungen, die etwa bei Handelssystemen wie Xetra (häufig in Form von Major Releases) anfallen, wirken sich nun nicht mehr auf alle am Handel beteiligten Systeme aus. Dazu muss nur das Daten-Mapping der veränderten Anwendung angepasst werden. In allen anderen Bereichen ändert sich nichts.
Positiv wirke sich aus, so Kraft, dass die Integrationsplattform durch Verwendung anerkannter, offener und W3C (World Wide Web Consortium)-konformer Standards flexibel gehalten wurde. So lasse sich zum Beispiel bei Bedarf auf ein am Markt verfügbares EAI-Werkzeug migrieren, solange auch dieses die Vorgaben des W3C konsequent umsetze.
Aus wirtschaftlicher Sicht war das Projekt nach Krafts Einschätzung erfolgreich. Da die einzelnen Komponenten auf den jeweiligen Systemen mitlaufen, habe die Bank keine zusätzliche Hardware beschaffen müssen. Die notwendigen Programme seien sehr schlank und belasteten die Systeme im vernachlässigbaren Bereich. Hier sieht Kraft auch einen grundlegenden Vorteil der Lösung: „Wenn man ein zentrales Mapping-Tool einführt, braucht man dedizierte, hochverfügbare Hardware. Da landen Sie schon allein für die Hardware mit Cluster-Lösung bei über 500000 Euro.“ Für die schlanke Lösung der Baden-Württembergischen Bank geht Kraft davon aus, dass der Return on Investment nach sechs bis neun Monaten erreicht worden sei.