Your brain does not process information and it is not a computer | Aeon Essays

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

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.

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.

“We don’t know who discovered water, but we’re pretty sure it wasn’t the fish.”
— John M. Culkin

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 2 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,

Waarom het niet werkt

or: the lack of cohesion-awareness.

In The Netherlands we have in our public transport trains the concept of silent compartments (quiet areas). Abundantly signalled in the compartments, the idea is that people are quiet in there, so that you can concentrate on work or just relax. There’s often people who pretend they have not seen the signals, or just because they do not want to acknowledge the concept, and talk or make other loud noises. Understandably this annoys other travellers. However the simple act of asking the perpetrators to be quiet has almost just as often the opposite effect. They become even more angry, and the conflict (as many conflict nowadays seem to do…) often escalates to dangerous levels. I was even suggested by the railway helpdesk, on complaining about this, that my best option would be to move to another compartment…

Another problem that irritates a lot of people is traffic jams. Sometimes they even seem to pop up out of nowhere and disappear just as silently. Of course most really large tailbacks are caused by accidents. What most people do not realise (because of the lack of cohesion-awareness) is that the net time to arrive at your destination can be minimised by a very simple trick: do not drive too fast!

I remember the (then) minister responsible for infrastructure saying she “could not explain speed limits”. I would say that explaining things like that is exactly her responsibility! Research has shown that a speed limit of 70 km/h on our congested roads would result in congestion disappearing and faster net arrival times. How can you not explain that?

As a small child my mother, as many mothers (and fathers) still do, took me to feed the ducks. Old and stale bread in a basket. I loved seeing the birds flock to get the food.

Near my office there is a pond with, surprise, ducks. I guess the ritual is repeated many times each day, only it is not just ducks that get fed. Masses of seagulls appear as well. The escalating problem that city councils face is that all this feeding attracts seagulls. Because of the abundance of food they start nesting on roofs, creating an awful lot of problems with their droppings and all. Most of the food gets spilled however, by sinking in the water, and gets to feed animals you definitely do not want to profligate in your cities and towns like rats! This food extravaganza is a potential cause of many diseases as well.

Complex systems are rife with feedback mechanisms. Most of these are very hard or actually impossible to detect and document. They are so much interwoven that it is impossible to see where one ends and another starts. It is the web of interconnected and interdependent things. However my impression is that not many people pay attention to those interdependencies. Or are even willing to consider that they miss most of them.

A story told by the “granddaughter of Chroestjev” Nina Khrushcheva (in fact she was his great-granddaughter) of a visit by a relative from her niece from Russia, in Vienna where Nina lived. They took a bus, and Nina stamped her ticket in the machine in the bus. Her niece exclaimed: “why do you do that? There is no-one to enforce that!”. That, Nina explained, is the difference between Russia and “the West”. “In Russia you only do something out of fear of getting caught, while I choose to pay for my ticket because I know that is what it costs to maintain that service on a level that, in the end, benefits me and everyone else.”

For Americans the fact that Swedish people actually want to pay taxes is incomprehensible. Their first priority is to minimise the amount they have to pay, and paying no taxes whatsoever is best. A deep and mostly subconscious mistrust of government seems to be behind this. For the Swedes the American attitude feels quite stupid: by paying taxes they are able to create and maintain a high quality of living for all citizens that they see is totally lacking in the United States.

On the last Dutch National Architecture Conference (LAC) I did a short survey in a session I did (called “Embracing the Future”) where the audience consisted of mostly architects. My question was how they responded to the road signs that are sometimes activated telling the drivers to maximise their speeds to 70 km/h. My expectation was that, being architects, they would be more than average inclined to actually comply. In practice we see that most drivers, especially when there does not seem to be a direct need to reduce speed, do not comply and continue driving with 120 km/h or more. I must admit that I was a bit disappointed that it seemed that only a handful raised their hands. The reason I thought they would comply more, is that compliance would, overall, result in more efficient traffic flow and less congestion which, in the end, would also benefit themselves. And architects especially would be an audience appreciating these arguments, or so I thought.

Feitse Boerwinkel
Feitse Boerwinkel

A (Dutch) book from 1966 recently came to my attention, written by the Dutch cultural philosopher Feitse Boerwinkel, called “Inclusive thinking – a different time requires a different way of thinking”. A very small book (only 98 pages) it was maybe the most influential inspiration for a whole cultural and educational reform in The Netherlands, completely in line with the spirit of the time.

Feitse argues for a different way of thinking he calls “inclusive thinking”. I have talked about the shift to sequential thinking that took place over a long period from the classical Greece to the Renaissance. As does Feitse, I think we are now in an era in which we are again shifting our mental mode towards a non-sequential, inclusive, time-transcending way of thinking. The movie “Arrival” depicts an alien species that completely transcended sequential thinking and even tells the story of a language that is completely non-sequential.

Movie poster Arrival

Time-bound thinking is coming to an end. Jan-Peter van der Berg, the Dutch psychiatrist,devoted an entire book on this development, which he traces from the European Middle Ages to the (then: 1970) present: Dieptepsychologie (“Depth Psychology”). In the book he talks about the rise (after the Middle Ages) and fall (in the hippie years) of the subconscious part of our minds as a somehow separate or dissociated part of ourselves.

This development is one we are smack in the middle of, which makes it hard (and for many: impossible) to see. I think the evolution of humankind is mostly a mental one, and the direction in which we are moving is so very interesting.

You might want to read my article “Why software bites back”.

von Neumann, revisited


Intel’s Bold Plan to Reinvent Computer Memory (and Keep It a Secret)

John von Neumann (during the Manhattan project, 1940-1945). Public domain, Link

We all read John von Neumann’s groundbreaking paper “First Draft of a Report on the EDVAC” back when it was published in 1945, did we not (just joking)?

You should. And read it well, because not many people did (I know of no-one). OK, I admit that some of the mathematics is above me as well, but one thing stuck with me: there are two ways of building a programmable computer. One is how we started doing it, which has become known as the “von Neumann architecture”: a memory unit and a processing unit, and a speeding cycle between the two, transferred through a bus.

We’ve all seen Alan Kay’s famous cardboard model of what a modern computer could look like, from 1965, did we?

Alan Kay’s Dynabook concept model (1965). Copyright Owner © Mark Richards

As we all did (OK I’ll stop here, but I am not kidding: you should have read them!), Alan Kay had read the article by Gordon Moore (inspired by Doug Englebart already in 1959), about cramming more processors on an Integrated Circuit:

The complexity for minimum component costs has increased at a rate of roughly a factor of two per year. Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years.

Useless, Alan Kay reasoned, to think about what computers can do now. We should be thinking about what they might be able to do 10 years from now, because it is almost unfathomable! And the Dynabook was a concept born from that daydreaming. A machine with a radio inside, able to communicate with similar devices in a world-spanning peer-to-peer network. How about that!

I fear that Alan Kay may be one of the very few who realised the consequence of Moore’s Law (as it was named in 1975). And now here we are, more than half a century later, and still we believe that von Neumann’s first proposal is the only way to build computers! And we still believe that creating the tools to tap that power should be built based on that architecture (memory-processor = data-functions)!

Change is inevitable. Even though Alan Kay’s vision from 1965 is still not really realised, it might be coming near now. Developments in hardware like memory and processors really start showing the shortcomings of the “first” von Neumann architecture. Massive parallelism, but especially memory that is so fast that the difference between memory and disk is disappearing, and memory that is persistent, is changing the game in a fundamental way. New computer architectures are desperately needed.

Intel’s 3D XPoint promises memory that is more than a 1000 times faster than flash, and stores more than 10 times more than DRAM. Memory and storage will no longer be different, databases are a thing of the past (everything can be done in-memory, just think about this!).

Architectuurstijlen en ReST

Het is niet eenvoudig om consistent te blijven gedurende implementatie projecten. De toenemende tijdsdruk maakt dat zelfs de beste architecturen sneuvelen in de optelsom van ad-hoc beslissingen.
Eén van de hulpmiddelen die ik met succes heb toegepast is het ontwikkelen van een referentie architectuur of een referentiemodel, of nog beter: een referentie-implementatie. Dit artikel bevat een applicatie-architectuur op een abstract niveau, die ik erg bruikbaar heb gevonden bij het bouwen van zo’n referentie-implementatie.
Het artikel is in het Engels. Klik op het vlaggetje rechts bovenin, of ga naar: Architectural Styles and ReST.

The ArchiMate metamodel

This article introduces a complete, navigable and clickable representation of the ArchiMate metamodel standard (both the 2.1 and the 3.0.1). The model is created using UML. This is not because I wanted to translate ArchiMate into UML, but because UML should be well-suited to define a language such as ArchiMate in. And after all, also the standard itself defines its metamodel using something that looks like UML.

Metamodelling and ArchiMate

Any language needs a specification. What are the rules? What is the format (its syntax)?

ArchiMate is no different. Its specification is part of the standard, published in document format by the Open Group:

The language specification consists partly of what ArchiMate calls its metamodel. For language designers the use of this term in the context of ArchiMate is somewhat problematic, because what ArchiMate calls a metamodel should more properly be defined as a class model. Also the lack of a proper metamodel layer in ArchiMate is revealed by the fact that ArchiMate is not specified in itself, but in what should be regarded as a handicapped UML.

Many people, including myself, have argued for ArchiMate to be specified as a UML profile. Unfortunately this has not happened yet.

(Note: it seems that OMG is actually working on this, and the effort is well underway, even to the level of MOF definitions, which I was very happy to learn)

The reasons can only be speculated upon, since most of the tool vendors were forced to do exactly that anyway. Language users (i.e. architects) need a “proper” metamodel, but that is much more so for tool builders. In fact I would think that the language designers need this as well because I cannot for the life of me imagine how I would go about working on the next version of the standard without a proper metamodel, accessible through a repository-based representation such as the one introduced here. But anyway.

Probably as a result of this, the language specification is inconsistent, ambiguous and contains several errors. This has improved somewhat in the latest 3.0.1 version. This article and especially the models will show these problems because the effort of creating the UML models of the standard made these problems explicit.

The goal of this article is to represent the ArchiMate metamodel as published by the Open Group in a slightly improved format, using “correct” UML. Doing that enabled me to:

  1. create (better) UML profiles for use in tools (using an XMI version of the metamodel)
  2. create much more usable documentation of the standard itself:
    1. clickable ArchiMate concepts, linking to the specification of that concept. For an example, please visit the model, for example the Business Service concept)
    2. diagrams with all defined/allowed relations of a specific ArchiMate concept (for an example, please visit the model, for example the Artefact concept). The standard itself for example provides a table with all allowed relations, containing several errors which are hoped to be corrected soon.
  3. create a “one-pager” of the entire metamodel (something Gerben Wierda also did for his book Mastering ArchiMate, on the 2.1 and 3.0.1 version of ArchiMate) or those parts you want to focus on
  4. extend the metamodel for specific customers
  5. and of course, for this article, detect and document problems (errors, ambiguities or vagueness) in the standard as published 😇

In fact I realised when creating this model that for me as an architect this is an infinitely more usable version of the specification than a stupid thing like a book with pictures.

Note: if your browser does not show the models properly, please refresh your browser cache, since the model is regularly updated.

The metamodel can also be downloaded in XMI format, for you to use in your tool of choice:

About ArchiMate metamodels

The metamodel for the 2.1 and 3.0.1 version of the standard are exported in HTML format. To view the metamodel, please use these links:

As said earlier, the UML this article refers to should be “correct”. Please let me know if you notice issues. However, a few remarks should be kept in mind:

  1. The use of colours is in line with the use in the standard. In 2.1 colours were used, in the 3.0 standard shades of grey were used. We tried to comply to the colouring scheme in the standard.
  2. Attempts have been made to create diagrams that are in line (mainly the layout) with those in the standard as much as possible. The goal was not to improve ArchiMate, but to detect/repair some of its problems.
  3. Multiplicity will be added in the future. As ArchiMate 2.1 states (the 3.0.1 standard is ominously silent on this…), most of the relations are zero or more (* in UML parlance) except where explicitly stated differently. Note that when ArchiMate talks about cardinality, UML (on the class level) talks about multiplicity.
  4. The direction of a relation is still not clear. It is clear what it means in ArchiMate, and what it means in UML, but the semantics of direction in ArchiMate are different from those in UML. We stick to the ArchiMate semantics for now, but I think this disparity is one of the big problems in ArchiMate. In my view, direction is about dependencies, but that is not how ArchiMate sees it.
  5. In this article, stereotypes (for relations or classes) have not been used. Obviously, if you want to create a UML profile for ArchiMate, this must be done.

The ArchiMate 2.1 metamodel

For the entire model, please visit ArchiMate 2.1 metamodel.

Generic Metamodel : Logical Diagram

This is the highest specification of the basic ArchiMate 2.1 concepts. It shows the three “columns”, but not the three layers (Business, Application and Technology) since these are not linked with generic ArchiMate concepts (i.e. there is no such thing as “Technology Layer Element” nor should there be one).

One diagram I added, because it is discussed in the text but not shown in any diagram. It is shown below:

Missing Core Elements : Logical Diagram

The ArchiMate 3.0.1 metamodel

For the entire model, please visit ArchiMate 3.0.1 metamodel.

Top-Level Hierarchy : Logical Diagram
Top-Level Hierarchy : Logical Diagram

The metamodel for ArchiMate 3.0.1, from a language specification perspective, is an improvement over its predecessor. All concepts have now been defined in the model. The above diagram shows the top-level concepts, the most generic ones, this time also including the relationships. It almost looks like a real metamodel!

Of course in the standard these are just pictures, so my hope is you will find these models useful. If you do, please do not hesitate to like this page using the LinkedIn and Twitter buttons in the top right!

List of detected issues

Below is a summary of the issues that I have stumbled on in making the models. The chapter in the standard is provided so that you can compare what the standard says with my proposed changes. The diagram in my repository is also hyperlinked for your convenience.

The elements hyperlinks do not always work correctly (sorry, this is due to the way the tool generated the HTML report, I am working on correcting this).

ArchiMate 2.1 issues

For an overview of the issues, please see the repository where all comments can be found. I have focussed for now on the new ArchiMate 3.0 standard, of which the issues are copied from the repository below.

ArchiMate 3.0.1 issues

“Core Element” and “Element”

There is talk of “Core Element”, but it seems equivalent to what is also referred to as “Element”.

4.1: Behavior and Structure Elements


  1. Diagram Behavior and Structure
  2. For completeness I added the Collaboration concept, which is also an abstract class.
  3. There is a problem in the standard with the abstract classes External Behavior Element and External Active Structure Element. These classes are nowhere explicitly specialised, for example a Business Service should be an External Behavior Element. I expect these diagrams to be added in the next revision of the standard.

4.2: Specializations of Structure and Behavior Elements


  1. Diagram Specialisations of Core Elements
  2. This diagram is not followed through with the specific subclasses of Process, Function and Interaction. Although it would potentially introduce multiple inheritance, these subclasses should be added, for example Business Process as a subclass of Process. Note that multiple inheritance in metamodels is not a problem, but should be avoided in “instance” models. The Business Process/Function/Interaction element is completely equivalent to Business Internal Behavior Element.

5: Relationships


  1. Diagram Relationships
  2. The associations between Relationship and Element show the labels as UML. In the ArchiMate standard (p. 22) these are shown on the other end.
  3. ArchiMate does not specify the multiplicity on the other side (related from). We show that an Element can participate in zero or more relations.

8.2: Active Structure Elements


  1. Diagram Business Internal Active Structure Elements
  2. The standard does not explicitly specify a generalisation relation between Business Internal Active Structure Element and Internal Active Structure Element. That seems to be an error.

8.3: Behavior Elements


  1. Diagram Business Internal Behaviour Elements
  2. One expects this diagram to repeat in the Application and Technology layers. It does not.
  3. I have added the generalisation to Internal Behavior Element, which seems to be lacking from the standard.
  4. There is a consistency problem with Specialisations of Core Elements diagram. This problem needs to be resolved!

Application Function/Process/Interaction


  1. Diagram Application Function/Process/Interaction
  2. This diagram has been added to model the not-really-existing Application Process/Function/Interaction concept properly. As was mentioned with the Business Internal Behavior concept, this concept should be named “Application Internal Behavior” for consistency.

10.1: Technology Layer Metamodel


  1. Diagram Technology
  2. As is noted with the concept, the Technology Process/Function/Interaction should be named “Technology Internal Behavior”.

Technology Internal Behavior


  1. Diagram Technology Internal Behaviour
  2. This diagram does not occur in the standard. Nowhere in the standard metamodel diagrams a Technology Function, Process or Interaction is shown, but its shared generalisation, incorrectly named Technology Process/Function/Interaction is.

11.1: Physical Elements Metamodel


  1. Diagram Physical
  2. In the standard (p. 91) the assignment between Equipment and Technology Process/Function/Interaction is shown explicitly. However since this relation is implied by the already existing one between Node and Technology Process/Function/Interaction in the Technology diagram and thus inherited by Equipment, it is omitted here.
  3. The accesses relation between Technology Process/Function/Interaction as shown in the standard (p. 91) is also omitted here, since it is inherited from the same relation between Technology Object and Technology Process/Function/Interaction in the diagram Technology.

12.1: Alignment of Business Layer and lower layers


Quite a few problems with this metamodel in the standard (p. 96).

  1. Diagrams Relationships between Business Layer and Application Layer Elements, and Relationships between Business Layer and Technology Layer Elements
  2. The Business Actor/Role element should be the Business Internal Active Structure Element since also a Business Collaboration can use an Application Service. We have put the correct element in this diagram.

13.1: Implementation and Migration Elements Metamodel


  1. Diagram Implementation and Migration
  2. The accesses relation between Implementation Event and Deliverable as shown in the standard (p. 99) is omitted here since it is inherited from the one between Event and Passive Structure Element as shown in this diagram.
  3. Same thing for all the trigger/flows between Event subclasses.

13.4: Cross-Aspect Dependencies


  1. Diagram Relationships of Motivation Elements with Implementation and Migration Elements
  2. Because of the realization relationship between Composite Element and Deliverable the same kind of relation is superfluous in the other diagram between Deliverable and Plateau.