PSA (Project Startarchitectuur): verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
(→‎NORA PSA Format: verwijzing naar ISO 42010)
 
(52 tussenliggende versies door 10 gebruikers niet weergegeven)
Regel 1: Regel 1:
{{kaderrechts|
{{Werkversie geïmporteerd Bindende afspraken}}{{Vakmanschap
Ga direct naar: [[Voorbeeld-PSA|NORA sjabloon PSA en voorbeelden]]
|Status actualiteit=Actueel
|Status toelichting=
|Contactpersoon=Bas Kaptijn
|Contactgegevens={{Maillink|to=nora@ictu.nl|cc=bas.kaptijn@ictu.nl|linktext=nora@ictu.nl|subject=PSA op noraonline}}
|Afbeelding=PSA NORA Familie.png
|Onder inhoudsopgave=
;PSA Format
* {{Bestand met info|NORA PSA format.odt|PSA Format}}
* {{Bestand met info|NORA-handleiding voor het opstellen van een PSA.odt|Handleiding opstellen PSA}}
* [[Webversie PSA Format]]
* [[Webversie PSA Handleiding]]
}}
}}
Een '''PSA''' is één van de [[architectuurproducten]] die als hulpmiddel bij een project moet worden ingezet. Zo worden vernieuwingen op een goede wijze gerealiseerd. De PSA zich richt daarbij op kaders die op een project van toepassing zijn en de impact van deze kaders op de beoogde verandering.
__TOC__
Een '''Project Start Architectuur (PSA)''' is een hulpmiddel dat bij een project wordt ingezet om veranderingen van A naar Beter te faciliteren. De PSA richt zich daarbij op de kaders die op een project van toepassing zijn en wat de oplossing bijdraagt aan het realiseren van de gewenste, toekomstige architectuur, wat de implicaties zullen zijn voor bestaande voorzieningen 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.<br>
De PSA kan je daardoor zien als de belichaming van het daadwerkelijk werken met architectuur. De PSA maakt concreet wat architectuur voor een project betekent.<br><br>
==NORA PSA Format==
De NORA heeft een PSA Format ontwikkeld dat is gebaseerd op formats die bij diverse private- en overheidsorganisaties in gebruik zijn en tegelijkertijd conformeert aan de [[ISO 42010]], [https://www.iso.org/standard/74393.html geactualiseerd per 2022], en omvat zaken als:
* Een beschrijving van de beoogde verandering op hoofdlijnen<br />De doelen en ambities waaraan het project bijdraagt en invulling geeft. Dus niet de projectdoelen en –ambitie !
* De betrokken stakeholders en de belangen die ze bij deze verandering hebben en inbrengen;
* Een analyse en beschrijving van de kaders en randvoorwaarden van het project<br />De visie en strategie van de betrokken organisatie(s), architectuurvisie <ref>Architecture Vision, TOGAF</ref>, afspraken, relevante delen van de enterprise- en/of domein-architectuur, [[NORA-principe|principes]], richtlijnen, [[standaarden]] en normen, die richting geven aan de oplossing die een project gaat realiseren;
* Een schets van de context en afbakening van de oplossingsmogelijkheden en de samenhang met bestaande en te realiseren diensten;
* Keuzemogelijkheden bij het ontwerp van de oplossing, zoals voor de samenhang in de informatievoorziening, interoperabiliteit van informatie, herbruikbaarheid van de oplossing en afnemende beheerlasten;
* Een explicitering van de impact van keuzes t.a.v. de oplossing en een verantwoorde onderbouwing van afwijkingen (zo borgt de PSA dat toekomstvaste en duurzame besluiten worden genomen).


==Waarom een PSA==
Een PSA kan 'dun' of 'dik' worden opgesteld, afhankelijk van de uitgangssituatie van het project. Sommige projecten starten met een groene weide met slechts enkele globale kaders. Het is dan aan het project om de context, afbakening en impact van keuzes verder uit te werken en af te stemmen. Dan kan een PSA dun zijn (in het ideale geval zo dun dat een samenvatting overbodig is). In andere situaties zijn de wensen en verwachtingen veel verder gespecificeerd en is het landschap waarop aangesloten moet worden complexer. In zo'n situatie kan een wat dikkere PSA nodig zijn.<br>


Een bestuurder heeft met een PSA alle ‘ins’ en ‘outs’ beschikbaar om een verantwoord besluit te nemen over een project. Met een PSA voorkom je dat het project achteraf op verrassingen stuit, waarvan de informatievoorziening in meest brede zin later last kan krijgen.  
De PSA beschrijft in elk geval niet de werking van de voorziening en hoe de door de voorziening te leveren diensten worden gebouwd. Dit komt later aan bod, bij de doorontwikkeling van de PSA naar de [[Solution-architectuur]].<br>
In de praktijk blijkt de samenhang tussen de PSA en Solution Architectuur (SA) soms tot vragen en discussies te leiden, zoals: ga je een aparte solution architectuur uitwerken of ga je ‘gewoon’ de PSA detailleren? <br>
Wellicht is het handig dat we in de toekomst de samenhang tussen een PSA en een SA nader uitwerken. Bij voorbeeld door ook een sjabloon te maken voor een Solution Architectuur en criteria voor wanneer een PSA te detailleren dan wel een aparte SA uit te werken.<br>
Zie ook [[Types architecturen in NORA-familie]].


Zo geeft de PSA de bestuurder/beslisser/projectmanager, middels kaders en randvoorwaarden, inzicht in de oplossing waar aan gedacht wordt en welke consequenties er aan gekozen voorstellen vastzitten.  
==Direct naar PSA Format & Handleiding==
Overigens is een PSA bij het Rijk verplicht voor grote projecten met een ICT component vanaf €20 miljoen en met een publiek afbreukrisico. Een PSA is zeker ook zinvol voor kleinere projecten.
De nieuwste versie van het PSA Format 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.
* {{Bestand met info|NORA PSA format.odt|PSA Format}}
* {{Bestand met info|NORA-handleiding voor het opstellen van een PSA.odt|Handleiding opstellen PSA}}
* [[Webversie PSA Format]]
* [[Webversie PSA Handleiding]]


==Wanneer pas je een PSA toe?==
==Waarom een PSA?==
Het is de bedoeling dat alle betrokkenen, dus zowel architecten als niet-architecten, met een PSA de essentie van een project snel kunnen doorgronden. Dit maakt de PSA –samen met de PID– een belangrijk instrument 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.


Een PSA wordt voor de start van een project (in de initiatiefase) ter besluitvorming aangeboden. Opdracht voor het maken van een PSA wordt na het [[Project Mandaat]]<ref>een term afkomstig uit de Prince2 projectmethodiek</ref> gegeven tegelijkertijd met de opdracht voor het maken van een plan van aanpak ([[PID (Project Initiatie Document)|project initiatie document, PID]]). Daarmee is de PSA integraal onderdeel van de PID.
Met een PSA maak je daardoor een vliegende start en voorkom je dat het project op verrassingen stuit, waarvan de informatievoorziening in de meest brede zin later last kan krijgen.


==Doel van een PSA==
Voor elke stakeholder levert een PSA iets op:
Op basis van een doelarchitectuur, dat is de architectuur van de uiteindelijk gewenste situatie, geeft een PSA richting aan de (technische) oplossing, die een project gaat realiseren. Vervolgens wordt in een [[solution architectuur]] de voorgestelde oplossing uitgewerkt. . Het belangrijkste doel van een PSA is het ondersteunen van de besluitvorming. Dit doet het door:
* Een bestuurder heeft met een PSA alle ‘ins’ en ‘outs’ beschikbaar om een verantwoord besluit te nemen over een project;
* De projectmanager kan aan de hand van de kaders en randvoorwaarden van de PSA, de context en richting van een project duidelijk maken en ruimte bieden voor oplossingsmogelijkheden, hetgeen de uitvoering vergemakkelijkt;
* De professionals kunnen met een PSA gerichter aan de slag om concrete, passende oplossingen voor te stellen die passen binnen de kaders van de PSA: ''werken met architectuur''.
De PSA zorgt er uiteindelijk voor dat een [[solution-architectuur]] opgesteld kan worden die aansluit op de wensen van alle stakeholders.


* Het analyseren en beschrijven van de kaders en randvoorwaarden van het project.
Volgens [[NORA_Familie#De_NORA_als_referentie-architectuur_voor_de_gehele_overheid|Kabinetsbeleid]] moet voor elk nieuw groot ICT-project een PSA worden opgesteld in lijn met de NORA.<br>
* Het expliciteren van de impact van keuzes t.a.v. de oplossing. Zo borgt het dat toekomstvaste en duurzame besluiten worden genomen.
Bij het Rijk is het daarom verplicht voor grote projecten met een ICT-component vanaf €20 miljoen en met een publiek afbreukrisico een PSA op te stellen. Maar een PSA is zeker ook zinvol voor kleinere projecten !
* Het meer inzicht geven in de onderbouwing van de business case bij het opstellen van een projectplan (PID).
* Het sturing geven aan het ontwerp van de oplossing. Denk aan zaken als: samenhang in informatievoorziening, interoperabiliteit van informatie, herbruikbaarheid van de oplossing en afnemende beheerslasten.


==Wat mag je van een PSA verwachten?==
==Wanneer pas je een PSA bij een project toe?==
Een PSA wordt voor de start van een project (wat bij Prince2 de initiatiefase wordt genoemd) ter besluitvorming aangeboden. Opdracht voor het maken van een PSA wordt na het Projectmandaat<ref>[https://www.pinkelephant.nl/kennisbank/prince2/opstarten-van-een-project/?hilite=%27Projectmandaat%27 Projectmandaat] is een term uit de PRINCE2 projectmanagementmethodiek</ref> gegeven, tegelijkertijd met de opdracht voor het maken van een plan van aanpak (PID<ref>Projectinitiatiedocumentatie, ook een PRINCE2-term</ref>). De PSA is bedoeld om meer inzicht te geven in de onderbouwing van de business case bij het opstellen van een projectplan/PID. Daarmee is de PSA onderdeel van de PID en voorkom je dat doublures optreden.


Een PSA:
Hoewel hier dus wordt gerefereerd aan PRINCE2 (als voorbeeld), kan een PSA ook van toepassing zijn bij andere projectmanagementmethoden, zoals Agile.
* beschrijft de belangrijkste kaders en randvoorwaarden (o.a. afspraken, [[principe]]s, richtlijnen, standaarden en normen) die richting geven aan de oplossing die een project gaat realiseren en schetst de implicaties ervan voor de oplossing.
* schetst de context en afbakening van de oplossing en de samenhang met bestaande en te realiseren diensten, voorzieningen en bouwstenen.
* kan 'dun' of 'dik' opgesteld worden, al naar gelang de behoefte van het project. Een 'dikke PSA' kan deels een [[solution architectuur]] in zich hebben.


==PSA Sjabloon NORA==
==Wanneer pas je een PSA in een Agile omgeving toe?==
Om te bevorderen dat er kwalitatief goede PSA’s worden opgesteld, waarin aan alle relevante aspecten aandacht wordt besteed. Dit om te voorkomen dat elk project zelf gaat nadenken over de opzet van een PSA is [[Voorbeeld-PSA|een sjabloon/format]] opgesteld.
Een PSA richt zich van oorsprong op projectmatige veranderingen. Toch is het van belang om ook in een agile omgeving een PSA toe te passen. Immers, ook in een agile omgeving is het nodig om besluitvorming over een of meer epics te ondersteunen en om vooraf kaders mee te geven aan de ontwikkeling daarvan. <br>
Het veel toegepaste Scaled Agile Framework (SAFe) spreekt over het zoeken van balans tussen Intentional Architecture en Emergent Design<ref> zie [https://www.scaledagileframework.com/agile-architecture/ SAFe agile architecture]</ref>. Een PSA biedt dan het vehikel om die kaders mee te geven die essentieel zijn en vrijheid te behouden waar dat nuttig is. <br> <br>
Als je wilt weten hoe je in een Agile omgeving het architectuur gedachtengoed effectief kan combineren, lees dan het artikel [https://www.researchgate.net/publication/370960006_Scaling_Agile_Company-Wide_The_Organizational_Challenge_of_Combining_Agile_Scaling_Frameworks_and_Enterprise_Architecture_in_Service_Companies#fullTextFileContent Agile en Architectuur].Hierin staan praktische tips vanuit agile perspectief richting Enterprise en Solution architectuur als andersom in relatie tot de rol en samenwerking van architecten in agile teams, coördinatiemethoden binnen en tussen agile teams en het balanceren van “emerging”  en doel architecturen.
 
==Hoe stel je een PSA op?==
Er zijn verschillende methodieken om architectuur te ontwikkelen. De NORA doet geen uitspraken over een daartoe te gebruiken methode. Het opstellen van een PSA maakt integraal onderdeel uit van het ontwikkelen van een architectuur.<br>
Een PSA wordt in een vroeg stadium van het project gebruikt. Het is in die fase belangrijk om een korte doorlooptijd te hanteren. Door de stakeholders en verschillende disciplines te betrekken bij het schrijven van de PSA, wordt de kans op witte vlekken verkleind en zijn alle partijen vanaf het begin aangehaakt.<br>
De opdrachtgever/producteigenaar keurt de uiteindelijke PSA goed. Deze partij kan toezien op naleving van de PSA in vervolgproducten.
 
In het voorjaar van 2023 is door een werkgroep van de NORA een nieuwe opzet gemaakt van het {{Bestand met info|NORA-format van een PSA - versie 6 juni 2023 def.pdf|PSA-format}}, op basis van de nieuwe ISO 42010:2022 (dat was voorheen de versie uit 2011) én afgestemd op de nieuwe NORA Architectuurprincipes. Naast het PSA-format is ook de {{Bestand met info|NORA-handleiding voor het opstellen van een PSA - versie 6 juni 2023 def.pdf|PSA-handleiding}} geactualiseerd.<br>
Zie de achtergrond en bespreking daarvan tijdens de bijeenkomst van de NORA Gebruikersraad op [https://www.noraonline.nl/wiki/NORA_Gebruikersraad_2023-06-06#15.30_u._-_Vaststellen_nieuw_PSA-format_en_-handleiding 6 juni 2023].
 
Met deze 2 stukken verwachten we de professional snel op weg te helpen om een degelijke PSA op te stellen, waarin aan alle relevante aspecten aandacht wordt besteed. Ze zijn gebaseerd op ervaringen vanuit verschillende (grote) organisaties en geven als het ware de 'goede voorbeelden' weer. Het basisidee is dat iedere professional het PSA-sjabloon van NORA als uitgangspunt neemt. In de praktijk blijkt dat organisaties weliswaar uitgaan van dezelfde inhoud, maar deze op uiteenlopende wijze ordenen, afgestemd op de behoefte en ervaring van de gebruikers binnen hun organisatie.


==Contact==
==Contact==
Voor vragen kan je terecht bij Jacques Verdaas en Paul van Raaij via [mailto:architectuur@ictu.nl architectuur@ictu.nl].
Vragen en suggesties kunnen worden gestuurd naar Bas Kaptijn (ICTU), via {{Maillink|to=nora@ictu.nl|cc=bas.kaptijn@ictu.nl|linktext=nora@ictu.nl|subject=Doorontwikkeling PSA}}.
==Zie ook==
 
==Referenties==
<references />
<references />
[[Categorie:Instrumenten]][[Categorie:NORA instrumenten]]
[[Categorie:PSA]]

Huidige versie van 18 feb 2024 om 18:32

Een Project Start Architectuur (PSA) is een hulpmiddel dat bij een project wordt ingezet om veranderingen van A naar Beter te faciliteren. De PSA richt zich daarbij op de kaders die op een project van toepassing zijn en wat de oplossing bijdraagt aan het realiseren van de gewenste, toekomstige architectuur, wat de implicaties zullen zijn voor bestaande voorzieningen 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 kan je daardoor zien als de belichaming van het daadwerkelijk werken met architectuur. De PSA maakt concreet wat architectuur voor een project betekent.

NORA PSA Format[bewerken]

De NORA heeft een PSA Format ontwikkeld dat is gebaseerd op formats die bij diverse private- en overheidsorganisaties in gebruik zijn en tegelijkertijd conformeert aan de ISO 42010, geactualiseerd per 2022, en omvat zaken als:

  • Een beschrijving van de beoogde verandering op hoofdlijnen
    De doelen en ambities waaraan het project bijdraagt en invulling geeft. Dus niet de projectdoelen en –ambitie !
  • De betrokken stakeholders en de belangen die ze bij deze verandering hebben en inbrengen;
  • Een analyse en beschrijving van de kaders en randvoorwaarden van het project
    De visie en strategie van de betrokken organisatie(s), architectuurvisie [1], afspraken, relevante delen van de enterprise- en/of domein-architectuur, principes, richtlijnen, standaarden en normen, die richting geven aan de oplossing die een project gaat realiseren;
  • Een schets van de context en afbakening van de oplossingsmogelijkheden en de samenhang met bestaande en te realiseren diensten;
  • Keuzemogelijkheden bij het ontwerp van de oplossing, zoals voor de samenhang in de informatievoorziening, interoperabiliteit van informatie, herbruikbaarheid van de oplossing en afnemende beheerlasten;
  • Een explicitering van de impact van keuzes t.a.v. de oplossing en een verantwoorde onderbouwing van afwijkingen (zo borgt de PSA dat toekomstvaste en duurzame besluiten worden genomen).

Een PSA kan 'dun' of 'dik' worden opgesteld, afhankelijk van de uitgangssituatie van het project. Sommige projecten starten met een groene weide met slechts enkele globale kaders. Het is dan aan het project om de context, afbakening en impact van keuzes verder uit te werken en af te stemmen. Dan kan een PSA dun zijn (in het ideale geval zo dun dat een samenvatting overbodig is). In andere situaties zijn de wensen en verwachtingen veel verder gespecificeerd en is het landschap waarop aangesloten moet worden complexer. In zo'n situatie kan een wat dikkere PSA nodig zijn.

De PSA beschrijft in elk geval niet de werking van de voorziening en hoe de door de voorziening te leveren diensten worden gebouwd. Dit komt later aan bod, bij de doorontwikkeling van de PSA naar de Solution-architectuur.
In de praktijk blijkt de samenhang tussen de PSA en Solution Architectuur (SA) soms tot vragen en discussies te leiden, zoals: ga je een aparte solution architectuur uitwerken of ga je ‘gewoon’ de PSA detailleren?
Wellicht is het handig dat we in de toekomst de samenhang tussen een PSA en een SA nader uitwerken. Bij voorbeeld door ook een sjabloon te maken voor een Solution Architectuur en criteria voor wanneer een PSA te detailleren dan wel een aparte SA uit te werken.
Zie ook Types architecturen in NORA-familie.

Direct naar PSA Format & Handleiding[bewerken]

De nieuwste versie van het PSA Format 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.

Waarom een PSA?[bewerken]

Het is de bedoeling dat alle betrokkenen, dus zowel architecten als niet-architecten, met een PSA de essentie van een project snel kunnen doorgronden. Dit maakt de PSA –samen met de PID– een belangrijk instrument dat inzicht geeft in de implicaties van de door het project te realiseren resultaten. Daarbij dient de PSA twee hoofddoelen:

  1. Ondersteuning van besluitvorming bij het starten van het project (gericht op adviseurs en beslissers).
  2. Kaderstellend en richtinggevend voor architecten en ontwikkelaars tijdens de uitvoering van het project.

Met een PSA maak je daardoor een vliegende start en voorkom je 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 alle ‘ins’ en ‘outs’ beschikbaar om een verantwoord besluit te nemen over een project;
  • De projectmanager kan aan de hand van de kaders en randvoorwaarden van de PSA, de context en richting van een project duidelijk maken en ruimte bieden voor oplossingsmogelijkheden, hetgeen de uitvoering vergemakkelijkt;
  • De professionals kunnen met een PSA gerichter aan de slag om concrete, passende oplossingen voor te stellen die passen binnen de kaders van de PSA: werken met architectuur.

De PSA zorgt er uiteindelijk voor dat een solution-architectuur opgesteld kan worden die aansluit op de wensen van alle stakeholders.

Volgens Kabinetsbeleid moet voor elk nieuw groot ICT-project een PSA worden opgesteld in lijn met de NORA.
Bij het Rijk is het daarom verplicht voor grote projecten met een ICT-component vanaf €20 miljoen en met een publiek afbreukrisico een PSA op te stellen. Maar een PSA is zeker ook zinvol voor kleinere projecten !

Wanneer pas je een PSA bij een project toe?[bewerken]

Een PSA wordt voor de start van een project (wat bij Prince2 de initiatiefase wordt genoemd) ter besluitvorming aangeboden. Opdracht voor het maken van een PSA wordt na het Projectmandaat[2] gegeven, tegelijkertijd met de opdracht voor het maken van een plan van aanpak (PID[3]). De PSA is bedoeld om meer inzicht te geven in de onderbouwing van de business case bij het opstellen van een projectplan/PID. Daarmee is de PSA onderdeel van de PID en voorkom je dat doublures optreden.

Hoewel hier dus wordt gerefereerd aan PRINCE2 (als voorbeeld), kan een PSA ook van toepassing zijn bij andere projectmanagementmethoden, zoals Agile.

Wanneer pas je een PSA in een Agile omgeving toe?[bewerken]

Een PSA richt zich van oorsprong op projectmatige veranderingen. Toch is het van belang om ook in een agile omgeving een PSA toe te passen. Immers, ook in een agile omgeving is het nodig om besluitvorming over een of meer epics te ondersteunen en om vooraf kaders mee te geven aan de ontwikkeling daarvan.
Het veel toegepaste Scaled Agile Framework (SAFe) spreekt over het zoeken van balans tussen Intentional Architecture en Emergent Design[4]. Een PSA biedt dan het vehikel om die kaders mee te geven die essentieel zijn en vrijheid te behouden waar dat nuttig is.

Als je wilt weten hoe je in een Agile omgeving het architectuur gedachtengoed effectief kan combineren, lees dan het artikel Agile en Architectuur.Hierin staan praktische tips vanuit agile perspectief richting Enterprise en Solution architectuur als andersom in relatie tot de rol en samenwerking van architecten in agile teams, coördinatiemethoden binnen en tussen agile teams en het balanceren van “emerging” en doel architecturen.

Hoe stel je een PSA op?[bewerken]

Er zijn verschillende methodieken om architectuur te ontwikkelen. De NORA doet geen uitspraken over een daartoe te gebruiken methode. Het opstellen van een PSA maakt integraal onderdeel uit van het ontwikkelen van een architectuur.
Een PSA wordt in een vroeg stadium van het project gebruikt. Het is in die fase belangrijk om een korte doorlooptijd te hanteren. Door de stakeholders en verschillende disciplines te betrekken bij het schrijven van de PSA, wordt de kans op witte vlekken verkleind en zijn alle partijen vanaf het begin aangehaakt.
De opdrachtgever/producteigenaar keurt de uiteindelijke PSA goed. Deze partij kan toezien op naleving van de PSA in vervolgproducten.

In het voorjaar van 2023 is door een werkgroep van de NORA een nieuwe opzet gemaakt van het PSA-format (PDF, 380 kB), op basis van de nieuwe ISO 42010:2022 (dat was voorheen de versie uit 2011) én afgestemd op de nieuwe NORA Architectuurprincipes. Naast het PSA-format is ook de PSA-handleiding (PDF, 944 kB) geactualiseerd.
Zie de achtergrond en bespreking daarvan tijdens de bijeenkomst van de NORA Gebruikersraad op 6 juni 2023.

Met deze 2 stukken verwachten we de professional snel op weg te helpen om een degelijke PSA op te stellen, waarin aan alle relevante aspecten aandacht wordt besteed. Ze zijn gebaseerd op ervaringen vanuit verschillende (grote) organisaties en geven als het ware de 'goede voorbeelden' weer. Het basisidee is dat iedere professional het PSA-sjabloon van NORA als uitgangspunt neemt. In de praktijk blijkt dat organisaties weliswaar uitgaan van dezelfde inhoud, maar deze op uiteenlopende wijze ordenen, afgestemd op de behoefte en ervaring van de gebruikers binnen hun organisatie.

Contact[bewerken]

Vragen en suggesties kunnen worden gestuurd naar Bas Kaptijn (ICTU), via nora@ictu.nl.

Referenties[bewerken]

  1. Architecture Vision, TOGAF
  2. Projectmandaat is een term uit de PRINCE2 projectmanagementmethodiek
  3. Projectinitiatiedocumentatie, ook een PRINCE2-term
  4. zie SAFe agile architecture