CW: Seit dem vergangenen Jahr haben sich Service-orientierte Architekturen zum Hype-Thema entwickelt. Lässt die Euphorie nun schon wieder nach?
Kosten sparen mit SOA?
Geht es um die Wirtschaftlichkeit von SOA-Projekten, bewegen sich die meisten Experten auf dünnem Eis. Das Prinzip scheint einfach: Je mehr Servicemodule in einer SOA-Infrastruktur wiederverwendet werden, desto höher die Einsparungen bei der Entwicklung neuer Anwendungen. Dagegen stehen hohe Anfangsinvestitionen, die sich oft nur schwer beziffern lassen. "Es gibt garantiert einen billigeren Weg, Ihr nächstes Produkt zu entwickeln", wirbt Christopher Crowhurst vom US-amerikanischen Softwarehaus Thomson Learning. "Aber es gibt keine billigere Methode, Ihre nächsten 20 Produkte zu entwickeln."
Die Forrester-Analysten Ken Vollmer und Mike Gilpin bestätigen diese Sicht. Betrachte man nur eine einzelne Anwendungskomponente, liege der Entwicklungsaufwand in einer SOA-Umgebung im Vergleich zu traditionellen Methoden doppelt so hoch. Werde die Komponente indes immer wieder benutzt, bringe eine SOA Kostenvorteile von mindestens 30 Prozent.
Redundante Anwendungen konsolidieren
Einen Großteil der potenziellen Einsparungen führen SOA-Protagonisten auf die Möglichkeit zurück, redundante Silos aus Anwendungen und Daten unternehmensweit zu konsolidieren: Weniger Softwarelizenzen und Server bedeuteten niedrigere Kapital- und Betriebskosten. Ebenso lasse sich mit einer geringeren Anzahl redundanter Softwarekomponenten der Bedarf an Programmierteams senken. Die mit SOA realisierbare Konsolidierung von Applikationen auf weniger Plattformen reduziere die Kosten über den gesamten Lebenszyklus der Software ("lifecycle costs"), argumentiert Gartner. Diese könnten sechsmal so hoch liegen wie die Lizenzkosten.
Ein prominentes Beispiel liefert die schottische Standard Life Group, wo rund 500 Spezialisten in drei SOA-Implementierungs-Teams arbeiten. Welche Kosten damit verbunden sind, verrät der Versicherer nicht. Weil einmal erstellte Funktionen aber mehrfach genutzt würden, habe man in den vergangenen drei Jahren mehr als 2,8 Millionen Pfund an Entwicklungskosten gespart, sagt IT-Manager Derek Ireland. In einem Servicekatalog führe Standard Life derzeit rund 300 Komponenten, mehr als die Hälfte davon sei mindestens einmal wiederverwendet worden. (wh)
www.computerwoche.de/go/
*80263: SOA-Risiken;
*77527: HP und IBM bieten Support für SOA;
151405: SOA - aber wie?
BEINHAUER: Ich fürchte, wir haben den Zenit noch gar nicht erreicht. Es wird wohl eher noch schlimmer werden.
CW: Hersteller versprechen mit SOA so etwas wie Plug-and-Play für die Unternehmens-IT. Wie realistisch sind die damit verbundenen Erwartungen?
BEINHAUER: Man braucht ja immer eine Vision, wenn man sich einem solchen Thema nähert. Im Fall von SOA wird diese sicher nicht so schnell Realität werden. Mir kommt der SOA-Hype ein bisschen vor wie die Fortsetzung der Web-Services-Euphorie. Immerhin ist man jetzt von einer rein technischen Fragestellung zu einer Art Vorgehensweise im architektonischen Stil gekommen. Von Plug-and-Play der IT über Unternehmensgrenzen hinweg sind wir aber nach wie vor weit entfernt.
CW: Glaubt man den Softwareanbietern, arbeiten etliche Unternehmen bereits an SOA-Projekten. Gibt es tatsächlich IT-Abteilungen, die ihre monolithischen Altanwendungen in austauschbare Servicemodule zerlegen?
BEINHAUER: Eben nicht, jedenfalls nicht in Reinform. Mir sind nur wenige Beispiele bekannt, wo das SOA-Konzept halbwegs konsequent umgesetzt wurde, zum Beispiel bei der Betreibergesellschaft des Flughafens Zürich. Sie stellt ihren Kunden auf verschiedenen Endgeräten Dienstleistungen automatisiert zur Verfügung. Dahinter liegen entsprechende Infrastrukturservices.
CW: Kennen Sie Beispiele im deutschen Markt?
BEINHAUER: Die Deutsche Post ist mit einem großen Projekt an die Öffentlichkeit gegangen. Nach meiner Kenntnis handelt es sich um ein größeres Framework, in dem verschiedene Anwendungen miteinander kommunizieren. Ob man das schon als SOA bezeichnen kann, ist fraglich. Die Hypovereinsbank betreibt ein Projekt zur Serviceorientierung in Teilen ihres Kernbankensystems, das schon ein gutes Stück weiter geht.
CW: Wo sehen Sie die größten Hürden auf dem Weg zu einer Service-orientierten Architektur?
BEINHAUER: Das sind zum einen organisatorische Fragen. Mitarbeiter, die mit der Prozessgestaltung befasst sind - also das strategische und das operationale Management - müssen sich mit den IT-Spezialisten zusammensetzen. Diese Kommunikation findet so noch nicht statt. Zum anderen fehlt es an verlässlichen Standards für Schlüsseltechniken wie Web-Services. Hier ist vieles noch im Fluss. Bis Ende des Jahres sollen beispielsweise die Spezifikationen für WS-Transaction in trockenen Tüchern sein, die für WS-Security erst Mitte 2006. Solange diese Prozesse nicht abgeschlossen sind, fehlt den Unternehmen die nötige Investitionssicherheit.
CW: Anbieter wie Bea oder IBM, die Software für Enterprise Application Integration (EAI) offerieren, bewerben ihre Produkte jetzt unter dem Schlagwort SOA. Bei EAI geht es um die Kopplung bestehender, auch sehr großer Anwendungen. Betreiben die Hersteller Etikettenschwindel?
BEINHAUER: Das muss man differenziert sehen. IBM unterstützt SOA doch sehr konsequent und hat letztes Jahr auch die Produktpalette darauf ausgerichtet. Zumindest lässt sich das nach außen hin gut so darstellen. EAI dagegen beinhaltet ja schon das Wort Application. Genau davon will man weg mit SOA, das Ziel ist eine Enterprise Process Integration. Insofern verbirgt sich hinter den Bemühungen der Hersteller doch mehr als ein reines Umetikettieren ihrer Produkte.
CW: Ein Argument für SOA lautet Herstellerunabhängigkeit. Dennoch müssen sich Unternehmen beim Aufbau solcher Strukturen auf einen Infrastruktur- beziehungsweise Middleware-Anbieter festlegen, beispielsweise wenn es um Application Server geht. Wird die Abhängigkeit damit nicht nur auf eine andere Ebene verlagert?
BEINHAUER: Die darunter liegenden Basistechniken sind immer die gleichen. Im Wesentlichen geht es um Techniken zum Nachrichtenversand wie Java Messaging Service (JMS), die von allen Anbietern gleichermaßen bedient werden. Insofern bereitet es eigentlich keine Schwierigkeiten, wenn etwa ein Application Server von Bea mit einer IBM-basierenden Anwendungslösung kommuniziert. Ich sehe eher ein Problem mit der Entwicklung der benötigten offenen Standards.
CW: Inwiefern?
BEINHAUER: Die großen Hersteller wollen mit ihren zahlreichen Tools für Service-orientierte Architekturen irgendwann einmal Geld verdienen. Deshalb kann ich mir vorstellen, dass sie von diesen momentan noch offenen Standards und Protokollen eines Tages doch abweichen. Unter dem Deckmantel einer Verfeinerung oder Verbesserung könnten sich dann wieder proprietäre Dinge einschleichen. Microsoft beispielsweise hat nach einigem Zögern Java unterstützt, dann aber mit C# doch eine eigene Variante der Programmiersprache gebracht.
CW: SOA-Projekte gelten als aufwändig und erfordern beträchtliche Anfangsinvestitionen. Viele Unternehmen aber wollen noch immer Kosten senken und fordern einen schnellen Return on Investment (RoI) für IT-Projekte. Wie lässt sich dieser Konflikt lösen?
BEINHAUER: Bei der RoI-Betrachtung von SOA-Projekten sollte man das Augenmerk nicht so sehr auf die Kosten richten, sondern auf den erzielten Nutzen. Ob sich überhaupt Kosten einsparen lassen, ist aus meiner Sicht fraglich. Dass man mit SOA eine neue Qualität bekommt und echte Wertschöpfung erzielen kann, ist hingegen sicher. In welchem Maße dies geschieht, hängt davon ab, inwieweit ein SOA einführendes Unternehmen tatsächlich auf flexible Prozesse angewiesen ist.