SOA aus dem Blickwinkel der Hersteller

EnterpriseSoftware

Dass serviceorientierte Architekturen langfristig sinnvoll sind, dürfte inzwischen bei den Anwendern angekommen sein. Doch die Frage nach der Implementation lässt Spielraum für verschiedene Interpretationen.

Serviceorientierte Architektur (SOA) bringt mit sich, dass Anwender innerhalb der Softwarelandschaft umdenken müssen. Am Ziel steht ein flexibles Gewebe, das sich nicht mehr durch die Silohaftigkeit und Lizenzproblematik in den Vordergrund schiebt, sondern sich als unterstützende Funktion ganz den betrieblichen Prozessen unterordnet. Dabei sehen die Hersteller die Einsatzmöglichkeiten nicht nur beim Kunden, sondern probieren selbst von der eigenen Medizin gegen Insellösungen im eigenen Haus. Die Einsatzbereiche lassen sich dabei gut aus der Herstellererfahrung studieren.

“Die klassische Anwendungsentwicklung ist ‘out’ – heute werden Prozesse modelliert und wiederverwendbare Services gebaut”, sagt Karin Sondermann, Platform Business Development Manager und SOA Spokesperson bei Microsoft Deutschland. Dabei werde erst der Prozess modelliert, dann der Code generiert. Microsoft nutzt die SOA also sogar für die Softwareentwicklung. Dabei fängt der Konzern auf der Geschäftsseite an. Doch Sondermann betont: “Einfach nur Geschäftsfragen in die IT zu schieben reicht nicht, dieser Versuch scheitert bereits seit mehr als 20 Jahren.” SOA sei schließlich keine Technik und schon gar kein Produkt.

Lernfähige Anwender gesucht

Zunächst müsse das ganze Unternehmen neu partitioniert werden: in Aufgaben und Entscheidungswege. Hierbei müssten Sollbruchstellen eingebaut werden. Diese wiederum seien die Stellen, an denen die Web Services oder ähnliche Trigger ansetzen können. Die Services wiederum sollten in einer möglichst flexiblen Engine verwaltet werden, die vom Business bestimmt werde. Überhaupt spricht sich Sondermann sehr für Offenheit aus.

“Kapselungen aus Legacy-Anwendungen kann es immer geben, aber dafür eignet sich beispielsweise auch die Integration mit Java-Komponenten”, sagt sie. Die Interoperabilität sei auch eine zentrale Frage des Übereinkommens zwischen Sun Microsystems, den Vätern von Java, und Microsoft vor einigen Jahren gewesen. Doch egal wie sich die Unternehmen entscheiden, sie hält die alte Art, Software zu bauen, für passé. Und sie macht SOA dafür verantwortlich, dass sich hierbei etwas Grundlegendes verändert hat.

“Wer IT-Schnittstellen unterstützt und verwaltet, tut nichts als neuen Spaghetti-Code zu generieren, über den wir schon seit Jahrzehnten stolpern – SOA ist mehrdimensional”, so Karin Sondermann. Sie verweist darauf, dass Microsoft die Partitionierungs-Methodik ‘Motion’ am eigenen Leib ausprobiert habe und die eigenen Tools für SOA-Prozesse verwende. Die Prozesse seien in BPEL-Dialekten vorhanden. Die Business Process Execution Language (BPEL) ist heute einer der wenigen gemeinsamen Nenner, die die Hersteller vorweisen können. Und dafür gibt es Gründe, denn die Frage, wie eine ganze Firma komplett auf SOA-Kurs kommt, ist laut Sondermann “wie einen Öltanker auf offener See zu wenden”. Echte Referenzen dafür gibt es erst wenige. Doch die Ideen der Hersteller nehmen bereits Formen an.

Logik des Firmenalltags

Ein Ansatz, der die SOA etwas weiter fasst, kommt von SAP. Wie Vorstandssprecher Henning Kagermann auf der Jahreshauptversammlung im Mai 2006 vor Aktionären sagte, habe die SAP “bereits vor Jahren begonnen, in eine neue Softwarearchitektur zu investieren. Wir nennen sie Enterprise Service Architecture, kurz genannt: ESA. Sie beruht auf dem Prinzip der Serviceorientierung.” Darunter wiederum versteht die SAP ein Organisationsprinzip, nach welchem Funktionen, die in verschiedenen Anwendungen gebraucht werden (beispielsweise das Finden eines Preises) nur einmal realisiert werden, jedoch mehrmals nutzbar sind – über Technik- und Abteilungsgrenzen hinweg.