WHITE PAPER PRINCE2 EN ARCHITECTUUR

Transcriptie

1 WHITE PAPER PRINCE2 EN ARCHITECTUUR JOOST LUIJPERS

2

3 WHITE PAPER PRINCE2 EN ARCHITECTUUR Joost Luijpers Versie: Copyright 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 I

4

5 Whitepaper: Prince2 en Architectuur Reviewers REVIEWERS De volgende medewerkers van Sogeti hebben bijgedragen aan de totstandkoming van deze white paper: Naam Martin van den Berg Paul Dijkwel Hans Engelen Harmen Holwerda Henk Jumelet Aniel Kalicharan Krijn Kalma Cor Kingma Rudy Kusse Han Streithorst Maarten van der Werff Renzo Wouters Functie Management Consultant Senior Program Manager Program Director manager Informatie architect Informatie architect manager manager Informatie architect manager Informatie architect Informatie architect 1

6 Whitepaper: Prince2 en Architectuur INHOUDSOPGAVE REVIEWERS... 1 INHOUDSOPGAVE INLEIDING... 1 Doel van het document Doelgroep Opzet van het document Verwachte voorkennis ARCHITECTUUR EN PROJECTEN DYA in een notendop Het DYA-model Het architectuurraamwerk Architectuur en projecten architect Controlling architect Escalatie naar de architectuurraad PRINCE2 EN ARCHITECTUUR Overzicht relatie Prince2 en architectuur Opstarten project (OP) OP4 voorstel opstellen OP5 aanpak definiëren OP6 Plannen Initiatiefase Initiëren project (IP) IP1 Kwaliteitsplan opstellen IP3 Business case & Risico s aanscherpen IP4 beheersing opzetten Sturen (SP) SP1 initiatie autoriseren SP4 - Ad hoc sturing geven SP5 - afsluiting bevestigen Beheersen Fase (BF) BF3 - issues verzamelen BF4 - issues beoordelen BF8 - issues escaleren BF9 - Afgerond Werkpakket ontvangen

7 Whitepaper: Prince2 en Architectuur Inhoudsopgave 3.6 productoplevering (MP) MP1 - Werkpakket aannemen MP2 - Werkpakket uitvoeren faseovergangen (MF) MF1 Faseplan opstellen MF3 Business case actualiseren MF6 Afwijkingsplan opstellen Afsluiten project (AP) AP1 afbouwen AP2 Vervolgacties identificeren Opstellen plan (PL) PL2 - Producten definiëren en analyseren PL3 - Activiteiten en afhankelijkheden identificeren PL4 - Schatting maken PL5 - Tijdschema opstellen THEMA S MET ARCHITECTUUR BINNEN PROJECTEN Inrichting van het project Impact Analyse Kwaliteit PSA Afwijkingen n op de architectuur

8

9 Prince2 en Architectuur Inleiding 1 INLEIDING Veel organisaties hebben ervoor gekozen om Prince2 als projectmanagementmethode te hanteren. Wanneer een organisatie daarnaast onder architectuur gaat werken, betekent dit dat er ook onder architectuur ontwikkeld gaat worden. Aangezien de meeste ontwikkelingen (lees: veranderingen) projectmatig worden doorgevoerd, zal architectuur ook terug te vinden zijn in de werkwijze van het uitvoeren van projecten en de producten die het project oplevert. Doel van het document Het doel van dit document is om te beschrijven hoe het werken onder architectuur volgens DYA het werken met Prince2 1 raakt en beïnvloedt. Het aanhaken van architectuur op Prince2 kent vier vormen: Een binnen Prince2 bestaande activiteit (of een onderdeel daarvan) krijgt een extra dimensie vanuit architectuur; Aan een binnen Prince2 bestaande activiteit of product wordt een nieuw element vanuit architectuur toegevoegd; Aan een binnen Prince2 bestaande activiteit of product wordt vanuit architectuur een bijdrage geleverd; Vanuit de architectuur worden andere standaardproducten toegevoegd. De beschrijving in dit document van de relatie tussen Prince2 en architectuur geeft aan waar van één van deze vier aanpassingen sprake is op het moment dat een project dat met Prince2 wordt gedaan onder architectuur wordt uitgevoerd. Bij een beschrijving van de relatie tussen Prince2 en architectuur komt automatisch de relatie tussen projectleiders 2 en architecten 3 tot uitdrukking. Het is ook het doel van dit document om deze relatie duidelijk te maken. De beschrijving geeft aan waar deze twee spelers elkaar binnen een project tegen komen. 1.2 Doelgroep De doelgroep voor dit document zijn de projectleiders enerzijds en de architecten 4 anderzijds. Voor projectleiders wordt duidelijk op welke manier architectuur inhaakt op de uitvoering project. Er wordt beschreven op welke plek, vanuit de procesgang van Prince2 de vier soorten van verandering, zoals hierboven aangegeven, plaatsvinden. Daarbij wordt ook duidelijk welke acties van hen verwacht worden en welke zij van de architecten kunnen verwachten. Zij kunnen dus aan de hand van dit document hun projectplan en -aanpak inclusief architectuur uitwerken. De architecten krijgen inzicht op welke plaats en manier hun werkzaamheden ten behoeve project inhaken op de aansturing van dat project. 1 De kennis over Prince2 is ontleend aan het boek De essentie van Prince2, geschreven door Colin Bentley, ISBN Dit boek is eigendom van Key Result. 2 Wanneer in dit document de term projectleider wordt gehanteerd, wordt hiermee ook projectmanager bedoeld, tenzij expliciet anders aangegeven. 3 Er bestaan veel verschillende functiebenamingen voor architecten. De algemene term architect wordt gebruikt wanneer elk van deze bedoeld worden. Specifieke soorten architecten worden expliciet aangegeven. 4 Bij veel organisaties wordt de term Informatiemanager gehanteerd. Deze worden hier ook bedoeld. 1

10 Whitepaper: Prince2 en Architectuur Inleiding 1.3 Opzet van het document In hoofdstuk 2 worden de essenties van DYA in het kort geschetst en wordt een globale schets gegeven van de relatie tussen projecten en architectuur. Deze relatie komt in DYA-termen tot uitdrukking in het proces Ontwikkelen onder Architectuur. In hoofdstuk 3 en 4 staat inhoudelijk hetzelfde, maar vanuit een ander perspectief. In hoofdstuk 3 wordt het perspectief vanuit de processen van Prince2 gegeven. Dit hoofdstuk is in eerste instantie bedoeld voor lezers die bekend zijn en een affiniteit hebben met Prince2. Er wordt expliciet ingegaan op de uitgangspunten en voorschriften van Prince2 en de aanpassingen ngen die daarop van toepassing zijn nu er onder architectuur ontwikkeld wordt. Uitgangspunt zijn daarbij de processen zoals Prince2 die definieert. Prince2 wordt bekend verondersteld dus er wordt op die plaats verder geen beschrijving van Prince2 gegeven. Enkel wordt aangegeven wat de consequenties zijn van het werken onder architectuur. Hoofdstuk 4 is geschreven vanuit het architectuurperspectief. Dit hoofdstuk is in eerste instantie bedoeld voor lezers die bekend zijn en affiniteit hebben met architectuur. tuur. Vanuit architectuur is er een aantal thema's te onderkennen die gerelateerd zijn aan het uitvoeren van projecten. Hoofdstuk 4 beschrijft het aanhaken op Prince2 vanuit dat perspectief. 1.4 Verwachte voorkennis Van de lezers van deze white paper wordt verwacht dat zij enige kennis hebben van zowel Prince2 als DYA. Binnen DYA is met name de PSA van belang. Deze kennis is te verkrijgen door het bestuderen van de onderstaande publicaties. Zoals in paragraaf 1.3 is aangegeven wordt DYA in hoofdstuk 2 in een notendop beschreven. [1] De essentie van Prince2 ; Colin Bentley; ISBN Dit boek is eigendom van Key Result. [2] De kleine Prince 2, vierde gehele herziene editie; Mark van Onna, Ans Koning; Academic Service; ISBN [3] DYA : Snelheid en samenhang in business- en informatiearchitectuur, derde oplage, augustus 2002; Roel Wagter, Martin van den Berg, Joost Luijpers, Marlies van Steenbergen; Uitgeverij Tutein Nolthenius, Den Bosch 2001, Nederland; ISBN ; 4; [4] DYA : Stap voor stap naar professionele enterprise-architectuur, 2004; Martin van den Berg, Marlies van Steenbergen; Ten Hagen & Stam uitgevers; ISBN [5] Start Architectuur, 2007 White paper; Joost Luijpers; [6] DYA INfrastructuur, architectuur voor de fundering van de IT, 2007; Daniel Jumelet; Academic Service; ISBN: /

11 Prince2 en Architectuur Architectuur en projecten 2 ARCHITECTUUR EN PROJECTEN 2.1 DYA in een notendop In deze paragraaf wordt DYA in een notendop beschreven. Meer informatie is te vinden in [3] en [4] en op DYA is de visie van Sogeti op het omgaan met architectuur. Het gaat over de totstandkoming en het onderhouden van de architectuur. Dit moet op een dynamische manier plaatsvinden; de organisatie gaat op een slimme, slanke en snelle wijze om met het fenomeen architectuur. DYA is ontstaan op basis van ervaringen uit de praktijk over hoe met architectuur wordt omgegaan. DYA is gefundeerd op tien principes. Deze principes worden door onderstaande uitgangspunten samengevat: Architectuur is geen doel op zich, maar is ondersteunend aan de doelen die de organisatie wil bereiken. Het doel van architectuur is niet om een document op te leveren, maar om ervoor te zorgen dat de veranderprocessen van de organisatie steeds soepeler gaan verlopen. Architectuurontwikkeling moet daarom worden verankerd in die veranderprocessen. Architectuur kan heel goed stukje bij beetje worden aangepakt. Het is niet nodig om in één keer een volledig architectuurdocument neer te leggen. Architectuur evolueert mee met de organisatie. Afwijken van de architectuur kan onder omstandigheden noodzakelijk zijn. Het is wel zaak een mechanisme in te richten waarmee dergelijke afwijkingen van de architectuur worden beheerst. Dit kan door aparte ontwikkelscenario's te onderscheiden voor het ontwikkelen onder architectuur en voor het niet volledig onder architectuur ontwikkelen. 2. Het DYA-model De kern van DYA wordt gevormd door het DYA-model. Figuur 1 toont het DYA-model. Dit model bevat vier processen die het hele traject van strategievorming tot realisatie beslaan. Deze processen helpen om uw architectuur in te richten, zodat tot een inzet van ICT wordt gekomen waarbij de business slagvaardig wordt bediend tegen acceptabele kosten. De samenhang tussen businessarchitectuur, informatiearchitectuur en technische architectuur wordt daarbij gewaarborgd. Inrichten van de processen rondom architectuur conform DYA heeft het voordeel dat de momenten zijn vastgelegd waarop architecturen gemaakt en toegepast worden. Daardoor is bekend op welk moment een architect nodig is en wat hij dan oplevert. Resultaat is de juiste architectuur op het juiste moment. 3

12 Whitepaper: Prince2 en Architectuur Architectuur en projecten Figuur 1 Het DYA-model In de Strategische Dialoog worden, op basis van de business strategie de businessdoelen bepaald, die vervolgens in business cases worden uitgewerkt tot concrete projectvoorstellen. Gezien het strategische belang van ICT tegenwoordig voor een organisatie bepalen business- en ICT-management steeds meer samen welke businessdoelen de organisatie wil nastreven. De mogelijkheden binnen de ICT bepalen namelijk mede de mogelijkheden voor de organisatie. Deze businessdoelen worden vervolgens in multidisciplinaire teams uitgewerkt tot business cases. De business cases geven aan hoe het gewenste doel bereikt kan worden, wat dat voor de organisatie betekent (op basis van impact analyses) en wat de financiële consequenties zijn (in termen van investering, jaarlijkse kosten en baten). Is een business case positief, dan wordt overgegaan tot het opstellen concreet projectvoorstel. De uitkomst van deze activiteiten is het projectportfolio; het overzicht welke projecten uitgevoerd (gaan) worden. Vanwege de directe relatie die dit portfolio heeft met de strategische doelen van de organisatie, zijn de functionarissen die bij de Strategische Dialoog betrokken zijn ook betrokken bij het projectportfoliomanagement. Zowel bij het vaststellen van de businessdoelen als bij het uitwerken van business cases werken business en ICT nauw samen. Het doel van de Strategische Dialoog is te zorgen dat op tijd de juiste dingen gedaan worden. Ontwikkelen (z)onder Architectuur realiseert de concrete businessdoelstellingen, binnen de gewenste doorlooptijd met de gewenste kwaliteit en tegen acceptabele kosten. Bij dit proces gaat het dus om de projectuitvoering. Hierbij is het ontwikkelen onder architectuur de standaard. Bij Ontwikkelen onder Architectuur krijgt het projectteam een zogenaamde projectarchitectuur is een vertaling van de algemene architectuurprincipes en modellen naar een op het project toegesneden start-architectuur architectuur mee. Een project-start-architectuur kader. Dit kader geeft de concrete standaarden, normen en richtlijnen weer die het project zal hanteren. Ook projectoverstijgende ontwerpkeuzen worden in de project- 4

13 Prince2 en Architectuur Architectuur en projecten start-architectuur vastgelegd. De project-start-architectuur wordt door de architecten opgesteld, in nauwe samenwerking met het projectteam. In paragraaf 2.2 wordt hier dieper op ingegaan. Onder speciale omstandigheden, echter, wanneer er sprake is van extreme tijdsdruk, kan er voor gekozen worden om voor een keer bewust niet onder architectuur te ontwikkelen. Dan wordt het proces Ontwikkelen zonder Architectuur uitgevoerd. In dit proces worden op beheerste wijze bepaalde architectuuraspecten tijdelijk niet meegenomen. Op beheerste wijze, omdat gelijktijdig, via de zogenaamde management letter, maatregelen genomen worden om uiteindelijk wel weer onder architectuur te komen. De management letter is een "contract" tussen opdrachtgever, projectmanager en architect waarin afspraken worden gemaakt met betrekking tot de beperkte levensduur van het projectresultaat en het parallel starten structureel traject. Het doel van Ontwikkelen (z)onder Architectuur is de juiste dingen juist doen. In dit model is Architectuur Services, het opstellen en bewaken van de architectuur, duidelijk gepositioneerd als ondersteunend proces. Architectuur is geen doel op zich, maar een middel om de veranderingen, vormgegeven in de Strategische Dialoog en het Ontwikkelen (z)onder Architectuur, zodanig te sturen dat de businessdoelen optimaal bediend worden. Architectuur Services is faciliterend aan de Strategische Dialoog en Ontwikkelen onder Architectuur. Het proces slaat daarmee de brug tussen de businessdoelen en de projecten die de oplossingen leveren. Aan de Strategische Dialoog worden de benodigde architectuurprincipes en modellen, onderdeel van de Referentie Architectuur 5, geleverd ten behoeve van het uitwerken van de business cases. Tevens helpt dit proces met het uitvoeren van de impact analyses. Ontwikkelen onder Architectuur wordt ondersteund met concrete kaders, richtlijnen, hulpmiddelen en ontwerpkeuzen in de vorm project-start-architectuur. De trigger voor Architectuur Services is doorgaans een concrete business case die uitgewerkt moet worden. Het doel van Architectuur Services is te zorgen dat de dingen juist gedaan worden. Processen lopen niet vanzelf goed. Daarvoor is een vorm van besturing nodig. Verantwoordelijkheden moeten duidelijk belegd zijn en er moet bewaakt worden dat de gewenste resultaten bereikt worden. Daarbij is het belangrijk de juiste stuurinstrumenten ter beschikking te hebben. Topmanagement speelt hierin een heel belangrijke rol. De eindverantwoordelijkheid voor architectuur is ook een zaak van het topmanagement. Wij vatten de besturingsaspecten samen onder de term governance. Een dynamische architectuur is een architectuur die specifiek gericht is op snelheid. Hier zitten twee kanten aan. In de eerste plaats is er de inhoudelijke kant die slaat op de architectuur als product: de vorm van de architectuur is zodanig dat aanpassingen aan nieuwe, nu nog onvoorziene, ontwikkelingen zo snel en goedkoop mogelijk zijn. De architectuur kan wijzigingen in de bedrijfsvoering snel ondersteunen. Hierbij spelen zaken een rol als ontkoppelpunten, gegevens bij de bron halen, sturing op interfaces en scheiding van presentatie-, business- en datalaag. De tweede kant is de proceskant: het omgaan met architectuur. Hier wordt mee bedoeld dat het tot stand komen en onderhouden van de architectuur dynamisch is. 5 De Referentie Architectuur geeft de principes, richtlijnen en standaarden weer die bij toekomstige ontwikkleingen gehanteerd moeten worden. Deze zijn gebaseerd op een ideale weergave van de toekomstige situatie, waar de verschillende ontwikkelingen naartoe moeten werken. Deze schets van de toekomstige situatie is ook een onderdeel van de Referentie Architectuur. Daarnaast kan de Referentie Architectuur een weergave van de huidige situatie bevatten. 5

14 Whitepaper: Prince2 en Architectuur Architectuur en projecten De organisatie gaat op een slimme, slanke en snelle wijze om met het fenomeen architectuur. Hierbij spelen zaken een rol als multidisciplinaire samenwerking, just-in-time architectuur, just-enough architectuur en de project-start-architectuur. architectuur Het architectuurraamwerk Om de architecturen te kunnen classificeren heeft DYA zijn eigen architectuurraamwerk. Het vormt als het ware een ladenkast waarin elke architectuur zijn plek krijgt. Het architectuurraamwerk illustreert dat de architectuur organisatie niet als een monolithisch geheel beschouwd moet worden, maar opgedeeld in onderdelen. Sommige van die onderdelen zullen in een specifiek geval tot in detail zijn uitgewerkt (de cel in de matrix is gevuld), terwijl andere delen wellicht nog helemaal niet beschouwd zijn (de cel is nog leeg). Dat is volstrekt legitiem. Zolang de wel ingevulde delen maar consistent met elkaar, en met de businessdoelen, zijn en de delen zijn ingevuld die nodig zijn voor de sturing van de actuele veranderingen binnen de organisatie. Het Architectuurraamwerk van DYA, zoals hieronder in Figuur 2 afgebeeld, heeft als doel om relevante deelarchitecturen turen een plek te kunnen geven en verbanden tussen deelarchitecturen zichtbaar te maken. De horizontale as van het raamwerk geeft de verschillende objecten van architectuur weer in de veelvoorkomende driedeling businessarchitectuur, informatiearchitectuur en technische architectuur. Deze driedeling wordt door vele architecten herkend. Daarbinnen is nog een verdere opdeling te maken. Elk van deze architecturen heeft een ander object van architectuur (producten/diensten, processen, gegevens, storage, etc.). Voor elk van deze objecten onderscheidt het raamwerk een kolom. De businessarchitectuur vormt het kader voor de wijze waarop de organisatie georganiseerd is om de businessdoelen te bereiken: de producten en diensten waarmee de organisatie de bedrijfsdoelen wil bereiken, de processen die hiervoor nodig zijn en de manier waarop de uitvoering van die processen is georganiseerd. De informatiearchitectuur vormt het kader voor de wijze waarop de informatievoorziening binnen de organisatie vorm gegeven wordt: de gegevens die voor de organisatie van belang zijn en de applicaties waarmee de informatie- uitwisseling binnen de organisatie ondersteund wordt. De technische architectuur vormt het kader voor de technische infrastructuur van de organisatie 6 : de servers die de procesverwerkende capaciteiten leveren, de middleware die ondersteunende, generieke ondersteuning aan bedrijfsapplicaties verzorgen, storage voor de (semi-)permanente opslag van data, de netwerken voor het transport van deze data tussen de verschillende systemen en de client realm voor het werkgebied van de gebruiker (inclusief werkstations en printers). Meer over deze indeling en de achterliggende uitwerking is te vinden in [6]. 6 Figuur 2 toont de oorspronkelijke indeling zoals die bij de introductie van DYA gehanteerd werd. [6] geeft een uitbreiding hierop. Een organisatie kan het raamwerk gebruiken dat voor hen het meest geschikt is. 6

15 Prince2 en Architectuur Architectuur en projecten Figuur 2 Architectuurraamwerk De verticale as van het raamwerk laat zien dat architectuur opgedeeld kan worden in drie abstractieniveaus: Algemene principes, Beleidslijnen en Modellen. Het hoogste abstractieniveau van architectuur is het niveau van de algemene principes. Deze weerspiegelen de gezamenlijke visie van business- en ICTtopmanagement. De algemene principes gelden voor iedereen en moeten ook voor iedereen begrijpelijk zijn. De algemene principes en concrete beleidslijnen samen noemen we de architectuurprincipes. Voorbeelden van algemene principes zijn: De organisatie streeft naar een foutloze en betrouwbare uitvoering van de dienstverlening; De klant kan bij één loket terecht voor al zijn vragen; Er mag geen ongeautoriseerde toegang plaatsvinden tot enig eigendom van de organisatie. Het tweede abstractieniveau van architectuur is het niveau van de concrete beleidslijnen die vorm geven aan de algemene principes. Deze zijn vaak specialistischer dan de algemene principes. Het is de vertaling van de algemene principes naar de concrete uitwerking per deelarchitectuur. Standaarden en richtlijnen bevinden zich bijvoorbeeld op dit niveau. De algemene principes en concrete beleidslijnen samen noemen we de architectuurprincipes. Voorbeelden van beleidslijnen zijn: Processtappen worden continu bewaakt op efficiency en tijdigheid van uitvoering; Processtappen zijn volledig traceerbaar; De loketmedewerkers zijn breed opgeleid; Toegang tot het netwerk kan alleen verkregen worden via een inlogprocedure; Wachtwoorden mogen niet langer dan 30 dagen geldig zijn. Het derde abstractieniveau van architectuur is het niveau van de specifieke modellen. Deze hebben, afhankelijk van het object van architectuur, verschillende vormen. Hier 7

16 Whitepaper: Prince2 en Architectuur Architectuur en projecten speelt de grafische vormgeving vaak een grote rol. De modellen vormen over het algemeen specialistentaal. Voorbeelden van modellen zijn: Organogram; Procesmodel; Gegevensmodel; Applicatie landschap; Netwerk lay-out. Het is zeker niet de bedoeling om in een autonoom proces het raamwerk van links naar rechts en van boven naar beneden cel voor cel in te vullen. Dat zou niet meer dan een papieren tijger opleveren. Integendeel, het raamwerk is juist bedoeld om de architect de mogelijkheid te bieden om zich bij het opstellen van architectuur te beperken tot specifieke onderdelen, terwijl hij toch het totaalbeeld bewaart. Welke cellen relevant zijn voor een organisatie hangt geheel af van de situatie en doelstellingen van de organisatie. 2.2 Architectuur en projecten en worden uitgevoerd om veranderingen door te voeren. Deze veranderingen echter, staan niet op zichzelf, maar passen in een groter geheel. Dat geheel wordt gevormd door de richting waarin de organisatie zich wilt ontwikkelen. Uiteindelijk zijn deze veranderingen bedoeld om de strategie die de betreffende organisatie voorstaat te realiseren. Het doel van architectuur is om het toekomstbeeld te schetsen waar alle veranderingen naartoe moeten werken. Dit volgt vanuit de strategie van de organisatie. In de uitvoering van de veranderingstrajecten gebruikt architectuur dat overzicht om te bewaken dat de ene verandering goed aansluit bij de andere veranderingen. Anders gezegd, architectuur heeft een helicopterview. De aanname is hierbij dat het doorvoeren strategie een langere termijn perspectief heeft. Het doorvoeren en bestendigen strategie is een kwestie van enkele jaren. en streven doorgaans kortere termijn doelen na. Kortom, het verschil tussen architectuur en projecten is de scope (respectievelijk breder tegenover smaller) en de termijn (respectievelijk langer tegenover korter). Werken onder architectuur betekent voor projecten dus dat de kortere termijn doelstelling voor het ene probleemgebied wordt afgestemd met de bedrijfsbrede context voor de langere termijn. Eén van de consequenties van het werken onder architectuur is dat aan een project extra requirements meegegeven worden vanuit de architectuur, ter bewaking van die langere termijn en om ervoor te zorgen dat de deeloplossing die het project oplevert past in het grotere geheel. Deze architectuurrequirements gaan over niet-functionele aspecten. Dit zijn extra requirements ter aanvulling op de gebruikelijke drieluik van requirements: business-, user- en systemrequirements. Figuur 3 geeft dit schematisch weer. 8

17 Prince2 en Architectuur Architectuur en projecten Algemene requirements Referentie Architectuur Principes en modellen Principes en modellen toegespitst op project Architectuur requirements Lange(re) termijn Korte termijn specifieke requirements Oplossing Impact analyse architect Figuur 3 Relatie architectuur en projecten Om de afstemming tussen het architectuurperspectief en het projectperspectief te krijgen wordt aan elk project de rol 7 van architect toegewezen. Deze projectarchitect ziet erop toe dat de resultaten van het project voldoen aan deze extra architectuurrequirements. Aan het begin van het project stelt hij deze architectuurrequirements op. Hierbij gaat het om het afleiden van requirements voor het project op basis van de Referentie Architectuur. Tijdens het project begeleidt hij het projectteam bij het maken van de juiste keuzes vanuit het gezichtspunt van de langere termijn en het grotere geheel. Als het project is afgelopen borgt hij de resultaten van dat project in de Referentie Architectuur. Dit betekent dat het overzicht van de huidige stand van zaken wordt aangepast en dat eventueel bestaande kaders worden aangepast, vervangen of verwijderd Controlling architect Een andere rol 8 die vanuit de architectuur aan een project wordt toegevoegd is die van de controlling architect. Tijdens het project controleert hij de verschillende producten die door het project worden opgeleverd op het voldoen aan de architectuurrequirements. Hiertoe neemt hij deel aan de productreviews. Hij is geen integraal onderdeel van het projectteam. Omwille van de zuiverheid van zijn oordeel dient de rol van de controlling architect door iemand anders ingevuld te worden dan degene die het product heeft opgesteld. Ontwerpdocumenten zijn in principe het product van de ontwerper. De projectarchitect kan dan ook de rol van de controlling architect op zich nemen. Indien de betrokkenheid van de projectarchitect bij het opstellen van het ontwerpdocument dusdanig is geweest dat dit product ook als zijn eigendom beschouwd kan worden, kan een andere architect de rol van de controlling architect vervullen. In het vervolg van het document wordt de rol van de controlling architect expliciet benoemd als onderscheiden van de rol van de projectarchitect. Wanneer beide rollen door de zelfde functionaris worden vervuld, vervalt dus dat onderscheid. 7 architect is een rol, geen functie. Deze rol kan dus door verschillende functionarissen ingevuld worden, zoals architecten van allerlei soorten en maten. De aard van het project bepaalt mede welke functionaris hier het meest geschikt voor is. 8 Ook hier betreft het een rol die ingevuld wordt door degene die voor het onderhavige project het meest geschikt is. 9

18 Whitepaper: Prince2 en Architectuur Architectuur en projecten Escalatie naar de architectuurraad 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 PSA. Architect Opdrachtgever manager Figuur 4 Samenspel rollen 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 architectuurraad 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 enwoordigd in de architectuurraad, tezamen met een vertegenwoordiger van het topmanagement. Een architectuurraad is een platform voor inhoudelijke afstemming en escalatie. Architectuurraad Top management Architectuur management Business management Programma management Architect Opdrachtgever manager Figuur 5 De architectuurraad 10

19 Prince2 en Architectuur Architectuur en projecten De voornaamste taken architectuurraad zijn: o Het verstrekken van architectuuropdrachten; o Het formeel goedkeuren van architectuurproducten; o Het fungeren als escalatieplatform bij inhoudelijke conflicten. Op het moment dat een projectarchitect en/of een controlling architect constateert dat de verandering die een project aan het doorvoeren is, niet strookt met de langere termijn of niet goed aan dreigt te sluiten bij andere veranderingen (anders gezegd: niet in overeenstemming is met de architectuur), moet hij dat signaleren. Hij initieert een exception. Allereerst doet hij dat aan de ontwerper om samen met deze tot een oplossing hiervan te komen. Lukt dat niet dan zal hij escaleren naar de projectleider. Ook escaleert hij binnen de architectuurfunctie naar de Lead Architect. Deze bespreekt het issue met de projectleider en de opdrachtgever. 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. Binnen de architectuurraad wordt, vanuit het bredere perspectief, besloten of de afwijking wordt toegestaan of niet en zo ja of dat dan een permanente toestemming of een tijdelijke toestemming is. Samen met de stuurgroep van het project wordt besproken wat de consequenties zijn wanneer de afwijking op de architectuur niet wordt toegestaan. Tevens wordt bekeken waar beide boards (architectuurraad en stuurgroep) elkaar kunnen vinden. Het project gaat verder met de uitkomst van het besluit dat uit deze discussie voort komt. Indien de afwijking is toegestaan kan het project zoals gepland doorgaan. Indien de uitkomst van de discussie is dat de afwijking van de architectuur niet door kan gaan, moet er naar alternatieven gezocht worden. Dit zal de uiteindelijke oplossing doen veranderen. Tevens zal het uitzoeken van het alternatief tijd en inspanning vergen, wat kan betekenen dat het project- of faseplan aangepast moet worden. Vanuit architectuuroogpunt kan een besluit van de architectuurraad en de stuurgroep ertoe leiden dat de Referentie Architectuur aangepast moet worden. Dit valt buiten de scope van deze white paper. 11