Sandbox:PSA (Project Startarchitectuur)/Sjabloon: verschil tussen versies
(→4.5 De invalshoek Infrastructuur: met links) |
(→4.5 De invalshoek Infrastructuur: correctie hoofd/kleine letter in link) |
||
| Regel 227: | Regel 227: | ||
Zorg in elk geval voor duidelijkheid over: | Zorg in elk geval voor duidelijkheid over: | ||
* Hoe wordt hergebruik gemaakt van internet en andere bestaande netwerken ([[ | * Hoe wordt hergebruik gemaakt van internet en andere bestaande netwerken ([[Diginetwerk]], Rinis, RON e.d.) | ||
Zie voor dit aspect NAP08 [[Standaardiseer waar mogelijk]]. | Zie voor dit aspect NAP08 [[Standaardiseer waar mogelijk]]. | ||
Versie van 5 jul 2023 13:50
Deze sandbox-pagina is bedoeld om een goed toegankelijke pagina te maken voor de PSA en PSA sjabloon, als aanvulling op het document dat in .odt wordt verstrekt.
PSA sjabloon als .odt bestand[bewerken]
De nieuwste versie van het PSA en de handleiding zijn te downloaden als .odt bestand, zodat je gemakkelijk zaken over kunt nemen in je eigen documenten. Publicatie van documenten is echter niet altijd even toegankelijk, dus publiceren we ook een web-versie van beide documenten.
- .odt PSA sjabloon
- .odt PSA Handleiding
- Webversie PSA sjabloon
- Webversie PSA Handleiding
(de koppen hieronder worden twee pagina's)
Webversie Handleiding PSA Sjabloon[bewerken]
NORA-handleiding voor het opstellen van een PSA[bewerken]
Architectuur is altijd maatwerk[bewerken]
Een Project Start Architectuur (PSA), ook wel een Globale Architectuur Schets (GAS) genoemd, inventariseert de voor het project geldende kaders, afspraken, principes, richtlijnen, standaarden en normen. Daarnaast geeft de PSA aan wat de oplossing bijdraagt aan het realiseren van de gewenste doel-architectuur, wat de implicaties zullen zijn voor de bestaande informatievoorziening en waar het project zal afwijken van bestaande beelden. Met de PSA wordt een concreet en doelgericht ICT-architectuurkader opgesteld, waarbinnen het project moet worden uitgevoerd.
De PSA beschrijft niet de werking van de voorziening en hoe de door de voorziening te leveren diensten worden gebouwd. Dit komt later bij de doorontwikkeling in de solution architectuur aan bod. De PSA biedt inzicht in de te beoogde verandering en bijbehorende oplossingsrichting(en) en is daarmee het voortraject van en een opmaat naar een solution architectuur. Zie Figuur 1 - Architectuur-producten in samenhang voor de relatie van de PSA met andere project- en architectuur documenten.
De context waarin een PSA tot stand komt verschilt per opdracht. Dit komt doordat iedere opdrachtgever zijn eigen stijl en ervaring heeft. Daarnaast heeft ook iedere opdrachtnemer binnen kaders zijn eigen werkwijze. Verder heeft iedere organisatie en opdracht zijn eigen dynamiek. Dit heeft zijn weerslag op de uitwerking van een PSA. Daarom is een PSA altijd maatwerk in zijn context en vertelt het een maatwerk verhaal aangepast aan de situatie en omstandigheden. Wees daarom flexibel in het gebruik en de toepassing van deze handleiding. De handleiding is richtinggevend en geeft handvatten en aspecten die in een PSA benoemd worden.
Waarom een PSA[bewerken]
Het is de bedoeling dat alle betrokkenen met een PSA de essentie van een project snel kunnen doorgronden. Dit maakt de PSA – samen met de Project Initiation Documentation (PID) – een belangrijk document dat inzicht geeft in de implicaties van de door het project te realiseren resultaten. Daarbij dient de PSA twee hoofddoelen:
- Ondersteuning van besluitvorming bij het starten van het project (gericht op adviseurs en beslissers).
- Kaderstellend en richtinggevend voor architecten en ontwikkelaars tijdens de uitvoering van het project. Hierbij wordt de PSA gaandeweg aangescherpt op weg naar een solution architectuur.
De bedoeling is dat door de toepassing van de PSA het (ICT-)project een vliegende start krijgt en tevens de eerste waarborg is, dat de beoogde oplossing zal passen in de context waarin deze een plaats krijgt. Zo wordt voorkomen dat het project op verrassingen stuit, waarvan de informatievoorziening in de meest brede zin later last kan krijgen. Voor elke stakeholder levert een PSA iets op:
- Een bestuurder heeft met een PSA de meest belangrijke ‘ins’ en ‘outs’ beschikbaar om een verantwoord besluit te nemen over een project.
- De projectmanager kan met een PSA, aan de hand van kaders en randvoorwaarden, de oplossingsrichting van een project duidelijk maken. Dit geeft inzicht in de oplossing waar aan gedacht wordt en welke consequenties (en risico's) er aan inrichtingskeuzes vastzitten. Dit vergemakkelijkt de uitvoering.
- De professionals kunnen met een PSA gerichter aan de slag om concrete, passende oplossingen voor te stellen.
Het maken van een PSA is binnen de overheid overigens niet vrijblijvend. Het is verplicht voor grote projecten met een ICT-component vanaf € 20 miljoen of met een aanzienlijk publiek afbreukrisico. Natuurlijk is een PSA zeker ook zinvol en aan te raden voor kleinere projecten.
1.3 Situaties waarin PSA's worden gebruikt[bewerken]
PSA's vinden doorgaans hun herkomst in één van de volgende situaties.
Binnen de context van een project binnen een organisatie[bewerken]
De PSA kan dan doorgaans voortbouwen op de kaders en informatie vanuit de Enterprise Architectuur (EA):
Als onderdeel van een project van samenwerkende organisaties in ketens of domeinen[bewerken]
Hierbij zie je dat de PSA dan doorgaans zal voortbouwen op de kaders en informatie vanuit de EA'en van de betrokken organisaties en dat die PSA op zijn beurt weer input zal zijn voor de EA en projectmatige veranderingen in die organisaties.
NB. Op Domein- c.q Keten-niveau is doorgaans ook sprake van Informatieplannen en Projectportfoliomanagement, denk met name aan de Vreemdelingenketen (VK), de Strafrechtketen (SRK), of de Zorg.
1.4 Te benoemen aspecten in een PSA[bewerken]
Architectuurproducten, waaronder PSA's, worden zo veel mogelijk opgesteld volgens ISO 42010:2022, vandaar dat het goed is om je daar eerst in te verdiepen. Deze ISO norm gaat uit de volgende invalshoek(en):
De ISO 42010:2022 stelt geen eisen aan de vorm van de architectuurbeschrijving, anders dan de inhoud die het uiteindelijk moet gaan bevatten. De ISO gaat dus ook niet over verschillende tussenvormen van een architectuurbeschrijving in het proces van de totstandkoming ervan zoals bijvoorbeeld de PSA als start van een architectuurbeschrijving nog zonder oplossing (solution), maar wel met een oplossingsruimte (kader), die later uitgroeit tot een Solution Architectuur (SA) met de gekozen oplossing. Beide versies zijn architectuurbeschrijvingen die aan de ISO kunnen conformeren. De ISO gaat ook niet over hoe architectuurbeschrijvingen tot stand komen. Er wordt wel gehint dat formele methoden minder ambigue resultaten geven dan informele methoden.
De eisen die vanuit de ISO 42010:2022 worden gesteld aan de inhoud van een architectuurbeschrijving staan in Hoofdstuk 6 benoemd. Die inhoud mag in de PSA verspreid zijn over hoofdstukken van andere stukken.
Webversie PSA Sjabloon[bewerken]
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:
- Een beknopte beschrijving van de verandering die wordt beoogd. Beschrijf hierbij met name ook de maatschappelijke context.
- De relatie met andere lopende Nationale- of Internationale ontwikkelingen.
- Welke overheidsdiensten, processen en systemen door de verandering worden geraakt. Benoem hierbij ook de meest belangrijke (generieke) functies of voorzieningen.
- 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.
- 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) Hier is de tekst met de kopjes omgezet naar wikicode voor kop niveau 3:
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:
- h. NORA, het toepassen van de Bindende Architectuurafspraken
- i. De VISIE ARCHITECTUUR Digitale Overheid 2030 (PDF, 1,07 MB)
- j. Kaders vanuit de NORA familie: Welke dochter is voor mij van toepassing?
- k. De lijst van verplichte standaarden van Forum Standaardisatie: 'Pas toe leg uit' standaarden (verplicht) volgens 'Pas toe of leg uit'-beleid
- l. Standaarden op de ‘pas toe of leg uit’-lijst van Forum Standaardisatie zijn verplicht om uit te vragen bij inkooptrajecten van meer dan EUR 50K (alleen onder zwaarwegende omstandigheden mag afgeweken worden van de verplichting via een ‘leg uit’ in het jaarverslag). Zie: 'Pas toe of leg uit'-beleid | Forum Standaardisatie
- m. Specifieke kaders vanuit de organisatie of een keten.
Bijvoorbeeld de regels die gelden vanuit de wettelijke taak, de Enterprise Architectuur of de begrotingsruimte.
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:
- Hoe goed is de dienst beschreven?
- Hoe is de dienst gepositioneerd t.o.v. andere diensten? Zie voor deze 2 aspecten NAP09 Beschrijf de dienst nauwkeurig
- Hoe is de dienst via internet te bereiken? Zie voor dit aspect NAP03 Lever een kanaal-onafhankelijk resultaat
- Hoe is rekening gehouden met wensen vanuit de gebruiker van de dienst? Zie voor dit aspect NAP01 Verplaats je in de gebruiker
- Welke kwaliteitsafspraken zijn gemaakt over deze dienst? Zie voor dit aspect NAP17 Stuur cyclisch op kwaliteit
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 Netwerklaag.
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:
- het principe NAP08 Standaardiseer waar mogelijk
- en de informatie over open Standaarden van het Forum Standaardisatie
- de standaarden die worden gebruikt in bestaande bouwstenen (voorzieningen), zie Bouwstenen en gebruikte standaarden
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 en bij behorende Implicaties zoals IMP004 "Data minimalisation".
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 | 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.