De CIO spreekt: John Froger, oud-CIO ABP

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, maandag 23 februari 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.

Digitale architectuur staat volgens John Froger heel dicht bij diens fysieke evenknie. Het is dus geen toeval dat de voormalige-CIO van ABP tijdens de terugblik op zijn tien jaar bij het pensioenfonds regelmatig gebruik maakt van analogieën uit de echte wereld. Ook visualiseren is volgens hem erg belangrijk. Bij de Sociale Verzekeringsbank, waar hij vóór zijn periode bij ABP werkte, liet hij de directievoorzitter de pijnpunten in de bedrijfsprocessen en architectuur zelfs letterlijk voelen door hem stapsgewijze fysiek het hele bedrijfsproces te doen doorlopen.

Paul:“Hoe definieer jij digitale architectuur?”

John:“Ik denk dat deze heel dicht tegen de fysieke architectuur aan ligt. Er liggen voor een groot deel ook dezelfde principes aan ten grondslag. Architectuur kan betrekking hebben op verschillende ‘dingen’, ‘zaken’ of ‘processen’. Dus of architectuur nu gaat over gebouwen, applicaties of wat dan ook, daar zit niet zoveel onderscheid tussen.”

Daan:“Er is een grote congruentie tussen het fysieke en het digitale en zij die beweren dat het niet zo is, zijn meestal zogenaamde softwarearchitecten, terwijl ik me persoonlijk afvraag of software wel architectuur heeft. Maar na een stap naar boven, dus naar de informatiesystemen en de businessprocessen, is de congruentie zogezegd erg groot.”

John:“Klopt. Ik zie die verschillen met de software overigens niet zo heel erg.”

Paul:“In de fysieke architectuur gaat het ook om ‘vormgeving’, ‘esthetiek’, dat soort onderwerpen. Kun je die doortrekken naar de digitale architectuur?”

John:“Ja. De volgende vraag is dan alleen hoe deze er dan uitziet en dat vind ik een stuk moeilijker. Misschien zijn we er bij digitale architectuur nog niet aan toe hoe je dingen mooier en toegankelijker kunt maken. Of gebruikers- en klantvriendelijk. Op die punten staan we nog maar aan het begin.”

Daan:“Ik hoorde twee dagen geleden een interview met een hoogleraar bewegwijzering uit Delft. Toen hij vertelde hoe hij Schiphol en JFK toegankelijk heeft gemaakt, kwam ik tot de conclusie dat je dat één-op-één kon omzetten naar de digitale wereld. Ik heb bij sommige applicaties, bijvoorbeeld voor internetbankieren, het gevoel dat de software niet weet waar ik zit. Ik weet bovendien niet waar ik naartoe moet, dus die hele ‘bewegwijzering’ ontbrak. Ik denk dat we op dat gebied nog veel van de fysieke wereld kunnen leren.”

Architectuurprincipes

Paul:“Hoe heb je de digitale architectuur bij ABP georganiseerd?”

John: “Het startte met het nadenken over de bedrijfsprocessen, die doorgaans event-gedreven zijn en waar mogelijk ondersteund door dezelfde applicaties voor min of meer dezelfde functionaliteit. Dat architectuurprincipe hebben we al vrij vroeg ingezet, al werd het niet onmiddellijk overgenomen en uitgevoerd. De vraag was vervolgens hoe je dat principe vervolgens bestuurt, wat veelal het probleem is bij grote organisaties. Een ander principe was dat wanneer je de gegevens van een klant al hebt, je ze niet nog een keer gaat uitvragen. Je moet er dus voor zorgen dat je al die gegevens eenmalig hebt opgeslagen. Dat is al een grote uitdaging, want grote organisaties hebben al die gegevens natuurlijk in meerdere bestanden zitten, met net verschillende betekenissen. Meta-gegevensbeheer is dus enorm belangrijk, maar het is tegelijk één van de moeilijkste dingen. Bovendien moet je er geld voor vrij zien te krijgen.”

Daan:“Ik weet er alles van. Ik heb voor het ministerie van OCW rond 1982 het basisonderwijs geautomatiseerd en daar bestonden misschien wel tien definities van ‘leerling’ We hebben toen, voor we verder konden, volop discussie gehad over wat ‘nuttig’ was en wat niet.”

John: “Dat kan ik me voorstellen, het is heel belangrijk dat je keuzes maakt. Ik heb tien jaar bij ABP gezeten en ik zat daarvoor tien jaar bij de Sociale Verzekeringsbank. Daar wordt onder andere de AOW en de kinderbijslag uitgevoerd. In die tien jaar hebben we de gehele kinderbijslag van ‘papier’ naar ‘digitaal’ kunnen herontwerpen en vervolgens geautomatiseerd. Dus alles van scratchaf aan. Ook daar hebben we dit soort keuzes gemaakt. Dat hebben we vervolgens met de AOW precies zo gedaan. En in essentie draait het nog op dezelfde wijze.

Paul:“Hoe heb je het aangepakt?”

John: “Het oude AOW-proces bestond uit 67 stappen. Toen de nieuwe president directeur binnenkwam dacht ik: hoe ga ik die man duidelijk maken dat het proces niet goed in elkaar zit? In het kort: hij was een paar weken binnen, toen we in twee zalen het hele AOW-proces hebben nagebouwd. Dus 67 tafeltjes en aan elk tafeltje gebeurde er iets. We hebben hem een niet te moeilijke, maar ook niet te makkelijke AOW-aanvraag in handen gedrukt en lieten hem beginnen bij tafeltje één, een videocamera er achteraan en vervolgens fysiek het proces door. Het duurde een hele dag en ik hoefde hem daarna niets meer te vertellen. Ik kreeg carte blancheom het proces te transformeren naar slechts vier stappen.”

Visualisaties

Daan:“Als het gaat om de werking van de architectuurprincipes zijn visualisaties bijna net zo belangrijk. Maar dan wel visualisaties op een niveau dat businessmensen kunnen gebruiken. Als je in de fysieke wereld een architect opdracht geeft voor het bouwen van een huis en deze komt terug met een stapel van 150 pagina’s tekst, dan kun je daar niets mee. Je wilt plaatjes!”

John:“Helemaal mee eens. Laat het maar zien. Een plaatje zegt meer dan honderd pagina’s tekst. Sterker: die film die we bij de SVB hebben gemaakt gaf zo duidelijk aan hoe erg het was dat hij meteen de kluis in moest”.

Paul:“Zijn de genoemde principes voor jou het belangrijkste als het gaat om architectuur?”

John:“De principes bepalen het ontwerp van je bedrijfsprocessen. Wanneer je geen principes hanteert, wordt het bovendien veel moeilijker om te denken in ketens. Dat zijn bedrijfsprocessen die dwars door businessunits heen gaan, wat altijd lastig is, omdat je te maken hebt met verschillende eigenaren, die aanvankelijk gericht zijn op hun eigen businessproces en nog niet zo bezig zijn met hun bijdrage aan het totaal.”

Daan:“Waren jouw principes bij ABP essentieel anders dan die van bijvoorbeeld PGGM? Of is er alleen verschil aan de buitenkant?”

John:“Hoewel ik daar met Wim Walter (de ex-CIO van PGGM, red.) nooit uitgebreid over heb gesproken, vermoed ik eigenlijk dat deze niet fundamenteel verschillen.”

Daan:“Hoe weet je dat je de goede principes hebt? In mijn ogen is architectuur zo ontzaglijk belangrijk, dat je ‘m eigenlijk onafhankelijk zou moeten laten auditen voordat je ‘m toepast. Hebben jullie dat ook gedaan?”

John:“De gedachte om onze architectuur eens te laten auditen kwam niet bij ons op. Bij de SVB had ik vrijwel dezelfde principes en ook deze heb ik nooit laten auditen.”

Daan:“En nu verandert er iets bij ABP, bijvoorbeeld een veranderende wens van de klanten. Maar je kunt die niet snel implementeren, omdat je vastzit in je eigen architectuur. Hak je dan bij de schuldige architect de vingertjes eraf? Krijgt er iemand op z’n kop?”

John:“Als er iemand op z’n kop zou moeten krijgen, dan zou ik dat moeten zijn. Ik heb dat destijds namelijk goedgekeurd en daar zit je dan voor vele jaren aan vast. Daarom zijn die basisprincipes ook zo belangrijk: je sleept ze jaren met je mee. Wil je ze veranderen, dan moet je je bedrijfsfunctiemodel omgooien, je processen, je ketens, alles. Die principes hangen met veel meer dingen samen dan alleen met IT.”

Effectueren

Paul:“Je kunt principes neerzetten, er de verantwoordelijkheid voor nemen. Maar dat betekent ook dat je het moet effectueren. Er zijn altijd diverse spelers binnen een organisatie, die allemaal een stukje macht hebben, belangen hebben, businessunits die specifieke IT-ondersteuning nodig hebben om producten in de markt te kunnen zetten. Hoe ga je daarmee om als CIO.

John:“Er is in de loop van de tijd wel het een en ander veranderd Aanvankelijk was er nauwelijks enige centrale sturing mogelijk De directies van de businessunits waren integraal verantwoordelijk, dus ook voor IT.”

Paul:“Op het gebied van IT was er geen overkoepelende sturing?”

John:“Nauwelijks en het gevolg was natuurlijk dat de kosten hoog waren, dat bleek ook uit een benchmark door Gartner. Er was wel een centrale architectuurclub en door te participeren in projecten slaagde deze erin architectuurprincipes neer te zetten. Maar dat was meer bottom-up dan top-down. Geleidelijk aan zag je evenwel dat het denken zich ontwikkelde in de richting van een centrale regie en architectuur. Op een gegeven moment beseften we met z’n allen dat het zo niet langer kon. Een jaar of vijf geleden hebben we de CIO-functie ingevoerd.”

Stroomversnelling

John:“Laat ik de ontwikkelingen van de afgelopen drie jaar eens schetsen, zaken die nu in een stroomversnelling komen. Drie jaar geleden heb ik twee clubs in het leven geroepen: de architectuurboard met de informatiemanagers van de verschillende businesses met de CIO als voorzitter. En de IT-governance-board met een lid van de RvB als voorzitter, de directeuren van de bedrijven en de CIO in een centrale rol. De architectuurboard is in feite het voorportaal voor de governance-board. Deze is formeel een adviesorgaan voor de RvB, maar materieel werden daar wel de belangrijke besluiten genomen. De lijn van betrokkenheid van de RvB is de afgelopen drie jaar gelukkig snel gegroeid.”

Paul:“Welke vragen stelt de voorzitter dan, in de lijn van de discussie?”

John:“ABP is op twee manieren in beweging. Ten eerste heb je de vormgeving van de (nieuwe) uitvoeringsorganisatie van ABP (en andere pensioenfondsen). Daarnaast is er de fusie met Cordares. Dat zijn twee bewegingen die bij elkaar komen. Dan moet je nadenken over de vraag welke architectuurprincipes je daarbij nodig hebt. Op dat niveau vindt de discussie plaats.”

Paul:“Helpt het hebben van een goede architectuur bij het integreren van een andere partij?”

John:“Absoluut. Ik denk dat de architectuurfunctie bij ABP goed is ingericht. Het is duidelijk dat het hebben van een goede chief architect in een organisatie zeer belangrijk is.

Paul:“Hoeveel architecten heb je binnen ABP nodig?”

John: “We hebben de laatste jaren de functie van lead architectgecreëerd, die dé architect is voor één business, onder aansturing van de chief architect die het geheel bewaakt. Daaronder heb je applicatiearchitecten, infrastructuurarchitecten en dergelijke. Dat brengt het totaal op pakweg 15 architecten.”

Paul:“De lead architect, is dat niet de business- of de informatiearchitect, bij wie de applicatie- en infrastructuurarchitecten als het ware ‘in de keten’ zitten? Of moet de lead architect de gehele keten kunnen overzien?”

John:“Wat we bedacht hadden was een lead architect per business. Dat is goed te doen voor vermogensbeheer, omdat er daarbij weinig verbindingen zijn met de rest. Maar we hadden er ook een bedacht bij pensioenen en bij de frontoffice, en daar zitten veel meer verbindingen tussen. Dus eigenlijk zou je een lead architect per keten moeten aanstellen.”

Daan:“Hoeveel declarabele uren zou de architect moeten maken?”

John:“Ongeveer de helft van zijn tijd, al kan het ook iets meer zijn. Je kunt van de klant namelijk niet verlangen dat deze betaalt voor het maken van de centrale kaders. Als het gaat om de rechtstreekse ondersteuning van de klant, dan laat je deze uiteraard wel betalen. Zo’n verhaal kan iedereen billijken.”

CIO-functie

John:“Er zijn in enkele jaren grote stappen gemaakt. Bijvoorbeeld het loskoppelen van de CIO-functie van de directeur-IT - ik heb nog beide petten op gehad.”

Daan:“De directeur IT wordt de baas van het rekencentrum en de applicatieontwikkeling en de CIO gaat meer op business- en directieniveau kijken hoe IT en informatievoorziening het proces kunnen faciliteren? Het zijn dus verschillende attitudes.”

John:“De CIO moet zich bemoeien met de businessprocessen en -architectuur. De directeur van een businessunit blijft wel verantwoordelijk voor de eigen processen. Maar het stelsel daarbinnen, de principes en de uitgangspunten, die worden naar mijn mening bepaald door de CIO. Uiteindelijk wordt alles afgetikt in de Raad van Bestuur, want als er onenigheid is tussen de CIO en een directeur van een businessunit, valt de beslissing toch in de RvB of bij het bestuurslid waaraan de CIO rapporteert.”

Daan:“Moet een club die onder een directeur IT valt wel of niet architecten hebben ?”

John:“In mijn ogen ligt de architectuur in belangrijke mate bij de CIO. Maar goed, de woorden architectuur en architect worden vreselijk misbruikt. Er wordt ook vaak iets mee aangeduid wat het niet is. Mensen die de infrastructuur uitwerken worden soms ook architect genoemd. Mensen die werken binnen de door de architecten gestelde kaders kunnen onder een directeur IT vallen. Voor de applicaties geldt precies hetzelfde. De applicatiearchitecten en de architecten van de technische infrastructuur vallen wat mij betreft onder de verantwoordelijkheid van een CIO.”

Paul:“Zit functioneel ontwerp ook bij het IT-bedrijf?”

John:“Ja.”

Paul:“Waar ligt de knip? Wanneer wordt iets een zaak voor het CIO-office of de business?”

John:“De uitvoering ligt op projectniveau, het CIO-office schept de kaders. Wie daar binnen blijft heeft geen last van de CIO of het CIO-office.”

Paul:“Je maakt dus een onderscheid tussen demand- en supplymanagement. De demand ligt bij de business, de supply ligt bij het IT-bedrijf. Maar wie stuurt het IT-bedrijf aan? Bijvoorbeeld in het geval de IT buiten de deur zou staan, waar jullie overigens niet voor gekozen hebben, maar wat in principe zou kunnen.”

John:“Je kunt twee kanten uit. Ik vind, maar niet iedereen zal dat met me eens zijn, dat de CIO-functie zwaarder is dan die van de directeur IT. Soms rapporteert de directeur IT aan de CIO. We hebben er bij ABP voor gekozen om ze naast elkaar te zetten en ze te laten rapporteren aan verschillende leden van de Raad van Bestuur.

Daan:“Het probleem is dat het CIO-office aan de vraagkant zit. Aan de andere kant zit de maak-kant. Dus krijg je tot in de Raad van Bestuur discussies over dat het gewilde niet maakbaar is. Dan krijg je al snel dat men zegt: ‘vraag eens iets reëels’. Als je alles neerlegt bij de CIO, dan regelt deze niet alleen de vraag, maar zorgt ook nog eens dat het maakbaar is.”

Discussie

Paul:“Verwacht je nu dat de discussie over architectuur ook in de Raad van Bestuur gevoerd wordt? Desnoods onder een andere naam, het business informatieplan, of hoe je het ook noemen wilt.”

John:“Dat denk ik zeker en dat juich ik ook zeer toe.”

Paul:“Betekent dat ook dat de CIO op een gegeven moment afgerekend wordt op het resultaat van architectuur?”

John:“Het zou wel moeten, maar ik zou niet weten hoe je dat aanpakt. Dat lijkt me heel ingewikkeld. Je komt dan op de vraag of je een businesscase kunt maken van architectuur.” Na een denkpauze: “Een voorbeeld: een stadswijk wordt onleefbaar. Is dat een architectuurfout? Is dat een fout in de opzet? Het heeft wellicht te maken met het feit dat er te veel goedkope huizen gebouwd zijn en er te weinig vertier is. Maar: hoe reken je dat nu af?”

Daan:“De Place d’Etoile werd ontworpen door de architect van Napoleon III, Baron Haussmann. Een helder ontwerp dat voldeed aan alle toegankelijkheidsprincipes van die tijd. Na 1960 is het vanwege het intensieve autoverkeer de slechtste architectuur die er is. Maar in 1860 was de auto nog niet uitgevonden”

John:“Kijk nu naar de woonerven: autoluw, drempels om ervoor te zorgen dat mensen langzamer gaan rijden. Maar iedereen wil daar weg, je wilt daar niet wonen. Heeft de architect die dat bedacht het fout gedaan?”

Goede architect

Daan:“Wat zijn volgens jou de positieve kenmerken van een goede architect? En welke dingen wil je bij een architect absoluut niet zien?”

John:“Wat ik niet wil zien zijn techneuterige architecten: jongens die prachtige modellen kunnen maken van blokjes en weet ik allemaal wat. Architecten en consultants zijn twee kanten van dezelfde medaille. Je moet dus ook het veld in kunnen gaan, begrijpbaar kunnen communiceren, luisteren en dat kunnen vertalen en terugleggen. Maar niet op de manier van ‘dit is mijn vak en ik weet wel hoe de wereld in elkaar steekt’. Daar is een brede oriëntatie voor nodig. En misschien ook wel grijs haar, want het totaalplaatje kunnen overzien ontwikkel je pas in de loop der jaren. Je moet ook de bedrijfsprocessen, de bedrijfsoutput, maar ook de bedrijfscultuur goed begrijpen. Je moet bij wijze van spreken tien jaar vooruit kunnen kijken. Daar komt dus meer bij kijken dan alleen het kunnen maken van mooie modellen.”

Daan:“Die grijze haren zijn iets wat je nodig hebt bij het bewandelen van het transformatiepad. Het gaat om aanvoelen wat het bedrijf aankan en ervoor zorgen dat je uiteindelijk terechtkomt waar jij dat wilt.”

John:“Je moet nadenken over het pad waarlangs en de tijdsduur waarin je een en ander denkt te kunnen realiseren. En architectuur ís een kwestie van langetermijndenken. Als je tenminste naar de principes kijkt. Hoe lager je komt, hoe korter de tijdscyclus wordt. Maar ik houd van lange-termijndenken, want dan bereik je ook wat. Dat AOW-traject, daar hebben we bij SVB vijf jaar over gedaan. Voor de kinderbijslag geldt precies hetzelfde. Maar dan kun je het ook grondig aanpakken. En uiteindelijk stáát er ook wat.”

Paul:“Maar wie ontwerpt dan de bedrijfsprocessen? Dat is op een hoger niveau toch ook een architectuurfunctie?”

John:“De business zelf in samenspraak met de CIO. Er moeten meer mensen met een businessarchitectprofiel komen. Het aantal businessconsultants en organisatieadviseurs die op een hoog niveau echt naar de processen kunnen kijken, is bij veel organisaties minimaal.”

Mannetjesputters

Daan:“Nog even terug naar echte gebouwen, bijvoorbeeld het nieuwe kantoor van een grote bank. Daar is iedereen in geïnteresseerd. Je kunt om zo’n gebouw heenlopen en de president-directeur kan erover opscheppen. Het is een soort fallus-symbool. Wat kunnen wij daar in de digitale wereld van leren?”

John:“Ik heb bij SVB gewerkt met de inmiddels overleden toparchitect Abe Bonnema, die heeft het gebouw van Nationale Nederlanden in Rotterdam neergezet. Als hij aan het werk ging, dan zat het Bestuur er met de neus bovenop. Dat is wanneer het om digitale architectuur gaat heel anders. Aan de andere kant, mensen als Carel Weeber, Abe Bonnema en Herman Hertzberger, dat zijn wel mannetjesputters! Ze kunnen fantastisch communiceren en hebben altijd een verhaal, al vraag je je soms af waar het over gaat. IT-architecten zijn daarentegen minder extravert.”

Daan:“Ook digitale architectuur moet je verkopen, vooral naar boven.”

John:“Wij hebben op architectuurgebied nog geen iconen.”

Daan:“En misschien moeten we minder architectuurtools gebruiken. Pak een vel papier en ga tekenen! Wanneer de opdrachtgever of de Raad van Bestuur je niet begrijpt, dan breng je het fout.”

John:“Is dat niet een probleem dat voor de IT als geheel geldt. De IT heeft zichzelf door allerlei prachtige modellen toch heel lang volstrekt onmogelijk gemaakt?”

Daan:“Is dat de schuld van het softwarehuis of van de klant die dat allemaal tolereert?”

John:“Heel veel IT-deskundigen kunnen niet anders communiceren dan op deze manier. Overigens geldt dat ook voor veel juristen. Het is niet zo eenvoudig je eigen vak te overstijgen. Vervolgens ben je niet staat om zodanig te communiceren dat je gesprekspartner je ook echt begrijpt.”

Paul:“Moeten we misschien, net als in de fysieke wereld, toe naar onafhankelijke personen, die gewoon langs komen, zich inleven in jou bedrijfsproces en vervolgens met een architectuur komen?”

John:“Architecten moeten goed kennis hebben van de bedrijfsprocessen. En het is vaak zo dat je die niet kunt opdoen als je niet zelf in zo’n bedrijf zit. Maar als je ze in de bedrijven neerzet, hebben ze soms weer geen overkoepelende visie. Misschien moeten ze eerste een tijdje in het proces hebben gezeten, om vervolgens verder te kunnen. Ik heb overigens wel een aantal externe architecten gehad, die het niet verkeerd hebben gedaan. Meestal zijn het mensen die het gewend zijn om zich ergens heel snel in te werken, de processen te doorgronden, de cultuur te pakken. Dat is zeker een toegevoegde waarde.”

Daan:“Je hebt er als externe architect alleen wel een paar goede businessanalisten uit het bedrijf bij nodig.”

John: “De essentiële kennis ontbreekt intern vaak om goed te kunnen ontwerpen. Je hebt inderdaad goede businessanalisten en businessconsultants nodig die de architect kunnen voeden. Maar voor een goede architectuur moet je wel vast wat geproefd hebben van ist en de mogelijke sollDat haal je niet alleen uit de businessconsultants, dat moet je zelf ook hebben geproefd. Door met mensen te praten, door participerende observatie. Ga desnoods met ze de kroeg in.”

[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