在企业内部引入企业架构（Enterprise Architecture )的概念，基于TOGAF开发企业自身的企业架构时，为了集中精力，重点突破，很多咨询公司常常把企业架构简化为4A架构，我曾经服务的某公司也是这个套路，详见下图：
在做架构开发时，业务架构（BA）作为技术与业务之间的统一语言，将技术与业务对齐,从而使企业具备随需而变的能力，详见下图：
因此在开发业务架构时需要投入重要的精力。
在标准的TOGAF 的 ADM方法中，并没有明确怎么去开发业务架构，没有给出具体的方法，因此在真正做EA架构规划的交付，尤其是业务架构开发时，不同的咨询公司方法不太一样，基本是两大流派，一个是基于业务能力去开发业务架构，另外一派以18M为代表，是通过CBM业务组件模型去开发业务架构，经过几次架构开发的实践之后，我个人的观点是 业务能力与CBM不矛盾，可以结合起来使用，详见下图：
业务架构是业务的结构化表达，我个人还是习惯于从CBM入手，去做业务架构的设计。
下面是对18M家的CBM的一些解读，主要信息来源于18M商业价值研究院及我自己个人咨询的总结，如果涉嫌侵权，我会在接到投诉后删除相关内容。
1.CBM的定义：
CBM通过对企业的业务组件化建模，形成企业业务架构的顶层视图，在一张图上，直观显现出企业的业务蓝图。通过这种方式，将企业的各项业务活动重新分组到数量可管理的离散化、模块化和可重用的业务组件中，确定改进和创新机会，实现有组织的提供服务的能力。详见下图：
2.CBM的作用：
CBM 提供了一个可以推广的框架，用来创造顺应组织战略的指导方向。企业也可以通过CBM实现专业化发展，实现柔性化运行，并建立和实现面向服务的架构（Service-Oriented Architecture，SOA），为实施 SOA 奠定基础，也可以帮助企业向中台架构演进。
中台架构演进的进一步解释：
通过CBM对企业的业务进行建模，使企业原有的所有业务系统都下沉，不再有按业务部门建立的多个烟囱式的业务系统的概念，原有的业务系统变化为一个个提供业务组件和服务能力的能力单元。此外，原有的所有业务系统中的组织，人员，权限，流程引擎，安全等公共基础设施全部抽取，放到同一的平台进行管理，业务系统不再单独构建IT公共基础能力设施。
3.CBM设计方法
CBM通过横向业务能力和纵向能力层级对企业的所有业务进行矩阵式定义，但是CBM体现的是企业的业务能力专业化整合能力，其划分并没有固定的方法，同一个企业的CBM可能由于关注点不同而呈现完全不同的结果。业务能力的划分需要与企业价值链保持一致，但先后顺序没有绝对定义。业务组件在划分的时候属于哪个维度，业务组件在操作层面需要反应到什么细节程度，也没有绝对的定义。
3.1 通过管理功能与管控权限来判别
按管理职能和管控权限的划分两个维度来确定。例如企业人力的备案属于执行层，而人力的审批属于管理层。
3.2 通过业务能力去设计
4.业务组件的定义和描述
CBM中每一个单独的业务模块叫做业务组件（Business Component，BC）业务组件是CBM的核心
4.1业务组件的典型特征
业务组件的典型特征，可以归纳为“高内聚、低耦合”
4.2业务组件的设计原则
业务组件是一系列不可分割的业务活动，那么如何设计业务组件呢？还是需要从业务组件的定义和特征着手，从业务组件是企业专业化的功能模块这个本质出发，从业务组件高内聚低耦合的特点出发，综合考虑以下因素：
在深谙业务组件“高内聚、低耦合”这一特性的基础之上，对于业务组件的设计，还需精准把控好组件的颗粒度。
4.3业务组件的验证方法
1.业务场景十字分析法
业务场景十字分析法仿若软件测试中的白盒测试，即凭借“测试用例”（流程场景）来校验组件外部的流程以及内部业务活动，以验明组件的正确性。就业务组件的 CBM 图而言，首先，相同业务域下的业务组件理应能够串接；其次，不同业务域下组件间的交互关系，应当呈现在同一层次。具体来说，战略层面不同业务域的交互应当皆体现在战略层，管理层面不同业务域的交互应当皆体现在管理层，执行层面不同业务域的交互应当皆体现在执行层。在交互进程中，不应存在斜线关系。
2.业务组件依赖性分析法
通过衔接业务组件的输入与输出，能够剖析业务组件于职能层级方面是否精准无误。通常而言，战略、管理以及执行层的业务组件在连接方面具备如下图所示的特征。
5.CBM和流程架构的关系
CBM 与流程架构之间存在着与生俱来的关联。于 IBM 所提出的企业总体架构方法论当中，CBM 与流程均为描绘企业总体架构的不同视角。流程能够被表述为业务组件相互协同、有条不紊执行的活动。组件能够被诠释为众多具备同类特性的流程的集合。
流程乃是企业业务活动的内在特质，不管企业是否施行流程管理，流程皆体现出“存在即合理”这一特性。CBM 能够推动企业的流程整合成为既能够为组织发挥独特效用，又能够作为单独实体运作的业务组件，使企业化作一个由不同业务模块构成的网络，每个模块当中均涵盖一系列相互关联的活动，并且促使企业从单条的流程优化朝着流程整体优化迈进，并最终造就整个企业层面上的全局优化之态势。
CBM和流程架构也存在着明显的区别：
二者的核心功能存有差异，CBM 侧重于业务块层面的业务设计与业务变革，旨在提升业务的专业化水准；而流程架构则是对业务构成予以描述，其主要作用在于指导业务流程的梳理，提供结构性的框架。
二者所描述的层面亦不相同，CBM 界定每个业务组件的五要素，涵盖价值、资源、所需的活动、业务治理以及提供的业务服务；流程架构着重定义末级流程的要素，包含活动、岗位、表单、制度依据等等。
CBM 的核心要义在于达成业务组件化，借由业务的模块化设计，为企业的应用架构、数据架构给予相同的模块化输入，达成企业架构设计的纵向传递与上下对准。企业借助 CBM 实现业务组件化之后，还需详尽剖析业务组件的交互，而此的根基即为业务流程交互。通过对业务组件交互的分析，不但能够为构建企业的业务流程体系提供输入，而且能够通过剖析业务组件之间传递的业务对象，为数据架构元数据模型的定义给予指引。
我们可以得出，CBM和流程架构在业务域层是一致的，在业务活动层是重合的
业务组件乃是对企业业务功能的划分，并且为了达成专业化发展，针对各类不同的业务均运用面向对象的切分准则。譬如针对战略规划业务能力（业务域），需依据企业各异的规划对象，切分成企业整体战略规划、人力资源战略规划、科技发展战略规划、军民融合发展战略规划等等。流程是面向特定的业务目标，将输入转化为具有价值输出的一系列相互关联的活动。流程组为流程的集合，能够采用面向对象的集成原则，亦能够采用面向过程的集成原则。当流程组采用面向对象的原则时，与业务组件的划分一致，二者等同。当流程组采用面向过程的方式时，二者存在着多对多的关系。
附录：
业务能力与流程体系的对比，来自我的老东家
下图也是