Wer Service-orientierte Architektur oder kurz SOA sagt, meint häufig Web-Services - genauer gesagt: "Websphere" von IBM oder die "Enterprise Service Architecture" (ESA) beziehungsweise "Netweaver" von SAP. Doch die Idee entstand unabhängig von den Produktentwicklungen der beiden Anbieter. Das wurde einmal mehr auf dem diesjährigen "Zukunftsforum IT" deutlich, zu dem Euroforum und "Handelsblatt" nach Berlin geladen hatten.

In ein Zukunftsforum passt das Thema insofern, als Marktbeobachter die ersten auf der SOA-Architektur basierenden Projekte frühestens im übernächsten Jahr erwarten. Doch die Diskussionen und Vorbereitungen sind in vollem Gange: Neben Voice over IP und Sicherheitsfragen gibt es derzeit kaum ein Thema, das die IT-Chefs so stark umtreibt. Service-Orientierung verspricht, die Komplexität der Anwendungslandschaft zu reduzieren und die Prozesse zu beschleunigen.

Als Pionier auf diesem Feld präsentierte sich die Credit Suisse Group (CS). Das in Zürich beheimatete Bankunternehmen hat sich Ende der 90er Jahre entschieden, seine Architektur nach den Prinzipien der Objektorientierung neu zu ordnen. Dazu nutzte es die von der Object Management Group (OMG) spezifizierte Common Object Request Broker Architecture (Corba). Sie dient heute als Integrationsplattform für wiederverwendbare Anwendungsdienste.

Wie in der Bankenwelt üblich, fußten die Credit-Suisse-Anwendungen bis zum Ende des vergangenen Jahrzehnts auf einer stabilen, aber monolithischen und deshalb schwerfälligen Softwareplattform. Die galt es zu modularisieren, berichtete der für die Integrationsarchitektur verantwortliche Claus Hagen.

Der logische Teil ist der schwere

Zunächst wurden die klassischen Bankapplikationen wie Buchung, Kredit oder Wertpa- piere in 19 Domänen unterteilt. Sie umfassen jeweils die Applikationen und die zugehörigen Daten.

Besondere Sorgfalt verwandten die Architekturexperten der Bank auf die Definition der Schnittstellen, denn sie leben länger als die Anwendungen selbst. Dabei galt es zu berücksichtigen, dass die existierenden Systeme teilweise ganz anders geschnitten waren, als es den Vorstellungen der IT-Architekten - und den Vorgaben etwaiger Standardschnittstellen - entsprach. "Der logische Teil ist der schwierigere", lautete Hagens Fazit. Die technische Integration sei weit unproblematischer - aber leider nicht ausreichend.

Die gekapselten Domänen kommunizieren untereinander über "Managed Interfaces"; Hagen umschreibt sie als "Verträge" zwischen den fachlichen Domänen. Sie sehen beispielsweise vor, dass die Internet-Banking-Anwendung Kontodaten vom Buchungssystem anfordert.

Geschwätzige Markup Language

Als Transportmedium für die Service-Calls fungiert der "CS Information Bus", der im Prinzip aus einer Corba-Middleware mit darunter liegendem Internet Protocol (IP) besteht. Die Anwender greifen mit einem Java-basierenden Web-Frontend auf die Services zu.

Wie Hagen versichert, läuft bereits ein Viertel der gesamten Transaktionslast über Service-Calls. Das sind fünf Millionen Calls pro Tag. Wegen dieser Last seien Web-Services für die CS keine Alternative: "Die Performance reicht noch nicht aus." Das liege vor allem an der "geschwätzigen" Beschreibungssprache XML, mit der die Web-Services-Implementierungen arbeiten. XML-Nachrichten seien um den Faktor zehn größer als die durchsatzoptimierten Corba-Nachrichten.

Gemeinsamkeiten im Ansatz

Inwieweit sich durch die neue Architektur die IT-Kosten der Bank verringert haben, wollte der Integrationsspezialist nicht beziffern. Außer Frage stehe für ihn, dass die CS auf diese Weise mehr IT für weniger Geld bekomme.

Allerdings benötige ein solches Projekt mehrere Jahre, bis es sich auszahle, räumte Hagen ein. Das liege unter anderem an den hohen Upfront-Investitionen in die Technik, die etwa eine Million Euro betragen hätten: "Da brauchen Sie ein Management, das so etwas unterstützt und einen langen Atem hat."

Der Unterschied zwischen einer Request-Broker- und einer Web-Services-Architektur liegt vor allem auf der Implementierungsebene. Vom logischen Ansatz her betrachtet, überwiegen die Gemeinsamkeiten. Das Prinzip der gekapselten Objekte hat das der Services quasi vorweggenommen. Und beide Konzepte gründen auf einer strikten Trennung von Entwicklungsplattform und Verbindungsschicht.

Die Credit Suisse begann vor acht Jahren mit der Umgestaltung ihrer gesamten IT-Architektur; zu dieser Zeit hatte der Begriff Service-Orientierung allenfalls im gastronomischen Gewerbe eine Bedeutung. Kaum drei Jahre alt und auf die SAP-Welt beschränkt ist dagegen das Projekt des Beleuchtungskonzerns Osram, das Christian Gührs auf dem Zukunftsforum vorstellte.

Gührs leitet bei Osram in München die Abteilung Web Development und IT-Architektur. In seinen Zuständigkeitsbereich fällt die Integration der drei kontinentalen R/3-Installation in Europa, Nord- und Südamerika sowie Asien - ein Vorhaben, das er noch im laufenden Geschäftsjahr 2005/06 zu Ende bringen will.

Als Integrationsplattform war naturgemäß die SAP-Lösung "Netweaver" ausersehen. Je nach Komponente verfolgte Osram dabei eine unterschiedliche Strategie: Das Business Information Warehouse wird in Nord- und Südamerika, Europa und Asien jeweils separat aufgebaut. Weil die kontinentalen Märkte laut Gührs zum Teil sehr individuelle Ausprägungen zeigen, erhalten sie ihre eigene Business Intelligence (BI). Die drei Datenspeicher speisen jedoch ein globales BI-System, das für konzernweite Analysen dient.

Am Puls der SAP-Entwickler

Die Exchange Infrastructure (XI) hingegen wurde einmal zen- tral installiert, so dass sie als übergreifendes Integrationwerkzeug genutzt werden kann. XI war 2003 ein neues und unerprobtes Produkt. Deshalb bewarb sich Osram bei der SAP für ein Ramp-up, sprich: den Pilotbetrieb unter ständiger Beobachtung und Hilfestellung des Anbieters.

Dass er mit dieser Entscheidung auch ein Wagnis einging, war Gührs durchaus bewusst. Doch aus seiner Sicht über- wogen die Vorteile, insbesondere der direkte Zugriff auf das SAP-Know-how. Zudem sei der "Scope" des Projekts "begrenzt" gewesen, ergänzte er, und damit das Risiko überschaubar. Osram nutzt XI nur in Ausnahmefällen für die Integration von Nicht-SAP-Systemen, so beispielsweise in Tschechien, wo es noch keine R/3-Installation gilbt.

Im März 2003 stieg Osram in das Ramp-up ein, etwa ein Jahr später wurde die Version 2.0 zusammen mit dem Web Application Server 6.20 in Betrieb genommen. Seit dem vergange- nen August läuft das Nachfolge-Release 3.0 produktiv. Damit ist auch der für Gührs größte Nachteil der Version 2.0 - die fehlende Priorisierung von Nachrichten - aus dem Weg geräumt.