Architecten kunnen zich volgens René Steenvoorden nogal eens verliezen in discussies over definities of het schijnbaar nodeloos categoriseren van functionaliteitseisen. "Ze zijn soms supereigenwijs", oordeelt de voormalige Essent-CIO, die inmiddels is overgestapt naar de Rabobank. En bovendien: "Elke IT'er die je extra bij de discussie zet, brengt je één niveau dieper in de details. Bij architecten werkt dat kwadratisch."

Voor René Steenvoorden is architectuur het beste te typeren als een landkaart. "Daarmee schets je hoe de business beweegt en welk effect dat heeft op processen, informatiestromen, applicaties en infrastructuur. Zoals de kaart van een stad, waarop je aangeeft waar de industrie zit, waar de woongebieden zijn, een eventuele rivier, vervuilde grond en de samenhang tussen deze dingen. Architectuur is een manier om de wereld te schetsen, te leiden en richting te geven."
Hoe de architectuur er in het IT-vakgebied uit ziet, hangt volgens de CIO af van de doelgroep en de levensfase of processtap waarin je je als organisatie bevindt. "Het topmanagement heeft bijvoorbeeld een groter abstractieplaatje nodig dan een dagelijkse opdrachtgever. Maar alles wat je dagelijks binnen IT doet, is in principe door architectuur gedreven. Architectuur is de leidraad in ons dagelijkse handelen."
Hoe ver het werk van de architect reikt, welke verantwoordelijkheden daarbij horen en hoe deze zijn of haar taken invult, hoeft dus niet in alle situaties hetzelfde te zijn. "Voor mij zit de architect vooral aan de beleidsmatige kant en draait desgewenst mee in het bouwteam, dan wel het functioneelontwerpteam. Hij of zij treedt daarbij op als de hoeder van de architectuur, maar is niet degene die het ‘huis' daadwerkelijk ontwerpt. Het functionele design wordt gedaan door de businessengineers, informatieanalisten in samenhang met de business. Bij het dagelijkse bouwen zijn architecten veel minder betrokken. Het houdt dus op op het moment dat duidelijk is hoe het plan in elkaar zit en men kan gaan bouwen. Net als in de fysieke wereld; daar komt ook niet elke dag een architect langs."
Ook tussen de architect en de bouwer loop volgens Steenvoorden geen harde grens. "Een echte IT'er is in zijn hart een bouwer én een ontwerper. Hij vindt niets leuker dan veranderen. IT is Legoblokjes voor grote jongens en meisjes. Daarom vind ik de IT zelf ook leuk en intellectueel uitdagend. Dus iedereen in dit vak is een architect in de dop. En ik moet zeggen: wij als IT'ers laten dat ook wel heel erg toe."

Legoblokjes
Over Legoblokjes gesproken, hoe zorg je ervoor dat alles een beetje flexibel blijft? "We hadden bij Essent een bedrijfs- en IT-architectuur die we ‘Flux' noemden: altijd in beweging en altijd in verandering. De basis hebben we gebouwd rond 2005, 2006. Er kwamen toen massale veranderingen op ons af, zoals de unbundling (de ontkoppeling van de netwerkleverancier en de commerciële aanbieder op het netwerk, red.), eventuele fusies, een veranderend marktmodel. Niemand overzag dat meer en bovendien liepen de budgetten als een razende op. We hadden daarom binnen het executiveteam behoefte om enige structuur aan te brengen."
"Binnen Flux hebben we eerst de businessveranderingen geschetst. Wat kwam er op ons af? Wat waren de leidende principes en wat de leidende key businessprocessen? Hoe liep de waardeketen? Daar hebben we onze basisarchitectuur op ontworpen en daaruit volgde onder meer de applicatiearchitectuur. Een van de belangrijkste principes die we bij Essent hanteerden, zijn de zogeheten ‘domeinen': logische eenheden van bedrijfsactiviteiten: trading, productie, verkoop, enzovoorts. Waar deze domeinen gekoppeld zijn, ook met externe partijen (de commerciële aanbieders die diensten aanbieden over het netwerk van de energieleverancier, red.), gebeurt dat op basis van openmarktstandaarden. Dus intern en extern op dezelfde manier. Omdat ik de applicaties bij de verschillende domeinen altijd uit elkaar heb gehouden, en de communicatie altijd bewust op basis van de marktstandaarden heb gehouden, was het uit elkaar trekken een relatief simpele operatie. Dit komt allemaal terug op het oorspronkelijke architectuurdenken."

Afschalen
Bovendien hebben Steenvoorden en de zijnen bij Essent een grote effort zitten in het afschalen van de legacy. Daarnaast speelt de applicatieredundantie. Voor een eenduidige architectuur moet je volgens hem keuzes durven maken welke applicaties je waar inzet en vooral welke applicaties je niet toelaat. Daarbij maakte de CIO bij de energieleverancier een onderscheid tussen applicaties die generiek en per domein werden ingezet. Bovendien werden de systemen zoveel mogelijk bij dezelfde leverancier betrokken.
"We hadden al sinds jaren een SAP-tenzij-beleid en volgden het store once, use many-principe. Dat betekende overigens niet dat daar altijd heel hard de hand aan is gehouden. De businessbehoefte was de laatste jaren zo groot, dat het niet uitmaakte wat het kostte, als het ‘morgen' maar klaar was. In dat soort omstandigheden heb je het als architect overigens zwaar. Later kwamen we weer terug bij operational excellence, kostenbesparing en het toevoegen van waarde voor de klanten. Daarbij speelt architectuur een belangrijke rol. In die zin is architectuur binnen Essent met een revival bezig."
Dat werd overigens niet altijd herkend en erkend door het management bij de diverse businesses. "Architectuur is daar geen populair thema, omdat ze zich er bij de business niet zo verschrikkelijk veel bij kunnen voorstellen. Ik heb het woord architectuur om die reden altijd weinig in de mond genomen, maar wat de business heel goed snapte is het belang van dingen simpel houden en operationeel excellent."
Simplify, standardize, mechanize is en blijft een belangrijk principe voor Steenvoorden. "Dus je vraagt je eerst af of er een businessbehoefte is en hoe deze simpel kan worden ingevuld. Vervolgens kijk je of het te standaardiseren is, om het daarna pas in het systeem te gaan stoppen. Daarnaast heb je het principe re-use, buy, make. Dus eerst kijken of je iets kunt hergebruiken, dan nadenken over een standaard oplossing en pas als dat echt niet lukt, dan ga je knutselen. Daarnaast hanteer je een standaard lijst waarin precies staat welke systemen je gebruikt voor welke dingen."

Auditen
IT'ers en architecten hebben nogal eens de neiging om verliefd te worden op hun eigen prestaties, terwijl iemand die van buiten komt kritische vragen kan stellen. Met andere woorden: hoe weet Steenvoorden dat zijn architectuur goed is? Heeft hij zijn architecturen bijvoorbeeld wel eens onafhankelijk laten auditen? "Bij Essent hebben we het oorspronkelijke ontwerp samen met McKinsey gedaan en daarna heb ik een aantal van de belangrijkste bouwpartijen onafhankelijk van elkaar kritiek laten geven. De grootste uitdaging was vervolgens het bijhouden. Dat is lastig. In de praktijk zie je dat het draait en werkt, dat maakt je misschien een beetje gemakzuchtig."
Daarmee komt de CIO vanzelf bij de IT-governance, want het bouwwerk moet dus wel consistent blijven. "Op IT-niveau werkten we daartoe met roadmaps, toegespitst op de genoemde domeinen en subdomeinen daarin. Maar er bestaat dus geen ‘gouden' architectuur. Ik zei het al: het hangt af van de vorm en levensfase van een bedrijf. Concreet zaten wij bij Essent vijf jaar geleden in een stadium van veranderingen, waarbij het meedoen aan de liberalisering veel belangrijker was dan de kosten. Dan kun je wel zeggen: zorgt dat die gebruiker ziet wat hij betaalt, maar dat interesseert hem in zo'n geval helemaal niks. Geld was geen issue, verandering des te meer. Momenteel zit het bedrijf in een heel andere fase en zijn dergelijke principes wel belangrijk."

Competenties
Als het gaat om de competenties van een goede architect, heeft René Steenvoorden een voorliefde voor mensen die businessgericht kunnen denken, functionaliteit kunnen vertalen naar het waarom, wat en hoe. Hij of zij moet dit bovendien kunnen visualiseren. Dit moet men vervolgens kunnen vertalen naar hanteerbare oplossingen. "Ik heb overigens liever geen architect die zegt: "Ik heb een lang advies geschreven en daarmee is mijn klus gedaan." Ik wil er een die met zijn poten in de modder gaat staan en blijft duwen en trekken, totdat het geregeld is. Dat laatste is heel lastig, sommige mensen lopen weg wanneer het spannend gaat worden. Een andere competentie is flexibiliteit van geest; je moet als architect kunnen accepteren dat er op een gegeven moment een beslissing wordt genomen waar je het niet mee eens bent. Waarom is dat belangrijk? Omdat het gewoon een beslissing is. Punt uit. De meeste architecten kunnen daar moeilijk mee omgaan. Die zijn er zo van overtuigd dat wat zij zeggen goed is, dat ze niet de mentale sprong kunnen maken om de zaak binnen een ander gegeven in goede banen te leiden."
Dat een architect voor de eer kan bedanken wanneer bepaalde zaken tegen zijn principes indruisen, ziet de CIO niet als een problematische machtsfactor. "De wereld is groot, je hebt altijd de keuze om op te stappen. Er zijn heel veel bedrijven en er zijn heel veel leuke banen, dus niemand hoeft te blijven zitten. Of je schikt je, of je gaat wat anders doen."
"De echte waarde van de architect ontdek je overigens pas op de langere termijn. Stel je bouwt een huis en op een gegeven moment wil je de witte kozijnen blauw schilderen, dan krijg je gewoon een rekening en klaar ben je. Maar als je aan het bouwen bent en je wilt ineens de liftschacht tien centimeter verplaatsen terwijl je al op de derde verdieping bent, dan gaat het dus niet gebeuren. Een goede architect behoedt je voor dit soort problemen en dat is veel geld waard. Het is een goede IT-kennis, in combinatie met ervaring. Gemiddeld genomen praat je over goed academisch niveau."
Bij de competenties hoort ook nog zoiets als natuurlijk gezag. "Overtuigingskracht, communicatie en senioriteit zijn zeker belangrijk. Maar wat ik afschuwelijk vind, zijn architecten die veel tijd besteden aan zwaar theoretische onderwerpen. Bijvoorbeeld over het categoriseren van functionaliteitseisen. Hoewel het aan het eind van de rit prachtig is, kost het vanwege de uurtarieven goud geld. En niemand wordt er wijzer van, behalve de architecten zelf. Het discussiëren om het discussiëren of het discussiëren om het niet kunnen accepteren dat er een ander soort beslissing wordt genomen, dat vind ik een heel vervelende eigenschap. En dat is de reden dat architecten vaak toch een beetje een negatief imago hebben."
Ze mogen van de CIO best tijd hebben om met de benen op tafel na te denken en hij vindt het prima wanneer ze zich door de Forresters en de Gartners van deze wereld laten informeren. "Maar ze moeten wel aan het werk blijven. Er is niets zo dramatisch als een goede architect die blijft discussiëren, daar kom je nooit uit. Dat is een vervelende eigenschap."

Noodzakelijk kwaad
De boodschap die René Steenvoorden zou willen meegeven aan collega-CIO's is dat architectuur belangrijk is. Ze moeten het evenwel niet zien als een noodzakelijk kwaad. "Doe het, en beperk je tot de praktische waarde: denken in oplossingen en waarde voor de business. Dwing daarbij de architect om ook in de modder te staan. Zo voorkom je dat hij of zij achteraf roept dat de uitvoering niet deugt en het allemaal anders moet."