Voor Achmea-CIO Eric Sluis strekt het digitale architectuurdenken zich uit over het totale speelveld van het bedrijf: producten, diensten, processen, informatie, systemen, de technische infrastructuur en zelfs de structuur van de organisatie. "Wat ik wil, is een integrale visie op ons bedrijf, nu en straks, en op de transformatie die we doormaken. En daar zitten dus al die verschillende aspecten aan."

Architectuur kwam bij Achmea in beeld toen Eric Sluis als directeur Finance & Control van Interpolis in 1998 binnen zijn domein een eigen informatiemanager en informatieplan richting het IT-bedrijf wilde hebben. "Er is in die opzet maar één eigenaar voor het businessdomein Finance & Control, die verantwoordelijk is voor alle investeringen en desinvesteringen. Zo heb ik informatiemanagement als functie ontdekt. Toen ik vervolgens naar Pensioenen ging heb ik businessinformatieplanning neergezet. Pensioenen was toen een transformatie- en fusiebedrijf, waarvoor we tevens een migratiearchitectuur hebben getekend. Dus net als in de wegenbouw, met tijdelijke oplossingen om de knelpunten te overbruggen. Toen ik in 2004 concern-ict ging doen bij Interpolis, ben ik heel zwaar gaan drukken op demandmanagement bij de businessunits. Bovendien is het CIO-governancemodel ingericht en de IT-supply georganiseerd als een aparte fabriek. En dat was feitelijk de denklijn tijdens de fusie met Achmea."
Volgens de group information officer kan architectuur binnen een bedrijf dat is voortgekomen uit fusies en overnames op diverse punten zijn dienst bewijzen. "We hebben op dit moment circa 1.800 serieuze businessapplicaties, waarvan heel veel specifieke toepassingen en een beperkt aantal generieke. Een bedrijf van onze omvang zou er naar ons gevoel niet meer moeten hebben dan een stuk of 300, met bovendien veel meer generieke toepassingen. Je hebt architectuur nodig om te kunnen bepalen wat specifiek en generiek is, dáár gaat het over. Je moet dus wegblijven uit de discussie centraal-decentraal."

Sneller en zekerder
Met generieke componenten kun je als organisatie sneller en zekerder bouwen, want deze componenten zijn al gelouterd door de tijd en daardoor zijn er al flink wat fouten uit. Terwijl in alles wat je van scratch bouwt nog vele fouten kunnen zitten. Er is evenwel flink wat abstract inzicht en overzicht nodig om te kunnen bepalen wat nu precies die generieke stukken zijn. Sluis: "Daarnaast speelt er nog iets anders. Verzekeringsbedrijven hebben sinds jaar en dag een redelijk hoog automatiseringsniveau. Bijna iedereen heeft al eens een centrale IT-afdeling gehad en er is al heel veel geautomatiseerd. Maar de exploitatiekosten van een verzekeraar zijn erg hoog. Daar zijn heel veel redenen voor: we slepen altijd van alles uit het verleden mee, een polis kan zomaar dertig jaar bestaan. En als we een nieuwe toepassing bedenken, dan automatiseren we de oude situatie opnieuw met de nieuwe componenten, waarmee de kostprijs waanzinnig hoog wordt en het project overcomplex. Architectuurdenken zou daar geweldig helpen."
"Een levensysteem bevat onder meer een stukje klantenadministratie, een polisadministratie, een incasso, een klein grootboek en een debiteurenadministratie", vervolgt de CIO. "Zo'n systeem moet, wil je eenvoudiger een nieuw product kunnen lanceren, dus als stukken uit elkaar gehaald worden. Daarmee kom je op een principe dat de automobielindustrie al lang geleden ontdekt heeft: mass customization. Dat is een specifieke assemblage van standaardcomponenten. Dat resulteert daardoor in een lagere kostprijs. Die lijn van denken zijn we nog maar net aan het ontdekken. In het nieuwe, ontkoppelde systeem zou je dan ook eenvoudig een nieuw, verbijzonderd productmodel moeten kunnen toevoegen. In die zin staan we als verzekeringsindustrie vlak voor een industriële revolutie."

Veranderbaarheid
Idealiter wil je als organisatie dus een architectuur die zoveel mogelijk losstaat van de organisatorische verbijzondering. Zodat, wanneer je gaat veranderen, niet je totale architectuur, inclusief het applicatielandschap en de infrastructuur, hoeft te veranderen. "Het is een ontkoppelingsvraagstuk", oordeelt de CIO. "Er zijn diverse te verwachten veranderingen waarvan we een aantal architectuurplaatjes hebben gemaakt. Daarbinnen hebben we de nodige percelen ontdekt. We weten ook wat de verbindende hoofdwegen zijn en kunnen een aantal percelen onafhankelijk van elkaar laten bewegen. Sterker nog: we weten al hoe die hoofdwegen eruit moeten zien. We kunnen dus de percelen en hoofdwegen separaat gaan ontwikkelen vanuit onze vastgelegde langetermijnvisie. Het gaat daarbij dus om toekomstbestendigheid, onafhankelijkheid en faciliterend voor veranderingen. Dus alle veranderingen die je binnen het bedrijf binnen vijf jaar mag verwachten, moeten gesupport kunnen worden."
Dat betekent dat je je legacy soms langer kunt gebruiken door deze te ‘wrappen', zoals bij Achmea met een oude AS/400 is gedaan bij de particuliere levensverzekeringen. "Dat draait nu als straight through processing, als een fabriek waar het licht uit is." Ander voorbeeld: door de nodige fusies en overnames zat men in de situatie dat er vijf verschillende polisadministraties draaiden. Daar wilde men aanvankelijk voor zoveel miljoen één systeem van maken. Sluis: "Maar mijn reactie was: "We zijn aan de voorkant nog niet performant, we hebben geen ontkoppeling tussen de front- en backoffice." Dus als een klant belde, stond iemand uit de backoffice op om de klantvraag te beantwoorden. Ik ben dus eerst maar eens een knip tussen front- en backoffice gaan leggen. Aan de voorkant hebben we een callcenterondersteuning ingeregeld. Vervolgens hebben we de backoffice gereorganiseerd volgens fabricageprincipes. Daar hebben we één operational datastore bovenop geplakt, waarmee we een integraal klantbeeld hadden. Daarmee waren we ineens hartstikke performant naar onze klanten."

Principes
Een belangrijk architectuurprincipe binnen Achmea is, met oog op de verschillende labels die worden gevoerd, het standaardiseren op producten en productvoering aan de achterzijde. Aan de klantzijde kun je meerdere voorkanten hebben, en bijvoorbeeld onderscheid maken tussen directe klanten en iemand die je via een intermediair of via een bank bedient. "Deze kanaalbediening is iets anders dan het runnen van een verzekeringsbedrijf, want dan maak je onderscheid tussen leven, schade, sociale verzekeringen en pensioenen. En over al die labels wil je al die producten kunnen verkopen. Dus je krijgt een een-op-eenrelatie tussen kanalen en productvoeringsentiteiten. Dat los je op door een koppelentiteit, die we hier ‘verbinding' noemen. Daarbij wordt zowel ontkoppeld van de backoffice als van de voorkant."
Hoe weet de CIO nu dat hij de juiste architectuur heeft? "We hebben de onze nog nooit echt laten auditen, maar ik heb bij IBM IAA gekocht, een insurance application architecture, die de kernfuncties van een verzekeraar beschrijft. We gebruiken ook de architectuurmodellen van onze leveranciers, zoals SAP en Oracle/Siebel. Denk dus niet dat we elkaar hier met z'n allen heel briljant zitten te vinden. Iets is goed tot we tegen een probleem aanlopen dat in het bestaande model niet oplosbaar is, waarna we het aanpassen."
Ten aanzien van de pakketkeuzes heb je in de ogen van Eric Sluis een eigen architectuurvisie nodig om een pakket in te passen, anders ben je namelijk overgeleverd aan de leveranciers van deze wereld. "Alle ontkoppelpunten van je eigen architectuur moeten door het pakket gerespecteerd worden. Als ik een logische knip zie, bijvoorbeeld tussen een integraal klantbeeld met alle polisnummers en een meer transactionele klantadministratie - systemen die wel in meerdere opzichten op elkaar lijken - dan verwacht ik dat die knip ten minste ook technisch gerealiseerd kan worden, anders heb je een niet-toekomstvaste oplossing. We hoeven dus veel minder systeemontwikkeling te doen als we maar eenduidig vasthouden aan de proces- en informatiearchitectuur."

Raad van bestuur
Architectuur staat binnen Achmea intussen steeds meer als onderwerp op de agenda bij de raad van bestuur. En wel onder de noemer van Groeps Business Informatieplan, waar elk jaar een nieuwe versie van uit komt. Daarin staan de architectuurplaten, het businessmodel en de procesarchitectuur. Dat alles moet dan worden goedgekeurd door de RvB. De leden zien volgens de group information officer in toenemende mate het oplossend vermogen van de in de bestuurskamer getoonde modellen. "De organisatieknippen verhouden zich namelijk nog niet altijd even lekker tot de modelknippen. Platen kunnen helpen om die dingen te doorzien. We gebruiken de definitie van de businessdomeinen binnen de architectuur als basis voor de discussie over het volgende organisatiestructuurmodel."
Sluis: "Het governancemodel is hier als volgt: je hebt een group information officer, dat ben ik dus. Als CIO heb je een integraal overzicht over het bedrijf en zie je waar de toekomstige veranderingen zitten, wat de veranderagenda is. Je hebt bovendien verschillende decentrale CIO's, de divisie-informatiemanagers binnen de business, waarmee ik een functionele relatie heb, dus geen hiërarchische. En we hebben met het oog op de knip tussen demand en supply de Group IT-services als uitvoeringsbedrijf."

Laarzen aan
Omdat de CIO wil dat ze ook de verantwoordelijkheid nemen voor de realisatie, wil hij het liefst een ‘controlling architect'. "Vergelijk het met de bouw van een huis: mijn architect helpt me mijn behoefte te vertalen naar een architectuur en neemt de verantwoordelijkheid voor het bestek en de uitkomst van de constructieberekening. Met de uitvoering van de bouw wil ik verder weinig te maken hebben, behalve dat ik van de architect wil horen dat het goed gaat. Dus ik verwacht van mijn toezichthoudend architect dat hij de laarzen aan heeft en hij de bouwvergaderingen bijwoont."
Vertaald naar de digitale architect betekent dit dat de CIO iemand wil die in normale businesstaal naar managers communiceert. "Iemand die complexe vraagstukken over structuur en inrichting gewoon in platte voorbeelden kan uitleggen en begrijpbaar kan maken. Een goede architect moet zogezegd ook organisatiebewust zijn, gevoel hebben voor de belangen en weten hoe de hazen lopen."
Dat komt ten dele neer op intuïtie en gevoel: "Als je aan Cruijff vraagt hoe hij een bal stil legt, dan kan hij dat niet uitleggen. Het is een kwestie van gesublimeerde ervaring en inzicht, en het al diverse malen eerder gedaan hebben. Op dit soort intuïtie en gevoel durf ik vervolgens blind te varen. Een goede architect is overigens ook een bedrijfseconoom, want hij krijgt te maken met principes van exploitatie. En er zitten vraagstukken uit de bedrijfskunde in: waar zitten procesknippen, hoe zien processen eruit, wat is het onderscheid tussen het primaire en het besturend proces? De architecten moeten in het bedrijf rondlopen om te ruiken waar problemen gaan komen of waar opportunities liggen."
Bij Achmea zitten architecten in diverse soorten en specialismen: applicatiearchitecten, informatiearchitecten, businessinformatiearchitecten en procesarchitecten. "Over de gehele breedte van het speelveld wil ik een soort architectuurdenken hebben; integraal vanuit producten, processen, informatie, systemen, technische infrastructuur; en dan alles met elkaar verbonden."