Business-Process-Management (BPM) verspricht schnellere und agilere Unternehmensprozesse. Die von CEOs vorgebrachte Forderung "IT has to follow Business" soll damit leichter erfüllbar sein. Ob dieses Versprechen eingelöst werden kann, hängt neben der Governance in hohem Maße auch von der technischen Umsetzung und deren Automatisierungsgrad ab.

So verlockend der Return on Investment aus Business-Sicht klingt, so groß sind auch die organisatorischen und technischen Herausforderungen. Prozesse müssen über Silos hinweg, also bereichsübergreifend analysiert, geplant, umgesetzt und optimiert werden. Abteilungen benötigen eine einheitliche Sprache für die Prozesskommunikation. Deren Vokabular muss ausreichen, um die unterschiedlichen Anforderungen berücksichtigen und die Prozesse vollständig abbilden zu können. Sie muss auch für Menschen, die keine Technikexperten sind, verständlich und gleichzeitig konkret genug sein, um als Startpunkt für eine automatisierte Umsetzung zu dienen.

Prozesse und IT entkoppeln

Derart definierte Prozesse treffen nun jedoch auf eine heterogene Systemlandschaft, die niemals im geforderten Maße agil sein kann. Dieses Dilemma kann behoben werden durch eine Entkopplung der Prozesse von der zugrunde liegenden Infrastruktur, durch eine Teilung der monolithischen Funktionsblöcke in kleinere, nahezu beliebig zusammensetzbare Dienste und durch die Definition von Verfahren zur Überwindung der Abstraktionsebenen.

Um die Austauschbarkeit und Orchestrierbarkeit der Prozessdefinitionen und Implementierungsbausteine zu gewährleisten, sind außerdem hersteller- und technologieunabhängige Standards erforderlich. Da die meisten Unternehmen über gewachsene heterogene Umgebungen verfügen, kommt solchen Standards eine entscheidende Bedeutung für das Gelingen und die Zukunftssicherheit eines unternehmensweiten Prozess-Managements zu, sowohl im Hinblick auf die Technik als auch bei Organisation und Governance.

Konzepte wie Service-orientierte Architektur (SOA), Kapselung von Funktionen, Entkopplung von Diensten, Technologieunabhängigkeit etc. sind als Grundlage für ein Business-Process-Management System wie geschaffen. Eine BPM-Einführung ist in der Praxis nur sinnvoll auf Grundlage einer Service-Orientierung, die zumindest die mit BPM anvisierten Unternehmensteile umfasst. Anbieter und Standardisierungsgremien koordinieren daher die beiden Strategien sehr eng; Kunden sind gut beraten, dies ebenfalls zu tun. SOA und BPM bedingen und komplettieren sich gegenseitig (siehe auch: Wie SOA und BPM zusammenwachsen). Im BPM-Umfeld sind Standards insbesondere erforderlich für eine einheitliche, für Menschen verständliche, untechnische Definition von Geschäftsprozessen sowie für den Austausch von Prozessdefinitionen und deren für Computer verständliche Codierung.

Fachliche Modellierung

Im Jahr 2003 befassten sich noch zehn Organisationen auf verschiedene Art und Weise mit dem Management von Geschäftsprozessen, sieben davon mit dem Thema Modellierung. Inzwischen hat eine gewisse Konsolidierung stattgefunden. Dies ist allerdings nicht immer zugunsten des umfassenderen Standards ausgegangen. Vielmehr gab wohl häufig die Unterstützung der Hersteller den Ausschlag für die Entscheidung. Heute haben sich die Business Process Modeling Notation (BPMN, früher BPMI), XML Process Definition Language (XPDL) und der Oasis-Standard Business Process Execution Language (künftig WS-BPEL) als die entscheidenden Standards etabliert.

Die Rolle von BPMN in diesem Trio ist unstrittig. Diese Notationssprache hat sich mittlerweile zum breit akzeptierten Standard für die fachliche Beschreibung von Prozessen entwickelt. Insbesondere international kann BPMN bereits als die führende Sprache für die fachliche Modellierung im BPM-Umfeld betrachtet werden. Als grafische Notationssprache eignet sich BPMN für die visuelle und dadurch eingängige Dokumentation von Prozessen; sie bildet damit eine gute Grundlage für die Kommunikation und Diskussion von Geschäftsprozessen. Dabei ist sie strukturiert genug, um als Ausgangspunkt für eine weitergehende Implementierung zu dienen.

BPMN ist in der Lage, den Ablauf der Aktivitäten eines Prozesses, die erforderlichen Daten sowie nötige Nachrichten zwischen den Prozessbeteiligten zu beschreiben.

Human Workflows

Die Definition ist nicht auf maschinelle Prozesse beschränkt, sondern kann von Menschen zu bearbeitende Prozessschritte, so genannte Human Workflows, ebenfalls dokumentieren. Diese Fähigkeit, nicht nur rein maschinell zu verarbeitende Prozesse beschreiben zu können, wird in der weiteren Betrachtung der Standards - insbesondere von BPEL - noch eine wichtige Rolle spielen. Funktionale Schwächen wie die explizite Definition einer Ausführungssemantik für Prozess-Symbole sollen in Version 2.0 adressiert werden, wodurch der normative Beschreibungsgrad eines Prozesses weiter steigen würde. Unterstützung erfährt die Sprache in den einschlägigen Tools der führenden Hersteller sowie in zahlreichen Implementierungen der Open-Source-Gemeinde. Selbst in den Fachabteilungen häufig genutzte Office-Tools wie Visio unterstützen mittels Plug-ins BPMN. In der gewohnten Umgebung arbeiten zu können stellt für die Mitarbeiter eines Unternehmens einen nicht zu unterschätzenden Vorteil dar und hilft, Akzeptanzhürden abzubauen.

XPDL beschreibt Prozesse

Da die BPMN eine rein grafische Notation darstellt, benötigt sie zur Serialisierung ein Format, das in der Lage ist, ihre Semantik vollständig abzubilden. Diese Aufgabe sollte ursprünglich die Business Process Modeling Language (BPML) übernehmen. Nachdem die Arbeit an BPML eingestellt wurde, klaffte hier zunächst eine Lücke. Hersteller nutzen heute zu diesem Zweck vermehrt die von der Workflow Management Coalition (WfMC) geschaffene Prozessbeschreibungssprache XPDL. Seit der Version 2.0 kennt XPDL X/Y-Koordinaten und Vektoren und ist dadurch in der Lage, auch die grafischen Informationen eines Prozessdiagramms aufzunehmen. Überdies kann die XML-basierende Sprache die Semantik von BPMN vollständig abbilden. Daher eignet sie sich hervorragend zu deren Serialisierung sowie als universelles Austauschformat für Prozessdefinitionen inklusive Human Workflows.

BPDM macht alles neu?

Eine Lösung für die Serialisierung von BPMN-Diagrammen scheint damit also gefunden und die Welt wieder in Ordnung zu sein. In die Idylle könnte allerdings bald wieder Bewegung kommen, wenn die Object Management Group (OMG), aktueller Träger des BPMN-Standards, mit dem Business Process Definition Metamodel (BPDM) nun wohl doch ein eigenes Verfahren zur Serialisierung einführen will. BPDM basiert auf der Meta Object Facility und ist damit auch in der Lage, auf Basis des insbesondere durch die UML breit akzeptierten XMI- Standards zu serialisieren. Dahinter steckt der Gedanke, eine einheitliche Metasprache zur Beschreibung von Workflow-Sprachen zu etablieren und so den Austausch zwischen BPDM-basierenden Auszeichnungssprachen zu ermöglichen.

Eine Weltsprache für BPM?

Die zugrunde liegende These der OMG ist, dass Business und Technik sich ständig ändern, viele Tools diesen Bedarf adressie-ren werden und es somit ohne-hin kaum zu einer einzigen BPM-Weltsprache kommen wird. Deshalb sei vielmehr dafür zu sorgen, dass die unterschiedlichen Sprachen und die darauf aufbauenden Tools kompatibel sind. Der Nutzen für die Anwender wird unter anderem mit einer höheren Zukunftssicherheit von Investitionen, einer einfacheren Wiederverwendung und der Interoperabilität im Unternehmen und über Unternehmensgrenzen hinweg angegeben. Hinzu komme eine größere Unabhängigkeit von den Herstellern.

Gerade dieser Punkt jedoch könnte zu einem Hindernis für den neuen Standard werden, da erfahrungsgemäß den Anbietern an einer zu großen Unabhängigkeit der Kunden nicht gelegen ist und viele bereits proprietäre Erweiterungen der Standards im Portfolio haben. Es bleibt also abzuwarten, ob sich BPDM entgegen allen Bedenken und insbesondere trotz der breiten bereits verfügbaren Unterstützung von XPDL etablieren wird. Einfach ignorieren lässt sich diese Entwicklung auf keinen Fall.

Technische Modellierung

Die fachlichen, durch die BPMN beschriebenen Modelle enthalten noch keine technischen Informationen über die konkrete Implementierung der einzelnen Prozessschritte. Für die Anreicherung um eben diese Merkmale betritt man die technische Domäne. Damit verbunden ist eine geringere Klarheit im Bereich der Standards. Das Ergebnis der technischen Modellierung ist eine von der Prozess-Engine direkt ausführbare Prozessbeschreibung. Diese Beschreibung enthält nicht nur die Aktivität, beispielsweise "Kontostand validieren", sondern nennt auch den Web-Service, der diesen Schritt ausführt. Wie diese technische Anreicherung vonstatten geht, hängt weitgehend vom Hersteller ab. Erst für die daraus resultierende ausführbare Prozessbeschreibung kommen die genannten Standards XPDL und BPEL wieder ins Spiel.

XPDL ist, wie bereits erläutert, eine vollständige Prozessbeschreibungssprache, die insbesondere den Austausch von Prozessbeschreibungen zum Ziel hat. Dieser Austausch kann von Modellierungs-Tool zu Modellierungs-Tool, aber auch vom Modellierungs-Tool zur Prozess-Engine erfolgen. Deshalb werden XPDL und die Business Process Execution Language (BPEL), deren Ziel die maschinelle Ausführung eines Prozesses im Kontext einer Prozess-Engine ist, häufig als konkurrierende oder gar austauschbare Standards ange-sehen.

Sowohl die Historie als auch der Funktionsumfang beider Standards entlarvt diese Meinung als Missverständnis. XPDL ermöglicht aufgrund der vollständigen grafischen und semantischen Abbildung von BPMN einen bidirektionalen Austausch mit dieser Notationssprache, BPEL nur einen unidirektionalen von BPMN nach BPEL. Aus dem B-to-B-Umfeld kommend, konzentriert sich BPEL stark auf die Orchestrierung von Web-Services zur maschinellen Umsetzung eines Prozesses. Die Sprache hat ihre Stärken in lange laufenden Prozessen, eine Abbildung etwa von Human Workflows ist auf dem heutigen Stand aber nicht vorgesehen. Auch der neue Standard WS-BPEL 2.0, der sich zu Redaktionsschluss in der zweiten Review-Phase befand, scheint seinen ursprünglichen Fokus beizubehalten.

Defizite von BPEL

XPDL dagegen hat seine Ursprünge in der Arbeit der Workflow Management Coalition, die die komplette Beschreibung von Workflows im Blickfeld hat und eben nicht nur die maschinelle Ausführung. Das schlägt sich etwa in der Unterstützung von Human Workflows nieder. Gleichwohl gibt es auch Engines, die XPDL direkt ausführen können, was letztendlich XPDL und BPEL zumindest im Hinblick auf die Prozessausführung doch zu Alternativen macht. Die Standardausführungssprache der großen, in der Regel von einem SOA-Kontext getriebenen Prozess-Engines ist gleichwohl BPEL, allerdings häufig mit proprietären Erweiterungen. Diese sind dann sowohl im Process Designer, dem technischen Modellierungs-Tool, als auch in der ausführenden Prozess-Engine berücksichtigt. Das nennt sich dann "auf Standards basierend". BPEL eignet sich daher als Austauschformat nur dann, wenn der Standard auch wirklich ausreicht. Proprietäre Erweiterungen gehen in der Regel verloren.

Um den Defiziten von BPEL zu begegnen, verfolgen einige Hersteller neben den proprietären Erweiterungen verschiedentlich Initiativen für Erweiterungen des Standards. So haben IBM und SAP zur Einbindung von Human Workflows und manuellen Tasks die Erweiterung BPEL4PEOPLE vorgestellt, die jedoch in der Praxis bisher kaum Niederschlag gefunden hat. Mit BPEL-J, unterstützt vor allem von IBM und Bea, soll die Integration von BPEL mit Java verbessert werden. Die große Menge an Business-Logik, die in Java programmiert ist, soll damit möglichst flexibel und einfach in BPEL-Prozesse eingebunden werden können.

Zusammenfassend betrachtet haben beide Standards ihre Stärken und ihren Schwerpunkt. In der Praxis wird die Auswahl häufig bereits durch das einzusetzende Tool vorgegeben. Hat man die Wahl, mag die Art des zu implementierenden Prozesses den Ausschlag geben. Sind zum Beispiel viele manuelle Prozessschritte enthalten, liegt XPDL nahe. Auch eine Kombination ist denkbar, etwa ein Teilexport der maschinellen und lang laufenden Prozesse nach BPEL. Vor dem Hintergrund des sich entwickelnden SOA-Marktes wird sich die auf Web-Services und Orchestrierung fokussierte BPEL als Ausführungssprache sicher behaupten. Tibco etwa hat bereits die Unterstützung der Version WS-BPEL 2.0 bekannt gegeben.

Warum XPDL?

Durch ihre umfassende Semantik hat XPDL ihre Stärken im Bereich der Prozessbeschreibung. Mit der Unterstützung von Attributen für Time Estimation, Cost Unit etc. deckt sie hierbei auch den Bereich Simulation und Prozessoptimierung und darauf spezialisierte Tools ab. Es ist davon auszugehen, dass auf absehbare Zeit ergänzend zu den Standards proprietäre Techniken und Erweiterungen die Bereiche technische Modellierung und Prozessausführung insbesondere der großen Hersteller maßgeblich prägen werden. Je tiefer also die Abstraktionsebene in der Prozessumsetzung, desto größer die Abhängigkeit vom Hersteller. Microsoft etwa verzichtet im Kontext der neuen Windows Workflow Foundation (WF), die Bestandteil von .NET 3.0 ist, komplett auf XPDL oder BPEL. Mit dem Hinweis auf die fehlenden Human Workflows und Subprozesse legt der Konzern die Prozesse in der eXtensible Application Markup Language (XAML) ab. (wh)