Guidelines for Defining and Distinguishing Business Capabilities

Business capability defines what a business does at its core, distinct from how or where it does it. It is central to business architecture (i). This article is not about the importance of business capability mapping; it targets readers already aware of its value and ready for the next stage.

As companies launch capability‑building exercises, many architecture teams struggle to determine what is or isn’t a capability. The following simple guidelines keep your effort on track when starting the journey. Identifying whether something is a capability, distinguishing it from others, and validating it in the business model can be challenging. The guidelines below provide insight on how to identify and differentiate capabilities when building a capability map.

Determine whether a capability truly describes *what* is done, not *how* it is done. Fax and email are not capabilities because they describe implementation methods; capital management is a capability because it describes the activity.

Capabilities have outcomes. Communication with customers is not a true capability because it lacks a defined result, whereas customer information management’s outcome is to maintain high‑integrity customer data.

Ensure a capability is not a process or value stream. Concepts such as authorization, verification, or participation in a series of activities belong to the process category, which focuses on *how* something is done.

Define the capability clearly at every level. For example, account management must define both the management aspect and the account terminology, forcing a shared view of the business.

Capabilities are unique in intent. If two capabilities appear similar, question their intent; e.g., customer‑management versus partner‑management may share actions but serve different purposes.

Capabilities are designed by their parents. A parent capability refines into detailed child capabilities, not process‑centric relationships. For instance, risk‑rating under solution‑management focuses on delivering or advancing a solution.

Based on required and used information, a capability is unique. Different capabilities may use or produce distinct data sets, and definitions must align with the corresponding business asset.

Capabilities can be composed of roles and resources that possess them. People can move between jobs and still perform similar capabilities if the underlying responsibilities remain effective.

Capabilities are a pure business view; automation status is irrelevant. If the enterprise truly possesses the capability—even weakly—it counts as a capability. System discussions can be set aside during the exercise.

For organizations just starting, this is the last point. Self‑reflection in capability analysis is rare, but those who sit down reap real rewards. As one business leader said, it makes a different part of your brain work; another noted the mapping process is as valuable as the result. Good luck and continue your journey.

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