Wining & dining

Van tijd tot tijd laait het debat op over de superioriteit van legacy software. Recentelijk heeft Wouter Keller deze discussie weer eens aangesneden op Via Nova Architectura. In zijn bijdrage stelt hij “politiekcorrecte technologie” tegenover “bestaande oplossingen die zich bewezen hebben in de praktijk”. En, het laat zich raden, hij stelt dat techniek “een van de belangrijkste faalfactoren is bij ICT-trajecten”. Mijn bijdrage aan dit debat beoogt dit beeld enigszins te nuanceren.

De Kwestie

De discussie over de zin en onzin van het gebruik van nieuwe technologie is zo oud als de IT-sector zelf. Er zijn vast nog schrijvers te vinden die de voorkeur geven aan het gebruik van een typemachine boven een PC. Toch is het een hele poos geleden dat ik voor het laatst over een typekamer liep. Het moet ongeveer in dezelfde tijd geweest zijn dat er een hevige discussie werd gevoerd over het gebruik van compilers voor tijdkritische processen. Er ging tenslotte niets boven ambachtelijke assemblercode.

Sindsdien heb ik opmerkelijk soortgelijke argumenten pro en contra nog diverse malen horen langskomen. Bijvoorbeeld bij de overgang van tekstgeoriënteerde schermen naar GUI's, de migratie naar relationele databases, bij de invoering van Client/Server technologie, bij de adoptie van webgebaseerde user interfaces en – last but not least – bij het gebruik van CBD en SOA. Telkens als het tegenzit, zoals bij organisaties die momenteel worstelen met opschaling van SOA, dan zijn de doodgewaande dino's er als de kippen bij om te betogen dat al die moderniteit in de praktijk alleen maar problemen oplevert en dat het vroeger allemaal beter was. Legacy is voor de één een haast onuitroeibaar onkruid, terwijl de ander trots is op het stoere, robuuste karakter ervan. Herkenbaar?

Er is een keur aan wijnen op de markt. Van jong tot oud, van soepel tot geraffineerd. Belegen wijn is jarenlang vertroeteld, de besten op nieuw eikenhout, voor een smaakvol en complex resultaat. Wie van zulke wijnen houdt, en dat zijn er velen, hecht aan oude tradities en is bereid om een stevige prijs te betalen. De pleitbezorgers van legacy software kunnen hier zeker moed uit putten.

Iedere levensgenieter weet dat wijn de kroon is op een goede maaltijd. Echter, niet iedere wijn past bij elk gerecht. Het echte succes zit in de combinatie. Zoals een witlofschotel baat heeft bij een Chileense Carmenère, een Australische Syrah heel goed past bij een Hongaarse goulash en een Kaapse Riesling een betoverend oesterwatertje is. En omgekeerd moet ik niet denken aan een mooie Sancerre met Hollandse Nieuwe, of een onvolprezen Barolo met erwtensoep. Yeck.

Een goede wijn kan een goede maaltijd tot een belevenis maken – mits goed gecombineerd. Een slechte wijn, of een slecht gecombineerde wijn kan een prima maaltijd behoorlijk bederven. En, jammer maar helaas, een goede wijn kan een slecht maal niet redden – tenzij je er misschien heel veel van drinkt (maar ook daar krijg je later spijt van).

Iets soortgelijks geldt voor archITectuurkeuzes. Er zijn boeken volgeschreven over succesvolle combinaties, patterns, maar hoed u voor het toepassen van goede technologie die niet past bij het probleem dat opgelost moet worden. Verwacht ook niet dat goede architectuur een slecht project kan redden. Dat levert hoogstens een kater op.

Weerwoord

ArchITecten worden verantwoordelijk gehouden voor architectuurkeuzes. Dat is een complexere en verantwoordelijkere taak dan sommigen zich lijken te realiseren. Zij hebben de neiging om slaafs de voorgeschreven referentiearchitectuur te volgen, of om juist vast te houden aan de vertrouwde keuzes uit het verleden. Beide vormen van jumping to solutions miskennen de echte waarde van (werken onder) archITectuur. Goede archITectuurkeuzes zijn geen sinecure! Het is een vak, dat veel studie vereist – al is het maar om de ontwikkelingen in de technologie en de ervaringen ermee nauwgezet te volgen. Een sommelier moet tenslotte ook blijven bijleren over de nieuwe jaargangen en de opkomende wijngebieden om bij te blijven in zijn vak.

Als projecten niet lukken, dan is de gebruikte technologie een dankbare zondebok. Het projectteam treft dan tenminste geen blaam, want de leverancier heeft de feiten anders voorgespiegeld, zo redeneert men. In de realiteit mislukken er maar weinig projecten door slechte technologie. Als je achteraf eerlijk analyseert wat er is misgegaan, dan blijkt het veel vaker te liggen aan verkeerde technologiekeuzes (erwtensoep met Barolo). En daarbij is het zeker niet zo dat het altijd ligt aan het kiezen van eigentijdse architectuur voor ouderwetse problemen; het kiezen van bewezen architectuur voor moderne problemen is een minstens even grote valkuil.

Een minder vaak belicht aspect is de neiging tot het schromelijk onderschatten van de consequenties van modernisering. Het is één ding om een – laten we zeggen – Progress ontwikkelaar naar een .Net cursus te sturen om te leren om webapplicaties te bouwen. Maar daarmee heb je nog niet de competentie in huis om self-service applicaties te kunnen ontwerpen of om websites professioneel te hosten. Net zo min levert het ontwikkelen van herbruikbare services een bijdrage aan het oplossen van het governance probleem. Gert Florijn heeft daarover laatst een behartenswaardig interview gegeven in het blad “service oriented architecture” [1]. Het zou archITecten naar mijn mening sieren als zij de verantwoordelijkheid zouden nemen om dit soort zaken vroegtijdig te signaleren

En ja, ook ik kom in mijn adviespraktijk projecten tegen die gewoon gefaald zijn door een slechte besturing. Eigenlijk is het onderschatten van de consequenties van veranderingen daar ook een vorm van. Want die consequenties hadden doorgaans best vooraf voorspeld kunnen worden. Het is en blijft kennelijk verschrikkelijk moeilijk om te leren van fouten van anderen. Jammer is dat.

Er moet mij nog één ding van het hart. Er wordt soms met wat dedain geschreven over het gebruik van moderne technologie als uit de hand gelopen hobby van de nerds uit de pizzakelder. Ik vind het volkomen legitiem om het ontwikkelen van nieuwe competenties als prominent nevendoel voor een project op te voeren, zo lang die nieuwe competenties maar stevig zijn ingebed in de strategie van de organisatie. Daarom is het juist zo belangrijk dat archITecten zijn aangehaakt bij de strategische dialoog.

Om nog één keer terug te grijpen op de metafoor van de wijn: ook hier geldt dat een wijn, hoe goed hij ook is opgevoed, na verloop van jaren over zijn hoogtepunt heen is. Dan gaat hij onverbiddelijk alleen nog maar achteruit. Zo is het ook met technologie. Eerst groeit het gebruik minder hard dan de markt, dan groeit het helemaal niet meer en daarna krimpt het marktaandeel alleen nog maar. Voor leveranciers is dat het signaal om de investeringen anders in te gaan zetten. Medewerkers die nog een carrière voor zich hebben, raken ook minder bereid om hun tijd en energie te investeren in oude technologie. En tegen de tijd dat zoiets zich aan het voltrekken is, dan kun je maar beter een alternatief achter de hand hebben.

Als je als organisatie het lef niet hebt om te investeren in de toekomst, dan moet je ook niet gek opkijken als het slecht met je afloopt. Daar kunnen de vele geoutsourcede IT-afdelingen inmiddels over meepraten.

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

[1] Dré de Man: “Struikelend hardlopen”. Service oriented architecture, mei 2009, p. 6.

Het hoogst haalbare

Er zijn architecten die zich nadrukkelijk weten te onderscheiden van het gemiddelde. Opvallende persoonlijkheden die ‘anders-dan-anderen’ zijn. Zo iemand is Richard Meier – in Nederland vooral bekend als architect van het Haagse gemeentehuis. Eén van zijn handelswijzen die bij mij altijd is blijven hangen is zijn haast koppige doorzettingsvermogen.

De Kwestie

Het oorspronkelijke ontwerp voor het Haagse gemeentehuis was volgens vriend en vijand baanbrekend. De meeslepende manier waarop hij het plan presenteerde! Iedereen die erover mocht beslissen was er vrijwel meteen laaiend enthousiast over. Hij had als geen ander aangevoeld wat er op die plek in de stad mogelijk was. Een gebouw dat de ambtenaren en ook de burgers een warm thuisgevoel zou bieden. Er was maar één probleem. Het was volgens de overheidsnormen te duur. Veel te duur. Niet haalbaar. Het moest wel versoberd worden.

Er zou ofwel bezuinigd moeten worden op de omvang van het complex, ofwel op de kwaliteit van de uitvoering. Dat kon niet anders. Dat zou tenminste de logische reactie zijn geweest van bijna iedere architect. En anders zou de gemiddelde opdrachtgever hem die les wel leren. De opdrachtgever bepaalt het budget, en de architect accepteert dat als randvoorwaarde waarbinnen hij moet werken. Samen met zijn opdrachtgever bepaalt hij het maximum haalbare binnen het toegestane budget. Zo gaat dat.

Bij de charismatische Richard Meier ging dat toch anders. Want hij geloofde heilig in zijn ontwerp. Het was het beste gemeentehuis dat Den Haag zich kon wensen. En als Den Haag het zich niet kon veroorloven, dan zou je de oplossing wel kleiner kunnen maken, maar hij koos ervoor om in plaats daarvan het probleem een stuk groter te maken. Dus werd er extra functionaliteit gezocht om de kosten van het gebouw te kunnen dragen. Zo ontstond het idee om de centrale bibliotheek in het complex onder te brengen. Op die manier kon hij vasthouden aan zijn ideale ontwerp en het toch betaalbaar maken voor zijn aan de strikte overheidsnormen gebonden opdrachtgever.

Kijk, dat is nou een houding die mogelijk maakt wat vele anderen voor onmogelijk hadden gehouden. Niet alleen maar luisteren naar wat een opdrachtgever zegt te willen, maar aanvoelen wat een opdrachtgever eigenlijk zou willen. Forget the requirements, focus on the true needs instead.

Zou iemand zich op dat moment afgevraagd hebben wat het belang was van Richard Meier zélf bij de uitbreiding van de scope? Het is immers gebruikelijk dat architecten een afgesproken percentage van de aanneemsom kunnen declareren. Hoe hoger de bouwkosten, hoe meer een architect dus kan verdienen.

Het lijkt mij niet erg waarschijnlijk dat dit een rol heeft gespeeld. Een architect met de reputatie van Richard Meier kan zich makkelijk veroorloven om alleen die projecten aan te nemen die passen in zijn filosofie. Een gebouw van de allure van het Haagse gemeentehuis is tenslotte een prestigeproject dat op wereldwijde aandacht van vakgenoten kan rekenen. Vanuit het perspectief van een architect is zoiets een gouden kans om zijn visitekaartje af te geven. Met zulke kansen moet je goed om weten te gaan.

Om over te peinzen.

Haalbaarheid – zeker ook in financiële zin – is keer op keer een argument om inferieure architectuurkeuzes te rechtvaardigen. Er lijkt zich zelden of nooit een goede gelegenheid voor te doen om een hoogwaardige oplossing te realiseren. Dan weer is het de knellende legacyproblematiek, een andere keer is het een gebrek aan ervaring en anders is het wel de korte time-to-market die roet in het eten gooit. En keer op keer krijgt de opdrachtgever niet wat hij eigenlijk zou willen. Keer op keer worden de echte noden niet gehonoreerd.

Natuurlijk zijn opdrachtgevers daarbij een deel van het probleem. Projecten worden altijd te laat gestart, projecten krijgen eng afgebakende doelstellingen mee en opdrachtgevers staan lang niet altijd open voor goede ideeën van anderen. Dat gold allemaal ook voor het gemeenthuis van Richard Meier. En toch, tóch was hij in staat om ruimte te creëren. Against all odds. Je krijgt succes zelden in de schoot geworpen. Het vereist passie, hard zwoegen, oefening, focus, gedrevenheid, dienstbaarheid, ideeën en volharding. Kijk daar de wijze lessen van Richard St. John maar eens op na.

Als je als architect je liever niet leidzaam neerlegt bij het gegevene, als je een passie hebt om het hoogst haalbare mogelijk te maken, dan zoek je net als Richard Meier naar wegen die anderen niet begaanbaar achten. Anders dan anderen heb je de neiging om niet slaafs binnen de kaders te blijven die je worden gesteld, maar in plaats daarvan het belang van je opdrachtgever te dienen door juist buiten de gestelde kaders te treden. Je hebt het lef om de uitgangspunten principieel ter discussie te stellen. Alleen dán zul je in staat zijn om écht een verschil te maken. Om de organisatie tot écht baanbrekende prestaties aan te zetten. En uiteindelijk is dat hetgene waar een opdrachtgever werkelijk op uit is. Gewoon het ongewone durven en doen. Zonder dat, geen vooruitgang.

Tegelijkertijd is het natuurlijk verstandig om te waken voor overdrijving. Niet ieder probleem vraagt om een onconventionele oplossing. Niet iedere onconventionele oplossing is geloofwaardig. Niet iedere archITect heeft een reputatie die bijdraagt aan zijn overtuigingskracht. Niet ieder moment is even geschikt voor structurele veranderingen. Houd dus de realiteit scherp in de gaten en kom altijd goed getimed met doordachte voorstellen. Laat geen onnozele proefballonnetjes op, die worden toch maar doorgeprikt. En bouw ondertussen doelbewust aan een sterke reputatie. Want de successen uit je verleden zijn nou eenmaal de beste basis voor je toekomstige succes. 

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

Methodologica

De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op de site van Via Nova leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?

Het debat

Als je nuchter kijkt naar de bedrijfsprocessen in IT-afdelingen, dan zijn het er eigenlijk niet zo heel veel. Het onderstaande rijtje zal in de meeste gevallen al behoorlijk dekkend zijn.

1. Het ontwikkelen van nieuwe applicaties / systemen / functies / oplossingen

2. Het implementeren van op de markt verkrijgbare applicaties / systemen / functies / oplossingen

3. Het verbeteren van bestaande applicaties / systemen / functies / oplossingen

4. Het in stand houden van applicaties / systemen / functies / oplossingen

5. Het ontwikkelen en bewaken van beleid voor (een specifiek domein van) applicaties / systemen / functies / oplossingen

Het organiseren van een handvol bedrijfsprocessen zou dus moeten volstaan om IT-afdelingen in te richten. Hoeveel standaard processen, methodieken en raamwerken zouden er moeten zijn om deze 5 bedrijfsprocessen professioneel in te vullen...?

Denk dan eens aan de keuzerijkdom van instrumenten zoals ASL, BiSL, CMMI, COBIT,Cocomo, Demo, DSDM, DYA, EUP, FPA, IAF, IEEE-1471, ITIL, ITSMI, JBF, MArch, MSP, Pino, PMBOK, Prince2, RUP, SEBOK, Scrum, SDM, TMap, TOGAF, XP, Zachman en vele, vele anderen. Het is natuurlijk goed om iets te kiezen te hebben, maar is het allemaal niet een beetje veel en onoverzichtelijk geworden? Begrijpen we wel goed hoe de verschillende methodieken op elkaar aansluiten? Wie doorziet de methodologica nog?

Als je goed kijkt naar de verschillende methodieken, dan valt op dat de meeste zich niet richten op een proces, maar op een subdiscipline. Ze gaan over testen, project management, governance of beheer. Nog preciezer: ze beschrijven de bedrijfsprocessen vanuit het perspectief van de tester, de project manager, de IT manager of de beheerder. De makke van de huidige methodiekenstrijd is dat deze vooral binnen subdisciplines woedt. Testers debatteren over de beste aanpak om te testen, functioneel beheerders zijn vooral met hun eigen best practices bezig en voor project managers, ontwikkelaars en architecten geldt al niet veel anders. Ieder specialisme zijn eigen manier van werken.

Dit geldt net zo goed voor TOGAF. De Architecture Development Methodology, het beeldmerk van TOGAF, is architect-centric. Het beschouwt de wereld vanuit de bril van de IT-architect en de discussie daarover woedt louter in het architectenwereldje. Deze discussie vertroebelt tot mijn verdriet het zicht op de bal. Wat was ook al weer het verheven doel van werken onder architectuur? Waar doen we het voor? Om architectuur te produceren? Ter meerdere eer en glorie van architecten? Of om de informatievoorziening van bedrijven te stroomlijnen? Om de chaos van werken zonder architectuur te bestrijden?

Als we dát willen, dan zullen we toch de samenwerking moeten zoeken met de professionals uit die andere subdisciplines. Dan hebben we weinig aan een methodiek voor architecten. Dan hebben we nood aan een methodiek die multi-disciplinaire samenwerking ondersteunt en bevordert.

Unified view

De vijf geschetste bedrijfsprocessen vragen elk voor zich om een multidisciplinaire aanpak, waarbij dezelfde subdisciplines in meerdere processen een rol spelen. Die bedrijfsprocessen verschillen van bedrijf tot bedrijf niet wezenlijk van elkaar. Dat schreeuwt om een standaard aanpak, om een overkoepelende methodiek. Maar het debat over de samenhang tussen de verschillende methodieken binnen één voortbrengingssproces is merkwaardigerwijs nog nauwelijks van de grond gekomen. Zouden IT-ers te betrokken zijn bij hun eigen werk om hun eigen manier van werken goed te kunnen analyseren en structureren?

Als je nog iets verder denkt, dan is het niet persé handig als een professional die een rol speelt in meer dan één soort bedrijfsproces telkens zou moeten overschakelen op een andere methodiek. Maar waarom is er dan niet één methodiek die de vijf genoemde bedrijfsprocessen in hun onderlinge samenhang beschrijft? Zo moeilijk kan dat toch niet zijn? Zouden we dáár als architectuurcommunity eigenlijk onze energie niet in moeten steken?

Zo'n integraal procesmodel hoeft heus geen one-size-fits-all te zijn. Er mogen best een stuk of drie scholen zijn, die elk een principieel andere weg kiezen voor de invulling van de bedrijfsprocessen in de informatievoorziening. Laten we zeggen, de Engelse school – gebouwd op ITIL en DSDM – de Rationele school – gebouwd op de unified processes – en de Rode school waaraan Oracle ongetwijfeld naarstig werkt. Dan blijft er iets te kiezen en zou zo'n keuze te baseren zijn op de mate van synergie met de eigen bedrijfsprincipes.

Er zijn wat hoopvolle tekenen dat er meer mensen in deze richting denken. Wim Hoving en Jan van Bon pleiten in een artikel in de Automatiseringgids bijvoorbeeld voor een fusie van ITIL, ASL en BiSL. Eén methodiek voor het in stand houden van applicaties / systemen / functies / oplossingen. Ook het unified process is van nature multidisciplinair. Het kán dus wel degelijk.

Oproep

Als architectencommunity zouden we een bijdrage moeten leveren aan de verbetering van de organisatie van de bedrijfsprocessen in de informatievoorziening. Het concept “Ontwikkelen onder Architectuur” is alvast een goed begin, zij het dat het dan wel als een volwaardig ontwikkelproces uitgewerkt zou moeten worden (ik heb het altijd een merkwaardig fenomeen gevonden dat iets wat we betitelen als “Ontwikkelen” als een primair architectuurproces wordt gepositioneerd, maar dat terzijde). Zo zouden we ook voor “Implementeren onder Architectuur”; “Evolueren onder Architectuur”; “Beheren onder Architectuur” en “Beleidsontwikkeling onder Architectuur” modelprocessen kunnen ontwerpen. Uiteraard zouden die processen zoveel mogelijk voort moeten bouwen op de de-facto standaarden die al in gebruik zijn, waarbij het een behoorlijke uitdaging wordt om die qua terminologie en qua systematiek goed op elkaar te mappen. En uiteraard moeten deze modelprocessen inzicht bieden in de plaats van architectuur binnen die bedrijfsprocessen.

Zou dat nou niet een interessant thema zijn voor een workshop tijdens het komende LAC als opmaat naar een nieuw NAF-boek?

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

Intensieve computerhouderij

Nicholas Carr heeft het weer voor elkaar. Zijn laatste boek “The Big Switch” heeft de tongen en pennen wereldwijd weer hevig in beroering gebracht. Het blad “Computable” stelt naar aanleiding van het oplaaiende debat weer eens openlijk de vraag “Wordt it een nutsmiddel net als de elektriciteitsvoorziening?”

Zelf was ik eigenlijk niet van plan om opnieuw aan dit debat mee te doen. Ik heb er hier al een keer over geschreven en toen was mijn boodschap al dat “IT” veel meer is dan alleen maar het opwekken van een betrouwbare informatiestroom. Wat dat betreft vind ik de argumenten van autoriteiten als Don Tapscott of Chris Verhoef veel overtuigender. Ik ben niet van mening veranderd. Toch heb ik er opnieuw over zitten peinzen.

Het debat

Nicolas Carr predikt de revolutie. Wat in een grijs verleden met stroom is gebeurd – van lokaal opgewekte stroom naar nutsvoorziening – zou nu met 'IT' gaan gebeuren. Gebruikersorganisaties zouden massaal tot het inzicht komen dat het “opwekken van IT” geen core business is en veel beter door een gespecialiseerd bedrijf zou kunnen gebeuren. Zo'n – wat ik noem – intensieve computerhouderij zou belangrijke schaalvoordelen met zich mee brengen, met een hogere betrouwbaarheid en een lagere prijs als onvermijdelijk resultaat. En wie zou dat nou niet willen? Het is niets nieuws. Het rijtje is even bekend als afgezaagd: Internet Service Providers, Application Service Providers, Outsourcing, trusted Business Service Providers, Software-as-a-service, Platform-as-a-service, the Cloud. En dan zie ik vast nog wel wat incarnaties van in essentie hetzelfde concept over het hoofd. Maar om nou te spreken over een revolutionaire verandering?

Tapscott heeft er al uitgebreid op gewezen dat IT niet alleen een “T”-gezicht heeft, maar ook een “I”-gezicht (“Why You Can't Take the "I" Out of IT”). Wanneer heeft u voor het laatst gelezen over een mislukt project vanwege een tekort aan computercapaciteit? Of vanwege een fout van een beheerder? Zet dat eens af tegen de projecten die op de klippen zijn gelopen door tekortschietend opdrachtgeverschap, mismanagement of fundamentele ontwerpfouten? Carr wil ons toch niet werkelijk laten geloven dat iedere SAP-implementatie alleen nog maar glansrijk kan slagen, alleen maar omdat SAP “uit de muur komt”? Of dat je voortaan probleemloos zou kunnen overschakelen van SAP op Oracle Fusion, omdat het toch uit dezelfde muur komt? Of zelfs dat je de verantwoordelijkheid voor zo'n operatie bij een externe provider zou willen beleggen? Dat valt toch in de verste verten niet te vergelijken met de switch van NUON naar Eneco?

Misschien is een vergelijking met de telecomindustrie wel veel meer op z'n plaats. Ook deze industrie is ontstaan als een nutsvoorziening. Telefoon komt gewoon uit de muur, of beter nog, uit de lucht, toch? Maar dat betekent nog níet automatisch dat geen enkel bedrijf zou hoeven te investeren in een éígen telefooncentrale! Als de telefoon een cruciaal bedrijfsmiddel is om je call-center te runnen, dan is het toch ook in economische zin volkomen gerechtvaardigd om daarin zelf te investeren? En zelfs als het zo zou zijn dat alle functionaliteit die je voor je call center nodig hebt “uit de muur” beschikbaar zou zijn, zou het dan ook maar een greintje minder ingewikkeld zijn om het voice-respons systeem goed in te richten, om de binnenkomende gesprekken goed te routeren en om de benodigde operator capaciteit goed in te plannen? Zou het voor zo'n grootschalige nutsvoorziening wel eenvoudiger zijn om nieuwe, concurrerende call-center technologie te implementeren? Of zouden zulke innovaties al snel smoren in complexiteit?

Om over te peinzen

Het lijkt mij dat er een reden moet zijn waarom veel computerintensieve bedrijven niet enthousiast inhaken op het idee van “IT uit de muur”. Zou het misschien zo kunnen zijn dat dit het simpele feit is dat “IT uit de muur” voor veel van die bedrijven geen reëel probleem oplost? Dat hun rekencentra grosso modo tenminste voor de bedrijfskritische systemen de huishouding behoorlijk op orde hebben? Immers, zou dit structureel niet het geval zijn, dan had men dit probleem immers al veel eerder op kunnen lossen; al was het maar via outsourcing.

En als je een goed lopend rekencentrum hebt, dan kan Carr wel voorrekenen dat dezelfde service goedkoper elders betrokken kan worden, maar dan houdt hij waarschijnlijk geen rekening met de desinvesteringen die daarmee gepaard gaan. Als je daar wel rekening mee houdt dan krijg je een business case niet zo makkelijk rond. Over hoeveel jaar is 'het rekencentrum' bij u afgeschreven?

Maar moet je eigenlijk wel rekencentra willen verplaatsen en concentreren, enkel en alleen om van schaalvoordelen gebruik te kunnen maken? Heeft u daar wel eens over nagedacht? Ik kom de laatste tijd niet meer zo vaak op een computervloer, dat geef ik grif toe, maar de keren dat ik er eens kom, dan valt het me iedere keer weer op dat het rekencentrum zo goed als uitgestorven is. Er is zelden iemand te bekennen. Waarom zou je ook? De systemen zijn prima op afstand te besturen en iets handmatigs als het verwisselen van tapes is al lang geleden gerobotiseerd.

Automatisch up- en downscalen kan met moderne virtualisatietechnologie best over de fysieke grenzen van rekencentra heen. Wat vroeger “uitwijk” werd genoemd, kan met moderne technologie geautomatiseerd worden door meerdere rekencentra met elkaar te verbinden. En op die manier kan onvoorzien onderhoud aan computersystemen best planbaar worden: er gaat iets stuk, je herrouteert de informatiestroom en je kunt een reparatie rustig uitvoeren terwijl het vliegtuig gewoon in de lucht blijft. En de overcapaciteit in het rekencentrum van het ene bedrijf kan – tegen een passende betaling, dat spreekt! – eenvoudigweg benut worden voor de capaciteitsbehoefte van een ander bedrijf. Met andere woorden: een virtuele cloud kan in principe net zo effectief zijn als een fysieke cloud. Maar het is wel veel makkelijker van de grond te krijgen! Bestaande capaciteit koppelen in plaats van afbreken en elders nieuw opbouwen. Dat is toch veel slimmer?

Daarom zou ik Carr willen vragen, is zo'n intensieve computerhouderij geen verstokt 20^ste eeuws denken? Zou je nou juist de computertechnologie van de 21^ste eeuw niet heel goed kunnen gebruiken om fysieke barrières te overwinnen? Om capaciteit te distribueren en alleen de activiteit te centraliseren? Is het niet de verdienste van het internet dat we tegenwoordig locatie-onafhankelijk kunnen werken, ook – of misschien wel juist – als IT-ers? Zou daar dan het debat niet over moeten gaan?

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

Darwin Day

Vandaag, donderdag 12 februari 2009, is uitgeroepen tot world Darwin day. Het is namelijk 200 jaar geleden dat deze wetenschapper is geboren. Ter ere daarvan heeft Google vandaag zelfs haar logo hierop afgestemd.

Het nieuws

Darwin, die zoals bekend aan de basis van de evolutietheorie heeft gestaan, wordt alom gezien als een van de grootste wetenschappers die ooit heeft geleefd. Zoals het blad Nature het deze week verwoordde: “Als hedendaagse wetenschappers zouden mogen beslissen wiens afbeelding er op het papiergeld afgebeeld zou moeten worden, dan zou Charles Darwin daar zeker bij zitten”.

De meeste Nederlanders accepteren tegenwoordig dat evolutie 'van nature' plaatsvindt. Anders dan in sommige andere landen is het onderwijzen van de evolutietheorie op scholen in Nederland nauwelijks omstreden. Andries Knevel, van wie je toch een creationistische grondhouding zou verwachten, veroorzaakte onlangs een relletje toen uitgerekend hij liet weten ook voor orthodoxe christenen ruimte te zien om niet te geloven in een schepping van 6 dagen van 24 uur.

Wat heeft dit alles te met het bedrijven van archITectuur? Nou, dat zit zo. Ik heb sterk de indruk dat IT-organisaties in Nederland massaal zo zijn georganiseerd alsof ze nog steeds geloven in het scheppingsverhaal van de digitale wereld. Er zijn programma's en projecten, die worden verantwoordelijk gehouden voor de creatie van telkens een stukje van de digitale wereld. Als dat eenmaal is gelukt, of tenminste enigszins is gelukt, dan wordt het resultaat 'overgedragen' aan 'beheer'. De voornaamste verantwoordelijkheid van 'beheer' is om er voor te zorgen dat de digitale wereld blijft zoals die door de scheppers is gecreëerd. Deze twee verantwoordelijkheden zijn meestal op afstand van elkaar georganiseerd – soms zelfs bij totaal verschillende organisaties belegd.

Naar mijn overtuiging is deze scheiding gebaseerd op een schijnwerkelijkheid. Namelijk de schijnwerkelijkheid dat evolutie in de digitale wereld niet bestaat, of dat je er in elk geval in je organisatie geen rekening mee hoeft te houden. Dat de zaken in de digitale wereld alleen gecontroleerd en gepland veranderen. En dat is nou naar mijn idee een tragisch voorbeeld van bedenkelijke

Flauwekul!

Wie een beetje oplet, die ziet de evolutie in de digitale wereld overal aan het werk. Systemen worden voortdurend aangepast aan wijzigende omstandigheden; gebruikers gaan de systemen in de loop van de tijd op een andere manier gebruiken en dan heb ik het nog niet het effect van de technologische infrastructuur, die voortdurend in ontwikkeling is. De digitale wereld wordt ook steeds groter: meer en meer systemen worden gekoppeld; meer en meer domeinen worden gedigitaliseerd.

Allerlei technologische ontwikkelingen van de laatste jaren vergroten de mogelijkheden van evolutie. Webapplicaties worden steeds minder in omvangrijke releases met lange intervallen uitgegeven, maar in plaats daarvan in korte cycli permanent verbeterd. Enterprise software is dankzij de inzet van business process en business rules engines geschikt gemaakt om at runtime aangepast te worden aan wijzigende behoeften en omstandigheden. En het concept van «Event Stream Processing» is zelfs gelanceerd met het idee dat het zich in combinatie met «Enterprise Decisioning» heel goed dynamisch aan wijzigende omstandigheden zou kunnen aanpassen. «Continuous Business Improvement» noemen ze dat bij IBM.

En toch, toch werken wij nog steeds met processen als DYA, TOGAF, Prince2, RUP en SCRUM om systemen te ontwikkelen en BiSL, ASL en ITIL om diezelfde systemen vervolgens te beheren. De verbinding tussen die gescheiden werelden is min of meer bewust zo beperkt mogelijk gemaakt. Er wordt gesproken in de metafoor van een “slagboom” of een “sluis” om aan te geven dat de verbinding meestal dicht is en alleen in bijzondere omstandigheden kan worden geopend – en dan nog slechts heel tijdelijk. Die scheiding is ook te merken aan de tools en technieken die worden ingezet om te helpen de processen uit te voeren – iets waarover ik al eens eerder heb geblogd.

In de rol van archITect ervaar je de effecten van die scheiding in twee digitale werelden. Het slechten van de muur tussen ontwikkeling en beheer is voor een archITect een uitdaging die vooral veel tijd en energie kost en voor de overkoepelende organisatie betrekkelijk weinig rendement oplevert. En dat heeft er alles mee te maken dat deze organisatie bewust of onbewust een conflict heeft ingebouwd door belangen te scheiden langs de lijn «vernieuwen» tegenover «in stand houden». Het valt betrekkelijk eenvoudig in te zien dat deze belangentegenstelling geen reflectie is van de belangen van de gebruikers waarvoor de digitale wereld is gecreëerd. Immers, die gebruikers willen vooral graag dat hun digitale wereld geleidelijk met hen meegroeit. Die gebruikers hebben vooral behoefte aan een permanente evolutie – iets waarvan we trouwens sinds het werk vanCharles Walcott vermoeden dat het gedurende lange periodes betrekkelijk langzaam verloopt en tijdens korte periodes plotseling heel snel kan verlopen. Herkenbaar?

Dus mijn revolutionaire archITectuuridee van vandaag is betrekkelijk simpel: laat je eens inspireren door het concept van een permanente digitale evolutie om archITectuur en archITectuurprocessen vorm te geven. Verfrissend!

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

Moord met voorbedachten rade

Het jaar 2009 is in de archITectuurblogosfeer met vuurwerk begonnen. Anne Thomas Manes van de Burton Group heeft veel stof doen opwaaien met haar posting “SOA is Dead”. Zelfs de Automatiseringgids wijdt er een artikel aan. Sommige reacties waren instemmend, zoals die van David Linthicum, die in zijn podcast droogjes constateerde dat SOA al lang dood was en Anne Thomas alleen maar het tijdstip van overlijden heeft bepaald op 1 januari 2009. Anderen waren minder positief. De leukste titel was wat mij betreft SOA: Wanted Dead or Alive.

Het debat

Ik dacht Anne Thomas te kennen als een bedachtzame, vrij ingetogen persoonlijkheid. En ze is bepaald niet dom. Dat zij zoveel gedoe kon veroorzaken deed mij in eerste instantie de wenkbrauwen fronsen. Waar was de nuance gebleven? Een citaat:

"It's time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. 'SOA' has become a bad word. It must be removed from our vocabulary."

Niet zo gek dat mensen daarop geprikkeld reageren. Zeker de professionals die uit het SOA gedachtegoed hun inspiratie putten, dagelijks hun stinkende best doen en de laatste jaren aanzienlijke vooruitgang weten te boeken – met hier en daar zelfs spectaculaire resultaten.

Als je de hele posting leest en probeert te begrijpen wat Manes werkelijk bedoelt, dan wordt het beeld wat subtieler.

"SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”."

Anne Thomas probeert dus juist vooruit te kijken naar de nieuwe trends. Al die trends bouwen voort op de principes van een service-geörienteerde architectuur. In die zin is SOA springlevend. Het verkoopt alleen niet meer als doel op zich, het is – hè hè, eindelijk! – een middel geworden om andere doelen, samen te vatten onder het motto 'beter, sneller én goedkoper', te bereiken.

Mijn idee

Ik ben een verklaard aanhanger van de stelling “een SOA kun je niet kopen”. In een eerdere posting heb ik mij al eens afkeurend uitgelaten over “vendor driven architecture”. Architectuur kan naar mijn mening pas duurzaam succesvol zijn als het hecht verbonden is met de strategie en de cultuur van de (extended) enterprise. Daarmee is iedere organisatie in zekere zin uniek. Het is dus goed dat leveranciers stoppen met het verkopen off-the-shelf 'architectuur'. Dat kan alleen maar teleurstellingen opleveren.

Het adopteren van SOA is een langjarig traject. Uit eigen ervaring weet ik dat een transitietijd van 7 jaar haalbaar is, in een niet al te complexe omgeving met goede en standvastige sturing. Dat was wel in een tijd dat er nog veel minder ervaring met het toepassen van SOA was en er nog veel minder technologische hulpmiddelen beschikbaar waren. De Enterprise Service Bus was nog niet eens beschreven. Wellicht dat het anno 2009 dus een tandje sneller zou kunnen. Aan de andere kant, als ik er nu op terugkijk, dan waren de lastigste veranderingen organisatorisch van aard. Het opbouwen en vasthouden van het vertrouwen dat het “in de toekomst” – na de nodige bloed, zweet en tranen – echt veel beter kan en zal gaan, is begrijpelijkerwijs moeilijk. Het vergt het soort missiewerk dat onvermijdelijk met een gezonde portie scepsis wordt ontvangen. Een sterke visie en een krachtig doorzettingsvermogen zijn even onmisbaar als de nodige tegenslagen voorspelbaar zijn. En veel meer praktisch advies dan de tegeltjeswijsheid dat het vieren van successen kan helpen om de moed erin te houden is er jammer genoeg niet voorhanden.

Waar het om draait is dat SOA een architectuurstijl is die daadwerkelijk kan helpen bij het beter beheersen van complexiteit in moderne, IT-intensieve organisaties. Ik ben nog steeds van mening dat het op de weg van de verklaarde tegenstanders van SOA ligt om een reëel alternatief te schetsen. Terug naar vroeger is daarbij wat mij betreft geen serieuze optie. Want de ervaringen uit het verleden hebben toch afdoende aangetoond dat de kachelpijparchitectuur, de archipelarchitectuur en de data-geörienteerde architectuur uiteindelijk tot een haast onontwarbare kluwen aan onderlinge afhankelijkheden leiden – met alle verstorende en verstarrende effecten van dien.

Een complexe enterprise architectuur is complex om te besturen – en in de overgangsfase van de bestaande naar de nieuwe architectuur geldt dit des te sterker. Daarbij moet echter bedacht worden dat SOA de beste kans is om het enterprise niveau überhaupt bestuurbaar te maken. Het falen van SOA initiatieven is imho vaak een indicatie van een gebrekkige besturing – en veel minder van gebrekkige technologie. Architecten hebben primair de taak om het ontwerp van een SOA in goede banen te leiden – moeilijk zat. Het kan echter geen kwaad om ook vanuit de verantwoordelijkheid van de architect de bestuurders op hun cruciale rol te wijzen en ze waar mogelijk met raad en daad bij te staan bij het invullen van hun verantwoordelijkheid.

Blijf dus ook in 2009 werken aan het flexibiliseren en rationaliseren van uw business- en IT-landschap en blijf vooral ook pleiten voor een slimmere besturing van de evolutie van die landschappen.

De leveranciers zullen de boodschap van Anne Thomas vast vertalen in een nieuwe stortvloed van overgehypte instant-oplossingen. Laten we hopen dat daar nou eens met de gepaste scepsis naar gekeken wordt...  

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

Mijn voorspellingen voor 2009

Het is weer de tijd van het jaar om stil te staan bij de gebeurtenissen van het afgelopen jaar en vooruit te kijken naar de ontwikkelingen die op stapel staan. Vijf onorthodoxe voorspellingen om u gedegen voor te bereiden op hetgeen dat 2009 voor u in petto zal hebben.

Voorspelling 1: Google komt in 2009 met een eigen web-OS

Google heeft tot nu toe de financiële crisis voorbeeldig doorstaan. De populariteit van “gratis” is onverminderd hoog en er is vooralsnog geen reden om te twijfelen aan de toekomstbestendigheid van dit onorthodoxe business model. En mocht de nood aan de man komen, dan zijn er waarschijnlijk meer dan voldoende particulieren te vinden die bereid zijn om microbetalingen te doen voor waardevolle diensten.

Twee van de meest in het oog springende nieuwe diensten van Google in 2008 zijn Chrome – de browser die van de grond af aan opnieuw is ontworpen om als platform voor webapplicaties te kunnen dienen – en Android – het open source besturingssysteem voor smartphones. Wat zou er nou makkelijker zijn dan deze twee paden bij elkaar te brengen en een platform te maken voor webtops – slimme apparaten die het gemak van een telefoon combineren met de bedieningsmogelijkheden van een PC. En -last but not least- no Microsoft needed. De gemiddelde consument besteedt al een groot deel van zijn PC-tijd online, dus in een browser. Google heeft al een prima webgebaseerde vervanging voor de MS Office applicaties. Apple is vast niet te beroerd om iTunes op het nieuwe platform beschikbaar te stellen. En voor de overige applicaties komt er vast snel een Wine variant beschikbaar. Het is in elk geval goedkoper (vooralsnog gratis), hoogstwaarschijnlijk sneller (want geen legacy probleem) en in de beste Google tradities vast in tal van opzichten beter.

Voorspelling 2: Het web wordt in 2009 alweer opnieuw uitgevonden

Na het barsten van de internet bubble werd het web door velen doodverklaard. Geen droog brood mee te verdienen. Daar zou geen investeerder ooit meer intrappen. Hoe anders is het gelopen. Onder het wat pretentieloze motto “web 2.0” zijn tal van nieuwe initiatieven tot bloei gekomen. De consument is “prosument” geworden – hij consumeert niet alleen de informatie op het web, maar draag er ook actief aan bij. Amazon, Hyves, Youtube, Wikipedia, Marktplaats en Twitter zijn maar een paar van de namen die niet meer weg te denken zijn in de webwereld.

Al deze webdiensten zijn als eilanden in het universum van het internet ontwikkeld. De apartheid viert hoogtij. Als je gebruik maakt van Hyves dan kun je geen contact maken met iemand die op Facebook zit. LinkedIn en Plaxo zijn als telefoonnetwerken waar je alleen mensen kunt bellen die bij dezelfde maatschappij een abonnement hebben afgesloten. Maar ook Flickr en Picasa zijn gescheiden werelden. Wordpress en Blogger. Slideshare. En zo kan ik nog wel even doorgaan. En overal moet je weer een nieuw account aanmaken en overal moet je die gegevens bijhouden als er eens iets verandert.

Natuurlijk, er zijn al wat initiatieven om hier iets aan te doen. Peopleaggregator en Friendfeed bijvoorbeeld, of Shozu – speciaal voor de populaire iPhone. Op de keper beschouwd zijn dit niet veel meer dan goedbedoelde pogingen om verschillende sites “op de glasplaat” te integreren. Er zou zoveel meer en innovatiefs mogelijk zijn als we tot het inzicht zouden komen dat we de informatiebron en de applicatie radicaal van elkaar moeten scheiden. Als we in ons denken de gebruiker centraal zouden stellen in plaats van de provider. Beeld je eens een portaal in, dat je indeelt naar “gebruiksmomenten” – een tabje voor werk, een tabje voor familie, een tabje voor vrienden, een tabje voor golf, een tabje uitgaan, eentje voor vakantie en een tabje scuba duiken. En op elk tabje de relevante content – blogs, contacten, foto's, filmpjes, tweets, links – ongeacht uit welke bron ze afkomstig zijn. Collega's en vrienden waarmee je regelmatig golft staan broederlijk naast elkaar op de golfpagina, of zij hun gegevens nou op LinkedIn of op Myspace bijhouden. En mensen met wie je een keertje bent gaan skiën hoeven niet meteen toegang te krijgen tot alles wat je met je vrienden deelt. SOW. Het service oriented web. Houd die trend in de gaten.

Voorspelling 3: We blijven ook in 2009 vrolijk doordiscussiëren over de rol van architecten.

Als het laatste Landelijk Architectuur Congres iets heeft duidelijk gemaakt, dan is het wel dat er nog steeds enorm uiteenlopende interpretaties zijn van het begrip ArchITectuur, en de rol die er voor ArchITecten is weggelegd. De ene nestor verdedigt de stelling dat ArchITectuur alleen om beeldvorming gaat, liefst in de vorm van cartoons, en betitelt iedereen die met geformaliseerde modellen werkt als “engineer”. De andere keynote spreker beweert met evenveel stelligheid dat archITectuur uiteindelijk alleen om de “ilities” draait en stelt dat archITecten zich toch vooral niet met functionaliteit zouden moeten bemoeien. Nog weer anderen zijn in de loop van de afgelopen tien jaar afgehaakt en helemaal hun eigen gang gegaan.

Jammer toch, dat er in het wereldje nog niemand in staat is geweest om de verschillende meningen en belangen van al die verschillende professionals te verenigen. Iemand die het gemeenschappelijke belang van dat mooie vakgebied weet te vertegenwoordigen. En dat terwijl het overbruggen van tegenstellingen toch de core-business van archITecten zou moeten zijn...

Voorspelling 4: De opkomst van Infofluence

De verkiezing van Obama als the next POTUS is om meer dan één reden opmerkelijk geweest. Als geen ander is hij in staat geweest om de potentie van het web als communicatieplatform in te zetten in zijn campagne. Vanzelfsprekend wordt er op de campagnebureaus van de Nederlandse partijen nagedacht over de lessen die hieruit voor de volgende verkiezingen te trekken zijn. Maar ook bedrijven zouden er goed aan doen om eens stil te staan bij de verborgen potentie van hun webpresence.

Transparantie is een ingrijpende ontwikkeling die al langer gaande is en ook in 2009 verder om zich heen zal grijpen. Zie bijvoorbeeld mijn post over de toekomst van de assurantietussenpersonen. Transparantie heeft veel goede kanten. Het ene ziekenhuis is het ander niet. Als alle patiënten zouden weten hoe de prestaties van de verschillende ziekenhuizen verschillen, dan zou dit misschien pijnlijk zijn voor ziekenhuizen die niet zo best presteren, maar uiteindelijk zal het de kwaliteit van de ziekenzorg verbeteren. Een open markt is gebaat bij transparantie omdat consumenten dan een beter onderbouwde keuze kunnen maken.

Transparantie is typisch zo'n voorbeeld van een bedreiging die je als kans zou moeten zien. Zou de directie van de IJsselmeerziekenhuizen niet in een eerder stadium gedwongen zijn geweest om in te grijpen als algemeen bekend zou zijn geweest wat de direct betrokkenen al lang wisten? Zou het ziekenhuis er uiteindelijk niet bij gebaat zijn als er tijdig bijgestuurd zou zijn in plaats van toen het al te laat was? Zou het voor het vertrouwen van de patiënten in het ziekenhuis niet veel beter zijn geweest als het ziekenhuis openlijk had gecommuniceerd over de problemen én over de maatregelen die het had genomen om de problemen de baas te worden? Was het ziekenhuis niet te redden geweest als het bestuur het vertrouwen in het ziekenhuis niet had ondergraven?

Natuurlijk is het allemaal niet zo simpel. Ieder bedrijf dat zich kwetsbaar opstelt staat een stortvloed van acties van concurrenten en andere tegenstanders te wachten. Het is ook bepaald tegennatuurlijk om de vuile was buiten te hangen.

Het mooie van Obama is nou dat hij laat zien dat je ook in een smerige campagne informatie- en communicatietechnieken kunt inzetten die vertrouwen wekken. Dat consumenten niet zo dom en kortzichtig zijn als we soms wel eens geneigd zijn te denken. En dat je er goed aan kunt doen om het publiek bij het oplossen van je problemen te betrekken. En dat zouden bedrijven zich eens ter harte moeten nemen. Marketing is anno 2009 al lang geen eenrichtingsverkeer meer. Het gaat er steeds meer om klanten positief te beïnvloeden door hen op het juiste moment en via het juiste kanaal van de juiste informatie te voorzien. En natuurlijk om onjuiste informatie van concurrenten op het juiste moment en via het juiste kanaal te ontmaskeren.

Moet ik nog voorspellen dat bedrijven die beter zijn in deze infofluence in 2009 succesvoller zullen blijken dan de in zichzelf gekeerde concurrenten? En dat bedrijven die zich dit realiseren hard zullen gaan werken aan hun infofluency?

Voorspelling 5: Het netwerk is de professional

Je hebt geen glazen bol nodig om te voorspellen dat het klimaat voor IT-investeringen in 2009 ernstig zal bekoelen. Ook ik ga uit van de nodige ontslaggolven en faillissementen. En buiten de voorspelbare krantenkoppen om zullen ook de tienduizenden ZZP-ers het het komend lastig krijgen. Het mooie is dat er hierdoor een enorm potentieel vrijkomt voor reflectie en innovatie. Maak je maar op voor een golf aan nieuwe boeken, blogs en andere bewijzen van persoonlijke expertise. Oude contacten hervinden elkaar op de sociale netwerksites. Nieuwe groepen zullen op deze sites als paddenstoelen uit de grond schieten. En misschien, heel misschien komen er al de eerste tekenen van doelgroepnetwerksites.

Hoe dan ook, de trend van personal branding zal ook in Nederland meer en meer voelbaar worden. Ook een voornaam instituut als de Open Universiteit heeft trend al opgepikt. Het draait om zelfbewuste professionals, die zichzelf niet profileren als medewerker van een bedrijf, maar zichzelf onderscheiden als zelfstandige krachten met een eigen, unieke expertise. Op dit moment in hun loopbaan wenden zij deze expertise aan – en bouwen deze verder uit – in een bepaalde rol in een organisatie. Kijk maar naar de groeiende hoeveelheid boeken die hierover wordt gepubliceerd. Het is in 1997 begonnen met een artikel van de befaamde management goeroe Tom Peters. In 1999 publiceerde hij het boek “The Brand You 50 – Or: Fifty Ways to Transform Yourself from an 'Employee' into a Brand That Shouts Distinction, Commitment, and Passion!”.

Vergezocht en on-Nederlands? De tijd zal het leren.

Tenslotte

In één aspect zal 2009 hetzelfde zijn als alle voorgaande jaren. De meeste voorspellingen zullen weer geen rekening houden met de traagheid van de veranderingen. Er verandert namelijk helemaal niet zo veel in één jaar. Voor je het weet zit je alweer aan de oliebollen na te denken over de gebeurtenissen van 2009 en de voorspellingen voor 2010.

Ik sluit 2008 graag af met de wens dat 2009 hoe dan ook, ondanks alle sombere vooruitzichten, toch een bruisend en inspirerend jaar mag worden. 

Bij Benadering Exact

'Als je niet exact kunt specificeren wat je wilt hebben, dan moet je ook niet verbaasd zijn als je iets anders krijgt dan je had verwacht.' Common sense? Of valt hier toch nog wel wat op af te dingen?

De paradox

Wanneer vinden mensen de uitvoering van een muziekstuk “mooi”? Een vreemde vraag misschien. Toch geeft het wetenschappers de kans om iets subjectiefs als “smaak” te objectiveren. Muziek leent zich immers prima om softwarematig te produceren, waarbij de effecten van kleine variaties onderzocht kunnen worden. Wat blijkt? Als een muziekstuk exact volgens de specificaties wordt uitgevoerd – iedere noot exact op de juiste toonhoogte en exact zo lang als in de partituur staat voorgeschreven – dan vinden menselijke luisteraars dat niet mooi maar mechanisch, klinisch en kil. Het moet natuurlijk ook niet hoorbaar vals of uit het ritme zijn. Op de schaal van mooi zit ergens tussen 'perfect goed' en 'waarneembaar fout' blijkbaar een heel subtiel optimum.

Sommige architecten uit de fysieke wereld zijn zich bewust van dit soort kwaliteiten. Christopher Alexander – de grondlegger van de “design patterns” – is daar een uitgesproken voorbeeld van. Hij noemt het in zijn boek “The Timeless Way of Building” de “quality without a name”. Recht en vierkant zijn doods, voor “een greater sense of life” moet je op zoek naar een “harmony” met de omgeving. En wat is er in nou de natuur volgens exacte, mathematische precisie gevormd? Alexander zoekt ook in gebouwen naar het organische, net niet geometrisch precieze vormen die zich ook vooral niet identiek herhalen. Hij gebruikt in zijn zoektocht naar de “quality without a name” natuurlijke materialen die vooral moeten verweren en hij zou waarschijnlijk gruwen van het idee van een rijtje huizen die stuk voor stuk exact gelijk gebouwd zijn.

Het wereldberoemde kaartje van het metronet van Londen is een ander voorbeeld. Deze “tube map” is een schematische voorstelling van het netwerk met een interessante evolutie. De eerste kaarten waren zoveel als mogelijk geografisch correct, toonden voor de oriëntatie het bovengrondse wegennet en gaven tal van andere herkenningspunten. Harry Beck, een medewerker van de ondergrondse, maakte in 1933 in zijn vrije tijd een alternatief, drastisch versimpeld kaartje. Daarbij liet hij zich inspireren op de toenmalige diagrammen van elektronische circuits. De metrolijnen liepen op deze kaart alleen nog horizontaal, verticaal of diagonaal; en de locaties van de stations kwamen nog maar ongeveer overeen met de geografische locaties. Zelfs de rivier de Thames ontkwam niet aan zijn drang om te abstraheren. Deze topologische kaart werd onverwacht een groot succes. Eindelijk begrepen de gewone reizigers de metrokaart en konden ze met hulp van deze kaart hun weg vinden – of ze nu echte Londenaren waren, forensen, bezoekers of buitenlandse touristen.

Beck heeft de kaart nog tot 1960 verder geperfectioneerd. Sindsdien is de kaart niet meer wezenlijk aangepast en is de systematiek in vele andere wereldsteden gekopieerd.

De les

In de IT kom ik het inzicht dat de drang naar precisie niet altijd tot begrip leidt, nog betrekkelijk weinig tegen. In tegendeel. Alles moet bij voorkeur zo exact mogelijk gespecificeerd worden en natuurlijk ook exact volgens specificatie worden uitgevoerd – zeker als het werk wordt aan- of uitbesteed. In de specificaties wordt vooral erg veel aandacht besteed aan uitzonderingen en details, terwijl de grote lijnen maar al te gemakkelijk uit het oog worden verloren. En het klinkt erg herkenbaar in de oren dat het van de inzet van een gedreven individu afhankelijk is of er van een complexe enteprise architectuur ook een eenvoudig toegankelijk overzichtskaartje beschikbaar is.

Sommige archITecten lijken dit wel begrepen te hebben. Zij hebben ervaren dat al te technische plaatjes een lage communicatieve waarde hebben. Zij begrijpen dat de specificaties die inzichtelijk zijn voor specialisten niet noodzakelijkerwijs door het grote publiek begrepen worden. Ze kennen de waarde van UML en ArchiMate, maar zijn ook in staat om dit te vertalen naar een visualisatie die begrijpelijk is voor een breder publiek. En hier en daar hoor je ook wel eens een geluid dat gebruikers het juist wel op prijs stellen als de user interface net niet 100% logisch in elkaar steekt of als niet alle pagina's strikt dezelfde designprincipes volgen.

Natuurlijk ligt daarbij al snel het gevaar van overdrijving op de loer – dan werkt het averechts. Denk maar aan een overbekende tekstverwerker waar je de functie “paginaopmaak” om raadselachtige redenen niet in het menu “Opmaak” maar “Bestand” terugvindt (onder het menu-item “pagina-instelling” op het tabblad “Indeling” om precies te zijn) en je de “Koptekst en voettekst” niet moet instellen bij de pagina, maar in het menu “Beeld”. Een beetje inconsistentie is juist goed, maar het mag eigenlijk nauwelijks waarneembaar zijn. Een lastige les.

Ik ben trouwens erg benieuwd wanneer Apple (wie anders?) gaat komen met een organische versie van zijn operating systeem. De windows net niet vierkant, de listboxen een klein beetje scheef, de radiobuttons net niet rond – en vooral niet allemaal precies even groot. Of misschien doen ze dat stiekum al, maar hebben we het gewoon niet bewust opgemerkt?

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

Adieu Bonusprovisie

De bonusprovisie voor assurantietussenpersonen wordt met ingang van volgend jaar afgeschaft. Zoveel is nu wel zeker. Bos heeft gesproken, er is hier en daar nog wat plichtmatig verzet, maar er lijkt ook veel berusting. Het zat er ook al zo lang aan te komen. Dan is op een zeker moment de tijd aangebroken om de spreekwoordelijke wonden te likken en weer vooruit te kijken.

Er wordt in de branche al volop geëxperimenteerd met alternatieve beloningsmodellen voor intermediairs. Het is op dit moment nog te vroeg om te bepalen wat goed aanslaat en wat niet. Wellicht kunnen we in de tussentijd op basis van een gezond historisch besef toch alvast wat lessen trekken...

Historische lessen

Het is niet voor de eerste keer dat een bedrijfstak onder druk van de economische en maatschappelijke ontwikkelingen drastisch hervormd is. Of het nu gaat om de traditionele kleermaker, de smid, de koetsier of de boer, het vak is niet alleen drastisch veranderd, maar de productiviteit is ook zodanig toegenomen dat er met minder mensen meer geproduceerd kan worden.

Als we kijken naar de verzekeringsintermediairs, dan dringt de vergelijking zich op met de oorspronkelijke positie van de groenteboer. Niet dat er ook maar enige overeenkomst is tussen groenten en polissen, maar vanuit de positie in de waardeketen. Groenteboeren zijn typische retailers die zich bezighouden met de distributie en vooral de verkoop van groenten die door anderen geproduceerd zijn. Lange tijd hebben zij met deze nering een solide positie gehad in de winkelstraten van Nederland. Totdat de supermarkten opkwamen. De formule van één plek voor al je dagelijkse boodschappen sloeg aan. En hoe zeer de groenteboeren zich ook probeerden te profileren als deskundige adviseurs van kwalitatief hoogwaardige producten, welke aanvullende diensten ze ook hebben bedacht, velen hebben on de loop van de tijd het onderspit gedolven. De consument kiest massaal voor goedkoop en gemakkelijk in plaats van deskundig en vertrouwd.

Als we dit op de verzekeringsbranche betrekken, dan zijn zou de les kunnen zijn dat er betrekkelijk weinig toekomst zit in “verkoop en distributie” – er wordt, ook vanwege de snelle technologische ontwikkelingen, simpelweg te weinig economische waarde gecreëerd om de hele bedrijfstak in stand te kunnen houden. Niet voor niets wordt er hard gewerkt aan alternatieve businessmodellen, waarbij intermediaire partijen juist moeten gaan kapitaliseren op het deskundige advies dat zij kunnen bieden. Deze partijen mogen zich gelukkig prijzen met het besluit van minister Bos. Eerlijke adviseurs hebben immers alle belang bij kostentransparantie en het tegengaan van adviespraktijken waarbij de adviseur geprikkeld wordt om adviezen te geven die mede in zijn eigen belang zijn. Dat kan alleen maar goed werken als de adviseur zelf geen onderdeel van de waardeketen is. Hij adviseert één partij in de keten en hoeft dus ook maar één belang te dienen. Vergelijk het maar met de advocatuur. De advocaat is zelf geen partij in het proces, maar staat één van de partijen bij om hun – en alleen hun – belangen te verdedigen. Financiële coaching zou dan ook best een levensvatbaar model kunnen blijken om de dienstverlening in de bedrijfstak aan de eisen van de tijd aan te passen.

Een andere les zou kunnen zijn dat voor de pure “verkoop en distributie” alleen díe partijen een reële overlevingskans hebben die een hoge productiviteit bieden – dus lage kosten – en die het de consument makkelijk weten te maken. Dat zullen er naar alle waarschijnlijkheid geen 3000 onafhankelijke kleine ondernemers zijn, maar een klein aantal ketens die slim gebruik weten te maken van hun schaalvoordeel maken wel degelijk een kans. De vraag die zich hier opdringt is of een supermarkt die polissen van veel verschillende verzekeraars aanbiedt wel voldoende potentie heeft. In de digitale wereld zijn sinds enige jaren supermarkten met beleggingsfondsen van veel verschillende aanbieders succesvol. Het is een markt van lage marges en hoge volumes die niettemin lucratief is. Dit zou een goede indicatie kunnen zijn dat er ook ruimte is voor een soortgelijke polissupermarkt op internet.

Voor de ondernemers onder u: zowel www.polissuper.nl als www.polissupermarkt.nl zijn op het moment van schrijven nog beschikbaar. Dat biedt u een mooie kans om deze markt te betreden. Ik vertrouw er natuurlijk op dat u uw adviseur in deze op passende wijze voor zijn werkzaamheden zult belonen.

Of er ook in de winkelstraten ruimte is voor zo'n polissuper lijkt mij minder waarschijnlijk. Zo'n specialist in verzekeren zou je toch eerder moeten vergelijken met de traditionele groenteboer of kruidenier dan met een moderne supermarkt. Een echte financiële supermarkt doet niet alleen in verzekeren, maar ook in sparen, beleggen, lenen, hypotheken en misschien zelfs wel belastingen. Alles onder één dak. One stop shopping. U vindt er een interactieve tafel die u helpt om snel inzicht te krijgen in de beschikbare producten en ze desgewenst ter plekke af te sluiten. En als u er toch nog graag een professioneel advies wilt hebben van een financiële consulent, dan kan dat natuurlijk. Maar dan bent u alvast goed voorbereid en kunt u in een consult van – zeg – tien minuten tot zaken komen. Wie zou er nou geen 25 euro over hebben gehad voor een tijdig advies dat het extra rendement van sparen op een IJslandse bank niet opweegt tegen het extra risico en dat overigens het spreiden van spaargeld over meerdere banken nog altijd de beste risicobeperkende maatregel is?

Trouwens, ook www.geldsupermarkt.nl en www.geldgrutter.nl zijn nog vrij. Nog meer ideeën? GeldRijk, GeldRuimte, GeldBoetiek, deGeldZaak, Geldenier, Poenshop; er zijn nog mogelijkheden genoeg. U kunt trouwens ook denken aan iets fantasievollers als www.pKunia.nl, www.rix.nl of www.fleurio.nl.

Voer voor archITecten

Voor architecten leveren beide concepten een machtig mooie uitdaging op. Het is verre van makkelijk om financiële producten zodanig te classificeren dat het makkelijk wordt om ze goed met elkaar te vergelijken. Een klassieke informatieanalyse werkt maar beperkt – het is in een snel veranderende werkelijkheid welhaast onmogelijk om objectieve vergelijkingscriteria aan te leggen, op een overzichtelijke manier te classificeren en om daarbij tenminste enigszins volledig te zijn. Analyse van complexe financiële producten is een wicked problem. Niet voor niets hebben intermediairs er al jaren op gehamerd dat het vergelijken van complexe financiële producten vakwerk is en dat er simpelweg niet zoiets bestaat als een recept dat automatisch tot een optimaal advies leidt – zo min als er een magische formule zou bestaan die alleen maar muzikale tophits oplevert of kaskrakende films.

In de wereld van Web2.0 wenden we ons in dit soort gevallen tot het publiek. We proberen de intelligentie van de massa aan te wenden om goede adviezen te geven. Een bedrijf als Amazon heeft dit in hoge mate geperfectioneerd. Zij nodigen hun klanten uit om de ervaringen met hun producten te delen en gebruiken ook het surfgedrag van de bezoekers van hun site om adviezen op te baseren in de trant van “73% van de mensen die dit artikel hebben bekeken was ook geïnteresseerd in dat artikel”, of “27% van de kopers van dit artikel kocht ook dat artikel”. Expliciete en impliciete feedback blijken erg krachtige adviesmethodes te zijn. Dat geldt ook voor feed-back op feed-back. De melding “87% van de stemmers vond deze opmerking nuttig” betekent een hogere rangorde waardoor de opmerking ook sneller wordt getoond. Je kunt zelfs traceren hoeveel bijdragen iemand heeft geleverd en wat zijn gemiddelde score is: “Helpful votes received on all contributions: 86% (1,592 of 1,869).

Om zo'n adviesmechanisme ook bij financiële producten te laten werken, is profiling van cruciaal belang. Stel dat je een hypotheek zoekt. Wat heb je dan aan de informatie dat 45% het afgelopen jaar heeft gekozen voor een spaarhypotheek en dat 17% heeft gekozen voor de Rabobank? Het antwoord is: betrekkelijk weinig. Maar als je zou weten dat 21% van de tweeverdieners zonder kinderen met een gezamenlijk inkomen van tussen de 40.000 en 60.000 euro en een hypotheekbedrag van tussen de 225.000 en 275.000 euro kiest voor de VoordeelPlus hypotheek van de Postbank en 16% voor de Bankspaar hypotheek van Florius, dat wordt de informatie al een stuk geloofwaardiger – en dus nuttiger. Met andere woorden: het gedrag en de mening van andere mensen zijn relevanter naarmate ze meer voldoen aan je eigen profiel.

De echte kans c.q uitdaging ligt toch in een hoog-interactieve toepassing die op een intuïtieve wijze multi-dimensionale analyses toestaat. De Motion Charts in Google Analytics laten zien hoe je tegenwoordig met geavanceerde visualisatietechnieken inzicht in complexe dataverzamelingen kunt bieden. Als je dit op zo'n hypermoderne interactieve tafel zou kunnen presenteren, dan gaat er een wereld aan mogelijkheden open om complexe producten in een passende analytische ruimte te projecteren, met elkaar te vergelijken en af te sluiten. Of om op een simpele, visuele manier zelf een schade te melden, bij voorkeur vergezeld van digitale foto's of een filmpje voor eventuele tele-expertise. Of om op en speelse manier het huizenaanbod langs verschillende dimensies te bekijken. Met dat soort innovatieve diensten heeft zo'n financiële supermarkt ook daadwerkelijk toegevoegde waarde.

Vergezocht? De toekomst zal het leren. Maar als architect ga ík me er in elk geval verder in verdiepen. En als ik ondernemer in de financiële dienstverlening zou zijn, dan zou ik het ook wel weten...

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

De softwarerechercheur

Testen van software is de laatste weken een populair onderwerp. Nadat onder andere Chris Verhoef en Daan Kalmeijer hun licht over de problematiek hebben laten schijnen kan ik natuurlijk niet achterblijven. Mijn oplossing is even simpel als cool…

De Kwestie

Testen is niet sexy. Hoe je het ook wendt of keert, het is maar voor weinig mensen duurzaam inspirerend om hun dagen te slijten met het vastleggen van “bevindingen”. Er zijn ongetwijfeld voorbeelden van toegewijde testers die van het zo grondig mogelijk doortesten van het werk van anderen hun levensvervulling hebben gemaakt. Mensen met een passie voor het testen van software. Jammer genoeg zijn dit er te weinig om te voorkomen dat er vaak veel, erg veel te verbeteren valt aan de kwaliteit van software – in het bijzonder als deze nog maar kort geleden gereleased is.

Er is in de loop van de jaren van alles aan gedaan om dit te verbeteren. Bijvoorbeeld door het werk van testers te professionaliseren via methodieken als TMap. Of door het testen vroeger in het ontwikkelproces een rol te laten spelen – test-driven development of zelfs test-driven design. Er is ook veel geïnvesteerd in test-tooling, om de productiviteit van testers te kunnen verhogen. Het resultaat? Er wordt meer getest dan ooit, er worden meer “bevindingen” gelogd dan ooit en de kwaliteit van de software is…? Tsja, daar is dus geen objectieve maatstaf voor. Misschien is die kwaliteit wel beter dan ooit, maar ervaren we dat op de een of andere manier anders.

Er zijn verschillende auteurs die erop hebben gewezen dat er wel degelijk voorbeelden van goede, robuuste software zijn. En dan gaat het niet eens in het bijzonder over de software van NASA – waarbij de gevolgen van een programmeerfoutje wel erg pijnlijk kunnen zijn – maar bijvoorbeeld over iets als Google Earth. Welke software engineer droomt er niet van om zoiets monumentaals op z’n naam te hebben? En als je nagaat hoe foutloos en snel dat werkt, zelfs terwijl het wereldwijd door misschien wel honderden miljoenen gebruikers wordt gebruikt, dan kun je alleen maar veel respect hebben voor de makers.

Steve Yegge werkt voor Google, en heeft in zijn beroemde artikel “Business Requirements are Bullshit” al eens onthuld wat het geheim is achter het succes van de software van Google: «ONLY BUILD STUFF FOR YOURSELF». Gewoon de beste mensen inhuren en ze de opdracht geven om dingen te bouwen die ze zelf leuk zouden vinden om te gebruiken. Just for Fun. Dat werkt blijkbaar. Maar ja. Wie vindt het nou “fun” om een magazijnvoorraadsysteem van een EDI-koppeling te voorzien? Of om een FTP-client te porten van WinXP naar Vista? Of om de belastingdiskette (ahum) aan te passen aan alweer gewijzigde belastingregels?

Kalmeijer snijdt dit aspect ook aan. Was het testen van businesssoftware maar net zo leuk als het is om een game te testen… Yegge heeft slecht nieuws voor de gedroomde gametesters: de ontwikkelaars zelf vinden het veel te leuk om hun eigen game te testen – ze laten dat echt niet aan een goedbetaalde tester over.

Maar als het dan onvermijdelijk is dat er “saaie” software gemaakt moet worden en het geen fun is om die te testen, hoe zouden we dan toch de kwaliteit van de software een boost kunnen geven?

Kunnen we het echt niet leuker maken?

Hoezo zou het niet leuk kunnen zijn om saaie software beter te maken? Ik ken een heleboel mensen die dol zijn op het oplossen van raadsels en cryptogrammen. Het schijnt dat Sudoku’s enorm populair zijn. House trekt wereldwijd miljoenen kijkers met zijn zoektochten naar medische mysteries. Sinds CSI en Numbers zijn er massa’s schoolkinderen die dromen van een carrière bij de misdaadbestrijding. En geef toe: het moet een kick zijn om met het slimme gebruik allerhande bewijsmateriaal een dader te vinden.

Waarom zou het dan niet leuk kunnen zijn om de oorzaak van een softwareprobleem te traceren? Dat is toch ook werk voor een soort detective? Verzamelen van bewijs, andere daders uitsluiten en de echte dader liefst op heterdaad betrappen?

Als we dan het werk van ‘testers’ eens zo zouden organiseren dat ze niet afgerekend zouden worden op het aantal “bevindingen” dat ze vastleggen, maar het aantal oorzaken van problemen die ze hebben blootgelegd? Dat ze daarbij ook de tools krijgen om sporenonderzoek te kunnen doen, om verdachten te kunnen ondervragen en om bewakingsbeelden te kunnen opnemen? Dat ze, kortom, een echte softwarerechercheur zouden worden? En dat de beste rechercheurs kunnen promoveren naar een heus SWAT-team?

Hmmm, dat zou wel eens kunnen werken. Bug hunting zou best eens cool kunnen worden. Als we met z’n allen nou eens serieus werk zouden maken van test-requirements en testware en een succesvolle softwarerechercheur ook navenant zouden belonen, dan heb ik er alle vertrouwen in dat het goed gaat komen met die softwarekwaliteit.

Nu moet er alleen nog iemand een script bedenken voor de volgende succesvolle tv-serie: the Bug Hunter. Een kerncentrale redden van een melt-down, voorkomen dat een ruimtevaartmissie op een ramp uitloopt, op het nippertje voorkomen dat de wereld ten onder gaat omdat het interbancaire geldverkeer niet meer werkt, een volkomen vastgelopen luchthaven weer op gang helpen, het lek in de CIA-systemen dichten en zo kan ik er nog wel meer bedenken. Wie tipt Hollywood?

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

Grensoverstijgend denken

De wereld is vol grenzen. Grenzen tussen landen, provincies en gemeentes; maar ook grenzen tussen afdelingen, divisies, bedrijven; grenzen tussen de sociale ruimte, de digitale ruimte en de fysieke ruimte; grenzen tussen portalen, werkstroombesturing, integratieservices en transactieverwerkende systemen en ga zo maar door. Er zijn mensen die het best gedijen binnen een duidelijk afgebakend verantwoordelijkheidsgebied. Grenzen scheppen immers duidelijkheid. Je hebt collega's en concurrenten; allochtonen en autochtonen; software en hardware. Er zijn ook mensen die niet zo in tegenstellingen denken. Mensen die vooral geïnteresseerd zijn in zaken die een afgebakend probleemgebied overstijgen. Mensen die van nature zien dat ook simpele problemen vaak meerdere facetten hebben, waardoor het soms tergend ingewikkeld is om een werkbare oplossing te bedenken – laat staan te realiseren – en daar van kunnen genieten. In principe zijn ze in een organisatie allebei even waardevol – ze vullen elkaar prima aan. Maar je kunt het ook overdrijven...

Teveel van het goede

Denken in hokjes wordt ons met de paplepel ingegoten. Op school krijg je verschillende vakken – je bent misschien goed in taal, maar niet zo goed in rekenen – en hoe verder je onderwijscarrière zich ontwikkelt, hoe meer je geleid wordt naar een specialistische discipline. En kies je voor het één, dan sluit dat welhaast automatisch al het andere uit. Daar komt bij dat specialisten maatschappelijk meestal hoger worden gewaardeerd dan generalisten – en daar is het onderwijs dan ook logischerwijs op gericht.

Niet iedereen is het met die benadering overigens eens. Bijvoorbeeld in de geneeskunde woedt – mede aangewakkerd door het succes van sommige 'alternatieve', Oosterse behandelwijzen – al decennia een debat over thema's als “holistische diagnose” of “integrale geneeskunde”. Er wordt dan bijvoorbeeld gepleit om bij de diagnose van een patiënt het lichaam meer als een eenheid in interactie met zijn omgeving te zien. Bij een “ziekte” zou er eerder gedacht moeten worden in termen van een verstoorde balans, dan van een specifiek orgaan dat niet optimaal functioneert. Dat is bijvoorbeeld ook de grondgedachte van de Ayurveda, “het enige niet-allopathische [1] geneeskunde systeem [...] dat door de Wereld Gezondheid Organisatie als een volledig geaccepteerd gezondheidssysteem erkend [is]” [2]. Het gaat in dit systeem niet zozeer om het “bestrijden van symptomen”, maar juist om het “genezen” en “voorkomen” van ziekten. Dat dit soort denken inmiddels in brede lagen van de westerse bevolking op een warme belangstelling kan rekenen blijkt bijvoorbeeld ook uit het succes van een TV-serie als House – de laatste 'allopathische' hoop voor patiënten die door reguliere artsen niet te helpen zijn.

In onderwijskundige kringen is een vergelijkbaar thema aan de orde. Er wordt hier al jarenlang gediscussieerd over het thema “inclusief denken”. De term dateert al uit 1966 [3], maar het gedachtengoed leeft nog steeds. Er is tegenwoordig zelfs een weblog dat zo heet. Inclusief denken gaat in zekere zin ook over het over grenzen heen durven denken. Niet alleen je individuele belangen nastreven, of die van de groep waartoe je behoort, maar juist ook van de ander. Niet antagonistisch, maar consensualistisch. Geen concurrentie, maar samenwerking.

Ik ben geneigd om het grensoverstijgend denken als een kernkwaliteit van archITecten te beschouwen. Of je het nu “integrerend”, “holistisch”, “inclusief” of “consensualistisch” noemt, het gaat in alle gevallen om het overbruggen van – al dan niet schijnbare – tegenstellingen, om het verder denken dan de eigen voordeur en om het verbanden leggen die anderen niet zo snel zien. Uit de wetenschap is bekend dat er veel doorbraken zijn bereikt door kennis en technieken uit een discipline in een andere discipline toe te passen. Dat zou op z'n minst te denken moeten geven. Grensoverstijgende denkers zouden op hun eigen werkterrein misschien wel heel goed in staat kunnen zijn om doorbraken tot stand te brengen.

Er is ook een natuurlijke tegenhanger van het grensoverstijgend denken – het “exclusief” denken. Exclusieve denkers zijn voornamelijk met hun eigen zaken bezig, of die van hun groep, en tonen typisch weinig sympathie voor 'anderen'. Ze zijn vaak scherp gefocussed, sterk territoriaal ingesteld en bijzonder competitief aangelegd. Dat zijn precies de kenmerken van dominantie die maatschappelijk vaak zo gewaardeerd worden. Je vindt exclusieve denkers dan ook met name bij captains of industry, militaire en politieke leiders. Ze worden vaak getypeerd als 'vechters', ze lijken soms wel te genieten van conflicten en zijn geneigd te stellen dat het doel zo'n beetje alle middelen heiligt. Ze worden geroemd om hun 'daadkracht'. In alle opzichten zijn ze de tegenpool van de grensoverstijgende denkers.

Zo'n exclusieve mindset kan ook doorslaan – je kunt over-exclusief zijn. Psychologen hebben het dan over sociopatisch gedrag. Er vallen dan kwalificaties als 'gewetenloos', 'impulsief' en 'meedogenloos' [4]. Het interessante is dat slimme sociopaten in het dagelijks leven heel goed in staat zijn om de extreme kantjes van hun karaktertrekken te maskeren. Ze zijn van nature charmant en hebben geleerd om zich precies te gedragen zoals van een sterke leider wordt verwacht. En juist daardoor vallen ze niet zo gemakkelijk door de mand.

“How do we recognize the remorseless? One of their chief characteristics is a kind of glow or charisma that makes sociopaths more charming or interesting than the other people around them. They’re more spontaneous, more intense, more complex, or even sexier than everyone else, making them tricky to identify and leaving us easily seduced. Fundamentally, sociopaths are different because they cannot love. Sociopaths learn early on to show sham emotion, but underneath they are indifferent to others’ suffering. They live to dominate and thrill to win.” [5]

Het hoeft dus geen verbazing te wekken dat er nogal wat historische figuren voorkomen op de lijstjes met beroemde sociopaten. Mensen als Napoleon, Hitler en McCarthy, om er maar een paar te noemen. Die lijst kun je – al naar gelang je politieke voorkeur – moeiteloos uitbreiden met omstreden machthebbers [6], maar ook met oorlogsmisdadigers, seriemoordenaars, sekteleiders en directieleden die in hun ijver tot excessieve zelfverrijking hun eigen bedrijf ten gronde hebben gericht. Ik denk wel eens dat het juist omdat de kwaliteiten die het exclusieve denken kenmerken in een zo hoog aanzien staan, het sociopaten – die immers extreem exclusief denken – extra gemakkelijk wordt gemaakt om grote groepen mensen te domineren, te manipuleren en uiteindelijk te duperen.

Net zo goed als je het in beginsel positieve 'exclusieve' denken kunt overdrijven, kun je ook het in beginsel positieve 'inclusieve' denken overdrijven. Je kunt dus over-inclusief zijn in je denken en je handelen. Overal rekening mee willen houden, ook al heeft het maar zijdelings met het probleemdomein te maken. Ook over-inclusief denken is grappig genoeg een bekend psychopathologisch symptoom, namelijk van schizofrenie, met als voornaamste kenmerk “unability to perserve conceptual boundaries” [7].

Maar levert dat 'teveel-van-het-goede' dan geen akelige paradox op? Zou het dan zo zijn, dat een architect die erg goed is in zijn vak, die heel grensoverstijgend kan denken, die de meest netelige problemen weet te doorgronden en die in zijn ontwerpen echt rekening weet te houden met alle stakeholders, per definitie, eh, gestoord is?

De uitweg

We kennen uit de literatuur het anti-patroon “Analysis Paralysis” [8]. Dit patroon beschrijft de verlammende werking van het eindeloos blijven zoeken naar een betere oplossing. Iedereen voelt wel aan dat dit uiteindelijk zijn doel voorbij schiet, maar 'exclusieve' denkers zijn er ronduit allergisch voor. Die willen restultaten zien. En wel nu!

Het Analysis Paralysis anti-patroon leert dat je resultaten ook incrementeel kunt boeken, om zo het betere niet de vijand van het goede te laten zijn. Een 'goede' architect kan net zo goed alvast een paar stappen vooruit denken, zonder dat hij daar zijn omgeving nodeloos mee lastig valt. Je kunt ook – desnoods in het geniep – gewoon rekening houden met bepaalde concerns zonder dat je daarover in discussie gaat. Dat heet dan goed vakmanschap. Natuurlijk kom je daar niet altijd mee weg, zeker niet als het een grote impact heeft op de business case, maar je kunt op deze manier wel vaak veel meer bereiken dan je in eerste instantie zou denken.

Het kan ook geen kwaad om goed na te denken over welke discussie je met wie wilt voeren. Hoe zeer je ook twijfelt over de validiteit van een ontwerpprincipe voor jouw probleemsituatie, of de kwaliteit van de ontwerptools, of het nut van reviews – voer zo'n discussie liefst met collega architecten en vooral niet met een projectmanager of je opdrachtgever.

Het valt ook voor een inclusief denker best te begrijpen dat er maar weinig betrokkenen blij worden van een mededeling dat “alle voorgenomen keuzes nog niet vaststaan, omdat ze eerst nog met andere partijen besproken moeten worden” – hoe waar dat op zichzelf misschien ook is. Natuurlijk moet je vaak van alles overleggen met ketenpartners, andere afdelingen, toezichthouders, beheerders, eigenaren van bestaande services of leveranciers. Maar je zou in zo'n geval gewoon ook kunnen zeggen dat er nog meer partijen betrokken zijn, om daar meteen aan toe te voegen: “maar maak je daarover maar geen zorgen, dat regel ik wel met ze”. Kijk, dat is nou iets wat een exclusieve denker graag wil horen.

Het is trouwens ook niet sterk om dat soort zaken wel ondershands met die partijen te regelen, maar daarover, in een poging om er verder maar niemand mee lastig te vallen, helemaal niks te melden. Je loopt dan niet alleen het krediet mis dat je wel verdient, je loopt ook het gevaar dat men zich gaat afvragen waar je nou eigenlijk zo druk mee bezig bent. En, erger nog, je kunt heel wat mensen in verlegenheid brengen als er plotsklaps blijkt dat je iets om welke reden dan ook niet hebt kunnen regelen. In zo'n geval kan je op onbegrip stuiten, terwijl je juist zo hard steun nodig hebt.

De moraal van dit verhaal? Een inclusief denker kán ook in een exclusief denkende omgeving wel degelijk zeer gewaardeerd worden. Als hij of zij tenminste maar zo slim is om inclusief te denken en tegelijkertijd exclusief te communiceren.

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

Noten
[1] Allopathie is de in homeopathische kringen gebruikte term voor reguliere geneeskunde.
[2] Zie: http://www.ayurvedicstudies.nl/ayurveda/artikelen/assets/Introductie%20Ayurveda.pdf
[3] Feitse Boerwinkel: “Inclusief Denken, een andere tijd vraagt een ander denken”; Paul Brand, Bussum, 1966.
[4] In de gezaghebbende 'Diagnostic and Statistical Manual of Mental Disorders (DSM-IV-TR) wordt voor een anti-sociale persoonlijkheidsstoornis als criterium gehanteerd dat iemand tenminste drie van de volgende zeven gedragskenmerken moet hebben:

“ 1. failure to conform to social norms with respect to lawful behaviors as indicated by repeatedly performing acts that are grounds for arrest
2. deceitfulness, as indicated by repeated lying, use of aliases, or conning others for personal profit or pleasure
3. impulsivity or failure to plan ahead
4. aggressiveness, as indicated by repeated physical fights or assaults
5. reckless disregard for safety of self or others
6. consistent irresponsibility
7. lack of remorse, as indicated by being indifferent to or rationalizing having hurt, mistreated, or stolen from another”

Een alternatieve, meer populaire opsomming kun je vinden op Profile of the Sociopath.

[5] Martha Stout: “The Sociopath next door – The Ruthless Versus the Rest of Us”; Broadway Books, February 2005, Synopsis.
[6] Er wordt aangenomen dat sociopathie in zekere mate erfelijk is. Zo zou George W. Bush volgens een propagandistische, maar goed gedocumenteerde website de vierde patient in de erflijn zijn.
[7] Andrew Sims: “Symptoms in the mind – an introduction to descriptive psychopathology”; Saunders Ltd.; 4 edition (April 21, 2008), p. 160.
[8] William J. Brown et al: Anti Patterns – Refactoring Software, Architectures, and Projects in Crisis”; John Wiley & Sons, 1998, p. 215 e.v.