WHITE PAPER PROJECT START ARCHITECTUUR

WHITE PAPER

PROJECT START ARCHITECTUUR JOOST LUIJPERS

WHITE PAPER PROJECT START ARCHITECTUUR

Joost Luijpers

Versie: 1.0 oktober 2009

Copyright Sogeti Nederland B.V. © te Vianen Niets uit deze uitgave mag worden verveelvoudigd (voor willekeurig welke doeleinden) door middel van druk, fotokopie, microfilm, geluidsband, elektronisch of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van Sogeti Nederland B.V.

Sogeti Nederland B.V. oktober 2009

1.0

I

Whitepaper: Project Start Architectuur Inhoudsopgave

INHOUDSOPGAVE INHOUDSOPGAVE ............................................................................ 1 1

2

3

4

5

INLEIDING .............................................................................. 3 1.1

Doel van dit document ............................................................................3

1.2

Opzet van dit document ..........................................................................3

HET DOEL VAN DE PSA ............................................................... 4 2.1

De toegevoegde waarde van de PSA ............................................................4

2.2

De drie architectuuraspecten in de PSA .......................................................5 2.2.1

Van abstract naar concreet .............................................................6

2.2.2

Deelarchitecturen ........................................................................6

2.2.3

Tijdsaspect ................................................................................6

2.3

De PSA reflecteert de architectuuraspecten ............................................7

2.4

De PSA als validatie-instrument .................................................................8

DE BETROKKENEN BIJ DE PSA ....................................................... 9 3.1

De ‘verantwoordelijken’ ..........................................................................9

3.2

De ‘stakeholders’ van de PSA .................................................................. 11

3.3

De ‘opstellers’ van de PSA ..................................................................... 12

DE PROCESSEN ROND DE PSA ....................................................... 13 4.1

Ondersteuning van architectuur aan projecten ............................................ 13

4.2

Het opstellen van de PSA ....................................................................... 14 4.2.1

De activiteiten voor het opstellen van de PSA .................................... 15

4.2.2

Omgaan met Projectoverstijgende Ontwerpkeuzen ............................. 16

4.2.3

Afwijkingen en escalatie .............................................................. 17

4.3

Het bewaken van het kader .................................................................... 18

4.4

Het borgen van de resultaten .................................................................. 18

4.5

De levenscyclus van een PSA ................................................................... 19

DE INHOUD VAN DE PSA ............................................................. 20 5.1

De content ........................................................................................ 20

5.2

De deelarchitecturen ............................................................................ 20

5.3

Voorbeeld indeling ............................................................................... 22 5.3.1

Keuzes voor de indeling ............................................................... 23

5.3.2

De mate van detail ..................................................................... 23

5.3.3

Levend document of eenmalig? ...................................................... 23


1.0

1

Whitepaper: Project Start Architectuur

6

7

DE REFERENTIE ARCHITECTUUR EN DE PSA ...................................... 25 6.1

Van Referentie Architectuur naar PSA ....................................................... 25

6.2

Geen Referentie Architectuur, toch een PSA ............................................... 27

6.3

Van PSA naar Referentie Architectuur ....................................................... 27

DE PSA EN PRINCE2 TM ............................................................... 29 7.1.1

8

De PSA en de PID........................................................................ 30

TOT SLOT ............................................................................. 32


1.0

2


1

INLEIDING

Vanuit Sogeti ondersteunen wij veel organisaties bij het werken onder architectuur. Daarbij is het gedachtegoed van DYA® steeds ons uitgangspunt geweest. De basis van DYA® is gelegd in het boek DYA®: snelheid en samenhang in business- en ICTarchitectuur. Belangrijk onderdeel van DYA® is het gebruik van de Project-Start-Architectuur (PSA). Het toepassen van de PSA stelt organisaties in staat het denken over architectuur aan te laten sluiten bij het doorvoeren van veranderingen in hun organisatie. De PSA is het meest gebruikte instrument van DYA®.

1.1

Doel van dit document

Het veelvuldig gebruik van de PSA heeft een grote hoeveelheid praktijkervaringen opgeleverd, die ons in staat hebben gesteld het inzicht in het effectieve gebruik van de PSA nog verder aan te scherpen. Daarnaast is gebleken dat veel organisaties dezelfde vragen hebben omtrent het doel, de inhoud en het gebruik van de PSA. Dit document is bedoeld om de vragen die bestaan rondom het gebruik van de PSA te beantwoorden. In dit document hebben we uiteraard gebruik gemaakt van het scala aan nieuwe inzichten en ervaringen van de talrijke gebruikers van de PSA.

1.2

Opzet van dit document

Als eerste wordt in dit document uiteengezet wat het doel van de PSA is en welke waarde de PSA toevoegt aan het werken onder architectuur (hoofdstuk 2). Daarbij geven wij ook aan hoe het ‘architectuurdenken’ in de PSA terugkomt. Vervolgens worden de betrokkenen bij de PSA voorgesteld (hoofdstuk 3). Onder ‘betrokkenen’ verstaan wij diegenen die de verschillende processen rond de PSA uitvoeren. Deze processen worden in hoofdstuk 4 beschreven. De inhoud van de PSA wordt beschreven in hoofdstuk 5. Deze inhoud weerspiegelt zowel het doel van de PSA als het gebruik ervan. Omdat de PSA zich op het scheidsvlak van de Referentie Architectuur en projecten bevindt, wordt bij de relatie tussen de PSA en deze twee terreinen apart stilgestaan. Eerst wordt de relatie tussen de Referentie Architectuur en de PSA besproken (hoofdstuk 6). Daarna wordt aangegeven welke rol de PSA speelt bij de ondersteuning van architectuur aan projecten, die volgens de Prince2TM-methode worden uitgevoerd (hoofdstuk 7).


1.0

3


2

HET DOEL VAN DE PSA

De PSA (Project Start Architectuur) is een document, waarin de architectuur is beschreven zoals deze geldt bij de start van PSA Architectuur Project een project. Het document is bedoeld als verbinding tussen de architectuur aan de ene kant en een project aan de andere kant. De PSA is een stuurinstrument dat er voor zorgt dat architectuur niet beperkt blijft tot de ivoren toren van de architect, maar dat de architectuur concreet maakt om de veranderingen in een organisatie te faciliteren. De uitwerkingen van deze veranderingen worden hoofdzakelijk binnen projecten uitgewerkt tot businessoplossingen. De PSA is een vertaling van de algemene principes en beleidslijnen naar een projectspecifiek kader. Relevante onderdelen uit de algemene (referentie)architectuur worden toegesneden op de scope en de specifieke problematiek van het project. Hierdoor geeft de PSA een heel concreet en doelgericht architectuurkader aan, waarbinnen het project moet worden uitgevoerd. Dit kader bestaat uit de concrete standaarden, normen en richtlijnen en uit de modellen die het project dient te hanteren. Ook projectoverstijgende ontwerpkeuzes worden in de PSA vastgelegd. De PSA geeft dus de context en de richting van de oplossing van een project weer, maar niet de oplossing zelf. De PSA gaat niet over de 'solution architecture'.

2.1

De toegevoegde waarde van de PSA

De toegevoegde waarde van de PSA is zowel waarneembaar bij de architectuur als bij de projecten. Binnen het architectuurperspectief zorgt de PSA er voor dat het eindresultaat, dat door het project wordt opgeleverd, past in de totale informatievoorziening. Ook zorgt de PSA er voor dat bij de ontwikkeling van een oplossing rekening gehouden wordt met de gehele life cycle van de voorziening, doordat eisen op het gebied van beheer en flexibiliteit worden meegenomen. Mits goed toegepast heeft de PSA, vanuit projectperspectief, een positief effect op de totstandkoming van projectresultaten. Gebruik van de PSA kent de volgende voordelen: 1.

2.

3.

Met de PSA wordt een aanzienlijke versnelling bereikt, doordat het projectteam minder tijd kwijt is met afstemmingssessies met andere projecten en partijen. Dat is immers in de architectuur al ondervangen. De context en de richting zijn dus al bepaald. In de PSA staan de richtlijnen en standaarden die binnen het project gehanteerd moeten worden. Hiermee wordt bijgedragen aan de standaardisering binnen een organisatie en wordt het hergebruik van gestandaardiseerde, bewezen oplossingen bevorderd. Tevens hoeft het project over deze standaardoplossingen geen discussies te voeren. Er is geen uitgebreide discussie over de te gebruiken hulpmiddelen en technieken nodig. Bovendien bouwt een organisatie -na verloop van tijd- steeds meer ervaring op voor wat betreft de standaard hulpmiddelen en technieken. Het projectteam kan de aandacht dus richten op het doel, in plaats van op de middelen. De start van het project verloopt hierdoor een stuk sneller.


1.0

4


4.

Doordat veel keuzes al gemaakt zijn in de PSA, is vanaf de start van het project duidelijk welke competenties nodig zijn. Het project kan dus met de juiste personen bemand worden.

Een organisatie die de PSA al vier jaar gebruikt in haar architectuurproces heeft de voordelen als volgt geformuleerd: • • • • • • • •

•

Het werken met de PSA geeft betrokkenen in het project een gemeenschappelijk vertrekpunt en de juiste afbakening, scope en richtlijnen; PSA’s geven projecten een snellere start en meer eenduidigheid over projecten heen; De PSA en de Bouwvergunning zijn goede mechanismen die zorgen dat deeloplossingen in de totaaloplossing passen; De PSA maakt concreet wat architectuur voor een project betekent; PSA’s helpen de projectleiders om een betere planning te maken; De PSA wordt gebruikt als criterium door het datacenter om iets in beheer te nemen; De PSA geeft mensen in projecten een goed inleesdocument; De PSA heeft behoorlijk wat voordelen richting uitbesteden aan leveranciers. De PSA geeft richtlijnen waar leveranciers zich aan moeten houden. Het is een betere basis voor een contract en het is een acceptatiecriterium. Als het geleverde niet voldoet aan de PSA wordt niet betaald. Kortom, de PSA is een stuurinstrument voor de projectmanager. Zowel project- als contractmanagement hebben baat bij de PSA; De PSA is een onderhandelelement in de gesprekken met de klant en dat is goed, want klanten hebben de neiging om zich met alles te bemoeien. De PSA bevat datgene wat al eerder afgesproken is (beleid) en creëert duidelijkheid, waardoor veel onnodige discussie met klanten en medewerkers wordt voorkomen.

Los van deze voordelen voor de specifieke projecten, draagt het gebruik van de PSA ook bij aan een verandering in de benadering van architectuur in een organisatie. De organisatie zal bij het realiseren van de korte-termijn-doelen (projecten) steeds meer de (architectuur)doelen voor de langere termijn in ogenschouw nemen. Het projectresultaat krijgt hiermee een hogere kwaliteit, is in lijn met de lange(re)termijn-doelen, bevordert de flexibiliteit en is consistent over projecten heen.

2.2

De drie architectuuraspecten in de PSA

DYA® hanteert de volgende definitie van architectuur: "Architectuur is een consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie". In deze definitie zitten drie algemene aspecten van architectuur besloten, die hierna verder besproken worden.


1.0

5


2.2.1

Van abstract naar concreet

Architectuur dient bij te dragen aan de realisatie van de bedrijfsstrategie. Vanuit die strategie worden meerdere vertaalslagen gemaakt om zodoende de strategie concreet te maken. Deze vertaalslagen “vertalen” dus de strategie vanuit de bedrijfsdoelstellingen en resulteren in algemene principes, daarna in beleidslijnen op verschillende zorggebieden en uiteindelijk in modellen. Businessdoelen

Abstract

Technische architectuur

BusinessInformatiearchitectuur architectuur Prod/ Proces Orgadienst nisatie

Gegevens

Applicatie

Middle- Platware form

Netwerk

Algemene principes Beleidslijnen

Concreet

Modellen

Figuur 1 Van abstract naar concreet

2.2.2

Deelarchitecturen

Het tweede aspect betreft de deelarchitecturen. Architectuur wordt doorgaans beschouwd vanuit meerdere deelarchitecturen (domeinen). Die deelarchitecturen worden bepaald door de gebieden waarop een organisatie wil sturen om zodoende de strategie te realiseren. Dat is dé reden om principes, richtlijnen, standaarden, normen, etc af te spreken. Een veel voorkomende onderverdeling is die in een business-, een informatieen een technische architectuur (ook wel infrastructuur-architectuur genoemd). Elk van deze architecturen wordt verder verdeeld in de specifieke deelarchitecturen. Daarnaast zijn ook andere deelarchitecturen denkbaar zoals (informatie-) beveiliging en beheer. Businessdoelen BusinessInformatiearchitectuur architectuur Prod/ Proces Orgadienst nisatie


GegeAppliMiddle- PlatDeelarchitecturen vens catie ware form

Netwerk

Algemene principes Beleidslijnen Modellen

Figuur 2 Deelarchitecturen

2.2.3

Tijdsaspect

De architectuur geeft richting aan ontwerp en realisatie. Zij stuurt de veranderingen die in een organisatie plaatsvinden. Daarmee is het derde aspect van architectuur geduid: het tijdsaspect. Een verandering impliceert dat er een periode is vóór de verandering (current state) en een periode ná de verandering (future state). Sogeti Nederland B.V. oktober 2009

1.0

6


Het doorvoeren van de verandering zelf neemt ook tijd in beslag (migratie, zowel door vervanging of door geleidelijke afschrijving). Alledrie de periodes kunnen in de architectuur beschreven worden. Er zijn modellen die (delen van) de huidige situatie weergeven, modellen die (delen van) de toekomstige situatie weergeven en de architectuurprincipes geven richting aan die toekomstige situatie en de verandering die daarvoor nodig zijn. Businessdoelen BusinessInformatiearchitectuur architectuur Prod/ Proces Orgadienst nisatie

Algemene principes

Gegevens

Applicatie

Technische architectuur Middle- Platware form

Netwerk

Migratie

Beleidslijnen Modellen

Current / Future Figuur 3 Tijdsaspecten

2.3

De PSA reflecteert de architectuuraspecten

De PSA reflecteert de drie aspecten: van abstract naar concreet, deelarchitecturen en het tijdsaspect. De PSA zelf is een belangrijke stap in de vertaling van abstract naar concreet en dus van strategie naar de implementatie daarvan. Zij benoemt relevante onderdelen uit de Referentie Architectuur en vertaalt deze, ten behoeve van de uitvoering, naar het concrete architectuurkader binnen de scope van het project. De beleidslijnen die in de PSA worden opgenomen, worden -als laatste concretiseringslag- vertaald naar requirements die aan de (door het project op te leveren voorziening) worden gesteld. Doorgaans omvatten deze requirements zowel business-, user- als systeemrequirements. Bij het werken onder architectuur komen daar, op basis van de PSA, de architectuur-requirements bij. De inhoud van de PSA wordt bepaald door de deelarchitecturen die door de organisatie worden onderkend. Een organisatie bepaalt zelf welke domeinen voor haar van belang zijn. De wijze waarop het architectuurraamwerk is ingevuld is bepalend voor deze keuze. Deze deelarchitecturen komen ook terug als onderdelen van de PSA. In de paragraaf over de inhoud van de PSA wordt hier dieper op ingegaan. De PSA geeft ook aan welk tijdsaspect is meegenomen. De Referentie Architectuur schetst niet alleen de bestaande, in gebruik zijnde, principes en standaarden (current), maar ook de principes en standaarden die in de toekomst van toepassing zijn (future). Zij geeft aan op welke wijze invulling wordt gegeven aan de voorgestane 'future state'. De principes, richtlijnen, standaarden, normen, etc geven richting aan de ontwikkeling van de voorzieningen. Zij hebben tot doel om ervoor te zorgen dat de ‘weg naar de toekomst’ een rechte weg blijft. Zij zetten de piketpaaltjes voor de richting en route van de evolutie van de voorzieningen van een organisatie. De context die van het project geschetst wordt kan zowel de huidige context zijn (current state) als een projectie op die toekomst (future state). De eerste is het resultaat van de impact analyse, die aan de PSA vooraf gaat. De tweede geeft een beeld van de bijdrage van het project aan de future state. Sogeti Nederland B.V. oktober 2009

1.0

7


2.4

De PSA als validatie-instrument

De PSA is het instrument bij uitstek om te controleren of bij de realisatie van een project de architectuurrichtlijnen worden nageleefd. Dit geldt niet alleen voor ontwikkelingen die door de organisatie zelf worden uitgevoerd. Ook ontwikkelingen die worden uitbesteed moeten zich houden aan de architectuurrichtlijnen van de organisatie. Een PSA kan in outsource-trajecten dan ook uitstekend gebruikt worden om als input te dienen voor de SLA van de leverancier. Het is belangrijk in de PSA aan te geven hoe het project en het beoogde resultaat zich verhouden ten opzichte van haar omgeving waarin het geïmplementeerd wordt. Een van de doelen van de PSA is juist om het project in zijn omgeving te plaatsen (interprojectrelaties) en de resultaten van het project in te passen in de bestaande situatie (installled base). Het is expliciet niet de verantwoordelijkheid van de architectuurfunctie, en vormt dus ook geen inhoudelijk aspect van de PSA, om te bepalen of het project aan de requirements tegemoet gaat komen. Het voldoen daaraan is een vraag voor de stuurgroep van het project.


1.0

8


3

DE BETROKKENEN BIJ DE PSA

Er zijn tijdens haar levenscyclus meerdere ‘rollen’ betrokken bij de PSA. In dit hoofdstuk worden die rollen beschreven, geordend volgens de volgende drie categorieën: - Allereerst zijn er degene die ervoor verantwoordelijk zijn dat de PSA wordt opgesteld; - Een grotere groep bestaat uit de stakeholders van de PSA; - De derde categorie wordt gevormd door de opsteller(s) van de PSA. Elk van de drie categorieën worden hierna in een aparte paragraaf besproken.

3.1

De ‘verantwoordelijken’

De verantwoordelijkheid voor het opstellen van de PSA moet belegd worden in de organisatie. Daar zijn drie rollen bij betrokken. De projectleider is ervoor verantwoordelijk dat de PSA tijdig wordt opgeleverd. Hij is sowieso verantwoordelijk voor het tijdig opleveren van de producten die voor het project nodig zijn. In die rol is hij direct betrokken bij het op één lijn krijgen van de projectarchitect en de projectteamleden. De projectarchitect is verantwoordelijk voor de inhoud en kwaliteit van de PSA. Hij is dus verantwoordelijk voor het feit dat de PSA wordt opgesteld conform die twee criteria. Wie hij hier verder bij betrekt, wordt beschreven in paragraaf 3.3. De projectarchitect is een architect die is toegekend aan een project. Hij begeleidt en helpt het project om een oplossing te ontwikkelen die past binnen de kaders die vanuit en door de architectuur worden gesteld. De PSA die is opgesteld wordt uiteindelijk gevalideerd door de architectuurboard. Deze is in dit kader eindverantwoordelijk voor de juistheid van de PSA. Ook ziet de architectuurboard erop toe dat het kader, zoals geschetst in de PSA, past in het grotere (architectuur)geheel. Dit is één van de manieren om afstemming tussen de projecten onderling vorm te geven en te borgen en de langere termijndoelen te bewaken. De architectuurboard In de visie van DYA® werkt een architect in een organisatie voor een opdrachtgever. De opdrachtgever is degene die een bepaald businessdoel wil realiseren. Om dat doel te realiseren is inzicht nodig in de daarvoor benodigde veranderingen. Het is de taak van de architect om die veranderingen inzichtelijk te maken en er sturing aan te geven. Dit doet hij door –voor de genoemde gebieden- principes en modellen op te stellen en relevante standaarden te selecteren. Als het businessdoel daadwerkelijk in programma- of projectvorm moet worden gerealiseerd, worden projecten gestart met aan het hoofd een projectmanager. Het is de taak van de projectmanager om een oplossing te leveren binnen de kaders van de architectuur. De architect levert de principes, modellen en standaarden aan de projectmanager aan in de vorm van een PSA.


1.0

9


Opdrachtgever

Projectmanager

Architect

Indien de projectmanager van mening is dat de realisatie volgens de architectuur niet past binnen tijd en budget, staat de opdrachtgever voor het besluit of hij van de architectuur afwijkt of dat er meer tijd en geld beschikbaar moet komen. Maar hij doet dit niet in isolement. Binnen de organisatie spelen meerdere businessdoelen tegelijkertijd. Om te zorgen voor consistente afstemming, om keuzes te maken en prioriteiten te stellen wordt een architectuurboard in het leven geroepen. In feite dient elk van de rollen ‘opdrachtgever’, ‘architect’ en ‘projectmanager’ een achterban te hebben in respectievelijk ‘businessmanagement, ‘ architectuurmanagement’ en ‘programmamanagement’. Deze managementgroepen worden elk vertegenwoordigd in de architectuurboard, tezamen met een vertegenwoordiger van het topmanagement. Een architectuurboard is een platform voor inhoudelijke afstemming en escalatie. Architectuurboard Top management

De o o o

Architectuur management

Business management

Programma management

Architect

Opdrachtgever

Projectmanager

voornaamste taken van een architectuurboard zijn: Het verstrekken van architectuuropdrachten; Het formeel goedkeuren van architectuurproducten; Het fungeren als escalatieplatform bij inhoudelijke conflicten.


1.0

10


3.2

De ‘stakeholders’ van de PSA

De projectleider, de projectarchitect en de architectuurboard zijn stakeholders van de PSA. Maar ze zijn niet de enigen. Hieronder staan de verschillende stakeholders van de PSA en hun belang. projectleider

-

architect

-

architectuurboard

-

ontwikkelaars

-

beheer

-

Deze geeft opdracht voor het maken van een PSA. Hij ziet toe op een tijdige oplevering. Zijn inhoudelijke betrokkenheid betreft het opstellen van het Plan van Aanpak (PID) na oplevering van de PSA. Deze stelt (een deel van) de PSA op. De projectarchitect neemt de opdracht daartoe aan van de projectleider. Wanneer het een domeinarchitect betreft, heeft hij de rol van onderaannemer. Deze vult een specialistisch onderdeel van de PSA in. Met de hoofdaannemer (de projectarchitect) worden afspraken gemaakt over de inhoud en de doorlooptijd. De controlling architect controleert of de producten die het project oplevert ook voldoen aan het kader zoals dat door de PSA is gesteld. Deze valideert de PSA. De architectuurboard heeft de taak om toe te zien dat de inhoud van hetgeen beschreven is in de PSA klopt en bovendien in lijn is met het grotere geheel en de Referentie Architectuur op langere termijn. Zij keurt formeel de PSA goed. De architectuurboard is onderdeel van het escalatiepad indien er verschil van mening is tussen de projectleider en projectarchitect over het voldoen van de oplossing aan de architectuurkaders (zie ook paragraaf 4.2.3). Zij voeren -binnen de kaders van de PSA- het ontwerp en de bouw uit. In elk geval wordt met hen de PSA doorgenomen om te controleren dat de gestelde kaders duidelijk en hanteerbaar zijn. Ook kunnen zij (om dezelfde reden) ingezet worden bij het opstellen van de PSA. Zij zijn dan gesprekspartner van de projectarchitect. Beheer is ontvanger van de door het project opgeleverde oplossing. Bij het beheren moeten zij weten wat de uitgangspunten zijn waarop de oplossing is gebaseerd. De PSA geeft de uitgangspunten vanuit de architectuur weer. Een deel van de architectuurprincipes is gebaseerd op de eisen die Beheer zelf aan de oplossingen stelt, die zij in beheer nemen.

Een projectstuurgroep (Project Board en dus, via de Executive sponsor die hier gewoonlijk zitting in heeft, ook de business) is geen stakeholder in deze. Zij zijn afgeleid stakeholder via het Plan van Aanpak cq. de PID, die opgesteld wordt mede op basis van de PSA. Dit betekent dat er een scheiding van verantwoordelijkheden is tussen de architectuurfunctie en het project. Figuur 4 in de volgende paragraaf geeft dat ook weer.


1.0

11


3.3

De ‘opstellers’ van de PSA

Bij voorkeur wordt het opstellen van de PSA door de projectarchitect en het projectteam (minimaal de informatieanalist en/of de ontwerper) samen uitgevoerd. Door het samen te doen, wordt geborgd dat het projectteam de architectuurprincipes en haar consequenties daadwerkelijk begrijpt en onderschrijft. Dit maakt het makkelijker voor het projectteam om zich aan de richtlijnen te houden. De winst voor het architectenteam is dat de praktische toepasbaarheid van de architectuurprincipes op deze wijze zorgvuldig getoetst wordt. Ook de verschillende modellen, die in het kader van de PSA opgesteld worden, zijn op deze wijze tussen architect en projectteamleden afgestemd. De projectarchitect kan andere architecten (bijvoorbeeld domeinarchitecten) inschakelen om delen van de PSA in te vullen. Deze projectarchitect beschikt over het algemeen niet over diepgaande kennis van alle architectuurdisciplines. Het is niet voor niets dat er bloedgroepen van architecten zijn (business, informatie, infrastructuur). Daar waar de projectarchitect die kennis ontbeert moet hij voor de juistheid van de inhoud vertrouwen op de -door hem ingeschakelde- domeinarchitect. Die kan eventueel voor die juistheid verantwoordelijk worden gesteld. De projectarchitect blijft echter verantwoordelijk voor de oplevering van de PSA zelf. Project Board

Architectuur Board

PID Projectleider

Domein architecten Projectarchitect

Informatie- Ontwikkelaars / Analist / Bouwers Ontwerpers PSA

Figuur 4 Betrokkenen bij de PSA


1.0

12


4

DE PROCESSEN ROND DE PSA

In het vorige hoofdstuk zijn de rollen beschreven die betrokken zijn bij de PSA. Die betrokkenheid betreft verschillende processen van zowel het opstellen als het gebruiken van de PSA. Deze processen worden in dit hoofdstuk beschreven. De architectuurfunctie ondersteunt het uitvoeren van projecten. In DYA® is dat vorm gegeven middels de ondersteuning van het werkproces ‘Architectuur Services’ (de architectuurfunctie) aan het ‘Ontwikkelen onder Architectuur’ (de projecten). In deze ondersteuning speelt de PSA haar rol (zie figuur 6). De processen rond de PSA zijn dan ook gebaseerd op deze ondersteuning. Governance Ontwikkelen zonder Architectuur Nieuwe ontwikkelingen

Businessoplossingen

Ontwikkelen onder Architectuur

Strategische Dialoog

Architectuur Services

Businessoplossingen

PSA

DYA processen

Dynamische Architectuur Businessarchitectuur

Informatiearchitectuur


Figuur 5 De plaats van de PSA in de keten van DYA-werkprocessen

In dit hoofdstuk wordt die ondersteuning allereerst in algemene zin beschreven, waarna de verschillende processen rond de PSA verder worden uitgediept.

4.1

Ondersteuning van architectuur aan projecten

De relatie tussen architectuur en projecten, en dus de relatie tussen ‘Architectuur Services’ en ‘Ontwikkelen onder Architectuur’, wordt vorm gegeven door middel van de volgende vier architectuuractiviteiten. 1. Vaststellen kaders Aan het begin van het project stelt de projectarchitect -samen met het projectteamde architectuurkaders vast waaraan de oplossing moet voldoen. Dit kader wordt vastgelegd in de PSA. Hoe dat in zijn werk gaat wordt in paragraaf 4.2 beschreven. 2. Helpen ontwerpers/ontwikkelaars/bouwers Tijdens het project blijft de projectarchitect betrokken bij het project. Hij ondersteunt de ontwerpers, ontwikkelaars en bouwers bij hun ontwerp- en bouwactiviteiten om te borgen dat die voldoen aan de kaders, zoals vastgelegd in de PSA. Afwijkingen van de architectuur (inclusief verantwoording, consequenties en opruimscenario) en ontwerpkeuzes met een impact buiten het project worden door deze architect gesignaleerd en geëscaleerd naar de architectuurboard (zie paragrafen 3.1 en 4.2.3). Vastlegging vindt plaats in de betreffende hoofdstukken in de PSA (zie hoofdstuk 5).


1.0

13


Ook signaleert en escaleert de projectarchitect wanneer hij constateert dat architectuurprincipes ontbreken of niet voldoen (zie paragraaf 6.1). 3. Controleren producten Tijdens het project controleert de controlling architect of de opgeleverde producten voldoen aan de kaders zoals die in de PSA zijn vastgelegd. Afhankelijk van de uitslag van deze controle wordt wel of niet een bouwvergunning afgegeven voor de volgende fase. Deze bouwvergunning geeft aan dat de gecontroleerde producten inderdaad aan de gestelde standaarden en richtlijnen voldoen. Afwijkingen die eerder zijn gesignaleerd en via de architectuurboard zijn gevalideerd worden in dit kader meegenomen en zijn dan geen reden meer voor het weigeren van een bouwvergunning (zie paragraaf 4.3). 4. Borgen resultaten en definiëren vervolgstappen Aan het eind van het project borgt de projectarchitect de resultaten van het project. Dit betekent dat eventueel de Referentie Architectuur wordt aangepast, indien tijdens het project issues zijn opgelost die invloed hebben op die Referentie Architectuur. Hierbij valt te denken aan de eerder genoemde projectoverstijgende ontwerpbeslissingen, maar ook aan de aanscherping van de architectuurprincipes. Deze aanpassingen moeten formeel worden vastgelegd, zodat ze vanaf dat moment ook een leidraad vormen voor andere projecten (zie paragraaf 6.3). Bovendien leiden afwijkingen van de architectuur, zoals die door de architectuurboard zijn gesanctioneerd, tot vervolgacties voor het oplossen van die afwijkingen. Deze moeten worden gedefinieerd en de uitvoering moet worden belegd bij personen en/of projecten (zie paragraaf 4.4). Het zal duidelijk zijn dat de PSA bij al deze vier activiteiten een centrale rol speelt. Deze vier activiteiten komen dan ook terug in de processen rondom de PSA, die in de volgende paragrafen beschreven worden. De vier architectuuractiviteiten die hier beschreven zijn, moeten opgenomen worden in de -door een organisatie gehanteerde- projectaanpak. De plaats binnen de projectaanpak van Prince2 TM wordt beschreven in hoofdstuk 7.

4.2

Het opstellen van de PSA

Wanneer een organisatie besluit onder architectuur te gaan werken, wordt voor elk startend project een PSA opgesteld. Alleen als gekozen wordt voor ‘Ontwikkelen zonder Architectuur’ wordt geen PSA opgesteld. Nieuwe ontwikkelingen

Ontwikkelen onder Architectuur

Strategische Dialoog

Business-oplossingen

Referentie architectuur Enterprisearchitectuur

Projectstartarchitectuur

Domeinarchitectuur

Architectuur Services

Figuur 6 Een PSA bij Ontwikkelen onder Architectuur Sogeti Nederland B.V. oktober 2009

1.0

14


Met dat ‘opstellen van een PSA’ moet zoveel mogelijk pragmatisch mee omgegaan worden. Een dikke PSA bij een klein project is natuurlijk niet zinvol. Dus de inhoud van de PSA kan, in geval van kleine projecten, beperkt zijn. Het ‘just enough’-principe is een heldere leidraad bij de bepaling van de inhoud van de PSA bij kleinere projecten. Ook bestaat de mogelijkheid om de architectuurboard -op basis van het projectportfolio- te laten bepalen welke projecten wel en welke geen PSA behoeven. Een andere variant is dat de architectuurboard criteria vaststelt waaraan een project moet voldoen om te bepalen of er wel of geen PSA gemaakt moet worden. De projectarchitect beoordeelt het project aan de hand van deze criteria en legt verantwoording af aan de architectuurboard en de projectleider, indien hij besluit om geen PSA op te stellen. Zoals eerder gesteld, wordt het opstellen van de PSA door de projectarchitect en het projectteam gedaan, zodat de toepasbaarheid van de architectuurprincipes kunnen worden getoetst en de consequenties ervan voor het project worden begrepen en onderschreven.

4.2.1

De activiteiten voor het opstellen van de PSA

Het opstellen van een PSA gebeurt in een aantal vervolgstappen. In onderstaande tabel is een globale voorbeeldindeling gegeven. Deze wordt in paragraaf 5.3 verder uitgewerkt. 1. 2. 3. 4. 5. 6.

Projectinformatie Businessarchitectuur Informatiearchitectuur Technische architectuur Projectoverstijgende ontwerpkeuzen Architectuurafwijkingen

Allereerst moet worden vastgesteld welke onderdelen van de PSA ingevuld moeten worden. Ook voor de PSA geldt namelijk het principe ‘just-enough, just-in-time’. Dit betekent dat alleen die zaken in een PSA beschreven worden waarop de architectuurboard wilt sturen. Er wordt niet meer opgenomen dan nodig is voor het bereiken van het projectdoel. De aard van het project bepaalt welke onderdelen wel en welke niet ingevuld moeten worden. Zo is het denkbaar dat bij een project met een organisatorische impact er geen implicaties zijn voor de infrastructuur of dat bij een infrastructureel project de hoofdstukken over de business- en de informatiearchitectuur leeg blijven. Die betreffende hoofdstukken worden dan niet ingevuld. Voor de relevante onderdelen moet worden na gegaan welke architectuurprincipes1 van invloed zijn. Van die principes die een weerslag hebben op het project wordt een vertaling gemaakt naar concrete implicaties. De ultieme vertaling is die naar een concreet requirement, dat vanuit de architectuur aan het project wordt meegegeven. Relevante modellen en standaarden worden vanuit de Referentie Architectuur verzameld om zodoende de afbakening van de oplossing aan te geven. De scope van het project, zoals weergegeven in de projectopdracht, bepaalt welke modellen en 1

De term ‘architectuurprincipes’ wordt hier bedoeld als de verzamelnaam voor principes, richtlijnen, standaarden, normen, etc. Sogeti Nederland B.V. oktober 2009

1.0

15


standaarden gebruikt worden. Wanneer een organisatie beschikt over een volledig geïmplementeerd architectuurproces komt de input hiervoor uit de -in een eerdere fase uitgevoerde- architectuurschets en impactanalyse. Bij het opstellen van architectuurschetsen en het uitvoeren van een impactanalyse worden mogelijke oplossingsrichtingen geïnventariseerd en wordt vastgesteld welke modellen en standaarden uit de Referentie Architectuur relevant zijn voor het project. Tevens wordt vastgesteld of de voorschriften uit de Referentie Architectuur passend (genoeg) zijn voor de realisatie van de nieuwe voorziening. Indien er geen Referentie Architectuur aanwezig is, of deze is niet compleet of niet actueel, worden de modellen en standaarden in deze fase opgesteld of aangepast (zie paragraaf 6.2). Voor het selecteren, aanpassen en opstellen van modellen en standaarden dient er steeds een juist evenwicht te zijn tussen de verschillende disciplines van business-, informatieen infrastructuurarchitectuur. Deze architecturen worden tot stand gebracht door een juiste wijze van hanteren van kwaliteitsattributen in een uitgebalanceerd architectuurproces. Zo kan de business bijvoorbeeld vragen dat een voorziening 99,999999999% beschikbaar is, maar als dit ten koste gaat van (bijvoorbeeld) schaalbaarheid of als dat tot onredelijke kosten leidt, dan dient deze eis op gewogen wijze te worden herzien.

4.2.2

Omgaan met Projectoverstijgende Ontwerpkeuzen

In vrijwel ieder project komen projectoverstijgende ontwerpkeuzen en afwijkingen op de architectuur voor. In principe kunnen deze later in het project aangevuld worden. Een deel van de afwijkingen op de (Referentie) architectuur is al bekend tijdens het opstellen van de PSA. Deze worden dan daarin opgenomen. Echter, tijdens het ontwerptraject kunnen zich nieuwe (projectoverstijgende) ontwerpkeuzen en architectuurafwijkingen aandienen. Deze kunnen in een later stadium aan de PSA worden toegevoegd. Daarom wordt geadviseerd in de PSA hieraan een apart hoofdstuk te wijden. Wanneer de opdracht aan of scope van een project wijzigt is dit een reden voor het opstellen van een nieuwe PSA. Het is door deze wijziging namelijk een ander project geworden. Projectoverstijgende ontwerpkeuzes hebben meestal betrekking op de wijze waarop aan een bepaalde requirement wordt voldaan of op de middelen die daarvoor ingezet worden. Het ontbreken van een keuze betekent vrijwel altijd dat er nog niet eerder een behoefte heeft bestaan om op dat terrein een keuze te maken. Die behoefte ontstaat nu binnen dit project. Een deel van die keuzes leidt uiteindelijk tot een standaard, die voor elke soortgelijke oplossing gaat gelden. Om die reden spreken we over 'projectoverstijgend'. Dit heeft uiteraard als consequentie dat de keuze niet binnen het project gemaakt moet worden, maar dat deze keuze een architectuuraangelegenheid is. De projectarchitect, als bewaker van de architectuur binnen het project, is degene die moet signaleren dat een nieuwe ontwerpkeuze nodig is. Hij escaleert dat naar de architectuurfunctie die de keuze uiteindelijk voorstelt. Daarbij worden de relevante domeinarchitecten ingeschakeld, elk op het terrein van hun expertise. Die keuze wordt vervolgens in het project meegenomen. Het spreekt vanzelf dat een project niet een aantal weken kan wachten op het maken van zo’n keuze. Daarom dienen alleen de relevante architecten hierbij ingeschakeld te worden. Uiteindelijk moet de architectuurboard een formele uitspraak doen over de gemaakte keuze en die keuze dus valideren. Daarmee wordt de keuze tevens een onderdeel van de Referentie Architectuur.


1.0

16


4.2.3

Afwijkingen en escalatie

Het voorgaande verhaal geldt ook voor de zgn. afwijkingen op de architectuur. Op elk moment in een project kan geconstateerd worden dat een bepaalde oplossing alleen gerealiseerd kan worden met een afwijking op de architectuur. Ook hier is het de projectarchitect die dat signaleert en dit escaleert naar de architectuurfunctie. De architectuurboard is de instantie die uiteindelijk een dergelijke afwijking formeel goedkeurt. Een beoogde afwijking moet aan de board worden voorgelegd, met argumenten omkleedt. Daarbij dient ook aangegeven te zijn op welke wijze de afwijking hersteld gaat worden. Er zijn drie scenario's om met afwijkingen om te gaan: • De afwijking wordt niet geaccepteerd; het architectuurbelang is groter dan het projectbelang; • De afwijking wordt alleen ten behoeve van het specifieke project geaccepteerd; het project krijgt toestemming om af te wijken van de opgestelde architectuur (dit kan ook een tijdelijke oplossing zijn); • De geconstateerde afwijking is aanleiding om de Referentie Architectuur aan te passen. Pas als de architectuurboard de afwijking toestaat, kan het project deze gaan uitvoeren. Deze afwijking wordt dan, met verwijzing naar de beslissing van de architectuurboard, in de PSA opgenomen. Indien de architectuurboard de afwijking niet goedkeurt, is zij de discussiepartner van de Project Board, die het betreffende requirement wil om zodoende tot een oplossing te komen. Zoals in paragraaf 3.1 bij de architectuurboard is beschreven, beslist uiteindelijk de opdrachtgever of er meer tijd en geld aan het project beschikbaar gesteld wordt en/of er van de architectuur afgeweken mag worden. Als hij dat laatste kiest, kiest hij dus ook voor de consequenties daarvan op de langere termijn. Het project gaat vervolgens verder met het implementeren van de uitkomst van de beslissing. Figuur 7 geeft de escalatiepaden schematisch weer.

Domein architecten

Architectuur Board

Project Board

Projectarchitect

Projectleider

Project Project

Figuur 7 Escalatiepaden


1.0

17


4.3

Het bewaken van het kader

De betrokkenheid van de projectarchitect bij een project houdt niet op bij de oplevering van de PSA. De projectarchitect heeft als taak om de projectteamleden (informatieanalisten en functioneel en technisch ontwerpers) te ondersteunen bij de eis te voldoen aan het kader, zoals dat in de PSA geschetst is. Wanneer het project producten oplevert, dient de kwaliteit daarvan gecontroleerd te worden. Prince2 TM kent hiervoor de ‘quality reviews’. Deze review is het meest voor de hand liggende instrument om te toetsen of de opgeleverde producten ook voldoen aan de kaders van de PSA. Dit is de taak van de controlling architect. Om te voorkomen dat iemand zijn eigen werk gaat controleren is het van belang dat de project architect en de controlerende architect twee verschillende personen zijn. Wanneer de controlling architect instemt met de kwaliteit van de producten (lees: het voldoet aan het kader van de PSA) geeft hij de bouwvergunning af: het project mag wat hem betreft verdergaan met de volgende fase of het volgende product. De controlling architect controleert de opgeleverde producten aan de hand van de PSA. De PSA bevat voor hem de toetsingscriteria in de vorm van de afbakening van de oplossing en de concrete vertaling van de architectuurprincipes. Ook de -door de architectuurboard goedgekeurde- afwijkingen, die in de PSA zijn beschreven, dient hij te betrekken bij zijn toetsing. Hij controleert dan of de afwijkingen op de architectuur in de producten is opgenomen zoals de architectuurboard dat met haar beslissing heeft beoogd. Uitgangspunt bij deze controle is dus dat de overige ontwikkelingsdocumenten een verdere invulling en detaillering geven van dat wat in de PSA beschreven is. De PSA geeft het kader middels een afbakening van de oplossingsrichting en via -op het project toegesneden- richtlijnen en standaarden. De overige systeemontwikkelingsdocumenten geven daar dan een verdere invulling aan. De impactanalyse van het project geeft een globaal beeld van de voorgestane, toekomstige situatie en dus van de oplossing. Daarmee zit er enige overlap tussen de analyse en de documenten die in het begin van een project worden opgesteld, zoals een definitiestudie (watervalmethode) of een haalbaarheidsonderzoek (DSDM en RUP).

4.4

Het borgen van de resultaten

Aan het eind van het project moeten de resultaten op architectuurgebied geborgd worden. Dit betreft de projectoverstijgende ontwerpkeuzes, de aangepaste werkelijkheid zoals die in de modellen is vastgelegd en de afhandeling van de afwijkingen op de architectuur. Deze borging moet onderdeel zijn van de afronding van het project en daarmee van de décharge-procedure. De projectoverstijgende ontwerpkeuzes zijn tijdens het project besproken door de projectarchitect met de betreffende domeinarchitecten. Op basis daarvan is tot een afgewogen keuze gekomen. Deze keuze wordt door de projectarchitect voorgelegd aan de architectuurboard. Deze actie dient sowieso aan het einde van het project plaats te vinden, maar dat mag uiteraard ook eerder. De architectuurboard beslist uiteindelijk of de gemaakte keuze tot een standaard wordt verheven. Als dat zo is, wordt deze keuze in de Referentie Architectuur opgenomen. Als het project is afgerond kan dat veranderingen tot gevolg hebben voor de huidige situatie. Indien deze in de Referentie Architectuur worden bijgehouden, moeten die aanpassingen daar dus ook hun plaats krijgen. Andere projecten kunnen dan aan het begin van hun traject beschikken over een actueel beeld van de situatie. De projectarchitect levert de veranderingen aan. De architectuurboard geeft, als Sogeti Nederland B.V. oktober 2009

1.0

18


beheerder van de Referentie Architectuur, opdracht aan de geëigende instantie om de Referentie Architectuur dienovereenkomstig aan te passen. De architectuurboard baseert zijn beslissing om af te wijken van de architectuur niet alleen op de afwijking zelf, maar ook op de beschrijving van het scenario waarmee de afwijking teniet wordt gedaan. Dat scenario moet worden uitgevoerd. De architectuurboard definieert de vervolgstappen die daarvoor genomen dienen te worden. De architectuurboard of de Project Board, afhankelijk wie er in hun onderling gesprek verantwoordelijk voor is gesteld, kent deze vervolgstappen toe aan degene die deze gaat uitvoeren. Eventuele middelen die daarvoor nodig zijn worden daarbij ter beschikking gesteld.

4.5

De levenscyclus van een PSA

De levenscyclus van de PSA stopt niet bij het einde van het project. De PSA blijft geldig als kader, ook als de gerealiseerde oplossingen in beheer worden genomen. Op deze wijze wordt bewaakt dat ook latere aanpassingen getoetst (kunnen) worden aan de architectuur. De PSA wordt, samen met andere systeemdocumentatie, aan het beheer opgeleverd bij de oplevering van het projectresultaat. Indien in een latere fase een onderhoudsslag gedaan moet worden op de resultaten van het project, is de PSA nog steeds voorhanden om de plaats in het grotere geheel te bewaken. Zodra deze onderhoudsslag dusdanige proporties aanneemt dat hiervoor een nieuw project wordt gedefinieerd, krijgt dat nieuwe project zijn eigen PSA. De huidige PSA dient daarbij als bron. Wel is het zo dat –na afronding van die PSA voor dat nieuwe project- daarmee de levenscyclus van de huidige PSA eindigt.


1.0

19


5

DE INHOUD VAN DE PSA

De PSA bestaat uit: de content (de onderwerpen die beschreven worden) en de opbouw van de PSA volgens de domeinen waar deze onderwerpen betrekking op hebben. Beide worden in de volgende paragrafen beschreven. Daarbij zal ook naar voren komen dat de opzet van de PSA in nauwe relatie staat tot het gebruik ervan.

5.1

De content

De onderwerpen die in de PSA beschreven worden zijn uiteraard afgeleid van het doel van de PSA: het scheppen van een architectuurkader voor het betreffende project. Daarom dient de PSA concreet de volgende onderdelen te bevatten: o De afbakening van de oplossing, inclusief de interfaces; Binnen de businessarchitectuur betreft dit het omgevingsmodel (context-model) waarin de te ontwikkelen oplossing gerealiseerd moet worden. Bij de informatieen bij de technische architectuur betreft dit de logische en technische afbakening van de oplossing zelf. o De beleidslijnen, standaarden en richtlijnen; Deze worden overgenomen uit de Referentie Architectuur. Alleen de onderdelen uit de Referentie Architectuur die van toepassing zijn op het project worden opgenomen. Vervolgens worden deze geconcretiseerd naar richtlijnen en architectuurrequirements die aan het project worden meegegeven. o De ontwerpkeuzen die projectoverstijgend zijn; Alleen de ontwerpkeuzen die impact hebben buiten de scope van het project zelf worden in de PSA beschreven. Een dergelijke oplossing is dan meteen kandidaat voor standaardisering, waardoor in de toekomst soortgelijke problemen op soortgelijke wijze worden ontworpen. Op deze manier worden gelijksoortige problemen op een eenduidige manier opgelost. o De modellen; De beschikbare modellen die toegevoegde waarde hebben voor het project. Deze modellen zijn voorhanden in de Referentie Architectuur of zijn opgesteld ten dienste van de impact-analyse. o De afwijkingen van de architectuur Soms zijn afwijkingen van de architectuur niet te voorkomen. Dit betreft dan niet de gehele oplossing, maar heeft betrekking op onderdelen daarvan. Deze afwijkingen moeten in de PSA worden vastgelegd. Naast de vastlegging van de afwijking zelf, moet ook aangegeven worden hoe met de afwijking wordt omgegaan. Als in de organisatie een architectuurboard is ingericht, wordt de wijze hoe met afwijkingen moet worden omgegaan als advies aan de architectuurboard aangeleverd.2

5.2

De deelarchitecturen

Zoals eerder aangegeven bepaalt de inhoud van het gebruikte architectuurraamwerk grotendeels de opbouw van de PSA. Het raamwerk is een uitdrukking van de deelarchitecturen die door de organisatie belangrijk worden gevonden. Die moeten terugkomen in de PSA.

2

In paragraaf 4.2.3 is dit proces beschreven.


1.0

20


Businessdoelen BusinessInformatiearchitectuur architectuur Prod/ Proces Orgadienst nisatie

Gegevens

Applicatie

Technische architectuur Middle- Platware form

Netwerk

Algemene principes Beleidslijnen Modellen Figuur 8 Voorbeeld deelarchitecturen

De hoofddomeinen3 van het raamwerk komen overeen met de hoofdstukken. De subdomeinen zijn de paragrafen. Per deelarchitectuur worden de onderwerpen beschreven die in de vorige paragraaf genoemd zijn.

3

DYA® spreekt over Technische Architectuur, waarmee wordt gedoeld op infrastructuurarchitectuur. Binnen DYA|Infrastructuur, de op DYA-leest geschoeide, toegepaste infrastructuurarchitectuurmethodiek wordt consequent het begrip Infrastructuurarchitectuur gehanteerd voor een betere herkenning. DYA|Infrastructuur stelt daarbij ook een iets andere indeling van subdomeinen voor. Bij het werken onder DYA|Infrastructuur zal dit gevolgen hebben voor de indeling van de PSA. Voor deze whitepaper is uitgegaan van de oorspronkelijke voorbeeldindeling van DYA®. Overigens is de situatie in de eigen organisatie altijd leidend bij de indeling van domeinen en subdomeinen en derhalve ook bij de indeling van de PSA. Sogeti Nederland B.V. oktober 2009

1.0

21


5.3

Voorbeeld indeling

In deze paragraaf is een indeling opgenomen van een PSA die volgens de geschetste opbouw van Figuur 8 is samengesteld. 1. Projectinformatie 1.1. Doel van het project 1.2. Project organisatie 1.3. Betrokken architecten 1.4. Bedrijfsdrijfveren 1.5. Architectuurdrijfveren 2. Businessarchitectuur 2.1. Producten / dienstenarchitectuur 2.1.1. Afbakening 2.1.2. Beleidslijnen, richtlijnen, 2.2. Procesarchitectuur 2.2.1. Afbakening 2.2.2. Beleidslijnen, richtlijnen, 2.3. Organisatiearchitectuur 2.3.1. Afbakening 2.3.2. Beleidslijnen, richtlijnen, 3. Informatiearchitectuur 3.1. Applicatiearchitectuur 3.1.1. Afbakening 3.1.2. Beleidslijnen, richtlijnen, 3.2. Gegevensarchitectuur 3.2.1. Afbakening 3.2.2. Beleidslijnen, richtlijnen, 4. Technische architectuur 4.1. Middlewarearchitectuur 4.1.1. Afbakening 4.1.2. Beleidslijnen, richtlijnen, 4.2. Platformarchitectuur 4.2.1. Afbakening 4.2.2. Beleidslijnen, richtlijnen, 4.3. Netwerkarchitectuur 4.3.1. Afbakening 4.3.2. Beleidslijnen, richtlijnen, 5. Projectoverstijgende ontwerpkeuzen 5.1. Keuze 1 5.N. Keuze N 6. Architectuurafwijkingen 6.1. Afwijking 1 6.N. Afwijking N


1.0

standaarden

standaarden

standaarden

standaarden

standaarden

standaarden

standaarden

standaarden

22


5.3.1

Keuzes voor de indeling

Voor de uiteindelijke indeling van de PSA kan gebruik worden gemaakt van de volgende leidraad: o De PSA begint met een algemeen inleidend hoofdstuk, waarin het doel en de organisatie van het project wordt beschreven. Dit deel wordt overgenomen van de projectopdracht; o Elk van de deelarchitecturen wordt weergegeven conform de invulling van het raamwerk. Er moet dus vastgesteld zijn welke ontwerpdomeinen voor deze organisatie van belang zijn. Deze domeinen komen dan terug in de structuur (hoofdstuk- en paragraafindeling) van de PSA; o De beleidslijnen, standaarden en richtlijnen worden per deelarchitectuur weergegeven. Een alternatief is om deze in een apart hoofdstuk gezamenlijk weer te geven; o De projectoverstijgende ontwerpkeuzen worden in een apart hoofdstuk beschreven. Dit kan ook per deelarchitectuur. o De afwijkingen op de architectuur worden in een apart hoofdstuk weergegeven. Dit kan ook per deelarchitectuur.

5.3.2

De mate van detail

De mate van detail waarin modellen en standaarden worden vastgelegd wordt bepaald door de mate waarin vanuit de architectuur gestuurd gaat worden. Architectuur bepaalt de beperking van de ontwerpvrijheid. De afbakening van de oplossing wordt daarmee ruimer of krapper ingestoken. Hoe meer de architectuurfunctie in dit project wilt sturen, hoe meer ontwerpkeuzes dus eigenlijk al vooraf zijn gemaakt. Daarmee wordt logischerwijs de ontwerpvrijheid ingeperkt. Ditzelfde komt mogelijk ook al in de impact-analyse naar voren. Hoe meer zekerheid een organisatie wenst over de impact van de beoogde oplossing, hoe specifieker en dus gedetailleerder de beschrijving van impact zal zijn. Daarmee wordt ook meer detail in de impact-analyse opgenomen. Andersom geldt dat ook; bij minder sturing is er minder detail nodig. Dit alles betekent dat er geen sluitend antwoord te geven is op de vraag hoeveel detail in een PSA opgenomen moet worden. Dit verschilt van organisatie tot organisatie, van project tot project, en van persoon tot persoon. De uiteindelijke beslissing ligt bij de beoordeling van de PSA door de architectuurboard en het gebruik van de impactanalyse door de projectleider ten behoeve van de verdere uitwerking van de business case.

5.3.3

Levend document of eenmalig?

Een PSA is voor ’n belangrijk deel een document dat eenmalig wordt opgesteld. Dit betreft met name die onderdelen die het kader van het project weergeven: het omgevingsmodel en de afbakening van de oplossing. Deze eenmalige onderdelen betreffen de hoofdstukken 1 t/m 4 van de PSA. Verandering van deze onderdelen betekent formeel dat de opdracht aan het project (inclusief de scope) is veranderd en er dus een 'ander' project uitgevoerd wordt. Een ander project is een reden om een andere, een nieuwe PSA op te stellen. Afhankelijk van de omvang en de impact van die verandering wordt het merendeel van de huidige PSA wel overgenomen in de nieuwe PSA.


1.0

23


De reden om de projectoverstijgende ontwerpkeuzes en de afwijkingen apart op te nemen is het feit dat deze laatste twee hoofdstukken de ‘levende’ delen van de PSA vormen. Ontwerpkeuzes (hoofdstuk 5 van de PSA) worden grotendeels tijdens de ontwerpfase gemaakt. Het bepalen van deze keuzes vindt dus meestal plaats ná het opstellen van de PSA. Deze keuzes moeten dan in een later stadium worden toegevoegd. Dit verandert het kader zelf niet. Wel betekent dit dat er eventueel afstemming met andere projecten gezocht moet worden. Ook kan dit aan het einde van het project leiden tot een aanpassing van de Referentie Architectuur. Dat geldt ook voor de afwijkingen van de architectuur (hoofdstuk 6 van de PSA). Deze afwijkingen zijn voor een deel bekend aan het begin van het project en komen voor een deel pas in een later stadium naar voren. Afwijkingen moeten worden goedgekeurd door de architectuurboard. Bovendien leiden deze afwijkingen tot additioneel werk aan het einde van het project om die afwijkingen (eventueel, indien zo besloten) weer op te lossen. De overwegingen voor het apart beschrijven van de ontwerpkeuzes en de architectuurafwijkingen zijn dus direct gerelateerd aan het gebruik van de PSA in het ondersteunen van projecten en de verantwoording naar de architectuurboard.


1.0

24


6

DE REFERENTIE ARCHITECTUUR EN DE PSA

De Referentie Architectuur (RA) bestaat uit een Enterprise Architectuur en de -daarvan afgeleide- domeinarchitecturen.

Enterprisearchitectuur

Domeinarchitectuur


Domeinarchitectuur


Referentie architectuur

Domeinarchitectuur


Domeinarchitectuur



Figuur 9 De relatie tussen RA en PSA

De relatie tussen de Referentie Architectuur en de PSA is tweeledig (Figuur 10). Voor elk project worden de algemene principes, de beleidslijnen en de standaarden vertaald naar een projectspecifiek kader. De Referentie Architectuur wordt als het ware toegesneden op de specifieke problematiek van het project. Binnen de scope van het project worden relevante modellen -die de huidige en/of de toekomstige situatie weergeven- overgenomen. Na afloop van het project worden de veranderingen die zijn aangebracht in de architectuur doorgevoerd in de Referentie Architectuur. Ook de projectoverstijgende ontwerpkeuzes worden opgenomen in de Referentie Architectuur . Referentie Architectuur Projectoverstijgende ontwerpkeuzen Aanpassingen architectuur

Modellen Architectuurprincipes

PSA

Figuur 10 De uitwisseling tussen RA en PSA

6.1

Van Referentie Architectuur naar PSA

DYA® definieert architectuur als een “consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie”. Daarmee ligt ook de inhoud van de Referentie Architectuur vast: principes en modellen op de vier deelterreinen (processen, organisatorische inrichting, informatievoorziening en technische infrastructuur). Sogeti Nederland B.V. oktober 2009

1.0

25


De term ‘architectuurprincipes’ is een containerbegrip dat meerdere variabelen omvat. Denk daarbij aan principes, richtlijnen, normen, etc. Kern van dit alles is dat er een vertaling plaatsvindt van een abstract businessdoel van een organisatie (visie, missie) naar meer concrete uitspraken waar de praktijk mee uit de voeten kan, in een poging het businessdoel van het project te realiseren. Precies dat is ook de rol van de PSA in relatie tot de architectuurprincipes. Vanuit de Referentie Architectuur, waarin deze principes zijn vastgelegd en worden beheerd, worden de relevante principes geselecteerd. Deze worden vervolgens vertaald naar concrete consequenties voor het onderhavige project. Uiteindelijk levert dit requirements op die vanuit de architectuur aan het projectresultaat worden gesteld. Deze requirements kunnen dan door het project net zo afgehandeld worden als de overige requirements (business, user, system). De PSA is het communicatiemiddel om deze vertaling van principes naar requirements over te dragen van de architectuurfunctie naar het project. De PSA beoogt ook het omgevingsmodel uit te tekenen en een afbakening van de oplossing te geven. Dat wordt gedaan aan de hand van de modellen zoals die in en door de Referentie Architectuur worden beheerd. Daarbinnen moet de oplossing zijn plek zien te vinden. Deze plek wordt aan de hand van die modellen bepaald en via de PSA doorgegeven aan het project. De impact-analyse, die uitgevoerd wordt om de business case op te stellen, maakt ook gebruik van die modellen om zodoende inzicht te krijgen in de ‘future state’. Op basis van de analyse van de ‘current state’ wordt een vergelijking gemaakt tussen ‘çurrent’ en ‘future’. Deze vergelijking levert dan de impact van de oplossing op. Daarbij kunnen meerdere alternatieven in de analyse meegenomen worden. Referentie Architectuur Algemene requirements


Project

Domeinarchitectuur


Architectuur requirements

Projectspecifieke requirements

Oplossing

Impact analyse

Figuur 11 Requirements vanuit de RA voor het project


1.0

26


6.2

Geen Referentie Architectuur, toch een PSA

Vaak wordt het ontbreken van een Referentie Architectuur als reden gezien om geen PSA op te stellen. De PSA is immers een vertaling van die Referentie Architectuur ten behoeve van het project. Echter, het doel van een PSA is om een kader mee te geven aan het project. Ook zonder Referentie Architectuur is zo'n kader nuttig. Er kan dus ook in een dergelijke situatie een PSA worden opgesteld. Het verschil met al het voorgaande is dat er nu niets vanuit de Referentie Architectuur overgenomen kan worden. Het moet dus allemaal ‘vanaf nul’ beschreven worden. Dit kost uiteraard wel meer tijd dan wanneer een Referentie Architectuur een solide basis kan leggen onder de PSA. Gevolg is ook dat de doorlooptijd voor het opstellen van een PSA toeneemt. Architectuurprincipes worden niet opgesteld binnen het project. Die bevoegdheid ligt bij de architectuurfunctie4. Een project kan wel als trigger dienen om deze principes (en richtlijnen, standaarden en normen, etc.) op te stellen. De architectuurfunctie bespreekt deze en legt ze vast (just-enough, just-in-time) en legt ze ter validering voor aan de architectuurboard. De modellen die als kader meegegeven worden in de PSA, zijn nuttig voor het project, omdat ze de scope van het project weergeven. Die modellen worden nu opgesteld op het moment dat deze voor de PSA nodig zijn (ook hier ‘just-enough, just-in-time’). Wanneer ze er zijn kunnen ze, nadat ze de juiste validatieprocedure doorlopen hebben, opgenomen worden in de Referentie Architectuur. Zo worden twee vliegen in één klap geslagen: iets dat toch al nodig is voor het project (standaarden, richtlijnen, modellen, etc), wordt ook als invulling van de Referentie Architectuur gebruikt. Een valkuil in dit scenario is dat door het ontbreken van een concrete en volledige Referentie Architectuur er veel ontwerpactiviteiten plaatsvinden in de tijd dat de PSA wordt opgesteld. Dit heeft tot gevolg dat het vervaardigen van deze architectuurproducten een moeizame exercitie wordt. Vanuit DYA® wordt dan ook aangeraden om in dit scenario snelheid te laten prevaleren boven nauwkeurigheid en zekerheid. Gebeurt dit niet, dan worden projecten onnodig lang opgehouden en krijgt architectuur de naam een vertragende factor te zijn. Architecten ontkomen in dit scenario niet aan verwachtingsmanagement en doen er goed aan te blijven hameren op het feit dat de ontwerpfase een activiteit is die binnen een project hoort te vallen.

6.3

Van PSA naar Referentie Architectuur

De Referentie Architectuur kan aangepast worden naar aanleiding van keuzes die gemaakt zijn in het kader van een project. Dit betreft eerst en vooral de eerder genoemde projectoverstijgende ontwerpkeuzes. Juist door het projectoverstijgende karakter hebben deze ontwerpkeuzes een relatie met architectuur. De architectuur is immers de bewaker van de samenhang. Het gaat hier veelal om ontwerpkeuzes die tot standaard gepromoveerd kunnen gaan worden. Ook keuzes die met de inrichting van algemene faciliteiten te maken hebben, vallen in deze categorie. Andere projecten moeten daar op een juiste wijze op (kunnen) aansluiten. Dat kunnen zowel projecten zijn die parallel lopen (en waarvoor deze ontwerpkeuzes dus meteen actueel zijn) of die in de toekomst opgestart gaan worden.

4

Verschillende (domein)architecten zijn verantwoordelijk voor verschillende delen van de architectuur, waaronder de daarbij horende architectuurprincipes. Sogeti Nederland B.V. oktober 2009

1.0

27


De projectarchitect heeft de verantwoordelijkheid om de relevantie van projectkeuzes die van invloed zijn op de Referentie Architectuur te signaleren en deze issues mee te nemen voor bespreking binnen het architectenoverleg. Dat architectenoverleg adviseert de architectuurboard over het eventueel aanpassen van de Referentie Architectuur. De board geeft formeel opdracht voor de aanpassing van de Referentie Architectuur, die vervolgens door de geëigende persoon wordt doorgevoerd. Dit kan al tijdens het project plaatsvinden, maar moet zeker onderdeel zijn van het afsluiten van een project. Daarnaast kunnen ook (aanpassingen aan) modellen die gemaakt zijn voor het project (ten dienste van de PSA of daarna) “gepromoveerd” worden tot onderdeel van de Referentie Architectuur. Het project is opgestart met het doel om veranderingen door te voeren. Dit kan betrekking hebben op alle drie de terreinen: de business, de informatievoorziening en de infrastructuur. Dat betekent dat de huidige situatie is aangepast. Indien deze huidige situatie als onderdeel van de Referentie Architectuur wordt bijgehouden, moeten dus ook deze aanpassingen daarin worden doorgevoerd. Ook dit gebeurt na opdracht van de architectuurboard. Dit laatste is zeker handig indien de Referentie Architectuur zelf nog weinig vlees op de botten heeft. Dat “vlees” wordt dan stukje bij beetje door de verschillende projecten aangeleverd. Op deze wijze wordt de Referentie Architectuur stapsgewijs (‘just enough, just-in-time’) opgebouwd, uitgebreid en actueel gehouden. Deze stapsgewijze invulling van de Referentie Architectuur is idealiter een aanvulling op een algemene inspanning om de Referentie Architectuur op te stellen vanuit de bedrijfsvisie. Uitgangspunt hierbij is dat de Referentie Architectuur in releases wordt opgeleverd. Volgens een releaseplanning wordt duidelijk gemaakt wanneer een nieuwe versie beschikbaar komt. In die nieuwe versie zijn alle -door de architectuurboard goedgekeurde- wijzigingen opgenomen, die sinds de laatste release naar voren zijn gekomen.


1.0

28


7

DE PSA EN PRINCE2 TM

Prince2 5 is momenteel de meest gebruikte projectmanagementmethode. Figuur 12 geeft de plaats weer van de PSA binnen het Prince2 TM -procesmodel. Directing a Project

Starting up a Project SU

Initiating a project IP

Managing stage Boundaries SB

Controlling a stage

Closing a project

CS

CP

Project Kaders Brief (Impact) Kader voor hulp en toetsing

Managing product Delivery MP

PSA Afwijkingen Ontwerpbeslissingen

Borgen Afwijkingen Ontwerpbeslissingen

Planning

Figuur 12 De PSA binnen Prince2

TM

In paragraaf 4.1 zijn de vier ondersteunende activiteiten van architectuur aan projecten beschreven. In Prince2 zijn die vier ondersteunende activiteiten als volgt te plaatsen: 1 - Vaststellen kaders

2 - Helpen ontwikkelaars6

3 - Controleren producten

4 - Borgen resultaten

- Initiating a Project naast de Business Case en het Project Initiation Document (PID). - Managing Product Delivery het opstellen van het product, cq. uitvoeren van de work package - Managing Product Delivery onderdeel van de quality review. De controlling architect beoordeelt de kwaliteitscriteria vanuit architectuurperspectief. Hij is één van de specialisten die bij deze activiteit wordt betrokken. - Closing a project onderdeel van de te definiëren vervolgacties.

5

Voor kennis over Prince2 TM verwijzen we u naar de literatuur. Prince2 TM wordt hier alleen besproken in relatie tot de PSA. 6

.. en ontwerpers en bouwers.


1.0

29


7.1.1

De PSA en de PID

Het opstellen van de PSA vindt plaats in de fase Initiating a Project (IP). In die fase wordt uiteindelijk het Project Initiation Document (PID) opgesteld. De activiteiten die in deze fase uitgevoerd worden, leveren deelproducten op die onderdeel van die PID uitmaken. De PSA is op drie plaatsen in de IP-fase te zien. Ten eerste bij de activiteit Planning Quality (IP1). Onderdeel daarvan is het vaststellen van de relevante standaarden en richtlijnen. In dat kader wordt de PSA gezien als een specifieke invulling van de standaarden en richtlijnen vanuit de architectuur. Deze Planning Quality wordt later een onderdeel van de PID. Ook wordt hier bepaald wat de inspanning van de controlling architect dient te zijn en welke producten hij zal controleren. Een ander onderdeel is Planning a Project (IP2). Daarbinnen worden de relevante producten geïdentificeerd en de inspanning om deze te maken. De PSA dient als één van de producten te worden gezien. Voor de oplevering van dit product moeten dus tijd en resources gepland worden. Het opstellen zelf is, zoals eerder benoemd, een samenspel tussen projectleider en projectarchitect. In het kader van Prince2 wordt dit vorm gegeven door het opstellen van een PSA als ‘work package’ te definiëren, dat de projectleider ter uitvoering uitgeeft aan de projectarchitect. Een derde onderdeel is Refining the Business Case and Risks (IP3). In dat kader is de impact-analyse van belang, zoals die door DYA® wordt gepositioneerd. De mapping van de requirements op de architectuur leidt dan tot de voorziene impact. Die inschatting van de impact levert een bijdrage aan de schatting van de inspanning, doorlooptijd en kosten voor het project en het bepalen van de future-state. Dit gebeurt dan in het kader van het verder uitwerken van de business case. De PID is de samenvoeging van de resultaten van de activiteiten die in deze fase uitgevoerd worden. Vanwege de scheiding tussen architectuur- en projectverantwoordelijkheid wordt de PSA GEEN onderdeel van de PID. Zij bestaan parallel aan elkaar. De PSA wordt ter beoordeling voorgelegd aan de architectuurboard, terwijl de Project Board zich over de PID buigt. De relatie impactanalyse - PSA - PID De impact-analyse, zoals hierboven genoemd, wordt zelfstandig uitgevoerd. De resultaten van de impact-analyse zijn dan input voor zowel de PSA als de PID. Het opstellen van de PSA en de PID vindt dan initieel parallel aan elkaar plaats. De resultaten van de PSA worden vervolgens ingebracht in de PID. Figuur 13 laat dit zien.


1.0

30


Impact analyse

Project Brief

Business Case initieel

PSA

Go/ No Go

PID

Go/ No Go

Architectuur Board

Project Board

Business Case

Figuur 13 De relatie tussen impact analyse, PSA en PID

Voor zowel de impact-analyse als de PSA is de Project Brief het uitgangsdocument. Daarin worden de doelstellingen en de scope van het project meegegeven. Ook zijn op hoog niveau de business requirements gegeven, waaraan het project dient te voldoen. Daarbij is een initiële invulling gegeven aan de business case. De impact-analyse geeft inzicht in de betrokken processen, applicaties en infrastructuur. Dit inzicht kan zowel voor de PSA als voor de PID gebruikt worden. Deze twee documenten kunnen vervolgens initieel zelfstandig van elkaar tot stand komen. Ten behoeve van de PID gebruikt de projectleider de resultaten van de impact analyse om de business case verder uit te werken en de daarbij horende inspanning en doorlooptijd af te leiden. Op basis van de PID neemt de Project Board een “go/no go”beslissing over het project. In de PSA wordt, door de projectarchitect, het relevante kader voor het project geschetst. De nadruk ligt hierbij dus op de vertaling van de architectuurprincipes (die in de RA gegeven zijn) naar richtlijnen, standaarden en uiteindelijk requirements die vanuit de architectuur aan het project gegeven worden (Figuur 14). De PSA wordt geaccordeerd door de architectuurboard. Bij een eventuele “no go” van de architectuurboard is deze discussiepartner van de opdrachtgever die vertegenwoordigd wordt door en/of lid is van de projectboard. Deze escalatie is in paragraaf 4.2.3 beschreven. Referentie Architectuur Algemene requirements


Project

Domeinarchitectuur


Architectuur requirements

Projectspecifieke requirements

Oplossing

Impact analyse

Figuur 14 De impact-analyse apart van de PSA Sogeti Nederland B.V. oktober 2009

1.0

31


8

TOT SLOT

Deze ‘whitepaper’ heeft tot doel om veelgestelde vragen rond de PSA te verhelderen. Daarnaast is ook een aanzet gegeven tot een uitwerking van de relatie tussen de PSA en de Referentie Architectuur en de relatie tussen de PSA en de projectmethodiek Prince2TM. Deze relaties geven aan dat de PSA niet op zichzelf staat, maar onderdeel is van het architectuurproces én een rol speelt in de architectuurbegeleiding van projecten. De scope en het doel van deze ‘whitepaper’ zijn zodanig dat niet alle relaties en verbanden konden worden uitgewerkt. Toch worden - op de valreep - nog een tweetal aanbevelingen meegegeven die het werken met de PSA verder richting geven en eerder genoemde aanwijzingen onderstrepen. Een PSA komt vooral tot zijn recht als het architectuurproces in een organisatie in de volle breedte is geïmplementeerd en geborgd. Het denken werkmodel DYA7 richt zich hier primair op. Hoewel de PSA binnen DYA® een prominente plek inneemt, dient ook voldoende aandacht te worden besteed aan het werken met de andere architectuurproducten, zoals de producten die de PSA 'voeden'. Zowel het opstellen van Architectuurschetsen als Impact-Analyses zijn onmisbare voorbereidende stappen bij het creëren van een PSA. In sommige organisaties worden deze beide stappen uitgevoerd binnen de activiteit van het opstellen van de PSA. Het gevolg is dikke documenten en lange doorlooptijden voor het maken van de PSA. Bovendien is de PSA in zo'n vorm niet goed te onderhouden, omdat wijzigingen moeilijk door te voeren zijn. Voor het succesvol werken met de PSA dient niet alleen het architectuurproces goed ingericht te zijn, het dient ook te zijn ingebed in de organisatie. Dit betekent dat duidelijke rolverdelingen en verantwoordelijkheden zijn vastgesteld voor architecten, projectleiders, ontwikkelaars, bouwers, enzovoorts. In deze ‘whitepaper’ is hier uitvoerig aandacht aan besteed, juist omdat een goede rolverdeling essentieel is voor het functioneren van de PSA. In dit kader verdient de rol van architecten bij de ondersteuning van projecten extra nadruk, omdat dit in veel organisaties een onderbelicht aspect is. Het werken onder architectuur stopt niet bij het opstellen van de PSA. Zorg er dus voor dat de uitvoering van projecten vanuit de PSA onder architectuurbegeleiding plaatsvindt. Dan worden de voordelen van het werken onder architectuur en met de PSA makkelijker en met minder inspanning behaald!

7

Meer informatie over de PSA en DYA is te vinden op www.dya.info. Op deze site is een overzicht te vinden van alle publicaties die in het kader van DYA® zijn verschenen. Het is ook mogelijk om via deze site aan te geven aan welke thema's omtrent de PSA/het architectuurproces meer aandacht zou moeten worden gegeven.


1.0

32

WHITE PAPER PROJECT START ARCHITECTUUR

Recommend Documents