Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance.  I’d like to caution that this description is a concept rife with conflicts.  I’ll explain in a moment.

For those of you who don’t have a copy of the Bizbok 5.5, first off, get one.  But for the sake of expediency, the description I’m referencing comes from section 2.2.  in a subsection titled “The Capability Instance”

“As a rule, capabilities exist in multiple business units and enable multiple value streams and value stream stages.  As a result, a useful concept called a “capability instance” has emerged that allows practitioners to associate unique attributes, such as effectiveness or automation levels, with specific instances of a given capability in practice.  A capability instance is defined as “a specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit, value stream, or other situational context.”  In practice, identifying capability instances provides the business architecture practitioner and consumer with flexibility to assign unique heat map values and other ratings to a capability based on its effectiveness or impact within a given business unit or value stream.”

OK… so why my concern?

Almost a decade ago, I set out inside Microsoft to stop the raging debate about the definition of capabilities.  At the time, our business architecture team was using the concept of capabilities derived from the Microsoft Motion framework (very much like the definition used by the Business Architecture Guild today) as composed of People, Process, and Tools.  (We added “Information”).  However, the Business Process Innovation team was busy creating certifications for Six Sigma that describe processes as having people (in roles) and tools under the activities.  They saw no value in the concept of a capability at all.  I got my Six Sigma Green Belt and saw the problem.  Their use of language was sufficiently different from the words used by Enterprise Architecture that our two teams were creating problems for one another.

During this time, I blogged rather extensively on the difficulty of aligning these concepts.  I went back to source materials from such thought leaders as Michael Hammer and Michael Porter and held lengthy conversations with teams involved in business process management as well as business architecture.

The results, which I presented at the BPM conference at Stevens Institute of Technology, was that we could bring together business process management and business architecture if we recognized one very important principle: a business capability is a concept.  It cannot be realized.  A business process is a conceptual description of a realizable set of activities.  A process description is only interesting once the process is realized.  They are different in the ability to realize them.

A business capability is a concept.  It cannot be realized.

In that frame of mind, when I discuss measurement of a capability, I measure the maturity of the constituent elements.  I measure the people, the processes, the tools, and the information independently.  The capability measurement, if used, is a score of these four individual elements.

(Bizbok uses different framing: they now view a capability as composed of Organization, Value Streams, Resources, and Information, a distinction that I’m stepping over for now… a deeper discussion for a different blog post).

The point is that the notion that you are measuring the effectiveness of a capability is silly.  You are measuring the effectiveness of a business process.  You are using the concept of a capability to allow you to compare completely distinct business processes that have similar impacts on the organization.

The moment you cross the line and allow yourself to view a capability as something that can have an instance, you also cross the line between “what” a business does, and “how” a business does it.  The value proposition of the business capability concept collapses if you cross that line.

I soundly reject the notion of a capability instance as a mechanism to measure and apply attributes that belong in the world of business process measurement and management.  If there are other uses of the capability instance concept, I’m open to them.

Note that it is OK to create a score of a capability in a specific instance.  Is that a measure of a capability instance?  In a way, yes.  For example: the score of an accounts payable capability in customer refund handling is distinct from the score of an accounts payable capability in vendor management.  By comparing these scores, am I measuring the effectiveness of a capability instance?  No.  That’s a measure for the underlying process.  It’s a carful distinction.

Make the distinction.

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".

2 thoughts on “The Capability Instance – can capabilities be realized?”
  1. Interesting blog. Good explanation. I wonder how you would measure the maturity of a capability. And how to deal with that.
    Btw when talking about capability instance I’d rather think about the organizational concept …. Role having a goal major tasks and skills and personal profile.

  2. Hi Harry, A capability is different from a capability instance. It is the global concept of a capability. So if the organization has multiple instances of the level 3 capability “acquire customer”, then the maturity of that capability is the maturity of the organization as a whole to acquire a customer, not the maturity of one specific instance.

    So what if we are discussing a retail bank. One line of business is for retail checking accounts. In that context, “acquire customer” is a capability that is fulfilled through marketing and the placement of locations convenient to retail customers (in the US, it is not uncommon to see branches of a bank in a grocery story. These are primarily locations for acquiring customers for checking accounts.

    A different line of business would be home loans. Acquiring a customer is often more successful if the customer already has a checking account at the bank and trusts the bank. So in this context, acquiring a customer is often a matter of closed marketing — marketing to your existing customers. Of course, there are customers who are acquired through other means, such as purchasing a loan from a broker and marketing to non-customers who then get both a home loan and a checking account.

    How do you compare the maturity of the “acquire customer” capability across two very different lines of business? To be fair, you probably don’t. You CAN compare some elements of that capability, and I would suggest that it makes more sense to break the capability down one more level and compare those elements. How well do you do acquisition planning? Acquisition scenario analysis? Online acquisition tools? etc. At the level of “customer acquisition”, comparison, and therefore enterprise maturity assessment, is neither meaningful nor useful.

Leave a Reply

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

3 × 3 =

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