Wat is een register?

Betekenis van het begrip ‘register’

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.

Beelden van lezers van deze pagina zullen waarschijnlijk meer bij elkaar aansluiten. 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:

• holistisch: een volledig stelsel gericht op het bijhouden en leveren van bepaalde gegevens, bestaande uit wet- en regelgeving, betrokken organisaties en hun onderlinge afspraken, systemen voor opslag en distributie van gegevens en de technische infrastructuur die hiervoor nodig is;
• universeel: een digitaal of fysiek bijgehouden verzameling geordende informatie;
• afnamegericht: een plaats waar bepaalde gegevens onder bepaalde voorwaarden verkregen kunnen worden, of
• technisch: een database.

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.”

Perspectieven op het register

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:

1. De European Interoperability Reference Architecture (EIRA)
2. Het Common Ground-vijflagenmodel

Het register in relatie tot EIRA

De EIRA omvat vier lagen. De tabel hieronder beschrijft van iedere laag de betekenis en bedoeling, aangevuld met concrete zaken die binnen zo’n laag thuishoren en voor registers relevant zijn.

Het register in relatie tot het Common Ground-vijflagenmodel

Het Common Ground-vijflagenmodel beschrijft een verdere ontleding van de EIRA-applicatielaag. Iedere laag in dit model vertegenwoordigt een binnen de applicatiearchitectuur duidelijk te onderscheiden verantwoordelijkheidsgebied. De tabel hieronder beschrijft van iedere laag de betekenis en bedoeling, aangevuld met concrete zaken die binnen zo’n laag thuishoren en voor registers relevant zijn.

Architectuurlagen en scope UBB

Aanbevelingen vanuit ‘Uit betrouwbare bron’ hebben primair te maken met de semantische en applicatielaag binnen EIRA (paarse lijn in figuur 1). In het geval van die laatste kunnen we dankzij het Common Groundmodel preciezer zijn: 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 lijn in figuur 1). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:

• benoemen, beschrijven en begrijpen van generieke (dus onafhankelijk van welke gegevens een register omvat toepasbare) functionaliteit. Denk hierbij aan onderwerpen als historie, herkomst en zekerheid;
• welke architectuurpatronen (CQRS, event sourcing) in welke situaties te volgen;
• ontwerp van interacties (bijhouden, corrigeren, bevragen, notificeren), en
• applicatieve structuur en functionaliteit van het register.

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 bijvoorbeeld geen aanbevelingen doen over:

• interpretatie of herziening van wet- en regelgeving;
• verdeling van verantwoordelijkheden over organisaties (wel/niet gescheiden organisaties voor bijhouding en levering, bijhouding en levering wel/niet organistorisch federatief of juist centraal);
• gebruik van specifieke technische producten (hoewel die bij onze beproevingen wel een belangrijke rol spelen);
• bij concrete implementatie in één technisch product clusteren van applicatiecomponenten (bijvoorbeeld vanwege van efficiëntie- of performanceredenen), en
• het ontwerpen van interfaces om registergegevens aan gebruikers te presenteren.

Registergrenzen

Register en domein

Een register is een verzameling geordende informatie. De grenzen van de verzameling worden net als de betekenis en samenhang van de in het register opgeslagen informatie bepaald vanuit het domein dat voor het register verantwoordelijk is. Anders dan in de wiskunde kunnen we voor registers niet precies aangeven waar het ene domein ophoudt en het volgende begint. Analoog aan de definitie van Eric Evans in de context van Domain Driven Design beschouwen we een domein daarom als “een sfeer van kennis, invloed of activiteit”. Deze definitie veronderstelt een zekere mate van samenhang. Tegelijkertijd kan het binnen één domein voorkomen dat:

• dezelfde concepten verschillend geïnterpreteerd worden,
• regels en gedrag niet consistent zijn, en
• bedrijfsprocessen niet op elkaar zijn afgestemd.

Fictief voorbeeld: milieu-effect van auto’s

De overheid wil de impact van auto’s op het milieu te begrijpen en daarop kunnen sturen. Binnen het domein ‘Weginfrastructuur’ heeft men het daarom over het ‘milieu-effect’ van een auto. Verschillende taakgebieden leggen dat begrip echter subtiel verschillend uit: voor prioriteren van onderhoud aan wegen en parkeerplaatsen zijn immers alleen gewicht en oppervlakte van een auto relevant, terwijl de eenmalige aanschafheffing ten bate van wegonderhoud ook op CO₂-uitstoot is gebaseerd.

Er is ook nog een heel ander domein waarbinnen het woord ‘milieu-effect’ wordt gebruikt, namelijk dat van ‘Mobiliteitsturing’. Binnen dit domein wordt daarmee een cijfer bedoeld dat wordt gebruikt bij uitvoering van beleid dat aandschaf van milieuvriendelijke auto’s en het delen van auto’s binnen een huishouden stimuleert.

Voor wie zoekt naar aanknopingspunten over welke informatie binnen ‘hoort’ binnen een te ontwerpen register en welke buiten de registergrenzen zou moeten vallen, biedt het denken in ‘sferen’ onvoldoende aanknopingspunten. We moeten dus op zoek naar formeler en objectiever grensbeschrijvingen.

Bounded context

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’ 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:

• dezelfde concepten eenduidig geïnterpreteerd worden (op basis van gemeenschappelijke taal),
• regels en gedrag consistent zijn, en
• bedrijfsprocessen op elkaar aansluiten.

Fictief voorbeeld: milieu-effect van auto’s

Het domein ‘Weginfrastructuur’ waarbinnen het begrip ‘milieu-effect’ twee betekenissen had, wordt gesplitst in twee bounded contexts: ‘Prioritering en planning wegonderhoud’ en ‘Innen aanschafheffing’. In het domein ‘Mobiliteitsturing’ introduceren we de ‘Spitspas’ als bounded context.

‘Wellbounded’ registers

Op basis van het bovenstaande kunnen we het volgende concluderen:

1. De taal van het domein bepaalt het model.
2. In het model wordt de taal gemeenschappelijk.
3. Het model bepaalt de bounded context.3

Hieraan voegen we deze aanbeveling toe:

4. Een ‘wellbounded’ register valt samen met één bounded context.

Als we ervan uitgaan dat dit aandachtspunt ten opzichte van bestaande registers grosso modo kleinere, meer doelgerichte registers betekent, dan hoort bij deze aanbeveling één belangrijk nadeel:

• Integratiecomplexiteit. Registers moeten worden verbonden middels API’s, events of gegevenssynchronisatie.

Daartegenover staat echter een drietal belangrijke voordelen, die de bijzondere eisen ondersteunen die we op het gebied van kwaliteit en betrouwbaarheid aan overheidsregisters stellen:

• Duidelijkheid. Registers die horen bij één bounded context omvatten ondubbelzinnige terminologie en logica.
• Consistentie. Registers die horen bij één bounded context omvatten logisch consistente set regels en modellen.
• Autonomie. Registers die horen bij één bounded context onafhankelijk van registers in andere bounded contexten werken en (door)ontwikkeld worden.

Controleren van de ‘bounds’

In de praktijk laten de ‘bounds’ van een context zich niet altijd gemakkelijk herkennen en afbakenen. Bovendien kunnen bounded contexten onder invloed van impliciete of uitgesproken belangen worden ‘opgerekt’ of juist verkleind. In algemene zin is moeilijk te zeggen wanneer voor een register de ‘ideale’ bounded context is gevonden. Wel zijn enkele aanwijzingen voor een te ruime of te krappe afbakening te geven. Deze zijn hieronder beschreven.

Indicatoren en symptomen (van sterk naar zwakker) voor een te ruime bounded context:

1. Gebrek aan gemeenschappelijke taal. Er is discussie over concepten en betekenis, betrokkenen hanteren verschillend jargon.
2. Regels en gedrag niet in samenhang te brengen. Het lukt niet tot een samenhangend model te komen.
3. Afwijkende werkwijze(n). Bedrijfsprocessen zijn niet te verenigen.
4. Ontwerp-/owikkeltraject heeft onwenselijke overhead. Het ontwerp-/ontwikkelteam is te groot (geworden).
5. (Vermijdbare) overschrijding van team- en/of organisatiegrenzen. Conflict tussen eigenaren en/of verantwoordelijken.
6. Registeronderdelen vereisen verschillende opslag- en/of integratietechniek. Niet-verenigbare technische vereisten.

Indicatoren en symptomen (van sterk naar zwakker) voor een te krappe bounded context:

1. Registeroverstijgende consistentiewaarborgen vereist. Saga’s zijn nodig om transacties gedistribueerd af te handelen.
2. Model beschrijft domein zonder zelfstandig bestaansrecht. Gegevens in een register hebben ‘los’ geen enkel bestaansrecht en zijn niet te generaliseren voor gebruik in andere domeinen.

Registeranatomie

Hoe de overheid uitvoert

De overheid is een pluriform en complex systeem, dat we binnen de context van Uit betrouwbare bron niet in detail kunnen en willen begrijpen. Tegelijkertijd willen we laten zien hoe een register de administratieve behoeften van overheid ondersteunt. Voor dit doel beschrijven we de werking van de overheid op basis van een abstract en begrensd perspectief: de overheid als producent van gevolgen in uitvoerende processen.

Een gevolg is een betekenisvol resultaat van door overheid uitgevoerd werk. Denk aan een verleende omgevingsvergunning, verkregen nationaliteit of recht op studiefinanciering. Gevolgen ontstaan nooit ‘uit het niets’, maar hebben altijd een oorzaak. Heel vaak was die oorzaak zelf echter ook een - eerder in keten of netwerk geproduceerd - gevolg.

De keten van gevolgen die ontstonden naar aanleiding van eerdere gevolgen en zelf weer aanleiding geven tot nieuwe gevolgen heeft iets weg van een ‘perpetuum mobile’; hoewel op gegeven moment niemand meer precies weet wie het eerste zetje heeft gegeven, werkt het systeem gewoon door. De afbeelding hiernaast, waarin gevolgen zijn weergegeven als een serie kogels in een Newtonpendel illustreert deze metafoor.

Voor een vollediger begrip van hoe een gevolg tot stand komt, moeten we het bijbehorende totstandkomingsproces in meer detail bekijken. Doen we dat, dan kunnen we vier concepten onderscheiden die bij dit proces een rol spelen:

1. Signaal: het proces wordt in beweging gezet door een signaal - een indicatie dat er iets is gebeurd wat aandacht vraagt.
2. Taak: beoordeling van het signaal maakt duidelijk of, en zo ja, welke taken moeten worden uitgevoerd.
3. Gevolg: het uitvoeren van taken leidt tot betekenisvolle resultaten, ofwel gevolgen.
4. Bekendmaking: door gevolgen beïnvloede, daarbij betrokken of daarin geïnteresseerde derden kunnen daarvan na bekendmaking kennisnemen. Zo’n bekendmaking kan voor een volgende producent van gevolgen gelden als signaal, waardoor een keten of netwerk ontstaat.

Fictief voorbeeld: opleggen eenmalige aanschafheffing na aankoop auto

Het team ‘Heffing aanschafbelasting’ (DOW-AB) binnen de ‘Dienst onderhoud weginfrastructuur’ legt aan kopers van auto’s in bepaalde regio’s een eenmalige aanschafheffing op. Het bedrag dat door de koper betaald moet worden, is gebaseerd op het aanschafbelastingmileu-effect van de aangeschafte auto. Een van de ‘grondstoffen’ voor berekening hiervan is het door de dienst ‘Technisch onderhoud’ vastgestelde fysiek milieu-effect. Sam woont in één van de regio’s waarvoor de heffing geldt en heeft een nieuwe auto gekocht. Hij krijgt daarom met de eenmalige aanschafheffing te maken.

1. Signaal: het team ‘Heffing aanschafbelasting’ onvangt bericht van team ‘Technisch onderhoud’ dat voor de auto die Sam gekocht heeft een fysiek milieu-effect van 21 punten is vastgesteld.
2. Taak: het team ‘Heffing aanschafbelasting’ beoordeelt het ontvangen bericht om te bepalen of naar aanleiding daarvan actie nodig is. Omdat Sam in een regio woont waarbinnen de eenmalige heffing wordt opgelegd, is dat het geval. Er ontstaat nu een taak om de hoogte van de eenmalige aanschafheffing vast te stellen.
3. Gevolgen: tijdens het uitvoeren van deze taak onstaan twee gevolgen. Het aanschafbelastingmileueffect is vastgesteld op 33 punten (1), en de hoogte van de eenmalige aanschafheffing is vastgesteld op €2000 (2).
4. Bekendmakingen: deze gevolgen wordt op drie manieren bekendgemaakt. Er wordt een specifiek bericht gepubliceerd over vaststelling van het aanschafbelastingmileu-effect op 33 punten (1) - deze informatie is van belang voor de ‘Nationale Dienst voor Mobiliteitsstromen’, zie ook de volledige casus; het aanschafbelastingmileu-effect wordt samen met het heffingsbedrag gepubliceerd in een referentietabel (2), en Sam krijgt een brief met het verzoek de opgelegde heffing te betalen (3).

Uitvoering applicatief ondersteund

Het hierboven beschreven proces van signaal naar bekendmaking kunnen we spiegelen in een conceptuele architectuur voor IT-systemen die uitvoering binnen de overheid ondersteunen. Deze architectuur omvat een viertal data-artefacten die worden verwerkt door drie applicatiecomponenten (processoren).

Data-artefacten en applicatiecomponenten

• Het applicatieve equivalent van het signaal is een notificatie: een specifiek soort projectie, verspreid via ‘system-to-system’-communicatie en bedoeld om door ontvangers als signaal te worden gebruikt.
• Zo’n notificatie wordt ontvangen door een notificatieprocessor. Deze component beoordeelt op basis van verwerkingsregels en projecties de relevantie van de notificatie voor de eigen context, en creëert bij gebleken relevantie naar aanleiding daarvan één of meerdere commando’s.
• Het commando is een gerichte opdracht met de bedoeling de toestand binnen een bounded context te veranderen en geldt als het applicatieve equivalent van de taak. Een commando hoeft niet door een notificatieprocessor geproduceerd te worden, maar kan bijvoorbeeld ook geproduceerd worden door een procesondersteundende applicatie, bediend door een medewerker.
• Zo’n commando wordt ontvangen door een commandoprocessor. Deze component verwerkt het commando op basis van verwerkingsregels, valideert het tegen bestaande gegevens, en creëert op basis daarvan één of meerdere effecten.
• Het effect is een betekenisvolle gebeurtenis die toestand binnen een bounded context verandert en geldt als het applicatieve equivalent van het gevolg.
• Zo’n effect wordt ontvangen door een effectprocessor. Deze component verwerkt het effect op basis van verwerkingsregels om op de informatiebehoefte van specifieke doelgroepen gerichte projecties en notificaties te creëren.
• De projectie is een volledige, selectieve, of afgeleide weergave van één of meerdere effecten en geldt als het applicatieve equivalent van de bekendmaking. Projecties zijn dus altijd reducties op basis binnen één bounded context bijgehouden gevolgen. Er zijn ook andere soorten weergaves, ontstaan uit uitgebreidere verwerkingen of transformaties, eventueel op basis van gevolgen uit meerdere bounded contexten, die we syntheses noemen en niet als projectie beschouwen. Chronolexografie gaat dieper in op dit verschil.

Relatie met bounded context(en)

Nu we de conceptuele elementen van uitvoeringsondersteunende systemen begrijpen, kunnen we kijken hoe die zich verhouden tot de bounded context waarbinnen gegevens worden verwerkt. Voor commando’s en effecten is dat makkelijk: die conformeren zich altijd aan de taal en het model van de bounded context waarbinnen ze worden gemaakt en verwerkt.

Projecties en notificaties kennen geen ‘vaste’ bounded context. Ze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een projectie gaat, maar ook in de taal van de context die zo’n projectie als signaal verwerkt. Soms zal een producent van gevolgen ervoor kiezen om beide te doen: naast een of meerdere projecties die taal en model van de ‘eigen’ context volgen, worden dan ook projecties gemaakt die aansluiten bij de conventies van bounded contexten van afnemers.

Register = commandoprocessor + effectprocessor

Tot nu toe hebben we het gehad over ‘systemen’ die uitvoeringsprocessen binnen de overheid ondersteunen, zonder het woord ‘register’ te gebruiken. Door het voorgaande over de relatie tussen de beschreven architectuurelementen met bounded contexten en de eerdere uitspraak dat “een ‘wellbounded’ register samenvalt met één bounded context”, kunnen echter een poging doen het register te definiëren. Uitgangspunten daarbij zijn:

1. Ontkoppeling: we willen dat het register alleen afhankelijk is van keuzes gemaakt in de bounded context die het register bedient, en (dus) niet van in andere bounded contexten gemaakte keuzes.
2. Betrouwbaarheid: we willen voor betrouwbaarheid benodigde aspecten zoveel mogelijk binnen de registergrenzen realiseren.

Op basis hiervan komen we tot het volgende oordeel:

• Notificaties zijn veelal afkomstig van buiten bounded context die het register bedient. Zelfs als die door de producerende bounded context volgens de conventies van ‘de onze’ zijn opgemaakt, vallen ze niet binnen de sfeer van invloed en controle van de bounded context waarin het register opereert. De notificatieprocessor is derhalve geen onderdeel van het register.
• Commando’s volgen altijd de taal en het model van de bounded context waarbinnen ze worden gemaakt en verwerkt. De semantische en syntactische eisen aan commando’s worden bepaald door de commandoprocessor, die ook bepaalt welke effecten worden geproduceerd. Die effecten zijn de bron voor de stand van zaken binnen onze bounded context. Gezien het belang hiervan moet de commandoprocessor, inclusief de bijbehorende in- (commando’s) en output (effecten) onderdeel zijn van het register.
• Afnemers binnen en buiten ‘onze’ bounded context die kennis willen nemen van wat binnen onze context is gebeurd, kijken niet rechtstreeks naar effecten, maar naar projecties, of geïnterpreteerde effecten. Controle over de manier waarop die interpretatie plaatsvindt is noodzakelijk om de betrouwbaarheid van het register te kunnen garanderen. Dit betekent dat effectprocessoren, inclusief de bijbehorende in- (effecten) en output (projecties en notificaties) onderdeel zijn van het register.

Conclusie: Een register bestaat uit commandoprocessor(en) en effectprocessor(en).

Aspecten / Capability’s

Verwerkingsverantwoording

De verwerkingsverantwoording wordt geformuleerd vanuit een business-perspectief waarbij geredeneerd wordt vanuit een keten van verwerkingen en gevolgen:

Van ieder gegeven moet vanuit diverse perspectieven toegelicht worden waarom en hoe het tot stand is gekomen. Om dat toe te lichten zijn er 3 sub-aspecten benoemd.

Aanleiding

De aanleiding voor het tot stand komen van een gevolg is het gevolg dat hieraan voorafging en de verwerkingsverantwoordelijke voor het eerste deel van het verwerkingsproces dat zich in de “voorliggende” bounded context bevind ¹.

Dus in de bovenstaande figuur is gevolg1 de aanleiding voor gevolg 2 en de verwerkingsverantwoordelijke voor de aanleiding is verwerkingsverantwoordelijke 1.

Legitimering

De legitimering voor de totstandkoming van een gevolg is wet en/of het beleid en/of de procedures waarop de verwerking heeft plaatsgevonden van het gevolg dat de aanleiding was.

Verklaring

Met de verklaring wordt geduid op welke wijze de wet en/of het beleid en/of de procedures zijn toegepast en wie de verwerkingverantwoordelijke binnen de “eigen” bounded context is ². Een voorbeeld hiervan is de beslissing die een ambtenaar heeft genomen binnen zijn/haar discretionaire bevoegdheid. Het is dan ook van belang te weten welke ambtenaar deze beslissing heeft genomen. Deze ambtenaar wordt in het schema aangeduid met verwerkingsverantwoordelijke 2

Gebeurd op

Met gebeurd op wordt het moment aangeduid waarop het event heeft plaatsgevonden. Dit heeft een sterke relatie met de wijze waarop events worden gedefinieerd. Bijvoorbeeld, naar aanleiding van het verwerken van een commando waarin de geboorteaangifte ter registratie wordt aangeboden aan de Basis Registratie Personen zou je drie events kunnen definieren: - Het kind is geboren. - Er is een akte van geboorte opgesteld. - De akte van geboorte is geregistreerd in de Basis Registratie Personen. Deze drie events hebben ieder hun eigen “gebeurd op” moment.

Registratie

Dit aspect betreft wanneer en door wie iets is vastgelegd. Het systeem houdt bij op welk moment (en eventueel door welke medewerker of instantie) een gegeven is geregistreerd. Dit is van belang voor audit-trails en om vragen te beantwoorden als: “Sinds wanneer weten we dit?” Met registratie-informatie kun je een administratieve tijdlijn opbouwen – los van de inhoudelijke geldigheid.

Geldigheid

Veel gegevens kennen een periode van geldigheid of relevantie. Een adres is vanaf een bepaalde datum geldig, een inschrijving heeft een begin- (en soms eind)datum. Capabele registers leggen expliciet vast vanaf wanneer een gegeven geldig is en tot wanneer (indien van toepassing). Zo ontstaat er een historie in twee dimensies: één dimensie is wanneer iets gold in de werkelijkheid, de andere is wanneer het geregistreerd werd. Dit voorkomt verwarring over tijdreizen in data (bijv. late registratie van een gebeurtenis in het verleden).

Zekerheid

Ieder gegeven draagt informatie over de (on)zekerheid. Is het een bevestigd gegeven, of is er nog twijfel of een lopend onderzoek? In traditionele registers ontbreekt dit vaak, maar in een capabel register kunnen we bijvoorbeeld een “twijfel” annotatie toevoegen als iets betwist wordt. Zo weten afnemers of ze het gegeven voorzichtig moeten behandelen. Deze filosofie – data zien als “claims” in plaats van absolute feiten – is cruciaal. Het betekent dat het systeem beseft: “We denken dat dit waar is, maar het kan in de toekomst gecorrigeerd worden.” Door onzekerheid expliciet te modelleren, voorkom je dat één foutje doorwerkt als harde waarheid in allerlei ketens.

Degistratie

Van gegevens moet kunnen worden vastgelegd dat deze helemaal niet geregistreerd hadden moeten worden. Daarbij moet worden vastgelegd wat het moment is waarop is vastgesteld dat deze gegevens niet vastgelegd hadden moeten worden. Vanaf dat moment dat dit is vastgesteld zijn deze gegevens niet meer beschikbaar voor de business-processen. Deze gegevens niet fysiek verwijderd omdat er vanuit historische perspectief bekend moet blijven dat er ooit een moment was waarop deze gegevens wel gereistreerd zijn geweest. .

Componenten

Commando

Een commando is een opdracht aan het register, aangeboden met de intentie daarin een verandering aan te brengen, die door het register volledig en ineens (of in het geheel niet) verwerkt moet worden.

Verwerking van een [=commando=] kan leiden tot 0, 1 of meerdere ‘effecten’

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style cm1 stroke:#2962FF style cm2 stroke:#2962FF

Transactionele verwerking

Een commando moet door het register “volledig en ineens (of in het geheel niet) verwerkt worden”. Dit betekent dat de hele inhoud van het commando in één transactie verwerkt moet worden.

Taal

• Omdat een commando geldt als opdracht, wordt bij de naam daarvan de gebiedende wijs gebruikt (registreer..., vernietig...).
• De naam van het commmand beschrijft altijd iets wat gebeurt door verwerking in het register.
  • Als een commando gaat over iets met zelfstandig bestaansrecht, dus iets wat ook zonder registratie bestaat, geeft de naam van het commando uitdrukking aan een registratieve intentie.
    • Bijvoorbeeld: registreer uitgifte rijbewijs, en niet geef rijbewijs uit. De daadwerkelijke uitgifte van het rijbewijs vond immers plaats aan de balie of per post, niet binnen het register. Het rijbewijs zou dus ook zonder registratie zijn uitgegeven.
  • Als een commando gaat over iets dat zonder registratie niet bestaat, geeft de naam van dat commando uitdrukking aan een producerende of wijzigende intentie.
    • Bijvoorbeeld: creëer zaak, en niet registreer zaakcreatie. De daadwerkelijke zaakcreatie vindt immers binnen het register plaats. En zonder die registratie was de zaak niet gecreëerd.
• Concepten die de naam en inhoud van commandos beschrijven zijn onderdeel van de gemeenschappelijke taal van de bounded context die het register ondersteunt. De bedoeling van een commando wordt daarom in deze taal gedocumenteerd.
  • Hoewel een wijziging in het WOZ-objectenregister veroorzaakt kan worden door een verandering in de Basisregistratie Kadaster, gaat een commando binnen de bouded context van WOZ-objectenbeheer dus niet over eigenaren van kadastrale onroerende zaken, maar over belanghebbenden bij WOZ-objecten.

Effect

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style eff stroke:#2962FF

Projectie

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style prj stroke:#2962FF

Notificatie

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style no1 stroke:#2962FF style no2 stroke:#2962FF

Illustratieve casus: Verwerking auto-aankoop

De fictieve casus hieronder beschrijft een aantal binnen ‘Uit betrouwbare bron’ relevante aspecten rondom registratie en levering van informatie informatieflow binnen de overheid, te weten:

• Hoe één aanleiding (de koop van een auto) een serie overheidshandelingen in gang kan zetten;
• hoe overheidsorganisaties voor hun handelen (soms) afhankelijk zijn van resultaten van andere overheidsorganisaties, en
• hoe één concept (milieu-effect) door verschillende organisaties en personen binnen de overheid verschillend begrepen en berekend wordt.

Aanleiding

Sam koopt een nieuwe auto met de volgende kenmerken:

Zoals verplicht verzekert Sam direct na aankoop de nieuwe auto. De verzekeraar meldt de aankoop van de auto aan de Dienst onderhoud weginfrastructuur (DOW).

Behandeling door DOW-team ‘Technisch onderhoud’

Binnen de DOW belandt de melding van Sam eerst bij het team ‘Technisch onderhoud’ (DOW-TO). Deze afdeling heeft als taak het prioriteren van onderhoud aan wegen en parkeerplaatsen. Om deze taak uit te kunnen voeren bepaalt men voor iedere in de regio aangeschafte auto het mileu-effect.

Binnen het DOW-team ‘Heffing aanschafbelasting’ definieert men het concept milieu-effect als volgt:

Het milieu-effect is een maat voor de fysieke belasting die een voertuig op de weginfrastructuur uitoefent, berekend als de som van (a) een massacomponent gebaseerd op voertuiggewicht en (b) een ruimtecomponent gebaseerd op voertuigoppervlak.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen het Team ‘Technisch onderhoud’ verder het fysiek milieu-effect.

Voor de auto van Sam maakt het team ‘Technisch onderhoud’ de volgende berekening:

Gevolg: de wijk van Sam komt (een heel klein stapje) hoger op de wegonderhoudsplanning.

Behandeling door DOW-team ‘Heffing aanschafbelasting’

Het team ‘Heffing aanschafbelasting’ (DOW-AB) valt eveneens binnen de Dienst onderhoud weginfrastructuur. Dit team heeft als taak het opleggen van een eenmalige aanschafheffing aan autokopers die binnen bepaalde regio’s wonen. Deze heffing is bedoeld om het onderhoud van wegen te bekostigen en tegelijkertijd het aanschaffen van milieubelastende auto’s te ontmoedigen. Om deze taak uit te kunnen voeren bepaalt men voor iedere in de regio aangeschafte auto het mileu-effect.

Binnen het DOW-team ‘Heffing aanschafbelasting’ definieert men het concept milieu-effect als volgt:

Het milieu-effect is een samengestelde maat die de totale milieubelasting van een motorvoertuig weergeeft, berekend als de som van (a) het milieu-effect zoals vastgesteld door DOW-TO en (b) een uitstootcomponent gebaseerd op door de fabrikant opgegeven CO₂-uitstoot per kilometer.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen het team ‘Heffing aanschafbelasting’ verder het aanschafbelastingmilieu-effect.

Sam woont in een regio waarbinnen de aanschafheffing wordt opgelegd. Voor de auto van Sam maakt het team ‘Heffing aanschafbelasting’ daarom de volgende berekening:

De te betalen aanschafheffing wordt aan de hand van de volgende tabel bepaald:

Gevolg: Sam betaalt een eenmalige aanschafheffing van €2000.

Behandeling door Nationale Dienst voor Mobiliteitsstromen

De Nationale dienst voor mobiliteitsstromen (NDM) heeft het verstrekken van spitsdoorrijpassen als taak. Met deze passen kunnen via speciale rijbanen tijdens spitsuren files worden vermeden. Spitsdoorrijpassen moeten het rijden van milieuvriendelijke auto’s en het delen van voertuigen binnen een huishouden bevorderen. Huishoudens die één milieuvriendelijke auto delen, krijgen een per maand het maximale aantal passen. Huishoudens waarin iedere volwassene een eigen, zeer vervuilende auto bezit krijgen daarentegen geen spitsdoorrijpassen.

Binnen de Nationale dienst voor mobiliteitsstromen definieert men het concept milieu-effect als volgt:

Het mileu-effect is een maat voor de potentiële milieu-impact van het gebruik van een auto door een huishouden, berekend door het fysiek milieu-effect (zoals bepaald door DOW-AB) van alle auto’s in een huishouden op te tellen, en het resultaat te delen door het aantal volwassen personen in het huishouden.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen de Nationale dienst voor mobiliteitsstromen verder het huishoudelijk milieu-effect.

Sam heeft een vriendin. Samen vormen zij een huishouden, dat naast de nieuwe auto van Sam geen voertuigen bezit. Voor de auto van Sam maakt Nationale dienst voor mobiliteitsstromen daarom de volgende berekening:

Het aantal te verstrekken spitspassen wordt aan de hand van de volgende tabel bepaald:

Gevolg: Sam’s huishouden heeft per maand recht op 3 spitsdoorrijpassen.