Slimme energie prosumenten

Slimheid lijkt hoogtij te vieren in energieland. Kijk maar naar termen als slimme meter, slim netwerk en slim energie beheer. Die slimheid komt voort uit informatie innovaties.

Moeten gebruikers van energie, bedrijven, consumenten, nu ook aan die slimheid geloven? Wat voor een invloed krijgt het op hen? In deze blog een kijkje in de toekomst voor energie gebruikers. De trends die mogelijk tot die slimheid gaan leiden.

De eerste aanleiding voor slimheid voor gebruikers vormt de energiebesparingstrend. Onder het motto 'meten is weten'worden kleine, makkelijk te installeren energie management apparaten en natuurlijk de slimme meter geïntroduceerd. Zo kan de gebruiker zijn verbruik analyseren en bijstellen. Een besparing van 10% kan toch al gauw vele honderden euro's per jaar opleveren.

Een tweede trend is dat gebruikers van energie ook steeds meer producenten van energie worden. Huizen/gebouwen of wijken/industrieterreinen worden uitgerust met zonnecollectoren, windgeneratoren (bijvoorbeeld verwerkt in de nok van het dak), zonneboilers, aardwarmte systemen, micro-gecombineerde warmte-stroom opweksystemen (WKK) en energie opslag systemen. Ieder heeft een besturings element, vaak met de mogelijkheden om de resultaten - zoals opgewekt vermogen, gerealiseerde opwarming - zichtbaar te maken. Het rendement c.q. de terugverdientijd is interessante informatie in dit geval.

De volgende stap naar slimheid ontstaat als de sturing van zowel de genoemde opwek-systemen als de grote verbruik-apparaten (wasmachine, vaatwasser, droger) met elkaar in verband kunnen worden gebracht. Hierdoor wordt optimalisatie in huis/pand of wijk/terrein mogelijk. In de lijn van deze stap ligt dat ook één centraal dashboard voor de gebruiker ontstaat, waarop voorkeuren, besturing, verbruiken en resultaten worden samengebracht. Ook verdere huisautomatisering komt hier ter sprake. Dit kan gecombineerd worden door aanvullende (informatie)diensten, zoals adviezen over de contractvorm met een energieleverancier, gezien de configuratie, adviezen over verdere optimalisatie van de configuratie of zelfs overdracht van de configuratie aan een beheerpartij.

Nog verder gaat het als prosumenten gaan samenwerken en een grote 'virtuele' energie-opwek/opslag-eenheid vormen. In een dergelijk model behoort ook centrale aansturing door het samenwerkingsverband tot de mogelijkheden. Het samenwerkingsverband kan dan dagelijks op de energiehandelsmarkt een rol gaan spelen en gunstige inkoop- en verkooptarieven en -contractvoorwaarden bedingen. Afspraken die tot de mogelijkheden behoren is dat het opladen van elektrische auto's collectief wordt 'afgeschakeld' op piekmomenten en wordt 'ingeschakeld' op dalmomenten. Of dat alle micro-WKKs in een piek op maximaal vermogen worden geschakeld. Individuele deelnemers moet het dan mogelijk zijn om 'voorkeuren' of gebruikspatroon (bijv. een vakantieafwezigheid) aan te geven. Hiermee wordt dan intelligent rekening gehouden en op geoptimaliseerd. En voor hen is het interessant om op dat moment ook financiele resultaten inzichtelijk te krijgen.

Als de energie markt dezelfde ontwikkeling doormaakt als de internet en telecom markten volgt er daarna een enorme groei in diensten en differentiatie in produkten en tarieven. En komen er nog niet te voorziene innovatie en waardetoevoeging tot stand.

Ja, die slimheid komt stapje voor stapje naar de prosument toe, met alle keuzevraagstukken en mogelijkheden van dien. Gelukkig hoort uitbesteden tegen die tijd tot de mogelijkheden.

Waarnemen

Over wat een informatie architect doet bestaat veel discussie. Vaak wordt IT-architectuur vergeleken met bouwkundige architectuur. Jaap van Rees beschrijft in een artikel in 2003 dat beide definities van architectuur sterk van elkaar verschillen. IT-architectuur gaat vaak over regels en principes. Het gaat over het hoe (IT-)componenten met elkaar samenwerken. De IT-architect levert (meestal) slechts documenten op over hoe een systeem geconstrueerd moet worden. Bouwkundige architectuur gaat veel meer over het effect van een gebouw op zijn gebruikers en zijn omgeving. Het gaat over beleving, normen en waarden en cultuur. Het gaat over wat en waarom iets gebouwd wordt. En het gaat over hoe zich dit vertaalt in het gebouw dat opgeleverd gaat worden.

Dit vertaalt zich volgens Van Rees ook in de vaardigheden van een architect. Waarnemen is voor Van Rees een belangrijke vaardigheid van een bouwkundig architect. Door goed waar te nemen kan de architect iets ontwerpen wat de opdrachtgever nodig heeft. Daarbij neemt de architect vaak aspecten waar die in een organisatie bestaan, maar waarvan de organisatie zelf zich niet bewust is. "De ... architect is de regisseur van het beeldvormingsproces, dat hij samen met de opdrachtgever doorloopt." IT-architecten worden volgens Van Rees niet getraind in het waarnemen van een organisatie.

Christopher Alexander hecht ook veel belang aan waarnemen. Kijk naar een bestaande omgeving, het gedrag van mensen, de cultuur, etc. In die waarneming herken je ontwerppatronen. Christopher Alexander laat die ontwerppatronen de basis zijn voor nieuwe architectuur, zoals die van een stad. Ontwerppatronen zijn dynamisch, worden opgesteld door de gebruikers zelf en worden regelmatig geëvalueerd en bijgesteld. Via een geleid proces onstaat zo een organische groeiende gebouwde omgeving waarin mensen zich "thuis" voelen.

En ook mijn collega's Ruud van Vliet en Rijk van Vulpen hebben op deze site eerder gesproken over waarnemen. Zo heeft Ruud het gehad over de relativiteit van wereldbeelden en de betekenis ervan voor informatie architecten. En Rijk heeft eerder geschreven over een methodiek voor het waarnemen zoals beschreven door Goethe, het Goetheanisme.

De vraag is: Hoe neem je als goede (in de zin van Van Rees) informatie-architect een organisatie goed waar? Hoe laat je het voor die ene organisatie unieke gebruik van informatie tot uitdrukking komen in een informatiesysteem? En welke gevolgen heeft dat voor de implementatie ervan?

Een methode voor het waarnemen van het gedrag van mensen in een organisatie en het vastleggen ervan is het maken van personas. Personas zijn beschrijvingen van fictieve gebruikers van een informatiesysteem of een product. Via bijvoorbeeld interviews met gebruikers verkrijg je een veelheid aan informatie over hoe mensen in een organisatie werken, wat mensen van systemen verwachten, welke problemen zij ondervinden, etc. De veelheid aan gebruikers worden verdeeld in een aantal type gebruikers. Niet te weinig personas, maar ook niet te veel personas, maar wel altijd gerelateerd aan het product of informatiesysteem dat op dat moment gemaakt wordt.

Elk type gebruiker wordt uitgewerkt in een persona. Iedere persona krijgt een naam en een gezicht. Hiervoor worden vaak foto's en namen gebruikt die passen bij de persona. Door géén foto's of namen van bekende personen of personen uit de organisatie zelf te gebruiken, wordt vermeden dat een persona een karikatuur wordt. Van een persona wordt in detail beschreven wat zijn/haar context is, wat de eigenschappen of doelen zijn van de persona en welke eigenschappen van het product de persona waardevol vindt. Vaak komen er geanonimiseerde uitspraken van 'echte' gebruikers terug in een persona. Personas zijn dus niet zomaar verzinsels. Personas vertegenwoordigen voorbeeld gebruikers.

Projectleden en stakeholders kunnen zich identificeren met een persona en kunnen zich gaan inleven in de persona. Door personas op handige kaartjes of in een foldertje uit te werken kunnen teamleden personas gemakkelijk bij de hand houden tijdens het nemen van bijvoorbeeld ontwerpbeslissingen. Personas geven gedurende een project antwoord op de vraag: "Voor wie maak ik dit product?"

Personas kunnen nu gekoppeld worden aan (business)features. Simpelweg door de foto's van de personas bij de features te plakken. Het uitwerken van een feature kan nu gekoppeld worden aan nut van de feature voor een persona. Hoe werk ik de feature zo uit dat deze waardevol is voor deze persona? Welke karakteristieken moet het ontwerp hebben om geschikt te zijn voor dit type gebruiker? Bij de duizend-en-één beslissingen die er tijdens een IT project gemaakt worden, kunnen deze beslissingen genomen worden in relatie tot de onderkende personas. Ik denk zelf dat personas ook een goede bron kunnen vormen om tot een lijst van ontwerppatronen voor een product te komen.

Met behulp van personas kan er meer rekening gehouden worden met het effect dat een IT ontwerp heeft op de gebruikers van het informatiesysteem. Personas vormen een manier om de mens meer centraal te zetten in een IT ontwerp (user centric design). En dat is hard nodig.

Referenties:

 

De evolutie van informatie

Informatie architecten gebruiken verschillende invalshoeken om naar bestaande informatie verzamelingen te kijken. Daarbij staat de mens centraal, zoals mijn collega Anneleen ook onlangs schreef.

Er zijn verschillende manieren om naar informatie te kijken, maar er zijn ook verschillende manieren om naar de wereld te kijken. Hoe ervaart iemand de wereld om zich heen? Wat is je wereldbeeld?

Diverse religies geven een verklaring voor het ontstaan van de wereld die aan ons voorbij trekt en proberen ook doel en zingeving te verklaren. Het is dit jaar, 2009, Darwin jaar. Darwin geeft, in vergelijking tot religies, een geheel andere kijk op het ontstaan en de ontwikkeling van het leven op aarde. In "The Origin of Species" presenteert Darwin een theorie die, zoals Dan Dennett zegt, "...the lifeless world of matter and the world of meaning, purpose and goals..." bij elkaar brengt en met elkaar in verband brengt.

In 2008 heeft Richard Dawkins een documentaire gemaakt getiteld "The Genius of Charles Darwin". Voor deze documentaire heeft Dawkins verschillende mensen geïnterviewd, o.a. Dan Dennett. In het interview bespreken Dawkins en Dennett een naturalistisch wereldbeeld vrij van bovennatuurlijke elementen en mythen. De evolutietheorie geeft een wetenschappelijk bewezen verklaring voor de ontwikkeling van de natuur om ons heen en voor de ontwikkeling van de mens als (dier)soort. In het interview laten Dawkins en Dennett tevens zien dat evolutionaire processen mogelijk ook ten grondslag liggen aan het ontstaan van taal, muziek, cultuur en samenlevingen.

Wezenlijk onderdeel van het evolutionaire proces is dat uit levenloze onderdelen (moleculen, proteïnen, etc.) complexe, levende organismen ontstaan. Continu worden er binnen dit evolutionaire proces kleine wijzigingen geïntroduceerd. Succesvolle wijzigingen blijven generaties lang bestaan. Minder succesvolle wijzigingen verdwijnen uiteindelijk. Het geheel van interacterende organismen is zich continu aan het aanpassen en leeft voort zonder enig doel of richting. De "bottom up" theorie van het zich ontvouwen van complexe systemen uit interacterende, relatief simpele onderdelen intrigeert mij.

Na het bekijken van het interview van Dawkins met Dennett vraag ik mij het volgende af. Liggen evolutionaire processen ook ten grondslag aan het ontstaan informatiesystemen? Is een informatiesysteem op te bouwen uit ogenschijnlijk eenvoudige elementen van waaruit zich, volgens een evolutionair proces, een complex informatiesysteem ontvouwt? Hoe flexibel en adaptief is zo'n systeem?

Dawkins en Dennett zien in het internet een web van interacterende software en informatie. Ideeën verspreiden zich in een ongekend tempo over het internet. Dawkins ziet overeenkomsten in de manier waarop informatie zich verspreid en ontwikkeld in een samenleving met de manier waarop in de natuur eigenschappen zich verspreiden en ontwikkelen. Dawkins heeft hier, in 1976, de term meme voor geïntroduceerd.

Een meme is een idee of concept dat zich kopieert van persoon naar persoon. Een persoon kan, volgens Dawkins, gezien worden als een host voor de replicatie van memes. De mens staat centraal in het verspreiden en laten voortbestaan van ideeën en concepten. En het internet is daarbij het meest recente middel dat de evolutie heeft voortgebracht om ideeën en concepten te verspreiden en te laten voorbestaan. Het internet is een "thinking tool" zoals Dennett zegt. De meme-theorie is interessante manier van kijken naar de rol van informatie in onze samenleving. De meme-theorie is (nog) niet wetenschappelijk bewezen en kent ook (wetenschappelijke) kritiek.

Het is interessant om in uw eigen organisatie te kijken naar het voorkomen van memes. Zijn er ideeën of concepten die zich binnen een organisatie gedragen als een meme. Zijn het gewenste of ongewenste memes? Hoe om te gaan met dergelijke memes? Welke memes zijn er met elkaar in competitie? Hoe gemakkelijk is het om nieuwe memes te introduceren?

Darwin heeft ons niet alleen een andere kijk op de natuur en op ons mensen gegeven, maar wellicht ook een heel andere kijk op de rol, het nut en het gedrag van informatie.

Berry Groenendijk is informatie architect bij Caerleon.

 

SOA en architectuur taal Archimate

Er wordt gezegd dat Service Orientatie de brug tusse Business en ICT weet te slaan. In Archimate, the Architectuur taal, kan het concrete resultaat hiervan worden gezien. Services zitten in het hart van de taal. Dit kern element is aanwezig op alle architectuur niveaus. Externe business services overbruggen het gat naar de buitenwereld en externe applicatie services overbruggen het gat tussen de de business architectuur en de informatie architectuur. Technische services doen hetzelfde tussen informatie architectuur en technologie architectuur.

Kunnen services worden getekend tussen de horizontale Zachman lagen vraag ik me af?

Hypermedia en informatie architectuur

Het internet, het bekendste voorbeeld van een hypermedium, heeft tot een enorme groei van electronisch beschikbare informatie geleid. Met behulp van hyperlinks worden verschillende informatieblokken aan elkaar gekoppeld waardoor een web van informatie ontstaat. Op het internet worden al deze hyperlinks gemaakt zónder dat er bijvoorbeeld een centrale faciliteit is die garandeert dat alle hyperlinks ook geldig zijn. Er niets dat garandeert dat een hyperlink ook daadwerkelijk aankomt. Dit lijkt een enorme tekortkoming, maar het heeft er in werkelijkheid mede toe geleid dat internet pagina's (HTML documenten) zeer gemakkelijk te maken, te publiceren en te (her)gebruiken zijn. Het publiceren van informatie op internet is dusdanig laag drempelig geworden dat bijna letterlijk iedereen informatie kan delen met letterlijk de hele wereld.

Bovenstaande roept bij mij als informatie architect de volgende vragen op. Zijn deze uitgangspunten van het internet ook toe te passen op bedrijfsapplicaties? Welke voor- of nadelen levert dit op voor bedrijven en met name voor medewerkers binnen een bedrijf? En wat betekent dit voor het werk van de informatie architect?

Een architectuurstijl die aan populariteit wint is ReST (Representation State Transfer). ReST neemt de eigenschappen het hypermedium internet als uitgangspunt. Roy T. Fielding heeft deze architectuurstijl beschreven in zijn dissertatie. In een softwaresysteem gebouwd volgens ReST uitgangspunten vormt de locatie, een URL, van een informatie-eenheid (een "resource") het uitgangspunt. Voor het manipuleren van alle informatie-eenheden staan slechts 4 (Engelstalige) acties ter beschikking: get, post, put en delete. Met behulp van hyperlinks worden alle informatie-eenheden aan elkaar gekoppeld. En ook nu geldt dat niets of niemand garandeert dat een hyperlink ook daadwerkelijk aankomt.

Laten we als voorbeeld alle medewerkers van het bedrijf MijnBedrijf in een ReST softwaresysteem zetten:

De actie GET op de resource http://mijnbedrijf.nl/medewerkers/ toont een lijst van alle medewerkers. Iedere medewerker in de lijst heeft een hyperlink waarmee we detailinformatie van de medewerker kunnen opvragen. Met de actie POST op dezelfde resource voegen we een nieuwe medewerker toe.

De actie GET op de resource http://mijnbedrijf.nl/medewerkers/janjansen/ toont de detailinformatie van de medewerker Jan Jansen. Bijv. een telefoonnummer, een geboortedatum, een foto, etc. Maar, bijv. ook hyperlink naar de afdeling waar de medewerker werkt (bijvoorbeeld: http://mijnbedrijf.nl/afdelingen/inkoop/). Met de actie PUT kunnen we detailgegevens van deze medewerker wijzigen. Met de actie DELETE verwijderen we de medewerker uit het systeem. Stel dat Piet Pietersen helemaal geen medewerker is van MijnBedrijf, dan levert de actie GET op de resource http://mijnbedrijf.nl/medewerkers/pietpietersen/ simpelweg een foutmelding op. De foutmelding geeft aan dat deze resource niet bestaat en dat deze medewerker dus onbekend is binnen MijnBedrijf.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/ toont alle afdelingen binnen een bedrijf. De lijst bevat ook hyperlinks naar iedere individuele afdeling. Met de actie POST kan een nieuwe afdeling aangemaakt worden.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/inkoop/ toont de detailinformatie van de afdeling inkoop, zoals een hyperlink naar de manager van de afdeling inkoop. Met de actie PUT kunnen we detailinformatie van de afdeling wijzigen, zoals bijv. de naam van de afdeling. Met de actie DELETE kunnen we afdeling in zijn geheel verwijderen.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/inkoop/medewerkers/ toont een lijst van hyperlinks naar alle medewerkers van de afdeling inkoop. Voorbeeld van een hyperlink die in de lijst getoond wordt: http://mijnbedrijf.nl/medewerkers/janjansen/.

De voordelen van een systeem gebouwd volgens ReST uitgangspunten is dat het resources kent die heel dicht liggen tegen het informatiemodel van het bedrijf. De urls van de resources zullen voor de medewerkers van het bedrijf dan ook heel natuurlijk overkomen. De beperkte set van acties zorgt er voor dat je gemakkelijk tegen een ReST systeem aan kan automatiseren. Hierbij helpt ook dat ReST verschillende representaties (bijvoorbeeld HTML, XML, JSON, etc.) toestaat van één en dezelfde resource. Een ReST systeem kan dus tegelijkertijd gebruikt worden door mensen maar ook gebruikt worden om bijvoorbeeld integraties met andere bedrijfssystemen te realiseren.

De nadelen van een softwaresysteem gebaseerd op ReST uitgangspunten is de nu nog relatieve onbekendheid. Zeker bij bedrijfsapplicaties. Steeds meer cloud computing diensten op internet, zoals aangeboden door bijv. Amazon en Google, prefereren het aanbieden van een ReST interface op hun diensten in plaats van een interface gebaseerd op een service geörienteerde webservice (SOA). Mede hierdoor zal ook steeds vaker in (standaard) producten ReST interfaces te vinden zijn. 

Voor de informatie architect betekent ReST een nieuwe cq. een andere manier om een informatiemodel uit te werken in een werkend software systeem. ReST legt de focus op het definiëren van informatie-eenheden en op het onderkennen van relaties tussen deze informatie-eenheden. ReST sluit daarmee, naar mijn mening, nauw aan op de kracht van een informatie architect: het maken van een blauwdruk van informatie binnen een kennisdomein.

Berry Groenendijk is informatie architect bij Caerleon.

Service Normaal Vorm

Vandaag was ik aan het werk met het vinden van geschikte business services. Zoals altijd legde ik lakmoes proef criteria aan zoals een goede abstracties, goede verdeling van verantwoordelijkheden en maximale cohesie en minimale koppeling. Ook keek ik naar de toegevoegde waarde van een gevonden verzameling services, ik keek of ik er op ieder niveau 7 +/- 2 had gevonden en of ik voor een service ook afnemers kon vinden. Maar de ontwerpbeslissingen die ik nam bevredigden me niet volkomen. Plotseling kreeg ik een ingeving: is er niet net zoals bij de database theorie zoiets als een service normaal vorm, met standaard regels hoe je ze vindt, hoe je ze valideert en optimaliseert?

Al surfend op internet bleek dat  anderen al eerder dezelfde gedachte hadden gehad. Ze hebben onderzocht "welke eigenschappen een "goede" service zou moeten hebben". Ik zal het lezen en er later eens op terugkomen.

Waar ligt het initiatief in an SOA architectuur?

Ik ben gecharmeerd van de figuur hieronder (origineel van Oracle BEA). De meeste van de gelaagde SOA modellen plaatsen de GUI laag bovenaan, bij de gebruiker. Dan volgt de proceslaag, de business of domein logica laag en de data services laag.

Ik heb me altijd afgevraagd welke laag nu het initiatief had. Het leek er altijd op alsof het initiatief van de gebruiker moest komen via de GUI laag.

In deze figuur lijkt het er veel meer op (als de gebruiker zich bovenaan de afbeelding bevindt) dat de proces laag het initiatief heeft. Alleen door een actie van die laag krijgt de gebruiker zijn presentatiescherm. Presentatie is niet eerst. Dat lijkt mij de goede volgorde. Bovendien heeft de proces laag toegang tot alle andere lagen, zonder via andere lagen te moeten. Ook dat lijkt me zinnig. De Information Services direct toegankelijk hebben, zonder domein laag, is vooral zinnig op informatie te bekijken.

Hoe maak je je onderneming service georienteerd?

Ik werd gewezen op de bijdrage van Niels Klinkenberg aan het LAC 2007 met betrekking tot SOE (de Service geOrienteerde Enterprise). In zijn presentatie wordt de relatie gelegd tussen service orientatie en een network van organisaties, gericht op slimme samenwerking. De presentatie definieert de condities waaronder je succesvol een SOE kunt neerzetten en hoe je hem werkend krijgt.

Architectuur en Flexibiliteit: Twee Snelheden

Ik was in gesprek vandaag met Ruud van Vliet over de twee werelden die SOA lijkt op te leveren.

We merkten op dat SOA een trage wereld van core competenties, core services, oplevert die een zeer hoge kwaliteit en grote robuustheid moeten hebben. Dergelijke services worden typisch in releases opgeleverd die 3 maanden of meer duren. In de meeste bedrijven liggen die services verborgen in erfenis systemen (een leukere term dan legacy) en die kunnen stap voor stap worden ontsloten.

Daar tegenover staat een snelle wereld van mashup, samenstellen, integreren and via een proces aan elkaar knopen, waarin veranderingen dagelijks of wekelijks kunnen worden doorgevoerd. Soms is daarbij een ontwikkelcyclus nodig, soms zelf niet. Door het combineren en remixen van bestaande data en services kun je snelle veranderingen in de business doorvoeren.

Dit kan gaan leiden tot hele nieuwe rollen bij informatie innovatie. Aan de ene kant de communicatief vaardige, snelle business analist die nieuwe business ervaringen kan configureren in korte tijd, door hergebruik van bestaande services uit een service repository. Anderzijds techneuten, die nieuwe core services in een veel grote tijdspanne opleveren.

De nieuwe weg voor de informatie architect: Faust en de Duivel

Wat zouden wij informatie architecten geven voor een elegant en passend wereldbeeld van het organisatie domein? Faust, de hoofdpersoon uit het gelijknamige boek door Goethe, was bereid zijn ziel daarvoor te verkopen. En Goethe, Johann Wolfgang von Goethe, kon weten wat de consequentie was. Behalve advocaat, dichter, humanist en schrijver was hij een wetenschapper met een nieuwe onderzoeksmethode. Een onderzoeksmethode die we, in mijn mening, als informatie architecten goed kunnen gebruiken.

Zijn methode heet (Goethesiaanse) phenomenologie of Goetheanisme. Hij ontwikkelde het in de biologie en natuurkunde door de studie van planten en de studie van kleuren. En hij vond daarmee fundementele patronen, plantpatronen bijvoorbeeld. Zijn methode bestaat uit een aantal stappen.

De eerste fase: exacte zintuigelijke ervaring: intensief gebruik van de zintuigen en observatie van het onderhavige systeem. Niet tevreden zijn met een beperkt aantal cases. Maar zeer intensief, langdurig en zeer geconcentreerde observatie van het probleemdomein, studerend op uitzonderingen en onregelmatigheden. En niet door nu al te duiden wat wordt geobserveerd, maar alleen meer en meer feiten in het geheugen opnemen. Doelstelling is om diep in de situatie te kruipen.

De tweede fase: wendbare verbeelding: gegeven alle verzamelde feiten, probeer een holistisch en dynamisch beeld te maken van de situatie, door gebruik te maken van de afbeelding en film creërende vaardigheden van het brein. De geheugen opslag voor de individuele feiten smelten daarmee als het ware in één.

De derde fase: innerlijke hercreatie en herhaling: nog steeds je oordeel uitstellend, speel het beeld of de film steeds opnieuw af, zodat je dieper en dieper in de situatie terecht komt, om de essentie te naderen. Een antwoord over de structuur of de essentie van de situatie komt dan vanzelf.

De vierde fase: beschouwend oordelen: herken door denken de patronen, archetypes, regels of blueprint van de situatie.

Dit alles lijkt op wat goede detectives lijken te doen: laat de feiten voor zichzelf spreken, leef je door de hele situatie heen en kom tot je essentiele en creatieve conclusies. Dus laten we Morse, Frost of Dalgliesh kopiëren.

Deze blog is geïnspireerd door het boek Aardschok, Bliksemflits door Wil Uitgeest.

Rijk van Vulpen is enterprise architect bij Caerleon.