Posted by Derek Miers on May 24, 2012
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?