Mit Service-Oriented Architecture (SOA) kursiert ein neuer Modebegriff in der IT. Die mit dem Kürzel geweckten Erwartungen sind hoch: So soll SOA endlich die alte Idee verwirklichen, Anwendungen plattformunabhängig als Service über das Netz anzubieten. Anstelle großer, teurer, monolithischer Software können sich Unternehmen dann exakt jene Funktionen zusammenstellen, die sie für ihre Prozesse benötigen. Die Abhängigkeiten von Herstellern und Technologien sollen damit der Vergangenheit angehören. Doch die Realität sieht ein wenig anders aus. Bislang scheitert schon die einheitliche Definition von SOA. Den Begriff gibt es schon recht lange. Gartner reklamiert für sich, bereits 1996 das Konzept von Service-orientierten Architekturen beschrieben zu haben. Damit ist zumindest belegt, dass SOA nicht, wie zuweilen kolportiert wird, aus der Web-Service-Technologie hervorgegangen ist.
Der Gedanke von Services geht aber noch weiter zurück: Er lag bereits der objektorientierten Programmierung und den Komponententechnologien zugrunde. Bekannte Beispiele dafür sind Microsofts DCOM (Distributed Component Object Model) oder der Kommunikationsstandard CORBA (Common Object Request Broker Architecture). Damit war es bereits in den neunziger Jahren möglich, verteilte Anwendungen zu entwickeln. Die Anwender erhofften sich, Funktionen in kleinen Softwarekomponenten zu kapseln und diese mittels einfacher Schnittstellen über das Netz zur Verfügung stellen zu können. Wenn also neue Prozesse eingeführt werden sollten, wäre kein komplettes Redesign notwendig. Dann könnte man sich auf Modifikationen an bestehenden Komponenten beschränken oder neue hinzufügen. Diese Konzepte setzten sich allerdings nie auf breiter Basis durch. DCOM-Komponenten blieben stets auf die Microsoft-Plattform beschränkt, die Multiplattform-Technik CORBA verbreitete sich unter anderem wegen ihrer Komplexität nicht, wie ursprünglich erwartet.
Bei der Entwicklung der Web-Services-Standards griff man einerseits diese alten Ideen auf, andererseits sollten die Fehler der Vorgängerkonzepte vermieden werden. Auf der Basis plattformunabhängiger XML-Standards und den daraus abgeleiteten Protokollen SOAP (Simple Object Access Protocol), WSDL (Web Services Definition Language) und UDDI (Universal Description, Discovery and Integration) fanden Web-Services schnell breite Akzeptanz in der Industrie. Als Technik, mit der sich die bisher fremden Systemwelten koppeln lassen, haben sich Web-Services auf breiter Front etabliert. Was aber bisher fehlte, war der architektonische Überbau. Genau hier kommt SOA ins Spiel. Meta-Group-Analyst Christophe Toulemonde charakterisiert SOA anhand folgender Punkte:
Es handelt sich um eine allgemeine Architektur, die
- auf dem Internet und dem Web basiert
- eine erweiterbare, föderierbare Interoperabilität ermöglicht
- auf Netzwerkkonzepte wie Protokolle und Vermittler (Intermediaries) basiert.
Interoperabilität bedeutet hierbei die Zusammenarbeit mit bestehenden Systemen, Erweiterbarkeit bezieht sich auf Kompatibilität mit künftigen Neuerungen. Föderation letztendlich meint, dass ein System über Schranken hinweg funktioniert - technologisch, auf der Management-, Sicherheits- sowie Business-Ebene. Einerseits folgert Toulemonde daraus, dass die Web-Services Architektur die Umsetzung von SOA-Prinzipien bedeutet. Andererseits betont er: "SOA muss nicht zwingend mithilfe von Web-Services-Technologie implementiert werden".
Ein gutes Beispiel dafür, dass SOA nichts mit Web-Services zu tun haben muss, liefert die Stuttgarter Daimler-Chrysler-Bank mit ihrer neuen EAI-Infrastruktur, die mit dem EAI-Award 2004 ausgezeichnet wurde. CIO Dirk Pietrzyk erläutert die Vorteile der Middleware: "Unser Hauptziel war es, bestimmte Funktionen auf alten wie neuen Bestandssystemen wiederverwendbar zu gestalten, um sie als Service aus verschiedenen Anwendungen heraus nutzen zu können." Als Beispiel nennt Pietrzyk die Bonitätsprüfung für Bankkunden, die mit Hilfe der Vitria-Middleware bereitgestellt wird. Mitarbeiter aus verschiedenen Geschäftsbereichen greifen so beispielsweise beim Bearbeiten von Leasingverträgen, der Kreditkartenvergabe oder einer Kfz-Finanzierung auf ein und dieselbe Funktion zu.
Volle Kontrolle über Schnittstellen
Das spart zum einen Entwicklungs- und Implementierungsaufwand und bringt zum anderen laut Pietrzyk noch andere Vorteile: "Dank des in unserer Architektur verwendeten Service-Bus-Systems haben wir nun die volle Kontrolle über unsere Schnittstellen." Im alten Modell bestanden kaum Möglichkeiten, die vielfältigen Daten- und Funktionsverknüpfungen zwischen den einzelnen Systemen zu überwachen, so Pietrzyk. "Nun sind wir beispielsweise in der Lage, die Dauer von Arbeitsschritten in der Leasingkalkulation zu ermitteln oder tägliche Reports zur regionalen Verteilung der Vertriebsaktivitäten zu erstellen."
Die Autobank profitiert von der Kapselung bisher proprietärer Schnittstellen. Laut Pietrzyk könne man auf diesem Weg die Verantwortlichkeit für Schnittstellen klarer regeln, interne Landschaften neu ordnen sowie beliebige Systeme von A nach B verfügbar machen. Darüber hinaus bietet dieses Modell bei der Anbindung von Outsourcing-Anwendungen Vorteile. In einer weiteren Ausbaustufe werden auch Web-Services zum Zuge kommen. In dem Pilotprojekt für das Fuhrparkmanagement bieten sich Web-Service-Schnittstellen als ideale Lösung an, weil diese Funktionen auch extern über das Internet angeboten werden. Trotz der Vorteile versteht Pietrzyk SOAs nicht als Allheilmittel in der IT. So ergebe es keinen Sinn, alle 80 Systeme des Finanzunternehmens auf der Schnittstellenebene zu kapseln, da ein solches Beziehungsgeflecht erfahrungsgemäß nicht zu managen sei.
Dass sich eine Service-Architektur nicht als Bauplan für alle IT-Bereiche eignet, darauf weist auch Lars Erdmann, Mitglied der Geschäftsführung bei der Esprit Consulting AG in München, hin: "SOA gewinnt zwar in den nächsten Jahren an Bedeutung, aber das heißt nicht, dass Firmen nun um jeden Preis auf eine solche Architektur setzen sollten." Erdmann sieht Vorteile vor allem in Bereichen wie der Prozessoptimierung. Während bisher bei der Einführung neuer Prozesse auch neue Anwendungen notwendig waren, ermöglicht es SOA, Prozessschritte zu kapseln und so Anpassungen in granularer Form vorzunehmen.
IT und Business kommen zusammen
Ein weiterer bedeutender Aspekt sei auch, dass sich Services nun auf einer höheren Abstraktionsebene definieren lassen. "Services beschränken sich nun nicht mehr auf die Technik, sondern verlagern sich in Richtung Geschäftsfunktionen", so Erdmann. Bisher gab es einen Bruch zwischen beiden Ebenen, denn die technische Definition eines Services korrespondierte nur selten mit Prozessdefinition und -gestaltung des Managements. "SOA erlaubt eine bessere Kommunikation zwischen IT-Verantwortlichen und den Business Lines, da man nun vom Gleichen redet.
Einig sind sich die Branchenexperten darüber, dass mit SOA eine neue Epoche in der IT beginnt. Lediglich mit der Umsetzung auf breiter Basis dürfte es noch einige Zeit dauern. Zum einen hängt das laut Erdmann mit der nach wie vor starken Investitionszurückhaltung zusammen: "Solange IT als Kostenfaktor betrachtet wird, sind nur Bastellösungen zu erwarten. SOA-Projekte erfordern aber eine langfristige, strategische Perspektive und somit die Bereitschaft für eine Vorfinanzierung."
Als ideale Vorgehensweise empfiehlt Chefberater Reiner Schlosser beim Dienstleister Freudenberg IT, ein langfristiges Ziel ins Auge zu fassen und mit kleinen Projekten rechtzeitig zu starten - nach dem Motto "Think big, start small". Beginnen könne man beispielsweise mit einer Integrationsplattform oder einem Portal. Auch Meta-Analyst Toulemonde plädiert für eine derartige Vorgehensweise, indem er Anwendern nahe legt: "Fangen Sie klein an und gehen Sie von einer langen Lernphase aus." Firmen sollten sich taktisch verhalten und sich derzeit noch nicht auf eine umfassende Strategie einlassen, die auf einen Umbau der gesamten Organisation hinausläuft. "In der jetzigen Phase muss es vor allem erst einmal darum gehen, der Wert einer SOA für das Unternehmen zu ermitteln."
Die IT-Hersteller sehen das bisweilen anders - viele versuchen, Druck zu machen, und empfehlen einen schnellen Umstieg auf SOA. Reiner Schlosser sieht darin Anzeichen für einen anstehenden Verteilungskampf - nach dem Motto: "Die Schlacht um die Integrationsplattform von heute entscheidet darüber, wer morgen bei SOA das Rennen macht".