In der Tat, Webservices sind ja eine feine Sache. Da kann man, ohne viel Aufwand, ganz leicht 2 Anwendungssysteme verbinden. Denn jeder Hersteller, der was auf sich hält, “enabled” seine Anwendungen. Alte API’s werden “gewrapped” und SAP wartet sogar mit NetWeaver auf. Jetzt schnell noch die WSDLs ausgetauscht und fertig ist die Integration. Eigentlich. Weil im wirklichen Leben ist auch dieses “Einfache” nicht ohne Fallen und klappt nicht so auf Anhieb. Gelingt es aber dann doch neigen manche leicht dazu, Ihren Erfolg als Einführung einer SOA zu zelebrieren. Auch, wenn nur eine alte Stored Procedure einer Datenbank nun als Webservice daherkommt.
Im Glanze des Erreichten gibt es Begeisterung des CIOs und vielleicht auch Budget - für einen Service Bus. Der tut’s natürlich erstmal auch nicht so einfach wie in der Verkaufspräsentation des Lieferanten, aber auch das wird hingebogen. Jetzt geht Integrieren so richtig leicht von der Hand…
Hier endet häufig die Geschichte der Einführung von SOA in vielen Unternehmen. Entweder weil man mit dem Erreichten zufrieden ist - häufig auch zu Recht - oder weil es an den Voraussetzungen fehlt weiter zu machen. Das eigentlich schwierige und anspruchsvolle auf dem Weg zu SOA ist nämlich nicht die Technik sondern
- Analyse und Design der Geschäftsprozesse
- Erstellung einer Referenzarchitektur
- Festlegung (und Einhaltung !!) von Standards
- Übersetzen der Geschäftsprozesse in SOA Services
- Identifizieren von Business Cases zur Umsetzung der Services
- …
und so weiter und so weiter. Eine Menge Dinge sind zu berücksichtigen, um tatsächlich eine SOA einzuführen, die bereits viele Bücher füllen.
Es kann also sehr weise sein diesen schwierigen Weg nicht zu gehen. Nämlich dann, wenn der tatsächlich zu erwartende Nutzen den geschätzten Aufwand nicht deutlich übersteigt. Und wer vorbehaltlos den Versprechungen der Industrie von Consultants glaubt, der wird möglicherweise mit überzogenem Budget und doch keinem zusätzlichen Nutzen sich wünschen, mit der Umstellung auf Webservices zufrieden gewesen zu sein.
Einmal mehr sorgt ein US-amerikanischer IT-Berater mit einer gewagten Prognose für Schlagzeilen: Die wachsende Nutzung Service-orientierter Architekturen (SOA) wird zum Verschwinden des ERP-Markts in seiner heutigen Form führen, prognostiziert Bruce Richardson von AMR Research. In drastischen Worten beschreibt er den “Tag des jüngsten Gerichts” um das Jahr 2010: “SAP- und Oracle-Kunden werden dann aufhören, Anwendungen von ihren ERP-Anbietern zu kaufen.” Profitieren würden vor allem billige Systemintegratoren aus Indien oder Osteuropa. Sie entwickelten maßgeschneiderte “Composite Applications” für Kunden, die diese auf ihren vorhandenen ERP-Backbones einsetzen.
Auf den ersten Blick erscheint dieses Szenario ziemlich unrealistisch. Continue reading ‘Bedeutet SOA den Tod von ERP?’
Einher mit der Marketing-Euphorie von Herstellern, die SOA in den höchsten Tönen loben, hat sich die Anzahl der sogenannten SOA-Anbieter über die letzten 3 Jahre deutlich erhöht. Ich sage hier “sogenannte” SOA-Anbieter, da eine Architektur für eine Unternehmens-IT nicht von der Stange gekauft werden kann. Insofern kann es auch keine SOA-Anbieter geben, wohl aber Anbieter, deren Produkte mit allgemein anerkannten SOA-Standards konform sind. Diese kleinen aber wichtigen Unterscheide sind bei dem Anwenderunternehmen bisher nicht angekommen, wie eine aktuelle Studie der Experton Group bereits jetzt schon zeigt. Danach geben fast die Hälfte an, keine oder praktisch keine Kenntnisse über Service-orientierte Architekturen zu haben. Lediglich sieben Prozent der Unternehmen mit mehr als 100 Mitarbeitern haben derzeit eine SOA-Initiative entweder in Planung, Pilotierung oder Umsetzung. Es bleibt den Herstellern also noch einige Überzeugungsarbeit zu tun bevor der Euro auf der SOA-Schiene rollt.
Dies ist der Titel eines kürzlich angekündigten Buches. Der beigefügte Beitrag eines Beraters aus dem niederländischen Gartner-Consulting-Team setzt sich mit der SOA-Begriffsdefinition auseinander und beleuchtet die Bedeutung der Einbettung von SOA in bereits vorhandene Management-Disziplinen.
Ein Großteil der Kernanwendungen in Unternehmen und öffentlichen Verwaltungen basiert noch immer auf Programmiersprachen wie Cobol, PL/1 oder Assembler. Die Wartung dieser oft mehr als 20 Jahre alten Legacy-Systeme ist aufwändig und teuer, schlimmer noch: Anpassungen geraten zu komplexen Projekten und halten mit den immer häufiger wechselnden Anforderungen der Fachabteilungen nicht mehr Schritt. Das Konzept Service-orientierter Architekturen (SOA) verspricht einen Ausweg aus dem Dilemma.
Letzte Kommentare
RSSBenjamin Hötzel
Uwe Feddern, Falke, F. Delonge [...]
B. A. Schön, Jakob Freund
Daniel Craig, Tobias Thiel, Sascha Körner