Helaas, het toevoegen van nieuwe functionaliteit en semantiek gebeurt niet vaak. Ict-standaarden zijn dan ook gebaat bij kleine verbeteringen.
– Column –
Frank Terpstra
Als productmanager van de StUF-standaard kijk ik graag naar de tuin van mijn buren, naar andere overheidsstandaarden zoals SuwiML. Natuurlijk lijkt het gras dan snel groener. Bij nadere studie vallen daar dan vaak wel weer nuances in aan te brengen.
Voor één onderwerp ben ik er van overtuigd dat het gras van SuwiML objectief, beduidend groener is. Dat betreft het releasebeleid.
Bij StUF doen we aan grote releases waar alle functionaliteit voor de komende jaren in gerealiseerd is. Dit leidt er toe dat we eens in de vijf jaar met een nieuwe standaard komen. Om het in de periode daartussen werkbaar te houden, kennen we allerlei mechanismen om de standaard enigszins flexibel te houden. Helaas, het toevoegen van nieuwe functionaliteit en semantiek gebeurt niet vaak.
Daarnaast is het de vraag wanneer een nieuwe versie van de StUF-standaard daadwerkelijk door leveranciers geïmplementeerd is, en vervolgens bij gemeenten en andere gebruikers uitgerold is. StUF 3 stamt uit 2009, en de brede implementatie ervan wordt eigenlijk nu pas gerealiseerd. Ruim vier jaar later.
Suwi-standaard
Hoe anders gaat het bij de Suwi-standaard. Daar zijn jaarlijkse releases, met vaste implementatietermijnen voor leveranciers en deelnemers in de keten. De mazzel van de Suwi-standaard, of eigenlijk de oorzaak van dit succes, is de Wet Suwi (Structuur Uitvoeringsorganisatie Werk en Inkomen), die dit regime oplegt aan alle betrokkenen.
Nu denk ik niet dat er een Wet StUF moet komen. Toch lijkt een afspraak tussen gemeenten en leveranciers om over te gaan op jaarlijks releasebeleid en bijbehorende implementatietermijnen, mij grote winst voor de StUF-standaard. Effect hiervan zou zijn dat gemeenten een stuk flexibeler om kunnen gaan met veranderingen in hun omgeving. Daardoor kunnen veranderingen in softwaresystemen en processen sneller worden doorgevoerd, en kan niet meer gebruikte functionaliteit sneller uit de standaard worden verwijderd. Het kan ervoor zorgen dat we minder aandacht hoeven te besteden aan complexe vertalingen tussen versies van de standaard. Daarnaast is er, bij het neerzetten van nieuwe functionaliteit, niet meer de noodzaak om vijf jaar vooruit te kijken.
We implementeren alleen datgene dat het komende jaar écht nodig is.
Een jaarlijkse release zou de omvang en complexiteit van de standaard sterk verminderen. Het zou het voor gemeenten gemakkelijker maken om zelf te ontwikkelen, en voor leveranciers laagdrempeliger om in te stappen. Daar staat tegenover dat er met een andere instelling naar het implementeren van de StUF-standaard gekeken zou worden. Het is niet meer iets wat je eenmalig doet, waarna je voor de komende vijf jaar (of langer) klaar bent. Nee, je zal jaarlijks moeten kijken welke applicaties door de verandering in de standaard worden geraakt, en die zul je moeten voorzien van een kleine aanpassing.
StUF-standaard
Mijn gedachte over de StUF-standaard is niet nieuw. Het is een les die ik leerde toen ik begon met programmeren. In één keer een groots idee programmeren zonder alles in stapjes op te hakken, en deze individueel te testen, is moeilijk. En dom. Zeker als je moet voortbouwen op al bestaande systemen. Wat mij betreft kom je met kleine stapjes veel verder…
Geef een reactie