One of the key elements of a business architecture is a reasonable taxonomy of the capabilities of the business. For those folks who are not in business architecture, a business capability model is a hierarchical taxonomy of business capabilities that represents the entire breadth of the enterprise. The business capability model should be “MECE” (pronounced ME-see) which stands for Mutually Exclusive Comprehensive, and Exhaustive.

One of the problems we have is our own creativity. We can easily create a taxonomy that has thousands of different end capabilities. We know that human beings are really good at creating a huge taxonomy. We’ve done it over and over. The dewey decimal system in libraries is a MECE taxonomy. The list of all living things (animal kingdom, plant kingdom, etc) is a MECE taxonomy. The periodic table of elements is a MECE taxonomy.

We can break things down to a gory level of detail. But we shouldn’t. Why? Because the capability model is a tool. It doesn’t become a better tool or a more appropriate tool by making it too large to be useful. I recommend you keep the total number of entries under 300 and the total number of “levels” to four or fewer.

So a good model may have 250 elements in three levels.

And a bad model may have 750 elements in five levels.

But why would it be bad to list out 750 different capabilities? A couple of reasons come to mind:

  1. One of the activities you will do hundreds of times is to “map an application to a capability”. That means an analyst will look at a record of an application and will need to select one or more capabilities. This is called “mapping.” By selecting a capability, this analyst is recording the fact that this application is used by people involved in this capability to provide necessary value in that capability. If you have more than 300 capabilities in your taxonomy, this activity becomes DIFFICULT to do well.
  2. The taxonomy of capabilities quickly blends into becoming a taxonomy of business processes after about level two. But the tools and techniques of business process management are not well suited by a MECE taxonomy. It is normal for business processes to occur multiple times in different ways in an enterprise. In a MECE taxonomy, you can only record it once.
  3. The way a capability is used includes portfolio simplification, data mastering, and investment analysis. Three levels can be illustrated on a single diagram to support those purposes. Four levels can barely fit. Five levels with more than three levels makes the taxonomy too large to fit into a single page or poster diagram.

So in your capability hierarchy, if your stakeholders WANT to go deeper than three levels, suggest an alternative approach: allow them to list out their business processes, listed under a capability.

It is perfectly appropriate to create an entire taxonomy of business processes under a single business capability. However, in business architecture, we don’t map the applications and technologies and teams and information items to the business processes. We map them to the capability.

So limit yourself. A business capability model needs to be succinct to be useful.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

Leave a Reply

Your email address will not be published. Required fields are marked *

seven + 17 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.