developer.overheid.nl

Standaarden zijn vaak technisch van aard. Ze zorgen voor interoperabele oplossingen die technisch op elkaar kunnen aansluiten. Als we kijken naar adoptie van standaarden, dan is dat vaak een soft verhaal: "Wat heb ik hieraan?", "Is het verplicht?", "Doen anderen het ook?". Dit soort vragen worden door verschillende persona's gesteld en elke persona vereist een andere aanpak om te overtuigen van het nut van een standaard.

Bij het bevorderen van adoptie van standaarden is het van groot belang dat de softe kant op orde is. De keuze om een standaard te implementeren heeft een grotere impact als een bestuurder die maakt, dan één individuele developer. Zelf doe ik mee aan de werkgroep "Adoptie van standaarden" binnen het Federatief Datastelsel (FDS), om te analyseren welke activiteiten nuttig zijn om adoptie te bevorderen.

24 april was ik bij de softlaunch van code.overheid.nl. Het is een project dat bij veel developers en organisaties aanslaat omdat elke developer een gitomgeving nodig heeft om überhaupt samen te kunnen werken. Sinds er veel aandacht uit gaat naar digitale soevereiniteit is de roep om een gezamenlijke gitomgeving alleen maar gegroeid, het werd steeds minder voordehandliggend om op Github te blijven.

Vanuit dit besef heeft OSPO BZK zich hard gemaakt voor de opzet van code.overheid.nl, in de vorm van een Forgejo instance.

Op 22 april hielden we onze eerste online update-sessie. In de geest van open source werken lieten we zien waar we mee bezig zijn, wat er is opgeleverd en wat er aan zit te komen. Dit is een samenvatting voor degenen die niet bij konden zijn.

Elke medewerker heeft een account.

Maar wie heeft er écht zicht op?

Bij Wigo4it liepen identity-gegevens jarenlang via Microsoft Identity Manager. Het werkte — maar het was ook handmatig werk, dubbele administratie en een sterke afhankelijkheid van één leverancier.

Op een gegeven moment vroegen we ons af: moet dit zo?

Wij maken dit soort afwegingen dagelijks in onze eigen operatie. En soms leidt zo'n vraag tot een concrete beslissing.

In dit artikel laten we zien hoe Wigo4it Microsoft Identity Manager verving door een leverancier-onafhankelijke synchronisatie tussen AFAS, Keycloak en Entra ID. Wat de aanleiding was, welke keuzes we maakten, wat we leerden — en waarom we Entra ID bewust niet overboord gooiden.

Na dit artikel kijk je anders naar cloudkeuzes, security en de rol van identity.

"I know kung fu." In The Matrix downloadt Neo een vechtkunst in zijn hoofd en is klaar om te gaan. In het echt werkt het anders. Als developer moet je allerlei standaarden en protocollen kennen, en dat kost uren lezen en uitzoeken. Maar je AI-assistant kan die kennis wel gewoon ingeladen krijgen. Op developer.overheid.nl experimenteren we met skills die overheidsstandaarden inladen in je AI-assistant.

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.