Groupthink And The Problems Of Silos

I think we would all agree that BPM and business architecture set out to overcome the issues associated with silos. And I think we would also agree that the problems associated with silos derive from functional decomposition.

While strategy development usually takes a broad, organizationwide view, so many change programs still cater to the suboptimization perspectives of individual silos. Usually, these individual change programs consist of projects that deal with the latest problem to rise to the top of the political agenda — effectively applying a band-aid to fix a broken customer-facing process or put out a fire associated with some burning platform.

Silo-based thinking is endemic to Western culture — it’s everywhere. This approach to management is very much a command-and-control mentality injected into our culture by folks like Smith, Taylor, Newton, and Descartes. Let’s face it: The world has moved on, and the network is now far more important than the hierarchy.

But guess what technique about 99.9% of us use to fix the problems associated with functional decomposition? You guessed it:  yet more functional decomposition . I think Einstein had something to say about using the same techniques and expecting different results. This is a serious groupthink problem!

When we use functional decomposition to model processes, we usually conflate the organizational structure with the work itself. Rather than breaking down the silos, this approach reinforces them — effectively putting them on steroids. And when other techniques emerge that explicitly remove the conflation of process and organizational structure, those who are wedded to old ways of thinking come out of the woodwork to shoot them down. Examples include role activity diagrams (Martyn Ould), value networks (Verna Allee), and capability mapping (various authors, including Forrester analysts).

Even within the business architecture community, I hear the same issue coming over again and again. For example, a recent speaker at our EA Council meeting in Las Vegas was outlining how his organization had focused on the services delivered to external stakeholders and built capability maps to represent the enduring purposes of the organization. But then he said that he was still struggling to “make the decomposition from capabilities to processes.”

Another example was the head of EA for a major energy and services conglomerate talking of his “target operating model,” which was no more than a functional representation of the organization stuffed into his repository tool of choice (in this case, Aris).

A “target operating model” represents an optimal future-state business architecture that acts as a rudder for business improvement projects and initiatives. It’s a rich, layered set of perspectives and models that can integrate the agendas of the CMO (driving toward better customer experiences), the COO (driving operational efficiency), and the CIO (who, among other things, is struggling to improve an aging application portfolio). 

So what do you think? Is functional decomposition the problem? Or is it the answer?


To err is human

Hi Derek -

Conflating a model of reality with reality is a dangerous intellectual conceit.

Models are burdened by design-time assumptions that are fine for discussion purposes, but models should not be implementations as they are with BPMN.

A static model is based on fixed assumptions, it's context is set at design-time. It is unyielding to real-world events and unique requirements. To implement static models at run-time is to optimize for standardization (ie bureaucracy) as opposed to goals. This leads to lost business value and/or shadow systems/informal processes.

Models should be used as heuristics, to guide execution, not enforce proceduralism.


Hi Derek, It is true that we

Hi Derek,

It is true that we have over the past few decades applied FD - to fix silos, among other things. We have decomposed the 'enterprise' by a variety of functions (groups of transactions, information based, departmental, value chain, etc.), and it does seem like the problem of silos is still around. But in a sense, we seem to have more accurately defined the 'approach' but use the term 'silo' rather vaguely. IMHO each time, while one type of silo disappears, a new type appears and so I guess although 'silos' have been around, the nature of silos has been changing. So although I can't really say for sure if the problem is in the FD, I can tell it will take a big leap to escape from a FD approach. Besides, when it comes to processes, it can be argued that in a classical sense, 'process' itself is a result of a functional decomposition.

It's a 'round trip' problem

Good challenge to us all. I have a somewhat different take: functional decomposition is fundamental to description, and a key part of understanding. It is an important technique for solution design, and essential element in monitoring. It is the problem you describe when decomposition is taken further than the purpose you need, when you don't round-trip from the decomposition to the whole, or when you get into a recursive loop of decomposition.

To describe a Target Operating Model, the capabilities in a Capability Map, etc, you have to decompose them into their underlying elements. There should be intelligence applied to this decomposition: decomposing business capabilities into smaller capabilities until you are 4-5 levels deep is almost always a mistake - which is why we say to decompose them into processes, information, functions, assets, goals, metrics, etc. You can say a similar thing about understanding: you have to know how the elements contribute to the whole to understand change impacts, etc. Solution design is about changing the elements - which has to be done in the context of the whole. And for the purpose of developing a monitoring regimen, such as KPIs, Goal Tree Analysis is still the best way to identify how metrics at a detail level indicate the health of the whole.

What we need to do is to avoid unneeded decomposition, and then relate the elements to how they fit with the whole. Good job for us!

Just Wondering...

Is there really, really any - Essential - difference between FD and BPM?

Isn't Western culture literally Posessed with Having, Having and again Having? Having silos, for instance? Isn't it true that Western culture (almost) completely lost sight of / touch with balancing Being and Having resulting in balanced (vibrating) Be-Have-iour? [1], [2], [3]

Don't we hasten to concentrate on business on the one hand and technology on the other hand? In doing so... doesn't this collective groupthink make that we 'simply' overlook the crucial hinge-point that - in one-and-the-same coherent 'move' - connects as well as seperates the 'leafs' business and technology? [4] Couldn't it be this hinge-point that productively can dissolve silos?

[1] On Human-Havings (,
[2] An Architecture of Be-Having (
[3] On Being Alive (
[4] The Core of Information-Oriented Architecture (

Derek, thanks, your article

Derek, thanks, your article lays down a very relevant challenge. A couple of points.

You're spot-on with the observation that the inability to get away from 'functional decomposition' is largely a cultural constraint. Breaking out of silos often means questioning the very processes of which stakeholders' empires are comprised, so its usually safer just to tweak the existing silos. In particular more hierarchical organisations naturally enforce this kind of constraint.

Your Einstein quote also hits the mark, as to be able to understand alternatives to current silos, it is necessary to use techniques that encourage a different perspective than the current, 'functional', process view of the world. Working within current processes thinking will just lead to more of the same. Rather the key here is to use methods that emphasise abstraction and re-definition, those that could lead to killing-off the boss' empire!

Dave made a good point about

Dave made a good point about static models. You can't account for every potential variable, but models offer some degree of control. However, models do not have to be set in stone. Business issues evolve, grow and even disappear. It's important that our models offer a degree of flexibility to reflect that.