Webversie PSA Format

Uit NORA Online
Versie door RemcoOvervelde (overleg | bijdragen) op 20 aug 2024 om 10:55 (Tekst vervangen - "Netwerklaag" door "IT-Infrastructuurlaag")
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springen Naar zoeken springen
Contact
Bas Kaptijn
nora@ictu.nl
Status
Actueel
De tekst is inmiddels omgezet, de afbeeldingen moeten nog geüpload worden en beschreven in het kader van toegankelijkheid.
PSA Format
Deze pagina is een concept. Reacties via nora@ictu.nl of tekstvoorstellen in de wiki zijn welkom.

NORA sjabloon voor een Project Start Architectuur (PSA)[bewerken]

Volgens Kabinetsbeleid geldt voor de overheid als geheel de Nederlandse Overheid Referentie Architectuur (NORA) als norm en dient voor elk nieuw groot ICT-project een Project Start Architectuur te worden opgesteld in lijn met NORA. Het voorliggende PSA-format is in lijn met de NORA en kan dus worden gebruikt bij projecten binnen domeinen en ketens. En natuurlijk ook bij projecten binnen (grote) overheidsorganisaties.

Het is ook mogelijk om een ander PSA-format te gebruiken, zolang het maar in lijn is met de NORA. Bij dit sjabloon hoort een handleiding voor het maken van een PSA. Daarin is ook aangegeven hoe de onderdelen van de PSA zijn afgestemd op de NEN-ISO 42010:2022. Deze ISO norm stelt overigens géén eisen aan de vorm van een PSA c.q. van een architectuurbeschrijving. De vraagstelling is bepalend voor de diepgang van de PSA. Dat komt vooral tot uitdrukking in de oplossing(-srichting).

Uitgangspunt is dat de PSA in ieder geval moet aansluiten op de “bovenliggende" doelarchitectuur en tegelijkertijd niet de oplossingsarchitectuur moet zijn. Daarnaast moet de PSA voldoende informatie bevatten om bij de start van een verandertraject te kunnen besluiten over de oplossing(-srichting). Een PSA kan ‘dun’ of ‘dik’ worden opgesteld, al naar gelang de behoefte op het moment van opstellen. Een ‘dikke PSA’ heeft doorgaans al deels een solution-architectuur in zich. Hou de PSA dun door niet te veel details en meta-informatie op te nemen of (half)lege bladzijden. Gebruik geen aparte lijst met afkortingen of begrippen: afkortingen de 1e keer uitschrijven en meteen een linkje opnemen naar de verdere uitleg van het begrip. Ook geen aparte lijst met referenties: gewoon direct linkjes naar de bron opnemen, eventueel in een voetnoot.

Project Start Architectuur[bewerken]

<naam> <eventuele ondertitel>

Status[bewerken]

Concept / Definitief Datum <versiedatum> Afgestemd met stakeholders … (Nog af te stemmen met …) (Wordt) Vastgesteld in het overleg van … per datum …

<aansprekend (domein- of keten)plaatje>

Inhoud[bewerken]

De inhoudsopgave.

1 Managementsamenvatting (max 1 A4)[bewerken]

Hier wordt beschreven wat de belangrijkste bevindingen en conclusies zijn die kaderstellend aan de verandering c.q. het project worden meegegeven. Probeer het te verwoorden als een soort pitch die aan opdrachtgevers gegeven kan worden: een paar zinnen die de essentie van de PSA toelichten. Dat kan handig zijn wanneer een opdrachtgever of stuurgroep om een korte inleiding of toelichting vraagt.

Denk aan aspecten als:

  1. Een beknopte beschrijving van de verandering die wordt beoogd. Beschrijf hierbij met name ook de maatschappelijke context.
  2. De relatie met andere lopende Nationale- of Internationale ontwikkelingen.
  3. Welke overheidsdiensten, processen en systemen door de verandering worden geraakt. Benoem hierbij ook de meest belangrijke (generieke) functies of voorzieningen.
  4. De belangrijkste bestaande kaders en inrichtingskeuzes waarmee rekening moet worden gehouden. Benoem hierbij ook de samenhang met architecturen. Bijvoorbeeld door aan te geven welk deel van een enterprise-, domein- of ketenarchitectuur de verandering invulling geeft.
  5. De punten waarover besluitvorming en/of discussie moet plaatsvinden. Denk hierbij met name aan alternatieve oplossingsmogelijkheden en de impact daarvan. Maar ook afwijkingen van de afgesproken kaders.

2.1 Aanleiding en doelstelling[bewerken]

Beschrijf in het kort de huidige situatie en geef daarbij aan wat de precieze aanleiding is om deze PSA op te stellen: welke vraagstukken doen zich voor, wat moet worden aangepakt, welke ontwikkelingen vinden plaats waarmee rekening gehouden dient te worden, welke doelstelling en ambities worden nagestreefd, in welke richting het bestuur of management denkt qua oplossing e.d.

2.2 De opdracht, het resultaat en te bereiken effect[bewerken]

Beschrijf kort en bondig de verandering en aan welke maatschappelijke doelen/ambities die verandering bijdraagt. Hier worden dus niet de projectdoelen en -ambitie bedoeld! Geef daarnaast aan wat de door het project te realiseren oplossing moet gaan doen en wat de belangrijkste functies van die voorziening daartoe zijn. Het afgesproken tijdpad en de kwaliteitseisen: wanneer zijn we tevreden met het resultaat. Beschrijf dit vanuit een “Black Box” (dus geen details van een oplossing). Vaak zijn er al documenten die de beoogde verandering beschrijven.

2.3 Stakeholders[bewerken]

Benoem de stakeholders (burgers, ambtenaren, leveranciers enz.) met de belangen die zij hebben bij het resultaat van het project (de oplossing) en hun rol bij het maken van deze PSA.

Stakeholder Functie / Rol Belang in resultaat Bijdrage aan PSA
Opdrachtgever OG Realisatie, outcome Vaststellen
Opdrachtnemer PL Uitvoerbaarheid project
Burgers/Bedrijven Gebruiksmogelijkheden
Architect / Adviseur Oplossingsmogelijkheden Opstellen
Leveranciers Oplossingsmogelijkheden
Ontwikkelaars Oplossingsmogelijkheden
Uitvoeringsorganisaties Uitvoerbaarheid
Beheerder Beheermogelijkheden
Enz.

NB. Een volledige stakeholderanalyse is geen onderdeel van de PSA maar zal doorgaans in het projectplan of project initiatiedocument (PID) worden opgenomen.

Als het relevant is, neem dan ook wat achtergrondinformatie op over de betrokken overheidsorganisatie(s), de relevante wettelijke taken en de belangrijkste diensten/producten die die organisatie(s) aan de samenleving levert. Een belangrijke bron voor de beschrijving van een organisatie en het maatschappelijke belang, is de website van de organisatie. Daarnaast kunnen gesprekken met mensen, workshops of documenten binnen de organisatie veel input geven.

2.4 De relaties met andere (deel)projecten[bewerken]

Geef vooral aan of afhankelijkheden wederzijds spelen met andere (deel)projecten en waaruit die afhankelijkheid bestaat. Doe dat in elk geval voor projecten van en voor de Werkagenda Waardengedreven Digitaliseren (digitaleoverheid.nl)

3 Visualisatie (max 1 A4)[bewerken]

Neem een visualisatie op van zowel de IST als de SOLL situatie. Bijvoorbeeld een idEA-visualisatie

Als die (nog) niet beschikbaar zijn, neem dan bijvoorbeeld tijdelijk een foto op van de uitkomsten van de workshop(s) met de stakeholders. NB. Als er verschillende oplossingsrichtingen zijn, kunnen er ook verschillende visualisaties zijn. Neem die dan ook op.

Licht daarbij toe wat wel en niet binnen de scope van het vraagstuk en de oplossing valt: wat wordt wel aangepakt en wat niet. Geef de scope zo mogelijk aan in de visualisatie.

4 NORA-Vijflaagsmodel (max 4 A4)[bewerken]

Het opstellen van de kaderstellende en richtinggevende uitspraken die op de verandering van toepassing zijn, gebeurt aan de hand van het NORA Vijflaagsmodel en de visualisatie daarvan. Keuzes voor de verandering moeten aan die uitspraken voldoen. En gaande en aan het einde van de verandering (het project) wordt getoetst of de gemaakte keuzes binnen die kaders passen, opdat wordt geborgd dat toekomstvaste en duurzame keuzes worden gemaakt.

4.1 De invalshoek Grondslagen (Samenleving / Wet- en Regelgeving)[bewerken]

Geef hier een eerste indicatie van de manier waarop de wet- en regelgeving en beleidsafspraken van toepassing zijn op het vraagstuk. Dat kunnen ook algemene maatregelen van bestuur (AMvB’s), of Ministeriële regelingen (MR’s) zijn. Hierbij kan je gebruik maken van het overzicht van alle Implicaties van Architectuurprincipes voor de Grondslagenlaag

Denk verder met name aan de volgende wet- en regelgeving:

  • a. Algemene Wet Bestuursrecht (Awb)
  • b. Wet Open Overheid (Woo)
  • c. Wet Digitale Overheid (Wdo)
  • d. Archiefwet (Aw)
  • e. Privacywetgeving (AVG)
  • f. Specifieke wetgeving die van toepassing is op het domein of werkveld van de organisatie of keten waarop de verandering impact heeft. Bijvoorbeeld specifieke wetgeving in de Zorg.
  • g. Agenda Waardengedreven Digitaliseren

Architectuurkaders en voorschriften die van toepassing zijn:

Binnen deze kaders zullen diverse oplossingen mogelijk zijn voor de gewenste verandering. Die mogelijkheden worden via de PSA verkend en gerelateerd aan de belangen van de verschillende stakeholders.

Zorg in elk geval voor duidelijkheid over:

4.2 De invalshoek Organisatie[bewerken]

Geef hier een eerste indicatie van de (rol van) stakeholders die betrokken zijn bij (de oplossing voor) het vraagstuk. Hier is een overzicht van alle Implicaties van Architectuurprincipes voor de Organisatorische laag

Zorg in elk geval voor duidelijkheid over:

  • Wie (welke functie) is eind-verantwoordelijk voor deze dienst?
  • Hoe wordt de dienst gemanaged met het Dienstverleningsconcept?
  • Welk gremium bepaalt de afspraken over de dienst?

Denk aan Tweede Kamer als het een overheidsdienst aan burgers is, of het OBDO als het gaat om samenwerking tussen overheidsorganisaties of efficiëntie (via het gebruik van standaarden e.d.)

  • Welke overheidsorganisatie(s) voert (voeren) die afspraken uit?
  • Welke overheidsorganisatie is verantwoordelijk voor het herstel van eventuele gemaakte fouten? En bij wie kan de gebruiker (burger, ondernemer, ambtenaar) hulp vragen als het vastloopt oid.?
  • Welke overheidsorganisatie(s) is (zijn) verantwoordelijk voor het doorvoeren van wijzigingen in het proces?
  • Welke overheidsorganisatie is verantwoordelijk voor voorstellen voor verbetering van de afspraken of van de uitvoering?

Zie voor deze aspecten NAP17 Stuur cyclisch op kwaliteit

NB. Beheer is onderdeel van deze 5 processen (zie verder het hoofdstuk inzake Beheer) !

4.3 De invalshoek Informatie[bewerken]

Geef hier een eerste indicatie van de informatie-objecten die relevant zijn bij (de oplossing voor) het vraagstuk. Hier is een overzicht van alle Implicaties van Architectuurprincipes voor de Informatielaag

Zorg in elk geval voor duidelijkheid over:

  • Welke gegevens(soorten) zijn onderkend?
  • Hoe en waar zijn die beschreven?

Zie voor deze 2 aspecten NAP10 Neem gegevens als fundament

  • Uit welke bron-registraties kunnen die gegevens worden verkregen?

Zie voor dit aspect NAP12 Informeer bij de bron

4.4 De invalshoek Applicaties[bewerken]

Geef hier een eerste indicatie van de applicaties (voorzieningen) die relevant zijn bij (de oplossing voor) het vraagstuk. Hier is een overzicht van alle mplicaties van Architectuurprincipes voor de Applicatielaag.

Zorg in elk geval voor duidelijkheid over:

  • Welke bestaande bouwstenen (voorzieningen) zijn te hergebruiken?

Ook mogelijk internationale bouwstenen (voorzieningen)! Zie voor dit aspect NAP08 Standaardiseer waar mogelijk

  • Algoritmen zijn bekend en aangemeld bij het algoritmeregister, conform de kamerbrief 2022-0000693912: "In de aanloop naar verplichtstelling zal het kabinet overheidsorganisaties stimuleren om waar mogelijk hun (hoog-risico) algoritmes te publiceren. Dergelijke publicatie kan wel begrensd worden door wettelijke of gerechtvaardigde uitzonderingen die van toepassing zijn in het kader van bijvoorbeeld opsporing, rechtshandhaving, defensie of inlichtingenverzameling. "

4.5 De invalshoek Infrastructuur[bewerken]

Geef hier een eerste indicatie van de netwerken c.q. de infrastructuur die relevant is bij (de oplossing voor) het vraagstuk. Hier is een overzicht van alle Implicaties van Architectuurprincipes voor de IT-Infrastructuurlaag.

Zorg in elk geval voor duidelijkheid over:

  • Hoe wordt hergebruik gemaakt van internet en andere bestaande netwerken (Diginetwerk, Rinis, RON e.d.)

Zie voor dit aspect NAP08 Standaardiseer waar mogelijk.

5 Standaarden (max 1 A4)[bewerken]

Hier wordt onderbouwd met welke open standaarden verplicht zijn om toe te passen en met welke (open) standaarden rekening wordt gehouden. Maak daarbij vooral ook gebruik van:

Indien van toepassing ook aangeven waar wordt afgeweken van de standaarden, de reden hiervoor en de maatregelen om negatieve consequenties te voorkomen. Deze verklaring moet worden gebruikt in de jaarrapportage voor compliancy aan open standaarden, zie 'Pas toe of leg uit'-beleid | Forum Standaardisatie.

6 Privacy en Informatiebeveiliging (max 1 A4)[bewerken]

6.1 Privacy[bewerken]

Beschrijf hier hoe het geldende privacykader, te weten de AVG, zal worden vertaald naar maatregelen die nodig zijn voor het borgen van de privacy van betrokkenen, gezien de processen en gegevens binnen de scope van de verandering c.q. het project. Bijvoorbeeld op basis van een uitgevoerde Privacy Impact Assessment (PIA).

Privacy is uitgewerkt via het thema Privacy en via het Kwaliteitsdoel Privacy (Doel) en via NAP10 Neem gegevens als fundament en NAP11 Pas doelbinding toe, met bij behorende Implicaties zoals IMP004 Minimaliseer het gebruik van gegevens.

Een advies daarover kan je mogelijk verkrijgen via de community van het thema Privacy.

6.2 Informatiebeveiliging[bewerken]

Beschrijf hier hoe de geldende beveiligingskaders, waaronder met name de BIO, zullen worden vertaald naar beveiligingsmaatregelen die nodig zijn voor de processen en gegevens binnen de scope van de verandering c.q. het project. Denk ook aan open standaarden ten behoeve van veilig internet en de Meting Informatieveiligheidstandaarden (beide Forum Standaardisatie). Zie ook Kaders beveiliging. Informatiebeveiliging is uitgewerkt in het thema Beveiliging en via NAP10 Neem gegevens als fundament, NAP13 Beheers risico's voortdurend, NAP14 Verifieer altijd en NAP15 Maak diensten schaalbaar. Een advies daarover kan je mogelijk verkrijgen via de community van het thema Beveiliging.

7 Beheer (max 1 A4)[bewerken]

Beschrijf welke uitgangspunten en kaders gelden voor het beheer.

Om daar achter te komen is het adagium om voor een specifieke PSA afstemming te zoeken met de toekomstige beheerpartij over de dan geldende normen.

Denk aan beheerpartijen als Logius, SSO-ICT, DICTU en ODC-Noord.


8 Beslispunten[bewerken]

De achilleshiel van het werken onder architectuur is een veelheid van afwijkingen die vervolgens jaren blijven bestaan en uit zicht verdwijnen. Daarom is het van belang dat er een verantwoordelijke is voor het beoordelen, goed- dan wel afkeuren en blijvend monitoren van bewuste afwijkingen op de architectuur. Er kunnen valide redenen zijn om afwijkingen toe te staan; niet om ze jarenlang te laten bestaan…

Geef een opsomming van de punten waarvan de stakeholders aangeven dat daar besluitvorming over nodig is en licht per punt kort toe welke discussie speelt.

Punten die afwijken van de aangegeven kaders en (referentie)architecturen moeten daar deel van uitmaken. Geef voor die punten aan welke functie of welk gremium op termijn het besluit zal nemen om de afwijking op te laten heffen.

En hier kan je ook alle overige relevante vraagstukken benoemen.


9 BIJLAGE - Betrokkenen[bewerken]

Geef hier aan wie vanuit zijn of haar functie heeft meegewerkt aan de totstandkoming van deze PSA.

Nr. Naam Organisatie Functie / Rol
Opdrachtgever
Opdrachtnemer