Vor allem Softwareanbieter bereiten derzeit den Boden für Service-orientierte Architekturen. Anwenderunternehmen stehen SOA-Konzepten zwar aufgeschlossen gegenüber und beschäftigen sich auch schon mit der Technik. Sorgen bereiten ihnen jedoch die nötigen organisatorischen Umwälzungen.

Es verwundert daher nicht, dass Unternehmen und die IT-Industrie über SOAin unterschiedlichen Kategorien denken und reden. Während Hersteller nahezu unisono von der neuen Möglichkeit der IT-Flexibilisierung schwärmen, die ihre Produkte bieten, plagen sich Anwender mit gewachsenen IT-Landschaften herum. Immerhin herrscht über den potenziellen Nutzen von SOA Einigkeit: leichter anpassbare Geschäftsprozesse und weniger Aufwand bei der Pflege von IT-Systemen - wobei der endgültige Beweis noch aussteht. Auf einer von der computerwoche veranstalteten Konferenz ("SOA Initative") kamen die unterschiedlichen Lager zu Wort.

Fachabteilungen einbinden

Ganz neu sind die Ideen nicht, und dies gilt auch für die Zutaten einer SOA. Das Softwarekonzept, so erläutert Dieter Sinn, Managing Partner von Sinn Consulting, hat seine historischen Wurzeln in der objektorientierten Programmierung, Komponententechnik wie "Javabeans", den Geschäftsobjekten bei Standardsoftware wie SAP R/3 sowie dem Corba-Referenzmodell und vor allem der auf der Extensible Markup Language (XML) basierenden Anwendungskommunikation mittels Web-Services.

Obwohl sich zurzeit in erster Linie IT-Experten mit SOA befassen, sind es nach Überzeugung vieler Experten die Entscheidungsträger in den Fachabteilungen, die den Erfolg von SOA-Projekten sicherstellen müssen. Der Grund: SOA ist keine neue Spielart der IT, sondern greift im gesamten Unternehmen um sich. Es geht auch nicht nur darum, DV-Kosten zu senken. "Der Mehrwert einer SOA liegt nicht in der IT, sondern auf der Geschäftsseite", so Martin Raab, Vice President bei Capgemini Deutschland.

IT- und Business-Services

Schon aus diesem Grund wurde auf der Konferenz zwischen "Business Services" und "IT-Services" unterschieden. Mit Ersterem sind Unternehmensprozesse aus Geschäftssicht gemeint. Bezogen auf einen Logistikdienstleister könnten dies sowohl stabile, also wenigen Änderungen unterworfene Vorgänge wie etwa das Personalwesen als auch volatile Prozesse wie das tägliche Zusammenstellen der Langstrecken-Routen sein. "Ein Service-orientiertes Unternehmen sollte 30 bis 40 Business Services definieren", meint Raab. Die zahlenmäßig weit überlegenen IT-Services stellten die Funktionen bereit, mit denen Business-Services realisiert werden können. Die Fragen, wie viele dieser IT-Dienste erforderlich sind und vor allem, wie eine hohe Anzahl solcher Komponenten in den Griff zu bekommen ist, kann auch Raab noch nicht beantworten.

Wiederverwendbarkeit

Ebenso im Dunkeln bleibt, ob und in welchem Ausmaß es möglich ist, IT-Services in unterschiedlichen Business-Prozessen widerzuverwenden. SOA-Befürworter vergleichen IT-Services mit den Komponenten von Automobilen, die die Fahrzeugbauer in unterschiedlichen Modellen verbauen. Zweifler glauben nicht daran, dass sich diese Idee auf die Softwareindustrie übertragen lässt. Sie verweisen auf die objektorientierte Programmierung: Deren Protagonisten hatten stets die Widerverwendbarkeit von Objekten versprochen, am Ende aber nicht liefern können.

Unisono fordern alle SOA-Experten eine engere Verzahnung zwischen IT und Business. Doch genau diese Nahtstelle funktioniert bekanntlich schon heute vielerorts nicht. Ob durch das neue Architekturkonzept die Missverständnisse beigelegt werden? Neue Ideen scheiterten schon zu oft am Widerstand der jeweils anderen Fraktion.

Tobias Kohl, Business Manager IT-Architektur beim Beratungshaus Plenum AG, mahnte die Zuhörer, die Qualifikation des Personals in die Planung einzubeziehen: "Firmen sollten den organisatorischen und fachbezogenen Herausforderungen des SOA-Ansatzes mehr Bedeutung beimessen als den technischen Risiken." Ideal wäre Kohl zufolge ein neuer Typus von Mitarbeiter: Der Servicearchitekt, der in Software, Entwicklung und Qualitäts-Management bewandert ist, aber auch zwischen Geschäfts- und Anwendungsarchitektur unterscheiden kann.

Hersteller ermuntern Firmen

Geht es nach den Technikern, dann stehen die für den Bau von SOAs erforderlichen Werkzeuge längst bereit. Zwar herrscht die Meinung vor, nur Web-Services bildeten die Grundlage für eine SOA. Dem ist nach Worten von Ralf Bracht, Consulting-IT-Spezialist bei IBM, nicht so. Services könnten mit bekannten Programmiersprachen wie Java, Cobol, Abap (SAP) und anderen implementiert werden. Dem kann Wolfgang Beinhauer nur zustimmen. "Eine SOA kann, muss aber nicht mittels Web-Services realisiert werden", so der Leiter Marktstrategie beim Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) aus Stuttgart.

Enterprise Service Bus

Neue Konzepte sind hingegen erforderlich, um mit verschiedenen Diensten Geschäftsprozesse abzubilden. Hierzu werden Services über ein Koppelelement, einen Enterprise Service Bus (ESB), zusammengeschaltet. Dieser vermittelt zwischen Services, ohne dabei deren jeweilige Implementierung berücksichtigen zu müssen. Er bedient sich hier Web-Services-Verfahren zum Nachrichtenaustausch. Um aus einzelnen IT-Services Geschäftsprozesse zu gestalten und diese zu steuern, sind Methoden wie Business-Process-Management und Orchestrierung erforderlich.

Eher am Rande erwähnten die Hersteller Service-Repositories, in denen Anwender Beschreibungen von Diensten einer SOA abspeichern. Mit Ausnahme der Software AG. Für Ivo Totev, Vice President des in Darmstadt beheimateten Softwarehauses, stellt nicht der Enterprise Service Bus, sondern das Repository den Mittelpunkt einer SOA dar. Mit "Centra Site" bietet sein Unternehmen ein Metadaten-Repository für Richtlinien, Daten sowie Prozess- und Schnittstellenbeschreibungen.

Zu den SOA-Protagonisten zählen Unternehmensberater Sinn zufolge IBM, Microsoft, Oracle, Sun Microsystems, das sich unlängst durch die Übernahme von Seebeyond auch Integrations-Know-how eingekauft hat, und SAP.

Nach Überzeugung von Rolf Schumann, Director SAP Net- weaver bei SAP, könnten Anwender schon heute davon profitieren. Dies gelte auch für R/3-Kunden, sofern diese von der "Netweaver"-Plattform Gebrauch machten. Der SAP-Manager berichtete von einem Unternehmen, das auf diese Weise seine IT-Kosten halbiert habe.

Umbau der DV-Abläufe

Doch es geht nicht nur um IT-Budgets, sondern vor allem um Rationalisierung der Unternehmensprozesse. Plenum-Berater Kohl spricht von einer erweiterten Unternehmensarchitekur. Durch eine neu eingezogene "Geschäftsservice-Architektur" sollen Business-Prozesse von den Anwendungen entkoppelt werden. Was sich harmlos anhört, bedeutet einen massiven Umbau der IT-Abläufe. Dazu zählt, Change-Prozesse mit den Disziplinen zum Steuern des Lebenszyklus von IT-Services in Einklang zu bringen. Niederschlag finden müsse SOA außerdem in der IT-Governance - sofern die im Unternehmen überhaupt vorhanden ist. Gemeint sind damit Prozesse, Rollen und Gremien, die den DV-Einsatz lenken. Kohl zufolge macht die SOA-Einführung ein zusätzliches Querschnittsgremium ("SOA Board") erforderlich. Darin sollte natürlich Einigkeit über das Ziel herrschen. Das ist keine Selbstverständlichkeit. So sieht es auch Rainer Scheibehenne vom Team Strategie/Architektur bei der West LB in Düsseldorf: "Es gibt eine Menge verschiedene Definitionen für SOA, wichtig ist, dass man sich für eine zum Unternehmen passende Definition entscheidet und diese auch durchhält."

Architektur-Management

Um überhaupt ein SOA-Projekt auf die Beine stellen zu können, müssen Anwender ihre IT-Infrastruktur genau kennen und die Anforderungen der Fachabteilungen zusammentragen. "Architektur-Management ist eine wichtige Voraussetzung für SOA und wird häufig unterschätzt", so Scheibehenne. Steht das Architektur-Management, müssen Anwender es für SOA nicht neu erfinden. "Die grundsätzlichen Schritte und Zielrichtungen des Architektur-Managements werden durch SOA nicht in Frage gestellt. Jedoch gilt es bei Anforderungs-Management, Architekturdesign und Umsetzungsplanung SOA-spezifische Eigenheiten zu beachten." Hier könne es zu Problemen kommen: "Oft fällt es schon heute schwer, IT-Anforderungen von den Fachabteilungen einzusammeln."