Defining the Business Capability - A Cheat Sheet

Comments: 8
Rate this:
Total votes: 5

A business capability defines “what” a business does at its core. This differs from “how” things are done or where they are done. Business capabilities are the core of the business architecture(i). Before I go further, let me say that this is not an article on the importance of the business capability or capability mapping. If you have doubts about this, read some of the other posted articles or white papers on the topic to build your familiarity. This article is for those of you who already understand the value of business capability mapping and need to go to the next stage.

As companies launch business capability building exercises, many business architecture teams struggle with the issue of what is or is not a capability. I have included some simple guidelines to keep your efforts on track as you embark upon your journey. Determining if something is or is not a capability, differentiating capabilities from other capabilities and validating these issues within the context of your business model can be challenging. The following guidelines provide insights into how capabilities can be identified and differentiated when establishing your capability map.

  1. Determine if a capability is actually a capability because it describes what – not how – something is being done.
    Faxing and emailing are not capabilities because they describe ‘how’ a capability fulfilled. Similarly, mailing an invoice is not a capability. Capital Management is a capability because it describes what is being done.
  2. Capabilities have outcomes.
    Communication with a client or customer is not really a capability because it has no clearly defined outcome. A Customer Information Management capability would, however, have the outcome of ensuring that a customer has high integrity information associated within it at all times. Lower level capabilities have more specific but related outcomes to their parent.
  3. Make sure a capability is not a process or value stream.
    Topic categories that require movement, such as the concept of authorizing, validating or engaging in some sequence of activities fall into a process category. A process or value stream stands out because it veers into “how” something is being done.
  4. Capabilities must be clearly defined.
    Capabilities must have clear definitions at every level. Calling something Account Management requires not just a definition of the management portion but also the account portion of the term. This forces a common view of your business.
  5. Capabilities are unique in terms of intent.
    If two capabilities seem alike, question their intent. For example, if a Customer Management capability appears to be the same as a Partner Management capability, consider that customers are inherently different than partners (the fact that they may be one in the same notwithstanding) and demand a different set of management capabilities. Conversely, managing customer information could easily double for managing prospect information if the business can align it terminology and thinking around this concept.
  6. Capabilities are framed by their parents.
    The relationship within a given capability between a parent and its children is not process centric but just a detailed refinement of the parent. For example, if a capability called Risk Rating is contained within a higher level capability called Solution Management, then this case of risk rating is focused on delivering or furthering a solution. If a Risk Rating capability is shown under a Risk Management capability within a Capital Management capability, it is mostly likely furthering an aggregate view of risk management that is not tied to a given solution.
  7. Capabilities are unique based on the information they require and use.
    One capability may use or produce certain information that a similar sounding capability may not require or use. Again, an aggregate view of Risk Rating when decomposed may only look at a country or a class of customer while a similar sounding capability within the context of Solution Delivery looks only and entirely at information that is tied to that specific solution. In addition, a capability definition must align with the corresponding definition of that business asset. Account must be defined in the same way as it is in the definition of Account Management.
  8. Capabilities can be framed by the roles and resources that have those capabilities.
    Can two people switch jobs and still perform adequately well in relation to two similar sounding capabilities? For example, if the corporate risk manager switches jobs with an underwriter, will each person still be able to fulfill their roles within an equivalent level of effectiveness?
  9. Capabilities are purely business views of the business.
    It does not matter if a capability is automated or not. It is a capability if the business can and does have this ability – even if it is weak. Keep the discussion of systems on the sidelines as you go through this exercise. Later, when your capability map has matured, you can begin validating and using it through value stream, organization and IT asset mappings.

One last point here for those organizations just getting started. There is a degree of introspection involved in capability analysis that few people have experienced. Not everyone can sit through the sessions, but for those that do, the rewards are very real. Business people have said that it makes a very different part of your brain go to work. Another said that the journey of building the map is as valuable as the end result. Good luck, as you continue your journey.

(i)Page 48, Business Architecture: The Art and Practice of Business Transformation, Ulrich, W. and McWhorter, N., MK Press, 2010

Comments

Colin Field
,
posted 31 weeks 4 days ago
Clear, excellent guidelines, William. My only concern, over an otherwise flawless article, is the assertion that 'business capabilities are the core of the business architecture'. I view business architecture as how a business structures itself and operates to achieve its goals, perform its mission and ultimately realise its vision. The capabilities, on the other hand, are what a given type of organisation must have the ability to do in order to survive and perform in its chosen industry and marketplace. With this in mind, rather than business capabilities being the core of business architecture, I see business architecture (and enterprise architecture generally) as the platform (I use this term loosely) that strengthens, weakens or maintains the business capabilities. When a business strengthens its core capabilities it becomes more adept at achieving its goals, performing its mission and closes it the realisation gap on its vision.
Thoughts?
Bill Francis
,
posted 1 year 4 weeks ago
I would only change one of your recommendations. I would suggest that capabilities set expectations, not outcomes. Outcomes can only be produced by a process. Just because you have the ability to do something does not mean you will produce an outcome. It's only when you apply a process, supporting that capability, that will produce the outcome. Example. Portfolio Management is a business capability. The outcome could be a new portfolio if I execute the process of creating a portfolio or the outcome could be an updated portfolio if I execute the process of updating the portfolio.
Phil Mizzi
,
posted 1 year 4 weeks ago
Good article going a few levels down in capabilities.
Timothy Manning
,
posted 1 year 8 weeks ago
A Business Capability is not about "what" a Business does, rather the ability it requires. It is about the 'what rather than the how', but unfortunately people tend to equate the 'what' word with the activities of an organisation. And Business Capability modelling is not about modelling activity. So careful with the 'What' word.
Skip Lumley
,
posted 1 year 10 weeks ago
I'm curious to know the reason for the appearance of 'outcomes' in criteria 2. Why that term rather than goals, objectives, results, consequences, impacts, purposes, intentions, effects, etc? Is there anything behind its choice?
carl brodeur
,
posted 1 year 14 weeks ago
Thanks for this article. very useful.
satya chunduru
,
posted 1 year 15 weeks ago
Is there any liast or catalouge of capabilities for variuous industry verticles to be used as reference?
Curtis Fahlberg
,
posted 1 year 27 weeks ago
Excellent and useful examples and clarification for guidance.

Join the Discussion

Your email address will remain private.

Shopping cart

View your shopping cart.

Editorial DIrectors

Gregg Rock
Gregg Rock
Editor & Founder
BAInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Related training courses

BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

BA 101Establishing Business Architecture Governance and Centers of ExcellenceBuilding a Business ArchitectureThe Business Architecture PlaybookBusiness Architecture / IT Architecture AlignmentView the Learning Path for more courses »