De CIO spreekt: Hennie Wesseling, CIO TNT Post

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

Hennie Wesseling, CIO bij TNT Post, heeft vanaf het jaar 2000 de aanbodkant van de IT als een bedrijf georganiseerd. “Op die manier maak je namelijk alles transparant en voorkom je de discussie dat IT te duur is.” Destijds is bovendien besloten om de digitale architectuur bottom-up, vanuit de infrastructuur, op poten te zetten. “Je begint dan namelijk vanuit een gebied dat je als IT’er zelf kunt besturen, in plaats van dat je telkens in het vaarwater van de business komt. Onze ervaring is dat deze benadering werkt.”

Paul: “Wat versta jij onder digitale architectuur?”

Hennie: “Het is een analogon. Daaronder versta ik een set van wetten en regels waarmee je als bedrijf IT-oplossingen en IT-diensten die ertoe gaan doen, gericht kunt doorontwikkelen, of afscheid kunt nemen van zaken die er niet meer toe doen. Het is dus niet het kunstje van het afschaffen van oude systemen, maar het gaat erom IT een plaats te geven binnen de dynamiek van het bedrijf. Zet je een fysiek gebouw neer, dan kan een architect eisen dat je er vijftig tot honderd jaar niet aan mag komen. Neem het Congresgebouw in Den Haag: de tegeltjes mogen er niet af, het gebouw gaat niet met z’n tijd mee. Binnen de IT is dat anders. Iedereen weet dat de digitale systemen vergeleken met fysieke bouwwerken een korte levensduur hebben. Bovendien is in de IT altijd sprake van een doorontwerp-situatie. Je moet altijd rekening houden met wat je doorontwerpt over vijf jaar. Een ander groot verschil met de fysieke situatie is dat je je eigen werk in een hoog tempo moet vernietigen; het wordt opgevolgd door het volgende werk. Dus naast de regels en wetten is digitale architectuur een ontwerpstrategie die houdbaar blijft en het in zich heeft om gestructureerd afscheid te kunnen nemen van vorige ontwerpen.”

Daan: “Ik zeg altijd: maak twee architectuurplaatjes. Een voor over drie jaar, want dat heb je gemiddeld nodig voor je transformatieproces. En een voor over tien jaar om richting te geven aan je toekomstverwachtingen. Het gaat namelijk niet alleen om het plaatje, je moet ook de vrijheid hebben om volgende stappen te kunnen zetten.”

Hennie: “Ja, maar er moet ook een continuïteit in zitten. Veel IT-architecturen worden ingevuld met harde hulpmiddelen. Dan kun je anno 2000 zeggen dat je bij wijze van spreken het leukste geveltje hebt gevonden, maar dat kan na verloop van tijd een product blijken met een te gering tijdsbesef; je hebt dus producten die je ondanks hun populariteit toch niet wilt hebben. Toen wij rond die tijd een paar dingen bij elkaar brachten, kozen we voor SAP en de Microsoft-suite. We wisten dat een producent als Microsoft in een tijdsbestek van acht jaar één generatie software genereert. Dat betekent dat we in 2010 nog steeds op deze basislijn zitten, want we gaan niet om de vijf jaar hele blokken veranderen. Maar we wisten toen wel dat binnen die tooling de hele architectuur op z’n kop zou gaan, onder meer in de richting van het web. We wisten evenwel dat het binnen de te verwachten lijn zou blijven, inclusief de productaankondigingen, en dat weten we ook voor de komende jaren. Dus door een bepaalde setup van tooling kun je door één, twee, misschien wel drie generaties een lijn doorontwikkelen. Dat bepaalt in hoge mate ons succes van standaardisatie en kostenverlaging. De afweging is daarbij onder meer hoe sustainabledeze lijnen en partners zijn. Terwijl in veel gevallen de keuze in politieke termen wordt besproken.”

Opdrachtgevers

Hennie: “Als het gaat om de functionele architectuur heb je twee soorten klanten: aan de ene kant onze 24 business-opdrachtgevers. Aan de andere kant heb ik er nog eens meer dan tienduizend, de eindgebruikers. Die laatste groep wordt in toenemende mate een autonoom gebied binnen IT. Iedereen die zegt dat de pc een commodity is, die jokt. De totale omgeving van de pc is geen commodity, wij hebben bijvoorbeeld gecertificeerde weegschalen aan de pc hangen en we hebben gecertificeerde processen voor het scannen van pakketten. Ook de pc’s moeten daardoor aan allerlei ISO-standaarden voldoen, waardoor je soms bijvoorbeeld met een thin-client niet uit de voeten kunt. We hebben dus ‘consumenten’, waarvoor we een personal environment hebben. De architectuureis is een suite die het mogelijk maakt om in continuïteit door te ontwikkelen, om jezelf te refreshen. Aan de andere kant hebben we het corporate verhaal, waarvan 50 tot 70 procent van de belangrijkste processen zo SAP in gaan. Dat doen we overigens niet met onze primaire processen. We maken voor SAP dus geen vertical voor de postal industry. Waarom niet? Geld, verwachtingen, complexiteit; het is een echte special. Er is binnen onze industrie namelijk geen bedrijf identiek.”

Daan: “Je hebt dus een eigen, wellicht impliciete, vanuit de business gedicteerde architectuur. Daarin kies je vervolgens voor een pakket, dat ook een inherente architectuur heeft. Dan implementeer je met de nodige moeite dat pakket. Maar misschien is het wel verstandiger om de eigen architectuur eens te confronteren met de intrinsieke architectuur van het gekozen pakket, want zo kom je erachter waar de ruimte en de eventuele frictie zit. En kun je bekijken of je er op de lange termijn mee uit de voeten kunt.”

Hennie: “Toen wij besloten om SAP aan te schaffen was dat geen IT-beslissing, maar een businessbeslissing. Daarbij was de business verantwoordelijk voor de functionaliteit , maar de randvoorwaarden waren wel dat het ondersteund moest worden door SAP. Die afspraken zijn gemaakt. We hebben bovendien een architectuurboard opgericht en spelregels opgesteld. Daaraan ging wel een grondige analyse vooraf, die bijvoorbeeld moest uitwijzen of SAP wel voldoende rijk en flexibel was. Bovendien moesten de roadmaps van SAP de bulk van onze bedrijfsactiviteiten in voldoende mate ondersteunen.”

Er zijn destijds bovendien een paar belangrijke principes geformuleerd, bijvoorbeeld dat men binnen SAP zo min mogelijk maatwerk wilde. Hennie: “Wij konden in 2000 als IT overigens niet steunen op een vooraf vastgelegde bedrijfsarchitectuur. Als je dan zou moeten wachten tot iedereen zijn mind heeft opgemaakt om iets te kunnen kiezen, dan komt de uitvoering in de knel. Er moest natuurlijk ook wel iets gebeuren. En men had doorgaans al zo weinig affiniteit met IT.”

Businessarchitectuur

Hennie: “Bij het maken van een businessarchitectuur houden we het dus eenvoudig. We hebben het van twee kanten bekeken: de bedrijfsprocessen (business environment) en de eindgebruikers (personal environment). De eindgebruiker wil alles wat hij al had terugzien in de nieuwe applicaties. Het architectuurprincipe op het functionele vlak wordt dus dat hij ook alles krijgt, mits tegen marktconforme prijzen.. Wanneer we maar ver genoeg voorlopen op de markt, hebben we hier doorgaans tevreden eindgebruikers. Zo zitten wij nu in de fase dat we PKI (private key infrastructure, red.) uitrollen, waarmee bijvoorbeeld iedereen , ongeacht de vormfactor van zijn apparaat, draadloos het netwerk op kan. Op het moment dat iemand zich aanmeldt, weet het netwerk of iemand geautoriseerd is. Daar ligt architectuur aan ten grondslag. Dus binnen de personal environment gaan we niet zitten wachten op de business, maar de gebruiker krijgt bij wijze van spreken alles. Tienduizend klanten krijgen gemak, weelde en aardigheid.”

Daan: “De drie g-factoren: gemak, gewin en genot.”

Hennie: “Aan de businesskant wilden we in het kader van de beheersbaarheid en de kosten toe naar een aantal doelarchitecturen voor de infrastructuur, want die hebben we gekozen als basis. De applicatiearchitectuur lieten we rond 2000 nog even voor wat hij was. Vervolgens hebben we ons de vraag gesteld waar we zelf goed in waren en waar pakketten voor beschikbaar waren. En daarbij hebben we gekeken welke leverancier de meeste continuïteit kon bieden. Daarvoor hebben we onder andere gewoon het financiële jaarverslag van de leverancier gebruikt, we wilden tenslotte een oplossing voor de lange termijn. Vervolgens kregen we de vragen of ‘daar dan alles in zit’ en ‘of het dan alles doet’. Nee dus, vandaar dat we hebben gesteld: het is SAP, tenzij businessprocessen er echt niet door kunnen worden ondersteund. Dat is het eerste ontwerpprincipe. Het tweede is dat we standaard SAP gaan gebruiken. Dus de businessprocessen werden waar mogelijk aangepast aan de standaard.”

Methodisch

Volgens Hennie zorgt dat niet voor wrijving: “De IT is in bepaalde opzichten verder dan de business in zijn strategische opzet. Dat zeg ik niet uit arrogantie, het is een methodische constatering. De IT heeft nu eenmaal bepaalde dingen die gewoonlijk tot een bepaald resultaat leiden. Dit moet je vervolgens verkopen aan de business. Die willen nu ook een portfoliomanagement hebben, een businessarchitectuur. Op zo’n moment kan de IT een oplossing bieden, op de voorwaarde dat de business de boel structureert. Het is vaak een bottom-up verhaal; we zijn begonnen met de architectuur van datacenters en zo. En dat ziet de business op dat moment nog helemaal niet. Vervolgens ga je omhoog, zoals gezegd met de keuze voor SAP, en nu zitten we op een niveau dat binnen de business het besef bestaat dat ze ook mee moeten.”

Daan: “Dus er is op een gegeven moment besloten de architectuur serieus aan te pakken. Vervolgens rationaliseerden jullie eerst de infrastructuur, daarna het applicatielandschap, eventueel met pakketten en dergelijke, en daarna gingen jullie naar de business. Op dat moment konden jullie ze ook iets bieden, in plaats van alleen de vraag te stellen wat ze zouden wensen.”

Hennie: “Exact. Als je in 2000 had gezegd dat men eerst een businessarchitectuur moest hebben, dan hadden we pas nadat die op orde was kunnen kijken naar de applicatiearchitectuur. En als we daar dan mee klaar waren geweest, hadden we eens kunnen kijken hoe we de pc’s zouden kunnen neerzetten en inrichten. Als we het zo hadden gedaan, dan hadden we onze functie verkeerd ingevuld.”

De IT zou in zo’n geval niet serieus genomen zijn. De CIO kiest derhalve liever voor een meer pragmatische benadering: “Wat IT’ers fout doen is zeggen: ‘ik kan niets doen, omdat u niet zegt wat u wilt’. Maar draai het nou eens om; sla vanuit de IT eens de brug naar de business. Maak jezelf explainable, transparant en leg aan de functionele kant uit voor wie je aan het werk bent.”

Daan: “Tegenwoordig is enterprise architectureenorm in opkomst, wat dat ook moge zijn. Maar ik zie dat sommige enterprise-architecten zo ongeveer op de stoel van de CEO gaan zitten. Die willen de hele onderneming in kaart brengen, et cetera, et cetera. Dat is totaal anders dan wat jij zegt.”

Hennie: “Stel dat jij CEO van een bedrijf bent en dat er iemand verschijnt die zegt dat jij even opzij moet en hij gaat jou vertellen hoe de business in elkaar steekt. Lijkt me redelijk arrogant en bovendien ben je bezig de business te ‘sjabloniseren’. Daar geloof ik dus niet in, want de business is een dynamisch iets. Een commerciële baas is een ander iemand dan een IT-baas. En de business blijft de baas,

De methodische aanpak komt tot uiting in de IT . Eerst vanuit de kelder, via de terminal op het bureau. Vervolgens kwam de pc en voor de ondersteuning van moeilijke kwesties - men wilde namelijk geen ‘help’ meer roepen - de servicedesk. Inmiddels zijn we zover dat op elk bureau een ‘zendmast’ staat. Met andere woorden: de eindgebruiker die vanuit de kelder werd bediend, vervolgens werd geholpen op zijn bureau en daarna geserviced in zijn bestaan, die heeft nu een website waarmee hij jou bestookt en een weblog waarin hij over het bedrijf schrijft wat hij wil. De communicatie was ooit technologisch, maar deze is nu helemaal aan het opschuiven naar het sociale vlak. Voor HR iemand aanneemt, hebben ze deze persoon eerst gegoogeld en ook nog even gekeken op Hyves. Vanuit de architectuur moet je nu dus al de principes gaan meenemen die betrekking hebben op die sociale context. Maar de business moet aangeven wat een medewerker mag of niet mag.”

BlackBerry

Hennie: “Dus waarom hebben wij nu dit ding (laat zijn Windows-smartphone zien) en geen BlackBerry? Omdat die laatste alleen e-mail biedt. Dit ding hier is een communicatiecentrum aan het worden. Dat was een uitgangspunt in de integrale architectuurbenadering, en zo gebruiken wij ‘m inmiddels ook. Daar komt de onafhankelijkheid van de vormfactor dus nog bij. Bovendien kost dit mij straks niks, want de werknemer gebruikt z’n eigen apparaat. Een BlackBerry moeten wij als bedrijf daarentegen aanschaffen. Vanuit de alignment met de business gaat het hier vooral om kostenbesparing. Net als bij de zendmasten is het dus niet alleen meer een IT-managed object, er komt ook een stuk zelfmanagement bij kijken. Als iemand bijvoorbeeld tien printers op zijn bureau zou willen, dan is dat zijn eigen verantwoordelijkheid. Wij garanderen de laagste prijs per item. Door dat wij daar als principe voor kiezen, is de manager vrij in zijn keuzes.”

Daan: “Waar luister je dan naar? Want je zegt eigenlijk ook dat je niet naar de business hoeft te luisteren, want je weet het zelf beter. Je hebt namelijk architecten die een droomkasteel kunnen ontwerpen, terwijl bouwers misschien een kaartenhuis willen maken. Jij zegt als het ware: mensen willen heel veel verschillende droomkastelen, maar ze kunnen niet zeggen hoe het eruit moet zien.”

Hennie: “Nou nee, beter weten doe je samen. Beslissen over shared services doe je wel centraler. Wij draaien hier sinds 1998 e-commercetoepassingen. Destijds is gezegd: we moeten toe naar een platform, want ‘ze’ gaan straks allemaal websites maken en die willen ze vanuit de business allemaal gaan aansluiten op de facturering. En we leven hier nu eenmaal van onze administratie, dus facturering is essentieel. De toenmalige architect maakte een platform, een schil, daar kunnen we vervolgens websites op aansluiten en is daarmee bij het opzetten van een website de facturering meteen geregeld. Is dat een architectuurprincipe of niet? Op end-user niveau is het een kwestie van vraagcoordinatie en portfoliomanagement door het CIO-office, omdat we dit puur zien als infrastructuur.”

Daan: “Dus als het gaat om eindgebruikers, dan ben jij als CIO namens het bedrijf verantwoordelijk, neem je de beslissingen en schat je in overleg met de business IM- of IT bazen in wat er moet gebeuren. Als het over de bedrijfsprocessen gaat en de businessunits, dan zijn zij verantwoordelijk. Maar hoe ga je nu met architectuur om in relatie tot die primaire processen? Met name als het gaat om de governance: wie beslist waarover? Je komt nu namelijk op een punt dat je wellicht meer moet samenwerken.”

Hennie: “Samenwerken doen we altijd al, al gaat dat niet altijd zonder slag of stoot. Ook van onze kant worden gewoon voorstellen ingebracht die dienen te worden goedgekeurd, daar is geen misverstand over. Het is alleen zo dat je het infrastructurele denkwerk vanuit een meer centrale visie verricht.”

Wagenpark

Dat is volgens de CIO wel nodig als het gaat om IT, en om dat te illustreren maakt hij de vergelijking tussen managen van IT en een wagenpark: “Die auto’s snapt iedereen, de IT niet. Maar zodra iets in de gemakssfeer belandt, zoals de auto’s, dan wordt het uit je handen gerukt. Dan hebben ze je niet meer nodig. Neem webontwikkeling. Dat leidt tot geweldige gevaren, omdat mensen het nu zelf denken te kunnen. Of goedkoper. Je krijgt nu de fase van de ‘rommelwijken’, geknutsel door jongetjes op de hoek. Dit speelt naast de ‘gestructureerde wijkaanpak’ waar wij het vanuit de CIO-office over hebben. Mensen hebben tegenwoordig het idee dat ze de IT zelf kunnen doen. Mensen die willen structureren worden vaak als lastig ervaren, dus dat draagt hier ook aan bij.”

Daan: “Daarom zijn er ook nog maar zo weinig mensen die IT gaan studeren. Je gaat toch niet iets studeren wat je thuis ook kunt opzetten?”

Hennie: “Precies. Het idee dat er op scholen geen onderzoek meer nodig is, omdat alles op IT-gebied al is uitgevonden. Er is dus een onderstroom aan het ontstaan van mensen die zich eigenlijk niets van architectuur willen aantrekken, maar een eigen krottenwijkje naast het voetbalveld willen maken. Dat gaat een aantal jaren goed, tot het veldje vol staat, er misdaad en allerlei ongeregeldheden plaatsvinden.”

Paul: “Moet je het dan verbieden?”

Hennie: “Een belangrijke regel: verbied nooit iets. Want wat doen mensen dan? Ze doen het toch!”

Paul: “Het betekent wel dat je de randvoorwaarden creëert dat ze niet je kern kunnen raken. Ze kunnen een website maken, die kan rommelig zijn, maar via deze site kunnen ze nooit bij een van je kernsystemen komen.”

Hennie: “Zowel procedureel als technisch. Maar dat heeft niets meer met architectuur te maken. Dat is gewoon management.”

Besluitvorming

Paul: “Hoe heb je het proces van het architectuur bedrijven ingeregeld? En hoe je de besluitvorming daaromheen plaats? Bijvoorbeeld in een architectuurboard, waarin principes worden besproken?”

Hennie: “We verwachten allereerst van de business dat architectuur terugkomt in hun informatieplannen. Architectuur is bovendien een onderdeel van het gemeenschappelijk stuurgroepoverleg. Vijf jaar geleden was het woord architectuur nog helemaal niet aan de orde. Dus we zijn het vanuit een systematische benadering gaan opbouwen. Inmiddels hoef je over de werkplek niet meer te praten, maar vijf jaar geleden was dat nog hét onderwerp. Het onderwerp verschuift in de OSI-stack dus nog steeds en, nogmaals, we zitten nu op het applicatieniveau. Administratieve primaire applicaties hebben we in samenspraak met de business vrij centralistisch opgelost. Dus als we een factureringssysteem vervangen, dan zijn de productie, de commercie, IT en administratie betrokken. Die zitten dan ook allemaal in de stuurgroep. Bij andere primaire processen, zoals sortering, stoppen wij op de grens van specifieke en generieke ontwikkelingen. Wij hebben het dus altijd over de generieke zaken. Er is één businessline die sortering doet en die hebben daar dan ook een dedicatedclub op zitten. Hetzelfde geldt voor onze printdivisie. We standaardiseren daarbij alleen op interfaces.”

Bij TNT is zo langzamerhand sprake van een ‘voorwaardenscheppende architectuur’. De controle vanuit de CIO-office bij grote investeringen spitst zich bijvoorbeeld toe op de vraag of er sprake is van portfoliomanagement, een van de voorwaarden die vanuit de architectuur geschapen wordt: “Je bent dus samen een opkruipend design aan het maken, door het hele bedrijf heen, waarbij de business in toenemende mate ook een beschrijvingsmethodiek moet kiezen en ontwerpconstraints krijgt opgelegd.”

Daan: “Je zegt dus eigenlijk: architectuur is een kwestie van standaardiseren en fatsoeneren. Je bent begonnen bij je infrastructuur en je bent vervolgens langzaam naar boven gegaan. Dit in plaats van de benadering van bovenaf met regels en richtlijnen.”

Hennie: “We komen langs en kleden jou bij wijze van spreken van onder naar boven aan. We beginnen met de schoenen en komen een week later met je broek. En als we eenmaal boven zijn, dan kom jij erachter dat het allemaal leuk bij elkaar past. Van die aanpak hebben we dan een blauwdrukje gemaakt, waarmee je vervolgens zelf aan de slag kunt. Maar als we geen succes kunnen boeken, dan beginnen we er niet aan.”

Daan: “Quick wins, die ervoor zorgen dat je succesvol blijft.”

Hennie: “Eerder begrijpelijke stappen maken, die leiden tot het inzicht dat de uitkomst nuttig was. Maar dat gaat niet zonder een zekere arrogantie en productgerichte aanpak. Met polderen kom je op dit gebied niet ver. Wij moeten dan ook altijd al een stuk voor het peloton uit rijden. De klanten denken nog aan pc’s, terwijl wij al denken in termen van services. Dat is wel eens lastig. Je moet dan ook niet te ver voor de rest uit rijden. Kom je een half uur voor het peloton binnen, dan is na de bloemen niemand meer in je geïnteresseerd, want iedereen vraagt zich af hoe de wedstrijd verloopt. Heb je een voorsprong van tien meter, dan spreekt iedereen van een fantastische overwinning.”

Vanzelfsprekend

Daan: “Is architectuur hier al vanzelfsprekend aan het worden?”

Hennie: “Het is niet vanzelfsprekend binnen ons totale bedrijf. Maar de mensen in dit kantoor en die we dagelijks zien, die snappen wel dat je dingen onder architectuur moet doen. Maar naarmate je bij kleinere units komt, die net gekocht zijn, of nieuw opgericht zijn, dan is het wel eens anders. Dat is veelal een maturiteitskwestie, maar dat is ook wel te begrijpen. Architectuur is voor velen een wezensvreemd onderwerp. Qua abstractie valt het overigens wel mee, onder meer door het opkruipen van methodieken binnen de business.”

Paul: “Heb je het onderwerp architectuur, misschien in andere termen, op de agenda van de Raad van Bestuur staan?”

Hennie: “Absoluut niet. Binnen de board zijn ze met business bezig, met geld verdienen. Architectuur is misschien pas over tien jaar aan de beurt. Ik vraag me overigens af waar ze het wél op de agenda hebben staan. Bij verzekeringsbedrijven? Ja, dan praat je over mensen die in hun product-development volledig IT-gedreven zijn. Wij zijn van oudsher een fysiek bedrijf. Als wij over e-commerce willen praten, dan wordt dat gezien als een IT-gedreven iets. Terwijl wij zeggen: dat is business. Als het gaat om architectuur mogen we al blij zijn dat er draagvlak voor is dat wij het als instrument nodig hebben om verder te kunnen komen.”

Paul: “Mag je er geld aan uitgeven?”

Hennie: “Dat bepaal ik zelf. Dat is een managementkwestie en heeft niets met IT te maken. Als je voortdurend iets moet verkopen om geld te krijgen, dan krijg je hetzelfde verhaal als met de hoogleraren in Nederland. De helft is bij wijze van spreken overbodig, omdat ze de helft van hun tijd bezig zijn met geld te zoeken. Vanuit het CIO-office zorg ik dat er binnen het totale budget een gedeelte beschikbaar is voor architectuur.”

Daan: “Hangt deze pragmatische benadering samen met het feit dat TNT met name een fysiek bedrijf is?”

Hennie: “Het heeft ook met mijn managementopvattingen en manier van besturing te maken. Ik zou het bij bijvoorbeeld een financiële instelling of de overheid waarschijnlijk precies zo doen. De infrastructuur is iets dat niemand meer op zijn begroting hoeft te hebben, want het staat al op de mijne. Moet je nagaan wat dat scheelt voor businesslines om niet over dat soort posten te hoeven nadenken.”

Competenties

Paul: “Welke eigenschappen en competenties moet een architect hebben?”

Hennie: “Dé architect? Serieus: deze moet een goed overzicht hebben in wat zich afspeelt binnen de velden, zowel technologisch als methodisch. En pragmatisch zijn in wat het bedrijf bezig houdt, dus vanuit de business-alignment snappen wat de business nu eigenlijk vraagt. Dus iemand met technische wortels die een brug kan slaan. In toenemende mate zal de architect meer te maken krijgen met de sociale context, zeker als je kijkt naar applicatiearchitecturen. Er zal steeds meer vraag komen naar chatfuncties en andere communicatiemogelijkheden.”

Daan: “En omgedraaid? Waarmee moet een architect volgens jou eens ophouden? Wat voor architect zie je liever niet?”

Hennie: “Iemand die zich louter in de technologieën en methodologieën wentelt, en vindt dat dit het communicatievehikel is. Iemand die niet de houding heeft van bruggen bouwen, maar zich in zijn eigen wereldje wentelt. Als mensen niet naar mij luisteren als ik ze vraag om een businessarchitectuur te maken, dan kan ik niet beginnen; zulke mensen zijn volkomen obsolete. In zijn algemeenheid moet het IT-vak leren - voor zover dat nog niet gebeurd is - om op aarde terug te keren en te beseffen dat we leven in een wereld die betaalt voor het gebruik van onze spullen, en niet omdat ze zo mooi zijn. We moeten bezig zijn om moeilijke dingen op een gemakkelijke manier toegankelijk te maken.”

Er kan bovendien maar één architect verantwoordelijk zijn: “Je kunt meerdere architecten aan het werk hebben, en dat gebeurt hier ook wel, maar er moet er maar één gelijk hebben. Dat heeft hij natuurlijk niet altijd, maar het voordeel is wel dat je consistent bent. Dat is in dit vak, vanwege die snelle veranderingen vele malen belangrijker dan de topkeuze op het moment dat je moet kiezen. Ik ben dan ook een forse tegenstander van de best-of-breed-benadering. Want als je al die leuke pakketten samen wilt brengen, dan heb je geen architectuur en geen interface-policy. Daar gaan je kosten down the drain.”

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