Wat is Just Enough Architectuur?

Wat is “Just Enough” Architectuur? Scope en diepgang voor Project Start Architecturen Thesis – Pro Education Master in Management en ICT

Versie: Datum: Status: Auteur:

1.00 1 oktober 2010 Definitief Jacob Boer [email protected]

Just Enough Architecture

Inhoudsopgave Inhoudsopgave ................................................................................................................................. 2 Lijst met afbeeldingen ....................................................................................................................... 3 Lijst met tabellen ............................................................................................................................... 3 Voorwoord ........................................................................................................................................ 4 Management Samenvatting .............................................................................................................. 5 1 Onderzoeksopzet ........................................................................................................................ 6 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

2

Architectuur, scope en diepgang en bruikbaarheid in de literatuur ............................................ 14 2.1 2.2 2.3 2.4 2.5 2.6 2.7

3

Veranderen en onderzoek doen: Action Research .......................................................................................... 22 Praktische en wetenschappelijke relevantie: Grounded Action Research ....................................................... 23 Issues met Action Research in de eigen organisatie ....................................................................................... 24 Het object van zelfstudie ................................................................................................................................. 25 Dataverzameling ............................................................................................................................................. 26 Samenvatting methodologie ............................................................................................................................ 26

Praktijk en resultaten ................................................................................................................ 28 4.1 4.2 4.3 4.4

5

Werken onder architectuur .............................................................................................................................. 14 Enterprise Architectuur, Domein Architectuur en Project Start Architectuur .................................................... 15 De rol van de Project Start Architectuur .......................................................................................................... 16 Dimensies van scope en diepgang .................................................................................................................. 17 Bepalende factoren voor scope en diepgang .................................................................................................. 18 Bruikbaarheid .................................................................................................................................................. 20 Conclusies en vervolgvragen .......................................................................................................................... 20

Onderzoeksmethodologie ......................................................................................................... 22 3.1 3.2 3.3 3.4 3.5 3.6

4

Het afslagbord komt voor de afslag ................................................................................................................... 6 Doel van het onderzoek..................................................................................................................................... 7 Centrale vraagstelling ........................................................................................................................................ 8 Onderzoeksvragen ............................................................................................................................................ 8 Theoretisch model ............................................................................................................................................. 9 Definities............................................................................................................................................................ 9 Research strategie: Action Research .............................................................................................................. 11 Afbakening en verantwoording keuzes ............................................................................................................ 11 Structuur van dit document.............................................................................................................................. 12

Diagnosing: Bepalende factoren voor scope en diepgang in de praktijk ......................................................... 28 Planning Action: Naar een concept werkwijze ................................................................................................. 31 Taking Action: De werkwijze toegepast in de praktijk ...................................................................................... 33 Evaluating Action: De werkwijze geëvalueerd ................................................................................................. 34

Conclusies en aanbevelingen ................................................................................................... 38 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Bepalende factoren voor scope en diepgang .................................................................................................. 38 Een werkwijze om de agenda te bepalen ........................................................................................................ 38 Bruikbaarheid .................................................................................................................................................. 39 Over architectuur: Bottom Up Architectuur ...................................................................................................... 40 Methode van Onderzoek ................................................................................................................................. 40 Aanbevelingen m.b.t. de inbedding van de werkwijze in de organisatie .......................................................... 40 Aanbevelingen voor verder onderzoek ............................................................................................................ 40

6

Reflectie op het onderzoek ....................................................................................................... 41

7 8

Literatuur .................................................................................................................................. 44 Bijlagen & Digitale Audit Trail .................................................................................................... 46

Reflectie op de bruikbaarheid van buiten de onderzochte organisatie ..................................................................... 43

Pagina 2 van 65

Just Enough Architecture Bijlage 1. Bijlage 2. Bijlage 3. Bijlage 4. Bijlage 5. Bijlage 6. Bijlage 7. Bijlage 8.

Audit Trail .................................................................................................................... 47 Bronnen Allianz / Architectuur artefacten ..................................................................... 48 Begrippen en afkortingen ............................................................................................. 49 Projecten ..................................................................................................................... 50 Van interviews naar checklist: Coding Tables .............................................................. 51 Concept werkwijze - Stappenplan ................................................................................ 55 Concept Werkwijze - Checklist .................................................................................... 56 Taking Action – Project Affinity Portal .......................................................................... 57

Aandachtspuntentabel ............................................................................................................................................. 57 Issue-Matrix ............................................................................................................................................................. 58 Aandachtspunten in DYA raamwerk ........................................................................................................................ 58

Bijlage 9. Taking Action - Architectuuraandachtspunten.............................................................. 59 Bijlage 10. Vragenlijsten Bruikbaarheid ......................................................................................... 60 Evaluatie bruikhaarheid Werkwijze Scope en Diepgang PSA (gesloten vragen) ..................................................... 60 Evaluatie bruikhaarheid Werkwijze Scope en Diepgang PSA (open vragen) .......................................................... 60

Bijlage 11. Resultaten Evaluating Action ....................................................................................... 61 Resultaten gesloten vragen enquête bruikbaarheid ................................................................................................. 61 Resulaten open vragen enquête bruikbaarheid ....................................................................................................... 62 Evaluatie werkwijze – ruwe data enquête en gesprekken........................................................................................ 63

Bijlage 12. Digitale bijlage: CD-Rom ............................................................................................. 65

Lijst met afbeeldingen Figuur 1: Centrale vraagstelling .............................................................................................. 8 Figuur 2: Theoretisch model ................................................................................................... 9 Figuur 3: Action Research cyclus .......................................................................................... 11 Figuur 4: Feedback volgens Foorthuis .................................................................................. 15 Figuur 5: Bottom Up Architectuur gebaseerd op Foorthuis .................................................... 16 Figuur 6: DYA Raamwerk .................................................................................................... 18 Figuur 7: Issue-Matrix - Impact en waarschijnlijkheid, gebaseerd op TOGAF ...................... 19 Figuur 8: Action Research Cycle en Learning Cycle ............................................................. 23 Figuur 9: Focus van researcher en systeem volgens Coghlan ............................................. 25

Lijst met tabellen Tabel 1: Abstractieniveaus Architectuur ................................................................................ 10 Tabel 2: Projecten en aandachtsgebieden ............................................................................ 12 Tabel 3: Activiteiten per fase ................................................................................................. 23 Tabel 4: Methoden van dataverzameling .............................................................................. 26 Tabel 5: Bepalende factoren scope en diepgang .................................................................. 29 Tabel 6: Werkwijze bepalen scope en diepgang ................................................................... 32 Tabel 7: Bijzonderheden projecten........................................................................................ 33 Tabel 8: Projecten en architecten.......................................................................................... 50 Tabel 9: Project Affinity Portal - Aandachtspuntentabel......................................................... 57 Tabel 10: Project Affinity Portal - Issue-Matrix....................................................................... 58 Tabel 11: Project Affinity Portal - Aandachtspunten in DYA raamwerk .................................. 58 Tabel 12: Aandachtspunten per project ................................................................................ 59 Tabel 13: Aandachtspunten per DYA rij en uitwerkcategorie................................................. 59 Tabel 14: Aandachtspunten in het DYA raamwerk ................................................................ 59 Tabel 15: Uitwerkcategorieen per DYA domein..................................................................... 59 Tabel 16: Resultaten gesloten vragen bruikbaarheid ............................................................ 61 Tabel 17: Resultaten open vragen enquête bruikbaarheid .................................................... 62 Tabel 18: Ruwe data evaluatie en enquête ........................................................................... 64

Pagina 3 van 65


Voorwoord Dit onderzoek vormt de afsluiting van een periode van drie jaar waarin ik aan de Master in Management en ICT van Pro Education heb deelgenomen. Doordat de inhoud van de studie dicht op mijn werkzaamheden in de ICT lag, heb ik in alle fases van de studie het geleerde in de praktijk kunnen toepassen. Dit onderzoek is daar geen uitzondering op. Als verantwoordelijke voor het architectuurproces had ik de kans theorieën en ideeën over Architectuur in een actieonderzoek in de praktijk te toetsen en daarmee een bijdrage te leveren aan het verbeteren van dat architectuurproces. Een belangrijk deel van het plezier in dit onderzoeksproject komt voort uit de samenwerking met de architecten. Zij hebben ideeën geleverd, hebben gediscussieerd, hebben de ideeën toegepast en daarvan verslag gedaan. Ze zijn kritisch geweest en hebben veel tijd geïnvesteerd in “mijn” afstudeeronderzoek. Ze hebben al tijdens het onderzoek laten zien dat het de moeite loont te reflecteren op de eigen werkpraktijk, door de nieuwe inzichten toe te passen. Graag wil ik Albert, Chris, Hans en Rob bedanken voor hun inzet en positieve bijdragen. De inhoudelijke reacties van Gerrit Jan, Johan en Martin hebben me geholpen het onderzoek goed af te bakenen en hun belangstelling heeft me mede in beweging gehouden. Jelle heeft met kritische correctierondes bijgedragen aan de leesbaarheid van dit onderzoek. Inhoudelijk heeft het onderzoek veel voldoening gebracht, logistiek heeft het voor de nodige uitdagingen gezorgd. De balans tussen een uitdagende studie, een veeleisende baan en een geweldig gezin was de laatste maanden verstoord. Mijn kinderen Jelle, Lotte en Niels en mijn partner Olga hebben heel wat te verduren gehad. Vanaf nu komen ze weer op de eerste plaats. Jacob Boer September 2010

Pagina 4 van 65


Management Samenvatting Architectuur geeft richting aan de ontwikkelingen binnen een organisatie en moet die richting op tijd aangeven. Een Project Start Architectuur (PSA) is daarbij een hulpmiddel om die richting mee te geven aan een startend project. In een organisatie waar de Architectuur nog niet algemeen is uitgewerkt, is het voor de architecten vaak problematisch om op tijd te achterhalen wat de juiste vragen zijn en op welk moment en met welke diepgang die beantwoord moeten worden. In dit onderzoek wordt, in aanvulling op begrippen uit de Architectuurliteratuur, in de praktijk onderzocht welke factoren een rol spelen bij het bepalen van scope en diepgang. Vervolgens wordt een werkwijze beschreven waarmee bij aanvang van de werkzaamheden de aandachtspunten geïnventariseerd worden en vertaald worden in prioriteiten voor het project. Uit het onderzoek komt naar voren dat de beschreven werkwijze de architecten helpt witte vlekken in kaart te brengen en op basis daarvan prioriteiten en diepgang inzichtelijk helpt te maken en te presenteren in de vorm van een Issue-Matrix. Hierdoor wordt het mogelijk met het projectmanagement een onderbouwde dialoog te voeren over de architectuurprioriteiten en de bijbehorende planning en resources. Voor de onderzochte organisatie treedt een onverwacht maar welkom effect op. Toepassing van de werkwijze helpt de architecten hun blikveld te verbreden van de Informatie Architectuur, waar hun oorsprong ligt, naar de Business Architectuur en de Technische Architectuur. Een belangrijke aanbeveling voor de onderzochte organisatie is om structureel, in de besluitvormingsfase tijd en capaciteit in te plannen om voor de feitelijke start van projecten de beschreven werkwijze toe te passen. Op die manier kan de PSA op tijd de richting aangeven voor de belangrijkste Architectuurvraagstukken. Het verdient nader onderzoek om te bepalen hoe vanuit de Project Start Architecturen als het ware Bottom Up een Enterprise Architectuur en Domein Architecturen opgebouwd kunnen worden.

Pagina 5 van 65


1

Onderzoeksopzet

1.1 Het afslagbord komt voor de afslag Wanneer een organisatie niet “Just in Time, Just Enough” architectuurdiensten kan leveren, ontstaan er problemen. Op de snelweg van de vooruitgang razen de projecten de afslag voorbij zonder dat ze ooit een afslagbord te zien krijgen met de gewenste bestemmingen. Gedreven door de projectplanning kiezen ze dan voor oplossingen die bij het project passen en die niet per definitie bij de Architectuur van de organisatie op de lange termijn passen. Of projecten kiezen oplossingen waarop ze later moeten terugkomen. Een voorbeeld daarvan is te vinden in Kader 1. Een snel veranderende wereld vraagt om bedrijven die zich snel aan kunnen passen. Het onder Architectuur ontwikkelen van bedrijfsprocessen en informatiesystemen kan daar aan bijdragen (Schekkerman 1999; Rijsenbrij, Schekkerman e.a. 2004; Lankhorst 2005; Foorthuis en Brinkkemper 2007). Voor de architectuurmethode DYA is snelheid zelfs één van de uitgangspunten (Wagter, van den Berg e.a. 2001). Maar het denken over Architectuur kost tijd. Wanneer er al veel is uitgewerkt van de architectuurdomeinen en wanneer er uit de uitgewerkte Enterprise Architectuur, Domein Architectuur of Referentiearchitecturen kan worden geput, dan is het op tijd aangeven van de richting door de architecten geen probleem. Dat is de manier waarop methodes als DYA (Dynamische Architectuur) en TOGAF (The Open Group Architecture Framework) werken: vanuit het kader van een Enterprise Architectuur naar een op de specifieke oplossing gerichte Architectuur (Rijsenbrij, Schekkerman e.a. 2004; van den Berg, Blom e.a. 2009). Indien organisaties minder volwassen zijn in het omgaan met Architectuur of indien architectuurdiensten worden gevraagd op domeinen die nog sterk in ontwikkeling zijn, dan is het niet eenvoudig voor de architecten om de leversnelheid af te stemmen op de snelheid waarmee architectuurdiensten nodig zijn. Ook in de organisatie waar dit onderzoek zich afspeelt lopen de projecten voor op wat er vanuit de architectuurdomeinen ontwikkeld wordt. De projecten nemen al architectuurdiensten af en hebben daarbij haast: het bedrijf wil verder. Niet alleen ontbreekt het in deze organisatie aan een uitgekristalliseerde Enterprise Architectuur, ook is het werken onder Architectuur nieuw voor de organisatie. Project Start Architectuur in het Front End project: Afslag gemist In de eerste fase van het Front End project is een algemene, publieke website gerealiseerd. Een website die voor iedereen toegankelijk is en gericht is op het overbrengen van algemene informatie over de organisatie en haar producten en diensten. Hiervoor is in een Project Start Architectuur (PSA) beschreven welke componenten daarvoor nodig waren en wat daarvan de samenhang was. De in de PSA beschreven Architectuur is geïmplementeerd in de vorm van servers, content management systeem en andere zaken. In de volgende fase werd duidelijk dat er ook een afgesloten gedeelte op de website moest komen. Daarin kunnen klanten inloggen en specifiek op hen afgestemde informatie krijgen. Bij het opstellen van de PSA voor deze tweede fase, bleek de in de eerste fase gerealiseerde “architectuur” niet geschikt om deze nieuwe mogelijkheden te ondersteunen. Er was een andere inrichting nodig van servers en content management systeem. Een deel van de inrichting van de eerste fase moest opnieuw en anders worden uitgevoerd. Dit bracht extra kosten en tijdverlies met zich mee. Wanneer bij het opstellen van de eerste PSA de tijd was genomen om voldoende ver vooruit te kijken, dan hadden deze extra kosten en dit tijdverlies voorkomen kunnen worden. Kader 1: Voorbeeld Project Start Architectuur Front End project

Pagina 6 van 65

Just Enough Architecture De architecten in de onderzochte organisatie worstelen met de vraag: “Wat is op dit moment de goede breedte en diepgang voor het architectuurproduct dat ik aan het opstellen ben?”. Ze baseren zich daarbij voornamelijk op hun eigen ervaring en die van de collega’s met wie ze over hun producten van gedachten wisselen. Een vaste werkwijze of checklist hanteren ze daarbij niet. Een te ruime scope of teveel diepgang van de architectuurproducten leidt tot verwarrende documenten, papieren tijgers, overschrijding van het budget, vertraging in het project en onnodige inperking van de vrijheden van de ontwerpers en ontwikkelaars in het vervolgtraject. Onvolledigheid of een gebrek aan diepgang echter, leidt tot producten die van beperkt nut zijn. Ook leidt voortschrijdend inzicht1 tot ongewenste aanpassingen van recent geïmplementeerde oplossingen (Wagter, van den Berg e.a. 2001) (TheOpenGroup 2009) (van den Berg en van Steenbergen 2004). Een architectuurdienst waarbij Architectuur en projecten samenkomen is het opstellen van de Project Start Architectuur (PSA) bij aanvang van een project. Een PSA geeft volgens Foorthuis (2007) op basis van de Enterprise Architectuur en Domein Architectuur de beperkingen en de richting voor de verdere uitwerking van een project. Juist in situaties waarin er nog weinig af te leiden valt uit Enterprise Architectuur en Domein Architectuur moeten de architecten er hier precies op tijd bij zijn om het project de juiste richting op te sturen. Er ontbreekt in de geraadpleegde architectuurmethoden een pragmatische werkwijze, om bij aanvang van een architectuurvraagstuk, op systematische wijze te bepalen wat de scope en diepgang moeten zijn van het op te leveren product. Dit onderzoek richt zich dan ook op het ontwikkelen van een dergelijk werkwijze voor architecten, een werkwijze om tot een “Just Enough, Just in Time” Project Start Architectuur te komen. Het onderzoek spitst zich toe op de situatie waarbij nog geen uitontwikkelde Enterprise Architectuur of Domein Architectuur beschikbaar is en waarbij de architectuurdiscipline nog in de kinderschoenen staat. 1.2 Doel van het onderzoek Het onderzoek heeft als doel door literatuuronderzoek en door actieonderzoek in de praktijk bij Allianz een werkwijze te ontwikkelen, die architecten behulpzaam is bij het bepalen van de scope en diepgang van hun dienstverlening en die daarbij behulpzaam is bij het vaststellen van de prioriteiten. Anders geformuleerd is het doel een werkwijze te ontwikkelen, die bij het werken aan een PSA kan worden toegepast om specifiek te maken wat voor deze PSA “Just Enough, Just in Time” is. Deze werkwijze zou binnen de onderzochte organisatie, maar ook voor andere IT organisaties bruikbaar moeten zijn en een praktische aanvulling kunnen bieden op de Architectuur Body of Knowledge en methodes als DYA en TOGAF. Aangezien de Enterprise Architectuur en Domein Architecturen van de organisatie waar het onderzoek uitgevoerd wordt, nog in de kinderschoenen staan, zal de werkwijze vooral bruikbaar zijn voor organisaties die hun Architectuur nog aan het ontwikkelen zijn. De veronderstelling achter het onderzoek is dat de veranderdruk vanuit de organisatie steeds dusdanig groot is en de voor Architectuur beschikbare capaciteit dusdanig klein is, dat er altijd een gebrek aan tijd en middelen is en dat dit de noodzaak schept voor “Just Enough, Just in Time Architecture”.

1

In de onderzochte organisatie wordt het begrip “voortschrijdend inzicht” vaak gebruikt als eufemisme voor een gebrek aan een gedegen voortraject. Pagina 7 van 65


1.3 Centrale vraagstelling Architectuurmethodes als DYA en TOGAF streven naar “Just Enough” Architecture (Schekkerman 1999; Wagter, van den Berg e.a. 2001; Rijsenbrij, Schekkerman e.a. 2004; van den Berg en van Steenbergen 2004; TheOpenGroup 2009). Een werkwijze die daarbij voorgesteld wordt, is: “Think big, start small” (Schekkerman 1999). Maar hoe krijgen deze begrippen handen en voeten, in organisaties waar het werken onder Architectuur nog in de kinderschoenen staat en waar Enterprise Architectuur en Domein Architectuur alleen in een paar eerste schetsen zijn vastgelegd? Welke factoren zijn bepalend voor de benodigde scope en diepgang van een Project Start Architectuur, hoe kunnen deze factoren uitgewerkt worden in een werkwijze om de agenda van de architecten vast te stellen en wat is in de praktijk daarvan de bruikbaarheid? Figuur 1: Centrale vraagstelling

1.4 Onderzoeksvragen Om tot een bruikbare werkwijze te komen moet een aantal vragen beantwoord worden.  Over werken onder Architectuur en werken met Project Start Architectuur: o Waarom werken onder architectuur? o Welke werkwijze hanteert men bij de onderzochte organisatie met betrekking tot architectuur? o Wat is de rol van de Project Start Architectuur? o Wat is de samenhang tussen de Enterprise Architectuur, de Domein Architectuur en de Project Start Architectuur en wat betekent het voor het opstellen van een PSA wanneer de eerste twee nog niet zijn uitgewerkt? Deze vragen worden zowel vanuit theoretische perspectief als vanuit de onderzochte praktijk beantwoord.  Over scope en diepgang: o Wat is er in de theorieën over Architectuur te vinden over het bepalen van diepgang en breedte van architectuurproducten. o Welke dimensies van scope en diepgang zijn er te onderkennen vanuit de literatuur? o Welke factoren geven in de praktijk aan hoe diepgaand een issue uitgewerkt moet worden?  Over de werkwijze: o Welke elementen dragen bij aan een bruikbare werkwijze? o Op welke wijze kunnen de bepalende factoren rondom scope en diepgang in beeld gebracht worden? o Welke processtappen kunnen bijdragen aan het herkennen van witte vlekken? o Hoe kan de werkwijze helpen bij het bepalen van de Architectuur agenda?  Over bruikbaarheid o Wat maakt een werkwijze tot een bruikbare werkwijze? o Welke conclusies kunnen we uit het onderzoek trekken over bruikbaarheid binnen de onderzochte organisatie?  Over de methode van onderzoek: o Welke methode van onderzoek past er bij de vraagstelling? o Hoe kan deze methode van onderzoek in de context van de onderzochte organisatie worden toegepast? o Welke wijze van dataverzameling wordt er op welke momenten toegepast? o Hoe wordt in het onderzoek zowel de wetenschappelijke als praktische relevantie gewaarborgd?  Welke conclusies & aanbevelingen kunnen er aan het onderzoek worden verbonden? Deze vragen vormen het uitgangspunt van dit onderzoek. Pagina 8 van 65


Theoretisch model Voor de theoretische onderbouwing van het architectuurproces is een beroep Conclusies gedaan op DYA. Deze methode wordt Aanbevelingen bij de onderzochte organisatie in de Diagnose praktijk gehanteerd en laat zich Onderzoek werkwijze kenschetsen als een pragmatische en organisatie architectuurmethode (van den Berg, Evaluate Action Plan Action Blom e.a. 2009). Ook is er uit de Architecture Evalueren Uitwerken aanpak en concept werkwijze concept werkwijze Development Method van TOGAF (TOGAF 2009) geput om aanvullende Take Action methodische onderbouwing te vinden. Toepassen TOGAF is een wijd verspreide methode, concept werkwijze die dankzij haar systematisch opgezette procesmethode zeer geschikt is voor gebruik in een omgeving waar architecten van buiten en ook minder ervaren architecten van binnen de Figuur 2: Theoretisch model organisatie gestructureerd mee kunnen samenwerken (van den Berg, Blom e.a. 2009). Op basis van architectuurmethodes DYA en TOGAF en op basis van ervaring in de praktijk van de onderzochte organisatie, is in een Action Research cyclus een concept werkwijze ontwikkeld. Deze werkwijze stelt de architecten in staat om vast te stellen wat de vereiste scope en diepgang voor een PSA zijn. De concept werkwijze is vervolgens in een aantal projecten toegepast en geëvalueerd volgens de principes van de Action Research. De evaluatie van de toepassing in de praktijk heeft geleid tot conclusies en vragen voor verder onderzoek. 1.5

Project 4

Project 3

Project 2

Project 1

Praktijk Allianz

TOGAF

DYA

1.6 Definities Architectuur In dit onderzoek wordt het begrip Architectuur gebruikt voor “Business en ICT architectuur”. Architectuur wordt in navolging van Wagter en van den Berg (2001) gedefinieerd als “een consistent geheel van modellen en principes, dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie”. Uit deze definitie komt naar voren dat Architectuur richting geeft en zowel om de architectuurproducten gaat als om het proces waarmee ze tot stand komen. Enterprise Architectuur, Domein Architectuur en Project Start Architectuur Architectuur wordt op verschillende niveaus beschreven. Een veelgemaakt onderscheid daarbij is dat tussen Enterprise Architectuur, Domein Architectuur en Project Start Architectuur. o Een Enterprise Architectuur (EA) beschrijft de uitgangspunten voor de inrichting van de gehele onderneming op het overkoepelende niveau van de gehele organisatie en beschouwt daarbij structuur, bedrijfsprocessen, informatiesystemen en infrastructuur. De Enterprise Architectuur focust zich op de essentie van de onderneming en is daardoor relatief stabiel (van den Berg en van Steenbergen 2004; Lankhorst 2005). o Een Domein Architectuur (DA) wordt gedefinieerd op basis van een specifieke groep van producten, diensten, processen of functies. Een domein kan de organisatie als geheel doorsnijden, zoals het “Outputmanagement” domein in de organisatie van dit onderzoek, maar kan zich ook richten op een specifiek product of proces. Het begrip domein kent vele verschijningsvormen. In dit onderzoek wordt het begrip “Domein” gebruikt voor een technologisch aandachtsgebied, bijvoorbeeld “Portals”. Ook wordt het begrip “Domein” gebruikt voor de indelingen in domeinen die DYA en TOGAF hanteren. Dat zijn Business, Informatie en Techniek voor DYA en voor TOGAF zijn het Pagina 9 van 65


o

Business, Data, Applications en Technology (van den Berg en van Steenbergen 2004; Foorthuis en Brinkkemper 2007; TheOpenGroup 2009). De Project Start Architectuur (PSA) is de vertaling van de Enterprise Architectuur en Domein Architectuur naar de specifieke projectsituatie. Uit de EA en de DA zijn de principes, beleidslijnen en modellen af te leiden die nader uitgewerkt worden en bij aanvang van een project meegegeven worden in de vorm van een Project Start Architectuur. Dit zijn de richtlijnen die ontwerpers en ontwikkelaars richting geven bij het realiseren van hun project, zodat het in het grotere geheel past (Wagter, van den Berg e.a. 2001; van den Berg en van Steenbergen 2004; Foorthuis en Brinkkemper 2007).

Hoewel TOGAF andere begrippen hanteert komen dezelfde abstractieniveaus erin terug. In navolging van de onderzochte organisatie hanteren we in dit onderzoek de begrippen van DYA. Niveau

Dit onderzoek

TOGAF

Strategisch

Enterprise Architectuur Strategic Architecture

Tactisch

Domein Architectuur

Domain Architecture

Operationeel

Project Start Architectuur

Solution Architecture

Tabel 1: Abstractieniveaus Architectuur

Pagina 10 van 65


1.7 Research strategie: Action Research Het doel van het onderzoek is een bijdrage te leveren aan de praktijk van het werken met Architectuur bij Allianz en aan het ontwikkelen van de Body of Knowledge rondom Enterprise Architectuur. Het onderzoek wordt uitgevoerd in een bestaand architectuurproces, waarbij de actoren in dat proces nieuwe kennis en ervaring opdoen om het bepalen van scope en diepgang meer structuur te geven. Deze combinatie van probleemoplossing en genereren van nieuwe kennis vormt bij uitstek het domein van de Action Research (Coghlan 2001; Robson 2002; Eriksson en Kovalainen 2008) waarbij de onderzoeker optreedt naar analogie van de acteur-regisseur bij films (Coghlan 2001). Conclusies Aanbevelingen

Diagnose Onderzoek werkwijze en organisatie

Evaluate Action

Plan Action

Evalueren concept werkwijze

Uitwerken aanpak en concept werkwijze

Take Action

Action Research (Figuur 3: Action Research cyclus) speelt zich af in een iteratief proces, van diagnosticeren, plannen en doen en evalueren rondom veranderingen in een organisatie. Deze Action Research cyclus wordt gedurende dit onderzoek één keer doorlopen.

Toepassen concept werkwijze

In deze cyclus wordt onderzocht hoe de organisatie omgaat met Figuur 3: Action Research cyclus het bepalen van scope en diepgang in Architectuur trajecten. Vervolgens wordt een werkwijze ontwikkeld, toegepast en geëvalueerd, waarna conclusies en aanbeveling voor nader onderzoek worden opgesteld. Het onderzoek is gestart in maart 2010 met literatuuronderzoek en de inbedding van het onderzoek in de organisatie en afgerond in september 2010 met de conclusies en aanbevelingen. 1.8 Afbakening en verantwoording keuzes Architectuurmethodes: DYA en TOGAF Het ontbreekt in dit onderzoek aan tijd om alle beschikbare architectuurmethoden door te lichten. Om pragmatische redenen is het onderzoek beperkt tot TOGAF en DYA. Bij DYA ligt de nadruk op het proces van werken onder Architectuur en het realiseren van business doelen. TOGAF is een industriebrede open standaard, die sterk gericht is op het ontwerpen en implementeren van Architectuur (van den Berg, Blom e.a. 2009). In de organisatie waar dit onderzoek wordt uitgevoerd is DYA in gebruik, bij de moedermaatschappij TOGAF. Allianz als onderzochte organisatie Het Action Research project richt zich volledig op Allianz Nederland en de Architectuur processen in die organisatie. Het ontbreekt aan tijd om ook onderzoek te doen in andere organisaties. Om de bredere relevantie van het onderzoek zeker te stellen, is er op verschillende momenten een tweetal externe deskundigen betrokken. Architectuurdienst: Opstellen PSA Het onderzoek beperkt zich tot het proces rondom het opstellen van Project Start Architecturen. Dit is de activiteit waar de Allianz architecten nu volop mee bezig zijn en waar deze architecten herhaaldelijk tegen de problematiek aanlopen van het bepalen van scope en diepgang. De problematiek speelt uiteraard ook bij het opstellen van een Enterprise Architectuur of Domein Architectuur, maar in de periode van het onderzoek ontwikkelen de Enterprise Architectuur en Domein Architectuur zich vooral als de optelsom van de Project Pagina 11 van 65

Just Enough Architecture Start Architecturen. Het ontwikkelen van Enterprise Architectuur en Domein Architectuur vanuit de PSA is een gangbare werkwijze (Foorthuis en Brinkkemper 2007) en deze aanpak draagt bij aan het draagvlak voor Architectuur bij de business (Hendriks en Oosterhaven 2009). Architectuur: wel proces, niet de inhoud Het onderzoek beperkt zich tot het proces rondom het opstellen van architectuurproducten en het leveren van architectuurdiensten. De technisch/inhoudelijke kant van de Architectuur issues, met vragen als “wat is de beste portal tooling, welke programmeertaal moeten we gaan hanteren?” wordt in dit onderzoek buiten beschouwing gelaten. Eén Action Research cyclus, over meerdere Architectuur Domeinen Een thesis onderzoek wordt mede afgebakend door wat haalbaar is binnen de beperkingen die daaraan gesteld worden op gebied van tijd, geld en toegankelijkheid (Morsink 1993; Coghlan 2001). Voor dit onderzoek is tijd de beperkende factor. Het onderzoek moest in september afgerond zijn, vanwege de door de opleidingsinstelling vereiste mijlpalen. Door deze beperking in tijd, is slechts één Action Research cyclus uitgevoerd. Wel is in deze cyclus de totstandkoming van meerdere Project Start Architecturen onderzocht, op verschillende domeinen, afhankelijk van de startende projecten in de onderzochte organisatie. Alle projecten waarvoor in de onderzoeksperiode gewerkt is aan een PSA, zijn betrokken in het onderzoek. Ook zijn alle vier de architecten betrokken, zie Tabel 2: Projecten en aandachtsgebieden. De projecten zijn geselecteerd, omdat ze op het juiste moment in het onderzoek “actueel” waren. Door de keuze om de projecten samen in één Action Research cyclus te onderzoeken is er geen mogelijkheid geweest om de leerervaringen van het ene project tijdens het onderzoek te vertalen in acties voor het andere, volgende project. Deze keuze was noodzakelijk omdat het vertragen van projecten voor onderzoeksdoeleinden niet aan de orde was. Project Belangrijkst domein Affinity Portal

Portals & Security

CRM/BRM Plateau 2

Datawarehouse

Datawarehouse Schade (DANS)

Datawarehouse

Debiteurensysteem

Transactieloket

Nieuw Leven

Alle

Optimalisatie Processen Schade direct

Outputmanagement

Tabel 2: Projecten en aandachtsgebieden

1.9 Structuur van dit document Deze thesis bestaat uit 6 hoofdstukken en een aantal bijlagen. In hoofdstuk 1 wordt de inleiding beschreven over het onderwerp van het onderzoek. De aanleiding voor het onderzoek is hierin weergegeven evenals de doelstelling, de probleemstelling en de afbakening van het onderzoek. In hoofdstuk 2 wordt een overzicht gepresenteerd van de stand van zaken in de literatuur over Architectuur. Daarbij komt een aantal onderwerpen aan de orde. Dit betreft de rol van de Project Start Architectuur in het architectuurproces, de verschillende aspecten van scope en diepgang, de factoren die van invloed zijn op de benodigde scope en diepgang evenals aanknopingspunten in het proces om scope en diepgang vast te stellen. Ook wordt in dit hoofdstuk toegelicht hoe “bruikbaarheid van de werkwijze” in het kader van dit onderzoek wordt gedefinieerd. Hoofdstuk 3 beschrijft vervolgens de methodologie van het onderzoek. Dit hoofdstuk gaat nader in op het theoretisch en het empirisch onderzoekskader. Het beschrijft de manier Pagina 12 van 65

Just Enough Architecture waarop het actie onderzoek is vormgegeven, de keuzes die daarbij gemaakt zijn en de methoden en analyses die gebruikt zijn om van de diagnose tot een toegepaste en geëvalueerde werkwijze te komen. In hoofdstuk 4 wordt voor elk van de vier Action Research fasen (Diagnosing, Planning Action, Taking Action, Evaluating Action) beschreven hoe het onderzoek zich in de praktijk heeft afgespeeld, wat de rol van de theoretische concepten daarbij is en wat de uitkomsten van die fase zijn en hoe zich dat vertaalt in de volgende fase van het onderzoek.  Diagnosing In het eerste deel van hoofdstuk 4 wordt beschreven hoe in de praktijk van Allianz met Architectuur en met Project Start Architectuur wordt omgegaan en hoe de architecten bij aanvang van het onderzoek omgaan met het bepalen van scope en diepgang en welke concepten ze daar zelf bij hanteren.  Planning Action In het deel over de Planning Action fase wordt beschreven hoe de architecten in dit onderzoek zijn gekomen tot een indeling in factoren die een rol spelen bij het bepalen van scope en diepgang. Ook beschrijft dit hoofdstuk welke aanknopingspunten in het architectuurproces de architecten onderkennen om op een zorgvuldige manier te bepalen wat de scope en diepgang van een PSA moeten zijn. Aansluitend wordt beschreven hoe deze aspecten met de aspecten uit de architectuurliteratuur samenkomen in een werkwijze die in de Taking Action fase wordt toegepast.  Taking Action In Taking Action wordt uiteengezet hoe de werkwijze in een aantal projecten in de praktijk is toegepast en welke leereffecten daarbij zijn opgetreden.  Evaluating Action Het laatste deel van hoofdstuk 4 is gewijd aan de evaluatie van de Taking Action fase. Hierin worden de ervaringen van de architecten met het toepassen van de werkwijze geanalyseerd en wordt nagegaan wat de bruikbaarheid van de werkwijze voor de praktijk van de onderzochte organisatie is. In hoofdstuk 5, de conclusie, worden de onderzoeksvragen beantwoord en worden er aanbevelingen voor vervolgonderzoek gegeven. De aanbevelingen komen voort uit de inzichten die het onderzoek heeft opgeleverd en uit de beperkingen van het onderzoek, zoals ze door de thesis heen aan de orde zijn gekomen. In hoofdstuk 6 tenslotte wordt de reflectie van de onderzoeker op het onderwerp en onderzoeksproces beschreven.

Pagina 13 van 65


2

Architectuur, scope en diepgang en bruikbaarheid in de literatuur

In dit hoofdstuk worden de volgende vragen beantwoord:  Waarom is werken onder Architectuur van belang?  Wat is de rol van de Project Start Architectuur?  Wat is de samenhang tussen de Enterprise Architectuur, de Domein Architectuur en de Project Start Architectuur en wat betekent het voor het opstellen van een PSA wanneer de eerste twee nog niet zijn uitgewerkt?  Welke dimensies worden vanuit de literatuur aangedragen ten aanzien van scope en diepgang?  Welke factoren voor het bepalen van scope en diepgang van architectuurproducten worden er in de literatuur gebruikt?  Welke processtappen worden er vanuit de literatuur aangedragen om scope en diepgang van architectuurproducten te bepalen?  Op welke wijze kan de bruikbaarheid van de uit te werken werkwijze worden vastgesteld? De antwoorden op deze vragen worden geplaatst in het kader van hun betekenis voor het ontwikkelen van een werkwijze voor het bepalen van scope en diepgang, bij het opstellen van Project Start Architecturen. 2.1 Werken onder architectuur Architectuur wordt in paragraaf 1.6 Definities gedefinieerd als “een consistent geheel van modellen en principes, dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie”. Voor dit onderzoek is het richtinggeven van belang. Het richtinggeven wordt door verschillende auteurs anders gedefinieerd, maar is een terugkerend aspect. Lankhorst (2005) verwoordt Architectuur als volgt: “Enterprise Architecture captures the essentials of the business, IT and its evolution. The idea is that the essentials are much more stable than the specific solutions for the problems currently at hand”. Ondanks die betrekkelijke stabiliteit verandert de Architectuur als de omgeving, de technologie of nieuwe inzichten in het bedrijf daar aanleiding toe geven. De stabiele essenties van de Architectuur geven de richting voor de vragen van vandaag. TOGAF (TheOpenGroup 2009) geeft aan dat het doel van de Enterprise Architectuur gelegen is in het optimaliseren over de breedte van de organisatie, van een vaak gefragmenteerde erfenis (legacy) van al dan niet geautomatiseerde processen, in de richting van een geïntegreerde omgeving die nauw aansluit bij de business strategie. Een goede architectuur, aldus TOGAF, zorgt voor balans tussen efficiëntie van IT en innovatie van de business. Rijsenbrij, Schekkerman e.a. (2004) geven aan dat Architectuur structuren duidelijk maakt en ondersteuning en regels biedt voor degenen die op basis van de Architectuur systemen bouwen. De Architectuur schrijft voor en geeft richting. Het werken met een Enterprisearchitectuurmethode biedt organisaties structuur en samenhang bij veranderingen, vanuit een breder perspectief dan alleen de huidige IT omgeving. De Architectuur en de methode dienen als sturingselement (Wagter, van den Berg e.a. 2001; van den Berg en van Steenbergen 2004). Daarnaast kan het werken onder Architectuur bijdragen tot flexibiliteit van de onderneming. Deze flexibiliteit komt voort uit een Architectuur gericht op het kunnen inspelen op nieuwe, nu nog niet voorziene ontwikkelingen en uit een architectuurproces dat op een slanke en snelle wijze kan worden ingezet (Wagter, van den Berg e.a. 2001). Betekenis voor het onderzoek De te ontwikkelen werkwijze moet bijdragen aan het doel van het werken onder architectuur: het bieden van structuur, zorgen voor coherentie, het tegengaan van versnippering en het Pagina 14 van 65

Just Enough Architecture vergroten van de verandersnelheid. De werkwijze moet de hele organisatie in de beschouwing betrekken en het resultaat van de werkwijze moet ertoe leiden dat projecten zich aan de Architectuur houden en hun bijdrage leveren aan het opbouwen van de Architectuur (Foorthuis en Brinkkemper 2008). Anders gezegd, als Architectuur richting geeft, dan moet de te ontwikkelen werkwijze zorgen dat de Project Start Architectuur richting geeft. Zoals de ANWB haar paddenstoelen alleen op relevante punten neerzet en daarop verwijst naar relevante bestemmingen, moet de werkwijze ervoor zorgen dat ook in de PSA alleen de relevante zaken aan de orde komen. Precies genoeg wegwijzers en precies genoeg informatie over de bestemming. 2.2 Enterprise Architectuur, Domein Architectuur en Project Start Architectuur Architecturen kunnen beschreven worden op strategisch, tactisch en operationeel niveau (van den Berg en van Steenbergen 2004). In een indeling die we bij meerdere auteurs tegenkomen, wordt dat vertaald in de Enterprise Architectuur, Domein Architectuur en de Project Architectuur of Project Start Architectuur (Wagter, van den Berg e.a. 2001; van den Berg en van Steenbergen 2004; Foorthuis en Brinkkemper 2007; Greefhorst, Rodenhuis e.a. 2009). De Enterprise Architectuur beschrijft de Architectuur op het abstractieniveau van de gehele onderneming (TOGAF hanteert hiervoor het begrip Strategische Architectuur). De Enterprise Architectuur kan vervolgens gedetailleerder worden vastgelegd op het niveau van Domein Architecturen. Dat domein kan een deel van het bedrijf (het verzekeringsbedrijf binnen een financieel conglomeraat) of een proces (bijvoorbeeld Relatiebeheer) of wat in TOGAF een capability wordt genoemd (bijvoorbeeld “digitalisering output”). Het derde niveau is de Project Start Architectuur. Deze Architectuur wordt samengesteld op basis van de Domein en Enterprise Architectuur en levert de principes en modellen voor een te starten project (Foorthuis en Brinkkemper 2007). In paragraaf 2.3 De rol van de Project Start Architectuur wordt dit nader uitgewerkt. DYA en TOGAF werken van strategische Architectuur via het tactische niveau naar de operationele uitwerking. Doordat de methodes ruimte bieden voor iteraties, komen aanpassingen vanuit de Project Start Architectuur, indien nodig ook terug in de Enterprise Architectuur en de Domein Architectuur. Om een Project Start Architectuur of Oplossing Architectuur op te kunnen stellen, wordt er dus zowel bij TOGAF als DYA een Enterprise Architectuur en of Domein Architectuur beschikbaar verondersteld. In de praktijk wanneer een onderneming Figuur 4: Feedback volgens Foorthuis nog maar kort met Architectuur werkt, worden de EA en DA voortdurend aangevuld vanuit de principes en modellen die in het kader van projecten worden uitgewerkt. Deze samenhang tussen Enterprise Architectuur, Domein Architectuur en PSA is in beeld gebracht door Foorthuis (2008) in zijn artikel “Best practices voor projecten onder Enterprise Architectuur”. Foorthuis noemt deze wisselwerking “feedback”. De feedback is weergegeven door de blauwe pijlen in Figuur 4: Feedback volgens Foorthuis.

Pagina 15 van 65

Just Enough Architecture Betekenis voor het onderzoek In de geraadpleegde literatuur wordt de situatie waarbij de Enterprise Architectuur en de Domein Architectuur slechts minimaal beschikbaar zijn en er toch door middel van PSA’s richting wordt gegeven aan projecten, niet nader uitgewerkt. Deze vorm van werken met Architectuur zou omschreven kunnen worden als Bottom Up Architectuur (Figuur 5: Bottom Up). In de beschouwde methoden wordt de Architectuur Top Down uitgewerkt, met ruimte voor feedback vanuit de PSA naar de DA/EA en is het opstellen van een PSA voor een belangrijk deel het samenstellen van een richtinggevend document op basis van bestaand materiaal. Echter juist in een Bottom Up situatie, waarin het opstellen van een PSA veel verder gaat dan het vergaren van bestaande richtlijnen, is het vaststellen van de juiste scope en diepgang voor de PSA zeer relevant. In een Bottom Up situatie is het uitwerken van nieuwe richtlijnen bewerkelijker en herbergt het meer verrassingen, dan het geval is bij een Top Down situatie, waar het aankomt op het vergaren van bestaand materiaal. Naarmate er minder materiaal beschikbaar is, is de bepaling van scope en diepgang zodoende relevanter. De te ontwikkelen werkwijze moet de focus richten op het verduidelijken van die aspecten van de Architectuur waarvoor materiaal slechts beperkt of nog niet beschikbaar is. Aanbeveling Uiteindelijk moet ook in de Bottom Up situatie een Domein en Enterprise Architectuur uitgewerkt worden. Het proces van het opstellen van de EA en DA vanuit de praktijk van de projecten (Bottom Up Architectuur) komt in de geraadpleegde literatuur nauwelijks aan de orde en verdient nader onderzoek. Dat geldt ook voor het specifiekere onderzoek naar de consequenties van onjuiste scope en diepgang in een PSA voor de ontwikkeling van de Enterprise Architectuur en Domein Architectuur. 2.3

De rol van de Project Start Figuur 5: Bottom Up Architectuur gebaseerd Architectuur op Foorthuis In vorige paragrafen werd geconcludeerd dat, om de doelen van de Architectuur te bereiken, het van belang is dat projecten zich aan de richtlijnen van de Architectuur houden. Vervolgens werd duidelijk dat er een gelaagdheid is aan te brengen in de Architectuur en dat methodes als DYA en TOGAF van globaal naar gedetailleerd toewerken. Daarbij wordt ruimte geboden voor wisselwerking of feedback tussen de verschillende architecturen. In deze paragraaf wordt het vergrootglas gelegd op de Project Start Architectuur en wordt duidelijk hoe een Project Start Architectuur ervoor zorgt dat projecten bijdragen aan het realiseren van de Architectuur. Van den Berg en van Steenbergen (2004) geven in hun beschouwing over de architectuurmethode DYA de Project Start Architecturen een heldere plaats: “Ze worden op het moment dat een positieve business case tot een project leidt meegegeven als kader waarbinnen de ontwerpbeslissingen worden genomen.” Het betreft Architectuur op operationeel niveau, de nadruk ligt op de constructie. Over de mate van detaillering blijven ze abstract: “De architecturen geven precies zoveel detail dat een projectleider er voldoende houvast aan heeft om de juiste ontwerpbeslissingen te nemen binnen zijn project”. Wagter, van den Berg e.a. (2001) stellen dat “De PSA is de vertaling van de algemene architectuurprincipes en modellen naar een op het project toegeschreven kader……Ook projectoverstijgende ontwerpkeuzes worden in de Project Start Architectuur vastgelegd.” Een PSA komt volgens deze definiëring tot stand op basis van beschikbaar materiaal. Er is echter ruimte voor een wisselwerking tussen de PSA en de overige architecturen, doordat het ontwikkelen van architecturen op alle niveaus binnen DYA een iteratief proces is.

Pagina 16 van 65

Just Enough Architecture In TOGAF is geen expliciete plaats voor de PSA. De definitie van de Solution Architecture volgens TOGAF komt dicht in de buurt van de PSA: “A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks” (TheOpenGroup 2009). Ook hier gaat het om het vertalen van algemene Architectuur requirements naar specifieke projectrichtlijnen. Foorthuis (2007) geeft de volgende opsomming van de veronderstelde voordelen van het werken met PSA’s:  “Reduced project risk and complexity: a better understanding of the solution context and potential problems before the project starts should reduce project over-runs in both cost and time.  Improved project success: resulting solutions are consistent with the strategic view of the business and of higher quality.  Reduced project costs and improved return on investment: specific projects are aware of the available reusable services and components and can make use of them.  Project initialization: EA models assist in specifying the PSA at the beginning of a project. As such it should remove the need to coordinate extensively with other project teams and help avoid irrelevant discussions and other redundant project activities.  Shorter projects: this is the result of the decisions that are made at the beginning of the project in the PSA. The project team, then, should be able to concentrate its energy on creating the solution. There should be no need to discuss tools or techniques. In addition, reuse of knowledge and components is assured. Finally, it should be known which competencies are needed. This allows for finding compatible people for the project.” Hendriks en Oosterhaven (2009) stellen in “Architectuur moet bijdragen” dat een PSA vooral zinnig is, als het voor de betrokkenen niet helder en eenduidig is wat moet worden gedaan. In een onderzoek naar de relatie tussen projectsucces en het gebruik van PSA’s concludeert De Boer (2009) dat een PSA vooral bijdraagt aan het projectsucces wanneer de tastbaarheid van het project op voorhand niet groot is en wanneer de projectleider een doelgerichte (en niet een structurerende) aanpak kent. Verder concludeert De Boer dat een PSA nuttiger is naarmate meer projectleden hem lezen. Voor de inhoud van de PSA is het van belang te focussen op processen en applicaties en op de zaken die nog niet bekend zijn bij de doelgroep van het document. Betekenis voor het onderzoek De PSA moet richting geven aan het project, zodanig dat het project oplossingen toepast die bijdragen aan het realiseren van de Enterprise Architectuur en de Domein Architectuur. De voordelen daarvan uiten zich in risicobeperking, herbruikbaarheid, kostenbeperking en mogelijk snellere projecten. Bij projecten met een lage tastbaarheid draagt het werken met een PSA meer bij dan bij projecten die al een grote tastbaarheid hebben (de Boer 2009). De te ontwikkelen werkwijze moet ervoor zorgen dat de aandacht bij het opstellen van een PSA gaat naar de minder tastbare zaken en de zaken die voor de doelgroep niet bekend zijn. 2.4 Dimensies van scope en diepgang Dit onderzoek beoogt een werkwijze te ontwikkelen die de architecten kan helpen bij het vaststellen van de vereiste scope en diepgang bij het opstellen van een PSA. In deze paragraaf worden de factoren van scope en diepgang nader uiteengerafeld.

Pagina 17 van 65

Just Enough Architecture Het DYA Raamwerk (Wagter, van den Berg e.a. 2001; van den Berg en van Steenbergen 2004) is één van de manieren om naar scope en diepgang te kijken. De businessdoelen zijn leidend voor de Business Architectuur, Informatie Architectuur en Technische Architectuur. Deze domeinen zijn nog verder op te delen, in de aspecten zoals weergegeven in de kolommen. De indeling in kolommen is een Figuur 6: DYA Raamwerk manier om de scope van de PSA definiëren en te beoordelen. De rijen van de tabel bepalen vervolgens de diepgang. Deze gaat van abstracte principes via concrete beleidslijnen naar gedetailleerde modellen. Bij het opstellen van architectuurproducten kan dit raamwerk gebruikt worden om de uit te werken aandachtsgebieden te bepalen en vast te stellen wat de vereiste diepgang is. Het vullen van alle cellen van het raamwerk is geen doel op zich. Scoping bij het opstellen van architecturen vindt volgens TOGAF (TheOpenGroup 2009) plaats op een aantal dimensies: Enterprise scope: Wat is de reikwijdte van de te beschrijven architectuur? De hele organisatie of een divisie? In samenhang met de ketenpartners? Welke business sectors, functies, organisaties, regio’s spelen een rol? Architecture domains: TOGAF hanteert het begrip domein voor de vierdeling Business, Data, Applications, Technology. Welke architectuurdomeinen moeten er beschreven worden? Time horizon: Wat is de horizon voor de Architecture Vision en moeten we de architecturen tot aan de horizon gedetailleerd uitwerken of kunnen we werken met een of meer tussentijdse ijkpunten? Vertical scope: Tot welk detailniveau moeten de architectuurproducten uitgewerkt worden? Hoeveel Architectuur is "genoeg"? Waar trekken we de grens tussen Architectuur en bijvoorbeeld systeemontwerp? De waarschijnlijkheid van toekomstige veranderingen op de uitgangspunten en het daarmee gepaard gaande risico bepalen de vereiste diepgang. Vertical Scope is daarmee synoniem met het begrip diepgang zoals het in dit onderzoek wordt gehanteerd. Betekenis voor het onderzoek Voor het onderzoek betekent bovenstaande, dat het DYA raamwerk gehanteerd kan worden om de dimensies van scope en diepgang in kaart te brengen en om de bevindingen in vast te leggen. De TOGAF begrippen Vertical Scope en Architecture Domains worden daarmee ook afgedekt. Time Horizon en Enterprise Scope zullen daarnaast een plek moeten krijgen in de werkwijze. 2.5 Bepalende factoren voor scope en diepgang Over de diepgang van een PSA wordt door van den Berg en van Steenbergen (2004) gesteld: “De architecturen geven precies zoveel detail dat een projectleider er voldoende houvast aan heeft om de juiste ontwerpbeslissingen te nemen binnen zijn project”. Een manier om tot een PSA te komen is om alle projectoverstijgende issues die in het project gemaakt moeten worden, langs te lopen en vast te leggen (Wagter, van den Berg e.a. 2001). Een beginnend architect heeft aan beide benaderingen weinig houvast. De geraadpleegde literatuur biedt slechts een beperkte set factoren waaruit valt af te leiden of bepaalde onderdelen van de Architectuur veel of weinig diepgang behoeven.

Pagina 18 van 65

Just Enough Architecture De Boer (2009) geeft met het begrip tastbaarheid een indicator. Naarmate een project minder tastbaar is er meer behoefte aan de duidelijkheid die een PSA kan bieden. Een website waarop een klant een schademelding kan opvoeren is tastbaarder dan bijvoorbeeld een groepsbreed management informatie systeem.

Groot

Klein

Imapct van verandering

Voor TOGAF (TheOpenGroup 2009) zijn de waarschijnlijkheid dat de uitgangspunten in de toekomst zullen wijzigen en de daarmee gepaard gaande impact bepalend voor de vereiste diepgang van architectuurproducten. Het in kaart brengen van de waarschijnlijkheid en consequenties van het veranderen van uitgangspunten vertoont parallellen met het in kaart brengen van risico’s zoals dat in het kader van risk management gebeurt. In een Risk Classification Scheme (TheOpenGroup 2009) worden de ingeschatte frequentie en de ernst van de gevolgen van het optreden van een risico in een tabel weergegeven om het risico te kunnen classificeren. Een dergelijke werkwijze kan ook gehanteerd worden om de waarschijnlijkheid van verandering van uitgangspunten af te zetten tegen de consequenties die dat voor de organisatie heeft. In Figuur 7: IssueMatrix - Impact en waarschijnlijkheid, gebaseerd op TOGAFis dat weergeven III IV in vier kwadranten. Ter illustratie een voorbeeld. Wanneer het uitgangspunt “niets uitbesteden” wijzigt in “alles uitbesteden” zijn de consequenties veel groter dan wanneer het uitgangspunt “de klant krijgt zijn documenten digitaal I II of op papier” wijzigt in “de klant krijgt zijn documenten digitaal”. De waarschijnlijkheid dat het uitgangspunt over digitale documenten wijzigt is Klein Groot echter groter dan de waarschijnlijkheid Waarschijnlijkheid verandering dat het uitgangspunt over uitbesteden Figuur 7: Issue-Matrix - Impact en waarschijnlijkheid, zo rigoureus zal veranderen. gebaseerd op TOGAF

Een ander aspect dat in TOGAF regelmatig terugkomt, is de constatering dat zaken die nieuw zijn in meer detail uitgewerkt dienen te worden, dan al bekende zaken. Dit geldt voor nieuwe bouwstenen, nieuwe processen, nieuwe applicaties etc. Verder geeft TOGAF aan dat in een situatie waarin een lange termijn architectuurvisie wordt ontwikkeld en deze geïmplementeerd wordt in een aantal kleinere stappen, het zinvol is deze stappen steeds met een korte tijdshorizon te werken en die gedetailleerd uit te werken. Dit lijkt in tegenspraak met de door de Boer geschetste tastbaarheid, immers hoe korter de horizon hoe tastbaarder het project, en hoe tastbaarder het project des te beperkter de toegevoegde waarde van een Project Start Architectuur. Betekenis voor het onderzoek Onderzocht wordt hoe het inschatten van de tastbaarheid van het project, de nieuwe factoren, de waarschijnlijkheid van toekomstige veranderingen op de uitgangspunten en de consequenties of impact van die veranderende uitgangspunten vorm kunnen krijgen in een werkwijze. Ook wordt onderzocht of toepassing van de matrix uit Figuur 7 bruikbaar is om te bepalen wat de vereiste scope en diepgang is bij het uitwerken van het betreffende issue. Hierbij wordt verondersteld dat de onderwerpen in vak IV breder en dieper uitgewerkt moeten worden, dan die in de vakken II en III. Het uitwerken van onderwerpen uit vak I kan achterwege blijven. De literatuur biedt geen aanknopingspunten of procesbeschrijvingen die bijdragen aan het bepalen van die factoren. Onderzocht wordt daarom ook op welke wijze de genoemde factoren in kaart gebracht kunnen worden.

Pagina 19 van 65

Just Enough Architecture Ook andere mogelijke factoren voor scope en diepgang worden in het onderzoek verzameld. 2.6 Bruikbaarheid Bruikbaarheid van de werkwijze Een doel van het onderzoek is te komen tot een bruikbare werkwijze voor de architecten om scope en diepgang te bepalen. Het vaststellen van de bruikbaarheid draagt bij aan de overdraagbaarheid van de resultaten van het onderzoek. De bruikbaarheid zoals die ervaren wordt, is in Action Research een pragmatische basis om de bruikbaarheid van de resultaten van het onderzoek vast te stellen (Baskerville en Wood-Harper 1996). In dit onderzoek wordt dan ook volstaan met de perceptie van de architecten over de bruikbaarheid van de toepassing van de werkwijze en de verwachtingen ten aanzien van toekomstig gebruik van die werkwijze. 2.7 Conclusies en vervolgvragen Waarom Architectuur en Project Start Architectuur Architectuur is van belang omdat het richting geeft. Werken onder Architectuur zorgt voor coherentie, het tegengaan van versnippering en het vergroten van de verandersnelheid. Wanneer Architectuur richting moet geven, dan moet de Project Start Architectuur richting geven aan specifieke projecten. De te ontwikkelen werkwijze moet zodoende:  gericht zijn op het betrekken van de hele organisatie in de beschouwing;  ertoe bijdragen dat de PSA projecten in staat stelt zich aan de Architectuur te houden en ertoe bijdragen dat projecten hun bijdrage leveren aan het opbouwen van de Architectuur om versnippering tegen te gaan;  ondersteunen bij de keuze van uit te werken onderwerpen, om snelheid te faciliteren. Project Start Architectuur in Bottom Up situatie De situatie waarbij de Enterprise Architectuur en de Domein Architectuur slechts minimaal beschikbaar zijn, terwijl er toch door middel van PSA’s richting wordt gegeven aan projecten, komt in de literatuur niet aan de orde. Deze vorm van Architectuur is te beschouwen als Bottom Up Architectuur. Omdat het opstellen van een PSA in een Bottom Up situatie veel verder gaat dan het vergaren van bestaande richtlijnen, is het vaststellen van de juiste scope en diepgang voor de PSA zeer relevant. Naarmate er minder materiaal beschikbaar is, zijn keuzes ten aanzien van scope en diepgang belangrijker.  De werkwijze wordt voor een Bottom Up situatie ontwikkeld.  De werkwijze moet de onderwerpen aan het licht brengen waar principes, beleidslijnen en modellen niet voor handen zijn, maar wel gewenst. Dimensies van scope en diepgang Het DYA raamwerk geeft de dimensies voor scope in de kolommen en voor diepgang in de rijen weer. TOGAF kent andere termen voor de DYA begrippen en voegt daar Time Horizon en Enterprise Scope aan toe.  Het DYA raamwerk wordt in de werkwijze opgenomen om de scope en diepgang weer te geven.  Van TOGAF worden de begrippen Time Horizon en Enterprise Scope opgenomen.  Hoe deze begrippen worden ingepast in de werkwijze, wordt onderzocht in de Planning Action fase van het onderzoek. Bepalende factoren voor scope en diepgang Tastbaarheid, de waarschijnlijkheid van toekomstige veranderingen en de impact daarvan zijn factoren die bepalend zijn voor scope en diepgang. In de Diagnosing fase wordt onderzocht welke verdere factoren er in de praktijk een rol spelen bij het bepalen van scope en diepgang. In de “Planning Action” fase wordt onderzocht hoe deze factoren in de te ontwikkelen werkwijze worden opgenomen. Ook wordt onderzocht of een Issue-Matrix bijdraagt aan het inzichtelijk maken van de impact en waarschijnlijkheid van nieuwe keuzes als gevolg van voortschrijdend inzicht.

Pagina 20 van 65

Just Enough Architecture Werkwijze De literatuur biedt geen aanknopingspunten of procesbeschrijvingen die bijdragen aan het vaststellen van die factoren. Een werkwijze om de gevonden factoren in kaart te brengen wordt daarom uitgewerkt in de Planning Action fase. Bruikbaarheid De bruikbaarheid zoals die ervaren wordt, is in Action Research een pragmatische basis om de bruikbaarheid van de resultaten van het onderzoek vast te stellen (Baskerville en WoodHarper 1996). Om de bruikbaarheid vast te stellen wordt in de Evaluating Action fase de door de architecten ervaren bruikbaarheid onderzocht.

Pagina 21 van 65


3

Onderzoeksmethodologie

In dit hoofdstuk wordt uiteengezet welke onderzoeksstrategie en onderzoeksmethode toegepast worden en hoe dat past bij de onderzoeksvraagstelling. De volgende vragen komen daarbij aan de orde:  Welke methode van onderzoek past er bij de vraagstelling?  Op welke wijze wordt de wetenschappelijke relevantie gewaarborgd?  Hoe wordt deze methode in dit onderzoek toegepast?  Welke wijze van dataverzameling wordt er toegepast?  Welke specifieke bijzonderheden kleven er aan het doen van Action Research in de eigen organisatie en wat betekent dat voor dit onderzoek? 3.1 Veranderen en onderzoek doen: Action Research Zoals eerder geschetst heeft het onderzoek als doel een op de ervaring gebaseerde werkwijze te ontwikkelen. Deze werkwijze moet architecten behulpzaam zijn bij het bepalen van de scope en diepgang van hun dienstverlening. De werkwijze zou binnen de onderzochte organisatie, maar ook voor andere IT organisaties bruikbaar moeten zijn en een praktische aanvulling kunnen zijn op bestaande methodes als DYA en TOGAF. In deze doelstelling zitten de elementen praktijk en theorie. Zoals in paragraaf 1.7 werd aangegeven vormt deze combinatie van probleemoplossing in de praktijk en genereren van nieuwe kennis, het domein van de Action Research (Coghlan 2001; Robson 2002; Eriksson en Kovalainen 2008). Argyris e.a. (Argyris en Schon 1978; 1996; Coghlan 2001) zeggen over Action Research onder andere:  Action Research gaat over veranderexperimenten met echte problemen in sociale systemen;  Action Research verloopt in cycli van diagnose of probleemidentificatie, planning, actie en evaluatie;  Het onderzoek draagt bij aan de ontwikkeling van kennis in de sociale wetenschappen en aan de alledaagse praktijk. Deze kenmerken zijn in dit onderzoek als volgt herkenbaar:  Het “echte” probleem van het bepalen van scope en diepgang in het sociale systeem van de architecten in hun (project)omgeving wordt onderzocht en er wordt geëxperimenteerd met een nieuwe werkwijze.  De cyclus is in het onderzoek terug te vinden in de analyse van het probleem (Diagnosing), de zoektocht naar factoren voor scope en diepgang en het uitwerken van een werkwijze (Planning Action) en de toepassing (Taking Action) en evaluatie van de werkwijze (Evaluating Action);  Het onderzoek draagt bij aan de praktijk van de architecten in de onderzochte organisatie. Door de vastlegging als Thesis en de publicatie ervan draagt het ook bij aan de Body of Knowledge van de architecten. Het resultaat van het onderzoek kan als aanvulling dienen op DYA of TOGAF.

Pagina 22 van 65


Figuur 8: Action Research Cycle en Learning Cycle

Action Research speelt zich af in een iteratief proces van diagnosticeren, plannen en doen en evalueren rondom veranderingen in een organisatie. Deze Action Research cyclus wordt gedurende het onderzoek een aantal keren doorlopen. Daarnaast doorlopen de onderzoeker en de actoren of medeonderzoekers een aantal cycli van experimenteel leren, de groene cirkel in Figuur 8. De volgende vragen zijn daarbij van belang: “Wat is er gedaan of gebeurd, wat was daarvan het effect, wat betekent dat voor de rol van de onderzoeker of actor en wat betekent dat voor de volgende stap?” (Coghlan 2001). De leerervaringen van de onderzoeker komen terug in hoofdstuk 6. Voorafgaand aan het onderzoek is een literatuuronderzoek uitgevoerd. Hierin wordt vastgesteld welke modellen en aanpakken er in de architectuurliteratuur beschikbaar zijn. De uitkomst daarvan is beschreven in hoofdstuk 2. In de inbeddingfase of entrancefase (Davison, Martinsons e.a. 2004) vindt de plaatsbepaling van het onderzoek plaats. Hierin worden afspraken gemaakt over de werkwijze en rollen in het onderzoek en de verhouding tot de reguliere werkzaamheden en rollen van de betrokkenen. In deze fase wordt ook de overeenkomst tussen de onderzoeker en de organisatie vastgelegd in de Researcher Client Agreement2. In dit onderzoek overlappen de inbeddingfase en de Diagnosing fase elkaar. Fase Diagnosing

Planning Action Taking Action Evaluating Action

Onderwerpen & Activiteiten Inbedding van het onderzoek in de organisatie, Researcher Client Agreement. Architectuur in de praktijk van de organisatie Bepalen concepten van invloed op scope en diepgang Concepten uit theorie en praktijk vormgeven in een werkwijze Werkwijze toepassen Werkwijze evalueren  Betekenis voor de organisatie  Betekenis voor de Architectuur Body of Knowledge  Aanbevelingen voor verder onderzoek

Tabel 3: Activiteiten per fase

3.2 Praktische en wetenschappelijke relevantie: Grounded Action Research Action Research wordt wel afgedaan als relevant voor de praktijk, maar irrelevant voor de theorie. Baskerville en Pries-Heje (Baskerville en Pries-Heje 1999) beschrijven in “Grounded Action Research: a method for understanding IT in practice” hoe op basis van principes uit de Grounded Theory ook met Action Research tot een verantwoorde theorievorming is te komen. 2

Digitale bijlage: AR000 - 20100520 Researcher - Client Agreement thesis J Boer.doc Pagina 23 van 65

Just Enough Architecture Deze theorievorming vindt plaats door het structureren van de resultaten van de dataverzameling. Hierbij worden drie soorten codeerprocedures toegepast: Open Coding, Axial Coding en Selective Coding. Deze principes worden in dit onderzoek toegepast om te komen tot een werkwijze:  Door Open Coding worden de belangrijkste ideeën en datacategorieën uit de data afgeleid. In de Diagnosing fase zijn de aantekeningen en de verslaglegging gecodeerd op basis van open coding. Een tussenresultaat daarvan is opgenomen als Bijlage 5.  Axial coding legt vervolgens de verbanden tussen de categorieën. Een eerste ronde van Axial coding heeft geleid tot toevoeging van de kolom “categorie” in de tabel in Bijlage 5.  Op basis van Selective Coding wordt vervolgens een theorie ontwikkeld die past op de bestudeerde verschijnselen rondom het centrale onderzoeksprobleem (Baskerville en Pries-Heje 1999; Eriksson en Kovalainen 2008). De Selective coding heeft geleid tot samenhang tussen de concepten die scope en diepgang bepalen en de wijze waarop ze bepaald kunnen worden. Deze storyline is vastgelegd en besproken aan de hand van powerpoint presentaties3. Deze tussenstappen hebben geleid tot een eerste versie van de werkwijze, zoals vastgelegd in Bijlage 6. Het toetsen in een nieuwe Action Research cyclus van een, naar aanleiding van de evaluatie vernieuwde storyline, past niet meer binnen de scope van het Thesisonderzoek. 3.3 Issues met Action Research in de eigen organisatie Coghlan signaleert in “Doing Action Research in Your Own Organization” (2001) een aantal issues m.b.t. onderzoek in de eigen organisatie. Daarvan zijn Role Duality, en Preunderstanding zijn voor dit onderzoek relevant. Role Duality: Het werk van de manager en de onderzoeker kunnen elkaar in de weg zitten.  De onderzoeksopdracht volgt uit de reguliere taakomschrijving van de manager/onderzoeker, maar de waarde voor de praktijk zegt weinig over de wetenschappelijke waarde.  De deelnemers/mede-onderzoekers hebben vaak een hiërarchische relatie met de onderzoeker.  De interventie heeft vermoedelijk een productiviteitsverbetering ten doel.  De dataverzameling vindt plaats op formele en informele wijze.  Feedback sessies kunnen in het reguliere werk worden ingepast of apart worden georganiseerd.  De manager heeft een belang bij de uitkomst van het onderzoek. Deze punten samen zijn op te vatten als issues van “Role Duality”: de wetenschappelijke integriteit van de onderzoeker en het praktische belang van de manager zitten elkaar soms in de weg. Voor de praktijk van dit onderzoek is een aantal maatregelen genomen om te voorkomen dat deze dualiteit problematisch wordt.  In de inbeddingfase zijn in de Researcher Client Agreement afspraken gemaakt en vastgelegd. Daarbij gaat het om rollen en verantwoordelijkheden van de onderzoeker en medeonderzoekers, vastlegging en vertrouwelijkheid en de eindtermen van het onderzoek.  Het is de bedoeling dat het ontwikkelen van de werkwijze een gezamenlijke leerervaring is van de architecten die als mede-onderzoekers optreden. De rol van de onderzoeker is die van betrokken procesbegeleider of acteur-regisseur. Daarbij dient vermeden te worden sturend op te treden in de richting van de uitkomsten. Dit is besproken met de betrokkenen en ook vastgelegd in de genoemde Researcher Client Agreement.

3

Zie digitale bijlage: AR004P - 20100610 Meeting ontwikkelen werkwijze.ppt Pagina 24 van 65

Just Enough Architecture  

Gespreksverslagen en conclusies zijn getoetst met de deelnemers. De reacties zijn toegevoegd aan het dossier. Hoewel het onderzoek op een aantal momenten in reguliere werksituaties aan de orde is geweest, zijn er in elke fase besprekingen expliciet aan het onderzoek gewijd, hierbij is ook feedback op de rol van de onderzoeker aan bod gekomen4.

Preunderstanding De onderzoeker maakt al enige jaren onderdeel uit van de organisatie en is ook een actieve deelnemer in het architectuurproces. Voordeel is dat dit veel informatie uit de eerste hand oplevert. Mogelijke problemen zijn: interviews gaan niet diep genoeg; zaken worden bekend verondersteld; aannames worden niet getoetst en contrasterende visies komen niet vanzelf aan de orde. Deze zaken, die Coghlan schaart onder Preunderstanding, zijn niet helemaal te vermijden in een onderzoek in de eigen organisatie. In het onderzoek is hier op een aantal manieren aandacht aan geschonken:  Een externe architectuurbegeleider heeft in alle fasen van het onderzoek voor een blik van buiten de organisatie gezorgd. Tijdens de Evaluating Action fase is nog een tweede externe architect in de organisatie aangesteld en bij het evalueren betrokken.  De resultaten tot en met de Planning Action fase zijn met de heer van den Berg, Serviceline Manager Architectuur bij Sogeti Nederland BV en auteur op gebied van Architectuur besproken. Dit heeft tot een aantal aanvullingen op de concept werkwijze geleid.  Terugkoppeling in de thesisbegeleidingsgroep, bestaande uit IT-ers uit andere organisaties, heeft bijgedragen aan de vormgeving van het onderzoek en tot kritische “is dat nou wel zo” vragen, al zijn deze inzichten niet in de verslaglegging terug te vinden.

Nee

Ja

III

Researcher Intended Selfstudy in action

3.4 Het object van zelfstudie In “Doing Action Research in Your Own Organization” (2001) onderscheidt Coghlan twee dimensies waarlangs actieonderzoek kan worden ingedeeld. Het betreft de mate waarin de onderzoeker onderwerp van zelfstudie is en de mate waarin de organisatie onderwerp van zelfstudie is.

Individual engaged in reflective study of professional practice

IV Large scale transformational change

I

II

Traditional research approaches

Pragmatic Action Research, Internal Consulting Action Learning

Dit onderzoek bevindt zich in kwadrant II. Het is vooral het team van architecten dat de eigen Nee Ja werkwijze onder de loep neemt. Het team wordt Intended Selfstudy in action begeleid door de manager/onderzoeker. Het System onderzoek is dus te beschouwen als “Pragmatic Figuur 9: Focus van researcher en systeem Action Research”. De focus van het onderzoek ligt op het leren van de organisatie en niet op dat volgens Coghlan van de onderzoeker. Uiteraard leidt het doen van dit onderzoek wel tot zelfreflectie en tot leren bij de onderzoeker. Deze bijvangst is terug te vinden in hoofdstuk 6.

4

Zie bijvoorbeeld digitale bijlage: AR004 - 20100610 Meeting ontwikkelen werkwijze verslag.doc en de reacties daarop. Pagina 25 van 65


3.5 Dataverzameling Fase Dataverzameling Diagnosing Participerende observatie in werkoverleg architecten. Open interviews met de architecten Analyse van verslagen van de diverse architectuuroverleggen, projectplannen, Project Start Architecturen en andere architectuurdocumenten. Planning Action Participerende observatie in werkoverleg architecten. Open interviews met de architecten Werksessie bespreking voorgestelde werkwijze Taking Action Analyse van de procesverslagen “toepassen werkwijze” Evaluating Action Vragenlijst bruikbaarheid werkwijze (gesloten vragen) Vragenlijst bruikbaarheid werkwijze (open vragen) Bespreking toegepaste werkwijze Bespreking onderzoeksresultaten, conclusies en aanbevelingen Tabel 4: Methoden van dataverzameling

In de diagnosefase is de dataverzameling vooral exploratief van aard: wat speelt er allemaal? Vanaf de Planning Action fase is de dataverzameling meer confronterend en gericht op reflectie bij de actoren: wat gebeurde er, waardoor komt dat? Van alle gesprekken is een verslag opgesteld en aan de betrokkenen voorgelegd. Deze datafeedback (Eriksson en Kovalainen 2008) dient om de validiteit van het vastgelegde te toetsen en de basis te leggen voor de volgende stap. Validiteit van de data Validiteit van de veelal kwalitatieve data is bij veel Action Research een issue (Coghlan 2001; Davison, Martinsons e.a. 2004; Eriksson en Kovalainen 2008). Om hieraan tegemoet te komen is in dit onderzoek een aantal maatregelen genomen. In de eerste plaats zijn alle uitwerkingen van gesprekken en bijeenkomsten voorgelegd aan de deelnemers. De interviews in de diagnosefase zijn met de architecten in koppels gehouden. De bevindingen uit de interviews van de diagnosefase zijn in een open interview met de externe architect getoetst (zie audittrail, AR005). De sessies in de Planning Action fase zijn met alle architecten tegelijk gehouden, waardoor de ervaringen en bevindingen daar het persoonlijke ontstijgen. Ook de tussenresultaten van de Planning Action fase zijn besproken en getoetst met de externe architect en met de eerder genoemde heer van den Berg. 3.6 Samenvatting methodologie Als onderzoeksmethode wordt de Action Research toegepast. Deze methode leent zich goed om bruikbaarheid van de werkwijze in de praktijk te combineren met een bijdrage aan de Body of Knowledge over Architectuur. Het onderzoek is volgens de cyclus van Action Research onderverdeeld in vier fasen. In de “Diagnosing Fase” worden de bepalende concepten voor scope en diepgang uit literatuur en praktijk verzameld. In de Planning Action Fase wordt een werkwijze vormgeven om de gevonden concepten in de praktijk toe te passen. In de Taking Action fase wordt de werkwijze toegepast, waarna in de Evaluating Action wordt gereflecteerd op het toepassen van de werkwijze en de bruikbaarheid daarvan. Vooral bij aanvang van het onderzoek is gebruik gemaakt van in de organisatie beschikbaar materiaal. Daarnaast zijn interviews (Diagnosing fase) en (uit)werksessies gehouden (Planning Action en Evaluating Action fase) en is het toepassen van de werkwijze vastgelegd in rapportage-templates. Om de wetenschappelijke relevantie te waarborgen en het proces van dataverzameling en interpretatie te borgen wordt de coderingswijze van de Grounded Action Research toegepast. Pagina 26 van 65

Just Enough Architecture Om te voorkomen dat teveel in het denkpatroon van de eigen organisatie wordt gedacht is op een aantal momenten toetsing door derden opgenomen in het onderzoek. Om zeker te stellen dat de ontwikkelde werkwijze van en voor alle betrokkenen is en niet die van de onderzoeker, is de verslaglegging van alle tussenstappen aan de betrokkenen voorgelegd en zijn de aldus gekregen reacties verwerkt. Om duidelijkheid te scheppen in verband met de verschillende rollen en relaties, zoals onderzoeker – medeonderzoeker, manager – collega zijn afspraken gemaakt en vastgelegd in de Researcher Client Agreement en is de problematiek tussentijds besproken met betrokkenen.

Pagina 27 van 65


4

Praktijk en resultaten

Dit hoofdstuk beschrijft de Action Research cyclus zoals die voor dit onderzoek is uitgevoerd. Van de vier fasen wordt beschreven welke stappen er gezet zijn en wat de resultaten daarvan waren. Inzichtelijk wordt hoe de concepten die in de Diagnosing fase zijn verzameld, een plaats krijgen in de werkwijze die in de Planning Action fase wordt ontwikkeld. Vervolgens wordt duidelijk hoe de werkwijze is toegepast in de Action fase en hoe de uitkomsten daarvan in de Evaluating Action fase zijn geëvalueerd om de bruikbaarheid van de werkwijze vast te stellen. Daarnaast zijn in alle fases effecten opgetreden die niet direct te relateren zijn aan de onderzoeksvragen. Omdat deze leerervaringen wel van invloed zijn op hoe de architecten met de materie omgaan, zijn ze per fase verwoord in de paragraaf Leereffecten. 4.1 Diagnosing: Bepalende factoren voor scope en diepgang in de praktijk In de volgende paragrafen worden de activiteiten en resultaten beschreven uit de eerste fase van het onderzoek: Hoe en waarom wordt Architectuur in de onderzochte organisatie ingezet en welke rol speelt de PSA daarbij? Daarnaast wordt onderzocht welke concepten in de praktijk bepalend zijn voor de scope en diepgang van een PSA en hoe deze factoren bepaald worden. 4.1.1 Uitgevoerde onderzoeksactiviteiten Het praktijkonderzoek is uitgevoerd met en door de vier architecten uit de organisatie. In mei 2010 is de onderzoeksopzet met hen en met de externe Architectuur begeleider doorgenomen. Deze besprekingen hadden de vorm van open interviews aan de hand van de onderwerpen in het onderzoeksvoorstel. Deze gesprekken leverden diverse concepten op, die een rol spelen bij het bepalen van scope en diepgang. Ook is in deze periode de Researcher Client Agreement tot stand gekomen waarin de rollen en afspraken zijn vastgelegd. Deze is in juni 2010 goedgekeurd door de COO, de eindverantwoordelijke voor Architectuur in de organisatie. Daarnaast zijn in deze fase de beschikbare verslagen en presentaties onderzocht op inrichting en doelen van Architectuur. 4.1.2 Onderzoeksresultaten: Architectuur inrichting en doelen De onderzochte organisatie is medio 2009 begonnen met het werken onder Architectuur. De DYA methode is daarbij als uitgangspunt genomen, omdat deze voor de organisatie goed toegankelijk was en zonder grote leercurve snel in te zetten. Er is een sturend overlegorgaan dat de grote lijnen uitzet, en voor de hele organisatie de richting bepaalt. Dit Architectuuroverleg is namens de COO verantwoordelijk voor Architectuur en is daarmee in feite wat DYA de “Architectuur Board” noemt. In de zomer van 2009 zijn de doelen voor Architectuur voor de organisatie uitgewerkt in een Masterplan Architectuur. Daarin staat dat Architectuur moet bijdragen aan een vereenvoudiging van het versnipperde applicatielandschap, moet bijdragen aan een robuuste informatievoorziening en dat de Architectuur de organisatie in staat moet stellen nieuwe proposities in de markt te zetten die de traditionele “Lines of Business” ontstijgen. Er is op het moment van onderzoek geen uitgewerkte Enterprise Architectuur beschikbaar. Ook zijn er geen Domein Architecturen beschikbaar. Wel is er een “Masterplan Architectuur” waarin vier aandachtsgebieden5 globaal zijn uitgewerkt. Hiermee wordt richting gegeven aan zowel het tegengaan van versnippering als het ontwikkelen van nieuwe proposities over “Lines Of Business” heen. De architecten geven aan dat het masterplan bruikbaar is voor de hoofdlijnen, maar dat het onvoldoende aanknopingspunten biedt bij het opstellen van een PSA.

5

De aandachtsgebieden zijn: Portals & Security, Datawarehouse, Transactieloket en OutputManagement. Pagina 28 van 65

Just Enough Architecture Architectuur vanuit de domeinen Aan elk van de aandachtsgebieden in het masterplan is één van de vier architecten toegewezen als domein architect. Deze ontwerpt de Domein Architectuur voor het aandachtsgebied. De samenhang tussen de domeinen bewaken de architecten onderling, onder andere in hun wekelijkse overleg. De richting toetsen de architecten in het bredere Architectuuroverleg. Architectuur vanuit de projecten De architecten zijn niet alleen aan een domein gekoppeld, ze worden ook toegewezen aan projecten. De belangrijkste taak die ze als projectarchitect hebben is het opstellen van de Project Start Architectuur. Aangezien er geen Enterprise Architectuur is om uit te putten en omdat er nog geen Domein Architecturen zijn, moet er voor het opstellen van een PSA veel uitgezocht en uitgewerkt worden. Het doel van de PSA is om de projecten in de richting van het masterplan te sturen. De architecten besteden het grootste deel van hun tijd aan de rol van projectarchitect. Hierbij komt het in vrijwel alle projecten voor dat de projectleiding eerder resultaten wil dan de architect kan leveren. In de praktijk van de organisatie bepaalt de architect in overleg met de projectleiding met welke diepgang en scope en met welke prioriteit de aandachtspunten voor de PSA worden uitgewerkt. Hierbij wordt geen gestructureerde werkwijze gehanteerd. Vanuit de Architectuur die uitgewerkt wordt voor de projecten en domeinen, wordt geleidelijk de Enterprise Architectuur afgeleid. In de praktijk is daar echter weinig capaciteit voor. De bevindingen in deze paragraaf zijn herleid uit de bronnen zoals vermeld in Bijlage 2. 4.1.3

Onderzoeksresultaten: Factoren voor scope en diepgang

Door de architecten onderkende factoren scope en diepgang Factoren gerelateerd aan het doel van de PSA en het Project:  Beschikbare tijd;  Het doel van de PSA;  De doelgroep van de PSA;  De mate waarin sturing noodzakelijk is;  Gewenste mate van inzicht in mogelijke kosten van de oplossing;

Factoren in verband met raakvlakken  Raakvlakken met externe organisaties (ketenpartners)  Raakvlakken met externe organisaties in ontwerp en realisatie van de IT  Raakvlakken met andere projecten  Raakvlakken met andere domeinen  Raakvlakken / interfaces met systemen.

Factoren gerelateerd aan tastbaarheid  Het al dan niet aanwezig zijn van een EA/DA  Het ontbreken van een referentiekader vraagt meer diepgang  Onduidelijkheden in het uit te werken aandachtsgebied  Nieuwe materie vereist extra diepgang  Vakvolwassenheid/ervaring van de doelgroep op het domein van de Architectuur  Duidelijkheid of onduidelijkheid over toekomstig processen  Complexiteit van de materie

Factoren in verband met risico van toekomstige veranderingen  De consequenties van een mogelijke verkeerde keuze in de PSA bepaalt mede de scope/diepgang.  Impact van een mogelijke verandering  Waarschijnlijkheid van een verandering

Tabel 5: Bepalende factoren scope en diepgang In het onderzoek is door de architecten een reeks van factoren benoemd. Het zijn factoren waar in de praktijk door de architecten tot op heden geen expliciete aandacht aan werd besteed. Scope en diepgang worden nu op basis van ervaring, beschikbare tijd en impliciete kennis bepaald.

Pagina 29 van 65

Just Enough Architecture Het ontwikkelen van een werkwijze die de architecten helpt te bepalen wat de scope en diepgang van hun PSA moet zijn, wordt door de architecten als nuttig ervaren. Drie categorieën van architectuurissues De architecten zijn in deze fase tot de conclusie gekomen dat je de punten die in een PSA moeten worden uitgewerkt in drie categorieën te verdelen zijn: 1. Issues die zonder meer uit de beschikbare Enterprise Architectuur of Domein Architectuur zijn af te leiden. 2. Issues die uitgezocht en uitgewerkt moeten worden en een plek moeten krijgen in deze versie van de PSA. 3. Issues die na de start van het project uitgezocht en uitgewerkt kunnen worden, waaraan capaciteit toegewezen kan worden in een volgende fase, maar die nu even kunnen blijven liggen. Hiervan is categorie 1 zeer zeldzaam in de onderzochte organisatie, maar kan het onderscheid tussen categorieën 2 en 3 de architecten helpen bij het stellen van prioriteiten. In Bijlage 1 onder het kopje Diagnosing is aangegeven op welke brondocumenten bovenstaande gebaseerd is. 4.1.4 Leereffecten diagnose fase Werken met versies Tijdens de discussie over de factoren die bepalen wanneer een PSA goed genoeg is kwam onder andere het “doel” van de PSA naar voren. Hierbij blijkt het doel van de eerste versie van de PSA te maken te hebben met de besluitvorming over het al dan niet starten van een project. Voor die besluitvorming zijn globale adviezen nodig over de richting van de oplossing op grote lijnen. Pas in de volgende stap is het nodig ontwerpers richting te geven over de wijze waarop het advies meer gedetailleerd uitgewerkt moet worden. Voor de praktijk betekent dit dat versies van een PSA elkaar kunnen opvolgen. Werken met versies in combinatie met de drie hierboven genoemde categorieën van issues, biedt mogelijkheden om prioriteiten te stellen in de onderdelen van de PSA. Het werken met versies van een PSA hebben de architecten in de loop van het onderzoek tot standaard verheven.

Pagina 30 van 65


4.2 Planning Action: Naar een concept werkwijze In de Planning Action fase is een werkwijze ontwikkeld om de bepalende factoren voor scope en diepgang in kaart te brengen. In de volgende paragrafen wordt beschreven welke onderzoeksactiviteiten daarvoor zijn uitgevoerd en hoe de resulterende werkwijze eruit ziet. 4.2.1 Uitgevoerde onderzoeksactiviteiten In juni 2010 is de “Planning Action” fase gestart. Op basis van de resultaten van de diagnose fase zijn de samenhang van de factoren en de suggesties voor een werkwijze geordend in een storyline6. Deze storyline is in een sessie met de architecten bediscussieerd en van aanvullingen voorzien. Vervolgens is de aangepaste storyline herzien in werksessies met de externe architectuurbegeleider en een architectuurdeskundige van buiten de organisatie. Dit heeft geleid tot een versie die besproken is in het reguliere architectuuroverleg, waarna afspraken gemaakt zijn over het in de praktijk toepassen van de werkwijze. Ook zijn in dit overleg de vragen opgesteld die inzicht kunnen geven in de factoren. Het resultaat daarvan is weergegeven in Bijlage 5. De documenten en verslagen waarin de tussenresultaten van deze fase zijn vastgelegd zijn te vinden in Bijlage 1 onder het kopje “Planning Action”. 4.2.2 Onderzoeksresultaten: Een eerste werkwijze Uitgangspunten Uitgangspunt voor de werkwijze was dat deze ervoor moet zorgen dat de bepalende factoren voor scope en diepgang in kaart gebracht worden. Uit het literatuuronderzoek was al een aantal uitgangspunten geformuleerd:  gericht zijn op het analyseren van de organisatie als geheel voor de PSA;  ertoe bijdragen dat de PSA projecten in staat stelt zich aan de Architectuur te houden en ertoe bijdragen dat projecten hun bijdrage leveren aan het opbouwen van de Architectuur om versnippering tegen te gaan;  ondersteunen bij de selectie van de uit te werken onderwerpen, om snelheid van projecten te faciliteren. Daarnaast is in de Planning Action fase nog een aantal eisen geformuleerd:  De werkwijze moet opeenvolgende versies van een PSA kunnen ondersteunen.  De werkwijze moet “witte vlekken” signaleren. Hiertoe is een aantal referentiedocumenten in de checklist opgenomen. Het doorlopen van deze documenten waarborgt dat alle relevante aspecten onder de aandacht worden gebracht.  De werkwijze moet zorgen dat meerdere gezichtspunten worden betrokken: o meerdere architecten, zodat tevens kennisdeling ontstaat, o projectleiders en informatie analisten en/of materiedeskundigen, o vertegenwoordigers van de business.  De werkwijze moet in te passen zijn in de besluitvormingsfase die voorafgaat aan de start van een project.  De werkwijze moet ertoe bijdragen dat inzichtelijk wordt welke issues in welke van de volgende uitwerkcategorieën vallen: 1. Direct herleidbaar uit Enterprise of Domein Architectuur; 2. Direct bij aanvang PSA uitwerken; 3. Later in het project uitwerken. Werkwijze De werkwijze die uit de Planning Action fase is voortgekomen bestaat uit drie elementen: 1. Checklist De checklist is een vragenlijst waarin o.a. de factoren die bepalend zijn voor scope en diepgang expliciet aan de orde komen. De checklist dient ervoor om geen relevante aspecten over het hoofd te zien. 6

digitale bijlage: AR004P - 20100610 Meeting ontwikkelen werkwijze.ppt Pagina 31 van 65

Just Enough Architecture 2. Organisatiespecifiek referentiemateriaal Het referentiemateriaal bestaat uit diverse beschikbare documenten over de organisatie, de processen en de systemen. Het materiaal dient om de architect vanuit zoveel mogelijk verschillende views naar de vraagstukken uit het project te laten kijken. Het helpt de architect bij het stellen van de juiste vragen en geeft in sommige gevallen ook al enigszins de richting aan. Dit geldt bijvoorbeeld voor het “Target Operating Model”, wat in feite een Enterprise Architectuur document is, al heeft het nooit dat stempel gekregen. 3. Stappenplan in vier stappen Dit beschrijft de manier om op basis van de checklists en het referentiemateriaal te komen tot aanbevelingen over scope en diepgang en dit te vertalen naar een agenda voor de PSA. Afhankelijk van de aard en de fase waarin het project verkeert kunnen deze stappen een aantal keren worden herhaald. Stap

Bijzonderheden en overwegingen

Stap 1: Inlezen en aandachtspunten verzamelen

Een projectarchitect en een architect/meelezer verdiepen zich parallel in de materie. Dit waarborgt verschillende invalshoeken. Ze verzamelen los van elkaar de aandachtspunten op basis van de beschikbare documenten en stellen los van elkaar de prioriteiten en vereiste diepgang vast.

Stap 2: Sparren en toetsen met collegaarchitect

De architecten leggen hun bevindingen naast elkaar en bespreken de resultaten. Hieruit ontstaat een gedeeld beeld op de op te pakken issues. De aandachtspunten worden geordend en er wordt samen opnieuw bepaald waar ze in het DYA raamwerk passen, waar ze in de IssueMatrix (Figuur 7: Issue-Matrix - Impact en waarschijnlijkheid, gebaseerd op TOGAF) passen en in welke van de drie uitwerkcategorieën ze vallen.

Stap 3: Toetsen breder in de organisatie, agenda opstellen.

De projectarchitect gaat met het nu ontwikkelde beeld van aandachtspunten en prioriteiten in dialoog met de betrokkenen. Op deze manier kunnen de aandachtspunten en prioriteiten getoetst en bijgesteld worden. Hiermee wordt tevens in de organisatie aandacht gekweekt voor de aandachtspunten. Gesprekspartners zijn hier in elk geval de projectleiding en de opstellers van eventuele vooronderzoeksrapporten. Resultaat van deze stap is overeenstemming tussen project en Architectuur over de Issue-Matrix en over prioriteiten en de uitwerkcategorieën van de aandachtspunten.

Stap 4: Uitwerken Project Start Architectuur

Pas in deze stap worden de aandachtspunten daadwerkelijk onderzocht en worden de richtlijnen of modellen uitgewerkt.

Tabel 6: Werkwijze bepalen scope en diepgang Om de prioriteit van de Architectuur aandachtspunten te bepalen wordt in alle stappen de Issue-Matrix gehanteerd om impact en waarschijnlijkheid van voortschrijdend inzicht te visualiseren. Voor het uitvoeren van de werkwijze is een template gemaakt, waarin de stappen aangegeven staan en waarin ruimte is voor het vastleggen van de bevindingen. De toepassing van deze werkwijze wordt besproken in paragraaf 4.3. In paragraaf 4.4 wordt de evaluatie van de toepassing van de werkwijze toegelicht. Het stappenplan is opgenomen als Bijlage 6 en de checklist en het referentiemateriaal als Bijlage 7. Pagina 32 van 65

Just Enough Architecture 4.2.3 Leereffecten uit de Planning Action fase Uitgaan van processen Naar voren is gekomen dat de vier architecten een “Informatie Architectuur” focus hebben. Dit heeft in het verleden geleid tot PSA’s die belangrijke business issues onbenoemd lieten, waardoor oplossingen bijvoorbeeld niet goed in beheer genomen konden worden. De toepassing van o.a. het waardeketen-model uit het referentiemateriaal bij de checklist blijkt de focus meer op de business en de processen te leggen dan eerder het geval was. Moment van opstellen van de PSA Terugblikkend op één van de projecten die al in de realisatiefase is, wordt geconstateerd dat die PSA die er voor opgesteld is erg op de techniek is gericht en belangrijke business vraagstukken over het hoofd heeft gezien. Er was al een Proof Of Concept uitgevoerd. Daaruit waren diverse technische issues naar voren gekomen. Die vragen zijn vervolgens in de PSA beantwoord. Doordat het project al begonnen was en haast had, zijn de vragen over doel en raakvlakken nooit gesteld. Conclusie van de architecten is dat ze ook wanneer ze op een rijdende trein springen toch de werkwijze moeten toepassen. 4.3 Taking Action: De werkwijze toegepast in de praktijk In de Taking Action fase is de werkwijze in de praktijk toegepast. Aangezien de terugblik en de conclusies over het toepassen van de werkwijze bij de Evaluating Action fase aan de orde komen, wordt hier volstaan met een beschrijving van de uitgevoerde activiteiten en leereffecten die al tijdens de uitvoering van deze fase optraden.

Stap 1 uitgevoerd

Stap 2 uitgevoerd

Stap 3 uitgevoerd

Projectfase

8

4.3.1 Uitgevoerde onderzoeksactiviteiten De werkwijze is in de praktijk toegepast voor een aantal projecten. Daarbij zijn wisselende koppels geformeerd van projectarchitect en een sparringpartner/meelezer, zoals in de werkwijze is aangegeven. De vijf aandachtsgebieden uit het masterplan Architectuur zijn allemaal in één of meer van de projecten prominent aanwezig7. Stap 4 van de werkwijze, het opstellen en redigeren van de PSA aan de hand van de in de voorgaande stappen verzamelde aandachtspunten is in geen van de projecten uitgevoerd. Dat is niet problematisch voor dit onderzoek omdat de werkwijze vooral bedoeld is om tot de agenda voor stap 4 te komen. Om ervaring op te doen met de werkwijze en om te kunnen bepalen of de werkwijze nog tot nieuwe inzichten leidt, is de werkwijze ook toegepast op een aantal projecten waarvan al een eerste versie van de PSA was opgesteld. De architecten hebben hun bevindingen vastgelegd in rapportage-templates. Deze rapportages zijn terug te vinden in de Audit Trail, in Bijlage 1 onder het kopje Taking Action.

Affinity Portal

Ja

Ja

Nee

1

CRM/BRM Plateau 2

Ja

Ja

Ja

4


Ja

Nee

Ja

4

Debiteurensysteem

Ja

Ja

Nee

2

Nieuw Leven

Ja

Ja

Ja

3

Optimalisatie Processen Claims Direct

Ja

Ja

Nee

3

Project

Opmerkingen

Niet in duo uitgevoerd.

Tabel 7: Bijzonderheden projecten

7 8

Voor een overzicht zie: Tabel 8: Projecten en architecten in Bijlage 4 1=Idee, 2=Vooronderzoek, 3=Project Setup, 4=Project Uitvoering Pagina 33 van 65

Just Enough Architecture In Bijlage 8 zijn als voorbeeld de resultaten van de uitwerking van het project Affinity Portal opgenomen. Hierin is te zien welke aandachtspunten er door toepassen van de werkwijze gesignaleerd zijn, hoe deze in het DYA raamwerk zijn geplaatst en hoe deze aandachtspunten vervolgens in de Issue-Matrix zijn geplaatst. 4.3.2 Leereffecten uit de Taking Action fase Architectuurplaatjes Het blijkt handig om bij het doorlopen van deze stappen een aantal architectuurplaatjes op te stellen. Daarmee kan de problematiek inzichtelijk gemaakt worden zodat betrokkenen een beter inzicht krijgen. De plaatjes zijn bruikbaar om in de discussie met de projectbetrokkenen de situatie te schetsen en de plaatjes dragen bij aan begrip voor de Architectuur aandachtspunten. 4.4 Evaluating Action: De werkwijze geëvalueerd In de evaluatiefase is de toepassing van de werkwijze geëvalueerd en is vastgesteld wat de bruikbaarheid van de werkwijze is. In de volgende paragrafen wordt beschreven welke onderzoeksactiviteiten daarvoor zijn uitgevoerd, wat de resultaten waren en welke leereffecten er in de evaluatiefase opgetreden zijn. 4.4.1 Uitgevoerde onderzoeksactiviteiten In deze fase zijn allereerst de door de architecten in een template vastgelegde inhoudelijke resultaten van het toepassen van de werkwijze geanalyseerd. Vervolgens is de werkwijze in een evaluatiesessie met de betrokkenen geëvalueerd. Het doel daarvan was om te bepalen hoe het gebruik van de werkwijze in de praktijk is verlopen, hoe de architecten dat ervaren hebben en om na te gaan wat de bruikbaarheid van de werkwijze is en wat er eventueel nog aan verbeterd moet worden. Voorafgaand aan deze sessie hebben de architecten van drie projecten de aandachtspunten op de Issue-Matrix geplaatst, om te bepalen of dit nog tot nieuwe inzichten zou leiden. Daarnaast is een korte enquête met open en gesloten vragen voorgelegd aan de architecten over de bruikbaarheid van de werkwijze. Dit is gedaan om eventuele verschillen tussen de gezamenlijke evaluatiesessies en de individuele inzichten van de architecten te signaleren. De vragen van de enquête zijn opgenomen als Bijlage 10. De resultaten van de bespreking en de enquête zijn samengevoegd, geanalyseerd en in concept vastgelegd, opnieuw besproken met de architecten en waar nodig bijgesteld. De resultaten in de volgende paragrafen zijn gebaseerd op de documenten die voortkwamen uit de Evaluating Action fase. Deze documenten staan vermeld onder het gelijknamige kopje in Bijlage 1. Daarnaast zijn in Bijlage 11 de resultaten van de enquête opgenomen evenals een opsomming van alle opmerkingen uit de evaluaties en de open vragen van de enquête. 4.4.2 Onderzoeksresultaten: Bruikbaarheid voor scope en diepgang De bruikbaarheid van de werkwijze om scope en diepgang te bepalen wordt positief ervaren door de architecten. Illustratief in dit verband is dat de werkwijze in de praktijk al voor nieuwe projecten buiten het onderzoek wordt toegepast. Bij bruikbaarheid worden de volgende effecten onderkend:  Toepassen van de werkwijze blijkt tot een balans te leiden in aandachtspunten die al in de scope van de PSA moeten worden uitgewerkt en aandachtspunten die later in het project kunnen worden uitgewerkt (zie Tabel 13).  Bij aandachtspunten in de categorie “uitwerken in PSA” wordt vaker volstaan met uitwerking op het niveau van diepgang van “beleidslijnen”. Bij aandachtspunten die in het project moeten worden uitgewerkt, wordt vaker aangegeven dat uitwerking op het niveau van modellen nodig is (zie Tabel 13). De categorie “overnemen uit de Enterprise Architectuur” is in het onderzoek niet voorgekomen.

Pagina 34 van 65

Just Enough Architecture 

Het plaatsen van de aandachtspunten in het DYA raamwerk om de scope aan te geven werd door de architecten als praktisch ervaren. Dit geldt ook voor het onderscheid in diepgang aan de hand van de driedeling principes, beleidslijnen en modellen in het DYA raamwerk (zie Tabel 18).

4.4.3 Onderzoeksresultaten: Bruikbaarheid werkwijze Uit Tabel 17 en Tabel 18 uit de bijlagen is het volgende te concluderen over de bruikbaarheid van de werkwijze. Wanneer bruikbaar De werkwijze is vooral bruikbaar wanneer dit in of voorafgaand aan de eerste fase van een project wordt uitgevoerd. Ook is de werkwijze beter toe te passen wanneer er al informatie uit het vooronderzoek voorhanden is. Daarnaast dient er sprake te zijn van een proces waarbij architecten nauw betrokken worden bij de projecten die er (gaan) spelen. Wanneer niet bruikbaar De werkwijze is niet zinvol te gebruiken wanneer een project al in een vergevorderd stadium is en een PSA niet meer bijdraagt aan de keuzes in het project. Om de keuzes achteraf in kaart te brengen is de brede analyse niet nodig. Wanneer een project een zeer sterke gelijkenis vertoont met eerdere projecten (een jaarlijks terugkerende premieaanpassing bijvoorbeeld) en de tastbaarheid daardoor groot is, voegt het toepassen van de werkwijze eveneens weinig toe. Daarnaast wordt aangegeven dat de werkwijze niet zinvol is, wanneer de architect hierdoor zijn gezond verstand niet meer aanspreekt. 4.4.4 Onderzoeksresultaten: Bruikbaarheid voor het bepalen van prioriteiten Uit de tabellen in Bijlage 11 kan geconcludeerd worden dat de werkwijze bruikbaar is voor het stellen van prioriteiten. Het toepassen van de Issue-Matrix om waarschijnlijkheid en impact van veranderingen te bepalen heeft geholpen bij het bepalen van de indeling in de drie categorieën (Herleidbaar uit Enterprise Architectuur, Uitwerken in PSA, Uitwerken in project). Betrokken partijen, ook externen krijgen hierdoor een vollediger beeld van de situatie waarin een oplossing moet passen. Partijen kunnen daardoor betere beslissingen nemen over prioriteiten. 4.4.5 Onderzoeksresultaten: Breder kijken – witte vlekken De architecten geven in het onderzoek aan dat de werkwijze hun focus op het project verbreedt. Deze verbreding komt doordat de architecten het referentiemateriaal met o.a. de waardeketen en de proces- en informatiemodellen als uitgangspunt nemen en doordat ze van de DYA kolommen nagaan welke issues daar spelen. Illustratief is dat één van de architecten opmerkt (zie Tabel 18) dat toepassing van de werkwijze in een eerder stadium in zijn project diverse problemen had kunnen voorkomen. Het levert issues en informatie over witte vlekken op die anders niet gesignaleerd zouden worden en die nu een plek krijgen in de PSA. De werkwijze haalt Business Architectuur en de processen meer naar de voorgrond (Tabel 18), al blijkt uit het onderzoek dat aandachtspunten in het Informatie Architectuur domein de overhand houden (Tabel 14). Working in Pairs De architecten geven aan dat het met elkaar van gedachten wisselen, zoals uit de werkwijze volgt, tot aanvullende inzichten leidt. Uit de vergelijking van de rapportage-templates over hetzelfde project door twee verschillende architecten, blijkt dat ze verschillende aandachtspunten signaleren, waarmee ze elkaar aanvullen (zie bijvoorbeeld de templates AR012A1 en AR012A2 uit de digitale bijlagen). Eén van de architecten geeft expliciet aan een volgende keer parallel te willen voorbereiden, zoals dat bedoeld is in de werkwijze, in plaats van te reageren op de ingevulde templates door de collega architect.

Pagina 35 van 65

Just Enough Architecture 4.4.6 Onderzoeksresultaten: Communicatie Op een aantal onderdelen draagt de werkwijze bij aan verbetering van de communicatie. Toepassing van de werkwijze leidt ertoe dat een derde partij die ontwerpen maakt of bouwt een veel bredere set van uitgangsinformatie meekrijgt dan tot dusver het geval was (zie Tabel 18). Dit maakt dat ook die partij betere beslissingen kan nemen. Het doorlopen van de werkwijze brengt architecten al vroeg in contact met de andere betrokkenen, waaronder vertegenwoordigers uit business en projectleiding. Dit wordt als positief ervaren omdat er daardoor meer binding tussen Architectuur en project en organisatie ontstaat. Het vergroot het draagvlak voor werken onder Architectuur. Daardoor is men beter in staat projecten in de gewenste richting te sturen. Een van de architecten geeft in de gesloten vragen (Tabel 16) aan dat de werkwijze niet heeft bijgedragen aan de communicatie. Bespreking achteraf leert dat dit om een project ging waarvan de uitvoering al begonnen was en de werkwijze “met terugwerkende kracht” is doorlopen. Hier viel dus weinig meer te communiceren. 4.4.7 Onderzoeksresultaten: Voorgestelde verbeteringen Uit het onderzoek naar de toepassing in de praktijk komt een aantal mogelijke verbeteringen naar voren die de bruikbaarheid ten goede komen (zie Tabel 17 en Tabel 18).  De vraag 'wat spreekt er voor zich, en wat niet' lijkt overbodig. De issues weerspiegelen de zaken die aandacht vergen. Hiermee is de scheiding 'wat spreekt er voor zich en wat niet' eigenlijk al gemaakt.  Niet alle punten die met behulp van de werkwijze worden gesignaleerd krijgen een plek in de aandachtspuntenlijst. Het toevoegen van een check op de consistentie, als extra stap in de werkwijze zou dat kunnen verhelpen.  De vragen uit de checklist worden niet allemaal op dezelfde wijze uitgelegd. Een aantal hints zou op zijn plaats zijn. Dit blijkt onder andere uit de verschillen in gesignaleerde issues tussen de ene architect en de andere voor hetzelfde project, zoals in paragraaf 4.4.5 werd aangegeven.  De Issue-Matrix was niet opgenomen in de eerste stap, waardoor deze niet gehanteerd kon worden als illustratie bij de discussies in stap 2. Er wordt voorgesteld het invullen van de matrix op te nemen als laatste activiteit van stap 1, waarna er in stap 2 over kan worden gediscussieerd.  Voorgesteld wordt de richtlijnen voor Beschikbaarheid Integriteit en Beveiliging (BIV classificatie) toe te voegen aan het referentiemateriaal. Daarmee wordt een andere invalshoek toegevoegd aan het repertoire.  De stappen om te komen van de bepalende factoren tot de diepgang voor de aandachtspunten, verdient een concretere uitwerking. In de huidige werkwijze geven sommige factoren wel een indicatie voor verhoogde diepgang (zoals het aantal raakvlakken), maar als er geen concreet uit te werken aandachtspunt aan verbonden is, raakt die indicatie buiten beeld in het vervolgtraject. 4.4.8 Aanbevelingen voor inbedding in de organisatie Uit de evaluatie volgt een aantal zaken dat te maken heeft met de inbedding van de werkwijze in de organisatie:  De werkwijze is door de betrokken als een nuttige toevoeging ervaren. Uitvoering van de werkwijze kost wel tijd en capaciteit. Daarom wordt aanbevolen om hiervoor structureel tijd in te plannen in de initiatiefase van projecten.  Aanbevolen wordt de werkwijze op te nemen in de standaardprocessen van de afdeling Projectmanagement. Daarmee gepaard gaand kan een presentatie van de werkwijze in het werkoverleg van de projectleiders en Informatie Analisten worden voorzien.  Aanbevolen wordt de suggesties ter verbetering uit de voorgaande paragraaf te bestuderen en door te voeren.  De werkwijze is een beperkt aantal keren uitgevoerd en nog niet geëvalueerd na de afronding van een project. Aanbevolen wordt de werkwijze iteratief te verbeteren en Pagina 36 van 65

Just Enough Architecture zodra de gelegenheid zich voordoet een evaluatie uit te voeren voor een project na stap 4. 4.4.9 Leereffecten uit de Evaluating Action fase Issue-Matrix direct toepasbaar Tijdens een van de evaluatiesessies werd gevraagd of de architecten iets moesten vinden van een applicatie die een businessafdeling zelf had uitgezocht. De architecten hebben dit vraagstuk in de Issue-Matrix geplaatst en kwamen tot de conclusie dat de kans op voortschrijdend inzicht wellicht groot was, maar dat de impact zeer gering zou zijn. Daarop werd besloten dit issue geen verdere aandacht te schenken. De Issue-Matrix kan dus ook gebruikt worden om los van de werkwijze te bepalen of een vraagstuk geagendeerd moet worden. PSA of Solution Architectuur Een discussie die tussen de architecten nog wel eens terugkwam is of er in de PSA niet te gedetailleerd een oplossingsrichting wordt beschreven, omdat oplossingen niet thuis zouden horen in een PSA. Door architectuurvraagstukken te agenderen op basis van de nieuwe werkwijze is deze discussie niet meer relevant. Door het volgen van de werkwijze wordt bepaald of iets belangrijk genoeg is om voor het project uit te werken in de PSA of dat het later kan. Principes, Beleidslijnen, Modellen (DYA) De discussie over aandachtspunten en hun plek in het DYA raamwerk bracht aan het licht dat niet iedereen hier hetzelfde beeld bij had. Een korte discussie leidde tot een gedeeld beeld van wat onder de drie rijen in het DYA raamwerk te verstaan.

Pagina 37 van 65


5

Conclusies en aanbevelingen

In deze paragraaf wordt de centrale onderzoeksvraag beantwoord en worden de deelvragen beantwoord. Centraal stond de vraag: Welke factoren zijn bepalend voor de benodigde scope en diepgang van een Project Start Architectuur, hoe kunnen deze factoren uitgewerkt worden in een werkwijze om de agenda van de architecten vast te stellen en wat is in de praktijk daarvan de bruikbaarheid?

Om deze vraag te kunnen beantwoorden, is in dit onderzoek een aantal deelvragen geformuleerd rondom de onderwerpen scope en diepgang, werkwijze, bruikbaarheid, Architectuur werkwijze en methode van onderzoek. In de volgende paragrafen volgen eerst per onderwerp de conclusies van het onderzoek en daarna de aanbevelingen voor de inbedding van de werkwijze in de organisatie en de aanbevelingen voor nader onderzoek. 5.1 Bepalende factoren voor scope en diepgang Dimensies van scope en diepgang Uit het onderzoek zijn de kolommen van het DYA raamwerk naar voren gekomen als dimensies van scope, de rijen van het DYA raamwerk geven de diepgang aan. Ook Time Horizon en Enterprise Scope zijn als dimensies van scope opgenomen in de werkwijze. Factoren van invloed op scope en diepgang Naast de in het literatuuronderzoek gevonden factoren tastbaarheid en de waarschijnlijkheid en de impact van eventueel voortschrijdend inzicht is er in het praktijkonderzoek een reeks factoren gevonden die scope en diepgang van een Project Start Architectuur bepalen. Deze zijn voor de werkwijze onderverdeeld in vier categorieën:  Factoren gerelateerd aan het doel van de PSA en het Project:  Factoren in verband met raakvlakken  Factoren gerelateerd aan tastbaarheid  Factoren in verband met risico van toekomstige veranderingen Het volledige overzicht van de gevonden factoren is opgenomen in Tabel 5. Het onderzoek heeft geen “formule” opgeleverd die de factoren omrekent naar een getal voor scope en diepgang. 5.2 Een werkwijze om de agenda te bepalen Werkwijze Het onderzoek heeft tot een werkwijze geleid die uit drie elementen bestaat: 1. Stappenplan in vier stappen 2. Checklist 3. Organisatiespecifiek referentiemateriaal. Stappen Met een werkwijze in vier stappen is het mogelijk gebleken de relevante factoren in kaart te brengen. Hiermee kunnen scope en diepgang van de architectuuraandachtspunten evenals eventuele witte vlekken in kaart worden gebracht. In de werkwijze brengen de architecten achtereenvolgens de aandachtspunten in kaart, nemen deze met elkaar door, waarna de projectomgeving betrokken wordt voor nadere afstemming over scope en diepgang en het vaststellen van de agenda. Vervolgens wordt de PSA opgesteld conform die agenda. Issue-Matrix om prioriteiten en agenda te bepalen Uit het toepassen van de werkwijze volgt een aantal uit te werken aandachtspunten. Het plaatsen van deze aandachtspunten, in een Issue-Matrix draagt bij aan het opstellen van een agenda voor de in de Project Start Architectuur uit te werken aandachtspunten. In de IssuePagina 38 van 65

Just Enough Architecture Matrix worden de impact van een mogelijke toekomstige verandering en de waarschijnlijkheid daarvan weergegeven. Op basis hiervan kan de agenda worden opgesteld. 5.3 Bruikbaarheid De bruikbaarheid zoals die ervaren wordt, is in Action Research een pragmatische basis om de bruikbaarheid van de resultaten van het onderzoek vast te stellen (Baskerville en WoodHarper 1996). Om de bruikbaarheid vast te stellen is in de Evaluating Action fase de door de architecten ervaren bruikbaarheid onderzocht. Bruikbaarheid voor scope en diepgang De bruikbaarheid van de werkwijze om scope en diepgang te bepalen wordt positief ervaren door de architecten. Het zorgt voor een balans in aandachtspunten die al in de scope van de PSA moeten worden uitgewerkt en aandachtspunten die later in het project kunnen worden uitgewerkt. Daarbij leidt de werkwijze tot een keuze voor minder diepgang bij aanvang van de PSA en voor meer diepgang verder in het project. De DYA indeling in de rijen Principes, Beleidslijnen en Modellen wordt daarbij door de architecten bruikbaar genoemd. Bruikbaarheid werkwijze De werkwijze is vooral bruikbaar wanneer ze in of voorafgaand aan de eerste fase van een project wordt uitgevoerd. De aanwezigheid van informatie uit het vooronderzoek en een goede integratie van de architecten in het projectenproces dragen positief bij aan de bruikbaarheid van de werkwijze. De werkwijze voegt weinig toe wanneer een project al in een vergevorderd stadium van realisatie is of wanneer er sprake is van weinig nieuwe materie in het project. Bruikbaarheid voor het bepalen van prioriteiten De werkwijze is bruikbaar voor het stellen van prioriteiten. Het toepassen van de Issue-Matrix om waarschijnlijkheid en impact van veranderingen te bepalen draagt bij aan het bepalen van de indeling in de drie categorieën (Herleidbaar uit Enterprise Architectuur, Uitwerken in PSA, Uitwerken in project). Betrokkenen kunnen daardoor betere beslissingen nemen over de prioriteiten van de aandachtspunten en de agenda voor het uitwerken ervan. Breder kijken – witte vlekken Het toepassen van het referentiemateriaal dat bij de werkwijze hoort, het werken in tweetallen en het nalopen van de scope dimensies van het DYA raamwerk, aangevuld met de dimensies Time Horizon en Enterprise Scope stimuleren een brede kijk op de materie bij de architecten. Deze brede kijk zorgt ervoor dat witte vlekken tijdig gesignaleerd worden en dat de Informatie Architectuur focus van de architecten in het onderzoek wordt verbreed. Communicatie Het toepassen van de werkwijze zorgt voor een betere afstemming tussen de architecten en de omgeving waarin zij opereren. Dit vergroot het draagvlak voor Architectuur en zorgt ervoor dat projecten zich beter laten sturen door Architectuur. Voorgestelde verbeteringen Er kan een aantal verbetering worden aangebracht om de bruikbaarheid van de werkwijze te vergroten. De belangrijkste verbeteringen zijn:  het toevoegen van een check op de consistentie,  het toevoegen van een aantal hints bij vragen die door de architecten verschillend worden uitgelegd en  het aanbrengen van een concretere verbinding tussen het signaleren van bepalende factoren voor diepgang en de uitwerking van de aandachtspunten met de vereiste diepgang. Deze verbeteringen zijn in dit onderzoek niet nader uitgewerkt.

Pagina 39 van 65

Just Enough Architecture 5.4 Over architectuur: Bottom Up Architectuur Architectuur geeft richting aan de ontwikkelingen in een organisatie. Ook in een situatie van Bottom Up architectuur, zoals in de onderzochte organisatie, kan het werken met Project Start Architecturen bijdragen aan het bereiken van de Architectuur doelstellingen, zoals het zorgen voor coherentie en het bijdragen aan de ontwikkelsnelheid van de organisatie. Juist in een Bottom Up situatie, is het belangrijk om aandacht te schenken aan de scope en diepgang van een PSA omdat het grootste deel van de beleidslijnen en modellen, niet voorhanden is maar in beperkte tijd en met beperkte capaciteit uitgewerkt moet worden. Uit de diagnosefase blijkt dat voor het onderzoek de architect in overleg met de projectleiding bepaalde met welke diepgang en scope en met welke prioriteit de aandachtspunten voor de PSA werden uitgewerkt. Hierbij werd geen vast werkwijze gehanteerd. 5.5 Methode van Onderzoek Het onderzoek middels de vier fasen van de Action Research methode heeft ertoe geleid dat de onderzoeksvragen beantwoord konden worden. Om de relevantie en zorgvuldigheid van het onderzoek te waarborgen is er een Researcher Client Agreement opgesteld, is aandacht besteed aan toetsing van buiten de onderzochte organisatie, zijn de codeerprincipes van de Grounded Action Research toegepast en zijn alle verslagen voorgelegd aan en van commentaar voorzien door de betrokkenen. 5.6 Aanbevelingen m.b.t. de inbedding van de werkwijze in de organisatie De werkwijze is door de architecten als goed bruikbaar ervaren. Aanbevolen wordt om:  de werkwijze op te nemen in de standaardprocessen van de afdeling Projectmanagement en dit uit te dragen aan de betrokkenen;  daarvoor structureel tijd in te plannen in de initiatiefase van projecten;  de suggesties ter verbetering uit dit onderzoek te bestuderen en door te voeren en aansluitend de werkwijze in een aantal iteraties te verbeteren. 5.7 Aanbevelingen voor verder onderzoek Bottom Up architectuur Hoe in de praktijk vanuit Project Start Architecturen de Enterprise en Domein Architectuur kunnen worden opgebouwd, verdient nader onderzoek. Uiteindelijk moet ook in de Bottom Up situatie een Domein en Enterprise Architectuur uitgewerkt worden. Het proces van het opstellen van de EA en DA vanuit de praktijk van de projecten komt in de geraadpleegde literatuur nauwelijks aan de orde. Onderzocht zou kunnen worden:  Welke aspecten spelen een rol in het proces om vanuit PSA tot EA en DA te komen en daadwerkelijk te bouwen aan een Enterprise Architectuur die de projecten ontstijgt?  Wat is er nodig om van concrete PSA richtlijnen en modellen te komen tot generieke richtlijnen en modellen voor de EA en DA?  Wat betekent het voor de bouwstenen van een PSA, wanneer deze als basis moeten dienen voor de EA of DA? Communicatie De architecten stellen dat de communicatie met Figuur 4: Bottom Up Architectuur de omgeving verbetert door toepassing van de werkwijze. Om over de aandachtspunten te communiceren zijn ze begonnen met het maken van architectuurplaatjes in de tekentechniek van Archimate en aan de hand van een artikel van Greefhorst en Roodenhuis (2009). Nader onderzocht zou kunnen worden op welke wijze en in welke mate de beschreven werkwijze voor betere communicatie zorgt en welke architectuurplaatjes daarbij voor toegevoegde waarde zorgen. Pagina 40 van 65


6

Reflectie op het onderzoek

Onderzoeksafbakening De keuze voor Architectuur komt voort uit mijn werkzaamheden op dat vlak en de behoefte die er in de organisatie is om Architectuur te professionaliseren. Het oorspronkelijke idee was om “architectuur als doel op zich” als uitgangspunt te nemen. Na een omweg via “architectuur en innovatie” was medio april de verwarring compleet. Eind april werd haalbaarheid een belangrijk criterium en heb ik alles gestript tot ik uitkwam op het onderzoek naar het bepalen van scope en diepgang. Aanleiding hiervoor waren concrete situaties in de organisatie waarbij projecten dringend op PSA’s zaten te wachten en de architecten aangaven moeite te hebben de juiste keuzes te maken. Keuzes in de theorieën Aanvankelijk stonden er in de literatuurlijst ook titels over innovatie, organisatiedynamica, kennismanagement en lerende organisaties. Alleen het laatste is in beperkte mate terug te vinden in dit onderzoek. Enerzijds heeft dit eenvoudig te maken met afbakenen. Anderzijds staan kennismanagement en organisatiedynamica wat verder van me af en speelt mee dat zowel de organisatie als ikzelf een voorkeur hebben voor pragmatiek boven theoretiseren. Ook het “spiral model” (Boehm 1998) dat aanvankelijk nog in scope was heb ik laten vallen. Het leverde weinig aanknopingspunten op voor Architectuur en sloot niet aan op de praktijk en belevingswereld van de architecten. Action Research De keuze voor Action Research is in hoofdstuk 2 en 3 al toegelicht evenals de keuze voor de indeling van de cycli. Action Research kan de status quo ter discussie stellen, dat had kunnen gebeuren wanneer ik na de diagnose fase alle “algemene” opmerkingen zoals weergegeven in Bijlage 5 een plek in het vervolg van het onderzoek had gegeven. Een vraag die dan voorbij had kunnen komen was “waarom houden sommige projecten zich niet aan de PSA?”. Om de haalbaarheid van het onderzoek niet in gevaar te brengen ben ik blijven focussen op de werkwijze voor scope en diepgang. Thesisonderzoek – Organisatieonderzoek Het was een groot plezier om samen met de architecten de architectuurpraktijk onder handen te nemen. Op een aantal momenten waren de architecten in de organisatie al verder dan ik met de plannen was. Ik was nog aan het puzzelen op de precieze vraagstelling en op de procedures van de Action Research. Zij wilden al beginnen met de werkwijze. Het was echter mijn taak om dat proces in de juiste banen te leiden, zodat de uitkomsten bruikbaar waren voor deze thesis. Dit is het verschil tussen het “Core Action Research project” en het “Thesis Action Research project” (Zuber-Skerritt en Perry 2002). Dat eerste liep als het ware vanzelf door het enthousiasme van de architecten, aan het tweede heb ik zelf hard moeten trekken. Proces versus inhoud In de eerste sessies liepen proces (werkwijze ontwikkelen) en inhoud (specifieke Architectuur issues en projectvragen) door elkaar heen. Deels lag dit aan mijn voorbereiding van de eerste gesprekken. Het ligt ook aan de neiging van de architecten om de inhoud in te willen duiken. Ik ben me beter voor gaan bereiden en ik heb het overleg over het afstudeerproject buiten de reguliere overleggen geplaatst. Aan het eind van het project lukte het daarmee beter om inhoud en proces te scheiden. Last minute evaluatie Het laatste deel van de template waarin toepassing van de werkwijze werd vastgelegd, was de evaluatie van de toepassing van de werkwijze. Deze is slechts zeer beperkt ingevuld en de evaluatie ging in de helft van de gevallen niet over de werkwijze, maar over de inhoud van het project. Om aanvullend materiaal te hebben op de mondelinge evaluatiesessie is een lastminute enquête ingelast en uitgevoerd naar de bruikbaarheid en naar verbetersuggesties. Pagina 41 van 65


Actoren in het onderzoek Op een aantal momenten heb ik getwijfeld over het betrekken van derden en dan vooral projectleiders bij het onderzoek. Zowel bij het uitwerken van de werkwijze als bij de evaluatie hadden de projectleiders voor een alternatieve blik kunnen zorgen. Dat ze desondanks niet betrokken zijn heeft twee redenen. Het was planningstechnisch nauwelijks mogelijk meer partijen te betrekken en de focus van het onderzoek lag op een werkwijze die de architecten kunnen toepassen en die voor hen bruikbaar moet zijn. Gezond verstand blijven gebruiken Eén van de architecten schreef in de evaluatie: “Voor alle werkwijzen vind ik gelden dat er altijd een gezonde dosis pragmatiek toegepast moet worden. Werkwijzen moeten niet gaan leiden tot plichtsmatige invuloefeningen.” Deze gedachte heeft voor mij ook meegespeeld bij besluit de vragen in de checklist niet concreter uit te werken en ook geen rekenformule te ontwikkelen voor scope en diepgang in de werkwijze. De werkwijze moet de architecten helpen zelf na te denken en draagt daarvoor een heel scala aan onderwerpen aan. Beperkingen als gevolg van de doorlooptijd van het onderzoeksproject De bruikbaarheid van de werkwijze is in de projecten vastgesteld tot en met stap 3. Doordat in geen van de projecten tijdens het onderzoek een PSA is afgerond, heeft er geen onderzoek plaats kunnen vinden na stap 4, de oplevering van een PSA aan het project. Voor de bruikbaarheid is ook omwille van de haalbaarheid afgegaan op de opinie van de architecten. Wat de bijvoorbeeld de projectleiders ervan vonden is niet onderzocht. Er is maar één Action Research cyclus uitgevoerd. De werkwijze is zodoende niet geëvolueerd aan de hand van toepassing in de praktijk. Documentkwaliteit Aspecten van documentkwaliteit en aspecten rondom bruikbaarheid liepen aanvankelijk door elkaar heen. Ik heb ze uiteindelijk niet opgenomen in de evaluatie omdat in het hele onderzoek de aandacht naar de werkwijze zelf en niet naar de vastlegging in een template ging. In de online enquête is er wel naar gevraagd, maar de resultaten zijn niet gebruikt.

Pagina 42 van 65


Reflectie op de bruikbaarheid van buiten de onderzochte organisatie Het onderzoek is uitgevoerd in slechts één organisatie waar de Architectuur Bottom Up wordt opgebouwd en waar Architectuur een nog onvolwassen vakgebied is. Terughoudendheid is daarom geboden bij het overnemen van de werkwijze in andere organisaties. Toepassing van de werkwijze is een manier om te komen tot een plan voor een Project Start Architectuur. Daarmee is de werkwijze ook in andere organisaties toepasbaar waar PSA’s gemaakt worden. Vooral wanneer een organisatie met PSA’s werkt waarin niet alleen bestaande richtlijnen worden opgenomen, maar waarin ook nieuwe issues worden uitgewerkt, kan de werkwijze helpen bij het bepalen van de vereiste scope en diepgang en het stellen van de prioriteiten. Dit doet zich vooral voor in situaties van Bottom Up Architectuur. De Issue-Matrix kan ook buiten de context van een PSA gehanteerd worden bij het bepalen van de prioriteit van verzoeken die aan de architecten voorgelegd worden en die de inzet van schaarse capaciteit vereisen. De werkwijze structureert de stappen die de architect aflegt, het koppelt hem aan een collega architect en leidt hem langs de relevante vragen, langs de relevante referentiedocumenten en langs de andere bij het project betrokkenen. Dit betekent dat de werkwijze eraan bijdraagt dat zowel beginnende architecten als architecten die nieuw zijn in een organisatie, snel ingewerkt raken en daarmee eerder bijdragen aan de ontwikkelsnelheid van de organisatie. De werkwijze lijkt daarmee ook geschikt om bijvoorbeeld door een Informatieanalist te worden toegepast.

Pagina 43 van 65


7

Literatuur

Argyris, C. en D. A. Schon (1978). Organizational Learning: A theory of action perspective, AddisonWesley. Argyris, C. en D. A. Schon (1996). Organizational Learning II: Theory, Method, and Practic, Addison Wesley. Baskerville, R. en J. Pries-Heje (1999). "Grounded action research: a method for understanding IT in practice." Accounting, Management and Information Technologies 9(1): 1-23. Baskerville, R. L. en A. T. Wood-Harper (1996). "A critical perspective on action research as a method for information systems research." Journal of Information Technology 11(3): 235 - 246. Boehm, B. (1998). "Using the WinWin Spiral Model: A Case study." Computer 31(7): 11. Coghlan, D. (2001). Doing Action Research in Your Own Organization, Sage. Davison, R. M., M. G. Martinsons, e.a. (2004). "Principals of canonical action research." Information Systems Journal 14: 65-86. de Boer, E. (2009). Effect of the Document Quality of the Project Start Architecture on Project Success. Architecture in the Digital World. Nijmegen, Radboud University. Master. Eriksson, P. en A. Kovalainen (2008). Qualitative Methods in Business Research, Sage. Foorthuis, R. M. en S. Brinkkemper (2007). "A Framework for Local Project Architecture in the Context of Enterprise Architecture." Journal of Enterprise Architecture 3(4). Foorthuis, R. M. en S. Brinkkemper (2008). Best practices voor projecten onder enterprise Architectuur. Architectuur maakt de toekomst mogelijk: LAC boek 2008. C. M. Hendriks en J. A. Oosterhaven. Den Haag, Academic Service, SDU Uitgevers bv.: 147-155. Greefhorst, D., S. Rodenhuis, e.a. (2009). "Een pragmatische aanpak voor Enterprise Architectuur." Hendriks, C. M. en J. A. Oosterhaven, Eds. (2009). Architectuur moet bijdragen Landelijk Architectuur Congres 2009. Den Haag, Academic Service. Lankhorst, M. e. a. (2005). Enterprise Architecture at Work Modelling, Communication and Analysis, Springer. Morsink, M. (1993). Van onderwerp naar onderzoeksontwerp. Bestuurskundes. Werkboek bestuurskundige vaardigheden. M. L. v. Muijen, UvA-PSCW Vakgroep bestuurskunde. Rijsenbrij, D., J. Schekkerman, e.a. (2004). Architectuur, besturingsinstrument voor adaptieve organisaties, Lemma. Robson, C. (2002). Real world research. Malden, Blackwell Publishing. Schekkerman, J. (1999). The (enterprise) Architecture Proces Cycle. LAC 1999. Amsterdam. TheOpenGroup (2009). TOGAF Version 9 The Open Group Architecture Framework. 2009, The Open Group. van den Berg, M., R. Blom, e.a. (2009). Wegwijzer voor methoden bij enterprise-architectuur, Van Haren Publishing. van den Berg, M. en M. van Steenbergen (2004). DYA Stap voor stap naar professionele enterprisearchitectuur, SDU Uitgevers bv. Wagter, R., M. van den Berg, e.a. (2001). DYA: Snelheid en samenhang in business- en ICTarchitectuur. Den Bosch, Tutein Nolthenius. Pagina 44 van 65


Zuber-Skerritt, O. en C. Perry (2002). "Action research within organisations and university thesis writing." The Learning Organization 9(4): pp. 171±179

Pagina 45 van 65


8

Bijlagen & Digitale Audit Trail

De belangrijkste bijlagen zijn in dit document opgenomen. Om onnodig papiergebruik te voorkomen zijn alle voor het onderzoek geproduceerde documenten op Cd-rom bijgevoegd. Dit zijn de documenten die in Bijlage 1 genoemd worden en waarnaar op een aantal punten in de tekst wordt verwezen. De geraadpleegde brondocumenten Bijlage 2 Bronnen Allianz / Architectuur artefacten zijn uit concurrentieoverwegingen buiten het dossier gehouden.

Pagina 46 van 65


Bijlage 1.

Audit Trail

Onderstaande documenten zijn opgenomen in de digitale bijlage. Ze geven een chronologisch overzicht van het verloop van het actieonderzoek. Diagnosing AR000a - Onderzoeksvoorstel What is Just Enough Architecture.doc AR000b - 20100520 Researcher - Client Agreement thesis JB.doc AR000c - 20100520 Researcher - Client Agreement akkoord opdrachtgever.doc AR001 - 20100601 Gespreksverslag bespreking thesis opzet CC en HL.doc AR001R1 - RE 20100601 Gespreksverslag bespreking thesis opzet CC en HLvan CC.doc AR001R2 - RE 20100601 Gespreksverslag bespreking thesis opzet CC en HLvan HL.doc AR002 - 20100519 Gespreksverslag Bespreking Onderzoeksopzet GJT.doc AR002R - Re 20100519 Gespreksverslag Bespreking Onderzoeksopzet GJT.doc AR003 - 20100512 Gespreksverslag Bespreking Onderzoeksopzet AP en RH.doc AR003R 20100514 Reactie AP en RH op gespreksverslag.doc

Planning Action AR004 - 20100610 Meeting ontwikkelen werkwijze verslag.doc AR004P - 20100610 Meeting ontwikkelen werkwijze.ppt AR004R1 - 20100702 Reactie CC op gespreksverslag.doc AR004R2 - 20100702 Reactie HL op gespreksverslag.doc AR005 - 20100618 Gespreksverslag bespreking werkwijze GJT.doc AR006 - 20100630 Gespreksverslag M. van den Berg - Sogeti.doc AR007P - 20100702 Meeting thesisgroep.ppt AR010 - 20100707 Gespreksverslag Architectuuroverleg commentaar AP.doc AR010 - 20100707 Gespreksverslag Architectuuroverleg.doc AR010A - Architectuuroverleg 7 juli 2010 agenda.doc

Taking Action AR011 - Rapportage template.doc AR012A1 - Rapportage project MDM-BRM AP.doc AR012A2 - Rapportage project MDM-BRM GJT.doc AR012B - Rapportage project Nieuw leven attacker versie 0 4.doc AR012C - Rapportage project schadebehandeling allsecur 0.2.doc AR012D - Rapportage project nieuw debiteurensysteem v1 0 (2).doc AR012E - Rapportage project DANS v1 0.doc AR012F - Bijlage.jpg AR012F - Rapportage project Affinity Portal.doc

Evaluating Action AR014 - Evaluatie template.doc AR015 - Issuematrix template.doc AR015 - Overzicht Issues en mapping.xls AR016b - Issuematrix CC.doc AR016c - Issuematrix JH.doc AR016d- Issuematrix HL.doc AR016e - Issuematrix AP.doc AR017 - Gespreksverslag Evaluatie werkwijze en Issuematrix.doc AR017 Evaluatiesessie.ppt AR017a - Evaluatiesessie.ppt AR017b - Gespreksverslag Evaluatie werkwijze en Issuematrix.doc AR017c - Aanvullingen opmerkingen en reacties op verslag.doc AR017d - Evaluatie uitwerking van verslag naar tabelvorm.doc AR018 - Mindmap Evaluatie.doc AR018 - Mindmap Evaluatie.jpeg AR018 - Mindmap Evaluatie.mmap AR018 - Van evaluatieopmerkingen naar conclusies.doc

Pagina 47 van 65


Bijlage 2. Bron Bron-000 Bron-001 Bron-002 Bron-003 Bron-004 Bron-005 Bron-006 Bron-007 Bron-008 Bron-009 Bron-010 Bron-011 Bron-012 Bron-013 Bron-014 Bron-015 Bron-016 Bron-017 Bron-018 Bron-019 Bron-020 Bron-021 Bron-022 Bron-023 Bron-024 Bron-040 Bron-041 Bron-042 Bron-043 Bron-044 Bron-045 Bron-046 Bron-047 Bron-048 Bron-049 Bron-050 Bron-051 Bron-052 Bron-053 Bron-054 Bron-055 Bron-056 Bron-057 Bron-058 Bron-059 Bron-060 Bron-061 Bron-062 Bron-063 Bron-064 Bron-065 Bron-066 Bron-067 Bron-068 Bron-069 Bron-070 Bron-071 Bron-072

Bronnen Allianz / Architectuur artefacten Omschrijving 000 - 20100520 Researcher - Client Agreement thesis J Boer.doc 20090604 Notulen Architectuur overleg nieuwe stijl.doc 20090917 Notulen Architectuur overleg nieuwe stijl.doc 20091001 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20091001.doc 20091015 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20091015.doc 20091112 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20091112.doc 20091126 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20091126.doc 20100107 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100107.doc 20100204 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100204.doc 20100304 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100304.doc 20100318 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100318.doc 20100428 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100428.doc 20100526 Notulen Architectuur overleg nieuwe stijl.doc Agenda ANG Architectuuroverleg 20100526.doc 20100623 Notulen Architectuur overleg nieuwe stijl.doc 20100707 Notulen Architectuur overleg nieuwe stijl.doc 200906 Pressure Cooker - presentatie sessie 1.ppt 200906 Pressure Cooker - presentatie sessie 2.ppt 200909 - Pressure Cooker Sessie 3 - Datawarehouse ambitieniveau.ppt 200909 - Pressure Cooker Sessie 3 - Output Management ambitieniveau.ppt 200909 - Pressure Cooker Sessie 3 - Portal ambitieniveau.pptx 200909 - Pressure Cooker Sessie 3 - Presentatie en agenda.ppt 200909 - Pressure Cooker Sessie 3 - transactieloket ambitieniveau.pptx 200909 Eindpresentatie Pressurecooker Architectuur.pptx 20091102 IT en Architectuur v02.doc 20091116 Kickstart PSA workshop - domeinarchitecturen te stellen vragen per onderwerpen.doc 20091116 KickStart PSA workshop - presentatie.ppt 20091116 Kickstart PSA workshop - uitwerking Datawarehouse omgeving.doc 20091116 Kickstart PSA workshop - uitwerking Outputmanagement.doc 20091116 Kickstart PSA workshop - uitwerking Portal en Toegang.doc 20100409 ANG Architectuur en thesis presentatie #JB .ppt 201006 Presentatie Corporate DWH.ppt 201006 Presentatie Document en Outputmanagement.ppt 201006 Presentatie Domeinarchitectuur Portal & Toegang V0.3 .ppt 201006 Presentatie Transactieloket_v0.1[1].ppt Masterplan 021109 Architectuur.ppt PID Datawarehouse Aantekeningen aanpak v0.3.doc PID Datawarehouse omgeving v0.2.doc PID Outputmanagement Aandachtpunten .doc PID Outputmanagement Input Principes en richtlijnen.doc PID Outputmanagement Input Projectafhankelijkheden Architectuur.doc PID Portal en Toegang Projectplanning.xls PID Portal en Toegang v0.4 #jb .doc PID Portal en Toegang v0.5.doc PID Transactieloket notities.doc PID Transaktieloket v0.2.doc PID Transaktieloket v0.3.doc PSA DANS v0 1 #jb.doc 20100318 Memo PSA MDM Reactie ANG Arch Overleg.doc

Pagina 48 van 65


Bijlage 3.

Begrippen en afkortingen

Begrip Action Research

Architectuur

Bottom Up architectuur

BRM/CRM Domein Architectuur (EA)

DYA Enterprise Architectuur (EA)

Grounded Action Research Issue-Matrix

Project Start Architectuur (PSA)

Tastbaarheid TOGAF en ADM

Omschrijving Onderzoeksbenadering echte problemen in sociale systemen worden onderzocht, in cycli van diagnose of probleemidentificatie, planning, actie en evaluatie. Het onderzoek draagt bij aan de ontwikkeling van kennis in de sociale wetenschappen en aan de alledaagse praktijk. Een consistent geheel van modellen en principes, dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie. Een werkwijze waarbij de Enterprise Architectuur en Domein Architectuur worden opgebouwd, uitgaande van de keuzes in projecten. Project voor Broker Relatie Management en Customer Relatie Management. Een Domein Architectuur (DA) wordt gedefinieerd op basis van een specifieke groep van producten, diensten, processen of functies. Een domein kan de organisatie als geheel doorsnijden, zoals het “Outputmanagement” domein in de organisatie van dit onderzoek, maar kan zich ook richten op een specifiek product of proces. DYA (Dynamische Architectuur) is een architectuurmethode ontwikkeld vanuit Sogeti. Een Enterprise Architectuur (EA) beschrijft de uitgangspunten voor de inrichting van de gehele onderneming op het overkoepelende niveau van de gehele organisatie en beschouwt daarbij structuur, bedrijfsprocessen, informatiesystemen en infrastructuur. De Enterprise Architectuur focust zich op de essentie van de onderneming en is daardoor relatief stabiel Specifieke vorm van Action Research waarbij methoden van de Grounded Theory worden gehanteerd om vanuit kwalitatieve gegevens tot theorievorming te komen. Een matrix waarin issues of aandachtspunten geplaatst kunnen worden afhankelijk van  de waarschijnlijkheid dat inzichten in de toekomst leiden tot het terugkomen op eerder gemaakte keuzes en  de impact van het terugkomen op die keuzes. De PSA is de vertaling van de algemene architectuurprincipes en -modellen naar projectspecifieke richtlijnen. Het doel van de PSA is om een project een concrete, relevante en praktisch realiseerbare scope mee te geven zodat het projectresultaat past in het grotere geheel van de organisatie De mate waarin het voor de betrokkenen bij een project duidelijk is wat er in het project gerealiseerd moet worden. The Open Group Architecture Framework. Architectuurmethode ontwikkeld vanuit The Open Group. ADM is de Architecture Development Method die bij TOGAF hoort.

Pagina 49 van 65


Bijlage 4.

Projecten

Project

Architect Sparring Aandachtsgebied partner

Affinity Portal:

CC

AP

Portals & Security

CRM/BRM Plateau 2

AP

GJT

Datawarehouse


HvdL

JB

Datawarehouse

Debiteurensysteem

HvdL,

AP

Transactieloket

Nieuw Leven

RH

CC

Alle

Optimalisatie Processen Claims Direct RH

AP

Outputmanagement

Tabel 8: Projecten en architecten

Pagina 50 van 65


Bijlage 5.

Van interviews naar checklist: Coding Tables

Bron

Wat

Categorie

001/001R

Als een EA/DA ontbreekt moet PSA richting ontwerp gaan / dieper uitwerken dan met EA/DA

Factoren

001/001R

Beschikbaarheid van een referentiekader bepaalt diepgang

Factoren

001/001R

Beschikbare tijd voor PSA bepaalt mede hoe diep / breed je kunt gaan

Factoren

001/001R

Doel bepaalt diepgang

Factoren

001/001R

Doelgroep bepaalt diepgang

Factoren

001/001R

Enterprise Scope volgt vaak uit opdracht

Factoren

002/002R

Mate waarin sturing noodzakelijk is bepaalt scope/diepgang.

Factoren

002/002R

Vanzelfsprekende richtlijnen hoeven niet in de PSA opgenomen te worden.

Factoren

001/001R

Processen wel / niet uitwerken

Factoren

004/004P

Ook de aspecten m.b.t. mogelijke kosten spelen een rol bij het bepalen van scope en diepgang op enig moment.

Factoren

005

Het begrip complexiteit als factor in de analyse opnemen? o.a. aantal componenten, hoeveelheid interacties daartussen etc

Factoren

001/001R

Extern Ontwerp van een project vereist meer diepgang in de PSA

Factoren

001/001R

Externe realisatie van een project vereist meer diepgang in de PSA

Factoren

001/001R

Raakvlak met ander project of domein. Meer raakvlakken betekent meer uitwerken.

Factoren

001/001R

Raakvlak met andere systemen. Meer raakvlakken betekent meer uitwerken. Raakvlakken = Interfaces

Factoren

005 004/004P

Een groot deel van de issues is te herleiden tot raakvlakken met de domeinen van Factoren de andere architecten.

003/003R

De consequenties van een mogelijke verkeerde keuze in de PSA bepaalt mede de Factoren scope/diepgang.

Literatuur

Impact van een verandering

Factoren

Literatuur

Waarschijnlijkheid van een verandering

Factoren

001/001R

Hoe meer onduidelijkheid op een bepaald gebied des te dieper moet het uitgewerkt worden.

Factoren

001/001R

Nieuwe materie vereist extra diepgang

Factoren

001/001R

Vakvolwassenheid/ervaring van de doelgroep op het domein van de Architectuur Factoren helpt bepaalt mede hoe breed / hoe diep .(meer ervaring = minder diep uitwerken)

Literatuur

Tastbaarheid

Factoren

Literatuur

Enterprise Scope

Dimensies

Literatuur

Architecture Domains

Dimensies

Literatuur

Time Horizon

Dimensies

Literatuur

Vertical Scope

Dimensies

001/001R

Input van derden “(gecombineerd met gezond verstand)

Werkwijze

001/001R

Vakvolwassenheid/ervaring op het domein van de Architectuur helpt om makkelijker te bepalen hoe breed / hoe diep .

Werkwijze

001/001R

Advies van derden / externen betrekken

Werkwijze

001/001R

Drie soorten “aanbevelingen in PSA’  Direct in te vullen vanuit EA/SA  Uit te werken in latere fase in project  Uit te werken direct bij opstellen PSA

Werkwijze

001/001R

DYA raamwerk doorlopen en van de cellen bepalen in welke cellen een verkeerde Werkwijze keuze nu, tot ongewenste consequenties in de toekomst leidt.

001/001R

DYA Raamwerk doorlopen en vaststellen in welke cellen er veel onduidelijkheid zit, of dat een probleem is en op welk moment in project er wel duidelijkheid moet zijn.

Werkwijze

Pagina 51 van 65

Just Enough Architecture Bron

Wat

Categorie

001/001R

Een PSA zou een aantal versies moeten kennen .

Werkwijze

001/001R 002/002R

Sparren en plaatjes tekeken met de collega architecten

Werkwijze

002/002R

PSA ontwikkelt zich vaak in iteraties van business- naar informatie- naar technische Architectuur. Werken met versies!

Werkwijze

003/003R

Analyse leidt tot overzicht van issues en een kalender die aangeeft wanneer in een project de betreffende issues moeten zijn uitgewerkt.

Werkwijze

003/003R

Bij het opstellen van architecturen altijd de processen mee beschouwen.

Werkwijze

003/003R

Eerder betrokken raken bij projecten

Werkwijze

003/003R

Proces doordenken, omissies, knelpunten, inconsequenties vaststellen, toetsen aan beschikbare deel referentie architectuur

Werkwijze

003/003R

Selectief zijn in welke projecten wel en niet aandacht van Architectuur behoeven

Werkwijze

003/003R

Think big start small

Werkwijze

003/003R

Wanneer Architectuur laat betrokken wordt bij een project, blijft het zinvol om alle domeinen (DYA) te beschouwen.

Werkwijze

004/004P

De architect zorgt voor het vormgeven van de architectuurkaders en het in kaart Werkwijze brengen van de Architectuur issues bij de project-setup fase. Resultaat daarvan is de PSA

004/004P

Het lijkt handig te zijn te issues voor de PSA in drie categorieën: • Richtlijnen die je zo kunt overnemen uit de EA/DA of eerdere PSA’s (we hebben nog niet veel EA?DA) • Richtlijnen/modellen die je bij het opstellen van de PSA moet uitwerken ivm samenhang andere domeinen of risico. • Richtlijnen/modellen etc.die verder uitgezocht kunnen worden in project (Maar hoe borg je dan dat in de door het project te beschrijven

Werkwijze

004/004P

Het is nuttig om met een andere architect de issues van een project door te nemen om zo samen tot een completer beeld te komen en te toetsen welke er issues er nu relevant zijn en welke nog even kunnen wachten.

Werkwijze

005

Een eerste versie van de PSA is een soort heatmap van de plekken waarop het project als eerste duidelijkheid moet krijgen. Deze vragen zijn niet altijd beantwoord voordat de PSA start dus moeten ze in de PSA of in het Plan van Aanpak gesignaleerd worden.

Werkwijze

Literatuur

Raamwerk DYA biedt houvast om gestructureerd na te gaan welke elementen uitgewerkt moeten worden. Ook geschikt voor vastleggen resultaten

Werkwijze

Literatuur

Issue-Matrix Impact / Waarschijnlijkheid

Werkwijze

001/001R

Definitie van PSA is onduidelijk,

Algemeen

001/001R

In PSA moeten witte vlekken gesignaleerd worden

Algemeen

001/001R

Ontbreken Enterprise Architecture / Domein Architecture

Algemeen

001/001R

Ontbreken van een infrastructuur-architect

Algemeen

001/001R

Witte vlekken soms direct of soms later uitwerken

Algemeen

002/002R

De PSA zou in balans moeten zijn mbt modellen, principes, beleidslijnen

Algemeen

002/002R

Ervaring en skills van de architect bepalen wel hoe breed/diep de architect het domein moet beschouwen, en hoeveel tijd daarmee gemoeid is. Doel en doelgroep bepalen diepgang.

Algemeen

003/003R

Werken onder Architectuur staat hier nog in de kinderschoenen

Algemeen

004/004P

Beschikbaarheid van EA/DA maakt opstellen PSA eenvoudiger.

Algemeen

004/004P

Bij niet beschikbaarheid zijn van EA/DA levert de PSA de input voor EA/DA

Algemeen

004/004P

Dat wat voor de architect wellicht vanzelfsprekend is, is dat wellicht niet voor de gebruiker van een architectuurproduct.

Algemeen

004/004P

De architect speelt een inhoudelijke rol in het voortraject (sparringpartner) bij het tot stand komen van het project idee en project voorstel.

Algemeen

004/004P

De architect zorgt voor het bewaken, invullen en vormgeven van de architectuurkaders in de implementatie fase. Resultaat daarvan zijn nieuwe

Algemeen

Pagina 52 van 65

Just Enough Architecture Bron

Wat

Categorie

versies van de PSA PA, 004/004P

De architecten nemen in de regel niet de tijd uitgebreid op de eigen werkwijze te reflecteren.

Algemeen

004/004P

De PSA komt dan tot stand op basis van de beschikbare standaards, de minimaal vereiste eerste uitwerkingen en een set van “witte vlekken” die nader uitgewerkt moeten worden. Dat uitwerken gebeurt tijdens de projectuitvoering en leidt tot de Project Architectuur.

Algemeen

004/004P

Doel van een PSA kan ook zijn beslissing te nemen over planning en/of scope van Algemeen een project.

004/004P

Iedereen heeft blinde vlekken, het is zaak het proces zo te organiseren dat deze blinde vlekken toch ingevuld worden.

Algemeen

004/004P

Ook de frequentie waarmee een proces wordt uitgevoerd bepaalt mede de Architectuur van de oplossing.

Algemeen

004/004P

Ook wanneer de PSA uit te werken zaken constateert, kunnen vaak al richtlijnen meegeven zoals beschikbare standaards, voorschrift om geen doodlopende wegen / point of no returns passeren, vermijden van leveranciersafhankelijke keuzes etc.

Algemeen

004/004P

Wanneer de set-up zonder inzet van architecten is verlopen is de PSA werkwijze lastig te handhaven en ontstaat er snel een mismatch tussen de verwachtingen van de projectleider en dat wat de architect tijdig kan leveren.

Algemeen

Nr

Factor

Vraag tbv Checklist

REF-1


Welke processen uit de Allianz Value Chain?

REF-2


Welke aspecten uit het Target Operating Model?

REF-3


Welke aspecten uit de informatiemodellen en het applicatielandschap zijn?

DO-1

Doel van een PSA kan ook zijn beslissing te nemen over planning en/of scope van een project.

Welke beslissingen moeten er genomen worden op basis van de PSA t.a.v. planning, scope, budget, ….

DO-2

Beschikbare tijd voor PSA bepaalt mede hoe diep / breed je kunt gaan

Wanneer moet de eerstvolgende versie van de PSA af zijn en waarom?

DO-3

Doel bepaalt diepgang

Wat is het belangrijkste doel van de PSA op dit moment?

DO-4

Doelgroep bepaalt diepgang

Voor wie is deze versie van de PSA bestemd?

DO-5

Mate waaarin sturing noodzakelijk is bepaalt scope/diepgang.

Op welke punten is welke mate van sturing noodzakelijk?

DO-6

Vanzelfsprekende richtlijnen hoeven niet in de PSA opgenomen te worden.

Wat spreekt er voor zich? Wat niet?

DO-7

Ook de aspecten m.b.t. mogelijke Welke issues hebben mogelijk grote gevolgen voor de kosten spelen een rol bij het bepalen project/organisatie kosten? van scope en diepgang op enig moment.

RI-1

De consequenties van een mogelijke Op welke keuzes kun je moeilijk terugkomen? verkeerde keuze in de PSA bepaalt mede de scope/diepgang.

RI-1

De consequenties van een mogelijke Welke keuzes brengen investeringen met zich mee? verkeerde keuze in de PSA bepaalt

Pagina 53 van 65

Just Enough Architecture Nr

Factor

Vraag tbv Checklist

mede de scope/diepgang. RI-1

De consequenties van een mogelijke Welke keuzes hebben consequenties voor vervolgprojecten? verkeerde keuze in de PSA bepaalt mede de scope/diepgang.

RV-1


Welke raakvlakken zien we?

RV-1


Welke raakvlakken zien we tussen organisatieonderdelen?

RV-1


Welke raakvlakken zien we met de buitenwereld en ketenpartners?

RV-1


Welke raakvlakken zien we tussen dit project en andere projecten?

RV-1


Welke raakvlakken zien we tussen de verschillende systemen?

RV-2


Welke raakvlakken zien we tussen de IT Partners?

RV-2


Welke partijen zijn betrokken bij ontwerp en realisatie en hoe raakt dat elkaar?

RV-3

Extern Ontwerp van een project vereist meer diepgang in de PSA

Welke partijen zijn betrokken bij ontwerp en realisatie en hoe raakt dat elkaar?

RV-4

Een groot deel van de issues is te herleiden tot raakvlakken met de domeinen van de andere architecten.

Welke raakvlakken zien we tussen dit project en de architectuurdomeinen / aandachtsgebieden?

TB-1

Als een EA/DA ontbreekt moet PSA richting ontwerp gaan / dieper uitwerken dan met EA/DA

Voor welke aspecten kan er uit de EA/DA worden geput, voor welke niet?

TB-2

Processen wel / niet uitwerken

Welke processen worden geraakt door het project, in hoeverre is de inrichting daarvan nog onzeker, en in hoeverre heeft de inrichting van deze processen impact op de te kiezen oplossingen?

TB-3


Waar bevinden zich welke onduidelijkheden? Welke DYA cellen?

TB-4

Beschikbaarheid van een referentiekader bepaalt diepgang

Wat hebben we eerder op dit vlak gedaan? Wie hebben er wel al ervaring op dit vlak? Wat kunnen we uit Duitsland overnemen?

TB-5

Vakvolwassenheid/ervaring op het Hoe ervaren is de doelgroep van de PSA met de materie van het domein van de Architectuur helpt om project? makkelijker te bepalen hoe breed / hoe diep .

TB-6

Vakvolwassenheid/ervaring van de doelgroep op het domein van de Architectuur helpt bepaalt mede hoe breed / hoe diep .(meer ervaring = minder diep uitwerken)

Hoe ervaren is de doelgroep van de PSA met de materie van het project?

TB-7

Nieuwe materie vereist extra diepgang

Hoe ervaren is de organisatie met de materie van het project?

Pagina 54 van 65


Bijlage 6.

Concept werkwijze - Stappenplan

Stap 1: Inlezen en aandachtspunten verzamelen  Door twee architecten onafhankelijk van elkaar aan de hand van de eigen kennis en de beschikbare documentatie.  Aandachtspunten aan de hand van checklist in kaart brengen  Aandachtspunten een plek geven in Issue Matrix  Aandachtspunten projecteren in DYA Raamwerk  Van alle aandachtspunten vaststellen wanneer ze uitgewerkt moeten worden: 1. Direct herleidbaar uit Enterprise of Domein Architectuur 2. Direct bij aanvang PSA uitwerken 3. Later in het project uitwerken Stap 2: Toetsen met collega-architect  Elkaars bevindingen doornemen  Herzien: aandachtspunten een plek geven in DYA Raamwerk:  Herzien: Issue Matrix  Herzien: Van alle aandachtspunten vaststellen wanneer ze uitgewerkt moeten worden: 1. Direct herleidbaar uit Enterprise of Domein Architectuur 2. Direct bij aanvang PSA uitwerken 3. Later in het project uitwerken Stap 3: Toetsen breder in de organisatie  Bevindingen toetsen met de betrokkenen bij project, business, Projectleiders, Informatie analisten, derde partijen, informatiemanagers  Issue Matrix herzien  Herzien: Issue Matrix  Herzien: Van alle aandachtspunten vaststellen wanneer ze uitgewerkt moeten worden: 1. Direct herleidbaar uit Enterprise of Domein Architectuur 2. Direct bij aanvang PSA uitwerken 3. Later in het project uitwerken Stap 4: Uitwerken Project Start Architectuur  Materiaal tbv categorie “Direct herleidbaar” vertalen in principes/modellen voor het project  Materiaal tbv categorie “In de PSA uitwerken” verzamelen en uitwerken in principes/modellen voor het project  Punten tbv restcategorie voorzien van een inschatting van de inspanning en hier budget voor claimen bij projectleiding  PSA redigeren en toetsen met doelgroep(en) waaronder het projectteam.

(Voorgestelde veranderingen naar aanleiding van de Evaluating Action fase zijn geelgemaakt)

Pagina 55 van 65


Bijlage 7.

Concept Werkwijze - Checklist

Dimensies:  Vertical Scope bepalen  Enterprise Scope bepalen  Tijdshorizon bepalen  Domeinen bepalen Doel:  Welke beslissingen moeten er genomen worden op basis van de PSA t.a.v. planning, scope, budget, ….  Wanneer moet de eerstvolgende versie van de PSA af zijn en waarom?  Wat is het belangrijkste doel van de PSA op dit moment?  Voor wie is deze versie van de PSA bestemd?  Op welke punten is welke mate van sturing noodzakelijk?  Wat spreekt er voor zich? Wat niet?  Welke issues hebben mogelijk grote gevolgen voor de project/organisatie kosten? Tastbaarheid  Voor welke aspecten kan er uit de EA/DA worden geput, voor welke niet?  Welke processen worden geraakt door het project, is de inrichting daarvan nog onzeker, heeft de inrichting van deze processen impact op de te kiezen oplossingen?  Waar bevinden zich welke onduidelijkheden? Welke DYA cellen?  Wat hebben we eerder op dit vlak gedaan? Wie hebben er wel al ervaring op dit vlak? Wat kunnen we uit Duitsland overnemen?  Hoe ervaren is de doelgroep van de PSA met de materie van het project?  Hoe ervaren is de doelgroep van de PSA met de materie van het project?  Hoe ervaren is de organisatie met de materie van het project? Raakvlakken  Welke raakvlakken zien we tussen organisatieonderdelen?  Welke raakvlakken zien we met de buitenwereld en ketenpartners?  Welke raakvlakken zien we tussen dit project en andere projecten?  Welke raakvlakken zien we tussen de verschillende systemen?  Welke raakvlakken zien we tussen de IT Partners?  Welke partijen zijn betrokken bij ontwerp en realisatie en hoe raakt dat elkaar?  Welke partijen zijn betrokken bij ontwerp en realisatie en hoe raakt dat elkaar?  Welke raakvlakken zien we tussen dit project en de architectuurdomeinen / aandachtsgebieden? Risico’s  Op welke keuzes kun je moeilijk terugkomen?  Welke keuzes brengen investeringen met zich mee?  Welke keuzes hebben consequenties voor vervolgprojecten? Referentiedocumenten:  Organisatiespecifieke waardeketen “Value Chain” model.  Organisatiemodel en voorgeschreven processen: Target Operating Model  Systeemlandschap: Informatiemodellen  Checklist Non Functional Requirements  Checklist Risico Analyse (uit projectplan en de algemene checklist) .  Project CBA, Project Idee en Projectvoorstel (Project Approach), Projectplan (PDD)  Richtlijnen Informatiebeveiliging (BIV Classificatie)  Beschikbare Enterprise, Domein, Referentie Architecturen, Masterplan Architectuur Pagina 56 van 65


Bijlage 8.

Taking Action – Project Affinity Portal

Aandachtspuntentabel Aandachtspunt

Categorie 1: Overnemen uit EA 2: Uitwerken in PSA 3: Uitwerken in project

1

Authenticatie + Self Service Collectieve eindklant ontbreekt

3

2

Centraliseren Content Management, dit gebeurt nu op meerdere plekken

2

3

Onderzoek welke business services gewenst zijn. Neem xxxxxx + yyyyyyyy functionaliteit als uitgangspunt/voorbeeld

3

4

Web Analytics beheren vanuit één plek

2

5

Onderzoek welke (nieuwe) processen er uit welke (nieuwe) business services voortvloeien. Beperken tot Schade producten? Of ook Leven/Inkomen?

3

6

Onderzoek welke bestaande processen hergebruikt kunnen worden in 3 de gewenste situatie

7

Onderzoek hergebruik van bestaanden batch componenten en integratielaag services.

8

Onderzoeken welke business logica er in applicatie xxxxx is ondergebracht. Denk aan: Formulieren systeem; Aanvragen administratie; Afspraken administratie (collectieven) GIM component Applicatie yyyy (toegangsbeheer en autorisatie)

9

Huidige situatie biedt (Schade) producten aan van verschillende LOB’s 3 Aparte administraties met aparte polissen. Hoe harmoniseren? Onderzoek: a) Outputmanagement (geïntegreerd? gebundeld? Separaat?) b) Applicatie-integratie (geïntegreerd tarief? geïntegreerde schermen?) c) Centraal CRM?

3

10 Onderzoek wat de rol xxxxxx zal zijn in de doelarchitectuur.

3

11 Over welke tijdshorizon hebben we het? Welke fasering kan worden aangebracht? Welke software componenten kunnen we verantwoord uitfaseren en wanneer?

2

Tabel 9: Project Affinity Portal - Aandachtspuntentabel

Pagina 57 van 65


Issue-Matrix Hoe waarschijnlijk is het dat er in de toekomst wat verandert aan de uitgangspunten van dit issue? WAARSCHIJNLIJKHEID

Issue-Matrix

Hoe ernstig zijn de consequenties wanneer er in de toekomst een andere keuze gemaakt moet worden? IMPACT

Zeer waarschijnlijk

Waarschijnlijk

Onwaarschijnlijk

Zeer groot

10

8

Groot

5,9

6,7,2,11

Niet groot

1,3

4

Zeer onwaarschijn-lijk

Verwaarloos baar

Tabel 10: Project Affinity Portal - Issue-Matrix

Aandachtspunten in DYA raamwerk Businessdoelen Business Architectuur Product Dienst

Proces

Organisatie

Informatie Architectuur Gegevens

Applicatie

4,8

1,2,7,9, 10

Technische Architectuur Middleware

Platform

Netwerk

Algemene Principes Beleids lijnen Modellen

11 1,3

2,5,6,9, 10

10

Tabel 11: Project Affinity Portal - Aandachtspunten in DYA raamwerk

Pagina 58 van 65


Bijlage 9.

Taking Action - Architectuuraandachtspunten

Project

Aantal

Schade

14

Nieuw Leven

12

AffinityPortal

11

DANS

9

MDM-BRM

5

Debiteuren

4

Eindtotaal

55

Tabel 12: Aandachtspunten per project Categorie

Principe

Beleidslijn Model

Eindtotaal

2 Uitwerken in PSA

17

11

28

3 Uitwerken in Project

9

18

27

Eindtotaal

26

29

55

1 Herleidbaar uit EA

Tabel 13: Aandachtspunten per DYA rij en uitwerkcategorie

DYA Rij

BA

IA

TA

Eindtotaal

Beleidslijnen

9

13

4

26

Modellen

10

16

3

29

Eindtotaal

19

29

7

55

Principes

Tabel 14: Aandachtspunten in het DYA raamwerk Categorie

BA

IA

TA

Eindtotaal

2 Uitwerken in PSA

7

16

5

28

3 Uitwerken in Project

12

13

2

27

Eindtotaal

19

29

7

55

1 Herleidbaar uit EA

Tabel 15: Uitwerkcategorieen per DYA domein

Pagina 59 van 65


Bijlage 10.

Vragenlijsten Bruikbaarheid

Evaluatie bruikhaarheid Werkwijze Scope en Diepgang PSA (gesloten vragen) helemaal mee eens – helemaal mee oneens: 1. De toepassing van de werkwijze heeft een aantal aandachtspunten aan het licht gebracht die ik anders wellicht gemist zou hebben. ( 2. Het toepassen van de werkwijze heeft het me makkelijker gemaakt over aandachtspunten te communiceren met de projectleiding. 3. Het toepassen van de werkwijze heeft het me makkelijker gemaakt over aandachtspunten te communiceren met andere betrokkenen. 4. Bij een volgend traject ga ik de werkwijze zeker weer toepassen. 5. Er moet nog heel wat aangepast worden aan de werkwijze, voor ik hem weer toepas. 6. De werkwijze is alleen onder beperkte voorwaarden van nut. 7. De werkwijze is van nut geweest voor het vaststellen van aandachtspunten in mijn PSA traject. 8. De Issue-Matrix helpt me om aandachtspunten te prioriteren. 9. De Issue-Matrix is een bruikbare toevoeging aan de werkwijze. 10. The information is appropriate for the intended audience. 11. The information is presented from the user's point of view. Evaluatie bruikhaarheid Werkwijze Scope en Diepgang PSA (open vragen) 1. Onder welke omstandigheden heeft toepassen van de werkwijze toegevoegde waarde? 2. Welke omstandigheden kun je bedenken waaronder toepassen van de werkwijze geen nut heeft voor het opstellen van een PSA? 3. Welke suggesties heb je voor verbeteringen in de stappen binnen de werkwijze? 4. Welke suggesties heb je voor verbeteringen in de vragen en inhoud van de werkwijze? 5. Welke suggesties heb je voor verbeteringen in de werkwijze in het algemeen? 6. Overige opmerkingen:

Pagina 60 van 65


Bijlage 11.

Resultaten Evaluating Action

Gemidde lde

Respond ent 4

Respond ent 3

Respond ent 2

Vraag:

Respond ent 1

Resultaten gesloten vragen enquête bruikbaarheid

De toepassing van de werkwijze heeft een aantal aandachtspunten aan het licht gebracht die ik anders wellicht gemist zou hebben. (1=Helemaal mee eens - 5=Helemaal oneens)

2

2

2

3

2,25

Het toepassen van de werkwijze heeft het me makkelijker gemaakt over aandachtspunten te communiceren met de projectleiding. (1=Helemaal mee eens - 5=Helemaal oneens)

3

4

3

2

3

Het toepassen van de werkwijze heeft het me makkelijker gemaakt over aandachtspunten te communiceren met andere betrokkenen. (1=Helemaal mee eens - 5=Helemaal oneens)

2

4

2

3

2,75

Bij een volgend traject ga ik de werkwijze zeker weer toepassen. (1=Helemaal mee eens 5=Helemaal oneens)

2

2

2

2

2

Er moet nog heel wat aangepast worden aan de werkwijze, voor ik hem weer toepas. (1=Helemaal mee eens - 5=Helemaal oneens)

4

4

4

4

4

De werkwijze is alleen onder beperkte voorwaarden van nut. (1=Helemaal mee eens 5=Helemaal oneens)

5

4

4

3

4

De werkwijze is van nut geweest voor het vaststellen van aandachtspunten in mijn PSA traject. (1=Helemaal mee eens - 5=Helemaal oneens)

2

3

2

2

2,25

De issuematrix helpt me om aandachtspunten te prioriteren. (1=Helemaal mee eens - 5=Helemaal oneens)

2

2

2

2

2

De issuematrix is een bruikbare toevoeging aan de werkwijze. (1=Helemaal mee eens 5=Helemaal oneens)

2

2

1

2

1,75

Tabel 16: Resultaten gesloten vragen bruikbaarheid

Pagina 61 van 65


Resulaten open vragen enquête bruikbaarheid Vraag

Antwoorden

Onder welke omstandigheden heeft toepassen van de werkwijze toegevoegde waarde?

In de voorfase van een project, waar de businesscase wordt opgesteld of vlak daar achter aan, maar voor afronding van het PDD. Als het goed is zal het nl de structuur geven voor de PDD en een bijdrage aan de risk analysis. tegelijkertijd kan de checklist gebruikt worden gedurende een (architecturele) evelauatie van het project. Op het moment dat er sprake is van het opstarten van een project waaraan een informatieanalyse vooraf is gegaan. Commitment van de organisatie en het besef van de meerwaarde van Architectuur voor projecten is bepalend voor de meerwaarde. Indien het project zich nog bevindt in de vooronderzoeksfase.

Welke omstandigheden kun je bedenken waaronder toepassen van de werkwijze geen nut heeft voor het opstellen van een PSA?

Om achteraf een Architectuur te (re)construeren voor een bijna uitgevoerd project. Als er sprake is van een project waarvan de inhoud sterke gelijkenis vertoont met eerder uitgevoerde projecten, bijv. het doorvoeren van een premieverhoging. De werkwijze is lastig toe te passen als er geen documentatie beschikbaar is uit een voor het project uitgevoerde informatieanalyse. De werkwijze heeft naar mijn idee altijd nut. Zeker de issue matrix en de 1/2/3 categorisering zijn altijd waardevol. Indien het project zich al bevindt in de ontwerp / implementatie fase. Er zijn dan keuzes gemaakt.

Welke suggesties heb je voor verbeteringen in de stappen binnen de werkwijze?

stappen zijn logisch qua volgorde. Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. Nog niet in die zin over nagedacht. Momenteel geen suggesties dus. De bestaande stappen voldoen. Geen.

Welke suggesties heb je voor verbeteringen in de vragen en inhoud van de werkwijze?

Ik denk dat we meer detail (hints) zouden kunnen aanbrengen naar wat voor zaken je op zoek bent op de horizontale en verticale scope. Kortom waar moet je bij elka blokje in de DYA matrix aan denken. Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. De vraag 'wat spreek er voor zich, en wat niet' lijkt overbodig. De issues weerspiegelen de zaken die aandacht vergen. Hiermee is de scheiding 'wat spreekt er voor zich en wat niet' eigenlijk al gemaakt. Geen.

Welke suggesties heb je voor verbeteringen in de werkwijze in het algemeen?

Ik denk dat de werkwijze bij de iets ervarener architect wel zal aanslaan, beginnende architecten zullen denk ik iets meer geholpen moeten worden bij invulling van het model (zie eerdere opmerkingen over inhoud) Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. Voor alle werkwijzes vind ik gelden dat er altijd een gezonde dosis pragmatiek toegepast moet worden. Werkwijzes moeten niet gaan leiden tot plichtsmatige invuloefeningen. Geen

Overige opmerkingen

Ik denk dat de werkwijze potentie heeft om uit te groeien tot een handige checklist/guideline voor architecten bij het identificeren van issues dei in de PSA aan de orde moeten komen. Geen. Geen. Door eerst de nieuwe werkwijze is volledig te gaan toepassen bij een pr oject in de vooronderzoeks fase, dan pas kan ik beoordelen of er nog geschaafd moet worden aan 'verbeteringen'.

Tabel 17: Resultaten open vragen enquête bruikbaarheid

Pagina 62 van 65

Just Enough Architecture Evaluatie werkwijze – ruwe data enquête en gesprekken In deze tabel zijn alle punten uit de evaluatieverslagen en die uit de evaluatie enquete opgenomen. Opmerking Combinatie beleidslijn in PSA en Model in Project komt vaak voor 19, 29, 7 issues mbt BA / IA / TA Grote verschillen in aantallen issues Niet alle aandachtspunten uit de template komen terug als issue in het raamwerk. Check invoegen Geen Aandachtspunten uit EA af te leiden; uitwerken in PSA en uitwerken in Project in balans. AP: Ook informatie van derde partijen (buiten de eigen organisatie) betrekken CC: Ook de informatiemanager betrekken bij stap 2/3 Allen: Issuematrix opnemen net voor stap 2: eerst individueel en dan samen doorlopen op verschillen en discussiepunten. Betrekken van derden naar voren halen? Informatiemanager en 3rd party expliciet noemen bij stap 3 Issuematrix naar voren halen, al in de eerste stap een keer invullen Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. Nog niet in die zin over nagedacht. Momenteel geen suggesties dus.De bestaande stappen voldoen. BIV classificatie opnemen. Ik denk dat we meer detail (hints) zouden kunnen aanbrengen naar wat voor zaken je op zoek bent op de horizontale en verticale scope. Kortom waar moet je bij elka blokje in de DYA matrix aan denken. Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. De vraag 'wat spreek er voor zich, en wat niet' lijkt overbodig. De issues weerspiegelen de zaken die aandacht vergen. Hiermee is de scheiding 'wat spreekt er voor zich en wat niet' eigenlijk al gemaakt. Ik denk dat de werkwijze bij de iets ervarener architect wel zal aanslaan, beginnende architecten zullen denk ik iets meer geholpen moeten worden bij invulling van het model (zie eerdere opmerkingen over inhoud) Momenteel geen. Bij het weer toepassen van de werkwijze komen wellicht verbeteringen naar voren. Door eerst de nieuwe werkwijze is volledig te gaan toepassen bij een pr oject in de vooronderzoeks fase, dan pas kan ik beoordelen of er nog geschaafd moet worden aan 'verbeteringen'. Kan wel wat duidelijker allemaal. Opmaak kan beter. Stroomschema opnemen. Voor alle werkwijzes vind ik gelden dat er altijd een gezonde dosis pragmatiek toegepast moet worden. Werkwijzes moeten niet gaan leiden tot plichtsmatige invuloefeningen. Als project al gestart is met realisatie. Om achteraf een Architectuur te (re)construeren voor een bijna uitgevoerd project. Als er sprake is van een project waarvan de inhoud sterke gelijkenis vertoont met eerder uitgevoerde projecten, bijv. het doorvoeren van een premieverhoging. De werkwijze is lastig toe te passen als er geen documentatie beschikbaar is uit een voor het project uitgevoerde informatieanalyse. De werkwijze heeft naar mijn idee altijd nut. Zeker de issue matrix en de 1/2/3 categorisering zijn altijd waardevol. Indien het project zich al bevindt in de ontwerp / implementatie fase. Er zijn dan keuzes gemaakt. CC toepassing van de werkwijze leidt ertoe dat een derde partij die ontwerpen maakt of bouwt een veel bredere set van uitgangsinformatie meekrijgt dan bijvoorbeeld bij Front End en Salesforce het geval was. Dit maakt dat ook die partij betere beslissingen kan nemen. Stap 3, overleggen met business en derden is in Nieuw Leven project expliciet toegepast en heeft tot positieve ervaringen geleid. Heeft projectleiding inzichtelijk gemaakt waar de uitdagingen zitten. Hier speelt wellicht mee dat architect op expliciet verzoek van projectleider betrokken is, juist vanwege behoefte aan inzicht in het project. CC geeft aan dat RH in dit project al voor de werkwijze er was op basis van een aandachtspuntenlijst met projectleiding in dialoog was. HL signaleert voor debiteurenproject (wat nog in de vooronderzoeksfase verkeert) dat de werkwijze je helpt om op een gestructureerde manier toe te werken naar een PSA. Werkwijze dwingt je om breder te kijken dan je uit jezelf misschien zou doen. Bovendien komen Doel en doelgroep uitdrukkelijk aan bod, evenals de scoping van wat wel en niet uit te werken. De categorieën 1/2/3 dragen bij aan juiste timing van je inzet. Geeft als geheel richting aan hoe een architect een PSA aanpakt. HL: terugkijkend op DANS project zou de eerste versie van de PSA dunner geweest kunnen zijn doordat een aantal zaken als categorie 3 was gekenmerkt. Daarbij had toepassen van de werkwijze tot meer interactie kunnen leiden met bij het project betrokkenen. CC stelt voor om de werkwijze en categorisering aan de projectleiders te communiceren. Zie actielijst. CC heeft bij toepassing in Affinityportal de indeling in de categorieën 1/2/3 zeer bruikbaar ervaren. CC geeft aan dat wanneer in Front End project de “informatiemodellen” en de valuechain plaatjes uit de werkwijze waren toegepast er dan meer witte vlekken op tijd waren gesignaleerd. Deze modellen voegen wat toe aan de werkwijze. In Affinityportal waarvoor nog geen PSA wordt gevraagd omdat er nog geen project is, heeft CC ze ook gebruikt om issues in kaart te brengen voor het vooronderzoek door twee Informatie Analisten. AP signaleert voor een commercieel project dat nu start en dus niet onder de terugblik valt dat de Informatie Analisten de architecten wel weten te vinden, maar dat de architecten niet in de lead zijn. CC geeft aan dat hij nauw betrokken wordt. Positief is dat architecten betrokken worden, CC geeft aan dat hij hier ook de werkwijze probeert toe te passen. Indien het project zich nog bevindt in de vooronderzoeks fase. Allen geven aan dat huidige template voor de werkwijze goed genoeg is om een volgende keer te hergebruiken. (paar aanvulling n.a.v. evaluatie, maar geen structurele) Indeling in categorie 1,2,3 wordt als zeer bruikbaar ervaren. HL heeft in Dans wel stap 3 uitgevoerd, maar voordat de werkwijze werd toegepast. Dit overleg met betrokkenen van business project en beheer leidt tot herzien van issues en toevoegen van aandachtspunten vanuit beheer, zoals de gewenste inrichting van het Business Intelligence Competence center. Relativering: AP geeft aan dat uiteindelijk voor het resultaat van de PSA ook heel belangrijk is hoe de architecten in het project en ontwikkel proces worden betrokken. Als ze er niet “tussenkomen” is alle inspanning bij voorbaat weinig kansrijk. Het doorlopen van de werkwijze brengt architecten al vroeg in contact met de andere betrokkenen. Is positief omdat er daardoor meer binding tussen Architectuur en project ontstaat. HL Was lastig toepassen voor project Dans omdat het Project al liep. Worstelt nog wel met de vraag voor wie we de PSA maken. Pagina 63 van 65

Just Enough Architecture Het beantwoorden van de Doel vragen vereist een dialoog in vroeg stadium met opstellers vooronderzoek, projectleiding en andere betrokkenen. Eerste versie is vooral voor projectleiding en beslissers over start en scoping van het project. Gebruik van de werkwijzetemplate wordt als bruikbaar ervaren. Een verbeterpunt is dat sommige vragen rechtstreeks tot een issue op de issuelijst leiden, maar dat anderen alleen maar een risico in kaart brengen. In de werkwijze gebeurt er dan verder niets mee. Het lijkt erop dat de werkwijze architecten helpt om op te schuiven van hun oorspronkelijk IA focus naar meer BA en ook de TA te beschouwen. Beetje vroeg om daarover conclusies te doen. Toepassing van de matrix om waarschijnlijkheid en impact van veranderingen te bepalen heeft geholpen bij het bepalen van de categorie 1/2/3. Wel wat verwarring over de definitie.. Definitie kan zijn “hoe waarschijnlijk is het dat er in de toekomst wat verandert in de uitgangspunten van dit issue”. Gebruik van de matrix wordt als zeer bruikbaar ervaren, al kan de definitie nog wat scherper AP: Waar houdt het op Architectuur te zijn en waar begint het ontwerp? CC: Door de werkwijze toe te passen kom je in overleg met projectleiding daarin tot keuzes en een timing. HL: volgende keer met twee man door dezelfde bron documentatie heen, stap 1 uitvoeren, issuematrix onafhankelijk invullen en dan sparren. Levert meer wisselwerking op. HL: volgende keer eerder dan bij DANS het geval was, de boer op naar betrokkenen om afstemming over issues en prioriteiten te verkrijgen. (conform werkwijze) CC: Informatiemodellen, Valuechain, TOM modellen volgende keer wel gebruiken want ze zorgen ervoor dat je witte vlekken eerder signaleert. Issuematrix direct kunnen toepassen op een “voorbijkomend Architectuur verzoek”. Dialoog en gezamenlijke planning ontstaan in project Nieuw Leven op basis van bespreken aandachtspunten. N.a.v. artikel zijn de architecten begonnen met een nieuwe tekentechniek en wordt het maken van (praat)plaatjes aan de hand van de archimate tekentechniek een nieuw ontwikkelpunt voor de architecten. Wordt al vaker toegepast o.a. voor nieuw commercieel project. Werkwijze haalt BA en Proces naar voren waar architecten nu meer een IA focus hebben. Geeft derde partijen een veel bredere set van uitgangsinformatie mee. Ik denk dat de werkwijze potentie heeft om uit te groeien tot een handige checklist/guideline voor architecten bij het identificeren van issues die in de PSA aan de orde moeten komen. Plaatsing in het DYA raamwerk van de architectuurissues wordt als praktisch ervaren. Geldt ook voor onderscheid in diepgang van modellen / beleidslijnen en principes. Kort stilgestaan bij de verschillen tussen principes bv. “Processen inrichten volgens Target Operating Model”, beleidslijnen “Bij alle processen en systemen aandacht besteden aan Security al naar gelang de BIV classificatie vereist”. Modellen: de plaatjes van de uitwerking. HL geeft aan dat de mapping van aandachtspunten in het DYA raamwerk tot een duidelijke afbakening leidt hij zal dit zeker voor volgende te maken PSA toepassen. Bij de informatiemodellen, riskmatrices etc. ook de BIV classificatie opnemen omdat dit een aanvullende blik oplevert vanuit “beschikbaarheid, beveiliging en continuïteit). Valuechain en informatiemodellen helpen witte vlekken in kaart te brengen. GJT: Opvallen en herkenbaar vindt ik het punt van het gebruik van Informatiemodellen, Valuechain en TOM modellen als teogevoegde aarde voor analyse. Dit is m.i. een extra onderbouwing voor de behoefte aan een referentie Architectuur voor proces, informatie/applicatie in navolging op wat Johan aan het doen is voor TA. Een verdieping en aanscherping van de bestaande modellen. Mogelijk dat hiermee het gat van BA en TA ook beter opgevuld kan worden. AP: Veel externe partijen leidt in de werkwijze niet automatisch tot een issue in de aandachtspuntenlijst, daarmee leidt het doorwerken van de lijst niet automatisch tot een formule voor scope en diepgang! (onderzoeksaanbeveling voor nadere uitwerking) Stap 3 is maar 1 van de projecten aan toegekomen, stap 4 geen. AP: Voor BRM project met terugwerkende kracht werkwijze toegepast. Veel informatie bleek ook zonder de werkwijze al verzameld. Opvallend: Business Architectuur gerelateerde vragen komen prominenter aan de orde dan in de eerste fase van het project het geval was. Vooral de blik op Proces speelt daarbij. AP geeft aan dat dat wel wat issues die nu spelen had kunnen voorkomen. O.a. met betrekking tot consequenties van de beheerprocessen van Salesforce die nu nog voor problemen in de implementatie zorgen, evenals de scoping van het project: Broker en/of Cliënten. CC herkent dit van de processen rondom Front End project. Een PSA aan het begin van een project of aan het begin van een fase In de voorfase van een project, waar de businesscase wordt opgesteld of vlak daar achter aan, maar voor afronding van het PDD. Als het goed is zal het nl de structuur geven voor de PDD en een bijdrage aan de risk analysis. tegelijkertijd kan de checklist gebruikt worden gedurende een (architecturele) evelauatie van het project. Op het moment dat er sprake is van het opstarten van een project waaraan een informatieanalyse vooraf is gegaan. Commitment van de organisatie en het besef van de meerwaarde van architetcuur voor projecten is bepalend voor de meerwaarde. Het is gelukt om dit gesprek nu eens los van de inhoud van het project te voeren. Kennelijk maken we hier vorderingen in en lukt het beter om proces en inhoud los van elkaar te beschouwen.

Tabel 18: Ruwe data evaluatie en enquête

Pagina 64 van 65


Bijlage 12.

Digitale bijlage: CD-Rom

Pagina 65 van 65

Wat is Just Enough Architectuur?

Recommend Documents