SOA-Vorhaben sind komplex und bergen ein großes Fehlerpotenzial, berichtet der amerikanische Analyst und Berater David Linthicum. Nach seiner Einschätzung scheitert mittlerweile annähernd die Hälfte aller Projekte (siehe auch: Warum SOA-Initiativen schiefgehen). Das Risiko eines Fehlschlags sei in großen Unternehmen und in Behörden besonders hoch. Dennoch haben sich Muster für erfolgreiche SOA-Initiativen herausgebildet, aus denen Anwender lernen können, so seine These. Die wichtigste Lektion aus den bisherigen Praxiserfahrungen: SOA hat ebenso viel mit altbewährten IT-Disziplinen zu tun wie mit neuer Technologie. Als erfolgsentscheidend habe sich ein organisatorischer Wandel erwiesen, der bei den Mitarbeitern beginnt und bis in die Tiefen der diversen technischen Schichten reicht. Diesem Wandel entsprechen Veränderungen auf unterschiedlichen Ebenen.
Erfolgsfaktor Mitarbeiter
Die zentrale Ursache für gescheiterte SOA-Projekte liegt im Mangel an qualifizierten Mitarbeitern, argumentiert Linthicum. Das Problem ziehe sich über alle Hierarchieebenen. Entscheidend sei aber nicht die Anzahl der SOA-Experten sondern deren Wissen und Fähigkeiten, den nötigen Wandel voranzutreiben. Unternehmen sollten bei ihren diesbezüglichen Überlegungen ganz oben ansetzen, rät der Analyst unter Verweis auf eine Studie des Beratungshauses Burton Group. Demnach verliefen SOA-Projekte besonders erfolgreich, wenn Sie von einem neu ins Unternehmen gekommenen CIO verfolgt wurden.
Zu den kritischen Erfolgsfaktoren zähle in diesem Zusammenhang generell ein Führungsteam, das Investitionen in die Infrastruktur zu schätzen wisse und deren langfristigen Wert erkenne. Linthicum nennt hier die bekannten Aspekte Agilität und Effizienz. Unterm Strich müsse das Management erkennen, dass SOA nicht billig zu haben sei. Vielmehr gehe es um einen gewaltigen Systemwechsel, der das Entwerfen, Bauen, Einführen und Testen von IT-Systemen radikal verändere. Damit verbunden seien Investitionen in Millionenhöhe und eine ganze Reihe von Teilprojekten, die sich über mehrere Jahre erstreckten. Etliche Unternehmen müssten erkennen, dass sie diese Herausforderungen mit dem vorhandenen Personal nicht stemmen können (siehe auch: Platzt die SOA-Blase?).
Erfolgsfaktor Prozesse
In der Vergangenheit griffen IT-Verantwortliche allzu oft auf die jeweils aktuellen Techniken zurück, um taktische Probleme zu lösen. Dieses Vorgehen führte laut Linthicum zu immer neuen taktischen Anforderungen und damit zu stets komplexeren und ineffizienten Architekturen. Für eine SOA sollten Unternehmen deshalb einen praktischen Prozess entwickeln, der zunächst einzelne Architekturdomänen in Basisfunktionen aufbricht. Darauf folgt der Wiederaufbau des Gesamtsystems in Form einer Service-orientierten Architektur.
Der nächste Schritt umfasst aufwändige, aber dringend notwendige Detailarbeiten, so der Berater. Die Projektverantwortlichen müssen die in den jeweiligen Domänen genutzten Informationen analysieren und dabei ein semantisches Modell für Anwendungen und Metadaten entwickeln. Viele Unternehmen vernachlässigen diese Aufgabe und erkennen daraus resultierende Probleme zu spät, warnt der Analyst.
Nach der Basisarbeit mit den Informationen steht das Definieren von Services auf der Agenda. Entgegen der weit verbreiteten Meinung gehe es bei SOA nicht primär um das Erstellen von grundlegend neuen Services. Solche Fälle seien in der Praxis eher selten. Vielmehr sollten Verantwortliche davon ausgehen, dass sie einen Großteil der Anforderungen mit bereits existierenden Softwarediensten abdecken können. Linthicum: Etliche SOA-Projekte scheitern, weil Unternehmen das Rad jedes Mal neu erfinden, statt drängende Business-Probleme zu lösen.
Stehen die Services, sollten Organisationen Prozesse definieren, die die Dienste zu Geschäftslösungen zusammensetzen. Dafür gibt es verschiedene Ansätze, beispielsweise einen Orchestration Layer in Form einer BPEL-Engine, das Erstellen von Service-orientierten Business-Applikationen (Soba) oder den Einsatz von traditionellen Tools zur Prozessintegration. Zum Erfolgsfaktor Prozesse gehören für Linthicum noch weitere Aufgaben, beispielsweise die Auswahl von Testing-Tools für Services oder das Definieren einer Strategie für die SOA-Governance (siehe auch: In zehn Schritten zur SOA).
Mehr zum Thema SOA und Geschäftsprozesse im CW-Experten-Blog SOA meets BPM.
Erfolgsfaktor Architektur
Das "A" im Kürzel SOA steht für Architektur, betont der Analyst. Obwohl dieser Aspekt fundamental sei, werde er in vielen so genannten SOA-Projekten sträflich vernachlässigt. Nach seiner Einschätzung sind daran nicht zuletzt die Enterprise-Architekten schuld, die in ihrem Elfenbeinturm säßen und aufgrund mangelnder Autorität zu wenig Einfluss auf die eingesetzte Technik nähmen. Allzu oft fänden sich unter dem Deckmantel einer Enterprise Architecture nur übereinander gelegte technische Schichten, die aus taktischen Erwägungen heraus eingeführt wurden und zu einem komplexen und schwerfälligen Ganzen gewuchert seien.
Unternehmen, die sich auf den Architekturaspekt konzentrieren, müssen einen kulturellen Wandel schaffen, fordert der SOA-Experte. Dazu gehöre eine grundlegend veränderte Sicht der IT-Abteilung auf die eingesetzte Technologie. Letztere dürfe nicht länger als eine Defacto-Architektur hingenommen werden. Andernfalls würden die Unternehmen weiterhin Millionenbeträge für den IT-Betrieb verschwenden.
Erfolgsfaktor Technologie
Es gibt keine SOA-Technologie, die die Anforderungen sämtlicher Organisationen abdeckt, lautet eine weitere Erkenntnis. Unternehmen sollten sich ihre Erwartungen an die Architektur klar machen und die dazu passende Technik auswählen. Nach Linthicums Erfahrung beginnen viele Verantwortliche SOA-Vorhaben am falschen Ende: In der Hoffnung, damit ihre Probleme zu lösen, kauften sie beispielsweise einen Enterprise Service Bus (ESB) oder ein SOA-Paket eines Herstellers. Die Folge: Die Produkte passen nicht zu den tatsächlichen Anforderungen, das SOA-Projekt fährt an die Wand (siehe auch: SOA-Pakete im Vergleich).
Der Consultant empfiehlt dagegen folgendes Vorgehen: Unternehmen sollten konkrete Anforderungen definieren und diese mit potenziell geeigneten Techniken abgleichen. Auf dieser Basis kann eine Shortlist mit denjenigen Lösungen entstehen, die im nächsten Schritt getestet werden. Dazu sollten Kunden die Hersteller einladen, um die Funktionsfähigkeit der Systeme im konkreten Fall zu demonstrieren.
Last, but not least sollten IT-Manager der Versuchung widerstehen, alle SOA-Produkte aus der Hand eines Herstellers zu beziehen. Einige Teile mögen gut in die geplante IT-Landschaft passen, andere dagegen könnten den Erfolg der Initiative womöglich zunichte machen. Die passende Lösung, so Linthicum, bestehe in den meisten Fällen aus einer Mischung unterschiedlicher Systeme von mehreren Anbietern.