Slachtoffers van architectuur

Erik Vermeulen, vrijdag 12 november 2010

Als u hebt besloten om dit artikel te lezen dan bent u mogelijk op zoek naar lotgenoten of bevestiging. Maar het kan natuurlijk ook zijn dat u zelf architect bent en enigszins geschokt bent door de titel. In dat geval hoor ik u al denken “Kunnen er ook slachtoffers vallen?”. Jazeker, is het antwoord: er kunnen slachtoffers vallen. Maar wie zijn dan die slachtoffers en welk leed wordt hen aangedaan? Daar gaat dit artikel over.

Over smaak valt te twisten

Het idee voor dit artikel kwam van Jan Truijens. Toen ik op twitter de vraag stelde “Waar zou een echt zinvol blog op vianovaarchitectura.nl over moeten gaan?”. Kreeg ik als antwoord “Niet over Architectuur maar over de slachtoffers van architectuur...”. Dat kwam toch wel een beetje als een verassing. Zo expliciet had ik nog niet naar de mogelijk nadelige gevolgen van architectuur gekeken. Ik stelde me dus de vraag: Wie zijn de slachtoffers van architectuur en welk leed wordt hen aangedaan? Ik voelde al direct dat dit geen eenvoudige vragen zijn. Het is tegen je intuïtie om je als insider te verdiepen in een vraag die haaks staat op je overtuiging: namelijk dat architectuur een positief fenomeen is. Maar waar gehakt wordt vallen spaanders; en waarom zou dit niet gelden voor architectuur.

Voor wat betreft de constructie van een huis is relatief eenvoudig vast te stellen wie de slachtoffers zijn en – zeker als het gaat om de materiële kant – wat de schade is. Als de fundering van een gebouw wegzakt; een balkon afbreekt of het dak bezwijkt tijdens een stevige sneeuwbui, kunnen er slachtoffer vallen. De schade kan materieel, bijvoorbeeld waardeverlies of lichamelijk letsel, of immaterieel zijn, bijvoorbeeld depressiviteit.

Zo is het in zekere zin ook met de constructieve aspecten van de architectuur van de informatievoorziening. Gebruikers worden het slachtoffer van een applicatie die bijvoorbeeld crasht, denk aan data die zoek zijn geraakt of zijn gestolen. Maar ook als medewerkers van twee afdelingen, bijvoorbeeld een afdeling operations en een afdeling planning & control, elkaar structureel verkeerd interpreteren kunnen er slachtoffers vallen. Denk bijvoorbeeld aan het ‘informeren’ van planning & control over de aanwezige oliereserves. Architecten hebben de verantwoordelijkheid om op deze constructieve kwaliteiten van een systeem te letten.

Het ligt echter een stuk lastiger als het gaat om de beleving van de architectuur. Wanneer kunnen we dan van slachtoffers spreken? Dan gaat het over subjectieve oordelen. Het gaat over gevoelens, over smaak. Neem bijvoorbeeld het inmiddels gesloopte wooncomplex de 'Zwarte Madonna'. Een gebouw dat bij velen niet in de smaak viel. Carl Weeber, de architect, heeft deze kritiek ooit op merkwaardige wijze gepareerd door te stellen dat 'je je niet moet neerleggen bij een zwak ontwikkelde bevolking'. En over de vermeende lelijkheid van het gebouw heeft hij eens gezegd: 'Zijn voorkomen is juist een van de verdiensten geweest van de Zwarte Madonna. Het gebouw behaagt niet, het is weerbarstig.'. Ondanks de kritieken op het voorkomen van het gebouw bleek het nog een hele klus om alle bewoners uit de 'huurkazerne' te krijgen. Zij voelden zich geen slachtoffer van de architectuur, in tegendeel zij voelden zich slachtoffer van de slopers: Over smaak valt te twisten.

Een aardig voorbeeld in de wereld van de digitale architectuur is het 'onderwaterscherm' van Wordperfect. In deze tekstverwerker, die in de jaren tachtig heel populair was, konden gebruikers het documentscherm in tweeën delen waarbij in de onderste helft alle (verborgen) opmaakcodes te zien en te bewerken waren (het ‘onderwaterscherm’). Een functionaliteit die ontbreekt bij bijvoorbeeld Word. Bij de grootscheepse verhuizing van WordPerfect naar Word in de jaren negentig kwamen er hele volksstammen in opstand wegens het ontbreken van het 'onderwaterscherm'. Zij voelden zich het slachtoffer van het Windows geweld.

Alvorens verder in te gaan op de slachtoffers van architectuur in de digitale wereld wil ik een onderscheid maken naar slachtoffers van enterprise architectuur respectievelijk project architectuur. Hierbij is met name het onderscheid in scope van belang; gaat het om de gehele organisatie of slechts over een beperkt deel.

Slachtoffers van project architectuur

Het eerste artikel dat ik voor deze tekst bekeek was een artikel over een proefschrift van de onlangs gepromoveerde “IT-veteraan” Raymond Slot. Maar tot mijn teleurstelling (en tevens opluchting moet ik toegeven) bleek hij tijdens zijn onderzoek helaas geen slachtoffers gevonden te hebben. “Het had wel gekund dat er ook negatieve zaken uit zouden komen, maar die heb ik niet kunnen vinden. Het is voor mij de bevestiging dat architectuur een nuttige exercitie is." aldus Slot. Hij wist te meten dat klanten meer tevreden zijn over projecten die werken onder architectuur. Volgens zijn bevindingen hebben projecten die onder architectuur werken 19 procent minder budget nodig en nemen de - helaas gebruikelijke - overschrijdingen van de tijdsplanning met 40 procent af. Projecten die werken onder architectuur zijn blijkbaar sneller klaar en blijven vaker binnen budget.

Slot noemt een drietal factoren die van cruciaal belang zijn: de besturing, de aanwezigheid van een projectarchitectuurdocument en het ervaringsniveau van de architect zelf. Met name de laatste factor wil ik er even uitlichten. Dit is een mogelijk hint naar slachtoffers en deed me direct denken aan een van de wetten van Hamurabi, een vorst die zo'n 38 eeuwen gelden heerste over de stadstaat Babylon. Deze wet luidt: "Heeft een bouwmeester een huis gebouwd dat instort, en de bewoner wordt daarbij gedood, dan zal die bouwmeester gedood worden; wordt de zoon van de bewoner gedood, dan zal de zoon van de bouwmeester gedood worden."

En zo eenvoudig is het natuurlijk: Architectuur blijft mensenwerk en waar mensen werken worden fouten gemaakt; ook als het architecten zijn. En het zal zeker zo zijn dat ervaren architecten minder snel fouten maken. Maar het blijven mensen en als ervaren mensen fouten maken dan zou er wel eens iets goed mis kunnen gaan.

Ruim tien jaar geleden heb ik een tijdje mee mogen werken aan een project dat, onder architectuur, een ingewikkeld nieuw maatwerk systeem moest opleveren. Hoewel ik als beginneling, verantwoordelijk voor de requirements voor enkele stukken van de projectarchitectuur vast niet alle ins en outs heb meegekregen zijn me de volgende zaken bijgebleven:

  • De zeer ervaren projectarchitect profileerde zichzelf graag als een über IT-er;

  • Er werd gewerkt met een niet beproefd IT-driven businessconcept dat was bedacht door een van de grote IT-bedrijven;

  • Er was gekozen voor niet eerder beproefde technologie. De software engineers (bouwers) waren, soms op het komische af, volstrekt nieuw in deze technologie;

  • Heel veel fundamentele softwareroutines moesten zelf worden ontwikkeld (zelfs basale datum routines);

  • Het was een project met een hoog prestige gehalte en een hoog projectbudget;

  • De business doelstellingen waren, evenals het programmamanagement en de projectarchitect, overambitieus;

  • Er waren heel weinig eindgebruikers betrokken bij de ontwikkeling; een van de weinige was een cum laude afgestudeerde econometriste.

Het project heeft heel veel geld gekost en nooit een productiewaardig systeem opgeleverd. Ik heb me later laten vertellen – dit zal wel een beetje overtrokken zijn - dat er nog maar een persoon was die het systeem kon bedienen; de cum laude afgestudeerde econometriste. De slachtoffers waren talrijk (denk alleen maar aan alle projectmedewerkers) maar bovenal was er veel geld en tijd verspild.

Gegeven de hierboven genoemde zaken denk ik niet dat het alleen aan de architectuur (of de architect lag) dat het geen succes is geworden. Ik herinner me nog een kenschetsende opmerking van de verantwoordelijk programmamanager. Toen ik hem op de man af vroeg wat er zou gebeuren als het hele project zou falen antwoordde deze: 'Dan hebben we toch ongelooflijk veel geleerd'. Met de wetenschap van nu kan ik alleen maar verzuchten dat het maar gelukkig is dat we niet in de tijd van Hammurabi leven. Ik ben tegen de doodstraf.

Slachtoffers van enterprise architectuur

Een zaak waar enterprise architecten zich doorgaans mee bezig houden is het beteugelen van de complexiteit van het applicatielandschap. Een manier om dit te bereiken is bekend onder de noemer “applicatie rationalisatie”. Hierbij wordt het landschap in gebieden verdeeld en worden er per gebied afspraken gemaakt over het opruimen van het landschap. Een voorbeeld van zo'n afspraak is "ERP tenzij...". Deze afspraak houdt in dat iedereen binnen het betreffende gebied met hetzelfde ERP-pakket moet werken. Alle bestaande systemen die door het geselecteerde ERP-pakket ondersteund kunnen worden moeten het veld ruimen.

Het mag duidelijk zijn dat hier slachtoffers kunnen vallen, met name onder de gebruikers van de overbodig verklaarde systemen. Zeker als deze systemen naadloos aansloten op hun zo gegroeide werkwijze. Als ze geluk hebben wordt het verlies aan functionaliteit gecompenseerd door nieuwe functionaliteit waarmee ze hun werkwijze kunnen verbeteren. Voor de enterprise architect valt dit onder de noemer "collateral damage" oftewel schade in de marge. Ze kunnen het onmogelijk iedereen naar de zin maken en alle ruimte bieden om zelf te bepalen welk systeem te gebruiken, want dat was nu juist de oorzaak voor de enorme complexiteit. Hoe onrechtvaardig dit ook voor de individuele gevallen is. Overigens is veel van dit leed te vermijden door voldoende aandacht te besteden aan het herinrichten van de werkprocessen op een manier die aansluit bij het ERP-pakket en eindgebruikers te begeleiden om zich deze nieuwe werkwijze eigen te maken. Maar dan begeven we ons weer op het niveau van de projectarchitectuur (de realisatie van een stukje architectuur).

Een ander principe in deze categorie is het principe “Kopen over maken”. Hoewel dit principe organisaties kan behoeden voor bijvoorbeeld debacles zoals geschetst in het vorige hoofdstuk kan het funest zijn voor organisaties die moeten excelleren op innovatie om zicht te onderscheiden van de concurrentie. De directe slachtoffers vallen bij de medewerkers van de R&D-achtige afdeling die zich beknopt zullen voelen in hun mogelijkheden.

Enterprise architecten houden zich ook vaak bezig met de technische infrastructuur. Bekende richtlijnen op dit gebied zijn bijvoorbeeld: "Integratie via de centrale broker", "Servers zijn gevirtualiseerd" en "Servers zijn gecentraliseerd". En ook hier vallen er mogelijk slachtoffers. Zo zullen er systemen zijn die niet zo eenvoudig via de centrale broker te koppelen zijn; ook zullen er systemen zijn die slechter presteren als ze in een virtuele omgeving draaien. En gecentraliseerde servers hebben de vervelende bijkomstigheid dat als het fout gaat het ook goed fout kan gaan. Ging het eerst om een paar decentrale slachtoffers; nu gaat het opeens over een heleboel slachtoffers; al snel een catastrofe. Natuurlijk zijn er van allerlei voorzieningen te treffen om de kans hierop tot een minimum te beperken, maar toch.

In toenemende mate begeven enterprise architecten zich ook op het gebied van de business architectuur. Als daar grote blunders worden gemaakt kan dit de organisatie de kop kosten. Neem een principe als “Volledige transparantie”. Dit kan resulteren in enorme stromen aan onbetrouwbare stuurgegevens waarop vervolgens wel gestuurd gaat worden. De eerste slachtoffers zijn de goedbedoelende medewerkers die waarheidsgetrouw de juiste cijfers rapporteren; zij presteren niet op niveau. Dit kan bijvoorbeeld tot gevolg hebben dat de arbeidssatisfactie zover daalt dat medewerkers – vaak degene die de organisatie het minst kan missen - eieren voor hun geld kiezen en bij de concurrent gaan werken. Een ander principe in deze categorie is bijvoorbeeld “Zelfbediening waar mogelijk”. In veel gevallen kan zelfbediening een prima en vaak goedkoop alternatief zijn. Maar niet iedereen wil zichzelf bedienen; niet iedereen kan zichzelf – zonder onevenredige inspanning - bedienen en het kan wel eens heel onvoordelig zijn om schaars kapitaal in te zetten om zichzelf te bedienen.

En zo heeft ieder principe net als de romeinse god Janus twee gezichten. Mijn tip is dan ook om bij de beoordeling van principes niet alleen te kijken naar de rationale (waarom het verstandig is om voor dit principe te kiezen) maar ook naar de contra-rationale (waarom het onverstandig is om voor dit principe te kiezen). Doet u dit niet dan vallen er geheid zo af en toe onbedoeld slachtoffers. U bent gewaarschuwd.

Oorzaken van falende architectuur

Ik durf na deze korte verkenningstocht dus wel te stellen dat er slachtoffers vallen zowel op enterprise als project niveau. Er valt wel iets te zeggen voor een meldpunt voor slachtoffers van architectuur; al was het maar om er lering uit te trekken. Voor de volledigheid wil ik nog noemen dat ik een groep slachtoffers buiten beschouwing heb gelaten en dat zijn de architecten zelf.

In zijn reactie op een eerdere versie van dit artikel noemt Jan Truijens een waarschijnlijk belangrijke oorzaak van falende architectuur, te weten: de neiging van architecten om hun modellen als werkelijkheid te zien. Hij illustreert dit met de volgende vergelijking:

"In Nederland is een uitgebreid rioleringsnetwerk, keurig ontworpen, uitgetekend, aanbesteed en in gebruik genomen. Meestal is het zo ontworpen dat maar één of twee keer per jaar de capaciteit te gering is en geloosd moet worden op het oppervlaktewater. Maar de praktijk is anders, door wortelingroei, verzakkingen, niet-deugdelijke bouw, gebrekkig onderhoud, e.d. Toch worden vrijwel alle beslissingen op basis van het model genomen, terwijl steekproeven aan het licht brengen dat hier en daar de riolering zelfs geheel verdwenen is. Die ongemakkelijke werkelijkheid toch!"

Een fraaier besluit had ik zelf niet kunnen schrijven. Dank Jan!

[PDF]

Opmerking

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

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 29 April 2012 op 11.31

Geschreven door Jan op 12-11-2010 21:14

Interessant artikel met verrassende inzichten.

Jammer dat er niet echt een concreet voorbeeld gegeven kan worden van een falende architectuur die écht tot slachtoffers leidt.

Nu ik dit zo schrijf, vraag ik me af hoe het zit met het verhaal achter het nieuwe systeem van de politie. In de media wordt gesteld dat het systeem niet werkt en ook niet zal (kunnen) werken. Lijkt mij typisch een geval van een falende architectuur. Mede ook omdat er door verschillende partijen over gerapporteerd is dat het ontwerp niet deugt.

Iemand die hier concrete informatie over heeft?

Reactie van Stichting Digital Architecture op 29 April 2012 op 11.30

Geschreven door Marc Lankhorst op 13-11-2010 13:13

Leuk stuk. M.i. is de huidige trend naar het gebruik van "principes" in architectuurland reuze gevaarlijk in dit opzicht. Je noemt een aantal goede voorbeelden van de manier waarop dit mis kan gaan. Principes hebben de connotatie van universeel geldige "normen en waarden" en juist dat leidt tot ongelukken. Misschien is het niet toevallig dat in ons calvinistische landje architectuurprincipes zo populair zijn.

En daar komt nog bij dat veel principes zo hoog over zijn dat ze blijven steken in het genre vrome wensen, goede voornemens en open deuren. Zie bijv. de NORA...

Een goede architect beoordeelt elke situatie op zijn merites en draagt vanuit zo'n analyse bij aan een goede oplossing, maar komt niet aanzetten met het argument "dat is nu eenmaal het principe". Kortom, gooi die principes aan de kant en denk zelf na!

Reactie van Stichting Digital Architecture op 29 April 2012 op 11.29

Geschreven door Hans der Kinderen op 17-11-2010 20:08

Boeiend artikel, grotendeels mee eens, maar wel wat kanttekeningen. Zo is de vraag of de architect schuldig of verantwoordelijk is voor overdemand, verkeerde technologie of misplaatste ambitie. Een collega van me noemde dat heel treffend "architectural debt", het al dan niet bewust afwijken van de doelarchitectuur. Architectural debt kun je kwantificeren door de (herstel-)schade achteraf die je oploopt door het niet volgen van de doelarchitectuur. De veroorzaker ervan zou je moeten kunnen afrekenen op die schade, alhoewel dat niet altijd even makkelijk te realiseren is. Helaas is het zo dat de doelarchitectuur een bewegend doel is, en dat "damage control" dan ook een belangrijke taak van de architect is!

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