De eind vorige maand vrijgegeven broncode en bijbehorende functionele en technische documentatie van de programmatuur voor de Basisregistratie Personen (BRP) blijkt volgens ingewijden onvolledig. Ook zou er code zijn aangepast. Hergebruik is daardoor haast onmogelijk. Dat wat er door het ministerie van BZK op softwareplatorm Github is neergezet, geeft bovendien geen compleet beeld van wat er met de operatie BRP is bereikt. Dat is tegen de wens van de Tweede Kamer. De Operatie BRP (oBRP) werd in juli van dit jaar gestopt; kostenpost zo'n honderd miljoen euro.
Dit melden bronnen uit de hoek van de leveranciers die bij de oBRP waren betrokken en van het programma GVR (Gemeentelijke Verenigde Registratie van persoonsgegevens). Dit programma houdt zich onder de vlag van de Verenigde Nederlandse Gemeenten (VNG) bezig met een herstart van de stopgezette vernieuwing van de gemeentelijke basisadministratie, maar dan alleen onder gemeentelijke vlag.
De vorige minister van Binnenlandse Zaken en Koninkrijksrelaties (BZK), Ronald Plasterk, beloofde onder druk van de Tweede Kamer na zijn besluit de stekker uit de oBRP te trekken, om alle broncode – zowel de oude als de recente versies – vrij te geven. Zijn opvolger van de rijks-ict-portefeuille, staatssecretaris Raymond Knops, gaf eind november de meest recente versie van de BRP-broncode daadwerkelijk vrij op de site https://github.com/MinBZK.
Onbruikbaar
Volgens Swier Jan Miedema van automatiseerder Gemboxx, een aanbieder die veel geld heeft gestoken in een burgerzakenmodule voor de BRP, is dat hij wat aan code en documentatie heeft kunnen vinden op Github – in vergelijking met wat Gemboxx eerder in een testomgeving heeft kunnen raadplegen, en via een koppeling met de BRP heeft kunnen testen – bij lange na niet compleet. Er ontbreken belangrijke onderdelen als de database, migratie- en conversiesoftware, testsoftware, testgevallen en bijbehorende leeswijzers om de documenten te kunnen begrijpen, stelt Miedema (zie ook kader).
‘Als je de stukken goed leest zie je direct dat er kaderdocumenten ontbreken. Er wordt verwezen naar een stuk – een KORT-dossier – dat noodzakelijk is om de architectuur te begrijpen. Dat stuk is niet gepubliceerd’, aldus Miedema. Hij snapt niet waar BZK mee bezig is: ‘Eerder heb ik al beweerd dat Gemboxx zou kunnen bewijzen dat de BRP-software voor 80 procent klaar was en nu wordt ons de kans ontnomen dat te bewijzen.’
Vanuit het programma GVR komen er signalen dat slechts 5 procent van de broncode is vrijgegeven. Ook zouden diverse onderdelen van de broncode zijn verwijderd. Daardoor zijn deze niet meer te compileren en daardoor niet meer te gebruiken. Ook door het programmabureau GVR dat vooralsnog geen BRP-programmatuur van BZK overhandigd heeft gekregen. Opvallend is dat het ministerie de VNG of het Programmabureau GVR ook niet heeft ingelicht dat de broncode is openbaar gemaakt. Volgens ingewijden is de VNG ‘not amused’ hierover en tekent dit ook de huidige gespannen relatie tussen BZK en de VNG over hoe het nu verder moet met de vernieuwing van de gemeentelijke basisadministratie. Een zegsman van de VNG zegt later deze middag met een reactie te komen.
Incompleet beeld
Bovendien voldoet het ministerie met de onvolledige (en kennelijk aangepaste) broncode en documentatie niet aan de wens van de Tweede Kamer om een compleet beeld te geven van wat er door oBRP is opgeleverd en waar softwareleveranciers tegenaan hebben getest.
Een woordvoerder van het ministerie van BZK zegt pas vanmiddag of morgenvroeg met een reactie te kunnen komen. Aanstaande donderdag stond overigens in de Tweede Kamer een Algemeen Overleg op de rol over de Basisregistratie en paspoorten. Vandaag is besloten die een week te verschuiven.
Het verweer van BZK zou kunnen zijn dat dat er veel privacygevoelige informatie in de software aanwezig is. Volgens deskundigen is dit niet juist. Er zijn hele delen waar geen Burgerservicenummer of naam in staat; deze onderdelen zouden makkelijk openbaar kunnen worden gemaakt.
Omissies in de vrijgegeven broncode BRP
Wat ontbreekt er zoal naast de nu vrijgegeven broncode en bijbehorende functionele en technische documentatie van de programmatuur voor de Basisregistratie Personen (BRP) op softwareplatform Github:
– Migratiesoftware. Zie bijvoorbeeld dit volgende document op Github. Op pagina 46 staat een serie mappen genoemd die niet in de publicatie zitten.
– De deployment- en distributiemodules missen. Zie de onderstaande foutmelding als je de code probeert te compileren:.
Project: nl.bzk.brp:operatie-brp:145.3
Locatie: xxx/GIT/OperatieBRP/Broncode/operatiebrp code-145.3/pom 08.17.42.xml
Problems: Module ‘deployment’ not found
Module ‘distributie’ not found
Module ‘migratie’ not found
– Het ontbreken van testcode en testgevallen. De daarvoor gegeven reden is dat dit mogelijk privacygevoelige data bevat. Dit terwijl het project niet met productiedata aan het testen was. Het niet publiceren van deze testgevallen is ook in tegenspraak met de richtlijnen van de RIVG over allerlei testgevallen met syntethische data. De testgevallen voor de BRP zijn niet anders verlopen .
– Het ontbreken van alle testdocumentatie. Zie deze beschrijving.
– Het ontbreken van documentatie, zoals zogeheten kaderdocumenten waaronder het KORT-dossier. Het ‘KORT – dossier 9 (Operatie BRP)’ beschrijft welke kaders onderkend zijn, waar ontwerpbesluiten gedocumenteerd staan, welke concrete requirements onderkend worden en op welke wijze de traceerbaarheid geregeld is. Het requirementsdossier (Operatie BRP) geeft een volledige opsomming van alle kaderdocumenten met per document een beknopte toelichting. Zie hiervoor deze PDF op Github.
– het ontbreken van het BRP Meta-register. Meer informatie over dit objecttype is te vinden in deze PDF op Github.
– Het ontbreken van releasenotes
– Het ontbreken van het berichtenmodel BRP. De toelichting staat er wel, maar het model zelf niet:
– Tot slot ontbreken er handleidingen voor het installeren omdat BZK ook de intentie bij het vrijgeven heeft uitgesproken dat de code beschikbaar gemaakt is om hergebruikt te worden
Waarom wordt hier fout op fout gestapeld? Waarom wordt dit geaccepteerd? Moet er soms iets of iemand beschermd worden? En nee, ik bedoel daarmee niet de burgers.
Als je ietwat in die richting wil denken kan het heel goed zijn dat er verschillende op het ministerie moeten worden beschermd, cq afgedekt. Immers, heb je niet de kennis en kunde zaken in te zien, dan heb je het inktzwarte scenario van mensen die niet kunnen controleren wat een leverancier doet. Je krijgt dan het beeld dat je leveranciers hebt die niet hebben weten te leveren en een situatie, zoals een Gemboxxx die hard achter de feiten aan aan het hollen is.
Hoe het ook zij, het idee dat de hele broncode werkelijk vrij zal komen heb ik persoonlijk niet. Daarvoor is de zaak en situatie veel te complex geworden.
Ik vond het al zo karig voor 100 mio.
De meest heftige persoonsgegevens in ontwikkelcode zijn namen en/of e-mail adressen van ontwikkelaars. Deze kunnen zijn verwijderd voor vrijgave – dit kan ik billijken. Testgevallen met echte persoonsgegevens lijkt me niet aanbevolen en zou -hoewel dit in de praktijk meer dan eens voorkomt- getuigen van beperkte professionaliteit.
Database code (structuur plus vulling referentietabellen) is wel aanwezig.
Migratie- en conversiesoftware, testsoftware, testgevallen niet, maar dit zie ik meer als “perifere code”: niet nodig om de applicatie, mits de primaire code compleet is, te compileren en tot leven te brengen.
We zijn benieuwd naar de toelichting van BZK morgen…
Het is de vraag of hier doorgezet gaat worden. Want je kan er vergif op innemen dat van die 5 dan maar 10% wordt gemaakt en ze dan weer eens kijken of ze er mee weg komen. Dan is er zoveel tijd gerekt dat de hoogvliegers met de noorderzon zijn vertrokken en het laaghangend fruit met de gebakken peren blijft zitten. (Zit teveel in de Sinterklaas modus denk ik)
Mijn dunk van de minister Ollongren is nog minder als die van Plasterk dus dat het goed gaat komen lijkt mij minimaal.
Het moet nog worden uitgebreid, maar in ieder geval is het logisch ontwerp al wel verhelderend. Ik weet nu in ieder geval wel waarom René Veldwijk zo kritisch was. Er staat expliciet in hoe met correcties wordt omgegaan, en dat is vanuit databaseperspectief niet best. Correcties met terugwerkende kracht zijn namelijk opgelost met extra velden in plaats van een correcte tijdsbehandeling.
Of dat echt zo in de database is gekomen, uiteindelijk, kunnen we echter niet meer zeggen. Dan moet toch eerst het logisch datamodel worden gepubliceerd. Of ik duik in de database code :/
Overigens: het Logisch Ontwerp is bijzonder goed leesbaar, behoorlijk compleet en heel helder. Het maakt de complexe zaak heel helder. Het zou de Kamerleden sieren als ze het ontwerp zelf ook eens doorlazen, om te zien wat voor moeilijkheden ontstaan als je een paar eeuwen aan niet-afgestemde wetgeving moet gaan zitten automatiseren, zonder dat de subject-matter expert tijd voor je heeft. Ik begreep dat er twee jaar lang geen tijd was om met de bouwers te praten… tjsa.
Je mag de bouwers verwijten dat ze toen de juiste conclusie niet hebben getrokken en zijn vertrokken. Je mag de opdrachtgever verwijten dat die toen de stekker er niet uit trok. Beide partijen hadden fors wat boter op hun hoofd.
Alleen de analyses en requirement publiceren is voldoende. Gebruik vervolgens een bewezen codegenerator om de functionaliteit te bouwen (bv Outsystems). De code is al verouderd voordat het ooit in productie is geweest.