读中台战略笔记02(200221）

注：图片来源于云徙科技官网。

这篇文章主要为本书里面的中台建设方法论，中台架构设计内容的读书笔记和思考整理。对于书籍后续的数字营销等相关内容不再整理额外的读书笔记。

在5.1给出了数字中台建设的整体策略，我先做下摘录。

数字中台建设的整体策略是从业务着手，自顶向下逐层调研业务，再自底向上对业务逐层抽象归纳，形成业务全景图。根据业务全景图，我们设计出应用全景图，根据应用全景图，我们逐层细化，设计出应用功能清单。在此过程中，业务被拆解为最小粒度-原子业务对象。原子业务对象包括了业务实体，业务活动和业务规则。

上面这句话可以看做是中台建设方法的高度概括，是否是感觉很熟悉？确实，这个方法实际上和我们传统的基于SOA思路进行的企业架构规划很类似，从业务驱动IT，端到端流程分析入手，形成业务架构，然后由业务架构到应用架构，再到详细的应用模块和功能清单。

那么实际上在使用这个方法过程中，出现最大的要给区别在哪里呢？ 实际上最大的一个区别在于我们分析和建模的粒度会更细化一级到传统应用系统的模块单元，基于这个我们在业务上要弱化部门概念，在应用上要弱化系统概念。用一种虚拟的域，类似业务域，数据域，应用域的概念来代替传统的应用系统概念。即：

1. 业务部门或业务科室概念 -》应该转变为业务单元的概念。

2. 应用系统的概念 -》不再有应用系统的概念，而是应用能力单元概念（对应中台各中心）

如果没有这种思想，那你无法规划建设中台，中台本质就是打破传统边界后的重构和共性能力提取，不能各自为政进行规划建设，讲共性能力全部集中化才是重点。

在这里我们先说下业务中台，实际上你可以看到业务中台建设的核心就是两个事情， 其一应该建设哪些中心，各个中心拆分粒度如何把控？其二就是各个中心应该提供哪些API能力接口 ？我们前面做的所有流程分析，业务建模，数据建模和CRUD分析等都围绕这个目标进行。

图书5.3部分-这里有个中台模块的构图需要我后面细化。归根到底，业务中台本质是一个体系或一个系统，它实现企业核心的业务运行机制，因而处于企业运行生态的核心位置，所有的应用系统都必须与之发生关联。中台的存在不仅仅是抽取可复用的能力，众多的可复用能力仅仅是中台的形，核心的业务数据和业务流程才是中台存在的本质。

如何建设中台？书里面提到的四个要诀点如下：

1. 能力支撑是基础（能力存在的目的是通过编排或组合支撑业务流程）

2. 中台自治是承载形式（注意中心和微服务模块的区别，一个中心还可以存在多个微服务）

3. 三层模型是骨架（实体层，协作层，活动层）

4. 五步法是指导思想（业务抽象-》高阶设计-》组件建模-》开发交付-》持续运营）

注意这本书给出了中台的三层模型，即实体层，协作层和活动层。对应业务中台各个中心究竟如何分类，在我博客上很多文章里面都有谈到。实际上我的分发是数据类中台，业务和流程类中台，规则类中台。但是我这个分法协作层和我的规则类中台是否能够对应暂时无法确定。

比如书里面举例的促销中心，评价中心，在我这并不属于规则类中台，仍然是属于业务和流程类中台。我们的规则中心很简单就是完全是给出具体的逻辑规则为主的中心，类似原来经常提到的预算中心。为何预算中心为规则中心，因为预算中心和外面打交道很简单，就是你给我一个输入，我告诉你有无预算，这就是一个规则。

基于这个我们看到，如果你给我一个用户ID，你告诉我们这个用户的评级水平。这也是要给显然的规则，但是这个规则往往需要大量数据分析计算后才能够得出，那么这个API能力谁来提供? 而这个API能力刚好就是数据中台需要提供出来的API服务能力。

如果把前台功能看成一个完整的业务流程，那么我们将其分解为：

业务流程 = 业务功能或活动*M + 业务规则*N + 业务数据*K（业务规则和数据都可能来源于数据中台）

即业务流程的完成就是调用了中台的业务功能模块，规则模块，数据模块进行组合和编排后完成完整的端到端业务流程能力。所以你中台做的足够好，那么前台的应用就能够足够轻，足够敏捷，这和我们SOA的服务重用，服务组合，服务编排的思路完全是一样的。

对于中台建设的5步法，即 业务抽象-》高阶设计-》组件建模-》开发交付-》持续运营 ，整体还是有参考意义。从业务分析和抽象入手，然后进行顶层设计，再到详细的组件模块设计。

但是最大的问题在哪里？

最大的问题就是我在整个规划建设阶段， 业务和技术两条线一定要分离去思考，最后再融合 ，实际上你可以看到业务中台的规划，包括到接口能力识别都完全偏业务层面，是业务顾问和架构师驱动的，而且整个过程和中台的技术选型，技术架构没有太大的关心。你可以完全将焦点关注在业务流程和业务建模上。其次才是中台建设中的技术架构如何规划，这个技术架构设计到传统的iaas,paas平台，也包括当前主流的技术服务，devops，微服务开发框架和环境等，这些技术都是为后续的中台模块开发构建服务的。

在看到这里的时候，我们再回到我们经常谈的企业架构规划中的业务架构，数据架构和应用架构。这次给了我一个很大的启发，这个启发就是对于传统的企业架构方法论我们应该做出调整，这个调整步仅仅是简单的我们分析的层次和粒度细化一层的问题。

调整的重点是业务架构+数据架构+应用架构合并思考，将应用架构中的技术架构拆分出来单独思考 。由于弱化了应用系统的概念，你会看到，我们在业务架构中的业务组件模块，和应用架构中的应用组件模块完全可以合并为一个内容，而不是分开的还需去映射的两个东西。也就是业务架构和应用架构统一了。应用架构中原理的共性应用能力支撑，类似4A，流程引擎，门户等也没有了，这些都全部剥离到了企业整体大架构框架里面。

业务+数据+应用的高度融合统一，而对技术又单独的抽象剥离才是对传统企业架构最大的调整点。

另外，对于中台各个模块如何划分，划分的粒度，这个始终都是中台建设的一个关键点。在这里我们再次提出，在前面谈到的业务分析，流程梳理和顶层建模的大思路下。我们进一步提出，业务流程分析和分解最终得到的都是细粒度的业务活动，而这些业务活动如何合并为一个个粗粒度的中台模块中心才是重点。

在这个分解后的朝上归纳合并中， 原则是高内聚松耦合，核心分析工具仍然是矩阵分析 。这个矩阵分析既包括了我们传统使用比较多的数据CRUD分析，也包括了业务活动+数据相互机会的CRUD分析，当然还可以是业务活动+业务活动的交付集成分析。

当然这个分析不足够，分析后给出初步的拆分，然后基于我们实际的前台流程场景进行演练，看下拆分后的中台模块和API接口如何通过编排来支撑，这个演练很重要，通过演练你会发现拆分中不合理的地方并进行调整。反复迭代多次就得到比较合适的中台模块划分和API接口。

既最终的核心分析方法思路为： 业务分析分解-》矩阵分析+流程化验证试算-》多次迭代 。

注意上面这点是在我读完这本书后的进一步思考和总结，在我博客前面的中台和微服务架构里面并没有提到。因此读书还有一个更大的作用就是进一步触发你的思考和复盘。当然这个也必须建立在你原来有类似的经验和实践的基础上。

中台架构与设计

前面我给出了要给重要思路，就是业务中台规划和建设这个偏业务层面，重点就是要给出业务中台究竟含哪些中心，每个中心究竟提供哪些业务API接口能力。而中台架构设计个人理解更多的就该从技术层面来谈一个中台如何进行架构和设计。当然要谈这个你可以分解为技术中台，业务中台和数据中台分开来谈。

在这里我们看业务中台的架构设计，那自然就要谈整个微服务开发框架的选择，关键的类似服务注册中心，网关，限流熔断，服务链监控等核心技术组件能力的提供等。实际上基于组件化和模块化的开发思路，在技术层面我们可以理解为要谈清楚如下事情：

1. 单个微服务模块的开发是如何的？(数据，业务，规则类不同的模块设计原则和要点是什么？）

2. 模块提供的API接口设计和开发，接口如何集成和统一管控（安全，限流，注册中心等）

3. 跨模块的协同能力，重点在前台如何应用中台能力，服务编排，APM，服务链监控上

把这些都谈清楚了，这个架构也就清楚了，既从最基本的开发框架和技术架构，再到集成架构，运维架构都需要谈清楚，这个中台架构才清楚了。

再回到技术中台，我前面谈到，需要重点谈清楚了容器化PaaS，DevOps持续集成交付和共性技术服务能力提供，这个是构建业务中台能力的基础。这个技术中台你可以完全依赖公有云能力，也可以部分自建，这个在我上篇读书笔记里面也有说明。