Een skelettransplantatie voor de BRP

De Kamer voorliegen als bewindspersoon heet een politieke doodzonde te zijn. Behalve dan als het over ict gaat. Maar wat er nu gaande is bij de herbouw van de Basisregistratie Personen (BRP) stelt eerdere ict-wantoestanden bij de overheid in de schaduw. Recent is men namelijk opnieuw begonnen met de bouw van de BRP. Voor de derde keer. En deze keer volledig in het geniep.

Even kort het geheugen opfrissen. Sinds 2010 is ons Ministerie van BZK bezig om een nieuwe bevolkingsadministratie te bouwen; voor de gemeenten en voor honderden overheidsorganisaties die betrouwbare persoonsgegevens nodig hebben. En dat lukt niet.

De eerste poging was tussen 2010 en 2013. Signalen dat het fout ging werden genegeerd. En toen was begin 2013 plots het budget van 44,5 miljoen euro op. Minister van BZK Plasterk haalde adviesbureau Gartner binnen. Gartner vroeg de programmeurs hoe ver ze waren en schreef op dat 32 procent van het systeem af was – codetaal voor een totale mislukking. Plasterk kon de stekker eruit trekken. Hij koos echter voor een doorschuifconstructie annex cover-up: het opnieuw beginnen (‘doorstarten’) met dertig miljoen extra budget en drie jaar extra doorlooptijd. Operationeel in 2018. Een politiek probleem werd zo afgekocht.  Als camouflage werd de naam ‘Modernisering GBA’ (mGBA) omgezet in ‘Operatie BRP’ (oBRP). De bestaande legacy GBA-systemen van Pink en Centric worden sindsdien aangeduid als ‘de BRP’. Een window-dressing klassieker.

Zoals elk groot ict project bij de overheid wordt ook de mGBA bemand door externen. Wat de mGBA/BRP bijzonder maakt is dat bij de doorstart in 2013 de topleiding (term: gedelegeerd opdrachtgever) óók in externe handen werd gelegd. De BRP-topbaas is sindsdien zzp’er Cor Franke, een ex-topambtenaar met een voorliefde voor hi-tech ict oplossingen en, heel opmerkelijk, een geheel BRP-loos LinkedIn cv.

Het generator-debacle: 2013 – 2016

Het gevolg van het zwakke ambtelijke management tijdens de pre-Franke periode had er toe geleid dat de inhoudelijke beslissingen werden genomen door een andere externe, lead architect. Deze zag veel herhalende patronen in de BRP-in-aanbouw en besloot om de benodigde programmacode automatisch aan te maken door middel van een door hemzelf te schrijven programmagenerator. De gewone programmeurs kregen als taak om maatwerk code te schrijven rond dit uitgegenereerde software-skelet.

Zijn generatoren zijn al in ontwikkeling als Franke aantreedt als puinruimer (Gartner noemt ze, maar mist de significantie). Franke besluit om lead architect carte blanche te geven. Dat kan, want geld en tijd zijn geen probleem meer en er zit nu eindelijk competent management. Hij is ook niet de eerste de beste. Hij heeft vijftien jaar gewerkt aan een eigen ontwikkeltool genaamd Cathedron. Het bouwen van een BRP-variant van Cathedron (in Delphi, op het Firebird dbms, executie at runtime) voor de BRP (in Java, op het Postgres dbms, generatie van broncode) mag redelijkerwijs geen probleem zijn. En staat het BRP-softwareskelet er eenmaal, dan is het afbouwen ervan een saaie en risicoloze klus.

Dit alles zou onder Plasterks pet zijn gebleven, ware het niet dat er een Kamerlid wakker was. VVD-backbencher Roald van der Linde (nr. 35 kieslijst TK 2017) vraagt bij de BRP-doorstart aan de minister om de BRP-broncode vrij te geven. Een verraste Plasterk stemt direct toe en Franke heeft het toekijken. Daarna begint het saboteren. Er wordt niets vrijgegeven. Anderhalf jaar, medio 2015, mogen geïnteresseerden kort in een afgesloten kamertje kijken naar Java-code, zonder enige documentatie of uitleg. Maar zelfs een korte blik is voldoende om een nieuw BRP-debacle in wording te zien. De broncode die wordt getoond is overduidelijk half gereed en niet executeerbaar en achter die code zien we de contouren van gammele generatoren. Wat we zien gaat nóóit werken en dat schijven we ook op in een Computable artikel:

‘Alarmbel 2 is dat het er alle schijn van heeft dat de generatoren nog niet af zijn. In onze lange loopbaan hebben wij een aantal keer dit soort projecten gezien (en één keer zelf uitgevoerd). De afloop is altijd rampzalig. Je moet nooit, echt nóóit zo dwaas zijn om generieke en specifieke software parallel te ontwikkelen. Het is voer voor eindeloze iteraties en intra-team-ruzies. Op zijn best zit je heel lang met onvolledige software en dat zagen we ook hier.’

Vijftien jaar in relatieve rust werken aan een Delphi-interpreter met twee man blijkt duidelijk iets anders dan met tientallen programmeurs tegelijk werken aan een Java code-annex-database generator en maatwerk code daaromheen. De zelfoverschatting van de lead architect en Frankes blinde vertrouwen komen het programma duur te staan.

De slapende Kamer: drie gemiste kansen

Tussen de herstart in 2013 en het heden zijn er drie momenten waarop Kamer of Kabinet hadden kunnen ingrijpen. Steeds gebeurt dat niet. De eerste keer is in oktober 2014 wanneer de Commissie Elias met haar rapport ‘Naar Grip op ICT’ zeven faalprojecten beoordeelt. Een van die projecten – en het enige dat nog niet was afgeblazen of in productie was gegaan – was de BRP. De Commissie schrijft de BRP totaal de grond in (tip: doorzoek het rapport op de term ‘mGBA’), maar trekt geen consequenties en adviseert niets.

Het tweede moment waarop had kunnen worden ingegrepen is in juni 2015 en de aanleiding is ons artikel over de code-inspectie. CDA-Kamerlid Mona Keizer (nr. 2 kieslijst) stelt dan verontruste mondelinge Kamervragen aan minister Plasterk. De reactie van de Excellentie van BZK is beschamend, maar ook effectief: in een een-tweetje met VVD-Kamerlid Ton Elias (onverkiesbaar) werd de boodschapper, schrijver dezes, als ‘niet de meest gezaghebbende persoon’ weggezet. Computable deed verslag, inclusief een link naar een video-opname van het gebeuren en een joktweet.

Het derde moment is de publicatie van een auditrapport van het Bureau ICT Toetsing (BIT) over het programma. Voorspelbaar genoeg ontpopt het BIT zich als schoothondje van de eigen minister. Het rapport had geschreven kunnen zijn door gedelegeerd opdrachtgever Franke zelf: ‘Of de Kamer zich in kan houden met de wetgeving want elke minimale wijziging kost miljoenen’. ‘De vertraging komt door héél moeilijke programmeerproblemen’ (die wel probleemloos worden ondersteund door de GBA-pakketten). ‘En die drie jaar extra tijd en dertig miljoen extra budget is ook te krap. Dus wil de Kamer even nog eens 8,6 miljoen budget lappen en negen maanden extra doorlooptijd geven aan de Franke en zijn mensen. En ondertussen rept het BIT met geen woord over de staat van de BRP-generatoren.

2015: KPMG plaatst een bom onder de BRP

De hulp van het BIT is nodig want met de systeemontwikkeling gaat het ondertussen niet beter. Bij een tweede software-kiekeboe-show in maart 2016 zien wij geen verbetering, wat ons toen verbaasde. Veel nuttiger zijn rapportages over de kwaliteit van de broncode die KPMG vanaf september 2014 begint te produceren. Natuurlijk zijn deze verhullend geschreven, maar voor de deskundige lezer is de boodschap duidelijk. In de eerste rapportage meldt KPMG bijvoorbeeld dat de generatoren alleen gebruikt zullen worden voor de initiële bouw van de BRP en niet voor het onderhoud – een veeg teken.  Omdat de gegenereerde code na implementatie dus moet worden onderhouden door mensen moet deze onderhoudbaar zijn. Dat is volgens KPMG niet het geval. Omdat KPMG de kwaliteit van alle broncode – gegenereerd of met de hand uitgekrast – geautomatiseerd controleert (met Sonarqube) besluit men om de gegenereerde code als ‘commentaar’ te behandelen. Dat legt natuurlijk een bom onder het werk van KPMG dat in de derde rapportage dreigend meldt:

‘Wij hebben begrepen [sic] dat het programma voornemens is om voor de definitieve oplevering de generatoren te verbeteren zodat daarna opnieuw de code wordt gegenereerd die dan aan de kwaliteitsdoelen voldoet.; 

KPMG gooit aldus een bom terug naar de programmaleiding: ‘die generatoren van jullie gaan wat ons betreft niet door als je geen onderhoudbare Java-code kunt genereren’. Het is dan december 2015. Franke en zijnlead architect zullen geen fijne kerstdagen hebben gehad.

Twee ingrijpende operaties

Na het december-2015 rapport van KPMG verdwijnt het onderwerp ‘software generatoren’ bijna een jaar lang uit beeld, tot oktober 2016, twee maanden geleden. Wie ook langdurig uit beeld verdwijnt is minister Plasterk zelf die een operatie moet ondergaan. Of hij door Franke is geïnformeerd over generatorproblemen is een open vraag, maar zeker is dat opdrachtgever Franke besluit om de codegeneratoren de deur uit te doen. Dat gebeurt in volledige stilte – in de vierde KPMG rapportage en de reactie van Franke daarop is het woord ‘generator’ niet te vinden. Maar dan komt op 4 oktober 2016 de vijfde rapportage van KPMG in de openbaarheid waarin opeens plompverloren wordt gemeld dat de generatoren zijn vervangen door met de hand geschreven Java-code.

De omvang van deze ingreep valt nauwelijks te overschatten. Het software-skelet van de BRP is tussen december 2015 en september 2016 volledig vervangen. Zo’n skelettransplantatie vergt grote en langdurige inspanningen. Dat we in maart 2016 oude software te zien kregen wordt opeens begrijpelijk. Of de skelettransplantatie überhaupt is voltooid is ook allerminst zeker, want KPMG rapporteert alleen over de kwaliteit van de code. De opdracht aan KPMG is listig geformuleerd: alleen de kwaliteit van de code telt en niet of die code doet wat de BRP moet doen.

Hoe wordt wat er is gebeurd verteld aan de Kamer? Met smoke and mirrors. In een Kamerbrief wordt eind november gemeld dat de code is geherstructureerd: ge-refactored. ‘Refactoring’ is op zijn best een misleidend eufemisme. Er is veel nieuwe code met het handje geschreven en oude maatwerkcode is daar tegenaan geplakt. In de bijlage bij de Kamerbrief wordt ons ook op de mouw gespeld dat het allemaal in twaalf weken is gebeurd, dat de kwaliteit nu bijna oké is en dat de verloren tijd natuurlijk gaat worden ingehaald. Yeah sure. We kunnen niet wachten tot het BRP-kastje in het voorjaar van 2017 weer twee uurtjes open mag.

De BRP 3.0: Lappendeken-systeem en Omerta-project?

Gesteld dat de derde BRP-bouwronde is geslaagd (of gaat slagen) zou je kunnen stellen dat de kans op een goede afloop van het programma in 2018 nu is toegenomen. Immers, de generatoren waren kansloos en ambachtelijk handwerk is dat niet. Maar natuurlijk is er net als in 2013 geen sprake van herbouw from scratch, maar van een mix van software-herbouw en software-quiltwerk. BRP versie 3.0 van Franke en zijn lead architect is vermoedelijk een software lappendeken, een coat of many colors’. Typerend voor dergelijke systemen is dat ze al bij de invoering zeer slecht onderhoudbaar zijn, al zal men natuurlijk om de KPMG-softwaremetrieken heen programmeren.

Maar de techniek is niet eens de grootste bedreiging. Dat de kans op een slechte afloop ook na de derde bouwronde nog levensgroot is, is vooral een zaak van cultuur. Het programma mGBA/BRP loopt nu ruim zes jaar en hangt al die tijd van leugens aan elkaar. Wie met dit soort programma’s te maken heeft gehad weet dat de nette professionals in stilte vertrekken en de meepraters en overlevers blijven zitten. Dergelijke omerta-projecten hebben de vervelende gewoonte dat ze nooit stoppen met tegenvallers opleveren. Minister Plasterks opvolger kan zijn hart nu al vasthouden.

Tenslotte: wat doet de politiek?

De BRP, ook versie 3.0, zal er niet komen in de voorziene vorm. De politieke partijen – de grote in elk geval – weten dat. Er is daarom een kleine kans dat een volgende minister van BZK het BRP-risico niet meer aandurft. Met een nieuwe, versplinterde Kamer is de kans op doormodderen echter veel groter. Uiteindelijk is doormodderen ook de geschiedenis van de mGBA/BRP.

Maar terwijl ik schrijf aan dit artikel gaat bij de behandeling van de begroting van BZK VVD-Kamerlid Ingrid de Caluwé (niet verkiesbaar) los op de BRP en Plasterk. En ze treft meteen doel want door haar onder druk gezet suggereert minister Plasterk dat er inderdaad wéér een ronde BRP-uitloop zit aan te komen. Dat suggereert sterk dat Frankes skelettransplantatie nog lang niet is voltooid en dat Plasterk dat weet. De minister zegt toe dat de Kamer komend voorjaar nader wordt geïnformeerd, ongetwijfeld op een electoraal handig moment. Misschien trapt de Kamer er deze keer niet in.

Ongeacht wat er gebeurt zal dit niet mijn laatste artikel over de BRP zijn. De BRP is in meerdere opzichten een uniek ict programma. Herstarts zijn zeldzaam en twee herstarts in één Kabinetsperiode is een unicum, zeker bij een programma dat is afgemaakt door een Kamercommissie. Ook zeldzaam is de bijna frauduleuze wijze waarop wordt omgegaan met belastinggeld en de afwezigheid van ambtelijke sturing. (zzp’ers die rijk worden van hun falen is in de publieke ict helaas gewoon.)

Het goede nieuws is dat alle software-versies tussen 2011 en vandaag in de archieven terug te vinden zijn, zodat wat hier wordt beweerd door een toekomstige parlementaire enquêtecommissie controleerbaar is. Het zal na 2020 zijn, maar die enquête komt er wel als in 2019 de BRP-software ‘bestuurlijk’ wordt opgeleverd en niet implementeerbaar blijkt. Een werkende, moderne bevolkingsadministratie is immers in een EU waarin grote mensenmassa’s op drift zijn ‘best belangrijk’. En die gaat er dus niet komen.