Die Leistungsfähigkeit eines Unternehmens hängt laut der CEO-Studie 2006 des Herstel-lers IBM von Innovationen in den Bereichen Geschäftsmodell, Betriebsabläufe und Produkte/Services/Märkte ab. BPM umfasst die kontinuierliche Verwaltung aller ablaufenden Prozesse inklusive der Betrachtung der Schnittstellen nach außen. Zu BPM gehören die Beschreibung, die Steuerung, die Ausführung und die Überwachung aller Prozesse über ihren gesamten Lebenszyklus hinweg. Kernpunkt von BPM ist der betriebliche Prozess als "Bündel von Aktivitäten, für das ein oder mehrere Inputs benötigt werden und das für den Kunden ein Ergebnis von Wert erzeugt", wie die klassische Definition von Hammer und Champy aus dem Jahr 1995 lautet. Diese Prozesse werden im Rahmen von BPM unternehmensweit modelliert.
Noch zu viel Handarbeit
Seit vielen Jahren sind verschiedene Techniken zur Modellierung von Prozessen, wie beispielsweise EPK (Ereignisgesteuerte Prozessketten), IDEF0 (Integration Definition Language 0) oder auch Petri-Netze, bekannt und im Einsatz. Prozesse werden mit geeigneten grafischen Werkzeugen modelliert und simuliert. Die Umsetzung der modellierten Abläufe in Informationssysteme erfolgte jedoch meist manuell, also durch Auscodierung der entsprechenden Anwendung.
SOA stellt nun Standards und Technologien zur Verfügung, die eine direkte Umsetzung von grafisch modellierten Prozessen in ausführbaren Code erlauben. Allerdings sind die Mechanismen von SOA nicht für jede Art von Prozess geeignet. So stehen bis heute keine standardisierten Mechanismen zur Abbildung der menschlichen Tätigkeit im Rahmen eines Prozesses bereit. Dennoch schließt SOA die Kluft zwischen der Struktur der betrieblichen Informationssysteme und dem Geschäftsprozessmodell eines Unternehmens.
Werden nun BPM und SOA gegenübergestellt, so ergibt sich folgendes Bild (siehe Abbildung 1): Auf der Ebene der Teilprozesse sind die einzelnen funktionalen Blöcke einer betrieblichen Informationstechnologie, also die Anwendungen und Daten, zu finden. Sowohl Anwendungen als auch die Datenbereiche sind mittels standardisierter Service-Schnittstellen als SOA-Basisdienste unternehmensweit sichtbar. Die Ebene der Mikroprozesse entspricht in einer SOA einer Gruppierung von Services (Composite Service), das heißt Services, die wiederum verschiedene Basisdienste aufrufen und als Ganzes eine erweiterte funktionale Einheit darstellen. Die Ebene der Makroprozesse entspricht der Orchestrierungsschicht, die Geschäftsprozesse in einer SOA als Sequenz von Dienstaufrufen modelliert. Die Steuerung der Anwendung erfolgt über den abgebildeten Prozessfluss und dessen einzelne Schritte, Entscheidungspunkte und Verzweigungen. Die Kombination von Web-Services und Orchestrierung ist nur dann möglich, wenn der Business Layer der Anwendungen eines Unternehmens in zwei Teile aufgetrennt wird: Funktion und Ablauf. Die einzelnen Funktionen einer Anwendung umfassen die statischen Komponenten, die eine bestimmte Business Logic abbilden. Der Ablauf, also die Sequenz der Aufrufe der einzelnen Funktionen, wird getrennt gehalten. Dies ist die zentrale Basis jeder SOA.
Die technische Umsetzung
Alle großen Hersteller (etwa Microsoft, SAP, Oracle oder IBM) und die spezialisierten Hersteller wie beispielsweise BEA gehen von ein und demselben Architekturmodell für SOA aus. Dabei besteht eine grundlegende Teilung zwischen Applikationen, Diensten und einem "Orchestration Layer". Die Applikationen beinhalten bestehende oder auch neue Systeme und logische Datenspeicher. Die Dienste stellen je eine Schnittstelle zu den einzelnen Applikationen dar. Der Orchestration Layer" dient der Steuerung von Abläufen. Die Kommunikation zwischen verschiedenen Diensten und die Kommunikation zwischen Diensten und deren Implementierung (Applikation und Daten) erfolgen über eine "Integration Architecture". Die wichtigsten Instrumente zur Unterstützung von BPM durch SOA sind die Services, die Integration Architecture und die Orchestration. Der Orchestration Layer bildet die Geschäftsprozesse mittels BPEL (Business Prozess Execution Language) ab. Die Integration Architecture ist der ESB (Enterprise Service Bus), der die einzelnen Services untereinander sowie die BPEL-Prozesse mit den Services verbindet.
Die Standards zur Unterstützung von BPM durch SOA sind Web-Services, die Protokolle WSDL/SOAP und allem voran BPEL. BPEL (Business Process Execution Language) oder auch WS-BPEL für Web-Services wurde in der ersten Version von IBM, Microsoft, Siebel, BEA, SAP und Oracle im Jahr 2002 entwickelt. Die Version 1.1 wurde im April 2003 erstellt. XLANG (von Microsoft) und WSFL (von IBM) wurden in BPEL integriert und der OASIS übergeben. Im Moment wird BPEL in der Version 2.0 von der OASIS standardisiert.
Mit BPEL lässt sich ein Prozess beschreiben und abbilden. Diese Beschreibung erfolgt grafisch mittels eines BPEL-Editors. Dies ist jedoch auch mit anderen Workflow-Modellierungstechniken möglich. Im Unter-schied zu den anderen Techniken kann aus dem modellierten Geschäftsprozess direkt die Steuerung der Workflow Engine (BPEL Engine) erzeugt werden. Mittels BPEL lassen sich verschiedene Dienste zu einer Gesamtanwendung verknüpfen.
Zwei Arten von Prozessen
BPEL unterscheidet zwei Arten von Ge-schäftsprozessen, die Geschäftsprotokolle (Business Protocols) und die ausführbaren Geschäftsprozesse (Executable Business Processes). Geschäftsprotokolle sind abstrakte Prozessbeschreibungen, die als Interaktionsmuster für die ausführbaren Geschäftsprozesse dienen. Ein BPEL-Prozess besteht aus einem Prozess-Interface und einem Prozess-Schema. Das Prozess-Interface ist in WSDL formuliert, da jeder BPEL-Prozess für sich selbst einen Web-Service darstellt. Das Prozess-Schema definiert den eigentlichen Prozessablauf (Actions), die Art und Weise der Instanziierung (Correlation Sets), die involvierten Partner (Partner Link) und die Mechanismen der Fehlerbehandlung (Fault Manager).
Die Modellierung von Prozessen in einer SOA mittels BPEL unterscheidet sich nicht von den üblichen BPM-Modellierungstechniken. Die Einschränkung von SOA gegenüber BPM erfolgt erst auf der Ebene der Ausführbarkeit. SOA versteht einen Prozess als automatisierbaren Prozess. Dies ist gemäß der Workflow Management Coalition (WFMC) die Definition eines Workflows. In diesem Sinne dient ein BPEL-Prozess der Bearbeitung eines Geschäftsfalles, der durch Bedingungen die Reihenfolge der Aufgaben festlegt.
Gemäß WFMC können diese Bedingungen wahr oder falsch sein. Eine Aufgabe hat Vorbedingungen (Anforderungen für die Weiterleitung eines Falles, die erfüllt sein müssen) und Nachbedingungen. Fälle sollten so effektiv und effizient wie möglich behandelt werden (maximaler Kundennutzen). Sie werden bearbeitet, indem Aufgaben in einer bestimmten Reihenfolge ausgeführt werden (Routing von Fällen). Genau diesem Paradigma folgt BPEL.
Die Strukturierung eines Prozesses erfolgt mittels einer Kombination aus hierarchischen Blöcken und Graphen. Die hierarchischen Blöcke können verschachtelt werden. Sie sind in BPEL als strukturierte Aktivitäten formuliert, die den Konstruktionen einer strukturierten Programmiersprache ähneln. Eine typische Ausprägung ist die strukturierte Aktivität <switch>, die eine bedingte Ausführung definiert. Strukturierte Aktivitäten kontrollieren den Fluss von atomaren Aktivitäten und bilden so die Knoten eines Ausführungsbaums. Die atomaren Aktivitäten steuern den einzelnen Schritt eines BPEL-Prozesses; so ruft beispielsweise <invoke> einen Web-Service auf. Das Durchlaufen eines Prozesses als ein Durchlaufen eines Graphen wird durch die strukturierte Aktivität <flow> ermöglicht, die eine parallele, serielle oder beliebige Abfolge definiert. Asynchrone oder synchrone Kommunikation und andere Abhängigkeiten werden über die <flow>-Attribute "source", "target" und "joinCondition" festgelegt.
Es menschelt zu wenig
Die meisten großen Hersteller bieten BPEL-Modelling-Tools und BPEL-Engines an. Zwei Schwachpunkte hat BPEL jedoch: die mangelnde Unterstützung der Ausführung von Prozessschritten durch den Menschen und die fehlenden Elemente für das Management ganzer Geschäftsprozessmodelle. Fast jeder Hersteller bietet Mechanismen für die "Human Interaction" an. Dies sind proprietäre Erweiterungen von BPEL, die es erlauben, Aufgabenlisten mit den entsprechenden Arbeitsanweisungen zu generieren und am Bildschirm darzustellen. In einem Joint White Paper von IBM und SAP wird versucht, die entsprechenden Erweiterungen zu formulieren. "WS-BPEL Extentsion for People" (BPEL4People) erweitert BPEL mit einer Reihe von "Human Interaction Features". Die fehlenden Elemente für das Management ganzer Geschäftsprozessmodelle werden durch Organisationen wie beispielsweise der BPMI (Business Process Management Initiative), der OMG oder der BPM Group erarbeitet. Sie stellen Standards wie die Business Process Modeling Notation (BPMN) oder das Business Motivation Model (BMM) bereit.
Die Umsetzung von BPM wird durch SOA überhaupt erst strukturiert und standardisiert möglich. Ein Task eines Geschäftsprozesses ist nichts anderes als ein Aufruf einer Business-Funktion, die durch den entsprechenden Web-Service standardisiert und unternehmensweit zugänglich ist. Der Prozess selbst wird als Workflow mittels BPEL modelliert und mittels einer BPEL Engine ausgeführt. Damit setzt SOA das bereits 1995 von der Workflow Management Coalition (WFMC) definierte "Workflow Reference Model" mit den grundlegenden Standards Web-Services, WSDL, SOAP und BPEL vollständig um. Jeder Hersteller einer SOA-Suite wie IBM, SAP, Bea, Oracle und Microsoft haben die entsprechenden BPEL-Modeller und BPEL-Engines im Programm. Die Umsetzung von BPM durch SOA erfolgt mittels einer Kombination aus Orchestrierung durch BPEL, Integration über einen ESB und Verwendung von Web-Services als Standardschnittstelle für jede Anwendungslogik und jeden Datenbereich eines betrieblichen Informationssystems.
Zentrales Instrument
Trotz fehlender Standards und der damit verbundenen mangelnden Unterstützung der Ausführung von Prozessschritten durch den Menschen und der fehlenden Elemente für das Management ganzer Geschäftsprozessmodelle ist SOA das zentrale Instrument für die Realisierung von BPM.
Daniel Liebhart ist Solution Manager bei der Trivadis AG.