De (on)wendbaarheid van overheids-IT
Leestijd 8 min
Techredacteur Rutger Otto publiceerde deze maand een artikel op nu.nl dat mij triggerde. Hij schreef over de beperkingen van overheid-IT, waardoor snel inspelen op situaties zoals de huidige hoge inflatie onmogelijk is. Zo zou het kabinet door verouderde systemen van bijvoorbeeld de Belastingdienst, pas in 2023 geld kunnen vrijmaken om de koopkrachtdaling tegen te gaan. Deze kreeg in 2019 al van de Algemene Rekenkamer te horen dat zeker de helft van hun systemen verouderd is. Mij verbaast het dat het niet lukt om sneller en voor langere termijn te verbeteren. Ondanks dat de Belastingdienst met ‘open winkel’ moet ontwikkelen, zijn er absoluut mogelijkheden om de systemen naar het jaar nu te trekken, zonder dat dat tientallen jaren of miljoenen euro’s kost.
Mijn visie & gedachten over overheid & ICT op een rij:
Visie op overheid & ICT
Alles begint met een duidelijke, houdbare visie, die bovendien goed bewaakt wordt. Ieder pakket heeft ownership nodig. Iemand die duidelijk de productvisie kent en niet lukraak het roer omgooit bij de minste of geringste beleidsverandering. Complexe en kritieke systemen als die van de Belastingdienst dien je te behandelen als modern, luxe jacht en niet als speedboot die in enkele seconden 180 graden kan draaien. Volledige flexibiliteit is simpelweg niet mogelijk, want je bouwt softwareoplossingen altijd vanuit een visie voor de lange termijn. Desalniettemin wil je op korte termijn wendbaar genoeg zijn om bij te sturen wanneer zich crises voordoen zoals de huidige. Daarom wil je te allen tijde zorgen dat je oplossing up to date is. Continu onderhouden en updaten van de bestaande infrastructuur zorgt dat je relatief snel kunt doorontwikkelen vanuit een actuele en optimale omgeving, wanneer dat nodig is.
Twee smaken oplossingen
Dan blijft de vraag: hoe leg je de juiste basis voor de toekomst? In het artikel op nu.nl stelt een hoogleraar van de Nyenrode Universiteit dat ‘er jaren aan mensuren voor nodig zijn’ om grote veranderingen door te voeren of een totaal nieuw, wendbaar systeem te bouwen. Ik snap die gedachte, maar nabouwen wat er nu is, is in mijn beleving niet wat je wil. Simpelweg omdat je dan vanuit dezelfde, niet-houdbare visie blijft ontwikkelen. Er blijven twee smaken over hoe het wel zou kunnen. Doorontwikkelen op één enkel solide onderdeel van het huidige systeem, of vanuit data naar je applicatielandschap te kijken en hier per onderdeel API’s voor ontwikkelen, zodat je stukje bij beetje een nieuw landschap creëert dat schaalbaar en flexibel is.
A: Vanuit één basis starten
De eerste optie is de meest traditionele ontwikkelmethode. Wanneer je weet wat je doet kan het een effectieve methode zijn. Je kiest het minst slechte deel van de huidige software en bouwt daar nieuwe delen bovenop, die oude systemen vervangen. Daar is uiteraard een heel leger aan ontwikkelaars voor nodig die de context en beleidsmatige doelen uitermate goed begrijpen, zodat zij de technische invulling hiervoor kunnen uitdenken. Om dit te laten slagen moeten de doelen en visie als een huis staan. Zo moet je heel scherp nadenken over de domeinen: hoe deel je de onderdelen van je software in? Daarnaast moet je een duidelijk visie op data hebben. Migreren gaat altijd fout, of kost op zijn minst bakken met geld en tijd. Daarom vermijd je migraties liever. Verder wil je helder hebben hoe je de systemen nu én in de toekomst aan elkaar koppelt. Een toekomstige module moet goed kunnen aansluiten op wat je nu bouwt. Je kunt nooit alles vooraf bedenken, maar kunt wel bedenken hoe flexibel je het systeem bouwt. Tot slot heb je een hele duidelijke visie op de werkwijze nodig. Hoe koppel je burger, Belastingdienst en wet aan elkaar en hoe verlopen de processen bij verandering in beleid?
B: Denken vanuit data
De tweede methode is gebaseerd op een modernere insteek van ontwikkelen voor publieke instanties: Common Ground. Je behoudt de huidige databases en gaat vanuit de data nieuwe functies ontwikkelen. Dat kan klein beginnen en kun je vervolgens steeds verder uitbouwen, waardoor het steeds meer functies overneemt. Overheden op gemeentelijk niveau gebruiken deze methode al vijf jaar succesvol om van elkaars kennis en ontwikkelingen te kunnen profiteren. Common Ground software wordt namelijk open source ontwikkeld. Dat biedt ook op landelijk niveau grote voordelen, omdat alle partijen in de markt in theorie kunnen aansluiten bij wat al gemaakt is. Aanvullingen, verbeteringen en nieuwe functies wordt in losse ‘lagen’ ontworpen, waardoor updates en wijzigingen veel makkelijker door te voeren zijn dan in de traditionele opzet.
Over de voordelen van Common Ground Software schreef ik in maart dit artikel.
Wanneer is Common Ground interessant?
- Wanneer publiek geld wordt besteed
- Wanneer samenwerking noodzakelijk of gewenst is
- Wanneer er een onderlinge behoefte aan data bestaat
- Extra interessant: wanneer organisaties vergelijkbare rollen invullen (zoals gemeentes binnen de VNG)
Gisteren beginnen
Nee, het zal niet makkelijk zijn om de kolos in enkele jaren compleet van nieuwe software te voorzien, maar er is meer mogelijk dan je denkt om de huidige problemen op te lossen. Een gedegen werkwijze, duidelijke stappen en open source software bieden de uitkomst om de overheid wendbaarder en flexibeler te maken voor de toekomst. Het roer hoeft niet ineens om, maar graad voor graad kunnen we vanuit een duidelijke visie een andere koers gaan varen, waarbij gisteren beginnen, beter is dan vandaag. Zo bekeken, wou ik dat we in 2019 al gestart waren in plaats van nu.
Enthousiast over Common Ground software?
Ben je enthousiast over Common Ground software en wil je weten wat jouw mogelijkheden zijn? Bekijk de speciaal voor Common Ground ingerichte informatiepagina of neem direct contact op.