Putting the brakes on “capability obesity”
Microsoft IT made a bet, a couple of years ago, on using capability modeling in our own internal Business Architecture program. That required us to have a shared and consistent hierarchy of business capabilities that we would use across all lines of business.
At that time, we adopted principles like MECE (“Mutually exclusive, comprehensive, and exhaustive”) to provide guidance about the contents of the capability hierarchy itself. We set up a process for the team to manage the hierarchy and insure that the principles were followed.
The team did NOT create other hierarchies, and simply “de-scoped” any discussion of a business process hierarchy or a platform feature hierarchy (those artifacts would belong to other teams, you see).
What happened?
The Business Capability Hierarchy (or BCH) grew fat. If we needed a taxonomy element because we were doing platform rationalization, we’d throw it into the BCH. If we needed a list of features so that we could compare vendor products (buy vs. build), we’d throw those in to the BCH as well. The stuff that got thrown in was “worded” as a capability, but it’s hard to know if it wasn’t just a reworded business process or system feature. It’s easy to make things unique. Just add words.
The result is not satisfying. Our current taxonomy is over 2,200 items long. In many places, it is five levels deep. That is really big. Too big. There are more capabilities than there are business systems. More capabilities than there are processes. More capabilities than there are roles. More capabilities than there are business objects. If the point was to be a place where we would consolidate information, we’ve blown that out of the water.
Even if I filter the hierarchy to only show me Level 3 elements, it is still over 650 elements long. Still too big, but if we limit ourselves to level 3, we can put two or three systems under each capability. That’s something. But not enough.
My advice to other companies who are adopting capability modeling: adopt a rich set of “management principles” early on:
| Principle | Implication |
| The Magic Number Seven (plus or minus two) | Level 0 has one item. At each level below, there are exactly seven elements (plus or minus two). If not, re-balance. |
| Only Level Three Matters | Levels 1 and 2 are for navigation and nothing else. Make associations ONLY to level 3 items. Level 4 is documentation. Level five is not allowed. |
| No system features | The capability hierarchy must not be used for feature-by-feature product comparisons. Leave features out. |
| No process variations | If the only difference between two “capabilities” is the process that a person is following when they perform it, merge them. Let the process hierarchy handle that distinction. |
| Three mappings per application or process | If you map an application or a business process to the capability hierarchy, it will map to three capabilities, at most. If the app or process maps to more capabilities… you have too many capabilities. Merge branches to reduce the hierarchy. (Twist: platform products like SAP should be mapped module-by-module.) |
| Comprehensive and Exhaustive | Leave nothing out. Don’t just focus on the value chain processes. That will mean that you use valuable “space” to cover supporting processes. This is a good thing. |
Net result, your capability hierarchy is unlikely to exceed 300 items. Best if you can keep it under 200. Anything more than that, and even your best architects cannot learn it. It becomes fat. An obese capability hierarchy is not an effective tool for strategic planning. Take my word for it.