A further reason for project failure is unreal expectations. These unreal expectations are often created during the sales process when companies are sold the idea of a utopian environment where all routine tasks are automated and there is full and seamless integration with the line of business applications. Whilst this may be an acceptable ultimate goal (although that is questionable), few people understand the amount of work required to achieve such utopia.
"Preventing
Workflow failure and rescuing doomed Document Management
projects..." Document Management in Finance, Volume 3, Issue
3, June 1996
De behoefte aan standaardisatie komt in hoofdzaak voort uit de drang naar integratie.
Bedrijven die groeien vertonen vaak de nood aan integratie van hun systemen. Redenen als behoefte aan betere informatiedoorstroming, betere ondersteuning bij beslissingsprocessen, wijzigingen in productiesystemen, verbetering van kwaliteitsopvolging, centralisatie van geografisch gescheiden gegevens en zo meer kunnen hierbij aangehaald worden.
Om vlot een groot scala aan informatiesystemen te kunnen integreren, is het een vereiste dat deze een grote flexibiliteit vertonen. Onderhoudskosten maken 60 tot 70% uit van de totale informatiseringskosten. Van deze onderhoudskosten wordt 40% besteed aan migratie van software naar een ander platform en het verbeteren van betrouwbaarheid en efficiënte. De overige 60% heeft betrekking op functionele aanpassingen. (van der Sanden W.A.M., Campschroer J.T.P., de Jel F.J., 1997).
Het is een gekend euvel dat heel wat bedrijven de dag van vandaag geplaagd zitten met de gevolgen van keuzes die gemaakt werden in het verleden. Wanneer markten jong zijn is er doorgaans ruimte voor een hoeveelheid concurrerende systemen. Na verloop van tijd slagen bepaalde technologieën - en niet noodzakelijk de beste, wat het probleem enkel nog vergroot - erin zich meer te profileren dan andere, en het meest verspreide systeem wordt tot de facto standaard verheven. Een voorbeeld van dergelijke evolutie is terug te vinden in het wijd verspreide gebruik van TCP/IP. Mogelijks brengt afwijken van de standaard aanvankelijk geen problemen mee of kan dit zelfs aangewezen zijn (bijvoorbeeld om performantieredenen), op langere termijn echter kan dit nefaste gevolgen hebben. Verdere ontwikkelingen van de betreffende technologie blijven uit en binnen de kortste keren vindt men zich "lokaal" geïsoleerd, want connectiviteit met andere systemen blijkt niet of slechts ten dele haalbaar. Op termijn is de kans reëel dat door stabilisatie en uitzuivering van de markt de verschaffer van de "overwonnen" technologie overkop gaat en verdwijnt. Bedrijven gaan dan ook op zoek naar duurzame oplossingen voor hun ICT-problemen, en liefst zonder zich onomkeerbaar te engageren voor een technologie die slechts door één producent wordt aangeboden.
Informatiesystemen worden steeds complexer en gespecialiseerde kennis ter zake is onmisbaar. Modulaire opbouw van zo'n systeem is dan ook een dwingende noodzaak om uitbreiding mogelijk te maken. Vaak is het om financiële redenen niet mogelijk de hele architectuur van een informatiesysteem te vernieuwen. Doordat de bestaande infrastructuur doorgaans stap voor stap is opgebouwd en investeringen soms op verschillende geografische lokaties en onder andere voorwaarden zijn gebeurd, zal de integratie in veel gevallen moeten plaatsvinden over vele platformen heen. Platformonafhankelijkheid is dus ook een belangrijk punt. Voor de producenten uit zich dit in bepaalde evoluties zoals bijvoorbeeld objectgeoriënteerde methodologieën of gelaagde communicatieprotocollen.
Een ander belangrijk punt is de openheid van systemen. Voor producenten kan de optie om bestaande gesloten systemen uit te breiden aanlokkelijk zijn. Het gevaar hierbij is dat men zich relatief veel moeite getroost om een in feite achterhaalde technologie te behouden. Het zeilschipsyndroom doemt op. Afgeschreven technologie is doorgaans ook niet overdraagbaar naar andere domeinen (of misschien tegen erg hoge kost) en onderhoud van een monolitisch systeem is een kolossale opgave. Gesloten systemen kunnen niet of moeilijk in-huis gewijzigd worden, waardoor cliënten opnieuw afhankelijk worden van één welbepaalde leverancier. Laatsgenoemden zullen dus eerder op zoek gaan naar een gedocumenteerd product dat zij eventueel zelf naar behoeven kunnen aanpassen. Indien zo'n product is opgebouwd volgens een standaardarchitectuur, wordt de keuzemogelijkheid voor ontwikkelaars beperkt. Dit betekent dat kans op alternatieve ontwikkelscenario's die niet werken verkleint. Bovendien kan men dan terugvallen op een bepaalde set van ontwikkeltools die hun deugdelijkheid bewezen hebben en aldus de ontwikkeltijd inkorten en dus kosten besparen.
Tegenover de uitdaging van niet aflatende vernieuwing aan competitieve prijzen staat dat de providers van informatietechnologie zich niet kunnen veroorloven het vertrouwen in hun sector te beschamen. Om hun geloofwaardigheid te behouden kunnen zij het zich niet permitteren om bedrijven niet te volgen in de -vaak zware- investeringen die zij reeds hebben gedaan. Hun oplossingen moeten dus duurzaam zijn, en standaardisatie kan hierbij een rol spelen. Standaarden zorgen voor stabiliteit : een standaard komt tot stand uit onderlinge samenspraak. Daarenboven kunnen technologieverschaffers zich concentreren op de ontwikkeling van producten waarvoor ze een competitieve voorsprong opgebouwd hebben. Standaarden maken de markt groter - het product is breder inzetbaar - en het bedrijf krijgt een kans grotere naambekendheid te verwerven.
Een optimale oplossing voor zowel producent als afnemer kan bestaan in het gebruik van zogenaamde open technologieën: gedocumenteerde oplossingen met een modulaire structuur die bij voorkeur bepaald is door een aantal belangrijke spelers in de markt voor het aanbelangende domein. Deze openheid laat mogelijkheden voor concurrentie op andere niveaus, zoals op het vlak van kwaliteit en uitbreidings- en integratiemogelijkheden en kan leiden tot meer indicatieve en competitieve prijzen.
Toegepast op workflow betekent dit dat een product dat beantwoordt aan vooraf bepaalde standaarden tot een schaalbare implementatie kan leiden, met mogelijkheden voor verticale en horizontale integratie. Enerzijds kan verticale integratie toegepast worden naar boven toe, bijvoorbeeld bij het inpassen van workflow management in een groupware systeem, in een Management Information System (MIS) of Decision Support System (DSS), of eenvoudigweg door het aansluiten van bestaande desktop software, anderzijds kan het ook naar beneden toe, bijvoorbeeld voor imaging- en opslagsystemen, internetwerking of Electronic Data Interchange (EDI); horizontale integratie kan in die zin dat gelijkaardige producten van andere leveranciers in staat zijn samen te werken. Bovendien moet het geheel platformonafhankelijk, beheer(s)baar en veilig zijn. Standaardisatie leidt tot integratie, integratie leidt tot productiviteit.
Many imaging and workflow projects have stalled or failed. This is because many such projects are complex and the view of the customer or the user is not shared by the supplier. We set out primarily with the systems integration component as the most important part because we perceive that as being the most lacking part in marketplace.
"Q&A" - Ian Elliot, ICL, Document Management in Finance, Volume 3, Issue 3, June 1996
Producten voor geautomatiseerde werkstroomondersteuning vinden hun oorsprong in verschillende technologieën. Terwijl sommige van de grond af zijn ontwikkeld als workflow software, zijn andere voortgekomen uit andere disciplines van de informatietechnologie, zoals image management, documentbeheer, databanken of andere opslagsystemen en systemen voor elektronisch berichtenverkeer. De ontwikkelaars van workflow management systemen hebben door de jaren heen eigen interfaces en terminologie ingevoerd, waar de leveranciers van producten die geëvolueerd zijn uit andere technologieën vaak eigen termen en interfaces gebruiken.
De beschikbaarheid in de markt van een brede waaier van producten heeft ertoe geleid dat producenten de kans kregen zich toe te leggen op de ontwikkeling van welbepaalde functionele mogelijkheden, en gebruikers hebben bepaalde producten gekocht om te voldoen aan specifieke behoeften.
Elk product heeft uiteraard wel zijn eigen sterke en zwakke punten. Het ligt nu in de bedoeling de gebruiker de mogelijkheid te bieden de sterke punten van elk van deze systemen te benutten in één en dezelfde infrastructuur en op die manier eilandautomatisering tegen te gaan.
Een individueel bedrijfsproces kan een levenscyclus hebben die varieert van een paar minuten tot enkele dagen of zelfs maanden, afhankelijk van zijn complexiteit en de duurtijd van de activiteiten waaruit het proces bestaat. Een dergelijk systeem kan op veel manieren geïmplementeerd worden, gebruik makend van een scala aan informatietechnologische hulpmiddelen en infrastructuren. Het kan aangewend worden voor het uitvoeren van taken binnen kleine lokale werkgroepen, maar evenzeer in een samenwerkingsverband dat de grenzen van de eigen onderneming overschrijdt.
Er is behoefte aan een model dat een brede kijk levert op werkstroomondersteuning en dat geschikt is voor de verscheidenheid aan implementatiemogelijkheden en operationele omgevingen waarin deze technologie wordt ingezet.
Ondanks deze verscheidenheid bezitten workflow management systemen een aantal karakteristieken die de basis kunnen vormen voor een model volgens hetwelke het mogelijk is om systemen te bouwen die hun specifieke taken vervullen en tegelijkertijd geïntegreerd kunnen worden of in staat zijn om samen te werken.
Onderzoek naar behoeften van de gebruikers (Aldridge) toonde aan dat workflow management aan vier vereisten moet voldoen, namelijk :
Op basis van deze vereisten onstond een architectuur voor workflow management die moet voldoen aan de voorwaarden van een open systeem, zoals schaalbaarheid, interoperabiliteit, overdraagbaarheid en beschikbaarheid.
De Workflow Management Coalition werd gesticht in augustus 1993 als een internationale non-profit vereniging van workflow verkopers, gebruikers en analisten. De missie van de Coalitie is het promoten van software terminologie, interoperabiliteit en connectiviteit tussen workflow producten.
Formeel heeft de Coalitie als standaardisatie orgaan geen enkele status. Het grote aantal bedrijven en organisaties dat tot de Coalitie is toegetreden of ermee samenwerkt, toont echter het belang aan van de organisatie voor de workflow industrie. Onder de stichtende leden vinden we alom gekende namen terug zoals Digital Equipment Corporation, Fujitsu, Hewlett Packard, Hitachi, IBM, Microsoft, NEC, Olivetti, Oracle en Unisys. De consulting wereld wordt onder meer vertegenwoordigd door Cap Gemini Innovation, Delphi Consulting Group en Ernst & Young. Andere stichtende leden zijn bijvoorbeeld nog SAP, SAS Institute, Defense Information Systems Agency en zelfs Coca-Cola. Naast de stichtende leden is er nog een hele lijst gastleden, waaronder hard- en software leveranciers, consulting bureaus, onderzoeksinstituten en universiteiten (waaronder de K.U. Leuven). Verder bestaan contacten met andere organisaties die zich inlaten met standaardisatie, zoals de AIIM (document management en imaging), de Open Document Management API (ODMA, houdt zich bezig met het ontwikkelen van een standaard voor interfacing tussen document-geörienteerde toepassingen), de 'Black Forest Group' (een belangrijke gebruikersgroep die eisen vaststelt op het vlak van document imaging, document management en workflow), de Object Management Group (OMG, gekend van de Common Object Request Broker Architecture of CORBA) en de CAD Framework Initiative (CFI, richt zich op standaarden ten behoeve van elektronische ontwerptoepassingen). Ook bestaan er contacten met enigszins concurrerende standaardisatie-initiatieven op het vlak van DIS, zoals van de 'Shamrock Group' die een API heeft genaamd Enterprise Library Services (ELS) en Document Enabled Networking (DEN) (Van Leeuwen, 1995 en van den Berg, A. J., 1995).
De opdrachtsverklaring van de Workflow Management Coalition luidt als volgt:
De Coalitie is opgedeeld in twee comités, het "Technical Committee" en het "Steering Committee", die elk bestaan uit een aantal kleinere werkgroepen. Deze werkgroepen zijn belast met het uitwerken van de terminologie en het referentiemodel dat als raamwerk moet dienen voor het opstellen van workflow standaarden. Elke werkgroep concentreert zich op een bepaald aspect van het model. De comités vergaderen vier keer per jaar afwisselend in Noord-Amerika en Europa. Lidmaatschap is open voor alle partijen die op een of andere manier begaan zijn met de creatie, analyse of uitwerking van workflow software systemen.
De Coalitie heeft haar doelstellingen als volgt geformuleerd:
Opdat de verschillende partijen die interesse hebben in de standaardisatiepoging elkaar goed zouden verstaan, is de Coalitie begonnen met het opstellen van een standaardterminologie voor het beschrijven van de verschillende elementen die betrekking hebben op een workflow management systeem en haar omgeving.
Ter verduidelijking van het referentiemodel dat in paragraaf 3.2.5 wordt besproken, volgt hier een korte beschrijving van een aantal basisbegrippen en hun onderlinge samenhang, zoals weergegeven in Figuur 3.
Een bedrijfsproces
wordt vastgelegd in een aantal procesdefinities, die processen
definiëren die uit een aantal subprocessen kunnen bestaan. Zo'n
subproces bestaat dan weer uit een aantal activiteiten, waarvan
sommige manueel en andere geautomatiseerd uitgevoerd worden. Het
verwerken van een schadeclaim in een verzekeringsmaatschappij,
het evalueren van een kredietaanvraag bij een bank, het invoeren
en opvolgen van een order voor een productiebedrijf zijn alle
voorbeelden van processen. Een activiteit is een logisch geheel
binnen een proces en vereist een aantal middelen om de uitvoering
van het proces waar het deel van uitmaakt mogelijk te maken.
Actviteiten kunnen zijn : verifiëren, inspecteren, rapporteren,
gegevensinvoer, printen,… Bij run time wordt dergelijk
gemodelleerd proces uitgevoerd onder supervisie van een workflow
management systeem. Dit creëert zogenaamde instantiaties (instances)
van een gemodelleerd proces en voert deze uit. Met de definities
van geautomatiseerde activiteiten uit het procesmodel komen
instantiaties van activiteiten overeen die een procesinstantiatie
uitmaken. Binnen het systeem hebben instantiaties (van processen
en activiteiten) een bepaalde toestand en een eigen identiteit.
De activiteitsinstantiaties vormen de basis voor de overgang van
het systeem naar een volgende toestand en ze worden afgebakend
door pre-, post- en overgangscondities. Overgangscondities vormen
de basis voor de relaties tussen activiteiten en de stroom van
werk. Ze kunnen eveneens gebruikt worden om aan te geven of
bepaalde activiteiten parallel dan wel sequentieel dienen
uitgevoerd te worden. Die elementen van een activiteit in
uitvoering die tussenkomst van een gebruiker behoeven worden work
items genoemd en komen op de worklist van de uitvoerder terecht.
Andere items worden rechtstreeks aan de verwerkende applicatie
doorgegeven. Deze items vormen een elementaire eenheid van
uitvoering en maken de activiteitsinstantiatie uit.
Figuur 3 Enkele basiselementen van een
workflow management systeem en hun onderlinge samenhang (WfMC,
1996a)
Om er voor te zorgen dat workflow management kon evolueren tot een open en flexibele technologie werd een metamodel uitgewerkt dat moet helpen bij het verwezenlijken van de doelstellingen die de Workflow Management Coalition zich heeft gesteld op het vlak van standaardisatie.
Om tegemoet te komen aan de vraag uit de markt zoals geformuleerd in paragraaf 3.2.2 (p. 17) enerzijds, en rekening houdend met de natuur van workflow management systemen zoals aangehaald in paragraaf 2.4 (p. 12) anderzijds, kwam onderstaand abstract model tot stand (zie Figuur 4). Het is opgebouwd rond de run time control functie (de workflow enactment service(s)), aangevuld met systemen die de run time interaction functie moeten uitmaken (de workflow client applications en de invoked applications) en de build time functie (process definition tools). Daarenboven werd connectiviteit met systemen voor administratie en monitoring voorzien (administration and monitoring tools). Het hart van het systeem, de workflow enactment service, wordt aangesproken via de WAPI of Workflow Application Programming Interface.
Het werk van de Workflow Management Coalition spitst zich dus toe op een abstract model, waarvan de verschillende deelsystemen elkaar benaderen via een aantal interfaces. De achterliggende gedachte is dat het model geen aanleiding moet geven tot een welbepaalde manier van implementatie, zoals bijvoorbeeld objectgeoriënteerde programmering. De interfaces schermen de toegang tot implementatiespecifieke details van de workflow server af voor de applicaties er gebruik willen van maken. De manier waarop de functionaliteit van de server geïmplementeerd is, blijft voor de applicaties die ervan gebruik maken verborgen.
Mocht daarenboven een fabrikant ervoor kiezen de interactie met zijn systeem niet te laten gebeuren via publieke interfaces, dan wordt daarin voorzien. Er zijn met name een aantal niveaus van conformiteit bepaald waarin komaf gemaakt wordt met de problematiek van openheid en coöperatie.
De verschillende deelsystemen en interfaces uit het model komen in de volgende paragrafen kort aan bod om aldus een idee te krijgen van de domeinen waarop standaardisatie zich concreet toespitst. Waar mogelijk zullen referenties opgegeven worden waar verdere technische details omtrent de betreffende interface kunnen teruggevonden worden. Voor verklaring van de terminologie wordt verwezen naar het document van de Coalitie dat de standaardwoordenschat en terminologie beschrijft met het oog op consistentie en uniformisatie voor de workflow industrie (WfMC, 1996a).
Figuur 4 Het workflow referentiemodel
(Workflow Management Coalition)
In de volgende paragrafen wordt verder ingegaan op de verschillende componenten uit Figuur 4. De bespreking van de "Workflow API and Interchange Formats" gebeurt echter pas in paragraaf 3.2.5.3 (p. 17), na een inleiding op de verscheidene soorten datatypes die in een workflow management systeem ter sprake komen (paragraaf 3.2.5.2, p. 17).
Zoals gesteld in de
definitie van workflow management systemen (paragraaf 2.2.1
Workflow management: definitie, p. 7), worden werkstromen
geïmplementeerd op basis van een computerrepresentatie van de
werkstroomlogica. De hulppakketten om deze representatie op te
stellen en de elementen van het bedrijfsproces te modelleren,
beschrijven en analyseren, vallen onder de noemer Process
Definition Tools. Doorgaans betreft het hier CASE-tools die over
een grafische gebruikersinterface beschikken en in staat zijn de
gedefinieerde elementen op te bergen in een repository-database,
zoals voorgesteld in Figuur 5. Er bestaan organisaties die zich
toeleggen op het bepalen van standaarden voor procesmodellering
in het algemeen en workflow modellering in het bijzonder
(bijvoorbeeld het onderzoek naar de Trigger Modeling Technique
door o.a. Stef Joosten aan de universiteit van Twente, zie
Joosten - workflow.html).
Figuur 5 Process definition tool,
workflow server, WAPI en repository
Het is opmerkelijk dat de repository voor definities in het schema gelokaliseerd wordt aan de serverzijde, en niet behoort tot het client programma waarmee de definities gemaakt worden. Hiervoor kunnen een aantal redenen aangehaald worden. Vooreerst is het niet vanzelfsprekend dat client- en servertoepassing van eenzelfde bestandssysteem gebruik maken. Ook laten sommige systemen geen rechtstreekse toegang tot deze gegevens toe, andere weer wel. Verder worden een waaier van opslagsystemen toegepast, variërend van relationele databases tot objectgeoriënteerde. Opslag aan de serverkant vereenvoudigt versiebeheer en verkleint de kans op ongeldige definities (ze zullen niet geaccepteerd worden en dus bekend zijn vóór ze gebruikt worden). Daarenboven stelt het de ontwerper van de server gemakkelijker in staat de repository te implementeren als een dynamisch kennissysteem met ingebouwde exception rules.
Het werk van de Coalitie spitst zich toe op het ontwerpen van interfaces voor de uitwisseling van definitiegegevens die volgende soorten informatie weergeven (WfMC, 1996b) :
Zie verder ook (WfMC, 1995) en paragraaf 3.4 in (WfMC, 1994b) van de Workflow Management Coalition.
De workflow enactment service voorziet in een run time omgeving waarin één of meerdere werkstromen worden uitgevoerd. Een workflow management systeem kan uit meerdere enactment services bestaan, die op hun beurt uit meerdere workflow engines kunnen bestaan. Een workflow engine zorgt voor de run time omgeving waarbinnen een bepaalde werkstroominstantiatie (workflow instance) wordt uitgevoerd. De workflow engine zorgt dus voor de interpretatie en uitvoering van de definities waarvoor het bevoegd is. Deze definities kunnen bijvoorbeeld betrekking hebben op het domein van document imaging of electronic mail.
De enactment service staat in voor de communicatie met externe bronnen zoals
Workflow engines kunnen logisch gegroepeerd worden in werkstroomdomeinen (workflow domains) binnen dewelke het toegelaten is samen te werken voor het afhandelen van een proces. De aanwezigheid van een workflow enactment service is transparant voor de gebruiker. Meer details kunnen teruggevonden worden in paragraaf 3.3 van (WfMC, 1994b).
De workflow client vormt het gezicht van het werkstroomsysteem naar de eindgebruiker toe. Het presenteert de te verwerken opdrachten en gegevens en kan eventueel de toepassingen opstarten die voor het verwerken nodig zijn. Het laat de eindgebruiker acties ondernemen vooraleer de uitvoering van de proces instantiatie (proces instance) terug over te dragen aan de workflow enactment service. De client wordt ook wel worklist handler genoemd omdat volgens het model en de terminologie van de Workflow Management Coalition een activiteit bestaat uit een aantal elementaire eenheden van uitvoering, work items, die op de worklist van de gebruiker komen te staan en de taak samenstellen die deze in het kader van een bepaalde activiteit moet uitvoeren (zie ook Figuur 6, p. 17). Afhankelijk van de implementatie van het systeem worden de gegevens op de worklist geplaatst door de workflow enactment service (bijvoorbeeld als deel van een elektronisch bericht) of raadpleegt de worklist handler zelf de enactment service voor uit te voeren werk (bijvoorbeeld door het uitvoeren van een remote procedure call).
Hoewel de termen 'worklist handler' en 'workflow client application' als synoniemen beschouwd worden, kunnen ze elk een andere invulling krijgen. Het is bijvoorbeeld mogelijk de client applicatie enkel te laten instaan voor elementaire worklist afhandeling, zodat deze er op de machine van de gebruiker uitziet als weinig meer dan een 'in-bakje' voor uit te voeren werk. Maar in meer complexe systemen kan de client ook zorgen voor een zekere taakverdeling tussen de uitvoerders. Dergelijk systeem voorziet dan in faciliteiten voor werklastverdeling, toewijzing van work items en aan- en afmelden van gebruikers.
Het is van belang een
uniforme gebruikersinterface te kunnen creëren voor het
uitvoeren van verschillende taken om het gebruik van het systeem
eenvoudig te houden en de werking transparant. Meer over de
client-functies is te vinden in paragraaf 3.5 van (WfMC, 1994b).
Figuur 6 Relaties tussen basiselementen
van een workflow systeem (WfMC, 1996a)
In veel gevallen bestaat de behoefte om een workflow systeem te integreren met bestaande applicaties om een efficiënte en gemakkelijke uitvoering van een proces of procedure mogelijk te maken. Zo kan bijvoorbeeld een connectie nodig zijn met een mainframe voor het ophalen van gegevens, kan een fax- of e-mailservice opgeroepen worden, enzovoort. Meer algemeen wordt gesteld dat een invoked application ingeroepen wordt voor de uitvoering van een volledig of gedeeltelijk geautomatiseerde activiteit of om ondersteuning te bieden aan de gebruiker bij het verwerken van work items uit de worklist. De applicaties die hierbij gebruikt worden kunnen gestart worden door de workflow engine of door een workflow client application. Er worden twee manieren vooropgesteld om interactie met bestaande applicaties mogelijk te maken:
De invoked applications worden besproken in paragraaf 3.6 (WfMC, 1994b).
Essentieel voor de Workflow Management Coalition is het opstellen van een raamwerk dat verschillende systemen van verschillende leveranciers en met verschillende achtergrond in staat stelt samen te werken. Dit samenwerken kan variëren van "samen bestaan" tot en met "common look and feel" van quasi identieke producten. De Coalitie relativeert echter zelf de haalbaarheid van een ultieme vorm van coöperatie:
"The greatest
level of integration is unlikely to be available generally as it
relies on a commonality of approach by a wide variety of
developers deep in their products where it is likely that healthy
innovation is rife." (WfMC, overview.html)
Interoperabiliteit tussen software componenten kan algemeen gesteld op vier manieren mogelijk gemaakt worden (WfMC, 1996c):
Figuur 7 Directe interactie tussen software componenten (WfMC, 1996c)
Figuur 8 Interactie tussen software
componenten door message passing (WfMC, 1996c)
Figuur 9 Gateway voor interactie tussen
componenten (WfMC, 1996c)
Figuur 10 Interactie door middel van
gedeelde opslag (WfMC, 1996c)
Op dit ogenblik worden volgende mogelijke niveaus van interoperabiliteit naar voor geschoven:
De documenten (WfMC, 1996c) en (WfMC, 1996d) van de Coalitie hebben specifiek betrekking op interoperabiliteit.
Hieronder ressorteren de toepassingen die een beeld moeten geven van de toestand van de verschillende werkstroominstantiaties die op elk ogenblik op eender welke plaats van het workflow management systeem in uitvoering zijn. Het is op basis van gegevens die door deze systemen worden veschaft dat men in staat moet zijn (in het beste geval) om werklast dynamisch te gaan heralloceren. Bij voorkeur moet het ook mogelijk zijn simulaties te maken en voorspellingen op te stellen met betrekking tot de te verwachten werklast op verscheidene plaatsen in het systeem.
De interface standaard is op het ogenblik van schrijven nog maar in "1.0-versie" en beschrijft de informatiebehoeften om een audit- en monitoringsysteem mogelijk te maken. Deze informatie wordt Common Workflow Audit Data (CWAD) genoemd. Het is de bedoeling dat de auditsystemen van de ene leverancier kunnen aangewend worden om workflow enactment service engines van andere leveranciers op te volgen.
Bij workflow systemen wordt een onderscheid gemaakt tussen gegevens die gebruikt worden in het ondersteunde proces, gegevens die de werkstroom sturen en controleren en gegevens die de werkstroom modelleren en definiëren.
De structuur en het model van de werkstroom zijn vervat in de process definition data.
Workflow control data zijn de enige gegevens waartoe de engine rechtstreeks toegang heeft en worden gebruikt door een workflow engine om intern de status van processen en activiteiten (onder andere) bij te houden en om eventueel bijkomende statusinformatie te leveren (werklast, up-time en dergelijke meer). Ze zijn niet rechtstreeks toegankelijk voor client applicaties.
Onder werkstroom relevante gegevens (workflow relevant data) worden die gegevens verstaan die gegenereerd worden door werkstroomtoepassingen en op basis waarvan de workflow engine routing beslissingen neemt en toestandsovergangen van processen in uitvoer bepaalt. Deze gegevens moeten dus kunnen uitgewisseld worden met client en invoked applications.
Andere gegevens,
toepassingsgegevens of application data, kunnen wel door
de engine worden getransporteerd om aangereikt te worden aan
toepassingen die voor het uitvoeren van het gemodelleerde proces
noodzakelijk zijn, maar kunnen door de engine niet bewerkt
worden.
Figuur 11 Plaatsing van de soorten data
(WfMC, 1996a)
Communicatie tussen
de workflow enactment service en de workflow client gebeurt in de
context van de workflow server, die de run time omgeving vormt
voor instantiaties van processen en activiteiten. Die maakt het
mogelijk dat via de enactment service gefilterde opvragingen
kunnen gebeuren over gegevens van objecten die beheerd worden
door de betreffende enactment service. Indien de vragende partij
geauthoriseerd is deze gegevens op te vragen, worden de
resultaten van dergelijke queries via WAPI overgemaakt aan de
client applicatie die de query startte. In het objectmodel dat de
gegevens modelleert die door de workflow client gemanipuleerd
worden, is daarom een filterobjecttype opgenomen en een
objecttype onder de naam Object Collection Type die de samenhang
tussen workflow server en filter weergeeft (zie Figuur 12).
Figuur 12 Uitgebreid object model met
filtermodule en Object Collection Type (WfMC, 1996e)
Concrete systemen voor het doorgeven van workflow relevant data en application data zijn er nog niet. Onder andere de volgende elementen vormen onderwerp voor verdere studie:
Voor de uitwisseling van toepassingsgegevens (application data) wordt een onderscheid gemaakt tussen directe en indirecte uitwisseling (direct interchange en indirect interchange). Bij directe gegevensuitwisseling is er geen onderscheid te maken tussen de fysieke gegevensstroom en de besturingsstroom ; de gegevens maken expliciet deel uit van de navigatie. Een typisch voorbeeld hiervan is e-mail. Om het uitwisselen van informatie mogelijk te maken dienen nog systemen vastgelegd te worden die informatie bijhouden omtrent het oorspronkelijke gegevensformaat. (Een voorbeeld hiervan is te vinden in RFC-1341 met betrekking tot inkapseling van internet MIME e-mail in X.400 boodschappen). In het geval van indirecte uitwisseling vindt geen fysieke verplaatsing van gegevens plaats, maar maakt de toepassing gebruik van een specifiek toegangspad naar de gegevens, eventueel binnen een netwerkomgeving. In dit geval dient het toegangspad vast te liggen in de procesdefinities of moet het doorgegeven worden tussen de toepassingen. In een omgeving waar heterogene systemen gebruikt worden kunnen naamgevingen en toegangsrechten (directory services) hierbij een probleem gaan vormen. Daarenboven zullen in sommige gevallen twee client toepassingen hetzelfde gegevensformaat ondersteunen, in andere gevallen zal echter een vertaalslag nodig zijn (bijvoorbeeld voor verschillende tekstverwerkers).
Met de term WAPI of "Workflow APIs (Application Programming Interfaces) and Interchange Formats" wordt volgens de Workflow Management Coalition bedoeld,
De WAPI laat toe
front-end toepassingen te ontwikkelen die gebruik kunnen maken
van de verschillende diensten die geleverd worden door één of
meerdere workflow engines. Het is speciaal de bedoeling deze
diensten op een uniforme manier te kunnen aanvragen,
onafhankelijk van de oorsprong van de onderliggende
serversystemen. Daarnaast moet ze toestaan dat verschillende
onderliggende systemen met elkaar kunnen communiceren. Deze API's
dienen dus zowel voor verticale communicatie (tussen workflow
engine en omliggende componenten, en dit in de twee richtingen),
maar ook voor horizontale communicatie (tussen workflow engines
onderling) - zie Figuur 13.
Figuur 13 Gebruik van de WAPI voor
horizontale en verticale communicatie
De implementatie van de interfaces kan theoretisch in verschillende programmeeromgevingen gebeuren, maar gezien het wijd verspreide gebruik van de C-taal, zijn de eerste specificaties van de Coalitie hierin geschreven. De basis voor de ondersteunde functionaliteit wordt gegeven door onderstaand objectmodel (zie Figuur 14), dat de verhouding tussen de workflow server en de verschillende elementen van het uit te voeren werk weergeeft.
Details omtrent de
naamgeving van elementen gerelateerd tot de interfaces zijn terug
te vinden in "Workflow Client Application Application
Programming Interface (WAPI) Naming Conventions (WFMC-TC-1013,
15-May-96, 1.1)", opgesteld door de Workflow Management
Coalition, en nadere specificaties omtrent de C-implementatie en
ondersteunde functionaliteit in "Interface 2 - Workflow
Client Application Application Programming Interface (WAPI)
Specification (WFMC-TC-1009, 1-Oct-96, 1.2)", eveneens van
de Coalitie. Een voorbeeld van implementatie van C-datatypes is
opgenomen in paragraaf 3.2.5.3 "Illustratie van WAPI :
enkele datatypes en functies", p. 17.
Figuur 14 Objectmodel (WfMC, 1996e)
Volgende functies zijn momenteel gespecificeerd :
voor het leggen van een connectie tussen een aanroepende toepassing en een workflow server. Dit kan zowel connectiegeoriënteerd als connectieloos gebeuren. De server geeft een identificatie mee zodat de aanroepende applicatie een onderscheid kan maken tussen verschillende onderliggende serversystemen. De WAPI-functies worden zo opgemaakt dat ze protocol-neutraal zijn, en dus kunnen geïmplementeerd worden als local of remote procedure calls, als een messagingsysteem, als aanroepen naar database management systeem en zo verder. Ze zijn opgevat als blocking calls, en laten dus geen verdere verwerking van andere gegevens toe op de client nadat een call is gemaakt naar de workflow server. Daarnaast bevat de huidige uitgave van de WAPI geen specificaties voor asynchrone communicatie zoals call-back.
functies die de toestand van processen in uitvoer kunnen opvragen en veranderen, op aanvraag van een client applicatie. Hierdoor kan een bepaalde uitvoerder bijvoorbeeld een lijst opvragen van uit te voeren procedures en bepaalde processen starten, pauzeren of beëindigen of de prioriteit ervan wijzigen. Ze kunnen ook gebruikt worden door de systeembeheerder door middel van beheerstoepassingen. Volgens de specificaties van de Coalitie kan een proces zich in volgende toestanden bevinden:
- initiated : gecreëerd maar nog niet gestart
- running : klaar om activiteiten te starten
- active : er zijn activiteiten gestart en work items toegewezen
- suspended : onderbroken; er kunnen geen activiteiten gestart worden vooraleer het proces wordt hervat
- completed : normale beëindiging van het proces
- terminated : het proces is op abnormale wijze beëindigd
analoog aan de process control functions, maar deze keer met betrekking tot welbepaalde activiteiten in plaats van processen. Toestanden van activiteit instantiaties kunnen zijn :
- inactive : de precondities zijn (nog) niet voldaan
- active : er kunnen work items worden toegekend
- suspended : onderbroken; er kunnen geen work items worden toegekend vooraleer het proces wordt hervat
- completed : de activiteit is beëindigd en postcondities kunnen geëvalueerd worden
hiermee kan een uitvoerder de stand van zijn werk nagaan en een overzicht vragen van reeds gepresteerd werk en werk dat nog moet uitgevoerd worden door hemzelf of mede-uitvoerders. Deze gegevens kunnen dan geraadpleegd worden door de uitvoerders zelf of een manager die over het betreffende domein toezicht houdt.
opnieuw analoog, maar met betrekking tot activiteiten in plaats van processen.
een worklist is een lijst van work items die door een uitvoerder moeten afgehandeld worden. Een work item kan gezien worden als een eenheid van uitvoering. Een activiteit in uitvoering kan overeenkomen met verschillende work items, die eventueel met behulp van een computertoepassing worden uitgevoerd. Bijvoorbeeld : de activiteit kan eruit bestaan dat persoon X een bepaald document drie keer moet tekenen (drie items), waarbij hij een toepassing gebruikt die automatische handtekeningen genereert.
Er dient hier rekening gehouden te worden met het feit dat een activiteit uit meerdere work items kan bestaan, en dat op een bepaald ogenblik slechts een aantal ervan succesvol zijn uitgevoerd. Op basis hiervan kan de workflow engine dan uitvoeringspaden gaan selecteren voor verdere afhandeling van het proces waarvan de betreffende activiteit deel uitmaakte. De worklist functions bieden ondersteuning voor het opvragen van work items en het opnieuw toekennen van work items aan worklists van andere uitvoerders.
voor administratie en onderhoud van het systeem. Deze set interfaces implementeert momenteel slechts een aantal elementaire acties zoals het beëindigen van processen en activiteiten in uitvoering, of het aanpassen van de status ervan.
Voor de functionaliteiten van de huidige versie van WAPI zijn vertalingen naar OLE-objecten en OMG-IDL interfaces opgesteld. Voor OLE-automation ondersteuning wordt gewerkt aan WAPI2, die bijvoorbeeld ook exceptions moet kunnen genereren.
Om interoperabiliteit tussen verschillende platformen te bevorderen, heeft de Coalitie een naamgevingsconventie opgesteld. Deze wordt beschreven in het document "Workflow Management Coalition Interface 2 WAPI Naming Conventions" (Document Number WFMC-TC-1013). Andere doelstellingen bij dit opzet waren leesbaarheid en overdraagbaarheid (portability). Ook aan naamgevingsconflicten bij het linken van verschillende modules werd gedacht. Hiertoe werd bepaald dat alle functies uit de WAPI dienen voorafgegaan te worden door het prefix "WM" (van "Workflow Management"). Verder worden typedefinities gedefinieerd met het prefix "WMT" en pointers met "WMTP".
Deze naamgeving vermijdt enerzijds het dubbel gebruik van namen binnen de set API's zoals een welbepaalde leverancier van workflow software ze zou implementeren, anderzijds laat ze ook toe dat gebruikers de bibliotheken van verschillende leveranciers kunnen aanspreken zonder voor elke leverancier de broncode te moeten aanpassen.
typedef char WMTInt8;
typedef short WMTInt16;
typedef long WMTInt32;
typedef unsigned char WMTUInt8;
typedef unsigned short WMTUInt16;
typedef unsigned long WMTUInt32;
typedef WMTInt8 WMTText;
typedef WMTText *WMTPText;
typedef WMTInt8 *WMTPInt8;
typedef WMTInt16 *WMTPInt16;
typedef WMTInt32 *WMTPInt32;
typedef WMTInt8 WMTBoolean;
typedef WMTUInt8 *WMTPointer;
typedef WMTText *WMTPPrivate;
#define WMNULL ((WMTPointer)0)
#define WMFalse 0
#define WMTrue (!WMFalse)
strings worden verondersteld null-terminated te zijn en zijn maximaal 63 karakters lang :
#define NAME_STRING_SIZE 64
Toegepast in een veld dat gebruikt kan worden bij identificatie van gebruikers:
WMTText user_identification[NAME_STRING_SIZE];
dat een tekstdatatype definieert van 63 karakters.
typedef struct
{
WMTText user_identification[NAME_STRING_SIZE];
// The identification of the workflow participant on whose behalf the Workflow Application will be operating. The value specified may represent a human, a device, etc. This identification is normally used for security checking, accounting, etc.
WMTText password[NAME_STRING_SIZE];
WMTText engine_name[NAME_STRING_SIZE];
// The identification of the WFM Engine to whom the subsequent API calls are to be directed. This information would not be required for some WFM products in the normal case. However, it is required for those Workflow Applications which interact with multiple WFM Engines. This would be a symbolic name which is resolved through a lookup facility.
WMTText scope[NAME_STRING_SIZE];
// Identification of scope for the application. If scope is not relevant, then this field would be empty and ignored.
}WMTConnectInfo;
typedef WMTConnectInfo *WMTPConnectInfo;
Figuur 15 Illustratie van het gebruik
van de datatypes in C-code
(The workFlow Management Coalition)
Bij een workflow management systeem is er sprake van een combinatie van gecentraliseerde controle en lokale interactieve verwerking. Dergelijke tweeledige structuur leent zich uitstekend om gebouwd te worden volgens een client-server model. De client-server architectuur is een implementatie van een gedistribueerde architectuur. Maar een workflow systeem kan ook een gecentraliseerde aanpak volgen. Gezien de hogere complexiteit van een gedistribueerd systeem en de daarmee gepaard gaande hogere kost van onderhoud, is het waarschijnlijk dat gecentraliseerde systemen in de toekomst aan belang zullen winnen. Meer recente evoluties in de richting van performante grafische terminals en netwerk computers bevestigen de trend naar centralisatie. Open platformonafhankelijke ontwikkelomgevingen zoals Java kunnen best gebruikt worden om de client zijde van dergelijk systeem te bouwen. In combinatie met encryptie- en beveiligingstechnieken kunnen dan zelfs client-applicaties gemaakt worden als zogenaamde plug-ins voor webbrowsers, waardoor elke PC die geconnecteerd is met het wereldwijde Internet als workflow client dienst kan doen.
Door het gebruik van platformonafhankelijke clients kan tegen geringe kost op vrij eenvoudige wijze de reeds bestaande infrastructuur aangewend worden om als workflow client te fungeren. Aangezien workflow systemen vaak geïmplementeerd worden als aanvulling op reeds bestaande applicaties, kan hierdoor de kost voor overschakeling naar een nieuw systeem voor elke client vermeden worden waardoor een grote uitgavenpost wegvalt. Doordat de client applicaties bovendien geladen worden van de server (eventueel een bestaande mainframe) en de uitvoerbare bestanden platformonafhankelijk zijn, wordt het onderhoud heel wat eenvoudiger. Tenslotte bestaat in heel wat gevallen ook de wens om de bestaande beveiligings- en opslagmogelijkheden van de centrale (mainframe) systemen te kunnen benutten.
In onderstaande
modellen wordt een voorbeeld gegeven van twee mogelijke
scenario's voor de implementatie van een workflow management
systeem. Er is hierbij een onderscheid gemaakt tussen de worklist
handler en de workflow client. De basis voor deze tweedeling ligt
in het functioneel onderscheid dat kan gemaakt worden tussen 'worklist
manipulation' en bijkomende procescontrole, zoals aangehaald
in paragraaf 3.2.5.1 "Workflow Client Applications",
p. 17.
Figuur 16 Workflow management systeem
volgens client-server architectuur
Figuur 16 geeft een beeld van een workflow management systeem dat volgens een client-server model is gebouwd. De centrale workflow server zorgt voor het beheer van de workflow control data, workflow relevant data en process definitions. Deze server communiceert met een DBMS-server voor het uitwisselen van gegevens uit de corporate database voor verwerking door de workflow client. Eventueel beheert de database server ook de eerdervermelde werkstroomgegevens. In dat geval kunnen de bestaande functionaliteiten van het database systeem overgenomen worden, zoals commit & rollback, transactiebeheer en gegevensintegriteit. De DBMS-server kan met de workflow engine communiceren via interface 4 van de WAPI (bijvoorbeeld voor een Lotus Notes database), door middel van een gateway, of eventueel als een client application via interface 2. De work items worden over het netwerk doorgegeven aan de worklist handler, door messaging of door het aanroepen van een remote procedure. De berichten of RPC's kunnen bijvoorbeeld verstuurd worden als Novell IPX pakketten over een Netware lokaal netwerk, of als TCP/IP pakketten via het Internet of een intranet. Eventueel worden grote documenten op voorhand doorgestuurd en opgeslagen aan de client zijde (prefetching), om aldus de wachttijd voor communicatie in te korten of te vermijden. De communicatielaag verzorgt de diensten uit het OSI-model, met name de functies met betrekking tot het opzetten van sessies, het verzekeren van betrouwbaar transport en functies uit de netwerk, datalink en fysieke laag. Daarnaast kan ze zorgen voor compressie en encryptie faciliteiten en omzetting van de gegevens naar een uitwisselingsformaat dat door de WAPI wordt ondersteund. De client applicatie verzorgt de standaard client functionaliteiten zoals verwerking en opvolging van de work items en presentatie aan de gebruiker(s). Desgevallend kunnen via OpenDoc of DDE/OLE interfaces lokale applicaties worden opgeroepen voor verwerking van objecten die zitten ingekapseld in de te bewerken work items of documenten. Deze al dan niet bestaande toepassingen kunnen op hun beurt via middleware diensten aanvragen bij een DBMS-server voor het rechtstreeks consulteren of bijwerken van de bedrijfsdatabases.
Volgens een ander
model (Figuur 17) worden de functies van de worklist handler
eveneens door de workflow server uitgevoerd. Eventueel kan
hiervoor een dedicated server worden ingezet. In een
gecentraliseerde omgeving zou een mogelijk scenario kunnen zijn
dat werkstations of netwerk computers de client applicatie als
platformonafhankelijke Java-toepassing binnenhalen. De
applicaties die nodig zijn voor het bewerken van in work items
ingesloten objecten, zoals viewers of editors, kunnen dan als
applets worden meegestuurd in de vorm van workflow application
data of op aanvraag worden doorgestuurd.
Figuur 17 Alternatieve architectuur voor
client-server omgeving
De conformiteitsregels werden vastgelegd voor elke interface apart en op verschillende niveaus voor elk van de interfaces. Op die manier verplicht men producenten niet om conformiteit van hun product op te geven door niet aan de implementatieregels van één van de interfaces te voldoen. Zo kunnen verschillende functionele componenten van een workflow systeem afgesloten blijven voor andere systemen (als er gebruik gemaakt wordt van zogenaamde embedded interfaces), terwijl naar andere componenten wel open interfaces voorzien worden (dit zijn dan exposed interfaces).
Een bepaald conformiteitsniveau groepeert een bepaalde set van API's, uitwisselingsformaten en protocolondersteuningen. Wat bijvoorbeeld API's betreft, geldt dat opdat een product zou geklasseerd worden in één van de niveaus, het een minimale set van verplichte API's moet ondersteunen. Als bovendien een optionele functionaliteit ondersteund wordt, moeten de API's die deze aanroepen voldoen aan de standaarden die voor die optionele functionaliteit werden uitgewerkt.
Wanneer een nieuw proces of een nieuwe activiteit gestart wordt, valt de verantwoordelijke workflow engine terug op de process definition data voor het correct creëren van zo'n process instance of activity instance.
Het is mogelijk dat deze definitiegegevens echter door meerdere engines gebruikt worden en gedistribueerd opgeslagen zijn over meerdere engines. Ook voor de uitwisseling van deze definities (in server context) kan van de WAPI gebruik gemaakt worden. Daarenboven moet de mogelijkheid voorzien zijn om processen of activiteiten uit te besteden aan een andere (eventueel heterogene) workflow enactment service of workflow engine. Vandaar dat de WAPI ook interfaces moet bevatten voor het uitwisselen van application data en interfaces voor het uitwisselen van controledata tussen engines en/of enactment services (bijvoorbeeld voor synchronisatie).
Het gebruik van interfaces voor het fysiek uitwisselen van data houdt in dat elke component van het model mogelijks gebruikt maakt van lokale opslag van gegevens, waarvan de structuur lokaal aangepast wordt naar een uitwisselingsformaat dat geschikt is om doorgegeven te worden via de WAPI naar een andere component. Bij voorkeur dienen deze componenten dan ook over eigen faciliteiten te beschikken voor bescherming tegen calamiteiten, en wegens de noodzaak aan samenwerking ook voor gedistribueerde transactieverwerking. De communicatie die plaatsvindt in het kader van synchronisatie en gedistribueerde transactieverwerking zal dus moeten gebeuren in de vorm van workflow relevant data. Specifieke interfaces naar database management systemen en traditionele transactiesystemen zijn niet voorzien, en bieden overigens ook geen soelaas. Workflow management systemen zijn van nature zo verschillend, dat een geheel nieuwe aanpak nodig is op het vlak van transactiebeheer. Hier wordt verder op ingegaan bij de bespreking van FlowMark ("Modellen voor transactiebeheer", p. 17).
In het geval waarbij de gegevens niet fysiek worden uitgewisseld via interfaces dient een systeem uitgewerkt te worden waarbij de toegangspaden naar toepassingsgegevens zijn vastgelegd in de (gemeenschappelijke) procesdefinities, of waarbij deze paden worden uitgewisseld bij het navigeren tussen de activiteiten (WfMC, 1996e).
Er komen vermoedelijk wel nog uitbreidingen op de interfaces die een verdergaande manipulatie van gegevens toelaten. Maar een standaardisatie van de opslag van gegevens is niet vooropgesteld (Aldridge, §"Data-access & storage").
De WAPI is niet verplichtend ten aanzien van de mechanismen waarmee producten informatie met andere producten uitwisselen. RPC's, message queues, OLE en shared databases behoren onder meer tot de mogelijkheden. Daarnaast kunnen gegevens hetzij atomair, hetzij in batch uitgewisseld worden en dit in half-duplex of full-duplex. Deze grote vrijblijvendheid kan een belemmering vormen voor systemen van verschillende leveranciers om samen te werken (Wieringa, 1995).
Een aspect dat de komende jaren een belangrijke rol kan gaan spelen door de ontsluiting van het Internet, is de beveiliging van transacties over een netwerk. Men mag verwachten dat klanten rechtstreeks een bestellingen kunnen plaatsen bij de leverancier. Dit kan bijvoorbeeld gebeuren via EDI of door het werkstroomsysteem uit te breiden naar de klant toe. In het laatste geval moet de workflow server over de nodige beveiligingsmechanismen beschikken, en in dit kader zijn de structuren die enkel paswoordverificatie implementeren ruim onvoldoende.
Een mogelijke oplossing kan er in bestaan om de WAPI uit te breiden met routines voor de aanroep van bibliotheken met versleutelingstechnieken, zoals RSA dubbele sleutel encryptie. Dergelijke systemen kunnen dan bovendien gebruikt worden voor het digitaal signeren van documenten. Daar staat tegenover dat een wettelijke kader omtrent het gebruik van encryptietechnieken en digitale handtekeningen in heel wat landen ontbreekt of slecht is uitgewerkt. Daarenboven kunnen wettelijke bepalingen het gebruik van versleutelingstechnieken beperken of helemaal verbieden.
Wat de conformiteitsprincipes betreft is het de vraag of er een objectieve maatstaf zal gevonden worden om te bepalen welke voorwaarden moeten vervuld zijn om een bepaald niveau van conformiteit te bereiken.
Gezien er reeds een belangrijk aantal producten op de markt zijn, en aangezien het merendeel van de producenten vertegenwoordigd is binnen de Coalitie, is het niet ondenkbaar dat deze voorwaarden zullen vastgelegd worden op basis van commerciële machtsverhoudingen. Het grote aantal niveaus van conformiteit, gekoppeld aan het aantal interfaces en de vraag omtrent de volledigheid van het model, stemt wel tot nadenken omtrent de bruikbaarheid van zo'n benadering. Het probleem doet zich in het bijzonder voor bij de vierde interface. Nochtans is interoperabiliteit van workflow management systemen onderling, van de workflow engines met andere woorden, één van de pijlers die aan de basis van de standaardisatiepoging lag. Het kan een hele klus worden om uit te maken of een product al dan niet voldoet aan alle vereisten nodig voor integratie met verschillende andere ICT-systemen. Als het voor de klant dan bovendien nog moeilijk is om een projectie te maken van de toekomstige behoeften aan integratie, dan bestaat ook nog het risico dat het ganse idee van "standaardisatie" een maat om niets is geweest. Dit probleem wordt ten andere ook door de Coalitie onderkend. Er zijn scenario's voor interoperabiliteit uitgewerkt die variëren van eenvoudig tot zeer complex, en de discussie ten gronde omtrent deze classificatie werd tot op heden nog niet gevoerd.
Hoewel het de doelstelling is van de Workflow Management Coalition om een open model voor workflow management systemen te creëren, is er nooit een keuze gemaakt voor een welbepaald objectmodel (omwille van tegengestelde belangen van de leden van de Coalitie, zoals Microsoft en IBM ?). Toch zal een implementatie bij voorkeur moeten gebeuren op basis van een bepaald objectmodel. Op plaatsen waar deze niet compatibel zijn, moet gebruik gemaakt worden van vertalers die specificaties van de ene standaard omzetten in specificaties van de andere. Dit is een omweg en heeft hoogstwaarschijnlijk gevolgen voor performantie en functionele compatibiliteit.
Voorlopig kunnen de
verschillende tekorten een basis vormen voor het onderscheid
tussen verschillende workflow management systemen buiten de
standaarden om of als toevoeging aan de standaarden. Het is
echter gewenst dat er snel werk gemaakt wordt van de uitbreiding
van de WAPI. Zoniet bestaat het gevaar dat men met een
structureel zeer goed raamwerk zit dat uiteindelijk in geen enkel
product wordt toegepast. En gezien het vrij grote succes van
werkstroomondersteunende systemen kan men stellen dat de tijd
dringt. Ondertussen doet de Coalitie er goed aan de constructeurs
te verzoeken om API's, zoals gepubliceerd door de Coalitie, ook
effectief te implementeren, naast die interfaces die misschien
verdergaande functionaliteit aanbieden en mogelijks volgens een
eigen model zijn geconstrueerd. Op die manier maakt de klant een
keuze tussen verregaande mogelijkheden voor schaalbaarheid -door
gebruik te maken van andere producten die aan de specificaties
van de WfMC voldoen- en extra functionaliteit naast diegene die
door de Coalitie is gedefinieerd.
Beoordeling van een aantal workflow management producten
© Filip Schepers, 1997 - Thesis: Standaardisatie van workflow management systemen en beoordeling van een aantal producten.