Von Wolfgang Kelz*
Wirft man einen Blick auf die Geschichte von Integrationslösungen, wird einem schnell klar, dass Unternehmen bereits seit langem SOA-ähnliche Projekte umsetzen. So hat zum Beipiel der italienische Reifenhersteller Pirelli eine europaweite Portalanwendung 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. Dafür entwickelte Pirelli je nach Grösse des Distributors verschiedene Anwendungen, die aber auf denselben Architekturkonzepten basieren und bestehende IT-Komponenten so weit wie möglich nutzen. Das war im Jahr 2001. Heute benötigt ein neuer grosser Distributor weniger als zwei Tage, um sich in die Systeme von Pirelli einzuklinken, ein kleinerer nur eine Stunde.

SOA im Kontext

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 und der einen wesentlichen, aber nicht den aussergewöhnlich hohen ROI liefern wird. 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 die nötige Aufmerksamkeit bekommt, 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 Befürworter, wie beispielsweise den CFO, für das Projekt gewinnen. Stephan Madlung, Leiter des Integ-rationskompetenzzentrums 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 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 Auftrags-eingabe-System zu verknüpfen, um einen Warnmechanismus zu schaffen, wenn Waren zur Neige gehen. Ziel ist, das Unternehmen von einer Silo-basierten zu einer Prozess-orientierten Architektur zu führen. Anstelle einer Einteilung des Unternehmens in Fachbereiche rücken Prozesse, wobei Handlungen einer Abteilung Konsequenzen auf jeden einzelnen in der Wertschöpfungskette haben.

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 lang--fristigen Nutzen von SOA und vermeidet übermässige Investitionen in die Architektur, da man sich auf die Funktionen konzentriert, die tatsächlich genutzt werden. Das Finanzierungsmodell sollte einen klaren und kontinuierlichen Fortschritt sicherstellen, unabhängig von dem Mass an verfügbarer, zent-raler Finanzierung.

Als nächstes sollte man ein Steuerungssystem erstellen, um sicher zu gehen, 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 Prozesse wie die Überprüfung der Kreditwürdigkeit erfordern, lässt sich die Idee von SOA anbringen, dass man diese Prozesse auf einer On-Demand-Basis nutzt. Diese können auch von Drittanbietern stammen, wobei immer das Konzept der Wiederverwendung im Vordergrund steht.

In dieser Phase sollte man überdenken, welche Services man selbst 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 bestehen vielleicht schon. Diese zu finden ist schwierig, aber unumgänglich, da die komplexen Prozesse in den Anwendungs-Silos von -vergangenen IT-Investi-tionen liegen. An dieser Stelle vergessen viele SOA-Anbieter, dass im Laufe der Entwicklung von 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. ESB sind heutzutage jedoch auf Lösungen für Fachabteilungen zugeschnitten, wo die Vermittlung relativ einfach ist. Doch ESB 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 echten 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 vielmehr darum, einen wachsenden Nutzen aus bereits Vorhandenem zu ziehen. Durch eine zentrale Finanzierung ist man flexibel für einen kurzfristigen, praktischen 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