Architectuur/Leerboek/zandbak

Dit is een voorlopige versie van een leerboek, uitsluitend bestemd voor studenten en medewerkers van de Radboud Universiteit. ©2012 all rights reserved

Hanno Wupper et al.

Architectuur voor de digitale wereld

Vooraf

Voorwoord

In de informatisering gaat voortdurend van alles mis. Landelijke projecten t.w.v. tientallen miljoenen lopen jaren vertraging op en worden regelmatig zonder resultaat afgeschreven. Als al iets opgeleverd wordt, werkt het vaak niet of slechts gedeeltelijk. En als het al werkt is dat vaak op een dergelijk complexe wijze dat het door de gebruikers geboycot of gesaboteerd wordt. We accepteren dit zoals we onweersbuien accepteren, alsof het onvermijdelijk is. Maar dat is het niet. De IT is geen natuurgeweld, het is mensenwerk. Mensen geven de opdracht tot het maken van iets, mensen voeren die opdracht uit, mensen gebruiken de zo gemaakte systemen, mensen leiden al deze mensen op.

Dat betekent dat u, beste lezer, mede verantwoordelijk bent: u als beslisser, die wellicht op ondoorgrondelijke rapporten van technici vertrouwt en niet met uw gezond verstand doorvraagt; u als ouder of leraar, die jongeren op de uitdagingen van de maatschappij alert kan maken; u als student, die door de keuze van een minor of een afstudeerthema meer inzicht in deze problemen kunt krijgen; u als scholier, die een interessante en nuttige studie wil kiezen, maar misschien nog niet weet wat interessant en nuttig is; en ook u als IT-er, die mischien de eigen mogelijkheden en beperkingen beter wil begrijpen en leren dat bepaalde problemen ook anders aangepakt kunnen worden. En, niet te vergeten, u als belastingbetaler en kiezer, die de ellende zelfs dan mede in stand houdt als u een leven zonder IT-producten op een alternatieve boerderij leidt.

Dit boek richt zich daarom tot u, of u nou meent wel of geen verstand van de IT te hebben. Geen zorg: het is niet de zoveelste computercursus, het gaat nauwelijks om techniek en zeker niet om weetjes over apparaten en programma's. Technisch jargon zult u hier niet aantreffen, wel een beroep op uw gezond verstand, uw nieuwsgierigheid en uw algemene vorming. Het gaat om de beoordeling van kwaliteit. Over kwaliteit moet men met elkaar praten, samen goed kijken en op zijn eigen gezond verstand minstens zo sterk vertrouwen als op aanbevelingen van deskundigen. Het gaat erom, de juiste vragen te stellen en niet te vroeg in technische oplossingen te denken. Met de juiste vraag ligt misschien een eenvoudigere, elegantere oplossing voor de hand dan techneuten u willen aandragen. Kennis van de onderliggende techniek kan bij de beoordeling van kwaliteit en het vinden van de juiste vraag helpen maar kan ook afleiden. Veel belangrijker is de kennis en ervaring waarmee de mensheid sinds vele eeuwen het maken van ingewikkelde artefacten aanpakt.

Dit boek begint even verderop zo als het hoort met een inleiding. Maar voordat u daaraan begint, nodigen we u uit tot een excursie naar een wereld, die schijnbaar weinig met de IT te maken heeft: de wonderbare wereld van een paar duizend jaar architectuur. U mag deze excursie gerust overslaan.

Dr. Hanno Wupper heeft al tijdens zijn studie wis- en natuurkunde bijgedragen aan de oprichting van het nieuwe vakgebied informatica, was betrokken bij de ontwikkeling van programmeertalen en enige grote computersystemen, was als onderzoeker in de informatica steeds meer geïnteresseerd in de vraag, wat men eigenlijk moet ontwerpen en bouwen dan in de vraag hoe men dit moet doen als men eenmaal weet wat men wil. Zijn informaticaonderwijs schoof van theoretische en programmeervakken steeds meer op richting toegepaste logica en architectuur. Als docent en onderwijsdirecteur heeft hij ook ervaring in onderwijsontwikkeling en onderwijsmanagement en was betrokken bij de ontwikkeling van IT-systemen die dit ondersteunen.

Dank aan Daan Rijsenbrij, Erik Proper, Dirk van der Linden, Angelika Mader, Royce Benda, Erik Barendsen, Jos Huls, Kees Waaijman, Gregor Terbuyken, David Jansen, ...

Excursie: Bouwen met steen, staal en glas Bouwen ligt de mensheid in het bloed. Sommige bouwwerken zo als de piramiden, de Chinese Muur, Tempels, Paleizen, Romeinse waterleidingen, dijken en hele steden staan er al vele honderd, soms enige duizend jaren. Bouwwerken kunnen uiterst complex zijn. Bekijkt u eens een barok operahuis, ook achter de schermen, of een modern cruiseschip! Onwaarschijnlijk veel onderdelen zijn daar precies op de juiste manier samengevoegd. Veel verschillende technieken zijn gecombineerd. En men heeft met onwaarschijnlijk veel dingen rekening houden. Wolkenkrabbers moeten bijvoorbeeld bestendig zijn tegen aardbevingen, en wel graag in één keer goed. Bouwen is erg moeilijk. Mislukkingen in de bouw zijn van alle tijden, maar men deed altijd zijn best, om ze te voorkomen. Daarom kent de mensheid al een paar duizend jaar het beroep van architect of bouwmeester. Dat is iemand die het hele proces van de eerste ideeën tot en met de oplevering en ingebruikname van het bouwwerk met zijn vakmanschap begeleidt. Dankzij zijn opleiding beheerst hij niet alleen materiaalkunde en theorie, hij kan ook uit een paar duizend jaar ervaring met het bouwen putten. Een goede architect weet dat men beter niet begint met het construeren van een gebouw voordat men weet wat werkelijk nodig is, dat men uiteenlopende belangen moet behartigen en dat ontwerp en uitvoering met de grootste zorgvuldigheid moeten gebeuren. Een burgemeester die een nieuw gemeentehuis nodig heeft, weet wel beter dan aan een bevriende aannemer te vertellen wat hij wil. Hij schakelt een architect in, alleen al omdat hij weet dat in andere steden architecten gemeentehuizen hebben ontworpen die landelijk en internationaal bewonderd worden, maar ook omdat hij en zijn ambtenaren helemaal niet zo precies weten wat nodig is, dat een aannemer daarmee aan de slag kan. De meeste gebouwen van een periode lijken op elkaar. Men volgt de traditionele manier van bouwen, want die heeft haar waarde bewezen. Men volgt de mode, want dat is de weg van de minste weerstand. En dan verrijst opeens een gebouw dat revolutionair anders is. Later kan men dan in architectuurboeken lezen dat een beroemde architect hiermee het begin van een nieuw tijdperk heeft gemarkeerd. Zo'n architect heeft in zijn studie de beheersing van nieuwe technieken en nieuwe soorten materiaal geleerd. Hij heeft ook opgemerkt dat de maatschappij in beweging is: normen en waarden, geloofsovertuigingen, de wetenschap en de manier van leven veranderen. Hij kijkt om zich heen, kijkt ook in andere landen en culturen en komt opeens met een gebouw dat de opdrachtgever helemaal niet had verwacht. "Nee, sire, U krijgt van mij geen burcht met donjon, want de middeleeuwen zijn voorbij. We hebben hier nu renaissance, al begrijpt U het nog niet. We worden wakker, en het is aan U, door me dit nieuwe renaissanceslot te laten bouwen, om uit te stralen dat U bij de tijd bent." Als dat renaissanceslot, hoe ongewoon het ook wezen moge, goed functioneert, niet snel instort en ook nog eens adembenemend mooi is, wordt de architect beroemd, en velen volgen hem na. Dat kan overigens een tijd duren, want niet iedereen heeft door dat meterdikke muren niet langer functioneel zijn en vindt zo'n renaissanceslot te licht. De cultuurgeschiedenis kent vele namen van architecten en nog meer bouwwerken van naamloze architecten die zichtbaar en tastbaar hebben gemaakt dat een nieuw tijdperk met nieuwe normen en waarden, nieuwe techniek en wetenschap en een nieuw begrip van de positie van de mens in de samenleving aangebroken was. Niet voor elke architect is het weggelegd een nieuwe stijl in te luiden. Nog veel meer architecten doen nuttig werk in stilte. Wie zeker weet dat hij precies zo'n huis nodig heeft als zijn buurman bewoont, kan het bij dezelfde aannemer bestellen. Maar weet men het wel zeker? Een onafhankelijke architect is ervoor opgeleid om goed te luisteren en de bouwheer voor fouten te behoeden. In onze maatschappij weten in elk geval bouwheren die maatwerk nodig hebben, dat ze zonder goede architect een groot risico lopen. Architectuurgeschiedenis (de spot over mislukkingen inbegrepen) hoort bij de algemene vorming. In de boekhandel liggen stapels boeken over architecten en hun werk – niet veel mensen zullen deze boeken voor hun beroep nodig hebben, maar genieten ervan omdat het een erg interessant stuk cultuur is. En wie kent niet ten minste een paar namen van beroemde architecten? Wie bewondert niet de scheppingen uit dit vak? Bijvoorbeeld het Haags Gemeentehuis of de Erasmusbrug in Rotterdam: besproken in alle media, ook in internationale architectuurtijdschriften, vergeleken met andere gemeentehuizen en bruggen, door de bewoners van de stad vol trots getoond aan bezoekers. Ja, de Erasmusbrug had een kinderzekte en begon en een storm te trillen. Ook dit kreeg weel aandacht. Het kon op behoorlijk elegante manier verholpen worden, en daaruit heeft men voor toekomstige constructies geleerd. Al dit is, nota bene, onderdeel van de algemene vorming en beschaving. Journalisten, die zelf geen bouwvakkers of bouwingenieurs zijn, schrijven voor lezers die dat ook niet zijn. Mensen hebben nu eenmal belangstelling voor de kwaliteit van bouwwerken. Nu schijnt het tegenwoordig in de bouw in Nederland niet goed te gaan met architecten. Het overgrote deel van de huizen wordt zonder architect gebouwd. Dat verbaast niet. De meeste nieuwe huizen lijken op elkaar. Als je één ontwerp meerdere keren uitvoert omdat de klanten geen maatwerk verlangen, hoef je natuurlijk niet bij elke uitvoering opnieuw een architect in te schakelen. Ook lezen we regelmatig dat beroemde architecten fouten maken of in hun arrogantie iets opleveren wat niet bruikbaar is. Dit neemt niet weg dat de architectuurgeschiedenis tot op heden een geschiedenis is van beroemde namen en fascinerende, grensverleggende gebouwen van hoge kwaliteit. Ook bij het maken van een IT-systeem moeten onwaarschijnlijk veel onderdelen op precies de juiste manier worden samengevoegd. Ook hier moeten uiteenlopende technieken en theorieën worden gecombineerd. Ook hier moet men allereerst goed erachter komen, wat eigenlijk nodig is en rekening houden met mensen en omgevingsfactoren. We zullen in dit boek laten zien dat er veel overeenkomsten zijn tussen het bouwen met steen, staal en glas en het bouwen met hard- en software. Maar hoeveel namen kent u van mensen die hun merites op vergelijkbare manier in de digitale wereld verdiend hebben? Waar zijn de gemeentelijke of landelijke IT-systemen, die men vol trots aan bezoekers toont? Is de ov-chipkaart met al die paaltjes een toonbeeld van landelijke trots? Bill Gates is overigens geen voorbeeld. Hij werd beroemd als zakenman die de hele wereld domineerde met de producten van zijn bedrijf, maar niet als bedenker en ontwerper van iets van uitzonderlijke kwaliteit. In de bouwwereld van steen, staal en glas zijn architecten een onmisbare schakel. In de IT-wereld blijft hun plek te vaak leeg. Daardoor blijft de kwaliteit van veel systemen achter bij wat mogelijk en wenselijk is, en daarover maakt zich de maatschappij te weinig druk. Een verklaring is misschien dat de grootste delen van IT-systemen onzichtbaar zijn. Men kan er niet samen naar kijken en ze zo bewonderen en beoordelen als men paleizen en bruggen kan bekijken en beoordelen. De sterke en zwakke kanten van een IT-systeem ervaar je pas als je er intensief mee werkt. Daarom zullen we in dit boek regelmatig tast- en zichtbare gebouwen als voorbeelden gebruiken. Wat erbij goed dan wel mis kan gaan is namelijk hetzelfde.

Inleiding

Het nieuwe communicatiesysteem van politie en hulpdiensten, ontwikkeld om ook dan te werken, als gewone mobieltjes niet meer werken, begaf het juist bij de eerste ramp. Het elektronisch patiëntendossier komt niet van de grond.De introductie van het biometrisch paspoort liep enorme vertraging op.De ov-chipkaart kwam veel later dan gepland en zorgt voor irritatie, belemmert de doorgang van de ene helft van Leiden naar de andere en bracht ons naast elkaar staande paaltjes van verschillende vervoerders, waar de reiziger allerlei handelingen moet verrichten die je aan een buitenlander niet kunt uitleggen. Een enorm ambitieus systeem voor de arbeidsbureau's en sociale diensten in heel Duitsland bleek bij oplevering totaal onwerkbaar. Het lijkt erop dat vrijwel alle grote landelijke IT-projecten mis gaan, met het systeem voor belastingaangife als uitzondering.

Bij bedrijven schijnt het beter te gaan. Veel commerciële websites werken behoorlijk. Maar sommige komen knullig over, andere flitsend, en pas bij nader inzien kan een flitsende website knullig blijken en een knullige degelijk. Dat is de buitenkant. Als binnen een organisatie een nieuw systeem word geïntroduceerd, leidt dit regelmatig tot onrust, tegenwerking, soms zelfs tot boycot door de medewerkers. De lezer kent vast voorbeelden uit zijn eigen omgeving.

Om zo'n IT-systeem te maken moeten onwaarschijnlijk veel onderdelen – stukjes hardware en software – precies op de juiste manier worden samengevoegd. Kennelijk lukt dit niet altijd. Op andere gebieden lukt het wél: we kunnen behoorlijk werkende stormvloedkeringen maken, vliegtuigen bouwen, we konden tot niet lang geleden treinen door het hele land laten rijden, op tijd, ook in de winter. Is het eenvoudiger, een stormvloedkering te maken dan een administratief computersysteem? Of ie er iets mis met ons kwaliteitsbewustzijn? Eisen we van IT-systemen minder kwaliteit dan van andere menselijke scheppingen? U betaalt voor een nieuwe versie van eenn besturingssysteem met het argument, dat daarin honderden, soms duizenden fouten verholpen zijn. Zou u betalen voor het verhelpen van constructiefouten in uw auto? Nee, als de maker een contructiefout ontdekt worden duizenden auto's teruggeroepen en wordt de fout verholpen. En een nieuw model automobiel dat onhandig in het gebruik is of slecht rijdt, zult u niet kopen, omdat het door de kritiek in de media is weggehoond.

Uitvluchten

Waarom gaat in de IT zo veel mis? Drie verklaringen worden steeds aangehaald.

Computers zijn er nog niet zo lang, en de informatica is maar een jonge wetenschap. Het moge zo zijn. Maar wij zullen hier laten zien dat er grote overeenkomsten zijn tussen het bedenken en bouwen van IT-systemen en van bouwwerken van steen, staal en glas. In beide gevallen moet men alles doen om het juiste probleem te pakken te krijgen, vaak complexe constructies ontwerpen om een antwoord op deze problemen te bedenken en systematisch nadenken over de belangen die spelen en de mensen die erbij betrokken zijn. De IT-wereld kan hier leren van de bouwwereld. Daar heeft men namelijk niet alleen bouwers die alle nodige technieken beheersen en met materiaal kunnen omgaan. Daar kent men sinds mensenheugenis architecten, die veel breder opgeleid zijn dan de bouwers en die met een bepaalde manier van meedenken en goed kijken helpen erachter te komen wat eigenlijk nodig is en bij welke belanghebbenden men welke vragen moet neerleggen. Hier weet men dat vooraf aan het ontwerpen en bouwen goed nagedacht en gecommuniceerd moet worden op een manier die gewone bouwers niet beheersen.

Het gaat bij IT-systemen om dynamisch gedrag, en dat is veel moeilijker dan statische structuren. Dat is waar. IT-systemen moeten het juiste doen en niet alleen er staan zo als een paleis of een brug. Maar hiervoor heeft de niet meer zo heel jonge informatica ondertussen goede theorieën, methoden en gereedschappen ontwikkeld. Alleen, die helpen niet als men het verkeerde probleem oplost of de nodige kennis niet toepast. Overigens gaan ook projecten mis waarbij dat dynamisch gedrag niets eens het probleem is.

De IT is zo ingewikkeld dat alleen experts het kunnen begrijpen. Dit is maar gedeeltelijk waar. Hoe een complex artefact met geavanceerde techniek gemaakt moet worden begrijpen alleen mensen die daarvoor opgeleid zijn, net als in het geval van cruise-schepen, orgels, stormvloedkeringen en vliegvelden. Toch kan iedereen die dat wil erover meedenken, hoe het cruise-schip of huis van zijn dromen eruit zou moeten zien, welke faciliteiten het zou moeten hebben enz. U doet dat ook als u een auto koopt. Ook de bouw van stalen bruggen is zo ingewikkeld dat alleen ervoor opgeleide ingenieurs dat beheersen. Maar toch praten bestuurders, beslissers, gemeenteraden en belangenorganisaties wel degelijk erover, wat voor soort brug met welke capaciteit van waar naar waar men precies nodig heeft en of die daarbij ook nog mooi mag wezen. Alleen bij computersystemen neigen veel menen ertoe, hun gezoend verstand uit te schakelen en alles over te laten aan "experts" die moeilijke gezichten trekken, ondoorgrondelijke woorden mompelen en onbegrijpelijke rapporten schrijven. De magiërs van onze tijd, waarbij de opdrachtgever niet eens kan beoordelen of ze hun vak beheersen en de ontwikkelingen hebben bijgehouden.

Dit zijn dus geen verklaringen. Om te begrijpen wat werkelijk mis gaat, moeten we beter — en vooral kritisch — kijken.

De digitale misère

Als een gebouw van beton een enkele keer instort, wordt de schuldige gezocht en verantwoordelijk gemaakt. Als de voicemail van leden van de regering op straat ligt, accepteren we dit schouderophalend zo als we een onweersbui accepteren. Als een duur systeem het door een constructiefout begeeft, betalen we voor een "update". Omdat men de bouw hier anders aanpakt.

Als voorbeed een scenario dat de lezer misschien uit zijn omgeving herkent. Iemand, die "last heeft van een automatiseringsprobleem" of moe is van het geklaag van zijn medewerkers, wil een "systeem" voor zijn organisatie of afdeling. (Voor wie onze excursie gevolgd heeft: Hij denkt helemaal niet aan een architect en kent er ook geen.) Hij doet zaken met een "informatiseringsbedrijf", een programmeur of het bedrijfsinterne rekencentrum. Niet zelden is deze opdrachtgever een oudere manager of overwerkte middenstander, die zijn knoppenangst verbergt door te zeggen trots erop te zijn, "geen computer nodig" te hebben, terwijl zijn secretaresse al zijn e-mailtjes uitprint. Of het is een bewindsvrouw die dag en nacht twittert en daarom meent, juist wél verstand van IT te hebben. Opdrachtgevers zien in elk geval flitsende webpagina's bij de desbetreffende maker en willen zoiets ook. Dat hun medewerkers daarmee niet kunnen werken omdat het lokale systeembeheer Flash (of een andere willekeurige soort software) "om veiligheidsredenen" verboden heeft, weten ze niet, en niemand die het hen kan en wil uitleggen. Opdrachtgevers zijn wel onder de indruk van het magische abracadabra van de maker, bijvoorbeeld: "to ensure your future flexibility, [we place] real emphasis on equipping your workspace with technologies that don’t involve restrictive ‘lock-ins’ and that can evolve as you do." De nieuwe kleren van de keizer! Niemand durft helaas te zeggen "leg nu eens in eenvoudige taal uit waar het om gaat".

In grotere organisaties begint het vaak met een wens van het hoofd van een der onderdelen (financiën, personeelszaken). Of dit hoofd wordt vooraf door het informatiseringsbedrijf benaderd om belangstelling voor het "systeem" te wekken. Omdat aanschaf van het systeem kostbaar is en het hoofd niet bevoegd hier zelf over te beslissen stapt hij met het voorstel van de informatiseerder naar de hoogste baas om hem te overtuigen van de noodzaak om dit nieuwe systeem aan te schaffen. Deze hoogste baas staat nog verder van de werkvloer en de bedrijfsprocessen waarvoor het systeem gebouwd moet worden, maar hij is wel degene die het uiteindelijke bouwbesluit moet nemen. Omdat hij over alle essentiële onderdelen van zijn organisatie de finale besluiten moet nemen en niet op alle gebieden een expert kan zijn, verlaat hij zich vaak op het advies van zijn ondergeschikten, zeker wanneer het zaken betreft die ook voor hem abracadabra zijn. Maar deze ondergeschikten hadden nooit de tijd en de opdracht om de technische ontwikkelingen in de IT bij te houden en kunnen zich door de informatiseerder alles laten vertellen. Die verspreidt dikke technische documenten, die de verantwoordelijken helemaal niet kunnen doorgronden, en in allerlei commissies wordt eindeloos over technische details vergaderd, waarbij lang niet iedereen zich iets kan voorstellen. Iedereen is bang om in de planningsfase fouten te maken. Dat vindt men bij IT-projecten normaal. Het is vergelijkbaar met het bestuur van een organisatie dat bij de aanbesteding van een nieuw hoofdkantoor erover vergadert of de wc-rol-houders ook bij alle nodige soorten wc-papier passen.

Neem de ov-chipkaart als voorbeeld. De opdrachtgevers en de vertegenwoordigers van het informatiseringsbedrijf zijn geen mensen die doordrongen zijn van ervaringen als reizigers in het openbaar vervoer. Ze reizen in een auto met chauffeur. Als ze een keer met de trein moeten reizen, regelt de secretaresse de kaartjes. Hoe goed hun bedoelingen ook zijn, aan zulke mensen kan men het bedenken van een systeem dat reizigers, ook incidentele ov-gebruikers en oude mensen moet helpen goed en zonder boete van a naar b te komen niet toevertrouwen. Ze laten zich daarom ook niet leiden door de kwaliteit van het reizen, maar door een secundair doel dat iets met afrekenen bij vervoerders te maken heeft. Vanwege de uiteenlopende belangen en de spraakverwarring worden bij de ontwikkeling de feitelijke gebruikers selectief of helemaal niet betrokken.

Uiteindelijk krijgt de opdrachtgever een systeem waarvan hij denkt dat het is wat hij meende wat het moest zijn. Zelf kan hij dat niet verifiëren omdat hij niet met computers werkt en de bedrijfsprocessen waarvoor het systeem gebouwd is niet kent. Als de gebruikers allerlei hiaten in het systeem ontdekken, functies missen en op grond daarvan steigeren, wordt het gebruik van het systeem uitgesteld om de maker in de gelegenheid te stellen (tegen meerprijs) de ontbrekende bouwstenen te leveren en krijgen de gebruikers (tegen meerprijs) een tijdvretende scholing om met de onvolmaaktheden van het systeem te leren omgaan. Om gezichtsverlies te voorkomen worden alternatieven gewoon verboden of onmogelijk gemaakt.

Valkuilen

We zien drie patronen die steeds weer leiden tot het falen van IT-projecten.

Oplossing van het verkeerde probleem. Men maakt ontwerpkeuzes en begint al aan de structuur van een concreet systeem zonder de probleemstelling goed te hebben geanalyseerd. Het opgeleverde systeem werkt misschien prima, maar blijkt niet te zijn wat echt nodig is. Het echte probleem te benoemen is soms moeilijk, en niet alle problemen verlangen dezelfde aanpak. Zelfs als een opdrachtgever duidelijk zegt wat hij wil, heeft hij misschien iets heel anders nodig. Technici zijn doorgaans niet opgeleid om uit te zoeken wat echt nodig is. Zij leveren wat gevraagd wordt. Opdrachtgevers en gebruikers hebben lang niet altijd het inzicht en de ervaring om hun werkelijke behoeften scherp te stellen, en ze kunnen niet beoordelen wat technisch mogelijk is.

Oplossing die geen rekening houdt met betrokkenen en de bestaande omgevng. Een systeem kan nog zo mooi bedacht zijn — als mensen er niet graag mee werken of als ze verkeerde taken moeten uitvoeren, zullen ze het systeem niet accepteren. Als ze gedwongen worden het te gebruiken, zullen ze fouten maken, tegenwerken of ziek worden. Een systeem dat niet aansluit bij wat er in de omgeving is leidt tot extra irritaties en overbodig meerwerk en is misschien onnodig duur.

Onvoldoende kwaliteit van de oplossing. Een IT-systeem moet niet alleen op het eerste gezicht doen wat nodig is, het mag geen fouten bevatten en mag het bij belasting niet begeven. Ook moet het misschien duurzaam zijn in een wereld, waar hardware voortdurend veroudert en waar millenniumwisselingen en schrikkeljaren aankomen. Dit is het domein van de technici en informatici. Daarvoor zijn ze opgeleid. Maar er zijn kwaliteitsverschillen. Oudere grote organisaties hebben bijvoorbeeld sinds de jaren zeventig van de vorige eeuw een eigen rekencentrum, dat feitelijk als intern aannemersbedrijf opereert voor alle digitale ontwikkelingen. Als zo'n rekencentrum in de organisatie een monopolie heeft, bestaat het gevaar, dat het scholing van medewerkers niet tot zijn taken telt en dat het niet kan inspelen op nieuwe technieken en methoden. Hetzelfde geldt voor bedrijven die in de begintijd van de informatisering zo succesvol waren dat ze geen tijd hadden om de ontwikkelingen bij te houden. Daar komt bij dat technici en informatici soms een wat eenzijdige blik op kwaliteit hebben. Een systeem moet namelijk niet alleen de juiste functionaliteit bieden, het moet ook rekening houden met menselijke factoren.

De opbouw van dit boek

Met dit boek willen we bijdragen aan een cultuuromslag door te laten zien hoe men anders dan meestal gebruikelijk naar IT-projecten kan kijken, hoe men ze beter kan aanpakken, hoe me niets vergeet wat een rol kan spelen en wat de kwaliteit van het eindproduct uitmaakt.

Het eerste deel, Beren op de weg, is vooral kritisch. Het beschrijft een aantal notoire gevaren en legt uit hoe deze vermeden kunnen worden. We bieden de lezer een eenvoudig begrippenstelsel om na te gaan, waarom bepaalde projecten moetsen of moeten falen.

Het tweede deel, "Kwaliteit", is constructiever. Het beschrijft een spectrum aan kwaliteiten die een goed systeem moet hebben. Het moet de lezer helpen, kwaliteit te beoordelen en naar kwaliteit te streven.

Het derde deel, "De architect", gebruikt de begrippen en observaties uit de vorige delen om de vraag te beantwoorden: Wat voor soort professionals zijn nodig, wat moet hun opleiding bevatten en wat kunnen ze dan allemaal betekenen?

Deel I. Beren op de weg

In elk hoofdstuk belichten we een ander aspect van de ontwikkeling of aanpassing van een systeem. De volgorde van hoofdstukken oriënteert zich, voor zover mogelijk, aan de fasen die bij het ontwikkelingsproces doorlopen worden.

Deze hoofdstukken hebben steeds dezelfde opbouw:

Een verkenning van projecten waar iets goed ging of juist faliekant mis ging. We zullen daarbij veel voorbeelden uit de bouwwereld van steen, staal en glas gebruiken. Die bouwwerken zijn sprekender dan de meestal onzichtbare IT-systemen, maar de problemen, valkuilen en kwaliteitsaspecten waar het om gaat zijn in beide werelden dezelfde.

Een analyse onder welke omstandigheden het mis moet gaan. Daarbij introduceren we enkele cruciale architectuurbegrippen, die helpen om een probleem te analyseren en de goede aanpak te kiezen of juist om uit te leggen waarom een aanpak verkeerd is.

Aanbevelingen voor een methodische aanpak. Deze aanbevelingen richten zich niet alleen tot mensen die daadwerkelijk een systeem willen bedenken en bouwen. Ze richten zich ook tot opdrachtgevers en verantwoordelijken en tot iedereen die in kwaliteit geïnteresseerd is: zo kunt u nagaan of een project goed aangepakt is.

Tamme problemen

Remscheid en de geboortestad van een van de auteurs, Solingen, grenzen aan elkaar, maar doordat de grensrivier, de Wupper, door een diep dal stroomt, moesten treinen 42 km omrijden. Rond 1890 besloot men daarom een spoorbrug van 107 m hoog van de ene stad naar de andere te bouwen. In 1897 was een stalen brug met 650.000 klinknagels klaar: de Müngstener Brücke, nog steeds de hoogste spoorbrug van Duitsland. Het ging in één keer goed. Net als bij de Eiffeltoren en vergelijkbare stalen bouwwerken mocht pas met de bouw worden begonnen nadat het ontwerp doorgerekend was: men wist dat de brug stabiel genoeg was om de treinen te dragen en wind, hitte en kou te trotseren. Ze staat er nu nog.

Staal had in de 19e eeuw voor de groei van de economie en de ontwikkeling van de maatschappij dezelfde betekenis die computers nu hebben. Toen ging het vooral om vervoer van mensen en goederen. Nu gaat het vooral om communicatie en gegevensverwerking. Toen en nu gaat het om bouwen: onwaarschijnlijk veel onderdelen samenvoegen tot een complex geheel dat doet wat het moet doen en het niet bij de eerste belasting door gebruik of omgevingfactoren begeeft. En ook hier kennen we indrukwekkende bouwwerken die het bij oplevering goed doen. Bijvoorbeeld draadloze telefoonsystemen voor een heel land. Of compilers, die programma’s uit de ene programmeertaal naar de andere vertalen.

Soms ging het ook spectaculair mis. Zo heeft Europa bijvoorbeeld al bij de start zijn raket Ariane 2 verloren. De projectleiding had voorgeschreven dat een bepaald onderdeel moest worden gebruikt dat al bij eerdere raketten zijn waarde had bewezen. Wat goed werkt moet men niet vervangen, was de gedachte. Net als elk computerprogramma kon dit onderdeel rekenen met getallen tot een bepaalde maximale grootte. Bij de nieuwe raket traden echter sterkere zijwaartse versnellingen op dan bij elk eerder model, waardoor de getallen te groot voor dit onderdeel werden. De resulterende rekenfouten leidden tot ontploffing van de raket. Het was een beetje alsof men in de Müngstener Brücke dezelfde boutjes had verwerkt die het eerder in talloze Meccanodoos-projecten goed hadden gedaan. Dit soort ongelukken leiden er in de informatica regelmatig toe dat betere theorieën en methoden voor het doorrekenen ontwikkeld worden. Zo had men bij het bewijzen van de correctheid van programma’s in het begin geabstraheerd van het feit dat getallen te groot kunnen worden voor een programma net zo als krachten te groot kunnen worden voor een bout in een stalen constructie. Na dat ongeluk was duidelijk dat men ook de maximale grootte van getallen overal moest controleren.

Het rationaliteitsvierkant

Bij het bedenken, doorrekenen en maken van zo’n brug en welk artefact dan ook spelen plannen een grote rol: beschrijvingen op papier of in de computer. Wat het nut van plannen is en welke we moeten onderscheiden, zien we, als we twee aspekten van artefacten onderscheiden: de structuur die gebouwd moet worden de eigenschappen die deze structuur moet hebben. Daarbij moeten we onderscheid maken tussen twee werelden: de fysieke realiteit en de beschrijvingen ervan. Twee aspecten in twee werelden. Twee maal twee is vier.

De gewenste eigenschappen in de fysieke realiteit. In ons voorbeeld gaat het erom dat treinen tussen Solingen en Remscheid zonder omweg kunnen rijden. De lezer moge zich 19e-eeuwse treinen met stoomlocomotieven voorstellen, met al hun geluid, stoom en rook. Of dat lukt, kan men na oplevering van de brug gewoon zien. Maar daarmee is men niet tevreden. Men wil zeker zijn dat het ook in de toekomst altijd zal lukken. Overigens kan het de opdrachtgever, in dit geval de Reichsbahn, niet schelen, of dit bereikt wordt met een stalen of een betonnen brug, met een Zeppelin of door nog uit te vinden teleportatie. Als het maar werkt en niet te duur wordt.

De daartoe gemaakte structuur in de fysieke wereld – een artefact. In ons voorbeeld de Müngstener Brücke, samengevoegd op precies de juiste manier uit duizenden stukken ijzer met honderdduizenden klinknagels.

Een specificatie van de gewenste eigenschappen op papier. Zo’n specificatie kan kort en bondig zijn, veel minder complex dan de brug zelf: per uur in beide richtingen zo veel zo zware treinen met een spoorwijdte van 1435 millimeter; bestendig tegen die en die milieuinvloeden. De specificatie moet voldoende informatie bevatten dat men kan beslissen of een oplossing eraan voldoet; met elke dergelijke oplossing zijn de betrokkenen tevreden. Als men per se een bakstenen brug wil hebben omdat die beter in het landschap past, moet dat ook in de specificatie worden opgenomen. Maar hoe minder in de specificatie staat, hoe meer mogelijkheden er zijn voor een creatieve, niet eerder bedachte oplossing. Specificaties kunnen ook als onderdeel van een contract gebuikt worden. Een specificatie die zo moeilijk te doorgronden is dat de opdrachtgever haar niet kan begrijpen is waardeloos.

Een blauwdruk van de structuur van het artefact op papier. Dit is meestal een dik document, alleen begrijpelijk voor mensen met de nodige opleiding: de ingenieur, de staticus en de bouwers. Het beschrijft tot in alle nodige details de structuur van de brug: welke onderdelen moeten precies op welke manier in elkaar worden gezet?

%%% tekening rationaliteitsvierkant %%%

Constructie

We noemen een probleem tam, als er een onomstreden specificatie is alsmede een manier om te controleren of een voorgestelde oplossing ook aan deze specificatie voldoet. In het geval van de brug kan men de treinen zien rijden en de berekeningen controleren.

Andere voorbeelden voor tamme problemen zijn: draadloos internet in een huis, levende mensen naar de maan en terug te brengen. Tamme problemen kunnen erg moeilijk zijn. Sommige wiskudige problemen, hoewel tam, zijn al eeuwenlang onopgelost. Maar als iemand met een oplossing komt, zal men na kunnen gaan, dat deze oplossing klopt door het bewijs te bestuderen.

Geef een ingenieur een tam probleem, bijvoorbeeld treinen van Solingen naar Remscheid te laten rijden. De ingenieur zal vragen hoe zwaar en hoe lang de treinen zullen zijn, hoe hard ze moeten kunnen rijden en hoe zwaar de zwaarste stormen en aardbevingen zijn waar hij rekening mee moet houden. Met andere woorden, de ingenieur verlangt een specificatie en vraagt zo lang door hij voldoende informatie heeft om aan de slag te kunnen. Dan maakt hij allerlei keuzes (staal of beton? tuibrug?) en tekent een ontwerp. Vervolgens laat hij een staticus dit ontwerp doorrekenen. Bij het ontwerpen en doorrekenen zijn materiaalkennis en diverse theorieën nodig, en het hele proces is duur. Maar dan weet men ook dat de brug, eenmaal conform dat ontwerp gerealiseerd, overeind zal blijven staan en de treinen dragen.

Dit noemen we constructie. Als alles goed gaat wordt het rationaliteitsvierkant een keer cirkelvormig doorlopen: van de gewenste eigenschappen een specificatie maken, van daaruit een blauwdruk bedenken, deze door een aannemer laten realiseren, en ziedaar – de gewenste eigenschappen zijn er. Na elke stap doet men er goed aan, zich te overtuigen dat het ook klopt.

Doorrekenen betekent: men overtuigt zich of de blauwdruk voldoet aan de specificatie. Als deze berekeningen stoelen op de juiste theorie en materiaalkennis, weet men dat elk artefact dat een realisatie van de blauwdruk is de gespecificeerde eigenschappen daadwerkelijk heeft. Zo moet het werken, en het werkt.

Bekwame informatici en IT-specialisten construeren net zo. Stel, de gewenste eigenschap in het echt is dat alle mensen in je huis draadloos het internet op kunnen via je DSL-verbinding, dan kan men een specificatie op papier zetten: niet afluisterbare, draadloze overdracht van TCP-IP-paketten tussen zoveel computers en een basisstation in een bepaald, wettig toegestaan radiofrequentiebereik. Nadat de ontwerper de nodige protocollen bedacht en een aantal creatieve keuzes heeft gemaakt, beschrijft een blauwdruk precies de nodige stukjes hardware (zendertjes voor de computers en het basisstation en alle nodige programma’s). Het artefact zelf bestaat dan uit stukjes hardware (een doos met het basisstation, kaartjes voor de computers) en de programma’s daarin en daaromheen.

Overigens gaat het in de praktijk vaak met vallen en opstaan: de cirkel wordt met voortschrijdend inzicht meerdere keren doorlopen. Maar aan het einde is er een specificatie, een blauwdruk, het ding zelf en de resultaten van het doorrekenen, alsof het in een keer goed gegaan was.

Als er iets mis gaat, en dat doet het in de IT-wereld helaas regelmatig, kan dat eraan liggen dat men het ontwerp onvoldoende doorgerekend of slordig gerealiseerd heeft. In de hoofdstukken over Utilitas, Firmitas en Venustas zullen we zien, waaraan allemaal aandacht besteed zou moeten worden.

Onze maatschappij beschermt zich met wetten en voorschriften zo goed mogelijk tegen constructiefouten, behalve op IT-gebied. De makers en verkopers dekken zich in met contracten die elke aansprakelijkheid uitsluiten. Zo koopt u uw hard- en software, en zo koopt de overheid voor tientallen miljoenen haar systemen. Zou u op deze manier een auto willen kopen? Kunt u zich voorstellen dat men in Nederland op deze manier, zonder statische berekeningen, met uitsluiting van aansprakelijkheid, kantoortorens zou mogen bouwen en verhuren?

Gemene problemen

Ingenieurs, informatici en de betere IT-ers zijn opgeleid om moeilijke tamme problemen op te lossen, en ze zijn daar erg goed in. Hun beroepsdeformatie is de drang om elk probleem te „temmen” zonder daarbij eraan te denken dat in de omgeving misschien nieuwe problemen ontstaan. Zo werden rivieren steeds rechter gemaakt, wat gunstig is voor de scheepvaart maar ons nu opscheept met overstromingen. Bij de Deltawerken vallen de nieuwe problemen nog mee, bij ontbossing en kerncentrales hebben ze tot rampen geleid. Zo werden in Berlijn en Jerusalem muren gebouwd, die weliswaar een probleem oplosten maar voor veel menselijk leed zorgden.

Als u in de betere kranten een ingezonden brief ziet in de vorm: „Het energieprobleem (allochtonenprobleem, klimaatprobleem, verkeersprobleem, geldprobleem) is eenvoudig op te lossen; men hoeft alleen een gracht van 10 m diep van A naar B te graven en te vullen met...” kunt u zeker zijn dat de brief ondertekend is door een prof. dr. ir. Het zijn allemaal aardige voorstellen, maar soms zijn de nevenwerkingen erger dan de kwaal die verholpen moe worden.

Maar het kan nog erger. Soms wordt helemaal geen probleem opgelost en zijn er alleen maar vervelende bijwerkingen. Zo kon Nederland eeuwenlang zonder DigiD bestaan. Sinds een paar jaar heeft de auteur precies een keer per jaar DigiD nodig, omdat hij anders zijn belastingaangifte niet elektronisch kan indienen. Hij is dan zijn wachtwoord vergeten of maakt van de zenuwen fouten bij het inloggen, waarop het wachtwoord gebokkeerd wordt. De aanvraag van een nieuw wachtwoord is een tijdrovende procedure, waardoor de aangifte te laat ingediend kan worden. En dan staat opeens in de krant dat DigiD door de belastingdienst verkeerd gebruikt wordt: het zorgt helemaal niet voor zekerheid, want je krijgt aangeraden om in geval van vergeten wachtwoord gewoon de login van een buurman te gebruiken. Het lijkt op IKEA, waar afsluitbare kasten van het model PS aangeprezen worden. Het zijn prachtige kasten, en elk deurtje heeft zijn eigen slot met eigen sleutel en eigen reservesleutel. Er zijn twee minpuntjes: als een deur open staat, valt het slot in de verkeerde stand, en als de deur door tocht dichtslaat, beschadigt de grendel de lak van het kozijn; en alle sloten zijn gelijk, ook over alle kasten heen. Als je je huis onderverhuurt kun je niet sommige deuren afsluiten en andere voor de gasten open laten. Je moet alle sleutels verstoppen, en als de gast ook een PS heeft, helpt zelfs dat niet. Een knop en een magneet bij elke deur zou net zo veilig maar makkelijker in het gebruik zijn.

Er zijn problemen die men niet eenvoudig kan temmen. Dit wordt door IT-ers en ingenieurs, die nu eens goe zijn in het oplossen van tamme problemen, een beetje geheim gehouden.

We noemen een probleem gemeen als we niet weten wat het probleem eigenlijk precies is. Er is onbehagen, dingen gaan niet goed, in het verleden zijn al allerlei oplossingen, regelingen, wetten, veiligheidsmaatregelen bedacht die het bij nader inzien steeds moeilijker en onoverzichtelijker maken. „De trage student” dan wel „de langstudeerder” is een voorbeeld. Dit probleem wordt tegenwoordig getemd met flinke boetes, waarbij alle studenten over één kam geschoren worden, terwijl niemand zich afvraagt wat eigenlijk de werkelijke motieven en belemmeringen voor sneller of langzamer studeren zijn. Zou het niet kunnen dat sommige opleidingen zo slecht onderwijs geven dat studenten daar langer over moeten doen dan nodig? Als ze bijvoorbeeld niet weten wat ze op het tentamen moeten kunnen, moeten ze de eerste keer aan het tentamen deelnemen om daar achter te komen. Pas dan kunnen ze doelmatig leren. Zou het niet kunnen dat sommige andere studenten, die hun gezin met een bijbaan moeten verzorgen, op halve kracht studeren? Dat ze per jaar maar de helft van de prakticumplekken, begeleiding en nakijkwerk nodig hebben en dus ook maar de helft kosten, maar daardoor twee keer zo lang over hun studie doen? Wat is daar mis mee?

Gemene problemen moet men anders aanpakken dan tamme problemen. Voor constructie is het nog veel te vroeg. De gemiddelde ingenieur of IT-er, bekwaam in constructie, is niet voor gemene problemen opgeleid; zijn kracht ligt juist in het focusseren op een tam probleem.

Probleemanalyse

Voor men overgaat tot bouw, verbouwing of sloop van iets, doet men er goed aan, alles in kaart te brengen wat men over het probleem weet. De tweemaal twee concepten van het rationaliteitsvierkant helpen, daarbij orde te scheppen en niets te vergeten.

De gewenste eigenschapen in het echt. Wat willen we eigenlijk bereiken, hoe is dit gedefiniëerd, welke domeinkennis hoort erbij? Wordt wat we willen bepaald door een artefact dat al bestaat? In welke omgeving dient het te functioneren?

In het geval van de Müngstener Brücke was dit duidelijk: een korte, snelle spoorverbinding tussen de stations van twee steden, aansluitend op het bestaande spoor. De domeinkennis omvat kennis over treinen en dienstregelingen, randvoorwaarden voor rails (stijging, ondergrond), de behoeftes van de steden en de mogelijkheden die het landschap biedt.

In het geval van langstudeerders is dit alles behalve duidelijk. Uit de media en de woorden van de politici is niet op te maken, wat men precies wil. Hier enige mogelijkheden: De kwaliteit van het onderwijs verbeteren? Minder uitval? Jongere afstudeerders met minder levenservaring? Goedkopere opleidingen? Minder studiefinancering? De paar procent studenten die verkeerd bezig zijn ontmoedigen? Voorkomen dat studenten naast het instampen van tentamenstof ook nog op ideeën komen?

In het geval van mobiel bellen is het weer eenvoudig: Men wil liefst waar men ook is met iedereen kunnen spreken. (Een informaticus zou daaraan automatisch toevoegen: zonder dat gesprekken afgeluisterd kunnen worden. Wie een keer in de openbare ruimte of het openbaar vervoer was, weet dat mensen juist hun best doen dat hun hele omgeving het gesprek kan volgen. Maar dit terzijde.)

De specificatie van de gewenste eigenschappen op papier. Een kort, leesbaar document op basis waarvan men kan beslissen of men dit wil en op basis waarvan men een contract met een ontwerper en bouwer kan sluiten. Als zo’n specificatie inderdaad specificeert wat men wil, is het probleem getemd. Als men moeite heeft, het eens te worden over zo’n specificatie, is het probleem waarschijnlijk gemeen. In elk geval kunnen opdrachtgevers, gebruikers, organisaties en partijen hun tanden in zo’n document zetten om erachter te komen of men dit werkelijk wil. Het gaat er in dit stadium van probleemanalyse niet om, zo’n specificatie te schrijven en het erover eens te worden; het gaat erom, vast te stellen of er op dit moment een is.

Voor de spoorbrug hebben we dit al uitgelegd. Voor mobiel bellen gaat het om de toegestane frequenties, de afluisterbaarheid en de belasting van milieu en gezondheid. Andere zaken als GSM-masten, protocollen, afrekening enz. hebben in de specificatie niets te zoeken, dat zijn implementatiebeslissingen die in de blauwdruk thuis horen.

In het geval van langstudeerders zou de opdrachtgever met de billen bloot moeten. Gaat het alleen om een financiële besparing? Als het om meer gaat, zal vast meer domeinkennis nodig zijn: waarom studeren mensen hoe lang en welke voor- en nadelen heeft dit voor de studenten, de universiteiten en de maatschappij?

Het artefact in het echt. Om welk fragment van de realiteit gaat het? Waar bevindt het zich? Is het er al, moet het verbouwd, uitgebreid, gesloopt, aangepast worden? Welke domeinkennis is nodig om het te maken en aan te passen?

De nodige domeinkennis betreft bij de brug staalbouw, spoorbouw, topografie, bodemmechaniek, winddruk, milieuregels enz. Bij mobiele telefonie gaat het om computers, elektromagnetisme, radio, landschapsbehoud enz. Bij langstudeerders is de nodige domeinkennis erg omvangrijk. Het onderwijslandschap kent talloze regelkringen en afhankelijkheden, en de gevolgen van ingrepen zijn moeilijk te doorgronden. Uiteindelijk heeft men, gespeend van elke domeinkennis, gekozen voor een simpel artefact: Wie langer dan X jaar studeert, betaalt een forse boete.

De blauwdruk van de structuur van het artefact op papier. Dit dikke document is resultaat van het ontwerpproces en bevat alle nodige informatie om het artefact (in het geval van IT een combinatie van hard- en software) te realiseren. Als een artefact verbouwd of uitgebreid moet worden, dient het als uitgangspunt voor het ontwerp van de aanpassingen. Een blauwdruk richt zich tot technici en is zonder technische kennis niet te doorgronden en daarom niet geschikt voor onderhandelingen met opdrachtgevers en gebruikers. De blauwdruk kan wel gebruikt worden om het ontwerp door te rekenen t.o.v. de specificatie voor men tot realisatie overgaat.

Spoorwegmaatschappijen hebben traditioneel hun dingen op een rij. Het hele bestaande systeem is precies beschreven. Zodra men plant iets te wijzigen of uit te breiden, treedt een procedure in werking om na te gaan dat dit geen gevaarlijke consequenties heeft. Stel dat ergens tussen twee plaatsen A en B een snelheidbeperking gold omdat de biels niet meer helemaal betrouwbaar waren, en stel dat de rails nieuw gelegd zijn. De snelheidsbeperking op dit vak zou nu kunnen vervallen. Maar ondertussen zijn er misschien snellere locomotieven beschikbaar dan voor de vernieuwing. Daarom mogen de snelheidsbordjes pas weggehaald worden als alles opnieuw doorgerekend is. Waarom? Omdat misschien ergens elders de afstand tussen een sensor en een slagboom vergroot moet worden om de slagbomen ook met de nieuwe locomotieven op tijd omlaag te krijgen. Overigens kwamen deze blauwdrukken van het spoor goed te pas bij de planning van de deling van de Berlijnse S-Bahn binnen één nacht.

In bedrijven en organisaties wemelt het ondertussen van IT-systemen. (We komen daarop terug onder de kop „Onzichtbare functionaliteit”.) Elk nieuw systeem betekent een ingreep in het samenspel van deze systemen. Om de consequenties te kunnen voorspellen heeft men de blauwdrukken van al deze systemen nodig – als die er zijn.

Wat helaas vaak voorkomt is dat de beoogde bouwers en de opdrachtgevers van een IT-systeem niet weten wat een specificatie is en de blauwdruk gebruiken als specificatie. Omdat opdrachtgevers zo’n document niet kunnen lezen worden ze bang en laten het doorgronden over aan hun techneuten. Echter, deze techneuten kennen misschien het hogere doel helemaal niet. Opdrachtgevers en gebruikers kunnen beter een dik document met veel jargon en formules weigeren tot er een heldere, begrijpelijke specificatie ligt.

Misschien blijkt daarbij dat eigenlijk niemand goed weet wat in de specificatie zou moeten staan. Dan gaat het vast om een gemeen probleem. Dan is het te vroeg voor de constructie van het complete systeem. Dat moet men het probleem anders aanpakken.

Behoedzaamheid met visie

Stel, u wilt de informatisering van uw organisatie vernieuwen. Eindelijk moet er een groot systeem komen waar alles nodige mee gedaan kan worden. Op dit moment is er een wildgroei aan systemen, wordt er inefficiënt gewerkt, maar u heeft nog geen helder beeld van wat het nieuwe systeem allemaal zou moeten kunnen. Of, nog gevaarlijker, u of uw automatiseerder heeft een helder beeld, maar misschien klopt dit beeld niet en wordt het geplande nieuwe, dure systeem helemaal niet iets waar uw organisatie iets aan heeft. U ziet overal voorbeelden, waar dit soort omvattende projecten mis gaan.

Er zijn voorbeelden waaruit men kan leren.

Steve Jobs, een van de weinige grote architecten op IT-gebied, heeft met de Macintosh zo’n voorbeeld gegeven, waaruit we meer kunnen leren dan uit menig ingewikkeld, duur organisatieadvies. Jobs wilde een computer voor persoonlijk gebruik voor iedereen maken. Hij (FS: wist?) wat kwaliteit is zo als in de volgende hoofdstukken beschreven. Hij wist dat computers in principe universele machines zijn. Maar niemand wist op dat moment, hoe de ideale persoonlijke computer eruit moest zien. Er kwamen allerlei soorten printers op, er waren beeldschermen met kleur, er waren talloze niet met elkaar compatibele apparaten en verbindingen (herinnert u zich SCSI nog?). Alles scheen te kunnen, maar alleen nerds konden in deze warboel iets voor elkaar krijgen. Steve Jobs wilde een computer niet voor nerds maar voor mensen die goed werk willen doen en geen tijd verklungelen met half begrepen techniek.

Op dat moment werd overal geëxperimenteerd met grafische gebruikersinterfaces en muizen. Maar het echte werk deed je met behulp van commando’s in de ene of andere besturingstaal en zestien functietoetsen. Wie een stukje van zo’n taal met dubbele punten en backslashes iets beter begreep dan anderen, gold snel als specialist en werd bewonderd zo als men vroeger magiërs bewonderde. De eerste Mac bleek opeens zo’n besturingstaal helemaal niet te kennen. Je kon alleen iets doen met icoontjes in vensters op het scherm. Je hoefde alleen maar een klein aantal concepten te kennen: icoontjes voor je floppies, mappen, bestanden (iets waar gegevens in staan) en programma’s (iets wat iets doet met de gegevens in bestanden), de prullenbak, menu’s die zich aanpassen, klikken, dubbelklikken en slepen. Negen concepten, maar twee meer dan het ideale aantal dat een mens goed kan overzien.

Dit apparaat werd door nerds verspot. Je kon er alleen mee werken maar geen magie beoefenen. Niet jij kon ermee indruk maken op je medemensen, het ding zelf maakte indruk. Vooral op mensen als secretaressen, schrijvers en typografen, die gewoon hun werk wilden doen. Voor deze groepen werkte alles veel beter dan op de machines van de concurrentie.

We zien hier vier kenmerken van een succesvolle aanpak van gemene problemen.

In der Beschränkung zeigt sich der Meister. Probeer niet in een keer alles op te lossen. Focus op iets wat op korte termijn ten minste een deel van de doelgroep helpt en lever snel iets op dat werkt. In het geval van de eerste Macintosh betekende dit concreet: geen commandotaal, alleen grafische besturing; alleen zwartwit (want kleur was nog niet goed begrepen en zorgde overal voor tijdverspilling en buitengewoon lelijke printouts), radicale “what you see is what you get”, waarbij de pixels op het scherm precies overeenkwamen met die van de naaldprinter; beeldscherm zo breed dat Amerikaans en Europees briefpapier er in de breedte op schaal op past; laat de mens geen dingen doen die de computer beter zelf kan doen. Voor dit laatste enkele voorbeelden: Als het gevaarlijk is, de computer uit te zetten of een floppy eruit te trekken terwijl nog bewerkingen aan de gang zijn, kun je beter de knoppen om iets uit te zetten of eruit te halen weglaten en de computer vertellen wat je wilt. Hij zal dan het nodige afwerken en vervolgens de floppy uitwerpen of zich uitschakelen. Niet de gebruiker moet onthouden in welk “drive” (A: of B:) welke informatie steekt en welke printer toevallig in welke poort geplugd is. Nee, floppies en printers hebben een naam, en de computer zoekt zelf uit hoe hij het object met de gewenste naam moet adresseren. Je hoeft geen functietoetsen (F0 t/m F15) uit je hoofd te leren, want in begrijpelijke menu’s wordt op elk moment getoond wat je op dit moment kunt. Deze principes zijn al bijna een specificatie van een tam probleem.

Wat we doen doen we goed. Helaas zijn we er ondertussen aan gewend dat IT-systemen fouten bevatten en moeilijk te gebruiken zijn. De bouwers sluiten elke aansprakelijkheid uit en voor verbeteringen moet men extra betalen. Dit is gewoon, maar het kan wel degelijk anders. Juist door zulke zelf opgelegde beperkingen in functionaliteit kan men dat, wat men in eerste instantie gaat maken, goed laten maken. Wat „goed” in de IT betekent, wordt in de volgende hoofdstukken uitgelegd. Het heeft niet alleen met functionaliteit te maken, maar ook met stabiliteit, duurzaamheid en, jawel, schoonheid. Gebruikers zullen iets dat mooi is en een aangename uitstraling heeft, beter accepteren en er liever mee werken. Alleen sommige nerds vinden het stoer dat ze met lelijke, omslachtige dingen omgaan. We herinneren ons dat al de eerste Macintoshes meteen prima werkten en voor veel minder problemen zorgden dan bepaalde andere personal computers, dat de paar dingen die je toen moest leren om ze te gebruiken tegenwoordig nog gelden, en dat over het design en de uitstraling goed nagedacht was. Deze apparaten werden toen omarmd door zetters en typografen, die teleurgesteld waren door de omslachtigheid en concurrerende producten en de typografische lelijkheid die ermee geproduceerd werd. Jobs had namelijk door Hermann Zapf speciale lettertypen laten ontwerpen die juist met de grove resolutie van toenmalige beeldschermen en printers er mooi uitzagen. Ook de icoontjes en zelfs de lijsten van de vensters waren door een kunstenaar vormgegeven en niet alleen door een programmeur in elkaar gezet.

Laat je leiden door visie. Het meesterschap van de beperking heeft twee kanten. Je kunt dankzij de overzichtelijkheid van het project kwaliteit leveren. En je kunt rustig nadenken over wat je voorlopig weggelaten hebt en hoe dat er later bij kan. Enige visie op het totale landschap, d.w.z. de omgeving van je systeem, en op toekomstige ontwikkelingen helpt daarbij. De eerste Macintosh kende alleen zwart en wit. Zijn processor was zo langzaam dat hij een venster, wat de gebruiker wilde verslepen, niet in real time kon bijhouden. Er werd alleen een gestippeld kader versleept; het hele venster verscheen pas na afloop. Maar de rekenkracht en capaciteit van computers verdubbelt eens in de anderhalf jaar, en spoedig verschenen Macs met zestien grijstinten. En later wel degelijk met kleur. En het bleek dat de oude vensters en lettertypes zo ontworpen waren dat ze op een natuurlijke manier met die zestien grijstinten mooier werden, maar herkenbaar bleven. En dat de vensters niet snoepkleurig werden toen kleur eenmaal kon maar minimalistisch elegant bleven. Ook nieuwe soorten printers en beeldschermen en nieuwe soorten netwerken kon je met nieuwe Macs gebruiken. Soms duurde het een tijd en was de concurrentie voor, niet altijd kon je elke printer aansluiten, maar je kon steeds meer, en wat werkte, werkte prima.

Stel je plannen bij. Steve Jobs heeft beslist in het begin niet de hele toekomst voorzien. Zijn visie was beperkt. Maar hij heeft continu geleerd uit de ervaringen met zijn eigen producten en die van anderen. Toen iemand het concept drag and drop had uitgevonden of het communicatieprotocol TCP/IP bedacht, kwamen er programmeurs, die voor de Mac een extensie maakten waarmee het ook kon. En enige systeemversies later was die extensie niet langer nodig, omdat de vernieuwing in het systeem zelf ingebouwd was.

Een aanpak met deze vier kenmerken kun je niet overlaten aan doorsnee informatici en programmeurs van de oude stempel, omdat er in hun opleiding en beroepspraktijk te weinig aandacht aan besteed is.

We moeten wel op de hoede zijn om bij deze behoedzame aanpak niet op het verkeerde deelprobleem te focussen. Daarover gaat het volgende hoofdstuk.

Verkeerde problemen

In 1974 huurde de auteur van zijn eerste salaris de zolder van een boerderij uit 1764, met uitzicht op een kerk uit 1100. Het was een goede plek en een goed huis, maar er was geen keuken. Twee kamers, een redelijke badkamer, een ruime hal, maar geen keuken. Nu kun je overal een koelkast en een paar kookplaten plaatsen, en er was ruimte in de hal, maar daar was geef afvoer voor water. In een oud, bewoond huis kun je niet zo maar een stortleiding door een aantal verdiepingen trekken en op het riool laten uitkomen.

De vorige huurders hadden dit binnen hun mogelijkheden goed opgelost. Ze hadden een keukenblok met gootsteen geplaatst en een koperen waterleiding uit de badkamer getrokken naar een kraan boven de gootsteen en in het gootsteenkastje een groene plastic emmer onder de afvoer gezet. Dat is een prima noodoplossing. Als je er nog een fornuis en een koelkast bij zet, kun je prima koken en afwassen. Alleen moet je van tijd tot tijd de emmer naar de badkamer dragen en ledigen. Niks mis mee binnen de gegeven beperking.

Daar had men het echter niet bij laten zitten. Een emmer naar de badkamer dragen is niet elegant. En je moet eraan denken voor hij overloopt. Daar had de huurder iets op gevonden. De emmer had net boven zijn bodem een tap van messing gekregen die verbonden was met een aquariumpompje, dat het water uit de emmer door een transparante, groene aquariumslang langs de plinten naar de badkamer pompte, aan de achterkant van de wc omhoog en onder de bril door. Zo kon je de inhoud van de emmer elektrisch de wc in pompen.

Nu de besturing nog. Natuurlijk moest het automatisch, want men neigt ertoe, de emmer te vergeten tot hij overloopt. Toen de auteur het appartement overnam, vond hij in de emmer een drijvende blok kurk, met twee schroefoogjes geleid door twee ingenieus aangebrachte breipennen. De kurk kon alleen op en neer, maar niet uitwijken. Op de kurk een stuk aluminium, verbonden met de ene pool van 230 Volt wisselstroom. Bij hoge waterstand drukte de kurk deze connector tegen een streep blik, die de stroom naar het pompje leidde, dat met de andere pool verbonden was. Een drijfschakelaar. Hij werkte nog ook, en de waterstand in de emmer werd automatisch verminderd.

Er waren wel wat minpuntjes. Er bleef altijd een flink 'bodempje' vies water in de emmer, waarin algen groeiden en waarop vet dreef. Dientengevolge was de transparante slang van binnen verschimmeld en neigde tot verstopping. De emmer stonk. De elektrische schakelaar was levensgevaarlijk. Om over bacteriën niet te praten.

Als dit een IT-project was geweest, was het als volgt verder gelopen: Het elektrische veiligheidsprobleem had men opgelost met een slot en een waarschuwingsbord op de deur van het kastje en een scholing van de huisvouw hoe hiermee om te gaan. met een sleuteladministratie als gevolg. Het hygiënische probleem had men opgelost door een dispenser voor een desinfectiemiddel, het vetprobleem door een tweede dispenser voor een detergent. Beide moeten natuurlijk door de drijfkurk en een teller aangestuurd worden. Na zoveel cycli zal het desinfactiemiddel c.q. het detergent op zijn, dus moet er ook nog een waarschuwingssysteem bij, liefst gekoppeld aan een to-do-lijst, die vervolgsn niet compatibel blijkt met het agendasysteem van de huisheer. Een volkomen tamme uitdaging, die uiteindelijk tot een prachtig, hoogcomplex systeem leidt. Omdat de huisvrouw het niet meer begrijpt en de huisheer geen tijd heeft, komt er dan ook nog een onderhoudscontract bij, net als bij een verwarmingsketel of leaseauto. Het e.e.a uiteraard gekoppeld aan de inboedel- en aansprakelijkheidsverzekering.

Gelukkig had de auteur en nieuwe huurder natuurkunde gestudeerd en zag hij meteen dat het putje van de gootsteen een handbreed hoger was dan de wc-bril. De nodige theorie: communicerende vaten. Het enige wat aangeschaft moest worden, was een verloopstuk van gootsteen naar slang, en het water liep vanzelf af. Emmer, drijfkurk, pompje, schakelaar konden weg. Ook de vervolgprojecten omtrent isolatie, desinfectie en detergentie bleken onnodig. Als je één keer per dag de vaat wast in de gootsteen en het hete sop in een klap laat afvloeien zonder omweg over een bestuurde emmer, wordt de slang steeds schoongespoeld. Deze eenvoudige, natuurkundig verantwoorde constructie heeft nog jaren prima gewerkt, tot eindelijk het huis verbouwd en een echte afvoer gelegd werd. Die bevroor overigens elke winter, maar dat is een ander verhaal.

Wat kunnen we leren uit dit waar gebeurde verhaal? Toen de auteur deze vraag onlangs stelde in een workshop voor managers, kwamen twee kernachtige antwoorden. Ten eerste had de auteur dit ongeschikte appartement helemaal niet moeten huren. Ten tweede had de verhuurder moeten verbieden dat er een keuken bij gemaakt werd, want dat was niet de bedoeling. Oneigenlijk gebruik.

Zo denken en werken managers tegenwoordig. Met oogkleppen recht op het doel af. En het doel is huurgeld incasseren zonder rompslomp. Maar de auteur wilde daar nu eenmaal graag wonen. Omdat het er mooi en behaaglijk was. Het gaat hier niet om doortastend management en stevige huurcontracten, het gaat om de oplossing van het echte probleem.

Het keukenblok met gootsteen was met visie neergezet tussen koelkast en oven: ooit zou daar een volledige keuken staan. Dat was een goede, duurzame investering. Het echte probleem was: het water moet uit de gootsteen. De emmer was bij gebrek aan beter inzicht en middelen een prima noodoplossing. Daarmee is helemaal niets mis. Al eeuwen worden emmers gebruikt om water van de ene plek naar de andere te verplaatsen, en voor een goed functionerende gootsteen in een verder prima appartement in een schitterend landschap heb je het er wel voor over om een keer per dag met een emmer naar het toilet te lopen.

De verkeerde afslag werd genomen toen men zich op het ledigen van de emmer concentreerde in plaats van op het ledigen van de gootsteen. De keerzijde van de noodoplossing werd als het primaire probleem gezien en aangepakt. Waarbij de slang een zinvolle keuze was: bij gebrek aan vaste riolering gebruikt men tijdelijk slangen. De emmer en het dragen ervan als noodopossing had meteen kunnen worden vervangen door de slang: ook nog een noodoplossing, maar een stuk eleganter en makkelijker. Door de slang echter op de emmer en niet op de gootsteen aan te sluiten werd een zwaartekrachtprobleem geïnroduceerd met een prompje als noodoplossing op de eerdere noodoplossing. Daardoor creëerde men een vetprobleem en een hygiëneprobleem, die om extra noodoplossingen vragen.

We noemen in het vervolg een noodoplossing op een noodoplossing een emmer-pompje-slang-oplossing, afgekort EPS-oplossing. In de IT wemelt het ervan.

Het hele ov-chipkaart-gebeuren is één en al EPS. Men wil dat mensen goedkoop en gemakkelijk kunnen reizen, en men wil de buschauffeurs niet met onnodig werk opzadelen en niet blootstellen aan rovers, die het op geld hebben afgezien. De landelijke strippenkaart was een prima noodoplossing, maar had wel nadelen, met name voor de vervoerders. Die nadelen, die de reiziger niet kunnen schelen, zijn het resultaat van eerder gemaakte keuzes: privatisering en concurrentie in combinatie met subsidies. Er moest dus een verbeterde strippenkaart komen, niet een beter doordacht openbaar vervoer. Inchecken in plaats van afstempelen. Helaas met uitchecken als gevolg, iets dat mensen nu eenmaal vaak vergeten. Ondertussen hebben we anonieme chipkaarten, chipkaarten op naam, poortjes, paaltjes, een opstaptarief, soms twee paaltjes naast elkaar om bij de ene vervoerder uit- en bij de andere in te checken, een klachtenlijn, een procedure voor mensen die vergeten uit te checken, hele nieuwe soorten fraude, ruzie over de manier hoe je in Leiden van het gedeelte van het centrum voor het station naar het gedeelte achter het station kunt lopen zonder daarbij in- en uit te checken, en ruzie over het feit dat mensen die gratis mogen reizen dankzij hun abonnement toch beboet worden als ze vergeten in te checken. Hoe mak moet een volk zijn dat dit alles accepteert? Incidentele reizigers mijden het openbaar vervoer omdat ze niet meer snappen hoe het werkt. Je kunt makkelijker een buitenlandse reis met visum, inentingen en valuta regelen dan in Nederland voor het eerst ov gebruiken. Terwijl men in andere landen nog wel overal kaartjes kan kopen die bij alle vervoerders in de regio geldig zijn.

Ook het Nederlandse paspoort en de indentiteitskaart hebben een hoog EPS-gehalte. Je pasfoto mag niet op het gemeentehuis worden genomen. In plaats daarvan zijn er specificaties hoe de foto er precies moet uitzien. Als een burger zich zelf fotografeert, precies conform de specificaties, durft de ambtenaar de foto niet te accepteren omdat zij de specificaties niet begrijpt. Als de foto in het hoesje van een fotograaf zit, wordt zij geaccepteerd, ook al voldoet ze niet. Althans, zo was het toen de auteur zijn vorige paspoort ophaalde. Nu gaat het anders: de fotograaf maakt een digitale foto, werkt haar op een beeldscherm bij en print haar op postzegelformaat uit. De burger draagt de foto naar het gemeentehuis, waar ze gescand wordt en een computerprogramma beslist of ze voldoet of niet. Als ze niet voldoet, bijvoorbeeld omdat het hoofd ietsjes te groot is, kan dit programma de fout niet corrigeren. De burger moet terug naar de fotograaf. Er is een regeling wie in dit geval voor de kosten moet opkomen en een geautomatiseerd systeem om de wachtrijen bij het loket te optimaliseren.

Bouwwerken en regels

Bij elk bouwwerk horen specifieke regels voor gebruik en beheer, die de ontwerper samen met het bouwwerk ontwerpt, tenzij ze al door de wet voorgeschreven zijn. Bij het Nederlandse wegennet horen de regels van de wegenverkeerswet. Veel kruisingen werken alleen omdat we rechts moeten rijden. Als we links zouden moeten rijden, zouden de stoplichten anders geplaatst moeten worden. Een gevangenis werkt alleen als de deuren ook daadwerkelijk op slot gehouden worden. De mooiste prullenbakken in de openbare ruimte werken averechts, als ze niet regelmatig geleegd worden.

Spotify laat alleen nog maar nieuwe gebruikers toe wanneer ze een Facebook account hebben.

De regels bij ons eigen huis kennen we, omdat de belangrijkste regels voor huizen overal dezelfden zijn: regelmatig een laagje verf, bevriezen van waterleidingen voorkomen, bij regen de ramen sluiten enz. enz. Bij auto's krijgen we een dik boekje. Een deel van de inhoud is de gebruiksaanwijzing, maar er zijn ook hoofdstukken vol regels die we moeten opvolgen, willen we recht op garantie houden.

Bij grotere gebouwen gaat het soms mis. Het oude faculteitsgebouw van de auteur werd opgeleverd met een prachtig systeem van wegwijzers die goed leesbaar waren en bij de architectuur pasten. Alleen was in de hele organisatie niemand ervan doordrongen dat bij verhuizingen of veranderd gebruik van een zaal een hele reeks van wegwijzers aangepast moet worden. Rijkswaterstaat heeft daar vast routines voor, maar in onze faculteit wist niemand, bij wie je een verhuizing moest melden, en al helemaal niemand, hoe men al die wegwijzers van nieuwe opschrift zou kunnen voorzien. Na verloop van tijd bedacht dan een nieuwe decaan of directeur, dat er een systeem van wegwijzers of plaatjes of plattegronden moest komen om de oriëntatie te verbeteren. Dat werd er dan bij gehangen. Aan het eind waren er vier van zulke systemen in uiteenlopende staat van veroudering.

Vergeten regels. IT-systemen worden bijzonder graag opgeleverd zonder dat de ontwerper of bouwer op de bijbehorende regels hamert. Een klassieker is de homepage van een bedrijf of organisatie. De opdrachtgever is blij met een flitsende web-site, de maker laat zich ervoor betalen en druipt af. Na verloop van tijd blijkt dat de informatie op deze mooie web-pagina’s verouderd is, en er moet iemand worden ingehuurd om ze te actualiseren.

Een maker van zo’n website, die zijn verantwoordelijkheid neemt, zegt tegen de opdrachtgever: let wel, bij elke interne verhuizing moeten kamer- en telefoonnummers aangepast worden; op de pagina „over ons bedrijf” staat dat u 317 verschillende tangen produceert, dat moet u aanpassen als het niet meer klopt; hier een boekje waarin alles staat wat regelmatig gecontroleerd en aangepast moet worden. Maar heeft u ooit zo’n boekje gezien?

Zonder zulke regels wordt een product snel waardeloos. Als de maker zijn verantwoordelijkheid neemt en ze keurig meedeelt, heeft de opdrachtgever drie keuzes. Hij kan afzien van het systeem, althans van sommige functies, bijvoorbeeld van het tonen van het aantal producten of van kamer- en telefoonnummers; dit zou al veel milieuvervuiling door verouderde webpagina’s en dolende bezoekers voorkomen. Hij kan een afdeling aanwijzen die de site actueel houdt, en de kosten in de begroting opnemen. Of, in het beste geval, hij komt op het idee dat die informatie al ergens in een systeem van zijn bedrijf of organisatie staat en dat er alleen een verbinding gelegd moet worden. Dan blijft de getoonde informatie vanzelf actueel. Hierop komen we in een later hoofdstuk terug.

EPS-regels. Als medewerkers er last van hebben dat de informatie in zo’n bedrijfseigen systeem verouderd is, kan van alles gebeuren, zoals we in een later hoofdstuk zullen zien. Bijvoorbeeld houden ze het uit ellende zelf bij, zonder dat dit tot hun taak hoort. Ze zijn daarmee gratis pompjes, met alle bedrijfspsychologische gevolgen van dien. Of ze maken een eigen systeem om hun werk te kunnen doen en boycotten dat van de organisatie. Of ze overtuigen de baas dat er een nieuwe regel moet komen: alle medewerkers zijn geacht om hun eigen telefoonnummer op de bedrijfseigen website bij te houden. Arme medewerker! Eerst wordt hij door promotie, demotie, interne verhuizing of vernieuwing van de telefooncentrale gedwongen om aan een nieuw telefoonnummer te wennen dat iemand anders voor hem bedacht heeft, en dan moet hij het ook nog zelf op de website zetten. Dat gebeurt natuurlijk niet, en dan komen er weer nieuwe regels bij. Noodoplossingen op noodoplossingen op noodoplossingen.

Je treft dit verschijnsel tegenwoordig ook bij landelijke organisaties aan. Bijvoorbeeld bij het goederenvervoer op het spoor. Eigenlijk is het heel eenvoudig. De domeinkennis van rails en treinen leert dat als en trein een bepaald vak in maar nog niet uit gereden is, die trein nog in dat vak moet zijn. Wie rekening wil houden met het spontaan verdwijnen van een hele trein kan met een beetje domeinkennis uit de natuurkunde (E = m c²) beredeneren dat de daarbij horende flits zelfs door de multinationale directie in Singapore waargenomen zou moeten worden. Men kan dus gewoon bijhouden waar treinen zijn. Toch wordt in Nederland in 2012 een vrij primitief detectiesysteem gebruikt dat door de weerstand tussen twee rails te meten kijkt of er een trein is. Een noodoplossing, want kennelijk lukt dat bijhouden niet meer. Nu is onlangs een locomotief „van het scherm verdwenen” zonder dat er sprake was van een lichtflits. Nadere inspectie leverde op dat de locomotief er wel degelijk nog was. Sinds die tijd, zomer 2012, is er een regel bij gekomen: om zichtbaar te blijven voor de noodoplossing mogen locomotieven niet meer zonder wagons rijden. Er moet altijd minimaal een wagon aan hangen om de weerstand tussen de rails te verlagen.

Bomen en bos

Hoe kun je voorkomen, met noodoplossingen op noodoplossingen bezig te zijn? Onder andere door de vergeten regels boven water te halen en de bekende regels kritisch tegen het licht te houden. En door alert te blijven.

Blik scherpen. Wie eenmaal een blik voor EPS-oplossingen heeft ontwikkeld, ziet ze overal. Daarom zijn we hierboven zo lang doorgegaan over voorbeelden, en daarom voegen we er nog een voorbeeld en twee oefenopgaven aan toe. Je kunt leren ze meteen te herkennen. Natuurlijk wordt je dat door de bedenkers ervan niet in dank afgenomen. Daarmee moet men kunnen leven.

Een laatste voorbeeld. In de collegezalen van de universiteit van de auteur hangen prachtige grote krijtborden, gewaardeerd door elke wetenschapper, maar men heeft bespaard op waterkraan en gootsteen. De docent kan de spons niet schoonmaken en zijn handen niet wassen. Dus moet er twee keer per dag per zaal een bakje met water worden neergezet en een handdoek voor de docent klaargelegd. Veel docenten laten nu de spons in het bakje liggen, want anders zou men hem op het mooie houten designmeubilair moeten leggen. Dus gaan die sponzen schimmelen. Dus liggen er nu geplastificeerde briefjes met het verbod, de spons in het bakje te laten liggen. En dat allemaal in een bèta-faculteit. Andere docenten missen iets om het bord zonder water te vegen of iets om een nat bord droog te maken en misbruiken de handdoek daarvoor, waardoor deze later wel geschikt is om je handen te witten, maar niet om ze af te drogen. Je kunt zo’n handdoek misschien niet in de ring gooien, maar wel naar het hoofd van een kletsende student, waardoor het fijnstofgehalte van de plaatselijke lucht toeneemt.

Oefenopgave: Sinds mensen op hun werk niet meer mogen roken, doen ze dit buiten bij de ingangen. Dus liggen daar overal peuken. De Universiteit Twente heeft daarom het roken binnen en straal van 50 m rond alle ingangen verboden. Andere organisaties hebben weer andere oplossingen bedacht. Let daar eens op.

Oefenopgave: Je medemensen kun je m.b.t. de inrichting van hun huis in twee groepen indelen. De ene groep heeft op de dag van de verhuizing de bank, de kasten en de tafel neergezet op de plek waar ze jaren later nog staan en alle problemen opgelost door geleidelijk staande lampen, verlengsnoeren, kamerschermen, bijzettafeltjes, krantenhouders, lopers, extra kussens, een extra radiootje enz. enz. toe te voegen, waardoor het geheel steeds rommeliger („knusser”) wordt. De andere groep streeft continu naar helderheid en eenvoud en arrangeert met voortschrijdend inzicht de hele inrichting af en toe nieuw.

Doorvragen. Als opdrachtgevers en toekomstige gebruikers zeggen wat ze wensen, komen ze vaak met EPS-achtige wensen. Ze zijn gewend, hun werk binnen een systeem van noodoplossingen te doen en wensen verbetering. Sterker nog: sommige medewerkers en hele afdelingen zijn zelf pompjes. Daarom moet men doorvragen: „U wilt het pompje niet droog laten vallen? Maar waartoe dient het eigenlijk?” – „Ah, en waarom moet die emmer zo dringend leeg? Waarvoor dient hij?”

Natuurlijk kun je niet oneindig doorvragen. Er moet ook eens iets gebeuren. Waar houdt men op met doorvragen? Dit heeft te maken met de principes van de organisatie, met de omgeving en met wat er op dit moment in de organisatie al is. Hierop zullen we in de volgende hoofdstukken nog uitgebreid ingaan.

Onverstand

Wie een spoorbrug wil ontwerpen moet verstand hebben van het spoor en van bruggen. De Müngstener Brücke toont al meer dan honderd jaar aan dat het kan. Om in het land te blijven: Wie een stormvloedkering wil ontwerpen moet verstand hebben van stormvloeden en waterkeringen. Rijkswaterstaat is daarvoor wereldwijd beroemd. Wie een ov-chipkaart wil ontwikkelen, moet verstand hebben van openbaar vervoer en van chipkaarten. Wie een elektronisch patiëntendossier wil bedenken moet verstand hebben van elektronica en van patiënten en dossiers. Een kind kan het bedenken!

Hier een waar gebeurd voorbeeld. De opdrachtgever, het college van bestuur, wil een agendasysteem voor zijn universiteit. Secretaressen zijn te veel tijd kwijt aan het rondmailen van datumbriefjes, daar moet iets aan gedaan worden. Op de werkplekken van de secretaressen staan Windows-computers. Opgeleverd wordt een agendasysteem met web-interface, dat het bij de demonstratie en bij medewerkerscholingen prima doet. Iedereen kan met de web-browser zijn eigen agenda beheren en zijn secretaresse daartoe machtigen. Systeembeheerders zijn van hun baan verzekerd omdat ze heel precies kunnen instellen, wie in wiens agenda mag kijken. Na verloop van tijd blijkt tot ontsteltenis van de opdrachtgever, dat het prachtige systeem niet gebruikt wordt en iedereen er een hekel aan heeft. Eén reden daarvoor is dat lang niet alle docenten of hun secretaressen de moeite nemen om al hun colleges in deze agenda te zetten. Die staan namelijk al in een ander systeem in de organisatie: het zaalreserverings- en roostersysteem. De ontwerper van het nieuwe agendasysteem had verzuimd, deze twee systemen aan elkaar te koppelen, waardoor elke medewerker, hoe goed betaald ook, de taak van een pompje krijgt dat de roosters uit het ene naar het andere systeem moet overtypen. Omdat niet elke docent daarvoor tijd uittrekt, staan tijden waarop hij verhinderd is door collegeverplichtingen niet in de agenda. Een tweede reden is dat aan een universiteit veel mensen zo koppig zijn dat ze niet met Internet Explorer onder Windows willen werken. En deze prachtive web-interface werkt nu toevallig alleen met Internet Explorer, niet eens met Firefox onder Windows en al helemaal niet onder Linux of MacOS. En derde reden is dat veel medewerkers op hun laptops en smartphones iCal gebruiken, een systeem waarmee men comfortabel een aantal agenda’s tegelijk kan beheren en raadplegen. Deze mensen vertikken het om een enkele van hun diverse agenda’s altijd een webbrowser te moeten opstarten.

Domeinen

Je herkent in deze voorbeelden al dat het telkens om twee verschillende domeinen gaat, waar degene, die een oplossing wil bedenken, verstand van moet hebben. Er komt nog een derde bij.

Het toepassingsgebied. Wie de besturing voor een chemische fabriek, bijvoorbeeld een olieraffinaderij, wil ontwerpen, heeft het makkelijk. Hij weet heel goed of hij domein-expert van dit probleemdomein is of niet. De domein-expert van het probleemdomein chemische reacties is iemand die verstand heeft van scheikunde en procestechniek en het ook nog kan vertellen. Iedereen weet dat dilettanten op zo’n gebied niets voor elkaar kunnen krijgen. Wie niet zelf domeinexpert is, weet de juiste expert te vinden.

Wie een IT-systeem voor een universiteit wil ontwerpen of kopen dat academisch onderwijs moet ondersteunen, moet verstand hebben van het academisch onderwijs in de bewuste universiteit. Dat houdt veel in: niet alleen welke cursussen in welke studieprogramma’s door welke docenten gegeven worden maar ook welke visie er is omtrent openheid van lesmateriaal, hoe de gewenste academische attitude bij studenten bevorderd wordt, welke gewoontes, verwachtingen en voorkeuren docenten en studenten hebben, welke werkvormen gebruikelijk zijn en nog veel meer. Wie daar geen rekening mee houdt, maakt met het resulterende systeem werk- en communicatievormen onmogelijk die hun waarde bewezen hebben en dwingt docenten en studenten in een keurslijf – het ergste wat men creatieve academici aan kan doen. Anders dan bij chemische fabrieken dreigt hier een valkuil: iedereen die wel eens college gevolgd of gegeven heeft, heeft de neiging, zich domeinexpert te voelen en zijn eigen beeld academisch onderwijs te generaliseren. Terwijl er in dit gebied weinig mensen zijn die alle nodige domeinkennis expliciet voor de geest hebben en kunnen meedelen.

Ook bij de ov-chipkaart dreigt een valkuil. De opdrachtgevers vertellen vast precies hoe ritten in hun bussen, trams en treinen vroeger afgerekend werden en nu afgerekend moeten worden, waar men kaartjes kan laten opladen en wie wat wil administreren. Maar dit is alleen een fractie van de nodige kennis omtrent openbaar vervoer. Een systeem wordt alleen geacepteerd als het ook rekening houdt met de gewoontes en verwachtingen van de reizigers, de psychologie van mensen en met reispatronen. Ook hier is i.t.t. chemische fabrieken waarschijnlijk geen expert te vinden die alle nodige kennis kan meedelen. Er komt bij dat men zich kan afvragen of de mensen die beslissingen nemen en ontwerpkeuzes maken tenminste wat eigen ervaringen met ov hebben.

De techniek. Wie een biezer om een stoelzitting vraagt, krijgt vlechtwerk. Wie een looier vraagt, krijgt leer. Wie een timmerman vraagt, krijgt latjes. Allemaal omdat het „ademt”. De oplossing die je voor hetzelfde probleem krijgt, hangt af van wat degene kan, die je erom vraagt.

Het oplossingsdomein is in het geval van IT-systemen natuurlijk hardware en software. Ook hier geldt dat veel makers alleen verstand hebben van bepaalde soorten hard- en software. Ze hebben bepaalde technieken, talen en theorieën geleerd, beschikken over bepaalde gereedschappen, misschien hebben ze zelfs een contract met een groot bedrijf dat ze uitsluitend bepaalde technieken zullen gebruiken. De opdrachtgever en de beoogde gebruikers kunnen meestal niet beoordelen of de optimale keuze is gemaakt. Dan kun je ze makkelijk intimideren met een volmondige kreet als: „Microsoft is nu eenmaal standaard in het onderwijs.”

De omgeving. Wie wil dat zijn IT-systeem graag gebruikt wordt doet er goed aan, de omgeving te kennen, waarin dit systeem zich bevindt en de kansen te grijpen die deze omgeving biedt. We noemden hierboven al het iCal-probleem. Steeds meer mensen houden hun agenda op hun smartphone of laptop bij. Dit heeft allerlei voordelen. Men kan zijn agenda delen met de secretaresse. Men kan een hele reeks afspraken, bijvoorbeeld de concerten waarop men geabonneerd is, in een klap importeren – als ze tenminste in een geschikt formaat aangeboden worden. Men kan zelfs abonnementen op een flink aantal andere agenda’s nemen, bijvoorbeeld van je sportvereniging en het plaatselijke museum. Als daar iets gepland wordt, verschijnt het vanzelf ook in je agenda. Helaas weten veel beslissers en sommige IT-ers niet, dat dit kan en dat het betrekkelijk eenvoudig is om gegevens in de geschikte vorm voor import of als abonnement aan te bieden. Een programmeur heeft dit in twintig minuten voor elkaar. Wie dit niet aanbiedt maar zijn termijnen alleen op zijn webpagina toont, zadelt iedereen met volkomen onnodig overschrijfwerk op, waarbij dan ook nog eens onnodig fouten gemaakt worden.

Zo zijn er veel meer voorbeelden te bedenken. Vaak komt het zelfs voor dat de omgeving al de oplossing biedt die men nodig heeft en dat dus helemaal geen systeem meer gebouwd hoeft te worden.

Ken je kennis

Om een goed systeem te ontwerpen, te bouwen of te kopen heeft men dus kennis uit drie gebieden nodig. Soms zijn er domeinexperts; dan moet men die weten te vinden. Soms zit de domeinkennis onbewust in veel hoofden en in de gewoontes en tradities van een organisatie; dan moet die kennis expliciet gemaakt worden. De gemiddelde IT-expert is daartoe evenmin opgeleid als degenen die over de aanschaf moeten beslissen.

Spraakverwarring. Daar komt nog een probleem bij. De opdrachtgevers, de beoogde gebruikers en de bouwers van een systeem spreken doorgaans verschillende talen en zijn er niet voor opgeleid om elkaar te begrijpen. De opdrachtgever denkt misschien in termen van bedrijfsdoelen, geld, effectiviteit en uitstraling en uit dit in het jargon van zijn cultuur, de gebruikers hebben het vooral over het kleine segment van bedrijfsprocessen dat ze kennen, de bouwer wil het alleen over terabytes, protocollen en besturingssystemen hebben en praat daarover in technische termen die niemand begrijpt, maar die iedereen ontzag inboezemen.

Belangen

Bij elk bouwproject spelen uiteenlopende belangen, en allerlei mensen en organisaties proberen het project verschillende kanten op te trekken.

Een ideaal uit de middeleeuwen is voor sommigen nog steeds leidraad: De mensen van een stad of streek bouwen samen een kathedraal. Het gemeenschappelijke belang is een zo goed en mooi mogelijke kathedraal samen op te richten, te hebben, te gebruiken en te kunnen zien, en daarbij ook nog te leren en zich te ontwikkelen. Sommige burgers betalen veel meer dan anderen, sommige werken veel meer, anderen ontwerpen en bedenken nieuwe technieken, maar iedereen is in staat om te genieten van elke steen, elk ornament en elk nieuw inzicht dat door het bouwen is verkregen. Spiritualiteit is de drijfveer.

Geleerden hebben dit ideaal voor ogen als ze het over het bouwen van de kathedraal van de wetenschap hebben. Ook in de IT-wereld kennen we bouwwerken die bij benadering van dit ideaal tot stand kwamen, bijvoorbeeld: Linux, irc, html en www, Wikipedia en MediaWiki, Word Press. Dit ideaal en zijn kenmerken hebben vele namen: ambachtelijke kwaliteit, wetenschap, Bildung, vrijheid, onbelemmerde communicatie, zoeken naar de waarheid, wiskunde.

Maar als er echt iets gebouwd moet worden, leiden tegenstrijdige belangen tot ellende. De bouwheer wil voor weinig geld een indrukwekkend bouwwerk, liefst met een psychoanalytisch uiterlijk. De aannemer wil zijn asbest kwijt en moet mensen aan het werk zetten die alleen verouderd materiaal beheersen. De gebruikers willen er prettig in kunnen werken maar weten niet goed wat dat betekent. En de omgeving van het perceel wil misschien helemaal geen gebouw. Deze tegenstrijdige belangen komen nog bovenop de gemeenheid van problemen en de fixatie op verkeerde problemen en EPS-oplossingen.

Belanghebbenden

Bij elk bouwproject, al dan niet digitaal, kunnen we vier hoofdgroepen belanghebbenden onderscheiden. We hebben ze al eerder zien langskomen en zetten ze nu op een rij. Elke groep kunnen we verfijnen, indien nodig, maar ook zonder verfijning kunnen we tot de nodige inzichten komen.

De bouwheer. Dat is iemand die een bouwwerk voor een bepaald doel wil hebben en ervoor betaalt, liefst zo weinig mogelijk. Denk aan een staatssecretaris die een veilig paspoortsysteem wil hebben, een burgemeester die aan een nieuw gemeentehuis toe is, een koning die nog een paleis wil, een dorpsdokter die toch eens „aan de computer moet”, of een universiteitsvoorzitter die een uniform financieel beheerssysteem voor zijn hele universiteit wil. Redelijkerwijs kan men niet verwachten dat zo’n bouwheer verstand van bouwmateriaal, statica en voorschriften heeft, noch dat hij een heldere specificatie van het benodigde bouwwerk kan geven. Hij is er vaak niet voor opgeleid om te weten en uit te kunnen leggen wat de beoogde gebruikers van het bouwwerk eigenlijk precies doen. Wat hij in zijn eigen jargon zegt nodig te hebben is in de regel iets anders dan wat hij denkt nodig te hebben en weer iets anders dan wat echt nodig is. En vaak speelt uitstraling een grotere rol dan de beoogde functionaliteit. Daarom wil een bank bij elke fusie, splitsing en naamswijziging een totaal anders ogend hoofdkantoor. Dat is niet kwalijk, dat was altijd al zo.

De aannemer. Dat is iemand die tegen betaling ervoor zorgt dat een bouwwerk neergezet wordt. Soms wordt het van de grond af gebouwd, soms samengesteld uit componenten die men kan kopen en soms wordt een bestaand bouwwerk gerenoveerd. Aannemers willen zo veel mogelijk geld verdienen, en soms willen ze ook nog af van verouderd materiaal dat er nog ligt (giftige spaanplaten, oude versies van hardware, onveilige pasjes). Sommige aannemers kennen alleen een bepaald soort materiaal en kunnen niet zien dat het beoogde bouwwerk ook anders gerealiseerd kan worden. En zij weten net zo min als de bouwheer wat voor bouwwerk eigenlijk precies nodig is. Hun ideeën over gebruiksgemak (veel knoppen) kunnen behoorlijk wereldvreemd zijn. Als bouwers zijn ze bovendien niet opgeleid om het jargon van de bouwheer en de beoogde gebruikers te kennen en ze kunnen vaak niet goed aan leken uitleggen wat de voor- en nadelen van bepaalde bouwwijzen en materialen zijn. Ook dat was altijd al zo. Men moet een aannemer niet kwalijk nemen dat hij allereerst aan zijn eigen belangen denkt en van andere dingen weinig verstand heeft. Men moet hem alleen niet zomaar met een bouwheer zaken laten doen.

RadboudNet denkt niet aan zijn gebruikers en dwingt studenten om iedere dag op één van de twee portals met dezelfde naam te kijken of er toevallig nog nieuwe mededelingen gedaan zijn.

Google weet dat de gebruikers lui zijn en biedt ze daarom de mogelijkheid om niet eens hun mobiel te pakken. Een app kan vanaf de computer geïnstalleerd worden.

De gebruikers. Met de gezondheid en motivatie van de beoogde gebruikers staat en valt de acceptatie en het succes van een bouwwerk, of dat nou een gemeentehuis is of een informatiesysteem. Hier gaat het om veel meer dan ergonomie. Sommige gebruikers overzien veel beter dan de bouwheer hoe delen van het bouwwerk gebruikt moeten gaan worden, maar slagen er niet in dat aan hem uit te leggen. Andere gebruikers begrijpen niet eens hun eigen functie in een groter geheel en kunnen niet meer uitleggen dan dat het nodig is dat hier een stempel gezet en daar iets ingetypt moet worden. De verschillende groepen praten dan ook nog in uiteenlopende jargons en begrijpen elkaar niet altijd. De primaire gebruikers van een universiteitsgebouw of universiteitsinformatiesysteem zijn wetenschappers en studenten die een academische attitude en wetenschappelijke nieuwsgierigheid aan elkaar moeten doorgeven. Dat werkt niet als het bouwwerk ze behandelt als de bewoners van een legbatterij. En ze zullen een systeem voor de administratie van hun onderzoeksprojecten niet gebruiken, als dit systeem hun bij hun primair werk niet ondersteunt omdat het alleen in de behoeften van de financiële afdeling voorziet.

De omgeving. De mensen die in de omgeving van een bouwwerk wonen maar niet tot de gebruikers behoren, hebben er belang bij dat het bouwwerk hun leven niet verstoort. De plantjes in parken en tuinen hebben er belang bij, dat gebouwen geen zonlicht wegnemen. De wind heeft belang om te waaien en de aarde om af en toe te schudden of juist tot moeras te worden enz. Als een bouwwerk niet aan deze factoren aangepast is, zal zijn omgeving problemen veroorzaken. Onder "omgeving" vatten we dus alle omgevingsfactoren zoals mensen, omringende gebouwen, infrastructuur, natuur, wind en weer, wetten en voorschriften en belangenorganisaties samen. Aannemers hebben verstand van sommige van deze factoren (wind, weer, grond, infrastructuur) maar vaak niet van bijvoorbeeld het historische gezicht van een dorpskern. Bouwheer en aannemer zitten soms op een heel andere locatie, zelfs op een ander continent met een andere cultuur en kennen de omgeving van het bouwwerk niet goed.

De Müngstener Brücke doet het prima tussen Solingen en Remscheid maar zeker niet tussen Roodeschool en de Eemshaven: daar is de grond te slap, en vooral ontbreken bergen om de constructie te dragen. In Rusland zou de brug zelfs in een geschikt berglandschap niet bruikbaar zijn, omdat daar de treinen en sporen te breed zijn. De omgeving zorgt voor allerlei eisen en beperkingen maar biedt ook mogelijkheden. Een goede ontwerper verkent de omgeving en laat ze meewerken bij een creatieve oplossing. In de IT-wereld gebeurt dit nog onvoldoende. Als de opdrachtgever een systeem voor een bepaald doel in zijn organisatie wil, wordt lang niet altijd gekeken naar de bestaande systemen, de mogelijkheden die het internet biedt en naar de laptops en smartphones die de meeste medewerkers al hebben.

Belangenverstrengeling

Deze vier groepen van belanghebbenden kent men ook in de bouwwereld van steen, staal en glas. Daar is het een van de belangrijkste taken van de architect, om ze in evenwicht te houden en hun belangen enigszins af te stemmen. In de IT-wereld is dit helaas nog niet gebruikelijk. Daarom gaat het vaak mis.

We kunnen een aantal verschijningsvormen van dit spanningsveld onderscheiden. Het is nuttig, ze te kunnen herkennen. Ze komen ook in de wereld van steen, staal en glas voor.

Eigenbouw. De bouwheer is tegelijk de beoogde gebruiker. Hij bouwt zonder aannemer en zonder architect wat hij nodig meent te hebben. Dat lukt meer of minder. Bezien we veel eigenbouwprojecten van een hoger niveau, kunnen we wildgroei observeren. Maar het komt ook regelmatig voor dat anderen zo onder de indruk zijn van een eigenbouwproduct, dat ze het bouwwerk kopen. De eigenbouwer, die geleerd heeft uit zijn ervaringen, bouwt opnieuw. Op deze manier kan hij in het gunstigste geval tot bouwend architect worden.

Wildgroei. Een organisatie heeft niemand die zich tot bouwheer geroepen voelt. Er is dan ook geen architect. Gebruikers bouwen maar wat in eigenbouw, als ze iets nodig hebben. Ze zijn niet opgeleid tot architect. Vaak kennen ze de overkoepelende principes niet, hebben geen blik op het grote geheel van de organisatie en weten niet wat andere gebruikers aan het doen zijn. Zo ontstaan vele kleine oplossingen van deelproblemen, die niet bij elkaar passen. Deze oplossingen veroorzaken nieuwe problemen, hetgeen tot nog meer wildgroei leidt.

We zien dit op IT-gebied in organisaties waarvan de leiding het belang van goede IT-systemen niet doorheeft. Elke administratieve medewerker ontwikkelt zijn eigen database, niet eens wetend wat een database is. Elke technische medewerker schrijft ergens voor een programma.

Als de wildgroei te erg wordt, kan het wildgroeimodel omslaan in het golfbaanmodel.

Het golfbaanmodel. De bouwheer heeft geen domeinkennis, maar wil wel een representatief bouwwerk, bijvoorbeeld omdat de concurrentie er ook een heeft. Gelukkig treft hij op de golfbaan regelmatig een aannemer, die nog verouderd materiaal heeft liggen en medewerkers in dienst heeft die de state of the art niet beheersen. Bouwheer en aannemer komen tot een oplossing waar ze beide mee tevreden zijn. Omdat de gebruikers er niets aan hebben, ontstaat nieuwe wildgroei.

De bouwende architect. Iemand met de capaciteiten van architect bouwt iets, bijvoorbeeld voor zichzelf. Anderen zijn onder de indruk van de kwaliteit van het product en willen ook zoiets. De architect begint zijn eigen aannemersbedrijf en bouwt op verzoek steeds meer soortgelijke bouwwerken, eventueel met kleine aanpassingen op wens van de koper. Omdat hij een goede architect met visie is, ontwikkelt hij nu en dan nieuwe producten en bouwt ook deze met de kwaliteit die men van hem verwacht. De klanten leggen zich er graag bij neer dat niet aan al hun wensen voldaan wordt. Zij willen liever een kwaliteitsproduct van een bewonderde architect dan iets met wat extra toeters en bellen, wat minder goed werkt.

Veel muziekinstrumentenbouwers zijn op deze manier begonnen en hebben een naam verworven. In de IT geldt hetzelfde voor sommige programmeurs van het eerste uur en voor scholieren en studenten die webpagina's konden maken. Dé grote naam op dit gebied is Steve Jobs, die op zijn eigenwijze manier kwaliteit leverde en visionair vernieuwde.

Als de bouwende architect toch niet alle voor een architect benodigde kwaliteiten heeft en de ontwikkelingen niet bijhoudt, lopen de klanten weg en wordt zijn naam vergeten. Als de bouwende architect daarentegen via zijn aannemersbedrijf de omgeving zo weet te manipuleren dat niemand om hem heen kan, gaat zijn bedrijf over op het vreet-of-stik-model. Op dit moment is Apple dit aardig aan het doen.

Het vreet-of-stik-model. Bouwheer, aannemer en architect vallen samen en zijn vooral uit op winst. De gebruiker heeft het bouwwerk nodig en moet betalen. Met de omgeving houdt de bouwer alleen rekening indien deze wettig beschermd is of ondergeschikt gemaakt kan worden aan het winstbelang. Als de omgeving zo gemanipuleerd is dat er alleen nog producten van de bouwer in passen, is het doel bereikt. Hoe groter het monopolie is hoe minder speelt kwaliteit een rol.

In de bouwwereld van steen, staal en glas zijn projectontwikkelaars er goed in. Men denke aan Vinex-wijken en al die winkelcentra voor steeds dezelfde ketens die overal verrijzen.

In de IT denke men aan Microsoft, dat met zijn Internet Explorer en web-development tools probeerde het hele internet over te nemen. Toen Java bedacht werd om de macht van Microsoft te breken, werkte Internet Explorer en de Microsoft tools met een eigen versie, waardoor alternatieve browsers weer niet compatibel waren. De laatste jaren gaat Apple met zijn iTunes en iOS ook deze kant op. Op dit moment overtuigen de iOS-apparaten nog steeds door kwaliteit en visie. De vraag is hoe lang nog.

De rekencentrumdirecteur als "rijks"bouwmeester. Grote organisaties zouden baat hebben bij een rijksbouwmeesterachtige huisarchitect. Al te vaak gaat het echter als volgt.

Grote organisaties hebben van oudsher een rekencentrum, dat in zijn begintijd de enige computer van de organisatie in gang hield en toegankelijk maakte. Deze dienstverlening was nodig, omdat het apparaat vele miljoenen kostte en een eigen gebouw nodig had. De rekencentrumdirecteur en zijn mensen waren de enigen, die er verstand van hadden en werden uiteraard bij alle ontwikkelingen betrokken. Naarmate computers kleiner en goedkoper werden, wilden afdelingen en medewerkers hun eigen computer, waardoor het bestaansrecht van het rekencentrum met zijn vele medewerkers in verdrukking kwam. Sommigen rekencentra werden conform de tijdgeest tot facilitaire bedrijven omgevormd en moesten winst maken. Deze druk heeft er regelmatig toe geleid dat rekencentra weinig tijd en animo hadden om de technische en maatschappelijke ontwikkelingen bij te houden. In plaats daarvan deden ze veel om hun macht te vestigen door een bedrijfsintern monopolie te verwerven.

Zulke voormalige rekencentra zijn eigenlijk aannemersbedrijven, en niet altijd de besten. Door hun voorgeschiedenis kunnen ze de organisatie flink manipuleren en zo het vreet-of-stik-model aardig benaderen: bepaalde systemen worden dwingend voorgeschreven en zodanig afgeschermd dat ze nergens mee gekoppeld kunnen worden. Andere systemen worden verboden. Voor een leider van zo'n voormalig rekencentrum is via een golfbaanbenadering de sprong naar "rijks"bouwmeester van de organisatie een logische stap. Maar heeft hij wel de in het vorige hoofdstuk genoemde kwaliteiten?

Deel II. Kwaliteit

We hebben nu gezien welke valkuilen beter vermeden kunnen worden bij het ontwerpen en maken van een systeem. Je hebt iemand nodig die zonder belangenverstrengeling met de aannemer de tegenstrijdige belangen van opdrachtgever, eennemer, gebruikers en omgeving kan afstemmen en uit een warboel van informatie en wensen iets zinnigs destilleren. In de bouw noemt men iemand die daarvoor opgeleid is architect. In de IT-wereld zijn er daarvan nog te weinig. Maar laten we nu aannemen we hebben er een bekwame gevonden. Geen binnenhuisarchitect, geen hoogbouwarchitect, geen landschapsarchitect, maar een IT-architect, dus iemand met de nodige IT-domeinkennis die op ooghoogte met IT-aannemers kan praten.

Stel, de architect heeft samen met de bouwheer het project geanalyseerd, en men is het eens dat het om een gemeen probleem gaat dat behoedzaam aangepakt moet worden; de architect heeft het spanningsveld van belanghebbenden in kaart gebracht en is erop voorbereid, zich in de nodige domeinkennis te verdiepen. De architect beheerst het ontwerpen en de theorie en materiaalkennis van het oplossingsdomein. Architect en bouwheer zijn zich bewust van alle mogelijke valkuilen: onbekende specificatie, spraakverwarring, EPS-wensen, onvolkomen domeinkennis, malafide aannemers. Het enige wat nu nog mis kan gaan is dat men ergens aan begint, want het vertrekpunt schijnt even mistig als het doel.

"Waar blijft in dit kritische boek het constructieve?", zal menige lezer zich afvragen.

Nu kent de Informatica en de IT-wereld allerlei methoden voor requirements engineering, voor het ontwerpen en doorrekenen van een ontwerp alsmede gereedschappen die dezer processen ondersteunen. We kunnen er gerust van uitgaan dat onze architect methodisch werkt en daarbij de nodige hulpmiddelen gebruikt. Dit boek is geen leerboek ontwerpen en gaat daar niet over.

Maar het vermijden van valkuilen, een gedegen probleemanalyse en het volgen van de ene of andere methode garandeert nog niet dat het resultaat ook goed wordt. Daarom moet een architect die een bouwwerk ontwerpt weten wat kwaliteit is, ook los van de specifieke eisen van de belanghebbenden. Ook dit hoort tot zijn opleiding.

De Romeinse bouwmeester Vitruvius schreef al dat drie kwaliteiten even belangrijk zijn. Hij noemnt ze utilitas, firmitas en venustas. Wij wijden aan elk een apart hoofdstuk.

Een goed architect gebruikt dit drieluik van Vitruvius als leidraad. Het wordt tegenwoordig in de IT-wereld herontdekt. Hier draaide het namelijk de laatste decennia vooral om functionaliteit, wat onder utilitas valt. Lange tijd deden IT-nerds lacherig over pogingen om systemen ook mooi te maken. Pas nu Steve Jobs dood is, wordt opeens overal over schoonheid gesproken. Dat valt onder venustas. Houdbaarheid, duurzaamheid en integriteit, hetgeen onder firmitas valt, telde lang al helemaal niet: ten eerste waren computersystemen zo duur dat milieuaspecten schijnbaar niet telden, ten tweede hield niemand er rekening mee dat zo'n systeem langer dan een paar jaar zou meegaan. Het millenniumprobleem was daar een triest gevolg van.

Ondertussen dringt ook in de IT door dat alle drie de kwaliteiten van Vitruvius even belangrijk zijn. En niet alleen de architect moet er verstand van hebben. Ook opdrachtgevers en gebruikers moeten ten minste weten, wat ze op deze gebieden kunnen verlangen en verwachten.

Voor Vitruvius en alle goede architecten was ook belangrijk dat een goed ontwerp rekening hield met de menselijke maat: het moet passen bij zijn gebruikers. Bij IT-systemen gaat het hier om meer dan alleen lichamelijke afmetingen. Ook hieraan wijden we een hoofdstuk

Architectuur – en daarmee ook kwaliteit van bouwwerken – hoort tot de algemene vorming. Mensen bezoeken beroemde gebouwen. Betere kranten berichten regelmatig over nieuwe bouwwerken. In betere boekhandels en bij De Slegte vind je stapels mooie architectuurboeken. Daarom is het niet moeilijk, kwaliteitsprincipes aan de hand van bekende voorbeelden uit te leggen. Ook alledaagse voorbeelden uit de eigen omgeving kunnen de principes verhelderen.

Bij digitale gebouwen – IT-systemen – is het moeilijker, want die zijn voor het grootste deel onzichtbaar. De kwaliteitsprincipes zijn dezelfde, maar men kan niet zo gauw samen iets bekijken. Alle medewerkers van een organisatie kennen het kantoorgebouw van steen, staal en glas, waarin zij en hun leiders werken. Maar wie kent de IT-systemen van dezelfde organisatie? De gebruikers zien alleen de buitenkant van het kleine stukje dat voor hen relevant is. De buitenkant van andere delen mogen ze niet eens zien omdat ze daartoe geen rechten hebben. De leiders zien alleen iets voorzover ze zelf gebruiker zijn. Wat er „onder de motorkap” zit, ziet bijna niemand.

Daarom lijkt het moeilijk om met een IT-systeem staat te maken. Het nieuwe ING-hoofdkantoor met zijn aggressieve uitstraling is vast iets waarop de leiding van de ING trots is. De belastingdienst, even afgezien van alle recente interne problemen en het onprofessionele geklungel met digitale handtekeningen, mag trots zijn op zijn programma voor belastingaangifte. Al de eerste versie, onder de naam „belastingdiskette”, was één van de weinige voorbeelden voor een kwalitatief goed systeem. Maar het verscheen niet op de architectuurpagina's van de krant.

Onze maatschappij heeft hier last van een vicieuze cirkel. Er is geen „digitale” architectuurkritiek van niveau, mede omdat de systemen en hun kwaliteiten onzichtbaar zijn. Daarom blijven nog steeds veel te veel systemen van erbarmelijke kwaliteit het kwaliteitsbewustzijn bepalen: IT is iets moeilijks, kortstondigs, lelijks, waar zichzelf respecterende mensen een hekel aan dienen te hebben en wat ze graag aan nerds overlaten. Daarom ontstaan er steeds nieuwe wanstaltige systemen. Ook van steen, staal en glas ontstaan de laatste jaren wanstaltige gebouwen langs snelwegen. Of gebouwen die op het eerste moment indruk maken met nieuw gevelmateriaal, maar na een paar jaar hopeloos verweerd zijn en niet meer om aan te zien. Zou dat een spiegeling zijn van de allesbeheersende IT-wereld?

Dit brengt ons op het thema eigenbelang van de architect.

Willen we belangenverstrengeling voorkomen, kunnen we beter een onafhankelijk architect aanstellen om het nodige systeem te ontwerpen en ook te controleren of de aannemer het ontwerp goed uitvoert. Verstrengeling met de aannemers is uit den boze. Willen we dat onze architect zijn werk goed doet moeten we hem ook voor de kwaliteitscontrole van uitvoering verantwoordelijk maken (en daarvoor betalen). Anders levert hij een ondoorgrondelijk document op, vertrekt met de noorderzon en schuift later alle kritiek op de aannemer en de domme gebruikers af.

Het eigenbelang van de architect is dan dat hij met zijn ontwerp geen spot en hoon oogst maar er bekend mee wordt en lucratieve vervolgopdrachten krijgt. Als persoon, niet als anonieme medewerker van een adviesbureau, want het begrijpen van een probleem en het maken van een kwaliteitsontwerp is iets persoonlijks. Vandaar al die bekende namen uit eeuwen bouwgeschiedenis. In de IT zijn er maar weinig bekende architecten. Steve Jobs was er een van, we zullen in deel III nog op hem terugkomen. Of Apple ook zonder hem zijn niveau van utilitas, firmitas, venustas en de menselijke maak kan houden, valt nog te bezien.

De architect moet dus producten van hoge kwaliteit afleveren, en zijn klanten moeten die kwaliteit kunnen waarderen. Vandaar de volgende hoofdstukken.

Utilitas

Utilitas staat voor bruikbaarheid, doelmatigheid, nuttigheid, deugdelijkheid. In de IT zou je het met "de juiste functionaliteit" kunnen omschrijven. Grote delen van de wetenschap informatica en van IT-opleidingen gaan over functionaliteit. Toch gaat het vaak mis. In deel I hebben we gezien, waarom, maar het kan geen kwaad om de oorzaken nog eens onder een ander perspectief te bekijken en als kans te zien.

Dit andere perspectief opent zich, als we, alvorens te fixeren op een nieuwe oplossing voor een acuut probleem, eens kijken wat er in de bewuste organisatie reeds is. En dan niet alleen kijken naar de officiële, door het management gewenste systemen maar naar de volledige werkelijkheid. Het management heeft daar geen blik voor, een goede architect wél. De onzichtbaarheid van IT-systemen bemoeilijkt het kijken, maar wie goed, liefst samen met een architect, kijkt wordt rijk beloond.

Amazon Web Services verleent tientallen verschillende diensten aan honderdduizenden organisaties en stelt iedereen in staat om complexe architecturen te creëren.

Stel, u bent de leider van een organisatie. De gebouwen van steen, staal en glas van uw organisatie kunt u zien, en uw medewerkers kunnen ze ook zien. Men weet wat men heeft. Als u wilt, kunt u ook zien of al uw gebouwen een eenheid vormen of zonder samenhang naast elkaar staan. Als u een gebouw of een deel van een gebouw ziet, waarvan u de functie niet kent, kunt u vragen. Als een gebouw aangepast of uitgebreid moet worden, kan men zich de consequenties voorstellen. Als u overgaat tot sloop en nieuwbouw, ziet iedereen wat er gesloopt gaat worden en op welke belangen hij moet letten bij de nieuwbouw. Als de nieuwbouw op dezelfde locatie moet komen als het te slopen oude gebouw, zal de architect een ingenieus plan maken wat wanneer gesloopt en gebouwd wordt en wie wanneer moet verhuizen.

De IT-gebouwen van uw organisatie zijn ook gebouwen. Maar ze zijn grotendeels onzichtbaar. U als leider ziet misschien helemaal niets, tenzij dat u tevens gebruiker bent. De gebruikers in uw organisatie zien alleen de buitenkant (het "gebruikersinterface") van dat kleine stukje IT dat ze voor hun eigen werk nodig hebben.

Onzichtbare wildgroei. Stel dat u als leider van de organisatie een architect aanstelt om te analyseren wat er allemaal is en dat u de tijd neemt om zich goed te laten informeren, zult u zien dat er veel meer is dan u verwacht had, en dat het allemaal wildgroei is. In het faculteitsgebouw, waarin dit boek werd geschreven, had men bijvoorbeeld jaren geleden al deze systemen en nog meer kunnen vinden: een systeem voor de administratie van tentamencijfers, een zaalreserveringssysteem, een database voor telefoonnummers op kamer, een systeem om roosters te helpen maken, Blackboard, een content-management-systeem; daarnaast per opleiding een eigen systeem voor: de administratie van studiegidsen, een systeem om roosters te communiceren, een studentenvolgsysteem, iets met pasfoto's van studenten en medewerkers, een website van het instituut, een of meer wiki's. Terwijl cruciale bedrijfsinformatie helemaal niet in een systeem wordt bijgehouden, maar in Word-bestanden, hooguit in een spreadsheet: taakverdeling van docenten, samenstelling van commissies, samenhang van cursussen en curricula en vooral: verdelers voor post en e-mail.

Al deze systemen waren onafhankelijk van elkaar in eigenbouw ontstaan doordat dappere gebruikers de behoefte zagen en het noodlot in eigen handen namen. Elk systeem is een stukje gestolde domeinkennis. Bovendien is de inhoud van deze systemen actueler dan de inhoud van de officiële systemen van de organisatie. Anders zouden ze niet nodig zijn. Maar niets sluit aan op elkaar omdat niemand weet wat er nog meer is. En als men al weet dat er een ander systeem is waarin de informatie die men nodig heeft al staat, mag men er niet bij. Zo worden namen, telefoonnummers en e-mail-adressen keer op keer met de hand overgeschreven van het ene systeem naar het andere. Of opnieuw achterhaald en ingevoerd. Een flink deel van de werktijd gaat op aan het overtypen, actualiseren en controleren van gegevens. En toch zijn er steeds weer webpagina's die iets vermelden wat er al lang niet meer is. Wie een keer in een commissie zat, zal voor de rest van zijn leven allerlei uitnodigingen en vergaderstukken ontvangen, omdat zijn naam in diverse afdelingen op met de hand bijgehouden verdelers staat. Omdat niemand ziet dat het veel beter zou kunnen, blijft de wildgroei maar doorgaan.

Misschien komt het op een gegeven moment in u op dat u een systeem mist wat u de nodige management-informatie kan verschaffen, bijvoorbeeld het overzicht over alle onderzoeksprojecten in uw huis. Die informatie is er op dat moment al, maar ze is verspreid over spreadsheets bij onderzoekers en secretaressen. Als u de aanschaf van een systeem doorzet zonder een bekwaam architect naar het geheel te laten kijken, komt er nóg een systeem bij, en er wordt nóg meer tijd besteed aan overtypen en controleren. De onderzoekers en secretaressen kunnen namelijk hun spreadsheets niet missen en moeten de informatie nu ook nog eens in het nieuwe systeem invoeren, zonder dat ze daar zelf bij aan hebben. Misschien is het nu tijd voor een golfbaantraject om de oude rekencentrumdirecteur tot "rijks"bouwmeester te machtigen, waardoor alles nog veel erger wordt. Gebruik van het nieuwe systeem wordt verplicht gesteld en al het andere verboden. Het gevolg is nog meer wildgroei, maar nu in het geniep.

Inconsistentie. In termen van databases uitgedrukt: Uw organisatie heeft een aantal informatiesystemen die onafhankelijk van elkaar bijgehouden worden, elk met zijn eigen database. Veel tabellen vind je terug in meer dan één van deze databases, maar soms is de inhoud volgens uiteenlopende conventies opgeslagen, soms niet actueel, soms niet eenduidig omdat niet goed over sleutels nagedacht werd.

Een van de oorzaken van inconsistentie is ontbrekende domeinkennis, bijvoorbeeld wat buitenlandse namen en adressen betreft. In Duitsland vraagt men zich af, waarom zo veel plaatsnamen met een kort woordje beginnen, bijvoorbeeld 'al Nuenen'. En wie weet bij een Chinese naam wat de voornaam en wat de familienaam is? Misschien zijn de namen al door iemand omgedraaid, misschien nog niet. Veel Amerikaanse software heeft geen apart veld voor tussenvoegsels in Nederlandse namen zo als Jan de Brock. Als we als achternaam 'de Brock' invoeren, wordt op de d gesorteerd. Als we 'Brock, de' invoeren, verschijnt op een brief: 'Geachte heer/mevrouw Jan Brock, de'. Als we alleen 'Brock' invoeren, ergert zich Jan weliswaar aan de aanhef van brieven, maar anderen valt het niet op: het sorteert lekker en ziet er redelijk uit. Zonder regels en probleembewustzijn bedenkt hier iedereen een andere noodoplossing.

Het is niet nodig en niet altijd verstandig, dit allemaal te slopen en in een klap te vervangen door een integraal nieuw systeem. Maar de architect moet de leiding van de organisatie en de beheerders van al deze systemen zo gauw mogelijk ervan overtuigen, dat door de hele organisatie dezelfde gegevens op termijn dezelfde sleutel (bijvoorbeeld een personeelsnummer of order-nummer) en dezelfde notatie moeten hebben. Alleen al, om gegevens uit de verschillende systemen met elkaar te kunnen vergelijken. Het gaat om een stukje bedrijfscultuur: "Adressen, ook die in andere landen, slaan we hier zo en zo op." Inconsistentie kun je niet voorkomen door alleen de aanschaf van een nieuw systeem. In tegendeel: juist door inconsistentie tussen verschillende systemen te demonstreren zien kun je medewerkers bewust maken dat er een probleem is.

Inkapseling. Op 13 Augustus 1961 werd West-Berlijn in opdracht van de DDR-regering ingemetseld. Dat moest het probleem oplossen dat steeds meer DDR-burgers via West-Berlijn uit de DDR weglekten. Deze oplossing werkte enigszins, maar veroorzaakte veel ellende en werd door de mensen niet geaccepteerd. De resulterende tegenwerking veroorzaakte nog meer oplosingen en nog meer ellende. Maar vanuit verkeerstechnisch oogpunt was deze oplossing bewonderenswaardig. Berlijn heeft namelijk sinds de 19e eeuw een geavanceerd ov-systeem op rails: de S-Bahn. (De NS hebben dit onder de naam "light rail" onlangs heruitgevonden.) Omdat het altijd goed werkte zijn de Berlijners er dol op. Om allerlei technische, juridische en politieke redenen was de DDR verantwoordelijk en vervoersplichtig voor het hele S-Bahn-net, ook in West-Berlijn. Veel DDR-burgers reisden dagelijks met de S-Bahn door West-Berlijn van huis naar werk en terug. En velen misbruikten dit woon-werkverkeer om in het westen te blijven. De te bouwen muur zou dit net van een metropool en haar omgeving op twaalf punten doorsnijden, met twee problemen als gevolg. In West-Berlijn moest het nog altijd functioneren, anders waren de west-geallieerden in opstand gekomen. En DDR-brugers moesten nog steeds van thuis naar werk kunnen komen maar nu onder vermijding van het westelijke grondgebied. Al dit moest in een klap gebeuren, en dat deed het en werkte goed. In de nacht tot 13 augustus werden in allerijl 12 lengtes rails op de cruciale plekken verwijderd en er werd beton gestort. Op de volgende dag bleken alle lijnen al gewijzigd, alle abonnementen op de nieuwe lijnen geldig en alle wegwijzers aangepast zodat de Oost-Berlijners naar hun werk konden, zonder over West-Berlijns grondgebied te komen en de S-Bahn in West-berlijn toch bleef rijden. Deze perfect geplande nacht- en neveloperatie na de val van de muur terug te draaien vergde jaren.

Wat toen verkeer voor de maatschappij betekende betekent nu communicatie, en de geschiedenis herhaalt zich. Veel organisaties voelen zich tegenwoordig door het internet zo bedreigd als zich toen het DDR-regime voelde door de mogelijkheid om vrij te reizen. Overal worden muren opgetrokken en verbindingen doorgeknipt, om hele staten, om organisaties, maar ook om systemen binnen een organisatie. Zelden is het zo duivels goed gepland als in het geval van de Berlijnse muur en de S-Bahn, maar het bezorgt mensen die van goede wil zijn net zo veel ellende, terwijl het niet echt goed werkt en ook nog eens allerlei criminelen gelegenheid geeft om aan het leed van anderen te verdienen.

Herkent de lezer dit? Heeft hij op zijn werk toegang tot alles wat voor zijn werk nodig is? Voegen zich e-mail en agenda van het werk soepel samen met die van het privéleven? Of moeten er dagelijks allerlei omwegen worden genomen en een soort dubbelleven geleid?

De bouwers van de verschillende systemen zien zelf de wildgroei niet omdat ze alleen oog voor hun eigen systeem hebben. Dáárvoor voelen ze zich verantwoordelijk, en omdat ze absoluut geen problemen met privacy-wetgeving willen, schermen ze hun systeem zo goed ze kunnen af. Ze worden daarbij bevestigd door de juristen van de organisatie, de iedereen bang maken door te vertellen welke gegevens allemaal privacygevoelig zijn.

Een andere afdeling binnen de eigen organsiatie wordt dan als vijandige buitenwereld beschouwd en mag ook niet bij de gegevens in het eigen systeem komen. Dit zorgt voor veel onnodig werk en ongesynchroniseerde tabellen. Een architect architect die hiernaar kijkt, doet er goed aan, de leiding en de beheerders zo gauw mogelijk ervan overtuigen dat al deze databases op termijn aan elkaar gekoppeld moeten kunnen worden. De verzameling tabellen als geheel moet goed afgeschermd worden, en bij elke zoekvraag moet erover nagedacht worden, wie de resultaten mag zien: een ander intern informatiesysteem, een medewerker of de boze buitenwereld.

Ook al is het misschien nog niet de tijd om alles door een integraal systeem te vervangen, kan nu de totale benodigde databasestructuur in kaart gebracht worden. Een beheerder van één systeem ziet dan in welke andere systemen dezelfde tabellen staan en went aan de gedachte dat koppeling misschien handiger is dan overtypen.

Vergeten regels. Bij elk systeem horen regels voor gebruik en beheer. Bij eigenbouwsystemen staan deze regels vaak alleen in de hoofden van de bouwers. Zolang ze bewust of onbewust opgevolgd worden, gaat het goed. Nalatigheid is funest: als er ook maar een paar weken de inhoud van een webpagina niet actueel is, zal iedereen ertoe overgaan, niet langer naar de webpagina te kijken maar de gegevens die daar zouden moeten staan zelf bij te houden, bijvoorbeeld in een Word-bestand.

EPS-oplossingen. Mensen zijn erg goed in het bedenken van steeds ingewikkelder EPS-oplossingen. Het begin thuis, waar we een bestand printen om het papier vervolgens op het faxapparaat te leggen en dan in de papiervernietiger te stoppen. In organisaties lopen medewerkers aan tegen inconsistenties en afkapseling van de in wildgroei ontstane systemen, en de kans is groot, dat ze dan EPS-oplossingen bedenken en in nog meer wildgroei realiseren.

Als een afdeling met klem van het management de aanschaf van een nieuw systeem verlangt, is het niet denkbeeldig dat dit een EPS-wens is. Misschien moet er juist geen nieuw systeem bij. Misschien moeten twee bestaande eindelijk eens worden gekoppeld, waardoor twee andere overbodig worden.

Microsoft weet dat de gebruikers bang zijn voor alle vernieuwingen in Windows 8 en speelt daarop in door de overstap erg goedkoop te maken.

Angst voor verandering. Als mensen moeten verhuizen uit een gebouw van steen, staal en glas naar een nieuwbouw, krijgen ze vaak lang voor de oplevering van het nieuwe gebouw tekeningen en maquettes ervan te zien. Ze kunnen zich voorstellen wat er komt, zich erop verheugen omdat het mooier is, nadenken hoe ze hun nieuwe kamer zullen inrichten.

IT-systemen daarentegen zijn onzichtbaar. Aan een korte demo van een prototype heeft men weinig en aan een paar schermafbeeldingen van het te verwachten systeem heeft men niets. Niet veel gebruikers kunnen zich voorstellen hoe ze zich met het te verwachten systeem zullen voelen. Men is bij voorbaat al wantrouwend.

Daar komt de ervaring met eerdere innovaties bij. Omdat gemene bouwprojecten op de verkeerde manier als tam constructieproject uitgevoerd werden, heeft men zijn ervaringen met systemen die niet doen wat nodig is. Vaak zijn er alleen maar een of twee velden in de cruciale datastructuur vergeten, maar het blijkt erg duur, deze alsnog toe te voegen. En omdat het veel geld gaat kosten, kost het ook nog eens veel vergadertijd. De ervaring is dus dat elke ontwerpfout vreselijk duur wordt en men nóg langer moet vergaderen en nóg beter plannen voordat een ontwerp goedgekeurd wordt. Nu wordt vergaderd over elk veld in de datastructuur, hoewel zich maar weinigen correct kunnen voorstellen wat het betekent.

Men kan zich het nieuwe systeem niet voorstellen. Het enige wat men weet is dat het duur zal worden en waarschijnlijk niet goed zal werken. En dat men vervolgens naar bijscholingen moet die het probleem ook niet oplossen.

Waarom moet ik telkens als een hersenloze machine al die programma's één voor één installeren? Dat is de vraag die de makers van Ninite zichzelf ongetwijfeld hebben gesteld. Zij hebben een website gemaakt waarmee je alleen maar hoeft aan te klikken welke programma's je wilt installeren, waarbij een executable deze vervolgens, zonder onnodige toolbars, op de achtergrond installeert, of naar de nieuwste versie update. Als je een tijd later alles wilt updaten, hoef je alleen de executable opnieuw uit te voeren, het programma doet de rest.

Menselijke machines. Medewerkers die doordrongen zijn van de leidende principes van hun organisatie zijn flexibel en zullen betrekkelijk weinig weerstand bieden tegen veranderingen in de dienst van deze principes. Als door automatisering een taak verandert of overbodig wordt, heeft zo'n betrokken medewerker misschien al uitzicht op een nieuwe taak in de organisatie.

Helaas vind je in organisaties ook medewerkers die niet betrokken zijn bij de leidende principes. Zij voeren een taak uit die een machine zonder bewustzijn even goed, misschien beter uit zou kunnen voren. Bijvoorbeeld het overtypen van gegevens uit het ene informatiesysteem naar het andere. Bijvoorbeeld het sorteren en afstempelen van formulieren. Eigenlijk zijn zulke medewerkers de pompjes en slangen van een EPS-oplossing, al realiseren zij en hun bazen zich dat niet altijd.

Hier worden mensen dus als machines gebruikt, hetzij omdat op dit moment een machine voor deze functie nog duurder is, hetzij omdat een EPS-oplossing nog niet vervangen is door een doelmatige oplossing. Op het moment, dat hun functie dreigt opgeheven te worden, zullen zulke medewerkers wel degelijk mensen van vlees en bloed blijken te zijn, met angsten, doorzettingsvermogen en een cao. Hun vermogen om ontwikkelingen tegen te houden mag niet worden onderschat. Hierop komen we terug in het hoofdstuk over integriteit.

Maar zelfs als alle medewerkers doordrongen zijn van de principes van de organisatie spelen de hiervoor beschreven gevolgen van de onzichtbaarheid van IT-systemen in de organisatie. Hoe moet het dan wél? We kunnen de bouw van wegen als voorbeeld gebruiken.

Ruimtelijke ordening

Niemand mag in Nederland zo maar een weg bouwen. Dat zou namelijk resulteren in wildgroei, inconsistentie en EPS-oplossingen, vergeten regels (wie betaalt voor onderhoud? Hoe moet het als een weg tijdelijk niet bruikbaar is?) en misschien zelfs afkapseling (als particulieren wegenbouwers elkaar tegenwerken). Niet alleen het hele huidige wegennet met al zijn knelpunten is goed in kaart gebracht maar ook de plannen op middellange en lange termijn. Elke nieuwe kilometer weg moet in een groter plan passen en vooral aansluiten op wat er nog gaat komen. Dat heet ruimtelijke ordening.

Voor de IT-systemen van een staat of een organisatie is zulk een ruimtelijke ordening met een visie op langere termijn nog dringender nodig dan in de wegenbouw omdat de bestaande systemen onzichtbaar zijn. Er is niets op tegen dat men knelpunten oplost door lokaal een systeem aan te passen of een nieuw systeem toe te voegen - als het maar in een hoger plan past.

Uit de voorafgaande bespreking van problemen volgt dat zo'n plan moet bestaan uit (1) een kaart van alle bestaande systemen en (2) een approximatieve kaart van het ideale totaalsysteem: welke tabellen en welke relaties zijn idealiter nodig voor de hele organisatie? Wie in de organisatie is verantwoordelijk voor welke relatie? Welke koppelingen van tabellen moeten beveiligd worden omdat ze vertrouwelijk zijn, en welk ander deelsysteem en welke groep van gebruikers mogen de resultaten van deze koppeling wel zien?

Opdrachtgevers willen snel resultaat zien. Ze hebben de neiging, het in kaart brengen van alle systemen over te slaan omdat alleen een lokaal knelpunt snel opgelost dient te worden. Maar ze weten vaak niet dat de voor de oplossing nodige informatie al op een andere, onzichtbare plek aanwezig is. Zo ontstaat dan de volgende EPS-oplossing met nog meer zinloos werk als gevolg. Daarom is het goed om in goed overleg alle systemen in kaart te brengen, ook degene die op het eerste gezicht weinig met het knelpunt te maken hebben. En vooral ook de niet-officiële wildgroei-systemen, want die zijn er niet voor niets.

Zo'n IT-ruimteplan heeft overigens alleen nut als deze door de betrokken beheerders, beslissers en andere belanghebbenden ook begrepen kan worden. Ook hier moet blijken dat een architect goed kan communiceren.

Als men dankzij zo'n plan weet waar het naartoe gaat, kan men behoedzaam kleine stappen in de juiste richting zetten zonder te veel tegelijk overhoop te halen. Bijvoorbeeld door een medewerker, die een tabel in een systeem moet bijhouden erdoor te belonen dat het systeem hem bij zijn werk ondersteunt i.p.v. extra werk te vragen. Dat is soms met één extra webpagina op te lossen, al kan zich betrokkene dat misschien niet voorstellen. Bijvoorbeeld door een tabel uit een ander systeem te importeren i.p.v. deze apart te laten bijhouden.

Verantwoordelijkheid op de juiste plek

Als we even alle tabellen van de denkbeeldige verenigde database beschouwen en niet de aparte systeempjes - wie is dan eigenlijk idealiter voor de correctheid van welke tabel verantwoordelijk? Het zal niet werken, de beheerder van de integrale database als verantwoordelijke aan te wijzen. Men moet zich realiseren dat elke relatie in deze database een natuurlijke eigenaar heeft.

Ergens in de organisatie is een afdeling of een bedrijf verantwoordelijk voor de draadjes van de telefooncentrale naar de afzonderlijke kamers. Hier, en nergens anders, zal op elk moment de actuele relatie telefoonnummer - kamernummer te vinden zijn. Hier wordt die relatie namelijk bepaald en in hardware geschroefd.

De toewijzing van werkplekken en kamers aan medewerkers gebeurt vaak op afdelingsniveau door de secretaresse. Klassiek houdt zij in een Word-bestand titel, naam, functie, kamer- en telefoonnummer, eventueel privé-adres bij omdat ze dit voor haar werk nodig heeft en maakt al dan niet met een sjabloon daaruit ook nog naambordjes voor de kamerdeuren. Maar eigenlijk gaat ze alleen over de relatie personeelsnummer - werkplek. Welke naam en titel bij een personeelsnummer hoort, wordt namelijk bijgehouden door personeelszaken. En de enige die zijn privéadres actueel bijhouden kan is de medewerker zelf.

Als de organisatie de secretaresse dwingt om de kamernummers ook nog in een ander systeem in te voeren, zonder dat ze daar iets voor terugkrijgt, zal ze dit niet stipt en betrouwbaar doen. Als de secretaresse daarentegen de kamernummers op personeelsnummer maar één keer hoeft in te voeren en ze daarvoor de voor haar benodigde lijst met naam, functie, adres, telefoonnummer enz. alsmede de deurplaatjes en visitekaartjes gratis krijgt, zal ze het secuur bijhouden, en wel in het systeem en niet in een inofficieel Word-bestand. Omdat eigenbelang dan samenvalt met het belang van de organisatie.

Er zijn dus twee fouten, die de organisatie moet vermijden: (1) dat iemand verantwoordelijk wordt gemaakt voor een stuk inhoud van het systeem die de nodige gegevens niet uit de aard van zijn taak zelf heeft maar ergens vandaan moet halen; (2) dat iemand die de informatie heeft en goed bijhoudt extra werk moet verrichten om ze ook nog in het systeem te stoppen zonder daarvoor iets terug te krijgen.

Behoedzaamheid

De minister van Veiligheid en Justitie ziet in de nazomer 2012 goed waar de politie veel tijd kan besparen: tegenwoordig worden door agenten bekeuringen op "gele bonnetjes" uitgeschreven; die moeten dan door iemand ergens ingevoerd worden en de invoer moet gecontroleerd worden. Het liegt voor de hand dat agenten beter ter plaatse de informatie digitaal invoeren, waarop dzee automatisch naar het Centraal Justitieel Icassobureau wordt opgestuurd.

Wie oog heeft voor de omgeving, ziet dat veel agenten een smart phone bezitten. De minister zou een universiteit kunnen benaderen waar studenten in hun practicum Apps voor spart phones bouwen. De studenten kunnen dan een prototype maken waarmee gegevens ingetypt en opgestuurd kunnen worden. Daarbij komen een aantal leerzame beveiligingsaspecten aan de orde. Dat zoiets zonder veiligheidsrisico mogelijk is bewijzen de Apps van banken, waarmee men op zijn smart phone de opdracht tot overschrijvingen kan geven. De studenten zullen daarbij nog een paar creatieve ideeën krijgen, bijvoorbeeld dat men een foto van betrokkene mee kan sturen en dat de plek van de bekeuring meestal niet ingetypt hoeft te worden omdat het apparaat dankzij GPS weet waar het zich bevindt.

Er zijn vast een paar honderd politieagenten die bereid zijn om aan een proef mee te doen, gewoon omdat ze dol zijn op hun smart phone en uitkijken naar dit soort vereenvoudigingen. Na een paar maanden heeft men daaruit veel geleerd. Gekost heeft het bijna niets. Andere agenten zien het werken en willen het ook.

Dit is het moment om op het ministerie na de denken of een bepaald type smart phone niet de handcomputer van de toekomst voor de politie is. Standaard-hardware, super-multifunctioneel met al zijn zintuigen, intuïtief in het gebruik en steeds weer met nieuwe Apps uitbreidbaar.

Het NL-Alert systeem van de overheid is d.m.v. Agile Development ingevoerd en het systeem wordt nog steeds verbeterd/aangepast.

Dit is wat we met een behoedzame aanpak bedoelen. Elke stap levert meteen resultaat op, en na elke stap weet men meer en kan het plan bijstellen indien nodig. De risico's zijn beperkt. Agile Development is een principe dat dit soort behoedzame migratie naar iets nieuws ondersteunt.

Maar helaas zijn beslissers en IT-ers it niet gewend. In niemand komt op dat het zo zou kunnen. Men zit vast in oude patronen. Ziehier een ingezonden brief, waarin een ervaren adviseur bewijst waarom het plan van de minister op middenlange termijn onhaalbaar is:

"Het plan van Opstelten gaat nooit lukken. Eerst moet er een programma van eisen worden opgesteld voor de hardware, handcomputer en software, onder meer het systeem dat de handcomputer verbindt met het Centraal Justitieel Incassobureau. Er moet een aanbestedingsprocedure worden gevolgd. Hardware en software moeten worden ontwikkeld, gebouwd en getest. Er moeten twintigduizend handcomputers worden geproduceerd. Ten slotte moeten ongeveer twintigduizend agenten worden opgeleid en geïnstrueerd in het gebruik van de handcomputer. Dit lukt nooit in een jaar. Immers, er kan pas worden begonnen nadat de Tweede Kamer akkoord is gegaan met het voorstel. Hierbij komt dat het project moet worden getrokken en gestuurd door de Nationale Politie. Die is dan net in opbouw.

Waarom komt Opstelten dan met dit plan? Misschien maakt het deel uit van zijn plannen om in zijn oorspronkelijke kabinetsperiode, dat was tot 2014, de administratieve lasten van de politie met een kwart terug te brengen. Maar is de minister er in 2014 nog wel? Het digitaal bekeuren in elk geval niet.

J.G.H. Quint

Organisatieadviseur en auteur van Manager van de wereld, Amsterdam"

Dit is in der daad de gebruikelijke manier, en op die manier is ook gebruikelijk, dat het mis gaat, altijd weer. Men ziet allerlei commissies vergaderen over het 'programma van eisen', verlamd door de angst dat men een miniscuul eisje vergeet en daardoor een onherstelbare fout maakt, verzuipend in technische documentatie die niemand begrijpt. Terwijl over de ene grote fout, dat men namelijk speciale hardware wil ontwikkelen, helemaal niet vergaderd wordt. De roep naar speciale hardware en naar 'een systeem dat de handcomputer verbindt me...' is niet ingegeven door kennis van wat er is en wat nu al kan, maar door angst. En dan worden — met houdt zijn hart vast — in één klap twintigduizend stuks computers geproduceerd, waarvan niemand weet of ze zijn wat echt nodig is en of ze ook voor toekomstige toepassingen geschikt zullen zijn. En twintigduizend politieagenten krijgen een apparaat erbij en moeten hem in een klap leren gebruiken. De agenten met knoppenangst zijn even gefrustreerd als die die een iPhone bezitten. En uiteraard wordt het papieren bonnetjessysteem net zo overhaast afgeschaft als de ov-strippenkaart.

En waarom dit alles? Om een paar gegevens naar een centrale computer door te geven, iets wat beslist niet revolutionair nieuw is!

Wat behoedzaamheid met visie inhoudt, hebben we in het hoofdstuk over gemene problemen uitgelegd. De door de organisatieadviseur beschreven aanpak heeft met het een noch het ander te maken.

Standaarden

Standaarden helpen. Dat ziet men ook in de wegenbouw. Snelwegen met hun kruisingen en aansluitingen zijn door en door gestandaardiseerd. Ook al komt er een bepaald stuk nog niet of is een uitrit nog niet nodig, bouwt men zo dat men er later goed op kan aansluiten.

Microsoft verplicht haar gebruikers alle oude office-bestanden om te zetten naar OpenXML, omdat deze bestanden vanaf Office 2013 niet meer geïmporteerd kunnen worden. Het gevaar van een gesloten 'standaard'.

De vele in wildgroei ontstane systemen van een organisatie zullen zich in eerste instantie niet houden aan standaarden. Het begint in het klein. Denk bijvoorbeeld aan het zaalreserveringssysteem voor een universiteit. Het bestaat al decennia lang tot iedereens tevredenheid. Men kan per e-mail een zaal aanvragen en krijgt per e-mail een zaal toegewezen. Vroeger gebeurde dit met de hand en een kaartenbak, ondertussen zit er een computerprogramma achter. In feite een database, maar zonder kennis van databasetheorie geschreven. Ooit werd het uitgebreid met een web-pagina die alle vrije zalen toont om te helpen bij het aanvragen.

In twee dimensies is dit systeem niet gestandaardiseerd. Ten eerste houdt zich de inhoud niet aan conventies. Elke aanvrager mag aangeven waarvoor de zaal gereserveerd is, en daar staat dan soms de naam van een docent, soms de naam van een cursus, soms een afkorting en soms "college". Ten tweede kan het systeem weliswaar mailberichten produceren en een webpagina tonen, maar er is geen interface om zijn databasetabellen rechtstreeks te kunnen lezen en te koppelen met tabellen uit andere systemen.

Het eerste is te verhelpen met een regel bij het gebruik, zonder de programmatuur te wijzigen: standaard dient het personeelsnummer van de aanvrager en de officiële cursuscode worden opgeslagen. Het tweede kan opgelost worden met beperkte programmeerinspanning: als men al een webpagina kan genereren, kan men er ook een met rauwe data in een geschikt semantic web-formaat genereren.

Zo'n systeem met gestandaardiseerde inhoud en een standaard interface heeft opeens meerwaarde: men kan er, zonder opnieuw in het programmatuur in te grijpen, collegeroosters en iCal-feeds voor docenten en studenten uit genereren, men kan het informatiesysteem met de beeldschermpjes bij elke zaal op aansluiten, en men kan zijn tabellen koppelen met de tabellen uit het systeem waar zich studenten inschrijven voor cursussen. Zo valt te achterhalen welke zalen structureel onderbezet zijn. Dit alles met beperkte inspanning, omdat de architect ziet wat er al is en wat wenselijk is.

In een organisatie die zich aan standaarden houdt kan veel werk bespaard worden, omdat alles past. Vandaar dat heel Europa het papierformaat A4 gebruikt. Men stelle zich een burgemeester voor die met zijn wethouders en gemeenteraad voor de bouw van een nieuw raadhuis wil vergaderen over een programma van eisen voor papier en opslagmeubels. Toch schijnt het dat in Nederland ministeries serieus over pakketen van eisen aan het nadenken zijn voor een systeem dat de ene computer met de andere verbindt.

Firmitas

Firmitas heeft ermee te maken hoe goed een bouwwerk in elkaar zit om niet in te storten of te verweren. We kennen gebouwen die zo stabiel zijn dat ze al vele honderden of zelfs duizenden jaren staan en nog steeds in gebruik zijn. Van talloze andere gebouwen is daarentegen niets meer terug te vinden. Die zijn na een tijd weer helemaal opgegaan in de natuur omdat ze van hout en leem gemaakt waren, of hun stenen werden na de sloop hergebruikt. Het ergste zijn gebouwen die als nutteloze, lelijke ruines blijven staan omdat men ze niet kan verwijderen.

Sinds de vorige eeuw komt aandacht voor duurzaamheid op. De technische vooruitgang heeft ons namelijk steeds meer bouwwerken gebracht die weliswaar na een tijd versleten en niet meer nodig zijn, maar waar we niet meer makkelijk van af komen, omdat hun overblijfselen niet meer opgaan in de natuur. Ze blijven dan gewoon staan, vormen vuilnisbelten, belasten lucht, aarde en drinkwater of draaien tot het einde der tijden als ruimtepuin rondjes om de aarde. Daarom doen we er tegenwoordig goed aan, duurzaamheid en milieuvriendelijkheid tot de firmitas te rekenen. Dit geldt niet alleen voor het artefact zelf en zijn gebruik, maar ook voor zijn productie, aanpassing an veranderende eisen en voor zijn sloop.

Wat betekent dit voor IT-systemen? We kunnen vier aspekten onderscheiden.

Stabiliteit

We noemen een bouwwerk stabiel als het bij normaal gebruik niet in elkaar zakt. De grondslag voor stabiliteit is materiaalbeheersing door de ontwerper en de bouwer. Men moet weten hoe men stenen gewelven, houten dakstoelen en stalen of betonnen bruggen ontwerpt, doorrekent en ten slotte fatsoenlijk in elkaar zet; anders stort het in. Daartoe is kennis van het materiaal en zijn eigenschappen nodig, kennis van allerlei theorie en kennis van het proces van bouwen.

Hetzelfde geldt mutatis mutandis voor de hardware van IT-systemen. Die stort misschien niet zo gauw in, maar gaat in vlammen op of stopt met werken als er iets hapert. Maar het geldt ook voor software. Die mag niet zo maar vastlopen, gekke dingen doen bij onkundig gebruik, vatbaar zijn voor virussen, toegankelijk voor inbrekers. Zo als een huizenarchitect verstand moet hebben van met metselen met bakstenen en van statica alleen al om goed te kunnen ontwerpen en om met de bouwers en met bouw- en woningtoezicht op ooghoogte te kunnen praten, moet een IT-architect verstand hebben van programmeertalen, programmeren, softwareverificatie, betrouwbaarheid en veiligheid. IT-opleidingen besteden daar dan ook de nodige aandacht aan. Belangrijke gebieden van de informatica die hieraan bijdragen zijn security en correctheid van software.

De stabiliteit van een bouwwerk hangt niet alleen af van de constructie maar ook van de omgeving. Een gebouw in moerassige grond verlangt een ander fundament dan een op een rots. De invloed van wind, weer en aardbevingen vergt in elke omgeving andere maatregelen. Vergelijkbare omgevingsproblemen in de IT worden tegenwoordig onderschat.

Zo lezen we in de krant van computervirussen in nucleaire energiecentrales. Nu moet zo'n energiecentrale absoluut veilig en betrouwbaar zijn, en de bouwkunde bij deze techniek leert hoe men dit bereikt. De bouwkunde voor de hard- en software van de nodige besturing wordt door de informatica geleverd, die leert hoe men software en het ontwerp van hardware formeel kan verifiëren. Dit is ondertussen goed begrepen, niet goedkoop, maar bij zo'n toepassing de moeite waard. Hoe kleiner en eenvoudiger de programma's, hoe minder complex de hardware, hoe eenvoudiger formele verificatie is. De hardware elf moet dan ook nog bestendig zijn tegen slijtage en materiaalmoeheid, en als dit niet gegarandeerd kan worden, gebruikt men redundante hardware. Voor al dit is er speciale, robuuste, eenvpudige hardware (bijvoorbeeld PLCs) met betrekkelijk eenvoudige besturingssystemen, programmeertalen en methoden die garanderen dat de software zich altijd houdt aan de nodige tijdseisen en niet opeens traag wordt vanwege garbage collection en niet vast kan lopen. Zo wordt de kans op ongelukken flink geminimaliseerd. Theoretisch. Want zulke hardwarecomponenten zijn duur, en men kan ze door goedkope programma's op een Windows-computer emuleren. Zo komt het tegenwoordig geregeld voor, dat een buitengewoon stabiel applicatieprogramma met een buitengewoon stabiel besturingssysteem als wirtuële machine draait op een afgedankte PC onder Windows. Het is alsof men een zorgvuldig ontworpen stalen brug zonder extra fundering in het moeras neerzet. Een ander veiligheidslek ontstaat door het feit dat zulke PLCs, hoewel ze autonoom kunnen werken, tegenwoordig graag met het internet verbonden blijven. Het is zo handig als de programmeur van zijn PC even kan inloggen om nieuwe software te uploaden. Zo kunnen virussen hun kwaadardig werk hezij vanuit het murwe fundament doen, hetzij binnenwaaien door open deuren.

Doordat computersystemen i.t.t. gebouwen uit steen, staal en glas dynamisch gedrag vertonen en zich zelf kunnen manipuleren, kan men ze zo bouwen dat ze zich bij bepaalde storingen zelf herstellen, net als levende wezens.

Houdbaarheid

Sommige bouwwerken zijn voor de eeuwigheid bedoeld, althans voor lange tijd, bedoeld. Soms valt dat tegen, omdat het ontwerp stoelt op iets gedateerds.

Sommige bouwwerken zijn bewust een oplossing voor de korte termijn. Soms staan ze er eeuwen later nog. Toen bijvoorbeeld in de 1970er jaren de eerste grote IT-systemen voor banken ontwikkeld werden, dacht niemand dat ze rond 2000 nog in gebruik zouden zijn. Met het millenniumprobleem als gevolg.

Sommige bouwwerken zo als watertorens en fabrieken uit de 19e eeuw zijn niet langer nodig, maar beginnen na een goed doordachte verbouwing aan een nieuw leven als woonruimte, kantoor of museum. Ze zijn daar niet voor ontworpen, maar hun firmitas en venustas wordt zo waardevol gevonden dat men er een nieuwe utilitas bij zoekt.

Sommige bouwwerken zijn zo ontworpen dat ze uitgebreid en aangepast kunnen worden aan nieuwe eisen. Andere, bijvoorbeeld het Jachtslot St. Hubertus van Berlage, zijn zo ontworpen dat zelfs kleine aanpassingen zonde zouden zijn.

Sommige bouwwerken verlangen regelmatig onderhoud, bijvoorbeeld een laag verf, anderen, zo als de piramides, gaan duizenden jaren zonder onderhoud mee. En weer anderen zijn na een paar jaar niet meer bruikbaar en niet meer onderhoudbaar omdat hun ontwerp cruciaal afhangt van technieken, materialen en onderdelen die na verloop van tijd niet meer leverbaar zijn.

De architect dient samen met de bouwheer goed na te gaan, hoe lang een bouwwerk dient mee te gaan en wat er na afloop mee moet gebeuren. Langere houdbaarheid is niet per se beter; korte houdbaarheid kan een bewuste keuze zijn, maar men dient de consequenties goed te doordenken. Dit geldt met name voor IT-systemen.

Lokale integriteit

De makers van de website mmminimal hebben hun principes laten doordringen tot in de wortels van de website.

Lokale integriteit is de eigenschap van een bouwwerk of een organisatie, dat elk onderdeel tot in het laatste vezeltje en schroefje in de dienst van de principes van de organisatie staat.

Toen de Spoorwegen nog niet geprivatiseerd en opgesplitst waren, was elke medewerker ervan doordrongen dat de treinen moesten rijden. Machinist, conducteur, wisselwachter, railbouwer, stationsopzichter, directeur - zij allen droegen daaraan bij omdat dat nou eens het doel van hun organisatie was. Zij allen konden in noodgevallen improviseren en daarbij ook „buiten hun boekje gaan”. Iets soortgelijks gold voor de Posterijen. Wie het niet gelooft, moge in zijn kennissenkring eens oudere NS- of PTT-mensen aanspreken. Ze zullen het bevestigen en niet ophouden met klagen over wat er ondertussen veranderd is.

Zo'n organisatie, waarin iedereen doordrongen is van de doelen en principes, ook kernwaarden genoemd, noemen we een (lokaal) integere organisatie. Als Greenpeace zijn donatiegelden in de kernwapenindustrie zou beleggen of het Vaticaan zijn gelden in pharmabedrijven die anticonceptiepillen maken, zou dat de integriteit van de hele organisatie aantasten, hoe veel goede werken ook met de winst van deze beleggingen gedaan kunnen worden. Wil je loyale medewerkes (of, in het geval van de overheid, burgers) die zich ook in moeilijke tijden inspannen voor de zaak, zal je integer moeten zijn. Lokale integriteit heeft veel te maken met →respect voor opdrachtnemers en gebruikers.

Ook de bouwwerken en IT-systemen van een organisatie dragen bij aan haar integriteit. Niet alleen alle medewerkers moeten tot in al hun vezels doordrongen zijn van de principes, maar ook de gebouwen en systemen tot in het laatste schroefje. Stel dat bijvoorbeeld het hoofdkantoor van Greenpeace de smeerolie van zijn drukpers met een loden pijp in het grondwater zou lozen en dat in de winkelruimte op de b.g. een bonthandel gevestigd zou zijn – dan noemen we dat hoofdkantoor voor Greenpeace geen integer gebouw. Hoe kunnen de medewerkers die dit dagelijks zien dan nog integer blijven?

Integriteit is een ideaal, misschien nooit helemaal waar te maken omdat men niet weet welk schroefje uit kinderarbeid in een corrupt land stamt. Maar het is een ideaal waarnaar een zichzelf respecterende organisatie en een zichzelf respecterende architect zou moeten streven. Als een organisatie voor integriteit kiest, zou een goede architect kunnen helpen om dit ook in haar bouwwerken uit te drukken. Architecten kunnen kiezen voor lokale integriteit als een leidend principe voor hun werk.

Globale integriteit

Een bom is, lokaal gezien, volledig integer. Alles staat in dienst van het doel, in een bepaalde situatie zo veel mogelijk te vernielen. Globaal is een bom iets vreselijks. Toen zich tijdens de Tweede Wereldoorlog kernfysici in verschillende landen realiseerden dat ze een atoombom zouden kunnen bouwen, hadden ze daar grote morele problemen mee. Ze konden en wilden zich niet onttrekken aan de vraag, wat de resultaten van hun onderzoek voor de wereld zouden betekenen.

Geen bouwwerk, geen IT-systeem, geen organisatie staat op zichzelf. Alles wat we maken heeft invloed op de maatschappij, het landschap en het milieu. Globale integriteit is de eigenschap dat iets geen schadelijke invloed heeft op zijn omgeving, nu niet en niet in de toekomst.

Op dit moment wordt de wereld beheerst door iets wat "de financiële markten" genoemd wordt, maar wat vooral een wereldomspannend computersysteem is dat door niemand meer begrepen en beheerst wordt. Het werkt zo snel als computer maar kunnen; daarom kan men zijn gedrag niet door simulatie voorspellen. Het kan hele landen financieel en economisch vernielen. Informatici en IT-ers hebben eraan bijgedragen door onderdelen ervan te helpen ontwikkelen. Bijna niemand maakt zich daar zorgen over. Kennelijk is het iets heel anders dan de atoombom. Of niet?

Venustas

Dit wordt een moeilijk hoofdstuk. We beginnen met een citaat uit Machine Beauty - Elegance and the Heart of Technology van de informaticus David Gelernter (1998).

In the computer world, beauty is the most important thing there is, and the paradox is this: beauty inspires the best technologists and confuses or outright repels everyone else—at least to begin with. Ordinary technologists don't understand it, and often behave as if they hate it. They don't actually; it's just that fancy features and complex, sophisticated functions inspire them—and, as for beauty, they can't see it at all. Because they are unaware of it, they will knock it over and destroy it without batting an eyelash, utterly oblivious.

Even eerder legt Gelernter uit, waarom schoonheid zo belangrijk is: software kan onze gedachten versterken; computers kunnen het menselijke intellect uitbreiden.

They can plat that role, however, only to the extent they are beautiful. No creative symbiosis is possible with an ugly virtual machine—with a complex or weak program that forces you to bent to its worldview instead of accomodating ours.

Dit boek is geschreven aan een natuurwetenschappelijke faculteit. Daar wordt nauwelijks over schoonheid gesproken. Goede natuurwetenschappers en wiskundigen weten natuurlijk dat ze zich laten leiden door een drift naar schoonheid, maar ze praten er niet over. Schoonheid kun je namelijk niet natuurwetenschappelijk onderzoeken en niet objectief meten. Schoonheid moet je beleven, samen met anderen ervaren, ervoor open staan om ze op je te laten werken. Dat laat zich niet vangen in formules en niet uitleggen in een theoretisch boek.

Daar komt dan nog bij wat Gelernter schrijft: veel techneuten, met name in de IT, kunnen schoonheid niet waarnemen en reageren met weerzin op alles wat in de buurt komt. Dit is een betrekkelijk nieuw fenomeen, en Gelernter is een van de weinigen die daar in een zeer aanbevelenswaardig boek aandacht aan besteedt.

Voor Vitruvius was het duizend jaar geleden geen punt: Een bouwwerk dient ook mooi te zijn. Hij bouwde waterleidingen. In zijn tijd deden ze het goed (utilitas), ze staan er nog (firmitas) — en hoewel ze nu technisch verouderd zijn laat men ze staan omdat iedereen ze mooi vindt (venustas). Op dezelfde manier worden tegenwoordig overal fabrieken uit de negentiende eeuw herontdekt, fabrieken zo als men ze nog een paar decennia geleden sloopte omdat ze "ouderwets" en waren.

In de software Carmen is schoonheid afwezig: felle kleuren die pijn doen aan de ogen, ouderwets uiterlijk en vreselijke lettertypen maken het werken met dit programma er niet fijner op.

Tot de Eerste Wereldoorlog was het ook voor exacte wetenschappers en ingenieurs geen punt. Men hield van zijn producten, apparaten en resultaten, dus werd er ook aandacht aan hun schoonheid besteed, zelfs bij het preparaat van een foetus op sterk water. Ga eens kijken in het Museum Boerhave! Niet opzettelijk werd er aandacht besteed aan schoonheid, niet met een programma "5% kunst aan de bouw", niet als iets extra's, maar omdat schoonheid en functionaliteit een eenheid vormden. Omdat je houdt van je producten, apparaten en resultaten, besteed je aandacht aan manier, waarop ze jezelf en de ander bekoren, zij het door een extra ornamentje dat de functionaliteit niet belemmert, zij het door te experimenteren met de verhoudingen van de vorm van het nuttige ding of van de bladspiegel en het lettertype van de publicatie erover.

Na de Eerste Wereldoorlog, toen maatschappelijke verhoudingen en politieke idealen in beweging waren, toen veel mensen een nieuw begin wilden, toen tegelijkertijd nieuw materiaal en nieuwe techniek andere manieren van bouwen mogelijk maakten, ontwikkelden docenten en studenten van het Bauhaus en hun collega's in andere landen een nieuwe stijl van bouwen, vormgeven en drukken. Nu moest men niets meer hebben van decoratie. Minimalistische kaalheid was het ideaal, met schoonheid als resultaat van eenvoud en de juiste verhoudingen. Dit alles werd bepaald door functionaliteit, utilitas dus. Form follows function. Allereerst werd opnieuw nagedacht over de functie van woonhuizen en hun diverse vertrekken, van boeken, folders en affiches, van huishoudelijke apparaten, zelfs van tuinen. Als we na deze oorlog, zo voelde men, anders denken en leven, als er andere mogelijkheden zijn om te bouwen, te stoken, de communiceren, dan willen we breken met oude gewoontes, als we daarna beter wonen, communiceren, werken, stoken en koken kunnen.

Maar tegenwoordig zijn er met name in de IT-wereld veel producten waar schoonheid ver te zoeken is. Werknemers in bedrijven en organisaties dienen gewoon hun werk te doen en niet tegen esthetisch verantwoorde schermen aan te kijken, want anders lijkt het te zeer op een spelletje, dat idee. Maar het schoonheidsbesef keert terug, en langzamerhad leren IT-guru's dat in der daad alle drie de kwaliteiten van Vitruvius belangrijk zijn. Uiteraard mag schoonheid daarbij niet hinderlijk zijn voor de twee andere kwaliteiten. Dat is juist de uitdaging voor een goede vormgever.

Schoonheid, volgens Plato de afglans van het ware, staat namelijk helemaal niet in tegenstelling tot de andere kwaliteiten. Die indruk ontstaat hooguit, als je iets achteraf decoreert om het mooier te maken en als die decoratie de functionaliteit en houdbaarheid belemmert. Of als je oriënteerbaarheid opoffert aan verkeerd begrepen minimalisme. Bij een goed ontwerp komen schoonheid, functionaliteit, houdbaarheid, oriënteerbaarheid en beleving (de laatste twee zullen we later bespreken onder 'de menselijke maat') samen en versterken elkaar.

We zullen in dit boek geen definitie van schoonheid wagen en evenmin ingaan op de vraag of over schoonheid te twisten valt. Het boek is ook geen inleiding vormgeving. We beperken is tot de observatie dat schoonheid zich bij IT-systemen op vier niveaus manifesteert:

Statisch uiterlijk

Een voorbeeld van de minimalistische vormgeving van het fotoblog Tumblr, dat de oriënteerbaarheid ten goede komt en het geheel tot een eenheid maakt. De kleuren zijn subtiel en zorgen voor een samenhangend uiterlijk. Verder ziet de gebruiker direct waar hij of zij is en zijn alle functies gemakkelijk vinden en binnen handbereik.

Net als een bouwwerk of een machine kan een computer, een mobieltje, ja, elk apparaat waar een computer in zit, bekoren door zijn vormgeving. Sommige pc's of laptops wil je liever niet in je designerinterieur hebben staan, andere misschien wel. Sommige handcomputers, bijvoorbeeld voor treinconducteurs, zien er zo plomp uit dat je er liever niet mee wilt worden aangetroffen. Ze moeten misschien een bepaalde grootte hebben, maar dit is geen excuus dat ze ook nog log en lelijk zijn. Het uiterlijk van een apparaat heeft wel degelijk invloed op de acceptatie door en het werkplezier van de gebruikers.

De bedrijven die consumentenelektronica maken weten hier alles van. En er zijn hele opleidingen toegepaste vormgeving.

Jammer genoeg is de dure audio-installatie van NAD in de werkkamer van de auteur een tegenvoorbeeld. De cd-speler, voorversterker en versterker vormen weliswaar een mooie, minimalistische sculptuur. Maar de vormen en de onderlinge plaatsing van de in totaal 25 knoppen zegt niet genoeg over hun functies. Je moet wel lezen wat erbij staat. En dat staat er in microscopisch schrift grijs op zwart, te klein en met te weinig contrast om bij schemerlicht leesbaar te zijn. Het enige effect van al die woordjes van verschillende lengte is dat de sculptuur toch nog rommelig oogt. Daar horen dan, om het goed te maken, twee erg lelijke afstandsbedieningen bij met in totaal 67 (ja, zevenenzestig) toetsen en vier dingen die op toetsen lijken maar die in feite pootjes zijn, om voor het geval dat je de dingen per ongeluk met de toetsen naar beneden neerlegt, te voorkomen dat toetsen ingedrukt worden.

Bij IT-systemen gaat het niet alleen om de vorm van de doos en de plaats van de knoppen, maar ook om de informatie op het beeldscherm, bijvoorbeeld om webpagina's. Hier komen we op het gebied van de grafische vormgeving en typografie, met eeuwen van ervaring hoe men iets doet om leesbaarheid, oriënteerbaarheid, beleving en uitstraling tot een eenheid te maken. Sinds iedereen zijn eigen webpagina's kan maken, zien we vooral hoe het niet moet. De auteur bezit ook nog een dvd- en harddisc-recorder van Pioneer. Die is tot in de knoppen perfect ontworpen en mooi. Maar wat er op het scherm van je tv verschijnt als je een opname wilt zoeken, is zo afgrijselijk dat het het niet wilt zien.

Voor de architect in de IT-wereld betekent dit: maak gebruik van de expertise van vormgevers en typografen en probeer niet zelf te stuntelen tenzij je ervoor opgeleid bent. En als dat te duur is: gebruik templates die door vormgevers ontworpen zijn!

Dynamisch gedrag

Anders dan bij de meeste bouwwerken van steen, staal en glas speelt bij IT-systemen het dynamisch gedrag een voorname rol. Op het beeldscherm beweegt iets, of het systeem beweegt hele voorwerpen. Wie naar sport of dans kijkt, ziet dat bewegingen mooi of lelijk kunnen zijn, ook al hebben ze misschien dezelfde functie. Ook zijn er mensen die graag naar de beweging van stoomlocomotieven kijken en door hun schoonheid gegrepen worden.

De auteur wordt niet gegrepen door de schoonheid van het gedrag van zijn NAD-installatie. Alle drie de onderdelen hebben een eigen 'power'-schakelaar. Als je de voorversterker inschakelt, gaat de versterker vanzelf aan, diens schakelaar heb je dus niet nodig. Als je de cd-speler inschakelt, verwacht je dat de rest ook aan gaat — bij andere installaties, bijvoorbeeld van Pioneer is dat ook het geval — je hebt namelijk aan de cd-speler niets zonder de versterker. Je moet dus de cd-speler en de voorversterker inschakelen. De eerste is dan klaar om voor je te werken. De tweede echter is dan in de slaapstand, ook al was hij voor het uitschakelen wakker. Uit de slaapstand haal je hem door een invoerkanaal te selecteren. Nee, dat is onnauwkeurig uitgedrukt. Je haalt hem uit de slaapstand door een willekeurige invoerselectorknop de drukken, bijvoorbeeld 'tuner'. Daardoor wordt het apparaat wakker, maar 'tuner' wordt niet gelecteerd. Als je dat wilt, moet je eerst wachten tot het apparaat helemaal wakker is en dan een tweede keer 'tuner' drukken. Bij 'cd' gaat het toevallig goed, want 'cd' is de default als je het apparaat uit de slaapstand haalt, ook al is de cd-speler uitgeschakeld of helemaal niet aanwezig. Mooi is anders. Maar aan deze lange, saaie alinea zie je al dat schoonheid van dynamisch gedrag niet met een blik waar te nemen is. Dit soort apparaten worden op statisch uiterlijk uitgezocht, kennelijk verlangt de afdeling verkoop dan niet altijd, dat ook aan het dynamisch gedrag aandacht besteed wordt.

Bij de huidige touch-screen-apparaten kun je interessante voorbeelden voor mooi en minder mooi dynamisch gedrag zien. Bijvoorbeeld om aan te geven dat het einde van het scrollen bereikt is en verder schuiven geen zin heeft. Bij het ene apparaat stuitert de scherminhoud even zo als een bal die legen een wand aanrolt. Bij het andere blijft alles met een ruk stil staan, en een blauwe melding geeft aan dat verder scrollen niet gaat.

Misschien het eenvoudigste voorbeeld voor schoonehdi van dynamisch gedrag is het ledje dat aangeeft of je laptop slaapt. Bij een bepaald merk is dat geen venijnig knipperend groen ledje dat niet bij je interieur past, maar een heel subtiel "ademend", onopdringerig wit gevalletje.

Talen

Taal en oriënteerbaarheid, cultuur, standaarden. De grote binnenstraat van het Huygensgebouw is op zich een goed voorbeeld voor oriënteerbaarheid: je ziet waar je zijn moet. Alleen de toiletten zijn verstopt in de kelder, en de trappen zijn niet goed te zien. Op elk vliegveld zie je hoe dit soort oriëntatieproblemen opgelost worden: er zijn standaarden voor voor de plek waar wegwijzers hangen opdat men ze kan vinden en voor de pictogrammen. Het is een taal. Maar hier zijn mensen bezig met het uitvinden van allerlei eigen taaltjes.Het ingelijste plaatje zegt: "paren op de roltrap!". En dan hangt het ook nog verkeerd, hetgeen een noodoplossing op de noodoplossing voortbracht.

Dit probleem is enige jaren later "opgelost". (Foto Mats Ouborg)

David Gelernter besteedt in zijn boek Machine Beauty vooral aandacht aan een vorm van schoonheid die je, anders als de schoonheid van gebouwen van steen, staal en glas, niet met je ogen kunt zien: de schoonheid van programma's. Hij geeft ook een aanzet tot een definitie: schoonheid is het product van eenvoud en kracht. Deze conceptuele schoonheid vinden we in de IT vooral op het gebied van talen. Eigenlijk is de informatica een soort taalwetenschap: ze kent specificatietalen, programmeertalen, vraagtalen voor databases (bijvoorbeeld SQL), talen waarin computers onderling communiceren (bijvoorbeeld html en iCal) en talen waarmee mensen een computer "bedienen" — overigens een verraderlijk woord. En de informatica kent theorieën, methoden en gereedschappen, om zulke talen in elkaar te vertalen of te interpreteren. Steeds meer van deze talen, althans als ze door mensen gelezen of geschreven moeten worden, zijn grafische talen. Ook de ledjes en de knoppen op een doos vormen het alfabet van een taal, die men moet beheersen, wil men het apparaat kunnen gebruiken.

Zolang er computers zijn zijn we op het gebied van all deze talen steeds weer dezelfde ontwikkeling.

1. Een ontwerper definieert ad hoc een interface tussen mens en het apparaat dat hij aan het ontwerpen is of tussen twee computers onderling. In het begin is dat iets heel eenvoudigs: twee, drie knoppen, twee lampjes of een paar keywords en getallen. Het is niet alleen eindig, het is klein, en de ontwerper realiseert zich niet, dat het een taal is. Je drukt gewoon op een knop en kijkt naar een lampje. Tegen de eerste modems praatte je bijvoorbeeld door ze gewoon een te kiezen telefoonnummer te vertellen of een H, als je wilde dat ze ophangen.
2. Als het apparaat steeds meer gebruikt wordt en de functionaliteit uitgebreid moet worden, komen er steeds meer knoppen, lampjes, een beeldschermpje en keywords of codes bij. Bij de modem eerst een W om op de kiestoon te wachten, en dan steeds meer letters van het alfabet. Dit alles te onthouden is al moeilijk genoeg.
3. Op een gegeven moment stelt de ad-hoc-syntax uit stap 1 grenzen. Verdere uitbreiding is niet meer mogelijk. Bij de modem bijvoorbeeld omdat het alfabet op is. Dan wordt een "escape" bedacht. Bij de modem een ampersand. Je kunt nu verder met &W, &h enz., en je meot onthouden welke commando's zo'n ampersand moeten hebben.
4. Vlak voordat ook deze escape-commando's opraken, als bijvoorbeeld &M nog niet niet verbruikt is, besluit men over te gaan op nummers: &M1, &M2 enz.
5. De bekroning van dit afschuwelijke proces is uiteindelijk een commando om rechtstreeks interne variabelen van het programma te kunnen aanspreken, liefst via hun numeriek adres. De taal hoeft dan nooit meer uitgebreid te worden. Maar de grens tussen communicatie met een apparaat en schrijven in het raderwerk aan de binnenkant is vervaagd.
6. Soms wordt er dan nog, als je toch al de binnenkant kunt manipuleren, een nieuwe programmeertaal aan de oorspronkelijke taal van de buitenkant toegevoegd: met een ander soort escape stop je een programma'tje in het apparaat. (Denk in het geval van html aan javascript!) Vanaf dit moment zijn natuurlijk de commando's uit stap 1 t/m 5 niet meer nodig, omdat met de doos nu vrij kan programmeren. Maar vanwege de compatibiliteit moeten ze er blijven.

Mooi is anders. Een beetje webpagina bestaat tegenwoordig uit in elkaar gemengde html-opmaakcodes van de allereerste generatie alsmede stukjes uit de talen ccs, php, sql, javascript en url. Al deze talen met hun eigen escapes en hun eigen manier om strings al dan niet tussen aanhalingstekens te zetten en spatis al dan niet te escapen.

De informatca weet ongeveer sinds 1960, uiterlijk 1968, hoe men zeer eenvoudige en tegelijkertijd onbeperkt krachtige talen maakt die ook nog eens door mensen goed begrepen worden en zich makkelijk laten vertalen en interpreteren. Maar in opleidingen informatica en IT schijnt men dit zorgvuldig geheim te houden, en het hierboven beschreven stappenplan herhaalt zich overal weer.

Gelukkig zijn er een paar uitzonderingen. Bijvoorbeeld een zekere taal die niet meer dan deze concepten kent: icoontjes voor bestanden, progamma's, mappen en schijfjes, een prullenmand; klikken, shift=klikken, dubbelklikken en slepen. Als je dit een keer snapt, blijkt elke combinatie van deze concepten (op wat rariteiten met de prullenmand na) precies te doen wat je verwacht, en je hebt niet meer nodig.

Wiskundige structuren

Elk stuk hardware en software en elke taal is gebaseerd op een conceptueel model, bijvoorbeeld een abstracte datastructuur of een automaat in de zin van de automatentheorie. Zulke conceptuele modellen zijn wilskundige objecten die als idee in ons hoofd leven. En ook zij kunnen, da zal elke wiskundige en natuurkundige beamen, mooi of minder mooi zijn. Ze gebruiken meestal de term "elegantie".

Het conceptuele model onder de eerder genoemde taal met icoontjes en klikken, slepen enz. is heel eenvoudig. We geven het hier informeel weer, maar je zou het ook als abstracte datastructuur in een formule kunnen vatten: "Je hebt bestanden, programma's en mappen. Programma's, bestanden en ook mappen kun je in mappen bewaren en naar andere mappen verplaatsen. Een programma kun je starten. Een bestand kun je met een erbij passend programma openen. Met een geschikt programma kun je een bestand of een programma maken." Veel meer dan dit is het niet, en dit wordt doorgaans als elegant ervaren.

De auteur is er nog niet in geslaagd, het conceptuele model van Facebook ook maar bij benadering te vatten. Het staat ook nergens beschreven. Er zijn tientallen dingen zo als een timeline, plaatjes, messages, news, vrienden, applicaties, boeken enz. enz. enz. Plaatjes kun je in mappen stoppen, en ze schijnen iets met berichten te maken te hebben. Als je zoiets als een eigen pagina voor een boek wilt aanmaken, kom je er hooguit per toeval achter, hoe men dat doet. Facebook is ongeacht de grafische vormgeving van de pagina's conceptueel door en door lelijk, erg complex en moeilijk begrijpelijk, net als een zonder plan en rede gegroeide stad of fabriek.

Of als wat vooraf ging aan het internet. Er was een tijd waarin je, om een mail van de ene naar de andere computer te sturen, het hele pad moest opgeven van alle tussenliggende computers. Een tijd waarin je iets moest weten van modems, internet via de tv-kabel, bulletin board systemen, gopher, telnet, een tcp-stack, ((hoe heetten die binaire, cecomprimeerde bibliotheken ook weer?)), V24, tiff, zip, tar enz. enz. Dit was historisch gegroeid en niet door ene Zuckerman met zijn visie ontworpen.

Ondertussen heb je internet, en je kunt met veel minder kennis van toevallige technische details communiceren en informatiebronnen raadplegen. Maar het moet nog verder gaan. Het is een uitdaging voor architecten om, net zo als ooit het Bauhaus deed, op zoek te gaan naar de fundamentele basisconcepten en vervolgens iets te ontwerpen, waar zich deze zo laten combineren dat elke combinatie doet wat je verwacht. E-mailen en chatten is bijvoorbeeld nu al stukken eenvoudiger dan in de begintijd, maar ik moet nog steeds een keuze maken tussen Jabber, MSN, ASM, Skype, Facetime enz. die niet afhangt van wat ik wil en wat logisch is maar van wat de ander toevallig geïnstalleerd heeft.

Second Life werd na een hype van een paar maanden weggehoond, en men doet er nu lacherig over. Dat is jammer, want ook in Second Life waren allerlei communicatievormen van het internet bij elkaar gebracht: chatten, mailen, help-teksten, praten, homepages, bouwen en nog veel meer. Hier was het onderliggende conceptuele model i.t.t. Facebook juist doorzichtig en eenvoudig.

De goede architect laat zich inspireren en leiden door een zoektocht

De menselijke maat

Leonardo da Vinci tekent de menselijke maat zo als beschreven door Vitruvius

Van oudsher weten architecten dat een goed bouwwerk afgestemd dien te zijn op de menselijke maat. Letterlijk betekent dit dat het bouwwerk past bij de proporties van het menselijk lichaam. Dit heeft een mechanisch aspect: Je moet in een gebouw immers kunnen staan, slapen en de trappen beklimmen. Het heeft ook een gevoelsmatig aspect: als een gebouw veel groter is dan voor het lichaam nodig, doet dat iets met je.

Wij trekken het begrip hier nog breder en beschouwen vier niveaus waarop een IT-systeem bij mensen moet passen. Aan elk niveau moet de IT-architect bij het ontwerpen van een systeem de nodige aandacht besteden.

Lichaam

Allereerst moeten artefacten waarin of waarmee mensen werken afgestemd zijn op het menselijk lichaam, met name op bewegingsapparaat (skelet en spieren); men mag niet continu gedwongen worden om ongezonde bewegingen te maken; hygiëne en temperatuur zijn belangrijk; maar ook met de zintuigen moet rekening worden gehouden.

KLEURCOMBINATIES MOETEN BIJ DE EIGENSCHAPPEN VAN HET MENSELIJK OOG PASSEN.

De iPhone bijvoorbeeld houdt rekening met het menselijk lichaam door de vorm van zijn weinige knoppen, de grootte en resolutie van het beeldscherm ("retina"!), diens gevoeligheid, de trilsensor, allerlei microfoons en luidsprekertjes, de kleurencombinaties enz. Belangrijk is ook het stukje iOS dat verantwoordelijk is voor schuiven en rekken: dat zijn dingen die men met zijn vingers ook in het echt doet. (De rest van het iOS heeft niets met lichamelijkheid te maken.)

Tegenvoorbeeld zijn PDA’s met veel te veel, veel te kleine knoppen.

Er is een hele wetenschap, de ergonomie, die zich hiermee bezig houdt.

Geest

Als een systeem niet bij het menselijk verstand past, kunnen mensen er niet goed mee werken. De cognitieve psychologie weet behoorlijk goed wat het menselijk brein kan behappen, maar veel makers van IT-systemen weten het helaas niet. Of ze hebben te lang in de bizarre wereld van MS-DOS-achtige systemen geleefd om zich nog te kunnen verplaatsen in eenvoudig gezond verstand.

Mensen zijn bijvoorbeeld niet goed in het mentaal stapelen van negaties en gevalsonderscheidingen. Als ik voor de rechter met klem betwist, nooit ontkend te hebben bij het afsluiten van het contract klagers wilsonbekwaamheid te hebben genegeerd - heb ik het dan goed of slecht gedaan, en zo ja, bij de klager of voor gerecht? En toch schotelen veel systemen de gebruiker vragen als deze voor:

Do you really want to exit? Click 'abort' to continue and 'yes' to cancel.	ja	neen

Mensen zijn wél goed bij het leren van allerlei ingewikkelde dingen, bij het omgaan met door elkaar heen lopende taalniveau's en indirecties en bij het goed interpreteren van slecht getypeerde zinnen. Maar dat verlangt concentratie en kost energie. Waarom moet men het van de gebruiker van een IT-systeem verlangen als het niet nodig is?

Waarom doet de ontwerper van een IT-systeem het de gebruiker aan, te moeten zeggen: print de inhoud van de schijf die ik toevalling in drive A: heb gestopt op de printer die iemand toevallig op port 2 heeft aangesloten. Waarom kon men decennialang bij MS-Dos-achtige systemen niet gewoon zijn schijven en zijn printers namen geven, en de computer zoekt de rest uit? Er waren toen al lang systemen die voordeden hoe het kan. Waarom moest een onschuldige gebruiker kunnen beoordelen dat vreemd gedrag te maken had met een 'ongeformateerde' schijf? Waarom moest hij de naam van een eens in de twee jaar gebruikt commando onthouden, waarmee een schijf geformateerd moet worden? Toen waren er al systemen die voordeden hoe het moest. Waarom oest men mensen inscherpen dat ze nooit zo maar een schijf mogen eruit trekken of een computer uitschakelen, omdat dan gegevens verloren kunnen gaan? Waarom niet de computer zo maken dat je hem verteld dat je nu die schijf eruit wilt hebben of wilt dat hij zich uitschakelt, en de computer zorgt ervoor dat geen ongelukken gebeuren? Het is luiheid van de ontwerper of aannemer of programmeur, met als resultaat dat mensen dingen moeten leren die totaal onnodig zijn.

Intuïtiviteit.

Oriënteerbaarheid in het klein. Op 30 augustus 2007 reed voor de tweede keer in twee weken een auto de trap af in de parkeergarage van het Huygensgebouw. Iedereen had het erover hoe dom mensen niet kunnen zijn. Maar de trap, tussen twee afritten, leek vanuit de auto precies op een afrit. Van boven kun je niet zien of er treden zijn. En na een lange werkdag zijn mensen moe en willen naar huis. — Nu zijn er paaltjes geplaatst: een noodoplossing. Uitdaging: geef de trap zodanig vorm dat verwisseling niet mogelijk is. Ook op webpagina's en elektronische apparaten roept je soms de verkeerde knop toe: "Druk mij!" En voor je het weet is er een ongeluk gebeurd.

Mensen zijn behoudend, maar ze zijn ook nieuwsgierig. Hoe kan men iets dat bijvoorbeeld de voordelen van een PC met die van een telefoon verenigt zo aanbieden dat de mensen het nog snappen ook en meteen “intuïtief” kunnen gebruiken? Toen Palm de PDA met het mobieltje deed versmelten, waren het op het beeldscherm nog twee verschillende apparaten, waartussen je hee- en weer kon schakelen. Het toetsenbord bevatte zowaar de vereniging van alle toetsen van een computer en een telefoon. Veel te veel knoppen die er altijd gelijk uitzien maar steeds weer een andere betekenis hebben. Het probeerde aan te sluiten bij culturele verwachtingen (zie onder) maar bleek veel te ingewikkeld. De iPhone gaat een heel andere weg: aansluiting wordt juist niet gezocht bij bekende, verouderde apparaten maar bij wat men wil en bij wat men uit de fysieke wereld gewend is.

Waar het om gaat: mensen leren op een bepaalde manier en hebben veel geleerd waarvan ze zich niet bewust zijn. Een artefact dat daarvan gebruik maakt, wordt als "intuïtief" ervaren. De gemiddelde IT-er zit te lang in zijn eigen wereld om daar nog gebruik van te kunnen maken. Architecten en designers zijn er beter voor opgeleid en hebben, als het goed is, geleerd uit gewoontes, verwachtingen, materiaal, lichtval en vorm juist die ingang, deurklink of trap te destilleren die intuïtief functioneert.

Filters. Op een gebied zijn computers veel beter en sneller dan de gemiddelde bibliothekaresse, archivaris of vakverkoper: ze kunnen betrouwbaar uit een onwaarschijnlijk grote database precies dat filteren, wat je nodig hebt. Als alles tenminste keurig in de database staat. Voorbeelden zijn ebay, amazon, imdb en steeds meer de site van de Consumentenbond. Wie een wasmachine zoekt die ook de poedel zachtjes kan centrifugeren, qua kleur in het interieur past, Intel inside, en een energielabel heeft, of wie voor zijn bejaarde moeder een faxapparaat met weinig knoppen en thermopapier zoekt, of juist een plaat met een zeldzame opname van een onbekende band, kan dit op internet beslist beter vinden dan in het stadscentrum of op een shopping mall.

Hier kunnen we misschien het minst leren van architecten uit de wereld van steen staal en glas. Dit is het terrein waarop computers uniek zijn. Mensen maken sinds Aristoteles en Leibniz cognitieve systemen om alles te ordenen, en die systemen zijn voor elk gebied andere. Wie verstand heeft van de classificatie van kledingmaten en stoffen heeft daardoor niet vanzelfsprekend verstand van de classificatie antiquarische boeken. Computers kunnen daarbij beter helpen dan mensen, als tenminste het systeem eenmaal bedacht is. Zolang computers niet ook deze systemen beter kunnen bedenken dan mensen, is gedegen domeinkennis van het probleemdomein nodig, om de goede filters te ontwerpen. Ebay weet hier alles van. Maar er is ook gedegen kennis van jet oplossingsdomein nodig: men moet de keuzemogelijkheden zo aanbieden dat de gebruiker er niet in verzuipt. Hier is het aangifteprogramma van de Belastingdienst een goed voorbeeld. Het lijkt op elk platform te werken en biedt op elk moment overzichtelijk en minimalistisch alleen die mogelijkheden, die nodig zijn.

Waar het om gaat: mensen hebben hun stukje wereld geordend. Een artefact dat van die ordening gebruik maakt is een echte versterking van het menselijke intellect op dit gebied.

Oriënteerbaarheid. Een groot probleem van de stedenbouw in de tweede helft van de 20e eeuw is oriënteerbaarheid, c.q. de afwezigheid ervan. Wie in Nijmegen in de Hegdambroek woont weet dat zijn gasten de eerste keer te minste twee uur nodig hebben, om zijn huis te vinden, ondanks de schilderachtige naam van de wijk. Alles ziet er gelijk uit, alles is genummerd, en nergens kun je zo maar rechtdoor.

Oriënteerbaarheid in het groot. Je iet het huis waar je zijn wilt. Te voet is het in een paar meter te bereiken. Helaas ben je met de auto. Het komt niet in je op dat voor die paar meter een TomTom nodig is. Na drie kwartier alle wegen recht op het doel af te hebben geprobeerd geef je op. - Bij websites zie je je doel misschien niet, maar je weet dat je ooit op een pagina was, en wat je ook probeert, je kunt ze niet meer vinden.

In Enschede hebben de straten in een vergelijkbare wijk geen nummers maar romantische namen als "Kafmolenhoek" en "Koppelboerhoek". Hier is vast over nagedacht: in dit soort wijken wonen starters met kleine kinderen, en begrippen als kafmolen en koppelboer spreken tot diër verbeelding. Ook hier kun je echter niets zonder TomTom vinden, en nu moet je i.p.v. een nummer ook nog die naam intypen. Dat je je doel kunt zien, helpt helemaal niet, als je met de auto bent. Vooral kom je, als je na je bezoek naar huis wilt, zo'n wijk nooit meer uit, want die ene uitrit die naar een doorlopende weg leidt, kun je onmogelijk vinden.

Met veel websites is het net zo. Je kunt je niet oriënteren; je ziet niet waar je bent; je weet niet hoe je iets terug kunt vinden waar je ooit was. IT-ers lossen dat, net als Hans en Griet, op met "breadcrumbs". Of ze bieden "sitemaps" aan — die dan natuurlijk zo complex zijn dat niemand er iets aan heeft. Kijk eens hoe veel van uw medewerkers Google gebruiken om webpagina's op de site van de eigen organisatie terug te vinden. Een teken aan de wand!

In de 19e eeuw konden stedenbouw-architecten het beter, en daar kunnen zowel stedenbouwers van nu als web-site-bouwers van leren. Bekijk eens Port Sunlight, een Engels dorp dat niet historisch gegroeid is maar in een klap neergezet werd voor de arbeiders van een zekere zeepfabriek, net als een website. Je ziet overal waar je bent, want hoewel alles uit een ontwerp stamt en dezelfde stijl heeft, is alles uniek, en van overal zie je dankzij doorkijkjes ook andere gebieden en allerlei bijzondere gebouwen. En als je ziet waar je zijn moet, kom je er ook zonder TomTom. Het is niet alleen mooi, het is vooral ook oriënteerbaar! Kunstmatige intelligentie. Eeuwenlang gold voor machines dat ze ons helpen, dingen te doen waarvan wij weten hoe met ze doet. Tot niet zo lang geleden gold dit doorgaans ook voor IT-systemen. De systemen in organisaties doen wat in de organisatie ook vroeger al volgens een bepaalde werkwijze gebeurde, alleen doen ze het sneller, betrouwbaarder en goedkoper. Althans, dat is de bedoeling. Sinds enige jaren rukken computers op die dingen doen waarvan mensen niet weten hoe men het moet doen. Ze zijn niet geprogrammeerd voor een bepaalde taak; ze hebben iets geleerd net als een kind. Het zijn geen "rekenmachines" meer, ze "denken". De theoretische informatica leert dat een denkende computer net zo onbetrouwbaar kan zijn als een medemens. Daarmee staan we aan het begin van een tweede computertijdperk, waarin computers wellicht net zo creatief, intelligent, maar zeker ook zo irrationaal en onbetrouwbaar beginnen te worden als mensen. Wie bijdraagt aan deze ontwikkeling, werkt mee aan iets dat ertoe kan leiden dat de mens niet langer de baas van alles is.

Binnen het bestek van dit boek kunnen we niet ingaan op deze ontwikkeling. Ze zijn stof voor een eigen boek: Wer isst den nächsten Apfel?

Gevoel

Tot nu toe hadden we het in dit hoofdstuk over het menselijk lichaam, dus in beginsel over fysica, en over het verstand, dus rationaliteit en logica. Maar er is meer, en daarmee verlaten we het terrein van de wis- en natuurkunde: mensen hebben gevoelens, en ook daarmee reageren ze op gebouwen en IT-systemen. Dat gaat verder dan de eerder besproken reactie op schoonheid. Een een bouwwerk, voertuig of gereedschap kan bijvoorbeeld gevoelens van onveiligheid, onbehagen of weerzin oproepen. Of juist het gevoel van veiligheid, acceptatie en saamhorigheid versterken. Een gebouw kan agressief overkomen zo als het ING-hoofdkantoor in Amsterdam, gezellig, truttig, transparant, open, gesloten of saai. Het kan maken dat gebruikers en mensen in de omgeving zich klein en onderdrukt voelen.

Architecten in de wereld van steen, staal en glas weten hier alles van. Ze weten dat een bouwwerk altijd ook een statement is dat zich aan de gevoelens van zijn gebruikers en, niet te vergeten, aan de mensen in de omgeving richt. Bouwwerken hebben een uitstraling.

Die uitstraling heeft natuurlijk in eerste instantie te maken met de eerder besproken drie kwaliteiten. Je kunt bijvoorbeeld een gevoel van nuttigheid, duurzaamheid en de missie van een organisatie oproepen. Maar uitstraling raakt ook meer algemene menselijke gevoelens. Wij geven maar drie voorbeelden.

Behagelijkheid.

Behagelijkheid in Berlijn. De plaatsing van de banken houdt geen rekening met het menselijk gevoel. Mensen in een park willen op een bank zitten, hun rust hebben en genieten van het uitzicht. Of ze willen juist met elkaar praten of samen picknicken. In het eerste geval willen ze niet op zo korte afstand tegen medemensen aankijken en bekeken en beluisterd worden. In het tweede geval willen ze dichter bij elkaar. Deze afstand van banken wordt dus als onaangenaam en - in letterlijke zin - confronterend ervaren.

Zeer centraal tussen Bundeskanzleramt en Hauptbahnhof in Berlijn vind je een vergeten parkje. Als je het vindt. Er zit nooit iemand. De meeste mensen zullen niet kunnen uitleggen waarom ze daar niet graag zijn, maar de uitstraling van dit park is eng. Met een beetje kennis van psychologie zie je dat direct.

De ondergrondse parkeergarage van het Radboud-ziekenhuis in Nijmegen daarentegen is door een paar slimme maatregelen veel minder onbehagelijk dan de gemiddelde parkeergarage en toont daardoor respect voor de mensen die daar moeten komen en niet alleen voor de auto's.

Respect. Respect voor de medemens is een goede richtlijn voor het sociale verkeer in de maatschappij. Deze richtlijn staat in de dienst van een aantal principes en wordt al duizenden jaren lang uitgedragen door filosofen, leraren en wijzen. Godsdiensten trekken het breder en roepen op tot respect voor de hele schepping, dus ook voor de natuur en door mensen gemaakte dingen. Een bouwheer en een architect kunnen hun respect voor de gebruikers en de omgeving uitdrukken door hun bouwwerk: Een goed bouwwerk toont respect tegenover de mensen die erin moeten wonen en werken en die ertegen aan moeten kijken, maar ook tegenover de omgevende gebouwen en het werk van hun architecten. Op die manier moedigt het ook wederzijds respect tussen mensen aan. Een goed gebouw toont ook respect voor zijn omgeving en draagt zo bij aan het respect van anderen voor de omgeving en natuur.

De Erasmusbrug in Rotterdam is de wellicht mooiste brug van Nederland. Maar vanuit het centrum kan men dat niet meer zien, want Renzo Piano en de KPN moesten er zo nodig een agressieve, schuine kantoortoren achter zetten die met zijn lijnen de aanblik van de brug totaal verstoort. Geen respect voor de Erasmusbrug en haar architect Ben van Berkel, maar ook geen respect voor de burgers van Rotterdam, die veel geld hebben betaald omdat ze zo'n uitzonderlijk mooie brug wilden.

Respect begint al met kleine dingen. Voor de hoofdingang van veel kantoorgebouwen moet elke bezoeker door peuken waden. Dit straalt uit: richting werknemers werknemers: "Als jullie al rookverslaafd zijn, jullie zoeken het zelf maar uit, in de kou, naast een draaideur."; richting de schoonmaakdienst: "Jullie ruimen het maar op, desnoods met je vingers tussen de tegels. Of met een bladblazer waar elke medewerker gek van wordt."; richting bezoekers: "Deze instelling volgt de letter van de wet ook al gaat dit ten koste van schoonheid en uitstraling."

In de IT-wereld is het soms nog erger. Sommige IT-ers van het oude stempel respecteren gebruikers helemaal niet, maar vinden ze gewoon dom. Kijkt u eens, hoe in uw eigen organisatie over "de gebruiker" gepraat wordt! En kijkt u eens naar het IT-systeem waarmee u van uw werkgever moet werken: is het zo omslachtig dat het u tot veel onzinnige handelingen dwingt? Waarom accepteert uw baas dit dan? Misschien omdat hij liever vol ontzag luistert naar de IT-ers dan naar gebruikers. Weet u of uw baas eigenlijk weet hoe het voelt om met zo'n systeem te moeten werken? — In het spanningsveld van belanghebbenden is respect soms ver te zoeken.

Er zijn web-sites waar men graag komt. Maar er zijn er ook waarvan men hopeloos en kwaad wordt. Het tonen van respectloosheid begint al met de melding: "Deze pagina is geoptimaliseerd voor Internet Explorer met een schrermresolutie van..."

Macht. Architecten en bouwheren hebben een paar duizend jaar ervaring met gebouwen die macht uitstralen. Bij dictatoren en koningen gaat het dan in eerste instantie om paleizen, in nieuwe tijd ook om regeringsgebouwen. In democratieën komen daar parlements- en gerechtsgebouwen bij. De onderdaan of burger moet zien en voelen wie de macht heeft en zich daarbij hetzij prettig voelen en trots op zijn staat zijn, hetzij heel klein en bang worden, afhankelijk van de principes van de bouwheer.

Toen in de 19e eeuw Noorwegen onafhankelijk werd met Oslo als hoofdstad, ontstond in het centrum van Oslo een bewust gepland, overzichtelijk ensemble uit koninklijk slot, parlement, nationaaltheater, universiteit en Grand Hotel: een democratische monarchie die kunst en wetenschap hoog in het vaandel heeft en waar gasten welkom zijn. In andere landen mag het ietsjes groter zijn en men bouwt een nieuwe hoofdstadt, zoals bijvoorbeeld Brasilia.

In moderne tijden dragen naast gebouwen ook web-sites, officiële documenten (paspoort, id-kaart, etc.) en briefpapier bij aan deze uitstraling.

Cultuur

Tot dusver hebben we in dit hoofdstuk mensen als individuen beschouwd. Maar mensen hebben ook nog samen culturen opgebouwd, en in de ene cultuur is de menselijke maat anders dan in de andere. Cultuur heet te maken met symbolen, verwachtingen, gewoontes, normen en waarden, taalgebruik, rituelen en nog veel meer.

In het eenvoudigste geval gaat het om gewoontes bij het omgaan met techniek. In de wereldwijde cultuur tot ongeveer 20 jaar geleden konden zich mensen om te bellen niets anders voorstellen dan een apparaat met 12 toetsen of juist een kiesschijf en een hoorn op een haak. Op mobieltjes is de hoorn nog steeds op een knop afgebeeld. Over een paar jaar zal niemand dat meer snappen, omdat de cultuur verandert. De eerste PDAs wrongen zich in bochten om tijdens het bellen eruit te zien als een telefoon en in de rest van de tijd als een DOS-machine. Dat is één aanpak van change management. Werkt vaak goed, maar houdt de echte vooruitgang tegen, bijvoorbeeld het besef dat een volwaardige telefoon en een volwaardig adresboek (en niet een slap aftreksel van het “echte” adresboek bij elkaar horen.

De ontwerper van IT-systemen heeft hier te maken met het spanningsveld tussen aansluiten bij verwachtingen en gewoontes van het oude en het verleiden door het revolutionair nieuwe.

Een ander probleem, eveneens bij de omgang met techniek, is dat in het ene land namen, telefoonnummers en postcodes anders functioneren dan in het andere. Voor je het weet is je prachtige adresboek-applicatie in het buurland waardeloos. Zo zijn er systemen die niet fatsoenlijk omgaan met tussenvoegsels in Nederlandse namen en systemen waarin je een postcode uit het buurland helemaal niet kunt opslaan. En wat is eigenlijk de voornaam en de achternaam van Kim Il Jong?

Maar ook op niet-technisch gebied kan van alles mis gaan. Stel, dat het Apple-logo geen appel was geweest maar een schattig geluksvarken, dat duidelijk zichtbaar en roze verlicht op elke laptop staat. Varkens zijn in veel culturen onrein. Wil iemand in zo;'n cultuur met zo'n laptop aangetroffen worden?

Hier in het westen kunnen we er ook iets van. Op veel oudere klokken staande uren in romeinse getallen op de wijzerplaat. Waarom staat daar dan altijd IIII in plaats van jet correcte IV? Omdat IV in het romeins de eerste twee letters van de naam van de heidense god Jupiter zijn. Zoiets wilde men niet in zijn huis hebben.

Is dit iets van lang geleden? Nee, ook in onze tijd in West-Europa hebben streng gereformeerde kringen serieus last van vlag en wapen van de Europese unie. Dat blauw, die twaalf sterren in een cirkel — dat zijn symbolen van Maria. Katholieker kan het niet, en tegen zoiets moet men op elke kentekenplaat en elk bankbriefje aankijken.

Voor de ontwerper van IT-systemen betekent dit: ken de cultuur van de beoogde gebruikers! Zeker als je je product wereldwijd wilt slijten kun je hier niet alert genoeg zijn.

Deel III. De architect

We vatten de belangrijkste inzichten uit deel I en deel II samen:

Bij IT-projecten kan men, net als bij alle bouwprojecten, vier groepen belanghebbenden onderscheiden. Zij hebben uiteenlopende, soms tegenstrijdige belangen. Door taal- en cultuurverschillen kunnen deze groepen moeilijk of niet met elkaar praten. Makers hebben in de IT soms wat eenzijdige domeinkennis van het oplossingsdomein, d.w.z. ze hebben een voorkeur voor bepaalde technieken. De domeinkennis van het probleemdomein is soms moeilijk te vergaren. De omgeving van het te maken systeem biedt kansen en legt beperkingen op. Opdrachtgevers en aannemers hebben de neiging om gemene problemen verkeerd aan te pakken. Of helemaal het verkeerde probleem aan te pakken. Allerlei onzichtbare, niet officiële systemen binnen een organisatie geven nuttig inzicht over het probleem en de beste oplossing. Het IT-systeem dat als oplossing gepresenteerd wordt moet niet alleen met hangen en wurgen doen wat het moet doen, het moot ook nog stabiel, houdbaar, integer en mooi zijn en rekening houden met de menselijke gebruiker.

Opdrachtgevers van bouwprojecten noch bouwers zijn ervoor opgeleid om met al dit rekening te houden. Als een beslisser zo maar een informatiseerder een opdracht geeft, kan het niet goed gaan, zelfs als beide parijen de beste bedoelingen hebben. Maar als je de gebruikers laat meebeslissen, gaat het ook niet automatisch goed, omdat bijna niemand het nodige overzicht over het geheel en volledige domeinkennis heeft.

Dit probleem is overigens van alle tijden en doet zich ook bij de bouw met steen, staal en glas voor. Daar heeft zich gedurende vele eeuwen het vak architectuur uitgekristalliseerd. Vandaar dat we voor het eigenlijke begin van dit boek de lezer uitnodigden tot een excursie door de architectuur.

Helaas wordt het woord "architectuur" tegenwoordig in de IT-wereld voor allerlei andere dingen gebruikt. In dit boek sluiten we aan bij de oorspronkelijke betekenis, niet bij het IT0jargon. De volgende definitie in de Engelstalige Wikipedia geeft goed weer wat wij hier met "Architectuur" bedoelen:

Architecture (Latin “architectura”, from the Greek “ἀρχιτέκτων – arkitekton”, from ἄρχων chief or leader and τέκτων builder or carpenter) is the art and science of designing buildings and other physical structures. Architecture is both the process and product of planning, designing and constructing space that reflects functional, social, and aesthetic considerations. It requires the manipulation and coordination of material, technology, light, and shadow. Architecture also encompasses the pragmatic aspects of realizing designed spaces, such as project planning, cost estimating and construction administration. A wider definition may comprise all design activity from the macro-level (urban design, landscape architecture) to the micro-level (construction details and furniture). In fact, architecture today may refer to the activity of designing any kind of system and is often used in the IT world. Architectural works are often perceived as cultural and political symbols and as works of art. Historical civilizations are often identified with their surviving architectural achievements. [1]

Archiutectuur is een vak, en dit vak heeft zowel iets van een kunst als van een exacte wetenschap.

Voor verschillende combinaties van probleemdomein en oplossingsdomein kennen we al langer specifieke architectenopleidingen: tot hoogbouwarchitect, binnenhuisarchitect, tuinarchitect, landschapsarchitect enz., maar overal leer je, als het goed is, belangen af te stemmen, het juiste probleem met de juiste methode aan te pakken, kwalitatief hoogwaardige oplossingen te ontwerpen en ervoor te zorgen dat een aannemer die ook kwalitatief hoogwaardig realiseert. Architect is in veel landen een beschermd beroep met behoorlijke opleidingseisen. Het is ook een beroep waarmee men eeuwenlang en internationaal beroemd kan worden. De beste architecten staan niet in dienst van een bepaalde aannemer.

Voor de digitale bouwwereld is het helaas nog geen beschermd beroep met vastgelegde opleidingseisen, terwijl de woorden "architect" en "architectuur" binnen de IT voor allerlei verwarrende dingen gebruikt worden. Met als resultaat dat het in veel gebruikers en bouwheren niet eens opkomt, een echte architect zo als hier bedoeld in te schakelen. Er zijn tegenwoordig dan ook te weinig goede IT-architecten, dus moeten er meer opgeleid worden. Universiteiten moeten de juiste opleiding aanbieden en mensen met de juiste mentaliteit ervoor interesseren.

Spraakverwarring

Als u voor uw project een IT-architect probeert te vinden, moet u op het ergste voorbereid zijn. U zult teksten als deze tegenkomen:

Architectuur is een samenhangend geheel van principes en modellen van de huidige én de gewenste situatie, dat daarmee richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie. [2]

Nee! "Architectuur" betekent in eerste instantie een vak, namelijk de kunst en wetenschap van het ontwerpen van bouwwerken. Net als bij "wiskunde" en "natuurkunde" wordt het woord ook gebruikt voor het beroepsveld en voor de opleiding ertoe. Dat kun je studeren, dat kun je beheersen, daarvan kun je leven. Net als bij "wiskunde" en "natuurkunde" wordt het woord verder ook gebruikt voor deelgebieden, stromingen en perioden van het vak, voor opleidingen tot eendeelgebied en voor beroepsspecialisatie: stationsarchitectuur, verkeersarchitectuur, renaissance-architectuur en, ja, computerarchitectuur en netwerkarchitectuur.

In zijn werk doet de architect er goed aan om per project te streven naar "een samenhangend geheel van principes en modellen van de huidige én de gewenste situatie, dat daarmee richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie." Zo als een dokter er soms goed aan doet zich een ziektebeeld voor ogen te halen, d.w.z. een verzameling kenmerken van een organisme waardoor degene die het ziektebeeld heeft zich onderscheidt van 'gezonden' en lijkt op anderen met een overeenkomstig beeld. Maar een dokter zal nooit roepen: "Geneeskunde is een ziektebeeld." Of: "Geneeskunde is een verzameling kenmerken van een organisme." Hij weet dat hij met zulke wartaal het aanzien van zijn vak ondermijnt.

De arme bouwheer die nu probeert te begrijpen wat bedoeld is met dat ingewikkelde "samenhangend geheel" pakt een ander artikel over architectuur en leest:

Although organizations increasingly realize the importance of architecture, the actual added value remains elusive to many. The question "what do we get out of architecture?" remains a tricky one.[3]

Geen wonder, dat niemand een professioneel architect wil inschakelen! Bedoeld is waarschijnlijk:

„De IT-situatie is in de meeste organisaties zo rommelig dat een professioneel architect er goed aan doet, allereerst een samenhangende analyse te maken van het (veronderstelde) geheel van principes en modellen van de huidige én de gewenste situatie, om daarmee richting te geven aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie. Laten we het achterhalen van dit samenhangend geheel ,structuuranalyse’ noemen (of 'IT-ruimteplan' of enig ander woord dat niet botst met het gewone taalgebruik). Zoiets is overigens duur, maar verdient zich later terug. Helaas ziet niet elk bedrijf dat in.”

Hier wordt meteen een probleem duidelijk. Te vaak komt het in de IT voor dat een dure adviseur, die zich al dan niet architect noemt, een omvangrijk, ontoegankelijk document oplevert als resultaat van zo'n structuuranalyse, zonder dat het vervolgens goed gebruikt wordt. Misschien kun je de architect beter verantwoordelijk maken voor het hele traject van ontwerp over kwaliteitscontrole naar ingebruikname en daarop afrekenen. Die structuuranalyse zal hij dan voor eigen gebruik moeten maken. Een dokter betaal je ook liever voor zijn behandeling, niet voor het ziektebeeld.

De opleiding tot architect

Wat een goede IT-architect moet hebben geleerd, kunnen we uit het voorafgaande afleiden. Een architect...

• kan ondanks taalproblemen uit de bouwheer, eventuele domeinexperts bij diens organisatie en uit de beoogde gebruikers trekken wat voor soort gebouw echt nodig is,
• kan een evenwicht vinden tussen uiteenlopende belangen,
• daarbij rekening houden met de onuitgesproken belangen en behoeften van mensen en van de omgeving,
• weet dat ook beleving, uitstraling en schoonheid beslissende succesfactoren zijn en kan daarmee omgaan,
• beschikt over de nodige materiaalkennis en theorie om een adequaat IT-bouwwerk te ontwerpen en het ontwerp voor bouwheer én aannemer begrijpelijk te beschrijven,
• weet dat je soms niet het hele bouwwerk in één klap moet ontwerpen en laten maken, maar dat je het beter in fasen doet ontstaan en daarbij uit de ervaringen leert,
• kan de aannemer instrueren en op ooghoogte met hem onderhandelen, en
• kan de kwaliteit van de uitvoering van de bouw en het opgeleverde gebouw controleren.

Zijn opleiding moet daarom een brede combinatie verschillende disciplines zijn:

Communicatie en omgaan met verschillende talen. De architect moet met alle belanghebbenden en de nodige domeinexperts kunnen praten, hun eisen, wensen en principes achterhalen, hun documenten en alle nodige voorschriften lezen, zijn oplossing begrijpelijk presenteren en de mensen van het aannemersbedrijf en de toekomstige gebruikers juist instrueren.

Informatici, IT-specialisten, systeemontwikkelaars en programmeurs hebben dit waarschijnlijk niet in hun opleiding geleerd. Sterker nog: deze beroepen trekken mensen aan die niet goed zijn in het communiceren met mensen met een andere gedachtenwereld. Daarom hebben veel IT-bedrijven speciaal opeleide mensen voor het contact met klanten en de aquisitie van projecten. Sommige ervan zijn architecten, sommige zijn veredelde verkopers en hebben evenmin de nodige kunde.

Materiaal- en bouwkunde van het oplossingdomein. De architect moet een degelijk en uitvoerbaar ontwerp kunnen maken, rekening houden met nieuwe materiaalsoorten en bouwtechnieken, maar ook met duurzaamheid. De architect moet op ooghoogte met de bouwers van de aannemer te kunnen praten en de kwaliteit van de uitvoering controleren. Bij een IT-architect is te denken aan:

• beschikbare hardware (om ervoor te kunnen ontwerpen),
• bestaande systemen, bibliotheken en modules,
• te verwachten ontwikkelingen op hard- en softwaregebied om daarop te anticiperen en rekening te houden met duurzaamheid,
• standaard-interfaces en protocollen,
• diverse programmeer- en specificatietalen,
• machinetal (om te begrijpen wat er mis kan gaan en waarom),
• gereedschap voor requirements, specificatie en ontwerp,
• gereedschap voor realisatie. De IT-architect kan namelijk in sommige gevallen zonder tussenkomst van een aannemer zijn ontwerp automatisch doen genereren.

Voor de digitale wereld betekent dit dat een flink deel informatica in de architectenopleiding noodzakelijk is. Omgekeerd kan niet elke informaticus architect genoemd worden.

Bing, een imitatie van de standaard dat de standaard moet verdrijven. Als bedrijf kun je nog zo veel geld en macht hebben, je bent niet alleen op de wereld. Een onderdeel van omgevingskunde is de kracht om te beoordelen in hoeverre jouw product iets toevoegt aan de omgeving. Bij Microsoft is dit begrip onbekend, vandaar dat Bing een koosnaampje heeft: 'Because it's not Google'.

Omgevingskunde. De omgeving van elk bouwwerk van steen is anders: de bodem, het weer, het landschap, het verkeer, de lokale wetten en verordeningen. De architect moet zich daarop kunnen instellen. Dit begint met goed kijken naar de omgeving en kunnen waarnemen wat belangrijk is. In de IT-wereld komt daar bij dat de gewenste systemen dynamisch verwegen zijn met hun omgeving. Een woonhuis ondersteunt weliswaar ook het dynamisch gedrag van zijn bewoners, maar het maakt niet uit wanneer precies ze naar het toilet of naar bed gaan, als het maar kan. Een IT-systeem is onlosmakelijk verbonden met dynamische bedrijfsprocessen. Dus moet de architect ook naar zulke processen moeten kunnen kijken en zien wat belangrijk is. En er komt nog iets bij: dat dankzij het internet elke omgeving eigenlijk overal is en dat alles razendsnel verandert. Wie bijvoorbeeld een nieuwsvoorziening bouwt en daarbij geen rekening houdt met RSS, Twitter en Facebook loopt hopeloos achter. Terwijl nu al zeker is dat ook Twitter en Facebook over een paar jaar achterhaald zullen zijn en RSS al als ouderwets geldt. Overigens vervaagt het onderscheid tussen materiaalkunde en omgevingskunde. Anders dan bij bruggen van beton bestaat de relevante omgeving van een IT-systeem voor een belangrijk deel uit hetzelfde materiaal. En de architect kan ervoor kiezen om zijn ontwerp te laten aansluiten op sociale media, maar ook ervoor, een functie van een sociaal medium te gebruiken als onderdeel van zijn systeem. Daarom is een deel van de omgevingskunde al onder materiaalkunde afgehandeld. Erbij komen onder meer:

• organisaties, bedrijfsprocessen en bedrijfsregels,
• wetten, bijvoorbeeld voor privacy
• Internet, sociale media en hun gebruik

Milieu: tijd, maatschappij en natuur. Wetenschap en technologie zijn niet geïsoleerd. Ze hebben een temporele en maatschappelijke context en uitwerkingen op de natuur. Opvattingen en methodes hebben hun herkomst; beslissingen hebben consequenties voor de toekomst. Een academicus is zich hiervan bewust en heeft de competentie deze inzichten te integreren in zijn wetenschappelijk en professionaal werk." Elke academische opleiding zou vanzelfsprekend dit zulk bewustzijn moeten bevorderen. De informatica is er helaas weinig van doordrongen en de IT-wereld vrijwel niet. Systematisch leren uit het verleden krijgt nauwelijks aandacht. Men kijkt zelden verder vooruit dan een paar jaar, terwijl de IT-wereld binnenkort dramatisch zal gaan veranderen. Oog voor de maatschappelijke context wordt eerder als hinderlijk ervaren. Met doet wat de opdrachtgever nu verlangt, want die zal het wel weten. Nederlandse universiteiten worden door regering en bestuurders eraan gehouden, voor het "afnemende veld" op te leiden. Met name informatica en verwante opleidingen komen zo in een vicieuze cirkel terecht. De sprekers van de arbeidsmarkt bepalen wat een afgestudeerde moet kunnen. Het gaat om het hier en nu, en als het al om innovatie gaat dan om iets dat gegarandeerd binnen zes maanden geld oplevert. Een toekomstvisie op langere termijn is zelden gevraagd, want het bedrijf van de werkgever is dan al lang een paar keer overgenomen en de regering vervangen. Daarom had zoiets als een iPhone met alles eromheen nooit in Nederland bedacht kunnen worden. Men kleeft bang aan het hier en nu en durft niet eens over een visie te praten. Alles is tenslotte goed zo als het is. Een IT-architect moet opgeleid zijn om

• bewust te profiteren van de kennis van verworvenheden en fouten uit het verleden (IT-architectuurgeschiedenis),
• een toekomstvisie te durven ontwikkelen die verder gaat dan het voorzichtig extrapoleren van de huidige toestand,
• zich van zijn maatschappelijke verantwoordelijkheid bewust te zijn en deze ook te nemen; niemand anders is tenslotte op IT-gebied breed genoeg opgeleid om dit te kunnen.

Modelleren. Architecten werken al eeuwen met modellen. Dat kunnen tekeningen zijn, huisjes van karton, en tegenwoordig steeds meer driedimensionale modellen in de computer, die men van alle kanten kan bekijken. Aan zulke modellen kan men ook rekenen, bijvoorbeeld om na te gaan of het gebouw niet instort onder zijn eigen gewicht en niet trilt in de wind. Bij IT-systemen is dit bijzonder complex. Zij beheren en sturen informatiestromen, verkeer, geld- en goederenstromen, bedrijfsprocessen enz. Het gaat om dynamisch gedrag, en een kleine fout kan catastrofale uitwerkingen hebben. Zulke systemen kan men niet ontwerpen zonder dynamische modellen van het systeem en zijn omgeving te maken en deze door te rekenen. Het begint met het modelleren van de omgeving en de eisen en eindigt met het bespreken van het ontwerp met de belanghebbenden.

Ontwerpen. Vanzelfsprekend moet een architect kunnen ontwerpen. Bij de IT-architect gaat dat verder dan het in de informatica gebruikelijke ontwerpen van software, databases, websites enz. Ook het biometrisch paspoort met alles erop en eraan is een bouwwerk: de database, te terminals bij de marechaussee, de loketten in gemeentehuizen, beveiligde verbindingen, websites die uitleggen wat de burger moet doen, het maken van de boekjes zonder dat het genummerde papier zoekraakt, distributie en ook de regels die bepalen wat de betrokken ambtenaren moeten doen - alles moet bij elkaar passen. De IT-architect moet de volgende dingen samen kunnen ontwerpen, en wel zodanig dat ze en waar verstandig uit bestaande componenten gerealiseerd kunnen worden:

• software,
• hardware en netwerken,
• protocollen,
• user interfaces en talen,
• bedrijfsprocessen en bedrijfsregels,
• uiterlijke vormgeving, die ook esthetisch voldoet.

Een systeem als het biometrisch paspoort hoeft niet in een klap landelijk opgeleverd te worden; het kan best beginnen met proeven in één gemeente en bij één grenspost, maar het moet wel werken, aansluiten bij wat er is en met groeiend inzicht behoedzaam aangepast kunnen worden. Nederland is er overigens verzot op, dingen die men nog niet goed begrijpt in een klap landelijk in te voeren. Herinnert u zich nog aan Deci-Bel? Opeens moesten alle telefoonnummers over nacht uit 10 cijfers bestaan. Er kwamen boekjes, tabellen, voorlichtingscampagnes, terwijl in het buurland in oude dorpjes nog steeds telefoonnummers met drie cijfers naast vaal langere in gebruik zijn en de EU al lang bezig was met andere richtlijnen. En nu weer de ov-chipkaart. Deze dure obsessie kan alleen worden doorbroken door goede architecten die met hun autoriteit kunnen uitdragen hoe men zoiets behoedzaam en stapsgewijs aanpakt: agile development.

De menselijke maat. Systemen die door mensen gebruikt worden, moeten aansluiten bij hun lichamelijke en cognitieve vermogens, moeten als aangenaam beleefd worden en passen in de cultuur van de gebruikers. De IT-architect moet hier blik en aandacht voor hebben.

Theorie. Bij alle genoemde gebieden hoort theorie. De architect moet deze niet alleen in gestalte van gecomputeriseerde gereedschappen kunnen toepassen maar ook zelf begrijpen, ten minste in hoofdlijnen. We noemen enkele voorbeelden:

• correctheid en formele verificatie,
• logica,
• talen,
• formeel modelleren, bijv. relationele databases, bedrijfsregels,
• onderhandelen.

P.R. Een architect moet zichzelf ook goed kunnen verkopen. Omdat er tegenwoordig te weinig goede IT-architecten ingeschakeld worden, moet hij ook voor zijn vak kunnen werven. Dat betekent niet dat de architect ook nog zijn eigen p.r.-bureau moet runnen met alle nodige expertise. Maar hij moet wel helder kunnen uitleggen wat hij kan, wat zijn aandachtsgebieden zijn en welke visie hij heeft. Daarbij helpt het, geslaagde projecten begrijpelijk te presenteren. We noemen dit hier, omdat dit voor huidige informatiekundestudenten niet vanzelf spreekt. Ze zien zich vaak nog als uitvoerende, die op opdrachten wachten, niet als experts op academisch niveau, die ook eens het voortouw kunnen nemen. Elke goede IT-architect zou een portfolio moeten kunnen bijhouden dat antwoord heeft op vragen als deze:

• Wat kan ik?
• Wat is mijn visie op mijn vak en de maatschappij?
• Welke proeven van bekwaamheid heb ik geleverd?
• Wat zijn mijn bijzondere aandachtsgebieden en sterke kanten?

Het werk van de architect

Een architect met deze bekwaamheid is, zo als we hebben gezien, in de ontwerpfase van een bouwproject absoluut nodig. In gunstige gevallen kan hij zelfs zonder aannemer zijn ontwerp automatisch laten realiseren. Maar hij kan ook later bijdragen tot het slagen van het project: door tijdens de bouw en bij oplevering de kwaliteitscontrole te verzorgen en na de oplevering de ingebruikname te begeleiden. Ook kan zo'n architect gevraagd worden om een analyse te maken van een bestaand bouwwerk of systeem en de aanpassing aan nieuwe vereisten of een veranderende omgeving te begeleiden.

De vrije, onafhankelijke, verantwoordelijke architect (geïdealiseerd). De bouwheer kiest zorgvuldig een onafhankelijke architect, d.w.z. een architect die niet in dienst is van een aannemersbedrijf. Kwaliteitscriteria zijn eerdere proeven van bekwaamheid (portfolio) van de architect en zijn opleiding. De architect luistert goed naar de bouwheer en naar de boogde gebruikers en verwerft vertrouwen door te laten merken dat hij echt begrijpt waar het om gaat. Hij kan ook toelichten wat op dit beginstadium nog niet duidelijk is en hoe hij met deze onduidelijkheden en het spanningsveld van belanghebbenden zal omgaan. Hij weet een agile aanpak door te zetten indien dit nodig is. Als de bouwheer besluit, met deze architect verder te gaan, wordt contractueel vastgelegd dat de architect niet alleen een ontwerp oplevert maar ook de aannemer aanstuurt, tijdens de bouw en na oplevering verantwoordelijk is voor de kwaliteitscontrole en dat hij de gebruikers begeleidt bij het in gebruik nemen van het systeem.

De rijksbouwmeester. De Nederlandse overheid is regelmatig bouwheer van grote en kleine projecten. Ze is niet alleen verantwoordelijk voor het goed functioneren van deze gebouwen maar ook voor het welzijn van de gebruikers en de omgeving. De overheid heeft daarom een van de aannemerswereld onafhankelijke architect in vaste dienst. Deze rijksbouwmeester kan niet zelf als architect alle projecten trekken, maar kan er wel op toezien dat de juiste architecten gekozen worden en de kwaliteitscontrole naar behoren gebeurt. Daan Rijsenbrij verlangt al jaren naar een "digitale rijksbouwmeester.

Aanhangsel. Architectuuranalyse

De volgende lijstjes zijn niet bedoeld als formulieren voor een invuloefening maar als richtsnoer voor degene die een project analyseert en uitvoert. Het resultaat van een architectuuranalyse dient een voor de nodige belanghebbenden leesbaar, acceptabel document te zijn dat starke en zwakke punten, kansen en belemmeringen helder uitlegt. Dit hoeft niet noodzakelijk de indeling van deze lijstjes te volgen.

Focus

Aan het begin van een project kan men beter in kaart brengen wat men wee, wat gegeven en wat gezocht is. Onderstaande indeling, gebaseerd op deel I van het boek, kan daarbij helpen. Het gaat er in eerste instantie niet om, de specificatie, de blauwdruk, de principes van de organisatie en de domeinkennis op te schrijven. Het gaat erom, wat we over deze informatie en haar totstandkoming weten.

het doel van de architectuuranalyse, bijvoorbeeld: analyse van de kwaliteit van een bestaand artefact ontwerp van iets nieuws aanpassing van iets wat al bestaat reconstructie van de nodige regels bij iets wat al bestaat of waarvan een blauwdruk voorligt de behandelde gezichtspunten het fragment van de realiteit en wat men erover weet het artefact (links onder in het rationaliteitsvierkant: het ding in het echt (in de fysieke realiteit)) Om welk segment van de realiteit gaat het? Bestaat het al? Het bestaat nog niet. Het bestaat al maar moet vervangen worden. Welke regels horen er op dit moment bij? Het bestaat, maar moet uitgebreid of aangepast worden. Welke regels horen er op dit moment bij? Is er al gekozen voor een bepaald oplossingsdomein (bijv. web-applicatie i.t.t. smartphone-app, Microsoft i.t.t. open source)? Welk en waarom? Is de nodige kennis van het oplossingsdomein beschikbaar? Waar? Wat weten we over de omgeving? alle overige concernsystemen alle niet officiële, mogelijk in wildgroei ontstane systemen binnen de organisatie welke apparatuur en welke systemen gebruiken de beoogde gebruikers buiten de organisatie? de gewenste eigenschappen (rechts onder in het rationaliteitsvierkant: wat moet het doen in het echt?) Hoe zijn de gewenste eigenschappen gedefinieerd? Door een vaag onbehagen? Door ontevredenheid met de bestaande situatie? Door de wil om een aantal bestaande systemen met elkaar te verbinden? Door een geschreven specificatie? zijn we zeker dat het geen EPS-probleem is? wat zijn de principes van de organisatie? staan die ergens, bijvoorbeeld in een mission statement? zijn de medewerkers ervan doordrongen? de specificatie staat op papier wat het systeem precies doen? Zo ja: is het een specificatie i.t.t. een blauwdruk? welke doelgroep kan deze specificatie lezen en beoordelen? hoe veel vrijheid laat deze specificatie bij het kiezen van een techniek voor de oplossing? kunnen alle belanghebbenden zich vinden in deze specificatie? is het soms een gemeen probleem? de blauwdruk (links boven in het rationaliteitsvierkant) is er een complete blauwdruk... van de nodige hardware van de nodige software van de nodige regels voor gebruik voor beheer in welke talen / formalismen is de blauwdruk opgeschreven welke tools horen daar bij?

Spanningsveld belanghebbenden

Wie is de bouwheer? Principes? Wat moet uitgestraald worden Hoe kijkt de bouwheer aan tegen de medewerkers van zijn organisatie? Kent de bouwheer zijn mogelijkheden en beperkingen? Welke probleemdomeinkennis heeft de bouwheer zelf? Welke heeft hij in huis? Waar? Hoe wordt de kwaliteit van het gebouw beoordeeld? Is agile development bekend? Van toepassing? Groei in het algemeen? Is nagedacht over de rol van architect en aannemer? Wie zijn de gebruikers? Welke verschillende groepen? Waar zit de domeinkennis? Ook in de gebruikers zelf? Wat voor soort mensen? In welke relatie tot de bouwheer? Principes, ethiek, ... Ergonomie Beleving Is er al een aannemer? Wie? Monopolie? Verstrengeling? Materiaalkennis? State of the art? Beperkt tot bepaalde bouwwijzen? Groei en agile development? Wat is de omgeving? Mensen Aanpalende systemen Internet, verkehr Organisaties Servers, providers Natuur Overheid met regels enz. Welke rol speelt beleving? Wie is de architect? Onafhankelijk? Verstrengeling? bekwaamheid Welke ontwerpmethode? Beheerst hij agile development?

Kwaliteit

Dit is gebaseerd op deel II van het boek.

utilitas is er zicht op de bestaande situatie? onzichtbare wildgroei weet de leiding wat er allemaal is? wil men het serieus weten? worden medewerkers met eigenbouw-systemen serieus genomen? inconsistentie is er organisatiebreed bewustzijn dat de informatie consistent moet zijn, ook dwars door verschillende databases? inkapeseling is de leiding ervan doordrongen dat er winst te halen valt uit de koppeling van bestaande systemen? wordt dit ondersteund, ook wat security- en privacy-vraagstukken betreft? vergeten regels is er binnen de organisatie de wil, in te zien dat bij elk systeem regels horen? EPS-oplossingen wat is de bedrijfscultuur t.a.v. EPS-oplossingen? angst voor verandering wordt hiermee rekening gehouden? of dienen de medewerkers zich maar schikken? menselijke machines als medewerkers met administratieve taken door automatisering overbodig worden, wat is hun perspectief binnen de organisatie? is er een visie op de toekomstige ontwikkeling? wat staat daarover op papier? ruimtelijke ordening verantwoordelijkheid op de juiste plek behoedzaamheid standaarden firmitas is men sich bewust van: stabiliteitsvragen? houdbaarheidsvragen? hoe lang moet iets meegaan? hoe afhankelijk is iets van de omgeving? lokale integriteitsvragen? hoe zeer is iedereen doordrongen van missie en principes? globale integriteitsvragen? venustas wordt er, voor zover van toepassing, bewust gestreefd naar schoonheid m.b.t. statisch uiterlijk? dynamisch gedrag? talen? onderliggende structuren? de menselijke maat: welke aspecten zijn van toepassing? is men zich ervan bewust? lichaam verstand gevoel cultuur

---