Sandbox:PSA (Project Startarchitectuur)/Sjabloon: verschil tussen versies
(met referentie naar 'echte' pagina PSA-sjabloon en mailmogelijkheid) |
(eerste versie inclusief upload tekst uit handleiding) |
||
| Regel 1: | Regel 1: | ||
{{Sandbox}} | {{Sandbox}} | ||
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== | |||
* een | 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= | ||
== NORA-handleiding voor het opstellen van een PSA == | |||
* | === Architectuur is altijd maatwerk === | ||
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 === | |||
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 == | |||
PSA's vinden doorgaans hun herkomst in één van de volgende situaties. | |||
=== Binnen de context van een project binnen een organisatie === | |||
De PSA kan dan doorgaans voortbouwen op de kaders en informatie vanuit de Enterprise Architectuur (EA): | |||
[[Bestand:Architectuur-producten in samenhang zonder met Agile Scrum aanpak.png||Figuur 1 - Architectuur-producten in samenhang: zonder resp. mét Agile/Scrum aanpak|thumb|450px|left|alt=]] | |||
[[Bestand:Relatie EA en PSA.png|thumb|450px|left|alt= |Figuur 2 - Relatie EA en PSA]] | |||
=== Als onderdeel van een project van samenwerkende organisaties in ketens of domeinen === | |||
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. | |||
[[Bestand:PSA in een domein of keten.png|thumb|450px|left|alt= |Figuur 3 - PSA in een domein of keten]] | |||
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 == | |||
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): | |||
[[Bestand:Architectuur-views van de NEN-ISO 42010.png|thumb|450px|left|alt= |Figuur 4- Architectuur-views van de NEN-ISO 42010]] | |||
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. | |||
Versie van 5 jul 2023 12:30
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.