Een onderwerp, waar in een bedrijfsarchitectuur traditioneel vaak minder aandacht voor is, is gebeurtenissen. Gebeurtenissen in een bedrijfsproces bij de ene ketenpartner kunnen van invloed zijn op een bedrijfsproces bij een andere ketenpartner. Daarom is het belangrijk dat ketenpartners elkaar op de hoogte kunnen houden van relevante gebeurtenissen. Dit noemen we notificeren.
Omdat het samenwerken op basis van gebeurtenissen één van de samenwerkpatronen van de Migratieketen is, wijden we in de MIRA Bedrijfsarchitectuur een apart hoofdstuk aan gebeurtenissen en het notificeren hierover. Hierin beschrijven we gebeurtenissen en het notificeren hierover vanuit bedrijfsperspectief. De architectuur voor de implementatie hiervan, in navolging van de hier geschetste kaders, is iets voor de informatiearchitectuur.
Als we het in de bedrijfsarchitectuur over gebeurtenissen hebben, hebben we het over bedrijfsgebeurtenissen, oftewel business events. Dit zijn gebeurtenissen die plaatsvinden in de juridische of materiële werkelijkheid en relevant zijn vanuit bedrijfsperspectief.
Deze gebeurtenissen kunnen binnen of buiten de organisatie (of keten) plaatsvinden en geven aanleiding tot bepaald gedrag binnen (of buiten) de keten. Gebeurtenissen binnen de keten komen voort uit een specifiek bedrijfsproces bij een ketenpartner (“besluit asielaanvraag genomen”). Gebeurtenissen buiten de keten kunnen vanuit de omgeving van de vreemdeling (“nieuw arbeidscontract getekend”) of uit andere ketens (“vreemdeling verdacht van strafbaar feit”). Gebeurtenissen kunnen aanleiding geven tot het starten van een bedrijfsproces (“asielaanvraag ingediend”), of het verloop van andere bedrijfsprocessen beïnvloeden (“vreemdeling in bewaring gesteld”). Uiteraard zijn er ook gebeurtenissen die geen impact hebben op bedrijfsprocessen (“een vogel fluit”). Deze zijn vanuit architectuurperspectief dan ook niet relevant.
Een gebeurtenis is altijd een momentopname. Het uitvoeren van een activiteit in het kader van een bedrijfsproces is geen gebeurtenis. Maar het feit dat een activiteit is gestart of is beëindigd wel. Vaak zal een gebeurtenis in een proces dan ook overeenkomen met een verandering van een bepaalde status in een proces (“asielaanvraag ingediend”). Maar ook andere, meer inhoudelijke gebeurtenissen die relevant zijn om in de keten te delen kunnen voorkomen (“advocaat toegewezen”). Gebeurtenissen worden altijd geformuleerd in de voltooid verleden tijd, want er is een nieuwe toestand bereikt.
Intermezzo:
Onlangs verscheen een architectuur voor notificatieservices die is opgesteld door het Project “Notificatieservices”, dat is uitgevoerd door de VNG in opdracht van het ministerie van BZK. Op basis van deze architectuur is een overheidsbrede standaard voor notificeren over gebeurtenissen (NLGOV profiel op Cloudevents) opgesteld die door Logius wordt beheerd en zal worden opgenomen in het Federatief Datastelsel (FDS). We volgen dit document en de standaard voor het realiseren van het notificeren over gebeurtenissen. Dit is in overeenstemming met Mira principe 4A: We maken optimaal gebruik van overheidsbrede afspraken, standaarden en voorzieningen. Dit vooral voor verdere uitwerking in de informatiearchitectuur en realisatie door middel van ketenstandaarden. Maar ook al voor de definitie en begrippen hier in de bedrijfsarchitectuur.
Het samenwerken op basis van het notificeren over gebeurtenissen is één van de samenwerkpatronen van de Migratieketen en geeft invulling aan MIRA Architectuurprincipe 2B: het beheersen van de wederzijdse afhankelijkheid is een gezamenlijke plicht.
Deze manier van samenwerken is een betrekkelijk losse vorm van samenwerking. Zolang andere ketenpartners maar op de hoogte worden gehouden van voor hen relevante gebeurtenissen, kan iedere ketenpartner tot op zekere hoogte autonoom invulling geven aan de eigen bedrijfsprocessen.
Een gebeurtenis gedreven architectuur (Event Driven Architecture) wint de laatste jaren ook aan aandacht in met name de informatiearchitectuur. Hoewel er in de samenwerking in de Migratieketen een belangrijke rol is weggelegd voor het notificeren over gebeurtenissen, is er nog geen sprake van een volledige gebeurtenis gedreven architectuur.
Binnen de Migratieketen werken we naast het notificeren over gebeurtenissen ook nog operationeel samen door het uitwisselen van gegevens en het van elkaar afnemen van diensten. Deze drie samenwerkpatronen vullen elkaar aan.
Zoals al opgemerkt is het begrip gebeurtenis heel algemeen van aard. We beperken ons hier tot gebeurtenissen die relevantie hebben in het bedrijfsproces. Een bedrijfsgebeurtenis moet ook niet verward worden met een systeemgebeurtenis, een gebeurtenis die plaatsvindt binnen een software- of registratiesysteem. Dit kan een neerslag zijn van een business-gebeurtenis en bijvoorbeeld leiden tot het creëren of wijzigen van bepaalde gegevens. Zo kan de business-gebeurtenis ‘aanvraag verblijfsvergunning ingediend’ leiden tot systeem-gebeurtenissen als 'dossier aangemaakt' en 'workflow opgestart'. Voor applicatie-integratie binnen een organisatie zijn dergelijke systeem-gebeurtenissen bruikbaar. Maar voor de goede samenwerking in de keten is het belangrijk om uit te gaan van de bedrijfsgebeurtenissen en deze ook in een gezamenlijke, begrijpelijke taal voor de business te definiëren.
Samenwerken in de keten op basis van gebeurtenissen vereist het op de hoogte stellen van de andere ketenpartners over gebeurtenissen die hebben plaatsgevonden. Dit noemen we notificeren.
Een notificatie is een strikt omschreven bericht over een gebeurtenis die heeft plaatsgevonden. Afgezien van technische informatie is de inhoud van een notificatie beperkt tot wat, wanneer heeft plaatsgevonden.
De ketenpartner die geïnteresseerd is in een notificatie is de afnemer. Een notificatie wordt vaak verzonden middels een ‘bericht’. Een afnemer kan zich abonneren op notificaties op gebeurtenissen van een bepaald type.
Om technologische en beheersmatige redenen is het distribueren van notificaties nu vaak gecentraliseerd. Dit is een technische keuze die met de komst van nieuwe technologieën ter discussie zou kunnen worden gesteld. Dat valt buiten de kaders van deze bedrijfsarchitectuur. Wel van belang is het ketenbreed maken van afspraken over notificaties.
MIRA Principe BA-G1: In de Migratieketen werken we samen op basis van gebeurtenissen uit de business.
Rationale: Notificeren over gebeurtenissen is een flexibele en krachtige manier om de samenhang en afhankelijkheden tussen bedrijfsprocessen te borgen. Door de gebeurtenissen te definiëren in termen van wederzijds herkenbare bedrijfsgebeurtenissen, is er aan beide kanten geen kennis over de achterliggende detailprocessen of gebeurtenissen nodig.
Het op de hoogte stellen van andere ketenpartners over een bepaald feit, of bepaalde feiten gebeurde vroeger vaak met papieren formulieren die ook direct alle gegevens omvatten. Dit is een patroon waar we in de digitale wereld afscheid van moeten nemen. Het is ook in de digitale wereld verleidelijk om bij een notificatie ineens een rijke set aan gegevens mee te sturen, zodat de afnemer ineens op de hoogte is van alle relevante gegevens rondom een gebeurtenis.
Dit is echter nadelig omdat deze vermenging een op zichzelf staande gebeurtenis koppelt aan een specifieke informatiewens. Dat maakt de gebeurtenis minder herbruikbaar. Voorwaarde is wel dat er een mechanisme is geïmplementeerd om de benodigde informatie bij de bron te kunnen opvragen.
Conform MIRA principe 5B: de keten werkt op basis van gestructureerde gegevens direct uit de bron, kiezen we daarom voor informatiearme notificaties. Hierin worden naast het type van de gebeurtenis enkel de benodigde identificerende (meta)gegevens meegestuurd. Het is aan de afnemer om, op een moment dat hem zelf past, de gegevens die hij nodig heeft naar aanleiding van de ontvangen notificatie op te vragen bij de aanbieder van de notificatie. Identificerende gegevens zijn bijvoorbeeld het v-nummer van de vreemdeling waarop de gebeurtenis betrekking heeft, of een tijdsaanduiding wanneer de gebeurtenis heeft plaatsgevonden. Per gebeurtenistype moet worden uitgewerkt welke minimale gegevens nodig zijn om een gebeurtenis uniek te identificeren.
MIRA principe BA-G2: In de keten werken we met informatiearme notificaties die enkel het gebeurtenistype en enkele identificerende (meta) gegevens over de gebeurtenis zelf bevatten.
Rationale: Het meesturen van gegevens is strijdig met het principe halen bij de bron en leidt tot schaduwregistraties bij afnemers die kunnen verouderen. Bovendien veronderstelt dit teveel inzicht in de informatiebehoefte van de afnemer wat strijdig is met het principe van de scheiding van belangen.
De verantwoordelijkheid voor het notificeren ligt bij de ketenpartner waar een gebeurtenis zich heeft voorgedaan (de aanbieder). Binnen een ketencontext en conform het eerder aangehaalde MIRA principe 2B: het beheersen van de wederzijdse afhankelijkheid is een gezamenlijke plicht, komt de lijst met gebeurtenissen waar in de keten behoefte aan is in dialoog tot stand.
MIRA principe BA-G3: Als een gebeurtenis van belang is voor een andere ketenpartner dan heeft de aanbieder de verantwoordelijkheid om hierover actief te notificeren. Een afnemer kan zich abonneren op gebeurtenissen van een bepaald type.
Rationale: Actief notificeren over voor andere ketenpartners relevante gebeurtenissen is de kern van het samenwerken op basis van gebeurtenissen en conform MIRA principe 2B. Een abonnementen-systeem om bij te houden welke ketenpartner in welke gebeurtenis geïnteresseerd is, is onmisbaar voor beheer en implementatie hiervan.
Notificaties gaan over gebeurtenissen die optreden in de bedrijfsprocessen van de aanbieder. Ze worden dan ook vanuit de context van de aanbieder gedefinieerd. Ze moeten dusdanig gedefinieerd worden dat ze door een ieder eenduidig te interpreteren zijn en voldoende informatie bevatten om de aard van de gebeurtenis goed te kunnen begrijpen.
Wat een afnemer met de notificatie over de gebeurtenis doet is de verantwoordelijkheid van de afnemer. Hier heeft de aanbieder beperkte kennis over.
MIRA Principe BA-G4: Gebeurtenistypen worden door de aanbieder gedefinieerd en zijn ontvanger-onafhankelijk en verwachtingsloos.
Rationale: Gebeurtenissen zijn 1-op-1 verbonden met het bedrijfsproces van de aanbieder waarin ze ontstaan. Het is dus enkel mogelijk om ze eenduidig en ondubbelzinnig te definiëren, als dit vanuit de context van de aanbieder gebeurt. Ontvanger-onafhankelijk betekent dat de gebeurtenissen door meerdere, ook bij het definiëren nog niet bekende, ontvangers (her)gebruikt kunnen worden, zonder dat er additionele afspraken of informatie nodig zijn voor het interpreteren ervan. De gebeurtenistypen zijn verwachtingsloos want er zijn geen (impliciete) verwachtingen over wat de ontvanger met een gebeurtenis gaat doen. Verwacht je iets specifieks van een ketenpartner, dan is het een verzoek/dienst en is het interactiepatroon notificeren over gebeurtenissen niet het juiste.
Notificeren in ketenverband voegt een extra dimensie toe aan het vraagstuk van het notificeren over gebeurtenissen. Meerdere partijen kunnen geïnteresseerd zijn in bepaalde gebeurtenistypen. Ook kunnen bepaalde gebeurtenissen bij meerdere ketenpartners optreden. Enige afstemming hierin is op ketenniveau wel noodzakelijk.
In de literatuur wordt er soms nog een rol voor een intermediair onderkend om vraag en aanbod naar notificaties over gebeurtenissen bij elkaar te brengen. In de Migratieketen is dit op business-niveau niet nodig, maar vullen de ketenpartners dit gezamenlijk in. Er wordt gezamenlijk een ketenbrede gebeurtenistypencatalogus opgesteld, waarin minimaal het gebeurtenistype, aanbiedende ketenpartner(s), bedrijfsproces waarin het gebeurtenistype ontstaat, een korte omschrijving en de afnemers in gedefinieerd staan. Het is belangrijk dat deze catalogus actueel wordt gehouden en dat de gebeurtenistypes juist gekozen zijn.
Bij het kiezen van de gebeurtenistypes in deze gebeurtenissencatalogus moet goed naar de granulariteit van de gebeurtenistypen gekeken worden. ‘Vreemdeling genaturaliseerd” zou een gebeurtenis kunnen zijn, maar wie weet zijn bepaalde ketenpartners enkel geïnteresseerd in genaturaliseerde asielzoekers en niet in genaturaliseerde reguliere vreemdelingen. Er moet dus rekening gehouden worden met de informatiebehoefte van de afnemer(s). Definitie van een gebeurtenis dient echter wel te gebeuren op basis van de context van de aanbieder.
MIRA principe BA-G5: Stel een ketenbrede gebeurtenistypencatalogus op en richt het beheer hierop in. Per gebeurtenistype worden minimaal de aanbieder, het bedrijfsproces waarin het ontstaat, de betekenis van de gebeurtenis en de op gebeurtenissen van dit type geabonneerde ketenpartners bijgehouden.
Rationale: Bij samenwerken horen goede afspraken over de wederzijdse afhankelijkheden. Voor het samenwerken met betrekking tot gebeurtenissen leggen we deze vast in een ketenbrede gebeurtenistypencatalogus die we gezamenlijk opstellen en beheren. Dit maakt reeds bestaande gebeurtenissen inzichtelijk voor andere ketenpartners; biedt inzicht in geval van wijzigingen en heeft het voordeel dat documentatie op één plaats beschikbaar is.
Het doel van het notificeren over gebeurtenissen is juist dat: het op de hoogte stellen van andere ketenpartners over een gebeurtenis die in een bedrijfsproces heeft plaatsgevonden. Eens de notificatie is verstuurd en ontvangen houdt deze op te bestaan (behoudens enkele technische maatregelen om de goede ontvangst te waarborgen). Een administratie van verzonden notificaties in de keten wordt niet bijgehouden. Kunnen tijdreizen regelen we in de registraties, niet door, wat je in sommige, event driven architectures wel eens ziet, door gebeurtenissen chronologisch 'terug te spoelen'. Uiteraard staat het de ketenpartners vrij om dit om interne redenen wel te doen. Wanneer de gebeurtenissen van belang zijn voor het verantwoorden over (niet) genomen besluiten bij de ontvanger, vereisen WOO en/of Archiefwet wellicht dat deze de ontvangen notificaties duurzaam bewaart.
MIRA Principe BA-G6: Notificaties van gebeurtenissen zijn vluchtig: we bouwen in de keten geen historie op van notificaties en verwachten dit ook niet van de ketenpartners
Rationale: Omdat het notificeren over gebeurtenissen niet het enige interactiepatroon in de keten is, is het belangrijk goed af te bakenen waarvoor dit dient, nl. het in het hier en nu notificeren over gebeurtenissen. Geschiedenis bijhouden en beschikbaar stellen is een verantwoordelijkheid van de bron. Doordat we werken met informatiearme notificaties zou het nut van eventueel tijdreizen op basis van de notificaties ook maar van beperkt nut zijn.
Ketenpartners zijn zelf verantwoordelijk voor de administratieve neerslag van hun bedrijfsprocessen. Relevante gegevens uit deze processen registreren zij zelf. Dit geldt ook voor gegevens over in deze bedrijfsprocessen voorkomende gebeurtenissen. Indien derden, dus ook andere ketenpartners, hierin geïnteresseerd zijn, kunnen ze deze opvragen bij de aanbieder, dwz. bij de bron.
MIRA Principe BA-G7: De geschiedenis van gebeurtenissen wordt bijgehouden door de aanbieder en kan worden opgevraagd bij de bron
Rationale: Ook gebeurtenissen worden geregistreerd bij de bron, zo blijft de context beter bewaard. Het is aan de aanbieder zelf om te bepalen hoe deze geschiedenis bewaard wordt. Dat kan in een aparte registratie zijn, of door middel van loggegevens in een processysteem. Indien er een informatiebehoefte van derden is naar deze geschiedenis, kunnen afspraken gemaakt worden over hoe deze geschiedenis opgevraagd kan worden.
Gebeurtenissen hebben een rol in de bredere bedrijfsarchitectuur. Gebeurtenissen ontstaan binnen de context van een bedrijfsproces bij een aanbiedende ketenpartner. Uiteraard kunnen er meerdere gebeurtenissen optreden binnen één bedrijfsproces.
Omdat de context van het bedrijfsproces bepalend is voor de definitie van een gebeurtenis, is het erg onwaarschijnlijk dat de twee verschillende bedrijfsprocessen exact dezelfde gebeurtenis zullen opleveren, zoals hieronder van bedrijfsproces B naar gebeurtenistype A.
Een vreemdeling kan agressief gedrag vertonen in meerdere bedrijfsprocessen. Maar de context van het bedrijfsproces maakt dat dit een ander gebeurtenistype is. En dat klopt ook wel met de realiteit, want agressiviteit in de context van een opstootje bij DJI in bewaring zal wellicht toch een andere betekenis hebben dan in de context van een gehoor bij de IND.
Aan de ontvangende kant, kan een notificatie over een gebeurtenis een trigger zijn voor het starten van een bedrijfsproces, of een input zijn voor een al lopend bedrijfsproces. Dit wordt geïllustreerd in onderstaande figuur, welke een heel erg versimpelde weergave van het Bedrijfsproces “Opvangen Asielzoekers” door COA weergeeft (in BPMN).
De gebeurtenis “Nieuwe Vreemdeling aangemeld” van de IND vormt de start van het COA-proces “opvangen vreemdeling”. Gedurende het verloop van dit bedrijfsproces komen er notificaties over gebeurtenissen uit het bedrijfsproces “Behandelen Asielaanvraag” van de IND die input zijn voor het opvangproces van de COA. Zo’n notificatie kan ook aanleiding geven tot het starten van een nieuw proces, zoals “Regisseren vertrek” bij DTenV. En dit is dan de min of meer verwachte procesflow. Er kunnen ook andersoortige gebeurtenissen voorkomen die impact hebben op het proces, zoals het treffen van een voorlopige voorziening door de rechter, of een notificatie van buiten de keten, bijvoorbeeld dat een vreemdeling is aangehouden voor een strafbaar feit.
Het wordt duidelijk dat dit al snel leidt tot een complex web van met elkaar interacterende bedrijfsprocessen die gekoppeld zijn door middel van notificaties over gebeurtenissen. De interacties tussen deze bedrijfsprocessen, vallen erg moeilijk voor de hele keten in kaart te brengen, laat staan beheren.
Het standaardiseren van informatiearme notificaties in een ketenbrede gebeurtenistypencatalogus maakt dat dit ook niet nodig is. Iedere ketenpartner kan zo focussen op zijn eigen bedrijfsproces en dient enkel aan te geven wanneer behoefte is aan een notificatie over een nieuw gebeurtenistype. Dit kan dan in het beheer van de gebeurtenistypencatalogus worden geadresseerd.
Hierboven zijn al enkele voorbeelden gegevens van gebeurtenissen in de Migratieketen waarover genotificeerd kan worden. Meer inspiratie kan gevonden worden in de bestaande lijst met BVV activiteiten. Dit vormt een goede basis voor de ketenbrede gebeurtenissencatalogus. Wellicht dienen sommige bestaande procesverwijzingen op basis van bovenstaande principes enigszins aangescherpt te worden.
Naast deze ‘interne’ gebeurtenissen, is de migratieketen natuurlijk geen eiland op zich. Ook buiten doen er zich gebeurtenissen voor die relevant zijn voor de bedrijfsprocessen binnen de keten. Bijvoorbeeld gebeurtenissen uit aanpalende ketens als de strafrechtketen of de inburgeringsketen. Omgekeerd kan dit uiteraard ook voorkomen: gebeurtenissen in de migratieketen die in aanpalende ketens of elders binnen de overheid relevant zijn.
Vaak zijn dit afspraken die tussen één ketenpartner en een andere overheidsorganisatie of keten worden gemaakt en hierdoor niet op ketenniveau binnen de Migratieketen bekend zijn. Dit hoeft echter geen probleem te zijn, zeker niet wanneer er gebruik gemaakt wordt van dezelfde overheidsbrede afspraken en standaarden.
In sommige gevallen zijn gebeurtenissen van buiten de keten bijvoorbeeld interessant voor twee of meer ketenpartners. Een voorbeeld is een adreswijziging van een vreemdeling die al langer dan 6 maanden in Nederland is. De bron van deze adresgegevens is de BRP[1]. In principe moeten alle ketenpartners die adresgegevens gebruiken deze bij de bron betrekken (via de BRP) en dus een abonnement nemen op notificaties op adreswijzigingen.
Als keten kan het in dit geval best interessant blijken, bijvoorbeeld vanuit efficiencyoogpunt, om de individuele ketenpartners te ontzorgen en als keten een abonnement te nemen op deze gebeurtenissen en deze eventueel te vertalen en distribueren naar de ketenpartners op dezelfde wijze als de gebeurtenissen uit de keten zelf.
Dit raakt echter aan informatiearchitectuur en implementatiekeuzes en zal van tot geval verschillen. Denk aan een vreemdeling die getrouwd is, diverse notificaties (gearresteerd, veroordeeld,..) uit de strafrechtketen of het verkrijgen van werk of behalen van een diploma.
Andersom geldt iets vergelijkbaars. Notificaties die relevant zijn binnen de keten, kunnen ook buiten de keten interessant zijn. IND en COA nemen bijvoorbeeld samen met o.a. gemeenten, DUO en SZW deel aan de Inburgeringsketen. Een gebeurtenis in de Migratieketen, bijvoorbeeld “Asielvergunning toegekend”, vormt de aanleiding voor de inburgeringsplicht en het versturen van ene brief hierover vanuit DUO. Het is aan de ketenpartners in de Inburgeringsketen hoe ze dit inrichten. Wanneer het echter wenselijk is om de Inburgeringsketen aan te sluiten op notificaties uit de Migratieketen, dan kan dit worden overwogen. Gebruik van overheidsbrede standaarden maakt dit makkelijker.
Daarom de aanbeveling om deze keuze telkens weloverwogen te maken en te delen met de andere ketenpartners.
MIRA Principe BA-G8: Wanneer het voor twee of meer ketenpartners voordelen biedt, bijvoorbeeld qua efficiency, kan het notificatiemechanisme van de Migratieketen ook worden ingezet ten behoeve van het notificeren van partijen buiten de keten, of het notificeren over gebeurtenissen van buiten de keten.
Rationale: Het is effectiever en makkelijker qua beheer als voor notificaties buiten de migratieketen ook gebruik wordt gemaakt van een standaardmechanisme. Dit vergt additionele afspraken buiten de keten. Hoewel we gebruik maken van overheidsbrede standaarden, kunnen we onze ketenstandaarden niet opleggen aan (ketenpartners in) andere ketens.
De Migratieketen maakt ook steeds meer deel uit van een groter Europees geheel. Een voorbeeld van een notificatie uit Europa is de gebeurtenis dat er “een gele link is ontstaan” die opgelost moet worden. Dit komt uit de Interoperabiliteitsverordening. Met het nieuwe asiel- en migratiepact, wordt de Europese samenwerking inniger. Het zou dus ook zomaar kunnen dat er meer Europese gebeurtenissen relevant zijn voor de Bedrijfsprocessen in de Migratieketen of vice-versa. Door het ketenbrede mechanisme voor het notificeren over gebeurtenissen, zijn we hier klaar voor en kunnen we relatief eenvoudig deze Europese gebeurtenissen meenemen. Hierdoor geven we deels invulling aan MIRA principe 3C: De keten heeft het adaptief vermogen om in te spelen op (Europese) veranderingen.
Deze pagina is voor het laatst bewerkt op 19 dec 2024 om 21:41.