Het verdrinkt in de commotie rond de SVB, maar dinsdag 23 juni staan wij – Ockham Groep – in de rechtszaal tegenover onze overheid. Inzet: vrijgave van de broncode en de ontwerpen van de Basisregistratie Personen, een systeem dat maar niet af komt. Na een sneak preview van de broncode denken we te weten wat de opvolgers van minister Plasterk te wachten staat: een heruitgave van de Vliegende Hollander.
De recente artikelen over de pgb-affaire waren zo leesbaar dat ze zelfs tot Kamervragen leidden. Maar waar het daar ging over ontwrichting, veroorzaakt door een operationeel systeem, gaat het hier over een belasting- slurpend programma waar niemand last van heeft. Het programma Basisregistratie Personen (BRP, zie kader onderaan) loopt al zo lang dat men ondertussen de oude Gemeentelijke Basisadministratie (GBA) maar BRP is gaan noemen. En het programma Modernisering GBA (mGBA) heet Operatie BRP.
Wat vooraf ging
In 2010 besloot BZK na drie mislukte pogingen om de oude GBA echt te gaan vervangen. De gemeentelijke GBA-systemen, de daarvan afgeleide landelijke personenbank (GBA-V) en een nog te bouwen tijdelijk systeem voor niet-ingezetenen (RNI) zouden alle opgaan in één landelijk systeem: de BRP. Er zou innovatief worden aanbesteed: niet werken met één maar met acht partijen. Aangestuurd door BZK zouden modules worden ontworpen die stuksgewijs zouden worden gegund aan de beste bieder.
Wat volgde, was een nachtmerrie. BZK kon geen regie voeren. Na een jaar lag er nog hoegenaamd niets. Geen ontwerpen. Geen koppelvlakken. Er viel dus ook niets uit te besteden. Zeven van de acht deelnemers vonden dat uitstekend. Nummer acht schreef een brandbrief, waarna het programma alle communicatie met de buitenwereld staakte.
Twee jaren verstreken. Toen was het budget van 38.800.000 euro op. Paniek bij BZK die een zomer lang een team van Gartner onderzoek liet doen. Conclusie: systeem voor 32 procent klaar. Besluit: dertig miljoen extra geld, drie jaar extra tijd en een externe programmamanager. Politiek probleem opgelost!
Behalve dan dat volgens onze bronnen zelfs die magere 32 procent gereed een leugen was. Gartner zou bijvoorbeeld de programmeurs hebben gevraagd voor hoeveel procent het werk af was. ‘Onafhankelijk onderzoek’ dus, zoals we dat kennen van de pgb’s met als doel om een bewindsman uit de wind te houden. Kamerlid Van der Linde (VVD) was de enige die ook lont rook en vroeg in een overleg of de broncode niet kon worden vrijgegeven. Open source, weet u wel? Een verraste minister Plasterk ging akkoord. Het is dan november 2013. Wij vragen de code op.
Weer paniek. Een levensgevaarlijk precedent dreigt. Straks wordt de broncode van elk mislukt of mislukkend ict-project nog opgevraagd. Stel je voor: Speer (Defensie), het Toeslagensysteem (Belastingdienst), de WIA-software (UWV), het Multiregelingensysteem (SVB). Kasten vol skeletten ter waarde van miljarden aan belastinggeld. De Kamer slaapt (nu niet meer) en de toezegging wordt uitgekleed. Alleen werkende software, dus niet de smoking gun van 2013. Geen onderdelen die hackgevoelig zijn. Alleen kijken in een afgesloten kamertje. Niet zelf compileren. Wij verzetten ons. Op 23 juni bepleit WOB-specialist Brenno de Winter onze zaak bij de bestuursrechter.
De broncode-review
Nu, medio 2015, mogen wij en anderen reviewen, want er is werkende BRP-software. We kunnen de verleiding niet weerstaan, dus we melden ons aan en krijgen toegang tot een hokje met een computer in de BZK-toren in Den Haag. Men heeft nog een hindernis toegevoegd: er wordt geen enkele documentatie ter beschikking gesteld. De broncode mag zichzelf verklaren en we mogen raden hoeveel van het toekomstige BRP-systeem we zien.
De opzet is natuurlijk om het onmogelijk te maken om wat dan ook met zekerheid over de status van de software te zeggen. Wat niet wordt getoond is wellicht voor 99 procent af. En zonder documentatie weet je niet of de puzzel bestaat uit 500 of 3000 stukjes. Toch weten we in ruim twee uur wat puzzelstukjes te vinden en op ongeveer de juiste plaats te leggen. En gelukkig is er ook nu weer een ‘onafhankelijke’ partij aangetrokken, KPMG, die de kwaliteit van de software bewaakt en daarover rapporteert.
Na twee uur denken we te weten waarom het BRP-systeem nooit gaat afkomen. De BRP-in-wording is geen total loss zoals de systemen bij de SVB en de Belastingdienst. Wat we zien is de ict-variant van de Vliegende Hollander, eeuwig varend rond Kaap de Goede Hoop.
Puzzelstukjes in 2D en 3D
Wat opvalt als je naar de code kijkt, is dat een deel is gegenereerd met een custom made programmagenerator. Men bouwt dus gewone software en aparte software om software mee te genereren. Niet altijd is zichtbaar welke broncode is gegenereerd en welke uitgekrast. Ook de code van de generator is niet geopenbaard. Het is alsof je puzzelstukjes in handen hebt van twee puzzels: een klassieke platte jumbo puzzel en zo’n moderne 3D-puzzel. Zeker zonder documentatie is zoiets heel vervreemdend.
De gegenereerde code zelf is verwarrend. Het BRP-datamodel (niet geopenbaard) is kennelijk een poging om het generalisatie-/specialisatieprobleem op te lossen. De BRP bevat in essentie personen die onderling in allerlei rollen tot elkaar staan (huwelijk, afstamming, erkenning, etc.) en daarvoor is iets slims bedacht. De generatoren lezen de definities van abstracte persoonsrelaties en spuwen vervolgens op basis van een datadictionary (niet geopenbaard) software uit waarin abstracte relaties zijn omgezet in herkenbare zaken staan zoals ‘huwelijken’, ‘ouderschappen’, enzovoorts. Maar we zien dat de gegenereerde code dat maar half doet: de gegevenselementen zijn specifiek voor de soort relatie maar de relaties zelf blijven ook in de gegenereerde code abstract. Heel desoriënterend.
Een geraadpleegde insider herkent het probleem. De initiator van de generatoren is de lead architect van de BRP en een van de meer begaafde ict’ers die er in Nederland rondlopen. Mensen van dit kaliber zien in de BRP geen groot systeem maar vele variaties op een beperkt thema. Automatiseer het abstracte thema en genereer de variaties uit, dan hoef je maar een keer te coderen.
Wat de insider boos maakte was dat er zou zijn afgesproken dat er wel met generatoren mocht worden gewerkt, maar dat er voor gewone ict-stervelingen onderhoudbare code zou worden uitgegenereerd. Wij begrijpen deze boosheid. Deze BRP gaat ook als hij operationeel is heel veel geld kosten.
De BRP: alarmbellen in het duister
De voorgaande bevindingen laten meerdere alarmbellen afgaan. De eerste is dat er kennelijk wordt gewerkt met generatoren die alleen worden gebruikt bij de initiële bouw van software. De winst van dergelijke one shot software in kosten en doorlooptijd valt dus alleen in de bouwfase. Zodra de software immers in onderhoud gaat wordt de gegenereerde software aangepast en is de generator waardeloos. Maar als je al jarenlang bezig bent met programmeren dan is er duidelijk iets goed mis. En dan zien, horen en lezen we vervolgens ook dat de gegenereerde programmatuur niet gemakkelijk is te doorgronden. We kijken naar een permanente ict-nachtmerrie.
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. De broncode voor de initiële vulling van de BRP heeft men netjes uitgeprogrammeerd, maar zo te zien met uitzondering van de 300+ BRP-invoercontroles. Het lijkt er op dat er nog een generator niet helemaal af is .
Alarmbel 3 is dat de gegenereerde code niet alleen bestaat uit een psychedelische mix tussen abstract en plat, maar ook dat deze volgens auditor KPMG zeer complex is (hier, blz. 4). Als het de bedoeling is om deze complexe gegenereerde code voor elk gegenereerd programma te onderhouden, dan moet het ergste worden gevreesd. Wat de zaak nog enger maakt is dat KPMG meldt dat de ontwikkelaars markeringen in hun software mogen plaatsen om stukken code uit te sluiten van geautomatiseerde beoordeling met het gebruikte Sonarqube-tool. Alsof je tegen de belastinginspecteur mag zeggen welke aftrekposten niet mogen worden gecontroleerd.
Als het project al deze stormen doorstaat en het BRP-schip de Kaap rondt, dan gaat alarmbel 4 af. Bij werkende generatoren is het dwaas om generatoren na de bouwfase af te zinken – zeker als de gegenereerde software complex is. De kans dat de generatoren blijvertjes worden is dus groot en het is goed denkbaar dat deze helemaal niet eigendom zijn van de Staat der Nederlanden. De generatoren zijn in elk geval losjes gebaseerd op het ontwikkeltool Cathedron van het bedrijf van de genoemde lead architect. Als de afspraak is dat de generatoren alleen worden gebruikt voor de systeembouw dan is het niet ondenkbaar dat er een juridisch probleem is wanneer er in de toekomst verstandiger keuzes worden gemaakt.
De BRP: alle hoeken van de kamer
Wat hiervoor is beschreven is één van de puzzelstukjes die ons zijn voorgelegd. We hebben er meer gezien. Om er één te noemen: we vinden in de referenties aan een zelfgemaakt locking mechanisme. Tja, waarom zou je ook een databasemanagementsysteem gebruiken? En nog een: de BRP lijkt uitermate redundant van opzet te zijn. De oogst van even rondneuzen: een database, JSON-geserialiseerde objectboom-kopieën in BLOBs en een applicatiecache, alles zelfgemaakt. Wie software tools wil bouwen hoeft niet naar Silicon Valley – ’s Gravenhage volstaat.
Toch blijft de hoofdvraag hoe men zo dwaas heeft kunnen zijn om simultaan applicatiegeneratoren en applicatielogica te bouwen. Het antwoord op die vraag lijkt te zijn dat de lead architect er met het project vandoor is gegaan en zich, zoals zovelen voor hem, totaal heeft verkeken op de technische uitdaging. Vijf jaar na de projectstart heeft men zich in een hoek geverfd. We weten alleen niet in welke hoek: een niet onderhoudbaar BRP-systeem, een permanente afhankelijkheid van één man of toch gewoon een totale mislukking. Tenzij de politiek ingrijpt zal de tijd het leren.
Resteert nog een vraag: na de crisis in 2013 is er een sterke (externe) programmamanager aangetrokken. Deze man weet uit ervaring hoe gevaarlijk de ingeslagen weg is. Als bestuurder van het toenmalige LISV (een voorloper van het UWV) is hij persoonlijk verantwoordelijk geweest voor het mislopen van een deels vergelijkbaar project (Kentech, Capgemini-dochter Bolesian) waarmee code voor uitkeringssystemen moest worden gegenereerd. Het resultaat was een totaalfaal met schade van minstens tien miljoen gulden (wat toen best veel was).
Geen misverstand: dit soort fouten wordt gemaakt door de beste mensen (ook dus door ons). Het zou kunnen dat men bij zijn aantreden in 2013 al te ver de doodlopende straat was ingelopen. Minister Plasterk had hem niet aangetrokken om de stekker uit het project te trekken. Juist om hierover helderheid te krijgen willen wij dus inzage in de status van het systeem ten tijde van het doorstartbesluit.
Het ziet er al met al slecht uit voor het BRP-programma. Er is echter een voordeel op de meeste andere grote publieke ict projecten: het programma heeft niet alleen onbeperkt budget maar ook onbeperkt de tijd. De Vliegende Hollander blijft dus zeilen en misschien rondt schip op een dag toch de Kaap. Als het hier geschetste beeld van de BRP-puzzel klopt dan begint de ellende dan pas echt.
Deze bijdrage kwam tot stand i.s.m. Frido van Orden en Marjan Schnetz, beiden werkzaam bij ict-maatschap Ockham Groep.
Waarom van de GBA naar de BRP?
De bestaande Gemeentelijke Basisadministratie (GBA) uit de jaren ’90 is opgezet per gemeente en wordt gebruikt door de afdelingen Burgerzaken. Tegelijk zijn de gegevens in de GBA van enorm belang voor bijna elk ander overheidsorgaan en daarom is er deze eeuw ook een landelijke gegevensbank, de GBA-V(erstrekkingen) opgezet. Daarnaast zijn er zo’n twee miljoen personen die wel een BSN hebben maar niet in de GBA zitten, zoals buitenlandse werknemers en in het buitenland woonachtige Nederlanders die sinds kort zijn ondergebracht in een tijdelijk systeem (RNI).
Met de komst van de BRP verandert er voor de buitenwereld niet veel, maar technisch des te meer. Alle gegevens van alle in de GBA en de RNI opgeslagen personen landen op één centrale plek, de BRP. Voor de gemeenten betekent dit dat hun kerndata verdwijnen in de cloud en zij hun overige systemen daarop moeten aansluiten. Dat moet allemaal nog gebeuren maar de kosten die de ict-leveranciers moeten maken worden nu al doorbelast.
Naast het probleem dat de BRP niet af komt, de gemeenten weinig oplevert en nu al geld kost, staan de gemeenten ook voor de uitdaging om hun persoonsdata beheerst te migreren (eigenlijk convergeren) naar de centrale BRP. De daaraan verbonden inspanningen leiden wel tot een kwaliteitsverbetering van de data in de GBA.
Voor de liefhebber is de geschiedenis van het BRP-programma sinds 2010 beschreven in een viertal artikelen op iBestuur.nl: over het initiële falen, de verkeerde opzet, de uitsteltruc van de minister en de cultuur van misleiding rond ict.
Ik citeer: “een van de meer begaafde ict’ers die er in Nederland rondlopen”.
Uit wat ik daarna allemaal lees concludeer ik dat we het dan in dit land verder wel kunnen schudden (of, in ICT-lingo, wel kunnen “shaken”).
Het lijkt nuttig om met een minimale investering de bestaande en aangrenzende code te laten doorploegen door een geautomatiseerd systeem dat op het niveau van een business analist instant de code kan doorgronden en beschikbaar kan maken. Een kamerlid met een geschikte achtergrond, kan er dan ook al wat mee. Dus mooi als de code beschikbaar komt, vooral voor een geavanceerde benadering. Daarom ben ik er voor dat indien de sources inderdaad beschikbaar komen, deze door een onafhankelijke partij zoals Cornerstone geprocessed worden tot een dictionary, waarna mensen die echt goed zijn – dus niet degenen die zichzelf vooral heel erg goed vinden (ahum) – er wellicht enige tijd in kunnen steken en wat slimme opmerkingen kunnen maken alvorens tot beslissingen te komen. Zo weet ik dat er kanjers in software architectuur zijn – ze weten zelf wel wie ik bedoel – die ik uitstekend in staat acht met behulp van een dergelijke tool in korte tijd goede aanbevelingen te doen, temeer daar sommige van hun reeds werkzaam zijn in de arbitrage van ict perikelen.
Dit leest als een geromantiseerde krimi met een onaangename verheldering van tijdsbeeld, wanneer je jezelf realiseert dat het geen fictie is, maar werkelijkheid! Waarom onze overheid zo halsstarrig vasthoud, en niet met de billen bloot wil, kan misschien verholpen worden! Hoe…,lees hiervoor eerst onderstaande informatie!
http://balance-research.com/category.html?identifier=HVA&session=E116E9AA5EA3B02E357F6CAB81A8B168
Wanneer men na het bestuderen van deze tekst nog volhoud dat men dit alsnog wil blijven handhaven… dan is er iets verschrikkelijk mis met de geestestoestand van betrokkenen! Hier beschrijft de in artikel genoemde intellectueel namelijk zelf waarom dit falen in de uitvoer van de opdracht niet langer geaccepteerd kan worden…
Mocht deze tekst u niet overtuigd hebben? Misschien is 38.800.000 euro voldoende argument, dit is het bedrag wat het de belastingbetaler gekost heeft. En om in Elias term te eindigen!
U (Overheid) heeft weer een auto zonder stuur gevraagd en gekregen…
Ga zo door René, ik hoop dat jullie in het gelijk gesteld worden!
Heerlijk artikel weer!
Niet te geloven dat er ICT’ers bestaan die daadwerkelijk op zo’n project dit soort zaken gaan bouwen. Het ontbrak er nog maar aan of er was ook gelijk een nieuw soort OS ontworpen.
Misschien een wat te voor de hand liggende vraag maar: waarom wordt er niet gewoon gekeken wat er in andere landen wel blijkt te werken?
Wederom bewezen dat grote ontwikkeltrajecten van software in eigen beheer een enorme faalkans hebben. Mckinsey onderzocht het meermaals: hoe groter het project, hoe groter die kans.
Waarom blijven we dan toch vasthouden aan de illusie van het in eigen beheer ontwikkelen van pakketsoftware die precies moet doen wat de organisatie wil, de “representatieve IT” zoals UVA hoogleraar Peter van Baalen zo mooi uitlegt? Zie http://www.uva.nl/nieuws-agenda/nieuws/uva-nieuws/content6/2015/04/when-the-rubber-meets-the-road.html
Het lijkt erop dat die platform gedachtengang hier wel enigszins is gevolgd. Maar het ontwikkelen van een generiek pakket of platform, de “generatieve IT” kan nooit slagen als onderdeel van een project, laat staan binnen hetzelfde project. Commerciele software pakketten met veel functies moeten ook jaren rijpen voor ze echt goed werken, dat kan een eigen beheer project nooit evenaren.
Het antwoord? Ik weet het ook niet. De werkwijze van de overheid aanpassen op de IT lijkt me ook niet echt een haalbare optie… Wie weet raad? Leuk onderwerp voor een round table!
Even tussen neus en lippen door : het Logisch Ontwerp incl. gegevenswoordenboek(en) staat op http://www.rijksdienstvooridentiteitsgegevens.nl/BRP/Inwerkingtreding_LO_GBA_3_9
Wat ík dan weer interessant vind : heeft er kwaliteitscontrole op dit LO plaatsgevonden?
@p.j. westerhof
Dat gaat over het bestaande GBA, niet om het mGBA tegenwoordig operatie BRP.
De meest recente publieke versie van een logisch ontwerp van operatie BRP is http://www.operatiebrp.nl/sites/operatie-brp/files/Logisch%20Ontwerp%20BRP%20-%20versie%201%200_dd08102014%20-%20publicatie%20(1).pdf
Uit oktober 2014. en nog niet compleet zoals bijvoorbeeld uit dit stuk blijkt:
http://www.gemmaonline.nl/images/cocreatiebasisgemeente/0/05/Notitie_RSGB3.0_en_informatiemodel_BRP_TP20150522.pdf
Dit is bovendien geen datamodel maar een abstractie hoger. Er zit natuurlijk wel een nauwe relatie tussen het niet openbare datamodel en het logisch ontwerp.
@Frank : tnx!
In de zijlijn betrokken geweest maar niet de indruk dat deze “sterke (externe) programmamanager” zich over techniek bekreunt. Wel een hele aardige man en zeker vaardig in communicatie. Weten dergelijke externen sterke mannen wel waar ze aan beginnen? Of maakt het hen niets uit?
Weer alle lof voor René Veldwijk en zijn mede-auteurs.
@hjk: Ik ben bang dat je gelijk hebt. Edsger W. Dijkstra zei al in de jaren ’80:
De universiteiten zal het de moed blijven ontbreken om harde wetenschap te onderwijzen. Men zal erin volharden de studenten te misleiden en elke volgende fase in de infantilisering zal toegejuicht worden als een onderwijskundige stap voorwaarts.
@Andre van Leur: Daarom wordt in (ICT) opleidingen in Nederland vooral ‘communicatie’ onderwezen.