Im SOA-Markt bewegen sich vier Kategorien von Anbietern:
-
Middleware-Anbieter (hier sind vor allem IBM und BEA zu nennen als "pure play"-Anbieter mit Fokussierung auf Middleware)
-
Applications-Anbieter mit eigenem SOA-Middleware-Angebot (hier besonders SAP, Oracle und Microsoft)
-
Applications-Anbieter, die Middleware anderer Anbieter nutzen (zum Beispiel Lawson)
-
Systemintegratoren
Die ersten beiden Kategorien versuchen, Anwendungslandschaften zu prägen und damit Marktterritorium zu gewinnen oder zumindest zu sichern. Die anderen haben weniger strategische Ziele: Sie wollen bei Integrationsprojekten auf eine gute, verbreitete und preiswerte Grundlage zurückgreifen. Systemintegratoren lieben SOA, weil sie hier ein sehr dauerhaftes Betätigungfeld sehen. Einmal begonnen, können SOA-Projekte leicht zum Dauerbrenner werden, weil (wie bereits bei ERP beobachtet) daraus über immer neue Erweiterungen eine "unendliche Geschichte" werden kann. Genau danach hatten die Anbieter doch gesucht ...
SOA nicht immer ein Enabler
SOA suggeriert die beliebige Kombination und Integration jeglicher Software. Da ist eigentlich kein Platz für Territorialkämpfe der Anbieter. Denn folgt man der SOA-Vision, dann muss alles so problemlos gehen wie ein Gespräch über zwei Telefonapparate unterschiedlicher Hersteller.
Anbieter preisen SOA als großen Kostensenker, Vereinfacher und vor allem als Enabler künftiger Geschäftsszenarien. Dies trifft nur eingeschränkt zu. SOA vereinfacht und senkt zwar die Kosten gegenüber üb-lichen Integrationsverfahren, die Produkte Punkt-zu-Punkt über eigens geschaffene Schnittstellen verbanden. Generell ist aber die beliebige Integration mit einer deutlichen Komplexitätssteigerung verbunden. Denn es ist schwierig, die so entstehenden Anwendungsnetze zu administrieren und so zu betreiben, dass der Anwender davon nichts merkt.
Nimmt man das Versprechen ernst, mit SOA endlich prozessorientierte Anwendungslandschaften zu gestalten, dann braucht man viel mehr als nur SOAP und XML: Man benötigt eine Kontrolle über die Prozess-struktur, die auch andere Bereiche wie Mail und Workflow einbezieht. Es reicht nicht, Prozesse zu definieren und die Definitionen in einem Repository abzulegen. Damit ist noch kein korrekter Ablauf gewährleistet.
Heutige SOA-Angebote der namhaften Anbieter leis-ten hier nur einen Teil. Spezialisten wie etwa Amadee, Cordys oder Saviion machen vor, was man braucht: ein System von Prozess-Servern, die alle Anwendungen, Workflows und Prozessen zurechenbare Mails kontrollieren sowie bei Störungen automatisch definierte Korrekturen und Notfallprozesse starten.
Es gibt keine SOA-Industrielösung
Damit ließe sich auch das drohende Compliance-Debakel lösen: Man kann dann tatsächlich sehen, was im Unternehmen und auch im Umfeld (Lieferanten, Kunden) geschieht und ob alle Regeln eingehalten wurden. Leider sind die hier tätigen Anbieter heute noch sehr klein, und ihre Langlebigkeit ist nicht sicher.
Anwendungshersteller wie SAP und Oracle erklären vollmundig, dass sie SOA bereits komplett in ihrem Bereich implementiert hätten. Sie lenken von der Realität ab: Es gibt praktisch keine Industrielösung, die SOA auf Standardschnittstellen an allen sinnvollen Stellen implementiert hätte. Der Kunstgriff, alle älteren proprietären Schnittstellen flugs unter dem Dach der SOA-Komponenten (wie beim NetWeaver geschickt geschehen) zu sammeln, ist eine Mogelpackung. Sie hat nur zum Ziel, schnell eine weite Verbreitung und Adaption statistisch nachzuweisen.
Hersteller hätten gerne eine deutlich schnellere Adaptionsrate von SOA. Sie vergessen aber, dass Anwender gebremst werden durch unzureichend ausgebildete Mitarbeiter (kaum ein Informatiker hat Kenntnisse über die hier so stark hervorgehobene Nahtstelle zwischen IT und Business), unpassende Organisationsstrukturen (kaum ein Unternehmen hat für jeden Prozess einen identifizierbaren Verantwortlichen) und die unabdingbare Notwendigkeit, jedem IT-Investment ein kurzfristig nachweisbares positives Geschäftsresultat gegenüberzustellen.