De CIO spreekt: Henk Grevelman, CIO Zwitserleven

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, vrijdag 01 mei 2009

De CIO is veelal de directe of indirecte opdrachtgever van de digitale architect. Maar heeft de CIO zelf ook een visie op digitale architectuur? En wat vindt hij of zij van het werk en functioneren van de digitale architecten? In deze serie interviews gaan we op zoek naar de antwoorden.

Henk Grevelman is naast CIO van pensioenverzekeraar Zwitserleven tevens de bedenker van een volwassenheidsmodel voor IT-organisaties. De architect kan wat hem betreft worden meegenomen in het ontwikkelpad, dat in vijf stappen van ‘stabiliteit’ naar ‘uitdagendheid’ moet leiden. Communicatie, inlevingsvermogen en verwachtingenmanagement zijn volgens de CIO de aandachtspunten.

Paul:“Kun je aangeven wat je onder architectuur verstaat?”

Henk: “Het maken van de bouwtekeningen voor ons applicatie- en infrastructuurlandschap en bewaken dat de bouw ook volgens tekening wordt uitgevoerd. Maar ook voor de producten, de gegevens en de bedrijfsprocessen. We werken daarbij volgens een betrekkelijk simpel model. Qua architectuur maak ik aan de ene kant onderscheid in data, applicaties en infrastructuur. En daarnaast onderscheid ik aan de andere kant de producten, processen en in zekere zin ook de organisatie. De domeinen data en applicaties zijn onderverdeeld in een business- en een IT-kant, met een scheiding tussen het ‘wat’ en het ‘hoe’. Voor de model-adepten onder ons: Het ‘wat’ van de data beschouw ik als logisch datamodel, het ‘hoe’ is het technisch datamodel. Dat is in het kort het raamwerk van mijn denken en de manier waarop we daar invulling aan proberen te geven. Een belangrijke taak van de architect is dat hij of zij weet hoe het landschap er uiteindelijk uit moet gaan zien. Daarbij moet proactief de soll-situatie worden bepaald: dus waar zouden we over pakweg drie jaar moeten zijn, inclusief het migratiepad daar naar toe. En dat niet eenmalig vaststellen, maar continu toetsen en eventueel bijstellen.”

Daan:“Je maakt dus een beeld voor over drie jaar en dat doe je volgend jaar weer.”

Henk: “Precies. Ist, soll, plus migratie. We kijken maximaal drie jaar vooruit en minimaal eenmaal per jaar lopen we er doorheen en stellen zaken eventueel bij. Vooral de productarchitectuur is daarbij belangrijk. Deze wordt zwaar onderschat binnen de financiële industrie en met name bij levensverzekeringen en pensioenen. Je móet daar veel aandacht aan besteden, want als je op dit vlak maar wat aanrommelt, creëer je een hoop ellende. Wanneer je namelijk het ene product na het andere in de markt neerzet en niet goed kijkt naar het ontwerp van de producten, dan krijg je bij elk nieuw product aparte processen, applicaties en soms ook nog een aparte infrastructuur. Zo is het althans jaren lang gegaan in onze industrie. Maar ik heb ook bij banken gewerkt en daar kreeg je onder de druk van de time-to-market eveneens duplicaten van een aantal van deze zaken binnen je bedrijf. Uiteindelijk zit de IT-organisatie met de gebakken peren, want die zitten met een onbeheersbaar applicatielandschap dat niet alleen veel te groot, maar ook te duur wordt.”

Digitaal

Daan:“Hoe digitaal zijn jullie producten?”

Henk:“Pensioenproducten zijn zeer complex, aanpassingen worden vooral gedreven door wetgeving (de pensioenwet). Je moet je producten, processen en applicaties continu bijstellen. Van ‘Den Haag’ moest er altijd heel veel verplichte informatie naar polishouders op papier, maar inmiddels is de digitale polis een feit. Dus we hebben nu enorm de kans, en daar kunnen architecten geweldig bij helpen, om onze informatie naar klanten en intermediair eens fors te digitaliseren en te versimpelen. Onze producten worden doorgaans nog steeds geadviseerd via tussenpersonen. Dat resulteert uiteindelijk in een polis of meerdere polissen met een aantal onderlinge verbanden. Dat is een complex verhaal. We verkopen inmiddels ook een aantal eenvoudige producten via onze website. De markt is nog niet echt rijp voor volledig pensioen-STP (straight through processing, red.). Er zijn maar weinig mensen die hun pensioen zonder enig advies via internet kopen.”

Daan:“Komt dat door de mensen of door de pensioenverzekeraars?”

Henk:“Ik zeg altijd dat het bij dat laatste begint En daarmee bedoel ik niet eens zozeer de afzonderlijke verzekeraars, maar de hele industrie. De producten zijn vaak zo complex en moeilijk te begrijpen voor de gemiddelde klant, dat je er wel advies bij nodig hebt. Terwijl ik ervan overtuigd ben, zeker met oog op de ontwikkelingen van de laatste tijd, dat het veel meer digitaal moet kunnen. Een verzekerings- of pensioenproduct hoeft helemaal niet zo ingewikkeld te zijn. Je betaalt een bepaalde premie om een zeker risico af te dekken, onverschillig of het nu arbeidsongeschiktheid, lang leven of overlijden is. Dat kun je iedereen nog wel uitleggen. Of je spaart voor je oude dag door je geld op een spaarrekening zetten of te beleggen. Of je geeft het aan een verzekeraar en op je 65e krijg je pensioenuitkering; gegarandeerd of via beleggingen.”

Daan:“Maar als ik nu zeg: tussen mijn 65e en 75e wil ik méér pensioengeld en daarna minder, want ik zal wat minder reizen als ik ouder word. En mocht ik een ongeluk krijgen en in een invalidenkarretje terecht komen, dan wil ik een academisch geschoolde verpleegster. Kun je voor mij uitrekenen wat dat kost? Zijn jullie zo flexibel?”

Henk:“Nee, zo flexibel zijn we nog niet.”

Daan:“Het is toch allemaal risicoanalyse en daar hang je vervolgens een prijskaartje aan?”

Henk:“Zeker en daarom zeg ik ook dat dit kansen biedt voor deze hele industrie. De knappe koppen waren vroeger de actuarissen. Als die maar voldoende complexe producten bedachten, waren ze in de jaren 80 en 90 de koning. Maar nu gaat het erom eenvoudige producten te maken en zaken in simpele mensentaal uit te leggen. Degene die in de financiële industrie een goede service beidt en qua productaanbod en marketing zaken echt simpel en helder kan maken, die is de spekkoper van de toekomst. Wat dat betreft liggen er, nogmaals, geweldige kansen.”

Componenten

Daan:“Het is de kunst je producten zó slim te definiëren en op te delen in door IT ondersteunde brokstukjes, dat je deze op verschillende manieren kunt herconfigureren Wanneer er dan een marketeer of een slimme verkoper langskomt die er iets anders mee wil, dan kun je wat schuiven en vervolgens doe je er een strik omheen en je hebt een nieuw product.”

Henk:“Dat is qua architectuur mijn ultieme droom: de dingen in brokjes hakken, zodat je in je fabriek diverse bouwsteentjes (productcomponenten) hebt die van de lopende band rollen. Vervolgens doe je er een marketingsaus overheen en dat is de propositie. De ene keer pak je brokje 1, 2 en 3; de andere keer neem je 1, 6 en 7 en een ander foldertje of webpagina. Dat is de uitdaging voor onze industrie.”

Daan:“In veel discussies komt het begrip SOA naar boven en dan hebben we het over Legoblokjes van het applicatielandschap. Maar jij wilt je Legoblokjes op een hoger niveau hebben; het niveau waarop je je businessspel wilt spelen.”

Henk:“Even een kort statement over SOA: ja daar zijn we een paar jaar geleden ook mee begonnen. Een hele uitdaging. De fout die mensen daarbij vaak maken is te stellen dat het gaat over data en over applicaties. Maar SOA gaat over een heel andere manier van werken en denken. Je moet in plaats van applicaties in processen gaan denken, dat is het kenmerk van een succesvolle SOA-implementatie. Als je die proceskant niet meeneemt, dan doe je precies hetzelfde als de middleware van vroeger: het leggen van lijntjes tussen applicaties. SOA daarentegen begint met een cultuurslag; niet allen aan de IT-kant, maar ook aan de business-kant. Een goed voorbeeld van product-decompositie zie je in onze industrie al bij de hypotheken. Vroeger zat bij een spaar- of beleggingshypotheek alles in één. Wat je tegenwoordig veel meer ziet is dat mensen dit allemaal te ingewikkeld vinden en een aflossingsvrije hypotheek nemen. Daarnaast sluit men veelal een losse overlijdensrisicoverzekering af. Dikwijls gebeurt dat tegenwoordig bij verschillende partijen. Klanten snappen hierdoor beter wat ze kopen”

Organisatie

Daan:“Hebben jullie zoiets als een organisatiearchitectuur?”

Henk:“Niet echt. Maar we zijn een klein bedrijf, met maar één locatie, een simpele organisatiestructuur en een eigen Zwitserleven-cultuur. We hebben korte lijnen, veel openheid en veel aandacht voor klant, medewerker en communicatie. We regelen hier veel dingen snel in de lijn of multidisciplinaire groepjes. Dus ook zonder diepgaande architectuurstudies en bouwtekeningen komen wij wel tot een pragmatische en goede invulling van onze organisatie. Ik kan me voorstellen dat wanneer je in een veel groter en meer complex bedrijf werkt, met verschillende businessunits, locaties, shared services centers en matrix-structuren, je daar wel expliciet het nodige aan moet doen.”

Paul:“Ik heb in mijn leven nog niet veel organisatiearchitecturen gezien.”

Daan:“Je zou zelfs een architectuur kunnen opzetten die organisatieonafhankelijk is. Het gaat om het definiëren van services en rollen. Vervolgens kun je voor iedereen de juiste werkplek in elkaar solderen.”

Henk:“Als je zo denkt, dan zou dat in theorie kunnen. Organisatie-architectuur is ook een van de domeinen in het DYA-model (DYnamische Architectuur, red.) van Sogeti, maar wij doen er niets mee.”

Doel en waarde

Henk:“We hebben ons model overigens niet omdat het zo in de boekje staat, maar het moet een doel hebben en waarde voor het bedrijf opleveren. En daarmee komen we automatisch bij het grote probleem van architectuur: het bedenken lukt meestal wel, maar goed erover communiceren is vaak een drama. Ik zeg daarom: vertaal de toegevoegde waarde naar concrete businesstermen. En houd het simpel. Dus geen dik pak papier, maar beschrijf op twee A4’tjes wat het betekent voor de klant en voor de business.”

Paul:“Architecten kunnen hun product niet verkopen aan de business?”

Henk:“Het is een beetje als het oude Philips-syndroom: er worden fantastische producten bedacht, maar het vermarkten is een probleem.”

Paul:“Zijn die dingen, uitgaande van de competenties van de architect, eigenlijk wel te verenigen? Enerzijds moet hij of zij heel veel verstand hebben van complexe technische zaken en sterk analytisch kunnen denken, maar zijn zij wel de aangewezen mensen om dit bovendien te verkopen?”

Henk:“Ja. Maar dan moet je wel naar een nieuw profiel toe. En dan belanden we bij mijn stokpaardje dat betrekking heeft op IT’ers in het algemeen: communicatie, inlevingsvermogen en verwachtingenmanagement zijn de cruciale skills voor de IT’er van nu en morgen, eigenlijk van iedereen die samenwerkt binnen een organisatie. Maar over het algemeen scoren IT’ers nog ver onder de maat, en dat geldt ook voor architecten.”

Daan:“Hoe verklaar je dit?”

Henk (denkt lang na):“Het type mens dat echt IT-architect wilde zijn, was de afgelopen decennia wel een beetje nerdachtig. Die mensen vonden het geweldig om diep in de applicaties, processen en computers te kruipen. Ze waren erg nieuwsgierig en ook erg van de details. Het vakgebied had een grote aantrekkingskracht op dit type. Een tweede probleem is dat de opleidingen tot nu toe erg beroepsgroep-tunnel-gedreven zijn geweest en dingen er niet in een breder kader werden geplaatst. Dus als je trainingen, workshops, seminars en opleidingen volgde, dan werd het oude beeld door de stof bevestigd. Ook de inleiders waren het prototype van de mensen die ze trainden. Dus het schort ook erg aan de opleiding.”

Daan:“Dat is het probleem van universiteiten: stop het in formules en het is goed. Maar het gaat niet om formules maar om formuleren!”

Henk:“Precies. Het is heel basaal: begin gewoon aan de voorkant. Je hebt verschillende klanten en stakeholders en verplaats je in hun probleem of wens Kijk of je ze er vanuit jouw vakgebied mee kunt helpen. Architecten beginnen daarentegen nog al eens aan de andere kant: met een paar boeken of platen van hun voorganger, zaken uit het verleden die je uiteindelijk veelal toch weggooit.”

Eigenwijs

Daan:“We waren laatst bij een collega van je en die vond IT’ers maar eigenwijs. Hij zei: ‘architecten zijn door de IT’ers uitgevonden en daarom zijn ze dubbel eigenwijs’ Bovendien zijn veel architecten via het engineeringspad op hun huidige plek terecht gekomen en hebben ze niet het holistische beeld dat de architecten eigenlijk zouden moeten hebben.”

Henk:“Als ik kijk naar de architecten met wie ik tot nu toe heb gewerkt, dan herken ik twee groepen. De introverte IT-architect. Wat deze groep betreft ga ik mee in wat je zegt. Binnen organisaties weet men vaak niet zo goed wat ze met zo’n clubje aanmoeten. Men snapt wel dat het ergens bij IT thuishoort, maar het was ook altijd een beetje een blok aan het been. Deze architecten werden om die reden altijd een beetje in een hoekje geduwd. En omdat niemand ernaar om keek, bedachten ze veel dingen puur vanaf papier. Daarnaast heb je de extraverte businessarchitect. Deze goed communicerende businessgeoriënteerde architecten zijn schaars. Onze controlling architect komt van oorsprong uit de accountancy. Ik heb hem bewust de baas van het architectuurteam gemaakt. Hij heeft flink wat kennis van het pensioen en financiële domein en trekt daarin de andere mensen mee in de richting van de business.

IT-ers en zeker architecten hebben een grote valkuil: te diep in de materie duiken, number crunching, zich verliezen in de details. Zeker als je ze nog wat mooie speeltjes geeft. Daarom ben ik ook heel beducht voor zware architectuur tooling.

Je kunt overal links tussen leggen, maar als je niet uitkijkt krijg je enorm gedetailleerde schema’s waar niemand meer wat aan heeft en die na een paar maanden al niet meer onderhouden worden.”

Daan:“Dat zijn dus geen echte architecten. Bovendien leiden die tools vaak alleen maar af.”

Henk:“Als mensen vinden dat ze tooling nodig hebben stel ik altijd een paar vragen. De eerste twee vragen zijn: Wie gaat er mee werken en wie gaat het betalen? Als dat niet dezelfde afdelingen of personen zijn, heb je vrijwel altijd een probleem. Er moet echt commitment voor gebruik van de tools zijn, dat toets je het best met de rekening. Mijn volgende vraag is: Wie regelt het beheer van al datgene wat er met de tooling geproduceerd wordt? Als het dan stil wordt, is de conclusie helder: niet aanschaffen.”

Daan:“Architectuurtools kunnen echter wel belangrijk zijn voor de fasen die erna komen. Trouwens mijn lakmoesproef om te bepalen of we te maken hebben met architectuur is te kijken of er ergens in die architectuur formules voorkomen. Als dat zo is, dan is deze niet opgesteld door een architect. Ben jij in de bouwtekening van je huis ooit formules tegengekomen? Dat komt pas later als het gaat om zaken als draagkracht en andere engineeringsaangelegenheden.”

Henk:“Inderdaad, die horen ergens diep in de bijlage. Ik geloof zelf dan ook heilig in het visualiseren. Het A4’tje tekst erbij moet bovendien zelfverklarend zijn voor de doelgroep. En dat heeft alles te maken met communicatie en inleving: voor wie maak ik nu wat? Verschillende doelgroepen willen verschillende plaatjes zien, weer een andere groep heeft misschien liever wat tekst. Maar zorg er in elk geval voor dat het appelleert aan hun wereld. De gemiddelde IT’er heeft daar al moeite mee en dus ook de gemiddelde architect. Die denkt te vaak maar in één wereld en dat zijn de plaatjes die uit die tool komen.”

Competenties

Paul:“Wat zijn de vaktechnisch relevante competenties van de architect?”

Henk:“De sociale skills heb ik al genoemd. Vakinhoudelijk zou ik zeggen: de competentie om moeilijke dingen uit te leggen in gewone mensentaal. De meeste architecten zijn in staat om zich complexe zaken zeer snel eigen te maken, maar vervolgens komt het neer op de vertaling ervan naar begrijpelijke oplossingen.”

Daan:“Je noemt twee competenties achter elkaar: een hoog abstractievermogen en dit kunnen verwoorden voor degene voor wie het bedoeld is. Je hoeft dus niet al je kennis over die businessmanager uit te storten.”

Henk:“Ja, maar dat is zoeken naar een naald in een hooiberg. Want je zoekt intelligente en nieuwsgierige mensen die snel en abstract kunnen denken, verbindingen tussen klanten, producten, processen en applicaties kunnen leggen. Per saldo zijn zulke bètatypes aan de alfakant minder ontwikkeld. Mijn pleidooi is: de pure bèta’s daar moeten we vanaf. Liever wat meer alfa’s met enige bèta-affiniteit.”

Paul:“Maar wat nu als het door alfa’s geschetste plaatje vaktechnisch gewoon niet klopt, omdat het op drijfzand gebaseerd is?”

Henk: “Ik vind werken onder architectuur en een concrete architectuur-roadmap heel belangrijk. Maar het plaatje zal nooit 100 procent kloppen. Geheid dat er altijd wel een linkje of een interface vergeten wordt. De gewenste situatie over drie jaar is over een jaar bovendien alweer anders. De soll is nooit volledig. Verandering is tenslotte de enige constante. Goed is goed genoeg.”

Paul:“Toch vraag ik me af of je soms toch niet een architect nodig hebt die geheel overziet en in staat is om de juiste beslissingen te nemen. Bij Essent hebben ze bijvoorbeeld bedrijfsdomeinen gedefinieerd, waardoor bepaalde onderdelen desgewenst los te koppelen zijn. Andere energiebedrijven hebben dat niet gedaan en missen nu die flexibiliteit.”

Henk:“Ik vind dat een hele goede en wil dat hier ook gaan doen. Wat je namelijk nog vaak ziet bij veel functioneel ingerichte bedrijven is dat ze binnen een wirwar aan processen en IT- landschappen te veel in silo’s denken en werken. En vanuit die silo’s wordt er vervolgens van alles gevraagd aan de IT, die op zijn beurt het overzicht niet heeft. Gemeenschappelijke functionaliteit wordt dan dubbel geïmplementeerd. Voor enkele generieke zaken onderkennen we sinds kort aparte domeinen, bijvoorbeeld NAW, rekenkernen. We verdelen de domeinen onder de architecten, die gerichte opdrachten meekrijgen, bijvoorbeeld een roadmap maken om het NAW-domein op te schonen.”

Maturiteit

Daan:“Nu weet ik dat jij een organisatiematuriteitsmodel hebt ontwikkeld, waarin je vijf fasen van volwassenheid onderscheidt: van stabiel tot uitdagend (Grevelman onderscheidt verder nog betrouwbaar, professioneel en proactief, red.). Kun je in het verlengde daarvan ook zeggen dat er verschillende stadia zijn voor de volwassenheid van de architectuur?”

Henk:“De organisatie krijgt de architectuur die ze verdient. En andersom. Toen ik hier acht jaar geleden binnenkwam, lagen soms wel driemaal per dag de systemen eruit. Hoewel ik een goed beeld van de ideale IT-organisatie had, heb ik er toen toch voor gekozen om de eerste drie jaar niet eens een architectuurafdeling neer te zetten. De basis-infrastructuur moest eerst goed functioneren. Dus even geredeneerd vanuit mijn maturitymodel: zet in fase nul architecten - als je ze dan al hebt - in hemelsnaam niet in om mooie plannen te schrijven, maar om te helpen om de dagelijkse operatie stabiel te krijgen. Daarmee doen ze kennis van de omgeving en dagelijkse praktijk en problemen op. In de volgende fase werken architecten actief mee aan nieuwe releases en projecten, zodat mensen hun toegevoegde waarde binnen een project zien. Op het moment dat ze meer zichtbaarheid en draagvlak krijgen, zullen ze vanzelf gevraagd worden om eens een keer strategisch mee te denken. Architecten die goed in klant- en businesstermen kunnen communiceren, zullen goed aansluiten bij de business en samen met hen kunnen werken aan de producten, processen en applicaties van de toekomst. In de laatste fase zullen de architecten de business zelfs keihard over de knie nemen. Dan zeggen ze bijvoorbeeld: ‘Leuk dat je dat wilt, maar wat levert het op? Levert dit alternatief niet meer op?’. De architecten vervullen in dat laatste stadium een soort countervailing power-rol. Ik vind trouwens dat iedereen zo moet denken. Bij Zwitserleven noemen we dat ook wel ‘Doe alsof het je eigen geld is’.”

Daan:“In die zin zou je tevens een maturity-model kunnen ontwikkelen voor de skills van de architect.”

Henk:“Dat ligt inderdaad in het verlengde van mijn model.”

Daan:“Hoe ver zijn de architecten van jou?”

Henk:“Al een heel eind, maar op het gebied van communicatie, verwachtingen-management en het denken vanuit de eindklant kunnen nog stappen gezet worden. Dit is ook logisch, want onze architectuurafdeling is nog relatief jong en is het afgelopen jaar bedolven onder werk met betrekking tot pensioenwet en de overname door SNS Reaal. Hierdoor is de aandacht voor eigen ontwikkeling en PR wat in de knel gekomen.”

Daan:“Welke rol kunnen de universiteiten op dit gebied spelen?”

Henk:“Multidisciplinair denken en communicatieskills een belangrijk onderdeel maken van de studie. Ik ben nog dagelijks blij met het bij Volmac geleerde, oude vertrouwde COPAFIT-breed denken. Schenk daarnaast veel aandacht aan communicatie en sociale vaardigheden. Maak architecten in de opleiding bewust van hun stakeholders en interne klanten, en de verwachtingen die zij van de architect hebben. Laat ze de oplossingen vervolgens vertalen naar concrete begrijpbare deliverables, liefst met behulp van een eenvoudig plaatje. Ik pleit er ook voor dat de IT- en consultancybureaus dit soort competenties meer in hun opleidingstrajecten gaan meenemen.”

Principes

Paul:“Maak je gebruik van architectuurprincipes?”

Henk: “We hanteren er hier een paar hele simpele: re-use before buy before makeenzovoorts. Met de business hebben we best lang over architectuurprincipes en -spelregels gediscussieerd. Het is ons eerlijk gezegd niet goed gelukt om die breed te laten beklijven. Dat komt weer vooral neer op communicatie; maand in maand uit dezelfde boodschap herhalen.”

Daan:“Hebben jullie dan misschien strategische uitgangspunten?”

Henk:“Ja, die hebben we verankerd in een strategische kaart. Mijn ervaring is echter dat, wanneer je het hebt over strategische uitgangspunten, spelregels, principes of wat dan ook, het zaken moeten zijn die iedereen snapt en dan door een brede doelgroep automatisch worden toegepast. Dan loop je al aan tegen het eerste probleem: zo’n principe wordt dan al snel een democratisch vastgestelde definitie. Hij wordt zo generiek opgeschreven dat niemand er tegen kan zijn. Men denkt het ook wel te snappen, maar vervolgens gaan mensen uiteen en leggen hem binnen hun eigen domein of achterban weer net even anders uit. Het wordt dus allemaal zo generiek dat het niet gaat werken. Ik ben meer iemand van de praktijk en van de feiten. Als ergens een getal staat en we zetten er een euroteken voor, dan weten we allemaal wat we ermee bedoelen. Dat kan niet door verschillende mensen uit verschillende disciplines en met andere competenties anders uitgelegd worden.”

Raad van Bestuur

Paul:“Wat vindt de Raad van Bestuur dat jij moet realiseren?”

Henk:“Ik zit als CIO zelf in de directie. We werken met een driejaarsplan met daarin KPI’s over omzet, kosten, winst, klant- en medewerkerstevredenheid. Dat zijn harde targets die je moet realiseren. Daarnaast hebben we multi-disciplinaire marktteams gevormd, waarin naast mensen van Sales, Marketing, Customer Services ook een controller zit en iemand vanuit IT. Deze managers vanuit de laag onder de directie maken vanuit de genoemde bedrijfsdoelen marktplannen voor de GrootZakelijke markt, de MKB- en de particuliere markt. Daar worden eveneens keiharde kpi’s in opgenomen, op basis waarvan bijvoorbeeld nieuwe producten worden bedacht en in de markt gezet. De marktteams geven aan wat ze nodig hebben van welke divisie om die producten te realiseren. Op basis daarvan maken de divisies en afdelingen hun eigen jaarplan. Zo formuleert iedereen vanuit de eigen afdelingsdoelen indirect de eigen bijdrage aan het bedrijf. Daarnaast heb ik natuurlijk mijn eigen persoonlijke doelen; de zaken die er binnen de directie voor het komende jaar van mijzelf verwacht worden. Voor dit jaar zijn dat vooral zaken die te maken hebben met het halen van IT-synergievoordelen als gevolg van de overname van Zwitserleven door SNS Reaal.”

Paul:“Architectuur betekent ook dat je in de toekomst kijkt en dat je weet waar je over een aantal jaar wilt staan. Als je daarentegen vastzit in een applicatielandschap dat niet aansluit bij het bedrijfsproces en de dynamiek van de markt niet aankan, dan verwacht ik dat de RvB eist dat je over drie jaar wél aangepast bent.”

Henk: “Dan zou mijn antwoord zijn dat ik daar zeker ideeën over heb, maar dat het allemaal toch begint bij de business. Anders krijg je dat de IT fantastische migratieplaten gaat maken, maar dat de business niet meedoet. Dat is een veel gemaakte fout. Ik wil daarentegen samen met de business vaststellen waar we in de toekomst onze centen mee verdienen en welke producten, processen en cost loadingdaarbij horen. Misschien blijkt daarbij wel dat we heel andere keuzes moeten maken dan in het verleden.”

Paul:“Hoe is de governance rondom architectuur geregeld?”

Henk: “We hebben een Architecture Committee waarbinnen we de kaders en richtlijnen vaststellen. Tevens staat daar (de ist, de sollen migratiepad op de agenda, alsmede de afwijkende architecturele beslissingen binnen het bedrijf als geheel of binnen de projecten. Het Architecture Committee wordt voorgezeten door de manager Architectuur, die aan mij rapporteert. Verder zitten de directeur Customer Services en de manager Informatiemanagement erin vanuit de businesskant, de manager Applicatieontwikkeling en -beheer en ikzelf. Afhankelijk van het onderwerp schuiven er bovendien architecten, business- en IT-mensen aan, als er zaken of projecten besproken worden die betrekking hebben op hun domein.”

Overname

Paul:“Je hebt een overname door SNS Reaal achter de rug. Heeft architectuur daarbij kunnen helpen?”

Henk:“Ja. De overname was gebaseerd op win-win. Reaal en Zwitserleven zijn beide sterk in de leven- en pensioenmarkt. Er werd al snel besloten om beide labels naast elkaar te laten bestaan. Vervolgens werd besloten om de administratie van pensioenen bij Zwitserleven onder te brengen en de administratie van leven bij Reaal. Backoffices moeten dus multi-label worden gemaakt en portefeuilles geconverteerd. Daarmee raak je keihard de processen, de applicaties en kom je bij de vraag waar je welke gegevens vandaan haalt. In zeer korte tijd moesten plannen voor samenwerking en synergie worden gemaakt die de businesscase van de overname moesten invullen.”

“De architecten van Reaal en Zwitserleven hebben fantastisch werk geleverd. Zij waren de mensen met overzicht en waren in staat ontzettend snel verbanden te leggen. Het was ook prachtig om te zien hoe goed de samenwerking tussen de architecten van beide organisaties verliep; ze hadden elkaar snel gevonden. Een aantal andere disciplines kon hier een voorbeeld aan nemen.”

[PDF]

Opmerking

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

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

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