De opdracht luidt vaak: maak deze applicatie geschikt voor Common Ground. Daarna begint het zoeken naar wat dat betekent voor de code, de database en de koppelingen die er al zijn.
Common Ground is de informatiekundige visie waarmee Nederlandse gemeenten en de VNG hun informatievoorziening anders inrichten. Gegevens komen los te staan van de applicaties en processen die ze gebruiken, en ze worden meervoudig gebruikt bij de bron. Het vijflaagsmodel uit GEMMA vertaalt die visie naar architectuur.
Hieronder lees je wat de vijf lagen concreet betekenen voor de software die je laat bouwen of aanpast: waar je data leeft, hoe je die ontsluit via API's, wat er gebeurt met je bestaande maatwerkapplicatie, hoe je koppelt aan Open Zaak en welke vragen je je leverancier stelt.
Wat Common Ground is en waarom er vijf lagen zijn
Gemeenten, ketenpartners, marktpartijen en de VNG werken samen aan Common Ground. Twee uitgangspunten dragen het geheel. Gegevens worden gescheiden van de applicaties en processen waarin ze gebruikt worden, en gegevens worden meervoudig gebruikt bij de bron.
Uit die twee uitgangspunten volgen vier afspraken over de uitvoering. Partijen sturen op gestandaardiseerde informatiemodellen per domein. Ze stellen databronnen beschikbaar via gestandaardiseerde API's. Ze zorgen samen voor één gestandaardiseerd uitwisselmechanisme. En gegevens blijven bij de bron, waar de bronhouder eigenaar blijft van de verzameling.
Het vijflaagsmodel is het hulpmiddel om die afspraken als architectuur op te schrijven. VNG Realisatie omschrijft het model als een hulpmiddel om de informatiearchitectuur te beschrijven die nodig is voor realisatie van de visie. De indeling in lagen laat zien welke functies bij het uitvoeren van processen horen en welke bij het vastleggen en verstrekken van data. Voor een bouwteam is dat de kern: je weet per stuk functionaliteit in welke laag het thuishoort en met welke andere laag het praat.
De vijf lagen van Common Ground op een rij
Van onder naar boven ziet het vijflaagsmodel er zo uit.
- Databronnen. Generieke functies om data vast te leggen en te ontsluiten, bij voorkeur gestandaardiseerd en passend binnen wet en regelgeving. Hier leven de gegevens zelf.
- Diensten. Generieke functies om diensten te leveren aan afnemers. GEMMA onderscheidt systeemdiensten, procesdiensten en gemaksdiensten. Deze laag maakt data uit de databronnen bruikbaar voor anderen.
- Connectiviteit. Generieke functies die afnemers in staat stellen gebruik te maken van de diensten van aanbieders. In de praktijk heet deze laag ook de integratielaag.
- Procesinrichting. Generieke functies om processen aan te sturen en data te analyseren. Hier zit de logica van een aanvraag, een controle of een besluit.
- Interactie. Generieke functies die gebruikers verantwoord toegang geven tot de gemeentelijke informatievoorziening. Denk aan schermen voor medewerkers en portalen voor inwoners en bedrijven.
De lagen werken los van elkaar en zijn tegelijk sterk verbonden. Een dienstenafnemer levert de interactie en de procesinrichting. Een dienstenaanbieder levert de diensten waarmee die afnemer bij de data komt. Dat onderscheid bepaalt straks ook wat je van welke leverancier vraagt.
Waar je data leeft en hoe je die ontsluit
De eerste vraag bij elke applicatie is welke rol ze speelt. Is je applicatie de bron van bepaalde gegevens, dan hoor je in de onderste twee lagen thuis en stel je die gegevens beschikbaar via een gestandaardiseerde API. Gebruikt je applicatie gegevens waarvan een ander de bron is, dan ben je afnemer en verandert wat nu in een eigen tabel staat in een aanroep bij die bron.
Voor je database betekent dat drie dingen. Kopieën van gegevens van een andere bron verdwijnen of worden een cache met een duidelijke houdbaarheid. Gegevens waarvan jij de bron bent, krijgen een eigen informatiemodel en een API die daarbij past. En elk gegeven krijgt één plek waar het ontstaat en wijzigt.
Voor de API zelf gelden de NLGov REST API Design Rules die Logius beheert. Die staan op de lijst met verplichte open standaarden van Forum Standaardisatie, dus je bouwteam ontwerpt de API naar die regels in plaats van naar eigen inzicht. Hoe een koppeling technisch in elkaar zit, met endpoints, notificaties en foutafhandeling, staat in ons artikel over de API koppeling. Onze werkwijze voor ontwerp en documentatie staat op de pagina over API development.
De derde laag regelt hoe je bij diensten van andere organisaties komt. Daar geldt sinds 2025 Federatieve Service Connectiviteit als standaard, kortweg FSC. De Programmeringsraad GDI wees FSC in december 2024 aan als standaard. Het is de opvolger van NLX en wordt beheerd door Logius, Stichting RINIS en de VNG. Versie 2.0 is opgenomen in de Digikoppeling release van 21 april 2026. Voor je eigen applicatie betekent dit dat verbindingen met andere organisaties via één uniforme manier lopen in plaats van per partij apart ingericht.
Wat de vijf lagen betekenen voor je bestaande maatwerkapplicatie
De meeste applicaties die nu bij gemeenten draaien, vullen alle vijf de lagen tegelijk. Het scherm, de procesregels, de koppelingen en de opslag zitten in één codebase, en de gegevens staan in tabellen die alleen die applicatie kent. Zo'n applicatie hoeft niet weg voordat je aan Common Ground begint.
De praktische route loopt van onderaf. Begin met ontsluiten: bouw een API voor de gegevens waarvan jouw applicatie de bron is, met een informatiemodel dat aansluit bij de standaard voor dat domein. Haal daarna de procesregels uit de schermen, zodat de logica ook aanroepbaar is zonder dat er iemand op een knop drukt. Vervang als laatste de interactielaag, bijvoorbeeld door een portaal dat via dezelfde API's werkt als de medewerkersschermen.
Die volgorde heeft een reden. Zolang data en logica in elkaar grijpen, verplaats je bij elke schermwijziging ook bedrijfsregels. Zodra de onderste lagen aanroepbaar zijn, faseer je stukken van de oude applicatie uit zonder dat de dienstverlening stilvalt. Dezelfde aanpak gebruiken we bij het moderniseren van legacy systemen buiten de overheid: eerst de gegevens en de logica bereikbaar maken, daarna de buitenkant vervangen.
Koppelen aan Open Zaak en de zaakgerichte standaarden
Voor zaakgericht werken bestaat een eigen standaard van VNG Realisatie: de API's voor zaakgericht werken, afgekort tot ZGW. Versie 1.7 verscheen op 9 juni 2026. Versie 1.8.0 ligt als concept ter consultatie tot 23 september 2026. De standaard bestaat uit zes API's:
- Catalogi API voor zaaktypen en de bijbehorende metagegevens
- Zaken API voor zaken en hun verloop
- Documenten API voor documenten en informatieobjecten
- Besluiten API voor besluiten
- Autorisaties API voor rechten op alle API's
- Notificaties API voor gebeurtenissen waarop andere componenten reageren
Open Zaak is een veelgebruikte invulling van de onderste twee lagen: een datalaag en dienstenlaag die deze standaard implementeert. Het pakket is open source onder de EUPL, werd gebouwd door Maykin Media in opdracht van een groep gemeenten onder aanvoering van Dimpact, en wordt beheerd door de Open Zaak community met hulp van de Codebase Stewards van de Foundation for Public Code. Open Zaak biedt de Zaken, Documenten, Catalogi, Besluiten en Autorisaties API's; de Notificaties API loopt via het aparte Open Notificaties.
Twee eigenschappen verrassen bouwteams die hier voor het eerst mee werken. Autorisaties gaan per zaaktype, informatieobjecttype en besluittype, dus je applicatie krijgt gerichte toegang tot precies die typen die ze nodig heeft. Daarnaast vraagt de Notificaties API om gebeurtenisgestuurd denken: je applicatie abonneert zich op wijzigingen in plaats van de bron periodiek te bevragen. Beide keuzes horen in je ontwerp thuis voordat de eerste regel code geschreven wordt.
Wat je van je leverancier vraagt
Vraag om concrete bouweisen in plaats van een verklaring dat een pakket klaar is voor Common Ground. Deze vragen leveren bruikbare antwoorden op:
- Welke laag van het vijflaagsmodel vult dit product, en welke lagen laat het open voor anderen?
- Zijn alle gegevens die het product vasthoudt bereikbaar via een gedocumenteerde API die de NLGov REST API Design Rules volgt?
- Welke versie van de API's voor zaakgericht werken ondersteunt het product, en hoe snel volgt een nieuwe versie van de standaard?
- Ondersteunt het product FSC voor verbindingen met andere organisaties?
- Blijft er data in het product achter die eigenlijk bij een bron hoort, en wat gebeurt daarmee bij vervanging?
- Hoeveel werk is het om het product te vervangen zonder gegevens te verliezen?
Die laatste vraag zegt het meest. Een product dat netjes in één laag zit, is vervangbaar. Een product dat alle vijf de lagen stilletjes invult, bindt je vast aan de leverancier die het bouwde.
Wij bouwen al ruim dertig jaar maatwerksoftware en koppelingen, met 30+ engineers in Nijmegen en Sarajevo en 100+ projecten, volgens ISO 9001 en ISO 27001. Dat werk zit onder meer in een platform voor subsidieadministratie, in MRO software voor de luchtvaart en in RFID toepassingen in de supply chain. Andere domeinen dan de gemeentelijke praktijk, met dezelfde bouwvraag: gegevens bij de bron houden, ze ontsluiten via API's en een bestaande applicatie stap voor stap ontvlechten. Onze aanpak van koppelingen staat op de pagina over software integratie, en op de pagina voor overheid lees je in welke omgevingen we werken. Plan een gesprek als je wilt toetsen welke laag je het eerst aanpakt.
Veelgestelde vragen
Wat is Common Ground?
Common Ground is de informatiekundige visie waarmee Nederlandse gemeenten en de VNG hun informatievoorziening opnieuw inrichten. De twee uitgangspunten zijn dat gegevens gescheiden worden van de applicaties en processen waarin ze gebruikt worden, en dat gegevens meervoudig gebruikt worden bij de bron. Het vijflaagsmodel uit GEMMA beschrijft de architectuur die daarbij hoort.
Welke vijf lagen kent Common Ground?
Van onder naar boven: databronnen, diensten, connectiviteit, procesinrichting en interactie. De onderste twee lagen leggen data vast en ontsluiten die via API's. De connectiviteitslaag verbindt afnemers met aanbieders. De bovenste twee lagen sturen processen aan en bieden gebruikers schermen en portalen.
Moet je een bestaande maatwerkapplicatie vervangen voor Common Ground?
Dat hoeft meestal niet in één keer. De gangbare route begint met het ontsluiten van de gegevens waarvan de applicatie de bron is via een gestandaardiseerde API. Daarna maak je de procesregels aanroepbaar en vervang je als laatste de schermen. Zo blijft de dienstverlening draaien terwijl de applicatie in lagen uit elkaar gaat.
Wat is het verschil tussen Open Zaak en de API's voor zaakgericht werken?
De API's voor zaakgericht werken zijn de standaard van VNG Realisatie: een set specificaties voor onder meer zaken, documenten, catalogi, besluiten, autorisaties en notificaties. Open Zaak is software die deze standaard implementeert, open source onder de EUPL, en vult daarmee de databronnen en dienstenlaag van het vijflaagsmodel in.
