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.
Uitmuntende analyse van Veldwijk en de zijnen.
Enige literaire begaafdheid kan de auteur(s) niet worden ontzegd; dit stuk leest als een spannende roman (zoals in eerdere reacties ook al opgemerkt).
Wel wil ik enige opmerkingen maken over de genoemde “alarmbellen in het duister”.
Uit de tekst gelicht is de uitspraak:
“Je moet nooit, echt nóóit zo dwaas zijn om generieke en specifieke software parallel te ontwikkelen”
natuurlijk niet waar; één van de doelen van software ontwikkeling is juist om functionaliteit zo generiek mogelijk op te zetten om optimaal te kunnen profiteren van *hergebruik* van software. Het parallel ontwikkelen van generieke en specifieke software is dus juist wat er gebeurd binnen service-georienteerde architecturen!
Binnen de hier gestelde context is deze uitspraak echter volkomen juist. Verderop in de tekst wordt dit zeer juist aangescherpt: “Toch blijft de hoofdvraag hoe men zo dwaas heeft kunnen zijn om simultaan applicatiegeneratoren en applicatielogica te bouwen”.
Met generieke software wordt hier dus dus duidelijk gedoeld op applicatiegeneratoren; vermoedelijk gebaseerd op software-templates (die in verschillende wiki’s ook ‘generics bij uitstek’ worden genoemd). Het resultaat is dan inderdaad de one-shot generator, die alleen in de bouwfase gebruikt kan worden, als je de (complexe) gegenereerde code vervolgens aanvult met specifieke software.
In die zin is alarmbel 4 alleen maar een theoretische mogelijkheid; de kans dat de generatoren blijvertjes worden lijkt mij op grond van de voorgaande alarmbellen eigenlijk niet zo groot.
Overigens zit er mijns inziens beslist wel heel veel in het idee van applicatiegeneratoren. Met alle juichverhalen over agile/scrum-applicatieontwikkeling vraag ik mij toch af wat voor programmeertalen dan wel worden gebruikt. Als je echt meters wilt maken, dan lijken mij 3GL-talen zoals Cobol of Java mij ook minder geschikt. Een best of both worlds krijg je als je applicatiegeneratoren gebruikt binnen een service-georiënteerde architectuur; meters maken met de generator (ook in beheer) en specifieke maatwerksoftware naast generieke software onderbrengen in services (die dus *niet* verloren gaat als de generator opnieuw wordt gebruikt).
Helaas is dit nog toekomstmuziek en kunnen we nog veel uitmuntende opiniestukken van Veldwijk c.s. verwachten.
Leuk artikel, zeker, hier is mijn plasje. In de basis houd ik altijd Gall’s Law aan :
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)
Ik ben nog geen uitzonderingen tegengekomen en dit stuk bevestigd de wet.
Hoe dan wel?
Laat ik voorop stellen dat ik niet tegen code generatoren ben, zij hebben de toekomst, zeker als machine learning kan worden ingezet.
Iedere code generator levert code op en de mogelijkheid om maatwerk op de generator te bouwen zonder dat dit betekent dat je de code niet nogmaals kunt genereren. Door de unit-tests kun je geautomatiseerd controleren of het nieuwe gegenereerde model nog steeds door alle tests komt en zodoende weet je welk werk aan de winkel is.
De basis is echter dat ze *nooit* vanuit scratch het nieuwe model hadden moeten bouwen en de illusie dat dit in een keer de huidige stand van zaken zou kunnen vervangen.
Vanuit een basis model (personen en een aantal van de veelvoorkomende relaties tussen die personen) kun je een werkend stukje maken wat een deel van het nieuwe model qua waarde bewijst. Je zult ook een mapping en synctool moeten maken tussen het huidige model en het nieuwe model zodat je beide modellen naast elkaar kunt gebruiken. Als dit nieuwe principe werkt en waarde toevoegd (working simple system) heb je de schets van een route gevonden die je verder kunt uitbouwen.
De voordelen:
– Relatief kleine investering
– Bewijs dat het werkt
– Dwingt geen snelle migraties of big bangs af
– controle en governance
Het voordeel is dat je ook daadwerkelijk kunt gaan scrummen. Bewezen waarde, iedere keer weer en heldere “slagboom” momenten. Door de korte iteraties heb je geen lange releases, is het gehele team vervangbaar en uitbereidbaar (elastisch en schaalbaar).
Hoe dan ook, als we succes willen zullen we terug moeten naar het begin van working simple systems.
Henri, mooie herkenbare reactie van je.
Met een heel eenvoudig voorbeeld kan ik aannemelijk maken dat de wet van Gall in ieder geval niet geldt voor bedrijfsapplicaties.
Als jij ergens een nieuw huis laat bouwen, dan zeg je niet tegen de aannemer: zet de fundamenten en de woonkamer alvast maar neer; de rest bouw ik er later wel omheen. Mijns inziens zou je een bedrijfsapplicatie kunnen zien als een huis – een functionaliteitengebouw – waarin je kunt wonen en waarin je je in meer of mindere mate thuis kunt voelen.
Wat dat betreft is “Windows” wel toepasselijk gekozen.
Jij blijft hier en in andere reacties spreken over data, logica, processen en systemen: ik spreek veel liever over objecten, functionaliteit, flow en applicaties (en dus ook over selfservice).
Jij spreekt over een code-generator; ik had het over een applicatie-generator.
Jack wat een vreselijke reactie schrijf je en we zitten echt op elkaars uiteinden.
Allereerst: Gall’s law geldt *juist* voor bedrijfsapplicaties. Je komt met een voorbeeld van een huis en dat is al een slecht voorbeeld in zichzelf. Je veronderstelt dat je namelijk al precies weet wat je wilt gaan bouwen. Als we dat op dit artikel betrekken dan was er dus bij het bouwen van BasisRegistratie Personen volstrekt duidelijk *wat* er gebouwd moest worden? Als dat zo is, dan kan dus alleen het bouwen van het huis mis gegaan zijn? Er is niet gebouwd volgens de specificatie.
Ik betwijfel het ten zeerste.
Daarnaast om de vergelijking met een huis bouwen meteen maar tot op de grond af te branden. Een huis is redelijk onveranderlijk. De functie verandert op details na nauwelijks. Software verandert continu. Nadat versie 1 af is wordt er door ontwikkelt, verbeterd, verbindingen gebouwd, verplaats afgebroken en zo verder. Dus de vergelijking raakt kant nog wal.
Wat BRP betreft. Het model kun je alvast maken en in de basis toetsen. Dit is de richtlijn voor je systeem / software. Door klein te beginnen om dit model in een applicatie te gieten kun je de levensvatbaarheid testen. Geen big bang, maar geleidelijk. GBA is ook niet op 1 dag/jaar verzonnen en gebouwd en is een levend iets.
Dan kom je in een stukje semantiek (data/logica versus objecten/applicaties) wat volstrekt oninteressant is om te noemen en dan kom je met de sluitende zin waarin je dus aangeeft de materie niet eigen te zijn: “Jij spreekt over een code-generator; ik had het over een applicatie-generator.”
Applicatie generatoren bestaan niet en wat er op lijkt functioneert niet. Geen uitzonderingen. Punt.
Daarnaast is een applicatie een subset van een systeem. Het is een hele beperkende gedachte en botst met je hele SOA filosofie.
Ik bouw systemen en software. Dat doe ik al meer dan dertig jaar en bedrijven betalen hiervoor. Nu hoeft dit niets te zeggen, maar het is wel een indicatie van veel ervaring op de dit vlak en als ik één ding van overtuigd ben is het Gall’s law. Geef mij één concreet -en dus niet filosofisch voorbeeld- van een complex systeem wat vanuit scratch goed werkte en ik zal in het stof bijten en ruiterlijk mijn ongelijk hier verkondigen. De gehele natuur om ons heen is één groot bewijs dat complexe systemen door evolutie tot stand komen, waarom zou het voor systeem ontwikkeling anders zijn?