De softwarecode van de Basisregistratie Personen (BRP) blijkt dit jaar in alle stilte te zijn vernieuwd. De codegeneratoren, waar auditor KPMG zware kritiek op had, blijken te zijn vervangen door met de hand geschreven Java-code. Wat de extra kosten en de projectvertraging hiervan zijn en of de code doet wat de BRP moet doen, is onduidelijk. Ingrid de Caluwé, Tweede Kamerlid van de VVD, heeft hierover vragen gesteld aan minister Ronald Plasterk van Binnenlandse Zaken en Koninkrijksrelaties (BZK). Zij wil nog voor het kerstreces opheldering.
De Caluwé wil bijvoorbeeld van de bewindsman weten welke verbeteringen hij verwacht na het besluit tot uitfasering van de codegeneratoren, wat dit extra gaat kosten en hoeveel vertraging de ‘Operatie BRP’ door de codevervanging oploopt ten opzichte van de eerder gestelde opleverdatum in 2018.
Zij verbaast zich er bovendien over hoe het komt dat de minister tijdens het debat over de begroting BZK voor 2017 heeft aangegeven dat de uitfasering van de codegeneratoren mogelijk tot uitloop en tot extra kosten kan leiden, terwijl dit in de voortgangsrapportage april-oktober 2016 (Kamerbrief van 25 november 2016, Kamerstuk 27 859-97, met bijlagen) nog niet is vermeld.
Skelettransplantatie
De Caluwé heeft de Kamervragen ingediend naar aanleiding van het opiniestuk Een skelettransplantatie voor de BRP van ict-overheidsexpert René Veldwijk. In zijn stuk schetst Veldwijk een ontluisterend beeld van de gang van zaken vanaf 2010 rond de herbouw van de Basisregistratie Personen (BRP), die in eerste instantie nog mGBA heette (modernisering Gemeentelijke Basisadministratie). In zes jaar tijd blijkt het projectbureau drie keer opnieuw met de herbouw te zijn begonnen. In 2013 bleek het herbouw-budget van 44,5 miljoen euro al op; Plasterk koos toen voor een doorstart met dertig miljoen extra budget en drie jaar extra doorlooptijd. Begin dit jaar besloot hij naar aanleiding van een advies van het Bureau ICT Toetsing (BIT) Operatie BRP met negen maanden uit te stellen. Gevolg: een extra kostenpost van 8,6 miljoen euro.
In 2018 zou de BRP operationeel moeten zijn. Maar, stelt Veldwijk, nu het software-skelet van de BRP tussen december 2015 en september 2016 weer volledig blijkt te zijn vervangen – een complexe operatie – is het aannemelijk dat de BRP niet in 2018 wordt opgeleverd; sterker nog, hij verwacht dat de BRP zoals voorzien er in het geheel niet gaat komen.
Refactoring
De Tweede Kamer is over de ‘skelettransplantatie’ weliswaar op 25 november middels een brief op de hoogte gesteld, maar daarin gebruikt BZK eufemismen als dat de code is ‘ge-refactored’ en dat deze ‘refactoring’ in twaalf weken naar tevredenheid is afgerond.
VVD-Kamerlid De Caluwé prikt hier wèl door heen en wil nu van minister Plasterk weten wat zijn oordeel is over de in het artikel van Veldwijk getrokken conclusie dat ‘bij het uitfaseren van de codegeneratoren in feite het gehele skelet van het BRP-systeem in ontwikkeling is vervangen.’
BIT genegeerd
Ook stelt zij de bewindsman de vraag waarom in de voortgangsrapportage BRP de uitfasering van de codegeneratoren wordt gepresenteerd als een logische stap in het project en een verbetering. Dit, terwijl het in feite een wezenlijke wijziging van het project behelst en het gevolg is van het niet voldoen aan de kwaliteitseisen van auditor KPMG.
De Caluwé plaatst tevens kanttekeningen bij hoe er is omgegaan met het eerdere advies en de aanbevelingen van het BIT. Zij vraagt: ‘hoe past de uitfasering van de codegeneratoren in de afspraak met de Kamer – op basis van het overgenomen advies van het BIT – dat nieuwe wijzigingen pas worden doorgevoerd nadat het huidige (lees d.d. oktober 2015) programma Operatie BRP is afgerond en alle GBA-aansluitingen zijn uitgefaseerd?’
Lappendeken
Zij wijst er daarnaast fijntjes op dat in de bijlage bij de Kamerbrief van 25 november 2016 onder punt negen ‘Status implementatie aanbevelingen BIT’ staat vermeld dat er wijzigingen in het project zijn uitgevoerd op verzoek van de Kamer. Alleen wordt hier niet de uitfasering van de codegeneratoren als wijziging vermeld.
Als laatste wil de VVD-politica van de minister weten wat zijn oordeel is over de ‘lappendeken’ van software, zoals Veldwijk vaststelt in het artikel, met de conclusie dat er straks een systeem staat dat al bij invoering zeer slecht onderhoudbaar zal zijn.
BRP
De Basisregistratie Personen (BRP) moet dé basisregistratie worden voor persoonsgegevens binnen het stelsel van basisregistraties bij de overheid. De hele Nederlandse overheid gaat de gegevens die in de BRP worden geregistreerd, gebruiken.
Lees ook het opinie-artikel van René Veldwijk: Een skelettransplantatie voor de BRP.
Soms begrijp ik dingen niet helemaal. Als een majeur project niet gaat zoals het moet, is het begrijpelijk dat je als toezichthouder wil weten wat er aan de hand is. Nu gaat een project blijkbaar wel goed; er ging iets stevig fout en de projectleiding heeft goed bijgestuurd. Waarom dan toch ingrijpen als toezichthouder? Dit lijkt meer op ‘de pers zoeken’ dan echt inhoudelijk toezicht houden.
Zo, de codegeneratoren zijn uitgefaseerd. Die gebruiken ze dus niet meer. Er wordt geen code meer gegenereerd. Een klein kunstje: een e-mail aan het hele team dat ze die dingen (Waren het er inderdaad twee of meer? Waarom dan?) niet meer mogen gebruiken en een opdracht aan de systeembeheerders om die dingen off-line te halen.
Maar dat de generatoren zijn uitgefaseerd zegt natuurlijk niets over de gegenereerde code. Deze is niet tegelijk automatisch verdwenen, toch? Nee, die code is vervangen, “gerefactord”.
Hier wringt iets.
Ze hebben, grof gesteld, codegeneratoren gebruikt gedurende bij elkaar een jaar of vijf, zes en nu zouden ze in twaalf weken de zaak gerefactord hebben – met de hand.
Als het waar is is het knap werk. Ongelooflijk knap. Dan verdienen ze de volgende Computable-award.
Maar is het waar? Vijf, zes jaar genereren levert een hoop code op. Is dat in twaalf weken met de hand te refactoren? Ik denk het niet.
Dus: óf de code die in de loop van vijf, zes jaar is gegenereerd stelde niet veel voor, óf maar een klein deel van de gegenereerde code is gerefactord.
In het ene geval hebben ze jaren lang geld zitten verbranden, in het andere geval zit het systeem nog vol met stukjes gegenereerde code. En die gegenereerde code wou men er juist uit hebben.
Doorvragen graag, mevrouw De Caluwé.
Dit gaat over de Basisregistratie Personen. Kan iemand mij uitleggen wat daar wel niet voor ingewikkelds in moet staan of mee moet gebeuren dat je er tientallen miljoenen voor kwijt bent om daar een database voor te ontwikkelen? En dan wordt er geschreven in Java???
Ik wil Veldwijk’s ‘skelet-analyse’ vooral lezen naast Plasterk’s kamerbrief, de Q3/Q4-voortgangsrapportage 2016 oBPR, het KPMG-onderzoek broncode BR augustus 2016 en het ICT-dashboard mbt. oBPR.
Dan zie ik volledig uiteenlopende belevingswerelden.
Dit lijkt meer een politieke actie van een VVD zijde die haar PvdA ‘partner’ in de schijnwerpers zet zo net voor de verkiezingen. Of ik ben te cynisch en is het De Caluwé te doen om een oprechte opheldering van dit verhaal te doen. In beide gevallen had Plasterk wat pro actiever en zo duidelijk mogelijk naar de 2e kamer moeten communiceren om zijn plannen bij voorbaat te vermelden. Een les die hopelijk voor zijn opvolger niet nog een keer geleerd moet worden.
Wat die technische kant betreft zijn generatoren een poosje hip geweest rondom die tijd toen dit project startte. Maar de techniek is niet stil blijven staan en is inmiddels verder waarbij wel is gebleken dat generatoren voor generieke zaken nog wel kan maar voor maatwerk vaak zo niet altijd niet specialistisch genoeg zijn. Bij de luchtmacht wordt overigens nog wel gebruik gemaakt van een generator.
Waarschijnlijk is bij de ‘re-factoring’ de gegenereerde code rechtgetrokken met zaken die de generator niet kon genereren. Dat houdt dan ook in dat je al die code niet meer her gegeneerd kan worden. Naar alle waarschijnlijkheid houdt dit dan ook in dat als de code niet zo generiek is dat er zeer speciale wensen zijn waardoor het geheel te ingewikkeld wordt. Vaak al een teken van een gebrekkige architectuur.
Dat er gebruik wordt gemaakt van Java is niet ongewoon want bij veel van dit soort projecten wordt er gebruik gemaakt van .Net of Java wat in technische zin geestverwanten zijn ontwikkeld door verschillende bedrijven.
Overigens ben ik zelf van mening dat all code van dit soort overheidsprojecten openbaar moet zijn voor inzage. Dat maakt de stap naar een open-source benadering van dit soort projecten dan ook makkelijker en kunnen al die externe ICTers die nu tijd over hebben ook meekijken en denken.
Volledig met Marc eens. Ik snap de commotie hier niet zo. Ook zie ik niet wat er mis is met Java voor een site, maar misschien zie ik iets over het hoofd.
@Technicus: Een Java front end is prima, maar ik zou de eigenlijke aansturing van de database en de business rules toch liever in een niet-script taal schrijven, als is het alleen maar vanwege de performance.
Verwarrend, ik zie in het artikel alleen Java genoemd worden en niet Javascript.
Ik weet het fijne er ook niet van, maar begrijp nog steeds de commotie niet.
Voor de beantwoording door Minister Plasterk van de kamervragen van De Caluwé over het artikel ‘Een skelettransplantatie voor de BRP’ zie :
https://www.rijksoverheid.nl/documenten/kamerstukken/2016/12/16/beantwoording-kamervragen-over-het-artikel-een-skelettransplantatie-voor-de-brp
Ondanks alle artikelen hierover zijn mij een paar zaken nog niet helemaal duidelijk:
– Hoe is de implementatiekeuze tot stand gekomen?
– Wie heeft de uiteindelijke beslissing genomen om dit soort maatwerk te gaan gebruiken?
– Waarom is er niet over de grens gekeken om te zien wat wel goed werkt?
– Waarom is er geen standaardsoftware overwogen voor het generieke gedeelte?
– Hoe kan het zijn dat dit hele project slechts 1 lead architect kende die, niet uitgedaagd door wat meer ervaren en up-to-date vakgenoten, jarenlang zijn gang mocht gaan?
– Hoe kan het zijn dat deze architect iets wat hij nog op de plank had liggen uit de jaren 80, een “soort black-box case-tool” tot de kern van de applicatie kon maken? En daarmee zijn klant tot in lengte van dagen afhankelijk maakt van zijn diensten?
– Hoe kan het zijn dat deze architect na enkele doorstarts nog steeds is verbonden aan dit project?
Mijn advies zou zijn om de zaak te bevriezen en over te gaan op een breed geadopteerde oplossing die zichzelf al in de praktijk heeft bewezen.