welche Voraussetzungen Unternehmen für SOA schaffen müssen;
welche Schritte sich in der Praxis bewährt haben;
was Experten empfehlen;
wo die größten Hürden liegen.
SOA ist eine Idee, keine Technik. Diese Botschaft kommuniziert die IT-Industrie schon seit längerem. Im gleichen Atem- zug überschüttet sie den Markt mit angeblich SOA-tauglichen Produkten und Dienstleistungen. Vereinfacht gesagt, bildet SOA ein breit angelegtes Rahmenwerk. Darin lassen sich Softwareservices erstellen, verwalten und kombinieren. Das große Ziel ist eine an Geschäftsprozessen ausgerichtete IT-Infrastruktur, die schnell auf veränderte Anforderungen reagiert. Weil Services mehrfach verwendet werden können, verspricht SOA zudem Kostenvorteile. Doch wo sollen Unternehmen beginnen? Erfordert SOA eine grundlegend veränderte IT-Landschaft? Müssen Geschäftsprozesse, Organisations- und Management-Strukturen neu definiert werden?
Mehr als zwei Jahre lang befragte die amerikanische CW-Schwesterpublikation "Infoworld" Spezialisten, die in ihren Organisationen SOA-Konzepte vorantreiben, unter ihnen Systemarchitekten, Entwickler und Projekt-Manager. Einige meldeten bereits erste Erfolge, beispielsweise eine leichtere Integration heterogener Applikationen oder die Wiederverwendung von Programmcode. Die Praxiserfahrungen ergänzten die US-Kollegen durch Empfehlungen von Analysten und anderen Experten.
Daraus entstand ein Ratgeber, der Planung, Aufbau und Verwaltung einer SOA in zehn Schritten beschreibt. Er enthält wesentliche Konzepte, die SOA zugrunde liegen, wenngleich die Reihenfolge der beschriebenen Stufen nicht auf jede Organisation passen muss. Das Procedere hängt davon ab, welche Bedingungen die Initiatoren vorfinden und was sie mit SOA erreichen wollen.
Soll SOA Unternehmen agiler machen, muss eine Prozessbetrachtung am Anfang stehen, darin sind sich die meisten Experten einig. Je rascher sich die Anforderungen verändern, desto mehr profitieren Organisationen von den Vorteilen einer gut implementierten Servicearchitektur. "Beginnen Sie mit einem Topdown-Ansatz aus Sicht der Geschäftsprozesse", rät Jean-Michel Van Lippevelde von Accelior Consulting. Dabei gilt es einerseits, Verbesserungspotenziale zu identifizieren, andererseits aber auch, die nötige Rückendeckung aus dem Topmanagement zu gewinnen. "SOA ist ein Management- und kein Technologiekonzept", formuliert auch Thomas Helbig, CIO der Deutschen Post, die hierzulande zu den SOA-Pionieren zählt.
In der Umsetzung sollte sich der Blickwinkel wieder verengen. Big-Bang-Konzepte haben so manche ambitionierte SOA-Initiative scheitern lassen, berichtet Ed Horst vom kalifornischen Software- und Beratungshaus Amberpoint: "Die erfolgreichsten Einstiegsprojekte, die wir gesehen haben, waren klein angelegt. Es ging um sechs bis zehn Services, die zwei oder drei Dinge integrierten und innerhalb von etwa sechs Monaten abgeschlossen waren."
Viele Unternehmen machen die ersten Schritte Richtung SOA, indem sie wenige geschäftskritische Legacy-Anwendungen als Services zur Verfügung stellen. Andere Applikationen erhalten damit erstmals Zugriff auf wichtige Daten oder Funktionen der Altsysteme.
Kein Projektverantwortlicher ist in der Lage, alle relevanten Geschäftsprozesse in Eigenregie zu sezieren. Von Beginn an sollte das Team die Fachverantwortlichen ins Boot holen. Sie wissen am besten, wie sich Prozesse restrukturieren lassen, und können den SOA-Spezialisten viel Arbeit abnehmen.
"Um die Prozesse zu verstehen, haben wir uns mit jeder Dienststelle einzeln zusammengesetzt", erläutert Dan Thomas, IT-Manager in der Verwaltung des US-Regierungsbezirks District of Columbia. Ziel des von ihm verantworteten Programms DC Stat ist es, die 65 Daten-Repositories der Regierungsbüros zu verbinden. Hohe Beamte sollen damit rasch Informationen für politische Entscheidungen abrufen können. Auch im SOA-Konzept der Deutschen Post spielen Fachabteilungen in der Umsetzung die entscheidende Rolle, erklärt Helbig. Sie sind Herren ihrer Anwendungsdomänen und Daten.
Zu den SOA-Grundsätzen gehört es, vorhandene IT-Ressourcen in der Anfangsphase so weit wie möglich zu nutzen. Die dazu nötige Bestandsaufnahme lässt sich in einem mehrstufigen Prozess bewältigen. Zunächst geht es darum, Datenquellen und Anwendungen zu dokumentieren, die von der ersten SOA-Implementierung betroffen sind. Dazu gehören auch Services von Partnern außerhalb der Firewall, die gegebenenfalls anzubinden sind.
