Schriftgröße wählen:

Hype und Hoffnung

Bankmagazin 3/06

Seit rund einem halben Jahr geistert der Begriff einer serviceorientierten Architektur - kurz SOA - durch die Fach- und Wirtschaftspresse. Das Konzept bleibt umstritten: Ist es nur alter Wein in neuen Schläuchen, oder stellt SOA die IT-Architektur der Zukunft dar?

Suchte man Anfang dieses Jahres auf der deutschen Seite der Suchmaschine Google nach dem Stichwort "SOA", so präsentierten sich dem wissenshungrigen Internetreisenden an erster Stelle die Aktienkurse der italienischen Versicherung Fondiaria-SAI (SOA.FSE), gefolgt von dem Verein der Versicherungsmathematiker (Society of Actua-ries) und einer Organisation zur Überwachung der Aktivitäten der US Army School of the Americas (SOA Watch). Immerhin zwei Treffer mit Bezug zur Finanzbranche, jedoch erklärt keiner befriedigend das, was die Großen der Softwareindustrie seit gut einem halben Jahr wie Propheten verkünden: Die Ankunft einer "Service Oriented Architecture". Den Begriff der serviceorientierten Architektur gibt es dabei bereits seit dem Ende der neunziger Jahre. Jedoch erfuhr er außerhalb von Softwareentwicklerkreisen erst im letzten halben Jahr weitläufige Beachtung. Bei der Schlagzahl, die Softwareanbieter wie SAP, IBM oder Oracle vorgelegt haben, hätte man erwarten können, auf den Google-Ergebnisseiten von Produkten, Erfolgsberichten und Anleitungen zur erfolgreichen Umsetzung einer SOA überschüttet zu werden -doch Fehlanzeige. Ist SOA also nach E-Business und Outtasking wiederum ein modisches Buzzwords oder doch nur ein reines Thema für die IT-Abteilung? Die Antwort auf die letzte Frage ist definitiv "Nein". Doch versuchen wir, uns dem Thema zunächst vom Ursprung her zu nähern.

Compact Discs sind SOA
Eine serviceorientierte Architektur ist eine Anordnung von Software, die unter anderem das Ziel verfolgt, eine lose Koppelung von Softwareagenten beziehungsweise deren Dienste zu erreichen. Ein Dienst ist dabei eine Arbeitseinheit, die ein Diensteanbieter (Service Provider) für einen Verbraucher (Service Consumer) durchführt, um ein gewünschtes Ergebnis zu erhalten. Dies klingt auf den ersten Blick ziemlich abstrakt. Jedoch ist in unserem täglichen Leben eine SOA überall anzutreffen. Ein Beispiel aus dem Wohnzimmer: Wer eine Audio-CD abspielen möchte, legt diese in einen CD-Spieler, der sie dann abspielt. Der CD-Spieler (Service Provider) bietet dabei einen Abspieldienst (Service) an, den ein Musikfreund (Service Consumer) in Anspruch nimmt. Das Schöne ist, dass man dieselbe CD im Autoradio, auf einem tragbaren CD-Spieler, am PC oder auf der teuren Stereoanlage abspielen kann. Alle diese Geräte (Service Provider) bieten also denselben Dienst an, jedoch mit einer unterschiedlichen Dienstgüte. Dieser modulare Ansatz steht im krassen Gegensatz zu den meisten Softwarearchitekturen der Vergangenheit. Würde man ein Audio-CD-System nach diesen Ansätzen entwickeln, so würde jede CD mit ihrem eigenen Abspielgerät verkauft. Eine Trennung zwischen CD und CD-Spieler wäre nicht vorgesehen. So seltsam das klingt, so real ist dies die Architektur vieler heutiger Softwaresysteme. Der Grund für die von SOA geforderte Auflösung eines monolithischen Systems in lose gekoppelte Diensteanbieter ist dabei zweierlei: Einerseits können Dienste leicht wieder verwendet werden. So würde unter einer SOA beispielsweise die Verwaltung von Kundendaten an einer zentralen Stelle erfolgen. Alle Systeme, die Kundendaten wie beispielsweise eine Adresse benöti gen, würden auf ein und denselben Dienst zugreifen. Gleichzeitig ermöglicht es dieser Ansatz einem Unternehmen, sich auf seine Kernkompetenzen zu konzentrieren, wenn unternehmensfremde Dienste zu verrichten sind. Wenn man über die eigene Anwendung hinausblickt, so gibt es sicher viele Tätigkeiten, die ein spezialisiertes Unternehmen besser kann als man selbst - beispielsweise die Abrechnung von Reisekosten. Statt nun ein Reisekostenmodul fest in einer Anwendung zu codieren, könnte es günstiger und effektiver sein, einen entsprechend spezialisierten Dienst zu nutzen. Unter einer SOA versteht man also letztendlich ein Konzept für eine Systemarchitektur, die die Verbindung von Geschäftsprozessen und ihren IT-Realisierungen als standardisierte, lose gekoppelte Komponenten ermöglicht, die als Dienste - auch als Services bezeichnet - genutzt werden. Diese Dienste sind unter anderem wiederverwendbar und kombinierbar und ermöglichen es, schnell auf veränderte Geschäftsanforderungen reagieren zu können.

Flexibilität bringt Marktvorteile
Die größte Möglichkeit, die eine SOA einem Unternehmen verschafft, ist eine höhere Geschwindigkeit und mehr Flexibilität bei der Umsetzung neuer oder veränderter Geschäftsprozesse in der IT-Landschaft. In einem Markt, in dem die aktuellen eigenen Produkte gegenüber Produkten des Mitbewerbers austauschbar werden, kann man sich nur durch neue Produkte, noch bessere Orientierung an den Bedürfnissen der Kunden und vor allem schnelles Handeln einen Wettbewerbsvorteil verschaffen und mittelfristig am Markt behaupten. Doch neue Produkte müssen nicht nur entwickelt und vermarktet werden, sie müssen auch in der IT-Abteilung umgesetzt werden. Dies wiederum kann nur mit Hilfe von wiederverwendbaren Diensten, offenen Standards und Protokollen zeitnah gelingen. Gleichzeitig ermöglichen die offenen Standards, die Teil einer SOA sind, neue Möglichkeiten der Vernetzung und Nutzung von Daten. Bis vor nicht allzu langer Zeit versuchten die etablierten Softwareanbieter, ihre eigenen proprietären "Internet-Lösungen" zu vermarkten. Heute haben sie sich fast ausnahmslos den offenen Standards geöffnet. Ein Datentausch zwischen aktuellen Systemen verschiedener Hersteller ist jetzt weniger problematisch. Dass die Softwareanbieter diese Offenheit inzwischen aktiv postulieren und unterstützen, ist vielleicht die größte Innovation von SOA und gleichzeitig eine große Chance. Denn in Zukunft erfolgt der Zugriff auf Daten in verschiedenen Systemen nicht mehr über fest definierte Systemschnittstellen, sondern über flexible Diensteanbieter, die die wesentlichen Inhalte neuen und alten Anwendungen zur Verfügung stellen. Die Herausforderung für jedes Unternehmen ist dabei, diese eigenen spezifischen Kernprozesse zu identifizieren und in einem Dienst umzusetzen. Denn nicht jede Anwendung eignet sich für eine SOA und nicht jede Portierung einer Anwendung bringt die erhoffte Kosteneinsparung oder Effizienzsteigerung. Zudem gibt es noch ein Problem zu berücksichtigen, das in Japan das"Jahr-2007-Problem" genannt wird. Denn in diesem Jahr beginnt die Generation der gelernten Cobol-Entwickler in Rente zu gehen. Da die meisten Kernbanksysteme Jahrzehnte alt sind, viele proprietäre Technologien nutzen und Jahrzehnte an eigenen Modifikationen enthalten, wird es zunehmend schwierig und teuer, einen entsprechenden Stab an Entwicklern aufrecht zu erhalten. Während kleinere Banken noch Berufsanfänger von den Cobol-Gurus ausbilden lassen, um die Laufzeit ihrer Systeme zu verlängern, ist dieser Ansatz für Großbanken wenig praktikabel. Diese kommen also mittelfristig um den Austausch der veralteten Plattformen nicht herum.

Vor dem Einsatz von SOA Geschäftsprozesse prüfen
Doch wie im richtigen Leben ist auch bei einer SOA nicht alles Gold was glänzt. Soll eine SOA ein Unternehmen flexibler machen, muss - so sind sich die meisten Experten einig- am Anfang die Betrachtung der eigenen Geschäftsprozesse stehen. Wer dies vernachlässigt und sich nur auf die Architektur seines IT-Systems konzentriert, wird die Chancen einer serviceorientierten Architektur nicht nutzen können. Zudem ist jedem anzuraten, zunächst ausreichend SOA-Wissen im Unternehmen aufzubauen und bei einem kleineren Einstiegsprojekt erste Erfahrungen zu sammeln. Wer zunächst einige wenige geschäftskritische Legacy- Anwendungen als Diensteanbieter zur Verfügung stellt, ist auf der sicheren Seite. Zu ambitionierte SOA-Initiativen können schnell scheitern - wer zu euphorisch und schlecht vorbereitet auf den SOA-Zug aufspringt, sieht sich schnell weiteren Gefahren gegenüber. So verändert sich beispielsweise das Arbeitsfeld der Entwickler ziemlich radikal. Empfiehlt die objektorientierte Programmierung viele Aufrufe von lokalen Objekten mit wenigen Daten, so bevorzugt man an Service-Schnittstellen einer SOA wenige, grob granulare Aufrufe mit vielen Daten. Des Weiteren setzen die unter den Diensten liegenden Technologien stark auf die Extensi-ble Markup Language (XML) zum Austausch von Daten, zur Beschreibung von Dienstschnittstellen und zur Beschreibung, wo ein Dienst überhaupt zu finden ist. Experten stellen jedoch in Frage, ob es wirklich sinnvoll ist, eine Schnittstellendefinition eines Dienstes in XML zu formulieren und zu veröffentlichen, die dem Entwickler jedoch verborgen bleibt. Jeder Entwickler, der sich dem Thema SOA nähert, wird damit zwangsweise zu einem Experten für XML werden müssen. Zudem kann der massive Einsatz von XML auch Auswirkungen auf die Infrastruktur haben. "Da bei SOA viel XML in der Kommunikation zwischen den Diensten und Anwendungen eingesetzt wird, wird die Menge der zu übermittelnden und zu verarbeitenden Daten massiv ansteigen", erklärt Jürgen Kirschbaum, Produktarchitekt beim IZB Informatik-Zentrum in München. "So liegt zum Beispiel bei einem SOAP-Request das Verhältnis von Nutzdaten zu Beschreibungsdaten bei rund 1:25, bei der Antwort ist es noch viel schlechter - je nach Daten kann es auch einmal mehr als 1:500 sein." Durch die gestiegenen Anforderungen an Systeme und Netze werde es zunehmend schwerer, kurze Antwortverhalten zu garantieren. Zusätzlich stellen Diensteanbieter und -verbraucher neue Anforderungen an die Zuverlässigkeit der Netzwerke, die die Dienste verbinden. Sollen nicht nur interne Anwendungen oder Verbraucher auf die eigenen Dienste zugreifen, sondern diese sich auch externen Unternehmen öffnen, gewinnt das Thema Sicherheit an zentraler Bedeutung. Hier kommt die Spezifikation der Web Service-Security ins Spiel, die die Integrität und Vertraulichkeit von Nachrichten sicherstellt und die Identität der beteiligten Parteien prüft. Ergänzungen wie WS-Trust, WS-Secure Conversation oder WS-Security Policy sind in der Praxis jedoch noch wenig genutzt. Damit fehlen in diesem Bereich praktische Erfahrungswerte. Auch gilt es zu klären was passiert, wenn ein Service oder das Transportnetz zwischen Anbieter und Nachfrager temporär nicht zur Verfügung steht. Ist dies ein zentraler Dienst, der von vielen geschäftskritischen Anwendungen genutzt wird, stehen diese dann auch still. Hier könnte die Stunde von Dienstleistern und Infrastrukturanbietern schlagen, die ihren Kunden eine sichere, skalierbare und hochverfügbare Plattform für deren SOA-Anwendungen zur Verfügung stellen. "Gerade bei SOA ist die Verfügbarkeit und Skalierbarkeit von Diensten ein extrem kritischer Punkt", bestätigt Yann Martin, Abteilungsleiter Produktmanagement beim IZB Informatik-Zentrum.

Banken arbeiten meist mit überalterten Großrechnern
Trotz ihrer geschäftskritischen Rolle sind zahlreiche Kernbanksysteme in die Jahre gekommen. Fast alle Großbanken verfügen laut einer von SAP und Accenture im Juli 2005 durchgeführten Studie über mehr als 25 Jahre alte Kernbanksysteme. Diese zeichnen sich einerseits durch Stabilität und Skalierbarkeit aus, andererseits fehlt es ihnen an Flexibilität. Auch sind die Pflege und Wartung der proprietären Großrechnersysteme europäischer Banken so teuer, dass sie zwischen 60 und 80 Prozent des gesamten IT-Budgets verschlingen. So sind sich europäische IT- und Unternehmensmanager einig: Die Kernbanksysteme müssen verändert werden - entweder indem bestimmte Bereiche verbessert werden (70 Prozent) oder indem sie abgelöst werden (30 Prozent). Neben den hohen Kosten ist es vor allem die mangelnde Flexibilität der Systeme, die den Verantwortlichen Kopfzerbrechen bereitet.

Hohe Erwartungen an Systeme
Die Erwartungen an die Systeme der Zukunft sehen entsprechend aus: An erster Stelle steht die Reduzierung von Kosten, gefolgt von der Vereinfachung der Einführung neuer Produkte und der Vergrößerung des eigenen Marktanteils. Innerhalb der nächsten drei bis fünf Jahre möchte daher ein Drittel der IT-Manager eine serviceorientierte Architektur einführen. Neben der Befragung von weltweit 147 Bankmanagern - 75 in Europa, davon 32 Prozent aus dem IT- und 68 Prozent aus dem operativen Bereich -untersuchte das Befragungsteam von Novamétrie im Auftrag von SAP und Accenture zudem die Meinung von 500 Bankmitarbeitern in den europäischen Zweigstellen sowie weiteren 800 außerhalb Europas. Denn die Kernbanken-Thematik ist auch für die Mitarbeiter in den Filialen von großer Wichtigkeit. So verbringen in Deutschland beispielsweise die Bankangestellten vor Ort 40 Prozent der Zeit mit Backoffice-Tätigkeiten und nur 60 Prozent ihrer Zeit mit dem Kunden. Obwohl die deutschen Mitarbeiter mit den Zweigstellensystemen relativ zufrieden sind (7,3 auf einer Skala von 0 bis 10), wünschen sich 38 Prozent eine Verbesserung der Antwortzeiten und 30 Prozent eine Verbesserung der Anwendungsintegration. Inkonsistente Daten sind immerhin für knapp ein Fünftel der deutschen Mitarbeiter ein Problem. Circa 30 Prozent haben in der Filiale vor Ort nur teilweisen oder gar keinen Einblick in die Kundendaten (siehe Grafik Seite 20). Eine Flexibilisierung ermöglicht also nicht nur schneller neue Produkte, sondern kann auch die Effizienz der Mitarbeiter vor Ort steigern, die dem Kunden bestehende Produkte besser verkaufen können.

Kernbanksysteme in naher Zukunft erneuern
Den meisten Bankern ist klar, dass die Komplexität ihrer Kernbanksysteme ihr Haus dem Risiko aussetzt, in Zukunft nicht mehr rasch genug auf sich schnell verändernde Situationen reagieren zu können. Daher haben bereits viele Finanzinstitute damit begonnen, ihre Kernbanksysteme zu erneuern. Dies reicht von Verbesserungen an der Architektur über die Neuentwicklung und dem Ersatz von bestehenden Anwendungen bis hin zum kompletten Austausch des Kernbankensystems in einigen Fällen. Alle diese Aktivitäten bewegen sich laut Accenture zunehmend in Richtung einer serviceorientierten Architektur. SOA wird kommen - da sind sich die Experten einig. Doch bis die eigene Geschäftslogik als Webservice veröffentlicht und nicht nur als interner Dienst verwendet wird, bedarf es noch einiger Standardisierungen und vor allem Erfahrungen.

it-outsourcing, archivierung, k-fall sicherheit