Onverklaarbare platformkeuzes bij de overheid?

17-01-2013 13:03 | Door Harrie Gooskens | Lees meer artikelen over: Authenticatie, Exploits, Legacy, Consulting, Processoren, Social media, Linux, Aanbesteding, DigiD, .Net, Ruby (on Rails) | Er zijn 11 reacties op dit artikel | Permalink
Computable Expert
Harrie Gooskens
Harrie Gooskens

Senior Consultant

Expert van Computable voor het topic Overheid

Meer

Het nieuwe jaar is (letterlijk) koud begonnen en de media maken al melding van het tweede overheidsprobleem met ict in 2013. Eerst moest DigiD een dag uit de lucht worden gehaald en vervolgens bleek de 'Mijn UWV'-portal al ruim een week niet meer toegankelijk voor uitkeringsgerechtigden.

Je zal maar een uitkeringsgerechtigde werkzoekende zijn die erop vertrouwt dat het met werk en inkomen weer spoedig goed gaat komen dankzij het UWV dat volledig digitaal gaat. Of erger nog, je zal maar een van de medewerkers van het UWV zijn die niet wordt vervangen door ict-voorzieningen en steeds met stoffer en blik achter ict aan moet. Beiden balen als een stekker maar geen van beiden heeft waarschijnlijk een verklaring voor de oorzaak van al die ict-ellende zo vroeg in 2013.

Ruby en DigiD

Is er eigenlijk wel iemand die de oorzaak van al die problemen kan verklaren? In de media lees ik daar immers niets over. Ik lees wel dat DigiD deze keer plat moest vanwege een ernstig beveiligingslek in Ruby On Rails. Dat blijkt een redelijk onbekend open source webapplicatie framework te zijn. Geschreven in Ruby en dat is nou niet bepaald een programmeertaal waarin veel it’ers bedreven zijn.

Met andere woorden: ons toch al kwetsbare nationale user-id met wachtwoord - DigiD - is afhankelijk van een open source product dat is geschreven in een taal die slechts weinigen beheersen. Achter zo’n open source product zou een open source community schuil moeten gaan bestaande uit een grote groep ervaren specialisten die in staat is zo’n beveiligingslek snel te repareren en zorgvuldig te testen. Een korte verkenning leert echter dat deze community minder dan drieduizend contributors telt, waarvan nog geen vijftig die meer dan honderd bijdragen hebben geleverd. In vergelijking met Linux en andere solide OSS-initiatieven slechts 'anderhalve man en een paardekop'.

Dat Groupon en delen van Twitter ook met Ruby zijn ontwikkeld bevordert het vertrouwen in Ruby wellicht een klein beetje. Als die vijftig ervaren contributors bij een volgende lek echter toevallig allemaal met Kerstverlof zijn, kunnen er bij de Nederlandse overheid (DigiD) toch heel andere problemen ontstaan dan bij de handel in kortingsbonnen en het plaatsen van tweets.

'Mijn UWV' softwareprobleem tast ook hardware aan

DigiD wordt gebruikt door tal van Nederlandse overheidsinstanties zoals gemeenten en de belastingdienst. Ook door het UWV voor 'werk.nl' en voor 'Mijn UWV', dat al ruim een week niet kan worden gebruikt. De twintigduizend mensen die dagelijks inlogden voor het updaten van gegevens en verkrijgen van informatie, ontvangen hun informatie inmiddels weer ouderwets per post en de dienstverlening probeert men af te handelen via de telefoon en een Webcare-team. Of dat echt zoden aan de dijk zet mag worden betwijfeld. Het UWV heeft de gebruikelijke sancties, zoals korten op de uitkering, vanwege de storing niet voor niets tijdelijk afgeschaft.

Ondertussen neemt het UWV de tijd om de portal helemaal opnieuw op te bouwen. Uiteraard samen met de hulp van de oorspronkelijke ontwikkelaars (IBM en Unisys). Niemand heeft enig idee hoe lang dat zal duren en hoeveel geld dat gaat kosten. De storing ontstond bij een software update en blijkt hardnekkiger dan verwacht. Volgens het UWV moet het systeem opnieuw steentje voor steentje worden opgebouwd. Daaraan wordt dag en nacht gewerkt. Aanleiding voor de upgrade was de performance die met de toename van het aantal werklozen in de afgelopen maanden gestaag afnam. De portal is gebaseerd op een Oracle-database die draait op Windows-servers met x86-processoren en het .NET-framework van Microsoft. Een woordvoerder beweert dat door de softwareproblemen ook de hardware bleek te zijn aangetast. Dat klinkt niet alsof de deskundigheid van het UWV afdruipt.

Keus en kneus

Nederland is gestegen naar de nummer twee positie op de wereldwijde digitale dienstverleningsladder, maar de trede waarop we staan kraakt hevig. Ons DigiD is immers afhankelijk van een kleinschalig open source initiatief met bijbehorende programmeertaal en het UWV werkt met een platformcombinatie die door de hoeven zakt zodra de werkeloosheid toeneemt. Dat rechtvaardigt de vraag wie er verantwoordelijk zijn voor dergelijke keuzes en dan bedoel ik niet de bewindspersonen Plassterk en Asscher.

Gelukkig valt er tegenwoordig veel meer te kiezen dan in de decennia die werden beheerst door de legacy platformcombinatie 'mainframe + Cobol'. Maar als er veel meer keuzes gemaakt kunnen worden, neemt de kans op een verkeerde keuze ook sterk toe. Zeker als de personen belast met de keuzetaak onvoldoende ervaren en competent zijn, of als zij aspecten als maturiteit ondergeschikt maken aan andere belangen. Of is er misschien helemaal geen overheidsdienaar verantwoordelijk voor deze keuzes omdat die taak werd overgelaten aan de leveranciers die de aanbesteding wonnen? Wie kan de keuzes verklaren? Ik schrik nergens meer van sinds René Veldwijk in de Volkskrant van zaterdag 15 oktober 2011 stelde dat de ict-kneuzen in den Haag werkzaam zijn.

Parlementair onderzoek

Sindsdien heeft vooral Ger Koopmans van het CDA zich hard gemaakt voor een parlementair onderzoek dat binnenkort op de rol staat. De tijdelijke commissie ict-projecten bij de overheid is daartoe geformeerd en heeft de aanbesteding gepubliceerd. Hopelijk ruimen de onderzoekers naar de falende ict-projecten bij de overheid ook wat tijd in voor de vraag wie inhoudelijk verantwoordelijk waren voor de platformkeuzes onder DigiD en 'Mijn UWV'. Welke criteria werden daarbij door hen gehanteerd op het gebied van volwassenheid en bewezen schaalbaarheid?

Helaas vrees ik dat het parlementair onderzoek op dit gebied te weinig 'lesmateriaal' zal opleveren omdat DigiD en 'Mijn UWV' niet bij de zes geselecteerde onderzoeksprojecten horen. Maar laten we het positief benaderen, misschien speelde iets vergelijkbaars bij een van die zes projecten. Of er bij de overheid sprake is van onverklaarbare platformkeuzes kunnen we dan hopelijk over ruim een jaar beoordelen. Misschien hoeven we daarop niet eens te wachten omdat zich hier een 'getuige' aandient met een verklarende reactie betreffende de platformkeuze bij DigiD of UWV.

Reacties op dit artikel
De redactie vindt deze reactie: OKLeen Blom, 17-01-2013 16:13
Ja, het zijn altijd elkaar tegenwerkende krachten: vernieuwing en bewezen technologie. De keuze voor Ruby is denk ik met name door de wijze van aanbesteding naar voren gekomen: de overheid heeft voorkeur voor het gebruik van open source. Daarvoor zal de inschrijver dan ook best veel punten hebben gescoord. In de aanbestedingsvragen vind je niet zo vaak terug hoeveel succesvolle en vergelijkbare projecten je met die specifieke technologie hebt uitgevoerd. Alleen de omvang en de generieke ervaring van de leverancier telt dan weer.
 
Van 'Mijn UWN' weet ik niet goed wat de achtergrond van de problemen is, volgens mij gewoon dat de nieuwe software niet werkt. Dat had elke combinatie van hardware, operating system, database en applicatie frameworks kunnen overkomen. Voorlopig lees ik hierboven allemaal bewezen technologie. Dit is een voorbeeld van een 'gewoon' falend ICT project, waar de oorzaak waarschijnlijk zit in te laag ingeschreven en te weinig tijd gecombineerd met minder goed projectmanagement.
De redactie vindt deze reactie: OKokke, 17-01-2013 17:21
Ondanks de vooringenomenheid van Dhr Gooskens en ondanks de korte bochten die hij af en toe neemt, kan ik niet anders concluderen dat hij natuurlijk helemaal gelijk heeft. Ja, software maken is een vak apart waarbij je goed moet nadenken over je keuzes. Vanaf de zijlijn die keuzes bekritiseren is heel makkelijk. Open source of de combinatie IBM en Microsoft op deze wijze afschrijven, lijkt mij zodoende een onterechte conclusie. Ik zou juist aandacht vragen voor de snelheid waarmee een kleine maar hechte community tot oplossingen weet te komen. In het verleden heb ik beveiligingslekken langzamer gedicht gezien. Daarom zou ik de tendens van dit artikel graag omdraaien. Juist door het toepassen van open source technologie zoals Ruby on Rails, is de overheid in staat snel te handelen in kritieke situaties.
 
Okke van 't Verlaat
Technisch en operationeel directeur
Finalist
De redactie vindt deze reactie: OKGerbrand van Dieijen, 17-01-2013 21:48
Over de technologiekeuze kan een nog levende discussie gevoerd worden, waar ik niet aan wil beginnen.
 
Ik ben het eens met de schrijver eens dat de oorzaak ligt in volstrekt onbegrip van overheid in de ICT. Aanbestedingen lopen ofwel op volstrekte mislukkingen uit, of voor een veel te hoog bedrag in een veel te lange periode wordt matige tot slechte functionaliteit opgeleverd.
 
De oplossing zou zijn dat de overheid weer goede ICT-ers in dienst neemt. Niet slechts 'enterprise architecten', 'business-analisten', 'functioneel beheerders' of 'ICT-managers' (die overigens ook meestal extern zijn) maar goede softwareontwikkelaars en algemeen mensen die werk kunnen doen. Diezelfe ontwikkelaars kunnen de leidinggevende van de toekomst worden - maar dan met kennis van zaken.
De redactie vindt deze reactie: OKMaarten Oberman, 17-01-2013 22:58
De keuzes zijn niet onverklaarbaar,...
 
de basis is een EU aanbestedingsprocedure en genoeg juristen bij alle betrokkenen om bij het minste foutje een aanbestedingsjurist uit het vat te trekken. Het verschil komt door de gestelde wensen en eisen en de beoordelingscriteria en dat komt weer door de basiskennis die aan een aanbesteding ten grondslag ligt....
De redactie vindt deze reactie: Goedrobb, 18-01-2013 9:40
Heerlijk weer, de tendentieuze toon waarmee een open source-project wordt neergesabeld. Net of deze problemen niet zouden zijn opgetreden als er een blackbox zou zijn binnengereden om DigID en UWV te bedienen van de ict-omgeving.
 
Er is al eerder opgemerkt of de keus van het platform wel de juiste is geweest. Het is zeker niet zinvol om hier nu te gaan lopen roepen welk platform dan wel gekozen had moeten worden. Daar komt nog bij dat bij juist testen het lek ook al naar voeren had moeten komen. Dan had de RoR-community voor de release het lek kunnen dichten en was er geen probleem geweest.
 
In plaats van de zwarte piet bij de open source community te leggen zou het verstandig zijn eerst eens het project management bij d overheid door te lichten. Als je regie wilt hebben over technische projecten moet je op zijn minst enig idee hebben wat er voor nodig is om dergelijke projecten in te richten. Zowel projectmatig als technisch.
Beide zijn al jaren een groot probleem bij de Nederlandse overheid.
 
De vooringenomenheid van de schrijver en zijn denigrerende toon vind ik ronduit stuitend.
De redactie vindt deze reactie: GoedWim de Bok, 18-01-2013 9:51
Of nu de keuze voor 'Ruby on Rails' de verantwoordelijke is voor de problemen betwijfel ik. Al kan je je inderdaad afvragen waarom er gekozen is voor dit misschien een tikje obscure platform. Maar dat dit de oorzaak van het probleem is weiger ik geloven. Wat ik me wel afvraag, dit is toch niet alleen een probleem van de overheid, van hier genoemde partners als IBM of Unisys mag je ook wat verwachten? Zij zouden zeker verstand van zaken mogen hebben.
 
En daar ligt volgens mij ook de crux van het verhaal. Misschien is het maken van een goede oplossing niet het primaire doel voor een ieder. De overheid heeft in de regel een enorme zak geld te verdelen en het is voor de aannemers van de opdrachten eerst zaak om binnen te komen om vervolgens een flinke duit te kunnen verdienen aan de overheid. Is het dan gewenst om kritisch te zijn of twijfels te hebben? Ik denk dat in dit soort trajecten de oplossing en de kwaliteit daarvan van secundair belang zijn. Binnenkomen is 1, het liefst met zoveel mogelijk mensen, voor zo lang mogelijk tijd voor een zo hoog mogelijk tarief. Trek het blik process begeleiders (scrum! lean!) en ity-bureaucraten maar open. En voor de opdrachtgever ook makkelijk, de verantwoordelijkheid voor de opdracht ligt ergens anders. Heerlijk toch als er gewezen kan worden als het niet werkt?
 
Wat ik denk is dat de opdrachtgever zelf de technische verantwoordelijkheid voor dit soort IT trajecten moet nemen en investeert in technische kennis en die ook een rol laat spelen bij de keuze voor een oplossing en maar niet afgaat op al die aanbieders die met een hele andere pet opzitten. Het gaat dan toch om die zak met geld.
De redactie vindt deze reactie: OKFrank, 18-01-2013 10:21
Hier een beveiligingslek die bij PinkRoccade (voormalige werkgever van dhr. Gooskens) speelde:
"Uit onderzoek van de Automatiseringsgids is gebleken dat een groot aantal Nederlandse websites met Microsoft server software 'lek' zijn omdat serverbeheerders bekende exploits in de webserver niet hebben dichtgepatched. .... Zo kon onder meer de site van Ohra, Wehkamp, Primafoon, Free Record Shop en PinkRoccade gekraakt worden."
 
http://tweakers.net/nieuws/10122/internetsites-zo-lek-als-mandje.html
 
En dat betrof dus software van Microsoft, met een patch, maar waar beheerders niets mee deden. En dat waren beheerders in dienst van PinkRoccade.
 
Met andere woorden, het aantal programmeurs zegt niks, zowel Ruby als Microsoft leveren snel patches maar uiteindelijk zijn het de beheerders die aan de slag moeten.
 
Jammer dat dhr. Gooskens zo bang is voor open source, het is gewoon software zoals alle andere software.
De redactie vindt deze reactie: OKAndré Koot, 18-01-2013 10:38
De voorbeelden van DigID en UWV zijn in zoverre interessant dat we nu meteen iets merken van overheidsprojecten zijn waarbij dingen fout lopen. Het zou interessant zijn om ook vergelijkbare informatie te krijgen van projecten bij het bedrijfsleven. Volgens mij verschillen dergelijke projecten niet veel van elkaar. Ook daar worden vergelijkbare (al dan niet te verantwoorden) keuzes gemaakt en ook daar worden projecten gedraaid met ook externe consultants van dezelfde partijen als die voor de overheid werken. Sterker, ook binnen het bedrijfsleven wordt gebruik gemaakt van tenderprocedures, die weliswaar niet wettelijk afgedwongen zijn, maar die wel gehanteerd worden om het inkoopproces transparanter te maken. Lukt niet altijd, maar dat geldt evenzeer voor de wettelijke afgedwongen projecten.
 
Ik vraag me werkelijk af of de faalfactor bij de overheid veel groter is dan bij het bedrijfsleven.
Kosten overheidsprojecten de belastingbetaler dan niet te veel geld? Tuurlijk. Maar mislukkingen binnen het bedrijfsleven betalen wij, belastingbetalers, ook dubbel en dwars: van de kosten betaalt in eerste instantie de belastingdienst (wij dus weer) grofweg een derde terug en daarnaast worden al die kosten ook echt wel in de kostprijs van de producten en diensten van het bedrijfsleven doorbelast. Ook weer aan ons.
 
En even een terzijde:
Ik denk dat de keuze voor RoR een hele goed was en dat daarmee niet voor een of ander obscuur platform is gekozen. Het foutherstel toont bovendien aan dat een dergelijk project in ieder geval een transparant proces is.
De redactie vindt deze reactie: OKWim de Bok, 18-01-2013 11:14
@André Koot. Met diacriet hoop ik, het woord 'tikje obscuur' was misschien niet het goede woord. Misschien iets minder gangbaar beter, de vraag waarom het ene en niet andere is een interessante. Maar dat is niet waarom het gaat natuurlijk.
 
Maar wat je schrijft over andere organisaties dan de overheid daar ben ik het helemaal mee eens. Zelf ook van een afstand gezien en dan vooral wat voor wonderlijk mechanismes er spelen. Ook die enorme hoeveelheid geld, volledig door externen gerund, leveranciers die onder druk altijd ja leveren. Vind daarvoor hetzelde gelden, de opdrachtgever moet zelf de verantwoordelijkheid nemen en zorgen voor technische kennis voor het beoordelen van de oplossing. Maar blijkbaar is het ook makkelijk om alles over de schutting te gooien. Aansprakelijkheid is dan wel zo makkelijk.
De redactie vindt deze reactie: OKJoris Dirks, 18-01-2013 11:27
De bewering dat Ruby on Rails 'obscuur' is vind ik even slecht onderbouwd als de bewering dat het slecht wordt ondersteund.
Vergelijken met Linux lijkt te slaan als een tang op een varken; het is een kleiner project met een kleinere scope zo je wil, dùs er zijn ook minder contributors nodig. Wanneer een auto een vangrail raakt hoor ik niemand klagen dat er maar één bestuurder was terwijl een vliegtuig vaak een co-piloot en boordwerktuigkundige heeft.
Ik ondersteun wel ten dele de gedachte achter dit artikel: wanneer voor open source gekozen wordt, is het handig om een lèvendig open source product te nemen. Wanneer meerdere partijen de software ondersteunen ben je pas echt leveranciersonafhankelijk. Dat heeft weinig te maken met veiligheid: tien mensen uit één bedrijf die full-time op een project zitten, lijken mij al ruim genoeg om incidenten te kùnnen opvangen.
De redactie vindt deze reactie: OKM. de Kort, 20-01-2013 3:35
In de reacties ben ik het eens dat 'obscuur' op zijn minst slecht onderbouwd is. Maar wat ik nog mis is iemand die zegt dat het het gewoon onzin is.
RoR is echt niet 'redelijk onbekend', het is zelfs al jarenlang één van de bekendere webframeworks. Ik heb er zelf nog nooit mee gewerkt, dus ik ben niet bevooroordeeld. Maar ik houd wel gewoon mijn vakgebied in de gaten.
Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1575 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1272 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 1000 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 528 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0