Studien bestätigen: Der SOA-Ansatz (Service-orientierte Architektur) ist weit verbreitet; laut Forrester verwenden 58 Prozent der Unternehmen einen ESB (Enterprise Service Bus). Aber nur jedes dritte Unternehmen baut auf dieser Grundlage neue Services, lediglich 14 Prozent nutzen die Vorteile der Business Process Execution Language (BPEL). Damit stellt sich bei vielen SOA-Implementierungen der ersten Stunde die Frage: Zahlt es sich überhaupt aus. diese Systeme zu migrieren oder anderweitig zu modernisieren?

Tatsächlich ist die SOA-Umsetzung in vielen Unternehmen quasi stecken geblieben. Meist kommen nur die zentralen Disziplinen des ESB zur Anwendung: Laut der erwähnten Forrester-Studie nutzen mehr als 90 Prozent der SOA-Anwender den Service-Bus für Routing und Messaging, etwa drei Viertel verwenden ihn für Datentransformationen. Ausgeblieben sind jedoch die umfassende Prozessautomatisierung und die Entwicklung von Services für neue Geschäftsmodelle. Bildlich gesprochen, haben sich viele Firmen einen hochwertigen Werkzeugkasten gekauft, der nach anfänglicher Begeisterung in der Garage verstaubt.

Lohnt es sich unter diesen Umständen eigentlich, noch viel Aufwand in die Architektur zu stecken? Sieben Fragen sollen helfen, herauszufinden, ob sich eine Modernisierung von ESB und SOA-Tools lohnt.

1. Ist die SOA kompatibel mit Geschäftsmodell und IT-Landschaft?

Zunächst wird man vorbehaltlos rekapitulieren müssen, ob die ursprüngliche Entscheidung für SOA vor dem Hintergrund der aktuellen Bedingungen eigentlich noch die richtige ist. War der Bedarf für wiederverwendbare IT-Services so groß wie erwartet? Ist die Systemlandschaft tatsächlich so heterogen, dass sie eines ESB bedarf? Von entscheidender Bedeutung ist auch, ob sich in den fachlichen Prozessen die Servicequalität verbessern lässt, wie das SOA-Konzept es verspricht.

Sollen dagegen vorrangig Daten in Echtzeit übertragen werden, so ergibt die Entkoppelung der Services über Integrationskomponenten keinen Sinn. Hier sind vielmehr direkte, hochperformante Kopplungen gefragt. Auch die "einmalige" Aktualisierung der Stammdaten - beispielsweise bei der Einführung der internationalen Bankkontonummer (IBAN) - ist eigentlich kein Kandidat für eine prozessgesteuerte Übertragung. Der Overhead ist bei SOA in diesen Fällen zu hoch.

2. Verwirklicht die SOA konsequent eine Architekturentscheidung?

Schon der Name Service-oriented Architecture zeigt an, dass es um eine IT-Architektur und eine grundsätzliche Entscheidungen in IT-Fragen geht. Nötig sind deshalb klare Vorgaben, für welche Einsatzgebiete der ESB beziehungsweise eine Orchestrierung in BPEL und BPMN (Business Process Model and Notation) zu verwenden sind.

Was bedeutet das konkret? Zum Beispiel sind Fortschritte im SOA-Ausbau zu kommunizieren, wiederverwendbare Services den Fachbereichen aktiv nahezubringen. Technische Vorgaben sollen die Homogenität der Servicelandschaft sichern. Standardisierte Nachrichten-Header mit Zusatzinformationen wie fachlichem Schlüssel oder Aufrufhierarchie sind unabdingbar. Bei der Fehlerbehandlung muss zwischen fachlichen und technischen Fehlern unterschieden werden.

Eine SOA erhöht zunächst die Komplexität, doch die Orchestrierung der Services und die Prozessautomation nach konsequent eingehaltenen Architekturrichtlinien machen die Komplexität der IT-Welt vielfach erst beherrschbar. Das bedeutet eine höhere Verantwortung bei der IT-Architektur, und es erfordert klare Regeln für IT-Entwicklungen.

3. Werden die Potenziale zur Effizienzsteigerung genutzt?

Eine IT-Architektur ist kein Selbstzweck. Die bloße Möglichkeit, flexible IT-Services aufsetzen zu können, rechtfertigt die Investitionen nicht. Nur wenn die Service-orientierte Architektur hilft, die Effizienz im Unternehmen zu steigern, zahlt sich der Aufwand aus.

Automatisierte Geschäftsprozesse können in vielfacher Weise Wert erzeugen. Die Teilautomatisierung und eine zielgerichtete Prozesssteuerung verbessern die Auslastung der Mitarbeiter. Durch Fristüberwachung und Eskalationsmechanismen wird sichergestellt, dass sich vereinbarte Qualitäts- und Durchsatzziele erreichen lassen.

4. Behindert eventuelles Silodenken den effizienten SOA-Einsatz?

Die Kopplung einzelner Systeme zu übergreifenden Prozessketten ist eher eine organisatorische Herausforderung als ein IT-Poblem. SOA-Potenziale lassen sich oft nur ausschöpfen, wenn vorher eine Silo-übergreifende Prozessoptimierung stattgefunden hat.

Der Erfolg hängt hier von einem konsequenten Projekt- und Change-Management sowie der Unterstützung des Topmanagements ab. Ohne diese Unterstützung tun sich IT-Abteilungen schwer, in SOA-Projekten die vertikalen Grenzen der Fachabteilungen zu durchbrechen und eine übergreifende Prozessautomatisierung zu erreichen.

5. Liefern die Services aussagekräftige Kennzahlen?

Bei der Orchestrierung und in den Services sind standardisierte Messpunkte zu setzen, die sich für die Auswertung durch ein Business-Activity-Monitoring eignen. Zudem liefern diese Messpunkte die Grundlagen für die KPI-Überwachung (Key Performance Indicators) sowie die kontinuierliche Prozessoptimierung.

6. Funktioniert die IT-Governance?

Als strategische Entscheidung bestimmt SOA, wie Prozesse in der IT abgebildet werden. Deshalb hängt sie eng mit der IT-Governance zusammen. Wenn es keine gibt oder die vorhandene nicht funktioniert, ist das häufig ein Grund für das Versanden von SOA-Projekten.

Zu den Aufgaben der IT-Governance bei Service-orientierten Architekturen gehören die Planung des Service-Lifecycle und der Service-Releases, die Einhaltung definierter Entwicklungsstandards sowie die Sorge um eine konsistente und homogene Servicelandschaft mit zentral registrierten und zugreifbaren Services. Konsistente Taxonomien sorgen dafür, dass geeignete Services sich auch wiederfinden und wiederverwenden lassen.

7. Welche SOA-Infrastruktur passt in das Unternehmen?

Erst nachdem die bisherigen SOA-Initiativen hinterfragt wurden, stellt sich die Frage nach einer Migration oder Modernisierung. Auch hier gilt: Die Komponenten müssen zur Strategie des Unternehmens und der dort vorherrschenden IT-Systemlandschaft passen.

Die Auswahl könnte mit einer groben Evaluierung von Softwareherstellern und Open-Source-Lösungen sowie mit Hilfe aktueller Reports bekannter Analysten wie Gartner oder Forrester beginnen. Hilfestellung können hier IT-Dienstleister geben, die Erfahrung bei der Auswahl und Bewertung verschiedener Integrationsinfrastrukturen haben.

Neben funktionalen und nicht funktionalen Anforderungen sind Systemarchitektur und Laufzeitumgebung der Lösung entscheidend. Oft vernachlässigt werden die Unterstützung des gesamten Software-Lifecycle, beispielsweise durch Entwicklungswerkzeuge mit grafischen Editoren, sowie die Testbarkeit der einzelnen Komponenten und des Gesamtsystems.

Eine Migration zu einem Open-Source-BPM- oder-ESB-System ist dort sinnvoll, wo sich die Inhouse-Entwicklermannschaft damit auskennt und bereit ist, Eigenverantwortung für die eingesetzten Softwarekomponenten zu übernehmen. In diesem Fall lässt sich von der Offenheit des Quelltexts und den Erweiterungsmöglichkeiten profitieren. Ratsam ist ein enger Schulterschluss mit den Open-Source-Communitys, um unmittelbar Einfluss auf die Roadmap nehmen zu können.

Vergibt ein Unternehmen Integrationsprojekte eher extern und ist vorwiegend Standardsoftware im Einsatz, so sind eher die SOA-Standards führender Produkthersteller zu favorisieren.

Fazit

Nur wer die oben aufgeführten Fragen beantwortet, kann den Werkzeugkasten SOA vom Staub befreien. Lässt sich vor einem anstehenden Upgrade oder einer Migrationen die strategische Entscheidung für SOA verifizieren, so lohnt es sich, Hindernisse wie Silodenken oder Defizite in der IT-Governance aus dem Weg zu räumen und die Orchestrierung neuer Services sowie die Prozessautomatisierung voranzutreiben.

Was letztlich mit diesem Werkzeugkasten erreichbar ist, wird sich aber häufig außerhalb der IT-Abteilung entscheiden. Denn die Bereitschaft zur Überarbeitung der Geschäftsprozesse über die Grenzen von Fachabteilungen hinweg ist eine Voraussetzung dafür, dass die SOA-Potenziale ausgeschöpft werden können. (qua)