diff --git a/API-strategie-algemeen/Inleiding/api-strategie-overheid.md b/API-strategie-algemeen/Inleiding/api-strategie-overheid.md index dd92518f..0a93de54 100644 --- a/API-strategie-algemeen/Inleiding/api-strategie-overheid.md +++ b/API-strategie-algemeen/Inleiding/api-strategie-overheid.md @@ -41,7 +41,7 @@ Iedere organisatie zou voor ontsluiting van data en functionaliteit altijd "API * Voor de ontsluiting die je zelf direct realiseert (bijvoorbeeld een website) maak je gebruik van diezelfde interface. Het geeft je omgeving de mogelijkheid om daar waar er voor hen geen geschikte ontsluiting bestaat, deze zelf te maken, als ook om nieuwe mogelijkheden te ontdekken die je zelf nog niet had bedacht. * Wanneer je de API met iedereen deelt geeft het ook je gehele omgeving in de basis een gelijke informatiepositie. * De API first strategie is in lijn met het NORA principe ["bouw diensten modulair op"](https://www.noraonline.nl/wiki/Bouw_diensten_modulair_op) en de bijbehorende implicatie ["wissel gegevens tussen (web)applicaties uit met API's"](https://www.noraonline.nl/wiki/Wissel_gegevens_tussen_(web)applicaties_uit_met_API%27s). -* Maak gebruik van API technieken die breed in de markt ondersteund worden. Dat zorgt ervoor dat benodigde kennis en middelen voor het toepassen eenvoudig verkrijgbaar zijn. Zorg dus voor actuele kennis binnen je organisatie over wat er in de markt speelt, en deel deze kennis met andere organisaties. Op moment van schrijven zijn REST APIs op basis van HTTP en JSON bijvoorbeeld breed ondersteund, maar dat kan in de toekomst veranderen. +* Maak gebruik van API technieken die breed in de markt ondersteund worden. Dat zorgt ervoor dat benodigde kennis en middelen voor het toepassen eenvoudig verkrijgbaar zijn. Zorg dus voor actuele kennis binnen je organisatie over wat er in de markt speelt, en deel deze kennis met andere organisaties. Op moment van schrijven zijn REST API's op basis van HTTP en JSON bijvoorbeeld breed ondersteund, maar dat kan in de toekomst veranderen. * API first is niet alleen een voorwaarde voor moderne IT systemen, het toepassen ervan is ook een middel voor modernisering, zoals Common ground en PSD2 laten zien (zie sectie bedien de omgeving). ### API first voor de omgeving @@ -61,12 +61,12 @@ In de publieke sector zelf zijn API's in sommige onderdelen ook al dominant, CBS De omgeving van organisaties in de publieke sector bedien je het best door hen de mogelijkheid te geven zoveel mogelijk op hun eigen voorwaarden gebruik te maken van data en functionaliteit die je als publieke organisatie aanbiedt. Je moet ze dus niet dwingen om één manier te gebruiken. Tegenwoordig zijn er vele manieren om data & functionaliteit te ontsluiten: -* Websites, -* Mobiele Apps, -* Computer applicaties, +* websites, +* mobiele Apps, +* computer applicaties, * IoT devices, -* Fysieke loketten, -* Brievenpost +* fysieke loketten, en +* brievenpost. Achter al deze ontsluitingsmanieren zit een IT systeem. Het is in de huidige digitale samenleving niet reëel om al deze manieren volledig zelf in de hand te hebben. Door direct toegang te geven tot data en functionaliteit door een API bied je de mogelijkheid om deze via verschillende kanalen aan te bieden. Je kan voor ieder kanaal afwegen of je dat als organisatie zelf aanbiedt of dit aan een andere partij overlaat. @@ -83,24 +83,24 @@ Een aantal beleidsdoelen waarin API's een rol kunnen spelen (met het voor API's * De [Interbestuurlijke Data Strategie (IBDS)](https://realisatieibds.pleio.nl/) is het resultaat van nauwe samenwerking tussen departementen, uitvoeringsorganisaties en koepels van medeoverheden. Het programma zorgt ervoor dat het makkelijker wordt om binnen de overheid verantwoord met data te werken. Een van de speerpunten van het IBDS is het ontwikkelen van overheidsbrede systeemfuncties waaronder een federatief datastelsel waarmee data beter _vindbaar en technisch uitwisselbaar_ wordt. * [EU Data Act of _Datawet_](https://digital-strategy.ec.europa.eu/nl/policies/data-act) De datawet is gericht op eerlijke toegang tot en het gebruik van gegevens. Hierbij worden met name _Internet of Things_ (IoT) apparaten genoemd en middelen voor openbare lichamen om toegang te krijgen tot gegevens die in het bezit zijn van de particuliere sector. De datawet maakt deel uit van de Europese datastrategie. -Voor al deze beleidsdoelen geldt dat API's er een rol in kunnen spelen maar dat de API standaarden en best practices er nog niet altijd in beeld zijn. Onderstaande acties verdienen verankering in het beleid van de organisatie wanneer je API first wil werken. +Voor al deze beleidsdoelen geldt dat API's er een rol in kunnen spelen maar dat de API standaarden en best practices er nog niet altijd in beeld zijn. Onderstaande acties verdienen verankering in het beleid van de organisatie wanneer je API first wilt werken. -### Actie 1: Houdt regie door open API standaarden toe te passen -API's vormen bij de grote platforms van de IT wereld, maar ook al bij nationale leveranciers een essentieel onderdeel van hun strategie. In de relatie met de markt houdt je als overheid de regie door zelf te bepalen hoe informatie middels open API standaarden wordt uitgewisseld. Samenwerking met de markt op basis van open standaarden is wenselijk. Samenwerking op basis van leveranciers eigen oplossingen onder voorwaarden van die leverancier is (hoewel op korte termijn soms aantrekkelijk) op de lange termijn zeer risicovol. Vanwege de kans op "vendor lock-in" maar misschien nog wel meer vanwege de mogelijkheid dat we als publieke sector de controle verliezen over wat er met gevoelige informatie die wij bijhouden gebeurd. Met name als die bij de grote platforms terecht komen. De samenleving verwacht van organisaties in de publieke sector dat we zorgvuldig met hun gegevens omgaan. Het gebruik van niet open standaarden voor gegevensuitwisseling past daar niet bij. +### Actie 1: Houdt regie door open API-standaarden toe te passen +API's vormen bij de grote platforms van de IT wereld, maar ook al bij nationale leveranciers, een essentieel onderdeel van hun strategie. In de relatie met de markt houdt je als overheid de regie door zelf te bepalen hoe informatie door open API-standaarden wordt uitgewisseld. Samenwerking met de markt op basis van open standaarden is wenselijk. Samenwerking op basis van eigen oplossingen van leveranciers onder voorwaarden van die leverancier is (hoewel op korte termijn soms aantrekkelijk) op de lange termijn zeer risicovol. Vanwege de kans op "vendor lock-in" maar misschien nog wel meer vanwege de mogelijkheid dat we als publieke sector de controle verliezen over wat er met gevoelige informatie die wij bijhouden gebeurt. Met name als die bij de grote platforms terecht komt. De samenleving verwacht van organisaties in de publieke sector dat die zorgvuldig met hun gegevens omgaan. Het gebruik van niet-open standaarden voor gegevensuitwisseling past daar niet bij. -## Actie 2: Gebruik APIs bij (ver)bouw van IT systemen -Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT systemen. Dit begint bij het volgen van de lijsten met verplichte en veelgebruikte standaarden van het forum standaardisatie. Daar zijn de verplichte en veel gebruikte API standaarden te vinden. Het toepassen van standaarden is echter het begin, pas ze toe binnen een modulair opgebouwde architectuur volgens de NORA. Maar denk vooral ook na over het ontwerp van je APIs dit moet afgestemd zijn op de behoefte van de afnemers van de API, zorg ervoor dat je de omgeving van je organisatie als ook onderdelen van je eigen organisatie zo goed mogelijk bedient. Het gebruik van APIs maakt het mogelijk verschillende onderdelen van een IT systeem zo veel mogelijk te ontkoppelen (onafhankelijk van elkaar te maken). Dit zorg ervoor dat het systeem in de toekomst met minimale inspanning op nieuwe eisen en uitdagingen is aan te passen. Volg niet alleen bij standaarden maar ook bij het ontwerp de kennis van de markt. Brede marktondersteuning zorgt ervoor dat er veel te kiezen valt als je ondersteuning nodig hebt (of het nu gaat om vinden van geschikt personeel of aanschaf van software). Meer keuze in de markt leid tot lagere kosten. +### Actie 2: Gebruik API's bij (ver)bouw van IT-systemen +Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT-systemen. Dit begint bij het volgen van de lijsten met verplichte en veelgebruikte standaarden van het Forum Standaardisatie. Daar zijn de verplichte en veel gebruikte API-standaarden te vinden. Het toepassen van standaarden is echter het begin, pas ze toe binnen een modulair opgebouwde architectuur volgens de NORA. Maar denk vooral ook na over het ontwerp van je API's. Dit moet afgestemd zijn op de behoefte van de afnemers van de API. Zorg ervoor dat je de omgeving van je organisatie en de onderdelen van je eigen organisatie zo goed mogelijk bedient. Het gebruik van API's maakt het mogelijk verschillende onderdelen van een IT-systeem zo veel mogelijk te ontkoppelen (onafhankelijk van elkaar te maken). Dit zorg ervoor dat het systeem in de toekomst met minimale inspanning op nieuwe eisen en uitdagingen is aan te passen. Volg niet alleen bij standaarden maar ook bij het ontwerp de kennis van de markt. Brede marktondersteuning zorgt ervoor dat er veel te kiezen valt als je ondersteuning nodig hebt (of het nu gaat om vinden van geschikt personeel of aanschaf van software). Meer keuze in de markt leidt tot lagere kosten. -### Actie 3: Deel Kennis over toepassen van API's -Je staat als organisatie in de publieke sector in de uitvoering nooit alleen. Je maakt de functionaliteit niet alleen, je werkt altijd in een keten met andere overheden en niet overheden. De kern van de samenwerking zit voor een significant deel in de koppeling. Daarom is het op een uniforme manier aanpakken van de API's die daar invulling aan geven van belang. Als organisatie in de publieke sector deel je kennis over hoe je dat doet met de hele publieke sector en maakt waar mogelijk hergebruik van wat anderen al hebben gemaakt. Voor API's doen we dat binnen het kennisplatform API's. Daar maken we standaarden en best practices die we met elkaar delen. Het gaat hier om standaarden voor uniformiteit, en interoperabiliteit van API's, maar ook voor over ontwerpkeuzes binnen API's, voor de IT architectuur waarbinnen ze gebruikt worden als ook over de vindbaarheid van API's. We streven ernaar deze binnen bestaande gremia zoals de lijst verplichte standaarden van het forum standaardisatie voor standaarden en de NORA voor architectuur vast te stellen. +### Actie 3: Deel Kennis over het toepassen van API's +Je staat als organisatie in de publieke sector in de uitvoering nooit alleen. Je maakt de functionaliteit niet alleen, je werkt altijd in een keten met andere overheden en niet-overheden. De kern van de samenwerking zit voor een significant deel in de koppeling. Daarom is het op een uniforme manier aanpakken van de API's die daar invulling aan geven van belang. Als organisatie in de publieke sector deel je kennis over hoe je dat doet met de hele publieke sector en maakt waar mogelijk hergebruik van wat anderen al hebben gemaakt. Voor API's doen we dat binnen het kennisplatform API's. Daar maken we standaarden en best practices die we met elkaar delen. Het gaat hier om standaarden voor uniformiteit, en interoperabiliteit van API's, maar ook om ontwerpkeuzes binnen API's, voor de IT-architectuur waarbinnen API's gebruikt worden en over de vindbaarheid van API's. We streven ernaar deze binnen bestaande structuren en afspraken zoals over het toepassen van de lijst met verplichte standaarden van het Forum Standaardisatie en de NORA vast te stellen. ### Actie 4: Zorg dat API's vindbaar zijn Het is niet alleen belangrijk om API's aan te bieden, ze moeten ook door de omgeving gevonden kunnen worden. Het is belangrijk om een balans te vinden tussen vindbaarheid en vereiste inspanning om alle publieke informatie op verschillende plekken actueel te houden. Vindbaarheid verhoog je door het voor makers van API's zo laagdrempelig mogelijk te maken om API's te publiceren. -Praktisch zijn er, afhankelijk van de ambitie en middelen van een organisatie, meerdere manieren voor. Je kan een eigen developer portaal bouwen waar je API's ontsluit toegang regelt (indien nodig) en zorgt voor goede documentatie. Je kan ook hergebruik maken van de catalogi en portalen die de overheid biedt. +Praktisch zijn er, afhankelijk van de ambitie en middelen van een organisatie, meerdere manieren voor. Je kan een eigen developer portaal bouwen waar je API's ontsluit, de toegang regelt (indien nodig) en zorgt voor goede documentatie. Je kan ook hergebruik maken van de catalogi en portalen die de overheid biedt. We werken als publieke sector aan afspraken (zoals in het Federatief Data Stelsel) om de vindbaarheid van API's in catalogi en portalen te vergroten waarbij het streven is dat informatie over API's eenmalig door de aanbieder wordt aangeleverd en in meerdere catalogi en portalen kan worden hergebruikt. -API's moeten waar mogelijk (binnen grenzen openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi. +API's moeten waar mogelijk (binnen de grenzen van openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi.