Serviceorientierte Architektur

1. Begriff: Eine serviceorientierte Architektur (SOA) bezeichnet ein modulares Architekturkonzept, wonach betriebswirtschaftliche Anwendungssysteme (z.B. Kernbankensysteme) aus eigenständig nutzbaren und kombinierbaren funktionalen Bausteinen bestehen. Diese Services kapseln gleichartige Geschäftsfunktionalitäten und stellen diese über eine informationstechnologische Infrastruktur unternehmensintern oder auch -extern zur Verfügung. Abhängig von der Granularität der Servicedefinitionen besitzen komplexe Servicebündel einen Bezug zu (bank)fachlichen Prozessen, wie etwa der Zahlungsverkehrsabwicklung. Sie bestehen aus feingranularen Services (z.B. „Get Order Quote“), die in Verbindung mit einer übergreifend eingesetzten Technologieplattform in mehreren Anwendungssystemen wiederverwendbar und interoperabel sind. Eine technische Implementierungsform sind die sog. Webservices mit Standards (wie SOAP, WSDL und UDDI). Obgleich dies einen erheblichen Standardisierungsaufwand bedeutet, ergeben sich mit einer SOA wichtige geschäftliche Potenziale. Dazu zählen eine höhere Flexibilität bei Anpassungen von Anwendungssystemen infolge veränderter Geschäftsprozesse oder ein verbesserter Abgleich von fachlicher und (informations)technischer Servicegestaltung (sog. „IT-Business Alignment“). Allerdings ist die Refinanzierung einer SOA bei einem technisch geprägten Verständnis allenfalls langfristig zu erwarten.

2. Bestandteile: Die Funktionsweise einer SOA besteht aus dem Zusammenwirken der drei Elemente „Service“, „Serviceverzeichnis“ sowie „Service-Bus“. Serviceerbringer registrieren ihren Service im Serviceverzeichnis mit Angaben zu Schnittstelle, Ergebnis, Qualität und Preis. Servicenutzer beziehen diese Informationen ebenfalls über das Serviceverzeichnis, sodass die Leistungserbringung selbst dann direkt zwischen Serviceerbringer und -nutzer stattfinden kann. Die Realisierung der Interoperabilität der einzelnen Services erfordert dabei eine hohe Standardisierung von Funktionen, Daten und Schnittstellen. Zur Beherrschung dieser Komplexität haben sich Visualisierungs- und Dokumentationsformen etabliert. Beispielsweise strukturieren Servicelandkarten die vorhandenen Services in einem fachlichen Zusammenhang, während Serviceverzeichnisse eine Klassifikationsaufgabe übernehmen. Durch unterschiedliche Anwendungsgebiete und Informationsinhalte von Servicelandkarten und -verzeichnissen sollten deren Aufbau und Struktur einem möglichst unternehmensübergreifenden Ordnungsrahmen folgen. Damit lassen sich Einflussfaktoren, wie Größe und Ausrichtung der Bank oder Zweck und Reifegrad der SOA systematisch berücksichtigen. Letztlich gilt für die Umsetzung einer SOA im Unternehmen oder mit Partnern eines Finanznetzwerks die Einrichtung einer unterstützenden Aufbauorganisation mit Verantwortlichkeiten als wichtige Voraussetzung (sog. „SOA-Governance“).

3. Beispiel: Insbesondere größere Finanzdienstleister, wie etwa Credit Suisse oder die Deutsche Bank, haben sich in den vergangenen Jahren mit der serviceorientierten Gestaltung ihrer Anwendungssysteme befasst. Neben diesen bankspezifischen Ansätzen sind Hersteller von Standardsoftware (Kernbankensysteme), wie etwa SAP oder Kordoba in Deutschland oder Avaloq und Finnova in der Schweiz, mittlerweile mit serviceorientierten Lösungen auf dem Markt. Zur Unterstützung eines unternehmensübergreifenden Sourcing sind Servicearchitekturen notwendig, die eine Interoperabilität zwischen verschiedenen Instituten und technischen Plattformen unterstützen. Ein überbetrieblicher Ansatz in diese Richtung ist etwa Banking Industry Architecture Network (BIAN).