Domeinregistraties; uitgangspunten, rollen en procesafspraken

Auteur: Jan Verbeek | Status: Review

Inleiding

Voor de realisatie van een domeinregistratie (gedeelde dataset) zijn er een aantal vaste uitgangspunten, verschillende rollen en een aantal procesafspraken gemaakt. Deze worden in dit document besproken.

De domeinregistraties zijn noodzakelijk voor domein specifieke applicaties (Werk, Inkomen, Inburgering) aanvullend op de al gerealiseerde generieke registraties (OpenZaak, OpenKlant, Objectenregister etc.)

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 gedeelde dataset”. Hierover 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. 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.

Eén datamodel voor alle gemeenten De domeinregistratie wordt ingericht voor het delen van domein specifieke gegevens tussen een groot aantal werkprocessen, samenhang over het geheel, en de relatie met andere domeinregistraties en de generieke registraties is essentieel (informatiemodel) Gemeenten zijn hier integraal voor verantwoordelijk. 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 afhandelcomponenten, het is belangrijk dat er niet tegelijker tijd 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 aansluiten op reeds bestaande voorzieningen zoals autorisatie, notificaties, logging, beheer interface, archivering en de mogelijkheden tot het verhuizen van een registartie (url’s), de generieke CommonGround infrastructuur.

· Het kunnen leveren van informatie ten behoeve van BI en rapportages

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

· Alle domeinregistraties dezelfde generieke functionaliteit bieden.

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.

Handeling gedreven API voor het opslaan van informatie Het ontwikkelen van handeling gedreven API waarmee ook informatie wordt opgeslagen in het domeinregister is toegestaan mits dit generieke functionaliteit betreft en deze service onderdeel gaat uitmaken van het domeinregister, Het implementeren van Domeinregistraties gebeurd tijdens/parallel aan het ontwikkelen van concrete usecases. 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.

API voor specifieke bevragingen voor afhandel componenten Bij de implementatie van een specifiek proces is het tempo waarmee afhandelcomponent specifieke services gerealiseerd kunnen worden essentieel Snel en eenduidig proces over hoe extensies vorm krijgen die proces specifiek zijn voor een beperkte groep gemeenten.

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,

· algemene 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 product owner (domein)registraties aan. Deze product owner gaat over het geheel aan (domein)registraties. Naast deze product owner (domein)registraties stelt de kerngroep PO een kleine werkgroep Koplopers-CG medewerkers aan voor het ontwikkelen en beheren van de (domein)registraties zodat er voor iedere (domein)registraties een eigenaar is (dit kan ook de product owner (domein)registraties zijn)

De product owner (domein)registraties en de werkgroep 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 responsetijden 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