Henk Dado, manager Concern Informatiemanagement bij APG

Transcriptie

1 Henk Dado, manager Concern Informatiemanagement bij APG interviewer Daan Rijsenbrij t.b.v. Via Nova Architectura Henk Dado geeft momenteel leiding aan het Concern Informatiemanagement bij de Algemene Pensioen Groep (APG). Daarmee is hij verantwoordelijk voor ontwerp, realisatie en implementatie van het ICT-beleid, waaronder de ICT-architectuur, inclusief de infrastructuur. Zijn verantwoordelijkheid omvat tevens consultancy, beveiliging en methoden, technieken en hulpmiddelen voor systeemontwikkeling. De totale groep is, inclusief ondersteuning op methoden en tools, ongeveer 50 FTE. Overigens zal hij deze rol binnenkort verruilen voor een andere managementpositie binnen APG. De belangrijkste succesvolle architectuurissues van de laatste jaren zijn: Implementatie van een near-soa architectuur waarmee het mogelijk is geworden om de diverse bedrijfsfuncties te ontkoppelen en deze te ontsluiten naar de persoonlijke internet omgevingen. Bovendien heeft hergebruik van diensten en services een grote vlucht genomen, waardoor een betrouwbaarder informatievoorziening is ontstaan die op elk kanaal dezelfde informatie geeft en dezelfde berekeningen uitvoert. De overstap van traditioneel ontwikkelen naar een OO-gebaseerde manier, gecombineerd met de ontwikkeling van webservices. Dit heeft geleid tot de inrichting van governancestructuren en een sterke bewakingsrol van de architectuur. Ontwerp en ontwikkeling van een, op de meest moderne inzichten en diverse lagen gebaseerd, pensioensysteem, waaronder gebruik van ESB, Portals, processervers, en business-rule engines. Binnen deze architectuurlijnen wordt een geleidelijke (doch complexe) overgang van het oude naar het gemoderniseerde systeem mogelijk gemaakt. Inrichting virtualisatie en nieuwe storage oplossingen ter reductie van kosten en het ontwikkelen van een infrastructuurconcept voor 7 X 24 uurs dienstverlening. Opzet van een nieuwe netwerkarchitectuur. Daan: Hoe wordt architectuur formeel gedefinieerd binnen APG? Henk: Er is geen formele definitie van architectuur in de betekenis dat er een theoretisch document is waarin het haarfijn wordt gedefinieerd. Architectuur wordt breed gezien als het middel om businessdoelstellingen en proces- en ICT-inrichting maximaal op elkaar te laten aansluiten. Architectuur is het totaal aan samenhangende afspraken, beleidslijnen en modellen die worden gemaakt op de verschillende domeinen (processen, applicaties, gegevens, infrastructuur, producten). Daan: Hoe leg je architectuur uit aan je vrienden en kennissen die niet in de IT zitten? Henk: De metafoor van de stadsplanner, de gebouwenarchitect en ook de ondergrondse infrastructuur werkt veelal in voldoende mate. Dit gelardeerd met voorbeelden (uit de fysieke bouwwereld) wat er gebeurt als je onvoldoende aandacht voor architectuur hebt. Ik geef meestal ook een van de belangrijke verschillen aan. In stads- en gebouwenarchitectuur Augustus

2 is mooi en esthetisch een van de criteria. In de ICT-architectuur is functioneel en voldoen aan behoeften voor zomin mogelijk geld vaak het meest doorslaggevend. Uiteindelijk gaat het vrijwel altijd over de vraag: welk doel wil je bereiken? Daan: Waarom is architectuur eigenlijk nodig bij APG? Henk: APG is een uitvoerder van Pensioenregelingen. We willen betrouwbaar, degelijk en concurrerend vermogensbeheer, pensioenbeheer en ondersteuning voor pensioenfondsen kunnen uitvoeren. Dit alles met een goede service. Het aspect om meerdere fondsen te kunnen bedienen tegen zo laag mogelijke kosten, vraagt om oplossingen die dat mogelijk maken. Ieder pensioenfonds zijn eigen APG organisatie, pensioensystemen, internet aansluitingen, betaalomgevingen en vermogensbeheer-toepassingen is dan niet de meest slimme optie. Vanuit de architectuur moet dus vorm worden gegeven aan oplossingen die de bedrijfsdoelstellingen (vanuit de bestaande situatie) zo optimaal mogelijk invullen. Daarbij houdt architectuur bij ons zich ook bezig met de vraag hoe en in welke volgorde dat dan het best kan worden ingevuld. Daan: Wordt die noodzaak ook daadwerkelijk door de businessmanagers bij APG ervaren? Henk: Het ervaren van de noodzaak verschilt per businessunit. Naarmate businessmanagers zelf meer kennis hebben van principes van bedrijfsinrichting en van ICT wordt de noodzaak van een goede architectuur meer onderkend. Tegelijkertijd betekent dit dat deze businessmanagers dan ook zelf meer sturen op de gekozen architectuur zodat architecten goed voorbereid voorstellen dienen te doen. Businessmanagement en architecten worden dan sparringpartners. Dit is zeker bij een aantal businessunits het geval. Daan: Hoe heb je trouwens architectuur verkocht aan de business? Henk: Je kunt architectuur eigenlijk niet verkopen, maar je moet het doen. Wij hebben dat onder andere ingevuld door per (business) unit lead architecten in te zetten die dicht bij het informatiemanagement van die eenheid opereren en door de business worden gezien als ondersteuning voor businessvraagstukken. Door op die architecten een concernbrede hiërarchische sturing te zetten kun je, op een zachte manier, bewaken dat alle projecten dezelfde kant op bewegen. Zonder kennis van de business is architectuur overigens helemaal niets. Daan: Interessante opmerking om lead architecten dicht bij het informatiemanagement neer te zetten. Nog bij teveel ondernemingen zie ik dat informatiemanagement en architectuur op één hoop wordt gegooid, terwijl het voor mij twee verschillende doch complementaire functies zijn. Kan jij hier iets over zeggen in de context van APG Henk: Informatiemanagement bestaat bij ons hoofdzakelijk uit businessconsultants en businessanalisten die de processen ontwerpen en functioneel beheerders. Zij zijn dus erg bezig met de vraag (demand) vanuit de business. ICT-Architectuur gaat over het vertalen van businesswensen in de juiste ICT oplossingen. Daarbij kiezen we er ook nog voor om de samenhang tussen die oplossingen organisatiebreed te bewaken. Er is echter wel een wisselwerking tussen de wat en de hoe vraag. Een strikte wat-hoe -scheiding is volgens mij niet mogelijk. Tenslotte praat je bij het definiëren van eisen voor een huis met een architect die, dat mag je toch hopen, ook verstand heeft van bouwen, constructies en bouwmaterialen. Om dus de goede balans te vinden moet je dus met elkaar samen optrekken bij het definiëren van het wat en de mogelijke oplossingsrichtingen. De combinatie van deze zaken maakt dat deze constructie voor APG gekozen is. Daan: Zijn er concurrenten of overeenkomstige ondernemingen/organisaties met een architectuur waar je een beetje jaloers op bent? Henk: Ik kom natuurlijk wel eens organisaties tegen die op deelgebieden verder zijn. Maar een organisatie die ik als algemeen voorbeeld gebruik of jaloers op ben, heb ik niet. Wel ben ik ervan overtuigd dat er veel te leren is van andere organisaties. Niet om overall stukken te kopiëren, maar om ervaringen met werkwijzen of architecturen te delen. Daan: Welke speciale architectuurprincipes zijn er bij APG? Op welke strategische uitgangspunten zijn die gebaseerd? Augustus

3 Henk: Tja, ik zou bijna een antwoord geven met een vraag om specificatie van wat je bedoelt met speciale principes. We hebben een stuk of 20 globale architectuurprincipes en vele kleinere. Zo zijn er naast de globale principes ook architectuurafspraken over hoe een stenen gebouw (lees bijvoorbeeld een applicatie in dot-net) er uit moet zien of over de manier waarop infrastructuur wordt opgebouwd. Misschien speciaal is het principe dat informatie die we geven betrouwbaar moet zijn en ongeacht het door de klant gekozen communicatiekanaal altijd hetzelfde. Onder andere dat principe heeft zich weer vertaald in een services georiënteerde architectuur. Ook de principes dat flexibiliteit alleen wordt aangebracht waar dat nodig is en dat materie wordt ontkoppeld (specifieke rekenfuncties) lijken open deuren, maar hebben hun waarde in de praktijk bewezen (hoge service, zo laag mogelijke veranderkosten). Daarnaast hebben we meer technologische principes zoals het gebruiken van bewezen technologie. Voor alle globale principes geldt dat zij zijn terug te voeren op voor onze organisatie strategisch belangrijke zaken die ik reeds eerder noemde. Daan: Nu je de term services georiënteerde architectuur noemt, ben ik eigenlijk wel geïnteresseerd in wat jij bedoelt met near-soa architectuur. Kan jij daar iets meer over zeggen? Wat impliceert near? Henk: Bij pure SOA praat je over gemeenschappelijke datamodellen, onderscheid in businessservices en ander type services etcetera. Daar zijn we nu pas mee gestart. We hebben het echter wel veel eerder mogelijk gemaakt dat services zijn gedefinieerd die data leveren of rekenfuncties uitvoeren en dat onafhankelijk van het onderliggende platform. Sommigen bij ons noemen het meer enterprise application integration dan SOA. Daan: Welke architectuurconcepten heb jij geïntroduceerd waarop je echt trots bent? Henk: Het gebruik van services binnen APG bestaat al jaren en is vanuit mijn architectuurclub geïnitieerd. Aanvankelijk beschouwd als een last, werden de voordelen ingezien toen internet steeds meer als kanaal werd gebruikt. Inmiddels is het een geaccepteerd verschijnsel om betrouwbare informatie te leveren, functionaliteit te hergebruiken en om systemen met elkaar via services te laten communiceren. Daan: Ik neem aan dat jullie ook pakketten gebruiken dan wel outsourcen. Welke rol speelt architectuur en de architecten daarbij? Henk: Onze basislijn van denken is dat hergebruik voor kopen gaat en kopen voor maken. Dit uiteraard met gebruik van gezond verstand. Deze lijn is namelijk zeker niet altijd de meest verstandige. Zowel hergebruik, maar zeker pakketten, passen vaak niet bij de gewenste architectuur. Bij de keuze van pakketten spelen architecten vaak wel een rol, maar zeker geen doorslaggevende. Het is vervolgens aan de architect om het in te passen in de bestaande situatie. Daan: Over hergebruik gesproken, jullie gebruiken een OO-gebaseerde manier van het ontwikkelen van webservices. Is dat OO in de uitgebreide betekenis, met overerving etc. of heb jij een wat beperktere invulling? Henk: Ik praat liever maar even over OO-ontwikkelen, los van de vraag of dat over webservices gaat. Met OO zijn we ongeveer een jaar of twee, drie geleden echt begonnen en dat gaat inderdaad over de echte OO-principes, zoals je er een noemt. In de praktijk valt dat echter nog behoorlijk tegen, want het is een paradigmashift in de manier van denken. Veel van onze OO is dat in de praktijk dan ook maar zeer ten dele. Daan: Wat is de (business)waarde van architectuur? Is dat eenduidig in geld uit te drukken? Henk: In theorie is vrijwel alles in geld uit te drukken dus in principe ook de waarde van een goede architectuur. De vraag is alleen waar je het tegen afzet. Wat zou er gebeuren als je geen goede architecten zou hebben of vrij bouwen zou toestaan. Hoeveel slechter zijn we dan af? Zouden er dan geen krachten zijn opgestaan die bijvoorbeeld geroepen zouden hebben: Nog een sporthal binnen 300 meter, is dat niet wat veel het goede? Of: Met deze Augustus

4 ontwikkeling kunnen we de kosten sterk verlagen terwijl we tegelijkertijd meer flexibiliteit bereiken? Misschien wel, misschien niet. Kortom een goede architectuur sluit aan bij de strategie van het bedrijf. Ontwerp en bewaking daarvan zorgt dat deze strategie beter kan worden ingevuld. Als de strategie er bijvoorbeeld uit bestaat om vooral zo goedkoop mogelijk te zijn, moet de architectuur daarop gericht zijn. Maar wat is dan de waarde van die architectuur sec? Daan: Hoe uniek is jullie architectuur? Zijn er referentiearchitecturen voor jullie sector? Henk: Onze architectuur is redelijk uniek. Dan gaat het niet zozeer over de globale architectuurprincipes (veel tref je ook bij andere bedrijven aan), maar wel de manier waarop we het toepassen en de modellen die we gebruiken. Onlangs hebben we een onderzoek gedaan naar een marktstandaard, maar die uiteindelijk niet kunnen gebruiken omdat die toch niet helemaal passend was. Dat heeft niet te maken met de vakinhoudelijke aspecten van de architectuur, maar ook met de kennis en de cultuur van de organisatie. Dat heeft geleerd dat architectuur niet alleen moet passen bij je bedrijfsstrategie, maar ook bij de kennis, de cultuur en het verandervermogen van je bedrijf. Daan: Wat zijn volgens jou de belangrijkste kwaliteitscriteria voor een waardevolle architectuur? Henk: Er zijn verschillende architecturen voor verschillende doelgroepen (denk aan procesarchitectuur, applicatiearchitectuur, softwarearchitectuur, infrastructuurarchitectuur). Dit ook nog op verschillende niveaus. Het belangrijkste kwaliteitscriterium is dat de doelgroep die er iets mee moet, of het nu gaat om besluiten nemen of implementeren, begrijpt (en waar van toepassing instemt) met wat ermee wordt beoogd en wat ermee wordt bedoeld. Daan: Kan je iets zeggen over het architectuurproject dat op dit moment jouw hoogste aandacht heeft? Wat is de ontwerpopdracht en welke grote uitdagingen zitten daarin? Henk: Momenteel zijn we bezig met een geleidelijke vernieuwing van onze primaire pensioensystemen door zeer moderne technologie. Tegelijkertijd moet het systeemcomplex gaan voldoen aan onze eisen van flexibiliteit, betrouwbaarheid en lage kosten. Met name het aspect van geleidelijke vervanging (oud en nieuw bestaan geruime tijd naast elkaar en zijn volkomen transparant in gebruik) maakt dit architectuurproject extra uitdagend. Een tweede project dat de volle aandacht heeft is de fusie tussen APG en Cordares en de wijze waarop de architectuur hieraan een bijdrage kan leveren. Het opstellen van een nieuwe concern-architectuur (inclusief migratiestrategie) is daarbij een belangrijk project. Daan: Ik neem aan dat het proces van het opstellen van een architectuur bij APG niet altijd goed is verlopen. Kan je iets zeggen over de consequenties van een verkeerde architectuur? Henk: Het proces van opstellen verloopt op zich vaak nog wel goed, maar onder druk van de tijd of van beperkte middelen wordt er in een project nog wel eens gekozen voor iets te pragmatische oplossingen. Dit betekent dat de oplossing of niet helemaal voldoet aan wat ervan verwacht wordt (vaak nog wel een bewuste keuze) of dat er (veel) later meerwerk moet worden verricht. Dat komt dan als een verrassing. Een voorbeeld is het integreren van delen van betaalfunctionaliteit in het systeem voor de polisadministratie. Die functionaliteit moet er nu weer uit worden gemigreerd hetgeen extra kosten met zich meebrengt. Daan: Wat was de rol van architectuur bij de fusie tussen APG en Cordares? Is jullie architectuur nu adaptief genoeg om makkelijk volgende fusies te kunnen doen, althans wat de IT betreft? Henk: De fusie tussen APG en Cordares geeft veel te beantwoorden architectuurvragen, om te beginnen op het niveau van de stadsplanning. Daar zijn we volop mee bezig. Of we adaptief genoeg zijn voor nieuwe fusies is nooit te beantwoorden. Als het zich voordoet zullen we zeker de goede oplossingen vinden. Daan: Hoe hebben jullie adaptiviteit gerealiseerd? Henk: We zijn er nog mee bezig. Een van de belangrijke architectuuraspecten is om opdrachtgevers-generieke en -specifieke delen goed van elkaar te onderscheiden. Augustus

5 Daan: Het programma Complexiteitsreductie 2 bij de Belastingdienst schijnt te zijn gebaseerd op ideeën die bij APG zijn geformuleerd. Wat was de impact van die ideeën en zijn die bij jullie nog verder geëvolueerd? Henk: Ik weet niet welke ideeën andere partijen van ons overnemen. Enerzijds kan het gaan over onze aanpak om te denken in processen, het afhandelen van klant-events en het gebruik van generieke productconcepten. Dat is in ons bedrijf ver doorgevoerd in systemen, in communicatie en zelfs tot in de organisatiestructuur. Deze concepten hebben al een geruime leeftijd, maar zijn nog vrijwel ongewijzigd. Daarnaast hebben wij een paar jaar geleden een programma voor ICT complexiteitsreductie doorgevoerd. Dat was vooral bedoeld om de diversiteit in de infrastructuur te reduceren (het aantal ontwikkelomgevingen, (type) servers en storage oplossingen). De basis van die ideeën is niet geëvolueerd. Hoe minder variatie, des te eenvoudiger en als gevolg daarvan betrouwbaarder en vervolgens goedkoper. Van alle voorstellen lagen sluitende businesscases. Wat we echter geleerd hebben is dat niet elke vereenvoudiging ook een kostenreductie teweegbrengt. De migratiekosten bleken soms hoger dan de mogelijke besparing. Wat we dus nu nog meer zouden doen dan voorheen is een sluitende businesscase maken die rekening houdt met tegenvallers. Daan: Wat is de rol van architectuur bij het aanpassen van de bedrijfsstrategie en organisatie als gevolg van ontwikkelingen in de markt en mogelijke veranderingen in wet- en regelgeving? Henk: De architectuur bepaalt uiteraard niet de business-strategie, noch heeft zij invloed om verandering in wet- en regelgeving. Wel worden vanuit architectuur verhelderende vragen gesteld over bijvoorbeeld de strategie, hetgeen helpt bij een verbetering daarvan. Daan: Ik begrijp dat de businessstrategie niet primair wordt bepaald door de architectuur, maar de vernieuwde businessstrategie moet wel mogelijk zijn binnen de aanwezige architectuur. Dus ik zeg altijd dat er tussen strategie en architectuur een verhouding is als tussen willen (waar willen we met de onderneming naartoe) en kunnen (kunnen we dat realiseren met de huidige architectuur of moet die worden aangepast). Als de architectuur moet worden aangepast krijgen we een transformatietraject waarin stapsgewijze de strategie en de architectuur naar een nieuwe toestand worden gemigreerd. Wet en regelgeving krijg je cadeau van de overheid, maar je moet wel zorgen dat je architectuur zo adaptief is dat je daar snel aan kan gaan voldoen, lijkt mij. Daan: Volgende vraag: speelt architectuur een rol bij de besluitvorming in de Raad van Bestuur? Henk: Ja, belangrijke architectuurbeslissingen, zeker als ze veel impact hebben in bijvoorbeeld kosten of strategische (on)mogelijkheden, worden door een lid van de RvB of zelfs door de hele RvB behandeld. Zij worden vaak door de architectuurclub aangedragen. Daan: Hoe vindt besluitvorming ten aanzien van architectuur plaats, wie is accountable voor de architectuur? En wie is de eigenaar van een architectuur? Henk: Dit is mede afhankelijk van het type architectuur. Besluitvorming vindt getrapt plaats en is afhankelijk van het belang en de impact van een voorstel. Soms besluit de lead architect, soms een informatiemanager of de businessdirectie. Bij belangrijke en/of overstijgende thema s kan de IT architectureboard besluiten (voorzitter is de CIO) of de governanceboard (voorzitter is lid RvB). De concernarchitectuur en het concern informatieplan, waarin de belangrijkste architectuurbeslissingen zijn opgenomen, is eigendom van de CIO. Daan: Wat zijn de kernpunten van de architectuurgovernance bij jullie? Henk: Er is één concernbrede architectuur en één concern informatieplan. Wij werken met lead architecten per businessunit die hiërarchisch centraal worden aangestuurd. We hebben architectuurplatforms voor grotere projecten en een getrapte besluitvorming. Uiteindelijk beslist het businessmanagement (niet IT). Augustus

6 Daan: Wat zijn volgens jou de karaktereigenschappen en competenties van een goede architect? Henk: Dat hebben wij expliciet gevisualiseerd met onderstaande figuur Daan: Hier hebben jullie echt over nagedacht. Wat doen die intervisiegroepen eigenlijk? Henk: Intervisiegroepen zijn vooral gericht op het ontwikkelen van persoonlijke vaardigheden. Door het in de groep brengen van iets dat je bezighoudt. Door het daarover bevraagd worden door je collega s leer je anders te kijken dan je gewend was te doen. Het is daarbij overigens niet de bedoeling dat je collega s oplossingen aandragen, maar dat ze je uitdagen om te kijken hoe je zelf met vraagstukken omgaat. Het gaat ook niet om inhoudelijke architectuurvraagstukken, maar bijvoorbeeld over de moeite die je hebt om zaken geïmplementeerd kunt krijgen. Daan: Wat is de werkrelatie tussen jou als manager concern informatiemanagement en de CIO? Henk: Momenteel is de CIO en de directeur ICT dezelfde persoon. In beide rollen wordt sterk geleund op de kennis en vaardigheden van de architectuurclub. Ik rapporteer aan beide rollen. Op zeer korte termijn worden deze rollen uit elkaar getrokken en heeft de CIO eigen architecten. Ik zal persoonlijk weer een andere rol hebben in het management van het IT bedrijf. Daan: Welke werkrelatie is er tussen de chief architect enerzijds en de innovator en technologen anderzijds? Henk: Zij werken onder verantwoordelijkheid van mij (als je mij als chief architect wil zien) en er bestaat dan ook een intensief overleg met deze functionarissen. Augustus

7 Daan: Impliceert dat dat de innovator/technoloog niet zelfstandig met zijn/haar ideeën naar buiten komt, maar dat dat geschiedt via de architect. Waarbij de architect de realiseerbaarheid van de innovatie in beschouwing neemt? Henk: Beetje vreemde vraag. Bij ons zijn de innovator/technologen vaak ook de architecten. Wij hebben geen separate functie van innovator. Architecten die voorstellen voor vernieuwing doen moeten daarbij ook de realiseerbaarheid in ogenschouw nemen. Daarbij moeten ze veel aspecten in ogenschouw nemen, niet in de laatste plaats de ermee gepaard gaande kosten en risico s van mislukking. Daarna gaan we proberen een draagvlak te creëren via de IT-governanceboard waarin directies van de bedrijven zitting hebben. Overigens staat het iedereen in ons bedrijf vrij om innovatieve ideeën te hebben. En als die over ICT gaan, stroomlijnen we die via de genoemde gremia. Daan: Maken jullie een expliciet onderscheid tussen businessarchitecten en IT-architecten? En hoe werken die samen? Henk: Ja. Zij komen elkaar meestal tegen in projecten en werken dan intensief in dat verband samen. Overigens geldt dat zij wel van elkaars domein op de hoogte moeten zijn en dus over muren heen moeten kunnen kijken. Daan: Hoe belangrijk is een goede architect? En waaruit blijkt dat Henk: Een goede architect is erg belangrijk om afspraken en ontwerpen te maken, de realisatie te begeleiden en te bewaken. Dat blijkt ook wel uit de beloning. Architecten zijn de best betaalde inhoudelijke ICT medewerkers die wij hebben. Daan: Horen de toparchitecten op jullie eigen loonlijst of huur je die liever in? Henk: Een toparchitect kan dat alleen zijn als hij/zij ook de business goed begrijpt. Dat impliceert dat we ze zelf in dienst willen hebben. Voor specifieke (technologisch nieuwe) trajecten huren we goede mensen in, met als doel om kennis over te dragen. Daan: Welke tools gebruikt APG in het architectuurproces? Henk: Buiten Microsoft office weinig formele tools. Wel een repository met daarin vastgelegd de bestaande situatie en een procesmodelleringstool. Daan: Welke eigenschappen/gedragingen bij architecten keur je af en waarom? Henk: In het algemeen vind ik gedrag dat alleen gericht is op het eigen domein of vakgebied en dat niet gericht is op samenwerking om een bepaald bedrijfsdoel te bereiken afkeurenswaardig. Daan: Welke opleidings-/bijscholingsadviezen heb je voor aankomende architecten? Henk: Adviesvaardigheden, het verkennen van de mogelijkheden van nieuwe technologie en het verkrijgen van voldoende businesskennis van jouw domein. vragen/opmerkingen kunnen worden gestuurd via: daan@rijsenbrij.eu. Augustus