今天跟大家聊下PBC业务能力组件，包括在整个企业架构规划和能力建设过程中，从 微服务 到PBC组件的整个思维演进过程。
企业级业务能力EBC
在聊PBC之前要先谈下EBC，金蝶早在2019年就联合Gartner在发布EBC企业级业务能力构建白皮书。在白皮书里面对EBC做了一个说明，即：
相较于ERP，EBC是从“资源计划”进化到“业务能力”、从“经营管理”进化到“产业链生态”、从“流程驱动”进化到“数据驱动”、从“套装产品”进化到“组装式应用”、从“单体架构”进化到“云原生架构”、从”判别式AI“进化到”生成式AI”。在数字化背景下，EBC特指“企业的数字化业务能力”，企业数字化的最终价值在于打造企业的数字化业务能力。
EBC为企业提供五大方面能力：数据驱动业务的能力、链接和服务客户的能力、链接和赋能伙伴的能力、链接和管理万物的能力、链接和赋能员工的能力。这五大能力支撑企业进行数字化商业模式创新和数字化运营优化，实现韧性成长。
同时提出EBC是在当前数字化浪潮下企业数字化能力构建的思维转型。
同时提出EBC并不是“另一个信息化项目”，它既是一种哲学，又是一种技术解决方案，构建EBC将是一个不断进化的过程。人和组织的思维演进需要经历一个过程，在这期间需要付出大量的时间和精力。随着时间的推移，EBC的定义和内涵也将随着每个组织的发展而变化。
在我前面谈企业架构文章，特别是TOGAF10最新版本企业架构规范变化的文章中谈到。新版本企业架构更加强调了业务能力的核心地位和承上启下的作用。
即企业核心战略和业务目标由企业业务能力支撑，而企业业务能力本身又通过流程，组织，IT三方面来进行支撑。
业务能力在整个数字化规划建设中起到相关关键的作用。而EBC企业级业务能力构建也是这个架构思想的进一步落地。
谈EBC是数字化技术，思维，实践的融合有点抽象。简单来说EBC核心应该体现两个关键点，即平台化复用，敏捷化组装。而对于涉及到的微服务，低代码，DevOps，中台，融合集成，能力开发，PaaS技术平台都是为了支撑上面两个关键目标的实现。
从EBC到可打包业务组件PBC
注意在白皮书里面PBC是翻译为可打包业务能力，即Package Business Capability。在这里为了更好的理解，我后面统一用业务组件这个词。
前面谈到了我们需要构建EBC企业级业务能力，但是这个能力如何构建，如何利旧当前的IT资产，如何整合第三方资源，如何快速扩展新能力，哲学都是必须要考虑的问题。
EBC的核心思路就是企业级核心能力应该可以分解为一个个独立的PBC组件，通过PBC组件的灵活组装来完成一个大的应用。也就是说针对企业不同场景下的业务需求，我可以快速组装PBC组件的能力来满足。
PBC组件在构建的过程中我还可以充分的利旧企业遗留IT资产和外部第三方的服务能力。单个PBC组件如下图：
这个看起来和微服务和领域建模中的六边形架构很类似。
简单来说一个PBC组件本身也需要依赖底层的一个技术底座，一个PBC组件以业务对象建模为核心，有自己的流程，规则，数据和文档。同时一个PBC组件本身通过接口服务进行同步集成，通过消息服务进行异步集成。
其中PBC组件最关键的有两个点。
- 基于业务对象建模驱动，进行能力聚合
- 可以有界面展现，形成独立可复用小应用功能
同时多个PBC组件之间可以通过接口，消息进行集成。这也就是前面说的PBC组件之间还可以灵活组装，构建完整的EBC能力。这也是组装式应用的一个核心逻辑。
微服务和PBC业务组件的关系
微服务和PBC业务组件这两个概念相当的类似，特别是组装编排，可复用等方面都具备很多类似性。所以还是得谈下两者的区别联系。
对于我们经常谈的微服务，更多是一个技术词汇，是面向技术人员的，包括微服务如何拆分，微服务应该提供哪些粗粒度的API接口。而对应PBC业务组件本身是面向业务用户的，是业务可以感知的一个业务功能。比如有一个供应商查询组件，这个组件本身就聚合了底层微服务API能力加前端的展现界面。
对于微服务更多谈API接口层面复用，而对应业务组件则是谈面向业务的功能层面的复用。具体如下图：
可以看到底层是微服务和微服务提供的可复用API服务接口。而上面是PBC组件。PBC组件和底层微服务和API并非严格一一对应，一个PBC组件可以消费和复用底层多个微服务提供的API接口能力。然后对这些API能力进行编排并增加相应的编排业务逻辑处理，同时再提供上层的应用界面，完成一个独立的业务功能实现。
例如上图中的订单组件，就是一个独立的PBC组件。
PBC组件是业务对象建模驱动的，PBC组件的颗粒度比微服务更小。类似我们在进行领域建模的时候通过事件风暴识别和聚合的领域对象，一个领域对象就可以独立构建一个PBC组件。但是对应微服务，我们往往会把多个领域对象聚合到一个业务子域，按业务子域的颗粒度来划分微服务。
PBC聚合的是业务对象非数据对象。类似供应商PBC，一个供应商业务对象包括了供应商基本信息，地点信息，地址信息，联系人信息等多个数据对象，共同聚合为完整的供应商业务对象。
PBC业务组件的识别方法
对于微服务的划分，API接口的识别和定义我们基本形成了标准的方法。类似基于流程驱动的纵向思路和基于底层共享数据驱动的横向思路。包括前面谈到的基于领域建模的思路来划分微服务，识别可复用API。
微服务和API识别和定义更多是面向技术实现层面的。比如一个业务场景有哪些业务能力支撑，一个业务能力实现需要调研底层哪些API，而这些API接口又由哪些微服务中心提供等。
但是PBC业务组件的识别和该方法有差异。
PBC组件的识别，特别是可复用组件的识别更多是基于横向的思路。即将业务能力不断拆分到细颗粒度的业务功能单元，再将业务功能单元拆分到应用功能单元。每个应用功能单元自带逻辑，自带界面，有明确的输入和输出标准。
这个应用单元有可能是比传统的应有系统的底层功能菜单更加细化的单元。例如供应商查询应用功能单元。我要分析到采购订单制作这个业务功能的时候，进一步分析到内部功能操作，才能识别出来，在订单头输入的时候涉及到选择供应商，而选择供应商涉及到供应商查询这个应用功能单元。所以可复用的PBC组件识别是业务层面的，不涉及到底层具体技术实现，也不用关心这个PBC组件具体有哪些底层API服务支撑。
编排和组装两个概念
很多时候我们会把编排和组装两个概念混用。在这里为了更好说明PBC和微服务的一些差异点，我将两个概念分开来描述。
对于微服务，我们谈编排，而且编排往往是面向技术人员的。这个编排涉及到API接口，规则，流程这些都可以编排。微服务通过编排可以完成一个独立的PBC组件的功能。
而对于PBC组件，我们谈组装，这个组装可以是面向业务用户的，业务用户不用关心单个PBC组件的内部实现逻辑，而可以将多个业务组件按一个的规则逻辑上组装在一起形成一个完整应用。
组件的组装类似很早我们谈SOA架构里面谈的SCA和SDO的概念。
多个PBC组件可以通过相应的接口组装到一起。这种组装是面向业务用户的，因此卡扣规则往往更加严格，卡扣接口标准也越少越好。
类似古代建筑中的榫卯结构，各个木块就是独立的PBC组件，可以长短不同，形状不同，粗细不同。但是榫卯连接点的接口规则一定是早期约定好的标准规则，就那么几种连接模式，确保严丝合缝。。通过这些连接模式可以将多个木块连接拼装在一起完成一个完整的小建筑。
低代码和SaaS应用平台生态
这个思路可以扩展到SaaS应用平台生态的构建上面。这里拿阿里钉钉的SaaS应用平台来举例。
因为原来大家对钉钉的认识都是可能只是简单的打卡考勤，但是他其实后面逐渐的变成了一个业务协同平台，当你对他的认识还只是沟通协同平台的时候，他已经在支撑上层企业核心的业务价值链的关键业务运作的企业业务应用平台。
能够达成这个目标不只是钉钉开发团队做完的事情，因为它聚合了大量的外围的开发商和合作伙伴，共同来给他提供相关的上层应用生态。对于一个好的SaaS应用生态的创建，就必须体现平台化，复用，敏捷，组装等核心思想。具体包括以下几个关键点：
第一个就是我们讲的数字化的技术底座，你一定要建好。大家都知道其实对于阿里来讲本身就有阿里云提供强大的云原生数字化技术底座。在技术平台上面它一定还有一个叫应用底座，就是你支撑上层应用开发的一个应用支撑平台，提供类似4A，流程，消息，通知，文件等公共应用支撑能力，为你上层的应用开发合作伙伴去做相关的能力支撑。
第二个就是提供单个应用或组件的快速开发能力。当你要去构建一个saas应用生态的时候，你应该提供一个基于你数字化底座的低代码开发平台，这个平台不是零代码开发，而是真正的低代码开发。它有点类似于云原生里面Serverless无服务器化的思路，也就说我底层提供了完整的完整的BaaS层的相关的能力，这个能力能够支撑我上层应用的快速开发这个开发，而且是可编排的方式进行开发。我的API的接口能力可以编排，流程可以编排，规则可以编排，我的界面可以可视化设计，这样的话方便你的合作开发商快速的是基于你的技术底座、开发框架、开发规范去快速的开发相关的SaaS应用。
第三个关键点就是提供应用灵活组装的能力，即基于可复用的PBC业务组件能够快速地组装完整的业务应用。PBC组件开发出来后，可以通过DevOps持续集成和交付到PBC组件应用市场，而最终业务用户可以快速地挑选PBC组件进行组装完整应用来支撑端到端业务流程。
所以说对于这一些组件怎么样去组装，组件之间怎么样去协同，从整个平台的角度，他应该去提供相关的集成的标准、接口的标准、协同的标准、数据传递的标准，这些东西必须要去提前制定，而且是基于这一些提前制定的接口标准，来驱动你后续的小应用组件的开发。你只有置顶朝下的做这件事情，你后面的组件才能够真正的拼装起来。
这个事情单个应用开发厂商没法做，而这个事情真的就应该由SaaS应用平台的服务商来提前做好这个事情。这样的话我面对最终用户的时候，我就不再是提供的一个个垂直小烟囱的小应用，而是提供的真正能够实现你企业横向端到端业务协同的完整的一个业务应用。这个就是我们说的构建SaaS应用平台和生态的关键最后一公里。
今天关于PBC组件分享就到这里，希望对大家有所启发。