Es wird viel über SOA (Service Oriented Architecture) geredet und geschrieben. Doch man erfährt wenig darüber, wie man ein SOA-Projekt konkret umsetzt. CIOs interessiert in erster Linie die Relevanz für ihr eigenes Unternehmen, die kurz- und langfristigen Vorteile sowie die Kosten. Im Folgenden wird ein sechsstufiger Plan zur Umsetzung eines erfolgversprechenden SOA-Projekts skizziert.
Wirft man einen Blick auf die Geschichte von Integrations-lösungen, wird einem schnell klar, dass Unternehmen bereits seit langem SOA-ähnliche Projekte umsetzen. So hat zum Beipiel der italienische Reifenhersteller Pirelli bereits 2001 eine europaweite Portal-Anwendung geschaffen, über die seine Distributoren den aktuellen Lagerbestand und die Liefersituation für die komplette Reifenpalette einsehen können. Die Idee hinter dem Projekt war, die Konkurrenz in Sachen Liefergeschwindigkeit und Kundenservice zu übertreffen.
Viele denken, dass SOA ein Unternehmen auch mit seinen Handels- und Geschäftspartnern verbindet. Dies ist sicherlich ein langfristiges Ziel für viele Unternehmen, doch bei der Planung einer Service-orientierten Architektur in einem frühen Stadium nicht hilfreich, da sich Geschäftsprozesse im Laufe der Zeit ändern.
Effektiver ist es, an der Basis des Unternehmens zu beginnen. Dabei gilt es, einen ineffizienten Prozess zu identifizieren, der nicht geschäftskritisch, aber relativ wichtig ist. Ein gutes Beispiel dafür wäre ein System für die Auftragseingabe, das sich nahtlos in die Kreditkontrolle integriert. So wird sichergestellt, dass zahlungsunfähige Kunden keine Waren oder Dienstleistungen erhalten.
Damit das Projekt unternehmensintern die nötige Aufmerksamkeit erhält, ist es wichtig, die Kosten dafür zu quantifizieren. Dabei sollte man auf der einen Seite mit den entsprechenden Fachabteilungen eng zusammenarbeiten und auf der anderen Seite einen «prominenten» Befürworter, beispielsweise den CFO, für das Projekt gewinnen. Stephan Madlung, Leiter des Integrationskompetenzzentrums von Lufthansa Systems dazu: «Als erstes haben wir einen starken Lobbyisten an Bord geholt, der sich für die gesamte SOA-Idee einsetzte.»
Wenn man sich auf ein einziges Projekt oder einen Piloten beschränkt, entspricht dies nicht gerade der zentralen Idee eines vernetzten Unternehmens. Als zweiten Schritt braucht man also ein Projekt, das als Sprungbrett für weitere Projekte dienen kann. Dafür eignet sich besonders ein Bereich, der stufenweise Vorteile bringt.
Die meisten SOA-Projekte tun sich schwer, bei der Erstimplementierung einen garantierten Gewinn zu liefern, da sie Basisarbeit leisten müssen, die sich erst im späteren Lebenszyklus des Projekts auszahlt. Ein Beispiel wäre hier, die Warenbewegungen mit dem oben genannten Auftragseingabe-System zu verknüpfen, um einen Warnmechanismus zu schaffen, wenn Waren zur Neige gehen.
Ziel ist es, das Unternehmen von einer Silo-basierten zu einer Prozess-orientierten Architektur zu führen. Anstelle einer Einteilung des Unternehmens in Fachbereiche empfiehlt sich eine Unterteilung in Prozesse, wobei die jeweiligen Handlungen einer Abteilung Konsequenzen auf jeden einzelnen Prozess in der Wertschöpfungskette haben.
Zentral für eine SOA: Der Enterprise Service Bus
Die Sicherung angemessener finanzieller Mittel für das Projekt ist ein nicht unwesentlicher Schritt. Nach einem Best-Practice-Report von Forrester bietet sich ein
kombiniertes Modell aus «gestreuter» und zentraler Finanzierung an. Dies entspricht dem langfristigen Nutzen von SOA und vermeidet übermässige Investitionen in die Architektur, da man sich auf die Funktionen konzentriert, die tatsächlich genutzt werden. Das Finanzierungs-
modell sollte einen klaren und kontinuierlichen Fortschritt sicherstellen, unabhängig von dem Mass an verfügbarer zentraler Finanzierung.
Als nächstes sollte man ein Steuerungssystem erstellen, um sicherzugehen, dass das Projekt im Zeitplan bleibt und jeder die Prozessschritte, Richtlinien und Standards nicht nur versteht, sondern auch umsetzt. Dies soll Innovationen nicht ersticken, sondern die Verbreitung von proprietären APIs vermeiden, die alle Bemühungen eines Unternehmens in Richtung von offenen, Standard-basierten Anwendungen und Funktionen untergräbt.
Die meisten Unternehmen haben eine IT-Umgebung, die Massimo Pezzini, Senior Research Analyst von Gartner, als eine «Spaghetti-Suppe» beschreibt: trübe und manchmal sogar undurchdringlich. Jede Anwendung einer Fachabteilung ist eng mit komplementären Anwendungen verknüpft. In einer SOA-Umgebung dagegen sind die Applikationen lose gekoppelt, so dass sie sowohl bestehende als auch zukünftige Geschäftsprozesse unterstützen. Überall dort, wo durchgängige Prozesse allgemein verwendete Komponenten wie ein Adressfeld oder Abläufe wie die Überprüfung der Kreditwürdigkeit erfordern, lässt sich die Grundidee von SOA umsetzen, dass diese Services auf einer On-demand-Basis genutzt werden sollen.
In dieser Phase sollte man überdenken, welche Services man selber erstellen und welche man einkaufen möchte und wie man diese skaliert. Jetzt ist es an der Zeit, die Hauptverantwortung für die Umsetzung an die IT zu übergeben, so dass dort die entsprechenden technologischen Entscheidungen getroffen werden können. Einige Services wie die Überprüfung der Kreditwürdigkeit lassen sich am besten auslagern, da sie alle Unternehmen benötigen und auch ausserhalb der Firewall liegen können. Andere Services bestehen vielleicht schon. Diese zu finden, ist manchmal nicht so einfach, aber unumgänglich, da die komplexen Prozesse in den Anwendungs-Silos von vergangenen IT-Investitionen liegen.
An dieser Stelle vergessen viele SOA-Anbieter, dass im Laufe der Entwicklung einer SOA immer mehr Services hinzukommen und dabei eher zu mehr als zu weniger Komplexität beitragen werden. Dies wirft die Frage nach der Skalierbarkeit auf, um zwischen der wachsenden Anzahl von Services zu vermitteln. Ein Enterprise Service Bus (ESB) bietet einen solchen Vermittlungsansatz. ESBs sind heutzutage jedoch auf Lösungen für Fachabteilungen zugeschnitten, in denen die Vermittlung relativ einfach ist. Doch ESBs sind –wie jede andere Servicekomponente –Teil des SOA-Frameworks, das man für kurzfristige, langfristige und komplexe Prozesse im Unternehmen pflegen muss. Deshalb sollte ein ESB SOA-Funktionalität bieten, um in der realen Welt bestehen zu können.
Schliesslich sollte man den kurz- und langfristigen ROI bedenken. Es ist wichtig zu verstehen, dass bei diesem Ansatz keineswegs bestehende IT-Investitionen verloren gehen. Es geht mehr darum, einen wachsenden Nutzen aus bereits Vorhandenem zu ziehen. Durch eine zentrale Finanzierung ist man flexibel für einen kurzfristigen Erfolg in einem grösseren Kontext.
Natürlich könnte man noch sehr viel mehr über SOA-Implementierungen sagen, aber allein dieser grobe Überblick sollte verdeutlichen, dass SOA-Projekte alles andere als vage Visionen sind, sondern zweifellos nachweisbaren Nutzen liefern. Auch wenn es sich bei SOA um eine langfristige Strategie handelt, so kann man sich seinem Ziel durchaus in kleineren, überschaubaren Teilprojekten nähern.
Wolfgang Kelz ist Director Solution Consulting Central and Eastern Europe bei TIBCO.
