Service-orientierte Architekturen

Kein schnelles Glück

05.10.2005
Lohnende Business-Cases fehlen, die Komplexität steigt, und billiger wird es auch nicht. Doch IT-Manager erhoffen sich eine deutlich höhere Flexibiliät durch SOA. Die Erfahrungen bei der Deutschen Post Brief, bei Vodafone und Degussa.

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."

Zur Startseite