'We hebben een API ontwikkeld. Nou wie gaat deze beheren?'

Tijdens de fieldlabdagen in Utrecht werken verschillende teams aan toepassingen voor gemeenten. Al deze digitale toepassingen hebben componenten die gebaseerd zijn op het Common Ground principe dat data bij de bron blijft en wordt bevraagd met een API. De data wordt dus niet meer nodeloos gekopieerd en veelvuldig opgeslagen.

De specificaties van deze API’s moeten weer beheerd worden en voor een deel van deze standaarden gaat VNG Realisatie die rol op zich nemen. Deze standaarden worden gebruikt door leveranciers en gemeenten om software te ontwikkelen voor de gemeentelijke dienstverlening.

API-beheer
Standaardbeheerders Robert Melskens en Michiel Verhoef van VNG Realisatie zijn tijdens deze fieldlabdagen aanwezig om userstories op te halen bij de deelnemende teams voor het aanscherpen van het beheerproces. Daarnaast geven ze advies wanneer de ontwikkelde API specificaties in beheer genomen kunnen worden. Het is een proces dat in elkaar overloopt. “VNG Realisatie gaat niet meer met de watervalmethode in een jarenlang ontwikkeltraject standaarden ontwikkelen waarna leveranciers deze pas kunnen implementeren in software”, zeggen Melskens en Verhoef. “In de oude standaard was alles beschreven. Dat heeft geleid tot een veel te uitgebreide en ingewikkelde StUF standaard. Daar zaten ook onderdelen in die uiteindelijk helemaal niet gebruikt werden door leveranciers en gemeenten. Daarnaast ondersteunen de huidige StUF koppelvlakken niet alle functionaliteit die geboden wordt door applicaties. Dat zorgt dan weer voor heel veel maatwerk oplossingen wat gemeenten enorm afhankelijk maakt. Dat vinden gemeenten een onwenselijke situatie. Met deze standaard en met deze werkwijze om de standaard verder te ontwikkelen, willen we voorkomen dat het weer zo ingewikkeld wordt en gemeenten afhankelijk blijven van maatwerk.”

Hoe gaat zoiets in z’n werk? Daar is niet zo lang geleden een goed voorbeeld van in de praktijk gebracht volgens Verhoef. “De gemeente Amsterdam heeft een nieuw meldingensysteem in gebruik. De specifieke melding overlast op het water was nog geen bestaande melding in hun systeem. Dat is een userstory geworden die helemaal beschreven is en is toegevoegd aan de ZGW-standaard. En omdat het in gebruik is leren we weer veel van de implementatie. Ervaringen komen terug en en de standaarden worden zo verbeterd.”

Vervangen van StUF
De ZGW-standaard vervangt de StUF-standaard. Waar we het vorig jaar nog wel eens hadden over de 2.0 versie van de ZGW-standaard wordt dat nu niet langer gedaan. Melskens: “Je zou immers kunnen gaan denken dat de nieuwe ZGW standaard op dezelfde manier werkt als StUF Zaak- Documentservices 1.x biedt. De nieuwe standaard is echter iets compleet anders, zowel technisch als functioneel.”

Is elke gemeente dan betrokken bij de ontwikkeling van de nieuwe ZGW-standaard? Verhoef denkt dat vrijwel alle gemeenten vertegenwoordigd zijn. “’In de wergroep die zich bezighoudt met de ontwikkeling van de ZGW API zijn ruim 30 gemeenten vertegenwoordigd die actief meedenken en mee ontwikkelen. Dit zijn grote, middelgrote en kleine gemeenten. Het Congrestival van woensdag 13 maart is een kans om dit verhaal bij nog meer gemeenten te laten landen. Op Github en portaal (te bereiken via http://ref.tst.vng.cloud/) kan informatie op verschillende niveaus, zowel technisch als functioneel, opgehaald worden.”