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.

De alignment valkuil

IT-snuggere bedrijven presteren veel beter. Dat blijkt keer op keer uit vergelijkend onderzoek. Tijdens het laatste Landelijk Architectuur Congres presenteerde McKinsey de resultaten van een langlopend onderzoek naar middelgrote Europese banken. Nog recenter verscheen het rapport “Avoiding the Alignment Trap in Information Technology” van MIT Sloan. De bevindingen zijn opmerkelijk gelijksoortig.

Er is maar een kleine groep van bedrijven die echt in staat zijn om IT effectief in te zetten ter ondersteuning van hun bedrijfsstrategie. Een procent of 7 maar. Deze IT-snuggere kampioenen groeien structureel zo'n 35% sneller dan het gemiddelde en besteden toch 6% minder aan hun IT. Ze zijn wel weer in staat om van dat 6% lagere budget maar liefst 45% aan vernieuwingen te besteden; tegenover 29% voor een gemiddeld bedrijf. Dat komt dus neer op een bijna 50% hoger budget voor productontwikkeling. En ze zijn ook nog eens in staat om aanzienlijk sneller dan een gemiddeld bedrijf nieuwe producten op de markt te brengen – een typische cyclus duurt 3-6 in plaats van 6-9 maanden.

Ook andere financiële metrieken, zoals koers-winst verhouding en winst per aandeel, zijn bij deze IT-snuggere business kampioenen significant beter. De klassieke voorbeelden van dit soort bedrijven zijn Wall-Mart, Dell, FedEx, Cisco en EasyJet. Maar het worden er hoe langer hoe meer. Bedrijven als Charles Schwab, Nestlé, De Beers, T-Mobile en National City Corp hebben de weg naar IT-snuggerheid gevonden. En dankzij dit soort onderzoeken begrijpen we steeds beter hoe ze dat voor elkaar hebben gekregen.

De kwestie

De logische vraag is natuurlijk: Hoe wordt u ook een IT-snugger?

De overgrote meerderheid van de bedrijven, zo'n drie kwart, heeft zo'n beetje gemiddelde IT-kosten en groeit net iets minder dan de markt. Hele normale bedrijven. Bedrijven waarvoor de stelling “IT doesn't matter” nog steeds opgeld doet. IT is geen integraal onderdeel van hun bedrijfsvoering, maar een kostenpost. De IT-afdeling wordt een beetje gezien als een lastige supplier. Er werken IT-specialisten die niets van de business snappen en het ook nooit zullen snappen. De IT kost steeds meer, en werkt steeds moeizamer. Outsourcing lijkt de beste uitweg. Er moeten toch zeker betere leveranciers te vinden zijn?

In termen van het MIT Sloan rapport scoren deze bedrijven zowel op het criterium “alignment” en op “effectiviteit” beneden de maat. Als je ze vergelijkt met de IT-snuggere bedrijven, dan zou een simpele conclusie kunnen zijn dat ze vanzelf beter gaan presteren als ze maar minder aan IT gaan uitgeven. Immers, de kampioenen doen het op alle fronten veel beter en geven toch zo'n 6% minder aan IT uit. De onderzoeken tonen echter onomstotelijk aan dat die simpele remedie niet zo maar effectief zal zijn. Je wordt niet gezond door minder geld aan IT uit te geven, je wordt eerder gezond door je geld aan minder IT uit te geven.

Er is een groep bedrijven van een procent of 8, die verreweg het minst aan IT uitgeven Zij groeien niettemin een stuk sneller dan het marktgemiddelde. Deze superieure IT-bedrijven groeien namelijk wel een procent of 10 sneller dan het gemiddelde bedrijf. Hun IT is weliswaar “well-oiled”, maar niet optimaal afgestemd op de groeikansen die business heeft. Het lage kostenniveau hebben ze bereikt door vooral veel te investeren in simpelheid; door vooral veel niet te doen – ook al vraagt de business er nog zo klemmend om. Hun focus ligt op een superieure prijs-kwaliteitsverhouding, en dan is het maximaal terugdringen van heterogeniteit en diversiteit een logische keuze. Zelfs als dat ten koste gaat van groeikansen.

Figuur 1: Een segmentering van bedrijven geïnspireerd op het MIT Sloan onderzoek.

De laatste groep, toch nog zo'n 10%, is helemaal slecht af. Zij betalen een hoge prijs voor een goede alignment. Hun IT kosten liggen 13% boven het gemiddelde, en hun groei ligt 14% onder het gemiddelde. Een sterke alignment in combinatie met een lage effectiviteit van de IT. Deze IT-sukkels bekleden een weinig benijdenswaardige positie, die MIT Sloan treffend de “alignment trap” heeft gedoopt. Alignment als valkuil.

Gevoelsmatig is deze “alignment trap” makkelijk te verklaren. Als het begrip “alignment” wordt uitgelegd als “luisteren naar 'de business' en precies doen wat zij vragen”, dan is het voorspelbare gevolg een complexe lappendeken van verschillende oplossingen voor steeds nieuwe problemen. In de loop van de tijd is 'de business' immers met een veelheid aan problemen geconfronteerd waarbij steeds verschillende mensen met wisselende verantwoordelijkheden steeds andere oplossingen hebben gevraagd. En die zijn steeds braaf naar beste kunnen geleverd. Althans, binnen de gegeven context.

Het nobele streven naar “alignment” is op deze manier vooral een symptoom van een gebrekkige IT-strategie en een onmachtige IT organisatie. Ad-hoc IT is op termijn nou eenmaal kostbaar. Dat weten we al lang. Vooral de kosten voor integratie en onderhoud stijgen dan de pan uit. En dat is uiteindelijk niet in het belang van de business. Een inter-application spaghetti kan zelfs dramatische vormen aannemen. Alleen drastische en pijnlijke maatregelen bieden dan nog een uitweg.

Figuur 2: het strategisch alignment model van Henderson en Venkatraman.

In 1993 hebben Henderson en Venkatraman een nog steeds zeer lezenswaardige analyse gepubliceerd in het IBM systems journal over “Strategic Alignment”. Zij delen de werkelijkheid in twee dimensies in: Strategie versus executie en Business versus IT. Hun betoog is charmant eenvoudig: voor alignment moet je zowel aan de business als aan de IT kant van het spectrum werken aan een “strategische fit” tussen strategie en executie. Tussen business en IT moet je werken aan “strategische en functionele integratie”. Zij spreken dus pas over “strategische alignment” als er een goede afstemming is op de werkvloer, en in de boardroom en tussen boardroom en werkvloer. Met andere woorden: er is pas alignment als de goede dingen gebeuren, en als die dingen ook goed gebeuren. Samenwerking en effectiviteit gaan dan hand in hand. De traditionele “Business en IT” polen versmelten dan in een gemeenschappelijke, integrale enterprise.

Met de kennis die we nu zo'n 15 jaar later hebben, weten we dat er in elk geval voorbeelden zijn van bedrijven die dit stadium daadwerkelijk hebben bereikt. En met enige studie kunnen we de best practices van deze bedrijven leren. Het kan wel degelijk; en het kan ook in uw bedrijf.

De uitweg

De onderzoeken laten een duidelijk en eenduidig beeld zien. Of je nu gevangen zit in de alignment val, of bij de grote massa van IT-suppliers hoort, de weg naar het kampioenschap verloopt via strategische investeringen in enterprise architectuur. In de woorden van het MIT Sloan rapport:

“Contrary to conventional wisdom, the path to IT-powered growth lies first in building high effectiveness and only then ensuring that IT projects are highly aligned to the business.”

Als je gevangen zit in de “Alignment Trap”, laat dan rustig de kloof tussen business en IT een poosje groeien, want dat creëert de nodige rust om de dolgedraaide IT onder controle te kunnen brengen. Dat vereist wel een gezonde dosis lef. Het kost serieus tijd en geld om de IT op orde te brengen, en in die tijd is er geen of weinig ruimte om leuke nieuwe projecten voor de business te doen. Dat is een zure appel. Het vereist leiderschap en uithoudingsvermogen om hier doorheen te bijten. Maar de feiten tonen helder aan dat dit de enige begaanbare weg naar IT-snuggerheid is.

Het laat zich raden dat hoe meer bedrijven de weg naar IT-snuggerheid weten te vinden, hoe meer de achterblijvers in gevaar komen. Zij vallen ten prooi aan de succesvolle bedrijven, of zijn onvoldoende concurrerend om de volgende tegenslag te kunnen doorstaan. Een bedrijf dat in zijn eigen toekomst gelooft, ontkomt er dus niet aan om aan zijn IT-snuggerheid te gaan werken. Hoe sneller de boel op orde is, hoe groter de overlevingskans zal zijn. Dat is iets om even bij stil te staan.

Er is nog een behartenswaardige les uit de onderzoeken getrokken. Als de IT-afdeling tot nu toe niet naar behoren heeft gepresteerd, dan is het in z'n algemeenheid toch beter om met de bestaande mensen serieus te gaan werken aan een vergaande versimpeling van het bestaande landschap, dan om de falende sleutelfiguren in de IT maar te vervangen door nieuwe. De bestaande mensen blijken, met voldoende mandaat en ondersteuning van externe specialisten, namelijk veel sneller in staat om overtuigende resultaten te bereiken, dan nieuwe mensen die de omgeving eerst nog door schade en schande moeten leren kennen.

Zodra de enterprise architectuur op orde is, als je IT superieur is, dan wordt het tijd om de aandacht op IT Governance te richten. Vanuit een solide basis kan er pas een zinvolle dialoog tussen business en IT ontstaan over vernieuwing en groei. Je hoeft toch niet al te snugger te zijn om dat te kunnen begrijpen?

In deze kwestie wordt een actueel architectuurthema op een messcherpe manier uiteengerafeld. Het is de 5^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.

Parodya

De gemeente Dyadam heeft zijn huisvestingsbeleid onder de loep genomen. Het was een beetje een zooitje geworden, met ambtenaren die met de beste intenties volstrekt langs elkaar heen werkten. Er was duidelijk onvoldoende samenhang in de gebouwde omgeving ontstaan. Daarom heeft de gemeente adviesbureau Goiste de opdracht verstrekt om een nieuw, eigentijds procesmodel te ontwikkelen. In het model moet duidelijk gemaakt worden dat Dyadam een moderne gemeente is, die architectuur in al zijn kernprocessen heeft ingebed.

Het verloop

Tijdens de kick-off meeting bleek iedereen reuze enthousiast over dit innovatieve idee. De burgemeester had de meest betrokken ambtenaren persoonlijk opgeroepen om hun agenda vrij te maken voor deze belangrijke meeting. Zelfs de medewerkers die normaal op vrijdag hun deeltijddag hadden, waren er gewoon bij. Het was nauwelijks nog nodig om het belang van het project uit te leggen. Er werd door iedereen actief gebrainstormd, en dat leverde adviesbureau Goiste aan het einde van de bijeenkomst het volgende lijstje met gemeenschappelijke uitgangspunten voor het nieuwe ruimtelijke ordeningsproces op:

• Architectuur is er voor de burgers
• Architectuur mag de snelheid niet in de weg staan
• De communicatie met de burgers staat centraal
• De architectuur ondersteunt het gemeentebeleid
• De gemeente wil maximaal profiteren van de investeringen van de burgers
• De gemeente doet niets te veel en niets te vroeg (daar was nog aardig wat discussie over geweest)
• We spreken een gezamenlijke taal
• Er is een goede aansluiting en ontsluiting
• Er zijn verschillende plangebieden
• We werken optimaal samen

Er was nog wel een behoorlijk verschil van mening omtrent een principe in de sfeer van “De opgestelde regels worden strikt gehandhaafd”. Tegenstanders vonden dat het nieuwe model alle schijn van bureaucratie moest vermijden, terwijl de voorstanders een duidelijk signaal wilden geven dat het afgelopen zou zijn met het gedoogbeleid. Gelukkig wist men elkaar net voor het einde van de sessie te vinden in het compromisvoorstel van de directeur van Goiste, dat inhield dat handhaving in de verdere uitwerking van de opgestelde principes best als een vorm van communicatie met de burger gezien kon worden.

Nu de aftrap voor het project was gegeven, en alle lichten voor het project op groen leken te staan, zou het een koud kunstje worden om de gemeentelijke ruimtelijke ordenings­processen opnieuw vorm te geven. Om aan te geven dat de gemeente de nieuwste ontwikkelingen op het gebied van ruimtelijke ordening en bouwkundige technologie actief volgt, werd besloten dat deze ontwikkelingen de input voor de processen zouden moeten zijn. Gebouwen waren de logische output, maar het kon natuurlijk ook om verbouwingen gaan. Besloten werd om het voorlopig maar op “bouwsels” te houden. Het te ontwerpen proces zou dus verlopen tussen die twee polen.

Alle ambtenaren die in dit proces van nieuwe ontwikkeling tot bouwsel een taak hadden, werden zorgvuldig 1-op-1 geïnterviewd. Het bleken er uiteindelijk niet minder dan 37 te zijn. Het adviesbureau gebruikte een techniek van individuele diepte-interviews om zeker te weten dat er geen zaken over het hoofd gezien zouden worden. De gesprekken duurden gemiddeld twee uur, waarna er een verslag werd opgesteld, dat in een vervolggesprek van een uur werd doorgesproken en waar nodig aangevuld en bijgesteld. Na drie maanden hard werken had men een schat aan informatie verzameld. Men had alleen nog niet met de manager van de vuilophaaldienst kunnen spreken, die was langdurig ziek. Dit werd dan ook noodgedwongen buiten de scope geplaatst.

Na afloop van deze drie maanden moest het eindrapport aan de burgemeester opgesteld worden. Een eerste consolidatie van alle taken bracht aan het licht dat er drie hoofdprocessen waren, die door drie verschillende disciplines ondersteund werden – de gemeenschaps­voorzieningen zoals scholen, buurtcentra, en de bioscoop; het gemeentelijke wegennet en de nutsvoorzieningen zoals water, elektra en riolering. Besloten werd om deze disciplines in verschillende secties in te kaderen, met als indelingscriterium of hun aandachtsgebied zich boven, op of onder de grond bevond. Verder werd er duidelijk onderscheid gemaakt tussen de besluitvormende taak – het beoordelen van de plannen – en de uitvoerende taak – het toezicht houden op de bouw. De taken van het kadaster waren aanvankelijk een probleem, omdat die in beide processen een rol spelen. Besloten werd om deze in een aparte groep van ondersteunende diensten te plaatsen. Wellicht zou de vuilophaal daar in een volgende versie ook nog wel bijgeplaatst kunnen worden.

Figuur 1: Concept model

Uiteraard werd het conceptrapport eerst met de gemeentesecretaris besproken. Die was vol lof over het vele werk dat was verzet, maar hij had ook een flinke dosis opbouwende feed-back. Er moesten nog “een paar puntjes aangepast” worden, om het voor de burgemeester wat “herkenbaarder” te maken. Het moest wat meer aansluiten bij de ambitie van de burgemeester om een “eigentijdse zakelijkheid” uit te stralen. Het mocht nog wel wat “minder ambtelijk”, en wat “hipper”. En een beetje meer “klasse” kon ook geen kwaad, het was tenslotte geen plan voor de gemeente Pauperveen. Een paar fragmenten uit het gesprek:

• 
  
• “De term ‘Bouwsels’, dat kan echt niet. Ik stel voor om daar ‘Bouwkundige oplossingen’ van te maken.”
• “Die drie basisdisciplines, die zijn veel te weinig onderscheidend voor Dyadam en missen een verbindende factor. Kunnen we hier niets met het begrip ‘architectuur’? Dat straalt tenminste kwaliteit en allure uit.”
• “Ik mis de rol het gemeentebestuur in het plaatje. Dat gaat de burgemeester zo nooit goedkeuren. De Raad zou haar vierkant uitlachen.”
• “En nog één ding. Het gebeurt nog wel eens dat we even snel wat moeten neerzetten voor studenten, of asielzoekers, ofzo. Dan bellen we zo’n bedrijf dat binnen een week een stapel containers neerzet. Dat proces staat los van bureaucratisch toezicht, daarom kan het zo snel. Dat moet in het model herkenbaar terugkomen.”

Al met al waren het nog behoorlijk wat verbeterpunten. Zo veel, dat de doorgewinterde mannen van Goiste het even niet meer zagen zitten. Er was tenslotte al zoveel werk gedaan, en dan nog is er zo ongeveer niets goed genoeg. Dat is demotiverend! En over een week moesten ze al met het finale concept bij de burgemeester bespreken. Ten einde raad werd er besloten om diezelfde avond een nog een extra brainstormsessie in te lassen met de voltallige directie van Goiste. De opdracht voor Dyadam mocht immers onder geen beding mislukken!

Die noodgreep bleek geen slechte zet. Nadat men collectief stoom had afgeblazen en elkaar weer wat moed had ingesproken leek de kritiek ineens helemaal niet zo fundamenteel meer te zijn. Al na twee uur was er een enigszins aangepast model, dat ogenschijnlijk aan alle bezwaren tegemoet kwam. Vooral die “Dynamische Architectuur” was een vondst. Grappig toch, hoe één zo’n woord ineens een heel ander beeld schept.

Figuur 2: Finaal concept model

Het moest allemaal natuurlijk nog wel in de beleidsnota verwerkt worden, maar dat zou met wat overwerk nog wel net op tijd gaan lukken. Verder spraken ze af dat de algemeen directeur vast informeel met de burgemeester ging praten om haar een beetje voor te bereiden op de uitkomst en om nogmaals te benadrukken hoeveel belang Goiste hechtte aan de Dyadam account. De burgemeester kon tenslotte ook best een succes gebruiken, dus er was een duidelijk gezamenlijk belang om op te kapitaliseren.

De burgemeester had op het gemeentehuis de reputatie om een enorme bitch te zijn, maar de consultants van Goiste vonden haar in de praktijk eigenlijk best aardig. Ze was erg geïnteresseerd in het verloop van het project, in de medewerking van iedereen en in aanbevelingen die “om tactische redenen” niet op papier waren gekomen. Er was drie kwartier uitgetrokken voor het gesprek, maar het duurde uiteindelijk bijna vijf kwartier – een duidelijk teken van haar commitment aan een positief resultaat. Toen ze na afloop hun aantekeningen naast elkaar legden, bleek dat er eigenlijk nog maar twee cosmetische puntjes in het model aangepast moesten worden. Ze vond de term “Gemeentebestuur” wat te beperkt. Ze refereerde aan allerlei maatschappelijke groeperingen die de besluitvorming mede bepaalden – dat vonden sommige partijen in de Raad namelijk erg belangrijk; aan de rol van andere overheden en aan de nutsvoorzieningen met hun eigen besluitvorming. “Maak daar maar gewoon ‘besturing’ van, dan kan ik er in de Raad wel een mooi verhaal van maken.”

En ze vond die “Bouwkundige oplossingen” van de gemeentesecretaris wel leuk bedacht, maar een beetje “oude politiek”. In de 21^ste eeuw moest het niet gaan om de gebouwen, maar om de beleving van de burgers. “De gemeente Dyadam biedt geen woonruimte, maar woongenot” was haar politieke statement.

Figuur 3: Definitief model

De burgemeester was briljant tijdens de gemeenteraadsvergadering. “Stel”, zo begon ze, “dat er een grote brand is die een aantal families dakloos heeft gemaakt. Tot vandaag zaten we dan vast aan tijdrovende procedures. Vanaf morgen is dat voorbij. Dan kunnen we die families binnen een week aan nieuwe woonruimte helpen. Dat is wat Dyadam wil zijn. Klantgericht, dynamisch en bij de tijd. En dit nieuwe model gaat dat waarmaken.”

De gemeenteraad was unaniem juichend over het “visionaire” model van de burgemeester. De burgers van Dyadam zouden weer “trots” kunnen zijn op hun gemeente. Daar konden alle andere gemeenten “een voorbeeld aan nemen”. Het voorstel werd bij acclamatie aangenomen.

De ambitieuze burgemeester werd na dit eclatante succes al snel benoemd in een grote stad, om ook daar het “Dyadamse model” in te gaan voeren. Goiste mocht zelfs een lezing houden op het Landelijk Ruimtelijke Ordening Congres. Na deze lezing stroomden de opdrachten uit gemeenteland binnen. Men had school gemaakt.

Om over te peinzen

Wat is nu de moraal van dit verhaal?

Een plaatje dat is gemaakt om besluitvorming te ondersteunen is nog niet per definitie geschikt om een organisatie te helpen professionaliseren. Iedere architect weet dat ieder viewpoint zo zijn eigen eisen stelt aan de modellen die worden gebruikt en de wijze waarop ze worden gepresenteerd. Het hoeft niet erg te zijn als er een politiek model wordt gebruikt dat vol slordigheden en inconsistenties zit. Het wordt pas erg als dit politieke model ook zonder een rationalisatieslag bij de implementatie gebruikt wordt. Dat worden alle onvolkomenheden pijnlijk zichtbaar, en in het ergste geval loopt een organisatie ondanks goede intenties en aanzienlijke inspanningen toch volkomen vast door een gebrek aan concrete resultaten.

Het politieke model voor “Werken onder Architectuur” bestaat inmiddels zo’n zeven jaar. De vertaling naar een werkbaar operationeel model is in elk geval nog niet in de openbaarheid gebracht. Dat is een enorm gemis, want het zou het vakgebied een enorme impuls kunnen geven als er een algemeen geaccepteerd en bruikbaar werkmodel voor “Werken onder Architectuur” zou bestaan. Een model dat ook duidelijk afgestemd zou zijn op andere bekende werkmodellen, zoals Prince2, RUP, ITIL en COBIT. Een model dat praktische aanknopingspunten biedt om architectuur in te bedden in de strategische plancyclus. Een model dat de toegevoegde waarde van “Werken onder Architectuur” concreet maakt. Een model dat het mogelijk maakt om best practices uit te gaan wisselen.

Wie doet er mee om zo’n model te ontwikkelen?

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

Gracieus mislukken is oké

Er mislukken veel te weinig IT-projecten. Inderdaad, we zijn in de IT sector – zeker sinds in 1994 het eerste CHAOS rapport van de Standish Group uitkwam – pijnlijk doordrongen geraakt van het besef dat het meerendeel van de projecten mislukt. Sindsdien is het onderzoek regelmatig herhaald, en is het uitkomen van een nieuwe versie van het rapport telkens wel voer voor zure krantenkoppen. “Het gaat beter: nog maar 73% van de IT projecten faalt” - of stellingen van soortgelijke strekking. Vanwaar dan toch de stelling dat er nog te weinig projecten mislukken?

De Kwestie

Eerst maar eens de vraag wie of wat nou eigenlijk bepaalt of een project succesvol is of niet. Een triviale vraag? De Standish Group is er in elk geval heel stellig over. Een project moet binnen de vooraf afgesproken tijdlijnen en binnen het vooraf afgesproken budget de vooraf afgesproken functionaliteit volledig opleveren. Het probleem is dat deze heldere definitie in de praktijk nauwelijks iets te maken heeft met het begrip succes zoals we dat ervaren. Zo zijn er tal van voorbeelden van bedrijven, met Microsoft als lichtend voorbeeld, die in deze termen nog nooit een succesvol project hebben opgeleverd. Hun projecten lopen altijd uit, kosten veel meer dan geraamd, en tot op het allerlaatste moment worden features geschrapt die niet op tijd het gewenste kwaliteitsniveau halen. En dan nog regent het na een marktintroductie van een nieuw product klachten over allerlei gebreken en tekortkomingen. Toch heeft deze praktijk Microsoft bepaald geen windeieren gelegd.

Stel eens dat een project 10% over zijn geplande budget is gegaan, maar ook 30% meer rendement opbrengt, moet je het dan beschouwen als een mislukking? En een project dat veel vroeger dan gepland en tegen veel minder kosten dan geraamd de gevraagde functionaliteit oplevert, dat is toch een daverend succes. Of niet soms?

In het minst ongunstige geval leidt najagen van de vorm van succes die de Standish Group propageert alleen maar tot overdreven defensieve planningen, waarbij alle projecten die ook maar enig risico met zich meebrengen meestal niet eens worden gestart. Een al te defensieve planning is namelijk dermate pessimistisch dat er a priori al een negatieve business case ontstaat. En wordt het project wel gestart, dan is het gevaar levensgroot dat al het toegekende geld ook daadwerkelijk wordt besteed. Het project gaat leven naar zijn rijkdom. Het al te ver doorgevoerde principe van Underpromise en Overdeliver is op die manier een wel erg povere kwaliteitsstrategie.

Een nog minder aantrekkelijk potentieel gevolg is dat projecten van enige omvang worden opgedeeld in een verzameling deelprojecten die elk voor zich zo klein zijn dat ze bijna niet kunnen mislukken. Als iedere simpele activiteit al als een los project wordt georganiseerd, dan is het makkelijk te plannen en de kans op succes wel erg groot. Feitelijk wordt de complexiteit die inherent is aan de gestelde doelen buiten projecten georganiseerd. Er ontstaan vanzelf allerlei formele en informele overlegstructuren en coördinatiemechanismen die formeel niet te boek staan als projectactiviteiten, maar wel degelijk tijd en geld kosten. En de deelprojecten die niet worden gestart omdat de tijd en of het budget voor het product al zijn verbruikt, die tellen in de boekhoudkundige werkelijkheid niet langer als ongerealiseerde functionaliteit. Een dergelijke praktijk doet het waarschijnlijk goed bij de cententellers van de Standish Group, maar zo'n virtuele werkelijkheid zal de reële perceptie van de betrokken stakeholders hoogstwaarschijnlijk op geen enkele manier positief beïnvloeden.

Het komt ook voor dat als gevolg van de drang naar boekhoudkundig succes juist de slimste projectmanagers de meest uitdagende projecten weigeren omdat ze vrezen anders genadeloos afgerekend te worden op het uitblijven van succes. Als het durven te nemen van risico's wordt bestraft in plaats van beloond, dan ligt lafheid op de loer. En het inzetten van minder getalenteerde projectmanagers op de meer uitdagende projecten is zeker geen garantie voor succes.

Waar ging het eigenlijk ook al weer om bij een project als organisatievorm? Zoals zo vaak lopen de definities uiteen. Toch zijn er voldoende overeenkomsten. Een project is tijdelijk, heeft een vooraf gedefinieerd, uniek resultaat als doel en wordt begrensd door afgesproken condities. Een project heeft typisch een multidisciplinaire samenstelling, vaak wordt er over de grenzen van afdelingen samengewerkt, en – heel wezenlijk – een project kent beheersbare risico's. Dit laatste betekent impliciet dat een project geen aangewezen organisatievorm is voor voorspelbare, routinematige, steeds terugkerende activiteiten, ook al gaat het om complexe activiteiten. Het betekent tegelijkertijd ook dat een projectmatige aanpak niet geschikt is voor volstrekt onvoorspelbare, researchmatige of exploratieve activiteiten. Een ontdekkingstocht door ongekarteerd terrein laat zich nou eenmaal lastig plannen. Het vinden van de dader in een moordzaak is ook zoiets. Het maakt niet uit hoe zorgvuldig je het plant, en welke geavanceerde methoden en technieken je hanteert, er is geen enkele garantie te geven dat je binnen tijd en budget met zekerheid de ware dader kunt identificeren.

Projecten hebben dus van nature een gematigd risicoprofiel. Risico's vertalen zich in onzekerheden. Het is dus normaal dat een project niet precies verloopt zoals je van te voren had gepland. Het is ook heel normaal om je dan af te vragen of het wel zinvol is om zo'n project door te zetten. Een organisatie met een laag percentage mislukte projecten moet zich dan ook serieus afvragen of ze wel goed bezig zijn.

Er bestaat ook een heel andere definitie van een succesvol project. Die is misschien wat subjectief, maar sluit wel veel beter aan bij de beleving van de direct betrokkenen. Hij luidt simpelweg dat een project succesvol is als de verwachtingen van de belangrijkste stakeholders nét worden overtroffen. Iedereen voelt wel aan dat verwachtingen lastig te objectiveren zijn. Ze hebben te maken met ervaringen uit het verleden, ze kunnen door allerlei omstandigheden worden beïnvloed, en ze kunnen in de loop van een project bijgesteld worden. Dergelijke argumenten worden door typische pennenlikkers aangevoerd om te onbruikbaarheid van zo'n definitie aan te tonen. In hun simpele, boekhoudkundige werkelijkheid hebben ze ongetwijfeld het gelijk aan hun zijde. Echter, de weerbarstige realiteit van alle behalve de meest simpele projecten toont keer op keer onomstotelijk aan dat indicatoren als “individuele prestaties” en “collectief succes” eenvoudigweg niet in simpele metrieken gevangen kunnen worden. En succesvolle projectmanagers weten dat een actief management van de verwachtingen van stakeholders onmiskenbaar leidt tot een hogere tevredenheid.

Wat te doen?

Er bestaat een krampachtige neiging om eenmaal gestartte projecten koste wat kost tot een goed einde te brengen. Hoe loffelijk doorzettingsvermogen ook is, dit is doorgaans niet in het belang van de organisatie. Alle tijd en resources die in een dergelijk project worden geïnvesteerd blokkeren immers andere, potentieel waardevollere initiatieven.

Gezonde organisaties beschikken over een goed gevulde portefeuille met projectvoorstellen. Het is uitermate wenselijk dat er veel meer goede ideeën zijn, dan er middelen zijn om ze uit te voeren. Dat betekent namelijk dat er scherp gelet moet worden op de kwaliteit van de voorstellen. Een slimme organisatie investeert immers alleen in de allerbeste ideeën.

Dat maakt de vraag opportuun hoe je het best op voorhand kunt vaststellen welk idee het meest kansrijk is. Hoe kun je uit al die voorstellen de projecten selecteren die het hoogste rendement op zullen brengen? Het antwoord op dergelijke vragen is simpel. Dit is voor iedereen die niet paranormaal begaafd is een onmogelijke opgave. Nauwkeuriger geformuleerd: een grondige analyse van de projectvoorstellen zou zodanig veel tijd en geld kosten, en zoveel risico met zich meebrengen, dat die analyse op zichzelf al een projectmatige aanpak zou vereisen. Waarmee de vraag opportuun wordt welke projectanalyse­projecten voorrang zouden moeten krijgen. Want – het laat zich raden – gezien de beperkte hoeveelheid tijd, mensen en middelen kunnen helaas niet alle voorgestelde projectanalyseprojecten uitgevoerd worden. Maar wie bepaalt dan op basis waarvan welke projecten geanalyseerd mogen worden? Er doemt al snel een netelige analysis paralysis op.

Het is een veel betere tactiek om veel meer projecten te starten dan de beschikbare resources toelaten en een evolutionaire aanpak te kiezen waarbij de sterksten automatisch overleven. Huh? Jazeker! Creëer een gezonde competitie tussen een stel opstartende projecten en beslis na verloop van tijd op basis van de feitelijke vorderingen welke projecten ook echt doorgezet worden. Stel dat er een capaciteit is om van 100 ingediende voorstellen er 10 te realiseren. Het zou wel erg toevallig zijn als van al die 100 voorstellen onmiddellijk duidelijk is welke 10 voorstellen het verdienen om gerealiseerd te worden. Maar het is niet zo moeilijk om er 30 aan te wijzen waar de 10 beste voorstellen met aan zekerheid grenzende waarschijnlijkheid tussen zitten. Geeft die 30 de kans om hun plan een slagje dieper uit te werken, en beslis dan welke 15 er nog een iteratie verder mogen. Tegen die tijd is vast wel duidelijk welke 15 in elk geval niet tot de 10 beste voorstellen behoren. Deze projecten mogen gracieus mislukken. Ze hebben een eerlijke kans gehad, de uitgewerkte plannen zijn ten opzichte van de andere plannen (nog) niet goed genoeg. Iedereen kan inzien dat deze projecten onder de gegeven omstandigheden niet rijp genoeg zijn om echt succesvol te worden. Dat is geen schande, dat is 'all in the game'.

Na nog een iteratie wordt het steeds scherper duidelijk welke 10 projecten echt de besten zijn. De business cases zijn uitgehard, alle risico's zijn geïnventariseerd, de belangrijkste risico's zijn al onschadelijk gemaakt en voor de overblijvende risico's zijn de beheersingsmaatregelen benoemd. Het pad voor succes is geëffend.

Is een dergelijke ogenschijnlijk verkwistende procedure zonde van de verspilling? Denk opnieuw! Het creëren van een gezonde competitie is een elementair economisch principe om de gezondste bedrijven uit een groep uit te selecteren. Het blijkt in de praktijk het meest efficiënte mechanisme dat we kennen. Er is, paradoxaal genoeg, geen betere manier bekend om verspilling juist tegen te gaan. Waarom zou ditzelfde principe bij projecten niet net zo goed kunnen werken? Misschien nog wel het mooiste aspect in deze aanpak is dat er een expliciet belang voor de opdrachtgever c.q initiatiefnemer is om tijdens de opstartfase het maximale te doen om de ideale omstandigheden voor een succesvol project te creëren. En dat gebeurt dus ook. En het project dat na zo'n strenge selectie wordt uitverkoren om te worden gerealiseerd, verkeert vanaf het begin in een winning mood. Dat motiveert enorm! Deze combinatie van de beste plannen en de fitste projecten staat garant voor een maximale return on investment. Gegarandeerd.

In deze kwestie wordt een actueel architectuurthema op een messcherpe manier uiteengerafeld. Het is de 4^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.

Wendbaar ondanks Architectuur

Een gewichtige paradox

Voor organisaties die zich serieus bezighouden met moderne, lichtgewicht ontwikkel­processen zoals eXtreme Programming, Scrum of ook wel het meer gangbare DSDM, is het dilemma ongetwijfeld herkenbaar. Deze op zich sympathieke methodieken zijn bij uitstek bruikbaar voor het oplossen van relatief overzichtelijke problemen. Projecten die je met een stuk of 6 medewerkers kunt realiseren zijn ideaal. Echter, zelfs in zulke betrekkelijk overzichtelijke projecten moet je toch wel over de nodige talenten beschikken om goed met de dynamiek in het project om te kunnen gaan. Je hebt heel wat ervaring nodig om op basis van een beknopte user story in korte tijd een voorspelbaar en bruikbaar deelresultaat op te leveren. Een deelresultaat dat bovendien in de toekomst nog moet passen in het grotere systeem, waarvan aanvankelijk alleen nog maar vage contouren bekend zijn. Want dat is immers de crux van Agile Development: alleen het hoogst noodzakelijke wordt gepland, er wordt liefst vanaf dag 1 met bouwen begonnen en er wordt heel snel productie geleverd. Er wordt wel een intensieve betrokkenheid van de klant verwacht om het project in goede banen te leiden. De klant is idealiter dagelijks aanwezig op de werkvloer, hij bepaalt zelf – op basis van de informatie uit het team – waaraan het team moet werken, en vooral ook waaraan niet. Dus als de klant het nut van formele documentatie niet ziet, geen prioriteit geeft aan stresstesten, of niet bereid is om te investeren in uitwijkprocedures, so be it.

Zo’n wendbaar project kan niet alleen op ieder gewenst moment een andere richting ingestuurd worden, maar het kan ook op ieder gewenst moment gestopt worden en desondanks toch een zinvol resultaat opleveren. In de praktijk wordt er natuurlijk pas gestopt als de opdrachtgever tevreden is of als hij om een andere reden stopt met het sponsoren van het project. Er zijn twee duidelijke voordelen: een opdrachtgever kan de ontwikkeling stoppen op het moment dat het systeem precies goed genoeg is; en het wordt makkelijker om de ontwikkeling van een half af systeem om welke reden dan ook een poosje te bevriezen en daarna zonder al te veel problemen weer op te pakken. Dit principe maakt dit type projecten overigens ook wel eXtreem kwetsbaar voor herprioritering, pardon, bezuinigings­operaties, maar dat terzijde.

Als deze manier van werken goed wordt beoefend, dan levert het volgens ingewijden bovengemiddeld elegante oplossingen op en hebben de bouwers bovendien tijdens het project veel fun gehad. Geen wonder dat de populariteit van deze manier van werken vooral onder geeks zo groot is.

Er is ook een downside. Goed beschouwd is complexiteit dodelijk voor lichtgewicht ontwikkelprocessen – die om die reden ook wel magere processen worden genoemd. Dergelijke processen zijn immers vanuit hun aard beperkt schaalbaar. Als je met meer mensen samen moet werken, dan krijg je vanzelf behoefte aan meer ceremonie – de span-of-control van zelf-sturende teams is immers vrij beperkt. En of je nu kiest voor meerdere parallelle teams, of grotere teams, of allebei, er ontstaat onvermijdelijk meer behoefte aan overleg en coördinatie. Trouwens, als de benodigde investeringen groter worden, dan worden de belangen en reputaties die in het geding zijn navenant groter, en zal er ook vanuit die hoek al gauw behoefte zijn aan meer sturing, control of governance.

Nou is er natuurlijk ook in de Agile methodieken wel nagedacht over het omgaan met afstemmingsproblemen bij het ontwikkelen van complexe systemen. Het basisidee is dat je niet alles van te voren probeert op te lossen, en de software die je maakt is dankzij de gekozen aanpak zo goed onderhoudbaar is dat je voortschrijdend inzicht heel makkelijk kunt verwerken. Op die manier kun je door refactoring de veranderingen doorvoeren om allerhande aansluitingsproblemen en voortschrijdend inzicht te verwerken. Dat klinkt heel goed, maar of je nou op die manier een echt ingewikkeld, bedrijfskritisch project tot een goed einde zou kunnen brengen…?

Het minste wat je kunt stellen is dat bovengemiddeld hoog gekwalificeerde, ervaren en gemotiveerde ontwikkelaars vereist zijn om succesvol systemen Agile te ontwikkelen. Ontwikkelaars die al het een en ander hebben meegemaakt, waardoor ze een mate van vakkundigheid hebben ontwikkeld die hen behoedt voor het maken van fundamentele ontwerpfouten. Teamspelers bovendien, die zonder al te veel sturing toch onderling effectief samenwerken - ook met klanten. Eigenlijk meer het type software architecten, die wat ze bedenken zelf bouwen, en wat ze bouwen goed doordenken. Korte lijntjes en zo min mogelijk overdrachtsmomenten, want hoe minder functiescheiding, hoe lichter het gewicht van het proces.

Maar al je daar even over doordenkt, dan betekent dat eigenlijk impliciet dat u uw beste mensen moet inzetten op niet al te complexe projecten! Zwaargewichten inzetten op lichtgewicht uitdagingen. Maar dat ligt niet onmiddellijk voor de hand! Zou u de beste ontwikkelaars die u in huis heeft, echt willen inzetten op eenvoudige klussen, omdat ze daar fun hebben en veel productiever zijn? Maar wie doen dan de complexere, mission critical projecten? Is dat geen schrijnend dilemma?

De uitweg

Gelukkig is er een uitweg uit deze paradox. Agile programmeren kan heel succesvol zijn, mits er een gezonde basis voor is gelegd. Daarmee bedoel ik een rijk platform met generieke enterprise en platform services die het leven van de ontwikkelaars makkelijk maken. En een set van standaarden, richtlijnen en best practices om die servicelaag goed te gebruiken. Minder ervaren ontwikkelaars kunnen zich toeleggen op het realiseren van specifieke functionaliteiten en de enterprise architecten waken over de generieke services. Waar nodig zullen ze deze services pro-actief onderhouden, maar doorgaans begeleiden ze de ontwikkelteams bij het gebruik van deze servicelaag.

De inzet van talent wordt dan overzichtelijk. De zwaargewichten houden zich bezig met de analyse van een complex problemen en de opdeling ervan in een aantal overzichtelijke deelproblemen. Voor de oplossing van deze deelproblemen schetsen ze de contouren en leggen ze principes en regels vast. En binnen zulke duidelijke kaders kunnen minder ervaren of getalenteerde collega’s, uiteraard onder de regie van de enterprise architecten, eXtreem succesvol zijn.

Er is wel een voorwaarde. Het vereist namelijk dat er strategisch geïnvesteerd is in een rijke collectie generieke services. Want alleen dan kan het ontwikkelen van een nieuwe, rijke functionaliteit relatief eenvoudig zijn. Een collectie services die bovendien voortdurend up-to-date gehouden wordt – achterstallig onderhoud in de generieke services zet projecten meteen op achterstand. En dat vereist niet alleen visie, maar ook een masterplan. Een Enterprise Architectuur. Want, om zoveel mogelijk vrijheid te kunnen bieden, moeten nou eenmaal duidelijke lijnen worden gesteld. Enterprise architecten zijn heel goed in staat om het nodige ceremonieel te betrachten in de richting van kritische stakeholders, en tegelijkertijd om op een meer informele manier effectief samen te werken met vakkundige ontwikkelaars en testers. Durf de bouwvergunningen af te schaffen, en schakel in plaats daarvan over op coaching en training-on-the-job.

Kortom: Met de best practices van Agile Development kunt u vooral heel effectief zijn als u ze combineert met de best practices van Werken onder Architectuur. Separation of concerns is het geheim achter de opschaling van lichtgewicht ontwikkelmethoden. En voor ieder viewpoint moet de hoeveelheid ceremonie voortaan afgestemd worden op de daarbij betrokken stakeholders. Logisch toch?

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

It's a Bloody Mess

De gebeurtenis

Laatst was ik, verleid door een intrigerende verwijzing naar een “SOA Maturity Scan”, weer eens op bezoek op de website van IBM. Dat had ik misschien beter niet kunnen doen. Ik begon enthousiast, het leek me interessant om eens te zien hoe zo'n gigant zo'n scan aanpakt. Welke niveaus zouden zij onderkennen, en welke criteria zouden ze hanteren? Zou het lijken op het vertrouwde rijtje “bevreesd, bewust, belegd, beproefd, beleid en begrepen”? En kun je dan, gegeven je huidige situatie, ook een verstandig advies krijgen over de meest effectieve ontwikkelingsstappen? Krijg je een duidelijke roadmap voor de groei naar volwassenheid?

Maar wat een gedoe is dat, zeg. Je moet je om te beginnen aanmelden. Logisch. Nou heb ik dat ongetwijfeld wel eens eerder gedaan; ik heb me tenslotte al jaren geleden verdiept in IBM's patterns for e-Business, en ik heb in de loop van de tijd ook al een hele verzameling IBM Redbooks gespaard, maar helaas, alle pogingen om met oude accounts aan te loggen mislukten jammerlijk. IBM had alle sporen van mijn bestaan in hun digitale wereld blijkbaar volledig gewist. Da's best pijnlijk. We hadden toch een hele constructieve relatie opgebouwd? Maar goed. Dan maar weer een nieuw account aangemaakt.

Jammer toch dat IBM niet gewoon gebruik maakt van de openID standaard. Dan zou je voor goed van al dat proprietary identitygedoe af zijn. Mijn ergernisniveau begon al wat te stijgen...

Uiteraard even snel louter de verplichte gegevens geregistreerd. Jammer genoeg wordt mijn standaard wachtwoord voor dit soort accounts door IBM niet geaccepteerd. En dat terwijl het wel gewoon voldoet aan de enige vermelde eis – minimaal 8 posities lang. Merkwaardig gepruts. Dan maar een ad hoc wachtwoord opgegeven, je moet tenslotte wat.

De ergernismeter stond inmiddels op 2. Toch maar snel teruggebladerd naar de Maturity Scan. Slordig trouwens, dat de site niet gewoon onthoudt waarom je je registeert, en je automatisch terugleidt naar de pagina die je wilde zien. Dat kan toch niet zo moeilijk zijn? Op andere sites werkt dat toch ook?

Oops, da's nou jammer. Ik word vanaf de pagina met de scan meteen weer teruggeleid naar de registratiepagina, met het vriendelijke doch dringende verzoek of ik toch nog maar wat aanvullende gegevens zou willen verstrekken. Dat kan toch niet waar zijn? Moet ik hiermee doorgaan? Oké dan, omdat ik toch nog steeds nieuwsgierig ben mag IBM best weten dat mijn bedrijf gevestigd is aan de Dorpsstraat in Madurodam. Als ze daar nou gelukkig van worden...

Met de meter bijna in het rood heb ik de scan uiteindelijk volbracht. Het is bepaald niet wereldschokkend. Het ziet er gelikt uit, dat wel, en bevat vooral veel verwijzingen naar IBM producten en diensten. Tsja, wat verwacht je ook anders. Maar mijn ergernis was weer dat gedaald. De scan deed het tenminste gewoon zonder haperen.

Uiteindelijk ben ik nog gezwicht voor het advies om vooral de IBM 'SOA newsletter' te gaan bekijken. Misschien dat ik daar nog wat nieuws van zou kunnen leren. Je moet toch bijblijven, niet waar? Maar hé, da's flauw, je moet hier alweer opnieuw aanloggen. Erger nog, het zojuist vers aangemaakte IBM account is hiervoor helemaal niet geldig. Je wordt gedwongen om weer een nieuw account aanmaken. Mijn adrenaline­niveau begint inmiddels gevaarlijk hoge waardes aan te nemen.

Maar wacht, het kan kennelijk altijd nog bizarder. Het ad-hoc wachtwoord dat IBM zojuist nog zonder mankeren accepteerde voldoet nu helaas niet aan de eisen van, eh, IBM. En het wachtwoord dat IBM zojuist nog weigerde, wordt gek genoeg nu ineens weer wel zonder enig probleem geaccepteerd. Is dat geen prachtig voorbeeld van ergerniswekkende SOA immaturity? Heeft de globally integrated company soms nog nooit van een enterprise directory service gehoord?

Overigens heb ik de hele newsletter uiteindelijk nooit gezien. Ik geef het eerlijk toe, ik ben volkomen verdwaald in het doolhof van de IBM website. Toch heb ik naar mijn idee, terwijl de stoom nog uit mijn oren spoot, nog behoorlijk mijn best gedaan. Ik geef niet zo snel op, en al helemaal niet als ik al een heleboel tijd heb verspild. Maar de zoekengine geeft simpelweg veel te veel hits en voornamelijk heel veel ruis. Dat is toch echt niet meer van deze tijd. Als dit representatief is voor de enterprise search service van IBM, dan is dat ver beneden het niveau dat ik vandaag de dag gewend ben. Ik heb al surfend tot vervelens toe nog meer nieuwe aanlogpagina's gekregen, allerlei onbegrijpelijke foutmeldingen te zien gekregen, en heb uiteindelijk met het oog op mijn bloeddruk de moed maar opgegeven.

Mijn gevoel over de website van IBM? It's a Bloody Mess.

Om over te peinzen

Noblesse oblige. Als je je als leverancier profileert als visionair op het gebied van enterprise architectuur, dan wekt dat bepaalde verwachtingen. Je kunt allerlei verzachtende omstandigheden aanvoeren. Natuurlijk is het dak bij de loodgieter altijd lek, en is het bij de concurrenten vast niet veel beter gesteld. Het is gewoon de zoveelste illustratie van de onvolwassenheid van de IT industrie. Allemaal 100% waar, maar het neemt de irritatie bij bezoekers en klanten echt niet weg.

Tegelijkertijd doet het je denken, wat je er van kunt leren. Het hele geval is in zichzelf in elk geval een prachtige illustratie van de noodzaak om meer onder architectuur te gaan werken. Minder chaos en meer eenheid.

Maar hoe zou je nou een complexe informatieruimte, zoals die zonder enige twijfel achter de website van IBM schuil gaat, een beetje snugger kunnen organiseren? En dat, want laten we wel realistisch zijn, onder de randvoorwaarde dat het geen volkomen verstarde, trage, onwerkbare bureaucratie oplevert. Enig idee?

Zoals zo vaak wijst de architecturele benadering de weg naar de oplossing. Wie zijn de belangrijkste belanghebbenden bij de website? De content managers? De verkopers van producten en diensten? De service managers? Nee natuurlijk niet! De website is er primair voor de klanten. Zonder klanten geen verkopen, en zonder verkopen geen inkomsten. Ook bij IBM geldt de aloude wijsheid dat de salarisketen begint bij klanten die bestellingen plaatsen en facturen betalen. Klanten zijn uiteindelijk de moeder van alle stakeholders.

En dus?

Stel dat IBM zijn website zou organiseren rondom zijn klanten en prospects. Dat de totale informatieruimte ingedeeld werd in regio's die zich op specifieke klantpopulaties zouden richten. En dat die regio's misschien nog verder gedifferentieerd zouden worden in rayons, die nog specifieker getarget zouden zijn op concrete klantgroepen. Stel dat de website zo vormgegeven zou worden dat u, als bezoeker, voortdurend de beleving zou hebben alsof u bij een bepaalde klantgroep zou horen. Dan zou het ineens niet meer zo gek zijn dat u, als u er bewust voor zou kiezen om een grens te passeren, op dat moment uw identiteitsbewijs zou moeten tonen.

Je zou je heel goed kunnen voorstellen dat er een content manager verantwoordelijk zou zijn voor het beheer van een rayon. Omdat zo´n persoon in beginsel binnen zijn rayon de vrijheid geniet om alles te doen wat zijn klanten en bezoekers tevreden zou kunnen stemmen, is er geen enkele reden waarom dat niet soepel, daadkrachtig en effectief zou kunnen zijn. Uiteraard geldt dat de overgang tussen de regio´s aan speciale voorwaarden verbonden is, en de overgang tussen gebieden aan nog strengere voorwaarden. Het herindelen van de regio´s is niet zo makkelijk, en de indeling in gebieden is nog lastiger te wijzigen. Flexibiliteit binnen de grenzen, en stabiliteit van de grenzen zelf. Is dat niet net zoiets als `separation of concerns´? Lijkt dat niet heel erg op 'high cohesion and low coupling'? Is dat niet waar je een goede architectuur aan herkent?

Die enterprise directory, die moet er natuurlijk gewoon komen. Dat is een kwestie van organisatie. Het vrije verkeer van personen vereist gewoon dat er een gemeenschappelijk identificatie­systeem bestaat. Dat kun je iedereen uitleggen. Dan blijft er nog maar één te kraken noot over. Hoe kun je op zo'n website je weg vinden? Hoe kun je voorkomen dat je een overstelpende hoeveelheid irrelevante hits krijgt? Een standaard zoekengine heeft geen idee van een indeling van de ruimte en geeft gewoon alles wat mogelijkerwijs relevant zou kunnen zijn. Maar waarom kent zo'n engine de geografische context eigenlijk niet? Waarom zou je niet, net als in een telefoongids, kunnen zoeken naar lokale items, intelokale items en internationale items? Dat is toch eerder vertoond? Een wereldkaart heeft een andere resolutie dan een stafkaart. En zelfs het domeinnamensysteem op internet is gelaagd. Waarom, zo vraag ik mij af, zou dit dan niet de geëigende zoekstrategie voor searchengines zijn?

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

Duivelse details

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

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

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

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

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

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

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

De wereld op z’n kop!

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

Flauwekul?

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

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

De architectuuragenda

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

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

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

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

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