Gartner voorspelt melt-down Microsoft

Hè hè, het wordt nu eindelijk erkend. Windows is uit z'n krachten gegroeid. Gartner zegt het zelf:

“Windows collapsing under its own weight; Radical change needed” (zie: http://blogs.zdnet.com/BTL/?p=8428). Dat laat tenminste niets aan duidelijkheid te wensen over.

Common Sense?

Windows Vista is berucht om z'n geheugenhonger. Het is niet ongebruikelijk dat er na het vers opstarten van een machine, zonder dat er nog één applicatie is gestart, al in de buurt van 1GB aan geheugen in gebruik is. Er zijn dan ook al tientallen processen gestart, waarvan alleen de overhead van het context switchen vaak al zo'n 10% van de beschikbare processorcapaciteit vergt. Voor niets!

Windows is niet slim ontworpen – dat staat nu wel vast. Dat valt niet zozeer aan de software engineers van Microsoft te wijten, het is eerder een indicatie van het onvermogen van het vakgebied om technieken te ontwikkelen om slim met het potentiële vermogen van computers om te gaan. Vergelijk het eens met een biologisch systeem. Er zullen toch maar weinig mensen zijn die durven te stellen dat een PC met Windows Vista slimmer is dan de slimste mens. Toch?

Het complete menselijk genoom bevat zo'n 3 miljard baseparen (volgens de laatste wetenschappelijke inzichten om precies te zijn 2,86 gigabasen; zie: http://www.strategicgenomics.com/Genome/index.htm). Omdat één base – A, C, T of G – in twee bits uit te drukken is, kunnen er 4 baseparen in één byte. Het menselijk genoom kun je dus in 750 miljoen bytes opslaan. Een snelle rekensom leert dat dit ongeveer 715 Megabytes is. Sta daar eens even bij stil. De genetische code van een mens is kleiner dan de code van Windows Vista. Dan moet er in Windows toch iets een beetje suboptimaal zijn...

Windows Vista bevat onmiskenbaar een grote hoeveelheid legacy code – code die eigenlijk niet meer wordt gebruikt, maar nog wel aanwezig is. Genetici noemen dat junk-DNA. De schattingen lopen een beetje uiteen, maar van zo'n 80-90% van het DNA is in elk geval geen functie bekend. En van het overgebleven is natuurlijk nog maar een klein gedeelte dat voor intelligentie in de hersenen en de waarneming van de zintuigen codeert. Hoe simpel kan intelligentie zijn?

Er zijn op dit moment zo'n 30.000 genen bekend. Genen bestaan uit exons en introns. Exons coderen voor eiwitten, en zijn dus functioneel, introns worden uit het m-RNA verwijderd voordat het eiwit wordt gevormd. De totale hoeveelheid exons staat voor slecht 10MB aan code.

Nog een statistisch gegeven. Het menselijke brein bestaat uit ongeveer 1 miljard neuronen, elk met gemiddeld 10.000 synapsen. Het is niet onredelijk om te veronderstellen dat een synaps minstens één bit aan informatie bevat. Dit maakt samen 1,2 Terabyte; aardig vergelijkbaar met de opslagcapaciteit van een moderne PC. We noemen het allebei 'geheugen'. De verschillen in gebruik zijn echter groot.

Microsoft denkt traditioneel problemen op te kunnen lossen door meer functionaliteit toe te voegen, beter te testen en nog meer mensen bij de ontwikkeling te betrekken om de complexiteit daarvan te kunnen beheersen. De schaalbaarheid van dit model blijkt nu fundamentele beperkingen te hebben.

De Paradox

Als computers ooit zo slim als mensen zouden moeten worden, of misschien wel slimmer, zouden we dan juist niet moeten streven naar een veel simpeler operating systeem en veel minder betrouwbaar geheugen? Zou je met dommere computers geen slimmere systemen kunnen bouwen?

De conventionele manier van ontwerpen schiet vroeger of later tekort om de volgende generatie van complexe systemen te ontwikkelen. Functionele decompositie – het opsplitsen van een complex probleem in een verzameling minder complexe problemen – heeft zo zijn beperkingen. Hoe logisch deze methode intuïtief ook lijkt, het resulteert keer op keer in onhanteerbaar complexe systemen zoals Windows en Office. Bij een bedrijf als Intel hebben ze dat misschien al eerder ingezien. Er is een grens aan hoe complex je een processorkern kunt maken. Niet voor niets zijn de architecten van Intel al jarenlang druk bezig met de ontwikkeling van multi-core processoren.

Er moet voor software ook dringend gezocht worden naar een betere ontwerpmethode traditionele. Er zijn fundamenteel andere architectuurprincipes nodig om de software engineering op een hoger plan te brengen. Het is natuurlijk niet voor het eerst dat er daarbij gezocht wordt naar inspiratie in de natuur. Het vakgebied van kunstmatige intelligentie heeft een respectabele traditie opgebouwd – en zeker ook enkele doorbraken bereikt. Het wordt tijd dat dit doordringt in de mainstream van de software engineering.

Het meest markante verschil tussen computers en intelligente dieren is het belang van opvoeden. Dieren hebben een ingebouwde basisintelligentie, maar zijn ook in staat om veel van hun intelligentie te verwerven in een sociale context. Het is bekend dat dieren die buiten zo'n sociale context opgroeien betrekkelijk hulpeloos door het leven gaan.

De ander kant van diezelfde medaille is dat – zoals iedere ouder weet – opvoeding niet altijd gegarandeerde resultaten heeft. Kinderen gedragen zich niet altijd zoals ouders zouden willen. Er zijn zowel evolutionaire als sociale mechanismes ontwikkeld om ongewenst gedrag te corrigeren. Daarbij gaat het belang van de groep altijd boven het belang van het individu.

Er is ook een groot voordeel in het experimenteren met onaangepast gedrag. Van tijd tot tijd is er een individu die grenzen weet te verleggen, die dingen doet die anderen nooit zouden hebben bedacht of gedurfd, maar die wel succesvol zijn. Grensverleggend gedrag dat de groep op een hoger ontwikkelingsniveau brengt. Dit soort doorbraken kun je niet verwachten als alle individuen alleen maar voorgeprogrammeerd gedrag vertonen.

Zouden de engineers van Microsoft hier iets van kunnen leren? Zouden echte intelligente systemen minder voorgeprogrammeerd moeten zijn, en meer kans moeten hebben om te evolueren? Zouden de architecten van Microsoft wat kunnen leren van de architectuurprincipes achter simulatiespellen zoals 'Evolution: The Game of Intelligent Life'? Zou het fundamenteel beter zijn om ongewenst gedrag te bestrijden, dan om het te voorkomen? Moet Microsoft meer sociologen in dienst gaan nemen?

De sleutel ligt mogelijk in zogenaamde emergente systeemeigenschappen die in grootschalige, gedistribueerde systemen kunnen 'verschijnen'. Die zijn lastig voorspelbaar, maar daarom niet minder krachtig. Zodra we als architecten leren te denken in vrijheidsgraden in plaats van voorspelbaarheid, dan openen zich mogelijkheden waarvan we nu alleen maar kunnen dromen. En het paradoxale is dat er dan 'vanzelf' dynamische, vitale oplossingen zullen ontstaan die intelligenter, functioneler en betrouwbaarder zijn dan de huidige, voorgeprogrammeerde systemen.

Vergezocht? Wie had in 2000 durven te voorspellen dat er een jaar later een simpel programmaatje zou verschijnen dat binnen een paar jaar de wereld zou veranderen? Een user-generated encyclopedie met jaarlijks honderden miljoenen unieke bezoekers (per april 2008 staat de stand op 684 miljoen); meer content dan welke traditionele bron dan ook, en net zo betrouwbaar als (maar actueler dan) de beste encyclopedie? De Wikipedia software is charmant eenvoudig en de totale operationele kosten bedragen niet meer dan $2 miljoen per jaar – $0,3 cent per unieke bezoeker. Als dat geen 'big bang for bucks' is...

Stel je nu een voor dat de Linux-community in staat zou zijn om het OS op te delen in simpele 'pagina's' - of – in biologische termen – 'cellen'. En stel je voor dat er een mechanisme zou zijn om clusters van zulke cellen te bundelen tot 'organen'. Stel dat er communities ontstaan die hun eigen unieke 'organisme' samenstellen op basis van zulke organen. 'Organismen' die 'opgevoed' worden door een netwerk van meer ervaren 'exemplaren'. 'Soorten' die concurreren op een open markt, waar verschillende soorten de verschillende 'ecologische niches' bezetten en alleen de meest succesvolle op termijn kunnen overleven. Het zou volgend jaar al zover kunnen zijn.

Misschien doet u er goed aan om tijdens de komende vakantie eens zo'n evolutie-simulatiespel mee te nemen. Wie weet levert het een Eureka moment op. En anders in elk geval een hoop fun.

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 3^de in een reeks uncommon sense die op dit weblog gepubliceerd zal worden.

Multifocale projecten

Een vergrootglas past bij een projectmanager, net zo goed als een architect graag de verrekijker hanteert. Waar een projectmanager zich concentreert op kortetermijn resultaten, laat de architect zich niet zelden afleiden door visioenen over toekomstige verten. Projecten worden ingericht om in een zo kort mogelijke tijd en tegen zo laag mogelijke kosten een zo goed mogelijk resultaat te halen. Architecten hebben moeite om zich in zo'n project te manifesteren.

Een typische projectmanager stelt aan het begin van het project een business case op, waarin het projectbudget, de planning en de beoogde resultaten worden vastgelegd. Tevens wordt een raming van de met behulp van de projectresultaten beoogde besparingen en/of extra inkomsten gemaakt. In veel gevallen wordt de prioriteit van een project mede bepaald op de geschatte terugverdientijd. Om een hoge prioriteit te krijgen is het dus zaak om de opbrengsten zo hoog mogelijk in te schatten en de kosten zo laag mogelijk in te schatten. Geheel zakelijk verantwoord.

Binnen het project wordt er vooral op gestuurd dat de kosten in de hand worden gehouden. In het gunstigste geval wordt de business case in de loop van het project bijgesteld als de geplande opleverdatum of de geraamde uitgaven overschreden dreigen te worden. Voortschrijdend inzicht ten aanzien van de opbrengsten, de business benefits, leidt daarentegen zelden of nooit tot een heroverweging van de business case. Projecten zijn er om zo efficiënt mogelijk projectresultaten te leveren.

Flauwekul!

De laserscherpe focus op het leveren van projectresultaten staat niet zelden op gespannen voet met de eigenlijke belangen van de opdrachtgever. Neem nou de HSL-zuid. Het projectteam dat verantwoordelijk was voor het aanleggen van het nieuwe spoor is al lang klaar. Toch rijdt er nog steeds geen trein. Hoe dat komt? Er is voor de HSL-zuid een nieuw beveiligingssysteem aangelegd. Dat betekent dat er alleen maar nieuwe treinstellen op kunnen rijden. Die zijn er nog niet. Iedereen wist – of kon weten – dat dit zou gaan gebeuren. Maar de ijzeren logica van projecten zorgde ervoor dat de verschillende project­managers dit probleem bewust buiten hun project hebben gehouden. Het was zo logisch geweest als de nieuwe spoorlijn niet alleen het nieuwe, maar ook het bestaande beveiligingssysteem zou bieden. Dat had het project ongetwijfeld complexer en duurder gemaakt, en het zou misschien wel een paar weken later opgeleverd zijn. Maar dan hadden er ook jaren eerder treinen kunnen rijden en zou het nieuwe spoor nog decennia flexibeler in te zetten zijn geweest. Zo zijn projecten in de praktijk wel vaker penny-wise and pound-foolish.

De oorzaak is een veelvoorkomende weeffout in projectorganisaties, namelijk dat projectmanagers hun decharge krijgen als de projectresultaten zijn opgeleverd. Dit leidt onvermijdelijk tot – vanuit het perspectief van de opdrachtgever – ongewenst gedrag. Het leidt er namelijk automatisch toe dat een projectmanager er alles aan gaat doen om te sturen op kosten en tijd – dat heeft hij namelijk in de hand – en heel gemakkelijk concessies doet aan de opbrengstkant van de balans. De traditionele verantwoordelijkheid van een projectmanager is bedrijfsmatig gezien fundamenteel fout. Hij is waarschijnlijk de enige manager in de organisatie die alleen verantwoordelijk is voor de uitgaven, en niet voor de inkomsten. Met andere woorden: de verantwoordelijkheden van een projectmanager zijn niet in balans.

Een projectmanager zou eigenlijk verantwoordelijk gesteld moeten worden voor het realiseren van zijn business case – niet alleen de uitgaven, maar ook de inkomsten. Dan zou hij een eerlijke afweging kunnen maken tussen investeringen en de rendementen. Een beetje meer investeren om veel meer rendement te halen zou dan net zulk logisch gedrag worden als het verwerpen van een kleine besparing als dat een een grote aanslag op het rendement zou doen.

De agenda voor de architect

Omdat architecten van nature een tegenwicht vormen tegen een al te sterke focus op de korte termijn, is hij ook een logische bondgenoot voor het compenseren van de bijziendheid van de traditionele projectmanager. Omgekeerd kan een projectmanager de architect genezen van zijn verziendheid. Samen hebben ze de multifocale blik die het belang van opdrachtgevers maximaal kan dienen.

Een multifocale blik zal echter ook ondersteund moeten worden door een multifocale methodiek. Prince2, de dominante methodiek voor het managen van projecten, biedt in principe meer dan voldoende aanknopingspunten om multifocaal te werken. Er hoeven slechts wat accenten verschoven te worden.

Prince2 werkt met fasen en stadia - “stages”. Iedere overgang leidt tot een rapportage aan de stuurgroep – bijvoorbeeld een “project brief” of een “end stage report”. Dit zijn ideale momenten om multifocaal te kijken naar de voortgang van het project, en op basis van zo'n multifocale blik het project bij te sturen. Feitelijk zou het neerkomen op een periodieke review van de business case; waarbij niet alleen de kostenkant, maar uitdrukkelijk ook de opbrengstenkant tussentijds wordt geëvalueerd. Zo'n multifocale rapportage zou door de projectmanager en de architect in gezamenlijkheid opgesteld moeten worden en voorzien moeten worden van een advies aan de stuurgroep over de te nemen acties. Dat zou nog eens een creatieve invulling zijn van 'onder architectuur ontwikkelen'.

Als deze praktijk ook na het opleveren van de traditionele projectresultaten consequent wordt doorgezet – in Prince2-termen tijdens een “post-project review”, dan zal ook het doelmatig inrichten van een nieuwe of gewijzigde werkomgeving op de projectagenda komen te staan. Met andere woorden: een project wordt dan ook beloond voor een soepele implementatie in de organisatie – en gestraft voor een moeizame implementatie.

Eigenlijk is het heel simpel. Als de business case voor een project uitgaat van het bereiken van structurele besparingen of nieuwe inkomsten, dan is het project pas geslaagd als deze zijn gerealiseerd – en het is pas mislukt als zeker is dat ze niet (meer) te realiseren zijn. Tot die tijd is het aan de stuurgroep om leiding te geven aan het veranderingsproces, en zijn de projectmanager en de architect waardevolle krachten om dat proces in goede banen te leiden.

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

Paradigm Shift 2.0

Soms, heel soms lees je een boek dat echt baanbrekende inzichten verkondigt. Dat alle ontwikkelingen niet alleen signaleert, maar net een stap verder gaat, en probeert te voorspellen hoe de optelsom van die ontwikkelingen de toekomst zal veranderen. Een boek dat je niet alleen overtuigt, maar je ook vertwijfelt doet afvragen waarom je niet zo slim bent geweest om die toch zo logische consequenties zelf te bedenken.

Als je zo'n boek 10 jaar later herleest, en merkt dat veel van de voorspelde ontwikkelingen aan het gebeuren zijn, dan mag je zo'n boek met recht visionair noemen. Zo'n boek was “Paradigm Shift: The New Promise of Information Technology” [1] van Tapscott en Caston. Het verscheen in 1993, was briljant in zijn analyse en bleek een rijke inspiratiebron voor vele auteurs en sprekers. Ook de bekende titels als “Blown to Bits” [2] en “Power of Now” [3] borduurden nog dankbaar voort op de ideeën van Tapscott.

Nieuwe inzichten

Eén van de centrale ideeën die aan “Paradigm Shift” ten grondslag lag, is het inzicht dat als eenmaal de implementatie van de dynamiek van processen gescheiden zou worden van de functionaliteit van leverende componenten, IT-systemen veel verder zouden kunnen gaan dan de “automatisering” van stappen in bestaande processen. Er zouden nieuwe procesmodellen bedacht gaan worden, die simpelweg zonder de inzet van IT-hulpmiddelen niet mogelijk waren. Workflow Management zou de fundamentele organisatie van alle bedrijven en instellingen op z'n kop gaan zetten.

De rest is geschiedenis. Er zijn miljarden besteed aan business process reengineering en customer relationship management projecten, het internet heeft zich spectaculair ontwikkeld tot de global information highway van vandaag de dag en er is een enorme migratie in de richting van service oriented architecture gaande om de agility te ontwikkelen die nodig is om echt te profiteren van information age zoals Tapscott die al in 1993 heeft voorzien.

Toch lijkt het er steeds meer op dat Tapscott iets wezenlijks over het hoofd heeft gezien. Een aspect dat de ontwikkeling van innovatieve ketenoplossingen nu nog tegenhoudt. Hoe zou het anders kunnen dat er zo weinig voorbeelden zijn van echt succesvolle samenwerkingen in informatie-intensieve ketens? Economisch gezien zou het toch zo moeten zijn dat efficiëntere business modellen uiteindelijk de inefficiënte business modellen verdringen?

Zoals wel vaker bij dit soort ontwikkelingen loopt de verzekeringsbranche voorop bij het implementeren van nieuwe vormen van samenwerking. Bij de afhandeling van een simpele autoschade zijn al gauw een handvol verschillende partijen betrokken – een berger, een schadehersteller, een verzekeraar, een expert, een onderdelenleverancier, een tegenpartij en een verhuurder voor een vervangende auto. Het gaat jaarlijks om grote hoeveelheden gevallen en aanzienlijke bedragen per geval. En ieder specifiek geval is weer net een beetje anders dan andere. Logisch dat het loont om de werkzaamheden in zo'n keten goed op elkaar af te stemmen.

In deze keten speelt controle een belangrijke rol. Het betalen van de rekening is tenslotte verzekerd, dus de verleiding is aanwezig om minder zuinig te doen dan mogelijk zou zijn. Hier is ervoor gekozen om een ingewikkeld stelsel van normbedragen op te stellen, om een zo objectief mogelijke maatstaf voor de herstelkosten te kunnen bieden. Gegeven de variatie van merken, modellen, types en soorten ongevallen is het op zich al een prestatie van formaat dat dit is gelukt. Het feit dat alle schadeherstellers, experts en verzekeraars dit model ook met succes toepassen is miraculeus.

Zou het zo kunnen zijn dat samenwerking in ketens pas goed op gang kan komen als er vanuit een gezamenlijk productmodel gewerkt kan worden? Zou dit dan ook voor andere ketens een les kunnen zijn?

Om over te peinzen

Er zijn ruwweg twee voordehandliggende mogelijkheden om ketensamenwerking een impuls te geven. De ene mogelijkheid is commoditisering van services, zodat concurrentie zijn heilzame werk kan doen, de andere is intelligente service compositie.

Logistieke diensten zijn in hoge mate gecommoditiseerd. Het binnen een bepaalde tijd bezorgen van een item van een bepaald gewicht over een bepaalde afstand is een eenvoudige dienst. Het prestatieniveau kan eenvoudig worden gemeten en de prijs-prestatie-verhouding laat zich eenvoudig meten. Gegeven een gezonde markt met voldoende concurrentie, zal de prijs van de dienst 'vanzelf' naar het laagst mogelijke niveau dalen waarop de bedrijven die de dienst bieden nog gezond kunnen blijven. Er zijn een heleboel voorbeelden te noemen waar dit, soms onder dwang van de overheid, ook daadwerkelijk is gebeurd. Denk bijvoorbeeld aan de telecomsector of de energiesector. In de IT werken ook veel serviceproviders volgens een dergelijk model.

In theorie is het denkbaar dat ook wat ingewikkeldere producten gecommoditiseerd worden. Een verzekeraar zou simpelweg met een hersteller af kunnen spreken dat een gemiddelde schade op basis van statistiek €1564 per geval is, dus dat een landelijke keten van hersteller per 1000 schades €1.564.000 krijgt uitgekeerd – no further questions asked. En als een andere keten het voor minder wil doen, dan is dat normale concurrentie. Misschien zou je het voor de eerlijkheid nog wat kunnen verfijnen: aparte normprijzen voor éénzijdige schades versus meerzijdige schades, complexe auto's versus simpele types, dure of goedkope lak.

In de zorgsector zie je iets dergelijks gebeuren – daar noemt met het diagnose-behandel-combinaties. En daar zie je ook tot wat voor onbedoelde neveneffecten een dergelijk model kan leiden.

Hoe dan ook, een dergelijke commoditisering is eigenlijk alleen maar bruikbaar waar de dienst die wordt geleverd niet onderscheidend is voor de customer facing party. Dat de dienst door de eindconsument ook echt als een commodity wordt ervaren. Dit vereist enige uitleg. Consumenten worden in sommige gevallen verleid door de kwaliteit van een geleverde dienst. Anders gezegd: bedrijven proberen zich van elkaar te onderscheiden door hun diensten anders te organiseren dan concurrerende partijen. Bij verzekeraars kan dit bijvoorbeeld te maken hebben met wat er wel of niet is gedekt, hoe de waarde van een gestolen product wordt bepaald, hoe snel er wordt uitgekeerd en wat er als tijdelijke vervangende voorziening wordt geleverd. Omdat dit allemaal elementen zijn die bij meerdere partijen bekend moeten zijn, werkt commoditisering niet zo goed. Partijen in de keten moeten voor iedere verzekeraar, en voor ieder verzekeringsproduct in feite maatwerk leveren. Het behoeft geen betoog dat het leveren van maatwerk door een keten van samenwerkende partijen een complexe propositie is.

Intelligente service compositie is een nieuw concept, dat architecten kunnen inzetten om complexe ketenoplossingen op een andere manier te ontwerpen. Het betekent dat er tussen de ketenpartners een formele taal wordt afgesproken, waarin producten of diensten gespecificeerd kunnen worden. Dergelijke formele beschrijvingen moeten alle partijen dan intern gebruiken om hun aandeel in het product of de dienst conform de specificatie te leveren. Het ontwikkeling en beschrijven van producten wordt dan een aparte functie in de keten, en de partij die de producten verkoopt kan er op rekenen dat de producten door zijn partners precies zo worden geleverd als tijdens de ontwikkeling is voorzien. En zodra het product wordt gewijzigd, dan past de praktijk bij de ketenpartners zich vanzelf aan. Productontwikkeling met de snelheid van het licht.

Het spreekt voor zich dat de technologie van business rules zich bij uitstek leent voor het vastleggen en executeren van dergelijke productspecificaties. Op het moment dat doordringt dat deze technologie de missing piece in value chain innovation is, dan staan we aan de vooravond van een nieuwe paradidigm shift. Eens zien of de visionairs van “Blown to Bits” dan alsnog gelijk krijgen.

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 5^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

[1] Don Tapscott en Art Caston: “Paradigm Shift, the new promise of Information Technology”, 1993, McGraw-Hill inc, ISBN 0-07-062857-2.

[2] Philip Evans en Thomas S. Wurstner: “Blown to Bits, how the new economics of information transforms strategy”, 2000, The Boston consulting Group, ISBN 0-87584-877-X.

[3] Vivek Ranadivé: “The Power of Now, how winning companies sense & respond to change using real-time technology”, 1999, McGraw-Hill inc, ISBN 0-07-135684-3.

Requirements creep

“We gaan het dit keer heel anders doen”, zo stelde de project manager tijdens de kick-off van het nieuwe project. “We gaan ons dit keer exact aan de requirements houden. We doen niets meer, en niets minder dan is overeengekomen met de klant. En alles wat we tegenkomen aan meer- en minderwerk, dat zetten we gewoon op een aparte lijst. We gaan het systeem eerst conform de requirements opleveren, en daarna gaan we pas aan de slag met het meerwerk – als de klant daar tenminste voor wil betalen.” En hij sloot zijn betoog haast dreigend af met de woorden “Dit keer gaan we onze planning halen. Ik accepteer geen verrassingen meer.”

De kwestie

Hoe begrijpelijk is de opstelling van deze projectmanager. Het werk is voor een vaste prijs aangenomen. Er ligt na maanden onderhandelen eindelijk een lijvig contract; de wederzijdse verplichtingen zijn uitgebreid juridisch getoetst; er is een harde deadline voor de oplevering overeengekomen; er is dus geen enkele ruimte voor voortschrijdend inzicht. Het is goed voorstelbaar, zeker als een organisatie een historie heeft van uit de hand gelopen projecten, dat het bevriezen van requirements wordt gezien als een middel om projecten beter te laten lopen. In een post-project review wordt het fenomeen requirements creep immers niet zelden als de voornaamste schuldige van falende projecten aangewezen.

Toch is het niet bepaald zeker dat een systeem dat geheel conform de vooraf geformuleerde requirements wordt gebouwd, in de praktijk ook als een succesvol systeem wordt ervaren. Met andere woorden, een project dat we als een succes beschouwen, levert niet altijd een succesvol resultaat op.

Wat is hier aan de hand?

Er zijn boeken volgeschreven over de vraag hoe je aan goede requirements kunt komen en wat er in dat proces allemaal mis kan gaan. Eén van de aspecten is ongetwijfeld dat het ontwerpen van een oplossing en het ontlokken van eisen en wensen vaak hand in hand gaan. Ga maar na: zelfs de meest ervaren architect overziet het ontwerp pas als hij in detail heeft nagedacht over alle relevante aspecten in hun onderlinge samenhang. Dat doe je niet op basis van een schets, of een vaag idee, daarvoor moet je je echt in de oplossing verdiepen. Dus als je al een systeem volledig conform requirements zou willen bouwen, dan moet het ontwerp al helemaal af zijn, nog voordat je met de bouw begint. En dat is zo vorige-eeuws…

Een andere netelige kwestie draait om de “SMART-ness” van requirements. Het komt nog steeds voor dat requirements worden opgeleverd die onvoldoende toetsbaar zijn. Onvoldoende objectiveerbare eisen als “het systeem moet gebruikersvriendelijk zijn”, of “de onderhoudbaarheid moet voldoen aan de normen van professionaliteit” zijn geheide kiemen van conflict. Met name op het gebied van beveiliging kom je dergelijke vangnetartikelen nog verrassend vaak tegen.

Sommige opdrachtgevers hebben een onbedwingbare neiging om te overvragen. Bij het opstellen van een programma van eisen is de verleiding groot om het intern eens te worden over de optelsom van wensen en verlangens van alle betrokkenen, zowel in functionele als in technische zin, in de veronderstelling dat dit tijdens de onderhandelingen nog wel wordt aangescherpt. Echter, het spel van het tegen elkaar uitspelen van leveranciers brengt nogal eens met zich mee dat het eisenpakket een eigen leven gaat leiden. De prijs van de resulterende complexiteit weegt dan vaak niet op tegen de toegevoegde waarde van allerlei op de keper beschouwd niet-essentiele requirements.

Het opstellen van onhaalbare requirements is een andere bekende valkuil. Het is natuurlijk verleidelijk om – geheel in de geest van Machiavelli – te richten op een hoger doel in de hoop een lager gelegen doel te bereiken. Het wordt pas vervelend als dat hoger gelegen doel contractueel als verplichting wordt vastgelegd en het bereiken van het lager gelegen doel officieel als een mislukking wordt gezien. Oplossingen worden daardoor nodeloos duur en projecten worden nodeloos riskant. Het is dan ook zaak om als vragende partij zorgvuldig onderscheid te maken tussen wensen en eisen, en als aanbiedende partij, om wensen daadwerkelijk serieus te nemen.

Een laatste afrader is het gebruik van requirements om de oplossing te specificeren. Een combinatie van te veel en te strikte requirements heeft in het ergste geval een lege oplossingsruimte tot gevolg. Het is dan onmogelijk gemaakt om een succesvolle oplossing te bedenken. Maar ook als er nog wel een beperkte oplossingsruimte overblijft, dan blijft het risico bestaan dat in wezen superieure oplossingen onmogelijk gemaakt worden door een onvoldoende doordacht eisenpakket. Dus ook hier geldt: in de beperking toont zich de meester.

De rol van de architect

Een architect werkt nauw samen met zijn klant om zijn eisen en wensen duidelijk te krijgen. Hij doet dit om ‘in de huid van de klant’ te kunnen kruipen, om een ontwerp te kunnen maken dat voldoet aan de vaak dieperliggende behoeftes. Die zijn misschien niet SMART, maar dat maakt ze voor de klant nog niet minder relevant. Daarbij zal een architect op basis van zijn professionaliteit een klant ook stimuleren om na te denken over eisen en wensen die hij in eerste instantie misschien nog niet op zijn netvlies had. Tegelijkertijd zal een goede architect een klant niet lastig vallen met alle requirements die weliswaar relevant zijn voor de realisatie van het systeem, maar vanuit het perspectief van de klant volstrekt onbelangrijk. Het vinden van een goede balans tussen uitdagen en filteren getuigt van goed vakmanschap.

Een architect behoort een klant vriendelijk en vasthoudend uit te dagen om te verwoorden wat de achterliggende reden van een requirement is. Hij zal onderlinge strijdigheden blootleggen en op een constructieve manier proberen prioriteiten te achterhalen. Hij zal ook willen praten over de consequenties van een requirement, bijvoorbeeld in termen van kosten of risico’s. En hij zal actief op zoek gaan naar alle stakeholders die zeggenschap hebben over bepaalde aspecten van het systeem. Is er in de requirements wel voldoende met hun belangen rekening gehouden? Zijn zij voldoende gecommitteerd aan het gewenste resultaat? Hoe kan de oplossing zodanig worden ontworpen, dat het ook vanuit hun perspectief acceptabel is? Zijn alle criteria voor succes wel voldoende gewaarborgd?

Timing speelt ook een belangrijke rol. Aan het begin van een traject gaat het erom de requirements te adresseren die de besluitvorming kunnen beïnvloeden. In de loop van het traject wordt er meer gedetailleerd, en worden andersoortige eisen en wensen relevant. Het vroegtijdig lastigvallen van stakeholders met requirements die nog niet relevant zijn kan een professionele relatie ernstig ondermijnen. Dit is ook één van de achterliggende redenen waarom het vaak zo moeizaam is om alle relevante requirements te specificeren nog voordat er één spa de grond is ingegaan.

Een architect mag nooit een slaaf van de opgestelde requirements worden. Een architect komt pas goed tot zijn recht als hij de requirements meester kan zijn. Dat is immers de kern van “werken onder architectuur”. Als onvoldoende doordachte requirements tot wet worden verheven, als eisen en wensen niet als middel voor wederzijdse afstemming worden gezien, en als die wetten ook nog eens moeten worden toegepast zonder ruimte om na te denken over de bedoeling ervan, dan zullen nog talrijke ontwikkelprojecten tot mislukken gedoemd zijn.

Er zijn in het verleden al tal van dit soort kapotgespecificeerde projecten na veel geruzie uiteindelijk geëindigd in een rechtszaal. Als een rechter zich moet buigen over de bedoeling van de opgestelde requirements en de mate waarin het geleverde product daarin voorziet, dan heeft de betrokken architect in elk geval jammerlijk gefaald.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 6de in een reeks die op dit weblog gepubliceerd zal worden.