Review op visie Architectuur Digitale Overheid 2030
Content
Vergadering: Forum Standaardisatie 14 juni 2023
Agendapunt: 2E
Documentnummer: FS-20230614.2E
Download hier de PDF versie van dit vergaderstuk. Wij kunnen de digitale toegankelijkheid van het PDF bestand niet garanderen.
Rechten: CC0 publieke domein verklaring
| Paragraafnummer | Uitspraak in het document | Reviewopmerking | Concrete suggestie voor alternatieve tekst |
| 1, 6 | Architectuur probeert generiek te zijn. Zeker in een Architectuurvisie tot 2030 is het van belang uit te gaan van doelen die je wilt bereiken en zodoende af te pellen, dan specifieke oplossingen te noemen. De Architectuurvisie gaat veel uit van hergebruik van bestaande onderdelen/ Bouwstenen. Dat is erg goed. Is het, denkend vanuit een langer termijn perspectief (tot 2030), dan niet zinvol om ook te spreken van generieke functies? De term Bouwstenen wordt enerzijds gebruikt voor een 'generieke functie' èn is tegelijkertijd een specifieke oplossing die al is ontwikkeld. Dit zorgt voor verwarring. Aandachtspunt is dat de focus op hergebruik van bestaande, concrete oplossingen innovatie in de weg gaat staan. | ||
| 1 | Het document is niet digitaal toegankelijk. Dat is wel wettelijk verplicht. | ||
| 1 | Het stuk geeft aan dat het stuk geactualiseerd wordt. Suggestie is om het stuk primair online via HTML te publiceren en te actualiseren i.p.v. te werken met versies in PDF. Dit verhoogt de bruikbaarheid en dit kan een aantal issues uit DEZE versie rond digitoegankelijkheid oplossen. NORA online is een suggestie om de Architectuurvisie te puibliceren: dit verstevigt de relatie met NORA, en het maakt het makkelijker mogelijk te linken naar NORA bouwstenen en principes. Weet hierbij dat content in NORA zelf weer als linked data machineleesbaar te delen is. | ||
| 1 | Het eerste hoofdstuk legt veel nadruk op wat dit document allemaal niet is, bijvoorbeeld een enterprise-architectuur, een architectuur voor de digitale samenleving of digitale economie. Het zou helpen als het document ergens uitlegt hoe deze met elkaar en met de architectuur digitale overheid samenhangen. | ||
| 1 | Eén overheid naar burger en bedrijf toe is behalve een technische vooral ook een bestuurlijke en organisatorische opgave. Hoewel dit buiten de scope van de architectuur valt, moet de digitale overheid nadenken hoe deze architectuurvisie bestuurlijk en organisatorisch kan worden waargemaakt. In de inleiding kunnen hier misschien een paar woorden aan gewijd worden. | ||
| 1, 6 | Goed dat er aandacht is voor klimaat (zie pa. 6.3.4). Klimaat voor de hardware en de datacenters is slechts de helft van het verhaal. Suggestie: voeg toe dat software zelf ook ecologisch duurzaam(er) moet zijn. De ene code is groener (verbruikt minder energie) dan de andere code. Denk aan normen/ certificaten voor software in het verbuik van energie. | ||
| 1 | want data en gedigitaliseerde processen overschrijden snel de grenzen van individuele organisaties en bestuurlijke lagen. | 'overschrijden' geldt natuurlijk ook internationaal. Diverse acties uit de EU zijn direct van invloed op uitwerking in de afzonderlijke lidstaten. Denk aan eIDAS, gebruik van standaarden vanuit EU of ontwikkelingen rond de wallet. | organisaties, bestuurlijke lagen en landen. |
| 1 | Werkagenda Waardengedreven Digitaliseren1 | Hier en in het vervolg: vanuit Digitoegankelijkheidseisen is gebruik van voetnoten niet wenselijk. Probeer de tekst uit voetnoten te verweven in de hoofdtekst of hyperklinks in de voetnoten te verplaatsen achter de betreffende tekst in de hoofdtekst. | |
| 1 | Scope van de visie | Is deze alinea ook niet een plek om de Wet digitale overheid in ieder geval alvast te noemen? | |
| 1 | Voetnoot 6 | Hier en in het vervolg: vanuit Digi-toegankelijkheidseisen is het niet wenselijk hyperlinks voluit te schrijven: zet de hyperlink achter een gemarkeerde tekst die de inhoud van de hyperlink beschrijft of inhoudelijk relatie heeft met de hyperlink | |
| 1 | Programma’s en projecten die nodig zijn om van de bestaande situatie tot de gewenste situatie in 2030 te komen in het jaarlijkse Programmeringsplan. | De zin loopt niet goed. Er mist een werkwoord | |
| 1 | We dienen ons ook te realiseren dat de architectuur van de digitale overheid geen remedie is tegen complexe wet- en regelgeving met als gevolg moeilijk leesbare toelichtingen, onduidelijke formulieren en ingewikkelde processen. Het streven naar goed uitvoerbare wet- en regelgeving en ook beleid blijft van groot belang. | Dit punt 'Het streven naar goed uitvoerbare wet- en regelgeving en ook beleid blijft van groot belang' raakt een deel van het hier geschetste probleem. De andere helft is het belang van semantiek. Semantische standaardisatie draagt hieraan bij. Zorg eerst voor afstemming van wetten onderling en goed vastleggen van betekenis van wetten, en voorkom zo technische reparatie achteraf. Zie bv. https://forumstandaardisatie.nl/de-praktijk/aandacht-voor-semantiek-onmisbaar-voor-een-rechtmatige-en-rechtvaardige-digitale-overheid | |
| 3 | Waar mogelijk worden marktconforme standaarden toegepast. Het mechanisme van Forum Standaardisatie is daarvoor leidend. | Dwingerder formuleren van 'waar mogelijk' en 'marktconform'. 'waar mogelijk': er is gewoon sprake van ‘pas toe of leg uit’-verplichting van FS en van standaarden die wettelijk verplicht zijn. Wettelijke verplichting vindt plaats via Wdo (per 1/7: HTTPS en HSTS), maar er zijn daarnaast voldoende standaarden die binnen bepaalde sector of domein wettelijk verplicht zijn. Daarnaast is 'marktconform' ongelukkig gekozen; dit kan leveranciersafhankelijkheid impliceren terwijl de overheid (en FS) juist het gebruik van open standaarden nastreeft ter bevordering van interoperabiliteit en leveranciersonafhankelijkheid. Noem daarnaast niet sec ‘standaarden’, maar gebruik ‘open standaarden’. |
|
| 3 | Waar mogelijk worden marktconforme standaarden toegepast. Het mechanisme van Forum Standaardisatie is daarvoor leidend. | Hoofdstuk 3 stelt dat waar mogelijk ‘marktconforme standaarden’ worden toegepast volgens het beleid van het Forum Standaardisatie. Het beleid van het Forum richt zich op open standaarden, en het is misschien beter om die term hier ook te gebruiken. De lezer zou kunnen denken dat ook gangbare leveranciersafhankelijke standaarden ‘marktconform’ zijn, denk aan Microsoft Office of Adobe PDF. | |
| 4 | Deze 'proven' indeling | Hoe is hier de relatie met de NORA Vijflaagsmodel? Het is zinvol om uit te leggen waarom niet voor NORA Vijflaagsmodel is gekozen of hoe de relatie is met NORA Vijflaagsmodel. Te meer omdat Vijflaagsmodel weer overerft naar familieleden-architecturen en omdat eerder in het document NORA als een van de kaders wordt genoemd. | |
| 5 | afbeelding op blz. 11 | Hier en in het vervolg: vanuit Digitoegankelijkheidseisen: betekenisvolle afbeeldingen voorzien van alt-tekst of een bijschrift | |
| 6 | Het identificeren van nieuwe bouwstenen door opmaak (onderstrepen en cursief zetten) is geen goed idee. De nieuwe bouwstenen zijn hierdoor niet makkelijk zoekbaar in het document. Het komt de leesbaarheid bovendien niet ten goede, en het helpt de digitale toegankelijkheid van het document (wettelijk verplicht!) om zeep. Dit kan opgelost worden door de nieuwe bouwstenen apart als zodanig te benoemen in elk hoofdstuk. | ||
| 6 | Interorganisatorische koppelvlakken in en tussen de Bouwstenen moeten open standaarden hebben | ||
| 6.2.3 | Het document zet stevig in op APIs als interoperabiliteitsmechanisme tussen bouwstenen. In paragraaf 6.2.3 wordt ook gegevensuitwisseling met berichten genoemd. Het kan verhelderend zijn om uit te leggen wanneer APIs gebruikt worden, en wanneer gegevensuitwisseling op basis van berichten (zoals in StUF bijvoorbeeld) nog nodig is. | ||
| 6.3.2 | We passen de marktstandaarden van gelaagde opbouw van infrastructuur en platform zo conservatief mogelijk toe | Term 'marktstandaarden' is ongelukkig gekozen. Dit kan leveranciersafhankelijkheid impliceren terwijl de overheid (en FS) juist het gebruik van open standaarden nastreeft ter bevordering van interoperabiliteit en leveranciersonafhankelijkheid. Noem daarnaast niet sec ‘standaarden’, maar gebruik ‘open standaarden’. | |
| 6.3.4 | Het is noodzakelijk te kunnen beschikken over goed geoutilleerde huisvesting, die voldoet aan klimaat en milieu-eisen | Goed dat er aandacht is voor klimaat. Klimaat voor de hardware en de datacenters is slechts de helft van het verhaal. | |
| 6.5 | Bij het gebruik van open standaarden worden deze conform de door Forum Standaardisatie beschreven richtlijnen ontworpen en geïmplementeerd, zowel de verplichte standaarden als de aanbevolen standaarden | 'ontworpen' en 'richtlijnen' kunnen suggereren dat FS zelf standaarden ontwikkeld of voorschriften heeft over afzonderlijke implementaties van standaarden. FS geeft status aan standaarden volgens toetsingscriteria. Wordt hier bedoeld om standaarden te ontwerpen of om te gebruiken? | Gebruik open standaarden van de 'pas toe of leg uit'-lijst van het Forum Standaardistie of van de lijst aanbevolen standaarden. Houd bij ontwikkeling van nieuwe standaarden rekening met de toetsingscriteria van het Forum Standaardisatie |
| 6.7 | We stappen over op nieuwe standaarden en technologie zodra deze zijn vastgesteld, resp. dominant gaan worden. | welke 'vaststelling' wordt hier bedoeld? Vaststelling door de beheerorganisatie van een standaard? Vaststellen van een status ('pas toe of leg uit'-verplichting of aanbevolen status) van Forum Standaardisatie? | |
| 6.7 | We stappen over op nieuwe standaarden en technologie zodra deze zijn vastgesteld, resp. dominant gaan worden. | Voldoen aan 'nieuw'-zijn is geen doel op zich. Het kan ook zijn dat een andere al bestaande standaard of technologie voldoet | we stappen over op nieuwe of andere ... |
| 6.7 | We stappen over op nieuwe standaarden en technologie zodra deze zijn vastgesteld, resp. dominant gaan worden. | Overweeg om onderscheid te maken in standaarden en open standaarden. Noem daarnaast niet sec ‘standaarden’, maar ‘open standaarden’. Het gebruik van open standaarden bevordert interoperabiliteit en vermindert leveranciersafhankelijkheid. | |
| 6.7 | We maken gebruik van de jongste versie van open standaarden (zeker waar het beveiliging betreft) en we spreken elkaar aan op het voldoen aan dit uitgangspunt. Achterblijven wordt vastgelegd in de vorm van technische schuld en gerapporteerd. | Formuleer 'gebruik maken van' sterker: er is immers sprake van ‘pas toe of leg uit’-verplichting van FS en van standaarden die wettelijk verplicht zijn. Wettelijke verplichting vindt plaats via Wdo (per 1/7: HTTPS en HSTS), maar er zijn daarnaast voldoende standaarden die binnen bepaalde sector of domein wettelijk verplicht zijn. Noem daarnaast niet sec ‘standaarden’, maar ‘open standaarden’. Het gebruik van open standaarden bevordert interoperabiliteit en vermindert leveranciersafhankelijkheid |
|
| 6, 7, (en 7.3 i.h.b.) | Er wordt gesproken over lifecyclemanagement bij standaarden. Moeten we ook niet spreken van prioritering van internationale standaarden boven nieuwe, nationale of sectorale standaarden? | ||
| 7 | Bij de Bouwstenen in de bijlagen worden lang niet overal standaarden genoemd en er worden standaarden specifiek bij naam genoemd, m.u.v. het thema 7..2.14 (Beveiliging en privacybescherming). Is het niet zinvol om bij andere bouwstenen ook standaarden van Forum Standaardisatie in het algemeen te noemen naast een aparte selectie te maken? Immers, ook de niet genoemde standaarden die wel betrekking hebben op het betreffende bouwsteen, zijn verplicht ('pas toe of leg uit') of aanbevolen. | ||
| 7.2.2 | Standaarden voor websites | toevoegen: digitoegankelijkheid; standaarden voor veilig internet, incl. HTTPS en HSTS (Wdo-verplichting); standaarden voor metadatering (bv. OWMS, MDTO) | |
| 7.2.6 | verplichte standaarden/ aanbevolen standaarden | verduidelijken dat het gaat om 'pas toe of leg uit'-verplichting of aanbevolen standaarden volgens Forum Standaardisatie (géén wettelijke verplichting) | |
| 7.2.6 | NL GOV Assurance profile for OpenID Connect (aanbevolen) | NL GOV AP OIDC is nu in behandeling voor verplichting ('pas toe of leg uit'). Algemeen geldt: status van standaarden wijzigine n(aanbevol;en, pas toe of leg uit, wettelijk verplicht: dit vraagt om inrichten van processen rond goed lifecyclemanagement van deze Architectuurvisie 2030 | |
| 7.2.8 | E-factuurportaal Peppol | verduidelijken dat het gaat om 'aanbevolen'-status volgens Forum Standaardisatie | |
| 7.2.8 | XBRL | verduidelijken dat het gaat om 'pas toe of leg uit'-verplichting volgens Forum Standaardisatie (géén wettelijke verplichting) | |
| 7.2.9 | Toevoegen als bouwsteen: DCAT (en het nieuwe profiel dat in ontwikkeling is), SKOS (en aanpalende linked data standaarden zoals RDF, OWL en SHACL), MIM (en sector gebonden afgeleiden zoals NEN 3610: 2022 nl voor de Geosector) | ||
| 7.2.10 | TLS | verduidelijken dat het gaat om 'pas toe of leg uit'-verplichting volgens Forum Standaardisatie (géén wettelijke verplichting) | |
| 7.2.14 | Gebruik open standaarden conform richtlijnen van Forum Standaardisatie | Formuleersterker: er is immers sprake van ‘pas toe of leg uit’-verplichting van FS en van standaarden die wettelijk verplicht zijn. Wettelijke verplichting vindt plaats via Wdo (bv. per 1/7: HTTPS en HSTS), maar er zijn daarnaast voldoende standaarden die binnen bepaalde sector of domein wettelijk verplicht zijn. | Gebruik open standaarden van Forum Standaardisatie |
| 7.3 | Noem daarnaast niet sec ‘standaarden’, maar ‘open standaarden’. Het gebruik van open standaarden bevordert interoperabiliteit en vermindert leveranciersafhankelijkheid |