Eigenschap:Beschrijving
Naar navigatie springen
Naar zoeken springen
Type eigenschap
:
Tekst
Geldige waarden
:
Meerdere waarden toegestaan
:
Nee
Weergave op formulieren
:
Tekstvak
Initiële waarde
:
Verplicht veld
:
Nee
Toelichting op formulier
:
Deze elementeigenschap kan gebruikt worden om een element te voorzien van een beschrijving.
Subeigenschap van
:
Formatteerfunctie externe URI
:
Klik op de button om een nieuwe eigenschap te maken:
A
Verslag eerste bijeenkomst API-community gepubliceerd +
[[Afbeelding:Presentatie API's Youetta 2.jpg|thumb|rigth|350px|Presentatie API's en de samenwerkende overheid|alt=Presentatie in vergaderzaal over het onderwerp API's en de samenwerkende overheid”|link=API’s en de samenwerkende overheid]]
Youetta de Jager (ICTU, senior consultant) neemt de deelnemers mee op reis met de API-strategie van de overheid. Maar wat is eigenlijk zo’n API? Wat kan een API en wat weten we er al over? NORA ondersteunt de community in het ontwikkelen van een strategie en het gebruik van API’s. Waar is behoefte aan bij dit thema?
Door [[API|API’s]] (Application Programming Interfaces) kunnen computerprogramma’s communiceren met een ander programma. Het zijn programmeerbare blokjes waarmee een dienst slim samengesteld kan worden. API’s bieden mogelijkheden voor privacy-by-design. Er zijn bijvoorbeeld API’s die alleen ja/nee antwoorden geven. Daarmee kan het gebruik van Self Sovereign Identity worden gerealiseerd.
“Tot nu toe is er veel technisch werk verricht. Er liggen bijvoorbeeld standaarden voor API’s”, vertelt Youetta. “Dar gaat nog vooral om de vraag: welke data zitten erin? Als gebruiker wil je weten hoe robuust zo’n dienst gebouwd is. Bijvoorbeeld: deze API is 24/7 beschikbaar. Of: deze API is geschikt voor meer dan 10000 gebruikers.”
Ze heeft een [[media:Mindmap API's en de samenwerkende overheid.pdf|Mindmap (PDF, 80 kB)]] gemaakt over API’s en nodigt iedereen uit: “Werk mee, denk mee, vul aan.”
===Waar hebben deelnemers behoefte aan?===
* “Help ons standaarden beter te begrijpen.”
* “Vindbaar maken en bieden van standaarden.”
* “API’s kunnen plotten op alle architectuurlagen. Structuren.”
* “Hoe maken we de transitie naar op API’s gebaseerde diensten?”
* “Omschrijvingen van API’s vanuit de behoefte van de eindgebruiker en eisen aan de dienst.”
* “Behoefte aan organisatie die API’s publiceert en beheert: een soort API Management Platform.”
* “Gemeenten werken samen in de Common Ground. We zijn al met API’s bezig. Eigenlijk wil je dat ook landelijk als overheid. NORA kan een rol hebben in het bij elkaar brengen van die ontwikkelingen.“
==Voorbeelden==
Er zijn voorbeelden beschikbaar, vertelt Youetta. “Uber heeft architectuur met API’s, ook de Belastingdienst heeft voorbeelden. Er zijn mogelijkheden kennis uit te wisselen.” In NORA staan al namen van organisaties die met API’s werken, met contactpersonen erbij.
“Wat verwacht je van NORA?”, vraagt Youetta. “Focus op het gemeenschappelijke niveau. Domeinspecifiek hoort bij de domeinreferentie architecturen.” Youetta vertelt wat er al gebeurt: “We maken een verbinding tussen het Kennisplatform API’s en de NORA. Ontwerpvragen als ‘Hoe ontwerp ik een API?’ pakt developer.overheid.nl op. Op dat platform worden ook de API’s gepubliceerd.”
Het gedachtengoed van API’s wordt verwerkt in de NORA in de themapagina [[API]].
<div class="inspring pijl">[[media:Mindmap API's en de samenwerkende overheid.pdf|Mindmap API's en de samenwerkende overheid (PDF, 80 kB)]]</div>
[[Afbeelding:Presentatie API's Youetta 1.jpg|thumb|none|350px|Presentatie API's en de samenwerkende overheid|alt=Presentatie in vergaderzaal over het onderwerp API's en de samenwerkende overheid”|link=API’s en de samenwerkende overheid]]
ASN is een standaard manier voor het beschrijven van data die binnen een netwerk verzonden of ontvangen worden.
Abstract syntax notation one (ASN.1). ASN.1 wordt veel gebruikt voor het beschrijven van X.509 certificaten en de toepassing ervan. Voorbeeld van een toepassing is RSA public key voor beveiliging van het transactieverkeer in de elektronische handel. Hiernaast beschrijft deze standaard rollen en structuren om data in telecommunicatie en computer netwerken te representeren, te coderen, over te brengen en te decoderen. Hierdoor is het mogelijk grote hoeveelheden gegevens geautomatiseerd te valideren aan de hand van specificaties met behulp van software tools. +
Europese verordening die Nederland heeft verwerkt in [[Uitvoeringswet AVG]]. +
De overeenkomst bestaat uit het werkend opleveren en vervolgens het ter beschikking stellen van een burgerzaken-applicatie, inclusief onderhoud en ondersteuning. De burgerzaken-applicatie draait off-premise, waarbij de verantwoordelijkheid voor de hostering en onderhoud van de burgerzakenapplicatie bij de inschrijver ligt (SAAS). +
Deze aanbesteding betreft het verwerven van software verdeeld over 2 percelen:
<ul>
<li>Perceel 1: Opleveren en ter beschikking stellen van een taxatieapplicatie die als SaaS wordt aangeboden, inclusief hosting, onderhoud en ondersteuning;</li>
<li>Perceel 2: Opleveren en ter beschikking stellen van een applicatie voor (BAG-)objectenbeheer die als SaaS wordt aangeboden, inclusief hosting, onderhoud en ondersteuning.</li>
</ul> +
==Beschrijving==
Diensten zijn vindbaar, eenduidig gedefinieerd; afnemers kunnen ze na het afsluiten van een overeenkomst gaan gebruiken en het gebruik beëindigen.
* Bekendmaken diensten:
** Afnemers moeten bekend zijn met de locaties waar beschikbare diensten zijn te vinden en die gebruiken. Voorbeeld: Een afnemer weet dat developer.overheid.nl diensten worden aangeboden en kijkt hier regelmatig.
** Aanbieders moeten in staat zijn aangeboden diensten begrijpelijk te publiceren op voor afnemers vindbare locaties. Voorbeeld: Een aanbieder publiceert diensten in een catalogus zoals developer.overheid.nl.
* Documenteren diensten:
** Afnemers moeten in staat zijn om op basis van beschikbare documentatie de functionaliteit van een dienst te begrijpen. Voorbeeld: Een afnemer kan OAS-specificaties, gebruikt bij documentatie van API’s volgens de REST-stijl, begrijpen.
** Aanbieders moeten diensten zodanig documenteren dat afnemers ze kunnen begrijpen. Vooorbeeld: Een aanbieder gebruikt de OAS-specificatie om API’s volgens de REST-stijl te beschrijven.
* Testen diensten:
** Afnemers moeten in staat zijn om diensten te testen voordat zij beslissen over al dan niet gebruik ervan. Voorbeeld: Een afnemer gebruikt tooling zoals Postman om aangeboden REST API's te testen.
** Aanbieders moeten testfaciliteiten aanbieden die afnemers kunnen gebruiken. Voorbeeld: Een aanbieder stelt een Postman-collectie beschikbaar waarmee afnemers met de tool Postman beschikbare REST API’s kunnen testen.
* Afsluiten overeenkomst:
** Afnemers moeten in staat zijn om te voldoen aan de aansluitvoorwaarden, diensten in gebruik te nemen en gebruik te beëindigen. Voorbeeld: Een afnemer sluiten een overeenkomst met de KVK om de dienst 'KVK Handelsregister Vestigingsprofiel' te mogen gebruiken, neemt de dienst in gebruik en stuurt een brief of email als hij wil stoppen met gebruik van de dienst.
** Aanbieders moeten aansluitvoorwaarden kunnen bepalen, overeenkomsten met afnemers kunnen afsluiten en controleren op plaatsvindend gebruik. Voorbeeld: De KVK sluit een overeenkomst af met een afnemer die voldoet aan de voorwaarden om van de dienst gebruik te mogen maken, verleent toegang tot de dienst, controleert op correct gebruikt en beëindigt het dienstgebruik na ontvangst van een brief of email met het verzoek daartoe.
Het aspect 'aanpassingsvermogen' staat voor het tijdig en adequaat reageren op onverwachte gebeurtenissen; ofwel juist reageren.
#Regels zijn op verschillende plaatsen gemodelleerd en daardoor kost het aanpassen relatief veel doorlooptijd.
Architectuurprincipe ARB-04: Implementatieonafhankelijk
Onder techniek-onafhankelijk modelleren verstaan we dat regels los van de IT–technologie gemodelleerd dient te worden. Het IT-landschap is gestandaardiseerd d.m.v. een applicatie-architectuur waarbij aansluitvoorwaarden en Quality of Service vooraf zijn geformuleerd.
'''Hoe bevordert techniek-onafhankelijk modelleren de wendbaarheid?'''
Het bouwblok ‘aanpassingsvermogen’ verstevigt de wendbaarheid doordat regels en regelsets los van de technische implementatie worden gemodelleerd. Daardoor is er de vrijheid gecreëerd om de technische architectuur van de oplossing aan te passen over het verloop van tijd zonder de regels daarbij aan te passen: het vergroten van het aanpassingsvermogen.
Architectuurprincipe ARB-02: Hergebruik
Als de wetgeving wordt aangepast, dient de (bron) van de wet opnieuw geïnterpreteerd te worden en de impact voor de omgeving binnen de uitvoeringsorganisatie te worden bepaald.
De wijzigingen worden met behulp van een wijzigingsradar gemonitord en vastgelegd. Indien de kennis van de interpretatie van de wet is vastgelegd in een conceptueel model, dient het model tegen het licht van de nieuwe wetgeving te worden gehouden en zo nodig te worden aangepast.
Een impactanalyse kan plaatsvinden op basis van de verschillen tussen het huidige en het nieuwe conceptueel model: in de impactanalyse komen de consequentie(s) van de gewijzigde normen voor de verschillende vingers terug; zie [[Leidraad Regelbeheer Van wet naar loket#De hand met de vijf vingers|de hand met de vijf vingers]].
De geïmplementeerde regels/regelsets voor verschillende toepassingen dienen los van elkaar te worden geïmplementeerd, zodat conform Service-Oriented-Architecture–standaarden regels/regelsets aangeboden kunnen worden aan verschillende afnemers.
==Doel==
Zorgdragen dat de overheid gegevens kan uitwisselen tussen de eigen overheidsorganisaties onderling en met personen en publieke en private organisaties buiten de overheid.
==Scope==
De overheid wisselt gegevens uit met burgers, bedrijven en instellingen, zowel nationaal als internationaal. Digitale aansluiting helpt, ondersteunt, de overheid bij de diversiteit aan aansluitingen die daarvoor worden gebruikt. Daardoor kunnen zowel de overheid als de partijen waarmee zij gegevens uitwisselt, zich richten op de gegevens i.p.v. op de (technische belemmeringen van) het aansluiten.<br />
Wij zien verschillende ontwikkelingen op dit moment plaatsvinden m.b.t. het digitaal aansluiten van en met de overheid.
Uitwisselstandaarden worden breed ingezet, en met name internationaal zijn nog de nodige ontwikkelingen gaande. Het toepassen van (RESTful) API’s heeft een vlucht genomen.
Daarnaast zien wij een belangrijke ontwikkelingen als SSI opkomen.
Uitwisselstandaarden:
Instituten binnen de overheid hebben te maken met diverse digitale contacten zowel binnen als buiten de overheid, nationaal en internationaal. Het gaat hier om verschillende uitwissel standaarden, denk aan Digikoppeling, eDelivery. Uitwisselstandaarden waarvan de toepassing verplicht is vanuit nationale wetgeving of internationale verordeningen of anderzijds brede toepassingen kennen in de markt.
De verschillende standaarden geven ieder haar eigen beheerlast en daarbij behorende kosten.
Door deze vanuit digitale aansluiting als onderdeel van de GDI aan te bieden wordt het voor de betrokken instituten eenvoudiger om aan te sluiten. Voor de afnemende partijen is het handig dat zij niet met iedere aangesloten (overheids-)instantie apart een aansluiting moeten inregelen.
API:
Bij toepassen van API’s spelen hele andere zaken. Een API is een hele eenvoudige interface, zeker t.o.v. de eerdergenoemde uitwisselstandaarden, met vele toepassingen. Zonder een strategie, een set van afspraken en ondersteuning zal dit tot een wildgroei van API’s leiden.
Figuur API Ecosysteem
Het is van belang dat er voor API’s binnen de GDI, een overheidsbrede omgeving komt die leveranciers en afnemers ondersteunt bij het ontwikkelen en gebruik van de overheids API’s. Hierdoor wordt het bijvoorbeeld voor ontwikkelaars eenvoudiger om de definities van overheids-API’s te vinden en daarop applicaties te bouwen. Bestaande API’s kunnen worden hergebruikt en indien nodig worden gebruikt als basis voor nieuwe API’s.
Bij het toepassen van API’s voor het uitwisselen van gevoelige data, zoals persoonsgegevens, is het van belang dat er een éénduidige beveiligingsstrategie wordt opgesteld en daaraan, vanuit digitale aansluiting, ondersteuning wordt gegeven.
SSI
Een andere ontwikkeling die de komende jaren zijn toepassing binnen en buiten de overheid gaat vinden is Self Sovereign Identity (SSI). Hierbij ligt de nadruk niet langer meer op het halen van data uit een bron maar meer op de herleidbaarheid van de bron van de data. Deze bron zou ook buiten de overheid kunnen liggen. Een belangrijk onderdeel van de SSI infrastructuur is de zogenaamde Identity Trust Fabric (ITF). De laag waarin het publieke deel van digitale identiteiten worden opgeslagen, is in Figuur 3 weergegeven als ‘Layer One: DID Networks’. Tegen deze laag wordt binnen SSI de digitale identiteit van personen, systemen, bronnen, documenten, etc. etc. gecontroleerd.
Figuur Architectuurlagen Self Sovereign Identity
Met een ITF die openbaar, zowel publiek als privaat, beschikbaar is wordt het
ontwikkelen van breed inzetbare SSI applicaties eenvoudiger. Digitale toegang
zou de ontwikkeling en ondersteuning van een dergelijke ITF op zich moeten
nemen.
Implicaties Digitale aansluiting ondersteunt bij het toepassen van de diverse
uitwisselstandaarden waar de overheid mee wordt geconfronteerd. Dit
vereenvoudigt het werk van de betreffende instituten en maakt het ook voor
de afnemers eenvoudiger om met de overheid uit te wisselen.
Verder ondersteunt Digitale aansluiting de uitrol van API’s binnen en buiten de
overheid. Door het leveren van overheidsbrede ondersteunende diensten zal
de ontwikkeling en toepassing van overheids API’s eenvoudiger worden en
daardoor versnellen. Denk hierbij het verder uitbouwen van het overheids API
register tot een volledige Overheidsbrede API Store en het leveren van een
API gateway voor de overheid.
Om de ontwikkeling van SSI gerelateerde applicaties te ondersteunen levert
digitale aansluiting een Identity Trust Fabric in een publiek private
samenwerking om een brede toepassing van deze SSI applicaties mogelijk te
maken.
Om de aansluiting veilig te laten verlopen zijn certificaten vereist. Uitgifte van
en toezicht op certificaten moet goed geregeld zijn.
Standaarden:
* Digikoppeling
* Oauth
* OpenID
* JRC
* ASI²
Voorzieningen:
* eDelivery
* OpenPEPPOL
* SDG
* Digipoort
* X-Road
* Common Ground
* NLX
* uNLock
* Hyperledger Indy
* Hyperledger Aries
==Voorbeelden==
Nog te bepalen.
==Status==
Medio 2020 is via een pressure-cooker versnelling aangebracht in de oplevering van GA. Een vijftal werkgroepen heeft in 2 maanden tijd uitwerking gegeven aan:
* ‘Why’ van de GDI inclusief bijbehorende visual,
* uitgangspunten voor het vastleggen van generieke functies (capability’s),
* visies voor de domeinen Interactie, Gegevensuitwisseling, Identificatie en Authenticatie (Toegang), Machtigen en Infrastructuur.
Resultaten van de pressure cooker zijn overgedragen om mee te nemen in de GDI Architectuur (GA). GA brengt samenhang aan, verwijdert dubbelingen en verdiept visies zodanig dat besluitvorming in de PL en (naar beoordeling door PL) in het OBDO mogelijk is. Voor het domein Interactie geldt dat bovendien nog afstemming met de beleidsomgeving moet plaatsvinden. Gegevensuitwisseling heeft nu nog een bredere scope dan GDI en zal daarom binnen de GDI-context in samenhang met andere domeinen uitgewerkt worden.
==Documentatie==
De visie uit de pressure cooker GA t.a.v. Infrastructuur is opgenomen in het document van de werkgroep: [[media:GO_Pressure_Cooker_Infrastructuur.pdf|GO_Pressure_Cooker_Infrastructuur.pdf (PDF, 1,79 MB)]].
==Naamgeving==
Het visie document uit de pressure cooker gebruikt voor deze capability de naam '''Digitale aansluiting'''
Het doel van deze aanbesteding is te komen tot een overeenkomst met één Opdrachtnemer voor het verlenen van Diensten voor het aanvragen, onderhouden en beheren van (Data)Verbindingen aan Provincie Gelderland. Het betreft op dit moment o.a. ruim 130 verbindingen richting ruim 155 VRI-installaties.
Het beheer van verbindingen richting VRI-installaties werd voorheen verzorgd door de ICT-afdeling van Provincie Gelderland in nauwe samenwerking met afdeling Beheer Onderhoud Wegen (BOW). Bij de afdelingen ICT en BOW is een verschuiving van werkzaamheden gaande: van zelf doen, naar regie. De operationele handelingen worden als dienst belegd.
Provincie Gelderland is op zoek naar een leverancier die de werkzaamheden kan uitvoeren en de provincie kan 'ontzorgen'. De taken die niet meer tot het primaire aandachtsgebied behoren, moeten opnieuw worden ingevuld. Dit voornamelijk op onderstaande punten:
<ol>
<li>Nieuwe verbindingen</li>
<li>Monitoring</li>
<li>Verstoringen</li>
</ol> +
Circulaire van de Minister-President, Aanwijzingen waarbij de wetgevingstechniek en de wetgevingskwaliteit centraal staan. Hoofdstuk 5, paragraaf 8 behandelt de Informatievoorziening en Gegevensverwerking. Bevat de aanwijzigingen:
Aanwijzing 5.31. Aansluiten bij definities basisregistraties
Indien voor de uitvoering van een regeling gegevens van burgers, bedrijven of instellingen nodig zijn, wordt voor de omschrijving van de daaraan ten grondslag liggende begrippen zoveel mogelijk verwezen naar of aangesloten bij de definities uit de wetten inzake de basisregistraties
Aanwijzing 5.32. Informatieparagraaf in toelichting
Indien voor de uitvoering van een regeling de beschikbaarheid of uitwisseling van informatie tussen overheidsorganisaties van betekenis is, wordt in een aparte informatieparagraaf in de toelichting aandacht besteed aan de wijze waarop de informatievoorziening organisatorisch en technisch is ingericht.
Aanwijzing 5.33. Verwerking van persoonsgegevens
Bij het opnemen in een regeling van bepalingen over de verwerking van persoonsgegevens bevat de regeling een welbepaalde en uitdrukkelijke omschrijving van de doeleinden van de gegevensverwerking en bevat de toelichting een expliciete afweging van de belangen van verantwoordelijken en betrokkenen in relatie tot die doeleinden.
Aanwijzing 5.34. Structurele basis verstrekking persoonsgegevens
Indien het noodzakelijk is dat op structurele basis wordt voorzien in de onderlinge verstrekking van persoonsgegevens tussen bestuursorganen of toezichthouders, terwijl geldende geheimhoudingsbepalingen daaraan in de weg staan, wordt op het niveau van de formele wet voorzien in een uitdrukkelijke regeling van de gegevensverstrekking, met inbegrip van de vaststelling van het doel van de gegevensverstrekking. +
Abonnementservice die een automatisch bericht afgeeft wanneer er iets verandert in de registratie van voor de afnemer van belang zijnde WOZobjecten. Alle wijzigingen worden gebeurtenisgedreven aangeleverd.
Een afnemer kan zich abonneren op alle WOZ-objecten of op de gegevens van één of meer waterschappen.
Abonnementservice WOZ loopt via Digilevering. +
In 2007 heeft de Tweede Kamer het Kabinet gevraagd een plan op te stellen voor de bevordering van het gebruik van open standaarden voor overheidstoepassingen. Eind 2007 is het actieplan “Nederland Open in Verbinding” (NOiV) door de Tweede Kamer aangenomen. De doelstellingen van dit actieplan zijn
van toepassing op de rijksoverheid, de mede-overheden en de (semi-)publieke sector. +
Voor de komende periode van 2 jaar moeten voor de rijkswegen in Nederland de monitoringdata voor geluid, luchtkwaliteit en stikstofdepositie worden geactualiseerd en verwerkt. +
De mate waarin gegevens recent genoeg zijn. +
Geeft persoonsgegevens van alle op een adres ingeschreven personen. Bevragen kan met een adres als ingang of met persoonsgegevens als ingang. +
Verstrekking van gegevens van een bepaalde ingeschrevene naar aanleiding van een door afnemer gestelde vraag. +
Elektronische handtekeningen worden gebruikt voor het ondertekenen van digitale berichten. Een elektronische handtekening is voor de ontvanger het bewijs dat een elektronisch bericht inderdaad afkomstig is van de ondertekenaar en dat deze de inhoud van het bericht onderschrijft. Voor het ondertekenen van berichten die een hoger niveau van betrouwbaarheid vereisen, kunnen geavanceerde elektronische handtekeningen of gekwalificeerde elektronische handtekeningen worden gebruikt. De AdES Baseline Profiles zorgen ervoor dat een geavanceerde/gekwalificeerde elektronische handtekening voor de ondertekenaar en ontvanger uitwisselbaar is door eisen te stellen aan de minimale set aan informatie die wordt uitgewisseld.
De AdES Baseline Profiles beschrijven de minimale set aan gegevens die uitgewisseld moeten worden om aan de eisen van een geavanceerde elektronische handtekening te voldoen. Een geavanceerde elektronische handtekening voldoet aan vier eisen:
# De handtekening is op unieke wijze aan de ondertekenaar verbonden;
# De handtekening maakt het mogelijk de ondertekenaar te identificeren;
# De handtekening komt tot stand met middelen die de ondertekenaar onder zijn uitsluitende controle kan houden;
# De handtekening is op zodanige wijze aan het elektronisch bestand waarop zij betrekking heeft verbonden, dat elke wijziging van de gegevens, na ondertekening, kan worden opgespoord. +
Administratieve hygiëne is noodzakelijk om het opstellen, reviewen en valideren van bedrijfsregels met voldoende professionaliteit te kunnen uitvoeren. In dit opzicht is het beheren van bedrijfsregels vergelijkbaar met het beheer van specificaties.
Het versioneren van bedrijfsregels of regelsets is een invulling van dit aspect. Daarnaast moeten juridische en gegevensbronnen onder versiebeheer staan om traceerbaarheidsrelaties zuiver te kunnen leggen.
Ook het zorgvuldig verzamelen en beheren van alle secundaire documentatie is een noodzakelijk kwaad.
Het architectuurprincipe ARB-03 - Traceerbaar kan niet zonder dit aspect worden ingevuld. +
Eenmalige of maandelijkse levering met adresgegevens van een door de gebruiker gespecificeerde set bedrijven. Filtering is mogelijk op diverse criteria, waaronder gemeente, postcode, SBIcode. Het data-formaat van dit product is niet geheel handelsregister-compliant (afwijkende notatie BAG adressen) en levert geen BAG-IDs. Het product wordt naar verwachting uitgefaseerd. +
De persoon of organisatie die een dienst in ontvangst neemt. Dit kan een burger, een (medewerker van een) bedrijf of instelling dan wel een collega binnen de eigen of een andere organisatie zijn. +
Overeenkomst binnen de overheid of een deel (domein of sector) over de inrichting en het toepassen van bepaalde voorzieningen of standaarden. +
Ruwe aantekeningen. [[media:Basiswaarden Afstemmingsoverleg 1.pdf|Presentatie (PDF, 1,2 MB)]] is helaas niet toegankelijk aangeleverd. Neem contact op met [mailto:nora@ictu.nl?subject=toegankelijke%20versie%20presentatie%20Basiswaarden%20Afstemmingsoverleg%201.pdf nora@ictu.nl] als dat problemen oplevert, dan zoeken we samen een oplossing.
==Welkom==
Doel van deze opdracht: Het aansluiten van de kernwaarden op beleidsstukken en maatschappelijke beweging.
Op basis van een constatering van NORA: We zien onvoldoende actualisatie terug.
Het aansluiten van de kernwaarden op beleidsstukken en maatschappelijke beweging.
De Kernwaarden concreter maken door de AP’s te koppelen aan het [[Vijflaagsmodel]].
Kernwaarden worden onderdeel van een beschrijving binnen de NORA; Het moet toegankelijk zijn voor breder publiek dan de architecten. Er zal een link worden gelegd tussen de Kernwaarden en de NORA-principes.
Stel dat iets nog niet in de begrippenlijst staat?
Daar waar nodig gaan we zeker begrippen beschrijven in de NORA
Mark Paauwe kwam met de suggestie om het Kernwaarden te noemen: Iedereen is het eens met de kernwaarden :)
==Bespreking eerste resultaten==
Er is een volledige dekking van alle kernwaarden.
Opmerkingen over de toelichting van Aty, Andre en Marco:
Ad: De NORA vat het begrip ‘dienst’ breed op, namelijk alles wat een overheidsorganisatie doet voor een afnemer. Ik vind de brede definitie uit de NORA van dienst prima. Binnen de NORA vind ik het een van de sterke punten dat het (dienst) zo wordt opgepakt. Onderscheid tussen dienstverlening en bestuurlijke besluitvorming, in de originele definitie van de NORA past dat prima. Het hoeft niet, als het ware opnieuw uitgewerkt te worden, hoe dat zich met elkaar verhoudt.
Ralph: Toegankelijk zit als Basisprincipe onder Doelmatig, maar die kan ook goed passen onder Toekomstbestendig. Dat zou een eerste suggestie zijn; er zijn dus overlappen tussen Basis Principes en Basiswaarden Kernwaarden.
Jan: Mooie vorm van uitwerking; een aantal van de gebruikte begrippen vragen om een scherpere duiding. Het wordt van belang om elke uitwerking te gaan eiken aan het uitbreiden van de scope.
Aty’s voorbeeld over dienst; het is een pracht van een voorbeeld dat een afnemer niet alleen iets mag zeggen over een dienst, zoals toezicht en bewaking, maar dat dat refereert aan laag 1 van dit stelsel. (5laagsmodel?)
Waarschuwing: Ik verwacht dat je elke AP kan relateren aan elk van de Kernwaarden. Kernwaarden komen niet uit een geordend systeem. Ze hebben allemaal met elkaar te maken. Het is een stelsel van grootheden die niet onderling exclusief zijn.
Laurens: Wat mij opvalt: dergelijke conclusies in deze teksten gaan best snel. Terminologie is belangrijk. Pas op met causale verbanden.
Doeltreffend: Effectiviteit: De mate waarin het beoogde resultaat bereikt wordt. Efficacy: Vertaald uit het Engels - Werkzaamheid is het vermogen om een taak in voldoende of verwachte mate uit te voeren. Het woord komt van dezelfde oorsprong als effectiviteit en wordt vaak als synoniem gebruikt, hoewel in de farmacologie nu vaak onderscheid wordt gemaakt tussen werkzaamheid en effectiviteit.
==Architectuur van dienstverlening ==
Herziening van NORA’s architectirpincipes na een uitbreiding van de scope
Wat zou USM daaraan kunnen bijdragen?
Zie presentatie van Jan van Bon.
Marco opmerking: Dienstverlening binnen de overheid als begrip is smal. Men is geen klant van de overheid als het gaat om het begrip dienstverlening. Het gaat ook over de kwaliteit van openbaar bestuur.
Marco: Ook bekend als ' Servitization ' volgens mij. Grote trend in de industrie. Zoals een autofabrikant geen auto's meer wil maken, maar een dienstverlener wil zijn in mobiliteit (bv.). QoS (Quality of Service)
* Ad: “De IV-service zie ik als een van de vele diensten” Ik zie het meer als een ondersteunende services
* Mogelijk om de discussie rondom IV-service of andere gesprekken te transcriberen
Ruwe aantekeningen. [[media:Basiswaarden Afstemmingsoverleg 3.pdf|Presentatie (PDF, 847 kB)]] is helaas niet toegankelijk aangeleverd. Neem contact op met [mailto:nora@ictu.nl?subject=toegankelijke%20versie%20presentatie%20Basiswaarden%20Afstemmingsoverleg%201.pdf nora@ictu.nl] als dat problemen oplevert, dan zoeken we samen een oplossing. +
Ruwe aantekeningen. [[media:Basiswaarden Afstemmingsoverleg 2.pdf|Presentatie (PDF, 748 kB)]] is helaas niet toegankelijk aangeleverd. Neem contact op met [mailto:nora@ictu.nl?subject=toegankelijke%20versie%20presentatie%20Basiswaarden%20Afstemmingsoverleg%201.pdf nora@ictu.nl] als dat problemen oplevert, dan zoeken we samen een oplossing.
==Algemeen voor alle uitwerkingen ==
* Werk omzetten naar het vaste template format (indien dat nog niet gebeurd is)
* Bronvermelding aan het einde van de template (verwijzingen naar Beleidskaders ect.)
* AP’s kunnen betrekking hebben op alle lagen van het Vijflaagsmodel en meerdere Kernwaarden.
==Extra opmerkingen==
Jan van Bon: Kernwaarden zijn geen begrippen met een discrete dimensie. Hier lopen minimaal 3 dimensies doorheen (relatie, doel kwaliteit). Het is onmogelijk dat de begrippen niet overlappen.
==Vertrouwen==
* Vraag: Vertrouwen -> Betrouwbaar (consistent met terminologie van de andere Kernwaarden)
* Vraag: Moeten we Veilig en Vertrouwen uit elkaar trekken?
* Alle AP’s hebben eigenlijk een relatie met Kernwaarde vertrouwen.
* Wellicht kan er worden gekeken of sommige AP’s niet anders geformuleerd kunnen worden, zodat ze meer aansluiten.
* Vertrouwen en Veilig zijn uit elkaar getrokken; Veilig is een van de componenten van Vertrouwen.
* Security wilden Robert en Aty terugzien in Vertrouwen.
* Vertrouwen, daar hoort de mens bij.
* Veilig heeft vooral te maken met wat je doet om te maken dat mensen, systemen etc. echt beschermd worden tegen negatieve invloeden. (Dienstverlening)
* Vertrouwen en Veilig zijn minstens twee kanten van dezelfde medaille.
==Veilig==
* Veilig is iets dat je geregeld moet hebben, zodat je de dienst (daarna) kan aanbieden.
* Beschikbaarheid heeft met vertrouwen te maken; je neemt veiligheidsmaatregelen zodat anderen niet de beschikbaarheid van diensten kunnen beschadigen.
* On-beschikbaarheid kan ook leiden tot onveiligheid, omdat de dienst beschikbaar moet zijn om iets veilig te stellen.
* Veilig heeft niet alleen met afnemers te maken maar ook bij de aanbieder.
* Het is ook een ketending; de hele keten moet veilig zijn. Aan de voorkant moet je je ook afvragen, wanneer je over sourcing nadenkt, of je daarmee voldoende rekening hebt gehouden met veiligheidsaspecten als gevolg van outsourcen van kernactiviteiten of kerninformatie, waarvoor je als organisatie verantwoordelijk bent.
* Ralph: We moeten proberen duidelijk te zijn in wie de actoren zijn.
* Reactie Laurens: Veilig als Kernwaarde is iets dat je hoopt dat in de breedte overheid geadopteerd gaat worden. Hier is het geredeneerd vanuit de dienst, de afnemer en de aanbieder.
* Er moet een verschil kunnen worden gemaakt tussen politiek en overheid, maar daardoor veranderd te waarde niet.
== Toekomstbestendig==
Toelichting; Charmante verwoording, omdat het woord ‘we’ wordt gebruikt. Actieve benadering kiezen. Omschrijving verbreden naar andere overheidsorganisaties.
Suggesties:
* Toekomstbestendig betekent ook dat informatie blievend toegankelijk is voor iedereen die hier (een gerechtvaardigd) belang bij heeft en zo lang als noodzakelijk.
* De dienstverlening van de overheid naar burgers en bedrijven is op de toekomst voorbereid.
==Doeltreffend==
Twee versies van de omschrijving:
# De dienstverlening, handhaving en toezicht van de overheid naar burgers en bedrijven is er op gericht om de mate waarin het beoogde doel wordt gerealiseerd te maximaliseren.
# De dienstverlening van de overheid voldoet maximaal aan hetgeen de samenleving, bedrijven en burgers van deze dienst verwachten.
De essentie is dat je het doel bereikt dat je voor ogen hebt.
Vraag: Begrijpelijk en overzichtelijk naar doelmatig i.p.v. doeltreffend? Antwoord: Nee want je kan bij deze (Doeltreffend; dus effectiviteit) meten of het doel is bereikt.
Suggestie: Toevoegen dat het meetbaar is in de omschrijving.
Onderbouwing om ‘handhaving en toezicht’ weg te laten: Beschrijving van dienst is al: Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de afnemers).
==Doelmatig==
De dienstverlening is zodanig opgezet dat met minimale middelen het beoogde doel wordt bereikt.
Algemene regels over de verhouding tussen bestuursorganen en belanghebbenden bij het voorbereiden, nemen en toepassen van besluiten. +
Alle BIO Thema-uitwerkingen zijn geactualiseerd +
''''Reinvent Government,'''' dagen Steven Gort en Bas Kaptijn (ICTU, Discipl) ons uit.
[[Afbeelding:Presentatie Bas en Steven NORA Gebruikersdag 19 november 2019 (2).jpg|thumb|left|350px|Discipl - a global Society Architecture|alt=Presentatie in vergaderzaal Discipl - a global Society Architecture”|link=Discipl - a global Society Architecture]]
[[Afbeelding:Impressie sessie Society Architecture.jpg|thumb|right|500px|Impressie van oude en nieuwe werkwijze overheidsdienstverlening (volg link in afbeelding voor uitgeschreven beschrijving)|alt=Twee tekeningen onder elkaar met als titels Reinventing Government en Reinvented Government.]]
Als de bestaande organisaties, silo's en administratieve werkelijkheid er niet zouden zijn en je opnieuw zou beginnen, hoe zou je dan vandaag of morgen publieke dienstverlening inrichten?
Voor hen is dit duidelijk: de mens en de behoeften van die mens moeten centraal staan en de rest organiseer je flexibel genoeg om te veranderen als onze behoeften als burgers en samenleving veranderen. Gegevens die nu in silo's van overheden zitten moeten onder regie van de burger komen, bereikbaar vanuit je eigen devices en deelbaar als dat voor jou nuttig is. Wetten, regels, subsidies en toeslagen dienen de mens en moeten dus begrijpelijk worden in je eigen unieke context. Daar kan de techniek een handje bij helpen, als we wetten en regels als open linked data beschikbaar stellen: een persoonlijke app kan jouw gegevens en de wettelijke mogelijkheden voor je uitzoeken en wat in jouw situatie relevant is in heldere taal uitleggen.
In hun visie komt de techniek niet in de plaats van contact tussen burger en overheid, maar maakt dit contact juist menselijker: je uit je behoeften in je eigen woorden en zonder dat je zelf hoeft uit te zoeken bij welke overheidsorganisatie je moet zijn:
‘''Ik wil een betaalbaar huis''’ in plaats van ‘''ik schrijf mij in voor een sociale huurwoning bij deze woningcorporatie''’ & ‘''ik vraag huurtoeslag aan bij de belastingdienst.''’
Doordat de techniek veel wetsinterpretatie en rondschuiven met gegevens uit handen neemt heeft de ambtenaar de tijd om echt contact te leggen met de mensen die dat nodig hebben, terwijl het gros van de diensten automatisch verstrekt kan worden.
Door de dialoog tussen burger en overheid te versterken en te faciliteren groeit het wederzijds vertrouwen. En de flexibiliteit en ruimte die juristen oorspronkelijk hebben ingebouwd in veel wetten komt weer beschikbaar: niet 'computer says no' maar samen met de burger naar oplossingen zoeken.
Hoe willen ze de bestaande organisatie veranderen die hun visie in de weg staat? We lopen als overheid en samenleving tegen bestaande muren op, maar aangezien we die zelf hebben neergezet kunnen we ze ook zelf weer weghalen.
Een concrete toepassing van deze visie waar het discipl-team al ervaring mee heeft opgedaan is het opvragen van waardepapieren bij je gemeente, oftewel verifiable credentials. Hierbij hebben ze gelijk rekening gehouden met de W3C standaard en EIDAS, zodat het in de toekomst mogelijk moet zijn om een uittreksel uit het geboorteregister te krijgen dat overal geaccepteerd wordt.
Een andere opdracht is de waardewisselaar, waar compliance by design een belangrijke factor is. Lees meer over deze toepassingen op [https://discipl.org discipl.org].
: → [[media:Discipl, a global society architecture.pdf|presentatie (PDF, 6,94 MB)]]
==Objectdefinitie==
Betreft een systematisch onderzoek naar en het vaststellen van informatiebeveiligingseisen voor een applicatie.
==Objecttoelichting==
Het object Analyse en specificatie informatiebeveiligingseisen heeft betrekking op niet-functionele eisen, zoals betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid. +
==Objectdefinitie==
Betreft een systematisch onderzoek naar functionele eisen voor een applicatie, bepaald door de business en andere stakeholders.
==Objecttoelichting==
Het analyseren en specificeren van requirements is een proces van het traceren en onderkennen van functionele en niet-functionele requirements waar de te ontwikkelen applicatie aan moet voldoen. Ook worden de constraints geïdentificeerd die zullen gelden in de ontwikkel- en de operatiefases.
Het ontwikkelen van informatiesystemen wordt tegenwoordig veelal uitgevoerd conform de iteratieve ontwikkelmethode (Agile). Onafhankelijk van de methode (traditioneel, Waterval of Agile) is sprake van een aantal ontwikkelstappen waaraan aandacht wordt besteed:
* functionele eisen onder andere: functionaliteiten, gegevens, business rules, presentatie, interactie en foutafhandelingen;
* niet-functionele eisen onder andere: betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid.
In de [[ISO 27002 2017|ISO 27002 2017]] wordt rond dit thema alleen focus gelegd op niet-functionele eisen (beveiligingseisen). Daarom is naast het object ‘Analyse en specificatie van informatiebeveiligingseisen’ ook het object ‘Analyse en specificatie van informatiesystemen’ toegevoegd, waarbij de nadruk gelegd wordt op functionele eisen.
Deze BIO Thema-uitwerking is baseline gebaseerd en met lineaire volgens het V-modelaanpak uitgewerkt. Aangezien bij Agile niet op deze wijze wordt gewerkt, verdient dit aspect extra aandacht. +
De website Antwoord voor bedrijven is per 15 september 2014 opgegaan in [[Ondernemersplein]] en maakt ondernemers wegwijs door de grote hoeveelheid informatie van de overheid. +
==Objectdefinitie==
Betreft de instandhouding van apparatuur binnen huisvesting Informatievoorzieningen (IV).
==Objecttoelichting==
Apparaten zoals installaties en machines moeten voor veilige toepassing periodiek en volgens de juiste procedures worden onderhouden door geautoriseerde medewerkers of leveranciers. +
==Objectdefinitie==
Betreft het veilig plaatsen van apparatuur binnen huisvesting Informatievoorzieningen (IV).
==Objecttoelichting==
In huisvesting IV bevindt zich verschillende apparatuur. Deze apparatuur dient zo te zijn gepositioneerd en beschermd dat verlies, diefstal en onderbreking van bedrijfsmiddelen wordt voorkomen. +
==Objectdefinitie==
Betreft het veilig en gecontroleerd verwijderen van apparatuur binnen huisvesting Informatievoorzieningen (IV).
==Objecttoelichting==
Apparaten kunnen cruciale data bevatten. Het verwijderen van apparatuur moet daarom veilig met vastgestelde procedures plaatsvinden. +
Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf. +
Het doel van deze aanbesteding is het afsluiten van een overeenkomst met één of meerdere opdrachtnemers ten behoeve van de volgende software applicaties/ informatie systemen: Applicatie/ informatie systeem voor het Sociaal Domein. De gemeente Hollands Kroon is verantwoordelijk voor een goede dienstverlening naar haar inwoners en medewerkers. Ons uitgangspunt is om de huidige applicaties voor het Sociaal Domein meer aan te laten sluiten bij de wensen die staan omschreven in ons droombeeld. De huidige applicaties zijn geschikt voor het doel waar deze ooit voor zijn aangeschaft maar sluiten onvoldoende aan de huidige wensen, zoals bijvoorbeeld documenten opslaan in SharePoint en het onttrekken van data uit basisregistraties. +
==Objectdefinitie==
Betreft een modelmatige beschrijving van de samenhang van het applicatielandschap.
==Objecttoelichting==
De applicatie-architectuur beschrijft de samenhang tussen functionele en beveiligingseisen. Ook wordt aandacht besteed aan de integratie-aspecten met de infrastructuur. Vanuit een eenduidig beeld wordt de applicatie met deze architectuur gerealiseerd. Richtlijnen, instructies, architectuur- en beveiligingsvoorschriften en procedures worden zodanig toegepast dat een samenhangend geheel ontstaat. Op deze manier wordt ook zeker gesteld dat de applicatie aan de vereiste functionele en beveiligingseisen voldoet. +
Een beschrijving van de structuur en interactie van de applicaties die belangrijke bedrijfsfuncties ondersteunen en gegevens beheren. +
==Objectdefinitie==
Betreft specificaties vastgelegd in tekst en beeld van een computerprogramma.
==Objecttoelichting==
Tijdens de ontwerpfase worden de (niet-)functionele requirements omgezet naar een uitvoerbaar informatiesysteem. Een high level architectuur wordt ontwikkeld om de software te kunnen bouwen. Hierbij wordt onder andere aandacht besteed aan de gebruikte data door het systeem, de functionaliteit die geboden moeten worden, de toegepaste interfaces tussen componenten binnen het systeem en aan koppelingen met andere systemen. Ook worden constraints die voortvloeien uit specifieke beveiligingseisen verder uitgewerkt. +
==Objectdefinitie==
Betreft het ontwikkelen van een programmacode.
==Objecttoelichting==
Na de eerste twee ontwikkelfasen, waarbij de nadruk ligt op de analyse van requirements en op het ontwerp van het product, volgt de derde fase, de applicatiebouw. In deze derde fase wordt de programmacode gecreëerd met good practices, methoden/technieken en bepaalde beveiligingsuitgangspunten. +
==Objectdefinitie==
Omvat toepassingsfuncties die ondersteuning bieden aan bedrijfsprocessen.
==Objecttoelichting==
De functies kunnen worden onderverdeeld in invoer-, verwerking- en uitvoerfuncties. Binnen de functies worden controles en rekenregels ingebouwd om de gewenste acties te kunnen uitvoeren en gewenste resultaten te kunnen leveren. Het totaal aan functionaliteiten moet aan bepaalde eisen voldoen. Zo moeten functionaliteiten:
* voldoen aan de behoefte van de gebruikers;
* de gebruikerstaken afdekken;
* resultaten leveren die nauwkeurig zijn;
* geschikt zijn om bepaalde taken te kunnen ondersteunen. +
==Objectdefinitie==
Betreft een verbinding tussen twee of meer applicaties waarmee gegevens tussen deze applicaties uitgewisseld kunnen worden.
==Objecttoelichting==
Bij het ontwikkelen van applicaties kunnen mogelijk koppelingen tussen de applicatie die in ontwikkeling is en andere applicaties noodzakelijk zijn. Vanuit beveiligingsoogpunt dienen dit soort koppelingen aan bepaalde eisen te voldoen. +
==Objecten, controls en maatregelen==
Onderstaande afbeelding toont de objecten die specifiek voor dit domein een rol spelen. Het geeft een overzicht en de ordening van objecten. De geel gemarkeerde objecten komen voor in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. De wit gemarkeerde objecten zijn betrokken uit andere best practices. Voor de identificatie van de objecten en de ordening is gebruik gemaakt van basiselementen (zie de grijs gemarkeerde tekst). Ze zijn ingedeeld naar de [[Alle invalshoeken|invalshoek: Intentie, Functie, Gedrag of Structuur]].
[[Bestand:APO Overzicht objecten voor applicatieontwikkeling in het beleidsdomein.png|thumb|none|500px|Overzicht objecten voor applicatieontwikkeling in het beleidsdomein|alt=”Onderwerpen die binnen het Beleid domein een rol spelen”]] +
==Objecten, controls en maatregelen==
Onderstaande afbeelding toont de objecten die specifiek voor dit domein een rol spelen. Het blauw gemarkeerde object komt voor in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. De wit gemarkeerde objecten zijn betrokken uit andere best practices. De objecten zijn ingedeeld naar de [[Alle invalshoeken|invalshoek: Intentie, Functie, Gedrag of Structuur]].
[[Bestand:APO Overzicht objecten voor applicatieontwikkeling in het control-domein.png|thumb|none|500px|Overzicht objecten voor applicatieontwikkeling in het control-domein|alt=”Overzicht objecten voor applicatieontwikkeling in het control-domein”]] +
==Objecten, controls en maatregelen==
Binnen het uitvoeringsdomein worden specifieke inrichtings- en beveiligingsobjecten voor applicatieontwikkeling beschreven. Per object worden conformiteitsindicatoren en de desbetreffende implementatie-elementen uitgewerkt. De rood gemarkeerde objecten komen voor in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. De wit gemarkeerde objecten zijn betrokken uit andere best practices, zie onderstaande afbeelding. De objecten zijn ingedeeld naar [[IFGS Intentie|intentie]], [[IFGS Functie|functie]], [[IFGS Gedrag|gedrag]] en [[IFGS Structuur|structuur]]. In de [[BIO Thema Applicatieontwikkeling/IFGS gekoppeld aan het V-model|pagina Invalshoeken gekoppeld aan het V-model zijn de invalshoeken gekoppeld aan het V-model]].
[[Afbeelding:Thema Applicatieontwikkeling - Onderwerpen die binnen het Uitvoeringsdomein een rol spelen.png|thumb|none|500px|Overzicht objecten voor applicatieontwikkeling in het uitvoeringsdomein|alt=”Onderwerpen die binnen het Uitvoering domein een rol spelen”]] +
De drie gemeenten Deventer, Olst-Wijhe en Raalte werken samen in bedrijfsvoering zaken in DOWR verband. Dit is een samenwerking op basis van gastheerschap. Het gastheerschap van I&A ligt bij de gemeenten Deventer. Het project bestaat uit het leveren van (een) oplossing(en) voor de uitvoeringsondersteuning van de processen in het sociaal domein. De opdracht is om de applicaties in scope te (her)contracteren (incl. realisatie van technische en functionele implementatie, training en nazorg) voor applicaties die voldoen aan het Programma van Eisen en Wensen. +
==Objectdefinitie==
Omvat een verzameling van definities, waarmee programmaonderdeel A kan communiceren met programmaonderdeel B.
==Objecttoelichting==
Een API is te beschouwen als een soort digitale stekkerdoos, die externe diensten of personen gecontroleerde toegang kan verschaffen tot interne diensten, algoritmes, apparaten en/of informatiebronnen.
De eigenschappen van een API maakt een algoritme, dienst, apparaat of data programmeerbaar en daarmee ook gevoelig voor aanvallen. De maatregelen hieronder zijn beperkt tot generieke eisen. Zie voor specifieke eisen over [[JSON|JavaScript Object Notation (JSON)]], [[XML|Extensible Markup Language (XML)]] of Graph Query Language (GraphQL) en de [[OWASP Application Security Verification Standard 4.0.2|Application Security Verification Standard (ASVS)]] van [[OWASP (Open Source Foundation for Application Security)|Open Source Foundation for Application Security (OWASP)]].
Bij cloud-toepassingen speelt de HyperText Markup Language (HTML)-5 ondersteuning van bepaalde browsers en de versie van die browser een belangrijke rol, onder andere voor de ondersteuning van bepaalde office-versies.
==Schaalgrootte==
Elke schaalgrootte.
==Voor wie==
Leverancier. +
Aquo Begrippen is één van de drie pijlers van de Aquo-standaard. Aquo Begrippen is een gegevenswoordenboek voor data met betrekking tot het waterbeheer in Nederland.
Fouten in gegevensuitwisseling treden vaak op door de vele verschillende betekenissen die termen kunnen hebben. Een gegevenswoordenboek voorkomt dit, omdat dit een verzameling is van termen, definities, relaties en contexten, die betekenis geven aan data binnen bijvoorbeeld een bepaald vakgebied, database of informatiesysteem. Dit heeft als doel een eenduidige terminologie vast te stellen en daarmee spraakverwarring tussen mensen en informatiesystemen te voorkomen. Aquo Begrippen bevat daarom eenduidige termen en definities van termen, die gebruikt worden binnen waterbeheer in Nederland. Deze eenduidigheid leidt tot een betere gegevensuitwisseling. +