Richard Lugtigheid, Lead Information Architect bij PGGM

Daan Rijsenbrij, woensdag 24 maart 2010

Richard Lugtigheid, Lead Information Architect bij PGGM

Richard Lugtigheid is inhoudelijk verantwoordelijk voor de architectuur bij PGGM. Hij geeft leiding aan een team van businessconsultants en architecten, dat er voor zorgt dat PGGM de ICT- en procesoplossingen krijgt die de bedrijfsstrategie van PGGM actief ondersteunen.
Het bewaken van de samenhang tussen de diverse proces- en systeemcomponenten, het voldoen aan wettelijke kaders en andere compliancy-aangelegenheden is daarbij cruciaal. Architectuur is daardoor een van de belangrijke stuurinstrumenten om de PGGM-strategie, en het daarvan afgeleide informatiebeleid, te realiseren.

Het is de verdienste van Richard en zijn team dat niet alleen het werken onder architectuur bij PGGM een groot succes is geworden, maar dat architectuur is geaccepteerd als een vanzelfsprekendheid op operationeel, tactisch en strategisch niveau.
Door het inrichten van de juiste architectuurprocessen over alle betrokken afdelingen heen en het hanteren van effectieve architectuurproducten, is PGGM er in geslaagd de systeemarchitectuur (zowel qua applicatie- als infrastructuurlandschap) sterk te vereenvoudigen met goede resultaten in termen van kosten, flexibiliteit en kwaliteit (van processen, data en systemen t.a.v. betrouwbaarheid, volledigheid, actualiteit, onderhoudbaarheid en beschikbaarheid).

Uit het door de Raad van Bestuur geaccordeerd informatiebeleid is een set beleidsrichtlijnen opgesteld die invulling geven aan de ICT-strategie van PGGM. Deze beleidsrichtlijnen zijn aangevuld met ‘best practices’ uit het vakgebied. De ICT-strategie van PGGM impliceert onder andere maximaal hergebruik en keuzen zoals ‘Microsoft, tenzij’. Door deze pragmatische ICT-strategie zijn al grote successen geboekt.

Met enkel en alleen informatiebeleid en enterprise architectuur blijft architectuur een geduldig (digitaal beschikbaar gesteld) document. Architectuur gaat pas echt leven op de werkvloer door het opstellen van een projectarchitectuur die aansluit op de enterprise architectuur. Dit wordt vormgegeven door ProjectStartArchitecturen (PSA). In een PSA wordt, naast de algemene kaders uit het informatiebeleid dan wel de enterprise architectuur, juist ook een globale solution architectuur geleverd. De diepgang van deze solution architectuur is afhankelijk van het project.
Middels een PSA levert architectuur voor projecten een daadwerkelijk toegevoegde waarde. Bij het opstellen van de PSA zijn de (beoogde) projectleden betrokken en tijdens het project blijft de architect betrokken. Dit borgt de toegevoegde waarde van architectuur op het realisatieniveau.

Voor vrijwel alle projecten zijn PSA’s geschreven, en dat beperkt zich niet tot IT-projecten, hoewel de meeste projecten bij PGGM wel een IT-component hebben. Er zijn inmiddels honderden PSA’s geschreven voor nieuwe en gewijzigde producten, proces- en systeemaanpassingen en reorganisaties.

Daan: “Op de universiteit ben jij geschoold als biochemicus. Hoe zou jij aan een biochemicus uitleggen wat digitale architectuur is?”

Richard: “Aangezien ICT op universiteiten redelijk bekend is, zou je kunnen volstaan met het ‘in samenhang ontwerpen van het ICT- en procesgebouw’. Overigens is de uitleg aan biochemici niet anders dan aan de gemiddelde medewerker van de business.

Ik spreek trouwens niet over digitale architectuur, maar over ICT- en businessarchitectuur. In de communicatie met de business is architectuur een middel om het businessdoel te bereiken. Daarom is de naamgeving van onderdelen van de architectuur minder relevant in externe communicatie. Het gaat om het vertalen van businesseisen naar een oplossing die, onder andere met behulp van ICT, voldoet. De term ICT-architectuur voldoet dan. Digitale architectuur is mijn inziens een oplossingsrichting die uitgaat van een hoge automatiseringsgraad en eist een bepaalde manier van procesuitvoering door de business, en moet dus passen bij het probleem. Digitale architectuur is derhalve een deelgebied van de ICT-architectuur, met een focus op een bepaalde oplossingsrichting. Ook omdat een beperking in scope niet in lijn is met het sturen op samenhang, gebruik ik de term zelden.”

Daan: “Wat is voor jou het meest wezenlijke van architectuur? En hoe heb je dat verkocht aan de verschillende stakeholders?”

Richard: “Het belangrijkste is het opstellen van een samenhangende visie en het vertalen daarvan naar werkbare oplossingen. Dat betekent dat je met de expertise van de IT en de businessdomeinen een richting kan aangeven die PGGM vooruit helpt.
Er zijn immers veel mensen die op diverse gebieden oplossingen geven, maar er zijn slechts weinigen die vanuit het totaaloverzicht kunnen acteren. Daarbij helpt een toekomstvaste architectuur. Architectuur dient stabiel te zijn, hoewel het conform het ‘just in time’ principe niet ‘af’ hoeft te zijn.

Een tweede aspect is het daadwerkelijk ondersteunen van projecten. De visieontwikkeling zoals hierboven beschreven is belangrijk, maar het levert het risico van ivorentoren gedrag. En dan wordt de architectuur niet geoperationaliseerd en werken projecten, zoals verwacht mag worden, in ‘goede’ onderlinge communicatie zo dicht mogelijk langs elkaar heen.

PGGM kent diverse stakeholders als het gaat om het realiseren van de PGGM strategie, en dat zijn impliciet sponsors van het werken onder architectuur. De benadering van deze stakeholders verschilt, afhankelijk van hun belangen.
Qua verkoop van architectuur zijn we niet begonnen om architectuur te positioneren en te definiëren. We zijn begonnen met de organisatie te helpen, zowel bottom up als top down. Het is vooral een kwestie van kansen pakken.

Zo werden de projectleiders en de informatiemanagers geholpen door direct aan het begin van een project (met behulp van een PSA) een beeld op te bouwen van het projectresultaat ten aanzien van de processen en de systemen. Dat helpt de projectleiders en de opdrachtgevers (in ons geval is dat vaak de informatiemanager) bij het verminderen van risico’s en het verhogen van de kwaliteit. Juist omdat een PSA middels workshops met betrokkenen wordt opgesteld, komen de belangrijkste problemen aan de start van het project naar boven en worden expliciet de benodigde keuzen gemaakt. Aangezien de architect de enterprise architectuur voor het project vertaalt naar projectdoelstellingen en kaders, is de samenhang en toekomstvastheid geborgd. In lijn met de gedachte van ondersteunen, zijn we pas na een jaar begonnen met architectuurcontroles (met andere woorden het verstrekken van architectuurcertificaten).

Het belangrijkste van architectuur is niet het promoten van de aanwezigheid van een architectuur of architectuurafdeling. Het gaat om het ‘werken onder architectuur’, dat levert de gewenste effectiviteit. Promoten van ‘werken onder architectuur’ doe je door zichtbaar te zijn bij de diverse IT-disciplines (engineering, design, beheer etc.), de projectleiding en de business (FAB: functioneel applicatiebeheer, informatiemanagement etc.). Door het actief ondersteunen van projecten, door het houden van workshops, door het geven van presentaties, door een regelmatige berichtgeving op intranet en door frequent overleg (met als doel problemen helpen op te lossen), weet men architectuur eenvoudig te vinden. Omdat we nooit ‘nee’ zeggen (maar eventueel wel andere oplossingen voorstellen), wordt men geholpen op strategisch, tactisch en operationeel niveau. Daardoor blijft men steeds naar de architectuurafdeling komen.

Een andere belangrijke stakeholder is de CIO c.q. de directeur ICT. Toen deze begon kende PGGM een applicatie- en infrastructuurlandschap dat zwaar heterogeen was. Alles was aanwezig: mainframes, Unix en Windows systemen, systemen op basis van Cobol, Sybase, Oracle etc. met een enorme functionele overlap. De ICT-kosten waren navenant. De directeur ICT had heel goed in de gaten dat sanering, hergebruik en uniformering van groot belang was, met architectuur als één van de stuurinstrumenten. Dan moet je vervolgens een pragmatische visie ontwikkelen die richting geeft aan waar je heen wilt en hoe je daar komt. Het snel formuleren van die visie is één, het zodanig regelen dat deze visie breed wordt gedragen is het moeilijkste en belangrijkste. Vergeet niet dat je in een dergelijke situatie veel systeemeigenaren dient te overtuigen. We hebben dat opgelost door de problemen in kaart te brengen over de ketens en de domeinen heen, vervolgens samen met de informatiemanagers een integrale visie te ontwikkelen. Deze visie is door de architecten, in samenwerking met de business, nader uitgewerkt in een enterprise architectuur, die weliswaar via de architectuursite beschikbaar is doch slechts beperkt wordt uitgedragen. In overleggen en presentaties blijven we redeneren vanuit een voor de doelgroep relevant probleem en gebruiken slechts relevante onderdelen uit die enterprise architectuur.

Door het succes van enerzijds de projectondersteuning en anderzijds het hebben van de visie komt het ‘werken onder architectuur’ vanzelf terecht bij de diverse directies en de Raad van Bestuur. Want daar ligt uiteindelijk de vraag hoe de strategie gerealiseerd moet worden.
Op dit niveau binnen de organisatie is het informatiebeleid van groot belang. Deze beleidsrichtlijnen hebben betrekking op de informatievoorziening en worden door de Raad van Bestuur geaccordeerd. Zij geven kaders ten aanzien van processen en systemen.

Door intensief contact met de directies en het constructief meedenken, wordt je als architect betrokken bij de diverse initiatieven. Hierdoor ben je vroegtijdig betrokken en krijg je de kans om over de keten heen (dus buiten PGGM) de architectuur mee te helpen opstellen. Wij zijn daardoor als architecten betrokken bij het pensioenregister en het waardeoverdrachtportaal, waarbij ook extern stakeholders zijn betrokken.

PGGM heeft diverse klanten en toezichthouders die het aantoonbaar werken onder architectuur en het werken conform het informatiebeleid als kwaliteitskenmerk waarderen. Derhalve zijn voor de diverse controleorganisaties en onze eigen directies het architectuurproces en de architectuurproducten van groot belang. Dit besef is langzaam gegroeid.
Vanuit PGGM wordt het werken onder architectuur gebruikt om de goede kwaliteit en beheersbaarheid van onze systemen aantoonbaar te maken.
Momenteel vragen klanten en externe toezichthouders expliciet om het werkend hebben van het architectuurbeleid. Dat is een extra stimulans voor onze verkooporganisatie, directies en dergelijke om onder architectuur te blijven werken.”

Daan: “Wat vinden de businessmanagers bij PGGM belangrijk aan architectuur?
Hoe merken zij in hun werk de toegevoegde waarde?”

Richard: “Businessmanagers hebben problemen en uitdagingen waarbij ze geholpen willen worden. Architectuur is een product dat daarbij ondersteuning kan bieden. Het gaat in feite niet zozeer om architectuur, dat is immers maar een middel om hun doel, de realisatie van strategie, te bereiken. Architectuur helpt daarbij door de samenhang te combineren met een visie ten aanzien van de oplossing.

Als businessmanagers merken dat het werken onder architectuur zorgt voor kostenreductie, snellere time to market, algemene efficiëntie en kwaliteit, dan heb je voor hen toegevoegde waarde. Dat geluid krijgen ze terug vanuit de projecten en de business middels de observaties uit de PSA-workshops en een voorspoediger verloop van de projecten. Daarenboven zijn de ICT-kosten in de afgelopen vijf jaar gehalveerd door het bewust sturen op het verminderen van de complexiteit.

Overigens is het architectuurproces binnen PGGM dusdanig verankerd in de organisatie dat het werken onder architectuur een vanzelfsprekendheid is geworden. Zelfs de business is gewend geraakt om in de PSA fase (het opstellen duurt ca. 24 uur) middels workshops en dergelijke een eenduidig beeld te verkrijgen over de eindoplossing en op voorhand de belangrijkste discussies te voeren.
Ook onze projectleiders willen geen architectuurdiscussies meer halverwege een project.”

Daan: “Langs welke kwaliteitscriteria zou jij de architectuur van PGGM willen laten beoordelen?”

Richard: “Ik zou de architectuur van PGGM willen laten analyseren op:

  1. De mate van ondersteuning van de PGGM strategie.

  2. De mate waarin de architectuur gedragen wordt door de organisatie.

  3. De toekomstvastheid.

  4. De toepasbaarheid en de concreetheid.

  5. De begrijpelijkheid.

  6. De volledigheid voor het betreffende domein/project.

  7. De innovativiteit.

Met enige regelmaat vragen wij de business (feitelijk onze klanten) wat zij van architectuur vinden en bepalen de mate waarin wij de business ondersteunen door zowel het leveren van architectuur als consultancy. Het rapportcijfer dat gegeven wordt ligt al jaren tussen 7.5 – 8.5. Omdat sommige delen van de architectuur erg complex zijn, is ‘begrijpelijkheid’, iets wat blijvend veel aandacht vraagt (en krijgt).”

Daan: “Waar bevindt de architectuur van PGGM zich ergens in het Architecture Maturity Model of een ander volwassenheidsmodel?”

Richard: “In de top. We doen al jaren mee met diverse benchmarks (onder andere op basis van DYA en GEA) en het is opvallend dat PGGM steevast er heel goed of zelfs als beste uitkomt. PGGM heeft zowel haar architectuurproducten als de architectuurprocessen op orde. Daarmee is architectuur binnen PGGM erg efficiënt en effectief en dat is het kenmerk van volwassenheid.
We zijn trouwens in 2004 begonnen met het systematisch werken onder architectuur. We gebruiken daarvoor de DYA-methodiek, die we in detail zelf hebben uitgewerkt zodat het past bij PGGM zowel qua proces als qua product.”

Daan: “Welke grote uitdaging voorziet PGGM in de pensioenmarkt die niet zonder architectuur kan worden opgelost?”

Richard: “Binnen PGGM is het betrekken van de architectuurafdeling een vanzelfsprekendheid, dus eigenlijk is het antwoord: ‘vrijwel alles’.
PGGM heeft zoveel interferentie tussen processen en systemen, dat het oppakken van uitdagingen altijd in samenhang moet geschieden. Overigens heeft men het niet over ‘we gaan architectuur vragen om ons probleem op te lossen’, maar ‘we hebben een probleem, en de architectuurgroep heeft de kennis en ervaring om ons te helpen’. Dus ook als het gaat om nieuwe reglementen, offertes voor nieuwe klanten, nieuwe producten etc. Juist op die complexe gebieden hebben we erkenning gekregen.”

Daan: “Wat zijn de cruciale businessdrivers bij PGGM die bron zijn geweest voor belangrijke architectuurprincipes?”

Richard: “Dat zijn kwaliteit, efficiency, flexibiliteit en customer intimacy op PGGM gebied. Zoals bij de meeste bedrijven dus. Het verschil zit hem in de keuzen die PGGM maakt om dit te bereiken.”

Daan: “Welke eisen stellen toezichthouders als De Nederlandse Bank, die tot architectuurprincipes hebben geleid?”

Richard: “DNB stelt vooral eisen ten aanzien van de security over de ketens, en natuurlijk over compliancy ten aanzien van wetgeving, zoals het scheiden van data en de wijze waarop die beheerd en ontsloten wordt.
Architectuur biedt inzicht in de (huidige en gewenste) opzet van systemen, en daarmee inzicht in de kwaliteit.”

Daan: “Zijn er referentiearchitecturen die relevant zijn voor PGGM?”

Richard: “Nee, niet echt voor zover het externe referentiearchitecturen betreft. We kennen geen NORA, of afgeleide varianten daarvan. Wel baseren we een aantal zaken in onze infrastructurele en technische architectuur op de Microsoft architectuurconcepten, die dan verder naar PGGM worden maatgesneden.
Natuurlijk kijken we ook naar wat andere bedrijven zoal gebruiken.

We hebben wel onze eigen enterprise architectuur, en die mag je beschouwen als een PGGM interne referentiearchitectuur. Deze geeft voor de diverse producten, processen, applicaties, infrastructuren, BI-toepassingen en Sharepointimplementaties de kaders aan.”

Daan: “Wat is de verhouding tussen informatiebeleid en architectuur?”

Richard: “Het informatiebeleid is een architectuurproduct. In feite is het de hoogste laag in ons architectuurproductmodel.”

Daan: “Zoals je net aangaf is jullie architectuurmethode DYAP (DYA PGGM) een verbetering van het oorspronkelijke DYA.
Welke verfijningen hebben jullie op DYA aangebracht? En waarom?”

Richard: “Uit het DYA-handboek kun je niet eenvoudig afleiden welke architectuurprocessen je nodig hebt en hoe je ze moet vormgeven. Dat hebben we zelf gedaan, rekening houdend met de PGGM karakteristieken.

DYA heeft een focus op de PSA. De enterprise architectuurproducten en de wijze waarop je die doorvertaalt naar PSA’s was onderbelicht, dus hebben we dat verfijnd. Daarnaast hebben we de PSA in twee fasen opgeknipt, omdat je dan kan meebewegen met het project.
En ten slotte hebben we de term bouwvergunning vervangen door architectuurcertificaat. Dat geeft een veel positievere associatie.

De meeste van deze zaken zijn ondertussen opgenomen in de DYA-methode.”

Daan: “Bij veel ondernemingen zie je zoiets als een ‘building permit’ (bouwvergunning) die een architect afgeeft en waarna een bouwer mag beginnen. Kan je uitleggen waarom jullie architectuurcertificaat beter werkt?
Wat is trouwens de relatie tussen een dergelijk architectuurcertificaat en de PSA?

Richard: “Architectuur is pas een succes als er onder architectuur wordt gewerkt. Dat betekent samenwerken en dat is niet het zelfde als politieagent spelen. De term bouwvergunning werkt in deze dus averechts. Daarom spreken wij van architectuurcertificaten (AC), die een projectleider spaart als bewijs van goede projectkwaliteit. Dat geeft een positievere associatie.
Tijdens een project geven wij twee architectuurcertificaten af, één na de functionele fase en één tijdens de testfase. In deze certificaten maken wij, samen met de business, afspraken ten aanzien van eventuele afwijkingen. Het niet verlenen van toestemming om naar een bouwfase te gaan is een utopie. Je moet er samen uitkomen. Indien een project tijdens de uitvoering fors afwijkt van de overeengekomen architectuur, dan heeft de architectuurafdeling het ook niet goed gedaan. Meestal is dan al veel eerder in het project bijgestuurd of geëscaleerd.

Een architectuurcertificaat geeft aan dat het project conform de PSA is uitgevoerd. Een architectuurcertificaat hoort dan ook bij een PSA, of beter gesteld, in de projectdeliverables zijn een PSA en twee AC’s opgenomen.”

Daan: “Sogeti heeft weliswaar de PSA (projectstartarchitectuur) ten tonele gevoerd in 2001, maar jij kunt toch worden gezien als een van de grote evangelisten van de PSA.
Wat is in essentie de inhoud van de PSA? En hoe stel je een PSA op?”

Richard: “Leuk dat je dat zegt. Ik herken het wel. Het grootste succes van DYA is volgens mij dat deze methodiek veel aandacht geeft aan het operationaliseren van de (enterprise) architectuur middels de PSA. En door zowel architectuurprocessen als architectuurproducten (op een redelijk hoog abstractieniveau) duidelijk te beschrijven kan je ze organisatiespecifiek invullen.

Een PSA bevat de uitgangspunten en keuzen die de organisatie maakt ten aanzien van een bepaalde ontwikkeling/doelstelling op het gebied van producten, processen, organisatie en systemen. De PSA baseert zich op de kaders (zoals beleidsrichtlijnen, modellen en richtlijnen van de enterprise architectuur), die voor het project relevant zijn en vult die aan met een solution architectuur. Daarmee geef je voor alle betrokkenen een goed beeld van de eindoplossing, en hoe die samenhangt met andere processen, systemen en andere projecten. Kortom, in een week weet je precies wat het project moet gaan opleveren en is die eindoplossing doordacht en doorleefd. Daardoor zijn vroegtijdig allerlei problemen en vraagstukken naar boven gekomen en is een gedragen keuze gemaakt ten aanzien van die issues. Voor het project en opdrachtgever een ideale situatie. Door de kaders van de enterprise architectuur mee te nemen, worden ook andere belangen gediend.

Een PSA wordt aangevraagd bij de architectuurgroep door een informatiemanager of een projectleider.

  • Als eerste stelt een informatiearchitect de 0.1 versie op, waarbij al veel overleg is met materie- en systeemdeskundigen.

  • De technische applicatiearchitectuur, de infrastructurele architectuur en de security-aspecten worden daarna aangevuld in overleg met/door architecten met de benodigde specialisaties. Soms wordt de bijbehorende businessarchitectuur gelijk aangevuld door een businessconsultant.

  • Vervolgens wordt een workshop georganiseerd met business en IT om de PSA door te nemen en om gezamenlijk het beeld op te bouwen van de gewenste oplossing en om de cruciale keuzen te maken.

  • Na een aantal korte sessies om de nog openstaande punten te verwerken, wordt de PSA geaccordeerd door de manager architectuur (dat ben ik), de informatiemanager (namens de business) en de projectleider.

Om een PSA in 24 uur op te kunnen stellen, heb je als architect veel basiskennis nodig van IT en de businessmaterie, als wel van de samenhang van de ICT-systemen en processen die er gebruik van maken. Daarom is het inhuren van extra capaciteit in de vorm van externe informatiearchitecten nauwelijks zinvol.
Helaas overstijgt de vraag naar architecten het aanbod en daarom maken we regelmatig gebruik van businessconsultants, designers etc. die stukken van de PSA invullen of uitwerken voortbordurend op die 0.1 versie. De architect blijft echter wel eindverantwoordelijk.”

Daan: “Wat is de relatie tussen de enterprise architectuur en de verzameling PSA’s?”

Richard: “In de PSA staat welke stukken van de EA relevant zijn, en wat de wijzigingen zijn c.q. hoe het project bijdraagt aan de SOLL EA.
(SOLL EA = IST EA + 3 jaar).”

Daan: “In de introductietekst staat dat er honderden PSA’s bij PGGM zijn. Hoe wordt de samenhang in de architectuur bewaakt met zoveel PSA’s?”

Richard: “Simpel, door structuur aan te brengen in de opslag en naamgeving van die PSA’s.
Voorts wordt de EA bij elke PSA bijgewerkt. Het gaat dan met name om de zogenaamde interfacemodellen, waarin per domein2 de applicaties en hun logische interfaces zijn weergegeven. Bij elke wijziging in de EA staat welke PSA daarvoor verantwoordelijk is. Derhalve wordt de architect gedwongen op de huidige en toekomstige samenhang te letten.
Neemt niet weg dat mijn team klein is, en iedere architect ook een businessdomein als aandachtsgebied heeft. Daardoor weet de architect goed welke PSA’s relevant zijn voor een nieuw project.
Bovendien worden de definitieve PSA’s op onze Sharepoint site gepubliceerd.”

Daan: “Welke rol heeft de projectleider bij het opstellen van de PSA?”

Richard: “De belangrijkste rollen van een projectleider bij een PSA zijn:

  • Als er nog geen PSA is, dan is hij de aanvrager en participeert hij in de workshops en dergelijke.

  • Hij accordeert de PSA ook, en wel met het oog op uitvoerbaarheid.

  • Daarnaast initieert hij ook de architectuurcertificaten, die hij spaart als bewijs van kwaliteit."

Daan: “Ik heb begrepen dat een projectleider bij PGGM uit professionaliteitsoverwegingen niet begint aan een project alvorens er een geaccordeerde PSA ligt. De noodzaak van een architectuur is daardoor bij PGGM een vanzelfsprekendheid geworden.
Hoe heb jij deze attitude/cultuur geregeld?
Hoeveel inspanning en doorlooptijd heeft dat gekost?”

Richard: “Toen we met architectuur in 2004 begonnen conform DYA, hebben we dat zowel top-down aangepakt door het opstellen van het informatiebeleid, als bottom-up door te beginnen met de PSA’s.
We hebben die PSA’s opgesteld om projecten te helpen met onze kennis en expertise. Dus niet zozeer kaderstellend als wel ondersteunend. Natuurlijk stelden we daarbij impliciet kaders op, maar dat werd niet zo ervaren. Door die PSA’s zagen de projectleiders hun risico’s aanzienlijk verminderen en werden geholpen om snel keuzen te kunnen maken bij problemen.
We zijn ook veelvuldig bij de projectleiderscommunity langs geweest. Daarbij lukte het goed de groep te enthousiasmeren. Ik ben zelf jarenlang projectmanager geweest en weet welke risico’s projectleiders graag vermijden. Verder hielp het enorm dat de directie een sponsor was van DYA en het gebruik van DYA afdwong.
Pas na een jaar zijn we langzaam begonnen met de architectuurcertificaten. Maar ook hier altijd vanuit een ondersteunende attitude. Je moet altijd kunnen uitleggen waarom iets op een bepaalde manier moet worden gedaan en wat de nadelen en risico’s zijn voor het project c.q. de opdrachtgever indien niet aan de architectuur voldaan wordt.

Het inbedden van ‘werken onder architectuur’ had het eerste jaar tot gevolg dat we steeds drie stappen vooruit zetten, en vervolgens twee terug. Daarna ging het ineens heel snel met de volwassenheid.
Om dit te bereiken moet je dus PSA’s maken die waardevol zijn en het project daadwerkelijk vooruit helpen. Dat impliceert het leveren van solution architecturen bovenop het vertalen van de EA kaders. Daarnaast moet je heel veel communiceren en aansluiting zoeken met business en IT afdelingen, met als doel te kijken hoe je kunt helpen door samenhang te ondersteunen, oplossingen te structureren en flexibiliteit in die oplossingen te bieden door consolidatie en modulariteit.
Overigens blijft het ook in de jaren erna nodig om dergelijke inspanningen te verrichten. Maar ja, dat is in feite onderdeel van je werk als architect.”

Daan: “Wat doet de architect tijdens het projecttraject?”

Richard: “Dat is afhankelijk van het architectureel risico van een project en de omvang ervan.
In de lichtste vorm stelt hij de PSA en AC op en acteert als vraagbaak voor het project. Zo af en toe neemt hij spontaan contact op. Hij moet er een neus voor hebben om te weten wanneer dat moet.
In de zwaarste vorm organiseert hij daarnaast periodieke sessies met designers, engineers etc. om problemen, knelpunten, kansen en oplossingsrichtingen te bespreken en gezamenlijk detailkeuzen te maken. De vraagbaak functie is dan veel explicieter.”

Daan: “Wat vind jij van TOGAF? Zal dat ook aanleiding geven tot verfijningen van DYAP?”

Richard: “Ik ben daar nog niet uit. Ik heb nog geen tijd gehad mij er echt in te verdiepen. Ik wacht nog op een volgende versie die hopelijk de helft dunner zal zijn. Wat ik er van zie is dat op hoog niveau de architectuurprocessen logisch gegroepeerd zijn.
De omvang ademt een zekere massiviteit en ambtelijkheid uit. Dat brengt het risico met zich mee dat we vooral architectenproducten krijgen die veel kosten en niet aansluiten bij de klantbehoefte. Werken vanuit een ivoren toren is dan een groot risico.
Voorlopig voldoen onze eigen architectuurprocessen nog prima. Deze zijn uitgeschreven in minder dan 60 pagina’s, en dat betekent dat je veel vrijheden geeft en ruimte laat. Doordat we slechts beperkt tools gebruiken (alleen de office tools) dwingt dat de architecten om hun architectuurproducten zo te maken dat ze aansluiten op de belevingswereld van de klant/opdrachtgever. Intern, voor de architecten onderling, hebben we wel veel gestandaardiseerde modellen en schema’s, maar in een PSA zitten die hoogstens in de bijlagen.”

Daan: “Jij hebt ook meegewerkt/meegedacht met GEA (General Enterprise Architecturing). Welke aspecten van die methodiek spreken jou aan? En welke zaken heb jij opgenomen in DYAP?”

Richard: “GEA is een goede aanvulling op DYA. GEA richt zich vooral op de enterprise architectuur, terwijl DYA zich meer richt op de projectarchitectuur. Omdat Roel Wagter bij zowel DYA als GEA een prominente rol heeft, is die aansluiting niet zo heel verwonderlijk.

GEA is zeer bruikbaar als je nog moet beginnen met een EA. Het geeft duidelijk aan hoe je dat moet aanpakken. Het meest bijzondere van GEA is dat het goed invulling geeft aan het basisprincipe van architectuur: het bewaken van samenhang.
GEA is heel expliciet in het definiëren van de artefacten (perspectieven genoemd) die met elkaar samenhangen. GEA schrijft ook voor dat aan de perspectieven een gewicht hoort te hangen, omdat niet alle perspectieven even belangrijk zijn.

GEA is nog vrij nieuw, maar ik verwacht dat er op termijn een lijst zal komen van standaard perspectieven, omdat bedrijven vrijwel allemaal klanten, medewerkers, producten, processen en middelen kennen. Op basis van de bedrijfsstrategie kunnen echter ook perspectieven naar boven komen die bedrijfsspecifiek zijn. Voor PGGM is dat bijvoorbeeld ‘duurzaamheid’. Daarmee zorg je weer dat je architectuur aansluit bij de klant/business beleving en ook voor issues op dat gebied oplossingen kan bieden.

Daarnaast geeft GEA ook aan waar enterprise architecten qua profiel aan moeten voldoen. Ten slotte staat in GEA expliciet hoe de architectuurprocessen moeten verlopen om een succesvolle EA te krijgen, waarmee je een visie kan geven waar een organisatie heen moet bewegen.
Kortom, GEA richt zich vooral op de managementlagen en minder op het project of de portfoliouitvoering.”

Daan: “Welke architectuurproducten onderkennen jullie bij PGGM?”

Richard: “We proberen de diversiteit te beperken tot:

  • Informatiebeleid

  • Informatiebeveiligingsbeleid

  • Enterprise architectuur (modellen, richtlijnen)

  • Domeinarchitecturen (bijv. BI, portal, infra etc.)

  • PSA en AC

Voorts hebben we een aantal gerelateerde producten met een aanzienlijke architectuurcomponent zoals:

  • Procesontwerpen (als onderdeel van een project)

  • Roadmaps

  • Bedrijfsinformatieplannen

  • Business cases (een PSA is meestal een onderdeel van het proces om tot een business case te komen)

  • Uitvoeren pakketselectie (bepalen long/short list, architectuureisen, GAP-analyse en advisering, alles samen met de business).”

Daan: “Hoe hebben jullie adaptiviteit gerealiseerd in het applicatielandschap en de technische infrastructuur?”

Richard: “Ondertussen hebben we een homogeen applicatielandschap gebaseerd op een Microsoft georiënteerd infrastructureel platform. Daarop draaien pakketten en vooral Microsoft dotnet maatwerk.

Wij leveren flexibiliteit door hergebruik van componenten. We bewaken de uniformiteit, met als doel een lagere complexiteit en daardoor een snellere adaptiviteit. Een van onze beleidsrichtlijnen luidt daarom: ’we kiezen voor best of suite, in plaats van best of breed’. Door de rijkdom van de meeste pakketten kan dat ook. Hierdoor (en het uitfaseren van legacy) is het aantal pakketten in drie jaar met een derde verminderd, en dat levert flexibiliteit doordat er minder integraties nodig zijn.

Voor de infrastructuur hebben we een uitgewerkte ‘one size for all’ architectuur. Een Microsoft georiënteerde architectuur (met nog een paar afwijkende databases), die bovendien volledig is gevirtualiseerd van desktop tot server. Hiermee word voldoende adaptiviteit geleverd.”

Daan: “Op welke gebieden is business-IT alignment een issue bij PGGM? En hoe hebben jullie dat gerealiseerd?”

Richard: “Alignment is altijd een issue op die plekken waar twee partijen samenwerken. Of dat nu tussen IT en business is of tussen businessonderdelen onderling.

Meestal komt dat dus neer op samenwerken, luisteren en begrip hebben voor elkaars belangen. Dat is het proces dat je moet faciliteren door de juiste opzet van de architectuurprocessen.
Daarnaast gaan we pro actief rond in de organisatie en proberen tijdig aan te haken bij de diverse initiatieven.

In mijn afdeling zitten zowel architecten als businessconsultants. Die werken samen om projecten tot een goed einde te brengen. Beiden zorgen voor verbindingen tussen de diverse organisatieonderdelen, en daarmee voor alignment.”

Daan: “Welke architectuurconcepten zijn specifiek voor de pensioenwereld?”

Richard: “Dat is heel beperkt. Meestal gebruik je het gezonde verstand en bestaande concepten om zaken te structureren. Zo is er een zogenaamd lagenmodel dat aangeeft hoe pensioenfunctionaliteit gegroepeerd wordt, en daarmee het applicatiemodel vormgeeft.”

Daan: “Hebben jullie een productarchitectuur? En wat zijn daarbij de belangrijkste aspecten?”

Richard: “Ja, die hebben we, maar deze vraag kan ik in verband met de concurrentiegevoeligheid niet beantwoorden.”

Daan: “Wat is informatiearchitectuur bij PGGM?
Hoort daar ook de architectuur van de kantoorautomatisering bij?
Ligt daar ook de relatie met het ‘nieuwe werken’?”

Richard: “Qua architectuur van de informatievoorziening maken we onderscheid tussen de businessarchitectuur (d.w.z. product, proces en organisatie) en informatiearchitectuur (applicatielandschap, applicatie architectuur en fysieke architectuur).

Wij maken geen onderscheid tussen kantoorautomatisering en de rest. Alles dient voor procesondersteuning. En ons ‘Microsoft, tenzij’ beleid betekent natuurlijk ook Microsoft Office, dus architectuur is ook hier bepalend.

De relatie naar het ‘nieuwe werken’ heeft met onze algehele architectuur te maken, variërend van een volledig gevirtualiseerd server- en desktoppark, en systemen zoals Sharepoint en Unified Communications oplossingen. Het nieuwe werken komt niet van de grond als je de bedrijfsapplicaties niet kan laten werken conform ‘any where, any time’.”

Daan: “Kan jij wat dieper ingaan op wat bij PGGM de bedrijfsarchitectuur inhoudt?”

Richard: “Samen met de business units (meestal de businessconsultants en de materiedeskundigen) bepalen we de keuzen t.a.v. product, systeem en organisatie.”

Daan: “Hoe vindt de besluitvorming ten aanzien van architectuur plaats, wie is accountable voor de architectuur? En wie is de eigenaar van een architectuur? Hoeveel architecturen hebben jullie eigenlijk?”

Richard: “Ik maak onderscheid tussen enterprise architectuur en projectarchitecturen. De eerste wordt geaccordeerd door mijzelf en de IT-governanceboard, waarin alle informatiemanagers van de verschillende business units en de ICT-directeur (als CIO rol) zitting hebben.

De projectarchitectuur wordt gevormd door de PSA. Deze wordt geaccordeerd door de manager architectuur, de betreffende informatiemanager (dit is meestal de opdrachtgever voor het project) en de projectleider (indien al aanwezig). Doordat deze drie verschillende soorten functionarissen elk vanuit hun eigen invalshoek controleren, wordt geborgd dat de projectarchitectuur aansluit bij de enterprise architectuur, dat de oplossing het probleem oplost zonder enorme beheer- en uitvoeringskosten, en dat de oplossing te realiseren is.
Daardoor zijn er meerdere ‘eigenaren’ van een architectuur. Neemt niet weg dat ik eindverantwoordelijk ben.

We hebben slechts één (actuele) versie van het informatiebeleid en één van de enterprise architectuur.
Daarnaast kennen we meerdere domeinarchitecturen, zoals bijvoorbeeld de integratiearchitectuur, de portalarchitectuur, de BI-architectuur, de infrastructuurarchitectuur, de technische applicatiearchitectuur. Deze worden opgesteld en geactualiseerd naar behoefte.

En qua projectarchitecturen, ik heb ze niet geteld, maar het zijn er meer dan 500.”

Daan: “Kan jij in grote lijnen jullie architectuurgovernance schetsen als proces?”

Richard: “We hebben geen expliciet architectuurgovernanceproces.
We hebben wel architectuurprocessen, die zich richten op het juiste gebruik van architectuur. Daarin staat hoe samen met de rest van de organisatie de enterprise en projectarchitectuur wordt opgesteld. Ook zijn er architectuurprocessen ten behoeve van de architectuurborging opgenomen, die onder andere handelen over het verlenen van zogenaamde architectuurcertificaten aan projecten.

Bij een groot project starten we met een PSA v1.0 aan de start van het project, waarin de technische paragrafen nog niet af zijn. Na de functionele fase wordt gecontroleerd en in een architectuurcertificaat vastgelegd of het project zich aan de architectuur gehouden heeft. Als dat niet goed is, dan hebben ook wij het niet goed gedaan als architecten, want we hebben het project dan niet voldoende begeleid. Gelukkig zijn de afwijkingen in de regel beperkt en worden afspraken gemaakt om een en ander in de volgende ontwikkelfase op te lossen. Het kan ook zijn dat we in overleg met het project bepaalde keuzen accepteren, en dan passen we de PSA aan. Normaliter komt het project bij issues sowieso al langs de architectuurafdeling en sparren we gezamenlijk over de oplossingsrichting. Indien nodig, wordt de PSA aangepast/uitgebreid. Gelijk met het AC1 wordt de tweede versie (2.0) van de PSA opgeleverd. Hierin is dan ook de technische architectuur uitgewerkt. Tijdens de volgende fase wordt het project begeleid (d.w.z. af en toe contact houden) en via AC2 in de test wederom gecontroleerd of aan de PSA is voldaan. Bij sterke afwijkingen die een groot risico opleveren kunnen we het AC onthouden, wat voor de meeste projectleiders iets is wat men te allen tijde wil voorkomen. Het is nog nooit gebeurd. Wel worden soms afspraken gemaakt ten aanzien van het oplossen van issues in volgende fases of releases. De afspraken worden bewaakt door de architectuurafdeling en (periodiek) besproken met de informatiemanager. Mocht het echt mis gaan, dan is er een escalatiepad waarlangs het probleem in een aantal stappen op het niveau van de Raad van Bestuur belandt.
In de kwartaalrapportage die vanuit de architectuurafdeling naar de Raad van Bestuur gaat, en gecontroleerd wordt door de ‘internal audit’ afdeling, wordt aangegeven in hoeverre projecten voldoen aan de architectuur en het informatiebeleid. De score ligt al jaren tussen 96-98%.

Naast veranderingen in de architectuur die door projecten worden veroorzaakt, kennen wij ook veel kleine ‘verzoeken tot wijzigingen’. Wij hebben een checklist die door de ‘projectleiders van het onderhoud’ en de zogenaamde implementatiemanagers wordt gevuld. De checklist bestaat uit een aantal vragen die bedoeld zijn om het architectuur- en securityrisico van de change te achterhalen. Indien op enige vraag van die checklist ‘ja’ wordt ingevuld, dient men contact op te nemen met de afdeling architectuur.
Periodiek wordt dit proces van ‘werken onder architectuur bij kleine change’s’ door de architectuurafdeling onder de aandacht gebracht bij de relevante afdelingen. Om na te gaan of de checklist niet te lichtvaardig wordt gehanteerd nemen we steekproeven.
Omdat de beheerafdeling de PSA’s gebruikt om een vroegtijdig beeld te krijgen wat een systeem gaat doen, is de vraag van de beheerafdelingen (zowel functioneel applicatiebeheer als technisch applicatiebeheer) om PSA’s de beste methode om werken onder architectuur af te dwingen.”

Ons IT-governanceproces is uitgewerkt in het artikel binnen het lac2009 boek3. Het governanceproces kent meerdere lagen:

  • Zo is er een IT-governanceboard, waarin alle informatiemanagers van de verschillende units en de directeur IFS (als CIO rol) zitting hebben. Deze board accordeert richtlijnen van de enterprise architectuur, verleent tijdelijke ontheffingen voor projecten die afwijken van het informatiebeleid (komt weinig voor, is met name nog wat oude legacy), stimuleert samenwerking over de units, en bereidt het informatiebeleid voor.

  • Daarnaast zijn er processen waarbij de enterprise architectuur via informatieplanningen omgezet wordt in projectenplanningen (overigens veroorzaken bedrijfsinformatieplanningen ook bijstellingen van de enterprise architectuur).

  • Die planningen komen in de jaarplannen van de units. Via de normale rapportagelijnen wordt op de uitvoering gecontroleerd. Zo ontstaat de koppeling met corporate goverance.

  • Daarnaast zijn er diverse ‘key controls’, zoals ‘aantal projecten onder architectuur’,’veilige informatievoorziening’, die zorgen dat architectuurprocessen aantoonbaar worden uitgevoerd. Die ‘key controls’ zorgen er onder andere voor dat PGGM KEMA gecertificeerd is qua IT en SAS type 2 voor diverse onderdelen van de bedrijfsvoering.”

Daan: “Welke architectuurprocessen zijn er nog meer buiten de architectuurgovernance?”

Richard: “We hebben totaal een twaalftal architectuurprocessen. Denk onder andere aan opdrachtbeheer, actualiseren informatiebeleid/EA, kennismanagement & communicatie, PSA, architectuurborging, innovatie, bedrijfsinformatieplanning, pakketselectie. Daarnaast zijn er natuurlijk de standaard managementprocessen (plan, do, check, act).”

Daan: “In jouw team zitten businessconsultants en architecten.
Wat is de werkrelatie tussen deze twee teams?
Zijn er in PGGM ook nog ergens businessanalisten en businessstrategen?”

Richard: “De helft van mijn team is architect, en de andere businessconsultant. Wij hebben een functiehuis dat rollen kent, en de architect en de businessconsultant zijn rollen van de adviesfunctie. Daardoor hebben de meeste architecten een bijrol businessconsultant en vice versa. Door de combinatie van deze rollen binnen de afdeling wordt veel pragmatischer en effectiever omgegaan met business- en informatiearchitectuur. Architecten worden ‘gedwongen’ om hun oplossingen vanuit een businessperspectief te toetsen en consultants worden ‘gedwongen’ om projectondersteuning en procesontwerp te laten aansluiten op de mogelijkheden (en beperkingen) die de architectuur levert. Het effect is dat we niet alleen een samenhangende holistische architectuur opstellen, maar door de projectbegeleiding/consultancy hem ook kunnen implementeren.

Een ander voordeel van het feit dat ze in een afdeling zitten, is dat door het delen van kennis tussen de twee groepen die overal in de organisatie betrokken zijn bij de projecten een heel goed beeld ontstaat van alle initiatieven. Daardoor kunnen we met de architecten goed aanhaken en de business helpen om synergie over units heen te bereiken door initiatieven te combineren.

De meeste units hebben ook zelf domeinbusinessconsultants. Daar werken we heel goed mee samen. We leveren extra capaciteit en verzorgen via ons consultancy comité voor verbinding tussen de diverse consultants.

Overigens werken we ook nauw samen met de lead engineers van de ontwikkelteams. Bij het bepalen van oplossingsrichtingen worden deze intensief betrokken en er is periodiek overleg om zaken te bespreken zoals nieuwe projecten en nieuwe versies van ontwikkeltooling.

Op deze manier haken we aan bij zowel de business als de uitvoerende ICT-organisatie (en hun processen).”

Daan: “De architectuurorganisatie bestaat uit architecten, experts die de architecten adviseren, een soort van architectuurboard, mechanismen om de architectuur consistent en coherent te houden, controlemechanismen om te borgen dat de afgesproken architectuur ook daadwerkelijk wordt geïmplementeerd etc. etc.
Die architectuurorganisatie hoort, zoals elke belangrijke organisatie, een missie, een visie en een strategie te hebben.
Kan jij iets zeggen over de missie, visie en strategie van de architectuurorganisatie bij PGGM?”

Richard: “De architectuurafdeling Informatie Architectuur (IAR) maakt jaarlijks een jaarplan, waarin onder andere de missie, visie en strategie staan, inclusief een terugbik hoe het voorgaand jaar is vergaan en de leerpunten daaruit.

De architectuurmissie is voor 2010:
‘Ontwikkelen en handhaven van informatie(beveiligings)beleid en informatiearchitectuur en het verzorgen van business- ICT alignment, alsmede het initiëren van innovatie op de architectuur’

De strategie bevat onder andere:
Hoge kwaliteit producten en diensten: zorg dat IAR een duidelijke meerwaarde op gebied van architectuur/business consultancy heeft.
Waarborg het werken onder architectuur en behoud/verbeter de huidige inbedding hiervan.”

Daan: “Hoe belangrijk is een goede architect? En waaruit blijkt dat?”

Richard: “Extreem belangrijk. Architectuur is mensenwerk. Een goede architect zorgt dat de architectuurdoelstellingen kunnen worden gehaald.
De voordelen die architectuur levert zijn vaak financieel aan te geven. Het kost dus gewoon geld als je geen goede architecten hebt.”

Daan: “Wat zijn volgens jou de karaktereigenschappen en competenties van een goede architect?
Trouwens wanneer is een architect goed? En door wie/wat wordt dat eigenlijk beoordeeld?”

Richard: “Qua competenties springen eruit:

  • resultaatgerichtheid (focus houden, hoofd & bijzaken kunnen scheiden),

  • inlevingsvermogen,

  • oordeelsvorming,

  • overtuigingskracht,

  • marktgerichtheid,

  • klantgerichtheid,

  • onafhankelijkheid,

  • kunnen samenwerken en

  • een redelijk portie creativiteit.

Daarnaast moet hij of zij conceptueel kunnen denken en een helikopterview hebben.
Basis is bovendien goede kennis en ervaring met IT en business.

Een architect is goed indien hij binnen de organisatie draagvlak weet te verdienen. Met andere woorden de diverse bedrijfsonderdelen erkennen zijn/haar deskundigheid en willen hem/haar graag als gesprekspartner omdat hij/zij hen en het probleem begrijpt en actief helpt om een visie neer te zetten ten aanzien van de oplossingsrichting.

PGGM is met iets meer dan duizend medewerkers niet zo heel groot, dus je hoort als manager toch wel snel hoe naar architecten gekeken wordt. Een andere indicatie is overigens de vraag naar bepaalde architecten. Iedere architect heeft een eigen specialisatie en meestal worden ze op naam gevraagd. De vraag naar architecten overtreft het aantal beschikbare architecten.”

Daan: “Welke carrièreadviezen, loopbaansuggesties zou jij aankomend architecten willen geven?”

Richard: “De meeste architecten hebben een achtergrond in de IT. Dat is niet vreemd omdat je als architect gewend moet zijn om te structureren en een affiniteit met IT nodig hebt. Om architect te kunnen zijn moet je naast de juiste competenties ook over veel ervaring beschikken in IT en business. Je moet weten wat je met bepaalde keuzen veroorzaakt. Hoewel je niet meer hoeft te programmeren of te ontwerpen (meestal dan) moet je, omdat ‘the devil is in the details’, de juiste keuzen kunnen maken. Anders wordt er echt niet naar je geluisterd. Dus, een bepaalde levenservaring is ook handig om status te verkrijgen.

Als advies: zorg dat je gevoel krijgt voor de businessprocessen en leer te denken vanuit de businessdoelstellingen. Een bedrijfskundige studie is dan ook een goede stap.”

Daan: “Ik neem aan dat jij de rechterhand bent van de CIO. Wat is jouw werkrelatie als lead architect met de CIO?”

Richard: “Formeel hebben wij geen Chief Information Officer, maar de directeur ICT functioneert als zodanig.
Ik zit in het MT van dit bedrijfsonderdeel. Wat betreft beleid en architectuur ben ik zijn rechterhand. Daarnaast heb ik goede relaties met alle informatiemanagers, de directeuren en de eerstelijnsmanagers.”

Daan: “Welke werkrelatie is er tussen jouw team enerzijds en de innovator en technologen anderzijds?”

Richard: “Wij zijn vaak zelf de initiator van innovatie, alhoewel er gelukkig overal binnen het bedrijf aan innovatie wordt gedaan. Er zijn heel goede contacten met de units die aan product/markt innovatie doen en wij worden meestal op tijd betrokken.
Door de vele contacten met beheer en engineering hebben we een zeer frequente relatie met de technologen.”

Daan: “Als ik rondkijk door de architectuurprestaties in Nederland zie ik duidelijk verschillende stijlen, verschillende smaken. Sommigen architecten houden van mensen en zetten de eindgebruiker centraal, sommige architecten houden van high tech en maken gebruik van de allerlaatste technologieën, sommige architecten zijn meer economisch ingesteld en zetten de effectiviteit en efficiency van de bedrijfsvoering centraal.
Kan jij iets zeggen over jouw persoonlijke architectuursmaak?”

Richard: “Ik ben behoorlijk pragmatisch ingesteld, en stel de strategie van de organisatie centraal. Daarnaast is het van alles wat. Ik kijk wel graag naar nieuwe technologie, maar dan vooral wat die kan betekenen. En in een financiële instelling is efficiency, customer intimacy en kwaliteit een standaard aandachtspunt.”

Daan: “Welke architectuurstijl hoort bij de bedrijfscultuur van PGGM? Of is dat afhankelijk van de architectuurvolwassenheid?”

Richard: “De architectuurstijl is vooral een aspect van de cultuur. Het valt niet mee om de stijl te classificeren bij PGGM. Ik denk dat ‘ondersteunend’ het dichtste in de buurt komt.”

Daan: “Hoe bepalend is die bedrijfscultuur van PGGM dan voor haar architectuur? Op wat voor soort architectuurprincipes heeft dat impact gehad?”

Richard: “De bedrijfscultuur is sterk bepalend voor de vormgeving van de architectuurprocessen. De cultuur kent, zoals in elk bedrijf, een bepaalde mate van politiek en dat betekent dat architectuurprocessen gericht moeten zijn op het betrekken van de juiste personen. In onze cultuur heeft architectuur vooral een dienstverlenend imago, het is geen doel op zich.

De effecten uit de cultuur op de architectuurproducten zijn beperkt. Er zijn wat extra beleidsrichtlijnen ten aanzien van hergebruik over units heen van processen en systemen.”

Daan: “Wat boeit jou persoonlijk in het beroep van architect?”

Richard: “Een aantal zaken, waaronder:

  • De enorme variatie aan zaken die spelen, van business tot ICT, met andere woorden de breedte en diepte van het werkveld.

  • Je kunt de organisatie echt vooruithelpen door het omzetten van een doel via een architectuur naar een gerealiseerd systeem/proces. Net zoals een bouwkundig architect kan genieten van de schoonheid van een gebouw en hoe goed het het doel dient, zo kan ik genieten van goed samenhangende processen en systemen.

  • De samenwerking met de verschillende disciplines om tot een goed resultaat te komen, en het plezier in dat creatieve proces.”

Daan: “Hoe blijft jij zelf bij in het vakgebied?”

Richard: “Op allerlei manieren: congresbezoeken, abonnementen (we hebben een Gartner abonnement en architectuurtijdschriften), veel bij anderen kijken, samenwerkingsverbanden, leveranciersbezoeken. Voorts verplicht ik iedereen in mijn afdeling om jaarlijks een presentatie te houden over een onderzoek ten aanzien van externe ontwikkelingen in de ICT, over trends in business en/of architectuur, over mogelijke kansen voor PGGM, of hoe anderen architectuur vormgeven ten aanzien van bepaalde vraagstellingen.”

Daan: “Welke trends zie jij in architectuur? En welke zijn relevant voor PGGM?”

Richard: “Het belangrijkste is dat de klant steeds meer verantwoordelijkheid krijgt en neemt ten aanzien van productontwerp en procesuitvoering. Voorts worden klanten steeds ongeduldiger. Dat betekent dat processen en de controle daarop anders worden ingericht, waarbij de controle op gegevenskwaliteit van het hoogste belang wordt. Dus niet alleen meer STP4, dat zich deels op internet baseert, maar een vraag naar transparantie en aantoonbare kwaliteit. En dat moet alles door systemen worden ondersteund.

Belangrijk wordt verder de veranderende arbeidsmarkt en dus de wijzigende manier van werken (‘het nieuwe werken’). Dat stelt eisen aan ‘any where, any time’ en vergt andere vormen van samenwerking. Dat vraagt een andere manier van kijken naar mensen, processen en systemen. Architectuur moet daarop inspelen.

Daarnaast zijn er de gebruikelijke hypes zoals:

  • de cloud (verwacht ik pas over zo’n 5 jaar bij PGGM in verband met de eisen aan recovery, beschikbaarheid en security),

  • de verdere groei van BI naar een platform waar de eindgebruiker het voor het zeggen heeft (in plaats van de DWH ontwerper),

  • service architectuur (SA)/SOA,

  • meer social networks.

We zullen deze zaken toepassen indien het de beste oplossingsrichting is voor een probleem. En niet andersom.”

Daan: “Wat is jouw toekomstbeeld van de architectuur bij PGGM over pakweg 10 jaar?”

Richard: “Ik zit al zo’n 15 jaar in de pensioenbranche en deze is continu in beweging. Dat zal dus wel zo blijven. En dat betekent dat de architectuur deze flexibiliteit steeds beter moet gaan ondersteunen. Ik verwacht dat op hoofdlijnen de architectuur niet veel zal wijzigen, we zullen nog steeds een modulair applicatie- en infrastructuurlandschap hebben, waarbij ongetwijfeld nieuwe componenten zullen worden toegevoegd. Een deel van de componenten, zeker die de secundaire processen ondersteunen, zullen vaker extern staan. Dat betekent dat de architectuurfocus verschuift naar integratie en beheer van de totale informatievoorziening (onder andere hoe waarborg je recovery/uitwijk). Kortom, het bewaken van de samenhang blijft belangrijk en vanuit de architectuurafdeling zul je de regiefunctie over de in- en externe componenten inhoudelijk moeten ondersteunen.”

1 redactie: Sommige ondernemingen noemen hun chief architect ‘lead architect’ om te benadrukken dat er vanuit een visie gewerkt wordt. Ook komen wij soms de aanduiding ‘controlling architect’ tegen bij ondernemingen die meer een accountancy-achtige attitude hebben ten aanzien van architectuur.

2 Het informatiemodel van PGGM is opgedeeld in een 20-tal functionele domeinen.

3 Integratie van enterprise-architectuur, informatieplanning en IT-governance als succesfactor voor het halen van strategische doelstellingen bij PGGM, auteurs : R.B. Lugtigheid en B. van der Laars. Dit artikel is onderdeel van het boek: Architectuur moet bijdragen, LAC 2009, onder redactie van C.M. Hendriks, J.A.Oosterhaven.

4 STP staat voor Straight Through Processing.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

29-05: KNVI sessie - kick-off ethish manifest voor architecten meer...

19-06: KNVI/PLDN sessie over semantische data integratie in de weg- en spoorinfrastructuur 

28-06: LAC summit meer...

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden