Orchestreren van ketenprocessen

architectuur

Orchestreren van ketenprocessen Webserviceorchestratie in e-government

De overheid wil op korte termijn de administratieve lasten voor de burger en het bedrijfsleven verlagen. Daarvoor is het nodig de ketenprocessen te

informatie / juni 2005

orchestreren. Een technologie die zeer geschikt is voor

18

Het verbeteren van de dienstverlening aan haar klanten – burgers en bedrijven – is een van de grote uitdagingen voor de overheid. Dit komt deels voort uit het streven naar vermindering van de administratieve lasten van burgers, bedrijf en overheden (Kabinetsnota, 2003, 2004) en omdat burgers verwachten dat de overheid responsiever en transparanter wordt; dat aanvragen sneller afgehandeld worden en dat ze op de hoogte worden gehouden van de status van een aanvraag. Een eerste stap in het streven naar een betere dienstverlening was het automatiseren van bestaande diensten, die dan on line via een website kunnen worden aangeboden. Een volgende, meer omvattende stap is het aanbieden van ‘one-stop-shop’-diensten, waarbij huidige en nieuwe diensten van meerdere overheidsorganisaties gecombineerd of geïntegreerd worden aangeboden. Een geïntegreerde bouwvergunning, waarbij alle vergunningen die benodigd zijn bij de (ver)bouw van een woning of bedrijf, bijvoorbeeld een sloopvergunning, een vergunning voor de afvoer van afval en een kapvergunning, in een pakket worden aangeboden, is een voorbeeld van zo’n one-stop-shop-dienst. Meerdere afdelingen en overheidsinstanties

het orchestreren van zulke processen is BPEL4WS. BPEL is echter slechts een deel van de oplossing. Marijn Janssen en Jeffrey Gortmaker zijn betrokken bij de afhandeling van deze activiteiten. Een betere en on line dienstverlening moet kunnen omgaan met het probleem van de gefragmenteerde overheid. Taken en bevoegdheden liggen vaak verspreid over verschillende afdelingen en overheidsinstanties, met elk hun eigen, veelal heterogene, informatiesystemen. Voor de VROMvergunning wordt afstemming bemoeilijkt omdat de huidige gemeentelijke architectuur wordt gekenmerkt door een lock-in van softwareleveranciers. Gemeenten zoeken al jaren naar een uitweg voor deze situatie. De problemen op organisatie- en applicatieniveau bemoeilijken het automatiseren van de bedrijfsprocessen. Zelfs voor ‘enkelvoudige’ diensten zoals het aanvragen van een horecavergunning zijn vaak subprocessen benodigd die worden uitgevoerd door andere afdelingen of organisaties. Omdat bevoegdheden en processen wettelijk zijn vastgelegd, is, in tegenstelling tot in het bedrijfsleven, het elimineren van

deze fragmentatie veelal lastig en op korte termijn zelfs onmogelijk. Voor het aanbieden van diensten moeten de verschillende betrokken deelprocessen dus zo goed mogelijk op elkaar worden afgestemd. Omdat de overheid op korte termijn de administratieve lasten voor de burger en het bedrijfsleven wil verlagen, is orchestreren van deze processen dus noodzakelijk. Een technologie die zeer geschikt is voor het orchestreren van ketenprocessen is BPEL4WS.

BPEL4WS Webservicestechnologie is een naam voor een palet aan protocollen die het mogelijk maken functionaliteit, zowel op applicatie- als op bedrijfsniveau, aan te bieden via gestandaardiseerde interfaces. Met de term ‘webservice’ wordt meestal een service bedoeld die kan worden aangeroepen middels een gestandaardiseerde aanroep in xml/Soap-formaat. Webservices kunnen worden gebruikt als interface voor het aanroepen van functionaliteit, zoals

Samenvatting Met webserviceorchestratie kunnen ketenprocessen die door verschillende afdelingen en organisaties lopen, worden gerealiseerd. Eenmaal ontworpen processen kunnen in verschillende situaties worden hergebruikt. BPEL4WS is hiervoor de de facto standaard. Om webserviceorchestratie succesvol toe te passen is er behoefte aan een duidelijk definitie van de regierol en moet een groot aantal organisationele vraagstukken worden opgelost.

een betaalservice, voor het aanroepen van functionaliteit uit legacysystemen of voor het opvragen van data. Webservices zijn de belangrijkste technologie voor het implementeren van een servicegeoriënteerde architectuur (soa). In een soa worden applicaties niet gebouwd volgens een monolithisch patroon waarbij alle functionaliteit in één applicatie zit ingebakken, maar

1

wordt functionaliteit aangeboden middels services. Deze services kunnen vervolgens worden aangeroepen door serviceaanvragers die de service gevonden hebben in een servicedirectory. Het bijzondere van een soa is dat deze niet enkel toepasbaar is op het gebied van softwarearchitectuur, maar ook op het hogere niveau van zakelijke diensten (Steen e.a. 2004). Webserviceorchestratie is een onder-

deel van de webservices stack, gericht op het afstemmen van verschillende webservices, zodat een proces van opeenvolgende aanroepen van webservices ontstaat. Webserviceorchestratie richt zich op het specificeren van de logica achter de tijdsvolgordelijke aanroepen van verschillende webservices. De de facto standaard voor orchestratie is BPEL4WS, Business Process Execution Language for Web Services, vaak kortweg BPEL genoemd. BPEL is ontwikkeld door Microsoft, IBM en BEA, en verenigt twee oudere talen van Microsoft en IBM: XLANG en WSFL. De nieuwste versie van BPEL4WS zal ook proceslogica gaan bevatten die traditioneel alleen in workflowtalen aanwezig was. Zo biedt het de mogelijkheid taken door mensen te laten uitvoeren. De grote voordelen van webserviceorchestratie ten opzichte van workflow zijn de uniforme en standaardmanier van het aanroepen van bedrijfsprocessen en applicaties middels webservices. Dit maakt zaken als hergebruik en het snel en gemakkelijk aansluiten van nieuwe processen mogelijk. Een in BPEL4WS ontworpen proces kan idealiter in software van verschillende leveranciers worden afgespeeld. Een voorbeeld van een proces in BPEL4WS van de aanvraag van een horecavergunning is weergegeven in figuur 1. Dit proces begint met het ontvangen van een ingevuld webformulier en roept een webservice aan die controleert of het formulier wel volledig is ingevuld. Wanneer het formulier niet volledig is ingevuld, wordt de gebruiker verzocht deze kloppend te maken. In de andere gevallen gaan twee processen parallel lopen. De aanvraag wordt gepubliceerd in een krant en de politie wordt om advies gevraagd omtrent het verlenen van de horecavergunning.

informatie / juni 2005

Voorbeeld van een proces in BPEL4WS

19

architectuur informatie / juni 2005

20

Orchestratie komt op dit moment met name uit de softwareleveranciershoek. Er zijn verschillende leveranciers van orchestratietechnologie, waaronder zelfs een open-sourcevariant. Dit heeft tot gevolg dat veel toepassingen gericht zijn op het uitbreiden van de huidige middlewarefunctionaliteit voor het op elkaar aansluiten van de informatiesystemen in de front- en back-offices. Orchestratie wordt vanuit deze hoek gezien als een uitgebreide versie van enterprise application integration (eai). Dit is een logisch gevolg als we naar de ontwikkeling van de technologie kijken, maar dit is een veel te beperkt perspectief op de mogelijkheden van orchestratie. De toegevoegde waarde en het potentieel liggen nu juist in de toepassing van orchestratie voor het coördineren van bedrijfsprocessen die door verschillende organisaties en/of afdelingen lopen. De verwachting is dat de discussie webserviceorchestratie versus workflow of business process management (bpm) spoedig achterhaald zal zijn. Eai- en workflowtechnologie zijn namelijk aan het convergeren. De ontwikkelingen in de orchestratiesoftwaremarkt gaan snel, en de bestaande software biedt steeds meer functionaliteit. Ook zien we aan de andere kant de eai-markt convergeren met de workflow/bpm-markt. Zo nam eai-vendor Tibco onlangs de grote workflow/bpm-leverancier Staffware over. Met het huidige momentum achter BPEL is het de verwachting dat weldra ook andere bpm-vendors BPEL gaan ondersteunen in hun producten, en er zal een veelvoud aan business process management- en business process integratie-suites ontstaan, die applicaties, processen en externe organisaties kunnen koppelen.

BPEL4WS, als open standaardtaal, en webservices als gestandaardiseerde technologie voor de interfaces zullen hierin een hoofdrol spelen.

Hergebruik van processen Webserviceorchestratie heeft de potentie ketenprocessen te coördineren die door de gefragmenteerde overheid lopen. De organisatie die verantwoordelijk is voor het verlenen van de uiteindelijke dienst, kan met behulp van webserviceorchestratie het dienstverleningsproces starten of zelfs orchestreren door de via een gestandaardiseerde webservice-interface toegankelijk gemaakte subprocessen bij andere afdelingen en organisaties aan te roepen. In principe kan elke afdeling op haar beurt weer haar eigen processen orchestreren. Elke afdeling of organisatie kan onderdeel zijn van meerdere georchestreerde processen. Het gevaar is dat elke afdeling en organisatie haar eigen proces gaat ontwikkelen en onderhouden en er op deze maniereen wildgroei ontstaat aan ontwikkelaars en onderhoudsspecialisten.

waarbij er rekening mee wordt gehouden dat bepaalde taken op de specifieke omstandigheden worden afgestemd. Het proces dat op centraal niveau ontworpen is, moet voldoende algemeen zijn zodat het op lokaal niveau aan de specifieke omstandigheden kan worden aangepast en lokale instanties niet tot een eenheidsworst worden gedwongen. Dit kan door een shared service center te introduceren (Janssen en Joha, 2004). In dit soort centra worden diensten, in dit geval zelfs complete bedrijfsprocessen, geconcentreerd in een centrale organisatie, die deze diensten aanbiedt aan andere partijen op grond van een overeenkomst tegen een bepaalde prijs. Processen moeten natuurlijk ook onderhouden en regelmatig veranderd worden als gevolg van wetswijzigingen. Dit kan ook zeer efficiënt op een centrale plaats gebeuren, maar dient wel in samenspraak met de lokale niveaus te gebeuren aangezien die de tactische kennis over de uitvoering van de bedrijfsprocessen bezitten. Op centraal niveau zouden experts wets-

»Webserviceorchestratie kan ketenprocessen coördineren bij de gefragmenteerde overheid« Orchestratie biedt de mogelijkheid het ontwikkelen en onderhouden van software naar het procesniveau te tillen, zoals in figuur 2 weergegeven is. In tegenstelling tot bedrijven zullen overheidsinstanties er onder normale omstandigheden geen problemen mee hebben dat andere overheidsinstanties hun processen hergebruiken en het proces aan de lokale omstandigheden aanpassen.. Een bedrijf zal vanwege concurrentieoverwegingen meestal niet willen dat een concurrent zijn proces hergebruikt. Naast het hergebruik op decentraal niveau liggen de kansen binnen de overheid ook op het vlak van het eenmaal ontwerpen van een bedrijfsproces op centraal niveau en het op lokaal niveau (her)gebruiken,

wijzigingen kunnen bijhouden, de gevolgen hiervan evalueren en eventueel voorstellen doen voor aanpassingen om de administratieve lasten voor overheden en klanten te minimaliseren.

Inrichting van de regierol Het orchestreren of regisseren van een ketenproces is geen eenvoudige opgave en er moeten veel beslissingen worden genomen om tot een goede inrichting te komen. Dit roept onder andere vragen op zoals: wie is ervoor verantwoordelijk dat de juiste informatie bij de juiste instantie komt; moeten de diverse betrokken overheidsinstanties wel of niet zichtbaar blijven voor de aanvrager; hoe wordt de voortgang bijgehouden; moeten de bedrijfspro-

Onderhoud en hergebruik van processen

proces voltooid is, zijn de gegevens verdwenen. Voor het leveren van beleidsinformatie en archiefdoeleinden voor de verschillende overheidsinstanties is het echter zeer belangrijk ook daarna nog over de gegevens te kunnen beschikken. Ook is het vaak niet praktisch om alle informatie met het proces mee te voeren, en ligt een meer permanente vorm van gegevensdelen tussen de verschillende organisaties voor de hand. Bij een volgende aanvraag is de informatie vaak weer nodig, waardoor je informatie van de vorige aanvragen moet behouden. Ook als er iets fout gaat en een roll-back nodig is, is het handig een meer permanente opslag van gegevens en processtatus te hebben. Een ander punt waaraan aandacht dient te worden besteed, is het herverdelen van de bevoegdheden en verantwoordelijkheden. Iemand moet verantwoordelijk zijn voor het verzorgen van een hoge beschikbaarheid van de systemen, voor het verwerken van wetswijzigingen en voor de beveiliging. De regisseur moet de bevoegdheid hebben om de andere organisaties aan te sporen hun deel van het proces uit te voeren. Zo kan de orchestrator ervoor zorgen dat de factuur voor de leges van ver-

2

schillende vergunningen in één keer verstuurd wordt en de leges naar de juiste partijen worden verstuurd. Een groot voordeel hiervan is dat niet elke partij meer haar eigen factureringsafdeling hoeft te hebben en de partijen zich kunnen concentreren op hun corebusiness. Accountability van de overheid is een breed begrip, maar kan in deze context worden gedefinieerd als het afleggen van verantwoordelijkheid voor het verloop van overheidsprocessen. Dit houdt in dat moet worden bijgehouden hoe beslissingen tot stand zijn gekomen, waarom bepaalde besluiten zijn genomen, enzovoort. Wanneer bijvoorbeeld een vergunningsaanvraag wordt afgewezen op basis van ‘zachte’ belastende informatie over iemand, moet dit wel aan de aanvrager gemotiveerd kunnen worden. Hoe ga je hiermee om: maak je alle beslissingen van het hele proces transparant of maak je het proces alleen op aggregaatniveau transparant, dat wil zeggen enkel de input en output van de afdelingen/organisaties; de afdelingen/organisaties zelf worden dan als black box beschouwd. In het eerste geval is het nadeel dat een gebruiker de overheidsprocessen en beslisregels op

informatie / juni 2005

cessen of de aanwezige applicaties als uitgangspunt voor ontwerp worden genomen; worden service level agreements (sla’s) bilateraal of met een ‘centraal’ niveau afgesproken; wat gebeurt er als een van de organisaties een deadline overschrijdt of als één organisatie een bericht verstuurd heeft en de andere zegt deze nooit ontvangen te hebben; dient één rekening verstuurd te worden voor alle vergunningen of per vergunning een rekening? Hieruit blijkt dat technologie alleen slechts ten dele een oplossing is voor het orchestreren van ketenprocessen. Het orchestreren vereist namelijk een duidelijke regiefunctie, die verantwoordelijk is voor het totale dienstverleningsproces. Wanneer er namelijk niemand verantwoordelijk is voor de goede uitvoering van het gehele proces, moet de klant zelf de regierol vervullen. Dus feitelijk de verschillende organisaties coördineren, met de daarbij behorende hoge administratieve lasten en het risico van het kastje naar de muur gestuurd te worden. Het invullen van deze regie- of orchestratiefunctie is de grote uitdaging voor het succesvol toepassen van webserviceorchestratie voor het coördineren van ketenprocessen. Samenwerking tussen overheidsinstanties met verschillende doelen en informatiearchitecturen is noodzakelijk. Bij het implementeren van orchestratie moeten goede afspraken tussen partijen worden gemaakt over het uitvoeren van taken, zoals de toegestane verwerkingstijd van een aanvraag, het tijdig doorgeven van statusinformatie, of afspraken over de toegestane uitkomsten van een subproces. Een andere vraag die bij het inrichten van de orchestratierol beantwoord moet worden, is het niveau waarop coördinatie moet plaatsvinden. Dit kan op het activiteitenniveau in de subafdelingen, maar ook op het niveau van de afdelingen zelf plaatsvinden, waarbij de activiteiten binnen de afdeling een black box zijn voor de orchestrator. Er moet worden nagedacht op welke wijze met gegevensopslag en -distributie omgegaan wordt. Gegevens kunnen middels variabelen worden meegevoerd in het proces, maar wanneer het

21

architectuur een wel erg gedetailleerd niveau voorgeschoteld krijgt, maar het voordeel is dat alle details transparant zijn. In het tweede geval is het nadeel dat niet alle regels transparant zijn, maar het voordeel is dat het eenvoudiger te begrijpen is voor de aanvragers en dat aansturing van de verschillende afdelingen op basis van sla’s mogelijk is. Adaptiviteit van overheidsprocessen is een laatste belangrijk aandachtspunt voor het inrichten van de regiefunctie. Overheidsprocessen kunnen snel veranderen, bijvoorbeeld ten gevolge van nieuwe wet- en regelgeving. Wanneer deze dienstverleningsprocessen zijn vastgelegd in geautomatiseerde process flows, moeten er duidelijke afspraken zijn over hoe om te gaan met deze wijzigingen. Aan de Technische Universiteit Delft wordt onderzocht hoe de processen kunnen worden hergebruikt en hoe de regierol moeten worden ingericht. Het doel van dit onderzoek is te komen tot een referentiearchitectuur die overheidsbesluitvormers ondersteunt bij het maken van keuzen voor het orchestreren van ketenprocessen.

informatie / juni 2005

Toekomst

22

Orchestratie moet meer dan alleen als uitgebreide middleware gezien worden en vereist de inrichting van een duidelijke regierol met alle daarbij behorende organisatorische consequenties. Traditionele softwareaanbieders lijken orchestratietechnologie in enge zin te zien. Ondernemingen als Grand Central (www.grandcentral.com) onderstrepen de hier gepresenteerde gedachte en geven de mogelijkheid om complete bedrijfsprocessen te hergebruiken in analogie naar het hergebruik van softwarecomponenten. Dit sluit aan op de wensen van de vraagkant, van

waaruit er een behoefte aan ondersteuning van het inrichten van de regiefunctie en het hergebruiken van complete bedrijfsprocessen bestaat. Voor het realiseren van de voordelen dienen coalities van partijen gecreëerd te worden, waarbij duidelijke afspraken en keuzen betreffende het onderhouden van processen en het inrichten van de regiefunctie worden gemaakt. Reviewer Stef Joosten

Literatuur Janssen, M. & A. Joha (2004). De Onzekere Belofte van het Shared-servicecenter. Informatie, 46(6), pp. 26-31. Kabinetsnota (2003). Actieprogramma Andere Overheid, www.andereoverheid.nl. Kabinetsnota (2004). Meer ruimte voor ondernemers door minder lasten – Van lastenproductie naar lastenreductie, www.administratievelasten.nl/ default.asp?CMS_TCP=tcpAsset&id=8920A0B8 B340438AA3053712C0F67D2C. Steen, M.W.A. e.a. (2004). Service-Oriented Enterprise Architecture. In Z. Stojanovic & A. Dahanayake (red.), Service-Oriented Software System Engineering: Challenges and Practices. Idea Group.

Leveranciers BPEL-engines Oracle BPEL Process Manager: otn.oracle.com/bpel OpenStorm Service Orchestrator: www.openstorm.com IBM Websphere Business Integration Server Foundation: www306.ibm.com/software/integration/wbisf/fea tures Active Endpoints ActiveWebflow Server: www.active-endpoints.com/products/activewebflow ActiveBPEL (Open Source): www.activebpel.org Marijn Janssen is universitair docent bij de sectie Informatie- en Communicatietechnologie van de Faculteit Techniek, Bestuur en Management van de Technische Universiteit Delft. E-mail: [email protected]. Jeffrey Gortmaker is promovendus bij de sectie Informatie- en Communicatietechnologie van de Faculteit Techniek, Bestuur en Management van de Technische Universiteit Delft. E-mail: [email protected].