Expert Paper. Auf dem Weg zur SOA Geschäftsprozesse als Voraussetzung. Expert Paper - September

Transkript

1 Expert Paper Expert Paper - September 2006 Auf dem Weg zur SOA Geschäftsprozesse als Voraussetzung

2 Auf dem Weg zur SOA Geschäftsprozesse als Voraussetzung Das Thema Service-orientierte Architekturen (SOA) hat in den letzten Monaten viel Beachtung gefunden. Es ist jedoch in überwiegendem Maße auf der technischen Ebene diskutiert worden. Dabei wurde die eigentliche Aufgabenstellung der IT oft aus den Augen verloren die Unterstützung der Unternehmensprozesse. In diesem ARIS Expert Paper wird dargestellt, wie aufbauend auf Geschäftsprozessen technische Service abgeleitet und im Rahmen einer SOA orchestriert werden können. Über den Autor: Hier lesen Sie: wieso eine erfolgreiche SOA Implementierung ein Management von Geschäftsprozessen voraussetzt. wie fachliche Prozessmodelle zu technischen BPEL- Prozessen umgewandelt werden können. BPM + SOA = Agilität Der Erfolg eines Unternehmens wird immer mehr dadurch bestimmt, wie schnell es auf geänderte Marktbedingungen mit adäquaten Produkten und Dienstleistungen reagieren kann. Viele Unternehmen nutzen zur Steigerung ihrer Handlungsagilität bereits ein aktives Geschäftsprozessmanagement. Während die fachliche Beschreibung bzw. Anpassung der Geschäftsprozesse mittels spezieller Prozessdesign- und Analysetools deutlich beschleunigt werden kann, kommt 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 es bei der Umsetzung der Geschäftsprozesse in die unterstützende IT-Landschaft zu teilweise erheblichen Verzögerungen. Die in den letzten Jahren propagierte feste Verzahnung von Anwendungen und Prozessabläufen auf einer zentralen monolithischen Applikationsstruktur lässt sich nur unter erheblichen Zeit- und Kostenaufwänden modifizieren. Fehlende Dokumentationen und intransparente IT-Landschaften tragen ihr Übriges dazu bei, dass sich die IT eher zum Bremser als zum Beschleuniger entwickelt hat. Der Markt für betriebswirtschaftliche Anwendungssoftware steht nicht zuletzt deshalb vor einem technologischen Paradigmenwechsel. Service-orientierte Architekturen (SOA) sollen den Einsatz und den Nutzen von Software in den Unternehmen revolutionieren. Der Traum von einer Software, die eine agile Unternehmenssteuerung unterstützt, soll so Realität werden. Bis zum Jahr 2010 werden laut Prognose der Analysten von Gartner Group mindestens 65 Prozent der großen Unternehmen mehr als 35 Prozent ihres Anwendungsportfolios auf eine Service-orientierte Architektur umgestellt haben (Applied SOA: Best Practices From the Best Practitioners, Massimo Pezzini Gartner Symposium ITXPO 2005, 7-11 November 2005, Cannes, Franced). Die weltweit größten Unternehmen erwarten in den kommenden fünf Jahren Einsparungen von bis zu 53 Mrd. US-Dollar durch SOA, wie die Aberdeen Group in einem aktuellen IT Benchmark Report prognostiziert (Fontanella, John; Saia, Rick: The SOA in IT Benchmark Report; Dezember 2005; Aberdeen Group). Ein weit verbreiteter Irrglaube ist jedoch, dass SOA zum einen gleichbedeutend mit Web Services und zum anderen als Produkt käuflich erwerbbar ist. Das Gegenteil ist der Fall. Denn SOA ist in erster Linie ein Management- und Architekturkonzept, das eine IT-Infrastruktur fordert, die flexibel auf veränderte Anforderungen im Unternehmensumfeld reagiert. Das zugehörige Systemarchitektur-Konzept zerlegt die Unternehmenssoftware in fachliche Funktionseinheiten, welche durch kleine Softwarebausteine ausgeführt werden. 2 IDS Scheer AG September 2006

3 Diese Funktionsbausteine können durch modellgestützte Konfiguration ohne größere Programmieraufwände an die unternehmerischen Anforderungen flexibel angepasst werden. Wenn diese fachlichen Funktionseinheiten durch entsprechende Standard-basierte Technologien (WSDL, UDDI, SOAP, BPEL ) automatisiert werden, bezeichnet man diese als Services. Während eine SOA die technologische Basis für die Realisierung eines agilen Unternehmens ist, wird sehr schnell klar, dass neben der reinen Diskussion um die technologische Umsetzung auch der fachliche Bezug eine stärkere Rolle spielt. Wo bisher standardisierte Prozesse als integrierte Funktionalität einer Standardsoftware ausgeliefert wurden, können nun diese Prozesse wesentlich flexibler gestaltet werden und somit natürlich auch enger an der Unternehmensstrategie ausgerichtet werden. Aus diesem Grund ist das Geschäftsprozessmanagement oder Business Process Management (BPM) eine wesentliche Voraussetzung zur Übersetzung fachlicher Anforderungen aus Sicht der Unternehmenssteuerung in die IT-Systeme. Von wachsender Bedeutung ist in diesem Zusammenhang auch die XML-basierte Sprache BPEL (Business Process Execution Language), mit der sich technische Services zu komplexeren Geschäftsprozessen kombinieren bzw. orchestrieren lassen. Da der fachliche Leistungsumfang von Aktivitäten und deren zeitlich-logischer Ablauf durch Prozesse definiert werden, ist ein Geschäftsprozessdesign für die erfolgreiche Entwicklung einer technischen Service-Architektur von essentieller Bedeutung. Die fachliche Prozessbeschreibung bestimmt auch die Granularität der zu verwendenden oder zu entwickelnden Services und beantwortet somit die erste große Frage auf dem Weg zur SOA: Wie müssen technische Services geschnitten sein?. Die fachlichen Prozessanforderungen sind die Leistungsbeschreibungen der technischen Services. Ein fachliches Business Process Managmement ist somit die Grundlage für den Entwurf und die Implementierung einer SOA. Revolutionär ist der Effekt, den SOA in Zusammenarbeit mit BPM für den Umgang mit Anwendungs-Software bedeutet. Denn die Kombination von BPM und SOA schließt die Kluft zwischen den Geschäftsprozessmodellen der Fachabteilungen und den Diagrammen der IT-Abteilungen. Durch die Zusammenführung beider Welten erfolgt die Anpassung, Optimierung und Steuerung der physischen Abläufe in den Softwaresystemen aus der betriebswirtschaftlichen Perspektive. Aus dem Geschäftsprozessmodell heraus werden die entsprechenden technischen Services identifiziert und gegebenenfalls neu kombiniert. SOA schafft die technischen Voraussetzungen für die Integration und Kooperation von Prozessen über IT-Systemgrenzen hinweg. BPM verhilft der Zusammenarbeit der Services zur höchsten Effizienz und Effektivität. Integration des SOA-Konzeptes in den Business Process Management Lifecycle Wie in Abbildung 1 dargestellt, besteht erfolgreiches Business Process Management aus vier Schritten. Aufbauend auf der Business Process Strategy (Strategiefindung) erfolgen Design (Prozessmodellierung), Implementierung (Überführung in IT) und Controlling (Messung und Bewertung) von Geschäftsprozessen. Das Management von Geschäftsprozessen darf jedoch keine einmalige Aktivität darstellen. Mittelfristig bringt nur ein kontinuierlicher und in sich geschlossener BPM-Lifecycle nachhaltige Wettbewerbsvorteile. Die Ergebnisse der Controlling Phase dienen dabei als Input für die nächste Iteration, um eine kontinuierliche Verbesserung der Geschäftsprozesse zu erreichen. Auch beim Design, der Implementierung und dem Controlling einer SOA werden alle Phasen des BPM-Lifecycles durchlaufen. Abb. 1: Business Process Management Lifecycle IDS Scheer AG September

4 1 Strategiephase Auf strategischer Ebene wird festgelegt, welche Ziele durch die gewünschten Prozessveränderungen erreicht werden sollen, z. B. Einführung neuer Produkte und Vertriebswege, Konsolidierung verschiedener Unternehmensbereiche, kürzere Prozesslaufzeiten oder die Senkung von Prozesskosten. Diese fachlichen Ziele sind in dieser Phase des BPM Lifecycles noch unabhängig von deren Umsetzung in der IT. Ohne eine klare unternehmerische Zielsetzung wird es später jedoch schwer fallen, konkrete prozessbasierte Ziele abzuleiten. Diese sind wiederum die Grundlage für eine technische Unterstützung der fachlichen Prozesse. 2 Designphase Sind die strategischen Ziele definiert, können die fachlichen Geschäftsprozesse und die unterstützende IT- Landschaft in Prozessmodellen dokumentiert werden. Im Rahmen einer SOA werden fachliche Prozesse als Service-Konsumenten und Software-Anwendungen als Service-Anbieter betrachtet. Eine konsistente Service- Architekturplanung hilft später dabei, den Einsatz redundanter Services zu vermeiden. So können Implementierungs-, Wartungs- und Pflegekosten deutlich verringert werden. Die Beschreibung der Prozesse erfolgt bereits in dieser BPM-Phase vor dem Hintergrund der zukünftigen IT-Architektur. Der Granularitätsgrad der Modellierung kann so frühzeitig mit der technischen Service-Orientierung abgestimmt werden. Durch die Ableitung technischer Prozesse aus fachlichen Prozessaufzeichnungen kann die Informationstechnologie optimal an den geschäftsspezifischen Aufgaben ausgerichtet werden. Gleichzeitig wird eine Normierung erreicht, die die spätere Ableitung und Orchestrierung der Services erleichtert. 3 Implementierungsphase In der Implementierungsphase werden basierend auf den modellierten fachlichen Geschäftsprozessen die existierenden technischen Services orchestriert. In einem ersten Schritt wird geprüft, ob es für die zu unterstützenden fachlichen Funktionsbausteine passende Services gibt. Neben der Frage nach der Granularität der Services kommt nun eine weitere große Fragestellung auf dem Weg zur SOA ins Spiel: Wie kann ich bei der großen Anzahl technischer Services den Überblick behalten und die richtigen Services für die Umsetzung der fachlichen Anforderungen identifizieren? Die Informationen zu den vorhandenen Services in einem Service- Repository sind meist technisch. Es fällt somit schwer einzuschätzen, ob der angebotene Service auch wirklich die Anforderungen der Fachbereiche erfüllt. In diesem Zusammenhang ist es von entscheidender Bedeutung, ein Service-Repository anzubieten, dass technische Service-Beschreibungen zu den fachlichen Prozessbeschreibungen in Beziehung setzt. Wird ein Service benötigt, der noch nicht von einem Hersteller angeboten wird, muss der Funktionsbaustein entwickelt werden. Bereits bestehende Artefakte können hier als Input für eine UML-basierte Service- Implementierung genutzt werden. Hier sind Ansätze wie die Model Driven Architecture (MDA) zunehmend von Bedeutung. Ein Geschäftsprozess ist in den seltensten Fällen einspurig. Meist gibt es Verzweigungen, die durch bestimmte Kriterien definiert werden. Bei einer Kreditvergabe werden so zum Beispiel die betroffenen Freigabehierarchien mit der Höhe der Kreditsumme variieren. Dementsprechend wird der Prozess einem anderen Verlauf folgen. Die möglichen Verzweigungen werden durch Geschäftsregeln definiert. Durch die explizite Definition der Geschäftregel und deren Herauslösung aus der Prozessdefinition kann bei einer Änderung der Regel der Prozess unangetastet bleiben. Geschäftsregeln bilden so ein wichtiges Werkzeug, um die Modellierung fachlicher Prozesse zu vereinfachen; gleichzeitig können sie auch als technische Services orchestriert und ausgeführt werden. Durch Wiederverwendung kann eine definierte Regel an verschiedenen Stellen im Prozessablauf Entscheidungen fällen. 4 IDS Scheer AG September 2006

5 4 Controllingphase In der Controllingphase wird die Leistungsfähigkeit der Service-orientierten Architektur im Ausführungssystem gemessen. Nur so kann geprüft werden, ob die definierten Ziele erreicht wurden. Prozessmonitoring oder Business Activity Monitoring (BAM) sind wichtig, um den Erfolg des SOA-Projektes bewerten und Schwachstellen in der IT-Architektur identifizieren zu können. Typische Messgrößen sind z. B. die Häufigkeit von Serviceaufrufen, die Dauer der Serviceausführung und die Kommunikation der Services untereinander. Die Geschäftsprozessarchitektur als Voraussetzung Geschäftsprozesse werden in der Regel in einer mehrstufigen Vorgehensweise modelliert. Ausgehend von der obersten Prozesshierarchie eines Unternehmens werden die Prozesse sukzessive detailliert. Diese Verfeinerung erfolgt meist über 3 bis 5 Hierarchieebenen. Im Rahmen des SOA-Ansatzes wird nun parallel zu der fachlichen Prozesshierarchie die technische Servicehierarchie aufgebaut. Während die fachlichen Prozesse in einem top-down Ansatz erarbeitet sind, werden die schon existierenden Services in einem bottom-up-ansatz zu technischen Prozessen orchestriert. Die Zusammenhänge zwischen den beiden Hierarchien sind in Abbildung 2 dargestellt. Die Geschäftsprozesse werden bis auf eine Granularitätsebene heruntergebrochen, in der eine fachliche Funktion durch einen technischen Service ausgeführt werden kann. Durch diese technische Anreicherung der Prozessbeschreibung, mittels einer Ereignisgesteuerten Prozesskette (EPK), kann eine automatisierte Transformation des fachlichen Prozesses in einen technischen BPEL-Prozess durchgeführt werden. Nach dem die Transformation auf Ebene 1 der rechten Pyramide in Abbildung 2 durchgeführt wurde, können diese Prozesse auf der Ebene 2 als technische Geschäfts-Services betrachtet werden. Ein Geschäfts-Service kann somit einen kontextuell abgeschlossenen Prozess aufrufen bzw. zusammenfassen. Durch diese Schachtelung von technischen Prozessen können später komplexe fachliche Prozesse ausgeführt werden. Auf Ebene 3 in der rechten Pyramide in Abbildung 2 werden alle Prozesse der Ebene 1 und 2 in einem übergeordneten Prozess kombiniert. Abb. 2: Hierarchie der Geschäfts-Services auf Basis der Hierarchie der Geschäftsprozesse Durch die enge Integration der fachlichen Prozesse und der technischen Services wird ein Hauptziel einer SOA erfüllt: die flexible und schnelle Anpassung der IT an die sich ständig ändernden Geschäftsprozesse der Organisation. IDS Scheer AG September

6 Ein Repository für Business und IT-Logik Alle beschriebenen Elemente einer SOA spielen zusammen - angefangen beim fachlichen Prozessmodell über die abgeleiteten technischen Services, die UML-basierte Service-Entwicklung, bis hin zur Regelausführung durch Business Rules Services. Wird der fachliche Prozess modifiziert, hat dies zwangsläufig Auswirkungen auf die technische Service-Orchestrierung. Werden die technischen Service-Aufrufe ungünstig verändert, wird der entsprechende Fachbereich in seiner Wertschöpfung beeinträchtigt sein. Ändern sich die Geschäftsregeln (z. B. in einer Kreditvergabe), muss dies im Prozessmodell aber auch in der technischen Ausführung angepasst werden. Zeitliche Verzögerungen in der Synchronisation zwischen fachlichem Prozessmodell und technischen Ausführungen führen schnell zu Inkonsistenzen und damit zu wirtschaftlichen Problemen. Es bietet sich daher an, alle Elemente einer SOA in einem Repository zu konzentrieren (siehe Abbildung 3: Ein Repository für Businessund IT-Logik ). Durch die Zusammenführung der fachlichen und technischen SOA-Ebenen in ARIS werden wechselseitige Abhängigkeiten transparent und steuerbar. Per Mausklick kann herausgefunden werden, welcher Service in welchem Prozess verwendet wird. Beim Ausfall eines Services kann schnell geprüft werden, welcher Geschäftsprozess Abb. 3: Ein Repository für Business- und IT-Logik beeinträchtigt ist und wer im Fachbereich und in der IT-Abteilung benachrichtigt werden muss. In ARIS wird so ein umfassendes, semantisches Service Repository aufgebaut. Durch die weitgehend automatisierte Überführung von ARIS-Prozessmodellen in ausführbaren BPEL-Modellen wird gleichzeitig die Synchronisation zwischen fachlichem Modell und technischer Ausführungen stark vereinfacht. 6 IDS Scheer AG September 2006

7 Zusammenfassung Eine SOA beginnt und endet mit den Geschäftsprozessen eines Unternehmens. Durch die Ableitung technischer Abläufe aus betriebswirtschaftlichen Prozessstrukturen und die Verwendung eines einheitlichen Repository für Business- und IT-Logik wird die Kluft zwischen Fachbereich und IT-Abteilung geschlossen. Die Modelle auf der technischen Ebene entsprechen der programmierten Realität und führen dadurch zu einer hohen Nutzerakzeptanz. Gleichzeitig werden Unternehmen in die Lage versetzt, innovative Geschäftsstrategien und die zugrunde liegenden Prozesse schnell und flexibel zu realisieren. Literatur Von Prozessmodellen zu lauffähigen Anwendungen (2005) Agilität durch ARIS Geschäftsprozessmanagement (2006) August-Wilhelm Scheer, Wolfram Jost, Karl Wagner ARIS in IT-Projekten (2005) August-Wilhelm Scheer, Helmut Kruppke, Wolfram Jost, Herbert Kindermann Enterprise SOA Designing IT for Business Innovation (2006) Jürgen Grief Dan Woods, Thomas Mattern IDS Scheer AG September

8 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 sowohl 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 Verviel fä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 SOA0906-D-EP Copyright IDS Scheer AG, Saarbrücken, 2006 IDS Scheer weltweit: Belgien Brasilien China Deutschland Frankreich Großbritannien Japan Kanada Kroatien Luxemburg Malaisia Niederlande Österreich Polen Russland Schweden Schweiz Singapur Slowakei Slowenien Südamerika Tschechien Türkei Ungarn USA