SOA - Wege zum Ziel

Mit dem Begriff Service-Oriented Architecture (SOA) verbindet sich das Versprechen, IT-Prozesse zukunftssicher zu machen. Unternehmen winken dadurch echte Kostenvorteile. Eine Firma kann nur überleben, wenn sie sich ständig neuen Kundenbedürfnissen anpasst. Daher muss sich künftig auch die gesamte IT-Landschaft flexibler zeigen. Das Zauberwort, das Zukunftssichersicherheit gewährleisten kann, heißt Service-Oriented Architecture (SOA). Laut den Marktforschern stößt das SOA-Konzept auf großes Interesse bei den Unternehmen: Laut einem Bericht von Berlecon Research arbeiten Großunternehmen wie General Motors oder die Deutsche Post AG bereits an SOA-Projekten. Das Marktforschungsinstitut Forrester hat zu diesem Thema die Lösungen der verschiedenen Anbieter unter die Lupe genommen. In Führung lag dabei der Oracle Application Server 10g, dem eine sehr gute Eignung für die Entwicklung von Composite Applications bescheinigt wird. Wie sollte nun konkret die SOA-Einführung angepackt werden und wie schnell lässt sich ein ROI erzielen? Zunächst der menschliche Faktor: SOA heißt, eine Applikation oder ein Geschäftsprozess, die bisher nur von einer Abteilung verwendet wurde, nun dem ganzen Unternehmen zur Verfügung zu stellen. Das kann leicht zu Eifersüchteleien und Kompetenzstreitigkeiten führen: Es ist daher entscheidend, dass die Geschäftsführung mit ganzem Herzen hinter dem SOA-Projekt steht, um die potenziellen Streithähne mit sanftem Druck zur Kooperation zu zwingen. Ein Verantwortlicher für die Koordination kann der CIO sein oder in kleineren Unternehmen der Geschäftsführer selbst. In technischer Hinsicht ist der erste Schritt, mit einer Bestandsaufnahme der im Unternehmen vorhandenen IT-Landschaft zu beginnen. Dabei muss festgestellt werden, welche Prozesse bereits vordefiniert sind und welche nicht. Zudem sollte bei den vorhandenen Services herausgefunden werden, zu welcher Abteilung sie eigentlich gehören und wer sie hostet. Es müssen eventuell Service-Level-Agreements definiert werden, wenn ein Service, der bisher nur von einem Bereich genutzt wurde, nun dem ganzen Unternehmen zur Verfügung gestellt wird. Konnte beispielsweise bisher über Nacht problemlos ein Backup angefertigt werden, ist dies vielleicht nun nicht mehr möglich. In einem weiteren Schritt muss beim Software-Design überlegt werden, mit welchem Zuschnitt Services zur Verfügung gestellt werden. Wenn die einzelnen Blöcke zu klein sind, geht der Überblick schnell verloren und die Performance leidet. Sind sie zu groß, sind Teilfunktionalitäten oft nicht mehr zugänglich. Als nächstes sind das Verhalten und das Design der einzelnen Services zu definieren. Standards spielen eine wichtige Rolle bei SOA, wobei diese je nach Einsatzgebiet unterschiedlich sein können. Hier ist die Entscheidung Offenheit versus Performance. Ein klassischer Web-Service über SOAP/HTTP ist breit zugänglich, aber teuer in der Performance. Rein unternehmensintern genutzte Services sind daher mit nativen Protokollen oft besser ansprechbar. Das Apache-Projekt Web Service Invocation Framework (WSIF) hilft, die Vorteile beider Ansätze zu vereinen. Es kombiniert die Abstraktion eines Service über ein Web Service Interface und erlaubt trotzdem die Kommunikation mit dem Service über das jeweils beste Protokoll. Ein schneller ROI in Pilotprojekten lässt sich am besten erzielen, indem die schon vorhandenen vordefinierten Prozesse, die mit einem Business Process Management oder Workflow-System erstellt wurden, mittels der Business Process Execution Language (BPEL) zu Composite Applications optimiert werden. Dabei kann es sich beispielsweise um Bestellabwicklungen oder Auslieferungslogistik handeln, also Back-Office-Prozesse, die kein komplexes User-Interface benötigen. Diese Composite Applications sind in der Praxis unkompliziert zu bauen, sind portabel und lassen sich leicht an veränderte Prozesse anpassen. Es handelt sich in der Regel um relativ einfaches Programmieren: Eine XML-Datei zeigt den Ablauf eines Prozesses, der von Modellierungswerkzeugen graphisch dargestellt werden kann. Wenn beispielsweise in einem Wasserwerk ein Störungsfall auftritt, sind von der Meldung bis zur abgeschlossenen Reparatur dutzende Schritte notwendig, ERP- und GIS-Dateien müssen einbezogen werden. Eine Individual-Software für diesen Fall zu entwickeln, wäre äußerst aufwendig. Auch ein EAI-Ansatz ist wegen der proprietären Struktur problematisch. Dagegen ist eine SOA mittels BPEL eine schnelle und einfach zu verwirklichende Alternative. Der Nutzen eines SOA-Projektes wird so in einzelnen Schritten rasch sichtbar. Ein „Big Bang“ findet nicht statt, so dass der Anwender nicht Gefahr läuft, jahrelang Geld zu investieren, ohne konkrete Resultate zu sehen. Der direkte ROI ist allerdings schwer festzustellen, da das Unternehmen nicht nur von der verbesserten Software-Infrastruktur profitiert, sondern auch von einer generellen Optimierung der Geschäftsprozesse. Wie in einem Symphonieorchester ist es kaum zu sagen, welchen Anteil die Streicher am Gesamtkunstwerk haben und welchen Anteil die Hornisten. Dennoch gibt es Schätzungen, die von einem ROI von vier Monaten bis zu zwei Jahren ausgehen.