Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.04.1999 - 

Interface 4 der WfMC wird den Anforderungen nicht gerecht

Workflow-Standard hat versagt: Alternativen sind gefragt

Mit der Verbreitung von Workflow wird die Verbindung der organisationsübergreifend installierten Workflow-Engines zu einer technischen Herausforderung. Gerold Riempp* beschreibt die Probleme der bisherigen Standardisierungsarbeiten sowie neue Lösungsansätze, die sich aus einem Forschungsprojekt der Universität Paderborn ergeben haben.

In größeren und über mehrere Standorte verteilten Organisationen entstehen oft an mehreren Stellen und unbemerkt voneinander unterschiedliche Workflow-Lösungen. Oft entdecken die Mitarbeiter eines Konzerns erst im zweiten Schritt, daß sie die Systeme zur Unterstützung übergreifender Prozesse zusammenschalten müssen. In anderen Fällen gelingt es aufgrund strategischer Planungen und einer zentralen IT-Steuerung, ein durchgängiges Workflow-Management-System (WfMS) unternehmensweit zu etablieren. Diese Harmonie endet jedoch meist dann, wenn die Workflow-Systeme etwa der Kunden oder Lieferanten angebunden werden sollen.

Proprietäre Inseln als Herausforderung

In beiden Fällen zeigt sich sehr schnell, daß es bei der Verbindung der Inseln neben organisatorischen vor allem technische Hürden gibt. Die zur Zeit am Markt verfügbaren Workflow-Systeme sind geprägt von herstellerspezifischen Prozeßdefinitions-Werkzeugen und -formaten, die sich oft stark individuell gefärbter Prozeßabbildungssprachen bedienen. Außerdem sind die dazugehörigen Workflow-Engines, mit deren Hilfe die Prozesse zur Laufzeit vorangetrieben werden, auf unterschiedlichen Betriebssystemen und Datenbanken von jedem Hersteller eigenständig entwickelt worden.

Entsprechend wichtig sind Standards für Prozeßdefinitionen und Austauschformate, damit die Systeme unterschiedlicher Hersteller kompatibel werden und bleiben. Der Markt für WfMS ist allerdings geprägt durch viele relativ kleine Anbieter oder kleine Einheiten innerhalb größerer Softwarehäuser.

Dieser Umstand läßt sich schon seit den Anfängen der WfMS-Entwicklung in den frühen 80er Jahren beobachten, weshalb sich bislang kein Industriestandard eines früh präsenten und den Markt dominierenden Herstellers herausgebildet hat.

Ein weiterer Grund für das Fehlen von Workflow-Standards liegt darin, daß die unterschiedlichen Anwendungsgebiete - meist werden "Production Workflow", "Administrative Workflow" und "Ad-hoc-Workflow" unterschieden - deutlich abweichende Anforderungen stellen. Die existierenden Produkte fokussieren sich meist auf eines dieser Gebiete. Eine Vereinheitlichung von WfMS aufgrund von Marktkräften ist daher in naher Zukunft nicht zu erwarten.

Das Nachsehen hat der Anwender, denn der ist zur Zeit gezwungen, viel Geld in die Anschaffung und nochmal ein Mehrfaches in die Einführung eines hochproprietären Systems zu investieren. Darüber hinaus kann er sich aufgrund der meist geringen Größe des Herstellers nicht sicher sein, ob es den Anbieter und sein Produkt in zwei Jahren noch gibt. Kleine und große Softwarehäuser haben bei der Entwicklung von Workflow-Systemen schon viel Geld verloren, weil den Produkten der Durchbruch versagt blieb.

Prominente Beispiele sind IBM mit "Flowmark" oder die IDS Prof. Scheer GmbH mit "Aris Workflow", die ihre Produkte als Folge strategisch neu eingeordnet oder sogar vom Markt genommen haben. Aufgrund dieser Situation hemmt sich der Markt selbst, weil fehlende Standards, kleine Anbieter oder geringe installierte Basis gleichbedeutend sind mit mangelnder Investitionssicherheit.

Das haben viele Hersteller auch frühzeitig erkannt und sich 1993 in der Workflow Management Coalition (WfMC) zusammengeschlossen. Heute zählt dieser Verband über hundert Mitglieder (http://www.aiim.org/wfmc). Die WfMC hat zur Standardisierung ein Referenzmodell aufgestellt, das die wichtigsten Komponenten beschreibt und zwischen ihnen fünf Schnittstellen (Interfaces) festlegt.

Interface 4 ist für die Kommunikation zwischen verschiedenen Workflow-Engines zuständig und soll es ermöglichen, daß Prozesse von einem System an ein anderes übergeben werden können. Eine Spezifikation für diese Schnittstelle wurde 1996 herausgegeben und von einigen Herstellern prototypisch implementiert und demonstriert. Allerdings gibt es bislang keine Berichte über eine ernsthafte kommerzielle Anwendung und, was noch schlimmer ist, der Standard wurde seitdem nicht mehr weiterentwickelt. In Zeiten rasanter technologischer Änderungen kommt dies einem Todesurteil gleich.

Interface 4 für die Praxis ist eingeschränkt

Die Gründe, warum sich Interface 4 bislang nicht durchsetzen konnte, sind schnell ausgemacht: Zunächst deckt der Standard nur die Ebene der Workflow-Engines ab. Da aber Workflows erst geplant werden müssen, sollten auch die Prozeßdefinitionswerkzeuge Schnittstellen zueinander haben. Außerdem beschäftigt sich der Standard nur mit der Übergabe von feldformatierten Daten, im administrativen Bereich müssen dagegen Dokumentenmappen bewegt werden. Wichtige Dokumentenstandards wie SGML, HTML oder XML läßt die Schnittstellen-Definition jedoch außen vor.

Schließlich erfordert Interface 4, daß die Workflow-Engines vorab Prozeßdefinitionen austauschen. Das mag innerhalb einer Organisation gerade noch akzeptiert werden, aber zwischen rechtlich getrennten Besitzern verschiedener Workflow-Systeme ist dies ein Ausschlußkriterium. Niemand würde einem Lieferanten seinen Produktionsprozeß komplett offenlegen, nur weil er Schrauben bestellen will. Daher kommt Interface 4 für wichtige Trends wie Electronic Commerce oder Supply-Chain-Management, bei denen man Prozesse firmenübergreifend elektronisch abwickeln will, schlicht nicht in Frage. Dies wären aber gerade diejenigen Bereiche, in denen kooperierende WfMS ideal eingesetzt werden könnten.

Aufgrund dieser Schwächen gehen viele Hersteller dazu über, eigene Standards zu entwickeln. So etwa die SAP AG mit einer neuen Architektur auf Basis von XML, mit der Prozesse über mehrere R/3-Systeme hinweg via Internet nahtlos unterstützt werden können (eine Ergänzung zur der seit längerem verfügbaren Idoc-Technik). Eine Unterstützung beim Planen firmenübergreifender Workflows mit Hilfe eines Prozeßdefinitionswerkzeugs bietet jedoch auch dieser Ansatz nicht.

Es besteht also Bedarf an herstellerunabhängiger Entwicklung. Dazu wurde bereits 1994 am Groupware Competence Center der Universität Paderborn ein Forschungsprojekt aufgesetzt. Bis Mitte 1998 hat man hier untersucht, wie das "Wide Area Workflow Management" - so die häufige internationale Bezeichnung für die Kooperation mehrerer Workflow-Systeme - flexibel und effizient funktionieren kann. Zunächst wurden Ebenen der Zusammenarbeit identifiziert: von den organisatorischen Rahmenbedingungen über die Prozeßdefinitionswerkzeuge bis hin zu den Workflow-Engines und der darunterliegenden Technologie.

Ferner wurden grundlegende Koordinationsverfahren ermittelt: Einerseits kann ein Kooperationspartner die Prozeßdefinitionen und Laufzeit-Schnittstellen bestimmen. Dieses klassisch hierarchische Koordinationsverfahren trifft man oft innerhalb einer Organisation an. Eine zweite Möglichkeit besteht darin, daß sich die Teilnehmer über die Rahmenbedingungen der Prozeß- definitionen etc. in Verhandlungen einigen, was eine gleichberechtigte Partnerschaft voraussetzt. Schließlich kann ein Partner die Schnittstellen zu Prozeßdefinitionen und Workflow-Engines definieren und anderen anbieten. Die potentiellen Empfänger können diese abonnieren, ein typisch marktorientiertes Koordinationsschema. Die beiden letzten Varianten finden sich häufiger zwischen rechtlich selbständigen Partnern.

Trägt man die Ebenen und Koordinationsverfahren in einer Matrix auf (siehe Abbildung auf Seite 20), lassen sich die vielfältigen Möglichkeiten für Wide Area Workflow Management erkennen. Eine einzige Lösung für alle Anwendungsgebiete wird es also nicht geben. Trotzdem oder gerade deshalb sollten die verschiedenen Schnittstellen-Spezifikationen zusammengehalten werden. Dazu bieten sich Verzeichnisdienste etwa auf Basis des X.500-Standards an, die für alle Workflow-Systeme zugänglich sind. Im Rahmen des Forschungsprojekts werden sie als "Coordination Directories" bezeichnet.

Übergabe in Form von Compound Documents

Um die Übergabe von feldformatierten Daten ebenso zu ermöglichen wie von formatierten Dokumenten, bieten sich Compound-Document-Strukturen an, wie sie in Groupware-Systemen Verwendung finden. Aber auch unabhängige Standards wie HTML oder XML können genutzt werden, um sogenannte Message-Objekte zwischen den Workflow-Systemen auszutauschen. Sprechen die beteiligten Systeme unterschiedliche Sprachen, so benötigt man noch Gateways, die eine Konvertierung übernehmen.

Das Forschungsprojekt blieb nicht bei der konzeptionellen Betrachtung stehen. Um die Realisierbarkeit zu beweisen, wurde das "Wide-Area-Groupflow"-System entwickelt, das zur schnelleren Umsetzung auf einer Groupware-Plattform basiert. Die Lösung bietet ein grafisches Prozeßdefinitionswerkzeug, das sich aus Koordinations-Verzeichnisdiensten bedienen kann und so die Modellierung von firmenübergreifenden Prozeßdefinitionen erlaubt, indem Prozeß-Schnittstellen oder ganze Subprozesse eingebunden werden. Die Workflow-Engine verfügt über Schnittstellen, um von anderen Systemen aufgerufen zu werden, und kann ihrerseits weitere Engines einbinden. Message-Objekte und Gateways sichern die Kompatibilität zu anderen Systemen.

Freies Testen auf eigenes Risiko

Wide Area Groupflow war ursprünglich als Demonstrations- und Evaluationswerkzeug konzipiert. Seit es aber frei aus dem Web herunterladbar ist, wird es vielfach getestet und auch eingesetzt - allerdings auf Risiko des jeweiligen Anwenders (http:// gcc.uni-paderborn.de/wags). Ein Buch in englischer Sprache (ISBN: 3-540-76243-4) beschreibt die Ergebnisse des Paderborner Forschungsprojekts und erläutert den Aufbau und die Anwendung des Systems anhand von zwei konkreten Fällen aus der Praxis (http://www.springer.co.uk/comp/ support/index.html).

Solche Ansätze eilen der Praxis allerdings weit voraus. Hier dominieren fallspezifisch gestaltete Schnittstellen für Peer-to-peer-Verbindungen, bei denen die Workflow-Engines Daten direkt austauschen. Dies kann zwar im Einzelfall sehr leistungsfähige Workflows ermöglichen, aber mit zunehmender Zahl der Verbindungen steigt der Konfigurations- und Pflegeaufwand unverhältnismäßig an. Systeme für den Entwurf übergreifender Prozeßdefinitionen fehlen dabei ebenso wie Koordinations-Verzeichnisdienste, mit denen man eine einmal entwickelte Schnittstelle mehreren Empfängern unabhängig vom eingesetzten Workflow-System zur Verfügung stellen kann. Zumindest bei den Austauschformaten hat mit XML ein vielversprechender Kandidat die Bühne betreten, jetzt müßte noch eine Workflow-spezifische Document Type Definition (DTD) folgen - eine Aufgabe für ein Gremium wie die Workflow Management Coalition, möchte man meinen.

*Dr. Gerold Riempp ist Projektleiter bei der Price Waterhouse Coopers Unternehmensberatung GmbH in Frankfurt am Main.