Deze handreiking heeft als doel om iedereen die voor de uitdaging staat een nieuw register te ontwerpen deelgenoot te maken van de inzichten die opgedaan zijn in het project "Uit betrouwbare bron".
Op basis van deze inzichten bieden we handvaten aan om beslissingen te nemen. Dit document is géén "cookbook: hoe bouw ik een register". Dit document wordt in de komende maanden stapsgewijs uitgebreid.
De overheid heeft de bevoegdheid om vergaand in de situatie van burgers en bedrijven in te grijpen. Door automatisering van het inwinnen en verwerken van gegevens kon dit ingrijpen een steeds grootschaliger karakter krijgen. Onze vermogens om overheidshandelen te begrijpen, controleren en daarbij eventueel gemaakte fouten te herstellen hielden met de mogelijkheden van digitalisering echter geen gelijke tred.
Waar het misging werden daardoor niet alleen meer burgers en bedrijven getroffen. Doordat gegevens geautomatiseerd door ketens stroomden, konden op basis daarvan meerdere organisaties handelen. Fouten hadden daardoor voor betrokkenen ook verstrekkender gevolgen.
Deze handreiking beschrijft hoe we overheidsinformatie in registers zodanig kunnen vastleggen en beschikbaar stellen dat we de betekenis en waarde daarvan beter kunnen beoordelen, fouten zoveel mogelijk kunnen voorkomen - en die als dat niet lukt - in ieder geval herstellen.
Zo lang burgers en bedrijven dingen willen die wij vooraf hadden bedacht, tijdig de juiste informatie aanleveren, en ‘onze’ overheidsgegevens kloppen - voorwaarden waaraan in de meeste gevallen wordt voldaan - verlopen processen snel en met minimale menselijke tussenkomst.
Maar wat gebeurt er als zo’n burger of bedrijf wordt geconfronteerd met een situatie die niet past binnen de grenzen van de happy flow? Wanneer iets moet worden aangevochten, onderzocht of gecorrigeerd? Deze handelingen zijn onderdeel van de crappy flow: een werkstroom die vrijwel altijd handwerk vereist, en soms überhaupt niet wordt afgehandeld.
Dit betekent dat resultaten die ontstaan uit happy flows zich gemakkelijk en grotendeels geautomatiseerd door het overheidsapparaat kunnen verspreiden, terwijl uit crappy flows voortkomende twijfelindicaties en correctiehandelingen - als ze al verwerkt worden - nauwelijks de grens oversteken naar vanuit gegevensgebruikperspectief stroomafwaarts liggende domeinen. Waardoor in die domeinen op basis van verkeerde gegevens onjuiste gevolgen geproduceerd kunnen worden.
Parabel: Infrastructuur van Digitalië
De eilanden van het atollenrijk Digitalië zijn met indrukwekkende hogesnelheidsinfrastructuur verbonden. Maar die is alleen toegankelijk voor een selecte meerderheid van contente conformisten.
Pogingen om op deze infrastructuur ook een minderheid van abusievelijke anarchisten toe te laten zijn allemaal mislukt. Want deze groep zonder vaste bestemming negeerde zorgvuldig vastgestelde gewichts- en hoogtebeperkingen, bewoog zich tegen rijrichtingen in en vroeg om afritten op onmogelijke plaatsen.
Terwijl hoog boven de golven contente conformisten voortrazen, zijn abusievelijke anarchisten in hun kleine scheepjes nog altijd overgeleverd aan de stormen van de Analoge zee. “Natuurlijk is dat onrechtvaardig”, bevestigt een beleidsmaker. “Maar er is gewoon geen businesscase.”
Het bovenstaande maakt duidelijk dat overheidsinformatie niet altijd klopt. En dit soort onjuistheden zullen altijd overblijven, hoeveel crappy flows we ook in happy flows weten om te zetten. Deze constatering vraagt om epistemische nederigheid; het erkennen dat onze kennis beperkt, voorlopig en mogelijk onjuist is.
Maar naar dit principe handelen is moeilijk als het gereedschap om de waarde van informatie te kunnen beoordelen ontbreekt. Binnen de overheid kunnen we zo’n inschatting op dit moment vaak alleen voor het ‘eigen’ domein maken. Dit betekent dat we niet kunnen achterhalen wie een keten van overheidshandelen in beweging heeft gezet, en wanneer en met welke reden dat is gebeurd. En dat we geen compleet beeld hebben van hoe lang óns handelen verderop in de keten nog doorwerkt.
Om dit op te lossen hebben we meer en beter inzicht in de context van onze informatie nodig. Deze behoefte kunnen we samenvatten in een aantal aspecten:
Het woord ‘register’ heeft in verschillende contexten uiteenlopende bekentenissen. Een organist zal daarbij denken aan een serie orgelpijpen met dezelfde klankkleur, een auteur ziet een lijst met trefwoorden voor zich, terwijl een werkplekbeheerder zich de editor voorstelt waarmee instellingen van Windowssystemen kunnen worden aangepast.
Associaties van geïnteresseerden in deze handreiking zullen waarschijnlijk dichter bij elkaar liggen. Maar ook als we de betekenisruimte inperken door te stellen dat een register iets te maken moet hebben met het verwerken van informatie binnen de overheid, blijven nog uiteenlopende zienswijzen over. Bijvoorbeeld:
Om verwarring te voorkomen, is het belangrijk het begrip register in de context van ‘Uit betrouwbare bron’ betekenis te geven. Wij definiëren een register als volgt:
“Een applicatiecomponent, of een verzameling samenwerkende applicatiecomponenten, gericht op het betrouwbaar vastleggen en presenteren van een geordende verzameling digitale overheidsinformatie.”
Register of registratie?
Binnen de overheid gebruiken we voor aanduiding van een georganiseerde gegevensverzameling zowel het begrip register (Kentekenregister, Register van overheidsorganisaties, BIG-register, UBO-register) als registratie (met name in de context van basisregistraties).
Er zijn twee redenen om binnen ‘Uit betrouwbare bron’ het begrip register te gebruiken. Enerzijds sluit dat het beste aan bij de betekenis in ‘gewoon’ taalgebruik. Een register is volgens het Van Dale-woordenboek een “inschrijvingsboek, naamlijst; goed geordende inhoudsopgave: bevolkingsregister, namenregister”, terwijl registratie wordt gedefinieerd als “inschrijving in een register: de registratie van een koopakte.”
Daarnaast willen we de indruk vermijden dat ‘Uit betrouwbare bron’ gaat over basisregistraties. Hoewel het project niet tot doel heeft een in productieomstandigheden werkend register op te leveren, verwachten we dat in deze handreiking beschreven bevindingen in eerste instantie waardevol zullen zijn binnen domeinen waarbinnen op basis van gedeelde kennis intensief wordt samenwerkt, maar (nog) geen basisregistratie bestaat.
Een definitie alleen is niet genoeg om duidelijk te maken waarover ‘Uit betrouwbare bron’ gaat. Ook een applicatiecomponent kan je immers vanuit verschillende perspectieven benaderen. Om duidelijk te maken welke daarvan wij innemen, beschrijven we de scope van het project aan de hand van twee elkaar aanvullende architectuurmodellen:
Betere ondersteuning van de crappy flow en het faciliteren van epistemische nederigheid vereist verandering in alle EIRA-lagen: juridisch, organisatorisch en technisch. Deze handreiking richt zich echter primair op de semantische en applicatielaag (het gebied binnen de paarse gestreepte lijn in bovenstaande figuur).
Binnen de applicatielaag kunnen we dankzij het Common Groundmodel preciezer zijn over onze scope: we beperken ons tot de lagen ‘databronnen’, ‘diensten’ en vanwege de relatie tussen bijhoudingsdiensten en processen die deze gebruiken ook een deel van ‘procesinrichting’ (gele gestreepte lijn in bovenstaande figuur). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:
Hoewel we andere lagen niet helemaal kunnen en willen negeren - hieronder bespreken we bijvoorbeeld de begrenzing van het register in relatie tot de (organisatorische) domeinen die het ondersteunt - betekent deze scopeafbakening dat we in deze handreiking geen aanbevelingen doen over bijvoorbeeld:
Registers staan niet op zichzelf, maar ondersteunen de overheid bij het invullen van haar administratieve behoeften. Die overheid vormt geen homogeen, eenduidig handelend geheel, maar is een pluriform en complex systeem.
Om de verhouding tussen register en overheid te kunnen duiden, moeten we dat systeem - liefst op basis van objectieve criteria - kunnen verkavelen naar logisch samenhangende delen, zonder daarbij al te veel door bestaande indelingen geleid of gehinderd te worden.
Ons streven is dat ieder van die delen groot genoeg is om zelfstandig bestaansrecht te hebben, maar klein genoeg om een ondubbelzinnig begrip van concepten, regels en processen te kunnen waarborgen.
Vaak wordt het woord domein gebruikt om binnen het totaal aan taken en verantwoordelijkheden van de overheid een specifiek, samenhangend werkgebied aan te wijzen. Maar anders dan in de wiskunde kent het begrip domein in organisatorische context geen objectieve afbakeningscriteria. Dit blijkt bijvoorbeeld uit de definitie die Eric Evans hanteert in de context van Domain driven design. Evans beschouwt een domein als “een sfeer van kennis, invloed of activiteit”. Hoewel deze definitie een zekere mate van interne samenhang veronderstelt, sluit die niet uit dat binnen één domein:
Een domein voldoet dus weliswaar aan de eis van zelfstandig bestaansrecht, maar is niet restrictief genoeg om ondubbelzinnig begrip van wat daarbinnen gebeurt te waarborgen.
Binnen een domein kunnen meerdere subdomeinen of taakgebieden bestaan. Daarbij horen verantwoordelijkheden, die zijn toegekend aan specifieke teams, afdelingen of bedrijfseenheden. Zij worden ondersteund door eigen semantiek, processen en regels. Deze zaken kunnen worden beschreven in een model: een systeem van abstracties dat beschrijft hoe men vanuit een taakgebied naar de wereld kijkt en reageert op veranderingen in de buitenwereld. Zo’n model is beschreven in gemeenschappelijke taal die binnen het hele taakgebied begrepen wordt.
Model en taal beschrijven dus een voor betrokkenen herkenbare ‘blauwdruk’ van het taakgebied, die (onder andere) de basis kan vormen voor het ontwerp van een register. Een in gemeenschappelijke taal ondubbelzinnig en samenhangend gemodelleerd taakgebied noemen we een bounded context.
Het belang van het erkennen van bounded contexten wordt door Eric Evans in ‘the Blue Book’ over Domain driven design als volgt beschreven:
“A bounded context delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other contexts. Within that context, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other contexts, other models apply, with differences in terminology, in concepts and rules, and in dialects of the ubiquitous language [red. gemeenschappelijke taal]. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other contexts. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly.”
Uit dit citaat blijkt dat de ambiguïteiten die we op domeinniveau nog konden tegenkomen binnen een bounded context (idealiter) verdwijnen. Hier geldt (zoveel mogelijk) dat:
Bounded contexten bestaan zelden in volledige isolatie. Veel vaker zijn ze in ketens of netwerken verbonden met andere bounded contexten. Dit betekent dat een gevolg dat werd geproduceerd in de ene context, in een volgende context wordt beschouwd als aanleiding of trigger voor het produceren van een nieuw gevolg. Bij het oversteken van de grens tussen de twee bounded contexten ontstaat een contextovergang. Hierbij moeten taal en model van de ene context omgezet worden naar taal en model van de andere.
Leveringen kennen daarom geen ‘vaste’ bounded context. Deze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een levering gaat. In andere gevallen kan een levering echter expliciet bedoeld zijn om een specifieke (afnemende) bounded context te informeren. Op verzoek van deze contexten kunnen vanuit de producerende context daarom leveringen worden geproduceerd die dichter tegen de context van de ‘afnemende bounded context’ aanliggen.
Soms zal een producent van gevolgen ervoor kiezen om beide te doen: naast een of meerdere leveringen die taal en model van de ‘eigen’ context volgen, worden dan ook leveringen gemaakt die aansluiten bij de conventies van bounded contexten van afnemers.
Taak en gevolg hebben wel een vast bounded context en conformeren zich altijd aan de taal en het model van de bounded context waarbinnen ze worden uitgevoerd c.q. geproduceerd.
Binnen iedere bounded context wordt gewerkt. Een deel van dat werk slaat neer in onze registers. Om te begrijpen welk deel, moeten we het karakter van dit werk op abstract niveau begrijpen. In dit hoofdstuk beschrijven we daarom een conceptualisering van de overheid als uitvoerder van taken die horen bij publieke dienstverlening. Vertrekt hiervoor is de overheid als producent van gevolgen en consument van leveringen.
Het begrip gevolg wordt op Wikipedia beschreven als “een gebeurtenis of omstandigheid die optreedt als resultaat van een of meer oorzaken en bijdragende factoren en omstandigheden”. Binnen de context van deze handreiking hanteren we een wat preciezere betekenis, namelijk het gevolg als “duurzaam betekenisvol resultaat van overheidshandelen”.
Om bovenstaande definitie te begrijpen, is het behulpzaam het handelen van de overheid nader te bekijken. Dat handelen begint bij een taak of bevoegdheid, die ontstaat vanwege attributie (‘toewijzen’) door de wetgever. Artikel 5.8 van de Omgevingswet attribueert bijvoorbeeld aan het college van burgemeester en wethouders de bevoegdheid te beslissen of een omgevingsvergunning al dan niet wordt verleend.
Een bevoegdheid houdt (mits aan een aantal basisvoorwaarden voldaan is) een plicht tot handelen in; het college kan er dus niet zelfstandig voor kiezen de ene aanvraag wel, en de andere niet in behandeling te nemen. Dit betekent dat een aanvraag altijd leidt tot één of meer handelingen, die weer één of meer resultaten opleveren. In het geval van de omgevingsvergunning is aan te denken aan handelingen als:
Daarbij horen resultaten als:
Niet al deze resultaten zijn echter een gevolg. We hebben immers gesteld dat daarvoor een duurzaam betekenisvol karakter nodig is. Het is niet eenvoudig deze karakteristiek in algemeenheid waterdicht te definiëren. Informeel kunnen we stellen dat het resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt als gevolg gezien moet worden. Vaak (maar niet per definitie) is zo’n gevolg gelijk aan het rechtsgevolg dat naar aanleiding van overheidshandelen ontstaat.
In het geval van de omgevingsvergunningaanvraag beschouwen we op basis hiervan het verlenen (of juist het niet verlenen) van de gevraagde omgevingsvergunning als gevolg. Specifieke voorwaarden waaronder de vergunning is verleend, zoals een maximaal bouwvolume of vereiste goothoogte kunnen van zo’n gevolg onderdeel zijn.
Hoewel het voor de hand ligt een gevolg te beschouwen als verandering in de bounded context waarbinnen gehandeld wordt, maakt het bovenstaande duidelijk dat hiervan niet altijd sprake hoeft te zijn. Het niet-verlenen van de omgevingsvergunning betekent vanwege het gesloten karakter van het omgevingsrecht dat iets wat vóór de aanvraag niet mocht, nu nog steeds niet mag. Hier is dus sprake van een (beargumenteerde) bevestiging van de bestaande situatie, en niet van een verandering. Zo’n verandering zien we wel als de vergunning wordt verleend, waarna iets wat eerst niet mocht, (nu) wel mag.
Voor een vollediger begrip van hoe een gevolg ontstaat, moeten we het bijbehorende productieproces in meer detail bekijken. Binnen dat proces kunnen we drie belangrijke concepten onderscheiden. Hierbij geldt dat ieder volgend concept afhankelijk is van het voorgaande:
Hierboven benoemden we het signaal als aanleiding voor de productie van één of meerdere gevolgen. Maar we beschreven niet waar zo’n signaal vandaag komt. Omdat binnen de overheid vaak in ketens of netwerken wordt gewerkt, is de bron van zo’n signaal heel vaak óók de overheid. Meer precies een andere bounded context die een gevolg heeft geproduceerd en keten- of netwerkpartners daarover informeert.
Dit betekent dat de productie van een gevolg in heel veel gevallen niet het eindstation van overheidshandelen is. Vrijwel altijd willen daarover ook anderen informeren - bijvoorbeeld de burger die een omgevingsvergunning heeft aangevraagd uit het voorbeeld hierboven, maar ook bedrijven, partnerorganisaties of collega-overheden. Deze doelgroepen hebben uiteenlopende informatiebehoeften en verwerken informatie op verschillende manieren.
Diversiteit in behoeften en verwerkingsvoorkeuren betekenen dat een informering meer omvat dan alleen de betekenis die een gevolg beschrijft. Die betekenis wordt in een bepaalde vorm overgebracht - denk aan een per mail verzonden besluit in Pdf-formaat, het resultaat van een specifieke query of een voor geautomatiseerde verwerking geschikte notificatie. Dit betekent dat we te maken hebben met een representatie van een gevolg.
Bij die representaties horen verschillende verstrekkingspatronen. Sommige leveringen worden pas verstrekt als daarom wordt gevraagd, bijvoorbeeld na aanroep van een bevragingen-interface. Andere leveringen worden juist proactief aangeboden, zoals een systeemnotificatie die naar aanleiding van registratie van een nieuw gevolg automatisch wordt verzonden.
Dat we met het doel anderen daarover te informeren op basis van een gevolg verschillende representaties creëren, rechtvaardigt het toevoegen van een vierde vierde begrip aan de drie concepten die we hierboven opsomden:
Met de toevoeging van levering is onze conceptualisatie van overheidshandelen bij publieke dienstverlening in de uitvoering compleet. Hieronder is dit proces volledig geïllustreerd.
Dat overheden elkaars leveringen gebruiken als grondstof voor het produceren van nieuwe - eigen - gevolgen klinkt vanzelfsprekend, maar brengt voor zo’n levering wel eisen met zich mee.
Een leveringsconsument heeft bijvoorbeeld duidelijkheid nodig over de bedoeling en betekenis van zo’n levering, zodat bepaald kan worden of de eigen taken of bevoegdheden het nodig maken naar aanleiding daarvan te handelen. Dit betekent dat bij leveringen verschillende aspecten van interpreteerbaarheid een rol kunnen spelen: wat is de boodschap, op welk moment heeft die betekenis, voor wie is die bedoeld, en in welke omstandigheden is die toepasbaar? Dit noemen we de context van de levering.
Producenten van leveringen kunnen interpretatieverwarring over leveringen deels voorkomen door die te laten aansluiten bij taal en model van consumerende bounded contexten waarbinnen gegevens ontvangen en verwerkt gaan worden.
Onderdeel van deze contextinformatie is ook twijfel over de juistheid van, of andere kwaliteitsvoorbehouden bij de inhoud van de levering. Zulke twijfels kunnen zijn ontstaan na constatering van (vermoedelijke) fouten door een leveringsconsument. Die moet dergelijke fouten dan wel kunnen melden, wat vraagt om betwistbare leveringen - of met andere woorden: leveringen waarop teruggemeld kan worden, waarop onderzoek, en indien nodig, correcties kunnen volgen.
Leveringen moeten daarnaast een onveranderlijk karakter hebben. Het vandaag opvragen van geleverde gegevens moet ook morgen of over een aantal jaar - zolang tenminste dezelfde vraag gesteld wordt - hetzelfde resultaat opleveren. Dit noemen we de herhaalbare vraag.
Toegangsbeperkingen zijn een laatste punt van aandacht. Bijvoorbeeld vanwege het waarborgen van de privacy van betrokkenen mogen sommige afnemers misschien niet kennisnemen van een volledig gevolg - zoals een adoptie - terwijl onderdelen daarvan - zoals een verandering van ouderschap - voor hen wel relevant zijn.
Bespiegeling over de modellering van gevolgen
Bovenstaande roept vragen op over wat nu precies de omvang en granulariteit van gevolgen bepaalt. Hierboven noemden we als uitgangspunt het (handelings)resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt. Dit impliceert dat alléén vanuit het proces dat ze produceert wordt bepaald wat als gevolg wordt beschouwd. Als vervolgens echter blijkt dat afnemers in heel veel gevallen slechts recht hebben een deel van een gevolg in te zien - zoals in het adoptievoorbeeld - is de vraag gerechtvaardigd of voor dat gevolg niet een te grote omvang is gekozen. De metafoor van de januskop helpt hier ook: het gedeelde brein, waarin de belangen van gevolgenproducent en leveringsconsument samenkomen, moet zorgen voor een logische begrenzing van het gevolg.
Nu we een beeld hebben van hoe publieke dienstverlening binnen de overheid werkt en beschikken over een bijbehorend begrippenkader, kunnen we overstappen naar het onderwerp van deze handreiking: registers. We beginnen die gezamenlijk te beschouwen, als ‘datalaag van de overheid’.
Bestaande overheidsregisters zijn op basis van ondertussen vaak decennia-oude techniek en inzichten primair ontworpen om administratieve processen efficiënter te maken. Deze inzichten en techniek zijn verrassend veerkrachtig en toekomstigbestendig gebleken. Maar dit vereiste ook dat bijvoorbeeld bijhouding en levering in één model werden samengebracht.
Dit compromis blijkt terugblikkend ongemakkelijk. Registers bevatten daardoor presentaties die niet helemaal voldoen aan de behoeften van afnemers, maar tegelijkertijd vanuit bijhoudingsperspectief ook niet de essentie - ofwel gevolgen representeren.
Veel registers bedienen alle afnemers op basis van één generieke gegevensset. Omdat in dat geval geen onderscheid wordt gemaakt naar taken en bevoegdheden, krijgen sommige afnemers meer informatie dan nodig - en soms zelfs toegestaan - is, terwijl anderen juist gegevens missen.
In veel registers wordt bovendien contextinformatie niet (volledig) vastgelegd. Informatie over de aanleiding van een wijziging, de juridische grondslag of de handelingen die tot het resultaat hebben geleid ontbreekt of is onvolledig. Voor een afnemer is daardoor niet altijd duidelijk wat een gegeven precies betekent, voor welke situatie het geldt en hoe het moet worden geïnterpreteerd.
Historie wordt vaak slechts beperkt bijgehouden. Soms is alleen de actuele toestand beschikbaar, in andere gevallen is die beperkt tot eendeminsionale wijzigingshistorie. En als wel volledige historie in twee dimensies wordt bijhouden, zorgt het toestaan van wijzigingen in de registratietijdlijn (bijvoorbeeld als gevolg van rechtelijke uitspraken) dat het stellen van een gegarandeerd herhaalbare vraag moeilijk niet mogelijk is.
Ook het betwisten en corrigeren van gegevens is vaak onvolledig ondersteund. Wanneer een afnemer een mogelijke fout constateert, bestaat er meestal geen gestandaardiseerde manier om die constatering zichtbaar te maken voor andere afnemers. Terugmeldprocessen bestaan meestal wel op organisatieniveau, maar de koppeling tussen deze processen en de registers die betwiste gegevens leveren zijn niet altijd goed ingericht.
Een combinatie van bovenstaande zorgt ervoor dat het vaak niet mogelijk is mutaties met terugwerkende kracht uit te voeren. Dit betekent dat fouten die het nodig maakt niet-actuele informatie te corrigeren, niet kunnen worden hersteld. Dit betekent dat betrokkenen blijvend met de gevolgen van foute gegevens geconfronteerd worden.
Deze beperkingen waren lang onvermijdelijk en werden, afgezet tegen geboekte efficiëntiewinst, als acceptabel beschouwd. Maar nu overheidsorganisaties de ambitie hebben (zie hieronder) veel vaker elkaars gegevens gebruiken als grondstof voor nieuwe besluiten en gevolgen, en dat bovendien bij de bron te doen, wordt het belangrijk dat leveringen ook context, betwistbaarheid, reproduceerbaarheid en passende toegang ondersteunen.
De De Architectuur Digitale Overheid 2030 onderkent de belangrijke rol van data bij (proactieve) beleidsontwikkeling en dienstverlening van de overheid. Om wildgroei en kwaliteitsverlies te voorkomen, willen we die data liever vanuit een aangewezen bron hergebruiken dan (steeds) opnieuw inwinnen. Dat vraagt om de organisatie-overstijgende waarborgen voor gegevenskwaliteit en -uitwisselbaarheid waaraan onder de naam Federatief Datastelsel (FDS) wordt gewerkt.
Deze handreiking beschrijft hoe partijen in de FDS-rol van data-aanbieder hun data zodanig kunnen vastleggen en beschikbaar stellen dat die een bruikbare basis vormt voor FDS-datadiensten.
Binnen de overheid bestaan ook andere initiatieven die vernieuwing van het fundament van de overheidsinformatievoorziening bepleiten. Sommige daarvan, zoals Regelrecht zouden traditionele registers uiteindelijk overbodig kunnen maken. Chronolexografie is een manier om heel gestructureerd rechtstoestanden - oftewel “hetgeen juridisch gezien het geval is (geweest)” - vast te leggen en te reproduceren.
Ten opzichte van bovengenoemde initiatieven zijn de aanbevelingen in deze handreiking minder vergaand, ambitieus en prescriptief (we schrijven immers geen vastleggings- of verwerkingsconventies voor). Wel liggen ze in elkaars verlengde; de uitgangspunten in deze handreiking moeten ook relevant zijn voor systemen die op regelrecht- of chronolexografiegedachtengoed gefundeerde data vastleggen en beschikbaar stellen.
We streven er dus naar deze handreiking toepasbaar te laten zijn bij uiteenlopende vereisten, omstandigheden, en omgevingen. Tegelijkertijd willen we oplossingen bieden voor de hierboven beschreven problemen. Bovendien willen we aansluiten bij, en voorsorteren op overheidsbrede ontwikkelingen die de werking van registers raken. Onderstaande uitgangspunten helpen hierbij door scope te beperken en elementaire werking te beschrijven.
We kopiëren te veel gegevens zonder mechanismen om kwaliteit en actualiteit van die kopieën te waarborgen. Deze handreiking is erop gericht de noodzaak voor het maken van gegevenskopieën bij uitvoeren van publieke dienstverleningsprocessen waar dat haalbaar is weg te nemen.
We erkennen een verschil tussen formeel beschreven of informeel uitgevoerde processen en daaruit voortkomende resultaten. Een proces vertelt hoe de overheid handelt. Als resultaat daarvan ontstaat iets met betekenis of waarde. Deze handreiking gaat niet over procesautomatisering, maar beschrijft op welke manier we de resultaten daarvan zo goed mogelijk kunnen vastleggen en beschikbaar stellen.
Als het gaat om bovengenoemde resultaten, erkennen we het verschil tussen betekenis van een resultaat - dat we gevolg noemen, en communicatie daarover, waarvoor een representatie (levering) nodig is. Het verenigen van deze concepten in één artefact - bijvoorebeeld een akte - werkt ‘vormfouten’ (bijvoorbeeld het onjuist overnemen van een juiste conclusie in een besluit of databasetabel) in de hand.
Hoewel sprake is van een afhankelijkheidsrelatie - de levering is afgeleid van het gevolg - zijn ze vanuit verantwoordingsperspectief van even groot belang. Het gevolg betekenis als ‘kern’ van wat bedoeld werd, en de levering als hetgeen op basis waarvan anderen (mogelijk) hebben gehandeld.
Bij deze conceptualisatie past de metafoor van de januskop of het hoofd met twee gezichten. Janus deelt één brein - dus een gedeelde, onderling verbonden hoeveelheid kennis, met daarop twee perspectieven, ingegeven door twee paar zintuigen. Het ene paar blikt terug op een proces dat een bepaald resultaat - of gevolg opleverde, terwijl het andere paar vooruit kijkt, richting door leveringen van die gevolgen in gang gezette vervolghandelingen.
Janus(kop)
In de beeldhouwkunst en schilderkunst is een januskop een hoofd met zowel aan de voorzijde als aan de achterzijde een gezicht. Het is genoemd naar de Romeinse god Janus, die in een van zijn verschijningsvormen twee gezichten had.
Afbeeldingscredit Igor Gordeev
Janus was een Romeinse god die heerste over alle begin en overgang. Vóór hij door Jupiter tot god met twee gezichten gemaakt werd, heerste hij volgens legende als koning over Latium. Daar werd hij beschouwd als stichter van het maatschappelijke leven en van de maatschappij, die de mensen verloste uit hun barbaarse toestand en tot een ordelijk leven bracht.
Gelijktijdig erkennen van het verschil tussen, en gelijkwaardig belang van gevolg en levering, vraagt in registerarchitectuur om onderscheid tussen bijhouding en levering. Dit maakt het mogelijk om op de specifieke informatiebehoefte van bepaalde afnemers (of leveringsconsumenten) toegesneden informatieproducten te leveren.
De wens onnodige kopieën te vermijden vraagt erom deze perspectieven op één onderliggende werkelijkheid beide als bron met zelfstandig bestaansrecht te beschouwen. Aandachtsgebieden voor betrouwbare registers zijn dan ook voor beide perspectieven relevant. De begrippen gevolgenjournaal en leveringenstaat gebruiken we om de gegevensverzamelingen die bij de perspectieven horen te onderscheiden.
Als we registers werkelijk capabel en betrouwbaar willen maken, moeten we vanaf het eerste ontwerp met een aantal belangrijke aandachtsgebieden rekening houden.
Deze aandachtsgebieden worden hieronder in algemene zin beschreven. In de hoofdstukken hierna beschrijven we hoe ze specifiek doorwerken in het gevolgenjournaal en de leveringenstand.
Terugmelden is het proces waarbij een afnemer van gegevens aan de bronhouder meldt dat hij twijfelt aan de juistheid van geleverde gegevens.
De term is afkomstig uit het stelsel van basisregistraties. Binnen dat stelsel zijn overheidsorganisaties verplicht twijfel over de juistheid van gegevens aan de bronhouder te melden.
Functioneel is het principe echter breder toepasbaar: overal waar gegevens worden gedeeld tussen een beheerder en afnemers, kan terugmelden als mechanisme dienen om de kwaliteit van die gegevens gezamenlijk te bewaken.
Na een terugmelding moet de bronhouder beoordelen of de gemelde twijfel gegrond is. Daartoe onderzoekt hij of de betreffende projectie inderdaad onjuist is, en zo ja, of die onjuistheid te herleiden is naar een of meer onjuist geregistreerde gevolgen - en mogelijk andere daarvan weer afgeleide projecties.
Dit onderzoek vindt plaats buiten het register, bijvoorbeeld in een zaaksysteem of ander procesondersteunend systeem. Gedurende het onderzoek kunnen in het register wel indicaties van twijfel worden aangebracht, zodat afnemers weten dat over de juistheid van bepaalde projecties of gevolgen onderzekerheid bestaat.
Wanneer het onderzoek onjuistheden aan het licht brengt, corrigeert de bronhouder de betrokken gegevens.
Een betrouwbaar register legt niet alleen vast wat er is gebeurd, maar ook waarom en hoe dat is gebeurd. Deze contextinformatie hoort bij het aspect dat we verwerkingsverantwoording noemen. Verwerkingsverantwoording stelt afnemers in staat de betekenis en herkomst van een gegeven te beoordelen, en maakt het mogelijk fouten te herleiden en te herstellen. Verwerkingsverantwoording valt in drie onderdelen uiteen:
De aanleiding beschrijft wat de productie van een gevolg in gang heeft gezet. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.
Met legitimering bedoelen we het wettelijk of beleidskader dat diende als grondslag voor de productie van een gegeven.
Met de verklaring wordt duidelijk gemaakt op welke manier het legitimerende kader in een specifieke situatie is gehanteerd. Denk daarbij aan informatie over toegepaste procedures, versieaanduidingen van gebruikte algoritmes of de motivatie van een ambtenaar die op basis van discretionaire bevoegdheid van een norm afweek.
Geldigheid beschrijft wanneer en op wiens gezag iets ‘gold’ of beschouwd werd als ‘juist’ of ‘waar’.
Geldigheid wordt bepaald door het administratieve domein dat gegevens registreert. In tegenstelling tot de registratiecontext is geldigheid een onveranderlijk of ‘intrinsiek’ onderdeel van hetgeen geregistreerde gegevens beschrijven. Gegevens die in meerdere registers gedupliceerd zijn, hebben als logisch gevolg hiervan in ieder van die registers dezelfde geldigheid.
Geldigheid als administratief construct
Hoewel het woord ‘intrinsiek’ anders kan doen lijken, is geldigheidstijd een administratief construct. Niemand zal kersverse ouders immers een kaartje sturen om te ze te feliciteren met de nieuwverworven geldigheid van hun pasgeboren baby. In de ’echte’ wereld, waar de dingen die we met behulp van gegevens beschrijven daadwerkelijk bestaan, komen we dus hooguit gebeurtenissen tegen die aanleiding geven om gegevens in administratieve context als geldig te gaan beschouwen. In het geval van een persoon kan dat een geboorte zijn, maar bijvoorbeeld ook een immigratie als iemand pas op latere leeftijd in beeld komt van ‘onze’ administratieve werkelijkheid. Overlijden zou aan de andere kant een reden kunnen zijn om de geldigheid van een persoon te beëindigen.
Registratiecontext beschrijft wanneer en door wie - welke medewerker of afdeling - iets is vastgelegd.
In tegenstelling tot geldigheid is de registratiecontext niet onverbrekelijk gebonden aan een set gegevens. De registratiecontext wordt ten opzichte van daarvan daarom ook wel als ‘extrinsiek’ beschouwd.
De registratiecontext wordt bepaald en vastgelegd door het systeem waarin gegevens worden bijgehouden. Dit kan een IT-systeem zijn, maar ook het sociotechnische systeem waarin mensen en IT-systemen samenwerken om taken uit te voeren. Dit betekent dat gegevens die in meerdere systemen zijn vastgelegd, in ieder van die systemen verschillende registratiecontexten hebben.
Bespiegeling over tijd
De aandachtgebieden geldigheid en registratiecontext zijn sterk verbonden met het concept tijd. Over dit onderwerp in relatie tot registers zijn boekenkasten vol geschreven. Daarin worden eindeloos veel verschillende ‘tijdsoorten’ of ‘tijdsassen’ genoemd. Binnen deze handreiking maken we primair onderscheid op basis van wie of wat de waarde van een tijdstip of periode bepaalt.
Bij domeintijd wordt de temporele waarde bepaald op basis van de werkelijkheid, de regelgeving of de bestuurlijke context waarbinnen een registratie werkt. Geldigheidstijd is het bekendste voorbeeld, maar ook ‘event occurence time’ - het tijdstip waarop een gebeurtenis plaatsvond - valt hieronder, evenals juridische inwerkingtredingsdata of beslistermijnen. Domeintijd is intrinsiek, dus onlosmakelijk onderdeel van en verbonden met de gebeurtenis of toestand die een registratie beschrijft.
Bij systeemtijd wordt de waarde bepaald door het IT- of sociotechnische systeem dat gegevens verwerkt en opslaat. De registratietijd is hiervan het enige voorbeeld: het systeem legt vast wanneer een gegeven beschikbaar kwam, ongeacht wat er inhoudelijk is gebeurd. Systeemtijd is daarmee per definitie extrinsiek; het zegt iets over de verwerking van een registratie binnen een systeem, maar niets inhoudelijks over de gebeurtenis of toestand die een registratie beschrijft.
Met zekerheid bedoelen we de mate waarin een registratie als feitelijk juist wordt beschouwd. Zekerheid is om twee redenen geen eenvoudig begrip. Ten eerste is het gradueel: een registratie kan geverifieerd en onbetwist zijn, maar ook onbevestigd, in onderzoek, of actief betwist. Ten tweede is zekerheid niet altijd gedeeld: verschillende partijen kunnen op hetzelfde moment een verschillend oordeel hebben over de juistheid van dezelfde registratie.
(On)zekerheid werkt diep door in ketens of netwerken. Als een bedrijfsregel bij het afleiden van een resultaat steunt op een gegeven waaraan getwijfeld is, is immers ook dat resultaat onzeker. Als datzelfde resultaat door andere partijen in de keten gebruikt weer wordt gebruikt als basis voor eigen handelingen, kunnen weer nieuwe op onjuiste gronden gefundeerde resulaten ontstaan, enzovoorts.
Onttrekking is het logisch ongedaan maken van een registratie in een overheidsregister, zonder dat de bijbehorende gegevens fysiek worden verwijderd.
In een betrouwbaar register verwijderen we geen gegevens die we mogelijk ooit hebben geleverd. Fysiek verwijderen levert op conceptueel niveau geschiedvervalsing op en breekt op functioneel niveau de garantie op de herhaalbare vraag. Om historische vastleggingen gegarandeerd te behouden, hanteren we voor het gevolgenjournaal en de leveringenstaat een append only-patroon: gegevens worden alleen toegevoegd, nooit overschreven of verwijderd.
Om de reden voor het onttrekken van gegevens goed te begrijpen, is het eerst nodig om onderscheid aan te brengen tussen twee verschillende vormen van juistheid:
Vervolgens kunnen we (tenminste) de volgende aanleidingen onderscheiden:
Onttrokken gevolgen zijn niet langer beschikbaar voor ‘normaal’ gebruik. Onttrokken gevolgen worden niet meer getoond in standaardprocessen, rapportages of openbare inzage en zijn niet langer beschikbaar voor normaal gebruik door ambtenaren, burgers of geautomatiseerde systemen.
Bespiegeling: is onttrekking een gevolg?
De vraag is of onttrekking zelf als gevolg moet worden beschouwd. Het alternatief is onttrekking te behandelen als een abstract supertype - een op technisch niveau geïmplementeerd begrip dat in de administratieve praktijk verschijnt in herkenbaarder vormen zoals correctie, herstel, herroeping of vergeten in de context van het AVG-recht op vergetelheid.
Het gevolgenjournaal is een volledige en onveranderlijke vastlegging van alle gevolgen die binnen een register werden geproduceerd, in de volgorde waarin die gevolgen ontstonden. De naam is ontleend aan het scheepsjournaal, waarin door nauwkeurige waarnemers volledig, chronologisch, zonder weglating én zonder oordeel wordt genoteerd wat is waargenomen.
Gevolgen zijn temporeel atomair: ze gebeuren op een moment, maar hebben geen duur. Geboortes, verhuizingen of huwelijken markeren geen toestand, maar beschrijven de verandering die van de ene toestand leidt naar de volgende. Gevolgen zijn daarmee een voorbeeld van wat transitional modeling of overgangsmodellering wordt genoemd.
Vraagstuk: gevolgen feitelijk of administratief formuleren?
Gevolgen kunnen we op twee manieren formuleren:
- Feitelijk, beschouwd vanuit de werkelijkheid waarop dat handelen betrekking heeft - ongeacht de wijze waarop het administratief is verwerkt of vastgelegd. Bijvoorbeeld
"persoon p1 geboren".- Administratief, beschouwd vanuit de administratieve context waarbinnen dat handelen heeft plaatsgevonden - dat wil zeggen: de registratie, vastlegging of formalisering van een feitelijk gevolg binnen een specifiek overheidsproces. Bijvoorbeeld:
"geboorte persoon p1 geregistreerd".Welke van de twee we kiezen heeft effect op de aandachtsgebieden geldigheid en zekerheid. Zie de toelichting onder de corresponderende koppen.
Terugmelden gebeurt door afnemers op een projectie die onderdeel is van de leveringenstaat, en dus níet op een gevolg in het gevolgenjournaal.
Onderzoek(en) naar aanleiding van een terugmelding gebeuren buiten het register. Zo’n onderzoek zelf leidt dus niet tot nieuwe gevolgen in het gevolgenjournaal. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste gevolgen binnen het register indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.
Het gevolgenjournaal is append only: gevolgen worden alleen toegevoegd, nooit overschreven of verwijderd. Correctie betekent dus altijd het toevoegen van een nieuw gevolg dat een eerder gevolg ongedaan maakt of herziet.
Bij voorkeur gebeurt dat in de taal van de bounded context; een
gevolg als "emigratie p1 herroepen" maakt de bedoeling
direct duidelijk. Deze aanpak heeft echter een praktische beperking:
het is niet goed mogelijk om vooraf alle situaties te voorzien
waarin correctie nodig kan zijn. Bovendien vereist ieder
domeinspecifiek correctiegevolg dat de bijbehorende bedrijfsregels
worden bepaald en geconfigureerd, wat bij een laag correctievolume
onevenredig veel ontwerplast met zich meebrengt.
Daarom kan het soms nodig zijn generieke correctiegevolgen te
introduceren die domeingevolgen ‘passeren’ en direct inwerken op de
begrippen uit de leveringenstand, zoals bijvoorbeeld
"verblijfsadres p1 gecorrigeerd". Belangrijk is dat
zulke correcties altijd in het gevolgenjournaal worden opgenomen en
transactioneel worden afgehandeld, zodat het journaal consistent
blijft.
In het uitzonderlijke geval dat niet meer te reconstrueren is hoe een bepaalde toestand is ontstaan, maar wel bekend is hoe die eruit zou moeten zien, kan het nodig zijn op basis daarvan een nieuwe historie op te bouwen. Dit soort ingrijpende correcties moet zoveel mogelijk beperkt blijven omdat daarop nauwelijks (al dan niet geautomatiseerde) integriteitscontrole mogelijk is en op basis daarvan moeilijk geleverd kan worden.
Op basis van het onderscheid tussen proces en resultaat willen we het register niet de wereld van procesuitvoering in trekken. Maar we willen afnemers wel in staat stellen door het register geleverde gegevens op onder andere betekenis, kwaliteit en juistheid te beoordelen. Verwerkingsverantwoording is daardoor binnen het gevolgenjournaal een belangrijk aandachtsgebied.
De aanleiding beschrijft wat de productie van een gevolg in gang heeft gezet. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Of meer precies: een levering, afkomstig uit een voorliggende bounded context, die als signaal is ontvangen en binnen de ‘eigen’ bounded context aanleiding gaf tot handelen. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.
Vragen bij het vastleggen van aanleiding in het gevolgenjournaal
- Wat slaan we op? Tenminste een verwijzing naar het voorliggende gevolg of de externe aanleiding, inclusief de partij die verantwoordelijk was voor productie van die aanleiding. Omdat hierbij grenzen tussen bounded contexten worden overgestoken, moeten contextoverstijgende afspraken worden gemaakt over vorm, inhoud en uitwisseling van deze verwijzing.
- Wat doen we met bijlagen? Aanleidingen kunnen gepaard gaan met ondersteunende documenten, zoals een aanvraagformulier of een bijgevoegd bewijs. Deze bijlagen zijn niet altijd op een volledig gevolg van toepassing. Een te complexe koppelstructuur tussen bijlagen en gegevens is moeilijk te begrijpen en te onderhouden. De vraag is of zulke complexiteit altijd noodzakelijk is, of dat een eenvoudiger benadering (aparte documentopslag waarnaar voor aanleiding verwezen kan worden) volstaat.
Voor ieder gevolg wordt een zo gedetailleerd mogelijke verwijzing naar het wettelijk of beleidskader dat diende als grondslag voor de productie daarvan vastgelegd.
Voor ieder gevolg wordt vastgelegd hoe het legitimerende kader in de betreffende situatie is toegepast. Deze verklaring omvat ten minste:
Voor ieder gevolg wordt het moment van vastlegging in het gevolgenjournaal vastgelegd.
Als we kijken naar temporele concepten die bij gegevensopslag een rol spelen, kunnen we in het gevolg een specifieke vorm van een event herkennen. Zo’n event wordt beschreven als een ogenblikkelijk feit, ofwel iets dat in één moment plaatsvindt.
Dit temporeel atomaire karakter maakt dat het gevolg geen
(geldigheids)duur heeft. In plaats daarvan kent het één door het
domein bepaald moment, dat samenvalt met het moment waarop het
gevolg in de echte wereld een verandering tot stand bracht. Dit
moment noemen we "gebeurd op".
In veel gevallen (maar niet alle, zie toelichting hieronder) kan
van het gebeurd op-moment bij een gevolg een
geldig vanaf-moment in een projectie worden afgeleid.
Ervan uitgaande dat we het moment van geboorte beschouwen als
startpunt voor een geldige inschrijving, kan bijvoorbeeld van het
gevolg persoon p1 geboren | gebeurd op 18-07-1985 de
volgende projectie worden afgeleid:
| persoon | geldig vanaf |
|---|---|
| p1 | 18-07-1985 |
Impact van feitelijk of administratief formuleren op aandachtsgebied geldigheid
- Bij feitelijke formulering is het ‘gebeurd op’-moment een logisch startpunt voor geldigheidsperiode(s) in leveringen, terwijl
- bij administratieve forumlering weliswaar sprake blijft van een domeindatum, maar het ‘gebeurd op’-moment meer neigt naar het karakter van een ‘geregistreerd op’-moment.
Of bij een gevolg twijfel over de feitelijke juistheid mogelijk of zinvol is, hangt af van de wijze waarop het gevolg is geformuleerd (zie toelichting hieronder). Voor zover dit wel mogelijk en zinvol is, maakt het register het mogelijk een zekerheidsindicatie vast te leggen, en biedt het gebruikers de mogelijkheid om hierop te reageren: door een regel situationeel te overrulen, door de verwerkingsengine onzekerheid te laten signaleren, of door bedrijfsregels expliciet te laten omgaan met onzekerheid.
Impact van feitelijk of administratief formuleren op aandachtsgebied zekerheid
- Bij feitelijke formulering beschrijft het gevolg iets wat buiten de context van het register is gebeurd. Deze gebeurtenis kan feitelijk waar, maar ook feitelijk onwaar blijken te zijn. Als we gevolgen feitelijk modelleren, lijkt het dus nodig om aan de juistheid van een gevolg te kunnen twijfelen door daaraan zekerheidskenmerken te verbinden, terwijl
- bij administratieve formulering het gevolg gaat over iets dat door registratie van gevolg zelf feitelijk waar wordt - de geboorteregistratie ontstaat immers door registratie van het bijbehorende gevolg. In dit geval ontstaat de feitelijke juistheid door registratie van het gevolg zelf, en lijkt het niet zinvol om aan de juistheid van een gevolg te kunnen twijfelen.
Iedere onttrekking begint in een gevolg, tenzij de fout uitsluitend zat in de wijze waarop leveringen uit het gevolgenjournaal werden afgeleid (zie leveringenstaat).
Los van de mate waarin een onttrekkingsgevolg aansluit bij de taal van de bounded context (zie corrigeren) beschrijft zo’n gevolg altijd de onttrekkingscontext. Die maakt achteraf reconstrueerbaar waarom en wanneer een gevolg niet langer beschikbaar is en omvat tenminste:
Als een onttrekking betrekking heeft op identiteitdragende kenmerken van een gevolg of levering, wordt het volledige gevolg of de volledige levering onttrokken. Bij niet-identiteitshoudende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.
De leveringenstaat is de volledige verzameling van projecties die op basis van het gevolgenjournaal afleidbaar zijn, en waaruit concrete leveringen aan afnemers worden gegenereerd. De naam is ontleend aan gebruik van het woord staat in samenstellingen als ‘staat van dienst’ of ‘urenstaat’, waarbinnen het zoiets betekent als “geformaliseerd, geordend overzicht”.
Waar het gevolgenjournaal nauwkeurig documenteert wat er is gebeurd, beantwoordt de leveringenstaat primair vragen als “leeft persoon p1 nog?”, “wat is zijn burgerlijke staat?”, en “heeft hij gezag over p3?” Zulke vragen veronderstellen een stand (ook wel toestand of state), ofwel een beeld van de wereld dat gedurende een bepaalde periode geldig is.
Niet alle projecties beschrijven een stand. Een notificatiebericht is daarvan een voorbeeld: het informeert een afnemer over een verandering die door registratie van een gevolg is veroorzaakt. Net als het onderliggende gevolg is zo’n bericht temporeel atomair - het beschrijft wat er is gebeurd, niet welke toestand na die gebeurtenis geldig werd.
Iedere concrete levering is een op de informatiebehoefte van een specifieke afnemer of doelgroep toegesneden uitsnede uit de leveringenstaat. Daarbij kan niet alleen de actuele state worden geleverd, maar op basis van selecties over meerdere tijdsassen eventueel ook historische toestanden.
Hoe de leveringenstaat technisch wordt bijgehouden is een implementatiekeuze: daarbinnen beschikbare projecties kunnen vooraf worden berekend en opgeslagen, of op het moment van bevraging worden gegenereerd op basis van de gevraagde parameters.
Terugmeldingen hebben altijd betrekking op een projectie - een concrete uitsnede uit de leveringenstaat zoals die aan een afnemer is geleverd. De afnemer meldt dat hij twijfelt aan de juistheid van (een deel van) die projectie.
Omdat projecties over uiteenlopende samenstellingen van gegevens kunnen gaan en de aard van geconstateerde onjuistheden sterk kan verschillen, kan een terugmelding vele vormen aannemen. Daarbij past geen beperkend ‘terugmeldformulier’, maar (vorm)vrijheid en veel ruimte voor toelichting in vrije tekst.
Als een bronhouder regelmatig terugmeldingen van dezelfde strekking ontvangt, kan hij overwegen daarvoor een specifieke, meer gestructureerde interface aan te bieden. Dit verlaagt de drempel voor de terugmelder en maakt de verwerking aan de kant van de bronhouder efficiënter.
Een terugmelding bevat in ieder geval:
Open vragen
Onderzoek(en) naar aanleiding van een terugmelding gebeuren buiten het register. Zo’n onderzoek zelf leidt leidt dus niet tot nieuwe projecties in de leveringenstaat. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste projecties binnen het register indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.
Onderzoek(en) naar aanleiding van een terugmelding vinden plaats buiten het register, en hebben dus geen gevolgen voor het gevolgenjournaal. Als gevolg van (tussen)resultaat van onderzoek moeten bij registraties in dat register wel zekerheidsindicaties kunnen worden aangebracht.
Iedere correctie begint met een gevolg in het gevolgenjournaal,
tenzij de fout uitsluitend zat in de wijze waarop leveringen werden
afgeleid - zie onttrekking. Op basis
van zo’n correctiegevolg wordt bepaald vanaf welk moment een
bestaande projectie niet langer geldig is. Die projectie krijgt
daarna een vervallen op-indicatie, waarmee de levering
voor actief gebruik wordt afgesloten.
Omdat projecties direct worden afgeleid uit gevolgen in het gevolgenjournaal, is verwerkingsverantwoording aan de kant van de leveringenstaat beperkter van omvang dan aan de journaalkant. De voornaamste verantwoording ligt immers al besloten in de gevolgen waarop een projectie is gebaseerd.
De aanleiding verwijst naar het gevolg of de gevolgen die als basis dienden voor de productie van de projectie. Daarmee is de herkomst van een projectie altijd herleidbaar naar het gevolgenjournaal.
Voor zover van toepassing wordt een verwijzing vastgelegd naar het wettelijk of beleidskader dat diende als grondslag voor de productie van de projectie - bijvoorbeeld als regelgeving voorschrijft welke gegevens aan welke afnemers geleverd mogen of moeten worden.
De verklaring omvat een verwijzing naar het algoritme of de algoritmes die zijn gebruikt om van één of meer gevolgen een projectie af te leiden, inclusief de versie daarvan. Zo is achteraf reconstrueerbaar op welke manier de projectie tot stand is gekomen.
Bij iedere concrete levering kan het moment van opname in de leveringenstaat worden meegeleverd. Of dat wenselijk is, hangt af van de situatie. Bij een vraag naar de actuele stand is registratietijd vaak niet relevant. In andere gevallen kan het meesturen ervan juist ongewenst zijn, omdat het informatie kan onthullen die niet met iedereen gedeeld mag worden, zoals het feit dat een correctie heeft plaatsgevonden.
Bij projecties die zijn opgebouwd uit meerdere gevolgen, is het belangrijk onderscheid te maken tussen de geldigheidsdatum van de projectie zelf en de domeindatums van de gegevens daarbinnen.
De geldigheidsdatum van een projectie geeft aan vanaf welk moment deze weergave in deze vorm als ‘juist’ of ‘waar’ beschouwd wordt. Die datum zegt (dus) niets over de ouderdom van in de projectie betrokken objecten of andere daarin opgenomen gegevens.
Neem als voorbeeld de volgende gevolgen:
woz-object w1 ontstaan | gebeurd op 15-08-1994belanghebbende bij woz-object w1 is p1 | gebeurd op 23-08-1994belanghebbende bij woz-object w1 is p2 | gebeurd op 19-10-2009belanghebbende bij woz-object w1 is p3 | gebeurd op 07-03-2023Het WOZ-object bestaat al sinds 15-08-1994, maar de projectie is voor het laatst bijgewerkt naar aanleiding van het gevolg van 07-03-2023. Die datum markeert dus niet het ontstaan van het object, maar het meest recente domeinmoment dat de huidige vorm van de projectie heeft bepaald.
Zonder die toelichting riskeert een afnemer de datum verkeerd te
interpreteren. Uit de projectie moet de betekenis daarom voldoende
duidelijk blijken - bijvoorbeeld door de
geldig vanaf-datum expliciet aan de projectie te
koppelen (zie het voorbeeld hieronder), of door aan te geven dat die
datum de laatste relevante wijziging in het domein betreft.
projectie l1
geldig vanaf 07-03-2023
woz-object w1
eerste registratie 15-08-1994
belanghebbenden
p1
start belang 23-08-1994
einde belang 18-10-2009
p2
start belang 19-10-2009
einde belang 06-03-2023
p3
start belang 07-03-2023Zekerheidsaanduidingen zijn in de eerste plaats relevant voor afnemers. Zekerheid moet daarom zichtbaar zijn in leveringen en (dus) onderdeel zijn van projecties.
Omdat onzekerheid diep kan doorwerken in ketens, is het niet altijd voldoende alleen de zekerheid van een projectie als geheel aan te geven. Een daartoe geautoriseerde afnemer moet ook kunnen zien welk onderliggend gevolg de bron van twijfel is, zodat hij kan beoordelen in hoeverre zijn eigen verwerking daarop steunt en hoe hij daarmee wil omgaan.
Afhankelijk van de situatie kan een afnemer er bijvoorbeeld voor kiezen een bedrijfsregel situationeel buiten werking te stellen, onzekerheid door te geven aan zijn eigen afnemers, of processen die op de gegevens steunen expliciet te laten waarschuwen wanneer zij onzekere gegevens tegenkomen.
Of een onttrekking ingrijpt in het gevolgenjournaal, de leveringenstaat, of beide, hangt af van waar de fout zat. Zat deze fout uitsluitend in de wijze waarop leveringen uit het gevolgenjournaal werden afgeleid - en niet in de gevolgen zelf - dan volstaat het de afleidingswijze te corrigeren en nieuwe projecties te produceren.
In alle gevallen resulteert een onttrekking in opname van een
vervallen op-moment (zie ook corrigeren) bij de door
de onttrekking geraakte projecties. Daarmee wordt de projectie voor
actief gebruik afgesloten, zonder dat de oorspronkelijke vastlegging
verdwijnt. De onttrokken projectie blijft om de herhaalbare vraag te
waarborgen technisch behouden. Die is daarna echter alleen onder
specifieke voorwaarden - bijvoorbeeld voor juridisch of historisch
onderzoek - toegankelijk.
Als de onttrekking betrekking heeft op identiteitsdragende kenmerken van een projectie, wordt de volledige projectie onttrokken. Bij niet-identiteitsdragende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.
Resultaat voor ontrokken gegevens moet in normaal verkeer hetzelfde resultaat zijn als bevragingen van niet-bestaande gegevens.
In het voorgaande is de context beschreven. Hieronder beschrijven we de elementen waaruit het register bestaat.
In de afbeelding hierboven zien we allereerst de eerder geïntroduceerde elementen signaal, taak, gevolg en bekendmaking terug. Deze elementen zijn geïllustreerd als bedrijfsobject.
Om op basis van het ene het opvolgende bedrijfsobject te kunnen produceren (bijvoorbeeld een gevolg op basis van een taak) zijn handelingen (bijvoorbeeld taak uitvoeren) nodig. Deze werden eerder impliciet benoemd, maar worden nu expliciet als bedrijfsprocessen opgenomen.
De wijze waarop bedrijfsprocessen worden uitgevoerd is beschreven in het model van de bounded context. De inhoud hiervan is vaak gebaseerd op andere kaders, zoals wet- en regelgeving, beleid en bedrijfs- of uitvoeringsregels. Het bindende karakter van het model wordt benadrukt door de illustratie als contract.
Het register zelf is geïllustreerd als element van het type application-collaboration om aan te geven dat het register niet per se één applicatieve component hoeft te zijn, maar ook - en misschien zelfs meestal - kan bestaan uit een samenhangende verzameling applicatiecomponenten.
De elementen die bijdragen aan de verwerking van commando’s en productie van gevolgen op basis daarvan vormen de bijhoudingskant (‘C’ in CQRS) van het register.
Het register wordt bediend door het aanbieden van commando’s. Deze data-objecten volgen altijd de taal en het model van de bounded context waarbinnen ze worden gemaakt en verwerkt.
Zowel de semantische en syntactische eisen aan commando’s als de wijze waarop die verwerkt moeten worden, zijn beschreven in het bijhoudingsmodel (data-object). Dit vormt dus het contract op basis waarvan commando’s worden verwerkt.
De Commandoverwerkingsservice (applicatieservice) controleert of aangeboden commando’s aan het contract voldoen.
Het bijhoudingsmodel en Commandoverwerkingsservice horen bij de Commandoprocessor (applicatiecomponent) die met het commando als input op basis van in het bijhoudingsmodel beschreven regels gevolgen (data-objecten) produceert.
Voor ieder bedrijfsobject van het type Gevolg dat wordt geproduceerd als resultaat van het bedrijfsproces ‘Taak uitvoeren’, wordt door het verwerken van een commando een equivalent data-object van het type gevolg geproduceerd. Dit data-object is een directe representatie van het bijbehorende bedrijfsobject. Zo registeren we (tenminste) de essentie van het overheidshandelen.
Gevolgen worden opgeslagen in de Gevolgenstore (applicatiecomponent).
De Gevolgenstore biedt toegang tot gevolgen via de Gevolgen-bevrageninterface (applicatie-interface). Deze interface wordt gebruikt door de Commandoprocessor als gegevens uit eerder vastgelegde gevolgen nodig zijn om te beoordelen welk gevolg moet worden geproduceerd.
De elementen die bijdragen aan de verwerking van gevolgen en productie van projecties op basis daarvan vormen de leveringskant (‘Q’ in CQRS) van het register.
Een gevolg dient als input voor de Gevolgenverwerkingsservice (applicatieservice).
De Gevolgenverwerkingsservice is onderdeel van de Gevolgenprocessor (applicatiecomponent) die projecties (data-objecten) produceert.
Projecties worden opgebouwd op basis van het leveringsmodel (data-object) dat beschrijft welke gegevens in welke vorm in een bepaalde projectie worden opgenomen.
Een projectie is een data-object, bedoeld om afnemers binnen en buiten ‘onze’ bounded context te informeren over wat binnen onze context is gebeurd. Een projectie kan allerlei vormen hebben: een databaserelatie, een notificatie(bericht) of een (digitaal) document.
Van het ‘setje’ Gevolgenverwerkingsservice, Gevolgenprocessor en leveringsmodel kunnen er meerdere naast elkaar bestaan. Dit betekent dat één gevolg door meerdere Gevolgenprocessoren wordt verwerkt om verschillende projecties op te bouwen.
Projecties kunnen ‘on demand’ (op aanvraag) worden gegenereerd of worden gepersisteerd. In dat laatste geval is in de vorm van een Projectiestore een extra applicatiecomponent nodig.
Toegang tot projecties wordt geleverd door de Projectietoegangsinterface (applicatie-interface).
Anders dan bij de relatie tussen Gevolg (bedrijfsobject) en gevolg (dataobject), vormt de projectie (dataobject) niet de volledige representatie van de Levering (bedrijfsobject). De projectie bestaat immers direct nadat die is geproduceerd, terwijl van een Levering pas sprake is nadat de projectie of een selectie daaruit aan iets of iemand is beschikbaar gesteld. Een Levering is daarom een voor consumptie aangeboden projectie.
Bespiegeling over projectie op basis van gevolg versus gevolg volgend op eerder gevolg
Bovenstaande laat ruimte voor discussie over de vraag in welke gevallen sprake is van een projectie op basis van een gevolg en een gevolg op basis van een eerder geproduceerd gevolg. Hiernaar kunnen we op ten minste drie manieren kijken:
- Iedere bewering die op basis van een gevolg (geautomatiseerd) binnen het register kan worden gecreëerd, beschouwen we als projectie. De binnen het register geproduceerde bewering met een ‘happened’, of gebeurtenisachtig karakter “aanschrijfvorm van persoon p1 gewijzigd in ‘mevrouw’” op basis van gevolg “geslacht van persoon p1 gewijzigd in ‘vrouw’” wordt in dit geval beschouwd als projectie.
- We beschouwen alleen representaties van een gevolg zelf, of daarvan afgeleide stand (of state-)informatie als projecties. Vervolgbeweringen met een ‘happened’-karakter beschouwen we als nieuwe gevolgen. De binnen het register geproduceerde bewering “aanschrijfvorm van persoon p1 gewijzigd in ‘mevrouw’” op basis van gevolg “geslacht van persoon p1 gewijzigd in ‘vrouw’” is in dit geval als nieuw gevolg. De op basis van hetzelfde gevolg geproduceerde standbewering “geslacht van p1 is ‘vrouw’” beschouwen we wél als projectie.
- We maken helemaal geen onderscheid tussen gevolgen en projecties. Iedere nieuwe bewering zien we als gevolg.
Het verwerken van signalen kan uiteraard ook applicatief ondersteund en eventueel geautomatiseerd worden. Dit geldt zeker als een signaal in de vorm van een notificatie wordt ontvangen. Omdat zo’n notificatie (ten opzichte van het register) veelal van buiten de ‘eigen’ bounded context afkomstig is, en vanuit het register dus geen controle bestaat over de vorm en inhoud daarvan, beschouwen we de elementen in de applicatiearchitectuur die hiervoor nodig zijn niet als onderdeel van het register. Deze elementen zijn daarom hierboven niet geïllustreerd.