Link: http://weblog.tetradian.com/2013/03/19/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?
