Duivelse details

Architecten moeten zich niet met details bemoeien. Architecten zijn tenslotte hoog-gekwalificeerde professionals die spaarzaam met hun tijd moeten omgaan en zich dus wel moeten beperken tot hoofdzaken. Dat is althans het heersende inzicht onder veel architecten. Maar is dit ook terecht?

Er zijn veel argumenten aan te voeren die voor deze stelling pleiten. Architectuur gaat tenslotte om fundamentele ontwerpkeuzes die niet, of heel moeilijk achteraf te wijzigen zijn. Allerlei meer oppervlakkige ontwerpkeuzes zijn achteraf altijd nog makkelijk te wijzigen. Een lelijk behangetje vervang je nou eenmaal makkelijker dan een rottende heipaal. En dankzij de moderne technologie, met zaken als business rules, business process management systemen, enterprise service bussen en portals, komen er steeds meer mogelijkheden om het gedrag van applicaties run-time aan te passen aan wijzigende behoeften. Met als logisch gevolg dat architecten zich steeds minder met functionaliteit en steeds meer met ‘agile technology’ bezighouden.

Tegelijkertijd het is een algemeen erkende valkuil dat de architect die zich verliest in een moeras van details als de opper-nerd ervaren wordt. Een harde werker, een ongetwijfeld slimme expert, maar onbegrepen, weinig effectief en al helemaal niet daadkrachtig. Maar het is juist de kern van de functie van een architect dat hij een waardevolle en gewaardeerde gesprekspartner voor een opdrachtgever moet zijn. De gemiddelde opdrachtgever is nou eenmaal meer geïnteresseerd in meetbare resultaten dan in de onderliggende technologie. Dus architecten moeten nadrukkelijk bezig zijn met de tastbare effecten van de structurele aspecten van complexe systeemontwerpen en ze moeten dat op managementniveau uit kunnen leggen. Daar zijn ze tenminste voor ingehuurd. Architecten ontlenen op z’n minst een deel van hun waarde aan het in Jip-en-Janneketaal kunnen vertalen van ingewikkelde verhalen van specialisten. Ze moeten niet voor niets excellente communicatoren zijn. Maar is dat alles? Gaat het meer om de presentatie dan om de inhoud? Zou een goede spindoctor automatisch ook een goede architect zijn?

Microsoft heeft een weinig benijdenswaardige reputatie opgebouwd als het gaat om het ontwikkelen van gebruikersvriendelijke, begrijpelijke applicaties en systemen. Er zijn tal van voorbeelden van – vanuit het perspectief van de gebruiker – volstrekt onlogische constructies, onbegrijpelijke meldingen en inconsistent of op z’n minst weerbarstig gedrag. Microsoft is dan ook nog steeds het archetypische voorbeeld van alles wat er mis is in de digitale wereld. En haast iedereen kan er uit eigen ervaring over meepraten.

Apple toont juist aan dat het ook anders kan. Hun laatste ultra-thin client, de iPod-touch, blinkt volgens vriend en vijand uit door gebruikersgemak. Het ding heeft vast een operating systeem, maar als gebruiker merk je daar eigenlijk niets van. Het blijft volledig op de achtergrond. Toch kun je er ondermeer mee browsen, mailen, YouTube filmpjes bekijken, je eigen foto’s, video’s en muziek meenemen en afspelen, je aandelenportefeuille monitoren en routes plannen. Het apparaatje is niet meer dan 8mm dik, heeft een haarscherp, goed leesbaar touch-screen, het biedt eindelijk een bruikbaar mobiel toetsenbord, en het maakt op innovatieve wijze gebruik van ‘multi-touch’. De hele gebruikershandleiding bestaat uit een videofilmpje van een kwartier en al na een avondje uitproberen voelt alles volkomen vertrouwd aan. Bovendien hebt je er geen systeembeheerder voor nodig. Simpel, sexy en soepel.

De applicaties van Microsoft bieden een overvloed aan functionaliteit. Je kunt er in principe alles mee wat je zou willen, ze zijn tegenwoordig behoorlijk stabiel, de beveiliging is op orde en er valt ook verder weinig aan te merken op de fundamentele ontwerpkeuzes. Sterker nog, qua architectuur zijn ze voorbeeldig. Alle irritante eigenschappen zijn op de keper beschouwd niet meer dan oppervlakkige details. De applicaties op de iPod zijn daarentegen juist erg beperkt in functionaliteit en doordat alle functionele complexiteit zoveel mogelijk is vermeden, is de architectuur ook betrekkelijk eenvoudig. De onderliggende technische complexiteit is ongetwijfeld duizelingwekkend, maar vanuit het perspectief van de doorsnee architect zijn dat nou juist de details die hij graag aan de echte nerds overlaat.

De conclusie moet wel zijn dat Microsoft de beste architecten heeft en Apple juist de beste ingenieurs. Dus goeie architecten maken kennelijk slechte applicaties en voor werkelijk goeie IT-systemen heb je meer aan geniale ingenieurs.

De wereld op z’n kop!

Maar is de stelling dat goede architecten zich beter niet met details kunnen bemoeien op basis van dit ene voorbeeld dan ook te kwalificeren als

Flauwekul?

Het is van belang om je te realiseren dat niet alle details per definitie bijzaken zijn. Er zijn legio voorbeelden van details die over het hoofd zijn, die gezien uiteindelijk funest bleken te zijn. Een goede architect heeft een goed ontwikkeld gevoel voor zulke details. Om niet te zeggen: oog voor detail is een onmiskenbare kernkwaliteit voor architecten.

Soms heb ik wel eens het bange vermoeden dat de architecten die zich met de meeste verve achter de stelling verschuilen "omdat het niet bij hun functie past om zich met details bezig te houden", dat vooral ook beweren omdat ze volkomen vervreemd zijn van de hedendaagse technologie. Soms denk ik dat de stelling vooral populair is onder het type ivoren-toren-architecten die hun gebrek aan materiekennis proberen te verhullen door zoveel mogelijk afstand te creëren van de weerbarstige werkelijkheid. Het kaliber architecten die opmerkelijk vaak hun in wezen geniale architecturen verprutst zien worden door incompetente ontwerpers en ontwikkelaars.

De architectuuragenda

Het is en blijft een feit dat architectuur per definitie niet over details gaat. Het is tegelijkertijd een hardnekkig misverstand dat architecten dus niet voor details verantwoordelijk zouden zijn. Een gemiddelde opdrachtgever verwacht – mijns inziens terecht – van zijn architect dan hij zich namens hem met alle relevante details bezighoudt. Dat wil zeggen, met alle technische, functionele, juridische, sociale of ergonomische aspecten die – hoe futiel ook – het succes in de weg kunnen staan. De opdrachtgever heeft zelf immers niet de benodigde deskundigheid om te kunnen voorzien welke details relevant kunnen zijn, laat staan de tijd om zich er zelf mee bezig te houden. Anders gesteld, als de architect zich niet met de details bezighoudt, wie zou het dan moeten doen? De opdrachtgever zelf? De projectmanager soms?

Pas er als architect overigens wel voor op om al die relevante details ook met je opdrachtgever te bespreken, of, erger nog, de opdrachtgever te overvoeren met voor hem onbegrijpelijke details waarover hij een beslissing moet nemen. Verantwoordelijkheid nemen voor details is volstrekt wat anders dan je indekken door alle keuzes bij iemand anders neer te leggen. Een goede architect voelt haarscherp aan welke details hij zelf kan afhandelen en welke hij aan zijn opdrachtgever moet voorleggen en in dat geval, in welk stadium hij ze moet voorleggen. Een afgepaste dosering schept namelijk het vertrouwen dat de architect het ontwerpproces meester is, terwijl een overvloed aan kwesties – hoe relevant ook – juist twijfel zaait.

Het blote feit dat een architect geacht wordt zich met alle relevante details bezig te houden wil nog niet automatisch zeggen dat hij alles in z’n eentje moet doen. Sterker nog, een grote architect kan juist heel effectief zijn door allerhande specialisten in te schakelen om allerlei aspecten voor hem uit te laten zoeken. Een effectieve architect neemt op zo’n manier de leiding over het totale ontwerpproces, inclusief de detaillering, ook als het om een omvangrijk traject gaat. Dit geldt ongeacht de subdiscipline, dus of het om een businessarchitect, een softwarearchitect, een netwerkarchitect of een enterprise-architect gaat, de ambitie voor succes vereist een passie voor beeldbepalende details.

Architecten moeten als professional nadrukkelijk wel in staat zijn om hoofd- en bijzaken te onderscheiden. Ze houden zich als het goed is zelf intensief met hoofdzaken bezig, terwijl ze de bijzaken managen door ze uit te besteden aan bekwame derden – engineers, ontwerpers, analisten, vakspecialisten of junior architecten. Dat neemt echter niet weg dat ze de bijzaken niet uit het oog verliezen, maar er uitdrukkelijk regie over blijven voeren. Een goede architect laat het succes immers niet aan het toeval over.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 3^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.