读中台实践数字化转型方法论与解决方案的一些思考

　　今天整理和分享下对云徙可以最近新出版的《中台实践-数字化转型方法论与解决方案》这本书的一些总结和思路。在前面云徙科技已经出版过《中台战略》这本书，我当时也整理了相关的阅读笔记整理，具体可以参考：
　　阅读《中台战略-中台建设与数字化商业》的一点思考
　　而对于新的这本《中台实践》这本书，实际上可以看到包括了两个方面的内容，一个还是整体企业数字化转型和中台建设方法论的介绍，另外一大部分则是实际的解决方案和实践案例介绍。对于实践案例本身包括了地产，汽车，新零售等诸多行业。对这本书的整体思考总结
　　对于这本书，我花了差不多3个半天的时间把本书的第一个大部分，即企业数字化转型和中台建设方法论，整体架构规划设计部分的内容做了下阅读。最大的感受就是整体的更加务实和可落地，这个可能也是跟云徙本身实施了一些B端企业本身的中台规划和建设相关。
　　而这种建设方法论和架构设计的可落地性，可以看到又回归到了包括我在前面几年就谈到了企业私有云PaaS平台规划，厚平台+应用的构建模式，企业架构规划分析和设计，SOA和云计算思想融合等方面。具体可以参考我出版的《企业私有云平台规划和建设这本书》，书里面谈到的很多内容实际上我5年前在实施大型集团私有云PaaS平台建设思路完全是一致的。
　　唯一差异点就是当时我们谈组件化开发而没有说是微服务，谈PaaS技术平台没有谈技术中台，谈业务服务共享中心和能力开放而没有谈业务中台，谈虚拟化资源池而没有谈容器云，谈持续集成和交付而没有谈DevOps最佳实践。
　　但是这些都不重要，重要的就是围绕企业传统IT，如何构建中台？
　　如果完全参考互联网和阿里的做法去构建传统企业内部中台，那么绝对是思路一条，对企业内部业务模式，信息化，传统遗留IT架构的不了解都会让互联网理想的中台思路在企业无法落地。包括书里面一点谈得好的再次提出了技术平台的概念，这个和我谈过多次的私有云PaaS平台很类似，这个技术平台不仅仅包括了传统的技术中台和技术服务，同时包括了开发框架环境，敏捷研发，持续集成和交付过程管理，容器云，集成架构等诸多内容。
　　所以在该书我们看到最大的一个变化就是重新回归到企业信息化内部，来思考企业内部的IT架构和数字化转型，企业内部的业务中台和数据中台如何建？
　　而这个建设的难点在哪里呢？
　　其一就是我们前面讲过的中台构建本身是提升业务敏捷响应能力，实现业务目标和价值的，要围绕这个最终的业务目标去构建中台。
　　其二就是回归中台这个概念的业务本质，这个业务本质就是共性业务能力下沉，并抽象为可复用的业务服务能力，能够通过组装或编排的方式快速为前台应用构建服务。
　　企业只要围绕上面两个核心目标来构建，那么最终建设的就是企业中台，这个中台建设究竟是不是微服务，是全新建还是遗留适配，是否满足云原生技术要求，全部都不是最重要的。如果以上两点有任何一点不满足，都不能谈构建了企业的数字中台。
　　再回到这本书来说，再次说明下本书对于中台建设知识和实践的学习还是有很大的参考价值，特别是给出了比较完整的中台建设方法论，各个中台建设的整体架构规划思路，这些都值得参考和学习，也有利于读者构建一个比较完整的中台知识体系。
　　整本书的第一个大部分实际上分为了数字化转型，中台价值，业务中台建设，数据中台，技术平台五个大部分的内容。对于这本书的阅读，我会尽量少引用书里面的内容，而是基于阅读后对我自己一些观点的进一步澄清，也包括对书里面一些观点保留个人差异化看法的一些说明。数智化转型
　　书里面提出了一个新词，即数智化，简单来说即数字化+智能化。
　　数智化，可以概括为通过连接产生数据，基于数据产生智能，基于智能赋予商业，进而推动业务新的增长。数智化转型是指企业利用大数据，人工智能，IoT，5G等技术，通过改善客户体验，改进产品及提高运效能来赢得客户，降低成本，形成和保持企业核心竞争力。
　　阿里在19年底的研究报告里面提出：
　　数智化转型的核心理念是以消费者运营为核心，采取实现需求端到端数据智能，供需协同的全链路数字化和供给端数字化基础设施重构的路径，实现可持续增长目标。
　　对于企业数字化转型，我们在前面多篇文章都提到了，即数字化解决三个核心：
　　连接+数据+智能
　　也就是说，数字化概念里面已经包括智能化，再新提出数智化这个概念哗众取宠了。
　　那重新回顾数字化的这三个核心的时候，可以看到。
　　不管是人和人，人和物，还是物和物的连接，在数字化时代希望达到的一个目标是通过连接自动的产生数据，而且数据本身具备时间和空间属性，而不是需要人为去录入。在这个的实现过程中可以看到IoT物联网和传感技术，5G等是关键。
　　其次在数字化转型过程中，对于数据而言，个人理解最重要的就是围绕数据驱动的核心价值观形成。而数据驱动里面又有一个核心，即业务围绕数据形成的闭环协同。
　　即业务协同产生数据，数据经过加工分析后快速地反哺业务，然后持续改进。这也是在中台里面经常会谈到的业务能力数据化，数据能力业务化。
　　数字中台是基于云计算，大数据，人工智能等新一代技术打造的持续演进的企业级业务能力和数据共享服务平台。实现业务能力数据化和数据能力业务化。从上面谈中台的核心价值可以看到，数据中的作用包括三个方面的内容。共性业务能力下沉，可复用，为上层应用快速构建服务。沉淀企业核心数据资产，进一步支撑业务协同和数据分析决策。端到端生态协同，从最开始的C端用户打通，到上下游产业链全打通。
　　因此企业构建的数字中台可以从上面三个方面来检验是否达到预期的效果和目标。即使你企业采用的传统的服务共享平台+大数据平台，只要达到上述目标也可以为企业数字中台。
　　软件定义中台
　　软件定义中台的核心思想包括两个方面的内容技术平台支撑业务中台和数据中台构建和运行，形成闭环将中台解耦为运营，控制，执行三个平面，实现统一运营，集中管控和柔性执行
　　控制平面关注业务逻辑的配置和编排，执行平面关注通用接口能力的抽象和业务稳定运行。中台可以拆解为分布式的执行单一，并且纳入到控制平面统一管控。控制平面将可信息以可配置的方式下发到各个执行单元执行。
　　个人理解提出软件定义中台这个概念本身又不伦不类了，对于软件定义存储，软件定义网络，是我们经常听说的词，什么意思？
　　即通过软件重新对硬件层面的内容进行定义，并通过标准的x86服务器来模拟各类硬件的能力。比如我们说的x86服务器完全可以模拟交换机，存储设备的能力等。
　　而软件定义中台，作者希望表达的是我们希望通过软件来实现一个高度灵活和可配置的中台能力，仅此而已，这个完全没必要用到软件定义中台这个新概念，引入太多新词，新概念导致很多东西更加难以理解。
　　其次引入了运营，控制，执行三个平面，这个估计做技术的人看到会比较熟悉，类似我们在ServiceMesh服务网关里面经常会谈到的控制平面和数据平面。但是在这里实际要看到执行平面和控制平面本身就是应该在一个平面，只是同一个平面的分层而已。下层执行层：独立自治的，松耦合的微服务模块上层控制层：对微服务模块能力能够组装，配置，协同
　　是不是感觉很熟悉？即实际上还是回到我们常说的SOA服务分层，在下层找到可复用的接口服务能力，在上层对服务进行灵活的组装和编排上。
　　什么才是中台需要的核心特性?
　　书里面提到了系统化协同，柔性化运行，可配置，动态化扩展，场景化自治，生态化开放等中台核心关键特性。那么我们来思考下什么才是真正中台阶段的关键特性。
　　要明白对于流程可配置，数据模型可配置，可视化设计界面和快速开发，权限可配置这些不是新东西，原来叫快速开发平台，现在叫低代码开发平台。目的就是提升软件开发效率，提升软件可配置性和柔性，灵活响应业务。
　　但是务必不要把低代码开发平台特性和中台特性混淆在一起谈。
　　那么对于中台来讲，真正需要的核心技术特性是什么？
　　再次回到中台的核心定义，即共享核心业务能力下沉，下沉的能力能够快速地支撑上层应用的构建，这是标准的SOA的思路。但是在SOA里面经常会谈到在原子服务上还有组合服务，还能够可视化地进行服务能力的组装和编排。
　　回到中台同样的道理，即中台实际需要的核心技术能力同样是对中台已有的API服务能力的灵活组装和编排能力，通过组装形成复合能力。
　　如果没有这个能力，那么就只有前台通过代码进行服务的组装调用，而这个本身在业务变化后就很难通过配置化的方式进行调整。中台价值-业务和数据深度融合
　　企业把全程业务的共享业务能力和数据沉淀到中台，形成中台的数据能力，并以积木式的机制进行组装，共享给前台业务调用，赋能前台业务个性的端到端场景创新。数字中台作为共享服务平台，把原来重复建设在多个独立IT系统中的数据和能力，以共享的方式提供给业务部门使用。
　　书里面多次提到到共享服务平台的概念。
　　共享服务平台在企业实施集成平台或ESB服务总线的时候就经常提到，即将遗留系统适配接入后，将可复用的接口服务统一暴露出去给上层业务使用。
　　那么共享服务平台是否是中台？我们还是回到中台本身的核心定义出发来看。服务能力可共享并满足上层应用：满足共性能力下沉集中建：不满足，共享服务平台是集成的遗留系统能力
　　因此从这个层面来说共享服务平台不是完整意义上的中台，但是已经满足了中台最核心的价值，即能力可复用，能够满足上层业务的构建需求。
　　那么传统的共享服务平台或ESB建设本身存在的问题主要体现在两点。传统架构模式下更多是数据集成，导致数据多个业务系统落地传统模式下更多是接口，接口本身并不复用
　　因此即使你要把传统的ESB总线或集成平台升级为中台，你也需要优先去解决上面两个问题。一个就是接口本身能复用，一个就是数据尽量不要多点落地。
　　打造企业业务和数据的闭环
　　谈数字化和中台建设，一直在强调一个概念就是业务和数据的闭环。
　　但是数据中台如何建立？是否一开始就搞大而全覆盖全域，全数据的数据中台。这个估计没有哪个企业一开始能够全部建设出来。
　　那么真正的思路还是回到业务驱动，业务场景和端到端流程整合优化需求驱动。即围绕你优化和整合的业务流程来梳理具体要先规划建设数据中台的哪个数据主题域，要先采集和集成哪些数据。
　　包括我们在最早实施SOA进行端到端流程整合的时候就谈到。
　　对于供应链，财务，工程项目建设等都涉及到端到端流程，那么当前你在优化哪个端到端流程，就优先围绕流程梳理，跨系统流程分析来梳理需要识别和暴露地可复用接口服务。虽然这个时候构建的服务目录不是完整的，但是却最快速的解决了端到端流程整合问题。业务中台
　　业务中台是以业务领域驱动划分边界，形成高内聚，松耦合的面向业务领域的能力中心，打造持续演进的企业级业务能力共享服务平台。业务中台的直观呈现是各个能力中心，常见的有交易中心，商品中心，库存中心等。
　　这个定义实际上我和对中台的定义基本一致，简单来说就是。
　　业务中台是共性业务能力下沉并对前台提供可复用能力，同时下沉的共性业务能力又参考微服务思想进行高内聚，松耦合拆分，形成多个能力中心。
　　微服务不是业务中台，微服务只是能力中心构建的最佳技术实践。
　　业务中台的核心架构是纵向切分，横向分层。对于纵向切分则是微服务架构思想，而对于横向分层则刚好是SOA架构思想。所以中台思想 = SOA+微服务思想融合。
　　本书给出了中台的三层模型，即实体层，协作层和活动层。
　　对应业务中台各个中心究竟如何分类，在我博客上很多文章里面都有谈到。实际上我的分发是数据类中台，业务和流程类中台，规则类中台。但是我这个分法协作层和我的规则类中台是否能够对应暂时无法确定。
　　比如书里面举例的促销中心，评价中心，在我这并不属于规则类中台，仍然是属于业务和流程类中台。我们的规则中心很简单就是完全是给出具体的逻辑规则为主的中心，类似原来经常提到的预算中心。为何预算中心为规则中心，因为预算中心和外面打交道很简单，就是你给我一个输入，我告诉你有无预算，这就是一个规则。
　　基于这个我们看到，如果你给我一个用户ID，你告诉我们这个用户的评级水平。这也是要给显然的规则，但是这个规则往往需要大量数据分析计算后才能够得出，那么这个API能力谁来提供? 而这个API能力刚好就是数据中台需要提供出来的API服务能力。
　　如果把前台功能看成一个完整的业务流程，那么我们将其分解为：
　　业务流程 = 业务功能或活动*M + 业务规则*N + 业务数据*K
　　即业务流程的完成就是调用了中台的业务功能模块，规则模块，数据模块进行组合和编排后完成完整的端到端业务流程能力。所以你中台做得足够好，那么前台的应用就能够足够轻，足够敏捷，这和我们SOA的服务重用，服务组合，服务编排的思路完全是一样的。
　　中台建设的5步法
　　对于中台建设的5步法，即业务抽象-》高阶设计-》组件建模-》开发交付-》持续运营，整体还是有参考意义。从业务分析和抽象入手，然后进行顶层设计，再到详细的组件模块设计。
　　那企业中台规划和建设中的整体关键点在哪里？
　　在整个规划建设阶段，业务和技术两条线一定要分离去思考，最后再融合，实际上你可以看到业务中台的规划，包括到接口能力识别都完全偏业务层面，是业务顾问和架构师驱动的，而且整个过程和中台的技术选型，技术架构没有太大的关系。你可以完全将焦点关注在业务流程和业务建模上。其次才是中台建设中的技术架构如何规划，这个技术架构设计到传统的iaas,paas平台，也包括当前主流的技术服务，devops，微服务开发框架和环境等，这些技术都是为后续的中台模块开发构建服务的。
　　中台构建策略
　　书里面谈到基于领域驱动分析和设计的思路来构建业务中台，这个本身没有任何问题。而领域分析的核心本身包括了三个方面的内容。业务场景梳理：根据高价规划业务领域梳理业务场景领域模型推导：根据场景，活动，规则，事件抽象领域模型高阶规划调整：结合业务场景和能力中心来持续优化调整
　　对于整个中台的构建，实际上包括了两个方面的内容。其一是要确定究竟划分哪些能力中心，能力中心划分的颗粒度是如何的。其二是确定具体哪些业务功能和业务数据应该分配到不同的能力中心上面。
　　对于能力中心中具体的业务功能，API接口等都需要不断迭代和优化。
　　业务中台规划真正难点在哪里呢？
　　实际上还是在于业务场景梳理完成后，对业务功能活动，业务数据的聚类分析上面。这个聚类可以采用面向对象的方法，类似领域驱动分析方式进行抽象和聚合。也可以采用面向结构的分析方法进行CRUD分析后进行聚合。
　　个人理解不要认为采用了领域驱动分析设计就一定排斥结构化分析方法，特别是传统结构化分析方面里面的CRUD矩阵分析是进行微服务拆分的关键方式之一。数据中台
　　数据中台是一种将企业沉睡的数据变成数据资产，持续使用数据，产生智能，为业务服务，从而实现数据价值变现的系统和机制。
　　对于数据中台，实际上我在前面文章里面已经专门谈过。即数据中台的核心还是可复用的数据能力，那么什么叫可复用的数据能力？
　　这个数据能力不是来自于上层数据的下沉，而是来自于跨越数据的抽取和整合。其次这个数据能力不仅仅是满足传统的大数据分析决策使用，更加重要的是实时的反哺业务形成数据使用的闭环。因此我们在看一个数据中台建设的时候相当关键的两点包括：数据中台能力接口是否之间提供给前台应用在业务协同中使用？数据中台是否开放共性数据服务能力？
　　如果以上两点都是否定的，那么企业可能根本就没有进行数据中台的建设。而仅仅是在进行大数据平台或分析平台的建设。
　　任何一个数据中台，底层都需要一个提供数据存储和处理能力支撑的技术平台。
　　这个技术平台如果你有大数据需求，构建出来的就是大数据平台。但是如果你没有大数据需求，那么用传统的数据集成和管理技术平台即可。
　　其次，数据中台的范畴包括了如下几个方面一套底层的数据技术平台（可以是大数据平台，也可以是数据集成平台）一套数据资产（业务层面的内容，实际数据，数据模型，算法装进来了）一套数据服务能力提供和共享一套数据管控和治理标准规范体系
　　因此可以看到对于数据中台核心重要的反而是数据资产+数据服务能力共享这两点,而这两点在一般的大数据平台并不会包含。如果整个数据中台建设有大数据平台，那么大数据平台也仅仅是一个底层技术平台和技术实现手段。
　　传统IT架构下规则引擎能力迁移
　　大家可以思考下，如果我们当前需要采集多个能力中心的数据，进行规则计算后才能够得出一个具体的结果。在传统架构下这个能力属于规则引擎的能力。但是在新的中台架构下，我们看到这个能力实际上已经迁移到数据中台来实现。
　　基于数据中台采集各个能力中心的数据，基于自己的规则库进行规则计算，最后得出最终的结果，这个结果之间采用API接口的方式供前台应用调用。
　　我们可以举个最简单的例子，比如对于订单折扣，我们需要首先计算该客户的信用度，而客户信用度的计算需要采集用户中心，订单中心，支付中心各个中心关于用户的静态数据和动态行为数据最终得出一个信用评级。因此这个基于用户编码获取信用评级API接口来源于数据中台的能力提供，前台应用基于获取到的信用评级再进行具体的订单折扣计算。
　　所以不要将数据中台简单理解为仅仅用作内部管理人员使用的数据分析和决策，这个理解是完全错误的，如果仅仅是这样，那么数据中台就和传统的大数据分析平台没有任何区别。技术平台建设
　　技术平台不等于技术中台，在书里面提出技术中台特指PaaS平台提供的各类技术服务能力，类似我们常说的消息，缓存等技术服务。技术平台是基于云原生架构体系打造的服务企业数字化中台建设的全景化平台基座，即业务中台和数据中台建设都需要基于技术平台进行。
　　技术平台通过体系化的工具链，协同研发各角色，进行需求全生命周期跟踪，提供低代码开发平台，全平台构建等能力，实现多维度应用管理，从给规范整个研发过程，加速整个研发效率。
　　对于技术平台总体来说就包括了我们常说的研发过程管理，开发工具和框架，运行态支撑，运维监控平台等几个关键内容，在前面我给出过具体的技术中台架构，整体的底层是容器云平台和DevOps过程支撑平台。在上面基于整个软件生命周期分为了开发态，运行态和运维态。开发态重点是开发框架和环境，低代码开发平台运行态重点是容器云平台运维态重点是运维监控平台，服务链监控
　　整个技术中台架构如下：
　　在整个技术中台架构完全和云原生技术解决方案匹配，同时我在原架构图的基础上增加了微服务治理管控的内容。当前最底层是技术平台，中间是业务中台+数据中台，上层是业务应用的构图思路完全没有问题。但是整体来看对于数据中台中的大数据平台仍然应该划归到技术平台层更加合理。
　　中台的服务能力与API网关进行接入和开放
　　对于API网关本身也是技术中台里面重要的一个关键组件，即中台提供的API服务能力最终还是接入到API网关，由API网关统一对外开放。如果再加速对API接口服务本身的全生命周期管理，API接口服务的运营和自服务能力的话，还需要基于API网关引擎来构建完整的服务能力开放平台。对于服务能力开放平台可以参考我前面发布过的文章。
　　那么现在问题就变成了在ServiceMesh完全去中心化的架构下，是否还需要API网关来统一管理对外开放的AP接口服务能力？
　　这个问题点大家也可以思考下。我个人理解是如果涉及到对外能力开放和管理，采用API网关仍然是最佳的实现策略和方式。
　　对于该书的中台建设案例还没有细读，这部分内容后续再进行专门的分享和总结。