developer.overheid.nl

Toegegeven, het is een beetje een melodramatische quote. Maar ik vond hem toepasselijk voor het thema van deze blogpost. Deze blogpost gaat namelijk over effectiever bijdragen aan een betere digitale overheid. De originele quote is van niemand minder dan J.F. Kennedy en komt uit zijn inauguratie-speech uit 1961. Met recht een andere tijd en plaats.

Mijn inspiratie voor deze blogpost kreeg ik toen ik een paar weken terug mijn zoontje de fles aan het geven was op een nachtelijk uurtje, en me de volgende vraag overviel:

Schematisch beeld van de event-driven overheid

Steeds meer overheidsorganisaties stappen over naar eventgedreven architecturen (EDA). Waarom? Omdat het beter schaalbaar is, sneller reageert op veranderingen en beter past bij een moderne digitale overheid waarin systemen onderling proactief samenwerken op basis van gebeurtenissen, in plaats van reactieve vraag-antwoordstructuren. In dit artikel duiken we in de kern van EDA binnen de Nederlandse overheid en bespreken we Stelsels, Standaarden en Voorzieningen als CloudEvents, Webhooks, DigiLevering en DigiMelding.

Binnen de Nederlandse overheid zijn DigiD, eHerkenning en eIDAS al jaren de ruggengraat van digitale identiteit en toegang. Ze zijn betrouwbaar, veilig, bewezen en breed ingezet door heel Nederland heen. Tegelijkertijd stoelen deze voorzieningen op een technische basis die steeds minder goed afgestemd is op hoe we vandaag digitale diensten bouwen: SAML 2.0.

Eerlijk is eerlijk, SAML werkt. Het is veilig, veel klassieke webapplicaties zijn erop ingericht om het te ondersteunen en de techniek is door de experts echt goed begrepen. Maar er schuurt wel wat. Ontwikkelaars en beheerders ervaren het vaak als lastig te implementeren en te testen, de uiteenlopende manieren waarop de eHerkenningsmakelaars de standaard implementeren compliceert aansluitingen en updates en het is lastig te combineren met moderne security-patronen zoals “zero trust”. SAML is in de kern ontworpen voor browser-based SSO, niet voor API beveiliging. Voor organsaties die richting API-first architectuur, mobiele apps en microservices bewegen is er echter een passend alternatief: OpenID Connect, ofwel OIDC.

Buiten de Rijksoverheid is het gebruik van (REST) APIs voor het ontsluiten van informatie al jaren gemeengoed. Binnen de Rijksoverheid en specifiek binnen Justitie en Veiligheid neemt de inzet van (REST) API's de afgelopen jaren toe. Zo hebben we als Justid in 2024 de Gouden API gewonnen voor onze CPA Register API en in 2025 de Zilveren API voor de API van het Centraal Digitaal Depot (CDD+).

Als je je ontwikkelproces wilt verbeteren zijn er veel standaarden en raamwerken beschikbaar. Eén van de bekendere is de Plan-Do-Check-Act (PDCA) cyclus om continue verbetering te realiseren:

• Tijdens de Plan-fase stel je verbeterdoelen en ontwerp je een nieuwe versie van je proces.
• Tijdens de Do-fase probeer je het nieuwe proces uit.
• Vervolgens evalueer je tijdens de Check-fase de resultaten van het nieuwe proces tegen de gestelde doelen.
• Als de nieuwe processen de gestelde doelen halen neem je die tijdens de Act-fase in gebruik.

Nu heb je een betere versie van je proces en kun je de cyclus opnieuw uitvoeren. Tenminste, dat is het idee. In de praktijk van softwareontwikkeling is de PDCA-cyclus nog niet zo eenvoudig uit te voeren. Het ontwerpen van een nieuw proces leidt al snel tot big-design-up-front en wensdenken. Een enkel softwareontwikkelproject kan lang duren waardoor resultaten lang op zich laten wachten. Nieuwe processen implementeren is sowieso ingewikkeld. En, of een nieuw proces werkt of niet is lastig te evalueren als je organisatie een diverse portfolio aan applicaties en projecten heeft.

Er is echter een pragmatisch alternatief: Do-Describe-Check-Act.

Binnen modern web-development zijn er veel processen waarbij we NPM-packages gebruiken. De meest herkenbare verschijningsvormen van NPM-packages zijn libraries en frameworks, maar in de afgelopen jaren is het scala behoorlijk uitgebreid.

In veel codebases zie je ook: linters , test-engines, type-definitions en CLI-tools. Deze groei is verklaarbaar maar zorgt wel voor een stijging van het aantal dependencies binnen projecten. En dat zorgt weer voor problemen als: de welbekende dependency-hell, grote hoeveelheden onderhoudswerk en trage transpile-processen.

In deze post duiken we wat dieper in het NPM-ecosysteem en lees je hoe je bovenstaande problemen kunt voorkomen.

Het Open Geospatial Consortium (OGC) is een internationale standaardenorganisatie. Hier komen onder andere de OGC API standaarden vandaan: gestandaardiseerde REST APIs die ervoor zorgen dat geodata op een universele manier geserveerd en gebruikt kan worden. Regelmatig organiseert het OGC code sprints: hackathons van drie dagen waar standaarden-experts en ontwikkelaars de OGC standaarden implementeren in software. De OGC standaarden die geimplementeerd worden zijn dan meestal nog in draft; wel stabiel, maar nog niet officieel goedgekeurd. Op basis van de feedback van ontwikkelaars kunnen OGC standaarden-experts meteen de standaarden verbeteren en aanvullen. Zo wordt het ontwikkelen van standaarden net iets meer agile.

De Nederlandse overheid publiceert een deel van haar broncode als vrije opensource software. Om software te beheren is een versiebeheersysteem nodig. Hiermee kun je veranderingen in de broncode traceren en beheren. Een versiebeheersysteem faciliteert ook het samenwerken tussen verschillende software-ontwikkelaars. Een gedistribueerd versiebeheersysteem maakt het mogelijk dat ontwikkelaars op verschillende locaties toch kunnen samenwerken aan één softwareproduct. Het de facto versiebeheersysteem voor software is Git. Git is vrije opensource software. Voor een interessante en leerzame introductie in Git zie deze presentatie.

Er zijn online platforms die werken met Git, en die daaromheen toegevoegde functionaliteit bieden om softwaredevelopment en projectmanagement met Git te ondersteunen. Ik gebruik hieronder de term Git-forge (Git-werkplaats) om zulke platforms aan te duiden. GitLab, Forgejo en GitHub zijn allemaal Git-forges.

In deze blog ga ik in op een aantal aspecten van verschillende Git-forges, om zo de beste keuze voor een Git-forge voor de overheid te kunnen maken.

Hoe bouwen we binnen de overheid software die betrouwbaar, open en herbruikbaar is en goed aansluit op standaarden en beleid?

Tijdens zoBouwenWijSoftwareBijDeOverheid laten we zien hoe we dat in de praktijk doen. Op dinsdag 16 december 2025 nodigen we je uit bij Dev.loer in Utrecht voor een inspirerende en vooral hands-on middag. Samen met developers, product owners en technische leads van verschillende overheden ontdek je hoe bestaande tools, richtlijnen en kennisplatforms je direct kunnen helpen bij jouw softwareprojecten.

Ken je dat? Je gaat aan een nieuw project beginnen en dan vraagt iemand 'Doen jullie wel Privacy by Design?'

Uiteraard is het belangrijk om bij de bouw van nieuwe software meteen te denken aan privacy – en ook aan security, toegankelijkheid en mogelijk meer. Maar hoe past dat binnen een moderne, agile werkwijze?

In vroeger tijden, toen complete, gedetailleerde ontwerpen werden gemaakt nog voor er een letter geprogrammeerd was, konden die ontwerpen vooraf aan al deze eisen getoetst worden. In theorie dan, want onder tijdsdruk kwam het daar veel te vaak niet of onvoldoende van. Of de wereld was alweer veranderd tegen de tijd dat de software in productie ging.