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.
Hallo Herr Spies,
inwiefern ist denn ihr Kommentar eine Gegenposition zur Aussage von Wolfgang Hermann? Vielmehr unterstreichen Sie doch die These.
Wie sieht das denn bis jetzt in der Praxis aus? Kaufen sich Anwender bereits Services von x verschiedenen Herstellern und assemblieren diese? Selbst IBM-SOA-Gurus haben mir bestätigt – off the Record natürlich – das Services, die mit unterschiedlichen Plattformen gebaut sind, wohl nur schwer auf einer Ablaufumgebung zum Fliegen kommen werden. Also: SOA macht Spaß, aber herstellerabhängig!
Viele Grüße
Bernd Seidel
Hallo Herr Seidel,
ich denke, ich muss da mal was für meine “Guru”-Kollegen zurecht rücken. Sie haben schon recht, dass es immer Herstellerabhängigkeiten geben wird. Das von Ihnen angeführte Beispiel stimmt, hat aber mit SOA herzlich wenig zu tun. Bei einer SOA geht es nicht um eine Plattform-resistente Implementierung, sondern um eine Plattform-resistente Nutzung von Services. Bedeutet also, egal wo und wie implementiert wurde, ich will den Service nutzen können, heisst, möglichst leicht entlang meiner Prozesskette integrieren können. Plattformunabhängigkeit kann trotzdem ein Ziel sein. Das hat aber dann was damit zu tun, dass ich mich z.B. im Java-Umfeld auf den Standard beschränke, den alle Applicationserveranbieter auch unterstützen.
Gruss
Norbert