On not eating the elephant
How do we make sense of an enterprise? Is analysis the best or only way to do it?
That now long-running LinkedIn thread about capability, function, service and process that I referenced in a couple of recent posts just keeps rolling on, and unusually well, too. Most recently it was this post from JD Beckingham that caught my eye:
Folks — the enterprise is an elephant composed of many, interacting parts. The trick in EA is to “cut your food into smaller pieces” – organizational structure, capabilities, processes, value streams, value chains, value systems, information, applications, infrastructure, etc. – before attempting to eat it.
This is why clear, concise, workable definitions of “Business Capability, a Business Function, a Business Process and a Service” are important.
“Agree 100%”, one person instantly replied; “Agree 200%”, said another. Yet whilst I do agree with JD’s overall sentiment on this, I’d have to say that I’d agree only “kinda 50%” – because there’s a crucial rider that needs to be added here.
Okay, I’d agree 100% with the second part, about “This is why” – no question there.
It’s the first paragraph that I’m more troubled about: I’m very, very wary about that statement that “the enterprise is an elephant composed of many interacting parts”. Sure, that’s a useful way to describe it; yet there’s a real yet subtle trap there, because “composed of” is actually not true – not in and of itself. In reality, the notion of “composed of” is an arbitrary view into a whole; the notion of “parts” is a view into a whole; they’re ways we may choose to partition out a segment (“the elephant”) from the whole (the ecosystem, within ecosystem, within ecosystem…) and then further partition out segments (“components”) within this selected-out ‘the elephant’.
“The trick” called ‘analysis’ – breaking the view of the whole into more manageable parts – is, yes, really helpful when trying to make sense of an elephant, or an enterprise.
The trap called ‘analysis’ is in thinking that analysis alone is enough, because it leads us into thinking that the ‘component’-boundaries that we select are real, and that the collection of ‘smaller pieces’ that we select out is, ultimately, just a collection of independent, isolated parts.
We can choose to view an elephant in terms of ‘components’; we can choose to view an enterprise in terms of components such as ‘capability’, ‘function’, ‘service’ and ‘process’. But that isn’t the elephant or enterprise itself – just the way that we have chosen to view it.
The boundaries are what we choose, too: and if we forget that, that’s when we get into all those ‘which contains what?’ tangles, around process versus service versus function versus capability. They’re all just views into a whole: they’re ‘separate’ and not-separate, all at the same time.
The enterprise is composed of parts; it is also, always, a whole, itself as itself; and also, always, a ‘part’ of something greater than itself. Analysis splits things into parts; yet always goes hand in hand with synthesis, combining parts into wholes. If we ever forget that, in architecture, we’re in real trouble straight away… so be wary here, please?
Personally, I think “eating the elephant” is a singularly icky metaphor, if only given the state of the elephant population in the world. The advice to “eat” the problem one bite at a time seems pretty reductionist, in a time when systemic thinking is required.
I know this wasn’t your metaphor, Tom, but I’d put it right up there with with “let’s not boil the ocean” for unhelpfulness. Boil the ocean? Eat the elephant? Who the hell would want to?
Yeah, exactly. Kind of a reminds me about someone’s comment that “a metaphor is a leaky bucket: we can only carry it so far before it runs dry”. 🙂
Hi Tom,
You make an excellent point about the dangers of reductionism. The point about views on the whole rather than parts of the whole is excellent.
You end the post with ‘be wary here’ – can you elaborate on some of the things to watch out for? What are the traps and danger signs if we rely solely on ‘sub-system’ rather than ‘system’ thinking?
Regards
Mike
@Mike: “What are the traps and danger signs if we rely solely on ‘sub-system’ rather than ‘system’ thinking?”
Thanks, Mike – and yes, sure, will do. Most of them are traps that we know about, yet keeping falling into, time after time, including:
— silos: “as long as our bit’s fine, the rest can keep care of itself”
— solutioneering: “this is The Answer! – now what was your question?”
— ‘best practices’: “this worked well somewhere else, so it must work well here” (this is actually a variant on solutioneering)
— self-centrism: “business-architecture is anything not-IT that might affect IT”
Return to reductionism does tend to be an automatic default in most (business)-cultures: we don’t need to go into the details as to why here, more just note that it’s so, and hence aim to design-in appropriate mitigation for the concomitant risks. For example, I use various catchphrases to keep reminding people to ‘think system’, such as:
— “It depends…” (to avoid simplistic solutioneering)
— “Just Enough Detail” (to avoid ‘boil the ocean’)
— “Everything is or represents a service” (to assist in thinking consistently across the context)
— “Everywhere and nowhere is ‘the centre’, all at the same time” (dissuade ‘self-centrism’)
— “Start anywhere” (to remind about the systemic-characteristic of ‘everything is connected to everything else’)
— “Link inside-out with outside-in” (multiple perspectives within the same system)
— “Think holograph, not photograph” (reminders on ‘everything connects’, ‘everything supports everything else’, ‘everywhere is ‘the centre”, ‘just enough detail’ and ‘multiple perspectives)
Any other suggestions from your own experience?
This is something I learned from my younger brother many Christmases ago – being able to take a watch apart may give you some insight into how it works, but having all the parts is not the same as having the watch.
Yep! And also that crucial distinction between machines and living-organisms: machines can be taken apart to individual components and (we hope!) will work again in the same way when we put them all back together again in the same order; but that doesn’t tend to work with animals, organisms or enterprises… 😐
I think this is a nice example of one of the biggest differences between enterprise architects and real architects like Frank Gehry & Norman Foster. Enterprise architects deal with existing elephants. Gehry and Foster create there own new species.
I’d have to disagree with you there, Peter: to me it’s pushing a metaphor too far. For example Gehry or Foster create new buildings, but what they do is still only ‘buildings’ and the context within which that building exists – it’s not a fundamentally-different deliverable, which many enterprises do in fact do.
A perhaps closer metaphor is the overall enterprise of transport – including transport of things, people and information. New technologies and capabilities enable entirely different enterprises of transport: look at the impact of the arrival of the horse in north America, for example, or the invention of the sail. Look at the impact of canals on goods-transport, or aircraft on people-transport, or satellites and fibre-optics on information-transport.
People like Gehry and Foster use these technologies and capabilities – often in very inventive ways – but they don’t create the technologies or capabilities themselves (“new species”, as you put it). Enterprise-architects tend to focus more on the ‘how’ of those innovations, whereas building-architects tend to focus on the ‘with-what’; good architects of both types also remember to focus on the ‘why’ as well. Yet those differences don’t necessarily make Gehry or Foster ‘better’ than enterprise-architects, as you seem to suggest: it’s just different. (And trying to make out that a mere difference in scope or focus is ‘better’ is itself bad-architecture, surely?)
Hi Tom,
There is a reason that I use Gehry and Foster as examples. It is because they don’t look at just buildings and their context. They are very keen to learn from other professions and working together with modelers, engineers and all other stakeholders to (trying to) realize their ideas (including new infrastructures, technologies and capabilities).
So yes, for me they are without doubt the better architects…
Again, great thinking being shared here – thanks, everyone.
So, questions that emerge for me:
a) what would be a better metaphor?
b) what would be more helpful language for us to use?
“making sense of an enterprise and its potential” is a far better expression than EA which invokes so many counter-productive connotations (thanks to Len F for insights into denotes vs connotes!!)
I am now using the expression enterprise-modeling rather than enterprise-architecture, for example. It is less wrong-meaning-laden and more consistent with our ecosystem thinking where modeling is the appropriate term in the biological setting, so why not also in the organisational setting?
The “elephant eating” bit has two limitations:
a) it focuses us on content and loses sight of context – our profession brings value through integrating context and content
b) it focuses us on parts and loses sight of systems – our profession brings value through the understanding of these two orthogonalities
@Peter — A quick take here. In terms of metaphors, the elephant part isn’t so bad, it’s the “eating” part that I personally object to. I don’t so much object to the elephant part because at least we’re talking about a living system in some context. I personally think this is much preferable to mechanistic metaphors, such as buildings, aircraft, and the like.
In terms of non-metaphoric language, I have appropriated the word “enterprisology”, for the study of enterprise, and coined the term “enterprisography” for the representation of the results of such study. This after another in the endless rounds of argument over the meaning of architecture 🙂
Peter: strongly agree with you about “our profession brings value through integrating context and content” and “our profession brings value through the understanding of these two orthogonalities”.
Here is a potential metaphor – noting that any metaphor has limitations – enterprise radiologist : one with the capacity to offer visibility to that which is not visible and to provide advice as to the significance of irregularities.
Of course, this only cover the gap assessment – it does not handle the treatment, recovery, growth aspects
Yep: useful metaphor.
Another nice metaphor that someone came up with around a year ago: ‘corporate cartographer’. (Peter Bakker would no doubt be happy with that one! 🙂 )
We’re mapmakers: and there are some very important and influential choices and emphases that arise from what we choose to include or leave out of each map that we create. It’s also very much about the process of mapmaking, the exploration, the methods of assessment and measurement, the schemas that we use to identify existence and relevance and relationship: the map itself is perhaps merely the ‘decision-record‘ that we leave behind after we’ve passed through.
I’m happy 🙂 because as Denis Wood says:
Source: “Sébastien Smirou interviews Denis Wood for LIGNE 13, No. 4, 2011” – http://www.deniswood.net/content/LIGNE13.pdf
Someone shared the map maker metaphor in EAN. I like it as one part of our role – that part that describes what we see that exists – it is not helpful though in terms of envisioning what might exist. In that sense, we are more of a navigator aiding the captain in exploring uncharted waters!
Peter,
The map maker metaphor is extremely useful for visualizing the Terra Ingocnita and the dragons that might exist there 🙂
See my comment on http://weblog.tetradian.com/2013/03/28/control-complex-chaotic/#comment-6217 for an example.
Typo: Terra Ingocnita should of course be Terra Incognita
And this is why I mentioned the dragons: http://en.wikipedia.org/wiki/Here_be_dragons 🙂