读中台战略笔记01

来源于  http://blog.sina.com.cn/s/blog_493a84550102z7ap.html

 

我从上个周末开始，花了差不多1周的时间把这本书读完《中台战略-中台建设与数字化商业》，读完后整体感觉这本书可以打4颗星以上的水平。

 

整本书实际上讲两个方面的内容，一个是数字化营销，一个是中台建设，融合起来说就是企业围绕数字化营销这个目标来说，如何进行内部IT架构转型或如何构建支撑企业数字化营销的中台平台。从我这个角度来说就可以看到，这本书实际上是中台本书建设方法论和架构设计部分内容稍微偏粗，但是对于数字化营销等内容偏多，但是仍然和该书的副标题是切合的。

 

这本书我看完后推荐给我们的SOA顾问和项目经理看，同时推荐给我们做电信运营商的所有顾问看，同时安排对于BSS域的顾问看完后整理一篇读书笔记。最近两年几个电信运营商本身都在做已有架构重构，大中台建设，内部IT全部上云（云原生DevOps）改造。而这本书不仅仅是中台建设方面可以参考，对于数字化营销层面对我们的BSS域顾问也有较大的参考价值。

 

我始终认为是一本书在适合的时候给适合的人看，书本身才能够发挥最大的价值。有时候并不是说书不好，而是看书的人，选择看书的时机不对。比如这本书来说，有些内容和经验之谈，往往说到了，但是并没有点细化，但是真正有过类似经验和实践的人往往就有很强的共鸣感。

 

对于这本书，截图我也给出了书籍本书的目录结构和关键内容，看完后给出我理解的受众为：

 

1. 准备做业务或IT数字化转型的企业管理层，特别是负责市场营销的和企业CIO，CTO阅读

2. 对于软件企业的项目经理，咨询企业的IT咨询顾问阅读

3. 做数字化营销的团队和人员，做各类电商平台的产品经理，运营经理阅读

4. 软件企业的业务架构师，流程总监，IT架构师阅读

 

这本书的读书笔记我不太详细的摘录书籍里面的内容，仅仅对里面的一些关键概念做摘录，同时对看完这本书以后的我自己的一些关键感受和观点做记录。

 

企业数字化的关键特征包括三个方面，即连接，数据，智能。连接包括了人员，客户，供应商，设备。由于连接产生了数据，有了数据后产生智能分析和应用。可以看到，这个和我们前面谈的物联网云平台的三点完全是一样的，首先是连接，通过连接满足了业务协同和集成；在连接完成后能够积累和采集数据。然后数据逐渐积累后可以利用数据进行进一步的智能分析。

 

连接解决的业务协同问题，对应到业务中台；数据解决的是数据能力提供，对应到数据中台。而业务+数据的双中台才能够更好的支撑企业的智能化分析和应用。

 

这本书的另外一个重点是讲数字化营销，因此还是看下书里面对这个概念的定义：

 

数字化营销师以技术+数据为双驱动，对企业的传统营销进行互联网化，数字化，智能化改造，进而帮助企业构建消费者全渠道触达，实现精准互动和交易的过程。

 

从这个概念里面可以看到数字化营销需要技术支撑，而这个技术最重要的就是企业数字中台的建设，数字中台师企业级互联网及大数据架构打造的数字化创新平台，包括业务中台和数据中台。数字中台成为指导企业数字化转型，实现数字营销的主流方法。

 

所以这本书总结下来就是，传统企业在当前从消费互联网到产业互联网发展下，必须进行数字化转型，而这个转型里面有个重点就是以数字化营销做为关键突破口，而数字化营销本身是技术+数据双驱动，要做好就必须构建强调的支撑平台，这个支撑平台就是我们说的数字中台。

 

那么围绕数字化营销如何构建中台，包括业务中台，数据中台，技术能力等，其构建方法流程是如何的？构建关键技术工具是如何的？在中台构建完成后，我们再来复盘下构建的中台能力是如何支撑和赋能数字化营销的。以上可以理解为书籍整体的关键脉络。

 

以下是个人阅读后的重要观点记录，在不再图书章节详细整理笔记。

 

企业为何要做数字化转型？简单来说应该是两点，业务创新和敏捷需求和连接生态构建驱动。首先就是企业需要更加敏捷的响应市场和消费者个性化需求，这个敏捷的实现需要有一个强大的数字中台。其次就是我们经常讲的，连接才有价值，企业要逐步开放，形成开放+连接的上下游生态，合作伙伴生态。

 

数字中台的核心是业务中台和数据中台。对应企业而言转型的主要路径是业务数据化和数据业务化。简单来说就是首先将业务中台化，业务协同基于业务中台各组件模块提供API能力来支撑，同时在这个过程中积累有价值的数据资产（数据中台）；而数据业务化理解为数据中台最终有提供有价值的业务API能力反哺给业务目标使用。

 

企业数字化转型实际上涉及到三个大的领域，其一是传统ERP领域，其二是智能制造和工业大数据，其三是数字化营销。可以看到这本书重点还是在讲数字化营销层面的内容。当然对ERP领域也有一定的参考借鉴价值，但是完全这个方法来做传统ERP转型那肯定是行不通的。

 

我们可以来比较下三个方面内容在业务流程和逻辑复杂度，并发量，敏捷需求三方面差异。

 

1. 传统ERP： 复杂度高， 并发量低，敏捷需求中

2. 智能制造：复杂度中，并发量中，敏捷需求低

3. 数字营销：复杂度低，并发量高，敏捷需求高

 

如果从敏捷需求的响应角度来看，数字化转型和中台的优先级应该是数字营销，ERP，然后是智能制造。

 

数字化营销的三个重要趋势

 

1. 互联网+重构数字营销链条（线上+线下，多终端，多渠道，多场景全域覆盖）

2. 大数据和AI全面赋能精准营销

3. 平台化和微服务变更传统架构(--》云原生发展）

 

建立一个全面服务化架构的数字中台，依靠平台能力微各个前端输出统一的管理能力，帮助企业实现业务数据化，数据业务化，赋能企业智能化营销，将会成为传统大型企业全面数字化转型的最佳方案。

 

数字中台的构建

 

对于中台，在我博客前面文章中也多次提到，中台的本质是共性业务能力的下沉，同时下层的共性业务能力不再像传统的单体大结构，而是拆分为一个个独立自治，可灵活组合的微服务模块单元。然后再将共性业务能力抽象为可复用的API服务接口统一对外开放，前台可以基于这些API能力快速组装和编排应用，敏捷响应业务。因此中台建设一定是梳理共性业务入手，这个是中台构建和以往的技术化PaaS平台建设最大的区别。

 

这本书里面对中台解读有句话和我思路是一致的，即：

 

中台，通过对业务，数据和技术的抽象，对服务能力进行复用，构建了企业级的服务能力，消除了企业内部各业务部门，各分子公司件的壁垒，适应了企业，特别是大型企业集团业务多元化的发展战略。基于中台，可以快速的构建面向最终消费者和客户的前台应用，从而满足各自个性化的前台需求。

 

只对企业内遗留系统做集成，然后将接口服务统一发布到ESB集成平台，是否是中台？

 

这里可以看到的是提供了统一的服务目录库，上层仍然可以基于这些API接口服务能力进行服务的编排和应用的组装，那么这种情况下实际和理想中台的差别究竟在哪些地方？具体如下：

 

1. 遗留系统本书未进行拆分或微服务化，不具备后续云原生和朝云迁移的能力，也不具备扩展能力

2. API接口为遗留模式下偏重的类似SOAP接口模式。ESB本身也承担了过多的协议转换和映射职责

3. 数据多点落地，整体架构模式偏接口集成，而非服务能力实时共享。

 

业务中台和数据中台

 

业务中台是围绕易交易为核心管理的领域组成，典型的业务中台由多个业务服务中心组成。而数据中台是实时，敏捷的为业务提供数据服务和数据分析服务能力的平台。对于数据中台，本书给了一个定义可以参考，即：数据中台是一个用技术连接大数据计算存储能力，用业务连接数据应用场景能力的一个平台。连接能力是数据中台的精髓。

 

那么两者的关系究竟如何理解比较好？

 

首先我们说要构建业务中台，来解决最基本的业务流程和业务协同问题。其次是业务数据化，即将业务中台存储的数据统一存储到数据中台并进行二次加工。最后是数据中台将加工后的数据形成业务可以使用的数据服务接口或数据分析服务能力即可反哺给业务应用。这就是两者的关系。

 

两者的核心协同就体现在业务数据化，数据在业务化反哺业务上。

 

所以这里我们由必要澄清一些理解，即你看到的中心或模块，不论是以数据为主体的，还是以业务交易或规则为主体的模块，这些模块都属于业务中台的内容。类似我们看到的供应商中心，供应商是主数据，但是供应商中心仍然是属于业务中台的范畴，不是数据中台。

 

而到了数据中台注意看到的已经不是一个个拆分后的模块中心，而是一个整合后的数据共享库，即我们经常说的分布式的ODS库，但是这个还不够，在ODS库上我们还是做了部分数据仓库要做的数据模型涉及，维度表设计等。但是所有做的这些事情，最终提供的支撑API能力都是实时为业务服务的，不是为管理决策服务的，这个是和传统的BI分析平台最大的区别。

 

即一个是为业务服务，一个是为管理决策服务；一个是实时性要求，一个是定期非实时需求。

 

举一个最简单的例子来说，我们浏览一个电商平台的时候，刚我们购买一个商品的时候，会出现一个推荐的其它商品列表，这个针对性推荐就来源于我们数据中台的API接口服务能力。数据中台要提供这个能力不容易，一个是要采集集成日常的商品，用户，交易，关联交易数据，一个是基于这些数据要做分析模型，然后基于分析模型最终得出一个推荐商品列表。这个数据中台提供的API接口服务是实际业务应用场景中实时要用的能力，是为业务流程和协同服务的。

 

可以看到数据中台反哺业务的能力越强，我们业务能够为用户提供的增值服务价值就越大。

 

中台和平台间的关系

 

对于中台构建中，我们有一个概念就是技术中台，实际上在中台标准概念里面是没有技术中台的说法的，技术中台应该划入到标准的PaaS技术平台里面去。而传统的PaaS平台能力我们原来也讲的很清楚，即应用托管能力，各类技术服务提供能力。只是现在应用托管能力转变为了容器云和集群调度管理。

 

所以对于中台和平台的关系，包括技术中台和已有的云PaaS平台边界是我们需要思考的问题，对于该问题我们分两个层面进行思考，第一就是混合云或部分能力自建模式；第二就是基于公有云能力完全的云原生模式。这两者模式本身存在一定的区别。

 

方式一：混合云或部分自建模式

 

在这种模式下，我们理解云平台的边界为容器云PaaS平台，即我们常说的通过Docker容器+K8S来统一对外提供容器资源和集群编排调度能力。

 

在这种模式下，技术中台为：DevOps过程支撑平台+技术服务提供+大数据集成技术工具

 

对于技术服务提供既包括互联网常说的消息，缓存，日志，通知，分布式存储，分布式数据库等技术服务能力，同时也包括传统企业信息化应用中的4A和流程引擎。

 

方式二：基于公有云能力完全的云原生模式

 

我们可以看下当前的阿里云和华为云，可以看到当前的公有云平台除了提供完整的容器云PaaS平台，各类的技术服务能力外，也还提供了DevOps的过程支撑能力平台，方便你进行持续集成和交付。

 

也就是说在这种模式下实际我们没有必要有任何的技术中台，即使涉及到你项目要使用的一个个性化的共性技术组件，我们仍然可以把他放到业务中台里面，作为业务中台的一个模块进行管理。注意在这种模式下，开发团队真正只需要关注业务中台中的各个微服务模块功能和API接口开发，其它你都不需要关心和自建。

 

同时你按照标准规范开发的东西，能够确保快速的部署和交付到公有云基础设施，而且保证足够的可靠性和资源弹性扩展能力。

 

在前面几篇文章我都在谈云原生，云原生应用的一个核心就是为了公有云平台而生，不仅仅是设计开发，部署交付，同时也包括后续的运维监控。为了更好做到这点，需要类似DevOps，微服务，ServiceMesh等相关的过程，工具技术来进行支撑。

 

对业务创新的敏捷响应和支撑能力-P86页

 

企业已经过了通过软件来完成信息化的年代，企业需要的是创新的机会，变革的机会，即：

 

1. 企业的IT基础设施能够全面云化，能够实现朝云端的全面迁移能力

2. 业务架构必须互联网化，只有这样才能够组件化，只有组件化才能够更好的组合编排

3. 数字化转型必须要实现数据在线和智能化

 

共享创造条件，企业都会在思考，如何更好的实现客户共享，会员共享，交叉引流，形成自有流量的生态平台。就我对公司福利平台思考一样，从我们简单的面向B端企业，但是B端企业入驻自然就是最终的企业员工入驻，即从B到C，而这个时候无法真正裂变，真正的关键点还是C端用户如何围绕自己的强关系进行类似社交电商方式的进一步推广和引流，这个往往才是真正的裂变点。

 

通过C端用户再引流，同时把引流的用户又变成自己平台的自有流量并进一步经营。

 

中台实施的教训，书里面提到了中台建设和实施的一些教训共参考：

 

1. 团队组织错误（实际应该是按devops组织思路，建立岗位角色全覆盖的高度自治团队）

2. 业务拆分不清（业务和需求没有梳理清楚，直接导致的就是模块划分不合理，接口设计不合理）

3. 微服务被滥用（最常用的就是微服务粒度太细，比如设计上100个的微服务模块）

4. 系统过度设计（按太理想化的思路去设计，而不是按照持续迭代，逐步演进的思路去设计）