Service Orientierte Architektur im Praxiseinsatz

Service Orientierte Architektur im Praxiseinsatz von Torsten Kalinowski Wincor Nixdorf Retail Consulting GmbH Service Orientierte Architektur (SOA) – ist das auch ein Thema, mit dem wir uns be- schäftigen müssen? Diese Frage stellen sich in letzter Zeit immer mehr IT- Verantwortliche aller Branchen. Lässt man die Frage etwas auf sich wirken, erkennt man, dass das Thema SOA durchaus an Brisanz gewonnen hat, jedoch die notwen- dige Transparenz und Aufklärung noch weitgehend fehlt. Es ist sehr positiv zu bewerten, dass sich IT-Verantwortliche mit SOA auseinander- setzen, doch SOA ist kein reines IT-Thema. Die IT spielt die Rolle des Technologie- providers, SOA muss jedoch vom Management getragen und im ganzen Unterneh- men gelebt werden. Schließlich ist SOA kein Produkt das man kaufen kann, sondern Teil eines Umdenkungsprozesses. Dieses Umdenken soll dazu führen, auch zukünftig flexibel im Unternehmen zu agie- ren und neue Geschäftsanforderungen umzusetzen. Um dies zu realisieren, ist es notwendig, vorhandenes Abteilungsdenken und IT-Modulgrenzen aufzuweichen. Es muss verstanden werden, dass die IT zukünftig dazu in der Lage sein wird, aus Ge- schäftsanforderungen resultierende Prozesse weitestgehend zu realisieren. Hierbei wird es egal sein, in welchem System ein Prozess beginnt und in welchem System ein Prozess endet. So kann es durchaus sein, dass eine Planung, die im Data Ware- house durchgeführt wird, zu einer Beschaffung im ERP-System führt. Dieser Prozess muss jedoch damit nicht zu Ende sein, denn der externe Lieferant kann ebenfalls integriert werden. Die Diskussion um Frontends wird es nicht mehr geben, denn die Darstellung wird durch die Anforderungen und Gewohnheiten der Anwender bestimmt. Um dies zu realisieren, gilt es, die Brücke zwischen Fachbereich und IT zu schlagen und die Kompatibilität zwischen Menschen, Prozessen und IT zu schaffen. Die IT ist der Enabler der SOA Betrachtet man die Historie von IT-Systemen zur Unterstützung von Geschäftspro- zessen, so wurden diese Systeme monolithisch entwickelt. Prozesse wurden nach Abteilungen oder Fachbereichen abgebildet, wodurch sich die uns noch heute gut bekannten Softwaremodule etabliert haben. Einige Unternehmen nutzen Module unterschiedlicher Hersteller, was zu einer hete- rogenen Systemlandschaft geführt hat. Andere Unternehmen setzen auf integrierte Systeme von möglichst nur einem Anbieter. Egal welche Systemarchitektur im Un- ternehmen zu finden ist, beide sind starr, wenn es um die Anpassung von Prozessen geht. Service Orientierte Architektur im Praxiseinsatz 07.05.2008 Seite 1/4 Wie wird nun eine IT-Landschaft tatsächlich zu einem Enabler der SOA? Nachdem viele Unternehmen vor nicht allzu langer Zeit den Wechsel von serverbasierten Lö- sungen zu Client-Server-Lösungen vollzogen haben, wird ein weiterer technologi- scher Wechsel vorerst nicht wieder in Frage kommen. Somit muss die Softwarein- dustrie einen evolutionären Weg ebnen, der einen Paradigmenwechsel mit vorhan- dener Technologie umsetzbar macht. Oftmals hat sich der Eindruck manifestiert, dass eine Ablösung von heute bereits etablierten Prozessen bevorsteht: Das ist schlichtweg falsch. Diese Prozesse, die beispielsweise über einen SAP Standard ERP-Prozess ausgeliefert werden und im Unternehmen erfolgreich das Geschäftsmodell unterstützen, sollen dies auch weiter tun. Es ist nach wie vor der richtige Weg, Standardprozesse über Best-Practice Sze- narien auf dem Standard abzubilden. Die serviceorientierte Architektur soll allerdings dazu befähigen, spezielle Geschäftsprozesse, welche in keinem Standard zu finden sind, abbilden zu können - und das über Modul- und Systemgrenzen hinweg. Die technologische Hilfestellung wird durch die SOA gegeben. Die grundsätzliche Idee von SOA ist es, einzelne Funktionalitäten in Services zu kapseln und diese Ser- vices für die externe Nutzung bereitzustellen. Das Kapseln geschieht in den Syste- men wie beispielsweise dem ERP-System selbst. Diese Services können nun über diverse Tools miteinander zu Prozessen zusammengefügt werden. Das Zusammen- fügen von Services nennt man Komponieren und somit das Ergebnis eine Komposi- tion oder ein Composite. Evolutionärer Wechsel – leicht gemacht Die SAP AG hat mit ihrem Konzept ein sehr gutes Beispiel gegeben, wie der evoluti- onäre Wandel stattfinden kann. Zuerst wurden die diversen Anwendungssysteme auf eine gemeinsame Basis gehoben - den Web-Application-Server. Zudem wurde ne- ben der Programmiersprache ABAP auch JAVA in die Umgebung etabliert. Durch JAVA wurde es möglich, web-basierte Technologien in SAP zu nutzen. Unter SAP NetWeaver wurde die technologische Plattform gebündelt und die Grundlage in Rich- tung Service-Enablement geschaffen. Mit der Einführung von ERP 6.0 hat die SAP AG bekannt gegeben, den Kern des Systems bis zum Jahr 2010 einzufrieren. Mit dieser Entscheidung hat man sich klar von der bis dato gültigen Softwarepolitik distanziert. In der Vergangenheit wurden neue Funktionalitäten über Releasewechsel ausgeliefert. Somit hat der Kunde sein komplettes System auf einen neuen Stand bringen müssen, was in der Regel mit einem hohen Aufwand und hohen Kosten verbunden war. Auch musste der Kunde immer den Schritt gehen, die neuen Applikationen in pro- duktiven Bereichen auch zu nutzen. Dies war nicht immer sehr beliebt, denn viele Unternehmen wollten nur in Teilbereichen neue Funktionalitäten haben und oftmals eingespielte oder für sie modifizierte Prozesse beibehalten. Mit der Stabilhaltung des Kerns wurde eine neue Releasestrategie vorgestellt. Neben den Legal Changes und Softwarekorrekturen, die weiterhin über Support-Packages Service Orientierte Architektur im Praxiseinsatz 07.05.2008 Seite 2/4 ausgeliefert werden, kommen neue Funktionalitäten über Enhancement Packages zum Kunden. Dies können beispielsweise funktionale Erweiterungen des SAP Stan- dards oder Enterprise Services sein. Die hauptsächliche Neuerung ist allerdings hierbei die Möglichkeit, dass der Kunde über das „Switch-Framework“ einzelne Funk- tionalitäten selektiv aktivieren kann. Hierdurch ist der Kunde nicht mehr gezwungen, einen kompletten Releasewechsel durchzuführen, sondern ist frei in der Entschei- dung, ob und wann er eine neue Funktionalität einsetzt. Problemlos und einfach Prozesse komponieren Parallel zur ERP-Entwicklung reift die Technologie-Plattform SAP NetWeaver zur SOA-Middleware. Das beweist unter anderem die Weiterentwicklung der SAP Exchange Infrastructure (XI) in Richtung SAP Process Integration (PI). Die SAP PI verfügt ab NetWeaver 7.1 über das Enterprise Service Repository und Registry, wel- ches als Erweiterung des Integration Repository der SAP XI zu sehen ist. Das Enter- prise Service Repository und Registry ist ein zentrales Repository, in welchem Servi- ce-Interfaces und Enterprise-Services modelliert und deren Metadaten gespeichert werden. Das Enterprise Service Repository dient hierbei für die Definition von Servi- ces und Prozessen und die Ablage von Metadaten. Die Service Registry übernimmt die Aufgabe der zentralen Servicebibliothek. Mit dem SAP NetWeaver Composition Environment (SAP NetWeaver CE) bietet die SAP die Entwicklungs-Plattform, mit der Anwender ihre eigenen Geschäftsprozesse auf SOA-Basis gestalten können. Innerhalb dieser Plattform werden unterschiedliche Entwicklungstools angeboten, die je nach dem zu entwickelnden Anwendungstyp zu unterscheiden sind. Mit dem Visual Composer wird die Möglichkeit gegeben, über ein grafisches User- Interface, Services miteinander zu kombinieren und somit einfache Composites zu bauen. Wo die grafische Programmierung nicht mehr ausreicht, bietet das Eclipse- basierte SAP NetWeaver Developer Studio weitere Möglichkeiten, um EE5 Applikati- onen zu entwickeln. Durch die Integration in die Service Registry lassen sich hier problemlos Services einbinden. Unter dem Code-Namen „Galaxy“ wird zur Zeit bei der SAP AG ein Projekt durchge- führt, in dem Business Process Management (BPM) Funktionalitäten in SAP NetWeaver Composition Environment integriert werden sollen. Über diese BPM- Tools sollen auf Basis von Enterprise Services Geschäftsprozesse modelliert, ausge- führt, verwaltet und überwacht werden können. Eines der Werkzeuge ist der „Process Composer“, welcher auf Basis der Business Process Management Notation (BPMN) Prozessmodellierung erlaubt. Die BPMN gilt seit 2006 als standardisierte grafische Beschreibungssprache, um Geschäftsprozes- se und Arbeitsabläufe modellieren zu können (www.omg.org). Durch die Integration der BPM-Tools in SAP NetWeaver, sollen diese Funktionen für die SAP Business Suite, SAP All-in-One und SAP Business ByDesign zur Verfügung stehen. Service Orientierte Architektur im Praxiseinsatz 07.05.2008 Seite 3/4 Überschaubares Risiko – ungeahnte Möglichkeiten Sollten Sie sich jetzt noch die Frage stellen, ob SOA ein Thema für Sie ist, kann die Antwort nur lauten: „Wir sind doch schon mittendrin…“. Durch die Tatsache, dass die Softwareindustrie, hier am Beispiel der SAP AG, einen evolutionären Weg in Richtung serviceorientierte Architektur ebnet, ist das Risiko als Anwender überschaubar. Als Kunde ist man nicht gezwungen, mit Biegen und Bre- chen auf eine neue Technologie zu setzen, in dem man in vielleicht vage Theorien investiert. Im Gegenteil: Die Tools, die durch eine SOA und auch durch BPM zur Ver- fügung gestellt werden, öffnen Türen im eigenen Unternehmen, von denen man vor- her nicht einmal wusste, dass es diese Türen überhaupt gibt. Service Orientierte Architektur im Praxiseinsatz 07.05.2008 Seite 4/4