Globaal programma van eisen voor pakketsoftware

Inleiding[bewerken]

De transitie naar een architectuur volgens de thema-architectuur Common Ground wordt door steeds meer gemeenten voortvarend opgepakt. Het is daarbij lastig gebleken de juiste vragen te stellen waarop leveranciers passend kunnen reageren. Een van de redenen hiervoor is dat de thema-architectuur Common Ground een eindsituatie beschrijft die niet van vandaag op morgen is gerealiseerd maar in veel gevallen een transitie gedurende meerdere jaren zal betekenen.

Een handreiking[bewerken]

Deze pagina biedt houvast en is een handreiking voor gemeenten bij het maken van keuzes tijdens de transitie naar de thema-architectuur Common Ground. Hiervoor is een “adoptiecurve” opgesteld met ambitieniveaus die stapsgewijs steeds verder invulling geven aan de thema-architectuur Common Ground. Bij ieder ambitieniveau zijn eisen en wensen geformuleerd.

Idealiter maken alle partijen gebruik van deze curve, ambitieniveaus en bijbehorende eisen en wensen. Iedere gemeente verkeert echter in een eigen specifieke situatie met een eigen bestuurlijke agenda, doelen en strategieën, eigen (on)mogelijkheden (financiën, kennis, kunde, etc.) en een eigen uitgangssituatie (applicatielandschap). Deze zaken zullen voor iedere gemeente mede bepalen hoe de adoptiecurve met ambitieniveaus eruit ziet en wanneer iets een eis of een wens is.

Het voorstel in dit document kan uiteraard gevolgd worden, het is wel verstandig er situationeel naar te kijken en passend te maken waar nodig. Afwijkingen zijn dus toegestaan, zowel op de onderkende ambitieniveaus als op de eisen en wensen die gemeente/afdeling specifiek moeten worden gemaakt. De transitie zal per gemeente / domein / applicatie volgens verschillende ambities en snelheden verlopen. Dat vraagt veel afstemming en aandacht om de samenhang te bewaken. Zoek daarbij de samenwerking met gemeenten met een vergelijkbaar uitgangssituatie en deel ervaringen en best practices zodat anderen hiervan kunnen profiteren en de thema-architectuur Common Ground snel en effectief kan worden gerealiseerd.

De gereedschappen in dit document kunnen op verschillende manieren worden toegepast. Zo kan met de adoptiecurve en de kenmerken van de ambitieniveaus een bij een gegeven vraagstuk passend ambitieniveau bepaald worden. De eisen en wensen kunnen vervolgens worden afgeleid. Waar gewenst, kunnen de adoptiecurve en ambitieniveaus gebruikt worden als inspiratie om vertaald te worden in een gemeente specifieke curve met bijpassende niveaus. De eisen en wensen per functiegebied kunnen vervolgens worden ingericht naar de eigen niveaus. Marktpartijen kunnen de informatie in dit document gebruiken bij het opstellen van (strategische) productontwikkelingsplannen.

De adoptiecurve en ambitieniveaus op de pagina zijn uitgewerkt met het oog op de aanschaf van softwarepakketten. Daarbij zal de leverancier van een pakket veelal zelf bepalen hoe de interne structuur van zijn product (software architectuur) is ingevuld. In het kader van de principes van de thema-architectuur Common Ground zijn wél eisen en wensen geformuleerd die impact kunnen hebben op de software architectuur. Deze worden in dit document als wens voorgesteld om toch sturing te geven aan de gewenste richting. Daarbij moet gedacht worden aan zaken die te maken hebben met “COMPONENTGEBASEERD – We werken met ontkoppelde componenten”, “STANDAARD – We standaardiseren maximaal” en “EENMALIGE VASTLEGGING – We leggen gegevens eenmalig vast en vragen op bij de bron”.

Hoewel dit document primair voor de aanschaf van pakketsoftware is bedoeld kan de inhoud met enige oplettendheid ook gebruikt worden in situaties zoals zelf ontwikkelen of configureren.

Belangrijk om er bij te betrekken[bewerken]

Een inkoopvraagstuk kent een veelheid van onderwerpen die in het bestek aan de orde komen. De eisen en wensen in dit document zijn daarvan slechts een onderdeel en dienen naast de business specifieke eisen en wensen gebruikt te worden als ook naast die van overkoepelende onderwerpen zoals:

  • BIO - Baseline Informatiebeveiliging Overheid (informatiebeveiligingsdienst.nl)
  • AVG - Algemene Verordening Gegevensbescherming (autoriteitpersoonsgegevens.nl)
  • eID - elektronische identiteit (digitaleoverheid.nl)
  • eHerkenning (eherkenning.nl)
  • Handreiking betrouwbaarheidsniveaus (forumstandaardisatie.nl)
  • Nederlandse API Strategie (geostandaarden.nl)
  • API Beveiligingsrichtlijnen (gemmaonline.nl)
  • Nadere uitwerking op onderdelen van de thema-architectuur Common Ground(gemmaonline.nl)
  • GEMMA Referentiearchitectuur (gemmaonline.nl)
  • GIBIT - Gemeentelijke Inkoopvoorwaarden bij IT (vngrealisatie.nl)

Achtergrond[bewerken]

Common Ground[bewerken]

De informatiekundige visie Common Ground vindt haar oorsprong in een overheid breed initiatief met betrekking tot een gegevenslandschap. Het doel is een solide basis van voorzieningen, afspraken, standaarden en registraties te laten realiseren. Hierbij worden standaarden verplicht, Open data zoveel mogelijk gebruikt en de vernieuwing & modernisering van de Basisinfrastructuur (GDI) gerealiseerd. Als onderdeel van de solide basis van voorzieningen en afspraken is een gegevenslandschap ontwikkeld. Wanneer we spreken over een gegevenslandschap, dan hebben we het over alle (gedigitaliseerde) gegevens en informatievoorziening die we als overheid voor het primaire proces nodig hebben.

De modernisering van de dienstverlening vereist het breder deelbaar maken van gegevens. Met de totstandkoming van het stelsel van basisregistraties is een eerste belangrijke stap gezet in de realisatie van het gegevenslandschap: overheden hebben afspraken gemaakt over eenmalige vastlegging van gegevens waardoor er een meervoudig te gebruiken gegevensbron is ontstaan. De volgende stap is om de gegevens (zowel gemeentelijk als bij ketenpartners) uit de spreekwoordelijke silo’s te bevrijden. Daarbij heeft elk domein zijn eigen wetten, eigen cultuur, eigen techniek, eigen dynamiek en zijn eigen doelgroepen. Juist die specifieke context is voor het gebruik van gegevens essentieel. Het idee dat er één generiek en uniform gegevenslandschap voor gebruik binnen de overheid gemaakt kan worden, is dan ook een illusie. De uitdaging is om tot een samenhangend gegevenslandschap te komen.

Thema-architectuur Common Ground[bewerken]

VNG Realisatie heeft de informatiekundige visie Common Ground uitgewerkt in de thema-architectuur Common Ground.

De thema-architectuur Common Ground is een informatiearchitectuur die een gelaagd model beschrijft voor het scheiden van processen en gegevens en het ‘bij de bron’ kunnen bevragen van gegevens. Data wordt ontsloten via API’s, specifieke software speciaal bedoeld om computerprogramma’s met elkaar te laten communiceren. Hiervoor worden gestandaardiseerde informatiemodellen met gemeenschappelijke gegevensdefinities toegepast waardoor gegevens consistent worden gebruikt en gedeeld. Door het ontkoppelen van processen en gegevens wordt het mogelijk om autorisatie en logging van het gebruik van gegevens in de architectuur te verankeren. Hiermee worden recht op toegang en vastleggen van gegevens uniform bestuurd en wordt consistent vastgelegd welke data met wie is uitgewisseld.

Eén van de doelen van de thema-architectuur Common Ground is de flexibiliteit en wendbaarheid van de informatievoorziening te vergroten. Dit wordt bereikt door in de informatievoorziening onderscheid te maken tussen dienstafnemers en dienstaanbieders die via een integratiemechanisme met elkaar communiceren. In de architectuur zijn hiervoor 5-lagen gedefinieerd, ieder met specifieke functiegebieden[1]. Het Programma van Eisen is gebaseerd op deze 5 lagen en de functiegebieden daarbinnen.

Architectuurlagen en Functiegebieden in het GEMMA Gegevenslandschap

De transitie[bewerken]

De transitie wordt vanuit drie behoeften benaderd: Gefaseerd, Passend en Gericht. De verandering is ingrijpend en zal daarom niet in één keer gerealiseerd worden. Er moet daarom een serie ambities worden geformuleerd waarin passende gegevenslandschap onderdelen worden geadresseerd en daarbij gericht invulling wordt gegeven aan bijpassende specificaties.

Gefaseerd – adoptiecurve[bewerken]

In de huidige gemeentelijke ICT-infrastructuur is data vaak als het ware in ‘silo’s’ per beleidsdomein opgesloten. Gemeenten ontsluiten die gegevens via koppelingen, die complex en kwetsbaar kunnen zijn. De silo’s kopiëren veelal gegevens naar de eigen omgeving, terwijl in de informatiekundige visie van Common Ground wordt uitgegaan van gegevens eenmalig vastleggen en meervoudig gebruiken.

Dit is echter een grote verandering die niet van vandaag op morgen gerealiseerd is maar in praktische, weloverwogen stappen zal verlopen. Hiervoor heeft VNG Realisatie een strategie uitgewerkt (een “adoptiecurve”) waarin op basis van ambitieniveaus stapsgewijs invulling wordt geven aan de realisatie van de thema-architectuur Common Ground.

Let op! De adoptiecurve is een voorstel gebaseerd op de kennis en ervaring van VNG Realisatie. Het kan uiteraard overgenomen worden maar dient ook ter inspiratie voor gemeenten/marktpartijen om een eigen strategie uit te werken.

De adoptiecurve is opgezet langs twee kernelementen van de thema-architectuur Common Ground te weten:

  • Standaardisatie van gegevensuitwisseling via informatiemodellen en API’s;
  • Modulariteit door ontkoppeling van gegevens en processen en door ontkoppeling van componenten.

Deze kernelementen hebben de grootste bijdrage aan het van elkaar scheiden van de dienstenaanbieder en -afnemer. Door het scheiden van gegevens en processen en deze weer met elkaar te verbinden via standaarden wordt het mogelijk gegevens te hergebruiken en deze bij de bron te beheren en bevragen.

De Adoptiecurve

Passend – ambitieniveaus[bewerken]

De bij de adoptiecurve gedefinieerde ambitieniveaus hebben ieder een eigen doel en zijn bedacht om stapsgewijs op elkaar voort te borduren om de thema-architectuur Common Ground te implementeren. De ambitieniveaus 1 t/m 5 worden in de hierna volgende paragrafen kort toegelicht. Niveau 0 (géén ambitie) is een silo applicatie die gebruikt maakt van STUF en waarin geen duidelijk scheiding van de architectuurlagen is te herkennen. Niveau 0 wordt in dit document niet verder behandeld (zie document "Aanleiding vernieuwing gemeentelijke informatievoorziening" op GEMMA Online voor meer toelichting op de huidige situatie).

Niveau 1 – Ontsluiting silo data met bevragings-API’s[bewerken]

Het uitgangspunt bij niveau 1 is een silo applicatie die gebruikt maakt van STUF en als één geheel de vijf lagen bestrijkt. In de architectuur zijn de vijf-lagen niet feitelijk te identificeren. Het systeem werkt met een eigen informatiemodel en de gegevens worden met behulp van specifieke silo-functionaliteit ontsloten.

Globaal Programma van Eisen - image5.png

Het doel bij niveau 1 is om de gegevens in de (database van de) silo te ontsluiten. De dienstenaanbieder (vb. de gemeente) stelt de gegevens in het systeem door middel van API’s beschikbaar aan derden. De API’s worden gepubliceerd en zijn algemeen vindbaar. Daar waar mogelijk zijn de geleverde gegevens conform een standaard semantisch datamodel en gestandaard-iseerde definitie voor gegevensuitwisseling. Conform AVG worden naar behoefte de gegevens pseudonimiseerd en/of geanonimiseerd.

Voor het (extern) beschikbaar stellen van de API’s wordt, indien beschikbaar en gewenst, gebruik gemaakt van een landelijke (vb. NLX) dan wel interne integratiefaciliteit (vb. ESB). Waar nodig verloopt het gebruik over een beveiligde verbinding. De toegang tot de API’s en gegevens wordt beheerd en iedere aanroep van een API wordt gelogd. Dit gebeurd zowel bij de Dienstenafnemer (in de aanroep) als bij de Dienstenleverancier (in de API).

Het voordeel van applicaties op niveau 1 is dat de gegevens opgesloten in de silo-applicatie door andere toepassingen real-time geraadpleegd en gebruikt kunnen worden.

Niveau 2 – Mutatie API’s[bewerken]

Globaal Programma van Eisen - image6.png

De uitgangsituatie bij niveau 2 is een applicatie die voldoet aan de niveau 1 specificaties. Het systeem is nog altijd een silo en bestrijkt als één geheel de vijf lagen. Het werkt doorgaans nog met een niet-standaard vastgesteld informatiemodel en gegevens zijn met behulp van bevragings-API’s te ontsluiten.

De ambitie van niveau 2 is om nu naast de bevragings-API’s het ook mogelijk te maken om gegevens van derden met API’s te ontvangen én te bewerken in de ‘silo’ database. Waar standaard domein-/ sectorspecifieke informatiemodellen beschikbaar zijn, werken de API’s daarmee. Als het systeem intern nog met een niet-standaard informatiemodel werkt is er logica om de ontvangen gegevens te transformeren. Gebruik van de API’s waarborgen de consistentie in de database(s).

Voor niveau 2 zijn de inspanningen vooral in de lagen Diensten en Gegevensbronnen.

De voordelen van applicaties op niveau 2 t.o.v. niveau 1 is dat applicaties/processen van buiten de silo gegevens kunnen aanleveren om opgeslagen te worden. Hiermee is een belangrijke stap gezet richting ontkoppeling van proces en gegevens.

Niveau 3 – Ontkoppeling proces en gegevens[bewerken]

De uitgangssituatie bij niveau 3 is een applicatie dat voldoet aan de niveau 2 specificaties. De gegevens in de silo zijn zowel voor bevragingen als mutaties ontsloten middels API’s. Het systeem werkt vaak nog met een eigen informatiemodel.

Globaal Programma van Eisen - image7.png

Een niveau 3 applicatie kenmerkt zich doordat er een ontkoppeling is tussen de gegevenslaag en de proceslaag. Deze worden door dezelfde leverancier geleverd, werken nog als één geheel maar kunnen apart uitgerold worden.

Voor de ontkoppeling wordt gebruik gemaakt van dezelfde API’s die voor derden beschikbaar zijn gesteld. Hierdoor is de verwerking van gegevens in de database gegarandeerd hetzelfde, ongeacht de toepassing die de gegevens heeft aangeboden.

Door de ontkoppeling is speciaal aandacht nodig voor autorisatie en audit logging. Dit gebeurd zowel bij de Dienstenafnemer (in de aanroep) als bij de Dienstenleverancier (in de API). Deze moeten als geheel sluitend zijn. Bijvoorbeeld moet een bevraging uit de proceslaag in de gegevenslaag qua autorisatie getoetst worden (heeft de aanvrager toestemming om deze API te gebruiken) en moeten doelbinding en grondslag meegegeven worden om te toetsen of de bevraging rechtmatig is.

Het grote voordeel van niveau 3 is dat er nu volwaardig en gelijkwaardig gegevensdiensten zijn voor alle afnemers, waarvoor de autorisatie en (technische) logging op orde zijn. Wijzigingen kunnen sneller geïmplementeerd worden. Wanneer bijvoorbeeld in de schermafhandeling of procesvoering iets wijzigt hoeft alleen dit deel van de oplossing uitgerold te worden. De opvraging en verwerking van gegevens in de database blijft door de ongewijzigde API’s immers onveranderd werken. Andere leveranciers dan de dienstenaanbieder kunnen hun diensten afnemende componenten aansluiten op de volwaardige gegevensdiensten van de dienstaanbieder.

Niveau 4 – Gebruik van standaard informatiemodellen[bewerken]

De uitgangssituatie bij niveau 4 is een applicatie die voldoet aan de niveau 3 specificaties. Het systeem is ontsloten met behulp van bevragings- en mutatie-API’s en de proces en gegevenslagen zijn volledig ontkoppeld.

Globaal Programma van Eisen - image8.png

Zoals in de adoptiecurve (Figuur 2) is te zien, is niveau 4 een grote sprong waarbij applicaties nu volledig met vastgestelde standaard informatiemodellen werken. Dit geldt ook voor sector-/domein informatiemodellen. De API’s werken daarmee ook op basis van standaard informatiemodellen. Het is nu denkbaar dat gebruik wordt gemaakt van componenten van verschillende leveranciers. In Figuur 6 is dit uitgebeeld waarbij de componenten in de interactie en procesinrichting lagen van leverancier 1 (Lev 1) middels API’s samenwerken met de componenten in de diensten en gegevensbronnen lagen van leverancier 2. Daarnaast heeft leverancier 1 ook diensten en gegevensbronnen die specifiek zijn voor de goede werking van zijn oplossing. Het geheel van de componenten in Figuur 6 vormen het systeem/de toepassing.

Met niveau 4 wordt een belangrijke stap gezet in de realisatie van een gestandaardiseerd, flexibel in te richten gegevenslandschap. De gegevens in de oplossingen en het delen van deze gegevens is ondubbelzinnig en er hoeven geen transformaties meer uitgevoerd te worden.

Door het verplicht stellen van het gebruik van vastgestelde standaard informatiemodellen zal voor niveau 4 vooral aandacht uitgaan naar de lagen Diensten en Gegevensbronnen.

Niveau 5 - Volledig doorgevoerde ontkopeling[bewerken]

De uitgangssituatie bij niveau 5 is een applicatie die voldoet aan de niveau 4 specificaties. Het systeem is ontsloten met behulp van bevragings- en mutatie-API’s, werkt met standaard informatiemodellen en de proces en gegevenslagen zijn volledig ontkoppeld.

Globaal Programma van Eisen - image9.png

In niveau 5 worden de laatste stappen gezet in de ontkoppeling van componenten. Het doel is verdere flexibilisering en hiermee het sneller kunnen doorvoeren van wijzigingen in de procesverwerking. Hiervoor worden de componenten voor interactie en procesinrichting ontkoppeld waarvoor aanvullende eisen zijn voor de inrichting van het systeem. Zo wordt de interactie met de gebruiker in eenvoudige aanvraag- en meldingsprocessen dynamisch gestuurd door bv. uitvoerbare BPMN-oplossingen waarin schermen, processen en bedrijfsregels afzonderlijke componenten zijn. Mogelijk is dit geen realistisch scenario voor pakketsoftware. De spelregels zijn nu nog niet bekend en zullen naar mate het gegevenslandschap steeds meer vorm krijgt geadresseerd moeten worden. Aanvullende diensten (API’s) worden geïntroduceerd waarmee data-analyse processen optimaal worden ondersteund zonder de primaire processen te verstoren.

Door de ver doorgevoerde standaardisatie en ontkoppeling is het nu mogelijk onderdelen van het systeem snel aan te passen en als afzonderlijke componenten uit te rollen. Door hergebruik van de procesinrichting kan worden gegarandeerd dat de functionaliteit over alle kanalen heen gelijk is, terwijl de UX anders is.

Een haalbare visie[bewerken]

De praktische haalbaarheid van onderdelen van deze architectuur wordt in de Common Ground praktijk-beproevingen aangetoond. Standaarden worden getoetst en werkende (voorbeelden van) softwarecomponenten worden gerealiseerd. Zo wordt gewerkt aan een proof-of-concept van de integratiefaciliteit (zoals NLX) en worden standaarden voor API’s uitgewerkt (vb. HaalCentraal en ZGW-API’s).

De belofte van de 5-lagen architectuur is flexibiliteit en daarmee aanpasbaarheid en verandersnelheid. Dat wordt tijdens de realisatie langs de adoptiecurve in toenemende mate bereikt. Doordat toepassingen kunnen worden samengesteld uit meerdere componenten verspreid over de lagen, kunnen ook componenten van verschillende leveranciers, ontwikkel-/beheerteams gecombineerd worden om gezamenlijk een toepassing te vormen.

Het blijft uiteraard mogelijk dat één leverancier een volledige toepassing aanbiedt die uit een samenhangende set componenten uit alle 5 lagen is samengesteld. Het gegevenslandschap zal in de toekomst een veelheid aan combinaties van componenten bevatten, van diverse leveranciers/aanbieders en die op basis van de standaarden goed samenwerken. Het maakt daarbij niet uit welke configuratie een gemeente kiest: gestandaardiseerde API’s en informatiemodellen en ontkoppelde functionaliteiten maken heel veel mogelijk, zoals in Figuur 8 hieronder wordt geïllustreerd.

Voorbeeld van een toekomstig applicatielandschap


Praktische tips[bewerken]

Dit document is een hulpmiddel bij de gefaseerde modernisering van de gemeentelijke informatievoorziening conform de thema-architectuur Common Ground informatiearchitectuur. Praktische tips daarbij zijn:

  • Begin met voorzieningen voor de integratie laag, dat is waar alle gegevensuitwisselingen met de API’s langs moeten. Dit kan in eerste instantie heel eenvoudig een webserver, gemeentelijke servicebus of API-gateway zijn.
  • Bepaal per project wat het ambitieniveau is op basis van de specifieke uitgangspunten, omstandigheden en ambities.
  • Bepaal aan de hand van het ambitieniveau en de (functionele) scope van het project welke delen van het gegevenslandschap van toepassing zijn.
  • Identificeer ten slotte de specificaties die nodig/wenselijk en haalbaar zijn op basis van de business case en het gewenst risicoprofiel.
  • Het is mogelijk om eisen en wensen uit verschillende niveaus te combineren in één project. Zorg er dan wel voor dat de eisen en wensen van de verschillende functiegebieden bij elkaar passen.
  • Realiseer alleen functionaliteit die ook gebruikt zal worden (minimum viable product), uitbreiden kan later.

Gericht – specificaties[bewerken]

VNG Realisatie heeft voor alle functiegebieden van de architectuur specificaties geformuleerd. Een systeem voldoet aan de principes van het GEMMA Gegegvenslandschap wanneer alle specificaties van alle functiegebieden zijn ingevuld.

Zoals in de niveaus is aangegeven is het niet realistisch in één keer aan alle specificaties te voldoen. Per vraagstuk (project) zal daarom moeten worden bepaald welke functiegebieden en specificaties door het project worden geraakt en daarvoor kunnen dan de relevante eisen en wensen worden bepaald. Daarbij wordt aanbevolen in de kosten en baten afweging van het project de maakbaarheid uitgewerkt in eisen/wensen van alle specificaties te toetsen. De verwachting is dat sommige onderdelen grote kosten en risico’s zullen inhouden.

Eisen en wensen[bewerken]

De in dit document gehanteerde adoptiecurve is gericht op standaardisatie (API’s, informatiemodellen) en het opsplitsen in componenten en geeft een volgordelijkheid aan voor de realisatie hiervan. Dit is ook terug te zien in de keuze en volgorde bij het invullen van de specificaties. Regie op Gegevens en Abonneren en Notificeren lijken daardoor relatief laat geadresseerd te worden. Dit heeft te maken met het feit dat het in de adoptiecurve niet zozeer gaat óf de genoemde functionaliteiten worden gerealiseerd maar dat die als componenten in de lagen worden gerealiseerd. In de voorgestelde adoptiecurve komen deze daarom pas ná ambitieniveau 3 aan de orde. Dit is zoals gezegd slechts een voorstel waarbij ervoor is gekozen om eerst te concentreren op het leggen van een deel van de fundering van de thema-architectuur Common Ground.

Zoals in §3.3 aangegeven is voor ieder functiegebied een set specificaties opgesteld. Om de transitie volgens de ambitieniveaus te laten lopen is per ambitieniveau aangegeven of de specificatie “nog niet van toepassing”, “een wens” of “een eis” is. In de uitvraag kan ervoor gekozen worden om punten toe te kennen aan eisen en wensen die horen bij een hoger ambitieniveau. Dit uiteraard alleen als deze ook toegevoegde waarde bieden voor de oplossing waarnaar wordt gezocht.

Algemeen[bewerken]

Los van de ambitie en het daarbij passend adoptieniveau, gelden de onderstaande generieke eisen en wensen voor inkooptrajecten voor bestaande pakketten.

Omschrijving Type
De leverancier heeft het Groeipact Common Ground ondertekend of heeft voornemens binnen een half jaar te ondertekenen en kan in een product strategie/release agenda aantonen dat hier naartoe wordt gewerkt. Eis
De beschrijving (van de transitie) van de applicatie architectuur wordt ter inzage beschikbaar gesteld aan de opdrachtgever Wens
Wanneer nog geen standaard informatiemodel is vastgesteld voor een (sub)domein neemt de leverancier initiatief om hiervoor een voorstel te doen (conform het MIM) Wens
Het product van de leverancier zal uiterlijk eind 2030 voldoen aan de eisen bij ambitieniveau 3 van de adoptiecurve Wens
Wanneer een gebruikte basisregistratie ontsloten wordt door API’s zal de leverancier zo spoedig als mogelijk deze API’s gebruiken om deze gegevens in zijn applicatie te gebruiken in plaats van kopieën op te slaan Eis
API’s voor gebruik door derden (buiten de eigen organisatie) worden op een landelijk catalogus gepubliceerd (vb. developer.overheid.nl) Eis
API’s worden via een standaard integratiefaciliteit ontsloten zoals bijvoorbeeld extern op NLX maar dit kan waar van toepassing ook een interne integratiefaciliteiten zijn zoals een gemeentelijke servicebus of API Gateway. Eis

Naar ambitieniveau[bewerken]

Voor iedere laag en functiegebied in de thema-architectuur Common Ground zijn specificaties geformuleerd. Door de keuze voor de adoptiecurve zijn bepaalde specificaties pas in een later ambitieniveau van toepassing. De adoptiecurve is erop gericht een systeem te realiseren conform de architectuur. Specificaties die direct hieraan bijdragen worden daarom sneller opgepakt dan specificaties die een bepaalde functionaliteit realiseren. Het gaat er niet om óf de genoemde functionaliteiten worden gerealiseerd maar dat die als componenten in de lagen worden gerealiseerd.

Afhankelijk van het aan te schaffen systeem, zijn de eisen van bepaalde functiegebieden mogelijk niet relevant.

Voor de voorgestelde adoptiecurve zijn bij de gekozen ambitieniveaus bepaald in hoeverre een specificatie ingevuld moet zijn. In de tabel is het resultaat hiervan verwerkt en wordt zichtbaar in welk ambitieniveau een specificatie wordt opgepakt dan wel uitgebouwd en wanneer het volledig ingevuld moet zijn. Hoewel dit geen limitatieve lijst is bestrijkt het wel de belangrijke onderwerpen in de lagen van de thema-architectuur Common Ground. Per adoptieniveau is aangegeven of een specificatie als Eis of als Wens moet worden gehanteerd. Als het onderwerp nog niet van toepassing is voor een specifiek adoptieniveau wordt dit met een minteken “-“ aangegeven.

Tabel met eisen per functiegebied en ambitieniveau[bewerken]

Uitvouwbare tabel met eisen per functiegebied en ambitieniveau

Laag Functiegebied Id. Nr. Specificatie 1 2 3 4 5
Interactie Proces ondersteuning 1.1.01 Gebruikersschermen zijn niet gekoppeld aan de procesinrichting en uitvoering van de proces laag - - - Wens Eis
1.1.02 Schermen worden dynamisch gegenereerd op basis van geconfigureerde procesinrichting en bedrijfsregels (vb. door middel van uitvoerbare BPMN) - - - Wens Eis
Regie op gegevens 1.2.01 Het systeem kan inzage geven in de geregistreerde gegevens van burgers en bedrijven aan daarvoor bestemde portalen en apps. - - - Eis Eis
1.2.02 Het systeem kan inzage geven in het gebruik door afnemers (binnengemeentelijk, keten- en netwerkpartijen) van gegevens van burgers en bedrijven aan daarvoor bestemde portalen en apps. - - - Eis Eis
1.2.03 Het systeem biedt de mogelijkheid voor burgers om de gemeente te verzoeken gegevens die naar zijn of haar mening incorrect zijn te veranderen - - - Eis Eis
1.2.04 Het systeem biedt de burger regie op de uitwisseling van zijn/haar gegevens tussen gemeenten en keten partijen daar waar deze uitwisseling bovenwettelijk is - - - Wens Eis
1.2.05 Het systeem biedt de burger de mogelijkheid om daar waar van toepassing expliciete toestemming te verlenen voor de verwerking van zijn/haar gegevens (t.b.v. grondslag en doelbindingsclaim) - - - Wens Eis
1.2.06 Het systeem biedt de mogelijkheid de burger actief te informeren op het moment dat een verwerking van zijn/haar gegevens plaatsvindt - - - Wens Eis
Aanvragen en meldingen 1.3.01 Het systeem biedt de mogelijkheid voor burgers en ondernemers meldingen te doen bij de gemeente (vb. Melding openbare ruimte MOR) - - - Wens Eis
1.3.02 Het systeem biedt de mogelijkheid aan burgers en ondernemers producten aan te vragen (vb. uittreksel uit de gemeentelijke basisregistratie personen) - - - Wens Eis
Eindgebruiker authenticatie 1.4.01 Authenticatie en autorisatie van de gebruiker vindt eenmalig bij het aanmelden plaats en wordt in de rest van het systeem toegepast Wens Wens Eis Eis Eis
1.4.02 Het gebruikte authenticatiemiddel past bij het betrouwbaarheidsniveau van de dienst of functie die de gebruiker gaat gebruiken Wens Wens Eis Eis Eis
1.4.03 Voor inwoners wordt gebruik gemaakt van authenticatiemiddelen vastgesteld in het landelijke eID-programma. Wens Wens Eis Eis Eis
1.4.04 Voor bedrijven en medewerkers van gemeenten (als ze namens de gemeente landelijk iets willen aanvragen) wordt gebruik gemaakt van een eHerkenningsmiddel voor authenticatie. Dit wordt tussen Dienstenafnemer en Dienstenaanbieder afgestemd. Wens Wens Eis Eis Eis
1.4.05 Het weergeven van gegevens in de (mobiele) applicatie vindt plaats op basis van het autorisatieniveau van de gebruiker Wens Wens Eis Eis Eis
1.4.06 Daar waar nodig worden diensten pas ter beschikking gesteld nadat de gebruiker is geauthentiseerd Wens Wens Eis Eis Eis
Proces Proces-inrichting en uitvoering 2.1.01 De procesondersteuning kan worden geconfigureerd (vb. door middel van een BPM-systeem) - - Wens Wens Eis
2.1.02 De procesuitvoering wordt bestuurd op basis van de configuratie - - Wens Eis Eis
2.1.03 De procesuitvoering maakt gebruik van de gebruikersinterfaces in de interactie laag - - - Wens Eis
2.1.04 Er wordt op notificaties van dienstenaanbieders gemonitord en geacteerd - - Wens Eis Eis
2.1.05 Het informatiesysteem houdt enkel proces(uitvoering)gegevens bij - - Wens Wens Eis
2.1.06 Gegevens die met API’s bij een bron zijn te bevragen worden niet als kopie van de bron in het informatiesysteem vastgelegd. - - Wens Wens Eis
2.1.07 Gegevens die met API’s bij een bron zijn te bevragen kunnen als proces(uitvoering)gegeven in het informatiesysteem worden vastgelegd als dit noodzakelijk is voor de verantwoording. - - Wens Wens Eis
2.1.08 Configuratiegegevens worden in het informatiesysteem vastgelegd - - Wens Wens Eis
Bedrijfsregels 2.2.01 Bedrijfsregels worden los van de software die zorgt voor de procesuitvoering vastgelegd en kunnen meervoudig toegepast/geraadpleegd worden - - - Wens Eis
2.2.02 Bedrijfsregels worden vastgelegd in een Business Rule Management Systeem (BRMS) - - - Wens Eis
2.2.03 Bedrijfsregels kunnen geconfigureerd worden in de procesinrichting - - - Wens Eis
2.2.04 Bedrijfsregels gericht op de gegevens worden in de Dienst vastgelegd die de gegevens leveren (de API’s van de bronhouder in laag 4) - - Wens Eis Eis
2.2.05 De Dienstenafnemer draagt zorg voor de kwaliteit van de gegevens die aan een Dienst van de bronhouder worden aangeboden om opgeslagen te worden - - Eis Eis Eis
2.2.06 De dienst van de bronhouder dat de gegevens opslaat zorgt voor de borging van de integriteit van de gegevens die worden opgeslagen - - Eis Eis Eis
Data-Analyse ondersteuning 2.3.01 Data-analyse ondersteuning wordt door gespecialiseerde informatiesystemen geleverd zoals datawarehouses en analysesystemen - - Wens Wens Eis
2.3.02 Voor real-time analyses worden de gegevens via API’s verzameld - - - Wens Eis
2.3.03 Het ophalen van grote hoeveelheden gegevens vindt plaats zonder dat dit ten koste van de performance van het systeem gaat - - Wens Eis Eis
2.3.04 Alleen gegevens die passen bij het autorisatieniveau/ doelbinding van het proces en de gebruiker mogen worden verwerkt in analyses - - Wens Eis Eis
2.3.05 Bij het opvragen van de gegevens wordt aangegeven of de gegevens geanonimiseerd/ pseudonimiseerd moeten worden aangeleverd - - Wens Wens Eis
2.3.06 Vanuit een analyse/dashboard is voor een CDO/gegevensmanager altijd te herleiden welke data hiervoor gebruikt is (data lineage) - - Wens Eis Eis
Functie autorisatie 2.4.01 Er wordt geborgd dat enkel bevoegden gebruik kunnen maken van functies Eis Eis Eis Eis Eis
2.4.02 Inregelen van autorisaties voor gebruikers en rollen wordt op een centrale plek in de organisatie uitgevoerd Wens Wens Eis Eis Eis
2.4.03 Voor het inrichten van autorisaties wordt gebruik gemaakt van een authenticatiemiddel zoals DigiD, eHerkenning, een lokaal Identity and Access Management (IAM) tool Eis Eis Eis Eis Eis
2.4.04 De gebruikte authenticatiemiddel heeft minimaal hetzelfde betrouwbaarheidsniveau als de dienst die gebruikt gaat worden Wens Wens Eis Eis Eis
Doel en grondslag 2.5.01 Bij het gebruik van een functie dient aangegeven te worden voor welk doel en met welke grondslag de functie wordt gebruikt (de doelbindingsclaim) - - Wens Eis Eis
2.5.02 Bij het gebruik van een functie moet de juiste doelbindingsclaim worden gehanteerd. Met de gegevens die geregistreerd worden kan de gemeente voldoen aan de eisen van de AVG - - Wens Eis Eis
2.5.03 Er wordt door de oplossing een register van verwerkingsactiviteiten bijgehouden Wens Wens Eis Eis Eis
2.5.04 De burger kan toestemmingen beheren (inclusief verwijderen) via de “Regie op gegevens” functionaliteit - - - Wens Eis
2.5.05 Voor doelbindingsclaims waarvoor geldt dat de grondslag voor de verwerking de expliciete toestemming van de burger betreft moet onomstotelijk aangetoond kunnen worden dat deze expliciete toestemming van de burger ten tijde van de verwerking verleend was - - - Wens Eis
2.5.06 Het systeem verschaft inzicht in het gebruik van persoonsgegevens, inclusief de gegevens voor doelbinding zodat de gemeente kan voldoen aan de eisen van de AVG Eis Eis Eis Eis Eis
Audit logging 2.6.01 Het gebruik van functies en het aanroepen van diensten (API’s) worden vastgelegd in logbestanden - - Eis Eis Eis
2.6.02 In de logbestanden worden minimaal opgenomen: datum en tijd, unieke log-ID van de aanroep bij de aanvrager, welke functie of dienst gebruikt is, wie de eindgebruiker is (authenticatie en autorisatiegegevens), wat de gehanteerde doelbinding is en de (categorieën van) gegevens die verwerkt zijn - - Eis Eis Eis
2.6.03 Voor de datum en tijd wordt gebruik gemaakt van een eenduidige tijd-server - - Eis Eis Eis
2.6.04 De integriteit van de logbestanden wordt bewaakt - - Eis Eis Eis
2.6.05 Er worden geen mutaties in logbestanden aangebracht - - Eis Eis Eis
2.6.06 Logbestanden worden duurzaam toegankelijk gehouden - - Eis Eis Eis
2.6.07 Logbestanden worden gebruikt om burgers en bedrijven inzage te geven in het gebruik van hun gegevens waarbij de autorisatie van de gebruiker bepaald of de gegevens mogen worden opgevraagd en/of verwerkt - - Eis Eis Eis
Integratie faciliteit Netwerk 3.1.01 Het te gebruiken netwerk (het internet of Diginetwerk koppelnetwerken zoals GGI-Netwerk) voor de uitwisseling van gegevens wordt bepaald door het betrouwbaarheids-niveau van de dienst (API) die wordt afgenomen Eis Eis Eis Eis Eis
3.1.02 Internet wordt alleen gebruikt voor diensten die uitsluitend open data verwerken zonder hoge eisen aan de integriteit van die gegevens Eis Eis Eis Eis Eis
3.1.03 De aanbieder van een dienst moet ondersteuning bieden voor gebruik van een netwerk dat past bij het betrouwbaarheidsniveau en benodigde integriteit Eis Eis Eis Eis Eis
Netwerk-beveiliging 3.2.01 Minimaal moeten “klassieke” preventiemiddelen zoals firewalls, antivirus, mail filtering, indringerdetectiesystemen etc. worden aangeboden Eis Eis Eis Eis Eis
3.2.02 Het component Netwerkbeveiliging geeft invulling aan de continue monitoring en analyse van het dataverkeer over het netwerk en de daaraan gekoppelde signaleringsfuncties Eis Eis Eis Eis Eis
3.2.03 Het GGI-Veilig-portfolio wordt gebruikt voor de preventieve en detective maatregelen op het gebied van netwerkbeveiliging Wens Wens Wens Wens Wens
Verbinden 3.3.01 De dienstencatalogus wordt gebruikt om te bepalen waar een dienst zich bevindt Eis Eis Eis Eis Eis
3.3.02 Er wordt gebruik gemaakt van client en server certificaten (eenweg of tweeweg TLS) tussen aanbieder en afnemer Wens Wens Wens Wens Wens
3.3.03 Voor het transport van gegevens tussen de aanbieder en afnemer wordt gebruik gemaakt van de netwerkfunctie Eis Eis Eis Eis Eis
3.3.04 De verbindingsfunctie voldoet aan de eisen die vanuit onder andere de Baseline Informatiebeveiliging Overheid (BIO) en privacywetgeving (AVG) gesteld worden Eis Eis Eis Eis Eis
Diensten-catalogus 3.4.01 Het volledig dienstenaanbod (API’s) van een aanbieder dat beschikbaar is voor afnemers worden gepubliceerd en ontsloten via een dienstencatalogus Eis Eis Eis Eis Eis
3.4.02 Diensten (API’s) worden in de vorm van REST/JSON beschreven volgens, in overeenstemming met de daartoe binnen de verheid vastgelegde Open API Specification (OAS) versie 3.x Wens Wens Wens Eis Eis
3.4.03 Per dienst worden de authenticatiemogelijkheden en testfaciliteiten beschreven Eis Eis Eis Eis Eis
3.4.04 Via de dienstencatalogus kunnen potentiële afnemers vinden waar een dienst in de praktijk getest kan worden Eis Eis Eis Eis Eis
3.4.05 De dienstencatalogus wordt niet gebruikt op run-time niveau (tijdens de uitvoering van processen), alleen op design-time niveau (het is geen single-point-of-failure in de communicatie tussen afnemer en aanbieder) Eis Eis Eis Eis Eis
Diensten (API’s) Organisatie authenticatie 4.1.01 Voor de authenticatie van aanbieders en afnemers wordt gebruik gemaakt van PKIoverheid-service certificaten Eis Eis Eis Eis Eis
Diensten autorisatie 4.2.01 Er wordt gebruik gemaakt van het principe van gedelegeerde autorisatie waarbij de afnemer autoriseert op het niveau van de eindgebruiker en de aanbieder autoriseert op het niveau van de afnemende organisatie. Er wordt dus gewerkt met de aggregatie van de identiteit van een specifiek niveau (gebruiker) naar een generiek niveau (gemeente) Eis Eis Eis Eis Eis
4.2.02 Er wordt door de aanbieder gewerkt met autorisatieprofielen o.b.v. gegevensleveringsovereenkomsten (GLO) tussen de aanbieder en afnemer ten aanzien van de uitwisseling van gegevens Eis Eis Eis Eis Eis
Diensten 4.3.01 Diensten (API’s) worden in de vorm van REST/JSON aangeboden Wens Wens Wens Wens Wens
4.3.02 Er wordt onderscheidt gemaakt tussen “Systeemdiensten”, “Procesdiensten” en “Gemaks-/ervaringsdiensten” Eis Eis Eis Eis Eis
4.3.03 Systeemdiensten werken op het niveau van de databron en zijn gericht op het ontsluiten (lezen) en bijwerken (aanmaken, wijzigen en verwijderen) van gegevens uit/in de gegevensverzameling die wordt bijgehouden Eis Eis Eis Eis Eis
4.3.04 Procesdiensten orkestreren één of meerdere systeem-diensten door deze aan te roepen en de resultaten gebundeld terug te geven aan de afnemer Eis Eis Eis Eis Eis
4.3.05 Gemaks- of ervaringsdiensten beantwoorden één specifieke gebruikersvraag Eis Eis Eis Eis Eis
4.3.06 Gemaks- of ervaringsdiensten verstrekken gegevens proportioneel en subsidiair (vb. in plaats van de geboortedatum de indicatie “Ouder dan 18 J/N”) Eis Eis Eis Eis Eis
4.3.07 De aanbieder van diensten maakt aantoonbaar enkel gebruik van diezelfde diensten in zijn eigen toepassingen Wens Wens Wens Eis Eis
4.3.08 Gegevens worden bij de bron opgevraagd op het moment dat ze nodig zijn Wens Wens Wens Eis Eis
4.3.09 Gegevens worden slechts één keer (in een applicatie) opgeslagen - Wens Wens Eis Eis
4.3.10 Gegevens worden niet over meerdere databases gesynchroniseerd - Wens Wens Eis Eis
4.3.11 Externe-brongegevens worden alleen bij het systeem opgeslagen als dit voor de verantwoording noodzakelijk is (vb. omdat er geen bronsysteem voor bestaat, het bronsysteem geen tijdreis faciliteit heeft, etc.) - Wens Wens Eis Eis
4.3.12 Een Procesdienst wordt als één geheel uitgevoerd en voldoet aan de ACID-eigenschap (Atomair, Consistent, Isoleerbaar, Duurzaam) waarmee de integriteit van de onderliggende data-attributen en de consistentie van de gegevens in het systeem worden geborgd - Wens Wens Eis Eis
4.3.13 Een Procesdienst start en beëindigt zelf de transactie waarin de dienst wordt uitgevoerd (definieert zelf de grenzen van de uit te voeren transactie) - Eis Eis Eis Eis
4.3.14 Bedrijfsregels met een oorsprong in wet- en regelgeving worden zo dicht mogelijk bij de gegevens geïmplementeerd Wens Wens Wens Eis Eis
Terugmelden 4.4.01 Het is in alle gevallen voor afnemers mogelijk om twijfels over de correctheid van gegevens door te geven aan de bronhouder - - - Eis Eis
4.4.02 De bronhouder richt diensten in waarmee terugmeldingen ingediend worden, deze gesignaleerd worden, acties uitgezet worden voor de afhandeling van de terugmelding waaronder notificaties en statusmeldingen - - - Eis Eis
Abonneren en notificeren 4.5.01 Door de bronhouder worden abonnementen aan Dienstenafnemers (organisaties) aangeboden op wijzigingen in een gegevensbron - - - Eis Eis
4.5.02 In een abonnement wordt aangegeven welke gegevens of gegevensgroepen onderdeel zijn van het abonnement - - - Eis Eis
4.5.03 Abonnementen worden alleen afgesloten op gegevens waarvoor de afnemende organisatie is geautoriseerd - - - Eis Eis
4.5.04 De dienstenaanbieder stuurt bij een geabonneerde wijziging iedere ingeschreven organisatie een notificatiebericht - - - Eis Eis
4.5.05 De geabonneerde organisatie draagt middels een lokale voorziening voor de interne routering van een notificatie - - - Eis Eis
4.5.06 In notificatieberichten worden alleen verwijzingen naar gewijzigde objecten (sleutelgegevens), de context van de wijziging en de reden voor de notificatie opgenomen - - - Eis Eis
Audit logging 4.6.01 De aanroep van een dienst (API) wordt vastgelegd in logbestanden ongeacht of de aanroep succesvol was of niet Eis Eis Eis Eis Eis
4.6.02 In de logbestanden worden vastgelegd de datum en tijd, de identificatie van de dienst dat gebruikt is (incl. versienummer), het OIN (Organisatie-identificatienummer) van de organisatie die de dienst heeft aangeroepen, de doelbindingsclaim en de unieke log-ID waarmee de aanroep herleid kan worden naar de logging van de dienstenafnemer Wens Eis Eis Eis Eis
4.6.03 De integriteit van de logbestanden wordt bewaakt Eis Eis Eis Eis Eis
4.6.04 Er worden geen mutaties in logbestanden toegestaan Eis Eis Eis Eis Eis
4.6.05 Logbestanden worden duurzaam toegankelijk gehouden Eis Eis Eis Eis Eis
Transformatie 4.7.01 Transformatie van gegevens moet zoveel als mogelijk voorkomen worden en beperkt worden tot (nog) niet op elkaar aansluitende standaarden Wens Wens Wens Eis Eis
4.7.02 Transformatie van gegevens in proces- en gemaks-/ervaringsdiensten heeft geen invloed op de gegevens in de bron Eis Eis Eis Eis Eis
Integratie 4.8.01 Voor het beantwoorden van één specifieke gebruikersvraag waarbij gegevens uit meerdere databronnen nodig zijn, roepen proces-, gemaks-, ervaringsdiensten de benodigde systeemdiensten aan om de gegevens uit verschillende databronnen te combineren en als één antwoord terug te geven Wens Wens Wens Eis Eis
Pseudonimi-sering en Anonimisering 4.9.01 Afhankelijk van de aard van de aangeroepen dienst (vb. t.b.v. data-analyse), de doelbindingsclaim en de privacywetgeving worden persoon identificerende gegevens pseudonimiseerd Eis Eis Eis Eis Eis
4.9.02 De bronhouder kan de pseudonimiseerde gegevens weer terug herleiden naar de persoon Eis Eis Eis Eis Eis
4.9.03 Pseudonimiseerde gegeven worden als persoonsgegevens gezien en worden volgens, in overeenstemming met de privacywetgeving behandeld Eis Eis Eis Eis Eis
4.9.04 Afhankelijk van de aard van de aangeroepen dienst (vb. ten behoeve van data-analyse), de doelbindingsclaim en de privacywetgeving worden persoon identificerende gegevens geanonimiseerde Eis Eis Eis Eis Eis
4.9.05 Bij anonimiseren worden alle herleidbare persoonsgegevens gemaskeerd Eis Eis Eis Eis Eis
4.9.06 De bronhouder kan de geanonimiseerde gegevens niet meer terug herleiden naar de persoon en hierdoor worden de geanonimiseerde gegevens niet als persoonsgegevens behandeld Eis Eis Eis Eis Eis
Gegevens Bijhouding gegevens 5.1.01 Gegevensbronnen zijn qua syntax en samenhang gestandaardiseerd - Wens Wens Eis Eis
5.1.02 De syntax en samenhang zijn in een informatiemodel gedocumenteerd. Een informatiemodel vormt de formele beschrijving van alle informatie die van belang is binnen een gegeven domein en beschrijft het domein in termen van objecten, gegevens (attributen) en de relaties daartussen - Wens Wens Eis Eis
5.1.03 Een informatiemodel is opgesteld volgens, in overeenstemming met het Metamodel voor Informatiemodellen (MIM) - Wens Wens Eis Eis
5.1.04 De beschrijving van het informatiemodel wordt ter beschikking gesteld - Eis Eis Eis Eis
5.1.05 Waar beschikbaar wordt gebruik gemaakt van gestandaardiseerde gemeentelijke informatiemodellen voor sectorale/domein specifieke gegevens en gemeentelijke kerngegevens - Wens Wens Eis Eis
5.1.06 Waar nog geen gestandaardiseerde gemeentelijke informatiemodel bestaat wordt een voorstel hiervoor aangedragen - Wens Wens - -
5.1.07 Er wordt gebruik gemaakt van landelijk vastgestelde catalogi ten aanzien van gegevens (vb. Suwi gegevensregister SGR) - Eis Eis Eis Eis
5.1.08 Het datamodel van het systeem is beschreven. - Eis Eis Eis Eis
5.1.09 De beschrijving van het datamodel wordt ter beschikking gesteld aan de opdrachtgever - Wens Wens Wens Wens
Historie en metadatering 5.2.01 Digitale informatieobjecten voldoen aan de eisen uit de Archiefwet - Eis Eis Eis Eis
5.2.02 De dienstenaanbieder borgt dat ten aanzien van de informatieobjecten (gegevensobjecten en documenten) die door hem worden beheerd wordt voldaan aan de DUTO-kwaliteitscriteria (informatieobjecten moeten vindbaar, beschikbaar, lees- en bruikbaar, interpreteerbaar en betrouwbaar -authentiek en integer- zijn) - Eis Eis Eis Eis
5.2.03 Informatieobjecten in een bronregister worden naar aanleiding van het gebruik in processen en/of diensten voorzien van automatisch gecreëerde en geüpdatete compliance metadata - Wens Wens Eis Eis
5.2.04 Daar waar het functioneel bijhouden van historie vereist is (vb. ten behoeve van bevraging op peildatum) moet iedere relevante toestandsverandering van een object in een register bekend zijn - Wens Wens Eis Eis
5.2.05 De aard van de toestandsverandering wordt bij het object vastgelegd - Wens Wens Eis Eis
Protocollering 5.3.01 Het is mogelijk om na te gaan of administratieve handelingen juist zijn uitgevoerd (volgens protocol) - Wens Wens Eis Eis
5.3.02 Daar waar het functioneel bijhouden van administratieve handelingen vereist is (vb. BRP) moet iedere handeling van het systeem worden vastgelegd (protocolleren) - Eis Eis Eis Eis
5.3.03 In de protocollering wordt vastgelegd welke gegevens uit de registratie wanneer, door wie, over wie en aan wie zijn verstrekt - Eis Eis Eis Eis
5.3.04 Het is achteraf m.b.v. de vastlegging van de gegevens-verstrekkingen mogelijk te herleiden of deze rechtmatig heeft plaatsgevonden (de privacy functie) - Eis Eis Eis Eis

Bijlage A: voorbeeld teksten Best Value Procurement[bewerken]

Op basis van de voorgestelde eisen en wensen per ambitieniveau zijn voorbeeld teksten opgesteld die gebruikt kunnen worden in Best Value Procurement aanbestedingen.

Voorbeeld teksten niveau 1[bewerken]

Eisen en wensen niveau 1

Bij voorkeur worden autorisaties voor gebruikers en rollen op een centrale plek in de organisatie uitgevoerd, vindt authenticatie en autorisatie van de gebruiker eenmalig bij het aanmelden plaats en wordt deze in de rest van het systeem toegepast. Het daarbij gebruikte authenticatiemiddel past bij het betrouwbaarheids-niveau van de dienst of functie die de gebruiker gaat gebruiken (vb. DigiD, eHerkenning, een lokaal Identity and Access Management (IAM) tool).

De dienstenafnemer houdt een (bij voorkeur digitaal toegankelijk) register van verwerkingsactiviteiten bij. Het systeem moet in ieder geval inzicht verschaffen in het gebruik van persoonsgegevens, inclusief de gegevens voor doelbinding zodat aan de eisen van de AVG kan worden voldaan.

Voor sectorale/domein specifieke gegevens en gemeentelijke kerngegevens mag het informatiemodel van de leverancier worden gebruikt. Waar mogelijk wordt bij voorkeur gewerkt met een standaard vastgesteld informatiemodel. Leveranciers worden verzocht in het geval geen standaard informatiemodel bestaat hiervoor een voorstel te doen. Ook wordt gebruik gemaakt van landelijk vastgestelde catalogi zoals Suwi gegevensregister SGR.

Er wordt vanuit gegaan dat de integratie laag (3) géén onderdeel vormt van het pakket maar dat het pakket hierop aansluit. Het wordt gebruikt als koppelvlak voor externe gegevensuitwisseling. De diensten/API’s zijn openlijk beschikbaar gesteld/gepubliceerd middels een dienstencatalogus waarbij ook authenticatiemogelijkheden en testfaciliteiten beschreven zijn. Contracten tussen de aanbieder en afnemer zijn in de integratie laag geregeld. De toegang verloopt afhankelijk van het betrouwbaarheidsniveau van de API en de gegevens (vb. Open Data) over passende beveiligde netwerken (internet of Diginetwerk koppelnetwerken zoals GGI-Netwerk). Daarbij wordt gebruik gemaakt van certificaten tussen aanbieder (server) en afnemer (client). Het dataverkeer over de API’s wordt continu gemonitord en geanalyseerd (vb. met het GGI-Veilig-portfolio).

Er wordt bij voorkeur gebruik gemaakt van REST/JSON API’s die voldoen aan de API-strategie voor de Nederlandse overheid. Zij zijn conform de Open API Specification (OAS) versie 3.x beschreven/ gedocumenteerd.

De toegang tot de gegevens wordt beveiligd op basis van autorisatiekenmerken die bij de aanroep van de API worden meegegeven. Hierbij wordt gebruik gemaakt van autorisatieprofielen op basis van een gegevensleveringsovereenkomst (GLO). Het autorisatiemechanisme moet voldoende bescherming bieden en ook goed beheersbaar zijn. Voor het extern (tussen organisaties) transporteren van gegevens tussen systemen over het internet worden PKIoverheid service-certificaten gebruikt. Authenticatiemiddelen moeten minimaal een gelijk niveau hebben aan het betrouwbaarheidsniveau van de diensten die gebruikt worden.

Niveau 1 API’s bevatten functionaliteit om gegevens uit de gegevensverzamelingen te lezen. Daarbij wordt onderscheid gemaakt in drie soorten diensten t.w.:

  • Systeemdiensten - gericht op het ontsluiten van gegevens,
  • Procesdiensten - die een of meer systeemdiensten orkestreren en de resultaten bundelen om de gevraagde informatie te leveren
  • Gemaks- of Ervaringsdiensten - die een specifieke gebruikersvraag beantwoorden.

Bedrijfsregels met een oorsprong in wet- en regelgeving worden zo dicht mogelijk bij de gegevens geïmplementeerd. De informatie wordt waar mogelijk proportioneel en subsidiair verstrekt (vb. in plaats van de geboortedatum de indicatie “Ouder dan 18 J/N”).

Bij voorkeur worden gegevens opgehaald op het moment dat ze nodig zijn.

Gemaks- en Ervaringsdiensten roepen bij voorkeur zelf alle benodigde systeemdiensten aan om de gegevens uit de verschillende databronnen te combineren en als één antwoord terug te geven.

Het heeft de sterke voorkeur dat de leverancier van de API’s deze API’s ook in het eigen product gebruikt.

Een applicatie zorgt dat bij aanroep van een API (succesvol of niet) wordt vastgelegd in duurzaam toegankelijke, beveiligde en bewaakte logbestanden (conform de BIO eisen). Een registratie van een aanroep bevat bij voorkeur de datum en tijd, de identificatie van de API dat gebruikt is (incl. versienummer), het OIN (Organisatie-identificatienummer) van de organisatie die de dienst heeft aangeroepen, de doelbindingsclaim en de unieke log-ID waarmee de aanroep herleid kan worden naar de logging van de afnemer. Voor de datum en tijdbepaling moet gebruik worden gemaakt van een eenduidige tijd-server (zie ook “Logging van verwerking van gegevens” op gemmaonline.nl).

Transformatie van gegevens mag geen invloed hebben op de gegevens in de bron. De doelbindingsclaim uit de aanvraag/aanroep in combinatie met de geldende privacywetgeving (AVG) moeten gebruikt worden om te bepalen of de gegevens in het antwoord gepseudimiseerd en/of geanonymiseerd aangeboden moeten worden.

Voorbeeld teksten niveau 2[bewerken]

Eisen en wensen (aanvulling/aanscherping op niveau 1)

Niveau 2 API’s (Systeemdiensten, Procesdiensten, Gemaks- of Ervaringsdiensten) bevatten functionaliteit om gegevens uit de gegevensverzamelingen te lezen én bij te werken (aanmaken, wijzigen, verwijderen).

Procesdiensten voor het bewerken van gegevens worden bij voorkeur als één geheel uitgevoerd (vb. het bijwerken van meerdere tabellen binnen één transactie) en de integriteit van de onderliggende data-attributen en de consistentie van de gegevens in de toepassing worden geborgd (vb. door te voldoen aan de ACID-eigenschappen Atomair, Consistent, Isoleerbaar en Duurzaam).

Gegevens worden bij voorkeur slechts één keer in een toepassing opgeslagen en niet over meerdere databases gesynchroniseerd. Het geniet de voorkeur dat externe brongegevens alleen in de database van de toepassing worden opgeslagen als dit voor de verantwoording noodzakelijk is.

Gegevensbronnen zijn qua syntax en samenhang bij voorkeur gestandaardiseerd.

Ten behoeve van de audit logging bevat een registratie van een aanroep altijd minimaal de datum en tijd, de identificatie van de API dat gebruikt is (incl. versienummer), het OIN (Organisatie-identificatienummer) van de organisatie die de dienst heeft aangeroepen, de doelbindingsclaim en de unieke log-ID waarmee de aanroep herleid kan worden naar de logging van de afnemer. Voor de datum en tijdbepaling moet gebruik worden gemaakt van een eenduidige tijd-server (zie ook “Logging van verwerking van gegevens” op gemmaonline.nl).

Digitale informatieobjecten voldoen aan de eisen uit de Archiefwet en er wordt voldaan aan de DUTO-eisen (DUurzame Toegankelijkheid van Overheidsinformatie) voor de informatie in de informatiesystemen.

Bij voorkeur worden automatisch gecreëerde en geüpdatete compliance metadata over het gebruik van informatieobjecten in bronregisters geregistreerd. Daar waar het functioneel bijhouden van historie vereist is (vb. een bevraging op peiljaar) wordt bij voorkeur iedere relevante toestandsverandering van een object in een register bijgehouden en geregistreerd (functionele logging).

Idealiter is het mogelijk na te gaan of administratieve handelingen volgens protocol zijn uitgevoerd. Daar waar het functioneel bijhouden van administratieve handelingen vereist is (vb. BRP) moet iedere handeling van het systeem worden vastgelegd (protocolleren). Daarbij moet worden vastgelegd welke gegevens uit de registratie wanneer, door wie, over wie en aan wie zijn verstrekt. Met deze gegevens moet het mogelijk zijn te herleiden of de handeling rechtmatig heeft plaatsgevonden (de privacyfunctie).

Voorbeeld teksten niveau 3[bewerken]

Eisen en wensen (aanvulling/aanscherping op niveau 2)

Registraties van autorisaties voor gebruikers en rollen moeten op een centrale plek in de organisatie worden uitgevoerd. Authenticatie en autorisatie van de gebruiker vindt eenmalig bij het aanmelden plaats en deze wordt in de rest van het systeem toegepast. Het daarbij gebruikte authenticatiemiddel moet bij het betrouwbaarheidsniveau van de dienst of functie passen die de gebruiker gaat gebruiken (vb. DigiD, eHerkenning, een lokaal Identity and Access Management (IAM) tool).

Bij voorkeur is er sprake van configureerbare procesinrichting, -besturing en -monitoring waarmee ook workflows en responsieve processen (vb. naar aanleiding van een notificatie) kunnen worden ontworpen, getest en geactiveerd.

Het informatiesysteem houdt bij voorkeur slechts proces(uitvoerings)gegevens bij en raadpleegt met bevragings-API’s de gegevens uit andere administraties (bronnen/bronhouders) op het moment dat die gegevens nodig zijn (vb. BRP). Gegevens die met API’s bij een bron zijn te bevragen worden daarmee niet gekopieerd en opgeslagen in het eigen informatiesysteem, tenzij dit voor de verantwoording noodzakelijk is (vb. als de bron geen tijdreizen ondersteunt).

Door de opsplitsing van gegevens en processen heeft het de voorkeur om (bedrijfs)regels voor het selecteren/filteren/combineren van gegevens niet in de code op procesinrichtingslaag worden opgenomen maar in de API’s van de bron. De Dienstenafnemer draagt zorg voor de kwaliteit van de gegevens die aan een Dienst van de bronhouder worden aangeboden om opgeslagen te worden. De Dienstenaanbieder zorgt voor de borging van de integriteit van de gegevens die worden opgeslagen.

Data-analyse-ondersteuning wordt bij voorkeur door gespecialiseerde informatiesystemen geleverd zoals datawarehouses en analysesystemen waarbij aangegeven kan worden of de gegevens geanonimiseerd/ gepseudonimiseerd moeten worden aangeleverd. Bij voorkeur is het voor een CDO/gegevensmanager mogelijk vanuit een analyse/dashboard te herleiden welke data hiervoor gebruikt is (data lineage). De te verwerken gegevens passen bij voorkeur bij het autorisatieniveau/de doelbinding van het proces en de gebruiker. Het ophalen van grote hoeveelheden gegevens vindt plaats zonder dat dit ten koste van de performance van het systeem gaat.

Functieautorisatie is volledig ingevoerd. Alleen bevoegden kunnen gebruik maken van functies doordat autorisaties ingericht worden met een authenticatiemiddel zoals DigiD, eHerkenning, eIDAS of een lokaal Identity and Access Management (IAM) tool passend bij het benodigde betrouwbaarheidsniveau.

Bij het gebruik van een functie dient bij voorkeur aangegeven te worden voor welk doel en met welke grondslag de functie wordt gebruikt (de doelbindingsclaim). Bij voorkeur wordt de doelbindingsclaim bij de uitvoering van een functie getoetst en gehandhaafd. In ieder geval wordt een register van verwerkingsactiviteiten bijgehouden waarmee de gemeente kan voldoen aan de eisen van de AVG.

Door de opsplitsing van gegevens en processen moeten ten behoeve van de controleerbaarheid (audit) aangevraagde en uitgevoerde diensten worden gelogd bij enerzijds de dienstafnemer en anderzijds de dienstaanbieder. Hiervoor worden logbestanden bijgehouden waarin minimaal opgenomen: datum en tijd, unieke log-ID van de aanroep bij de aanvrager, welke functie of dienst gebruikt is, wie de eindgebruiker is (authenticatie en autorisatiegegevens), wat de gehanteerde doelbinding is en de (categorieën van) gegevens die verwerkt zijn. De integriteit van de logbestanden moet worden bewaakt waarbij geen mutaties (wijzigen/verwijderen) in eerder vastgelegde loggegevens mogen worden aangebracht. De logbestanden worden duurzaam toegankelijk gehouden en moeten kunnen worden gebruikt om burgers en bedrijven inzage te geven in het gebruik van hun gegevens. Daarbij bepaald de autorisatie of de gegevens mogen worden opgevraagd en/of verwerkt.

Voorbeeld teksten niveau 4[bewerken]

Eisen en wensen (aanvulling/aanscherping op niveau 3)

Het is een optie om gebruikersschermen los te implementeren van de functies in de laag Procesinrichting en deze dynamisch te genereren op basis van geconfigureerde procesinrichting en bedrijfsregels (vb. door middel van uitvoerbare BPMN).

Om de burgers en bedrijven regie te laten voeren op hun gegevens zijn er faciliteiten waarmee inzage gegeven kan worden in de “eigen” gegevens van burgers en bedrijven alsook het gebruik van deze gegevens door afnemers (binnengemeentelijk, keten- en netwerkpartijen). Bij vermeende incorrecte gegevens zijn er faciliteiten waarmee correctie kan worden aangevraagd.

Bij voorkeur kunnen burgers, daar waar deze uitwisselingen bovenwettelijk zijn, regie voeren op de uitwisseling van hun gegevens tussen gemeenten onderling en tussen gemeenten en ketenpartijen. Ook zijn er bij voorkeur faciliteiten waarmee de burger daar waar van toepassing expliciete toestemming kan verlenen voor de verwerking van zijn/haar gegevens (t.b.v. grondslag en doelbindingsclaim). Tot slot zijn er bij voorkeur faciliteiten waarmee de burger actief geïnformeerd wordt op het moment dat een verwerking van zijn/haar gegevens plaatsvindt.

Er is sprake van configureerbare procesinrichting, -besturing en -monitoring (bij voorkeur met een BPM-systeem) waarmee ook workflows en responsieve processen kunnen worden ontworpen, getest en geactiveerd (vb. naar aanleiding van een notificatie). Er wordt actief op notificaties van dienstenaanbieders gemonitord en hierop wordt indien nodig actie ondernomen.

Bedrijfsregels kunnen buiten de software voor de procesverwerking (als stuurgegevens) worden vastgelegd.

Voor real-time data-analyses worden de gegevens bij voorkeur door middel van API’s opgehaald bij de bron.

Autorisatie voor het gebruik van functie is volledig ingevoerd op basis van een centrale autorisatie administratie van gebruikers en functies. Er wordt daarbij geborgd dat de gebruikte authenticatiemiddel minimaal hetzelfde betrouwbaarheidsniveau heeft als de dienst (API) die gebruikt gaat worden.

Het heeft de voorkeur dat een burger toestemmingen voor gebruik van zijn/haar gegevens kan beheren (inclusief verwijderen) via de “Regie op gegevens” functionaliteit. In het verlengde hiervan geldt waar van toepassing dat onomstotelijk aangetoond moet kunnen worden dat de expliciete toestemming van de burger ten tijde van de verwerking verleend was.

Functionaliteit voor de bewaking en registratie van grondslag en doelbinding is volledig geïmplementeerd. De gemeente kan hiermee volden aan de eisen van de AVG.

De leverancier maakt in het eigen product aantoonbaar gebruik van dezelfde API’s die aan derden ter beschikking worden gesteld.

Gegevens worden slechts één keer in een toepassing opgeslagen en niet over meerdere databases gesynchroniseerd. Externe brongegevens worden alleen in de database van de toepassing opgeslagen als dit voor de verantwoording noodzakelijk is.

Procesdiensten (vb. het bijwerken van meerdere tabellen binnen één transactie) starten en beëindigen zelf de transactie en worden als één geheel uitgevoerd. Zij voldoen aan de ACID-eigenschappen (Atomair, Consistent, Isoleerbaar en Duurzaam) waarmee de integriteit van de onderliggende data-attributen en de consistentie van de gegevens in de toepassing worden geborgd.

Aansluitend op de faciliteiten voor afnemers van gegevens om twijfels over de correctheid van de gegevens door te geven, zijn processen ingericht waarmee deze terugmeldingen kunnen worden ontvangen en verwerkt.

Afnemers kunnen zich abonneren op (bepaalde) wijzigingen in (bepaalde) gegevens van een gegevensbron waarvoor zij geautoriseerde zijn. Hiervoor worden afspraken tussen aanbieder en afnemer opgesteld (GLO) waarin onder andere wordt vastgelegd onder welke omstandigheden (wijzigingen) een notificatie wordt ontvangen, op welke gegevensgroepen dit betrekking heeft en hoe de autorisatie is geregeld.

Altijd worden op wijzigingen ingeschreven organisaties met een notificatiebericht op de hoogte gesteld van een wijziging. De geabonneerde organisatie draagt middels een lokale voorziening voor de interne routering van een notificatie. Notificatieberichten zijn gegevensarm en bevatten hierdoor alleen verwijzingen (sleutelgegevens) naar gegevensobjecten, de context van de wijziging en de reden voor de notificatie.

Transformatie van gegevens is beperkt tot samengestelde bevragingen (meerdere bronnen) waar standaardisatie over de informatiemodellen heen nog niet is doorgevoerd.

Proces-, Gemaks- en Ervaringsdiensten roepen zelf alle benodigde systeemdiensten aan om de gegevens uit verschillende databronnen te combineren en als één antwoord terug te geven.

Gegevensbronnen zijn qua syntax en samenhang gestandaardiseerd. Er wordt gebruik gemaakt van vastgestelde gestandaardiseerde gemeentelijke informatiemodellen voor sectorale/domein specifieke gegevens en gemeentelijke kerngegevens.

Er wordt gebruik gemaakt van landelijk vastgestelde catalogi ten aanzien van gegevens (vb. Suwi gegevens-register).

Gegevensbronnen zijn qua syntax en samenhang gestandaardiseerd en gedocumenteerd in overeenstemming met het Metamodel voor Informatie Modellen (MIM).

Voorbeeld teksten niveau 5[bewerken]

Eisen en wensen (aanvulling/aanscherping op niveau 4)

Gebruikersschermen en rapportages moeten los geïmplementeerd zijn van de functies in de laag Procesinrichting (2) Deze worden dynamisch gegenereerd op basis van geconfigureerde procesinrichting en bedrijfsregels (vb. door middel van uitvoerbare BPMN).

Om de burgers en bedrijven regie te laten voeren op het gebruik van hun eigen gegevens zijn voor alle relevante gegevens faciliteiten waarmee inzage gegeven kan worden in de “eigen” gegevens van burgers en bedrijven als ook het gebruik van deze gegevens door afnemers (binnengemeentelijk, keten- en netwerkpartijen). Voor vermeende incorrecte gegevens zijn er faciliteiten waarmee het corrigeren kan worden aangevraagd.

Burgers kunnen, daar waar deze uitwisseling bovenwettelijk zijn, volledige regie voeren op de uitwisseling van hun gegevens tussen gemeenten onderling en tussen gemeente en ketenpartijen. Ook zijn alle faciliteiten beschikbaar voor de burger om daar waar van toepassing expliciete toestemming te verlenen voor de verwerking van zijn/haar gegevens (t.b.v. grondslag en doelbindingsclaim). Tot slot zijn alle faciliteiten beschikbaar waarmee de burger actief geïnformeerd wordt op het moment dat een verwerking van zijn/haar gegevens plaatsvindt.

Er zijn faciliteiten beschikbaar waarmee burgers en bedrijven meldingen kunnen doen bij de gemeente (vb. Melding openbare ruimte) en producten kunnen aanvragen (vb. uittreksels).

Procesinrichting, -besturing en -monitoring is configureerbare met een BPM-systeem waarmee ook workflows en responsieve processen kunnen worden ontworpen, getest en geactiveerd (vb. naar aanleiding van een notificatie).

De bedrijfsregels worden buiten de software (de code) voor de procesverwerking (als stuurgegevens) vastgelegd.

Data-analyses worden door gespecialiseerde informatiesystemen geleverd. De gegevens ten behoeve van real-time data-analyses worden door middel van API’s verzameld waarbij in de aanvraag wordt aangegeven of de gegevens geanonimiseerd/gepseudonimiseerd moeten worden aangeleverd.

Alle functies van het systeem werken met API’s volgens de eisen en wensen van de thema-architectuur Common Ground.

Aansluitend op de faciliteiten voor afnemers van gegevens om twijfels over de correctheid van de gegevens door te geven, zijn diensten ingericht waarmee deze terugmeldingen geautomatiseerd kunnen worden ontvangen en verwerkt.

Afnemers kunnen zich abonneren op alle relevante wijzigingen in de gegevens van een gegevensbron waarvoor zij geautoriseerde zijn.

Bijlage B: Afkortingen en definities[bewerken]

Afkortingen

Afkorting Betekenis
ACID Atomair, Consistent, Isoleerbaar en Duurzaam
API Application Programming Interface
AVG Algemene Verordening Gegevensbescherming
GLO GegevensLevering Overeenkomst
JSON Javascript Object Notation
MIM Metamodel Informatie Modellering
REST Representational State Transfer
SOA Service Oriented Architecture
StUF Standaard Uitwisseling Formaat


Definities

Begrip Definitie
API Gateway Een API Gateway is een voorziening tussen de aanvrager (client) en de leverancier van een dienst (serviceprovider). Alle aanroepen van API’s door aanvragers verlopen via de API Gateway.

Een API Gateway beschikt over de volgende functionaliteit:

  • Ontvangt centraal alle aanvragen voor API’s.

  • Controleert de beveiligingsregels (authenticatie en autorisatie).

  • Past regels toe (bijvoorbeeld het toegestaan gebruik van systeemresources),

  • Geeft aanroepen door aan de API’s.

  • Geeft de antwoorden van de API’s door aan de aanvragers.

  • Registreert het gebruik van API’s (logging).

  • Publicatie van API’s die aan afnemers beschikbaar gesteld worden.

  • Registratie van abonnementen van afnemers voor API’s.

Application Programming Interface Een application programming interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma. API’s bieden de mogelijkheid om gegevens of functionaliteit op een gestandaardiseerde manier beschikbaar te stellen.
Basisregistratie Een bij wet als basisregistratie aangemerkte registratie. De basisregistratie is de elementaire bouwsteen van het Stelsel van Basisregistraties. Iedere basisregistratie bevat authentieke en meestal ook niet-authentieke gegevens. Een basisregistratie is dus geheel of gedeeltelijk een authentieke registratie en meestal ook deels een niet-authentieke registratie[2].

Basisregistraties[3]:

  • BRP - Basisregistratie Personen
  • BRI - Basisregistratie Inkomen
  • BAG – Basisregistratie Adressen en Gebouwen
  • BGT – Basisregistratie Grootschalige Topografie
  • BRK – Basisregistratie Kadaster
  • BRO – Basisregistratie Ondergrond
  • BRT – Basisregistratie Topografie
  • BRV – Basisregistratie Voertuigen
  • HR – Handelsregister
  • BRI – Basisregistratie Inkomen
  • WOZ – Basisregistratie Waardering Onroerende Zaken
Client-server architectuur Bij de client/server-architectuur bestaat een applicatie twee functies (2-tier), te weten de presentatie naar de gebruiker, de toepassingslogica van de feitelijke verwerking inclusief het datamanagement voor het raadplegen en muteren van gegevens in de database. Het systeem is operationeel in een enkel proces en bij iedere wijziging wordt de hele applicatie opnieuw gereleased in een nieuwe versie.
Common Ground Een ontwerp en veranderstrategie voor een nieuwe gemeenschappelijke gemeentelijke informatievoorziening. Daarbij wordt uitgegaan van een radicale omkering: het bouwen van de digitale gemeente alsof geen rekening gehouden hoeft te worden met datgene wat er al is. Het volgt niet de traditionele top-down benadering van eerst uniformeren op procesniveau, invoeren en opschalen, maar bekijkt de opgave juist van een informatiekundige invalshoek.
Datamodel Met een datamodel wordt beschreven hoe de gegevens in een informatiesysteem gestructureerd zijn. Het logische datamodel beschrijft de structuur van, en de relaties tussen, de logische gegevensobjecten (tabellen).
Doelbinding Het principe dat iemand (persoon of organisatie) alleen informatie mag vragen, opslaan, gebruiken, delen ten behoeve van welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden.
Domeinapplicatie Een afgebakende groep bedrijfsfuncties die in de gemeentelijke praktijk vaak in samenhang worden ingericht en gebruikt.
Functiegebied Een logisch samenhangend onderdeel van een architectuur laag waarmee een specifiek deel van de voorzieningen van die architectuur laag wordt gerealiseerd
Gegevenslandschap Alle (gedigitaliseerde) gegevens en informatievoorziening die een overheid voor het primaire proces nodig heeft
Gegevensmagazijn Het geheel van gegevens dat gebruikt wordt voor de ondersteuning van de processen in de digitale loketten.
GEMMA Referentiecomponenten Een modulair, zelfstandig inzetbaar en vervangbaar deel van een systeem, dat zijn functionaliteit aanbiedt via goed gedefinieerde interfaces. Applicatiecomponenten stellen functionaliteit beschikbaar, die gebruikt wordt om de systeemdiensten mee te leveren.
Informatiemodel Een informatiemodel vormt de formele beschrijving van alle informatie die van belang is binnen een gegeven domein. Een informatiemodel beschrijft dit domein in termen van objecten, gegevens (attributen) daarvan en relaties daartussen en doet dat op een inhoudelijke manier.
JavaScript Object Notation (JSON) JavaScript Object Notation, is een gestandaardiseerd gegevensformaat. JSON maakt gebruik van voor de mens leesbare tekst in de vorm van data-objecten die bestaan uit een of meer attributen met bijbehorende waarden. JSON wordt hoofdzakelijk gebruikt voor uitwisseling van data tussen server en webapplicatie, als een alternatief voor XML.
Kernregistratie Gemeentelijke en door college vastgestelde gegevens die breed binnen de gemeente worden gebruikt. Een kernregistratie kan aanvullende en actuele gegevens bevatten of andere gegevens om de werkzaamheden efficiënter te kunnen verrichten. Een bekend voorbeeld is de registratie van het aantal honden in een gemeente. De gegevens worden eenduidig en eenmalig ingewonnen voor meervoudig gebruik wat het uitwisselen en combineren van gegevens mogelijk maakt. De eigenaar is verantwoordelijk voor beschikbaarheid, integriteit, vertrouwelijkheid, volledigheid en kwaliteit.
Metamodel Informatie Modellering (MIM) Het MIM vormt een gemeenschappelijk vertrekpunt voor het maken van informatiemodellen, waarin duidelijke afspraken over het vastleggen van gegevensspecificaties op verschillende niveaus zijn beschreven. Bijzonder aan het model is dat de afspraken bestuurslaag overschrijdend gelden.
Representational state transfer (Rest) Representational state transfer (REST) is een software-architectuur voor gedistribueerde mediasystemen zoals het wereldwijde web. De term werd geïntroduceerd en gedefinieerd in 2000 door Roy Fielding in zijn doctoraatsstudie.
Sectorale registraties Binnengemeentelijk zoals:
  • Inkomen
  • Uitkeringen
  • Leerlingen
  • etc.

Buitengemeentelijk zoals:

  • Risicoregister gevaarlijke stoffen
  • Ruimtelijke plannen
  • Wkpb landelijke registratie
  • Innen eigen bijdrage Wmo en Wtcg (CAK)
  • KLIC-service - Kabels en Leidingen
  • Nationaal Parkeer Register
  • PIVA - Persoonsinformatie-voorziening Nederlandse Antillen en Aruba
Silo applicatie Een informatiesysteem waarin functionaliteit en gegevens onlosmakelijk verbonden zijn aan elkaar. Elk silo applicatie hanteert zijn eigen gegevensmodel en slaat deze op in een eigen database. Kopieën van gemeenschappelijke organisatiegegevens worden in de silo database opgeslagen. Functionaliteit en gegevens zijn onlosmakelijk verbonden aan elkaar. Silo applicaties worden vaak aangeschaft bij een pakketleverancier.
Service Oriented Architecture (SOA) Een architectuurmodel, geen technologie op zich. Centraal bestaat een SOA-systeem uit servicecontracten. Hierbij is sprake van leveranciers en afnemers van diensten. De technologische benadering van SOA is om platformonafhankelijke communicatie te bewerkstelligen. Door de beschreven principes van de services wordt het veel eenvoudiger om services te veranderen en nieuwe varianten te combineren zonder consequenties voor andere onderdelen. Services vormen ontkoppelpunten binnen bedrijfsprocessen.
Standaard Uitwisseling Formaat (StUF) StUF is een berichtenstandaard en bevat de afspraken over de basisprincipes voor het uitwisselen van gegevens tussen applicaties in het gemeentelijke veld.
Thema-architectuur Common Ground De Thema-architectuur Common Ground is een informatiearchitectuur die een gelaagd model beschrijft voor het scheiden van processen en gegevens en het ‘bij de bron’ kunnen bevragen van gegevens. Het werkt dit lagenmodel verder uit in benodigde functies, patronen en best practices. De uitwerking van de thema-architectuur Common Ground is in lijn met de visie van de Common Ground-beweging. De binnen Common Ground gehanteerde vijf-lagen-applicatiearchitectuur is in de thema-architectuur Common Ground geadopteerd en verdiept.
  1. een logisch samenhangend onderdeel van een architectuur laag waarmee een specifiek deel van de voorzieningen van die architectuur laag wordt gerealiseerd
  2. Bron: https://www.noraonline.nl/wiki/Basisregistratie
  3. Bron: https://www.digitaleoverheid.nl/dossiers/basisregistraties/
Deze pagina is voor het laatst bewerkt op 21 mei 2024 om 15:44.