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

spp175p1In 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]


  1. Metaphors – great servants of thought, terrible masters. I won’t report you to the ‘analogy police’ however because I took this post to be a discussion about where the evolution metaphor breaks down – when applied to organisational change.

    I have long been an opponent of ‘evolution’ as a way of thinking about organisational change – for reasons akin to your points. Evolution is, for a start extremely wasteful. It is ‘agile’ on steroids – provided we observe over very long timeframes, which is another problem with the metaphor.

    (I also choke on the idea of the sexual reproduction of organisations and the transmission of traits through some kind of ‘it’s-in-our DNA’ metaphor – but I recognise that reaction is a bit literal so generally keep it to myself.)

    Mostly however, I resisted the evolution metaphor at every turn because it is a cliche. And like all cliches it ends up substituting for thought, short circuiting observation and questioning in favour of easy self-evident propositions and conclusions.

    I was nice to see someone else take that lazy metaphor out to the garden for a quiet chat about its behaviour.



  2. Bit heavy on analogies but totally agree with your conclusiona. Also, how many organisations really have effective today EA really? I guess you end up describing EA V.nezt.

    Next trick is how do we redesign the Industrial Age organisations into something more organic and appropriate for the speed of change that digital enables. Answers on a postcard. 🙂


  3. The analogy police can rest easy, but maybe not the pedantic police.

    It is, of course, impossible to imagine an organization without enterprise architecture, because there can never be any such thing. All organizations have an enterprise architecture – they always had one, way before IT ever came along, and will continue to do so. Processes, information, organization setup………

    Now, of course, it by no means follows that the fundamental existence of an enterprise architecture requires the presence of an EA team to design/manage/govern it, and in fact, companies have managed without for most of modern history-

    But, in all seriousness, I think it is useful to distinguish between the architecture itself and the existence (or not) of framework and teams responsible for managing it. The overall premise in the article: that organizations can use EA to avoid leaving it to chance through an evolutionary approach (but only if architecture is performed in the right way) is clearly unarguable.

    (BTW, the keynote today delivered exactly the kind of thought provoking message I’d have expected at the Gartner summit. Very much enjoyed it.)


    1. Thanks, Chris.

      I agree EA is (almost by definition) not about IT, but I agree with Charles Rosenbury that the need for what we now consider to be EA has risen from the enormous rise in complexity of organisations, a rise that has only become possible as a result of IT. See The Great Escape — EA is not about IT!. The effect of IT on enterprise has been huge, so huge that much of enterprise now is IT, not just ‘supported by IT’.


      1. Yes, I totally agree with the thrust of that second piece. ‘EA in not about IT’ cannot be true. ‘EA is not ONLY about IT’ might be closer.

        It’s a small distinction; the problem is that by emphasizing the IT-centric nature of modern EA, we run the risk of pigeon-holing ourselves as solution architects / techies in the eyes of some business people. And that’s unhelpful for an EA group with ambitions to practice a business-outcome driven style of architecture, and be recognized as such.

        I always advocate positioning EA first and foremost in terms of outcomes, rather than emphasizing any particular aspect of of the architecture. If those outcomes are successfully delivered, it’s less important for EA clients whether it was done predominately by managing IT complexity or via some other approach.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: