"Your brain does not process information, retrieve knowledge or store memories. In short: your brain is not a computer."

No matter how hard they try, brain scientists and cognitive psychologists will never find a copy of Beethoven’s 5th Symphony in the brain – or copies of words, pictures, grammatical rules or any other kinds of environmental stimuli. The human brain isn’t really empty, of course. But it does not contain most of the things people think it does – not even simple things such as ‘memories’.

We are organisms, not computers. Get over it. Let’s get on with the business of trying to understand ourselves, but without being encumbered by unnecessary intellectual baggage. The IP metaphor has had a half-century run, producing few, if any, insights along the way. The time has come to hit the DELETE key.

_{Written by Robert Epstein, a senior research psychologist at the American Institute for Behavioral Research and Technology in California. He is the author of 15 books, and the former editor-in-chief of Psychology Today.}

The spirit of the time can be described pretty comprehensively by someone distanced from it, but it is virtually impossible to be aware of its peculiarities when immersed in it. In my article "The Importance of Metaphors" I tried to discuss several approaches to help in becoming at least somewhat more aware of it.

The current metaphor, as referred to in Epstein's article as the "IP metaphor", looks at the world as if it is all some kind of computer. As I explained in my article on metaphors (also of interest might be Von Neumann, Revisited) this "idea" of a computer is a very limited and distorted one: the result of a popularised representation that for some obscure reason exactly misses the point of the computer in the first place: it is not a machine, a device, but an extension of our human capability of language. In fact this misunderstanding is to a large degree a metaphoric confusion resulting from a backlash of the previous leading metaphor, the Steam Engine.

Language, unfortunately for Epstein, is exactly what he argues against: a method for symbolic representation, and manipulation. Language is the distinguishing property of the species of Homo Sapiens, and very much attributed to our brains, bodies, families, groups and social structures, and the biological world in which we are embedded. Language might even be not uniquely human but an endemic property of all life, as Daniel Dennet in From Bacteria to Bach and Back: The Evolution of Minds explains.

The computer can be seen as an extension of our human faculty of language, but it is another thing to see our brain as a "kind of computer". That metaphor does not see the computer as a language expression (similar to writing and printing), but as a mechanical architecture: the processing of information, still usually within the von Neumann part 1 definition (that of a processing and memory unit).

There the metaphor goes wrong. The brain is so much more complex in its architecture than any computer based on this mechanical definition can ever be. We are only scratching the surface in understanding the brain (or for that matter, biology and the cell).

A Viral (Arc)hive for Metazoan Memory: Cell

Arc, a master regulator of synaptic plasticity, contains sequence elements that are evolutionarily related to retrotransposon Gag genes. Two related papers in this issue of Cell show that Arc retains retroviral-like capsid-forming ability and can transmit mRNA between cells in the nervous system, a process that may be important for synaptic function.

The article shows a new discovery, namely that our nerve cells are capable not only of transmitting "information" through electric signalling with dendrites and synapses, but even, using the same trick retroviruses use, through modifying target cell DNA. In fact this one discovery might upend everything we thought we knew about our brains, based on the IP metaphor. Complexity just exploded!

This requires us to really reconsider our metaphors.

Images from aeon.co, cell.com

Banken, verzekeraars, ministeries en productiebedrijven, bijna allemaal maken ze tegenwoordig gebruik van enterprise architectuur om risico’s bij strategische verandering te beheersen. Er wordt bijvoorbeeld een ...

Source: www.computable.nl

Mark Paauwe over het probleem dat projecten en afdelingen soms een schreeuwende behoefte hebben aan artefacten vanuit de enterprise architectuur die er niet zijn, of waarvan het te lang duurt voordat die er zijn.

Mij lijkt dit probleem wat voor de hand te liggen. Natuurlijk is er voortdurend een behoefte die nog niet ingevuld kan worden. Een enterprise architectuur proces dat meer agile is (en dus bijvoorbeeld niet met een jaarplanning, of erger nog, een meerjarenplanning werkt) helpt maar lost het probleem nog niet op. Het is mij ook niet duidelijk of dit is waar Mark voor pleit.

De ICT manager die dan maar zelf workshops gaat beleggen hoeft helemaal niet verkeerd te zijn. Je kunt toch het resultaat van zijn werk inbrengen in de enterprise architectuur repository? Je wilt hem wel kunnen begeleiden zodat de inpasbaarheid zo groot mogelijk is.

Ook is het heel belangrijk dat de ad-hoc behoeftes die overal de kop opsteken in kaart worden gebracht en gecommuniceerd met het management. Vaak is het niet duidelijk waar de enterprise architectuur niet in heeft kunnen voorzien. Dan kan een groeiende ontevredenheid ontstaan die de effectiviteit van de discipline niet ten goede komt.

Microservices gaan overwaaien, want het past niet bij hoe tegenwoordige organisaties werken.

Source: cio.nl

Een wat chargerende titel die de lading van het artikel niet helemaal dekt. De schrijver is namelijk helemaal geen tegenstander van het principe, misschien zelfs integendeel. Hij signaleert alleen heel terecht dat het invoeren van deze architectuurstijl niet alleen maar beperkt kan blijven tot een technische architectuurkeuze.

De Wet van Conway is belangrijker dan ooit, namelijk de noodzaak de organisatie zodanig ingericht te hebben dat het af te beelden is op de architectuurstijlen (zowel aan business als techniek zijde!) waarvoor gekozen wordt. Ik noem dit ook wel "fractale architectuur": de structuur herhaalt zich op verschillende aggregatieniveaus.

Het is niet voor niets dat ik ook "slecht nieuws" heb voor organisaties die voor SOA hebben gekozen, maar niet een interne structuur (een dienstgerichte indeling) hebben die hiermee resoneert: jullie zullen ook  die interne structuur aan moeten passen, met een governance proces dat hierop afgestemd is.

Door dit af te stemmen op kantel-initiatieven die in heel veel organisaties al speelt, kunnen soms meerdere vliegen in één klap worden geslagen!

13 maart 2015 - Tien jaar geleden maakten we met service oriented architecture (soa) voortvarend een einde aan de spaghetti van systemen. Wist men vóór het soa-denken...

Source: www.computable.nl

Enigszins obligate opmerkingen, maar we zien ook in dit artikel weerspiegeld dat we het steeds moeilijker vinden in het complexe ecosysteem van business, IT, en maatschappij de bomen door het bos te blijven zien. Omgaan met chaos (of complexiteit) vereist een heldere en duidelijke positionering van waar het eigenlijk om gaat: de business. En dat vereist weer dat we een manier vinden om die business expliciet te demarkeren en managen in onze architecturen.

Hoeveel is een goede IT architect als zelfstandige of werknemer waard? Die vraag wordt steeds relevanter omdat de behoefte groeit.

Source: cxo.nl

Moeilijke discussie, omdat zoals we weten een goede architect niet 10% of zoiets meer geld oplevert voor het bedrijf dan een gemiddelde, maar soms zelfs meerdere ordes van grootte. Wie bepaalt wat een "normale" vergoeding is? Voor mij als zelfstandige is een aangeboden tarief beneden de 100 euro voor een verantwoordelijke rol als enterprise architect symptomatisch voor het kaasschaafdenken bij een organisatie en waarschijnlijk een waarschuwingslampje voor het ontbreken van het noodzakelijke mandaat. Maar als ik kan aantonen in mijn werk 2-3 maal productiever te zijn dan mijn gemiddelde kompanen (puur hypothetisch natuurlijk) wordt het verhaal anders.

Kunnen wij als enterprise architecten dat aantonen? Meestal niet. Ik stel dat (enterprise-) architectuur geen geld mag kosten. En ik voel mijzelf verantwoordelijk voor het inrichten van de noodzakelijke metrieken waarmee ik dat kan aantonen. Die metrieken hebben dat niet primair als doel. Ze zijn er voor de positionering van de maturity van de practice en de effectiviteit van de transformaties die door enterprise architectuur worden gefaciliteerd. Maar ook om de inspanning te rechtvaardigen. Enterprise architectuur mag nooit een doel op zich worden.

… in working with our clients, we are finding that the issue of using new technologies is only part of the story. To become truly digital organizations and fully exploit new technologies and outside-in forces, they also have to change how their IT organization is organized, including IT’s (increasingly blurring) relationship with the rest of the organization.

… how does the EA group need to change? …

Source: blogs.csc.com (links obsolete)

Mapping en reporting: inderdaad lijkt het alsof in het sterker versplinterde (ik zou eerder zeggen: opgedeeld in kleine, los gekoppelde componenten) EA landschap dit tot problemen gaat leiden. De oplossing voor dit probleem is dat weliswaar het landschap opgedeeld is, maar dat het business model "in eigen huis" moet zitten. Gekoppeld aan een veelheid van elementen geeft dit model een kapstok voor BI en what-if scenario's. Dit model is niet alleen model in de letterlijke betekenis van het woord: het is een graph van elementen die daadwerkelijk geïmplementeerd is (zie o.a. Business-Centred Architecturen).

Outside-in: dit aspect lijkt mij minder boeiend, of in ieder geval nogal voor de hand liggend. Ook wel technology push genoemd, is er inderdaad wel degelijk een beweging die gefaciliteerd moet worden vanuit push in het algemeen. Dit geldt niet alleen voor technologie: ook vanuit vernieuwingen in management theorieën (denk aan kantelen van organisaties), HR of welk gebied van onze moderne maatschappij dan ook is er impact waarvan we kennis moeten nemen en wanneer nodig faciliteren om de organisatie mee te laten bewegen.

Boundaries: gedeeltelijk overlappend met mijn opmerkingen bij het vorige punt. Actief openstaan voor aanpalende gebieden vraagt van de enterprise architectuur functie een brede basis, die niet alleen in de ICT technologie moet en kan liggen.

Customer: Vaak alleen met de mond beleden, kan alweer het business-centrische model helpen om dit ook daadwerkelijk in de implementatie terug te vinden: de klant centraal.

A nice little read during the holidays was Rich Gold book:

Usually the focus of software development is on the engineering part. Wearing the hat of the engineer, and expecting others to do the same, makes it very hard to make optimal use of our creativity. We all have heard a lot on the goings-on at Apple as a side-effect of Steve Jobs' death, and one of the things we should be aware of is the prominent position of the designer at Apple. In fact, the lead positions with Apple are taken by designers. Not engineers. Not project managers. Not architects either!

The other two hats are not less important either. The hats of the artist and scientist have something in common, that the engineer and designer, with their focus on "customer satisfaction", lack: a certain wilfulness, or obstinacy, the drive to pursue a venue just because it is there and fills your dreams, the vision that is larger than you are.

Build a team, and try to incorporate something of these four hats, to create a balance that nurtures creativity. I sometimes use inspiration from other sources to think about team member characteristics, which I want to share with you here.

One is from Marinus Knoope. Unfortunately I do not know of an English translation of his work. There is a German translation (Die Kreationsspirale, see below). He is a Dutch physicist gone psychological, and his book "De Creatiespiraal" (English: The Creation Spiral) is a nice additional view on the subject of creativity that Rich Gold talkes about, and his book provides very practical guidelines for applying this concept on teams and organisations.

Another source of inspiration is the Medicine Wheel from the native American traditions, which uses the four directions of the compass and links these with basic psychological attributes (in this case for example wisdom, justice, courage and temperance). There are many other possible sources: the wheel of astrology is one I also use often.

All of these models, or thinking matrices, have something in common. They describe a "wholeness", and attempt to achieve "whole-sightedness" (see Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean ). This is something we not only should attempt to accomplish in our organisation, but also in our products. It functions as an antidote of ant-sightedness, which is endemic in society as well as in software development. I often talk about the importance of realising that there is not so much difference between the way you should organise your product or the team that produces that product. These sources helped me through the holidays, and set a nice tone for me in the coming year.

Happy and creative 2012!

• The Plenitude: Creativity, Innovation, and Making Stuff (Simplicity: Design, Technology, Business, Life)
• Die Kreationsspirale. Wie wir Wünsche zur Wirklichkeit werden lassen können.
• The Medicine Way
• Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean

Some unrest has been created by the visible impact (that is, banning from the Apple AppStore) of the enforcing of certain clauses in the license agreement all developers need to sign in order to get access to iPhone development.

This license agreement has been in the news earlier. It is an interesting license agreement, since part of the agreement is that the agreement itself may not be publicly discussed (section 10.4). In fact posting this blog about it may itself be interpreted as a violation of the agreement and result in all my iPhone/iPad development being banned!

The banning of the Scratch app, based on section 3.2.2 of said agreement, has also created quite a buzz in the developers community. The ESUG mailing list (ESUG is the European Smalltalk Users Group, and a representative of a large part of the Smalltalk programmers community, Smalltalk being a programming language that seems to be violating section 3.2.2 of the license, and consequently cannot be used to program any software for the iPhone) sent some heated mails around. But this response in itself may be brought to court based on this paragraph!

A large part of the discussion is invisible to the public, because it takes place (from necessity since discussing it in the open may have undesirable repercussions…) on the Apple developers forums. To get access to these forums you need to sign the agreement!

All in all this seems a very undesirable situation, in dire need of clarification. Even the legal basis for the entire agreement may not be correct.

I suppose it can never be the intention of the license to ban freedom of speech, which can be a possible interpretation of these events. Fortunately the EFF seems to take the matter seriously.

This is going to be a small, technical tutorial on how to save a lot of time by watching videos at higher playback rates.

I first read about this idea from my most favorite personal development blog at Steve Pavlina.com. In his post "Overclock Your Audio Learning" he says that he occasionally listens to audios at 4.1x. At this speed 4 hour video/audio can be listened in less 1 hour!

How to Save Time by Watching Videos at Higher Playback Speeds

I have been advocating friends and colleagues to acquire the skill for some form of fast-reading or speed reading. It is a skill everyone can learn, and will bring with it many advantages. But this can not only be done for reading, but also for listening to audiobooks (which I do a lot) and watching video's.

Note: after experimenting a little with this, I increasingly found there is a difference between reading and watching/listening. When speed-reading I typically make something akin to "page pictures" in my mind, taking in whole paragraphs at a time, or sometimes even whole pages. It may be compared to a gestalt. I have a strong impression of changing my mental state for this. For audio/video this does not really seem to work. I find that the mental state for speed watching/listening does not really change, it goes faster, and not that much faster at that because it is still in the sequential state, which is really slow in fact.

Vannevar Bush has been referred to on this site, but despite him being Belgian (I am Dutch, which is almost Belgian?), I never heard of Paul Otlet, who seems to have pre-dated Bush by at least a decade. There is no evidence that Bush knew of Otlet, but seeing that Otlet in his time was rather famous I would not be surprised if that was the case.

Read this article about Vannevar Bush to understand the importance of his work.

Paul Otlet's name is currently more connected to his work on created a cataloguing system for libraries, which has become the UDC (Universal Decimal Classification) that libraries all over the world still use, an extension of the Dewey Decimal Classification.

Otlet set out his visionary work on libraries and the management of information, which is very similar to my own interest in the web and computers, being the next phase in time-binding, that uniquely human faculty as defined by Korzybski.

The story of Otlet is also one that struck me as particularly tragic, all the work being done in indexing those 12 million indexes destroyed in one sweep by the Nazis! I cannot imagine how he must have felt, but that he died a broken man is clear... This was a man whose vision was too advanced for his time. And the similarities between his work and that of Vannevar Bush and others is evident. It is definitely worthwhile to visit the museum in Mons, Belgium, and to gather more information on the ideas of Paul Otlet.

The video below (with voice-over available in Dutch, French and English) explains why the Mundaneum was so special:

More on the museum can be found at http://www.mundaneum.org/en