Requirements Optimization

Het rapport “Lessen uit ICT-projecten bij de overheid; Deel B” schetst een vrij mild beeld van de IT-debacles die de afgelopen jaren bij de Nederlandse overheid zijn gepasseerd. Dat kon ook bijna niet anders, want er bleken geen betrouwbare gegevens beschikbaar die scherpere conclusies zouden kunnen onderbouwen. De belangrijkste conclusies gaan noodgedwongen over het verzamelen van “betrouwbare gegevens over tijd, omvang, beschikbare mensen en kosten” op basis van “definities over kostensoorten en begin- en eindpunt van projecten”.

De Kwestie

Deel A was nog zo veelbelovend begonnen. Een scherpe analyse: “ICT-projecten van de overheid [worden] vaak te ambitieus en te complex [...] door de combinatie van politieke, organisatorische en technische factoren. Bij deze te complexe projecten is er geen balans tussen ambitie, beschikbare mensen, middelen en tijd”. Politici, ambtenaren en leveranciers blijken vanuit geheel verschillende belangen allemaal aan te sturen op het vergroten van de omvang en (dus) het verhogen van de complexiteit van projecten. Er is geen of weinig ruimte voor concessies aan het ambitieniveau – alles moet vanaf het eerste begin in alle gevallen volledig correct, volledig betrouwbaar en volledig geautomatiseerd verlopen.

Deze requirements frenzy is heel herkenbaar. Ook in het bedrijfsleven komt het niet zelden voor dat het resultaat van een requirementsstudie een eenvoudige optelsom van alle eisen en wensen van alle stakeholders beschrijft – met enig geluk zijn de meest opzichtige tegenstijdigheden er nog uitgehaald. Opdrachtgevers lijken te redeneren dat als je op voorhand al concessies aan het eisenpakket doet, de leverancier zijn best niet gaat doen om een zo goed mogelijke oplossing te realiseren. De leverancier heeft op zijn beurt geen enkele baat bij het versimpelen van de opdracht. Immers, hoe meer functiepunten en hoe meer technologische vernieuwing, hoe hoger het omzetpotentieel.

Het is niet moeilijk om in te zien dat beide redeneringen kortzichtig zijn. Projectrisico's nemen meer dan evenredig toe als het aantal en de complexiteit van requirements toenemen. Hogere projectrisico's vertalen zich onvermijdelijk in langere doorlooptijden, hogere kosten en grotere afbreukrisico's. Planningen van grote, complexe projecten hebben van nature een hoog speculatief gehalte. Dus, als opdrachtgever en leverancier het succes van een project zouden willen bevorderen, dan zouden ze tegen-intuïtief moeten handelen, door actief de complexiteit van het project maximaal terug te managen.

Helaas is matigheid een deugd die in moderne projectorganisaties nauwelijks wordt gewaardeerd. Kleine, simpele oplossingen met een hoge impactfactor, leveren nauwelijks interessante financiële of reputationele prikkels op. Het is jammer dat de rekenkamer daar niet op heeft gewezen. Het stelselmatig belonen van ongewenst gedrag – zowel van bestuurders, ambtenaren als leveranciers – is tenslotte een belangrijke bron van geldverspilling. Een beloningssysteem dat meer rekening zou houden met “value for money” zou dan ook een voordehand liggend advies zijn geweest.

De rol van de archITect

ArchITecten hebben iets met Requirements. Requirements zijn de belangrijkste grondstof voor architectuurproducten. Dat zie je bijvoorbeeld ook terugkomen in TOGAF, waar Requirements Management het centrale proces in de Architecture Development Method (ADM) is. In de woorden van the OpenGroup: “the ADM is continuously driven by the requirements management process”.

Het cruciale woord in deze definitie is “continuously”. Het is zaak dat gedurende het ontwerpproces de ambities continue op de haalbaarheid worden afgestemd. In de loop van het traject ontstaan nieuwe inzichten, waardoor de onzekerheid afneemt en er scherper gekozen kan worden tussen functionaliteit, kwaliteit, kosten en duur van het project.

Het is een verspilling van energie (dus tijd en geld) om aan het begin van zo'n traject een omvangrijke requirementsstudie te doen en op basis daarvan de specialisten aan het werk te zetten. Het werkt veel beter om in een verkennende fase op basis van een beperkte set aan globale requirements een archITect te vragen een aantal alternatieve oplossingsscenario's te schetsen. Zulke schetsen zijn namelijk prima hulpmiddelen om requirements aan te scherpen en om gerichte haalbaarheidsonderzoeken te doen. Zo'n haalbaarheidsonderzoek kan prima in de vorm van een bescheiden project uitgevoerd worden en is een uitstekend hulpmiddel om onzekerheden te elimineren en risico's te reduceren.

Architecten kunnen in de loop van het proces een waardevolle rol spelen bij het helder formuleren en het valideren van requirements. Requirements krijgen op deze manier de kans om geleidelijk, in balans met het ontwerp van de gewenste oplossing, te evolueren. Ze zijn niet langer een bron van conflict, maar een mechanisme voor wederzijdse afstemming. En daar is iedereen bij gebaat.

Requirements Optimization zou een goede term kunnen zijn om een dergelijke werkwijze te beschrijven. Risico's minimaliseren door requirements te optimaliseren. Zo krijg je een maximaal resultaat tegen minimale kosten. En dat is niet alleen voor ministers interessant!

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

Kies je kleur

Kleurenleer

Een aantal jaren geleden bleek uit een beknopt en alles behalve representatief onderzoekje dat er in de praktijk minstens vijf verschillende rolmodellen voor succesvolle archITecten bestaan.

• De constructieve architect: denkt vanuit oplossingen, focust op technologie, gericht op structuur

• De directieve architect: neemt verantwoordelijkheid namens opdrachtgever, zijn wil is wet, gericht op resultaat

• De coachende architect: concentreert zich meer op het groepsproces dan het eindresultaat, hij faciliteert, gericht op leren

• De creatieve architect: stelt uiterlijke schoonheid boven effectiviteit, hij provoceert, gericht op beleving

• De visionaire architect: weigert de huidige praktijk en technologie als beperking te accepteren, hij inspireert, gericht op innovatie

In diezelfde tijd maakte Leon de Caluwe school met zijn kleurentheorie. Hij hanteert een palet van vijf kleuren als evenzovele stijlen voor het aanpakken van veranderingsprocessen.

• Blauwdrukdenken is een planmatige, deterministische manier van veranderingen aanpakken. Projectmatig en methodisch werken zijn typische instrumenten. Principes worden tot stuurinstrument verheven.
• Geeldrukdenken is gebaseerd op machtsdenken – een commandostructuur en directieven zijn kenmerkend – 'Guerilla tactieken' zijn een geaccepteerde praktijk.
• Groendrukdenken stelt de lerende organisatie centraal. Het fenomeen ‘coaching’ is karakteristiek. Reviews en assessments zijn populaire middelen.
• Rooddrukdenken gaat om het verleiden en stimuleren van mensen. Het bewust creëren van voorwaarden en kansen is kern van de benadering. Empowerment is een doel op zich.
• Witdrukdenken vindt zijn oorsprong in de chaostheorie: een nieuwe orde ontstaat spontaan – maar inherent onvoorspelbaar – door het bestaande evenwicht bewust te verstoren. Buiten de bestaande kaders treden wordt tot kunst verheven. Inspiratie staat centraal.

Merk op dat deze theorie – die na uitgebreid wetenschappelijk onderzoek tot stand is gekomen – een frappante overeenkomst vertoont met de classificatie van architecten. Indirect zou je dit kunnen zien als een onderbouwing voor de eerdere vijfdeling.

Om over te peinzen

De vijf verschillende soorten architecten zijn niet voor niets als “rolmodellen” getypeerd. Het zijn archetypen van architecten die in de praktijk effectief zijn gebleken. Ze vertonen een voorbeeldgedrag waarvan andere architecten iets zouden kunnen leren.

Architecten realiseren zich als geen ander dat het gedrag van een systeem goed afgestemd moet zijn op de omgeving van het systeem. Dat geldt in dit geval natuurlijk ook. Niet ieder gedrag is in iedere omgeving even effectief. Het is dan ook raadzaam om de omgevingsfactoren goed in kaart te brengen, en het gedrag daarop af te stemmen.

Architecten hebben van nature een bepaalde stijl van werken. In termen van de Caluwé heeft iedereen een bepaald kleurpatroon in zich. Sommigen zullen zichzelf bijvoorbeeld herkennen als overwegend rood, wit of blauw. Je kunt op internet ook een digitale zelftest doen. Hiermee kun je vaststellen of je zelfbeeld klopt.

Nou is het best mogelijk om je natuurlijk gedrag een beetje bij te kleuren. Zeker als je je heel goed bewust bent van het verschil tussen het voor de omgeving meest effectieve gedrag en je natuurlijke gedrag, dan kun je heel gericht werken aan het vergroten van je effectiviteit. Het schijnt zelfs zo te zijn dat als je voldoende positieve feed-back krijgt op je gedragsverandering, dat dit uiteindelijk wordt geinternaliseerd. Je natuurlijke gedrag kun je op die manier veranderen. Werkt dat echt zo? Je kunt dit in principe met behulp van de digitale zelftest eenvoudig zelf controleren. Vul de test maar eens in met de antwoorden die je tien jaar geleden zou hebben gegeven...!

Niet alle kleurverschillen laten zich even gemakkelijk overbruggen, laat daar ook geen misverstand over bestaan. Soms moet je als professionele architect tot de jammerlijke maar onvermijdelijke conclusie komen dat je in een bepaalde omgeving op dat moment gewoon niet past. Dat is altijd nog beter dan je volkomen onbewust van de mismatch tussen jouw en je omgeving voort te modderen; ofwel gefrustreerd raken omdat het maar niet lukt om je omgeving aan te passen aan jouw gedrag.

Als het je gaat om het vergroten van je effectiviteit in de rol van archITect, dan kan het zoeken van een omgeving die beter past bij je eigen kleur dus net zo goed een slimme strategie zijn als het aanpassen van je gedrag aan de kleur van de omgeving. Het is maar dat je het weet.

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

Kill your managers

In de software architectuur laait van tijd tot tijd het debat op over de wenselijkheid van gecentraliseerde sturing van processen en het gevaar van “control objects” en “managing services”. De kracht van oplossingen als DNS en UDDI ligt juist in het ontbreken van een centrale regelmeester. De laatste tijd lijkt in enterprise architecturen de balans juist weer wat door te slaan naar meer en strakkere controle op de uitvoering van processen. De op allerlei terreinen aangescherpte regelgeving zal daar mede debet aan zijn. Meer controle wordt door architecten haast vanzelfsprekend vertaald in centrale componenten in de architectuur die als een spin in het web alles monitoren en niet zelden ook ongewenst gedrag uitfilteren. Service georiënteerde architecturen zijn in zeker zin een moderne poging om op enterprise niveau meer grip te krijgen op proces- en informatieflow.

De controleparadox

In het verleden zijn er verschillende technieken ingezet om een controlefunctie in de enterprise architectuur te engineeren. Een “integration broker” is feitelijk een centrale hub die het mogelijk maakt om controle uit te oefenen op het verloop van het berichtenverkeer tussen applicaties. Een workflow managementsysteem is een toepassing die een complex werkproces opdeelt in een stroom van taken die aan medewerkers worden toebedeeld. Het is niet zo moeilijk in te zien dat workflow management vereist dat er ook een informatiestroom tussen de medewerkers is. Binnen een systeem is dit geen al te prangend issue, maar zodra medewerkers verschillende systemen gebruiken om hun taken uit te voeren – en in het bijzonder als de medewerkers voor verschillende organisaties werken – is dit niet per definitie triviaal. De ervaringen met technieken als integration brokers en workflow management systemen zijn opmerkelijk gelijksoortig: het werkt heel aardig voor de eenvoudige, voorspelbare, sterk gestandaardiseerde processen; maar zodra het wat minder eenvoudig wordt, dan worden de beperkingen al heel snel tamelijk knellend. Er is een single point of control – met alle nadelen vandien – dat zich doorgaans uiterst rigide gedraagt. De gebruikers zien zich dan al gauw gedwongen om buiten het systeem om wegen te vinden om gewoon hun werk te doen. En met het oprukken van informatietechnologie in steeds complexere processen vraagt dit om een slimmere benadering.

Sommige organisaties realiseren zich dit terdege. Er is nog geen consensus over de vraag hoe dit probleem te tackelen. Industrialisten zijn geneigd om de producten en de processen zo te ontwerpen dan de variatie minimaal is en de verwerking mede daardoor tot in de kleinste details voorspelbaar wordt. De huidige six sigma golf zal niet vreemd zijn aan de populariteit van deze benadering. Anderen stellen juist dat je je met je procesmodel zou moeten richten op die 80% van de gevallen die je gemakkelijk kunt “vangen”. De uitzonderingen zouden dan gewoon moeten “uitvallen” en als handwerk afgehandeld moeten blijven worden.

Het grappige is dat het juist voor die zaken die niet zijn voorzien, of in elk geval niet passen in een standaard verwerking, controle op de uitvoering op z'n plaats is. Ga maar na. Vanuit het oogpunt van risico management moeten er controlemechanismen worden ontwikkeld die waarborgen dat er altijd inzicht is in de huidige staat van de risico's en die het verhinderen dat er onbezonnen risico's worden genomen. “Societé Generale” en “Barclays” dienen als afschrikwekkend voorbeeld van wat er mis kan gaan als deze mechanismen falen. Vanuit het oogpunt van compliancy moeten er corporate governance mechanismen ontwikkeld worden die de betrouwbaarheid van de informatievoorziening van het bedrijf moeten garanderen. De namen “Enron”, “Worldcom” en “US Food Service” zijn onlosmakelijk verbonden met even zovele boekhoudschandalen. In alle gevallen waren de betrokkenen betrekkelijk eenvoudig in staat om de bekende procedures te omzeilen. Je zou je kunnen afvragen of de wedloop tussen de controleurs en de overtreders met gecentraliseerde controlemechanismes wel te winnen valt. Is het in de praktijk niet zo dat met name goedwillenden er last van hebben en kwaadwillenden er vaak al te gemakkelijk omheen blijken te kunnen? En wie controleert eigenlijk de controleurs?

De uitweg uit de paradox

“Kill your Managers” is een bekend architectuurpatroon dat mogelijk kan helpen bij het vinden van een uitweg uit het dilemma. Het is onder de naam “Blackboard pattern” al 1996 beschreven door Frank Buschmann et al in “A System of Patterns”. Het komt er in de kern op neer dat je ervoor moet zorgen dat relevante informatie die in het proces ontstaat altijd op een geeigende plek wordt gepubliceerd. Vervolgens moet je erover nadenken wie er op welk moment toegang behoort te hebben tot die informatie. Tenslotte kun je in een apart proces deze informatie verwerken. Die verwerking kan een mix van geautomatiseerde en handmatige controles zijn. Daarbij is het goed voorstelbaar dat de controles niet altijd voorspelbaar hoeven te zijn. Het onvoorspelbare karakter van controles maakt het voor kwaadwillenden immers een stuk lastiger om ze te omzeilen. Inderdaad: het inbouwen van een zekere mate van onzekerheid in het proces maakt de effectiviteit van de controle sterker en juist niet zwakker. En voor het hoofdproces is het een verademing dat goedwillende medewerkers niet meer te pas en te onpas lastig gevallen worden door managers die zich zonder al te veel kennis van zaken met de uitvoering willen bemoeien.

“Kill your Managers” is een architectuurpatroon dat nog niet zo vaak wordt toegepast bij het ontwerpen van complexe processen. Dat is jammer. Het is een effectieve manier om de concerns “uitvoering” en “controle op de uitvoering” te scheiden. Het is bovendien uitermate schaalbaar en flexibel. Misschien wordt het alleen nog niet altijd goed begrepen wat de kracht van dit patroon is. Zie het als “op het proces zitten” in plaats van “in het proces”. Een goede manager zit niet “ín”, maar “óp” het proces. Dat kan iedereen toch begrijpen?

Het is niet altijd helemaal te voorkomen om een manager in enigerlei vorm in een architectuur op te nemen. Er kunnen hele goede redenen zijn om bepaalde zekerheden af te dwingen. Een access control manager is een typisch voorbeeld. In die gevallen werkt een asynchrone controle nou eenmaal niet. Het principe “kill your managers” moet dus niet al te dogmatisch toegepast worden. Maar onthoud dat als je architectuur echt niet zonder een manager kan, dat dan het tweede deel van de hoofdregel in werking gaat, namelijk: “if you definitely need your manager, be sure to keep him as stupid as possible”. Want niets is zo vervelend als een manager die slimmer probeert te zijn dan zijn medewerkers.

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

Scheiding der machten

De cartoonist Gregorius Nekschot heeft zich – bedoeld of onbedoeld – in het middelpunt van de discussie over vrijheid van meningsuiting gemanoeuvreerd. Hij is met veel bombarie opgepakt door de politie en heeft anderhalve dag in voorarrest gezeten vanwege zijn cartoons. Er wordt alom schande gesproken over deze behandeling, die ook inderdaad wel wat onevenwichtig overkomt. Voorlopig werkt de hele actie van het OM vooral – en waarschijnlijk onbedoeld – als een enorme publiciteitsstunt voor het werk van Nekschot.

De Kwestie

Het is bepaald niet de eerste keer dat traditionele burgerlijke vrijheden – zoals de vrijheid van drukpers – in het licht van internet ter discussie worden gesteld. Het is decennialang onomstreden geweest dat iedereen alles moest kunnen publiceren wat hij wilde. Maar dat was vroeger, toen alleen nog een betrekkelijk overzichtelijke elite van politici, kunstenaars en opiniemakers toegang had tot de media. Vandaag de dag vergt het nauwelijks investeringen om je eigen columns, cartoons, songs of filmpjes op internet te publiceren. En dankzij sociale netwerksites is een virale marketingcampagne ook al geen raketwetenschap. De ultieme democratisering van de media lijkt een feit.

Deze ontwikkelingen hebben er tevens toe geleid dat de publicist zijn eigen uitgever is geworden. En dat is niet alleen iets waar we met z’n allen aan moeten wennen – de politici voorop – het is ook iets dat tot nadenken zou moeten stemmen. Een uitgever is in zeker zin kwetsbaar. Hij kan niet zomaar alles uitgeven. Een uitgever is onderworpen aan de wetten van de markt. Hij moet immers geld verdienen aan zijn uitgaven en moet op z’n minst aan zijn goede naam denken. Het is daarom impliciet een traditionele functie van een uitgever om zaken als fatsoen en de goede smaak te bewaken. Dit heeft in het verleden aanleiding gegeven tot tal van conflicten tussen publicisten en uitgevers – zowel bij omroepen als bij uitgevers. Pas nu blijkt dat dit spanningveld feitelijk een pijler was onder de burgerlijke vrijheden.

Spanningsvelden zijn nuttig. Sinds Montesquieu de Trias Politica heeft verkondigd – de scheiding van wetgevende, uitvoerende en rechtsprekende macht – weten we dat eigenlijk al. Het is ons met de paplepel ingegoten. De spanning tussen de machten levert een heleboel stress op, het is inefficiënt en niet te besturen, maar tot nu toe hebben we domweg nog geen beter politiek/maatschappelijk systeem kunnen bedenken. Kennelijk gaan efficiënt en effectief niet altijd samen. Denk maar eens aan het proces van de evolutie: tijdrovend en verspillend, maar het leidt wel tot ontwikkeling.

De rol van de architect

De triade wetgevende, uitvoerende en rechtsprekende macht zien we in volwassen IT-projectorganisaties – die hebben nagedacht over ontwikkelen onder architectuur – eigenlijk altijd wel op de één of andere manier terug. Het ligt voor de hand om de opdrachtgever als de wetgever te zien, een projectmanager als de uitvoerder en wie anders dan de enterprise architect in de rol van rechter (dit hoeft overigens niet de enige rol te zijn die een enterprise architect bekleedt). Dat zou een gezond spanningsveld moeten opleveren, waarbij we natuurlijk wel moeten bedenken dat een rechter te allen tijde gebonden is aan het uitvoeren van wetten en regels die door de wetgever vastgelegd zijn. Dat zou dan ook moeten betekenen dat zaken als architectuurprincipes, bestemmingsplannen, enterprise architecturen en technologiebeleid pas opgelegd mogen worden als ze door de geëigende bestuursorganen bekrachtigd zijn.

En de project-architect? Een project-architect is primair adviseur, van de project manager, de opdrachtgever en de enterprise architect. Dit is misschien op papier geen al te machtige positie, maar in de praktijk is het – als het goed is – uitermate invloedrijk. Juist omdat een project-architect zelf geen stakeholder is, zijn enige concern is immers het creëren van zo veel mogelijk draagvlak onder de stakeholders, kan hij als geen ander bemiddelen tussen partijen en langs die weg tot evenwichtige oplossingen te komen. Daarbij is het de kunst om vage compromissen te vermijden, maar juist aan te sturen op creatieve win-win situaties. En dat hij in zo'n creatieve oplossing “iets van zichzelf” mee ontwerpt, wordt over het algemeen juist erg op prijs gesteld.

En hoe het nu verder moet met de burgerlijke vrijheden en het internet? Daar is vast het laatste nog niet over gezegd. Maar het lijkt wel vast te staan dat er een herwaardering gaat komen voor de stille kracht op de achtergrond. Want de efficiëntie van vele rollen in één hand leidt slechts zelden tot echt effectieve processen.

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