Webversie PSA Handleiding
NORA-handleiding voor het opstellen van een PSA.
1.1 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.
1.2 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). Eerst geven we de uitwerking hoe het dat doet in de traditionele aanpak, zonder Scrum / Agile aanpak.
De PSA is een stap in de uitwerking van de overheidsstrategie (Beleidsimplementatie) in een te realiseren verandering. De Enterprise Architectuur is een uitwerking van de (informatie)strategie en wordt tevens gevoed door de Solution Architecturen van reeds gerealiseerde veranderingen (waaronder systeem c.q. applicatiewijzigingen). De PSA vormt zo de spil tussen strategie en realisatie. Via de stappen van Informatiestrategie, Informatie Plan en Portfoliomanagement komt de overheidsstrategie samen met een concrete behoeften vanuit de business, in een Project Brief voor een concreet project. De Project Brief vormt met de Enterprise Architectuur het kader voor de PSA. De PSA voedt terug aan de Business Case en het Project plan, die ook vanuit de Project Brief voortkomen. En samen met het Project Plan is de PSA de start en het kader voor de Solution Architectuur en de Software Architectuur Description (SAD). Zo loopt de lijn van strategie naar uitvoering zowel door de architectuurkant (EA) als de kant van de business en projectmanagement. Door de Project Resultaten en de Solution Architectuur aan een Architectuur Review te onderwerpen kunnen zowel geleerde lessen als afwijkingen terugkomen in de Enterprise Architectuur.
Als we wel een SCRUM / Agile aanpak gebruiken is het minder zinvol om de afbakeningen tussen verschillende documenten te hanteren zoals je dat doet in de traditionele aanpak. De projectuitvoering (Solution Architectuur, SAD, Architectuur Review en Project resultaten in het oude voorbeeld) wordt uitgebreid met de Project Start Architectuur, die een levend document is bij elke sprint iteratief wordt aangevuld en geactualiseerd. Ook de SAD wordt iteratief opgezet.
Wat gelijk blijft, is het belang om wijzigingen en keuzes die breder zijn dan het project zelf, terug te voeden naar de Enterprise Architectuur.
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 en onder andere titels en hoeft niet zozeer een bepaalde volgorde aan te houden (als het document het maar bevat). Hieronder zijn in ieder geval de belangrijkste aspecten benoemd, die in enige vorm wel aan bod moeten komen in een PSA. Deze aspecten worden verder uitgewerkt in het NORA PSA-format:
- Het beschouwde “systeem”, zie ISO 42010:2022 Hoofdstuk 6.1. Dit omvat een introductie met een algemene beschrijving en het doel van de Entity of Interest (EoI), hetgeen voorheen System of Interest (SoI) heette1, alsook een beschrijving van de omgeving (het domein) waarin deze zich bevindt en een beschrijving van de verandering daarin die door de organisatie(s) met het project wordt beoogd.
- De betrokken actoren/stakeholders, zie ISO 42010:2022 Hoofdstuk 6.2.
- Met hun perspectieven, zie ISO 42010:2022 Hoofdstuk 6.3. Denk daarbij aan de Kernwaarden van Dienstverlening.
- En hun belangen, zie ISO 42010:2022 Hoofdstuk 6.4. Denk daarbij aan de Kwaliteitsdoelen.
- De relevante aspecten bij het project, zie ISO 42010:2022 Hoofdstuk 6.5.Denk daarbij aan de Architectuurprincipes en daaruit volgende Implicaties van Architectuurprincipes. Maar ook principiële uitspraken die vanuit de betrokken organisatie(s) zijn opgesteld. Bijvoorbeeld vanuit de Enterprise Architectuur of referentie architecturen zoals de GEMMA, PETRA en RORA (voorheen EAR). Van belang is de vertaling van deze principiële uitspraken naar principes en afspraken over standaarden die voor het project van toepassing zijn.
- De invalshoeken (viewpoints, views) van waaruit het systeem wordt beschouwd, zie ISO 42010:2022 Hoofdstuk 6.6, 6.7 en 6.8. De architectuurbeschrijving moet expliciet maken via welke invalshoeken en daarbij behorende componenten de eerder geïdentificeerde perspectieven, belangen en relevante aspecten behandeld worden. Denk hierbij aan het toepassen van het NORA Vijflaagsmodel om die invalshoeken en bijbehorende componenten te structureren.
- De samenhang (correspondence recording), zie ISO 42010:2022 Hoofdstuk 6.9. Een duidelijk overzicht geven van hoe architectuurbeschrijvingselementen (perspectives, concerns, aspects, viewpoints, views, view componenten, …) met elkaar samenhangen binnen de architectuurbeschrijving, alsook in relatie tot andere architectuurbeschrijvingen of architectuurbeschrijvingsframeworks (ADF’s) zoals de NORA of architectuurbeschrijvingstalen (ADL’s) zoals Archimate. Bedoeld is met name de inconsistenties en afwijkingen te benoemen. Maar hier wordt dus expliciet de link gelegd met het conformeren aan de NORA, eventuele aanvullingen op de NORA of afwijkingen van de NORA.
- Besluiten en overwegingen (Decision en Rationale recording), zie ISO 42010:2022 Hoofdstuk 6.10. Een overzicht geven van alle belangrijke inhoudelijke besluiten die zijn gemaakt binnen de totstandkoming van de architectuurbeschrijving, inclusief de rationale ervan (het waarom). Daarbij moeten ook de overwogen alternatieven, en afgewezen opties en afwijkingen worden genoemd met de rationale erbij (waarom niet is gekozen voor een bepaald alternatief).
Deze inhoudsopgave van de PSA is niet uitputtend. Er kan naar inzicht van de betrokkenen van worden afgeweken, wanneer dit gezien de omstandigheden of situatie beter uitkomt of nodig is. Een PSA is in beginsel compact: eerder een aantal bladzijden met een beknopte tekst en duidelijke visualisaties, dan een omvangrijk document. Dit is wel afhankelijk van de omvang van het vraagstuk en de context en moet daarom bij ieder project apart worden afgewogen.
Het vijflaagsmodel van de NORA is een nuttig hulpmiddel om de diverse aspecten in kaart te brengen. Daarnaast is de idEA methodiek een behulpzame methode om via workshops en een visualisatie inzichten en draagvlak te verkrijgen bij stakeholders. Hierbij wordt in workshops met stakeholders een beeld verkregen van wat het project gaat doen en hoe het zich verhoudt tot voorzieningen en initiatieven in de organisatie of keten. Daar wordt vervolgens dan een visualisatie van gemaakt.
Het NORA Vijflaagsmodel, in de vorm van een idEA visualisatie met toelichting, maakt altijd deel uit van een PSA. De NORA Architectuur Principes (NAP’s) hebben een duidelijke relatie met de verschillende lagen in het vijflaagsmodel en worden per invalshoek toegelicht.
De NAP’s hebben een algemeen en globaal karakter. Nu is het zaak om deze NAP’s specifiek op de context van het project toe te passen. Zodoende wordt vanuit diverse invalshoeken naar het project gekeken en wordt gewaarborgd dat verschillende zaken worden belicht die mogelijk in eerste instantie niet relevant geacht werden. In de praktijk zal blijken dat diverse NAP’s zeer relevant blijken te zijn en andere vrijwel niet. Het heeft vooral zin om de implicaties van de relevante NAP’s verder uit te werken en daarmee de oplossingsrichting van het ontwerp aan te scherpen.
Als je uitgaat van de belangrijkste te behalen maatschappelijke waarden (die zijn beschreven via Kwaliteitsdoelen en de stakeholders kunnen daar hun belangen aan relateren), dan kan je eenvoudig nagaan met welke NORA Architectuur Principes je die kunt realiseren: zie de tabel bij de kwaliteitsdoelen.
Onderstaande figuur betreft een visualisatie van de huidige situatie en de gewenste situatie. De verschillen worden in teksten goed toegelicht en zijn ook zichtbaar, waarmee eveneens transparant wordt gemaakt wat het project gaat realiseren. Hier gaat een goede communicatieve werking van uit. De doelen van het project zijn in een paar luttele minuten uit te leggen.
Aan de hand van een dergelijke visualisatie kunnen ook goed de relaties van de door het project te realiseren voorziening met andere gerelateerde voorzieningen in kaart worden gebracht.
Zo wordt duidelijker wat het project specifiek – als onderdeel van een groter geheel – aan resultaten gaat opleveren.
1.5 De te doorlopen stappen bij het opstellen van een PSA[bewerken]
De PSA is het resultaat van een multidisciplinaire inspanning, waarbij de architect penvoerder is. Uitgangspunt is dat de architect samenwerkt met een collega adviseur / visualisatie-expert om te sparren en continuïteit van beschikbare (architectuur-)kennis te borgen. De aangegeven inzet is die van deze twee personen.
1. Inlezen in stukken[bewerken]
De PSA wordt afgestemd op de inhoud van een project-brief en relevante onderdelen uit zowel een bestaande architectuur als een doel-architectuur (doorgaans onderdelen van een EA). De architect verzamelt daartoe de relevante documentatie. Denk daarbij aan het doornemen van de door een opdrachtgever ter beschikking gestelde documenten en eventueel enkele extra stukken die bekend zijn bij betrokkenen. Doorlooptijd 1 week, 2p x 8 a 16 uur Totaal 16 a 32 uur
2. Vooroverleg met opdrachtgever[bewerken]
Voorafgaand aan de workshops worden de stakeholders daarvan bepaald, samen met een inschatting van hun rol en belangen. Daarnaast wordt nagegaan welke kaders, documenten e.d. zullen worden gehanteerd. Doorlooptijd 1 week, 2p x 4 uur Totaal 8 uur
3. Interviews ter voorbereiding op workshops[bewerken]
Het draagvlak voor workshops wordt doorgaans groter indien voorafgaand een gesprek met (bijvoorbeeld de 4 meest bepalende) stakeholders heeft plaatsgevonden, waarin hun rol en belangen worden besproken en erkend. Doorlooptijd 2 weken, 2p x 4 a 4 uur Totaal 32 uur
4. Start-workshop[bewerken]
Op basis van de beschikbare documenten en de verkregen informatie wordt een opzet gemaakt van de te bespreken vraagstukken en issues. Daarnaast plant de architect een bijeenkomst c.q. workshop met (een vertegenwoordiger van) de opdrachtgever, de projectleider en enkele domeindeskundigen vanuit de business, voor het verkrijgen van extra informatie. De deelnemers worden uitgenodigd en de benodigde documentatie wordt hen beschikbaar gesteld. Deelnemers lezen zich in. Tijdens de workshop wordt met deelnemers inzicht en overzicht gecreëerd van de verandering die we willen realiseren. De architect en de deelnemers bespreken daartoe gezamenlijk de verzamelde kaders, randvoorwaarden, etc. en toetsen deze aan hun eigen beelden. Eventueel worden de beelden aangevuld met extra informatie. Hiervoor wordt de idEA aanpak gehanteerd, welke uiteindelijk resulteert in visualisaties met verschillende lagen van:
- maatschappelijke waarden en de dienstverlening;
- stakeholders;
- processen;
- informatie(stromen);
- onderliggende voorzieningen.
Vervolgens worden de implicaties van de kaders en context voor de te realiseren oplossing besproken en worden de nodige besluiten genomen, zodat de architect daarna de PSA kan gaan opstellen. Doorlooptijd 1 week, 2p x 16 a 20 uur Totaal 32 a 40 uur
5. Eerste aanzet PSA[bewerken]
De uitkomsten van de workshop worden door de architect verwerkt in een eerste aanzet van de PSA. Daarbij kan het NORA PSA-format worden gebruikt. Ontbrekende aspecten worden onderkend en voorbereid voor de volgende workshop. De visualisatie wordt gemaakt en vraagstukken worden beschreven in termen van het vijflaagsmodel, Architectuur Principes en relevante thema’s van de NORA. De thema’s Privacy, Beveiliging en Beheer zijn altijd relevant. Deze eerste versie wordt gedeeld met de deelnemers van de eerdere workshop. Doorlooptijd 2 weken, 2p x 24 a 32 uur Totaal 48 a 64 uur
6. Tussentijds bespreken met de opdrachtgever[bewerken]
Na afloop van de workshop wordt samen met de opdrachtgever nagegaan in hoeverre de uitkomsten aan de verwachtingen voldoen en of eventueel een extra workshop nodig is om aanvullende resultaten te bereiken. Ook wordt bepaald met wie de concept PSA nog meer gedeeld gaat worden om tot een definitieve versie te komen. Zo nodig worden nog meer bijeenkomsten ingepland. Doorlooptijd 1 week, 2p x 4 uur Totaal 8 uur
7. Optioneel: extra-workshop[bewerken]
Indien extra of verdiepende resultaten nodig zijn, wordt een workshop daartoe gepland en gehouden. Daarnaast worden de resultaten daarvan verwerkt in de PSA. Doorlooptijd 3 weken, 2p x 16 a 20 uur Totaal 32 a 40 uur
8. Afsluitende-workshop[bewerken]
De PSA, inclusief visualisaties en beschrijvingen, wordt vooraf toegestuurd en daarna plenair met de stakeholders besproken en van reflecties voorzien. Doorlooptijd 1 week, 2p x 16 a 20 uur Totaal 32 a 40 uur
9. Definitieve versie PSA[bewerken]
Alle uitkomsten en reflecties van de Afsluitende-workshop worden verwerkt in de PSA. De PSA wordt aan alle stakeholders beschikbaar gesteld voor de laatste aanvullingen en opmerkingen en die reacties worden verwerkt in de definitieve versie van de PSA. Doorlooptijd 3 weken, 2p x 16 a 20 uur Totaal 32 a 40 uur
10. Opslag en beheer[bewerken]
De definitieve PSA en relevante documentatie wordt in het projectdossier opgenomen en blijft onder beheer van de architect. Daarnaast is het ook nodig dat de PSA geïntegreerd wordt met de Enterprise Architectuur dan wel Domein- of Ketenarchitectuur. De architect stemt dat af met de betreffende enterprise- c.q. domein- of ketenarchitect.
NB. Het beheer en eventueel publiekelijk publiceren van PSA’s is nog weinig besproken binnen de architecten-community, maar heeft zeker de voorkeur gezien de Woo en de wens voor meer transparantie bij de overheid. Daarbij speelt de te maken afweging tussen transparantie en veiligheid: afhankelijk van het onderwerp / PSA zal dit moeten worden bepaald.
Let op[bewerken]
De doorlooptijd voor het maken van een PSA is met name afhankelijk van de beschikbaarheid van de stakeholders die bij de 2 (of meer) workshops worden betrokken. Er zijn doorgaans zeker 12 tot 15 weken nodig.
1.6 Indicatie benodigde expertise[bewerken]
Expertise die bij het opstellen van een PSA nodig is:
- Een ervaren business architect die de penvoerder is van de PSA.
- Een ervaren adviseur / visualisatie-expert die de workshops begeleidt en de visualisaties verzorgt.
- Een PSA-expert die zorgt voor kwaliteitsborging en de peer-review van de PSA.
Daarnaast kunnen in overleg altijd nog andere medewerkers met specifieke expertise worden ingezet, al naar gelang het vraagstuk dat speelt.
1.7 Indicatie benodigde tijd c.q. budget[bewerken]
| Activiteit | Benodigde uren | |
|---|---|---|
| 1 | Inlezen stukken | 20 - 28 uur |
| 2 | Vooroverleg met opdrachtgever | 8 uur |
| 3 | Interviews ter voorbereiding workshop | 32 uur |
| 4 | Start-workshop | 32 - 40 uur |
| 5 | Eerste aanzet PSA | 48 - 64 uur |
| 6 | Tussentijds bespreken met opdrachtgever | 8 uur |
| 7 | Optioneel: extra-workshop | 32 - 40 uur |
| 8 | Afsluitende-workshop | 32 - 40 uur |
| 9 | Definitieve versie PSA | 32 - 40 uur |
| Totaal | 244 – 300 uur |