Bij de grootste pensioenverzekeraar van Nederland is een toekomstbestendige IT een absolute noodzaak. APG gaat immers verplichtingen aan voor de zeer lange termijn met haar klanten. Daan Rijsenbrij (architectuur-auditor) en Hotze Zijlstra (IT-journalist) mochten enkele vragen stellen aan Henk Dado en Gerben Wierda in hun rol van senior enterprise architect.
APG voert de pensioenadministratie uit voor acht pensioenfondsen waarvan twee (ABP en bpfBOUW) in de top 5 van Nederland staan. Het vermogen dat APG voor haar fondsen en hun 4,8 miljoen deelnemers beheert, was eind januari 2023 ongeveer 541 miljard euro waard. De pensioenuitvoerder heeft kantoren in Heerlen en Amsterdam maar ook vestigingen in Brussel, New York en Hongkong, plus satellietlocaties in Beijing en Shanghai. Bij APG werken ruim 3.000 medewerkers.
APG is een grote speler in de markt en haar missie is om het meest klantgerichte bedrijf in de sector te zijn. IT speelt daarin, naast het duurzaam en optimaal beleggen van het vermogen van de pensioenfondsen, een extreem belangrijke rol. Ruim een derde van de medewerkers van APG is dan ook op een of andere manier gelieerd aan de inrichting en het beheer van IT-oplossingen. Ontwikkeling vindt plaats op een Agile-manier en steeds meer Agile-teams ontwikkelen zich tot echte DevOps-teams.
Precies honderd jaar na de oprichting van ABP, het grootste pensioenfonds van Nederland waaruit APG is voortgekomen, bereidt de pensioensector zich voor op de grootste hervorming in haar geschiedenis: de overgang naar de nieuwe Wet Toekomst Pensioenen. Daarbij is een forse ingreep in het IT-landschap van de pensioenuitvoering en klantbediening voorzien. De rol van architectuur daarin is van essentieel belang.
Hoe ziet APG eruit voor een digitale architect?
Henk Dado: “Zoals een architect zou zeggen: ‘it depends’. Het hangt er van af wat met de vraag bedoeld wordt. Daarom misschien eerst maar iets over de organisatie van IT binnen APG en de rol van architecten daarin.”
“APG is georganiseerd in businessunits, allemaal met hun eigen value streams en DevOps-teams. De infrastructuur en generieke faciliteiten die nodig zijn, worden geleverd door een centrale IT-unit. Centrale kaders en beleid worden gemaakt door een centrale IT- en data-beleidsstaf. Elke unit en ook de centrale staf heeft een eigen architectenteam, waarbij de architecten zorgdragen voor een adequate inrichting van het digitale landschap. Om dat te kunnen doen zijn ze actief betrokken bij de ontwikkeling van IT-oplossingen. Synergie wordt bereikt door een overleg tussen Lead-architecten.”
“Voor de digitale architect ziet APG eruit als een organisatie die geen theoretische modellen ontwikkelt, maar echt betrokken is bij het maken van oplossingen”
“Om de DevOps-teams te begeleiden en te zorgen dat beleid daadwerkelijk wordt geïmplementeerd, worden value streams ondersteund door een virtueel zogeheten Health-team – deze teams bewaken de duurzame gezondheid van het IT-landschap. Zo’n Health-team bestaat uit mensen met verschillende disciplines zoals security, risk, IT-beheer, data, lifecycle management én architectuur. Dus voor de digitale architect ziet APG eruit als een organisatie die geen theoretische modellen ontwikkelt, maar echt betrokken is bij het maken van oplossingen.”
En hoe ziet APG er digitaal uit voor de architect?
HD: “Ik kan daar wel dagen over vertellen, maar je kunt stellen dat APG moderne architecturen en hulpmiddelen gebruikt, waarmee de vraag moet worden beantwoord hoe we een klantgericht, wendbaar, robuust en veilig landschap maken”.
Gerben Wierda: “De focus op concrete ontwerpbesluiten is inderdaad key. Dat is altijd een mengsel van overall-keuzes, bijvoorbeeld APG-brede technologiestandaarden, security-eisen, proceseisen, documentatie-eisen, etcetera en keuzes die je in individuele situaties moet maken. Zaken als: ‘koppelen we A aan B of via C?’ Om die keuzes goed te maken, moet je de mensen die ergens verstand van hebben zo efficiënt mogelijk laten samenwerken en je moet dat met de juiste checks and balances doen.”
Kunnen jullie iets zeggen over de grootse architectuurprestaties in de afgelopen vijf jaar?
GW: “Het is lastig om zoiets zuiver op architectuur te gooien. APG is bijvoorbeeld zoals veel organisaties aan het transformeren naar Agile/DevOps en dat is doorgaans een combinatie van architectuur die dat DevOps werken mogelijk moet maken – zoals selfservice voor Agile/DevOps teams die immers autonoom moeten kunnen zijn – en veel andere elementen zoals opleiding, organisatie, management focus, etcetera… Het is dus nooit alleen een architectuurprestatie. Qua echte inrichting van het landschap is het mooi wat wij gedaan hebben in de infrastructuur, met het aanbieden van infra als selfservice aan de DevOps-teams. Daarvoor hebben we in 2015 vanuit architectuur het fundament gelegd.”
“Infrastructuur is nu met een druk op de knop verkrijgbaar; volledig in control en met alles erop en eraan: logging, monitoring, deployment-pipeline. Een private cloud, maar dan met dingen die geen cloudprovider je kan leveren, zoals een managed operating system. We zijn nog bezig om ons enorme landschap daar zo veel mogelijk in te krijgen. De eerste externe review vertelde ons dat we veel valkuilen waar andere organisaties in lopen, hadden weten te vermijden.
Een voorbeeld van zo’n valkuil was dat het bijvoorbeeld heel makkelijk is om uitzonderingen te maken en systemen ‘tijdelijk’ uit het standaard automatische beheer (‘cattle’) te halen. Na verloop van tijd had zo’n organisatie dan een team van 30 man die uitzonderingen (‘pets’) met de hand aan het beheren was. Die discipline om uitzonderingen te vermijden – die overigens niet eenvoudig vol te houden is – hadden en hebben wij wel omdat wij weten dat ook een landschap van uitzonderingen feitelijk je de facto ‘architectuur’ wordt. Een andere valkuil is het negeren van de gebruikende DevOps-teams en hun te ondersteunen bij het toepassen van de nieuwe ‘way of working’, ook dat is een continue uitdaging die commitment vereist.”
“APG heeft vanuit het functionele ‘why’ naar het technische ‘how’ een heel mooie strategie geformuleerd. Daarin staat letterlijk ‘een wendbaar en robuust IT-landschap’ als strategisch doel, en dat is wat mij betreft precies waarvoor architectuur nodig is. Dat wil trouwens niet zeggen dat het meteen een gelopen race is. De druk op de organisatie is van alle kanten enorm – van toezichthouders, klanten, cybercriminelen en ga zo maar door. Je moet pragmatisch blijven. Een extra uitdaging van architectuur is dat niemand van buiten er eigenlijk om vraagt. Het vereist dus een enorme discipline van de organisatie zelf om tegen de druk van buiten in aan architectuur te doen.”
Welke cruciale architectuuruitdagingen zien jullie aankomen in de pensioensector?
HD: “APG heeft met de komst van het nieuwe pensioenstelsel gekozen voor een nieuw pensioensysteem dat volledig gebaseerd is op een moderne en event-driven-architectuur. Dat concept willen we nog breder toepassen in de organisatie en dit levert nieuwe vraagstukken op ten aanzien van veiligheid, volledigheid en aansluiting op bestaande systemen. Welke interfaces gaan we hoe aanpassen, hoe besturen en beheersen we processen in een combinatie van orkestratie en choreografie?”
“Aan de kant van vermogensbeheer gaan we meer stappen zetten in het, op self-service-basis, toepassen van analyses op allerlei data om de juiste en ook duurzame investeringsbeslissingen te kunnen nemen. Dat vraagt om mogelijkheden en toepassingen om data te verzamelen, te verifiëren, te kunnen interpreteren, te autoriseren en modellen te kunnen maken. Het digitaliseringsprogramma is voor onze vermogensbeheerder van groot belang en ook daar speelt architectuur een grote rol.”
“APG heeft vanuit het functionele ‘why’ naar het technische ‘how’ een heel mooie strategie geformuleerd”
GW: “Wat mij betreft zijn – even los van de invoering van het nieuwe pensioenstelsel – de architectuuruitdagingen hetzelfde als in andere sectoren die zuiver informatiegedreven zijn en niet echt een fysieke kant hebben. Vanuit mijn perspectief zijn dat er altijd twee: de ene is organisatorisch, oftewel ‘architectuur als proces’. Hoe zorg je ervoor dat je goede keuzes maakt in een organisatie waar niemand alles van alles kan weten? Dan heb je het vooral over hoe die besluitvorming is ingericht, waar zit het eigenaarschap en waar zitten de checks & balances? Hoe combineer je zorgvuldigheid met snelheid?”
“Het tweede is momenteel de wijze waarop wij infrastructuur – zowel on-premises als cloud – beschikbaar maken in de organisatie. Dan gaat het meer over de technische inrichtingskeuzes, dus ‘architectuur, het ding’. Voor dat laatste hanteer ik een heel eenvoudige definitie: architectuur is de verzameling van keuzes die, eenmaal gemaakt, lastig te veranderen zijn. Een IT-landschap is lastiger te veranderen dan mensen, dat realiseert men zich niet altijd.”
Kunnen jullie enkele voor APG specifieke architectuurprincipes noemen met hun mogelijke impact?
GW: persoonlijk vind ik architectuurprincipes een instrument met meer nadelen en risico’s dan voordelen – en ik heb wel eens een megaproject (150 miljoen euro, niet bij APG) zien stuklopen vanwege het volgen van een architectuurprincipe. Ik heb er liefst zo weinig mogelijk, want de beste keuze komt niet voort uit het simpel volgen van eenvoudige regels. Architectuurprincipes zijn meestal goede beschrijvingen van gewenste uitkomsten, maar je bereikt die uitkomst niet door daar simpelweg naar te streven, net zo min als ik een schaakwedstrijd kan winnen door op elke materiaalwinst in te gaan. Ik vind dat de ‘principes’ in de architect moeten zitten en niet de architect in de principes moet (vast)zitten. Zetten wij in op bepaalde patronen? Uiteraard. Maar comply or explain vind ik ronduit gevaarlijk.
Hoe zijn de architecten bij APG georganiseerd?
GW: Wij hanteren een federatief model. Elke business unit (BU) heeft een lead architect en daarnaast zijn er lead architecten op specifieke initiatieven. Hoe een BU zijn architectuur inricht is eigenlijk per unit anders, vaak toegesneden op de specifieke behoefte van die BU. Bij Pensioenuitvoering zitten de architecten bijvoorbeeld in één club met de mensen die alles weten van de inhoud van pensioenregelingen (de ‘materiespecialisten’), terwijl in de Shared Infra Services (SIS) unit, omdat het allemaal IT is, er vele architecten zijn die niet allemaal in de centrale club zitten (maar wel nauw samenwerken). In de top-level profielen van DevOps engineer zie je dan ook architectuur-elementen terug.
Binnen SIS hebben wij bijvoorbeeld nu samenwerking van de ‘architecten’ van de diverse product teams in een value-stream-breed overleg, voorgezeten door de value stream lead architect waar de SIS-brede lead architect – ik of mijn plaatsvervanger – bij kan aansluiten (en dat ook doet), zodat als je keuzes maakt ten aanzien van ‘hosting’ in de ene landing zone je niet in isolatie je keuzes maakt, maar andere landing zones, of andere aspecten zoals deployment en development support hangen daar mee samen.
Welke standaard profielen hanteert jullie HRM-afdeling voor een architect
HD: APG hanteert verschillende profielen voor architecten: naast enterprise architect zijn er ook profielen voor software-architect, TI-architect en business & information architect. Dat is afhankelijk van het specialisme of juist het generieke karakter. De enterprise architecten worden geacht overal wel verstand van te hebben en fungeren vaak ook als solution architect. In de praktijk lopen de diverse rollen echter in elkaar over en weten TI-architecten bijvoorbeeld vaak ook veel van software en vice versa. Met name in de samenwerking tussen de diverse architecten ontstaat de beste architectuur.
Wat is jullie rol tegenwoordig binnen APG en hoe werken jullie samen?
GW: “Henk heeft mij ooit, nog net in de tijd van ABP, aangenomen. Daar heeft-ie nog jaren spijt van gehad, denk ik. Zonder gekheid: Henk is iemand die bijna zijn hele werkzame leven sterk sturend is geweest ten aanzien van het landschap van ABP, vaak als lead architect van de totale organisatie. Hij paart strategisch denken aan technisch inzicht, wat betekent dat je altijd een uitstekend inhoudelijk gesprek met hem kunt voeren.”
“Ik zag meteen dat de organisatie een sterke kwaliteitsbehoefte had en erg innovatief kon zijn: men had al een service bus zelf gebouwd voor je zoiets op de markt kon kopen. De keerzijde was een remmende voorsprong, want heb je zoiets eenmaal draaien, dan kom je er niet altijd makkelijk van af. Ik vond de behoefte aan kwaliteit en dat er wat te verbeteren viel wel aantrekkelijk.
“De echte – dus niet de papieren – architectuur van een organisatie, is de uitkomst van een enorme zee aan grotere en kleinere ontwerpbesluiten door de jaren heen”
HD: “In de ruim veertig jaar bij ABP en APG in diverse management-, consultancy- en architectuur-rollen ben ik altijd nauw betrokken geweest bij de inhoud. In een van die rollen heb ik ooit Gerben aangenomen en daar heb ik zeker geen spijt van. Gerben weet veel, is analytisch, heeft een visie en kent grote lijnen én de details. Hij weet dus niet alleen hoe iets werkt maar kan het, als het moet, ook nog wel zelf maken. Inmiddels werken Gerben en ik allebei op een andere plaats in het bedrijf. Ik ben volledig betrokken bij het programma om het nieuwe pensioenstelsel te introduceren, Gerben richt zich op de complexere vraagstukken rond IT-infrastructuur en architectuur in het algemeen. Waar het echt lastig wordt vraag ik Gerben zeker om advies.”
GW: “Als het nodig is weten we elkaar snel te vinden, dat is handig. Eigenlijk is mijn rolinvulling redelijk klassiek, inhoud aan de ene kant en proces aan de andere. Dus verstandige besluiten promoten en zorgen dat er voldoende knowhow en checks & balances in het besluitvormingsproces zitten. Voor mij is die combi voor een ontwikkelteam net zo geldig als voor een organisatie als geheel, het wordt alleen steeds groter en lastiger naar mate je de scope verruimt.”
Hoe zijn jullie de architectuur ingerold en wat vinden jullie er nog steeds fascinerend aan?
HD: “Het heeft te maken met wie ik ben. Als kind wilde ik al dingen maken, weten hoe ze werken en iets nieuws en beters creëren. Hoewel opgeleid in elektrotechniek/informatietechniek kwam ik, min of meer toevallig, als systeemontwerper in de IT terecht. Als je dan nog steeds wil begrijpen en verbeteren, heb je al gauw een link met architectuur. Maar ook met besturen, beïnvloeden en leidinggeven, want al snel leerde ik dat alleen techniek niet genoeg was. Die combinatie van de IT-kant en de menskant is nog steeds fascinerend. Hoewel IT zich de afgelopen decennia heeft ontwikkeld – alhoewel we dat niet moeten overdrijven, want veel basisprincipes zijn nog altijd hetzelfde – is en blijft het de kunst om een goede architectuur neer te zetten in de cultuur en besluitvormingsstructuur van een organisatie.”
GW: “Ik ben ooit als software engineer begonnen en ontwerp was altijd al een belangrijk onderwerp. Zodra je ervaren hebt hoe lastig de situatie al na een paar maanden wordt als je dat niet goed in de gaten houdt, wordt ‘ontwerp’ noodzaak om te kunnen presteren. Ik heb naast software engineering vervolgens ook strategie en beleid gedaan. Begin 2000, als hoofd van de afdeling Digitale Technologie van het Nederlands Forensisch Instituut, merkte ik hoe enorm belangrijk gezonde ontwerpkeuzes waren voor onze resultaten en hield ik daar als formele producteigenaar ook inhoudelijk de vinger aan de pols. Toen ik kort daarna bij het informatiemanagement van de Rechtspraak aan de slag ging, was er een gat: we hadden geen lead architect, alleen een tijdelijke ondersteuning van buiten. Ik ben die rol toen formeel op me gaan nemen.”
“De architectuurrol is fascinerend en tegelijkertijd frustrerend. Fascinerend, omdat het een enorme intellectuele uitdaging is en blijft. Frustrerend om precies dezelfde reden: je hebt enorm veel samenwerking nodig om tot verstandige besluiten te komen – niet iedereen kan tenslotte alles van alles weten – en niet iedereen heeft ruimte voor die complexiteit. Ergens denk ik weleens dat we met de IT-revolutie een grens gaan bereiken aan ons vermogen als mensen om complexiteit nog aan te kunnen. Dat moment wil je zo lang mogelijk uitstellen.”
“Als je mij nu vraagt wat de belangrijkste kennis is die een enterprise architect moet hebben, dan zeg ik techniek en psychologie. Ik heb mij de afgelopen jaren enorm verdiept in dat laatste, vanwege de vraag hoe overtuigingen en besluiten nu eigenlijk tot stand komen.”
Wat verwachten jullie van architectuur en architecten in 2030?
HD: “In 2030 is dat niet veel anders dan vandaag. Volg de ontwikkelingen, zorg dat je weet hoe ze werken en gebruik je ervaring om te weten waar het venijn zit – vaak in de details. De komende tijd zit het venijn ook steeds meer in security. Het ‘by design’ neerzetten van veilige oplossingen op basis van voldoende kennis is een van de toenemende uitdagingen voor architecten. Een andere ontwikkeling, hoewel zeker niet nieuw, is cloud. Het is aan de architecten om in een wereld van oneindige mogelijkheden de juiste basiskeuzes te maken. En wat ik altijd al als lijn hanteerde: ‘be where the action is’ en niet in een ivoren torentje.”
GW: “Emerging architecture is een handig begrip. De echte – dus niet de papieren – architectuur van een organisatie, is de uitkomst van een enorme zee aan grotere en kleinere ontwerpbesluiten door de jaren heen. De beste échte architectuur krijg je daarom als je in de organisatie de hele tijd zoveel mogelijk ‘goede keuzes’ maakt – net zoals je alleen een goede stelling krijgt op een schaakbord door heel veel goede zetten te maken. Maar heel weinig van die keuzes zijn goed top-down in een waterval te sturen, laat staan met een paar principes. Ze zijn ook vaak erg lastig. Ik zet daarom het liefste in op ‘consent-based decision making’ waarbij ik gebruikmaak van de inhoudelijke kracht van zoveel mogelijk mensen.”
“Wat de architecten betreft: McKinsey heeft laatst als een van de eerste grote consultancies terecht een lans gebroken voor het belang van technisch inzicht voor enterprise architecten. Ik vergelijk het altijd met je chief legal counsel. Als je een trusted advisor wilt voor het juridische, dan wil je iemand die de bits en bytes van de wet goed begrijpt en daar een diepgaande discussie over kan voeren. Mensen struikelen nu eenmaal niet over bergen, maar over molshopen. Dat geldt net zo goed voor IT. Hoog-over, top-down architectuur is weinig effectief gebleken de afgelopen dertig jaar. Ik verwacht van architectuur in 2030 hetzelfde als nu: zorgen dat de besluiten die je maar lastig kunt terugdraaien als ze eenmaal in je landschap verankerd zijn, goede besluiten zijn. Ik verwacht ook dat het steeds moeilijker gaat worden.”
Wat zijn jullie ‘lessons learned’ die je aan de lezers zou willen meegeven?
GW: “Die verwoord ik eigenlijk meestal op mijn blog, maar dat zijn algemene lessen uit mijn netwerk en niet zozeer APG-specifiek. De laatste jaren is mijn kernboodschap dat veranderen steeds moeilijker gaat worden naarmate onze business-IT-landschappen door IT complexer worden. In feite kun je zeggen dat we in de IT-revolutie als organisaties al enige decennia de productiviteit verhogen, maar dat we daarvoor betalen met steeds minder wendbaarheid.”
“Dat merk je ook op het niveau van de samenleving. Als je als regering iets via de Belastingdienst wilt regelen – bijvoorbeeld een regeling rond energiekosten – dan moeten de systemen veranderen en dat wordt steeds lastiger. Je bent zo drie jaar verder. In media wordt vaak negatief geschreven over die lange tijdslijnen bij de Belastingdienst, maar die conclusie zou ik niet zomaar trekken. Het is zeker deels gewoon ook de nieuwe werkelijkheid.”
“Er is zelden één goede keuze, maar je kunt wel degelijk foute keuzes maken”
“Het is een fundamenteel probleem dat ik ‘complexity crunch’ heb gedoopt. Mijn architectuurvisie is dan ook dat het steeds belangrijker wordt om niet zozeer een bedrijfsstrategie om te zetten in het juiste landschap, maar dat we steeds meer aandacht zullen moeten besteden aan ‘strategic agility’: naast het executeren van de huidige strategie zoveel mogelijk vermijden dat je middels je landschap vastzit aan die huidige strategie. Ik chargeer weleens dat de bedrijfsstrategie voor mij irrelevant is, omdat ik moet zorgen dat er landschapskeuzes worden gemaakt die meerdere, soms radicale wijzigingen van de strategie kunnen overleven.”
HD: “Door de jaren heen ben ik nauwelijks onder de indruk geraakt van theoretische architectuurmodellen. Enerzijds gaan ze vaak over hetzelfde. Anderzijds dragen ze maar beperkt bij aan het succes van een onderneming. Dat geldt ook voor dikke boekwerken over de architectuur van je bedrijf. Natuurlijk moet je weten hoe het landschap in elkaar zit, maar als je meer tijd bezig bent met alles in kaart brengen en houden, in plaats van het maken van keuzes die er daadwerkelijk toe doen – zie ook het pleidooi van Gerben over moeilijk veranderbare zaken – dan ben je niet bezig met architectuur maar met beheren. Ook belangrijk, maar niet de directe taak van architecten.”
“Zorg dus dat architecten betrokken zijn bij de belangrijkste ontwikkelingen die je als bedrijf wilt doorvoeren. Niet alleen op papier, maar ook dicht bij de teams die het werk doen. Houd je belangrijkste architecten in huis, want zij zijn echt betrokken en worden uiteindelijk geconfronteerd met de gevolgen van minder goede keuzes. Er is zelden één goede keuze, maar je kunt wel degelijk foute keuzes maken. Om die te vermijden is het belangrijk dat architecten niet alleen hun (IT-)vak verstaan, maar ook in goed contact kunnen staan met de beslissers, passend bij de cultuur van het bedrijf. Organiseer de governance zo dat architecten een stem hebben. ‘Be where the action is’ heeft dus niet alleen betrekking op aanwezigheid in de DevOps-teams, maar zeker ook op de plek waar de beslissingen genomen worden.”
Over Henk Dado
Henk Dado (1959, LinkedIn) vervulde in zijn loopbaan bij APG bijna 30 jaar diverse management- en directierollen van grotere (300 fte) en kleinere organisatie-eenheden (10 fte) en bleef daarbij aandacht houden voor de IT-inhoud. Hij was de (pro)motor van de service georiënteerde architectuur van APG en belangrijke architect van de automatisering van de automatisering. De laatste jaren is zijn loopbaan gericht op consultancy en architectuur. Vanuit zijn ervaring gaf hij onder andere de IT-governance bij APG vorm en adviseert hij directieleden met betrekking tot (IT-) vraagstukken en architectuur.
Over Gerben Wierda
Gerben Wierda (1961, LinkedIn, Mastodon) is lead architect van de Shared Infrastructure Services organisatie van APG en daarnaast thought leader in enterprise architectuur als spreker en auteur (Chess and the Art of Enterprise Architecture, Mastering ArchiMate, blog). Voor hij bij APG werkte was hij lead architect van de Rechtspraak in Nederland, hoofd Afdeling Digitale Technologie van het Nederlands Forensisch Instituut, staflid van de Adviesraad voor het Wetenschaps- en Technologiebeleid, en had hij diverse rollen in de IT (BSO, AKZO, RuG). Hij is actief in IT van de ‘bits en bytes’ tot aan de effecten op de samenleving.
