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.