Johannes Helbig, CIO und Bereichsvorstand bei der Post Brief, sah sich Ende 90er-Jahre durch die europäischen Regulierungsbehörden gezwungen, im Auftrag des Business einen IT-Strategiewechsel einzuleiten. Das Briefmonopol der Post sollte im Jahr 2003 auslaufen. Zwar hat der Gesetzgeber das Monopol-Ende inzwischen auf 2007 verschoben, doch 1999 begann die Post-IT mit der Neuausrichtung: Die IT sollte rasche strategische Reaktionen des Geschäfts im künftig härter werdenden Wettbewerb besser unterstützen. "Anwendungslandschaften müssen sich deshalb schnell flexibel ändern können. Dafür brauchten wir eine Service-orientierte Architektur", erklärt Helbig. Das Kürzel SOA gab es damals allerdings noch gar nicht.
Der vor gut zwei Jahren aufgetauchte Begriff sorgt in Deutschland für großen Rummel. "Anbieter verwenden ihn, seitdem sie mit Web Services versuchen, technologiegetrieben EAI zu vertreiben", sagt Wolfgang Beinhauer, Leiter Web Application Engineering beim Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO). SOA steht weniger für eine technische Architektur, sondern vielmehr für die Prozessorientierung der IT und ein neues - oder zumindest verändertes - Architekturparadigma. SOA soll es ermöglichen, sich einzelne Funktionen aus verschiedenen Anwendungen zu nehmen und sie zu einem neuen Service zusammenfügen. Sie ermöglicht es also, Softwarekomponenten mehrfach zu verwenden.
Georg Margraff, Head of Strategy and Architecture Coordination beim Düsseldorfer Mobilfunkanbieter Vodafone, erinnert dieses Konzept stark an die Objekt-orientierte Programmierung. Auch damals lautete das Versprechen, dass man eine Funktionalität einmal erstellt und sie dann als Klasse anderen zur Verfügung stellt. In der Praxis habe es dann aber so viele Klassen gegeben, dass es effizienter war, eine Funktion neu zu erstellen, als eine bestehende Funktion zu suchen, zu verstehen und zu nutzen, meint Margraff: "Wer stellt sicher, dass uns Gleiches nicht auch beim SOA-Ansatz widerfährt?"
Monolithen in Bausteine zerschlagen
So erdet Beinhauer von Fraunhofer das Kürzel auch wieder. Diese Architektur unterscheide sich nicht von einer herkömmlichen Integration. Wie bei einem EAI-Projekt (Enterprise Application Integration) müssen IT-Abteilungen ihre Software-Monolithen in Funktionsbausteine zerlegen, diese zu Services in jeweils passender Granularität herunterbrechen und kapseln. Der teure Programmieraufwand bringe Unternehmen erst einmal keinen Vorteil, räumt er ein. "Erst wenn eine IT-Landschaft komplett auf Web Services läuft, entfaltet eine SOA ihre Vorteile voll."
Nur besitzt kein Unternehmen eine durchgängig Web-Services-basierte Architektur. Daran führt aber für viele Unternehmen kein Weg vorbei, wie Forrester-Analyst Jost Hoppermann zu bedenken gibt: "Wenn CIOs immer stärker auf Software von der Stange setzen und Unternehmensgrenzen überschreiten, müssen diese Anwendungen zumindest Web Services konsumieren können."
Allerdings fehlen bei Web-Services noch weitgehend Standards. Nur der Protokollstandard SOAP (Simple Object Access Protocol), der Verzeichnisdienst UDDI (Universal Description, Discovery and Integration) und die Schnittstellenbeschreibungssprache WSDL (Web Service Definition Language) stehen unverrückbar fest. Aber schon bei der Prozessbeschreibungssprache BPEL (Business Process Execution Language) liegt der Reifegrad noch nicht bei 100 Prozent.
Für Margraff mangelt es noch an mehr. "Es fehlt vor allem ein Standard für die Orchestrierung der Services." Dabei unterscheidet er zwei Formen: die Verknüpfung einfacher, modularer Services zu komplexen Services sowie die Verknüpfung der Services zu einem Geschäftsprozess. Erst wenn diese Voraussetzungen geschaffen seien, ließe sich eine SOA in breitem Maßstab aufbauen. Aber nicht nur fehlende Standards schrecken IT-Manager wie Margraff noch von der neuen Architektur ab. Als wesentliche Hindernisse kristallisieren sich vier Punkte heraus:
- fehlende Business Cases
- fehlende Preismodelle
- steigende Komplexität
- überforderte Organisation
So sich keine eindeutigen Lösungen für diese Unklarheiten abzeichnen, richten nur wenige Unternehmen ihre Architektur Service-orientiert aus.
Business Cases fehlen
Der Düsseldorfer Chemiekonzern Degussa hat als eines der wenigen Unternehmen kleine Pilotprojekte gestartet, um erste Erfahrungen zu sammeln. "Die lohnenswerten Business Cases sind uns allerdings noch nicht klar", bilanziert Werner Kroer, Regional CIO Americas und Leiter des Advanced Solutions Competence Center Degussa. Zusammen mit SAP hatte er versucht, geeignete Prozesse für eine SOA zu finden. Die Ergebnisse waren ernüchternd. "Abgesehen von ein paar wenigen Beispielen in anderen Branchen weiß SAP selbst noch nicht genau, wo die guten Anwendungsfälle liegen", sagt Kroer. "Referenzarchitekturen fehlen bei SAP, die müssen Anwender noch stark selbst entwickeln. Wir sind alle noch Sucher."
Ob Unternehmen mit einer SOA Geld sparen, ist deswegen für Margraff von Vodafone noch mehr als fraglich. Er betrachtet potenzielle Kostenersparnisse skeptisch. "Das Versprechen, Geld zu sparen, haben schon viele Architekturansätze gegeben: Objekt-Orientierung, Corba, EAI, COTS (Connection Oriented Transport Layer Service). Viele haben diese Versprechen letztlich nicht eingelöst."
Beispiele von Unternehmen, die diese Skepsis entkräften, sind in der Tat rar. Die britische Versicherung Standard Life baut seit mehr als zehn Jahren eine SOA. Im vergangenen Jahr hat die Versicherung etwa 30 ihrer rund 250 Services untersucht. Das Ergebnis: Diese 30 Services brachten allein durch ihre Wiederverwendung eine Ersparnis von einer halben Million Euro innerhalb des vergangenen Jahres, wie Forrester-Analyst Hoppermann berichtet. Dabei hatte Standard Life schon heraus gerechnet, was sie zusätzlich aufwenden mussten, um diese Services in verschiedenen Versionen für die verschiedenen Anwendungen lauffähig zu halten.
Fehlende Preismodelle
Neue Lizenz- und Preismodelle der Anbieter könnten die Kosten treiben. Obwohl noch kein einziges vorliegt, befürchten einzelne Anwender bereits, dass die Softwarelieferanten SOA dazu missbrauchen könnten, ihre Lizenzeinnahmen aufzupäppeln. Dem SOA-Ansatz getreu wollen CIOs jedoch nur noch für diejenigen Funktionen zahlen, die sie aus den Monolithen für ihre Services brauchen.
Dazu müssten Anbieter noch Mechanismen schaffen, mit denen sie beispielsweise zehn Services für ein Jahr frei schalten oder nach Verbrauch abrechnen. Über derartige Modelle hat allerdings noch nicht einmal SAP abschließend nachgedacht. In Walldorf hält man neue Preismodelle frühestens Ende 2006 für wahrscheinlich.
Christian Glas, Berater beim Beratungsunternehmen Pierre Audoin Consultants (PAC), versucht bereits von vornherein die Bedenken zu zerstreuen. Lizenzen spielen nach seiner Ansicht nur eine untergeordnete Rolle. Bei einem SAP-System zum Beispiel entstehen die größten Kosten durch Services wie Anfangsimplementierung und jährliche Updates.
Ungewissheit herrscht bei Managern auch darüber, wie sich eine SOA auf die Komplexität der IT-Landschaft auswirkt. So argumentiert Margraff von Vodafone, zwar werde sich die Komplexität zunächst verringern, wenn durch die gegenseitige Vernetzung der Systeme die Point-to-Point-Verbindungen zwischen den Anwendungen geringer würden. Andererseits verspreche SOA jedoch, Services flexibel zu Prozessen zusammenzufügen. Seine Schlussfolgerung: "Wird diese Flexibilität tatsächlich in Anspruch genommen, so erhöht sich die Komplexität."
Auch Analyst Hoppermann macht sich keine Illusionen, dass die Komplexität sinkt - im Gegenteil. In den vergangenen Jahren wurden immer neue Softwareschichten eingezogen, die die Gesamtkomplexität stetig erhöht hätten. CIOs sollten deshalb nicht den Fokus darauf legen, die Komplexität zu senken. Das gehe gar nicht. "Die zentrale Frage lautet, ob CIOs mit einer SOA die zunehmende Komplexität besser beherrschen und steuern können", gibt er zu bedenken.
Dem widerspricht Beinhauer von Fraunhofer. Er leitet aus seinen Projekten die Prognose ab, dass die Komplexität der Systeme abnimmt. Er räumt zwar ein, dass erst ein hoher Aufwand notwendig sei. "Monolithische Anwendungen muss man erst zerlegen und die oft schlecht definierten und dokumentierten Schnittstellen in Web Services kapseln." Auf der anderen Seite baut SOA Redundanzen ab, sodass überflüssige Funktionen und IT nicht mehr gewartet werden müssen.
Überforderte Organisation
Letztlich scheitert SOA für den Post-CIO Helbig nicht an Komplexität und Kosten, sondern an der falschen Organisation. Er rät eindringlich, dass der Anstoß für SOA aus dem Management kommen muss: "Knackpunkt für eine erfolgreiche SOA-Einführung ist die Anforderungsseite: Das Business muss das Thema verstanden haben, es wollen und treiben." Sonst scheitert SOA wie frühere Hype-Themen CRM und Data Warehousing. Er warnt: "SOA kann man sich nicht technologisch kaufen, indem man eine Integrations-Infrastruktur hinstellt. SOA ist eine Managementaufgabe".
Zentrale Managementaufgabe muss deshalb sein, Abteilungs- und Projektegoismen zu überwinden. Darin sieht Margraff von Vodafone ein sehr großes Hindernis. Die zentrale Hürde bei Einführung von SOA besteht für ihn darin, dass jemand zunächst Vorleistungen in einem Projekt erbringen muss. Wer einen Service als wiederverwendbare Komponente bereitstellt, hat selbst eher Nachteile wegen erhöhter Kosten und längerer Laufzeiten. Den Nutzen aus dieser Service-Erstellung ziehen erst nachfolgende Projekte.
SOA bringt ersehnte Flexibilität
Trotz aller Bedenken setzen IT-Manager hohe Erwartungen in die größere Flexibilität durch SOA. Zwei große Vorteile erhofft sich Kroer: "SOA steigert die Effizienz, weil wir Prozesse sehr flexibel nach unseren Anforderungen gestalten, und das mit so wenig Prozessschritten wie notwendig. Mit SOA lassen sich Prozesse unterstützen, die gängige Applikationen nicht gut abdecken."
Flexibilität braucht Degussa vor allem bei firmenübergreifenden Prozessen. Gerade bei Cross-Functions könnte für Kroer SOA eine starke Rolle spielen. So wäre es beim Kredit-Management wünschenswert, eine einheitliche Sicht auf alle Partner zu bekommen. Das Ziel: Jedem Kunden und Lieferanten ordnet Degussa ein Kreditlimit zu, wobei sich das gesamte Kreditvolumen auf alle Länder bis auf alle Gesellschaften runterbrechen ließe. Kroer: "Mit SOA könnten wir flexibel und schnell ein Netz quer über alle Gesellschaften legen und eine neue Stufe der integrierten Organisation erreichen." Bis auf weiteres erledigen zahlreiche Mitarbeiter in den Serviceeinheiten diese Aufgaben weiter manuell oder mit Excel und Acces.
Den zweiten großen Nutzen sieht er in weltweit standardisierten Benutzeroberflächen und Prozessabläufen dahinter. So macht Degussa beispielsweise zurzeit viel Neugeschäft in China. Mit einheitlichen User-Interfaces müsste er die neuen Mitarbeiter ohne Erfahrung mit Anwendungen und Prozessen nicht teuer einarbeiten und schulen. Zugleich steigt dadurch die Qualität der Arbeit, weil Daten einheitlich erfasst würden. "Wir müssen nicht immer nachschauen, wie ein Mitarbeiter Prozesse ausführt. Das ist der Vorteil der Flexibilität von SOA", resümiert Kroer. Nur kostet die Flexibilität auch: "An der Oberfläche nehme ich Komplexität raus, aber dahinter steigt sie weiter."
Aufgrund der vielen ungeklärten Fragen und Probleme halten sich CIOs bei SOA noch stark zurück. "Bis Ende 2006 werden die technischen Fragen geklärt sein und bis 2007/2008 entwickelt sich SOA zum Mainstream", prognostiziert Beinhauer. PAC-Berater Glas geht davon aus, das CIOs 2008/2009 die ersten SOA-Projekte durchführen werden. Allerdings hat er festgestellt, dass sich viele Unternehmen bislang überhaupt nicht um das Thema kümmern: "Das ist definitiv ein Fehler. CIOs dürfen nicht nur die Kosten sehen, sondern auch die Vorteile für das Unternehmen."
CIOs warten skeptisch ab
Doch zu viele ungehaltene Versprechen aus der Vergangenheit, zu viele ungeklärte Fragen und zu viel Schall und Rauch der Marketing-Abteilungen lassen Unternehmen einen vorsichtigen Weg gehen. "Wir verfolgen den SOA-Ansatz aufmerksam", sagt Margaff und spricht damit für viele Unternehmen. "Wir werden uns mit kleinen Projekten an diese Architektur herantasten. Aktuell planen wir nicht, eine SOA-Architektur im Rahmen eines Großprojektes einzuführen".
"Bei einem evolutionären Ansatz können CIOs bei SOA mit geringen Kosten und schnellem ROI einsteigen", ermutigt Post-CIO Helbig nach sechs Jahren SOA-Erfahrung seine Kollegen.