Globaal programma van eisen voor pakketsoftware

Inleiding

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

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

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

Common Ground

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

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. Het Programma van Eisen is gebaseerd op deze 5 lagen en de functiegebieden daarbinnen.

Architectuurlagen en Functiegebieden in het GEMMA Gegevenslandschap

De transitie

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

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

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

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.

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

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

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.

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Basisregistraties: 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.

De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.

Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Betekenisvolle gegevens.

Een samenhangende set Diensten, Bedrijfsobjecten en/of Representaties die onder in een Overeenkomst beschreven voorwaarden kan worden afgenomen.

Het proces van vaststellen van de vereiste betrouwbaarheid van informatiesystemen in termen van vertrouwelijkheid, beschikbaarheid en integriteit alsmede het treffen, onderhouden en controleren van een samenhangend pakket van bijbehorende maatregelen.

De eenheid van wezen, volkomen overeenstemming en gelijkheid. Dat wat uniek of eigen is aan iets of iemand. Het kan daarbij gaan om zowel personen als organisaties of landen.

De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.

Sjabloonoplossing voor de architectuur van een bepaald domein.

Systematische en meestal in een informatiesysteem opgeslagen beschrijvingen van instanties van concepten.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Het geheel van mensen, middelen en maatregelen, gericht op de informatiebehoefte van de organisatie.

Een systeem waarbinnen organisaties via afspraken, standaarden en/of voorzieningen samenwerken om bepaalde functionaliteit te realiseren.

Voor alle gevallen geldend, niet specifiek.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.

Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen.

Het geheel van voorzieningen dat nodig is om een land of organisatie, zoals een bedrijf of een instelling, goed te laten functioneren.

Een afgebakend gebied binnen gemeenten waarvoor specifieke beleidsmaatregelen, regels en verantwoordelijkheden gelden. De GEMMA en het Gemeentelijk GegevensModel gebruiken dezelfde, op IV3 gebaseerde, indeling.

Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.

Het verstrekken aan en ontvangen van gegevens tussen (informatiesystemen van) overheidsorganisaties onderling en (informatiesystemen van) andere organisaties of personen.

De actor of applicatie die iets afneemt dat door een aanbieder wordt aangeboden.

Gestructureerde beschrijving van de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid.

Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.

Interactie in de context van overheidsdienstverlening betreft de (digitale) gegevensuitwisseling en wisselwerking tussen burgers en bedrijven en de overheid(sorganisaties).

Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem.

Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. (Synoniem van: Data )

Metamodel voor het maken van informatiemodellen. (Synoniem van: Metamodel Informatiemodellering )

Een door de overheid officieel aangewezen registratie met daarin gegevens van hoogwaardige kwaliteit, die door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.

Een toegangspunt voor API's dat verzoekverwerking uitvoert op basis van gedefinieerd beleid inclusief authenticatie, autorisatie, toegangscontrole, SSL/TLS-offloading, routering en load balancing.

Interactie in de context van overheidsdienstverlening betreft de (digitale) gegevensuitwisseling en wisselwerking tussen burgers en bedrijven en de overheid(sorganisaties).

Reeks opeenvolgend uit te voeren activiteiten die bijdraagt aan een specifiek resultaat, zoals de levering van een Product of Dienst. (Synoniem van: Bedrijfsproces )

Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.

Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.

Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.

Mate waarin vertrouwen kan worden gesteld in een identificatiemiddel, gebaseerd op de mate van zekerheid waarmee attributen, identiteiten, identificatiemiddelen en/of bevoegdheden zijn vastgesteld.

Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).

Een samenhangend geheel van gegevensverzamelingen en de daarbij behorende personen, procedures, processen en programmatuur alsmede de voor het informatiesysteem getroffen voorzieningen voor opslag, verwerking en communicatie.

Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).

Identity and Access Management (IAM) is vrij vertaald het beheer om er voor te zorgen dat de juiste "identiteiten" (denk daarbij vooral aan personen of computers), voor de juiste redenen en op het juiste moment toegang krijgen tot de juiste faciliteiten.

De actor of applicatie die iets aanbiedt dat door een afnemer is af te nemen.

Afkorting voor de Representational State Transfer architectuurstijl voor gedistribueerde hypermedia systemen

JavaScript Object Notation (JSON) is een lichtgewicht, op tekst gebaseerd, taalonafhankelijk gegevensuitwisselingsformaat.

Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).

Groepering van services die aan afnemers worden aangeboden, met als doel het bevorderen van uniformiteit en efficiëntie binnen de overheid.

De door een aanbieder aan afnemers verstrekte gegevens over binnen zijn domein plaatsgevonden gebeurtenissen

Het bekend maken van de identiteit van personen, organisaties of IT-voorzieningen.

Systematische en meestal in een informatiesysteem opgeslagen beschrijvingen van instanties van concepten.

Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen.

Betekenisvolle gegevens.

In de informatica is een interface een gedeelde grens waarover twee of meer afzonderlijke componenten van een computersysteem informatie uitwisselen. De uitwisseling kan plaatsvinden tussen software, computerhardware, randapparatuur, mensen en combinaties hiervan.

Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).

Afkorting voor 'Standaard Uitwisseling Formaat': een berichtenstandaard met afspraken over de basisprincipes voor het uitwisselen van gegevens tussen applicaties in het gemeentelijke veld.

Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.

In de informatica is een interface een gedeelde grens waarover twee of meer afzonderlijke componenten van een computersysteem informatie uitwisselen. De uitwisseling kan plaatsvinden tussen software, computerhardware, randapparatuur, mensen en combinaties hiervan.

Een door de overheid officieel aangewezen registratie met daarin gegevens van hoogwaardige kwaliteit, die door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.

Een systeem waarbinnen organisaties via afspraken, standaarden en/of voorzieningen samenwerken om bepaalde functionaliteit te realiseren.

Gestructureerde beschrijving van de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid.

Extensible Markup Language (XML) is een standaard van het World Wide Web Consortium voor de syntaxis van formele opmaaktalen waarmee men gestructureerde gegevens kan weergeven in de vorm van platte tekst.

Een door een organisatie tot bronregistratie benoemde registratie. Kernregistraties zijn bronregistraties.

Een door een organisatie tot bronregistratie benoemde registratie. Kernregistraties zijn bronregistraties.

Een weergave van een bepaald onderwerp. Een architectuurmodel geeft een kleinschalige, vereenvoudigde en/of abstracte weergave van het onderwerp.