Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

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 Jeanot Bijpost. 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.

Bijposts generatoren zijn al in ontwikkeling als Franke aantreedt als puinruimer. (Gartner noemt ze, maar mist de significantie.) Franke besluit om Bijpost carte blanche te geven. Dat kan, want geld en tijd zijn geen probleem meer en er zit nu eindelijk competent management. Bijpost 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. Bijposts zelfoverschatting 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 Bijpost 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 Bijpost 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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5895773). © Jaarbeurs IT Media.
7,6

Partnerinformatie
 

Reacties

Ook voor 2010 was men al bezig met de modernisering GBA. Een leuke oefening voor de geïnteresseerde lezer: google eens op "modernisering GBA 2001", "modernisering GBA 2002" etc... De start in 2010 was dus eigenlijk ook al een herstart/doorstart.

Over een ander berucht ICT-project bij de Overheid - SPEER van het Ministerie van Defensie - schreef ik een stuk met de kop: "ICT-projecten komen in de problemen omdat het ICT-projecten zijn", zie https://www.managementsite.nl/ict-projecten-falen-ict-projecten.
Afgaande op dit stuk van René Veldwijk kom ik tot de conclusie dat ook hier weer de nadruk ligt op de techniek en niet op wat nodig is.
Het BIT van Elias werkt daarbij volledig contra-productief want ook weer ICT-ers o.l.v. een ICT-er. Wanneer komt men er nu eindelijk eens achter dat ICT een middel is en geen doel? En dat ICT-specialisten ICT zien als doel en niet als middel ? Want dat is de echte kern van deze problemen.

René, mooi stuk. Je geeft aan dat overheidsorganisaties volstrekt onvoldoende leren van fouten bij complexe (ICT-) projecten. Dit is je zoveelste voorbeeld daarvan. Als bij het project BRP het budget van 44,5 miljoen op is bij een oplevering van 32% van het systeem (en dat is wellicht een te optimistische schatting) dan is het vreselijk misgegaan op diverse niveaus. Je kan het budget natuurlijk verhogen voor een "doorstart" om de resterende 68% van het systeem te maken. Maar als er bij de aansturing en de opzet van het project niks wezenlijks verbetert, dan zal misschien slechts 32% van die 68% worden verwezenlijkt. Dan moet je een derde, vierde, enz. ronde starten. Hiervan kan je een formule van maken met een paar variabelen, die laat zien dat het systeem nooit af zal zijn. Na heel veel inspanning en een lange doorlooptijd kan het systeem wel bijna 100% af zijn. Waarschijnlijk is het systeem dan al weer verouderd en moet het aangepast worden. Maar als het systeem niet goed te onderhouden is, zoals je aangeeft, dan kan je na pakweg 10 jaar alsnog vanaf scratch opnieuw beginnen. En al die jaren zit de overheid met hoge onderhoudskosten van een verouderd systeem. Dus komt er weer een nieuwe parlementaire enquêtecommissie.
Sommige projecten kan je beter beëindigen en vervangen. Laat de geit de kool maar opeten.

Het moge inmiddels wel duidelijk zijn dat minister Plasterk wederom blijk geeft van ondeugdelijk beleid door deze blamage. Oftewel Ome Roon heeft het mooi verkloot.
Maar in het huidige kabinet lijkt dit eerder de norm te zijn. Miljarden per jaar worden zo verspild dat terwijl zo'n beetje de hele publieke sector wordt kapot bezuinigd om maar aan de Europese begrotingsobsesie te voldoen. Dit heeft ernstige gevolgen voor onze hele samenleving maar niemand die zich daar druk over lijkt te maken om dat het NOS journaal ons niet verteld dat wij hier ontzettend boos op moeten worden. Mensen als René doen dat dus wel maar die krijgen nauwelijks een platform in de media.

Niet voor niets dat er komende maart er 63 partijen op het verkiezingsprogramma komen te staan. Wellicht dat wij ICTers dan ook op dat vlak onze bijdragen kunnen doen om te zorgen dat de ICT kennis binnen het politieke stelsel wat omhoog kunnen krikken want het is hard nodig zo blijkt weer eens.

Waarom heet een vervanging van door generatoren gegenereerde java code door java code van mogelijk ervaren programmeurs ineens een skelettransplantatie. Ik zou denken dat het skelet van een systeem niet de code is maar een framewerk van functies en relaties waarin de code wordt opgehangen.
Dat de overheid voor ict-projecten externen moet inhuren is het gevolg van bezuinigingsoperaties goedgekeurd en soms afgedwongen door het parlement, daar kan een ministerie zelf weinig aan doen.
Er is geen enkele zekerheid dat een herstart meer kans op succes biedt.
Of een systeem onderhoudbaar is ligt vooral aan een heldere structuur en goede documentatie. ICT-experts zijn notoir slecht in het goed vastleggen van hoe en waarom code zo is opgebouwd. Een goede generator zou ook de benodigde documentatie moeten genereren.
Het vervangen van een werkend groot legacy-systeem door een nieuw systeem is al moeilijk. Als dan ook de eisen iedere keer weer veranderen door nieuwe regelgeving kan je niet verwachten dat een jaren geleden gemaakte inschatting blijft kloppen. Maar het oorspronkelijke ontwerp moet wel berekend zijn op het eenvoudig kunnen maken van aanpassingen.
Ik vind het vrijgeven van de code vreemd, alsof je CoCa Cola het recept van CoCa Cola vrij te geven. Als je de voortgang wil controleren huur dan een bedrijf in of bouw zelf de expertise op hiervoor.
Is het niet logisch dat als de beoogde codegeneratoren niet de gewenste software bouwstenen opleveren dat je die bouwstenen dan vervangt door zelf geschreven java-code waarbij mogelijk veel van de gegenereerde code is hergebruikt.
Wat ik mis in dergelijke verhalen hoe uiteindelijk de afnametesten gebeuren. Pas uit een goede afnametest kan blijken of een systeem voldoet aan de eisen. Meestal is in het tijdplaatje daar onvoldoende ruimte voor ingebouwd of wordt de wel geplande ruimte opgesnoept om maar de opleverdatum te halen.

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

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×