Registraties: uitgangspunten, rollen en procesafspraken

Auteur: Jan Verbeek | Status: Review

Inleiding

Voor de realisatie van een domeinregistratie (CommonGround dataset) zijn er een aantal vaste uitgangspunten, verschillende rollen en een aantal procesafspraken gemaakt. Deze worden in dit document besproken en zijn een aanvulling op het voorgaande document: CommonGround dataset of Domeinregister.

De domeinregistraties zijn noodzakelijk voor domein specifieke applicaties (Werk, Inkomen, Inburgering) aanvullend op de al gerealiseerde generieke registraties (OpenZaak, OpenKlant, Objectenregister etc.) De hier gehanteerde uitgangspunten zijn zowel van toepassing voor domeinregistraties als voor generieke registraties

Het implementeren van een domeinregistratie staat veelal onder tijdsdruk bij de realisatie van een domein specifieke applicatie waardoor al snel wordt teruggevallen op het objectenregister omdat dit een bestaande component is in het Common Ground landschap. In dit procesvoorstel is een balans aangebracht tussen snelheid en inzet voor meerdere specifieke processen.

Domein registratie uitgangspunten

Er is sprake van een domein registratie als wordt voldaan aan de uitgangspunten uit de notitie “de CommonGround dataset”. Over de CommonGround dataset zijn al afspraken gemaakt en opgenomen in de wiki. De aanleiding voor het schrijven van die notitie is gelegen in het gebruik van het objecten register (voor een functie waar het niet voor is bedoeld) in plaats van een domein specifieke registratie. Dit leidt al snel tot veel technical debt en maakt het doorvoeren van wijzigingen tijdrovend en kostbaar. Daarnaast blijft de semantiek van een datamodel in het objectenregister onduidelijk en daarmee de aansluiting op het GGM en de landelijke standaarden die gebruikt worden in de verschillende domeinen.

Domeinregistraties zijn bij alle gemeenten gelijk ingericht. Domeinregistraties zijn implementaties (van delen) van het informatie model ‘Gemeentelijk Gegevens Model’ (GGM) en zijn voor alle gemeenten gelijk ingericht. Het domeinregister heeft geen leverancier specifieke api's / services. Alle api's / services leveren generiek functionaliteit. Binnen de domeinregistratie wordt de mogelijkheid geboden om gemeente specifieke extensies vast te leggen. Niet iedere gemeente zal van alle entiteiten/attributen van het domeinregister gebruik maken. Tevens worden in deze domeinregistratie alle gegevens vastgelegd die langdurig beschikbaar gehouden moeten worden voor gebruik, voorbijgaand aan de reguliere levensduur van een applicatie.

Eén datamodel voor alle gemeenten De domeinregistratie wordt ingericht voor het delen van domein specifieke gegevens tussen werkprocessen, en zorgt zo voor de samenhang van het geheel. De relatie met andere domeinregistraties en de generieke registraties is essentieel en komt tot uitdrukking in het GGM. De gemeenten zijn hier integraal verantwoordelijk voor. Het informatie model dat ten grondslag ligt aan de domeinregistratie wordt gevormd door een afgebakend onderdeel van het GGM. Aanvullende afspraken ten aanzien van het beheer en onderhoud van het GGM worden gemaakt. Door het GGM op te delen in samenhangende domeinregistraties blijven wijzigen beperkt tot de onderhavige domeinen en het geheel beheersbaar.

Er is maar één domeinregistratie per domein (groep samenhangende processen/data) met één eigenaar. Aanpassingen in een domeinregistratie kunnen ingrijpende gevolgen hebben voor afhandel componenten, het is belangrijk dat er niet tegelijkertijd aan verschillende registraties wordt gewerkt voor dezelfde gegevens. Wellicht dat een bepaald deel alleen in gemeente x in gebruik is, toch is het geheel is in één component ondergebracht en bij alle gemeenten volledig uitgerold. Dit om te voorkomen dat er verschillen ontstaan. Voor het beheer van de informatiemodellen die ten grondslag liggen aan de domein registraties wordt aangesloten bij het beheer proc es van het GGM

Eénduidige wijze van bevraging en functionaliteit Alle domeinregistraties zijn op dezelfde manier ingericht, kennen dezelfde functionaliteit en passen daardoor naadloos in het CommonGround IT-Landschap. Dit betekent dat:

· Iedere domeinregistratie wordt ontsloten via CRUD-API’s

· Een domein registratie uitgebreid kan worden met functionele api’s

· De domeinregistratie en de bijbehorende API’s als één geheel beheerd worden

· De domeinregistraties op volledig identieke wijze aansluiten op reeds bestaande voorzieningen zoals autorisatie, notificaties, logging, beheer interface, archivering en de mogelijkheden tot het verhuizen van een registratie (url’s), de generieke CommonGround infrastructuur.

· De doeminregistratie zelf is bedoeld voor operationele datset en niet bedoeld voor het uitvoeren van BI-analyses of rapportages maar moet daarvoor wel de data kunnen aanleveren naar een voorziening daarvoor is ingericht.

· Een domeinregistratie kan alleen bevraagd worden via de meegeleverde api’s (CRUD en functioneel) en kan niet rechtstreeks bevraagd worden (bijvoorbeeld met GraphQL) zodat autorisatie en ontsluiting op api niveau en logging (doelbinding) op api niveau mogelijk blijft. Daarnaast geeft dat meer mogelijkheden om backwards compatibility te implementeren doordat het fysieke datamodel niet wordt blootgesteld aan de buitenwereld.

· Alle domeinregistraties dezelfde generieke functionaliteit bieden.

Indien een taakapplicatie wordt vervangen door een andere taakapplicatie met vergelijkbare functionaliteit (zelfde domein) moet deze kunnen aansluiten op de domeinregistratie zonder dat deze domeinregistratie vervangen of gemigreerd hoeft te worden.

Een domeinregistratie bestaat niet alleen uit de implementatie (van een deel) van het informatiemodel GGM maar ook uit de bijbehorende services (API’s), de beheer interface en alle generieke services die benodigd zijn voor de inpassing in het CommonGround IT-landschap en is daarmee een component die voor een specifiek domein laag 1 en 2 invult binnen de CommonGround architectuur.

Functionele api’s API voor het ophalen of opslaan van informatie

Onder de term functionele API's scharen we zowel Convenience API's als handeling gedreven api's. Het ontwikkelen van API's waarmee op een eenvoudige wijze informatie kan worden opgehaald of opgeslagen in het domeinregister is toegestaan mits dit generieke functionaliteit betreft en deze service onderdeel gaat uitmaken van het domeinregister. Dergelijke API's verbergen de complexiteit (structuur (met één api call een contactmoment vastleggen) of business rules (met één api call het inkomen of het vermogen van een burger ophalen)) van een domeinregister voor de buiten wereld en maken het gebruik van het domeinregister makkelijker en de vastlegging en het gebruik van de data consistenter.

Het implementeren van Domeinregistraties gebeurd tijdens/parallel aan het ontwikkelen van concrete use cases. Bij de implementatie van een specifiek proces is het tempo waarmee afhandelcomponent specifieke services gerealiseerd kunnen worden essentieel. Dit proces loopt vooruit op uiteindelijke standaardisatie en interacteert met het GGM, Gemma. De koplopers Common Ground voeden het standaardisatie proces van VNG, GGM. Door de implementatie wordt op het standaardisatie proces vooruit gelopen en de werking in de praktijk getoetst. Vooruitlopend op standaardisatie heten onderdelen en / of componenten Experimenteel, Beta, Release Candidate en Standaard.

Rollen

De verantwoordelijkheid voor domeinregistraties is gesplitste in een aantal onderdelen:

De koplopers CommonGround zijn opdrachtgever en daarmee bepalend voor de solution architectuur en services. Hiertoe richten gemeenten een gezamenlijke governance in met één eigenaar als eindverantwoordelijke voor de overall aspecten en inclusief de governance voor domeinregistraties.

De koplopers CommonGround bepalen de algemene inrichting met betrekking tot;

· de solution architectuur,

· het informatiemodel,

· api services,

· scheiding en samenhang tussen de domeinregistraties,

· extensies voor een beperkte (groep) gemeenten.

Voor iedere domeinregistratie is één leverancier verantwoordelijk voor de kwaliteit van de generieke basis en de functionaliteit van de componenten in de gegevenslaag. Uitgezonderd hiervan zijn services die op verzoek van een leverancier van een afhandelcomponent zijn ontwikkeld of aan het domein register zijn toegevoegd. De generieke basis bestaat uit de inrichting van de database (datamodel, indexes) de aansluiting op de generieke CommonGround infrastructuur (Crud api’s, authorisatie notificatie etc.) en de functionaliteit van de componenten in de gegevenslaag.

De leverancier van een afhandelcomponent is verantwoordelijk voor de taak specifieke services Indien een leverancier van een afhandelcomponent behoefte heeft aan aanvullende services kan dat op twee manieren: Proces en verantwoordelijkheden bij een verzoek tot wijziging 1a) De leverancier van een afhandel component dient een pullrequest in. Dit pullrequest bevat de volledig benodigde code voor de functionele (taak specifieke) API.

1b) De leverancier van een afhandel component dient een issue in voor een extensie op het domeinregister en de wensen ten aanzien van de werking van de functionele api. Deze issue bevat een functionele beschrijving van de gewenste werking van deze API. De implementatie van de issue wordt uitgevoerd door de leverancier van de generieke basis in opdracht van de kerngroep PO.

2) De architecten voor het domeinregister en het overall model checken het pullrequest/issue op conflicten, onterechte dubbeling, en plaatsing in het totale informatiemodel over alle registraties. 3) De leverancier van de generiek basis doet ook de kwaliteitscontrole voor opensource package en checkt op werking van de sql in relatie tot de andere “API tbv afhandelcomponenten” in opdracht van de eigenaar. Het doel van de kwaliteitscontrole is het kunnen blijven voldoen aan de SLA op het domein register component. Een functionele API mag bijvoorbeeld geen data locken en geen overbodige overhead creëren (bijvoorbeeld outer joins ipv inner joins geen gebruik maken van een index, paginering moet ondersteunt worden e.d.)

4) Een wijziging van het informatiemodel dat geïmplementeerd is in het onderhavige domeinregister wordt altijd uitgevoerd door de leverancier van de generieke basis. Indien deze aanpassing leidt tot een aanpassing van functionele API’s wordt de ontwikkelaar van de functionele API gevraagd deze aanpassing door te voeren.

Organisatieinrichting

De kerngroep PO stelt een overall product owner voor het geheel aan registraties en indien van toepassing een product owner per domeinregistratie. Naast deze product owner registraties stelt de kerngroep PO een kleine werkgroep Koplopers-CG medewerkers aan voor het ontwikkelen en beheren van een domeinregistraties zodat er voor iedere domeinregistratie een eigenaar is (dit kan ook de product owner registraties zijn)

De product owner registraties en de werkgroep van een domeinregistratie (met eventueel een eigen Product owner) zijn verantwoordelijk voor:

· Het opstellen en onderhouden van een programma van eisen waaraan een domeinregistratie moet voldoen (inbedding in het CommonGround domein). De eisen ten aanzien van response- tijden en resource gebruik maken hier expliciet deel van uit.

· De solution architectuur en gewenste functionaliteit voor het gegevensdeel van het platform.

· Het bewaken van de samenhang van de (domein)registraties en de aansluiting bij het GGM

· De inrichting en afbakening van (domein)registraties

· Bewaken van de kwaliteit de (domein)registraties

· Het doen van voorstellen voor aanpassing en uitbreiding van de (domein)registraties aan de kerngroep PO

· De eigenaar van een (domein)registratie zorgt voor inzicht in de werkvoorraad en de realisatie snelheid voor de G1 en de kerngroep PO.

Gemeenten brengen via de G1 programma’s wensen in ten aanzien van de functionaliteit en (domein-) registraties bij de product owner (domein)registraties. De product owner (domein)registraties werkt in samenspraak met de werkgroep een voorstel uit en legt dit voor aan de kerngroep PO. De kerngroep PO besluit over de voorstellen of adviseert aan de G4 CIO zodra de governance is ingericht. En natuurlijk, de G4 gemeenten volgen de besluiten van de kerngroep PO en of het G4 CIO.

De algemene basis en de set aan (domein)registraties worden uiteindelijk beheert in één community maar in eerste instantie geleverd door één leverancier.