Defining Business Capabilities: Guidelines and Best Practices

Business capability defines what a business does at its core, distinct from how or where it does it, and is central to business architecture. This article is intended for readers already familiar with the value of capability mapping and ready to move to the next stage.

As organizations embark on capability‑building exercises, many architecture teams struggle to decide what is or isn’t a capability. The following simple guidelines help keep your effort on track, offering insight on how to identify and differentiate capabilities when constructing a capability map.

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

A capability has a result. Communication with customers is not a true capability because it lacks a defined outcome, whereas customer information management ensures high‑integrity data for each customer.

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

Define the capability explicitly at every level. For example, account management must define both the management aspect and the account aspect, forcing a shared understanding.

A capability is unique in intent. If two capabilities appear similar, question their intent; differentiate customer management from partner management based on their distinct nature.

Capabilities are designed by their parents. Relationships between parent and child capabilities are not process‑centric but rather a detailed refinement of the parent.

Based on required and used information, a capability is unique. Different capabilities may use or produce different information, and definitions must stay consistent across the business asset.

Capabilities can be composed of roles and resources that possess them. People can move between roles while still performing the capability effectively.

A capability is purely a business view; automation status is irrelevant. Even a weak capability counts if the enterprise truly possesses it. System discussions can be set aside until the capability map matures.

For organizations just starting, self‑reflection in capability analysis can be challenging but rewarding; the process of mapping is as valuable as the final map.

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

Original source: https://www.bainstitute.org/resources/articles/defining-business-capability-cheat-sheet

Article: http://jiagoushi.pro/node/980

Discussion: Join the Knowledge Planet or WeChat circle 【Chief Architect Circle】

微信公众号

关注微信公众号 【首席架构师智库】

微信小号

希望加入的群：架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化，产品转型。

知识星球

向大咖提问，近距离接触，或者获得私密分享。

点击加入知识星球【首席架构师圈】

微信圈子

志趣相投的同好交流。

点击加入微信圈子【首席架构师圈】

喜马拉雅

路上或者车上了解最新黑科技资讯，架构心得。

点击，收听【智能时刻，架构君和你聊黑科技】

知识星球

认识更多朋友，职场和技术闲聊。

点击加入知识星球【知识和技术】