Hoe zou jij architectuur willen omschrijven?

Fred: “Ik vind het wel handig om de vergelijking te maken met de bouw van een huis. IT-architectuur in een bedrijf is voor mij een conceptuele plaat van een samenhangend stelsel van zaken die in zijn geheel een werkend construct moet zijn. Net als een architectuurplaat een heel huis beschrijft en dan op een manier dat de samenhang tussen de verschillende onderdelen van het huis zichtbaar is. Je probeert op een zo strak mogelijke manier de gebruikswensen voor het huis te vertalen in een helder conceptueel beeld. Je moet er in kunnen wonen, kunnen slapen, je wilt ook kunnen douchen. Als je dat allemaal een beetje netjes, overzichtelijk ingeregeld wilt hebben, dan ziet dat er zo uit.

Zo’n conceptueel beeld geeft je ook houvast als je zaken wilt aanpassen of wijzigen. Met zo’n conceptueel beeld waak je er voor dat je niet alles zo verknoopt hebt, dat als je iets aan de badkamer wilt doen het blijkt dat je ook je hele fundament moet veranderen.
Dus niet alleen kijken naar de wensen van nu, maar vooral ook waarborgen creëren voor de bewegelijkheid naar de toekomst.”

Heb je zoiets al in de IT gezien?

Fred: “Ja, een voorbeeld daarvan zijn de schema’s die ik van de architecten bij UWV krijg waarin een conceptuele scheiding is gemaakt tussen wat nodig is vanuit de materiesystemen en wat nodig is vanuit de besturingslaag.
In enkele visuele schema’s staat weergegeven hoe je zaken op een handige manier uit elkaar trekt en weer aan elkaar knoopt. Dat vind ik als conceptueel kader heel handig om te hebben. Niet om in één keer te implementeren, dat moet je in mijn optiek niet proberen. Maar wel om, als je beweegt, te proberen een bepaalde kant op te bewegen.

Dan maakt het overigens nog heel veel uit of je op basis van architectuur een nieuw huis bouwt of dat je gaat verbouwen of renoveren.”

Gebruik jij als businessmanager die platen zelf of is het meer een weten dat ze er zijn en dat het daardoor wel goed komt?

Fred: “Kijk, de situatie waar we bij UWV in zitten is dat wij in feite een voortdurend renovatieproces hebben. Elke keer als je over je renovatie een besluit moet nemen is het belangrijk, en dat doen we ook, om die architectuurplaat als een van de variabelen in je besluitvorming mee te nemen. Dan gebruik ik die architectuurplaat om inzicht te krijgen wat waar zit en wat bepaalde veranderingen betekenen, net als in de fysieke wereld.”

Hoever moet een architect daarin gaan?

Fred: “Ik gebruik bewust de termen ‘intellectueel concept’ en ‘referentiekader’. Als je die architectuurplaat op dat niveau neerzet en als je hem zo gebruikt, dan heeft dat een zeker abstractieniveau in zich. Dat betekent ook dat je voor het maken van zo’n plaat analyses moet uitvoeren, analyses die je ook op dat abstractieniveau moet houden.
Nu zie ik twee type mensen. Sommigen kunnen alleen op dat abstractieniveau komen als ze eerst op een detailniveau beginnen en die tellen als het ware details op tot een bepaalde abstractie. En er zijn ook mensen die op het niveau van de abstractie analyses kunnen maken. Die tweede zijn succesvoller dan de eerste. Want als je op de details wilt beginnen dan loop je vast in detaildiscussies die je niet met de architect moet willen voeren.
De architect moet weten wat er nodig is. Hoe het precies gaat, zou indifferent moeten zijn aan de architectuurplaat. Voor een keukenontwerp wil ik niet hoeven vastleggen hoe laat er gekookt wordt en door wie. Dat weet ik nog niet. En bovendien, ik wil niet het gevoel krijgen dat als ik hier nu antwoord op geef ik straks iets opgelegd krijg van ‘ja, maar u zei dat u kookt van vijf tot zes’.”

Maar het krijgen van een bruikbare plaat heeft ook te maken met de open communicatie tussen businessmanager en architect. Een businessmanager moet duidelijk tegen een architect zeggen: ‘dit hoef ik beslist niet en dat wil ik absoluut wel’.

Fred: “Ja, maar dat vind ik in elke vakdiscipline die in zekere mate een eigen wereld, opleiding en taalgebruik heeft. Je ziet dat diegene die moet communiceren met dat vakgebied, enerzijds afhankelijk is van de kwaliteit van de mensen die in dat vakgebied zitten, maar anderzijds ook van de mate waarin hij zelf in staat is een beetje te begrijpen waar het over gaat.

Een gesprek tussen een patiënt en een arts van 25 jaar geleden is een ander type gesprek dan nu. Dat heeft te maken met in hoeverre de patiënt in staat is iets te zeggen over zijn kwaal en weerwoord kan geven. Het is ook belangrijk dat hij kan aangeven dat hij bepaalde conclusies niet logisch vindt. Als jij niet in staat bent dat geluid terug te geven, is de communicatie met die arts wellicht onbevredigend.
Dat niveau heb ik bijvoorbeeld nog niet bereikt met de automonteur in de garage, als die tegen mij zegt: ‘dat ding is stuk, dat moet vervangen worden’. Ja, dat zal dan wel, denk ik dan maar.”

De mondige patiënt heeft, voordat hij naar de huisarts gaat, Wikipedia geraadpleegd en heel het web met Google doorgespit. Hij weet ongeveer wat hij moet vragen. Dat zou je met je auto ook kunnen doen.

Fred: “Dat klopt. Als je in een opdrachtgeversrol praat met een deskundige heb je van te voren, hoop ik, een keus gemaakt in de mate waarin je er zelf iets van wilt weten en dus een serieuze gesprekspartner wilt zijn. Dat wil je niet op elk terrein dus als leidinggevende maak je daarover een risicoafweging. In een bedrijf als het UWV waar de IT zo’n impact heeft op de bedrijfsvoering, kun je het je gewoon niet veroorloven, vind ik althans, om dat gesprek zonder enige basiskennis in te gaan.
Als de automonteur iets in mijn auto vervangt waarvan ik met meer eigen kennis had kunnen weten dat dat niet vervangen had hoeven worden, neem ik dat voor lief. De investering om mij daar in te verdiepen weegt daar niet tegen op.
Maar bij UWV, waar de dagelijkse uitvoeringspraktijk, waar ik voor verantwoordelijk ben, echt afhangt van de kwaliteit van de IT-oplossingen - niet alleen op de korte termijn, maar ook op de lange termijn, omdat we natuurlijk met enorm veel wijzigende wet- en regelgeving te maken hebben - kan ik niet zeggen: ‘weet je wat, kom met iets, ik heb geen notie waar het over gaat, maar het zal wel mooi zijn’. Dat kan niet.”

Laat jij alternatieven schetsen?

Fred: “Ja, alternatieve oplossingsmogelijkheden met de architectuurplaat als leidraad voor hoe we het zouden willen als we opnieuw konden beginnen. Het geeft de richting waarin we bij ontwikkelingen proberen te bewegen.

Dus als er iets wijzigt of als er iets bijkomt, dan kijk je naar die architectuurplaat. Je bekijkt hoe de wijziging in jouw aandachtsgebied valt en vraagt je af wat je eigenlijk zou willen. Kan ik in de beweging die ik moet maken die kant op, in termen van doorlooptijd, tijd, geld en inhoud?
Dan maak je een afweging. Stel dat ik de mogelijkheid krijg om in de voorgestelde verandering iets te ontkoppelen, zodat ik materie en besturing wat uit elkaar kan trekken binnen het geld en de doorlooptijd die gegeven is, dan maak je die beweging.

Er zijn echter ook voldoende situaties waarbij je zegt: ‘Ja, dat zou mooi zijn. Maar dat wat er nu gevraagd wordt, dat moet over een week klaar. Er is weinig geld, en hoewel we met dit systeem nog niet op het niveau zitten waar we qua architectuur naartoe willen, passen we het huidige systeem nu gewoon aan binnen de context die er staat’.
Er moet een balans blijven tussen wat moet en wat kan, dat is een veel voorkomende managementafweging. Dan wil je geen hardnekkige architect die zegt: ‘nee, nee, dit moet in de architectuur!’ Ja, en hoe lang duurt dat dan? Nou ja, een maand of 12 voor de voorstudie en het kost 17 miljoen. Oh, da’s leuk, want ik heb drie weken en een ton. Dat gaat niet. Nou ja, vervolgt die architect, dan moet het maar niet, want het moet in de architectuur. Dan kom je in een soort omdraaiing van verantwoordelijkheden terecht. Dan moet de businessverantwoordelijke een knoop door kunnen hakken ook tegen de zin van de architect.”

Als het goed is, is de business de baas!?

Fred: “Ja, want we hebben met de minister afgesproken dat die wet op tijd geïmplementeerd wordt en het systeem moet worden aangepast Als jij, binnen de gegeven kaders, een slimme manier weet om dat te doen in de architectuur dan nemen we dat zeker mee. Maar zo niet, dan niet.”

Hoe gaat zo’n architect daar mee om? Met zo’n beslissing?

Fred: “Dat wisselt nogal, maar eerlijk gezegd wisselt de aard van het probleem ook. De ene keer is de urgentie prangender dan de andere keer. Dus het is ook wel belangrijk om met elkaar (business en architecten) afwegingen te onderzoeken in een soort checks and balances proces.
Het feit dat de business in de lead is, ontslaat de business niet van het serieus afwegen van de mogelijkheden die er zijn. Noch ontslaat het de architect van zijn verplichting om er toch maar even in te blijven prikken met de vraag of het echt niet twee maanden langer mag duren. Anders kom je, zeker in de UWV-situatie van permanente verbouwing, nooit echt verder. Dan is er altijd te weinig tijd en geld en komen we nooit tot wezenlijke verbeteringen.”

Waar zitten bij UWV de architecten?

Fred: “De mensen die zich echt bezig houden met architectuur zitten centraal. Hier in de business hebben we functioneel beheer, een helpdesk en een beleidsmatige club.”

Met wie praat jij dan? Met die beleidsmatige club?

Fred: “We hebben hier in huis twee type gesprekken gevoerd.
De informatiearchitecten vanuit de centrale directie ICT hebben relatief intensieve dialoogsessies gevoerd met de businessbazen over die abstracte architectuur, mijn referentiearchitectuur dus.
Als het gaat over de vraag hoe bewegen we en wat zijn daarbij de afwegingen, dan doen wij dat hier in het directieteam. Onze beleidsmensen praten met ICT en daar komen beslisdocumenten uit waarin die verschillende aspecten zijn afgewogen. Negen van de tien keer komen ze daar wel uit. Lukt dat niet, dan wordt er overleg gevoerd tussen de CIO en mij. Dat gebeurt overigens de laatste tijd minder dan een paar jaar geleden.

Toen we begonnen als UWV hadden we natuurlijk een bonte verzameling van allerlei IT-landschappen van al die verschillende onderdelen. Vanaf dat moment is er vanuit de centrale IT-directie gewerkt aan een architectuur voor het systeemlandschap. Met als strategisch uitgangspunt het splitsen van materiefunctionaliteit en besturing. Die architectuurplaten zijn uit 2003 of 2004. Het basisidee is toen gelegd, een duidelijk en eenvoudig beeld.
In die tijd liep de spanning wel eens hoog op. Dan had iemand op een kantoor ergens in het land iets heel bruikbaar in elkaar gezet en dan wilde ik als directeur dat landelijk implementeren. Dan zei architectuur natuurlijk dat dat niet kon, dat het anders moest. Dus moest er weer een studie worden uitgevoerd. Je krijgt dan een soort tijdsgevoel dat wel past bij de architectuurwereld ‘het zorgvuldig afwegen’. Maar in de wereld van de businessmanagers heb je een heel ander tijdsbesef, zo van er komt nu een grote doorstroom van aanvragen binnen en die wil ik gemanaged hebben.
Dergelijke spanningen zijn toen wel een paar keer hoog in de boom uitgevochten.”

Dat was dus de stress tussen de gewenste ideale architectuur en de werkdruk uit de huidige concerns van de business

Fred: “Die spanning is permanent, maar is nu in mindere mate. Wij zijn overgestapt van een benadering waarbij het bewegen naar de ideale architectuur heel erg maatgevend was, naar een benadering van kijken wat er kan. Dus meer redelijkheid, ook bij de architecten en ook bij de bazen van die architecten in mijn beleving.”

Wat is de tijdshorizon van je architectuurschetsen?

Fred: “Onze architectuur is meer een indeling van de typen functionaliteiten die we willen hebben. Daar zit geen tijdshorizon in.

Als we een nieuw systeem bouwen dan moet dat passen binnen de referentie architectuur. Dat was ook het uitgangspunt bij de nieuwbouw van het WIA-systeem. Dat project is zoals bekend niet succesvol geweest. De komende periode gaan we voor onze primaire processen geen grote nieuwbouw projecten starten. Dat komt misschien wel weer een keer, maar niet nu.
Voor de ontwikkelingen in de komende drie à vier jaar werken we met een instrument dat het jaar- en meerjaren informatieplan heet. Daarmee wordt vanuit de verwachte inhoudelijke ontwikkelingen (intern en/of extern) bepaald wat de beweging is ten opzichte van de bestaande situatie.
Je kijkt eigenlijk: wat heb ik te doen en wat staat er nu. Maar omdat ik dat gewend ben, stel ik nog wel de vraag: ‘kan ik nog iets met die beweging richting de architectuur?’. Dus je hebt die architectuurplaat en dan heb je in zo’n informatieplan en zo’n meerjareninformatieplan de planning van de zaken die je gaat aanpakken. Dus binnen AG probeer ik de zaken uit de informatieplannen als het ware te plotten op die architectuurplaat. Dan krijg je dus twee platen, één over hoe het is en één voor hoe het moet worden. Want nogmaals, die platen geven mij een soort overzicht en houvast.

We hebben per januari 2009 ook de fusie met het CWI gehad. Dat betekende dat je weer een ander systeemlandschap in huis haalt. De UWV architectuur is ontwikkeld voor de UWV-situatie, niet voor het CWI. Dat betekent dat je met de applicatieportefeuille die je binnenhaalt en de bedrijfsfuncties waar je die nu voor gaat inzetten weer opnieuw moet kijken hoe verhoudt zich dat tot elkaar, welke conclusies trek je daaruit.”

De fusie met CWI gaat gepaard met een kanteling van de organisatie. Dat kan een enorme impact hebben op je architectuur.

Fred: “Ik zie geen grote gevolgen van de organisatiekanteling voor de architectuur Dat komt doordat onze systemen geen organisatorische oriëntatie hebben, maar een inhoudelijke. De organisatiestructuur was wetsgeoriënteerd. We hadden een divisie AG die ging over alle arbeidsongeschiktheidswetten en de divisie WW met de werkloosheidswetten en met nog wat faillissement en aanverwante ellende. Binnen die wetsgeoriënteerde organisatiestructuur heb je taken op het gebied van uitkeren, taken op het gebied van re-integratie en taken op het gebied van sociaal-medische claimbeoordelingen. De meeste van de huidige systemen zijn inhoudelijk gericht. Zo is er een uitkeringssysteem, een systeem waarin je bijvoorbeeld dossierbewaking doet op re-integratiedossiers en een systeem waarin je inkooptrajecten administreert. Door de kanteling draait de organisatie een kwartslag. Zowel de wetten als de bedrijfsfuncties blijven bestaan. Waar nu de basisindeling van de organisatie gericht is / was naar wet, kantelt die per januari 2010 naar bedrijfsfunctie. De systemen worden herverdeeld over de nieuwe divisies zonder dat ze zelf significant worden aangepast.”

Dus in feite waren de systemen al redelijk ontkoppeld ingericht

Fred: “Ja, modulaire opbouw is een belangrijk architectuurthema bij UWV. Bij ons impliceert dat dat je in je architectuur slechts één excasso hebt, ongeacht recht, hoogte en duur van de uitkeringen. En dat je het ontvangen en registreren van post niet per wet verschillend hoeft te doen. Zo is die architectuurplaat opgebouwd: generieke delen, materiedelen en de besturingslaag apart. Prima concept.

Als ik nu even de feitelijke situatie bij AG bezie, dan hebben we de slag gemaakt waarbij we van zes van die systemencomplexen naar twee terug zijn. Eén heeft een geïntegreerd excassodeel en het andere een apart excassodeel.

Dan hebben we nog een systeem voor de Ziektewet, daar hebben we in een keer wel de slag gemaakt van zes verschillende naar één. Dat heeft een apart excassodeel, dat ook wordt gebruikt voor de WW-uitkeringen. Daar zijn ze al terug naar één systeem en daar is het materiedeel al los van het excassodeel. Deze situatie is niet gerealiseerd met nieuwbouw maar door bestaande functionaliteiten te koppelen, Er moesten behoorlijk wat lijntjes worden gelegd om het zo te laten werken.

De verbetering van de werkprocessen - zowel vanuit klantperspectief als vanuit efficiency perspectief – wordt aangepakt op basis van wat er nu staat, en niet op basis van grootschalige nieuwbouw. Daarvoor kan je diezelfde architectuurplaat gebruiken.
Je wilt daarbij in ieder geval een beweging naar meer modulariteit, het basisprincipe voor flexibele werkstromen.”

Over het overdragen van taken naar buiten, UWV heeft enige jaren geleden premieheffingen overgedragen naar de Belastingdienst. Dat ging, naar ik meen, niet helemaal goed?

Fred: “Met het overdragen van taken op het gebied van de premie-inning aan de Belastingdienst moest een heel nieuw proces ontworpen en geïmplementeerd worden wat maakte dat je niet uit de voeten kon met de systemen die je had en er dus iets nieuws gemaakt moest worden.
De nieuwe samenwerking tussen Belastingdienst voor de premie-inning en UWV voor de gegevensopslag in de polisadministratie, heeft zijn tijd nodig gehad. Inmiddels is dat proces op orde. Binnen UWV is vrij goed af te bakenen welke ICT-systemen welk proces dienen.
Als het echter gaat om het overbrengen van systemen naar een andere omgeving, loop je tegen een veelheid van wat ik noem technische problemen aan. Problemen die ik niet kan beoordelen. Dan gaat iemand weer allerlei - voor mij weer op het niveau van de automonteur - technische onmogelijkheden roepen dat de verkeerde versie van Oracle gekoppeld moet worden aan een apparaat dat daar niet mee kan communiceren.”

Dat zijn in feite inflexibiliteitsproblemen onder de motorkap

Fred: “Ja, en dat vind ik nog steeds wel schrikbarend. Daaruit blijkt dat er toch nog steeds een grote mate van onvolwassenheid heerst in de hele IT-sector. Veel zaken onder die motorkap blijken zo inflexibel, zo onvoorspelbaar. Waar je tegenaan loopt zijn de meest ondenkbare problemen waarbij ik functioneel gesproken denk ‘tja, je legt een draadje en je kunt gewoon aan het werk’.

Meerdere malen werd ik met twee IT’ers geconfronteerd die met elkaar overhoop lagen over wat ik technisch noem. Niet omdat ze elkaar niet mochten, maar omdat over dezelfde problematiek er allerlei totaal verschillende oplossingen langskomen.”

Is het niet aan de businessmanager om IT-problemen die op je bord worden gelegd en die je niet begrijpt, niet te accepteren?
Vraag heldere uitleg op jouw niveau, zou ik zeggen!

Fred: “Maar dat gebeurt ook en is vaak erg moeilijk. Ik heb toevallig net een nieuw huis gekocht, dus ik moet vanavond naar de keukenleverancier toe. Wat mij dan irriteert is dat er tussen de ene keukenleverancier en de andere keukenleverancier in het realiseren van dezelfde functionele eisen een behoorlijk prijs- en doorlooptijdverschil zit.

Ik probeer natuurlijk de vinger achter het kwaliteitsconcept te krijgen wat daar onder ligt door een beetje aan die laatjes te trekken enz. Maar ik ga niet zover dat ik de houtspecificaties opvraag. Daar ga ik dan af op het gevoel wat ik heb over die leverancier. Vertrouw ik hem wel?.Bij het bestellen van een keuken neem ik dat risico.

De mate van verschil die er uit de IT-deskundigen komt, qua bandbreedte, qua geld, qua doorlooptijd en technisch inhoudelijke oplossingen is vaak erg groot. Als je daar geen verstand van hebt, ben je genoodzaakt door te zoeken naar een volgende deskundige: een derde of een vierde die als het ware als een soort opperdeskundige zegt hoe het wel zit. Zo zie je dat ook bij UWV regelmatige externe onderzoeken worden uitgevoerd. Er zegt iemand: laten we dan nog maar een keer opschrijven hoe het zit. We halen er een onafhankelijke partij bij die kan beoordelen hoe het zit’. Met vaak het risico dat die geen uitspraak doen over of het A of B moet zijn, maar eigenlijk is het C.

Naarmate men de architectuur dieper gaat uitwerken, komen er meer en meer verschillende oplossingsvarianten boven de horizon. Die zitten ook al op functioneel niveau. Die zijn voor iemand als ik best te begrijpen, als je je er een beetje in verdiept en je dergelijke zaken een beetje conceptueel in kaders kunt plaatsen. Maar zodra het op het niveau komt van de feitelijke realisatie zie je het steeds verder divergeren in de oplossingsmogelijkheden die je kunt krijgen. Het wordt dan voor mij steeds onbegrijpelijker en moeilijker te doorgronden wat ik echt ga krijgen. Hier past dan ook vaak het gezegde ‘the devil is in the detail’.”

Kun je een paar competenties noemen van de volwassen architect waaraan de business volgens jou behoefte heeft?

Fred: “Een architect dient in staat te zijn om het businessproces op een hanteerbaar abstractieniveau te doorgronden. Niet te hoog, niet te laag.
Een architect is iemand die in termen van overzicht en structuur het type plaatjes kan maken dat zeg maar de breedte pakt zonder te ver in de diepte te gaan.
Een architect is iemand die begrip heeft voor het verschil tussen wat kan en wat moet. Die zelf een ‘gebruiksinterface’ heeft, om het maar even zo te zeggen, die te hanteren is. Dus die in staat is om zijn eigen kunde en kennis in woord en geschrift te vertalen naar het niveau van diegene die het moet kunnen begrijpen.”

Moet een architect ook inspireren, bijvoorbeeld tot het veranderen van bedrijfsprocessen?

Fred: “Dat is geen eigenschap die ik aan een architect zou koppelen. Ik vind dat de innovatie uit de business moet komen. De architecten zijn de tekenaars. Zij leveren mij de platen, daar heb ik echt iets aan.”

Dikke pakken papier hebben voor mij weinig toegevoegde waarde. Ik krijg teveel dikke stukken over teveel onderwerpen. De facto kom je nooit aan goed lezen toe. Daarom vraag ik altijd een samenvatting.

En als het gaat om de vraag ‘hoe breng ik een architectuur over’, dan is elk mens verschillend. Ik ben schematisch visueel ingesteld, dus ik moet gewoon een plaat hebben. Het liefst met vakjes en kleurtjes, zodat de verschillen goed helder zijn. En dan woorden erin die appelleren aan iets wat ik kan begrijpen. Dus als iemand daar afkortingen in gebruikt waarvan ik denk ik heb geen idee wat dit is, dat werkt bij mij niet.

Ik houd ervan als de architect zegt: ‘Kijk, dit is de functie voor het ontvangen van de post, maar ook van de telefoon. Dat is als het ware je inputstuk. Dit is je besturingslaag, dat is materie en dit is excasso. En dan stel ik voor om die hele zaak zo te modelleren, en als jij dat wilt dan heeft dat de volgende consequenties voor de eisen die je stelt aan de techniek, de leveranciersverhouding en alles wat er dan van afgeleid is’. Een dergelijk houding van de architect is voor mij nuttig, want dan kan ik ook zeggen: ‘Ja maar, dat vind ik niet handig. Want ik zie dat we die beweging gaan maken, dus wat jij nu nog aan elkaar geknoopt hebt dat heb ik toch liever in twee aparte functies’.”

Heb jij zicht op hoe dan vervolgens die architect kan zorgen dat die beelden worden overgedragen aan anderen die het dan feitelijk gaan realiseren?
Dat zeg maar de uitwerking uiteindelijk in lijn blijft met de architectuur?

Fred: “Ja, maar daar zit een veronderstelling achter over een werkwijze, die ik niet geheel deel. Ik zie de architectuur niet als een implementatiekalender. We realiseren wat er vanuit de business moet gebeuren. En vervolgens hanteren we de architectuur om te kijken of we de beweging in lijn met de architectuur kunnen brengen.

Er gaan geen mensen in een groot programma de architectuur realiseren. Dat was een beetje in die beginfase dat mensen zeiden: ‘We gaan nu een programma maken om de architectuur te realiseren. Dit is het belangrijkste, dan pakken we dit aan. Daar zijn we dan twee- en een halfjaar mee bezig en dat kost zoveel geld’. Dan krijg je de business die zegt: ‘Nou, interessante gedachte. Overigens, we hebben maar zoveel geld en de volgende vijf businessprioriteiten moeten gerealiseerd worden in die zelfde periode. En die grijpen in op dat zelfde landschap waar jij het ook over hebt. Ik vind het uitstekend dat we bij het realiseren van die vijf businessprioriteiten kijken hoe je dat koppelt met jouw architectuurbelang, maar niet omgekeerd’. Dus we gaan niet vanuit architectuur iets doen en dan kijken of ook nog de businessprioriteiten gerealiseerd kunnen worden.”

Stel dat een bepaalde businessprioriteit in lijn ligt met een wens van de architectuur, dan is belangrijk dat de mensen die het gaan realiseren begrijpen wat die architectuurkeuze inhoudt.

Fred: “Als het kleine veranderingen zijn, dan zal dat ook weinig betekenen in het realiseren van de architectuur. Maar als het grotere bewegingen zijn, dan worden die meestal in een project of in een programma aangevlogen en betrek je daarbij een architect die meedenkt.
Die architect borgt de kaders: ‘Als je nu iets bouwt voor een kleine wetswijziging, dan gaan we wel afspreken dat het stuk dat te maken heeft met de procesbeheersing in een aparte besturingslaag komt’. Je gaat dan niet een apart systeempje bouwen met weer je eigen besturingslaag erin.

Voor al die projecten en programma’s maken we keurige projectinitiatiedocumenten. En die worden op dat soort aspecten getoetst.”

Wat moet architectuur jou uiteindelijk opleveren?

Fred: “Eigenlijk een heleboel.

Architectuur schept orde, dat is het eerste doel. Die orde heeft een aantal voordelen. Voordelen voor de eindgebruiker, want als je aan hen iets aan kunt bieden qua set van processen en systemen, dat logisch geordend in elkaar zit, vind de gemiddelde mens dat prettig. Dit zit hierin, dat zit daarin. Dit is de applicatie waar ik in werk, er hangt een applicatie onder, maar die doet alleen dit. Als ik dit muisklikje doe, dan kom ik daarin terecht, en ik snap ook wat daarin zit.
Als je nu naast een medewerker achter zijn pc gaat zitten, kun je zien dat hij in het slechtste geval 11 applicaties tegelijk heeft openstaan. En het kost je enige tijd om te snappen waar alles zit: ‘dat zit daarin, behalve voor dit, want dan zit het daarin’. Voor de medewerker is dat arbeidsintensief, frustrerend en vervelend.
Gebruikers vragen niet om architectuur, zij vragen wel om logica en om overzicht.

Een tweede doel is het bereiken van efficiency. Als dingen helder in elkaar zitten en dingen ook meer onderscheiden zijn, dan kun je sneller zaken aanpassen. De kans is dan ook groter dat je maar een deel van je applicatieportefeuille raakt bij de aanpassing, omdat onderwerpen niet zo verspreid zitten.

Een derde doel is het gemak van koppelen aan bestaande zaken. Als je bijvoorbeeld zoiets als digitale dienstverlening wilt inrichten, moet je dat inprikken in de bestaande applicaties. Dat is een stuk simpeler als we weten wat waar zit.”

Interessant dat je stelt dat een gebruiker een eenvoudige interface verdient.
De gemiddelde architect zakt niet af naar het niveau waarop hij zou kunnen begrijpen hoe de ordening van de functionaliteiten door de gebruiker wordt ervaren.
Zou je de architect op pad willen sturen om zelf ook eens een keer in de praktijk te gaan kijken?

Fred: “Nee, want architectuur speelt zich af op een abstractieniveau hoger dan waar jij het nu over hebt. Architectuur betreft het ordenen van de applicatieportfolio die die individuele gebruiker moet faciliteren. Architectuur faciliteert veranderingen door orde en overzicht te brengen.”

Ik heb enkele jaren geleden mijn badkamer laten renoveren. Daar heb ik een binnenshuisarchitect voor in de arm genomen. Ik wil niet alleen een badkamer die geordend is, maar hij dient ook mooi te zijn. Een badkamer met uitstraling.

Fred: “Daar ben ik het in feite mee eens, maar ik vind dat een vorm van luxe Ik zou al enorm geholpen zijn als op het niveau van de badkamer, we gewoon een badkamer hebben waar het water uit de kraan komt en niet voor een deel uit de kraan en voor een deel uit een slang. Een slang voor het koude water en de kraan voor het warme water. Dus je kunt best douchen, maar dan moet je dat doen met een verloopstuk, die moet je dan aan die slang en aan die kraan bevestigen. Zo krijg je het zo noodzakelijke lauwe water.

Wat ik dus eigenlijk zeg is dat die gebruikerssatisfactie al een enorme opwaartse impuls zou krijgen als je de functionaliteiten ordentelijk inricht.”

Wat adviseer jij andere businessmanagers in hun gebruik van architectuur?

Fred: “Slechts twee punten:

1. Zorg dat je op een of andere manier een minimaal begrip hebt van waar het over gaat. Anders volg je een architectuurcursus, of lees je een boek over architectuur. Maar zorg in ieder geval dat je een gesprekspartner kunt zijn over je architectuurwensen. Dus vertrouw niet alleen op iemand die dat voor jou doet.

2. Zorg dat je iemand hebt, die er zelf echt heel goed in zit. Maar positioneer die wel in de rol van adviseur.

Trouwens twee ontslaat je niet van een.”

Dat tweede lijkt niet zo makkelijk, want hoe herken je een goede architect? Het is al moeilijk genoeg een goede IT-er te herkennen in een nog onvolwassen vakgebied.

Fred: “Je herkent een goede architect door ermee te werken. Je moet iemand hebben, vind ik, die je vertrouwt op zijn oordeel en die in een adviseursrol zit.

Eis van de architect met wie je praat, dat hij de dingen presenteert in de vorm en de taal die jij begrijpt en neem geen genoegen met minder.

Nogmaals, de technische werkelijkheid is zeer onoverzichtelijk voor mij als businessmanager. Een businessmanager zou zich niet te gedetailleerd moeten willen bezig houden met die technische werkelijkheid. Dus je hebt iemand nodig die daar op meekijkt. Je mag echter niet verwachten dat dat een soort orakel wordt. Maar wel iemand die je als een soort coach kan helpen de juiste vragen te stellen.”

Interessant vind ik de vertrouwensrelatie die jij noemt. Als je in de fysieke wereld opdrachtgevers spreekt, hebben ze het over de klik tussen hen en de architect. Als die er niet is, dan wordt het een steriele, analytische aangelegenheid.

Fred: “Zonder vertrouwensrelatie werkt het niet. Mensen die primair vanuit een juridisch perspectief denken, hebben soms het idee dat je alles met specificaties dicht kunt timmeren: ‘Ik schrijf precies op wat ik wil en dan schrijf jij precies op hoe het gaat worden, maar dan net in iets andere taal. Dan komt er iemand van de techniek en dan zit het zo strak in elkaar dat ik als het ware op die manier kan borgen, dat ik precies krijg wat ik wil’. Dat lukt in de fysieke wereld al amper, laat staan in de ICT-wereld waar het allemaal wat abstracter is.
Een open werkrelatie dus: ‘Ik vertrouw jou als architect, dat jij begrijpt wat ik bedoel en dat als je het niet begrijpt je doorvraagt. En ik neem aan dat je niet denkt, dat heeft ie zo dom opgeschreven, daar kan ik nog alle kanten mee op’.

Ook verwacht ik in de relatie opdrachtgever/architect versus opdrachtnemer dat naast het geschreven woord, het onderlinge begripsvermogen zodanig is dat het streven er is om er iets gezamenlijks neer te zetten. Het blijkt in de praktijk dat hoe je het ook dicht schrijft om het goed te laten gaan, er altijd veel ruimte is voor misinterpretatie. Dit is een vakgebied waarop heel veel mensen zich onzeker voelen. Vertrouwen kan niet worden gecompenseerd door alsmaar meer papier vol te schrijven.”

Veel papier maakt het vanuit het perspectief van de bestuurder niet beter beheersbaar. Je kunt toch niet de veiligheid afmeten aan het aantal centimeters van de dikte van de rapporten?

Fred: “Presenteren en communiceren is iets waar je extra aandacht aan moet besteden.

Nogmaals, het is natuurlijk wel belangrijk dat de mensen die iets technisch moeten doen hun basiskundigheid bezitten op het gebied van wat ze technisch kunnen. Als je een versleten heup hebt, vind je het prettig als je een chirurg hebt die het goed uit kan leggen. Maar als je moet kiezen tussen een chirurg die het niet goed kan uitleggen, maar wel technisch heel goed opereert en een die heel aardig is en ook goed kan uitleggen, maar er niets van bakt, dan weet ik wel hoe mijn keuze eruit gaat zien.”

[PDF]