Bei Anwendern entsteht zuweilen der Eindruck, dass durch die Einführung von Service orientierten Architekturen (SOA) künftig praktisch keine eigene Software mehr entwickelt werden muss. „Ein einmal eingeführtes SOA-Framework mache das ‘Einklinken’ von neuen Modulen zum Kinderspiel. Zusätzliche Composite Applications oder -Services seien aus dem Internet beliebig verfügbar und die zusätzlichen Module verschiedener Anbieter ließen sich beliebig kombinieren“, sind beliebte Aussagen der Hersteller. Das ist natürlich mitnichten der Fall! Richtig ist vielmehr, dass zwar Frameworks als SOA-Basis von den großen IT-Anbietern häufig in einer Mischung von Produkt- und Dienstleistungen angeboten werden; trotzdem sind die Frameworks für das Gesamtangebot des jeweiligen Herstellers optimiert. Eine wirklich offene Architektur als solche wird nur schwerlich von einem Hersteller kaufbar sein. Das Architektur-Design und die „Architektur-Hoheit“ liegen in der ureigenen Verantwortung eines jeden Unternehmens beziehungsweise des CIOs.
Author Archive for Rüdiger Spies
Viel ist bereits über die Notwendigkeit von Repositories in Service-orientierten Architekturen berichtet worden. Repositories sind bereits aus anderen Zusammenhängen bekannt. So ist es in der klassischen EAI (Enterprise Application Integration) sinnvoll beziehungsweise notwendig, über ein Repository ein Mapping der Punkt-zu-Punkt-Verbindungen über einen Integration-Server zu dokumentieren. Darüberhinaus sind im EAI-Repository die Translation-Regeln für die unterschiedlichen Applikationen zu hinterlegen.
Der Abschluß des Beitrags von Wolfgang Herrmann “Mit der Marktkonsolidierung steigt auch im SOA-Zeitalter wieder die Gefahr der Herstellerabhängigkeit” provoziert geradezu eine Gegenposition.
Es ist zwar das große Versprechen der Hersteller, dass mit SOA alles besser wird. Das bezieht sich auch auf vermeintliche Herstellerunabhängigkeit beim Einsatz von Software-Produkten (und ggfs. auch bei Hardware). Dabei soll hier nicht das Grundsätzliche SOA-Konzept in Frage gestellt werden. Aus meiner Sicht gibt es mittel- bis langfristig keine wirkliche Alternative – vielmehr meine ich, dass sich das Konzept auch auf allgemeine Unternehmenssteuerungskonzepte übertragen wird.
Allerdings wird es eine Herstellerunabhängigkeit nicht automatisch mit der Einführung von SOA geben. Die Abhängigkeiten werden – wie heute – erhalten bleiben. Es mag zwar im Einzelfall einfacher werden, eine Komponente von einem Hersteller gegen eine Komponente eines anderen Herstellers auszutauschen (zB. im Commodity-Office-Bereich). Aber ein komplexe Systemlandschaft wird sich nicht beliebig durch eine andere ersetzen lassen. Man könnte vielmehr vermuten, dass die Abhängigkeit sogar noch ansteigt. Denn wenn eine komplexe IT-Systemlandschaft, die sich auf Komponenten mehrerer Hersteller abstützt und auf der Basis einer SOA aufgebaut ist, erst einmal getestet ist (ja, das wird ein drängenden Problem!) und im Einsatz ist, wird der Ersatz von Teilkomponenten eher schwieriger als einfacher. Insofern nimmt die Herstellerabhängigkeit mitnichten ab.
Vielmehr bleibt es in Zukunft weiterhin keinem erspart, “am Beginn über das Ende” nachzudenken. Will heissen, dass das beste Architektur- und Implementierungskonzept auch immer eine Exit-Strategie umfassen sollte. Diese kann greifen, wenn ein Lieferant insolvent wird oder aus anderen Gründen eine Geschäftsbeziehung mehr aufrecht erhalten werden soll. Die Erhöhung der Flexibilität, die viele Unternehmen mit SOAs erreichen wollen, setzt auch voraus, die potentielle Flexibilität auch mit Leben zu füllen. Das wiederum bedeutet das Management von Optionen, die zwar derzeit nicht ausgeübt werden, die aber als Backup, Fall Back oder einfach als Alternativstrategie zu 80% einsatzfertig durchdacht sein sollte.
Die Empfehlung an Anwenderunternehmen lautet also, beim Einsatz von Komponenten (nicht nur) für eine SOA parallel eine Exitstrategie mitzuentwerfen. Diese “Denken mit doppeltem Boden” passt den Herstellern sicher überhaupt nicht, aber es schützt vor zu hoher Abhängigkeit.
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.