API community 19 november 2019
Bijeenkomst van API-community op dinsdag 19 november 2019, 10.00, locatie: Rijkswaterstaat, Utrecht.
Doel: Kennismaken met elkaar & de API strategie
Doelgroep: Overheidsorganisaties die al API's gebruiken en/of publiceren .
Verslag eerste bijeenkomst API-community gepubliceerd
Het verslag van de eerste bijeenkomst van de API-community in opbouw is gepubliceerd.
Dit was de eerste bijeenkomst van wat we graag de “API-community” willen gaan noemen. We waren te gast bij RWS te Utrecht. De sfeer was goed en ontspannen en we hebben veel informatie met elkaar gedeeld. Ons doel is om de implementatie van de Nederlandse API-strategie te versnellen. We bouwen daarom aan een community van overheidsorganisaties die al API’s gebruiken en/of publiceren, zodat die hun kennis en ervaring gaan delen met elkaar en met (overheids)organisaties die zich nog aan het oriënteren zijn op het gebruik van API’s. Hieronder is op hoofdlijnen aangegeven wat we met elkaar hebben besproken en afgesproken.
API’s geven ons de mogelijkheid een andere vorm van gegevensuitwisseling toe te passen[bewerken]
In die zin staat het gebruik van API’s náást andere vormen van gegevensuitwisseling, zoals via Digikoppeling of via X400. Er zit echter een heel ander gedachtegoed achter het gebruik van API’s. We gaan de gegevens niet meer van elkaar kopiëren om ze daarna zelf te beheren. In plaats daarvan gebruiken we API’s om informatie uit af te leiden en laten ze zo veel mogelijk gegevens bij de bron staan.
Hoe API’s passen in de dienstverlening van de Overheid, willen we kenbaar maken via de NORA[bewerken]
Daarin zijn immers de Nationale afspraken vastgelegd voor het ontwerp van de dienstverlening. De NORA-wiki is een goed werkend platform voor kennisdeling voor architectuur: het ontwerp van de dienstverlening van de overheid. Voor het geven van antwoord op maatschappelijke vraagstukken, hanteren we gewoonlijk drie invalshoeken:
- het maatschappelijke belang;
- het ontwerp van de specifieke dienst (zo mogelijk gerelateerd aan een levensgebeurtenis)
- hoe je daar vanuit een (overheids)organisatie een bijdrage aan kunt leveren.
We zijn dat aan het uitwerken voor API’s[bewerken]
Daarbij maken we natuurlijk gebruik van de API Strategie. Delen ervan gebruiken we voor het maatschappelijke belang en de strategie voor een organisatie. Maar er zijn ook delen die meer passen bij het werk van een architect of (software)ontwerper, zoals het hoofdstuk met ontwerp-principes waaraan API’s moeten voldoen.
We hebben al teksten die jullie kunnen bekijken en van commentaar en aanvullingen kunnen voorzien: API. Jullie review wordt zeer op prijs gesteld! Het werkt net zoals bij Wikipedia, kijk op Help/Bewerken voor meer uitleg. Als je hulp nodig hebt, mail dan gerust naar nora@ictu.nl
We werken natuurlijk ook samen met het Kennisplatform API’s[bewerken]
Daar is een Werkgroep Architectuur actief, die een architectuur ontwikkelt voor API’s. Dat vult dan Hoofdstuk 6 in van de API Strategie. De trekker is Peter Haasnoot (Logius).
Wil je ook deelnemen aan de Werkgroep? Neem dan even contact op via peter.haasnoot@logius.nl
DON (developer.overheid.nl) als Nationale publicatieplek te zijn van overheids-API's[bewerken]
DON, ofwel developer.overheid.nl, is beoogd om dé Nationale publicatieplek te zijn van overheids-API's.== Momenteel zijn daar ca. 30 API’s gepubliceerd. Het zal echter niet de enige plek zijn: diverse organisaties hebben hun eigen plek om API’s te publiceren. Maar op DON mogen alle overheidsorganisaties hun API’s (ook) publiceren.
Wáár we publiceren is op zich niet zo belangrijk, als we maar van elkaar weten waar dat is en dat ontwerpers daar eenvoudig toegang tot hebben! Sommige aanwezigen kennen DON al, anderen hebben het nog niet eerder gezien. Steven Gort (ICTU) kan je veel vertellen over (de plannen met) DON.
De kern is, dat wordt gewerkt aan een Compromisloos, Open Source, Data bij de Bron, platform. DON is daarbij een instrument om verzuiling tegen te gaan c.q. om organisaties te laten ont-zuilen. Om organisaties te flexibiliseren en samen met andere organisaties nieuwe diensten mogelijk te maken.
DON wordt in 2020 doorontwikkeld na een evaluatie[bewerken]
DON is voortgekomen uit een pilot en is gebaseerd op de infrastructuur die vanuit Common Ground wordt beoogd, te weten NLX. Die infrastructuur NLX is echter nog niet afdoende beheerd of in productie genomen. DON wordt momenteel in een tijdelijke exploitatie-omgeving beheerd door een kleine groep experts onder leiding van Eelco Hotting (gemeente Haarlem). Via DigiCampus proberen we het beheer van DON te laten verbeteren, zodat het in een reguliere productie-omgeving kan worden gebruikt door de API’s.
Afgelopen nazomer is een evaluatie geweest van de pilot met DON. Daarin zijn diverse ambities en verbeteringen bepaald. Die worden het komende jaar opgepakt.
Alle API’s die op DON worden gepubliceerd, zijn beschikbaar voor hergebruik.[bewerken]
Maar hoe kan je zoeken in die verzameling API’s? En wat is de kwaliteit van de API’s? Dat zijn we nog aan het uitwerken. Elke API wordt momenteel al op enkele aspecten beoordeeld (Documentatie, Specificatie, Contactgegevens en SLA) en krijgt daarmee een waardering op een schaal van 1 tot 10.
Maar wanneer vinden we een API eigenlijk goed? We denken daarbij aan zaken als:
- voldoen aan de Open API standaard
- conform de API-ontwerp-richtlijnen
- als de ontwikkelaar er wel wat mee kan
- als de API goed is beschreven
- als de ontwerper hem meteen kan gebruiken
enz.
API als middel, niet als doel[bewerken]
Duidelijk is, dat wij een API niet als het doel zien, maar als een middel voor gegevensuitwisseling en gegevensontsluiting bij de bron. Op bestuurlijk niveau worden API’s echter gepresenteerd als het nieuwe panacee. Het wordt daar tot doel gesteld en niet als middel.
Het risico bestaat dat daarmee op bestuurlijk niveau minder aandacht bestaat voor de WAT en WAAROM vraag en de aandacht te veel wordt gericht op de HOE vraag. De toepassing van API’s kunnen we beschrijven aan de hand van het NORA vijflaagsmodel: Een API geeft invulling aan de informatiebehoefte op het niveau van processen (in de organisatorische laag). Aangezien een API zelf een stuk software is, manifesteren API’s zich op de applicatielaag (waar ook registraties in kaart worden gebracht). Via een informatiemodel kan de relatie tussen de organisatorische laag en de applicatielaag in beeld worden gebracht (informatielaag).
Context (lagen) is van belang voor de werking c.q. effectiviteit van een API.[bewerken]
Als bijvoorbeeld de gegevens in een bron-registratie niet juist zijn, dan is de uitkomst van de API ook niet juist, met alle mogelijke consequenties voor de dienstverlening.
Diverse organisaties, zoals Microsoft, hebben handboeken geschreven over hoe je goed met API’s kan omgaan. Het lijkt verstandig dat we dat soort handleidingen gaan volgen vanuit Nederland, omdat het hier om wereldwijde ontwikkelingen en standaarden e.d. gaat. We moeten er ook rekening mee houden dat steeds sneller nieuwe standaarden naar voren komen: “over 2 jaar is er weer iets anders nodig”.
Ingebracht vanuit de deelnemers[bewerken]
VNG: Agile aan de slag i.p.v. vanuit theoretische informatiemodellen[bewerken]
Vanuit VNG werd als voorbeeld aangegeven dat vroeger systemen werden ontsloten door wijze heren die een informatiemodel maakten in de ivoren toren. En dat dat informatiemodel werd gebruikt voor de uitwisseling van gegevens: vroeger in SOAP XML en nu JSON. Daar zijn ze van teruggekomen. Ze werken nu met een Agile en Scrum methode en gaan niet meer uit van een informatiemodel, maar van User Stories. Ontwerpers van het Scrum-team proberen de vraag op te halen: welke diensten moeten aangeboden worden?
RvIG: Omslag nodig bij beheerorganisatie[bewerken]
Dat speelt ook bij het RvIG. Bij de beheer-organisatie zal een omslag gemaakt moeten worden. De behoefte aan gegevens uit de BRP is ook via API’s in te vullen. Dat zien we bij de toepassing van IRMA, waarbij gegevens uit de BRP worden gekopieerd naar de “wallet” van de betrokkene. Of via het gedachtegoed van Self-Sovereign Identity (SSI), waarbij een verklaring vanuit RvIG “deze persoon is ouder dan 18 jaar” al zou volstaan. Daarmee komen behoeftestelling en invulling dichter bij elkaar. Nu is het Logisch Ontwerp van de BRP bijvoorbeeld wel beschikbaar, maar dat is een boekwerk van 300 pagina’s. Via een goed opgezet informatiemodel kan een ontwerper straks via DON of NORA in drie klikken al de relevante informatie beschikbaar krijgen.
KvK: Van buiten naar binnen en van binnen naar buiten denken[bewerken]
En het speelt ook bij de KvK. Die wijzen analisten op het denken van buiten naar binnen en van binnen naar buiten. Het Handelsregister (HR) is op een bepaalde manier gemodelleerd, maar dat is wel 10-15 jaar geleden gebeurd. De moderne Resource-modellen staat daar zowat haaks op. Met analisten is het lastig om het gesprek te voeren over hoe we de API’s moeten modelleren. In 2014 begonnen we met API management. In 2015 zijn de eerste API’s de eerste gepubliceerd. Dat was een compromis: nog niet goed vanuit de Restful gedachte. Het Handelsregister moeten we als bron goed ontsluiten. Ook via Restful API’s. Dat kost heel echter veel tijd, vanwege de interne discussies.
Organisaties worden afhankelijk van de API van andere organisaties[bewerken]
Als het aanbieden van API’s door de ene organisatie van belang is voor de continuïteit van de processen en/of diensten van een andere organisatie, dan kunnen we daar beter goede afspraken over gaan maken. Dit is wellicht het meest belangrijke aspect dat we met en van elkaar kunnen gaan leren.
We gaan elkaar immers real time bevragen i.p.v. dat we op afspraak enorme datasets overzetten. Ook als leverende organisatie moet goed worden nagedacht over de impact daarvan qua beschikbaar stellen (24 x 7 e.d.). Feitelijk zullen organisaties dus 2 soorten diensten gaan leveren: op de bestaande manier (Digikoppeling e.d.) en via API’s.
Is er draagvlak voor een API-community?[bewerken]
Het is duidelijk dat veel overheidsorganisaties al aan de slag zijn met API’s of zich daarop oriënteren. De aangeschreven groep (waaronder dus de aanwezigen) zijn duidelijk de voorlopers. Zijn jullie bereid om je eigen ervaringen te delen? Mogen andere collega’s contact met je opnemen? In dat geval helpt het om jezelf kenbaar te maken in het netwerk.
We hebben daartoe alvast een overzicht gemaakt: API-contactpersonen. Zou je deze info aub willen bekijken en zo nodig aanvullen en corrigeren?
Welke vraagstukken en issues spelen bij de organisaties?[bewerken]
We hebben dit in een “rondje langs het veld” verkend:
- CJIB: sommige API’s zijn niet veilig: hoe gaan we dat verbeteren?
- RvIG: we zitten doorgaans nog op X400 protocollen en willen nu een omslag maken naar API’s om sneller op business behoefte in te spelen: hoe moeten we dat aanpakken?
- RDW: hoe kan je het beste omgaan met het onderscheid tussen gesloten en open data?
- RIVM: onze 1e API gaat half januari 2020 live in een test omgeving: we horen graag van anderen wat we wel of niet moeten doen.
- Logius: als je het werken met API’s wilt professionaliseren, welk API-managementsysteem gaan we dan gebruiken?
- KvK: Een tijd geleden zijn de eerste API gepubliceerd: hoe zorgen we er voor dat degenen die nu onze API gebruiken weten dat we overgaan op een nieuwe versie?
- KvK: aanbesteding voor (onderdelen van) een API management systeem duurt erg lang en voelt ook erg watervalliger aan: hoe kan je dat voorkomen of versnellen?
- RDW: een aantal APIs is beschikbaar gesteld op socrata platform: hoe kunnen we doorgroeien naar andere platformen?
- VNG: hoe zorgen we voor een veilige infrastructuur voor API’s, zoals NLX?
- ICTU en BZK: hoe borgen we de continuïteit van deze beweging naar API’s? Dat het niet wordt teruggespeeld als een technisch dingetje? En welke rol speelt het beheer van DON, NLX, NORA enz. daarbij?
Op de vraag of ook het bedrijfsleven kan deelnemen, kan geen eenduidig antwoord worden gegeven.[bewerken]
Alle informatie die op NORA wordt gepubliceerd is in elk geval openbaar en ook private partijen kunnen daar informatie aan toevoegen. Verder streven we bij veel diensten naar Publiek-Private Samenwerking en is het dus logisch dat ze daaraan kunnen deelnemen 😊. Ook ontstaan meer en meer portalen waar zowel publieke als private diensten bij elkaar worden gebracht, zodat het aansluit bij levensgebeurtenissen van burgers en bedrijven.
DON is echter geheel gericht op Overheids-API’s: daar worden geen API’s opgenomen van private partijen.
Vervolg[bewerken]
Dit was de eerste bijeenkomst. Wat ons betreft komen we elke 2 a 3 maanden bijeen om onze kennis en ervaring te delen.
We gaan dan nader in op de vraagstukken die naar voren zijn gebracht, zodat we telkens een stapje verder komen in het oplossen van issues bij jullie organisaties. Van de bijeenkomsten wordt verslag gemaakt en dat wordt gepubliceerd in de NORA.
Tot zo ver. Als je opmerkingen hebt of aanvullingen, stuur dan aub even een mail, zodat we daar de volgende keer op kunnen terugkomen.
Met hartelijke groet, Eric Brouwer