Losing a Limpet – What happens when we don’t have Enterprise Architecture?

Recently, I had a conversation with someone about how to do enterprise architecture. I prepared that conversation by trying to condense my basic argument for the`enterprise chess‘ approach to the absolute minimum. I started out with the question: “Suppose we don’t have enterprise architecture at all. What would happen?” and it led to an interesting train of thought, involving adaptive change (or evolution).

Imagine an organisation without Enterprise Architecture. What happens (except bliss for many)? Well, for one thing, change still happens. All the time. Al kinds of initiatives take place to change the organisation, from new versions of existing tools (with slightly different behaviour) to whole new business lines. We might look at this as constant ‘mutations’ happening in the organisation. It is a kind of `evolution in action’, but without the normal key role of offspring in expressing new traits that is key in biological evolution. Different, but still a useful analogy.

Now, evolution has in general a very positive press in our educated circles. Indeed, attempts have even been made to harness the power of evolution by ‘breeding’ better software algorithms (evolutionary algorithms). Why design if the ‘invisible hand‘ can do the job? The over-enthusiasm of the initial period (think Kevin Kelly’s 1994 book Out of Control) has long since gone, and for a good reason. Evolution — powerful as it is — is namely not that ideal as it first seems: evolution as a `design process’ is (from our human/ethical perspective) wasteful and thus (for those evolving) risky. How risky, an example may illustrate:

Losing a Limpet

In biological evolution, multiple independent issues can in their combination lead to killer problems. In the book Eight Little Piggies (by the late Stephen Jay Gould) there is a description of a recent example of Darwinian extinction, titled Losing a Limpet. It is about the Eelgrass Limpet, a sea snail that exclusively fed on eelgrass. The Eelgrass Limpet was last seen in 1933 and is considered extinct. What likely happened was that when a slime mold decimated (but not entirely killed off) the eelgrass, it led to the end of the limpet even if the eelgrass itself survived. This happened because the Eelgrass Limpet could only live in sea water of normal salinity, whereas eelgrass can also live in brackish water, where the slime mold could not go. So, the eelgrass survived the onslaught of the slime mold and repopulated the saline waters afterwards. Other species that fed on eelgrass also survived, even if they were decimated for a while, because they were able to switch to other foods (or live in brackish waters). But the Eelgrass Limpet could only survive on eelgrass and only survive in saline water. The narrowness of its `ecological niche’ led to its extinction. Thus the ecological landscape changed and with the extinction of the Eelgrass Limpet, new opportunities to fill a new niche arise.

The extinction of the Eelgrass Limpet is a good example to drill home the point that biological evolution works via death and extinction. Death happens to members of a species that are less well adapted to their niche, extinction happens to species if its members are unable to produce enough offspring (e.g. because they die before they get the chance). Niches change, sometimes slowly, sometimes catastrophically. That death is a main agent in biological-type evolution is something to keep in mind if again someone in earnest starts to suggest (like in Kelly’s book) that in the end we will be creating software for airplanes using evolutionary approaches. It will work, that we might assume, but how many planes will have to crash before the perfect airplane software has been bred? Kelly writes:

Artificial evolution is the end of engineering’s hegemony. Evolution will take us beyond our ability to plan. Evolution will craft things we can’t. Evolution will make them more flawless than we can. And evolution will maintain them as we can’t.

Evolution will maintain them certainly in a way we are not allowed to, given the human sacrifice and something called `ethics’. Kelly does not want to test the software by crashing airplanes. He assumes we can co-breed the ‘crash agents’ in a virtual world. How that should work, someone should explain to me (as I think there are fundamental hurdles here, akin to the ones Hubert Dreyfus wrote about in What Computers (Still) Can’t Do), but I digress.

Evolution in the enterprise

Transferring this to the constantly changing organisations we are part of: if we leave all those changes in an organisation to their own devices, they might lead to combinations that makes it hard to survive, let alone thrive, a hair ball architecture of sorts. We might — like the Eelgrass Limpet species ‘did’ in evolutionary terms — paint ourself in a dead-end corner if we let the constant mutation of the firm unchecked.

Death and extinction play a role in the economy as well, as we all know, in the form of the bankruptcy of firms and the demise of whole industries. The link was already made in Darwin’s time, at least partly by Darwin himself who was influenced by Thomas Malthus and also likely by Adam Smith, the founding fathers of modern economic theory.

When comparing what happens with firms to what happens in biological evolution, we are talking about the level of an ‘industry’. Enterprise architects, of course, work at the level of the individual enterprise, which is of course different (more `generic’ evolution without the ‘inherited traits’, more ‘mutation’ than ‘evolution’).

Having said that, what an organisation is trying with enterprise architecture can (at least in part) be seen as fighting some of the nasty side-effects of unchecked evolution. We enterprise architects are in fact fighting to make the evolution of the firm less wasteful and risky. We’re not the only ones to try to do that. Project and program management (and general management too) are trying to do the same. The important insight here is to keep in mind that we enterprise architects are not just helping to direct the way the firm evolve as if the firm would not evolve if we were not there. We’re not designers in a greenfield. No, the firm evolves anyway, move by move in enterprise chess terms, and what we are actually try to do is change the way that evolution happens, so the firm makes better `moves’.

This view of things also explains the fight for ‘agility’, in a way. All our attempts at control over autonomous fragmented change, all our efforts to fight blind evolution (all kinds of management, including enterprise architecture management), constantly triggers a counter-movement. From the ‘rapid application design’ of the 80’s to ‘agile’ now, attempts to smother the evolutionary free-for-all naturally lead to resistance by those that are being smothered. The natural mutation drivers of the firm (its people) are constantly looking for ways around any limits set for them. That is not something one should try to prevent completely (as some architects may dream of), it is a life blood of the organisation. But — taking the analogy in another direction — too many unchecked mutations all over the firm may lead to cancerous growths in your Business-IT landscape and even its death.

It’s also a bit as if we are watching the battle between the bacteria — (undirected) biological evolution) — and the antibacterial drug designers — (directed) intelligent design), with enterprise architects playing a pseudo-scientific god, or at least with the hubris as if they were a god. That gives us a nice definition of the classic `enterprise architect’: `intelligent designer’ of overwhelming complexity, without the god-like powers to back that up. That aspect of enterprise architecture has to change, I think: instead of behaving like a god (or a building inspector, see: Are you an Enterprise Architect? Really?), maybe enterprise architects should just behave as … architects. And they really need better `best practices’.

PS. Maybe it is now time for you to report me to the analogy police. I’ve been making such a mess of it: mixing evolution, biological evolution, mutation and so forth, that the fact that most of you will understand me at all is a nice example of the fact that human intelligence does not need clear logic for understanding. Similarity (Familienähnlichkeit), is enough. Uncle Ludwig strikes again 😉

[If you want to discuss my views with me: I will be speaking at the Gartner EA Summit 2015 London UK on May 20 and the MBT-Congress in Houten NL (closing keynote) on May 21]