De CIO spreekt: Eric Sluis, GIO Achmea

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, donderdag 15 januari 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.

Voor Achmea-Group Information Officer (GIO) 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.”

Paul:“Waar denk je het eerst aan als we het hebben over de digitale architect?”

Eric:“Dat hun hersenstructuur wellicht een andere is dan die van een ‘normaal’ mens. Een architect leest misschien ook andere boeken op vakantie. Je zou in dat licht een literatuurlijst voor architecten kunnen bedenken. Zo hoeven ze niet het eerste boek van Robert M. Pirsig ‘Zen en de kunst van het motoronderhoud’ te lezen, maar wel het tweede, ‘Lila’, waarbij de hoofdpersoon in zijn eentje een reis maakt in een zeilschip en zich ten doel heeft gesteld vanuit zijn boot met behulp van een kaartenbakje een model van alles te maken. Om vervolgens in het boek tot de conclusie te komen dat hij niet wegkomt met een statisch model, maar dat hij een dynamisch model nodig heeft.”

Daan:“Zo’n boek zou een architect dus gelezen moeten hebben, om wakker te worden en te beseffen dat de statische benadering niet de goede weg is?”

Eric:“Nou nee. Een goede architect denkt op een soort metaniveau. Herman Hesse, Nobelprijswinnaar voor de literatuur, schreef een boek met de Duitse titel ‘Das Glasperlenspiel’. Dat is smullen, metafysica in het kwadraat! Het is allereerst een leuke levensgeschiedenis van een intelligente jongeling, die van armen huize is, maar het in het klooster toch weet te schoppen tot abt. In dat bewuste klooster heeft men het doel om de essentie van alle grote kunsten, wetenschappen, muziek, noem maar op, te sublimeren in glazen kralen. Op gezette tijden is er een feest, waarbij onder de verantwoordelijkheid van de abt een symfonie ten tonele wordt gevoerd door kralen op een harmonische wijze aan elkaar te rijgen: het Glasperlenspiel Je moet wel een beetje ‘anders’ zijn om zo’n boek mooi te vinden, maar een architect is zogezegd doorgaans wel een apart iemand.”

Daan:“Ik zou het al voldoende vinden als ze de inleiding van dat boek lazen. Daar staat namelijk al de kern van de filosofie.”

Evolutionair

Eric:“Een ander boek dat ze zouden moeten lezen is van Ken Wilber: ‘A theory of everything’, waarbij hij vanuit de ontwikkeling van de mens modellen opbouwt om vervolgens tot de conclusie te komen dat er een bovenliggend evolutionair model is, waarmee je verbanden legt. Bijvoorbeeld dat het nog geen zin heeft om democratie als maatschappijvorm te hebben, op het moment dat we elkaar met stenen de kop inslaan. Teruggekoppeld naar de architect: je zou een filosofie van dat vak kunnen ontwikkelen, een wijze waarop men zou moeten denken.”

Daan:“Je zou hem tot een moderne versie van Vitruvius kunnen maken (een Romeins militair en architect, vooral bekend als auteur van een standaardwerk over de bouwkunst, red.). Iemand die filosofisch is, redelijk abstract kan denken en zich kan inleven in mensen.”

Eric:“Maar ook holistisch, integraal. En tegenwoordig komt daar nog een belangrijke bij: transformationeel. Jonge, aanstormende architecten zijn namelijk niet per definitie gevoelig voor de context van een bedrijf. Eén van mijn businessarchitecten had een visie ontwikkeld op het bedrijfsmodel, het procesmodel en het informatiemodel. Door de Raad van Bestuur was in het kader van een fusie ook een organisatiestructuur vastgelegd. Die architect komt vervolgens naar me toe en zegt: ‘die structuur is fout.’ Mijn antwoord was: “We hebben input geleverd tijdens het proces en we hebben ook invloed gehad. Maar de RvB heeft om haar moverende redenen gekozen voor deze structuur. Er is echter ook goed nieuws: er is geen detailleringsniveau aangebracht dat dieper is dan de detaillering die wij al hadden. En de knippen die er zijn, kunnen we met ons beoogde model allemaal faciliteren.” En daarmee is ons te implementeren model dus toekomstvast.”

Alignment

Paul:“Hoe kwam architectuur hier in de picture?”

Eric:“Als directeur Finance & Control van Interpolis wilde ik in 1998 binnen mijn domein een eigen informatiemanager en informatieplan richting het IT-bedrijf 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 business-informatieplanning neergezet. Pensioenen was toen een transformatie- en fusiebedrijf, waarvoor we tevens een migratiearchitectuur hebben getekend.”

Daan: “Net als in de wegenbouw.”
Eric:“Ja, 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 demand-management 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.”

Paul:“In hoeverre helpt architectuur binnen een bedrijf dat is voortgekomen uit fusies en overnames?”

Eric:“We hebben op dit moment circa 1.800 serieuze business-applicaties, 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.”

Daan:“Met generieke componenten kun je het spel spelen. Dat bouwt sneller en zekerder, 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. Maar er is flink wat abstract inzicht en overzicht nodig om te kunnen bepalen wat de generieke stukken zijn.”

Ontkoppelen

Eric:“Ja, maar 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.”

Daan:“Dat bedoel ik.”

Eric: “Een levensysteem bevat onder meer een stukje klantenadministratie, een polisadministratie, een incasso, een klein grootboek en een debiteurenadministratie. 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.”

Daan:“Eén systeem als backoffice product, terwijl je in het midoffice een grote verscheidenheid aan producten kunt genereren, waarmee je kunt inspelen op heel specifieke wensen van de consument.”

Eric:“Ja, dat kan. Maar vooralsnog wel met behulp van de huidige complexe oplossingen.”

Veranderbaarheid

Daan:“Je wilt dus een architectuur die zoveel mogelijk los staat van de organisatorische verbijzondering. Zodat, wanneer je gaat veranderen, niet je totale architectuur, inclusief het applicatielandschap en de infrastructuur, hoeft te veranderen.”

Eric:“Het is inderdaad een ontkoppelingsvraagstuk. Er zijn diverse veranderingen waarvan we een aantal architectuurplaatjes hebben gemaakt en 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 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.”

Daan:“Het sterkste punt is inderdaad de juiste ontkoppelpunten te vinden, zowel in procesgangen als in producten. Dat heeft alles te maken met toekomstbestendigheid, veranderbaarheid.”

Eric (vult aan): “Flexibiliteit en economies of scale Dat betekent ook dat je je legacy in sommige gevallen langer kunt gebruiken door deze te wrappen, zoals we met een oude, overfunctionele AS/400 hebben gedaan bij de particuliere levensverzekeringen. Dat draait nu als straight through processing, als een fabriek waar het licht uit is.”

Daan:“Een oud grachtenpandje waar je een andere gevel voor doet en de rest intact laat. Je stuurt het aan aan de voorkant en de dingen die je niet langer nodig hebt, die gebruik je ook niet.”

Eric:“Door de nodige fusies en overnames zat ik ooit in de situatie dat we vijf polisadministraties hadden draaien. Daar wilde men voor zoveel miljoen één systeem van maken. 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. En aan de voorkant hebben we een callcenter-ondersteuning ingeregeld. Vervolgens hebben we het 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.”

Businesscase

Paul:“Is het moeilijk om zulke voordelen van een dergelijke ontkoppeling vooraf te vertalen naar de business?”

Eric:“Ik was zogezegd een tijdje directeur Finance & Control bij Interpolis. Dat was in de periode dat het grootboeksysteem vervangen moest worden. Maar niemand gaf er een stuiver voor. Er komen enorme investeringen bij kijken en zo’n vervanging raakt de hele organisatie, zeker in die tijd. En niemand ziet de waarde ervan. Daar is dus eigenlijk geen serieuze businesscase van te maken. Omdat zo’n traject toch business value moet hebben, zijn we gaan bedenken hoe de finance-functie van de toekomst eruit ziet. En daarbij hebben we gekozen voor een oplossing die dat mogelijk maakt.”

“Zo hebben we de vervanging van het grootboek gecombineerd met cost-accounting. Bovendien hebben we het neergezet als een uitvoeringsfabriek met een referentiële stekker aan de voorkant, die de financiële administratie kan voeren van ieder verzekeringsbedrijf. Dus een duidelijk referentieel ontkoppelpunt tussen het finance- en businessdomein. Daar hebben we heel veel plezier van gehad. Binnen een kwartaal hadden we een overgenomen bedrijf gewoon ingeplugd.”

Paul:“Heb je een businesscase voor architectuur?”

Eric:“Niet voor de overall architectuur, maar we maken er een per programma of project. Dat is soms een probleem, want de mensen die zich in algemene termen met architectuur bezig houden heten ‘staf’ Dus als je wilt bezuinigen, is men wel eens geneigd om te denken dat staven kunnen worden geschrapt. Terwijl er door een aantal slimme jongens neer te zetten heel veel uitvoering weg kan.”

Raad van Bestuur

Paul:“Staat architectuur als onderwerp op de agenda binnen de Raad van Bestuur?”

Eric:“Absoluut. En ook steeds meer. We noemen het dan het Groeps Business Informatieplan en daar komt elk jaar een nieuwe versie van uit. Daarin staan onze architectuurplaten, het businessmodel en onze procesarchitectuur. Dat laten we dan goedkeuren door de RvB.”

Paul:“Hoe lopen ze dan inhoudelijk door die stukken heen?”

Eric:“Steeds beter. Ze zien namelijk het oplossend vermogen van de architectuurmodellen Het geeft prachtige input op de discussie. De organisatieknippen verhouden zich namelijk nog niet altijd even lekker tot de modelknippen. Platen helpen RvB om die dingen te doorzien. We gebruiken de definitie van de businessdomeinen binnen de architectuur als basis voor de discussie over het volgende organisatiestructuurmodel.”

Paul:“Maar nog niet alle architectuurdomeinen en businessunits sluiten dus op elkaar aan.”

Eric:“Nee, en dat moet je gewoon accepteren. Ik ben daarover zogezegd wel in gesprek met de Raad van Bestuur. Overal waar knippen in de architectuur niet op dezelfde plaats zitten als knippen in de organisatie, heb je namelijk machtsvraagstukken, politiek en gedoe. Ik zoek dus heel proactief de discussie op hoe het bedrijf ingericht zou moeten worden.”

Paul:“Rekent de Raad van Bestuur jou daar als CIO ook op af?”

Eric:“Nee. De RvB ziet architectuur als een middel voor de CIO. Maar ze praten erover in andere termen, dus los van de vaktechnische kwaliteit. We plotten er namelijk ook de pijnpunten binnen de organisatie in. Een kwalitatieve benoeming van het probleem. En vervolgens komen we met voorstellen voor programma’s die we willen doen om het op te lossen. Daarbij beschrijven we de businesscase al globaal: dit willen we gaan doen en dit kost het zo’n beetje. Daarmee maak je het bestuurbaar en volgbaar voor de RvB. Dan kun je ook de opbrengsten van architectuur veel duidelijker maken.”

Grote vraagstukken – zoals van 1.800 naar 300 applicaties – los je volgens Sluis namelijk niet op met IT, maar vanuit business-informatieplanning. “Het is dus heel belangrijk dat de business verantwoordelijkheid neemt voor de eigen processen en informatievoorziening en daar ook tactisch het stuur op neemt”

Governance

Paul:“Wie is uiteindelijk verantwoordelijk voor de architectuur?”

Eric: “Het governancemodel is als volgt: je hebt een group information officer, dat ben ik dus. Als CIO heb je een integraal overzicht over het bedrijf en ziet 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.”

Paul:“Welke argumenten heb je gebruikt?”

Eric:“Raden van Bestuur werken het beste met kwadrantjes van maximaal twee bij twee. Dat is metafysisch meestal een goede, want je krijgt heel vaak of/of-vraagstukken, die eigenlijk en/en-vraagstukken zijn: wil je een maximale businessalignment of een maximale IT-voortbrenging? Terwijl businessalignment en IT-voortbrenging twee verschillende functies zijn. Daarom hebben we demand en supply hier geknipt.”

Toen Eric Sluis aantrad zat het pas gefuseerde bedrijf overigens met twee IT-directeuren, die de opdracht kregen om de zaken bij elkaar te voegen en te kijken of men twintig procent kon besparen op IT-kosten. “Mijn idee was dat we, voor we zouden beginnen met saneren, misschien eerst eens moesten gaan investeren in IT. Met betere processen konden we namelijk een enorme bijdrage leveren aan de operations van het bedrijf.”

Daan:“Je bent zelf auditor geweest. Maar heb je je architectuur wel eens laten auditen? Hoe weet je dat je de juiste architectuur hebt?”

Eric:“We hebben onze architectuur nog nooit echt laten auditen, maar ik heb bij IBM IAA gekocht, een insurance application architecture, dat 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. We hebben hier gewoon een Popperiaans model (naar de Oostenrijks-Britse wetenschapsfilosoof Karl Popper, die het principe hanteerde van observatie, inductie en falsificatie, red.): het is goed tot we tegen een probleem aanlopen dat in het bestaande model niet oplosbaar is, waarna we het aanpassen. De werkelijkheid ontkennen heeft nooit zin. Je kunt niet zeggen dat de werkelijkheid niet kan bestaan omdat het model het niet ondersteunt.”

Principes

Paul:“Welke architectuurprincipes hanteer je binnen Achmea? En dan met name die die je helpen onderscheiden van de concurrent.”

Eric:“Als je meerdere labels hebt, meerdere voorkanten, en je wilt standaardiseren op producten en productvoering, dan maak je aan de voorkant bijvoorbeeld onderscheid tussen directe klanten of 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 ‘n-op-n’-relatie 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.”

Daan:“Dus als de Bijenkorf morgen verzekeringen wil verkopen, kan het bij jullie zo in de backoffice worden geplugd.”

Eric:“Dan zouden we alleen maar een ander webportaaltje hoeven te tekenen.”

Paul:“Hoe ver ben je daarin?”

Eric:“We hebben hier precies voldoende architectuurprincipes om het bedrijf nu verder te helpen. Maar er is al veel architectuur uitgewerkt volgens de deltamethode van het bureau Novius, die we gebruiken aan de kant van de informatieplanning. IAA beschrijft zogezegd alleen de kernfuncties, dus daar vallen de finance functie, HR, sturingsinformatie en workflow buiten. Wat het ook niet beschrijft is hoe je met je webportalen en commerciële voorkanten omgaat. Het is dus heel nadrukkelijk een instrument voor de professionele architect dat we moeten verrijken met de niet-beschreven procesmodellen.”

Daan:“Ten aanzien van de pakketkeuzes zou je misschien moeten kunnen blootleggen in hoeverre de onderliggende architectuur van SAP aansluit of juist conflicteert met je eigen procesarchitectuur.”

Eric:“Je hebt een eigen architectuurvisie nodig om een pakket in te passen, anders ben je overgeleverd aan de SAP’s 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.”

Paul:“Zijn de architectuurprincipes ook bekend bij de businessmanagers?”

Eric:“Businessmanagers hebben er niet altijd evenveel affiniteit mee, maar binnen de business is zogezegd informatiemanagement belegd en bij de informatiemanagers is dit alles in voldoende mate bekend. Binnen de informatiemanagementraad homologeren we de architecturen en spreken we elkaar aan op overtredingen hierin. Daaronder hebben we de architectuurraad, waarin alle lead-architecten met uitwerkingsvragen komen. Bovendien toetsen we hier alle zware ontwerpvraagstukken. Besluiten vallen uiteindelijk in de informatiemanagementsraad.”

Hoog intelligent

Paul:“Wat vind je over het algemeen van architecten?”

Eric:“Ze zijn veelal hoog intelligent, maar ze hebben een paar nadelen. Meestal zijn het te brave adviseurs, te stafachtig. Ze geven wel een advies, maar als het bedrijf daar vervolgens niets mee doet, dan worden ze niet narrig of vervelend.”

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 hoor dat het goed gaat. Dus ik verwacht van mijn toezichthoudend architect dat hij de laarzen aan heeft en hij de bouwvergaderingen bijwoont.”

Paul:“Dit vertaald naar de digitale architect betekent...”

Eric:“Dat ik iemand wil die in normale business-taal 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.”

Daan:“Intuïtie en gevoel dus.”

Eric:“Ja. 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 het 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.”

“Daarbij komt de vraag, in het kader van de transformaties, is de architectuur maakbaar en de organisatiestructuur veranderbaar? Daarom zouden architecten ook in dat traject moeten durven te treden.”

Competenties

Daan:“Welke competenties moeten digitale architecten in huis hebben?”

Eric:“Een prima vooropleiding is bestuurlijke informatiekunde (BIK), zeker voor de businessarchitecten. Een goede technische architect kan ook een ingenieur zijn.”

Daan: “Je bedoelt daarmee toch geen engineerhè?”

Eric: “Nee, dan heb ik het over een Ir. Ik vind overigens dat we af moeten van de term architect, we moeten daar veel meer nuance in brengen. Als het gaat om de proces-, de informatie- en de informatiesysteemarchitectuur, dan kom je met die BIK’ers al een heel eind. Praat je daarentegen over SOA en harde technische infrastructuren, dan heb je meer een echte techienodig. Hoe dan ook, ze moeten allemaal samenwerken binnen een integraal model. Een engineer vind ik dus echt wat anders. Als de architect het bestek levert, dan doet de engineer de constructietekening. Die mag wat mij betreft in het supplybedrijf, maar zijn werk moet vervolgens wel getoetst worden.”

Paul:“Wat voor soort architecten heb je? Heb je daar bij Achmea nog enige variatie in zitten?”

Eric:“Vanuit IT is het logisch dat je vanuit ieders eigen verantwoordelijkheid architecten hebt. Zo heb je applicatiearchitecten, informatiearchitecten, business-informatiearchitecten en procesarchitecten nodig. Dus over de gehele breedte van het speelveld wil ik een soort architectuurdenken hebben; integraal vanuit producten, processen, informatie, systemen, technische infrastructuur; en alles is met elkaar verbonden.”

Boodschap

Paul:“Heb je een boodschap voor de architecten, misschien voor mensen buiten je eigen bedrijf? Wat zouden ze moeten doen om te professionaliseren?”

Eric:“Ze moeten ontzettend veel snappen van de bedrijfsvoering. De businessoriëntatie, het bedrijfsmodel en de branche kennen. En dit alles gebruiken als bron voor migratie en transformatie. Naar houding en gedrag moet een architect z’n mannetje staan: een controlling architect, met de laarzen aan zogezegd, die ook een interventie doet op de uitvoering en durft te escaleren. Het mag bovendien allemaal wel wat serieuzer.”

Daan:“Dus de business begrijpen, gevoel voor transformatie en ruggengraat hebben. Maar wat moeten ze absoluut niet doen?”

Eric:“Ze kunnen zich eindeloos verliezen in methoden en technieken. En ze hebben nogal eens de neiging om te klitten bij de vakbroeders, terwijl ze de organisatie in moeten en het bedrijf helpen businessproblemen op te lossen.”

Paul:“En heb je een boodschap voor de CIO?”

Eric:“Ik vind het goed wanneer deze ook een exploitatieverantwoordelijkheid heeft. Dat maakt, net als bij de architect, dat je niet meer hoeft te dromen. Alles wat je zegt moet ook geleverd kunnen worden. Daarnaast moet jouw servicedelivery zoemen als een fabriek en transparant zijn. En wat je zelf niet hoeft te doen, dat source je, zodat je je handen maximaal vrij hebt om echte toegevoegde waarde te leveren op het koppelvlak met je businesscollega’s.”

Hotze Zijlstra (Journalist), CIO Magazine
Daan Rijsenbrij (Interviewer), Via Nova Architectura, daan@rijsenbrij.eu
Paul Laagland (Interviewer), Via Nova Architectura, Paul.laagland@equaterra.com

[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