De CIO spreekt: Hans Wanders, CIO Randstad Holding

Hotze Zijlstra, Daan Rijsenbrij en Paul Laagland, zondag 14 september 2008

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.

Hans Wanders, CIO van Randstad Holding, vindt architectuur heel belangrijk. Toch gebruikt hij het woord zelden en is er niemand binnen zijn organisatie die de functie ‘architect’ op zijn visitekaartje heeft staan. Die begrippen zijn wat hem betreft een beetje ongelukkig gekozen. Als er dan toch een vergelijking met de fysieke wereld gemaakt moet worden, dan kiest hij voor het bestemmingsplan.

Daan: “Laat ik even een aftrap geven: digitale architectuur is wat mij betreft volledig congruent met de fysieke architectuur. Ik hoor mensen wel eens zeggen dat het niet klopt, maar dat zijn dan meestal software-architecten of beter: software-engineers. In de fysieke wereld gaat het erom dat je een ruimte ontwerpt waarin je kunt functioneren en waarin je je prettig voelt. In de digitale wereld is het eigenlijk precies hetzelfde; het gaat erom dat je een ruimte ontwerpt waarin je kunt werken op een efficiënte, effectieve manier en hopelijk ook nog met een forse dosis arbeidsvreugde.”
In de fysieke wereld is het normaal dat, wanneer je met een architect spreekt en je eisen stelt, hij terug komt met een serie plaatjes. Daan: “In de digitale wereld komt de architect meestal terug met 150 pagina’s tekst en wat cryptische technische schema’s Dat roept al snel de vraag op: wat krijg ik nou eigenlijk? Kun je me eens iets laten zíen wat ik begrijp? Maar nee. Bij in de IT wordt alles in tekst uitgeschreven of in tools gegoten.”
Hans: “Met sommige dingen die je zegt ben ik het oneens, maar wat je bijvoorbeeld zegt over die 150 kantjes tekst is mij uit het hart gegrepen. Maar de vergelijking tussen wat ik digitale architectuur vind en de architectenrol in de bouwwereld, is wat mij betreft een foute. Ik denk dat je digitale architectuur beter kunt vergelijken met een bestemmingsplan.”
De CIO pakt een stuk papier en begint te tekenen: “Je begint daarbij misschien met een paar weilanden waarop je in de komende tien jaar wat wilt gaan bouwen. Dan komt hier een grote weg, hier nog wat kleinere wegen en hier woningen - zo veel sociaal, zo veel vrijstaand, zo veel geschakeld. Hier komt een winkelcentrum met bepaalde functies en een zekere capaciteit. En dit wordt een bedrijvenpark. Hoewel ik nog nooit een echt bestemmingsplan heb ingezien, kan ik me voorstellen dat er nog wel meer in staat. Bijvoorbeeld dat huizen een maximale hoogte mogen hebben en een bepaald aantal meter van de weg moeten staan. Dit alles schept een kader hoe die wijk langzaam uit de grond kan verrijzen. Vorm en functie worden vastgelegd, nog voordat er één huis getekend is.”

Niveaus


Daan: “Je hebt een stad die je gaat ontwerpen en die bestaat uit een aantal domeinen: een industriegebied, een ziekenhuisgebied en een woongebied. En binnen die domeinen worden gebouwen neergezet. Je hebt dus drie niveaus: de stad, de domeinen en de gebouwen. Als het gaat om de digitale architectuur heb je de onderneming, de domeinen en de informatiesystemen.”
Hans: “Precies! Mijn stelling is dat een bestemmingsplan als zodanig de beste vergelijking is die ik tot nu toe in de fysieke wereld heb kunnen vinden met wat ik digitale architectuur vind.  Om die reden vind ik de term digitale ‘architectuur’ ongelukkig gekozen, zeker als het gaat om wat men vaak aanduidt met ‘enterprise architecture. De eisen die worden gesteld aan bijvoorbeeld de huizen, zijn wat mij betreft de architectuur in de betekenis van bestemmingsplan alweer bijna voorbij.”
Daan: “Maar de architect van Lanzarote (César Manrique, red.) heeft ooit gesteld dat er op het eiland niet hoger gebouwd mag worden dan drie verdiepingen, omdat hij niet wilde dat gebouwen de horizon zouden vervuilen. Dat betekent dat je, ongeacht de creatieve invulling, je aan deze regels en richtlijnen moet houden.”
Paul: “Wat is jouw visie op digitale architectuur, Hans? En wat doe je daarmee binnen Randstad?”
Hans: “Voor mij is architectuur een set van regels - geboden en verboden - die beperkingen opleggen en richting geven aan hoe je systemen en applicaties vormgeeft. Het is een set van regels, die in een paar A4’tjes of in een presentatie van een uur aan de goegemeente uitgelegd kan worden en in de genen van de IT-afdeling zit. Deze regels hebben bovendien een lange levensduur, langer dan de onderliggende systemen zelf. Ze veranderen wel, want de architectuur leeft en is dus zeker niet statisch. Maar er zit wel heel veel balans in.”
Daan: “De digitale architectuur verandert sneller dan die in de fysieke wereld, doordat er telkens nieuwe technologieën opkomen die nieuwe zaken mogelijk maken.”
Hans: “Eens, de de digitale wereld gaat duidelijk sneller. Als je een wijk neerzet, dan staat die daar voor minstens 25 jaar, misschien wel 150. En je hebt gelijk: er zijn geen IT-architecturen van vijftig jaar en ouder.”

Brokken


Paul: “Wat is het doel van de digitale architectuur?”
Hans: “Het doel is het geheel van systemen hanteerbaar en beheersbaar te houden, meestal door het op te delen in brokken met duidelijke regels over wat er gebeurt in de grensvlakken. Hierdoor creëer je meer snelheid en creativiteit, doordat meerdere teams onafhankelijk van elkaar aan de verschillende brokken kunnen werken. Je kunt taken namelijk beter verdelen, hergebruik wordt mogelijk, enzovoorts. Maar soms doet het een beetje pijn, dan knelt het.”
Paul: “Bij wie doet het pijn?”
Hans: “Als het goed is doet het pijn bij de ontwikkelaars, niet bij de eindgebruikers. Architectuur moet trouwens ook niet te zeer knellen, het moet wel een enabler zijn van oplossingen. Je hebt bijvoorbeeld architecturen waarvan je zegt ‘mooi, knap bedacht, maar je kan er helemaal niks mee’.”
Paul: “Wat is de relatie tussen architectuur en de bedrijfsstrategie?”
Hans: “Als hij daarmee harmonieert is het goed. En als hij in een isolement in eigenwijsheid en schoonheid is bedacht, dan is het niet goed. In die zin houd je altijd goede en slechte architecturen.”
Paul: “En wie beoordeelt dat uiteindelijk?”
Hans: “De toekomst.”
Daan: “Is het ook een afspiegeling van de bedrijfscultuur?”
Hans: “Uiteindelijk wel. Wat ook belangrijk is: een goede architectuur valt zowel qua acceptatie als in technisch opzicht niet om vanwege een paar uitzonderingen. Als je ergens een geweldige commerciële kans krijgt, dan moet daarop ingespeeld kunnen worden. Het zal iedereen bovendien duidelijk zijn dat het ècht om een uitzondering gaat, zodat niet meteen het hek van de dam is.”

Eigenaar


Daan: “Wie is de eigenaar?”
Hans: “De eigenaar van wat ik digitale architectuur noem is het IT-management.”
Daan: “Heb je het dan alleen over de infrastructuur en het applicatielandschap. Of heb je het dan ook over het informatieverkeer en de digitale producten en diensten?”
Hans: “Qua definitie heb ik eigenlijk nog niet meer gezegd dan dat digitale architectuur een set van regels is, die bepaalt hoe je systemen in de toekomst vormgeeft. Het woord architectuur gebruik ik zelden binnen Randstad, dus ik heb ook geen heel sterke meningen over wat wel en niet architectuur is. IT is overigens de enige discipline die de term architectuur gebruikt. Andere disciplines hebben het over de organisatiestructuur, de administratieve inrichting, het strategisch plan of de juridische structuur. Elke discipline heeft z’n eigen woord om z’n topstructuur aan te duiden. De echte digitale architect overziet deze domeinen er zorgt ervoor, dat die met elkaar ‘in sync’ zijn.”
Paul: “Heb je echte architecten in huis? Zijn het mensen die het in hun rol erbij pakken. Of is er een externe architect die je erbij helpt?”
Hans: “De hoofdarchitect ben ik. Het is de CIO en op landniveau de IT-manager: híj is aanjager en beslisser. Verder is architectuur een taak van de IT-lijn. De functie van architectuur is geen dagtaak, je mag hopen dat een architect ook nog een project kan leiden of andere taken kan uitvoeren. Ik geloof dus niet in het beroep van digitaal architect binnen een bedrijf als Randstad. Laat ik het anders zeggen: Randstad is een HR-bedrijf, het helpen ontwikkelen van mensen en het coachen staan hoog in ons vaandel. Maar we hebben hier niemand met de functie van ‘coach’. Je begrijpt wel waar ik naartoe wil: ik vind het bedrijven van digitale architectuur vreselijk belangrijk voor een organisatie. Er zijn meerdere wijzen om vorm te geven dat het gebeurt, dat het goed gebeurt en dat het gecommuniceerd wordt. Ik denk alleen dat er meerdere modellen zijn om dat te doen. Het is een beetje primitief om te stellen: we hebben het onderwerp architectuur, het is belangrijk en dus moet er een architect zijn.”
Bij Randstad is er zogezegd niemand met de titel architectuur op zijn kaartje. Hans: “Echte architectuurbeslissingen zijn business-beslissingen. Waar ik in geloof is het beroep van digitaal architecturaal consultant. Op het moment dat je een architectuur tekent, maak je businesskeuzes. De juiste vragen zijn daarbij nog belangrijker dan het geven van antwoorden. Als je de goede vragen stelt, de juiste vragen en de volledige set vragen, dan heb je al tachtig procent van het probleem opgelost. Maar bij de antwoorden kan de architect je niet helpen. Je hebt geen architect nodig om te beoordelen of nieuwe ontwerpen binnen de architectuurkaders blijven. Dat kan de IT-manager, als eigenaar van deze architectuur, over het algemeen zelf wel beoordelen.”
Daan: “Toch geloof ik in één lead-architect, één kapitein op het schip. Die krijgt ook op zijn sodemieter als het fout gaat.”
Hans: “Er moet er één de baas zijn, dat ben ik met je eens. Die moet alleen wel dicht tegen de macht aan zitten in de IT-organisatie Daaronder is elke IT-manager verantwoordelijk voor zijn eigen architectuur. Hij kan zich daarbij laten helpen door iemand die ik best een architect zou willen noemen.”

Land voor land


Randstad doet zijn IT grotendeels land voor land. Hans: “Of werkmaatschappij voor werkmaatschappij. Er zijn dingen die we samen doen en er zijn regels, bijvoorbeeld dat alle werkmaatschappijen eens per maand bestanden met informatie over internationale klanten sturen naar één centraal datawarehouse. En dat iedereen zijn eigen e-mailsysteem heeft, maar één gezamenlijk adressenboek. Zo zijn er nog een paar dingen, maar verder ben ik gauw uitgesproken. Ik heb het ook nooit architectuur genoemd, het is het strikt genomen wel, volgens de regels die ik net aanhaalde, maar het is niet een heel erg interessante architectuur. Het is redelijk eendimensionaal, het past echt op een A4’tje, zelfs de uitleg.”
Hans Wanders praat, wanneer het gaat om de architectuur, het liefst over Nederland. Niet in de laatste plaats omdat hij de situatie hier, met 7000 medewerkers en 800 vestigingen goed kent. Het is de architectuur, waar hij vanuit zijn voormalige tweede functie directeur van Randstads eigen IT-dienstverlener I-bridge ook zelf verantwoordelijk voor was. De architectuur van Randstad in Nederland is als zodanig bovendien complexer dan die van de totale holding.
Hans: “Nederland is na Frankrijk het grootste land. Alle werkmaatschappijen maken gebruik van één shared services center, één netwerk en de vestigingen van die werkmaatschappijen gebruiken één instance van dezelfde applicatie. Wel zijn er totaal gescheiden kandidaat- en klantendatabases, want het zijn bedrijven die echt concurreren. Maar we slagen er toch in om dezelfde applicaties en systemen te gebruiken.”
Paul: “Om tot één systeem te komen zijn architectuurbeleid en -uitspraken toch noodzakelijke voorwaarden?”
Hans: “Ja, maar ik heb dat destijds nooit als architectuur bestempeld. Wij hebben hier gewoon een besluit genomen om gezamenlijk een applicatie te ontwikkelen. De vorige applicatie was overigens ook al dezelfde voor Tempo Team en Randstad. Yacht had toen nog een ander systeem, maar zit nu ook op hetzelfde systeem. De oude applicatie was technisch en qua structuur zo verouderd omdat het een database per vestiging had Inmiddels hebben we een zeer gecentraliseerde infrastructuur, die wordt bestuurd en verder ontwikkeld door een set regels.”
Randstad heeft in Nederland één grote centrale applicatie, die Mondriaan heet. Hans: “Met het Blauw van Randstad, het rood van Tempo Team, het geel van Capac en het zwart van Yacht. En een heldere lijn. De applicatie was gebaseerd op niet de allermodernste Oracle-technologie. Vorig jaar hebben we daar een update op gedaan. Ook heb ik, toen nog als directeur van I-bridge, samen met mijn team en ondersteund door een externe architect, een nieuw architectuur-raamwerk gemaakt voor de toekomst. Dat hebben we toen Metropool genoemd, ik realiseer me nu dat dit mooi aansluit op mijn idee van architectuur als stadsplanning.”

Benefits


Paul: “Hoe weet je of je architectuur goed is? Dat wil zeggen dat deze beantwoordt aan de wensen van de business?”
Hans: “Een architectuur kan inderdaad goed zijn of niet. Maar zelfs de benefits van een goede architectuur zijn heel ongrijpbaar. Een architectuur kan goed gedocumenteerd zijn, technisch heel knap, in de genen zitten van mensen en toch de business niet bieden wat ze nodig hebben. Zo’n architectuur kan flexibiliteit bieden op punten waar de business het niet nodig heeft en star zijn daar waar de business flexibiliteit nodig heeft. Zelfs wanneer je twee volledig uitgewerkte IT-architecturen naast elkaar zet, is het nog ontzettend moeilijk om te bepalen welke het beste is voor het bedrijf.”
Daan: “Flexibiliteit in alle richtingen kan niet, dat kost een oneindige hoeveelheid geld. Je kunt wel ‘what if’-analyses doen om bij keuze te kijken wat het beste werkt voor het bedrijf.”
Hans: “Het is heel moeilijk, maar je komt er uiteindelijk wel uit.”
Paul: “Hoe regel je dat die discussie goed gevoerd wordt en de business zich uiteindelijk in de architectuur kan vinden? Zodat ook iedereen begrijpt waarom je bepaalde dingen wel of niet doet.”
Hans: “Dat is heel moeilijk. Architectuur is een heel ambachtelijk vak, daar moet je gevoel voor krijgen. Het is ook een kwestie van openheid en de andere belanghebbenden laten meedenken. Iedereen die zegt dat hij een businesscase maakt en daar vervolgens een architectuur op baseert, die jokt. Je kunt wel wat sommetjes maken en je ideeën over bepaalde zaken zoveel mogelijk proberen te kwantificeren, maar er is geen businesscase voor digitale architectuur. Dat suggereert namelijk dat er kosten en opbrengsten aan verbonden zijn. Stel je voor dat ik  een dag nadenk over architectuur en vervolgens die uren moet verantwoorden... Het moet toch niet gekker worden. Je overlegt gewoon met collega’s uit de business, maakt een afweging en je bepaalt of je het wel of niet doet. En dan doe je het gewoon - niet omdat er een businesscase is, maar omdat je vindt dat het zo moet. Architectuur is bij ons in die zin een onderwerp dat regelmatig op de agenda van het IT-management staat.”
Daan: “Een belangrijk architectuur-issue is misschien wel hoe je grote klanten vanuit de IT zo kan ondersteunen dat de intercedent er misschien wel tussenuit kan. Dat je onderliggende software hebt die de match kan doen tussen vraag en aanbod.”
Hans: “Er is inderdaad een ontwikkeling: de slag om de klant en de slag om de kandidaat worden door internet en andere ontwikkelingen binnen de IT steeds belangrijker. Het koppelen met externe klanten is een belangrijk en ingewikkeld architectuurvraagstuk. Toch geloven wij dat matchen mensenwerk is, maar dan wel ondersteund door de computer die long- en shortlists maakt. Maar uiteindelijk gaat het ook om gevoel.”

Due-dilligence


Paul: “Je hebt net een fusie achter de rug. Wat was de rol van architectuur hierbij?”
Daan: “Is de architectuur en de rol van de IT bijvoorbeeld meegewogen bij de due-dilligence?”
Hans: “Ja, en we waren er snel mee klaar. We lazen in het jaarverslag dat de IT bij Vedior veelal niet per land, maar per werkmaatschappij werd gedaan. Dus geen centrale systemen. Op basis van de wet van de grote aantallen mocht je concluderen dat de risico’s beperkt en geïsoleerd zouden zijn. Idealiter zou je wel nog een blik hebben geworpen op de systemen van een paar grote werkmaatschappijen, maar daar was op dit moment geen mogelijkheid toe.  Dus met de due-dilligence waren we snel klaar.”
Nadat de fusie een feit was besloot Randstad om in de meeste landen de uitzendbedrijven te integrereren.  In het professionele segment doet men voorlopig nog even niets. Hans: “Aan mij de taak om richtlijnen te geven voor de integratie van de systemen van de uitzendbedrijven in de diverse landen. Ik heb dat weer op één A4’tje gedaan. Ik heb gezegd dat ze alleen moeten nadenken over het samenvoegen van IT-systemen als je ook daadwerkelijk van plan bent de businesses te integreren. En als je de businesses samenvoegt, kies dan van kop tot staart voor de systemen van één van de partners. Wee je gebeente als je gaat mixen en matchen: dat is een recept voor ellende! Punt drie: doe het snel. Dit beleid is in acht van de tien landen zo uitgevoerd. Daar had we geen architect voor nodig, alleen ons gezonde verstand.”
Daan: “Je zou ondanks de decentrale structuur op een hoger niveau wel van dezelfde bouwblokken gebruik kunnen maken en op deze manier kunnen profiteren van de schaalgrootte.”
Hans: “Standaardcomponenten zijn daarvan een vorm.  Maar door de grote lokale diversiteit, op allerlei niveaus en de complexiteit van de interfaces vallen de voordelen heel erg tegen. Daar hebben we internationaal geen goede ervaringen mee. Ik denk dat het standaardiseren van ideeën en functionele ontwerpen veel belangrijker is dan het vastleggen van die ideeën in standaard software.”
Randstad werkt nu aan de de ontwikkeling van een nieuw internet-concept, vooral gericht op het werven van kandidaten. Hans: “Een ‘bricks en clicks’-ontwerp. De processtroom, de navigatie en de look & feel zijn tot de laatste pixel als standaard ontworpen. De landen-organisaties hebben we een keuze gegeven. Ze kunnen gebruik maken van een centraal ontwikkelde component, of ze kunnen het ontwerp inbouwen in hun eigen systeem. Het is in mijn ogen een aardig voorbeeld van een ontwerp waarin business, marketing, componenten en architectuur verweven zitten.”

Nabrander


Daags na het interview stuurt Hans Wanders via de e-mail nog een aanvulling op de begrippen ‘architectuur’ en ‘architect’ en hoe deze binnen Randstad worden gebruikt. Als CIO hoort hij in zijn omgeving de volgende betekenissen van het begrip architectuur:
1. Een meerjarig kader c.q. bestemmingsplan voor het totale systeemlandschap van een bedrijf (of tenminste een zeer significant deel van dat landschap). Dit kader geeft richting aan en/of legt beperkingen op aan de wijze waarop nu en in de toekomst nieuwe applicaties en systemen kunnen worden ingepast en bestaande applicaties en systemen kunnen worden gewijzigd. Dit is ongeveer de betekenis van het buzzword ‘enterprise architectuur’.
2. Een ontwerp op hoog niveau voor het realiseren van een nieuwe (categorie) functies of oplossen van een nieuwe (categorie) problemen. Dit ontwerp bestrijkt vaker meerdere applicaties, systemen en technologieën, hetwelk een extra complexiteit aan het ontwerp meegeeft. Vaak bestaat de noodzaak dit ontwerp in eerste instantie op een hoog abstractieniveau uit te werken.
Hans: “Ik heb zelf de neiging deze twee betekenissen uit elkaar te houden. Maar soms vraag ik me wel eens af deze twee betekenissen in de praktijk niet in elkaar overlopen en of het theoretisch wel mogelijk is om dit onderscheid aan te brengen. Gevoelsmatig zeg ik dat architecturen van type-2 vaak echte ontwerpen zijn, in de zin dat ze daadwerkelijk gerealiseerd kunnen worden en dat architecturen van type-1 alleen een kader geven, waarbinnen de echte ontwerpen nog gemaakt moeten worden.”
Daan (ook via de e-mail): “Het begrip architectuur heeft nog vele en vaak zeer uiteenlopende betekenissen. Dat komt doordat de discipline relatief jong is en het hype-gehalte (te) hoog. Vaak is de scheidslijn tussen architectuur en ontwerp vaag. Architectuur is voor mij evenwel een coherente, consistente verzameling architectuurprincipes, die de ontwerpruimte inperken. Deze inperking heeft voor mij twee hoofddoeleinden: complexiteitsreductie en toekomstvastheid. Het coherente is nodig voor de samenhang.”

Architect


Over de aanduiding ‘architect’ schrijft Hans Wanders: “Hiermee wordt bij ons meestal aangeduid: a. iemand die architecturen maakt van type-2. Dus ontwerpen van een hoog abstractie-niveau met impact op meerdere applicaties, systemen en technologieën. En b. een zeer ervaren seniore IT’er, met statuur, met grote kennis op een breed terrein en een diep begrip van hoe technologieën en hun toepassingen en de gebruikers op elkaar inwerken. Het woord ‘architect’  wordt hier dus eerder als aanduiding van een niveau en/of rang gebruikt, dan als aanduiding van een functie. Voor mijn gevoel zijn dus de begrippen architect en architectuur niet één-op-één gekoppeld, in de zin dat de architect per definitie degene is die de architectuur bedenkt.”
Daan mailt terug: “Jouw constatering dat de begrippen niet een op een zijn gekoppeld, onderschrijf ik volledig. De chief-architect stelt de architectuur voor de onderneming vast. De lead-architect voor een veranderprogramma bepaalt welke gedeelte van die architectuur relevant is voor de onderhavige verandering en is tevens de baas over het ontwerp. Belangrijk vind ik dat de architect de regisseur van het beeldvormingsproces is: hoe gaat, althans het digitale gedeelte, van de nieuwe situatie eruit zien. Daarom staat de architect aan de kant van de klant. Architecten die op de loonlijst van de bouwer of het softwarehuis staan noem ik liever architectuurdeskundigen, die de architectuur kunnen begrijpen en de realisatieconsequenties kunnen doorzien.”
Hans: “Binnen Randstad gebruikt men het begrip architect in beide betekenissen (a. en b.) en in die zin lopen er wel de nodige ‘architecten’ rond. Voor architectuur in de eerste betekenis (die van het IT-bestemmingsplan) geldt dat we niet één architect of architectenteam hebben die deze architectuur maken en ontwikkelen. Het IT-bestemmingsplan is eigendom van het IT-management zelf. Dat wil zeggen: internationaal de CIO, lokaal de IT-manager. De architecten spelen uiteraard wel een belangrijke rol in de discussie.”

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/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