‘Capability’ – the micro-trendy word on its way to failure unless…

Is it just me or is the word ‘capability’ becoming a micro-trendy word and losing its meaning? I personally liked it b/c I love ways in which to communicate at abstract levels however it is so overloaded these days that I now try to avoid it and find myself cringing when hearing it misused.


In the context of different enterprise architecture, domains like the Business Domain, Application Domain and Technology Domain and at different IT organizational levels like the Senior Execs, Middle Management and project teams the word 'Capability' means entirely different things causes heaps of confusion.


I suppose that the proliferation of the word indicates it has a bit of merit in the right context and it should be used. But at as a result, those who like to spout their knowledge based on no understanding of the subject often misunderstand it and more often than not use it inappropriately. This leads to utter frustration and the need to find another word leaving a bit of damage to the proper use of the word 'capability' that only time will heal. This situation looks awfully familiar doesn't it? I can think of many more words that have suffered the same fate such as Architecture, Strategy, Risk, Quality, Pattern, etc. as well as SOA and ESB over the last few years too.


In the Business Architecture Domain, 'Capability' refers to the highest-level business functionality encapsulating People, Process and Technology. ‘Capability’ also refers to the value or result of a Business Process sometimes refered to Business Process Capability. In the Technology Architecture Domain, the word 'Capability' often refers to the functions an IT asset provides - I think of these as features or feature sets of a technology. I heard a senior IT executive use the word 'Capability' to describe the existence of a single master the other day. Whoa! Hold on a minute! All of these uses of the word ‘Capability’ are correct but have totally different meanings and it is now cause the word to fail to communicate.


Sidebar: I had a chat with a Business Architect colleague of mine yesterday on the word 'Capability' and they found themselves describing a business process and not a business capability. We resolved that the litmus test for identifying a business capability and not a business process isn’t so much to work from the definition itself but rather to check that the object/entity that you have identified has people, process and potentially technology included. If so, then you have a business capability. If what you have found describes what people do, then it is a business process


One way around this is to add a prefix or qualifier to help ensure the integrity of the meaning of the word.  This will help maintain the meaning of it and increase the longevity of the word.


We should instead talk about ‘Capability’ in conjunction with a domain or other qualifier like Business Capability, Technical Capability, Process Capability, Business Solution Capability, etc.

Comments (4)

  1. Bill says:

    Good Blog

  2. Jill says:

    I’m very interested that you have tried to distinguish between a business capability and business process.

    I would like to understand your rule of thumb in a bit more detail – can you elaborate please, perhaps give an example.  

    [The business process “Write letter” involves people (e.g. me), technology (my PC) and process the steps I go through.  Whereas it could be said that I have the capability of “Letter Writing”.  How do you avoid every business process been turned into a capability in this way, and how does your rule of thumb apply?]

  3. @ Jill,

    Great question and one of much debate. I can tell you how I view this but I’m certain it might confuse or ruffle the feathers of many.

    Business Capabilities represent a business function first and foremost. To have a business function, there are people, process, technologies and data. These are attributes of the business capability in that the business capability doesn’t own, maintain, control or master them. They are things which enable the business function to work. There are other business capability attributes as well; those for describing compliance, those for describing financial information/statistics, those for describing whatever a business analyst cares to analyze…like Organizational Health…why not?

    If a business wishes to be organizationally flexible, it might wish to modularize the business capabilities and work decoupling characteristics into the business capabilities attribution. This could give them the ability to spin-off a business capability, outsource it or reuse it across several high-level business groups. Or, a business may wish to optimize for innovation and simply let the different groups run rampant to do whatever they want. Or, something else.

    The point is that business capabilities offers a way of organizing the high-level business functions in a business organization to make changes to deliver on some business strategy. I suppose a business capability, theoretically, may have end-to-end containment of people, process, technology and data but this would be coincidental and highly unlikely. I can’t actually think of such a business capability in my organization but some typically offer up Finance and HR business capabilities but even these have people, process, technology and data edges that clearly cross into other business functions like business operational teams within a myriad of LoBs…so these too aren’t actually entirely decoupled. This is the very problem with trying to assume that a business capability hierarchy represent people, process, tech and data. It can’t and if you try to, it will not be useful for serving its original intended purpose as I stated earlier.

    I had a conversation with a business process SME on this topic recently and discovered a conflict with business capabilities and business processes that may be similar to your ask. A process is defined/labeled/named/valued by what it produces NOT how it was produced. This is a clear definition clash with business capabilities. Let me explain, The ‘sales’ business process is not a description of the process steps (ie the ‘how’) such as distribute lead, qualify opportunity, develop opportunity, proof solution, close sale. It’s named ‘sales’ process because that is what is produced from the process – a sale. The output of a process is the defacto name of the process itself. It is a ‘what’ to represent the underlying ‘how’. Unfortunately, this is also part of the process a business analyst would use to define business capabilities.

    This probably isn’t news to anyone, but here lies the eternal conflict business capability-people and business process-people have in my opinion. That isn’t to say that business capabilities are redundant with business processes. I maintain that business capabilities do a better job at the highest-level business process modeling because that’s where business strategy get’s executed, not in the bowels of some business process. A business capability model does a far better job at this high-level abstraction layer because business processes don’t have the mature ‘attribution’ concept business capability models do. Business Capability models are designed to make strategic heavy-lifting and not the fine-tuned process improvement work.

    I know several folks that use high-level business process frameworks like SCOR and APQC and simply take the level 0-3, do a little rejiggering where appropriate and use it as a basis for business capability modeling. This has worked for many and may be a consideration for those working in an industry that may not a have a ready-made business capability model template to kickstart the business capability modeling.

    Does this help make it clearer?

    By the way, I’ve written up another blog post which describes more on the metamodel of business capabilities and business process – see here. http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx


  4. Nick Malik says:

    Hi Gabriel,

    I wonder if we get wrapped around a tree sometimes with the notion of business capabilities vs. the results of business processes, because we use the word "capability" to refer to two things: a business function, and the results of a process.  I think we agree that these things are different, so why use the same word?  (Is that what you are getting at in your reply to Jill?)

    I share your frustration.  In talking with a business analyst the other day, it became clear that he was using the term "Business capability" to refer to both the high level (business function) and the low level (output of a process).  The problem with that is that the output of a process changes when the process changes.  It is not, therefore, a stable description of the abilities of a business.  The lack of stability means that mapping strategy to lower level elements is pointless.

    And therein lay the rub.  The model works at the high levels, but not at the low levels.

    Einstein faced the conundrum of trying to apply relativity to sub-atomic particles, where the principles of his cosmology did not apply.  He died without ever figuring it out.  He had a framework that worked at the cosmic level but that didn’t work at the subatomic level.  

    Physics has accepted that the levels are different.  Perhaps it is time for business architecture to take a page from the same book: use business capabilities to describe a function that actually includes people, process, and technology with a measurable business goal, but nothing more.  Once you enter the "land of process," the capabilities list should, IMHO, stop.

    My $0.02

    — Nick

Skip to main content