Op naar een fundament voor API-standaarden (in licht van Common Ground)

Velen van jullie zijn dagelijks bezig om invulling te geven aan de informatiekundige visie van Common Ground. Zoals jullie ongetwijfeld weten is Common Ground in 2016 vol energie gestart vanuit gemeenten. Zij verenigden zich om collectief te werken aan meer grip op hun informatievoorziening. Om daarmee beter te kunnen inspelen op de maatschappelijke uitdagingen. Sinds die tijd zijn er veel projecten gestart zoals HAVEN, NLX en de showcases Huishoudboekje en Registratie Vakantieverhuur.

Een ander gevolg van het inslaan van een nieuwe informatiekundige weg was het ontwikkelen van nieuwe API-standaarden die aansluiten bij het Common Ground-vijflagenmodel en de REST-architectuurstijl volgen.

Naar aanleiding van de eerste ervaringen met implementatie van deze standaarden is een aantal vraagstukken ontstaan dat niet gaat over individuele standaarden, maar raakt aan het fundament onder alle API-standaarden voor gemeenten. Dan ontstaat de vraag “gaan we in hoog tempo door op de huidige weg of maken we pas op de plaats?” Volgens een citaat van Albert Einstein is hierop maar één logisch antwoord mogelijk:

“Insanity: Doing the same thing over and over and expecting a different result.​”

Als we nu ongewijzigd doorgaan met de ontwikkeling van nieuwe APIs-standaarden, is de kans dus groot dat we bij implementatie daarvan aanlopen tegen dezelfde issues als we nu zien bij de bestaande standaarden. Dit moeten niet willen. Maar hoe kunnen we dit voorkomen? Hier kan Einstein opnieuw helpen:

“We cannot solve our problems with the same thinking we used when we created.”

Toen we in 2016 enthousiast begonnen met het invullen van die visie Common Ground stonden we voor een leeg canvas. Het ontbreken van knellende kaders en ontwerprichtlijnen stelde ons in staat met een frisse blik te kijken naar de inrichting van de gemeentelijke informatievoorziening.

Door agile te werken zouden kaders en ontwerpregels waar nodig uit de praktijk ontstaan. Tot op zekere hoogte is dat ook gelukt. API-standaarden binnen één familie (Zaakgericht werken, Haal Centraal) sluiten goed op elkaar aan. Onderling zien we echter (te) veel verschillen. Bovendien lijken onderwerpen als transacties en consistentie en bevragen over meerdere bronnen onvoldoende uitgewerkt.

Zoals het citaat van Einstein al suggereert, vereist het oplossen hiervan een andere denkwijze dan we tot nu toe hebben gehanteerd. Dit betekent in ons geval dat we er niet langer vanuit gaan dat kaders en richtlijnen vanuit de praktijk ‘vanzelf’ ontstaan. Tegelijkertijd willen we bij het invullen van het canvas waken voor ‘horror vacui’ of ‘de vrees voor het lege’, waardoor we niet verder zouden kunnen voordat we voor alle mogelijke problemen een oplossing hebben uitgedacht.

Om dit te voorkomen noemen we die andere denkwijze waarom Einstein vraagt ‘just enough architecture’. Maar hoeveel is ‘just enough’? Dat weten we nog niet precies.

Wel hebben we een aanpak bepaald. We generaliseren concrete issues die bij de implementatie van onze API-standaarden ontstaan. Bij zo’n issue zoeken we naar oplossingsrichtingen die we voorleggen aan gemeenten en leveranciers. Hun en onze opmerkingen daarbij vertalen we vervolgens naar concrete ontwerpregels of -overwegingen. Vervolgens herhalen we dat voor een nieuw issue. Zo ontstaat stap voor stap een API Referentie Architectuur (ARA).

Door het ontwikkelen van ARA doen we iets wat we eerder niet deden. Tegelijkertijd hebben we voor standaarden binnen het Kenniscentrum Architectuur zeer beperkt capaciteit. ARA heeft dus consequenties voor andere werkzaamheden. De ontwikkeling van de API-standaarden voor Klantinteracties en Notificaties is daarom voor nu gepauzeerd.

Maar we zien ook dat juist op het gebied van concrete API-ontwikkeling de komende tijd veel van gemeenten en de VNG wordt verwacht. Het leggen van deze puzzel is dus best complex. Voor nu zetten we in op een werkwijze over twee sporen: spoor 1 lost met het oog op de korte termijn openstaande issues voor de API-standaarden voor Zaakgericht werken op, terwijl spoor 2 zich richt op ARA waarbinnen meer fundamentele oplossingen gezocht en beproefd worden.

Een eerste stap op weg naar ARA hebben we de afgelopen weken gezet. Aanleiding hiervoor waren de problemen rondom performance bij het ophalen van bepaalde gegevenssets middels de API-standaarden voor Zaakgericht werken. Deze issues hebben te maken met het grote aantal ‘calls’ naar verschillende API’s dat nodig is om zo’n set bijeen te krijgen. Vertaald naar een abstracter niveau kan je stellen dat we hier onder andere te maken hebben met problematiek rondom gedistribueerde query’s.

Naar aanleiding van internationale ‘best practices’ en bijbehorende voor- en nadelen hebben we aan gemeenten en leveranciers over dit onderwerp een aantal stellingen voorgelegd. Hoe denken we bijvoorbeeld over convenience API’s en gedeelde databases? Hebben we daarbij een gezamenlijke voorkeur?

Vervolgens werd gekeken naar onderwerpen die volgens de aanwezigen verdere uitwerking verdienen. Daarbij werd aan de volgende thema’s prioriteit gegeven: het stap-voor-stap uitwerken van een API Referentie Architectuur (ARA), domeinafbakening en een verder uitgewerkte oplossing voor autorisaties waarbij onze API-standaarden aansluiten.

Genodigden vonden het een supersessie met goede energie, goede interactie en goede discussies. De oproep was dan ook “Laten de ruimte pakken om dit verder uit te werken. In 2016 zijn we eenvoudig begonnen, nu komt de complexiteit op ons af en dat moeten we samen oplossen”. Om met Stephen Covey af te sluiten:

“Want als we blijven doen wat we deden, zullen we blijven krijgen wat we kregen. ”

Auteurs:  Mascha Kranse (Coördinator Kenniscentrum Architectuur (Mascha.Kranse@vng.nl)) en Ivo Hendriks (Architect Kenniscentrum Architectuur (Ivo.Hendriks@vng.nl))