BPM befindet sich in der Zielgeraden zu einer Standardtechnologie, bei der der gesamte Geschäftsprozess-Lebenszyklus methodisch definiert und in die heutige Entwicklungs- und Betriebslandschaft eingebettet ist, sowie seitens der Hersteller leistungsfähige Produkte zur Verfügung stehen. Zeit also, sich die notwendigen Zusammenhänge klar zu machen.
Die Historie – Groupware, Workflow und EAI
Kern aller Aspekte von BPM ist die Erkenntnis, dass jeder Vorgang, der durch Mitarbeiter oder IT-Anwendungen in einem Unternehmen ausgeführt wird, einem teils mehr teils weniger strukturierten Geschäftsprozess zuzuordnen ist. Dieser Geschäftsprozess dient dann der Umsetzung von Unternehmenszielen.
Um Geschäftsprozesse durch IT zu unterstützen, müssen alle Phasen des Lebenszyklus für IT-gestützte Geschäftsprozesse durchlaufen werden. Die vollständige Unterstützung dieses Lebenszyklus ist das Ziel von BPM-Systemen.
Zwei zunächst unabhängige Fragestellungen haben den Werdegang von BPM wesentlich geprägt: Workflow Management und Enterprise Application Integration (EAI).
 |
 Klicken zum Vergrößern |
| Abb. 1: Der Prozess-Lebenszyklus |
Workflow hat seine Ursprünge in den Anfängen kollaborativer Nutzung von Standardsoftware wie Mail-, Aufgaben- und Kalendarverwaltung in den 90ern. Man hatte sich gewünscht, komplexe Bearbeitungsvorgänge mit Beteiligung mehrerer Benutzer durch vorgegebene Strukturen (Workflow-Modell) reproduzierbar steuern und nach verfolgen zu können. Da Kern solcher Vorgänge häufig die Bearbeitung von Dokumenten war und ist, sind die Hersteller von Dokumentenmanagementsystemen (DMS) wie FileNet oder Documentum früh als Protagonisten von – in diesem Fall dokumentenzentriertem - Workflow aufgetreten. Technologisch basierte die damalige Generation von Workflow-Systemen - bis auf die Datenhaltung über relationale Datenbanksysteme - sowohl auf dem Client (z.B. über Scriptsprachen zur Oberflächenbeschreibung) als auch serverseitig (z.B. bezüglich Lastverteilung, Transaktionsmanagement, Clientkommunikation) im wesentlichen auf proprietären Technologien, die teuer zu entwickeln und zu administrieren waren.
 |
| Klicken zum Vergrößern |
| Abb. 2: WfMC-Referenzmodell |
Was die eigentliche Funktionalität der Workflow-Systeme anbelangt hat die Workflow Management Coalition (WfMC) [1] früh begonnen, verschiedene Aspekte solcher Systeme über ein Metamodell und mehrere Schnittstellenmodelle (Abb. 2) zu standardisieren.
So wurden Schnittstellen
- zur Beschreibung von Prozessmodellen,
- für die Bearbeitung von Prozessen zur Laufzeit (Start, Abschließen einer Aktivität) und
- zum Auswerten von Prozessdaten
definiert.
Auch wenn diese Schnittstellen nur von wenigen Herstellern implementiert worden sind, ist jedoch deren Inhalt und Schneidung bis heute valide. Dennoch ist es anspruchsvoll – und wird es bleiben – die Semantik eines Workflow-Modells – als interaktiven Teil eines gesamten Geschäftsprozessmodells - zu standardisieren.
Die Basiselemente eines Prozessmodells (Abb. 3),
 |
| Klicken zum Vergrößern |
| Abb. 3: Metamodell für Geschäftsprozesse |
- Aktivitäten als atomare Schritte des Prozesses,
- Topologie zur Ausführung der Aktivitäten (Entscheidungen, Schleifen, Parallelität, Rücksprünge),
- Rollen, Organisationen oder Benutzergruppen zur Ausführung interaktiver Aktivitäten oder
- im Prozess bearbeitete Daten und Geschäftsobjekte
sind schon in frühen Versionen des WfMC-Standards abgebildet. Komplexere Aspekte wie
- Wiedervorlage,
- 4-Augen-Prinzip oder
- Eskalation
sind schon deutlich schwerer zu beschreiben und zu standardisieren.
Zeitgleich mit der ersten Welle von Workflow wurde das Problem offensichtlich, gerade in Großunternehmen statt jeweils komplett neue Anwendungssysteme zu bauen, die existierenden Kernsysteme z.B. zur Kundendatenverwaltung oder zum Rechnungswesen zu einem Gesamtgefüge verbinden. Hier wurde durch die Hersteller von EAI-Systemen wie TIBCO, SeeBeyond oder WebMethods ein Hub and Spoke (Nabe und Speiche)-Ansatz verfolgt, bei dem zwischen den zu integrierenden Systeme (Spokes) über eine Integrationsplattform (Hub) jeweils Nachrichten ausgetauscht wurden. Dabei haben die EAI-Hersteller neben der Umsetzung von Transformationsregeln für die auszutauschenden Nachrichten weitere Infrastrukturdienste wie Transaktionsverwaltung oder Ausfallsicherheits- und Skalierungsmechanismen zur Verfügung gestellt. So konnten gerade im Bereich des verteilten Online Transaction Processing (OLTP), z.B. Flugbuchungen oder Zahlungsverkehr mit EAI-Systemen Anwendungen für beachtlichen Lasten (deutlich über 1000 Transaktionen/Sekunde) umgesetzt werden.
Technologisch haben die EAI-Hersteller vieles von dem vorweggenommen, was über JMS, JTA, JCA, JDBC, JAAS heute Kernbestandteil von J2EE ist – teilweise auch in Anlehnung an CORBA-Systeme wie Borland VisiBroker oder IONA Orbix, aber auch Transaktionsmonitore wie BEA Tuxedo. Der Siegeszug der zu EAI doch teilweise kompetetiven J2EE-Standardtechnologie auf Basis eines Application Servers ist jedoch von den EAI-Herstellern lange Zeit unberücksichtigt geblieben. Ein wesentlicher Aspekt der Anwendungsintegration, dass nämlich die Aufrufe von Funktionen der zu integrierenden Systeme im Kontext eines komplexen Geschäftsvorfalls - dem Geschäftsprozess - ausgeführt werden, wurde bei EAI-Systemen mit Hub and Spoke-Ansatz nicht umgesetzt. Das führt zu Stilblüten wie der mühseligen Weitergabe von Daten über Nachrichtenketten von Anwendung 1 bis Anwendung N, weil die benötigten Daten – eigentlich der Prozesskontext – die in Anwendung 1 erzeugt oder gewonnen und in Anwendung N benötigt werden in allen Nachrichten zwischen den dazwischen liegenden Anwendungen „mitgeschleift werden, nur um diese in Anwendung N zur Verfügung zu haben. Ein Zugriff oder gar eine Auswertung über die Prozessdaten (z.B. „Was wurde alles mit meinem Kunden 4711 in welcher Zeit im betreffenden Geschäftsvorfall getan“) ist so praktisch nicht möglich.
Die technologische Abstraktion von (Geschäfts-)Funktionen zu integrierender Systeme über Web Services – mit den entsprechenden Standards wie SOAP, WSDL und UDDI - und das Bild, diese Services in einem Prozesskontext über Service Orchestrierung mit der Business Process Execution Language for Web Service (BPEL4WS, kurz BPEL) [2] zu integrieren lässt nun die Integration von Anwendungen in einem neuen Licht erscheinen. Der Prozesskontext ist berücksichtigt und die Schnittstellenabstraktion – bei EAI über Nachrichtenschnittstellen – erfolgt nun über synchrone Aufrufe von Web Services mit SOAP-Request/Response-Pärchen. Dieser Ansatz ist umso attraktiver und sozialverträglicher, da er Microsoft’s .NET mit Java/J2EE gleichschaltet.
Auch wenn die SOA-Gemeinde sich mit beachtlichen Anstrengungen – und mindestens ebenso beachtlichem Lärm – den zu betrachtenden Fragen wie Transaktionsverwaltung oder Sicherheit widmet, liegt der Schulterschluss mit der Workflow-Fraktion noch in weiter Ferne. So enthält auch der in Kürze zu verabschiedende BPEL 2.0-Standard noch keine Elemente zur Beschreibung von Prozessschritten, die nicht durch Web Services-Aufrufe, sondern durch Benutzer-Interaktion auf dem Client ausgeführt werden müssen. BPEL4People – so der Arbeitstitel des vereinheitlichenden Ansatzes – ist noch nicht in Sicht.
 |
| Klicken zum Vergrößern |
| Abb. 4: Einheitliche Sicht auf Workflow und Anwendungsintegration |
Dabei ist genau diese Vereinheitlichung – der Geschäftsprozess wird durch Services der Backend-Anwendungen und interaktive Prozessschritte auf dem Client umgesetzt – die Kernbotschaft von BPM (Abb. 4).
Die folgenden Abschnitte zeigen, was Standards und Produkte heute leisten und wie der Einsatz von BPM die Softwareentwicklung beeinflusst.
Die Standards – BPEL, BPMN, ASAP/Wf-XML, XPDL
Ein wesentlicher Vorteil bei der Einführung von BPM ist der gemeinsame Sprachgebrauch mit den von IT-Idiomen entnervten Fachabteilungen. Diese erachten es spätestens seit der Heilslehre des Business Process Reengineering als statthaft, ihre Vorstellung vom Verhalten einer neuen Anwendung über Prozessmodelle zu beschreiben, die dann in Werkzeugen wie ARIS von IDS Scheer, Adonis von BOC, die Income Suite von Synlogic oder schlicht in Microsoft Visio umgesetzt werden.
Damit auch die Techniker Geschäftsprozesse malen können, hat das W3C BPMN als Überbleibsel der gescheiterten Standardisierungsbestrebungen der von Intalio gegründeten Business Process Management Initiative (BPMI) übernommen und kurzerhand zur Diagrammsprache von BPEL erklärt. Zwar liefert auch UML 2 mit seinen Aktivitätsdiagrammen einen validen Kandidaten zur Darstellung von Geschäftsprozessen, ob aber die OMG die euphorisierte SOA-Gemeinde lange ignorieren kann, bleibt fraglich.
BPEL selbst liefert heute bereits die notwendigen Informationen zum Daten- und Kontrollfluss in einer ggf. nebenläufigen Prozesstopologie. Für den Aufruf von Web Services ist BPEL „berechnungsvollständig“, das heißt BPEL liefert ein durch Orchestration Engines direkt ausführbares Modell. BPEL ist hierbei allerdings nicht flow-orientiert: Prozesstopologien mit Rücksprüngen, wie sie die Fachler gerne liefern, sind in manchen Fällen nicht abbildbar (Listing 1).
| Listing BPEL |
<process name="loanApprovalProcess"
targetNamespace="http://acme.com/loanprocessing"
xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
xmlns:lns="http://loans.org/wsdl/loan-approval"
suppressJoinFailure="yes">
<partnerLinks>
<partnerLink name="customer"
partnerLinkType="lns:loanPartnerLinkType"
myRole="loanService"/>
<partnerLink name="approver"
partnerLinkType="lns:loanApprovalLinkType"
partnerRole="approver"/>
<partnerLink name="assessor"
partnerLinkType="lns:riskAssessmentLinkType"
partnerRole="assessor"/>
</partnerLinks>
<variables>
<variable name="request"
messageType="lns:creditInformationMessage"/>
<variable name="risk"
messageType="lns:riskAssessmentMessage"/>
<variable name="approval"
messageType="lns:approvalMessage"/>
<variable name="error"
messageType="lns:errorMessage"/>
</variables>
<faultHandlers>
<catch faultName="lns:loanProcessFault"
faultVariable="error"
faultMessageType="lns:errorMessage">
<reply partnerLink="customer"
portType="lns:loanServicePT"
operation="request"
variable="error"
faultName="unableToHandleRequest"/>
</catch>
</faultHandlers>
<flow>
<links>
<link name="receive-to-assess"/>
<link name="receive-to-approval"/>
<link name="approval-to-reply"/>
<link name="assess-to-setMessage"/>
<link name="setMessage-to-reply"/>
<link name="assess-to-approval"/>
</links>
<receive partnerLink="customer"
portType="lns:loanServicePT"
operation=
(Kompletter Text nur für Netzwerk-Mitglieder)
Veröffentlicht von
Dr. Marc Gille
bei BPM-Netzwerk.de am 20. August 2006
|
