Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com
Was ist...Workflow?
Workflow
Traditionelle Unterscheidung von Workflow und Groupware
Workflow-Kategorien
Workflow-Technologien
Entwicklungsaufwand
Verteilter Workflow in WAN-Umgebungen
Workflow
Während Groupware eher Informationen koordiniert, geht Workflow von einem prozeßorientierten Ansatz aus. Workflow-Systeme dienen der Automatisierung und dem Management von Geschäftsprozessen über Abteilungs- und Funktionsgrenzen hinweg, wodurch nicht nur Einzelfunktionen automatisiert und optimiert werden, sondern gesamte Prozesse und einzelne Werkzeuge wie Text, Tabelle, Grafik, Datenbank, Masken oder andere Einzelmodule nicht mehr isoliert nebeneinander stehen. Während Workflow ursprünglich lediglich die Vorgangssteuerung und -kontrolle beinhaltete, umfaßt Workflow heute zusätzlich die Integration von Daten, Dokumenten und Applikationen zur Ausführung der Arbeitsschritte. Wesentliche Merkmale von Workflow-Systemen sind:
Prozeßorientierung,
dynamische, in das Workflow-Programm integrierte Ablage,
Nutzung von Informationen und Dokumenten aus unterschiedlichen Quellen,
programmgesteuerte, automatische Bereitstellung von Daten, Informationen und Dokumenten,
Kontrolle der Bearbeitung und der Bereitstellung von Dokumenten,
Speicherung von Verwaltungsinformationen auf magnetischen Speicherplatten, von Dokumenten auf digitalen optischen Speichermedien.

Ein Workflow-System steuert den Arbeitsfluß zwischen definierten Teilnehmern gemäß definierter Prozesse, die aus verschiedenen Aktivitäten und Tätigkeiten bestehen. Es koordiniert Benutzer, Anwendungen und Geräte um definierte Ziele zu festgelegten Schlußterminen zu erreichen. Alle zur Ausführung der Prozesse erforderlichen Dokumente, Daten und Informationen werden automatisch bereitgestellt.
Ein Geschäftsprozeß besteht aus einer oder mehreren Aktivitäten, die wiederum aus einem oder mehreren Tasks oder Tätigkeiten bestehen. Ein Task setzt sich aus einem oder mehreren Work-Items oder Arbeitsschritten zusammen. Durch ein Workflow-System können die verschiedenen Aufgaben und Arbeitsabläufe koordiniert, kontrolliert und nachvollzogen werden. Die notwendigen Informationen werden für jeden Teil des Prozesses aufgabenorientiert zur Verfügung gestellt.
In Anbetracht der wachsenden Bedeutung des Workflow-Marktes, die im Kapitel 6 “Strategien und Trends im DMS-Markt” noch deutlicher werden wird, soll an dieser Stelle detaillierter auf den Workflow-Bereich eingegangen werden.
Top
Traditionelle Unterscheidung von Workflow und Groupware
Abgesehen davon, daß die Abgrenzung zwischen Workflow und Groupware schon in der Vergangenheit nicht immer eindeutig war, werden die Unterscheidungsmerkmale künftig immer mehr schwinden. In welchen Bereichen und Funktionen sich die beiden bisher eher unabhängigen Produktkategorien überschneiden, wird im Kapitel “Strategien und Trends im DMS-Markt” ausführlich dargestellt. Zu einem besseren Verständnis der verschiedenen Ansätze soll auf die traditionelle Unterscheidung an dieser Stelle aber dennoch kurz eingegangen werden.

Workflow
Groupware

System
aktiv
passiv
Benutzer
passiv
aktiv
Prozesse
strukturiert
unstrukturiert
Informationseinheiten
strukturiert
unstrukturiert
Kontrolle
system-/regelgesteuert
benutzergesteuert
Produktivität
Geschäftsprozesse
Endbenutzer
Zielrichtung der Anwendung
“Critical-Mission”-Anwendungen
Infrastruktur
Imaging
wichtig
eher unwichtig
Die traditionellen Unterscheidungskriterien von Workflow und Groupware treffen heute oft nicht mehr zu. Einerseits unterstützen Workflow-Systeme oft auch Ad-hoc-Arbeitsabläufe, andererseits lassen sich mit Groupware-Produkten bereits strukturierte Abläufe abbilden.
Workflow ist eine aktive, überwachende und kontrollierende Software, die dem Anwender Routineaufgaben abnimmt, ständig wiederkehrende Vorgänge abwickelt und aufgrund vorgegebener Bedingungen selbständig Entscheidungen trifft. Der Benutzer ist bei traditionellen Workflow-Systemen eher passiv und reagiert auf Vorschläge des Systems, welches Abläufe steuert, Aktionen auslöst und Dokumente weiterleitet. Bei Groupware stellt das System eine passive Infrastruktur bereit, auf der ein Benutzer dann aktiv alle Aktionen selbst bestimmt und verursacht und für deren ordnungsgemäßen Ablauf und Kontrolle verantwortlich ist.
Bei Workflow sind die Prozesse und Informationseinheiten gut strukturiert bzw. vorstrukturierbar. Abläufe wie der Kreditantrag in einer Bank oder die Schadensabwicklung in einer Versicherung lassen sich durch Regeln klar definieren und laufen jedes Mal bis auf vordefinierte Ausnahmen genau auf die gleiche Weise ab. Es handelt sich hierbei im allgemeinen um hochwertige, zeitkritische Arbeitsabläufe. Systeme, die diese Art von Abläufen unterstützen, müssen sehr robust sein, da viele Transaktionen sehr schnell gehandhabt werden müssen. Groupware eignet sich eher für un-strukturierte Vorgänge, die nur einmal auftreten oder so variieren, daß sie nicht vorhersehbar sind. Hierbei geht es insbesondere um kreativitäts- und teamorientierte Aufgaben wie das Zusammenstellen einer Werbekampagne, die Entwicklung eines strategischen Plans, Gruppenentscheidungsprozesse oder das gemeinsame Erstellen von Berichten. Bei diesen Abläufen gibt es keine oder nur wenig feste Regeln, Ausnahmen sind jederzeit möglich.
Die Produktivitätssteigerung geht bei Workflow von der Optimierung der Geschäftsprozesse aus, bei Groupware sind die Benutzer mit ihren Bedürfnissen, produktiv zusammen arbeiten zu können, der Ausgangspunkt. Während traditioneller Workflow eher der Unterstützung von Anwendungen, die in immer gleicher Qualität mit definierten Ergebnissen in definierten Zeiträumen erfolgen sollen (sogenannte “Critical-Mission”-Anwendungen) dient, stellt Groupware eine Infrastruktur für die Benutzer bereit, damit diese von überflüssigen Routineaufgaben entlastet werden. Das Herausfiltern der relevanten Informationen kostet beispielsweise wertvolle Arbeitszeit und hemmt die weitere Kreativität.
Die Verbindung von Workflow zu Document Imaging ist historisch gewachsen. Der Ursprung der ersten Workflow-Produkte war Document Imaging und die Weiterleitung der Dokumente innerhalb von Netzwerken. Imaging ist ein wichtiger Teil von Workflow-Systemen und stellt die Verbindung zwischen den verschiedenen Arbeitsschritten und den Ursprungsdokumenten, die diese Arbeitsschritte initiiert haben, her. Bei traditionellen Groupware-Produkten spielt Imaging eine eher untergeordnete Rolle, da die Ursprungsdokumente im allgemeinen nicht verlangt werden. Dokumente werden hier eher gemeinsam erstellt, als daß sie von einem Arbeitsschritt zum nächsten geleitet werden. Die Möglichkeit, Images in einem Workflow- oder Groupware-System zu verwalten, sollte aber auf jeden Fall vorhanden sein.
Top
Workflow-Kategorien
Workflow-Systeme sind inzwischen gegenüber der obigen Beschreibung erheblich weiter entwickelt worden und können beispielsweise auch Ausnahmen handhaben und Ad-hoc-Vorgänge unterstützen. Zur Beschreibung und Charakterisierung der verschiedenen Workflow-Typen und der Prozeßarten, die mit ihnen automatisiert werden sollen, werden oft vier Workflow-Kategorien unterschieden:
Production-Workflow (vergleichbar der obigen Beschreibung von Workflow),
Collaborative oder Cooperative Workflow (mit Eigenschaften der obigen Beschreibung von Groupware),
Ad-hoc-Workflow (mit Eigenschaften der obigen Beschreibung von Groupware) und
administrativer Workflow.

Zur Beschreibung und Charakterisierung der verschiedenen Workflow-Anwendungen und der Prozesse, die mit ihnen automatisiert werden sollen, werden oftmals vier Workflow-Kategorien unterschieden.
Es kann jedoch vorkommen, daß Beispiele und Eigenschaften, die von einem Autor oder Anbieter zur Beschreibung einer Workflow-Kategorie verwendet werden, von einem anderen zur Charakterisierung einer anderen benutzt werden. Um hier keine weitere Verwirrung zu stiften und aufgrund der Tatsache, daß sich die Produktkategorien derzeit zunehmend mischen und zusammenwachsen, erscheint eine klare und detaillierte Abgrenzung hier nicht sinnvoll. Die verschiedenen Kategorien sollen lediglich verdeutlichen, welch breites Anwendungsspektrum inzwischen durch Workflow-Systeme abgedeckt wird.
Production-Workflow
Bisher ist traditioneller Production-Workflow für strukturierte Prozesse wie die Schadensabwicklung in einer Versicherung die am weitesten verbreitete Kategorie. Die unterstützten Abläufe sind hochwertige, zeitkritische, transaktionsbasierte Prozesse mit strategischer Bedeutung für ein Unternehmen. Production-Workflow ist im allgemeinen datenbankbasiert, das heißt, daß nicht nur die Applikationsdaten, sondern ebenso Regeln, Abläufe etc. in einer zentralen Datenbank gespeichert werden. Andere Begriffe, die oft in Zusammenhang mit Production-Workflow gebraucht werden, sind prozeßorientierter oder transaktionsbasierter Workflow. Transaktionsbasierter Workflow basiert im allgemeinen auf zahlreichen Regeln, die Regeln gehören hier zu den Informationsressourcen und stellen einen wichtigen Teil der gemeinsamen Wissensbasis dar.
Collaborative Workflow
Die Begriffe Collaborative oder Cooperative Workflow werden manchmal auch als Synonym für Groupware gebraucht. Mit Collaborative Workflow können Informationen aber im allgemeinen besser strukturiert und das Routing besser kontrolliert werden. Collaborative Workflow-Tools sind “Knowledge Worker”-orientiert und im allgemeinen als Pull-Systeme konzipiert. Typische Funktionen sind Joint Editing oder elektronische Konferenzen. Anwendungsbeispiele für Collaborative Workflow sind die Produkt- oder Softwareentwicklung oder Werbekampagnen.
Ad-hoc-Workflow
Auch die Low-Cost-Workflow-Variante Ad-hoc-Workflow wird oft mit Groupware gleichgesetzt. Diese Workflow-Kategorie kann herkömmliche E-Mail durch Übermittlung von Vorgängen und Dokumenten mit einer verbesserten Kontrolle ersetzten. Ad-hoc-Workflow unterstützt einmalige oder stark variierende Prozesse. Das Routing ist nicht vordefiniert, sondern geschieht zur Laufzeit durch den Benutzer. Ad-hoc-Workflow-Systeme sind bereits zu sehr geringen Kosten erhältlich. Anwendungsbeispiele sind das Einholen einer Budgetgenehmigung, die Weiterleitung von Korrespondenz oder das Review von Dokumenten.
Administrativer Workflow
Administrativer Workflow unterstützt bzw. ersetzt Routinetätigkeiten und interne formular- oder papierbasierte Abläufe. Diese Abläufe haben in der Regel keinen Einfluß auf wichtige Geschäftsprozesse und einen ziemlich geringen Geldwert. Es macht folglich keinen Unterschied, ob sich die Abläufe um einen oder zwei Tage verzögern, man möchte aber trotzdem sicher sein, daß diese Vorgänge ordnungsgemäß ablaufen. Da administrative Abläufe in der Regel gut strukturiert sind und jedes Mal auf die gleiche Weise ablaufen, wird administrativer Workflow auch als “Low-cost, low-volume Production-Workflow” bezeichnet. Vielfach basiert diese Workflow-Kategorie auf elektronischer Formularverarbeitung. Beispiele für administrativen Workflow sind Kostenerstattungen oder Bestellungen. Üblicherweise beginnt die Workflow-Einführung in einem Unternehmen aber nicht mit der Automatisierung der administrativen Prozesse, dies ist eher ein Seiteneffekt: Workflow-Tools werden bereits erfolgreich im Rahmen der wichtigen Geschäftsprozesse eingesetzt, später werden dann auch einige der internen Routinetätigkeiten durch ein Workflow-Produkt automatisiert.
Enabling-Technologien
Neben eigenständigen Workflow-Systemen gibt es Enabling-Technologien, die vorhandene Anwendungen um bestimmte Workflow-Eigenschaften und -Funktionen ergänzen, so daß hier keine eigenen Clienten erforderlich sind. Es lassen sich zwei Enabling-Ansätze unterscheiden. Zum einen werden kommerzielle Anwendungen wie SAP, BAAN u.a. um interne Workflow-Engines ergänzt, so daß keine eigenständigen Workflow-Produkte in diesem Umfeld mehr erforderlich sind. Ein zweiter Ansatz ist der Ausbau von Design-Tools für Business Process Reengineering zu kompletten Workflow-Engines oder zumindest zur Generierung von Code, der von Workflow-Produkten direkt umgesetzt werden kann. Ferner gibt es im Ad-hoc-Workflow-Bereich zunehmend Plattformerweiterungen wie beispielsweise von Microsoft, Novell oder Lotus.
Top
Workflow-Technologien
Entsprechend ihrer Kategorisierung basieren Workflow-Systeme auf unterschiedlichen Technologien zur Verwaltung und Steuerung von Dokumenten und Vorgängen. Der Ausgangspunkt ist hier, wie die Arbeitsschritte und Tasks gehandhabt werden:
Prozeßorientierte Systeme
Prozeßkontrolldaten und Regeln werden im Prozeßmodell gespeichert. Die Dokumente spielen hier eine eher untergeordnete Rolle und unterstützen nur den Prozeß.
Dokumentorientierte Systeme Dokumente enthalten Informationen über Ersteller, Applikationen und Regeln, diese Systeme sind im allgemeinen objekt-orientiert. Die Dokumente unterstützen die Applikation nicht nur, sondern sind deren Auslöser.
Objektorientierte Systeme Diese Systeme basieren auf intelligenten Objekten nicht nur für Dokumente, sondern auch für Worklists, Prozesse oder Ressourcen.
Mail- oder messageorientierte Systeme Das Prozeßmanagement mit Routing und Weiterleitung erfolgt über “Mailbox”-Funktionen. Die Abgrenzung zu Groupware und E-Mail ist hier nicht immer eindeutig.

Prozeßorientierte Systeme verwalten die Verweise auf Dokumente und Vorgänge im allgemeinen in einer Datenbank. Die Informationen werden zentral gespeichert, und alle Benutzer mit entsprechender Berechtigung können auf die Daten zugreifen. Sämtliche Aktivitäten können jederzeit genauestens nachvollzogen werden.
Bei dokument- und objektorientierten Systemen enthalten die Dokumente selber die Informationen über ihren Eigentümer, über Applikationen und über die Regeln zur Ablaufsteuerung. Eine relativ neue Technologie in diesem Zusammenhang ist Object Request Broker (ORB). In einem ORB-System enthalten die Objekte alle notwendigen Informationen, um sich selbst verwalten zu können, das heißt daß jedes Objekt weiß, wo es hingehört und was es dort machen soll.
Entsprechend ihrer Kategorisierung basieren Workflow-Systeme auf unterschiedlichen Technologien.
Bei mailorientierten Systemen werden Dokumente an individuelle oder Gruppenverteilungsmechanismen angehängt. Da im allgemeinen nicht aufgezeichnet wird, wer ein Dokument benötigt und wo ein Dokument hingeht, wenn ein Benutzer die Arbeit mit diesem Dokument beendet hat, ist der Benutzer für die ordnungsgemäße Durchführung aller Aktionen verantwortlich. Andernfalls können Dokumente aus der Kontrolle des Systems geraten. Mail-basierte Systeme dienen im Wesentlichen der Verteilung von Dokumenten und Daten und benötigen in der Regel zusätzliche datenbankgestützte Dokumenten-Management-Systeme. Message-Oriented Middleware (MOM) ist eine Technologie, die den Mangel mailbasierter Systeme beseitigen kann, auch wenn der Endbenutzer hier für die ordnungsgemäße Durchführung aller Aktionen verantwortlich bleibt. MOM-Systeme lassen sich mit einem Arbeitsflußprotokoll vergleichen. Jede Message wird als Transaktion behandelt, über die Rechenschaft abzulegen ist, und nicht wie eine Nachricht, die sich irgendwo im System befindet. MOM bietet demzufolge einen höheren Grad an Sicherheit als mailbasierte Systeme.
Heute sind noch fast die Hälfte aller Workflow-Systeme prozeßorientiert. Die Unterscheidungskriterien sind jedoch auch hier nicht immer eindeutig, Systeme haben oft kombinierte Eigenschaften. In Zukunft wird der objektorientierte Ansatz immer mehr an Bedeutung gewinnen. Die zu bearbeitenden Tasks werden mit allen zugehörigen Merkmalen, Arbeitsanweisungen und Dokumenten als selbstbeschreibende Objekte versendet werden können. Aber auch der messageorientierte Workflow-Markt wie etwa E-Forms wächst enorm. Messaging-Verbindungen existieren oft dort, wo es keine Netzwerkverbindungen gibt. Ein Grund dafür liegt darin, daß es üblicherweise billiger und einfacher ist, Messaging-Verbindungen einzurichten als Unternehmen über ein Netzwerk zu verbinden. Viele Benutzer arbeiten gerne offline mit E-Mail-Systemen und erwarten von Workflow-Systemen, daß diese in der Lage sind sich ähnlich zu verhalten. Auf diese Weise können traditionelle datenbankorientierte Workflow-Lösungen auch mit “messaging-enabled” Benutzern zusammenarbeiten.
Fast die Hälfte der derzeitigen Workflow-Systeme sind prozeßorientiert. In Zukunft wird es eine Verlagerung zu dokument- und objektorientierten Systemen geben, die insbesondere für verteilten Workflow vorteilhaft sind.
Top
Entwicklungsaufwand
Workflow-Systeme unterscheiden sich hinsichtlich der Komplexität ihrer Entwicklung und Implementierung, das heißt es bestehen Unterschiede in der Fähigkeit zur Handhabung komplexer Strukturen und Ausnahmen und bezüglich des Entwicklungsaufwandes.
“Off-the-shelf”-Produkte mit Datenbankeditoren sind am günstigsten in der Entwicklung, in ihnen können jedoch auch keine komplexen Strukturen abgebildet werden. Programmierbare Workflow-Tools, die mit Skriptsprachen arbeiten, können komplexere Strukturen und Ausnahmen handhaben, Zeit und Kosten der Entwicklung nehmen aber ebenfalls zu. Diese Tools werden immer noch von einem Großteil der Workflow-Systeme benutzt. Objekt-orientierte Workflow-Tools bedeuten eine weitere Steigerung hinsichtlich Komplexität und Entwicklungsaufwand. Objektorientierte Systeme sind aufgrund wiederverwendbarer Strukturen und Unterstrukturen einfach zu pflegen und flexibel, durch Vererbungsmechanismen können Änderungen sehr leicht vorgenommen werden. Die Regeln sind nicht mit Scripts oder Applikationen verbunden. Wissensbasierte Systeme beruhen auf selbstlernenden Regeln und weichen Entscheidungskriterien. Folglich muß bei ihnen nicht bereits beim Systemdesign bis in das kleinste Detail überlegt werden, welche Ausnahmen auftreten können. Diese Systeme versprechen zwar einen gegenüber objektbasierten Systemen geringeren Entwicklungsaufwand, bislang sind aber noch keine Produkte verfügbar.
Workflow-Systeme unterscheiden sich hinsichtlich ihres Entwicklungsaufwandes sowie ihrer Fähigkeit zur Abbildung komplexer Strukturen und zur Ausnahmenhandhabung.
Top
Verteilter Workflow in WAN-Umgebungen
Entstanden durch den Trend zu virtuellen Unternehmen, deren Mitarbeiter von zu Hause aus arbeiten, sowie aus der Notwendigkeit, Workflows über Länder, Kontinente und verschiedene Zeitzonen hinweg zu unterstützen, ist verteilter Workflow in WAN-Umgebungen eine sehr interessante Entwicklung im Workflow-Bereich. Im Unterschied zu traditionellen verteilten Umgebungen wie beispielsweise verteilte Datenbanken werden bei verteiltem Workflow nicht nur die Applikationsdaten, sondern komplette Arbeitspakete zwischen verschiedenen Orten transportiert und ausgetauscht. Voraussetzung für verteiltes Workflow-Management ist die Fähigkeit des Workflow-Systems, mehrere Datenbanken und Workflow-Engines verwalten zu können. Workflow-Tasks oder Arbeitsschritte müssen unabhängig voneinander ohne die Kontrolle einer zentralen Workflow-Engine ausgeführt werden können. Auch die Clienten müssen in der Lage sein, ihre Workflow-Tasks eigenständig handhaben zu können.
Implementierung eines einfachen Workflows. Alle Clienten haben über ein LAN eine direkte Verbindung zu dem Server, auf dem sich der Workflow befindet.
Da Ad-hoc-Workflow typischerweise WANs auf Kosten von Möglichkeiten zur Kontrolle und zum Management des Arbeitsfortschrittes unterstützt, soll an dieser Stelle auf verteilte Production-Workflow-Implementierungen eingegangen werden. Die folgende Abbildung zeigt die Implementierung eines einfachen Workflows, der aus den drei Operationen “Dateneingang”, “Autorisierung” und “Genehmigung” besteht. Alle Arbeitsstationen sind in einem LAN verbunden und haben eine direkte Verbindung zu dem Server, auf dem sich dieser Workflow befindet.
Die Implementierung mit Wide-Area-Verbindungen wird durch die nachstehende Abbildung veranschaulicht. Hier wird die Autorisierung in einem anderen LAN durchgeführt.
Implementierung eines verteilten Workflows. Die Autorisierung wird in einem anderen LAN durchgeführt.
Für verteilte Workflow-Lösungen sind drei Punkte zu klären:
Spezifikation der Verteilung,
Übermittlung der Aufgaben und Arbeitsabläufe,
Übertragung der zugehörigen Daten.

Zur Ermittlung des Ausführungsortes eines Arbeitsschrittes muß bekannt sein, wann und wie dieser Ort bestimmt wird. Bezüglich des Festlegungszeitpunktes lassen sich eine statische und eine dynamische Festlegung unterscheiden. Bei der statischen Festlegung muß der Workflow-Entwickler den Ausführungsort bereits bei der Prozeßdefinition festsetzen. Dynamisches Binden verzögert die Bestimmung des Ausführungsortes bis zur Laufzeit und kann so die verfügbaren Systemressourcen besser nutzen. Das “Wie” der Lokalisierung beinhaltet, ob die Entscheidung daraufhin getroffen wird, was zu tun ist (die Aktivität), wer eine Aktivität ausführt (der Benutzer) oder welche Daten mit der Tätigkeit verbunden sind.

Die folgende Tabelle veranschaulicht die verschiedenen Kombinationen.
Lokalisierung
wann wie
Statisch
Dynamisch

durch die Aktivität
Alle Arbeitsschritte einer Aktivität werden an einer Stelle platziert. Wenn eine Tätigkeit in der Warteschlange ankommt, wird sie automatisch zu der spezifizierten Stelle übermittelt.
---
durch den Benutzer
Jedem Benutzer wird ein spezieller Platz zur Verfügung gestellt. Alle Tätigkeiten, die der Benutzer auszuführen hat, werden automatisch zu dem spezifizierten Server übertragen.
Wenn ein Benutzer sich, unabhängig von seinem Standort, am System anmeldet, wird seine ganze logische Workqueue an seinem Standort zur Verfügung gestellt.
durch die zugehörigen Daten
---
Wenn eine Tätigkeit in einer Warteschlange ankommt, untersucht ein Algorithmus die zugehörigen Daten, um den korrekten Ort für die übergeordnete Aktivität zu bestimmen. Das Objekt wird automatisch zum ausgewählten Server übertragen.
Für verteilten Workflow muß der Ausführungsort der verschiedenen Arbeitsabläufe festgelegt werden. Für den Zeitpunkt und die Art und Weise der Lokalisierung gibt es verschiedene Möglichkeiten.
Nach der Spezifikation der Verteilung gibt es drei Implementierungsmöglichkeiten für die Übertragung der Arbeitsschritte und der Datenobjekte, wobei jeweils folgende Übertragungsmechanismen benutzt werden können:
On Demand, zum Beispiel World Wide Web/Mosaic
Arbeits- oder Datenobjekte werden auf Verlangen (On Demand) durch die Client-Software von allen bekannten Servern zur Verfügung gestellt. Das verschafft eine lokale Kontrolle mit globalem Zugriff. Um alle bekannten Server nach zugehörigen Objekten zu durchsuchen, werden auf der einen Seite robuste Operationen (die Clienten nehmen Verbindung mit allen verfügbaren Servern auf) und auf der anderen Seite ein sorgfältiges, clientbasiertes Konfigurationsmanagement (zum Beispiel um die Existenz eines neuen Servers an alle Clienten bekanntzugeben) verlangt.
Replikation, zum Beispiel Lotus Notes
Arbeits- oder Datenobjekte werden periodisch auf allen bekannten Servern dupliziert. Fordert ein Benutzer einen Arbeitsschritt an, wird auf eine lokale Kopie zugegriffen. Es wird somit ein lokaler Zugriff auf alle Daten ermöglicht. Replikation ist mit hohen Investitionen in Ressourcen zur Unterstützung mehrerer Kopien der Daten verbunden. Das Server-Netzwerk verbirgt Übertragungsprobleme vor den Systemadministratoren, und Client-Applikationen greifen auf die lokale Datenbank zu. Das vereinfacht das Konfigurationsmanagement, während die Fähigkeit des Systems, einen Verbindungsausfall zu einem bestimmten Server zu bewältigen, beibehalten wird. Durch die Festlegung unterschiedlicher Replikationszyklen kann die Replikation anhand verschiedener Prioritäten gesteuert werden. Objekte mit hoher Priorität werden zum Beispiel jede Stunde und solche mit niedriger nur einmal pro Tag repliziert.
Verteilte OLTP-Anwendungen, zum Beispiel Two-Phase-Commit
Bei verteilten OLTP-Anwendungen (Online Transaction Processing) stehen die Arbeitsobjekte auf allen Servern online zur Verfügung. Die Workqueue ist die logische Verbindung mehrerer lokaler Tabellen in einem gemeinsamen Format. Dieser Ansatz scheint die meisten Vorteile zu bieten, da er das Online-Verhalten der Replikation mit der nicht-redundanten Speicherung des WWW kombiniert. Die Implementierung solcher Systeme ist jedoch insbesondere dann, wenn gute Performance und zuverlässiger Betrieb gefordert werden, sehr kompliziert. Für das Retrieval komplexer Daten und Objekte, die zu einer Tätigkeit gehören, ist dieser Ansatz ungeeignet, da verteilte OLTP-Anwendungen auf der parallelen Ausführung von SQL-Statements in mehreren Database-Instances basieren.Workflow mit verteilten Operationen erlaubt nicht nur die Arbeit in verteilten Systemen, sondern auch die von zentralen Verwaltungssystemen unabhängige Arbeit im “Home Office”. Workflow im WAN ist daher nur ein Übergang zu objektorientierter, dezentraler Verarbeitung. Die Verwendung von Standardschnittstellen und -komponenten wird die Nutzung und Kombination unter-schiedlicher Arten von Workflow-Systemen und -Komponenten gegebenenfalls verschiedener Hersteller in verteilten Umgebungen erleichtern.
© CopyRight PROJECT CONSULT 1992 – 2001. Dr. Ulrich Kampffmeyer
Home/Rechtshinweis
Presse/Autorenrechte
Top
Seitentitel: Was ist_Workflow, Zitierung: http://www.PROJECT-CONSULT.com/home.asp?SR=294
Zuletzt aktualisiert am: 3.12.2001
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com