Expert Paper. In 10 Schritten zur Business-Driven SOA. Expert Paper - Januar

Transkript

1 Expert Paper Expert Paper - Januar 2007 In 10 Schritten zur Business-Driven SOA

2 In 10 Schritten zur Business-Driven SOA SOA benötigt BPM hier sind sich die Experten einig. Was jedoch genau Business Process Management (BPM) umfasst, ist schon umstrittener. Viele sehen in BPM die alleinige Orchestrierung von Services zur technischen Abbildung betriebswirtschaftlicher Abläufe. Diese IT-zentrierte Sichtweise betrachtet jedoch nur die technische Architektur einer SOA. Woher weiß der IT-Mitarbeiter jedoch, wie die technischen Prozesse geschnitten sein müssen, damit der Fachbereich optimal unterstützt wird? Schon anhand dieser Fragestellung wird deutlich, warum ein alleiniges technisches BPM für eine erfolgreiche SOA-Implementierung nicht ausreichend sein kann. In diesem ARIS Expert Paper wird dargestellt, wie mit Hilfe einer 10 Schrittmethodik fachliche Geschäftsprozesse als Blaupause für eine SOA verwendet werden können. Durch diese betriebswirtschaft - liche Perspektive kann die zukünftige IT-Architektur frühzeitig an den gegebenen betriebswirtschaftlichen Abläufen ausgerichtet werden. Hier lesen Sie: wie Sie basierend auf fachlichen Abläufen Services zur Automatisierung identifizieren können. wie Sie Ereignisgesteuerte Prozessketten automatisch zu BPEL-Prozessen umwandeln können. warum ein zentrales SOA Repository notwendig ist, um die Vorteile einer SOA realisieren zu können. Über den Autor: Jörg Klückmann ist bei der IDS Scheer AG für das internationale Produktmarketing rund um die ARIS Implementation Platform verantwortlich. joerg.klueckmann@ids-scheer.com Warum braucht SOA ein fachliches BPM? Geschäftsprozessmanagement wird in Unternehmen unter verschiedensten Zielsetzungen betrieben. Es sollen Ab läufe optimiert, die Einhaltung gesetzlicher Regularien geprüft oder die Leistungsfähigkeit der in IT- Systemen ausgeführten Prozesse sichergestellt werden. In jedem Fall wird jedoch auch die Funktionsweise der Organisation dokumentiert. Jeder aufgezeichnete Prozess schafft mehr Transparenz in der unternehmerischen Wert schöpfung. Oft werden erst nach der Modellierung von Prozessen Optimierungspotenziale sichtbar. Die IT hat die Aufgabe, die optimierten Prozesse schnell in die IT-Landschaft zu übertragen. Geschieht dies mit Tech - no logien wie WSDL, BPEL, SOAP etc. spricht man von einer Service-orientierten Architektur. SOA ist kein Produkt und auch nicht mit Web Services gleichzusetzen. Im Gegenteil SOA ist in erster Linie ein Managementkonzept. Das zugehörige Systemarchitekturkonzept zerlegt Unternehmenssoftware in Funktions - einheiten, die durch kleine Softwarebausteine ausgeführt werden. Diese Funktionsbausteine können durch mo dell gestützte, standard-basierte Konfiguration an die unternehmerischen Anforderungen angepasst werden. 2 IDS Scheer AG Januar 2007

3 Auch wenn diese Konfiguration technologisch unterstützt wird, stellen sich für viele SOA-Architekten die folgenden typischen Fragen: Welche Services benötigen meine Fachbereiche zur Verrichtung der alltäglichen Arbeitsabläufe und wie finde ich diese? In welcher Reihenfolge werden welche Services nachgefragt? Welche Response-Zeiten sind für den Fachbereich notwendig? Gibt es kritische Services, die besonders abgesichert werden müssen? Woher weiß ich, wann sich ein fachlicher Prozess ändert und wie wirkt sich dies auf die ausgeführten BPEL-Prozesse aus? Welche fachlichen Prozesse sind betroffen, wenn ich einen bestimmten technischen Prozess modifiziere? Auf jede dieser Fragestellungen bietet ein fachliches BPM mit ARIS eine eindeutige Antwort. Ausschlaggebend ist hier natürlich die Qualität der modellierten Prozesse. Die Methode für ein Service-orientiertes BPM Meistens werden Geschäftsprozesse in Unternehmen in einer mehrstufigen Vorgehensweise modelliert. Aus - gehend von der obersten Prozesshierarchie werden die Prozesse sukzessive detailliert. Im Rahmen des SOA- Ansatzes der IDS Scheer wird parallel zu der fachlichen Prozesshierarchie die technische Service-Hierarchie aufgebaut. Während die fachlichen Prozesse in einem Top-down Ansatz erarbeitet sind, werden die Services in einem Bottom-up-Ansatz zu technischen Prozessen orchestriert. Die Geschäftsprozesse werden in der linken Pyramide in Abbildung 1 bis auf Ebene drei detailliert. Auf dieser Ebene kann ein Mapping von fachlicher Funktion und geeignetem Service durchgeführt werden. Durch diese technische Anreicherung der Ereignisgesteuerten Prozesskette (EPK) kann eine automatische Transformation des fachlichen Prozesses in einen BPEL-Prozess durchgeführt werden. Nachdem die Transformation auf der untersten Ebene von der linken zur rechten Pyramide stattgefunden hat, können die BPEL-Pro - zesse auf Ebene zwei in der rechten Pyramide als umfassendere Geschäfts-Services kombiniert werden. Ein Geschäfts-Service kann einen kontextuell abgeschlossenen Prozess der Ebene eins aufrufen, beziehungsweise diesen in einem Service zusammenfassen. Durch diese Schachtel ung von technischen Prozessen können später komplexe fachliche Prozesse mit Hilfe von Geschäfts-Services ausgeführt werden. Auf Ebene drei der rechten Pyramide werden alle Prozesse in einem übergeordneten BPEL-Prozess kombiniert. Durch die enge Inte - Abb. 1: Hierarchie der Geschäfts-Services auf Basis der Hierarchie der Geschäftsprozesse gration der fachlichen Prozess - abläufe und der technischen Service-Orchestrierung wird die Business-Driven SOA Wirklichkeit. Zur erfolgreichen Einführung einer Business-Driven SOA basierend auf fachlichen Prozessmodellen, empfiehlt die IDS Scheer eine 10-Schritt-Methodik, unterstützt durch den ARIS SOA Architect. IDS Scheer AG Januar

4 Abb. 2: 10 Schritte vom fachlichen Prozess zur Business-Driven SOA In 10 Schritten vom fachlichen Prozess zur Ausführung Schritt 1: Service-orientierte Prozessmodellierung In der ersten Phase werden die übergeordneten fachlichen Prozessmodelle erstellt, die meist noch nicht zur Ausführung bestimmt sind. Ausgehend von diesen High-Level Prozessen, erfolgt die service-orientierte Prozessmodellierung schrittweise in einem Top-down Ansatz. Durch die Aufnahme der Prozesse wird ersichtlich, welche Eigenschaften Services aufweisen müssen, um die definierten fachlichen Aktivitäten später technisch unterstützen zu können. In Abbildung 3 ist ein einfacher Sales-Prozess in einer EPK dargestellt. Das Pro zess modell beinhaltet unter anderem den Schritt Plan Production (Pro duk tions - planung). Dieser Funktions - baustein soll mit Hilfe des ARIS SOA Architect durch einen Service automatisiert werden. Die fachliche Aktivität ist durch Inund Output-Daten und ein Re - quire ment genauer beschrieben. Im Bei spiel hat der Prozessschritt als Input-Datum die Purchase Order (Bestell anfor der ung) und als Output den Sche dule (Pro- duktionsplan). Die IS Function Calculates Schedule beschreibt als Requirement die vollzogene Aktivität. Requirements bieten die Abb. 3: Ereignisgesteuerte Prozesskette (EPK) Möglichkeit, Services bezüglich ihres Einsatzgebietes zu ordnen und zur Wiederverwendung zur Verfügung zu stellen. 4 IDS Scheer AG Januar 2007

5 Schritt 2: Import und Beschreibung der Services Durch den Import von WSDL-Dateien können Beschreibungen von Services in ARIS zur Ver - fügung gestellt werden. Schon während des Imports kann der Service semantisch beschrieben werden. Dazu werden die Ser vices in Funk - tions cluster eingeordnet. In Abbildung 4 wird die Beschreibung des Service scheduling.wsdl in ARIS importiert. Zusätzlich zur Clusterzuordnung werden ein fachliches und ein technisches Diagramm aus der Service-Beschreibung generiert. Das fachliche Zugriffsdiagramm visualisiert die Schnittstelle zwischen fachlicher und technischer Service- Beschreibung. Das technische Komponenten - diagramm stellt die technischen Details wie Abb. 4: Service Import Dialog Operationen, Datentypen und Interfaces des Service UML-konform dar. Schritt 3: Ergänzungen des Prozesses um Services Die rein technische Service-Definition aus Schritt 2 (Interfaces, Operationen, Parameter, Messages, Datentypen) machen es den Mit arbeitern eines SOA-Projektteams schwer, passende Services zur Auto - matisierung von Pro zessen zu identifizieren. ARIS SOA Architect bietet daher ein automatisiertes Mapping von Prozessaktivität und geeignetem Service, basierend auf den fachlichen Requirements bzw. der Datenmodellierung in ARIS und den technischen Service-Beschreibungen der WSDL-Datei. Anhand der In- und Output-Daten und / oder des Requirement des Prozessschrittes Plan Pro - duction in Abbildung 3 kann ein geeigneter Service, soweit dieser vorhanden ist, leicht identifiziert werden. Per Mausklick auf die zu automatisierende Aktivität im Prozessmodell wird dem Benutzer der passende Service automatisch angezeigt. Abbildung 5 zeigt den semantischen Service Browser des ARIS SOA Architect. Der passende Service Scheduling wird dem Benutzer im Browser angezeigt. In diesem Menü kann der Service vom Anwender weiter be - schrieben werden. Wird kein entsprechender Abb. 5: Service Browser Service gefunden, kann die Prozessdefinition angepasst, ein existierender Service modifiziert oder ein neuer Service implementiert werden. In letzterem Fall wird mit dem in ARIS SOA Architect integrierten ARIS UML Designer ein Werkzeug zur Service-Definition bereitgestellt. Diese Spezifikation stellt dann die Grundlage für die Neuentwicklung des noch fehlenden Service dar. Im Geschäftsprozess sind nun die fachlichen Aktivitäten mit den zugehörigen Services verbunden. Es muss darauf geachtet werden, dass jede zu automatisierende Aktivität durch einen Service abgedeckt wird. Gleichzeitig sollten Prozesse, die in einem Service einer höheren Hierarchiestufe abgebildet werden, einen konkreten Geschäftsvorgang umsetzten. Dabei darf die Detaillierungsstufe weder zu niedrig (zu hohe Kom - plexi tät) noch zu hoch (zu geringe Flexibilität) sein. Das Augenmerk sollte immer auf der Wiederverwendbarkeit des Service liegen. IDS Scheer AG Januar

6 Das Objekt Scheduling in Abbildung 6 re präsentiert den Service, der den Pro zess schritt Plan Production automatisieren wird. In hinterlegten UML-Dia - grammen ist der Service weiter spezifiziert. Abb. 6: Service im Prozessmodell Schritt 4: Umwandlung des Prozesses in technischen Ablauf Nachdem die Ereignisgesteuerte Pro zesskette durch die technischen Services angereichert wurde, kann nun die Trans formation zum BPEL-Prozess erfolgen. Diese Überführung ist notwendig, da die Ausführung eines Prozesses in einem IT-System zusätzliche technische Informa tionen erfordert, die dem fachlichen Pro zess fehlen. Es wird da bei nicht nur der Ablauf des Geschäfts prozesses übertragen, sondern auch die bereits enthaltenen Service-Infor mationen. Gleich zeitig fallen fachliche Prozess inhalte weg, die für die technische Ausführung irrelevant sind. Abbildung 7 zeigt den aus der EPK in Ab - bildung 3 generierten BPEL-Prozess. Die grafische BPEL-Modellierungsnotation ist Bestandteil des ARIS SOA Architect. Das Invoke-Element Plan Production ist mit einem BPEL-Allocation Diagramm hinterlegt, in dem der Aufruf des Service Scheduling weiter spezifiziert ist. Die anderen Invoke-Elemente stellen Ser - vice-aufrufe dar, welche weitere Prozess aktivitäten der EPK ausführen. Abb. 7: Automatisch generierter BPEL-Prozess 6 IDS Scheer AG Januar 2007

7 Im BPEL-Allocation Diagramm in Ab - bildung 8 sieht man die Ein- und Aus - gabe variablen sowie die aufgerufene Operation des Service. Abb. 8: BPEL-Allocation Diagramm Schritt 5: Vervollständigung des Service-Designs Methodisch ist es nicht immer möglich, alle für einen ausführbaren BPEL-Prozess notwendigen Konstrukte in einer EPK zu modellieren. Das fachliche Prozess modell dient der Beschreibung der Ab läufe im Fachbereich. Technische Details wie Exceptions oder Correlation Sets sind auf dieser Ebene nicht angemessen. Deshalb erfolgt deren Mo - dellier ung ausschließlich in der technischen Sicht im BPEL-Modell. ARIS SOA Architect bietet umfang - reiche Funktionalitäten zur Unter stützung der technischen Verfeiner ungen. So wird zum Beispiel der Inhalt des Prozesses als Baum - struktur in einem spezifischen BPEL-View dargestellt. Mit dem Operation Chooser Dialog in Ab - bildung 9 kann man für einen Service-Aufruf die gewünschte Operation komfortabel auswählen. Am Ende dieses Schrittes steht eine ausführbare technische Beschreibung des Geschäftsprozesses. Abb. 9: Vervollständigung der BPEL-Modellierung IDS Scheer AG Januar

8 Schritt 6: Export des Service-Designs Der grafische BPEL-Prozess wird in eine XML- Datei exportiert. Gleichzeitig wird eine WSDL- Datei erzeugt, die den erstellten Service be - schreibt. Durch die in der WSDL-Datei enthaltenen Informationen steht der BPEL-Prozess in ARIS sofort als wieder verwendbarer Prozess - baustein zur Verfügung. Damit garantiert der ARIS SOA Architect das wichtigste Erfolgs - kriterium einer SOA die Wieder ver wendung von Services. Beide Dateien können zur Ausführungs - plattform übertragen werden. In Abbildung 10 sieht man den aus ARIS exportierten BPEL- Code in der standardkonformen XML-Syntax. Durch die Unterstützung von Standards können die in ARIS erstellten technischen Pro - zesse auf allen gängigen Integrations- und Applikationsplattformen ausgeführt werden. Abb. 10: BPEL-Code Schritte 7-10: Ausführung des Service Die gängigen Integrations- und Applikationsplattformen haben in den letzten Jahren spezifische Erweiterungen des BPEL-Standards eingeführt. Diese müssen in das technische Prozessdesign aufgenommen werden. In ARIS wurden diese Plattformspezifika bewusst nicht modelliert, da das SOA-Design plattformunabhängig stattfinden sollte. Dies bietet u. a. den Vorteil, dass nach einem Plattformwechsel die modellierten Inhalte weiterhin zur Ausführung gebracht werden können. Sowohl auf Software-Ebene als auch auf Prozessebene müssen die neuen Services nun realisiert werden. Abschließend werden Test- und Fehlerbehebungsaktivitäten durchgeführt. Der Geschäfts-Service ist nun für die Ausführung bereit. Ein zentrales SOA-Repository schafft Transparenz Werden unterschiedliche Repositories für betriebswirtschaftliche und technische SOA-Elemente verwendet, wird es schwer die Vorteile einer SOA zu erschließen. Intransparenz, mangelnde Wiederverwendbarkeit und dadurch hervorgerufene Kostensteigerungen sind die Folge. Deswegen empfiehlt IDS Scheer die Nutzung von ARIS als zentrales SOA-Repository. Mit ARIS sind zu jeder Zeit alle wechselseitigen Abhängigkeiten zwischen fachlichen und technischen SOA-Elementen transparent. Per Mausklick kann herausgefunden werden, welcher Service in welchem fachlichen Prozess verwendet wird. Beim Ausfall eines Service kann schnell geprüft werden, welcher Geschäftsprozess beeinträchtigt ist und wer im Fachbereich und in der IT-Abteilung benachrichtigt werden muss. Ändern sich fachliche Abläufe durch Markteinflüsse können die betroffenen technischen Prozesse schnell modifiziert werden. Mit der weitgehend automatisierten Überführung von ARIS- Prozessen zu ausführbaren BPEL-Prozessen wird gleichzeitig die Synchronisation zwischen fachlichem Modell und technischer Ausführungen stark vereinfacht. ARIS hilft somit, eine transparente Prozesslandschaft des Unternehmens aufzubauen. Durch die Vermeidung von Redundanzen und die Erreichung einer hohen Wieder - verwendungsrate können Kosten reduziert und Schwachstellen in den technischen Prozessen identifiziert werden. Mit ARIS können so die Vorteile einer Business-Driven SOA in der Realität eingelöst werden. 8 IDS Scheer AG Januar 2007

9 Fazit Eine SOA kann nicht Service-orientiert sein, wenn die zu unterstützenden fachlichen Prozesse unbekannt sind. Ohne das Wissen um die Abläufe der Fachbereiche ist die Chance hoch, dass die Fehler in der betriebs wirt - schaft lichen Softwareentwicklung der 80er und 90er Jahre wiederholt werden. Starre und an den Be dürf - nissen der Anwender vorbei entwickelte IT-Systeme bedeuten eine vorprogrammierte Lähmung der unter - nehmerischen Wertschöpfung. Eine SOA soll genau dieser Entwicklung entgegentreten. Dafür benötigt eine SOA ein fachliches BPM, denn das SOA-Design bestimmen nicht orchestrierte Services, sondern die realen Geschäftsprozesse. Dies ist auch der Grund, warum führende Softwarehersteller wie SAP, Oracle, Fujitsu, Tibco und die Software AG die Tools der ARIS Platform nutzen, um ihre Produkte optimal an die Prozesse von Unternehmen anzupassen. Weitere Informationen finden Sie unter: Literatur: Von Prozessmodellen zu lauffähigen Anwendungen (2005) Business Process Modelling with ARIS 7: Getting Started with BPM (2007) August-Wilhelm Scheer, Wolfram Jost, Karl Wagner ARIS in IT-Projekten (2005) Rob Davis, Eric Brabänder Enterprise SOA Designing IT for Business Innovation (2006) Jürgen Grief Dan Woods, Thomas Mattern IDS Scheer AG Januar

10 Firmenzentrale: Deutschland IDS Scheer AG Altenkesseler Straße Saarbrücken Telefon: +49 (0) Telefax: +49 (0) Das Software- und Beratungshaus IDS Scheer (Saarbrücken) ist der führende Lösungsanbieter für Geschäftsprozess - management und IT. Mit ARIS bietet IDS Scheer ein integriertes und vollständiges Werkzeug-Portfolio für Business Process Excellence ; es umfasst Methoden, Software und Lösungen für Design, Implementierung und Controlling von Geschäftsprozessen. Im Rahmen der kontinuierlichen Weiterentwicklung des Portfolios wurden alle Produkte der ARIS- Familie in der ARIS Platform for Process Excellence gebündelt, darunter mehrere Neuentwicklungen. Die Plattform ist so wohl technisch als auch fachlich hochgradig integriert und bietet Werkzeuge für alle Phasen des Prozesslebens - zyklus vom Design über die Implementierung bis zum Controlling. Sie stellt damit ein klares Alleinstellungsmerkmal von IDS Scheer dar und unterstützt die Kunden softwareseitig rund um den Process Lifecycle. Innerhalb der ARIS Platform for Process Excellence ist ARIS Toolset das weltweit meist verkaufte Werkzeug für die Prozessoptimierung. Eine strategische Kooperation mit SAP macht die ARIS Werkzeuge und Methoden künftig zum Standard der NetWeaver Plattform. Mit ARIS SmartPath steht ein Werkzeug zur Verfügung, das auch für mittelständische Unter - nehmen eine schnelle SAP-Einführung gewährleistet. Dank des integrierten Ansatz des ARIS Value Engineering (AVE) betrachten die IDS Scheer-Berater die Unternehmen ihrer Kunden ganzheitlich. AVE bedeutet Brücken zu bauen zwischen der Unternehmensstrategie, den daraus resultierenden Prozessen, den zur Unterstützung notwendigen IT- Lösungen und, nicht zuletzt, der Kontrolle des laufenden Betriebs. Darüber hinaus erhalten Kunden ein vollständiges, globales Service-Angebot für Outsourcing und Support. ARIS Strategy Platform ARIS Design Platform ARIS Implementation Platform ARIS Controlling Platform ARIS, IDS und das Symbol Y sind eingetragene Marken der IDS Scheer AG, Saarbrücken. SAP NetWeaver ist eine Marke der SAP AG, Walldorf. Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber. Alle Rechte vorbehalten. Der Inhalt dieses Dokuments unterliegt dem Urheberrecht. Veränderungen, Kürzungen, Erweiterungen und Ergänzungen bedürfen der vorherigen schriftlichen Einwilligung durch IDS Scheer AG, Saarbrücken. Jede Vervielfältigung ist nur gestattet unter der Bedingung, dass dieser Urheberrechtsvermerk beim Vervielfältigen auf dem Dokument selbst erhalten bleibt. Jede Veröffentlichung oder jede Übersetzung bedarf der vorherigen schriftlichen Einwilligung durch IDS Scheer AG, Saarbrücken. Bestandsnummer SOA0107-E-EP Copyright IDS Scheer AG, Saarbrücken, 2007 IDS Scheer weltweit: Belgien Brasilien China Deutschland Finnland Frankreich Großbritannien Japan Kanada Kroatien Luxemburg Malaisia Niederlande Österreich Polen Russland Schweden Schweiz Singapur Slowakei Slowenien Südamerika Tschechien Türkei Ungarn USA