Neben Cloud Computing und Green IT zählen Service-orientierte Architekturen zu den beliebtesten Buzz-Wörtern der vergangenen zwei Jahre. Dabei weiß kaum ein Verantwortlicher, was sich hinter der Idee eigentlich verbirgt. Selbst auf den großen IT-Fachkonferenzen wird zwar über so genannte Vor- und Nachteile einer SOA diskutiert, mit erfolgreichen Szenarien kann jedoch kaum ein CIO aufwarten. Immer noch beherrschen zentrale ERP-Systeme die IT-Landschaft in den Unternehmen.

IT-Infrastruktur mit ERP bewältigen

Dies gilt insbesondere für mittelständische und große Unternehmen, deren ERP-Backend das Rückgrat der IT-Infrastruktur bildet: Die zentrale Buchhaltung wird damit erledigt, ebenso das Management von Lieferketten, die Bestellungen von Kunden oder die Mitarbeiterverwaltung im eigenen Haus. Ziel der Systeme ist es, die einzelnen betrieblichen Ressourcen entsprechend ihren jeweils funktionalen Bestimmungen möglichst optimal einzusetzen. So sagt es jedenfalls die Theorie.

In der Praxis bedeutet das, dass die Anbieter dem Kunden nach wie vor ein weitgehend monolithisches ERP-System präsentieren, auf dessen Basis er alle Geschäftsprozesse abwickeln kann. Branchengrößen wie SAP oder Oracle haben sich hier spezialisiert. Das funktioniert jedoch nur bedingt: Wer eine bestimmte Funktion nicht in der eigenen ERP-Suite findet, prüft eventuell den Einsatz einer zusätzlichen Applikation. So entstehen über IT-Generationen hinweg auf Basis eines zentralen ERP-Systems unübersichtliche IT-Landschaften - es blüht ein Wildwuchs von Software, die sich wie eine Korona um das Kernsystem spannt. Spätestens dann ist es kaum noch möglich, die ERP-Suite oder andere Komponenten auszutauschen. Damit scheint der Anspruch moderner IT-Landschaften, verschiedene Dienste unter einer einheitlichen Struktur zu integrieren, verbaut zu sein.

SOA für die Integration von Diensten

Doch genau dies ist die Forderung von SOA. Theoretisch beschreiben Service-orientierte Architekturen ein Konzept für den Aufbau von IT-Infrastrukturen, die sich konsequent an den Prozessen im Unternehmen ausrichten. Diese sind nicht nur von der eingesetzten Software abhängig, sondern richten sich unter anderem nach dem realen Geschäftsmodell. SOA ist damit zunächst nicht mehr als ein reines Paradigma:

Die wichtigste Eigenschaft Service-orientierter Systeme ist es, dass Funktionen in eigenständige Module gekapselt werden. Ähnlich wie bei der Objektorientierung hat sich hier die Denkweise etabliert, dass nur über eine einheitliche und zentrale Schnittstelle SOA-Features angesprochen werden sollen, um eine einfache Wiederverwendung zu erlauben. Ein Zugriff auf die definierten Funktionen muss möglich sein, sofern man nur die Schnittstelle kennt - das Wissen über deren Implementierung hingegen ist nicht nötig.

Damit lassen sich die gekapselten Module auch über das Netz bereitstellen. SOA bedeutet nach idealtypischer Definition, dass alle Dienste möglichst verteilt zur Verfügung stehen sollten - im Gegensatz zum zentralen ERP-Ansatz, der häufig mit zentralen Server-Instanzen arbeitet. Die SOA-Module spannen also ein Netz, über das die eigenen IT-Prozesse bedarfsgerecht gelegt werden können. Dabei hilft auch die Unabhängigkeit von spezifischen Plattformen: Jedes SOA-Modul kann, so die Idee, in einer beliebigen Programmiersprache umgesetzt werden und auf beliebigen Systemen laufen. Die Kapselung und Bereitstellung über standardisierte Netze ermöglicht den problemlosen Zugriff auf die Funktionen.

Die wichtigste Eigenschaft von SOA ist, dass sich Dienste dynamisch binden lassen. In zentralen ERP-Systemen ist jedes Modul, das eine bestimmte Funktion bereitstellt, bereits ab dem Start des Programms verfügbar. In Software, die nach dem SOA-Paradigma gebaut ist, wird ein bestimmtes Modul immer nur dann geladen, wenn auf das Feature zugegriffen wird.

Was bietet SOA gegen ERP?

Das vorrangige Ziel einer SOA ist, sich von einem zentralen System als Basis der IT-Struktur zu lösen: Alle Prozesse sollen mit beliebiger Software auf beliebigen Plattformen laufen und dabei weitgehend unabhängig voneinander sein. So lassen sich Updates einzelner Module effizient bewerkstelligen: Wer zum Beispiel das SOA-Modul für den Postversand wechselt, braucht die Schnittstelle nicht anzutasten. Auf diesem Weg kann etwa ein Versandhandel seinen Postdienstleister schneller austauschen.

Geht es darum, neue Unternehmensherausforderungen zu unterstützen, wie etwa die zügige Prozessänderung in Zeiten der Krise, die Integration von übernommenen Firmen oder die Einführung innovativer Kommunikationsstrukturen, scheint ein monolithisches, zentrales ERP-System gegenüber einer SOA-Plattform zunächst deutlich im Nachteil zu sein. In kleinen Betrieben ist es allerdings unbestritten, dass ein zentrales ERP die Prozesse vereinfacht. In großen Unternehmen dagegen kann eine SOA dabei helfen, auf konzeptioneller Basis ERP-Funktionen auf Serviceniveau umzustellen.

Der Kern von SOA: Web-Services

Für die reale IT-Welt bedeutet dies, dass eine Software die eigenen Funktionen nicht mehr über proprietäre Protokolle anbietet, sondern direkt als Web-Services bereitstellt. Damit halten seit langem bekannte Techniken wie UDDI, WSDL und Soap endlich Einzug in konkrete Lösungen. Die Kapselung von SOA-Modulen ist über Soap vergleichsweise einfach und konform zum SOA-Standard der Oasis. Auf Basis von TCP/IP tauscht man über eine XML-Protokollschicht auf Soap die relevanten Daten aus. Das Ganze ist eigentlich "nur" eine moderne Form der Remote Procedure Calls, die es in der IT seit Jahren gibt. Fast jede moderne Programmiersprache bietet im Rahmen einer Standardbibliothek Tools für den Umgang mit Soap an. Wer an dem relativ komplexen Soap keine Freude findet, kann auch auf das ältere XML-RPC setzen.

Eine zentrale Forderung des SOA-Konzepts ist, dass die Schnittstelle zu einer Funktion über alle Plattformen einheitlich verfügbar sein muss. Dafür sorgt WSDL, die Web Services Description Language. Mit dieser Sprache definiert man die über das Netz angebotene Funktion, deren Argumente sowie Datentypen, Rückgabewerte und Protokolle. Nicht enthalten ist in WSDL leider die Information, ob ein Dienst zum Beispiel nur zeitlich beschränkt verfügbar ist - das muss man über einen einfachen Testzugriff herausfinden. Die Unterstützung von WSDL ist in Java und PHP sowie Ruby sehr gut, andere Sprachen sind diesbezüglich eher eingeschränkt.

In der SOA-Welt ist UDDI als dritte technische Säule am stärksten verbreitet. Der Dienst hat sich als universelles Verzeichnis etabliert, in dem Anwendungen und deren Module nach Features suchen können beziehungsweise die Adresse einer bestimmten Funktion herausfinden.

Schwächen bei der Umsetzung

SOA erscheint vielen IT-Verantwortlichen als eierlegende Wollmilchsau, die Nachfrage nach SOA-Ready-Software ist deshalb sehr groß. Doch selbst auf der CeBIT zeigte sich in diesem Jahr, dass das Angebot in dieser Richtung noch eher schwach ausgeprägt ist. Es gibt kaum Software, die sich konsequent an die SOA-Standards hält. Zwar strahlt inzwischen auf fast jeder Software das SOA-Logo, mehr als ein paar einfache Web-Services sind darin aber meist nicht enthalten. Zu wenige Features folgen dem SOA-Konzept, weil die Anwendung der Web-Services-Techniken in der Praxis recht aufwändig ist. Dennoch arbeiten die Anbieter zentraler ERP-Systeme derzeit mit Hochdruck daran, Funktionen mit SOA-Schnittstellen auszustatten - aber alleine SAP benötigt hier mehr als 30.000 Web-Services, um die komplette Funktionalität der ERP-Suite nachzubilden.

Das zweite, noch größere Problem, ist die strukturelle Komplexität von SOA: Zwar möchte man mit diesem neuen Paradigma die Komplexität radikal reduzieren. Die Umstellung komplexer IT-Infrastrukturen für Unternehmen mit mehreren tausend Mitarbeitern ist aber ähnlich aufwändig wie die Einführung eines komplett neuen zentralen ERP-Systems. Es gibt nur wenige erfolgreiche Beispiele für SOA-Systeme in Großkonzernen, unter anderem gehört die Deutsche Post dazu.

Reale Lösungen für die IT

Der Markt für SOA-Tools, mit denen sich diese Probleme bewältigen lassen, ist derzeit sehr schwierig. Zum einen etablieren sich Anbieter, die Softwarehäuser bei der Umsetzung von SOA unterstützen. So implementiert das Equinox-Framework der Eclipse Foundation den OSGi-Standard, der ein hardwareunabhängiges Komponentenmodell spezifiziert, auf dessen Basis sich SOA-Systeme modellieren lassen. Zum anderen gibt es einige kleine Anbieter, die ERP-Systeme mit SOA-Features neu entwickeln. Dazu gehört unter anderem die Alea GmbH, die mit der "Alea Commerce Suite" ein SOA-fähiges ERP-System für den Versandhandel anbietet. Die Anbindung einzelner Module über standardisierte Schnittstellen an externe Tools ist damit problemlos möglich. Auch die Produkte von Crossgate sind durchweg SOA-ready.

Damit steht SOA nicht mehr als Widerspruch zu zentralen ERP-Systemen im Raum: Sie wird es weiterhin geben, schon allein aus dem Grund, dass viele Betriebe alle Vorgänge in einer zentralen Datenbank speichern müssen. In den nächsten Jahren werden diese zentralen Systeme jedoch immer mehr Funktionen über Web-Services bereitstellen, so dass sich ein Netz von Tools und Drittlösungen bildet, die nahtlos an das Mutterschiff andocken können. (ue)