De CIO spreekt: Ton van der Linden, CIO Nationale-Nederlanden

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, donderdag 25 juni 2009

Van product- naar informatiegericht’

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.

Op dit moment herbergt de Verzekeringsmaatschappij Nationale-Nederlanden diverse Lines of Business (LoB’s), die van oudsher zeer product-georiënteerd zijn en met ieder zijn eigen specifieke IT. Momenteel vindt binnen het bedrijf een beweging plaats, waarbij de businessdomeinen binnen en tussen de LoB’s beter worden ingepast binnen de totale informatiestroom. Architectuur speelt bij deze slag, die volgens CIO Ton van der Linden bij heel veel financiële instellingen gemaakt wordt, een belangrijke rol.

Paul:“Kun je beschrijven of definiëren wat digitale architectuur betekent voor Nationale-Nederlanden?”

Ton:“We hebben twee niveaus van architectuur: enterprise-architectuur en businessdomein-architecturen. In feite hebben wij binnen de totale onderneming een platgeslagen businessdomeinenmodel (BDM), waarbij we product-marktcombinaties afzetten tegen wat wij intern generieke functionaliteit noemen: bijvoorbeeld incasso- en klantsystemen. Zaken die belangrijk zijn om je processing te doen, maar waarmee je je uiteindelijk niet onderscheidt. Op de punten waarop je product-onderscheidend wilt zijn, kunnen we er daarentegen voor kiezen om allerlei variaties te hebben.”

Daan:“Met het businessdomeinenmodel bedoel je dat je de business hebt opgedeeld in een aantal domeinen en de architectuur op het betreffende domeinniveau bekijkt?”

Ton:“Ja. Zo is de wereld hier verdeeld. En hier zetten wij alles wat wij doen tegen af. Hiermee onderscheiden we specifieke en generieke businessdomeinen. Het BDM model hebben we gevisualiseerd en wordt gebruikt als referentiemodel.”

Daan:“Mooi, ik houd van visualisaties.”

Ton:“Als het gaat om zaken als finance, HR, incasso, printstraten, noem maar op, zorg je dat iedereen van hetzelfde principe gebruik kan maken. Daar waar het echte product-marktcombinaties betreft, daar moet het product voorop staan. En dat onderscheid proberen we te maken. Met architectuur als ordeningsprincipe en change management sturen we hier binnen onze organisatie hard op.”

Daan:“Mag ik een heel gekke vraag stellen? Is jullie architectuur NORA-compliant? We hebben namelijk de Nederlandse Overheid Referentie Architectuur en ik hoop daarvan altijd dat deze niet alleen omarmd wordt door de overheid, maar ook wordt gebruikt voor het informatieverkeer tussen burger en burger, en burger en bedrijf. Dus op dezelfde manier als je als burger met de Belastingdienst communiceert, zou je dat misschien ook wel met een verzekeringsmaatschappij of een bank willen doen. Dus ik zou me kunnen voorstellen dat de NORA, en de opvolgers daarvan, als het gaat om kanaalbehandeling, output en input als richtlijn wordt gebruikt.”

Paul: “Ken je de NORA?”

Ton: “NN legt nu met de overheid een koppeling met klantgegevens. Als het gaat om de opvolger van het Sofi-nummer zou het helpen als iedereen van hetzelfde nummer gebruik maakt. De link met de overheid komt dan niet in het distributiekanaal binnen, maar in het klantdomein, en daar komen de identificerende gegevens samen. Dat wil overigens niet zeggen dat een individuele klant bij Nationale-Nederlanden met een levensverzekering en een pensioen een integraal antwoord kan krijgen op de vraag of beiden genoeg zijn om die beroemde 70 procent af te dekken. Dat kan namelijk vooralsnog niet. De wetgever eist Chinese Muren tussen verschillende producten en stelt dat er intern geen gegevens uitgewisseld mogen worden. Het zou waanzinnig veel helpen wanneer de informatiesystemen dezelfde informatie zouden gebruiken. Want of je nu bij de Belastingdienst naar binnen gaat, of bij Fortis, Rabo, ING een polis sluit, het zou in principe hetzelfde overzicht moeten geven. Maar dat is nog lichtjaren weg.”

Daan:“De overheid zou eigenlijk twee taken moeten hebben, als het gaat om zaken als de NORA: ten eerste met oog op de informatievoorziening van de overheid zelf, maar bovendien faciliterend voor het totale informatieverkeer in Nederland. Dus vandaar mijn vraag. We denken er dus hetzelfde over, maar zo werkt het in de praktijk nog niet.”

Ton:“Precies.”

Kanteling

Ton: “Het specifieke van onze LoB’s is dat dit per definitie product-georiënteerde bedrijven zijn. De grote kanteling komt wanneer je vervolgens, m.b.v. ons BDM, naar de totale informatiestroom kijkt. Dat is de grote slag die je de komende tijd in de financiële industrie gaat zien. Hetzelfde hebben we al gezien bij de elektriciteitsbedrijven. Hun grote slag was om de bediening van de klant, in combinatie met het proces te optimaliseren. En daar hangen dan toevallig producten aan. En welke producten dat zijn wordt hier straks de hele wedstrijd.”

Daan: “We hebben onlangs een collega van jou gesproken, weliswaar van een veel kleiner bedrijf. Daar kwam ‘productarchitectuur’ dé crux van verzekeringen en pensioenen uitvoerig langs. Hebben jullie een productarchitectuur die helemaal is doorvertaald naar de informatie?”

Ton: “Alles is actuarieel bepaald, of het nu gaat om Schade, Leven of Inkomen. Dat is de essentie. De rekenboxen zijn het meest cruciale onderdeel van het verhaal.”

Daan: “Logisch, dat is verzekeringswiskunde en dat doen we al sinds de gouden eeuw op ongeveer dezelfde manier.”

Ton: “Maar er is één nieuw probleem. Die uitgangspositie uit de gouden eeuw bied je nu aan op internet. In alle verschillende vormen die daarbij horen. Dat is de grote discussie; op het moment dat de informatieverwerking via internet bij de klant plaatsvindt publiceer je in feite die engine/rekenbox en bereken je dáár de offerte. De uitdaging is hoe je alles borgt, beveiligd en in sync. houdt.”

Paul: “Je hebt binnen de businessdomeinen verschillende productarchitecturen, je hebt een bedrijfsarchitectuur. Heb je ook nog andere soorten architecturen?”

Ton: “Binnen de bedrijfsarchitectuur kun je er wel een paar verzinnen. De eerste is het facilitaire stuk: de ontwikkeling van een werkplek, waarbij mensen onafhankelijk van de locatie toegang hebben tot de volledig gedigitaliseerde dossiers. De tweede is de daarbij behorende infrastructuur als het gaat om telecommunicatie, datacenters enzovoorts. En dan heb je nog de connectiviteit tussen applicaties en die met de infrastructuur. Je kunt de processen op een tweetal niveaus indelen: waar beleg je een functie en wat is de meest logische manier om een klant door het proces en de keten te laten lopen? Het is hier zo georganiseerd dat het facilitair bedrijf, het datacenter, het systeemlandschap en de processen op functioneel niveau in toenemende mate bij ons liggen. Met dat laatste bedoel ik de vraag op welk niveau je een bepaalde functie neerlegt. Architecturen helpen bij het bepalen van het antwoord.”

Klantperspectief

Ton:“Maar bekeken vanuit het klantperspectief, dus de manier waarop de klant door het proces heen gaat en hoe hij of zij dat proces ervaart, dat ligt bij productmanagement en bij marketing. Dat kan en mag niet bij de CIO liggen. Daar weten we namelijk nooit genoeg van. Je creëert bovendien een schijnzekerheid; dat je zaken met alleen een digitale architectuur kunt oplossen. Dat kun je namelijk niet. Juist omdat je digitaliseert zal de interactie met de klant en de manier waarop je daar vorm aan geeft, in toenemende mate aan belang winnen. De verantwoordelijkheid ligt evenwel bij degene die het product definieert, ontwikkelt en daarmee de interactie met de klant ontwerpt en bepaald.”

Paul:“Betekent dat je daar ook architectuurdenken wilt hebben? Om als gesprekspartner te kunnen optreden?”

Ton: “Tja, wat is architectuurdenken? Als je vindt dat productmanagement het definiëren is van de productcomponenten en deze in samenhang bewaken, dan is het een vorm van architectuur. En als je vindt dat die componenten actuarieel geborgd moeten zijn, dan is dat ook zo.”

Paul: “Maar het wordt bij productmanagement niet zo beleefd?”

Ton: “Of productmanagement het nu architectuur noemt of niet, zolang ze er maar zo over nadenken en dat doen ze gelukkig.”

Paul: “Ik kan me voorstellen dat men bij productmanagement nog klassiek denken aanhangt en dus het hele product, zowel aan de voor- als aan de achterkant helemaal zelf wil ontwikkelen en neerzetten in de markt. Dus dat ze zich niet willen concentreren op alleen dat stukje productarchitectuur en alles eromheen regelen met de architectuur-afspraken zoals die intern gemaakt zijn.”

Ton:“Die hele transitie is niet makkelijk. We zitten er middenin, werken met architectuur principes en vertalen dit in productcomponenten. En ja, dan kom je de dingen tegen die jij nu noemt. Producten worden gelukkig steeds meer architectuurgedreven ontwikkeld, maar we zijn er nog niet. Om succesvol te zijn is architectuur denkkracht bij deze collega’s en ook bij IT-collega’s noodzakelijk. Het oude product denken moet omgezet worden in het denken in informatiestromen en de IT-collega’s moeten de productontwikkelaar daarbij helpen.”

Belangrijk

Daan: “Hoe belangrijk is architectuur binnen Nationale-Nederlanden?”

Ton: “Heel belangrijk en daar gedragen we ons ook naar. Ten eerste hebben we een redelijk grote groep medewerkers, veertig tot vijftig mensen groot die zich bezighouden met architectuur en architectuur gerelateerde issues, die het hele plaatje leiden. Daarbij speelt wel dat het een inhaalslag is, waarbij deze mensen in plaats van in de centrale stafafdeling in toenemende mate bij de decentrale LoB gerelateerde units werken. Zodat ze een leidende rol krijgen in de veranderteams.”

Daan: “Dus je hebt architecten centraal zitten en je wilt dat ze meer de businessunits in gaan om aldaar meer gedetailleerde architecturen te maken?”

Ton: “In toenemende mate zou je dat willen. Het organogram is als volgt: ik heb vier veranderteams en er is een CIO-office met daarin planning & control, de architecten, de centrale projectmanagers, de convenanten en contracten. Verder hebben we een afdeling die de productieomgeving beheert en een afdeling die de contacten met het infrabedrijf legt. Binnen het echte technologiebedrijf hebben we verschillende smaken: Pensioen, zowel MKB als corporate; Schade en Inkomen; Leven Particulieren en Hypotheken (Bancair); en een generiek deel waarbinnen men zich bezig houdt met de centrale generieke componenten. In de productieomgeving zie je precies hetzelfde. Dus de value chain zie je terug in de IT. Daarbij breng je datgene centraal wat centraal hoort en probeer je per component te decentraliseren. Maar daarbinnen gaat men niet z’n eigen architectuurtje zitten maken, het moet passen onder de grote centrale paraplu.”

Governance

Paul: “Hoe zit de governance ten aanzien van de architectuur in elkaar? Wie adviseert, wie zoekt uit en wie beslist?”

Ton:“Het management team BPI (BedrijfsProcessen & Informatisering) en de vertegenwoordiger binnen dit team die de baas is van Strategie & Innovatie (S&I), daar valt de groep architecten onder. Zijn mensen doen de onderzoeken en komen vervolgens met voorstellen.”

Daan: “Zijn jullie verder dan je concurrenten. Of houd je je daar niet mee bezig?”

Ton: “Vorig jaar is er een groot Gartneronderzoek geweest. Zij hebben een benchmark gedaan bij een aantal verzekeringsmaatschappijen en andere bedrijven. Ook hier hebben ze rondgelopen. Als je dat rapport leest, waarbij in kaart is gebracht hoe je de portfolio en de governance hebt geregeld, dat zitten wij op een schaal van één tot vijf op drie-plus in het Gartner’s Value Management Maturity Model. We doen het dus goed, maar dat is relatief. Want als je dan in de directiekamer komt, dan is men er natuurlijk heel blij mee, maar je krijgt gelijk de vraag: ‘waarom hebben we dan nog problemen’. De essentie van niveau drie blijkt dan te zijn dat alle units op het kantelpunt zijn aangekomen waarbij de nadruk steeds meer komt te liggen op samenwerken. Oftewel: over de eigen grenzen heen kijken en bewust zijn van het effect van de eigen keuzes en handelen op de keten.”

Daan: “Ik heb altijd een paar vragen bij dat soort zaken. Je hebt een drie-plus maar waarom geen vijf? Wat is nog het verschil? Zit die drie ‘m in de mentaliteit, zit het in producten of misschien nog iets anders?”

Ton: “Als we van één naar twee gaan, dan betekent dat dat we binnen BPI hebben besloten om het allemaal op dezelfde manier te doen. In één doen we het op verschillende manieren en in twee op dezelfde manier. Als je naar drie gaat, dan besef je dat je iets gemeen hebt met een ander groep: bijvoorbeeld op projectniveau tussen de business en IT. Niveau vier betekent dat je het allemaal binnen grote programma’s en door de hele keten heen ook daadwerkelijk op dezelfde manier doet. Je wordt je hierbij steeds bewuster van het feit dat je binnen een organisatie heel veel eilandjes hebt. Bij elk niveau dat je stijgt, vermindert het aantal eilandjes. En wat Gartner dan zegt in variatie op CMMI: de organisatie is zich ervan bewust geworden dat ze in samenhang moet worden bestuurd. Het besef dat we portfoliomanagement moeten hebben over de gehele divisie is de slag waar we nu middenin zitten. Om zover te komen moet je eerst op alle afzonderlijke componenten redelijk professioneel zijn. Maar om terug te komen op de vraag: het is voor mij verschrikkelijk moeilijk om te zeggen of andere organisaties dat beter of slechter doen dan wij. Er is maar één oplossing voor en dat is dat je je op al die facetten eenmaal per jaar laat benchmarken. En dat doen we dus. De startpositie, bijvoorbeeld CMMI level één of vier, is daarbij voor mij niet zo belangrijk. Het gaat er vooral om hoeveel tijd je nodig hebt om op het gewenste niveau te komen en de snelheid waarmee je je kunt bewegen.”

Daan: “Adaptiviteit gaat misschien wel meer over mensen dan over systemen. In de snelheid waarmee je systemen of veranderingen kunt implementeren schuilt de grote waarde.”

Ton: “Absoluut.”

Professionalisering

Daan: “Als ik je goed begrijp zit de BPI organisatie midden in een transitie om verder te professionaliseren. Kun je daar iets meer over vertellen?”

Ton: “We hebben het nu specifiek over architectuur, maar alleen hiermee gaat Nationale Nederlanden en BPI niet de slag naar de toekomst maken. Architectuur kan alleen slagen als deze goed aansluit op het ontwikkelproces waarbij het een voorwaarde is dat het ontwikkelproces professioneel uitgevoerd wordt. Met het thema Innovatie met de focus om mensen, processen en technologie worden de medewerkers gestimuleerd om continue zelf verbeteringen aan te brengen.”

Paul: “Waar moet ik dan concreet aan denken?”

Ton: Allereerst moeten we onze ontwikkelprocessen op orde hebben. Duidelijk moet zijn op welke momenten expliciet architectuuronderwerpen en structuurkeuzes beslecht moeten worden. Het helpt enorm als je aan het begin van een ontwikkeltraject duidelijk hebt wat de architectuurprincipes zijn die van toepassing zijn op de te realiseren oplossing. Het is een kwestie van piket paaltjes slaan. De keuze momenten en de afwijkingen moeten adequaat door het projectmanagement bewaakt worden. Dat geldt overigens ook voor de bewaking van de waardecreatie door middel van Business Cases en TCO. Er ligt dus een relatie tussen architectuur en projecten. Daarom maken we in onze projecten gebruik van CMMi getoetste processen, o.a. vastgelegd in ons Application Management Systeem (AMS) en passen we TOC en FPA toe. De combinatie TOC en FPA helpt om de juiste keuzes te maken en snel tot resultaat te komen. Bij architectuur maken we voor domein- en structuurdiscussies gebruik van BDM en van het IAA model van IBM.”

Waarde

Paul: “Nog even over de waarde van architectuur. Je vindt het belangrijk om op niveau vier te komen, daar wil je ook op sturen. Maar ik kan me voorstellen dat er een nieuwe speler op de markt komt, die zich op één product concentreert en dat ene product heel efficiënt op de markt zet en daarmee qua prijs en kwaliteit kan concurreren met een product dat jullie voeren. Zo’n partij heeft dus geen architectuur.”

Daan (lachend):“Een internetbedrijf uit IJsland bijvoorbeeld.”

Paul:“Dat geldt voor het voorbeeld van Daan, maar het hoeft niet per se. Hoe houd je je architectuur zodanig dat je met zo’n partij kunt concurreren en hun aanbod kunt matchen?”

Ton:“Volgens mij halen we nu twee dingen door elkaar. Architectuur geeft inzicht in en een doorkijk op de samenhang der dingen. Maar je kunt alles in kaart hebben gebracht en alles op een heel logische manier in samenhang besturen, maar dat wil nog niet zeggen dat je kunt concurreren. Dat zijn echt twee volstrekt verschillende onderwerpen. Ik kan alles volledig gedigitaliseerd en op orde hebben, maar daarmee is nog niet gezegd dat het product verkoopt. Er is dus meer dan alleen technologische architectuur, er is ook nog een brand/merk, een prijsstelling, een distributiekanaal, de discipline in de salesorganisatie om het product te pushen/verkopen. Dat alles gaat ver voorbij de dingen die wij hier doen.”

Paul:“Een bekend voorbeeld: toen IBM begin jaren '80 nog heel sterk in de markt stond dreigden ze de pc-markt te verliezen. Toen hebben ze een aantal mensen bij elkaar gezet, die tezamen de pc hebben ontwikkeld en op de markt hebben gezet. Dat is toen een succes geworden ondanks dat er begin jaren '80 een sterke structuur in die organisatie was neergezet. Om een nieuw product in de markt te krijgen hebben ze die strakke sturing moeten loslaten.”

Ton:“Als je een innovatiestrategie op een technologie-unit van een financiële instelling van toepassing zou willen verklaren, dan heet dat ‘recombinatie’. Door het steeds slimmer leren combineren van bestaande technologische toepassingen kun jij outperformen. Maar je kunt geen oorlog winnen met technologie als je een financiële instelling bent. Je kunt ‘m ermee verliezen. Het is een conditio sine qua non.”

Paul: “Architectuur biedt je de mogelijkheid om te innoveren en dat ook kosteneffectief te doen.”

Ton: “Precies. Er is geen product zonder de technologie, maar voor IBM is de technologie het product.”

Daan:“Nationale-Nederlanden moet dus leren toveren met de technologie die je veelal overal ter wereld kunt kopen en vervolgens kunt combineren.”

Ton: “Ja. Tweederde van ons budget gaat naar technologie die we gewoon inkopen. En dat zal in de toekomst nog wel meer gaan worden. Maar de kennis van de processen en de samenhang tussen alles zit bij mijn mensen. Innoveren mijn mensen, dan innoveert ons bedrijf mee!”

Principes

Paul:“Onderschrijf je dat het bij architectuur belangrijk is om te werken met architectuurprincipes? Hanteer je er misschien een aantal?”

Ton: “Kleine aanpassingen kunnen nog in de oude systemen worden gedaan, maar bij een grote aanpassing is men verplicht om te migreren naar de standaard doelomgeving of doelarchitectuur. En daarmee heb je een principiële keuze gemaakt als het gaat over functies en processtappen: dit is de manier waarop wij definiëren waar welke functie ligt, dit zijn de applicaties die wij voor die functie gebruiken, dit is de server waarop wij draaien en dit is de standaard connectivity. Wanneer je dat volhoudt, krijg je een zeer gestandaardiseerd en homogeen landschap. En het wordt unieker op de plekken waarvan je zegt: daar mag je ook uniek zijn. Want dat onderscheidt jou nu juist op de markt. Maar de stack die eronder zit is wel dezelfde.”

Paul: “Als je door de aanpassing van een legacy-systeem heel snel veel geld kan verdienen, doen jullie dat dan?”

Ton: “Als binnen bepaalde criteria de business case heel positief is wel ja. In die zin heeft architectuur op zichzelf geen doel, het maakt ‘wonen’ en bedrijfsmatige activiteiten mogelijk. Het moet een oplossing verzinnen voor een zo optimaal mogelijk ‘leven’ van onze organisatie.

Daan: “Heb je ook nog andere principes? Strategische principes, die je misschien niet op een plaatje kunt aanwijzen? Bijvoorbeeld op het gebied van klantvriendelijkheid? Hebben jullie daar sowieso een beeld van?”

Ton: “Er zijn een aantal principes vanuit de Groep die doorvertaald zijn binnen Nationale-Nederlanden. In deze principes komen kernwaarden aan de orde zoals “Customer Centric”, “Easy to Deal With”, “Treats me Fairly” en “Delivers on Promises”. We meten onze klanttevredenheid, maar ook die van onze medewerkers. Door te werken met KPI’s en ratio’s stellen we de progressie en noodzakelijke verbeteringen vast.”

Daan:“Maar ik kan als klant van Nationale-Nederlanden nog steeds niet vanachter mijn pc inloggen om te zien hoe het ervoor staat met een aantal producten die ik afneem.”

Ton:“We hebben een paar distributiekanalen zoals het Intermediar en de bank en voor al deze distributiekanalen is er een ander bedieningsconcept. Met andere woorden “het distributiekanaal en het daarbij behorende bedieningsconcept bepaalt hoe en wanneer de consument over de relevantie informatie kan beschikken..”

Daan: “Jullie zorgen vanuit jullie domein voor de achterkant en de interface naar het frontend van de bank of de tussenpersoon?”

Ton:“Wij leveren steeds meer geparametriseerde componenten. En daarmee kom je op hetgeen architectuur brengt: flexibiliteit. Architectuur maakt iets mogelijk. Bij een bunker is deze zo star als wat, maar ons gebouw heeft nu eenmaal als doel flexibel te zijn.”

Daan: “Kun je op een gegeven moment op een punt komen dat jullie de frontoffice voor bijvoorbeeld ING definiëren.”

Ton: “Nee, want het gaat bij mij om de supply chain. Ik ben niet geïnteresseerd in look & feel. Dat is marketing en sales, daar weet ik niks van. En alles wat erachter zit zou eigenlijk één grote digitale machine moeten zijn.”

Discussies

Ton: “Als we hier architectuurdiscussies voeren, dan doen we dat op een drietal niveaus: op corporate-, line of business- en ook op productniveau. Bij het eerste twee gaat het om economy of scale, bij de derde geldt economy of scope. En vervolgens is de grote vraag wat precies waar hoort. Een datacenter hoort bij economy of scale, een gebouw idem dito. Maar een product is altijd economy of scope. Daarbinnen kun je zelf nog maatwerk krijgen, want binnen een productdomein, pensioenen bijvoorbeeld, zitten misschien wel twintig productvarianten die je allemaal moet kunnen ondersteunen. De vraag is of al deze twintig producten misschien met dezelfde incassomodule toe kunnen. Daar zitten dus gelaagdheden in. Er is vanuit de architectuur een beweging top-down en er is een productbeweging bottom-up. De uitzonderingen worden dus gedefinieerd door het product. Maar zou je altijd vanuit individuele producten werken, dan krijg je een bloedbad op het gebied van je infrastructuur en connectivity, want dan zit je met al die 1001 afzonderlijke componenten. We proberen natuurlijk wel te werken met in de basis identieke modules, waarbij er een gelaagdheid zit tussen rekenfunctionaliteit en het niveau waar de productfeatures worden gedefinieerd.”

Daan: “Het principe van de ontkoppeling tussen (bedrijfs)proces en (bedrijfs)functie, ook wel aangeduid met de ‘flow’ en de ‘know’.”

Ton: “Dat is het ultieme doel. Dat is de essentie waar het om draait.”

Raad van Bestuur

Paul: “Is architectuur een onderwerp dat je bespreekt binnen de Raad van Bestuur?”

Ton:“Op Nationale-Nederlanden-niveau kennen ze de BDM plaat allemaal. En iedereen weet dat wij langs deze as discussies voeren. Sterker: op een groot aantal van deze componenten zijn mijn businesscollega’s de eigenaar, die maken het beleid.”

Paul: “Wat verwachten ze van je?”

Ton: “Dat ik ze help met het realiseren van hun doelen.”

Daan:“Stel dat de business over twee jaar met iets nieuws komt en dat jij tot je spijt moet zeggen dat het niet kan. Wat dan?”

Ton: “Ik geloof in een architectuur als referentiemodel om variatie in het landschap te kunnen reduceren. Als dat lukt, dan maak je het zo flexibel dat het niet uitmaakt wanneer iemand na twee jaar iets anders bedenkt en anders moet je uiteindelijk bereid zijn je architectuur aan te passen.”

Paul: “De toepassing van architectuur vertaalt zich uiteindelijk in de beheersing van de overall-kosten van IT?”

Ton: “Inderdaad. En de keuzes worden steeds eenvoudiger. De eerste stap is een hele moeilijke, maar naarmate je die stap vaker hebt gezet, ontstaat er steeds minder discussie. Er komt vanzelf steeds meer functionaliteit in de centrale component, dus mensen zeggen op een gegeven moment zelf: ‘geef mij deze ook maar’. Dan is de governance-keuze snel gemaakt, de release-upgrade met de nieuwe functionaliteit zit tenslotte in het budget.”

Competenties

Paul: “Je hebt een architectuur unit. Kun je aangeven wat daarvoor de belangrijke competenties zijn?”

Ton: “Architecten moeten een diepgaande kennis hebben van het vakgebied; verzekeren en hypotheken in ons geval. Hij of zij moet het ook kunnen uitleggen, goed relaties kunnen leggen. En daarbinnen een onderscheid kunnen maken tussen hetgeen duurzaam is en operationele issues. Het eerste daar moeten ze de hele dag mee bezig zijn, van dat laatste moeten ze vooral wegblijven. Dus het zijn redelijk complexe functies en je zult er dus zelden jonkies zien.”

Daan: “Omdat ze onvoldoende achtergrond hebben, of omdat ze te chaotisch en te hectisch zijn?”

Ton: “Beide. De functie vraagt heel veel ervaring en het vermogen om nu en dan 'terug te zitten', te reflecteren en de zaak nog een keer uit te leggen. Begrijpen dat je sommige gesprekken nog een keer moet voeren. Dit was zo’n vijftien jaar geleden overigens nog geen sterk ontwikkeld gedachtegoed. We hebben daar voor een periode van zo’n vier tot vijf jaar echt heel veel tijd in geïnvesteerd. Inmiddels zijn we wel een eind opgeschoten, maar de omgeving weet nog steeds niet wat het allemaal precies betekent. Dat vraagt om uitleg. Naarmate wij dit beter doen, en hierbij het nodige geduld opbrengen, is men gevoeliger voor de verbetering. Maar het ontwikkelen van die vaardigheden kost zogezegd jaren en dat gaat niet vanzelf.”

Daan: “Dat snap ik, maar wat doe je daaraan?”

Ton: “Het gaat hier onder andere om een gedragsverandering die de gehele BPI organisatie aangaat. Hierbij staat het nog beter samenwerken op basis van gezamenlijke doelen, teamontwikkelplannen en innovatie, in de vorm van “continuous improvement” voorop. Dit bereiken we door teamsessies te organiseren met de focus op samenwerken en het maken van resultaatafspraken zowel op individueel als op groepsniveau. Dit maakt dat mijn mensen als professionals, zelfstandig en met brede ketenfocus, willen en moeten acteren.”

Paul:“Voor wat betreft architecten is het interessant om te weten welke eigenschappen een architect absoluut niet mag hebben”

Ton: “Te ‘klantgezwicht’ zijn. Als mensen de natuurlijke neiging hebben om alles wat er gevraagd wordt te verwerken in hun architectuur, dan is dat wel heel vervelend. Je moet vooral duurzaamheid nastreven in je principes en daaraan kunnen vasthouden.”

Daan:“Architecten moeten ruggengraat hebben.”

Ton: “Geen hit & run-mentaliteit, inderdaad.”

Paul:“Is er een opleiding waarvan je zegt: het zou goed zijn als ze die zouden doorlopen?”

Ton:“Je begint over het algemeen met werken als je ergens in de twintig bent. Bij een goed bedrijf leggen collega’s uit wat de basisvaardigheden binnen de organisatie zijn. Wij zijn een uniek bedrijf, de hier algemeen geldende principes kunnen we zelf uitleggen. Natuurlijk kan het ook anders, maar we hebben er nu eenmaal voor gekozen om het zo te doen. Daarnaast sturen we mensen naar congressen, maar dan vooral omdat wij denken dat ze dat leuk vinden. De rest komt van gericht trainen, trainen en nogmaals trainen en niet te vergeten collegiale toetsing.”

Paul:“Heb je nog een boodschap voor je collega-CIO’s?”

Ton: “Niet flauw bedoeld, maar die heb ik niet. Ik kan alleen maar uitleggen hoe wij vanuit onze werkelijkheid stappen maken. Ik heb niet de arrogantie om te denken dat de manier waarop wij stappen maken universeel is voor de rest van de wereld.”

[PDF]

Opmerking

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

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

19-03: NAF Insight met Jeanne Ross meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden