Toevoeging van werkstroomfunctionaliteit aan bedrijfsapplicaties (‘workflow-enabling’) vereist de scheiding tussen proces- en applicatielogica in de applicatie. Via twee technische oplossingen is te bereiken dat voor de gebruiker één logisch en samenhangend geheel ontstaat. Twee organisatie-adviseurs over de noodzakelijke voorwaarden, het belang van standaardisatie, en de relevante eigenschappen van op de markt beschikbare wfm-systemen.
Het uitbreiden van een bedrijfsapplicatie met werkstroomfunctionaliteit (workflow-enabling) staat momenteel sterk in de belangstelling. Ook het recent door Cap Gemini Ernst & Young uitgevoerde onderzoek naar werkstroombeheersystemen op de Nederlandse markt besteedde hieraan aandacht.
Een van de definities van ‘workflow-enabling‘ luidt: het opnemen van functionaliteit in een bedrijfsapplicatie, gericht op het besturen van werkstromen, waarbij de applicatie en de procesbesturingscomponent rechtstreeks met elkaar kunnen communiceren. Hierdoor lijkt voor de gebruiker het systeem één geheel, terwijl er intern in de bedrijfsapplicatie een scheiding wordt aangebracht tussen de proces- en applicatielogica.
De definitie is zowel gericht op de functionele aspecten van workflow management (het besturen en beheersen van werkstromen) als op de technische aspecten die om de hoek komen kijken bij het uitbreiden van een bedrijfsapplicatie met werkstroom-functionaliteit.
Essentie is dat voor de gebruikers een uniforme omgeving wordt gecreëerd, door de procesbesturing nauw te integreren met de applicaties die de gebruiker nodig heeft bij zijn werkzaamheden.
In het kader van dit artikel beschouwen wij zowel een directe koppeling tussen een applicatie, als een applicatie met een geïntegreerde ‘werkstroom-engine’ (‘embedded workflow’), als ‘workflow-enabling’. Met deze beide technische oplossingen (direct en ingebed) kan worden bereikt dat voor de gebruiker één logisch en samenhangend geheel wordt gecreëerd. Het is hierbij essentieel dat er in de bedrijfsapplicatie (het geheel van applicatie- en proceslogica, inclusief de bijbehorende gegevens) een scheiding wordt aangebracht tussen de applicatie- en proceslogica.
Voordelen
Er zijn verschillende overwegingen die ten grondslag liggen aan het besluit applicaties uit te breiden met werkstroomfunctionaliteit. Enkele overwegingen kunnen zijn het veilig stellen van investeringen in bestaande applicaties, integrale procesbesturing, het verzorgen van de aansluiting tussen frontoffice en backoffice en flexibiliteit in de modellering van processen.
Bij de afweging om al dan niet werkstroomfunctionaliteit tot te voegen dient rekening te worden met zowel de voor- als nadelen. Allereerst de voordelen.
Flexibiliteit bij veranderingen in het procesmodel en complexiteitsreductie. Een van de grootste uitdagingen bij het toevoegen van werkstroomfunctionaliteit is dat zodanig te doen, dat het model van de bedrijfsprocessen kan worden gewijzigd zonder dat hiervoor de onderliggende applicaties hoeven te worden aangepast. Er dient een dermate flexibele combinatie te ontstaan dat het mogelijk wordt om in het model van het onderliggende bedrijfsproces bijvoorbeeld de volgorde van taken te wijzigen, taken te combineren of juist te splitsen, en andere rollen te koppelen aan taken. Hierbij dient te worden aangetekend, dat het een illusie is te denken dat de bedrijfsapplicatie nooit meer hoeft worden aangepast. Indien een proceswijziging invloed heeft op de vast te leggen bedrijfsgegevens en applicatielogica, zullen in de onderliggende applicatie wijzigen moeten worden doorgevoerd.
Eenvoudiger koppeling van applicaties aan verschillende ‘werkstroom-engines’. Door bedrijfsapplicaties uit te rusten met een communicatielaag ten behoeve van uitbreiding met werkstroomfunctionaliteit, wordt het gemakkelijker ze te koppelen aan andere werkstroombeheersystemen. Ook wordt het gemakkelijker om verschillende bedrijfsapplicaties van verschillende leveranciers te koppelen aan één ‘wfm-engine’. Dit wordt duidelijk als we een bedrijfsapplicatie beschouwen waarbij de communicatie is gerealiseerd door middel van WfMC-standaard (Workflowmanagement Coalition) WAPI-aanroepen (Workflow Application Programmer Interface). Een vervanging van de bestaande ‘werkstroom-engine’ door een andere betekent in dit geval theoretisch gezien geen wijziging voor de applicatie, de ‘engines’ spreken immers dezelfde taal.
Hergebruik applicatielogica-componenten. Door het ontbreken van procesbesturing tussen de applicatielogica-blokken (componenten) binnen een applicatie, wordt het hergebruik van deze componenten binnen een procesmodel mogelijk zonder hiervoor de onderliggende applicatie aan te passen. De onderliggende applicatie dwingt immers geen bepaalde volgorde van uitvoering van componenten af. Bovendien komen we hiermee bij nog een ander voordeel, namelijk de onderhoudbaarheid van een applicatie.
Nadelen
Naast bovenstaande voordelen is tevens een aantal nadelen te onderkennen.
De benodigde inspanning om een ‘workflow enabled’ bedrijfsapplicatie te realiseren. Bij het toepassen van ‘workflow-enabling’ in nog te realiseren bedrijfsapplicaties, zal het relatief veel tijd kosten dit concept verder uit te werken tot een standaard werkwijze. Hierbij denken we onder andere aan het identificeren en verwijderen van de procesbesturing uit onderliggende applicaties en het opstellen van een standaard wfm-communicatie-laag.
Inherente afhankelijkheid van werkstroomfunctionaliteit. Het uitbreiden van een bedrijfsapplicatie met werkstroomfunctionalitiet kan ook een keerzijde hebben. Omdat de applicatie immers geen besturingslogica meer bevat, is het inherent afhankelijk van een wfm-systeem. Dit kan een nadeel zijn, indien men de applicatie wil inzetten in een organisatie die – om welke reden dan ook – geen werkstroombeheersysteem wil implementeren.
Onduidelijkheid over industriestandaarden. Het toepassen van ‘workflow-enabling’ vereist in eerste instantie het maken van keuzes. Welke communicatiemechanismen dient de communicatielaag te ondersteunen gezien de mogelijkheden die de huidige (of toekomstige) wfm-systemen bieden? Hoe krijgt de communicatie tussen de communicatielaag en de applicatielogica gestalte? Het ontbreken van één duidelijke industriestandaard waaraan iedereen zich conformeert brengt het risico met zich mee dat investeringen in ‘workflow-enabling’ niet altijd worden gewaarborgd. Dit wordt duidelijk indien er op enig moment een marktstandaard wordt aangenomen die afwijkt van de door een bedrijf gekozen standaard. Mogelijk dient de werkstroomoplossing waarvoor is gekozen, dan te worden aangepast aan de nieuwe standaarden om zodoende de compatibiliteit met bijvoorbeeld ‘wfm-engines’ te kunnen garanderen.
Belang van standaardisatie
Standaardisatie bij het toepassen van ‘workflow-enabling’ is essentieel, omdat organisaties anders met verschillende ‘werkstroom-engines’ in applicaties worden geconfronteerd die niet met elkaar kunnen communiceren. Ook is het belangrijk bij het gebruik van applicaties die zijn uitgebreid met werkstroomfunctionaliteit met verschillende ‘werkstroom-engines’.
Een orgaan dat zich richt op het formuleren van standaarden voor de industrie van werkstroombeheer is de Workflow Management Coalition (WfMC). Het WfMC fungeert als een ontmoetingsplaats voor onderzoekers, gebruikers en ontwikkelaars van wfm-systemen. Het is een internationaal standaardisatie-orgaan, dat onder meer de standaard-referentie-architectuur voor wfm-systemen heeft vastgesteld.
In figuur 1 is aangegeven welke leveranciers die aan het onderzoek ‘Trends in workflow management’ hebben deelgenomen, zich conformeren aan de WfMC-standaarden. Deze standaarden zijn onder meer uitgewerkt in vijf interfaces.
Interface 1 is gericht op standaarden voor de uitwisseling van procesmodellen. Interfaces 2 en 3 zijn opgesteld om de interactie tussen de werkstroomclient en een client-applicatie te standaardiseren. De vierde interface geeft aan op welke wijze verschillende ‘werkstroom-engines’ (van verschillende leveranciers) onderling kunnen communiceren. De vijfde interface geeft ten slotte aan op welke wijze, over meerdere werkstroomsystemen heen, informatie is te verkrijgen over het verloop van het proces (audit-gegevens). In de figuur is tevens aangegeven of de leverancier lid is van de WfMC, hiermee aangevende dat zij zich inspannen voor de doelstellingen van de WfMC en zich willen conformeren aan de standaarden.
WAPI’s
De standaarden op dit gebied, die in het kader van dit artikel van belang zijn, zijn verwoord in interface 2 (in de meest recente versie van interface 2 is tevens interface 3 opgenomen). Voor de verschillende interfaces zijn zogenaamde WAPI’s gedefinieerd (Workflow Application Programming Interface).
Met het definiëren van WAPI’s voor de integratie met applicaties wil men mogelijk maken dat ‘workflow-enabling’ van bedrijfsapplicaties op een gestandaardiseerde manier wordt uitgevoerd.
Verder wil men de ontwikkeling van gestandaardiseerde applicatie-agents mogelijk maken om een gelijksoortige manier van integratie te kunnen realiseren voor applicaties die niet zijn uitgebreid met werkstroomfunctionaliteit.
Indien een wfm-systeem zich volledig conformeert aan de standaarden van het WfMC, zit de organisatie die het systeem gebruikt, niet vast aan een specifiek systeem. Met behoud van de investeringen in de koppelingen met applicaties is eventueel gebruik te maken van een andere ‘werkstroom-engine’.
Als een organisatie kiest voor ingebedde werkstroomcomponenten, kunnen ook de aanvullingen van de Object Management Group (OMG) van belang zijn. Ook de OMG is een samenwerkingsverband van verschillende leveranciers. Het doel van de OMG is om een standaard te ontwikkelen voor op componenten gebaseerde software. Op het gebied van werkstroom zijn deze standaarden gebaseerd op de terminologie van de WfMC.
Voorwaarden
Een belangrijk uitgangspunt bij het uitbreiden van een bedrijfsapplicatie met werkstroomfunctionaliteit is de scheiding tussen de proces- en applicatielogica in een applicatie. Nadat het gegevensbeheer door databasemanagementsystemen en de gebruikersinterface zijn losgekoppeld van de applicatie, volgt de ontkoppeling van de proceslogica van de applicatielogica (bedrijfsinformatie). De scheiding die wordt aangebracht tussen de besturing en de uitvoering van het proces is te beschouwen als essentie van werkstroombeheer [1]. Voor de besturing is informatie over het proces nodig, voor de uitvoering is bedrijfsinformatie nodig.
De procesbesturingscomponent kan vervolgens worden gebruikt om een bedrijfsapplicatie (of meerdere) uit te breiden met werkstroomfuctionaliteit. De vraag naar ‘workflow enabled’ bedrijfsapplicaties ontstaat onder meer doordat veel organisaties gebruikmaken van meerdere applicaties die een bepaalde mate van proceslogica bevatten. Hierbij is het wenselijk dat de verschillende procesbesturingscomponenten informatie en werkorders met elkaar kunnen uitwisselen, zodat er voor de gebruiker een logisch geheel ontstaat. Om dit mogelijk te maken, is het belang van standaardisatie evident.
Daarnaast kunnen zowel aan de ‘wfm-engine’ als aan de applicatie voorwaarden worden gesteld voor het uitbreiden van een bedrijfsapplicatie met werkstroomfunctionaliteit. Allereerst de ‘wfm-engine’.
Deze moet applicatielogica kunnen activeren. Alleen dan ontstaat er voor een gebruiker een beeld van geïntegreerde bedrijfsapplicatie.
Ten tweede zal de ‘engine’ in staat moeten zijn informatie door te geven aan de applicatielogica. Het zal vaak blijken dat ten behoeve van een taak specifieke bedrijfsinformatie nodig is. De relatie tussen de taakidentificerende gegevens en de bedrijfsgegevens kan worden vastgelegd in de bedrijfsgegevenslaag. Door taakidentificerende informatie door te sturen naar de communicatielaag van de applicatie, zijn bedrijfsgegevens te verkrijgen.
Een derde voorwaarde is dat de wfm-engine in staat moet zijn informatie te ontvangen, bijvoorbeeld bedrijfsgegevens via de applicatielogica die wordt geïnterpreteerd door de wfm-engine, teneinde een routekeuze te maken binnen het bedrijfsproces.
Ook de applicatie moet aan een aantal voorwaarden voldoen.
In de eerste plaats zal de applicatie ‘van buitenaf’ aangeroepen moeten kunnen worden. Het moet mogelijk zijn gegevens van buitenaf te ontvangen en naar buiten aan te bieden. Binnen de applicatielogica is geen processturing. De applicatie moet de mogelijkheid bieden om functionaliteit van de ‘werkstroom-engine’ aan te spreken. Ten slotte moet de applicatie-communicatielaag op een of andere manier in staat zijn om benodigde bedrijfsgegevens te verkrijgen op basis van de kenmerken c.q. gegevens van een werkorder (‘case’).
Opnemen van werkstroomfunctionaliteit
Wij onderscheiden globaal vier mogelijkheden om een applicatie te voorzien van werkstroomfunctionaliteit.
De eerste mogelijkheid is het koppelen van de ‘werkstroom-engine’ met een applicatie via een (gestandaardiseerde) API-communicatielaag, zodanig dat het wfm-systeem kan communiceren met bepaalde taakondersteunende gedeelten van de applicatie. Bijvoorbeeld een orderinvoercomponent ten behoeve van de taak ‘registreren klantorder’. De communicatie tussen het wfm-systeem en de applicatie kan nu direct plaatsvinden, zonder dat hier een bepaalde tussenschakel nodig is. Hiermee wordt een ‘workflow-enabled’ bedrijfsapplicatie gecreëerd. Zowel de ‘werkstroom-engine’ als de applicatie moeten in staat zijn gebruik te maken van een (gestandaardiseerde) API-laag.
Een andere mogelijkheid is het opnemen (‘inbedden’) van het geheel of een deel van de werkstroomfunctionaliteit in een bedrijfsapplicatie. Zo kunnen werkstroominterfacecomponenten of de volledige ‘werkstroom-engine’ worden geïntegreerd. Hierbij is bijvoorbeeld gebruik te maken van DCOM of Corba-componenten.
De derde mogelijkheid betreft het opnemen (inbedden) van componenten van de applicatie in het wfm-systeem. Net als optie 2 sluit deze mogelijkheid aan bij de opmars van ontwikkelen op basis van componenten. Beide opties kunnen leiden tot een architectuur waarbij we drie lagen onderscheiden:
applicatie- en procesgegevens/dbms; applicatielogica/applicatie; proceslogica/werkstroom-engine.
Tenslotte kan werkstroomfunctionaliteit worden gekoppeld met een bedrijfsapplicatie door gebruik te maken van een ‘application agent’. Dit is een stukje software dat kan worden gebruikt om twee applicaties met elkaar te laten communiceren, door de rol van vertaler op zich te nemen. Hierbij worden, zowel in de aangeroepen applicatie als in het wfm-systeem, geen aanpassingen gemaakt. Typische bedrijfsapplicaties die worden gekoppeld met behulp van agents zijn kantoorautomatiseringapplicaties en legacy-systemen. Het gaat hier om systemen, waarbij het niet gewenst of onmogelijk is deze aan te passen. Overeenkomstig onze definitie beschouwen we deze laatste optie niet als ‘workflow-enabling’.
Integratiemogelijkheden
In het onderzoek ‘Trends in Workflow Management’ is een apart hoofdstuk gewijd aan de integratiemogelijkheden die de deelnemende systemen bieden. In dit kader is onder meer gevraagd naar de beschikbaarheid van API’s en de daarbij behorende documentatie. Deze vormt voor systeemontwikkelaars een handleiding bij het ontwikkelen van applicaties waarin zij bepaalde API’s van het wfm-systeem willen aanroepen. Indien aan deze twee voorwaarden wordt voldaan, voldoet het systeem aan de basiseisen op het gebied van API’s. Om API’s te kunnen gebruiken, is het veelal nodig om te programmeren. Sommige API’s zijn specifiek geschikt voor een bepaalde programmeertaal. De mogelijkheid van koppeling met programmeertalen is als een aanvullende functionaliteit beschouwd.
Basisfunctionaliteit refereert naar de aspecten die een systeem minimaal moet bieden om de betreffende functionaliteit te kunnen ondersteunen; aanvullende functionaliteiten daarentegen zijn extra’s.
Het overgrote deel van de onderzochte systemen (80 procent) biedt API’s aan die veelal ook zijn gedocumenteerd. Enkele leveranciers die momenteel nog lager scoren op dit gebied, geven aan in volgende versies uitbreidingen op te nemen van de bestaande API-set.
Uit figuur 2 blijkt dat Corsa Case geen API’s biedt terwijl Document Manager slechts een koppeling met een programmeertaal kent, waarbij ook geen gebruik kan worden gemaakt van standaard API’s.
Naast de hierboven genoemde mogelijkheden zijn er allerlei tussenvormen te bedenken om koppelingen te realiseren. De bedrijfsapplicaties en het wfm-systeem moeten rechtstreeks met elkaar kunnen communiceren om onder de hier gehanteerde definitie van ‘workflow-enabling’ te vallen. Doordat leveranciers hiervoor (markt-)standaarden ontwikkelen, kan een organisatie in principe zelfs meerdere ‘werkstroom-engines’ naast elkaar gebruiken, terwijl de gebruiker steeds één gebruikersinterface houdt.
Resumerend kan worden gesteld dat bij het uitbreiden van bedrijfsapplicaties met werkstroomfunctionaliteit de technische koppeling op verschillende manieren is te realiseren. Dit varieert van een losse, maar directe koppeling tot een volledige integratie van werkstroomfunctionaliteit in een bedrijfsapplicatie. Kenmerkend is hierbij altijd dat een scheiding wordt aangebracht tussen de proces- en applicatielogica.
Indien een werkstroombeheersysteem wordt aangeschaft met het oog op mogelijke uitbreiding van bedrijfsapplicaties met werkstroom, is het van belang dat zowel applicaties als het wfm-systeem gangbare standaarden ondersteunen.
Bastiaan Beltman en Erwin Dunnink,
organisatie-adviseurs Cap Gemini Ernst & Young
Literatuur
[1] Berg, A. van den, en Potjewijdt, P., Workflow, 1997
‘Workflow-enabling’
Ernst & Young Consulting ontwikkelde in korte tijd een totaaloplossing voor het afhandelen van visumaanvragen en implementeerde dit systeem bij een Ministerie van Binnenlandse Zaken. Om de afhandeling van de aanvragen te kunnen beheersen werd in het systeem een werkstroomcomponent opgenomen. Het ministerie heeft voor de oplossing van Ernst & Young Consulting de ‘1999 European Solution of the Year Award’ gewonnen.
Het systeem dat visumaanvragen afhandelt, heet Visa Inquire Open-border Network (Vision). Na de ontvangst van een visumaanvraag verzorgt het systeem de zeer intensieve communicatie met locale, nationale en internationale autoriteiten om tot een beslissing te komen. Meer dan 85 procent van de aanvragen wordt volledig automatisch afgehandeld. In de papierloze organisatie zijn daarbij alle documenten direct elektronisch beschikbaar, en de werkstroomcomponent van het systeem stuurt de opeenvolgende gebruikers aan.
Het systeem is opgezet volgens de richtlijnen die aan ‘workflow-enabling’ ten grondslag liggen. Er is een strikte scheiding aangebracht tussen de proces- en applicatielogica. Tevens is er een wfm-communicatielaag geïntroduceerd die enerzijds kan communiceren met de API’s van de ‘wfm-engine’ en anderzijds toegang heeft tot de verschillende applicatielogica-componenten.
Wijzigingen in het procesmodel konden worden gerealiseerd door slechts de processen aan te passen binnen de ‘wfm-engine’ waarbij de onderliggende applicatiecomponenten niet werden gewijzigd. Ook kon nieuwe functionaliteit worden toegevoegd aan het onderliggende systeem door het koppelen van nieuwe componenten aan de wfm-besturingscomponent. Om in de toekomst eventueel met een tweede ‘wfm-engine’ te kunnen communiceren, dient alleen de wfm-besturingscomponent te worden aangepast. Op deze manier zijn de investeringen in het onderliggende systeem veilig gesteld.
WfMC
De Workflow Management Coalition (WfMC) werd opgericht in 1993 als een non-profit, internationale bedrijfsvereniging Meer dan 200 organisaties zijn lid van het de WfMC. Hieronder bevinden zich naast de meeste van de belangrijkste workflow leveranciers ook gebruikers, consultants, universiteiten en analisten.
De missie van de WfMC is om het gebruik van werkstroom te stimuleren door standaarden te definiëren voor de terminologie, de interoperabiliteit en de verbindingsmogelijkheden tussen werkstroomproducten.
Figuur 1. Aangegeven is welke interfaces de systemen ondersteunen, en welke leveranciers zich conformeren aan de WfMC-standaarden.
Action Works Metro | Corsa/Case | Cosa Workflow | Donau Workflow Suite | Eastman Software Workflow for N’ | Flower | Keyflow | MQSeries Workflow | Oracle Workflow | Panagon Visual WorkFlo | Staffware | TeamWARE | Document Manager | Livelink | |
Interface 1 | Ja | Ja | Ja | Ja | Ja | Ja | ||||||||
Interface 2 | Ja | Ja | Ja | Ja | Ja | Ja | Ja | |||||||
Interface 3 | Ja | Ja | Ja | Ja | Ja | |||||||||
Interface 4 | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | ||||||
Interface 5 | Ja | Ja | Ja | |||||||||||
Lid | Ja | Nee | Ja | Ja | Ja | Nee | Nee | Ja | Ja | Ja | Ja | Ja | Nee | Ja |
Figuur 2. Beschikbaarheid van API’s in de verschillende systemen. Basis (1) geeft aan de mate van beschikbaarheid van API’s en de daarbij behorende documentatie. Aanvullend (2) geeft aan de mogelijkheid tot koppeling met programmeertalen.