SOA: Keine vage Vision

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.