De CIO spreekt: Rob de Haas, voormalig group CIO ABN AMRO

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, dinsdag 08 september 2009

‘Een knoeperd van een uitdaging’

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.

Rob de Haas, voormalig CIO van het wereldwijde bankconcern ABN Amro en CIO of the Year 2008, heeft naam gemaakt dankzij een intelligente sourcingstrategie en -aanpak. Hij had en heeft daarbij te maken met drie categorieën digitale architecten: de businessarchitecten van ABN Amro, zijn eigen ‘technische architecten’ en de technische architecten in dienst van de leveranciers. De uitdaging is en blijft volgens De Haas om de kloof tussen de twee typen architecten, die binnen business en die van de IT, te dichten.

Paul: “Architecten hebben vaak gelijk, maar omdat ze de boodschap niet altijd even goed overbrengen krijgen ze het niet altijd. Dat vormt de basis voor deze interviews en onze website www.via-nova-architectura.org. Zie jij dat ook zo?”

Rob: “Het moeilijke van architectuur is dat de waarde ervan nooit van tevoren is vast te stellen. Alleen maar achteraf, en in de regel als het niet goed gegaan is. Vaak lijkt de architectuur bovendien op een artist’s impression. Toen ik mijn eerste huis kocht kreeg ik ook zo’n impressie. Toen het opgeleverd werd heb ik tegen de verkoper gezegd dat het niet was wat ik gekocht had, want op het plaatje stond dat de lucht blauw was en er vlogen twee meeuwen. Maar bij oplevering regende het en die meeuwen waren nergens te bekennen. Dus wat had hij mij nou verkocht? Nogmaals: daar zit de moeilijkheid voor de architect. Bovendien krijgen zij het verhaal niet altijd goed over de bühne.”

Paul: “Zoals ik al zei.”

Rob: “Ja. En dus krijg je twee soorten architecten: de architect die een verhaal vertelt dat de business begrijpt, zo iemand noemen ze een businessarchitect, en daarnaast heb je de technische architect. Maar die twee zijn niet altijd op elkaar aangesloten, dus we blijven altijd hetzelfde probleem houden. De vraag is of je het met één architect af zou kunnen.”

Daan: “Heel lang geleden zeiden we ook al dat de programmeur de gebruiker niet begreep en omgekeerd. Dus toen zijn er aan enkele universiteiten BIK-achtige opleidingen bedacht om dat gat te overbruggen. Dat is niet gelukt, om het maar eens zachtjes uit te drukken. Daarna hebben we architecten uitgevonden, waarmee echter het gat weer niet is overbrugd. De IT’ers en de mensen voor wie het wordt gemaakt blijven elkaar niet begrijpen.”

Rob: “In Nederland wordt gewoon niet opgeleid voor hetgeen waarop men in het bedrijfsleven op het gebied van IT zit te wachten. In een veranderende omgeving hebben we inderdaad architecten nodig, maar ik blijf erbij dat er geen goede allround architecten worden opgeleid aan de universiteiten en dus houden we binnen IT technische architecten. Binnen ABN Amro hebben we een afdeling ‘business solutions’, waar de architecten aan de businesskant nadenken over de benodigde oplossingen. Maar helaas vinden die twee niet altijd aansluiting.”

Engineers

Daan: “Om terug te komen op je huis: de mensen die de mogelijkheid voor overspanningen en dergelijke berekenen noemen we ‘engineers’. Praten die in de fysieke wereld met de echte architect die alles op functioneel niveau bekijkt? Hooguit dat ergens een paal extra bij moet komen, maar in detail spreken ze niet met elkaar.”

Rob: “Jawel. De architect van mijn huis is de opdrachtgever aan de constructeur. Dan heb ik het dus over de echte architect. Maar deze is in feite ook de businessarchitect, want die maakt als eerste mijn artist’s impression. Daar zitten business- en technische architectuur dus in één hand. Die architect had meerdere constructeurs op het oog en heeft van allemaal een offerte aangevraagd. Hij moest ook kunnen bepalen met wie hij uiteindelijk in zee wilde gaan.”

Paul: “Zou je de technische architecten daarom niet veel meer moeten benoemen als ‘constructeurs’? En moet je niet veel meer kijken naar de competenties van de businessarchitecten, om vervolgens te bepalen of ze die centrale architectenrol kunnen spelen?”

Rob: “Eens. De businessarchitect moet dus leidend zijn. Maar vervolgens komt die businessarchitect ook in mijn ‘huis’ om functionele ontwerpen te tekenen, waarvan de technische mensen roepen dat het helemaal niet kan. Ik heb dus nu dingen in huis die op papier mooi leken, maar technisch niet helemaal goed zijn.”

Daan: “In jouw beleving of als het gaat om de adaptiviteit?”

Rob: “Het functioneert nu niet goed. Ik vraag me soms wel eens af of ik die architecten niet gewoon moet opdoeken. Welk risico loop ik daarmee? Hahaha.”

Daan: “Dan wordt het architectuurwerk wel gedaan door andere mensen; businessanalisten, innovators, noem maar op.”

Rob: “En wat is daar mis mee?”

Daan: “Helemaal niets. Er zijn bedrijven waar de architecten ‘informatiemanagers’ heten en de techneuten ‘architecten’. Het gaat in feite alleen maar om het functioneren.”

Outsourcing

Rob: “Precies, dus waar zit nu het echte risico? Waar moeten we ze wel hebben en waar komt het gewoon niet van de grond? Ik denk evenwel dat het in kaart brengen van de samenhang der dingen een hele wezenlijke is. Ook daarmee worstelen we binnen ABN Amro, maar we proberen het wel. Onze outsourcing heeft daar overigens bij geholpen. Wij hebben tegen de insourcer gezegd dat ze contractueel voor ons verplicht zijn een beschrijving van de current state technische architectuur te maken en dat hebben ze aan het begin van de contractperiode ook daadwerkelijk gedaan. We zijn trouwens met opzet niet bij de businessarchitectuur begonnen, omdat lang niet alles wat je kunt bedenken daadwerkelijk technisch realiseerbaar is. Op deze manier hebben we een fundament van waaruit we met de business kunnen praten. De current state architectuur is in kaart gebracht om daarmee een future state-architectuur te kunnen maken.”

Paul: “Wie is er verantwoordelijk voor die future state?”

Rob: “Wij, als ABN Amro. We hebben daarom ook onze eigen architecten gehouden. Maar het in kaart brengen van de current state kun je beter bij de leverancier neerleggen.”

Daan: “Een vakcollega van mij noemt dat soort architecten wel eens ‘cartografen’. Die hoeven niets creatiefs te hebben, die moeten de boel alleen maar in kaart te brengen. Precies wat het kadaster ook doet: dit zijn de kavels en dat de relaties. Maar je hebt deze informatie wel nodig voor je transformatie naar de future state.”

Rob: “Inderdaad. Want waar zijn architecten binnen het outsourcingsverhaal belangrijk? Niet bij de transitie, maar bij de transformatie. Dus niet bij het overnemen van de systemen en de regieprocessen enzovoorts. Maar wel waar het gaat om het doorvoeren van eventuele wijzigingen en innovaties. Wil een leverancier iets gaan verdienen aan een contract, dan moeten er qua technologie namelijk altijd wel dingen veranderd worden. Denk aan zaken als verbeterde server utilisation, gebruik van nieuwe technologieën en dergelijke. Wij hebben binnen ABN Amro 72 van deze transformatietrajecten afgelegd. Daar zijn in alle gevallen onze technische architecten bij betrokken geweest. Ook al omdat de businessfunctionaliteit ongewijzigd is gebleven.”

Daan: “Je hebt het over rationaliseren onder de motorkap?”

Rob: “In technisch opzicht inderdaad. Dat moet je doen, omdat als je het besluit om zaken terug te nemen, je vervolgens niet iets terugkrijgt dat je zelf niet kunt beheersen of kunt overdragen naar een andere contractpartner. Dat betekent dat er nog iets heel anders bij zit: bepalen waar de rechten op het intellectual property liggen. De technische architecten hebben mede de verantwoordelijkheid om vast te stellen of we, wanneer we als bedrijf en contractpartner uit elkaar gaan, de door de partner ontwikkelde technologie kunnen blijven gebruiken.”

Paul: “Je veronderstelt dus dat de architect verstand heeft van alternatieven, intellectual property en meer van dat soort zaken.”

Rob: “In ieder geval dat ze een signaal geven wanneer een leverancier tussen twee standaardpakketten een klein stukje software gaat maken voor zijn eigen optimalisatie. Want stel dat ik het pakket terughaal of verplaats, dan krijg ik een discussie over intellectual property. Er ligt dus een ander type verantwoordelijkheid bij de architect.”

Paul: “Er ligt wel een kiem voor een conflict, omdat de leverancier geld kan verdienen door efficiënter te opereren en dat jij vanuit jouw belang zegt dat je dat niet wilt.”

Rob: “Tenzij je goed op papier zet dat bijvoorbeeld de IP van jou is. De leverancier heeft in dat geval een right to use en jij bent de eigenaar.”

Daan: “Om te voorkomen dat je straks een business lock-in hebt met een provider.”

Rob: “Precies. Ik denk dat we wat dat betreft als ABN Amro weinig risico lopen.”

Innovatie

Daan: “De businessarchitecten zijn bij ABN Amro intern. In een grote transformatie kan ik me goed voorstellen dat je tegen de leverancier zegt: kom maar eens met suggesties. Zij zien namelijk heel veel nieuwe dingen op de wereldmarkt en kunnen dus ook optreden als een innovator op businessniveau.”

Rob: “Klopt, maar in de sourcingswereld moet je wel een onderscheid maken tussen aan de ene kant de Infrastructuur en anderzijds Application Development en Maintance (ADM). Je moet er voor zorgen dat contracten innovatie elementen in zich dragen, die de insourcers ‘aanmoedigen’ om producten en processen efficiënter te maken en de laatst beschikbare technologieën aan te wenden.”

Paul: “Kun je een voorbeeld geven?”

Rob: “Regel- en wetgeving op het gebied van security kunnen een trigger zijn. Onze strategische architecten gaan dan samen met de innovatie teams van de leveranciers opzoek naar een oplossing. Dat is ook contractueel geregeld en de leverancier speelt binnen het zogenoemde ‘value creation center’ een leidende rol, omdat bijvoorbeeld ook de partner voor het netwerk of een andere partij erin mee moet.”

Daan: “Ook in de fysieke wereld werd en wordt door architecten veel geëxperimenteerd, concepten en constructies worden gewoon uitgeprobeerd. Dergelijke laboratoria zijn voor de digitale wereld dus ook heel belangrijk, met name voor het uitproberen van nieuwe concepten van dienstverlening.”

Knip

Paul: “Waar ligt in ADM, binnen het ontwikkelproces de knip tussen de externe partijen en ABN Amro?”

Rob: “Richting India ligt de knip een klein stukje verder dan het functional design.”

Paul: “Functional design ligt hier en de rest in India, maar wat is de rol van de architecten daarin?”

Rob: “Bij het functional design zijn de businessarchitecten betrokken. En daar ga je dan weer, want de technische architecten vinden al zolang ik in dit vak zit dat ze er te laat of helemaal niet bij betrokken worden. Als je gaat outsourcen word je nog meer met de neus op de feiten gedrukt dan in het verleden. Je moet namelijk richting die insourcer een nieuwe opdracht formuleren, die moet door ons beschreven worden. Maar heel vaak wordt daarbij vergeten de technische architect te betrekken, dus komt de leverancier na bijvoorbeeld de calculatie terug met een voorstel en pas dan beseft men dat ook de architecten er nog even naar moeten kijken. Dan kan blijken dat het niet binnen de current state past of dat er een andere reden is waarom het gewenste gewoon niet kan. En dan krijgen we rework, want het gaat weer terug naar de leverancier, die past het weer aan. Had men nou maar die technische architect aan het begin van het traject om een mening gevraagd, dan waren we misschien een stuk sneller geweest.”

Daan: “Wat je zegt is dat je een businessarchitect hebt van ABN Amro en om te weten of die een maakbaar verzoek indient, leg je het voor aan een technische architect van binnen de bank. En je hebt een technische architect bij de leverancier zitten met wie ook overeenstemming moet worden bereikt. Want de een zegt dat het maakbaar is, maar de ander moet het bouwen.”

Rob: “Dus de architect van de leverancier moet dus tijdens het maken van het voorstel weten wat in de ogen van onze technische architecten mogelijk is, want re-work is het meest dodelijke wat je kunt hebben.”

Paul: “De businessarchitecten schakelen dus te vroeg.”

Daan: “En de eigen technische architecten blijven ten dele verantwoordelijk en krijgen dus op hun kop als het fout gaat.”

Rob: “Dat is inderdaad wat er zo ongeveer gebeurt, dus daar ligt een knoeperd van een uitdaging.”

Paul: “Ik probeer te traceren waarom het proces dan zo loopt.”

Rob: “Het hoort niet zo te lopen, maar het gebeurt omdat de businessarchitecten veelal niet weten wat ze met die techneuten aan moeten. In de bouwwereld weet de architect dat als het beton na een tijdje begint door te zakken, hij niet de constructeur de schuld kan geven. Hijzelf is bij wet verantwoordelijk. Wanneer onze businessarchitecten een dergelijke verantwoordelijkheid zouden hebben, dan zouden ze veel eerder zo’n technische man erbij vragen. Bij ABN Amro was het zo dat er, en zo noemden we dat letterlijk, een building permit moest worden afgegeven. Vergelijkbaar met de bouwvergunning in de echte wereld, en die kan alleen maar afgegeven worden als alle benodigde berekeningen gedaan zijn.”

Daan: “Eén van mijn uitspraken is: we hebben een groot gebrek aan architecten, maar een nog veel groter gebrek aan echte engineers. Want als je een SOA-plaatje kunt tekenen, dan ben je nog geen echte engineer. Een applicatie moet een goede performance hebben, moet robuust in elkaar zitten, moet eenvoudig onderhoudbaar zijn. Mensen die dat kunnen zijn nog sporadischer dan architecten die kunnen luisteren naar de business.”

Rob: “Zie daar wederom het probleem met de opleidingen in Nederland.”

Irritant strikt

Rob: “Om nog even terug te komen op die building permits: dat werkt dus alleen maar wanneer je irritant strikt bent. Letterlijk irritant strikt. Dus waar kom je nu op het punt dat je zegt: ‘hè, goed dat die architecten er zijn’.”

Paul: “Je kunt ze toch gewoon overrulen?”

Rob: “We hadden in die tijd zes, zeven domeinarchitecten, die allemaal verantwoordelijk waren voor hun respectievelijke businessdomein. Met mijn technische en procedurele eisen was het een enorme uitdaging voor mij om op een lijn te komen met de domeinarchitecten,. Want het moet uitvoerbaar en bovenal betaalbaar blijven. Dus waar is nu het moment dat we allemaal tevreden zijn?”

Daan: “Veel architecten zijn muggenzifters die een andere mentaliteit moeten krijgen, zodat ze beter gaan samenwerken.”

Rob: “Ja, maar dan wordt het probleem benaderd vanaf de andere kant, terwijl de kloof tussen beide typen blijft. We zijn waarschijnlijk gedoemd om dit soort discussies over architecten te blijven hebben.”

Cultuur

Daan: “In hoeverre is er in outsourcing-situaties sprake van culturele verschillen. Passen de providers en hun oplossingen altijd wel bij jullie organisatie? Is het niet denkbaar dat je twee totaal verschillende architectuurstijlen krijgt?”

Rob: “Dat probleem speelt niet echt, omdat de leveranciers niet over onze architectuur gaan. De development-kant moet, wanneer het ontwerp op de mat ploft, gewoon gaan bouwen en er verder niet teveel over nadenken. Neemt niet weg dat, wanneer het verzoek komt voor de bouw van bijvoorbeeld een nieuwe kas-applicatie, ze het wel moeten melden wanneer ze al eens eerder zoiets hebben gebouwd en ze deze applicatie dus nog een keer kunnen gebruiken. Daaraan hebben we binnen het ADM-contract te weinig aandacht besteed, maar we vragen er wel om. Maar de businessarchitectuur an sich is van ons. We hebben de architectuur dan ook niet uitbesteed. Onze infra-architectuur is bijvoorbeeld een vertaalslag naar de producten toe. Zou de leverancier dat doen, dan zou je een enorm risico lopen.”

Daan: “Tenzij je tegen je eigen architecten zegt: eens in de zoveel tijd doe je een architectuuraudit over wat de leverancier gedaan heeft.”

Rob: “En dan kom je aan het einde van het jaar 137 onderwerpen tegen waarvan je zegt dat er iets niet goed aan is. Achteraf, dus wanneer het kwaad al is geschied. Omdat je zelf weet waar je gevaar zou kunnen lopen, doe je alles zelf en bovendien vooraf.”

Daan: “Letten jullie op de architectuur van toeleveranciers, van bijvoorbeeld BPO-dochtermaatschappijen?”

Rob: “Nee, wij moeten dat ook niet willen. Als zij gaan toestaan dat onze architecten gaan meekijken naar hun producten, dan verliezen ze wellicht hun schaal- en prijsvoordeel. Zij hebben een architectuur voor een bepaald product of proces. Wanneer ze dat gaan aanpassen, gaan ze het in financieel opzicht verliezen. Daarmee kom je op de kern van outsourcing en offshoring: ergens kom je op de grens waarbij de leverancier zegt dat ie het niet meer gaat doen.”

Daan: “Anders wordt het maatwerk en driemaal zo duur?”

Rob: “Ja en dat is, nogmaals, de moeilijkheid. Moet je je architecten dus binnen houden of moet je de rol bij de leverancier neerleggen? Want in het verlengde hiervan: het zou mij niets mogen uitmaken hoe de leveranciers zijn monitoring doet, zolang dat hij het maar doet.”

Daan: “Hoe zie jij de rol van outsourcing-mediators als TPI, Quint Wellington Redwood en EquaTerra? En dienen zij architectuurkennis aan te dragen?”

Rob: “Moeilijk, omdat ze vaak niet het geheel overzien. Ze hebben templates, een aanpak en een werkwijze, daarmee nemen ze je van a tot z bij de hand. Dat helpt je om alles op een rij te krijgen, maar ze zijn niet in staat om de consequenties te overzien om een totale keten van activiteiten te outsourcen. Ze weten bijvoorbeeld nog onvoldoende hoe je moet omgaan met intellectual property in geval van ontbinding van het contract. Of ze geven te weinig input aan het vervolg in een contractrelatie. Stel dat je uiteindelijk de juiste leverancier hebt gekozen. En dan? Hoe vlieg je de volgende stap aan? Wanneer je je contract klaar hebt, hoe doe je de transitie dan? Er valt binnen de RfP-fase een ‘price drop’, je hoort hem bij wijze van spreken vallen. En dan?”

Productarchitectuur

Daan: “Een volledig andere vraag. We hebben verschillende verzekeringsmaatschappijen gesproken en die hechten een enorme waarde aan hun productarchitectuur. Ze willen heel snel nieuwe producten in de markt kunnen zetten waarmee ze de concurrentie te slim af willen zijn. Wat is het belangrijkste voor banken? Is er ook zoiets als een productarchitectuur?”

Rob: “Voor verzekeringsmaatschappijen is time-to-market met nieuwe producten net zo belangrijk dan voor een traditionele bank. Bij banken gaat het bij productinnovaties of -aanpassingen vooral om variaties op een bestaand thema (sparen en lenen), voor de systemen heeft dit nauwelijks gevolg.”

Governance

Paul: “Over de governance, wie geeft er uiteindelijk toestemming dat er gebouwd kan worden?”

Rob: “De business, want die betaalt. We maken wel het onderscheid tussen applicatieontwikkeling en de bijbehorende infrastructurele consequentie. Die laatste opdracht gaat naar de insourcer. Uiteindelijk komen die twee terug met een quote; een oplossing, prijs en planning. Daar zeggen wij vervolgens vanuit het technische perspectief na een toets ‘ja’ op. De quote wordt de input voor de businesscase die de business dus gaat maken.”

Paul: “De business is dus opdrachtgever en jouw organisatie houdt de regie in handen.”

Rob: “Absoluut. Bovendien ligt er bij ons een bepaalde verantwoordelijkheid, want als bij wijze van analogie een voorgestelde latei, waar een hele muur bovenop komt, te dun is, dan moeten wij waarschuwen dat het raam zou kunnen doorzakken.”

Paul: “Je tekent dus dat je het ermee eens bent.”

Rob: “De rol van de architect zit ‘m in het aftekenen van het voorstel van de leverancier, of zoals wij zeggen: het technical solution document. Daarbij wordt dus ook gekeken naar de prijs, het aantal uren dat men aan iets denkt te moeten werken, de total cost of ownership, enzovoorts. Er ligt dus best een groot deel van de verantwoordelijkheid bij de technische architecten. Het voordeel is dat onze eigen architecten samen met de architecten van een leverancier naar een oplossing kijken, waarna het weer bij onze technische architecten terug komt. Dus daar zit wel een check & balance in.”

Daan: “De businessarchitecten zitten in de business en de technische architecten bij jou?”

Rob: “Ja. De constructeur zit namelijk ook niet bij de architect, die hebben allebei hun eigen verantwoordelijkheid. Er heeft er evenwel één de ultieme verantwoordelijkheid en in mijn ogen moet dat de businessarchitect zijn.”

Paul: “Maar jouw architecten hebben de verantwoordelijkheid om de constructeur te auditen.”

Rob: “Zeker, ze kijken of het past binnen het totale landschap, maar bij wijze van spreken met oog op bijvoorbeeld de veiligheid ook met de ogen van de brandweer. We kijken of het past binnen de voorschriften.”

Paul: “De businessarchitect heeft een business executive als opdrachtgever en de technische architect heeft jou als opdrachtgever?”

Rob: “Nee, die laatste heeft de businessarchitect als opdrachtgever, maar rapporteert in hiërarchische zin aan mij.”

Paul: “Leeft de businessarchitectuur bij de business executives, zoals de IT-architectuur leeft bij jullie?”

Rob: “Ik denk minder. Het gaat binnen de business meer om de (vernieuwde of nieuwe) functionaliteit. Er is wel een tijd geweest dat de business zei: ik wil deze functionaliteit, doe maar product ‘x’ en ik wil wel mijn eigen server. Dat hebben we, door het laten maken van businesscases, wel enigszins weten terug te dringen.”

Paul: “Architectuur gaat om de samenhang binnen het totale landschap. Dat geldt ook in de business. De businessarchitect moet op een gegeven moment een gesprekspartner zijn voor zijn opdrachtgever en vertellen hoe een gewenste functionaliteit in het totale landschap past.”

Rob: “Daar praten de businessarchitecten wel over, maar ik heb niet het idee dat ze samen met de businessopdrachtgevers naar architectuurplaatjes zitten te kijken. Dat geloof ik niet. Je ziet wel de verwevenheid tussen de bedrijven. Vroeger had je een spaarbedrijf, een leenbedrijf en de operationsfabriek en daarvan waren met name de eerste twee volledig gescheiden. Het is pas gaan integreren toen men riep dat je als bank je klanten moest kennen. Want stel dat deze eerst alleen leende en vervolgens ging sparen, dan kon het in principe gebeuren dat de klant opnieuw geregistreerd moest worden. Dat is raar. Door het samenvoegen van de klantenbestanden is uiteindelijk de complexiteit ontstaan. Daardoor kun je de risico’s die gekoppeld zijn aan een persoon niet alleen afleiden uit wat deze leent, maar ook wat deze aan spaartegoeden heeft staan.”

Boodschap

Daan: “Wat zou jij je collega-CIO’s aanraden als het gaat om de inzet van architecten in een outsourcing-context?”

Rob: “De architecten zitten in de outsourcingcontext op drie gebieden. Ten eerste bij het vaststellen van de baseline: de huidige kosten, producten en architectuur. Je stelt dus vast wat je hebt en dat neem je mee tijdens de RfP. Vervolgens beoordeel je wat er vanaf de insourcers terugkomt, de technical solution. Daar speelt de architect zogezegd absoluut een rol in. Daarna komt het maken van voorstellen voor het tranformation schedule, ook daarover moet de architect een oordeel hebben. Onder meer over de vraag of wij, indien we ingaan op het voorstel, de technologie ooit nog kunnen verplaatsen.”

Paul: “Wat zou je architecten willen meegeven?”

Rob: “Dat ze een onderdeel zijn van de keten, wat betekent dat ze een taal moeten gaan praten die begrijpbaar is voor alle partijen. Verder denk ik dat de digitale architecten zich moeten ontwikkelen zoals de architecten in de bouwwereld dat hebben gedaan, dus ook een eigen beroepscode moeten definiëren, met de bijbehorende verantwoordelijkheden. Ze moeten afdalen vanuit de ivoren toren waarin ze zichzelf nog steeds hebben opgesloten. Dat doen ze niet, ze worden er helaas ook niet voor opgeleid.”

Daan: “Je bedoelt dat ze zelfs voor de rechtbank gesleept moeten kunnen worden?”

Rob: “Ja. Zoals ik ook mijn aannemer voor de rechter sleep als het dak van mijn huis instort. Zo’n code of conduct bestaat namelijk niet voor architecten en daarmee, door het nemen van die verantwoordelijkheid, zouden ze zichzelf veel meer een plaats kunnen geven. Ze moeten niet alleen ‘nee’, maar ook ‘ja’ kunnen zeggen.”

Paul: “Welke boodschap heb je voor je collega-CIO’s?”

Rob: “Dat ze architecten in dienst nemen die voldoen aan de voorwaarden die ik zojuist gesteld heb.”

 

[PDF]

Opmerking

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

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

22-01: Quantum Computing - KNVI meer...

31-01: Smart Data Practices - PLDN meer...

19-02: ERP software - KNVI meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden