关于业务架构基础知识的二三事儿： 业务能力

企业架构领域中有很多让人觉得很重要、听起来很有道理，但又总让人觉得似是而非、似懂非懂的概念，比如，业务能力。无论对于企业还是个人来讲，能力都是极为重要的东西，没有能力，梦想就只是“梦”和“想”，能够将一个目标、一个想法付诸实现，也许这就是能力的意思。当然，掰扯一下的话，能力也有两个大的层次，一个层次是能将想法想清楚，另一个层次是想清楚还能做出来，这两个层次我觉得也是对企业和个人都适用的，在企业和个人身上，这两者都可以被笼统地以战略和执行两个层次加以概括，战略能力和执行能力。

百度上的解释，“能力是完成一项目标或者任务所体现出来的综合素质”，有一点说的确实在理，就是“能力总是和人完成一定的实践相联系在一起的。离开了具体实践既不能表现人的能力，也不能发展人的能力”。英语中与能力相关的词主要有以下几个：

1、competency：能力素质，指在任务或情景中表现的一组行为；

2、ability,capacity：指能力的大小或高低；

3、skill：指做事情的技巧。

此处不再深究，大意上也与汉语强调的核心点一样，可以做成某件事。

能力一词可以冠上很多定语，进而延展出在某一方向上做成特定类型事情的“能力”，事实上，这个词的使用很难避免循环定义的问题，这也是有时候会觉得讨论起来费劲的原因，因为本体不够清晰，就像《鬼灭之刃刀匠村篇》中的“上弦之肆”一样，一只鬼套着一只鬼，不砍断本体的脖子，鬼就不会消失，但是本体挺不好找的。

词语的溯源就到这里，毕竟再深究也难有更多跟我们要在企业架构这个语境下研究的“能力”一词的语义更多的关键信息了。

在企业架构下，到底什么是能力呢？鉴于能力种类太多，我们聚焦到读者的问题上，探讨什么是“业务能力”。

聚焦下也不会让这个问题更简单，毕竟，我个人认为，各类企业架构方法论都在逐渐将自己演进成关于能力定义和实现的理论，架构说到底就是结构、关系、原则这三个关键点，所以，各种企业架构理论都可以看作是定义能力分布、阐述能力关系和设计原则的方法论，帮助企业建设和管理自身的能力，就是帮助企业建立实现战略目标的“武器库”，也就是“能力库”，TOGAF 讲的“连续统一体”，也是一个循环迭代的“能力库”。

在这个“能力库”中，鉴于企业的钱要靠业务赚回来，所以，“业务架构”就是能力定义的核心，无论多优秀的技术，最终还是要转变成产品、业务，才能实现可持续发展。那么“业务架构”及其相关的知识体系是如何定义业务能力的呢？这个就“八仙过海各显神通”了。

一、CBM

大名鼎鼎的、以业务能力组件定义为核心的方法论，其对业务能力的定义是怎样的呢？鉴于该方法是基于企业管理乃至经济学中非常经典的专业化分工原理，所以，业务组件可以视为该方法论中能力定义的主要载体，基于分工和协同的业务组件包含了企业的各种业务能力，由于不一定每个组件的每个部分都可以系统化，所以，CBM 的业务能力范围是企业业务能力的全集并且范围大于系统能力的集合。至于业务能力的定义，方法论中给出了五个参考要素：用途、活动、资源、治理、业务服务，满满的专业化分工味道。可以参考下图：

由于该方法论是基于既有案例的总结，因此并未给出明确的组件设计方法，国内企业在引进该方法论时，将流程梳理作为定义业务组件的主要方法，也就是划定初步范围，再细化业务流程，重新精化组件边界。总是有些经验逻辑在里边，毕竟很多行业都有一些信息化或者流程管理基础，就算你所在的企业没有，这个行业也是可能有的，或者可借鉴的行业有些可以输入的东西，至少在今天这个环境下，不至于完全从零起步，虽然有 0.2、0.3 的可能。

所以 CBM 的业务能力指的是企业所有业务的专业化分工结果，因此，流程梳理，尤其在这个方法最盛行的时期，是必不可少的，经验有助于加快设计，但不能完全取代现状梳理，要建立一个基线版本的业务组件模型，之后再用其分析企业战略，找到实现路径，将战略能力向执行能力转化，所有分析结果最后凝结成新的业务能力，固化在业务组件中。

二、BizBOK

BizBOK 在业务能力定义方面可以说让人又爱又恨，说到爱，毕竟人家是专门的业务架构知识体系，主角光环拉满，自带 BGM；说到恨，就是它定义得太完整了，以至于反倒不好理解了。

BizBOK 中专有“能力”这个域，对能力可以说有很全面的解释，它对能力的定义是，“企业为实现特定目的或结果而可能拥有或交换的特定能力或能力”，嗯哼，BGM 是循环的，而且还有专用和泛化两个定义，你永远不可能打败自带 BGM 的角色。

BizBOK 是很有元模型范儿的，里边有大量抽象结构关系图用以辅助说明，比如能力的参考图如下：

还有一些补充说明，比如：

Ø 能力提供了以业务为中心的组织视图

Ø 能力是用业务术语定义的

Ø 能力基于业务对象

Ø 能力定义了企业的工作

Ø 能力稳定

Ø 企业只需定义一次能力

Ø 能力分解为更多的能力

Ø 业务有一张能力图

Ø 能力映射到业务的其他视图

Ø 自动化能力仍然是业务能力，而不是 IT 能力

Ø 如果团队无法定义一种能力，那么它可能不是一种能力

Ø 能力由拥有和行使这些能力的个人和业务单位命名和定义

还有一个关于能力知识库的抽象图：

补充介绍如下：

Ø 能力基于业务对象

Ø 能力分解为能力

Ø 能力实现和需求结果

Ø 能力实例实现能力

Ø 能力行为表征能力

Ø 能力行为表征能力实例

Ø 业务单元实现能力实例

Ø 业务单元影响能力行为

从这堆抽象中，我们可以看到几个基本点：

1、能力可以根据业务对象进行区分，毕竟能力是基于业务对象的，简单地讲，处理人际关系的能力跟定义系统协作关系的能力就不太一样，虽然目的都是让业务对象协作起来，但是要吃饭和不要吃饭的业务对象思考问题的点不太一样，处理的能力也就不同

2、能力可以有层次，可以再分解，大能力套着小能力，俄罗斯套娃般的存在

3、能力应该是企业的所有工作，虽然你做设计不用一次搞全，但终究是对着企业总体业务来的

4、能力最终会落实在业务单元上，无论是人还是系统，并且业务单元会影响到业务能力的表现，无论是人还是系统

5、能力可以图形化，并且，说不清、画不出的，可能就不是个能力

再总结下，在这个体系里，业务能力也是指企业的所有工作，根据业务对象可以有所不同，并且可以被说清，最终会落实在业务单元上。

BizBOK 确实是没少说，推荐大家自己阅读。

三、中台

中台很强调业务能力，但是好像没有对这方面做什么太明确的定义，尽管自己心里清楚它很重要，中台的能力定义其实是很偏系统化的，尤其强调系统化能力中可以复用的能力，这也是它的设计目标决定的，一定要找出个“中台”来。

关于这一点，可以参见早期的中台原理介绍的图示，那些老图的设计意图更明显：

四、现代企业架构框架（MEAF）

这是 Thoughtworks（思特沃克）提出的企业架构框架，今年一直说要翻新，但是王老师一直在忙，所以一直在跳票，新戏没来，就先看看旧的吧。

就像我说的，方法论都在向定义能力及其关系聚焦，MEAF 也一样，有一套自己的能力定义，这套逻辑如下：

1、基础能力：是对领域对象的原子操作，完成一个领域上单一且完整的职责。比如：创建售后单、修改商品库存量等。

2、扩展点与扩展实现：“扩展点”是对基础能力的可变性设计，在技术侧体现为基础能力实现中的某一个步骤的接口定义，而接口的一个实现为一个“扩展实现”。

3、能力组件：是对基础能力的进一步封装，目的是方便业务的使用。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。

能力组件按封装粒度不同分为两类：

3.1、第一类能力组件是根据业务服务的需要编排封装的一组关联的基础能力，从而提供完整的业务服务。比如：订单创建能力组件。

3.2、第二类能力组件是平台针对一系列紧密关联的业务活动，设计的能力模板，可基于该模板快速定制某个具体业务的特定流程和能力，从而达到复用全部关联能力的目的。比如：“购物车”、“结算”、“快速建站”等能力组件。

可以参考下图理解：

毕竟是在中台时代提出的方法论，本身也指向中台的构建，所以，我这篇文章中台反倒没写多少，读者可以参考这部分去看中台。

MEAF 也是偏系统化的能力定义方式，能力组件是基础能力的套娃，但是与 CBM 不同，CBM 的组件可以是子系统的概念，是个“筐”，里边是一堆零散的业务能力，但是 MEAF 的第一类组件不像是筐，更像是名符其实的“套娃”；第二类组件有“筐”的意思，但是这个“筐”的内聚性要比 CBM 的“筐”内聚性要求更高些。但二者有什么本质区别吗？至少我看不出来，等着新戏来了再说吧，毕竟写本子的人都清楚，唱戏的时候是不会完全照着本子来的。

五、聚合架构

最后聊聊我自己的想法做个收尾吧。

首先，业务能力的定义虽然各个庙里的和尚都有自己的经念，但是总体上也都不算脱离能力的“本体”，就是能够实现某个目标或者想法，所以，它的定义离不开过程和对象，在数字化的大语境下，也就是离不开常说的流程和数据，毕竟过程可以转化为流程，对象可以描述为数据，流程里还蕴含着参与人和规则，目标和想法实现与否最好也能通过数据展现或者度量，规则与数据之间也有密切联系，所以，流程加数据，人物、时间、地点、规则、故事也就差不多都有了。定义业务能力，在数字化语境里，可以通过流程和数据的定义得到，这一点与上述方法论的介绍并不冲突，这个定义也不会过分偏重系统，毕竟流程和数据无论有没有系统企业都是需要的。

其次，根据这个，可以把业务能力定义为通过一定的流程处理一定的数据进而实现一定的目标，这个定义听着不够通顺，但是尽可能避免了循环。在这个定义里，目标是定义能力的“锚定”，不然这个能力为什么需要就不知道了，这也是 CBM 里边的“用途”；流程和数据是能力的具体体现，画流程图、画数据实体关系图、关联流程和数据都是为了清晰地定义业务能力，这与 BizBOK 的理念也是一致的，但是 BizBOK 并没有展开的更细，因为三级活动以下不属于 BizBOK 的涉猎范围，它认为那些属于流程管理；流程结合数据的分析也可以等价于中台、MEAF 对于领域能力的定义方法，尽管方法论的外在表达上他们都是采用 DDD 的。

最后，关于聚合架构的内容我有视频讲解，这里不多讲了，可以参考下图：

这个方法的核心就是任务和数据实体的设计。

本文通过几个方法论的介绍比较了下“业务能力”的定义，其实怎么定义都有些万变不离其宗，关键是在你自己的方法论体系中要自洽，不要脱离方法论的语境泛泛地谈论业务能力，那样得不出有用的结论。方法论的学习不同于方法的学习，方法论算是方法的方法，因此跟方法处理的具体对象之间还隔着一层，越是指向具体产出、具体设计的，越是属于方法，而越是指向总体框架的越是靠近方法论，因为越具体越局限，比如对着某个企业的具体资产讲企业架构，其实讲的是方法，但是这个方法是受到实施环境高度限制的，它的通用性是极差的，包括资产本身都是如此；而脱离具体资产和设计讲的则是方法论，它强调的是总体过程、关键要素关系和设计原则建议，但是具体设计方法则要根据具体企业调整，一个企业一个样儿，看别人的资产别说学不会架构方法，就是抄一套架构资产出来都是“不合脚”的。

最后，借用 TOGAF10.0 的一句话来结束这次关于业务能力的讨论，“任何建议有一个单一正确方法、模型、视图、工作产品或技术的人，都没有为您提供正确的成功建议。”

更多阅读：

关于业务架构基础知识的二三事儿：架构联通设计