在年初，我花了差不多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. 数字营销：复杂度低，并发量高，敏捷需求高

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

1. 互联网+重构数字营销链条（线上+线下，多终端，多渠道，多场景全域覆盖）
2. 大数据和AI全面赋能精准营销
3. 平台化和微服务化下传统架构变更和演进

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

数字中台的构建

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

因此中台建设一定是梳理共性业务入手，这个是中台构建和以往的技术化PaaS平台建设最大的区别。这本书里面对中台解读有句话和我思路是一致的，即：

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

企业内遗留系统做集成，然后将接口统一注册到ESB，是否是中台？

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

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

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

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

业务中台和数据中台

业务中台是围绕以交易为核心管理的领域组成，典型的业务中台由多个业务服务中心组成。而数据中台是实时，敏捷的为业务提供数据服务和数据分析服务能力的平台。

对于数据中台，本书给了一个定义可以参考即：数据中台是一个用技术连接大数据计算存储能力，用业务连接数据应用场景能力的一个平台。连接能力是数据中台的精髓。而这个定义本书并不足够准确，这个在我数据中台文章里面谈到过，即：

数据中台本质是一个能够实现跨域数据融合，并在数据融合后对数据进行整合加工和分析，提供增值的数据服务能力给业务使用的一个平台。在我这个概念里面多强调了两点，一个是实现跨域数据融合，一个是提供增值的数据API服务能力给业务使用。

业务中台和数据中台的关系如何理解比较好？

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

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

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

而到了数据中台注意看到的已经不是一个个拆分后的模块中心，而是一个整合后的数据共享库，即我们经常说的分布式的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. 系统过度设计（按理想化的思路去设计，而不是按照持续迭代，逐步演进的思路）

注意，中台建设是逐步演进出来的，而不是设计出来的，一切都来源于实践。由于内容较多，对于中台建设方法论，中台架构设计，准备再起一篇单独讲。

中台建设方法论

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

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

上面这句话可以看做是中台建设方法的高度概括，是否是感觉很熟悉？

确实，这个方法实际上和我们传统的基于SOA思路进行的企业架构规划方法论很类似，从业务驱动IT，端到端流程分析入手，形成业务架构，然后由业务架构到应用架构，再到详细的应用模块和功能清单。

那么实际上在使用这个方法过程中，出现最大的要给区别在哪里呢？

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

1. 业务部门或业务科室概念 -》应该转变为业务单元的概念。
2. 应用系统的概念 -》不再有应用系统的概念，而是应用能力单元（对应中台各中心）

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

在这里我们先说下业务中台，实际上你可以看到业务中台建设的核心就是两个事情。

• 其一应该建设哪些中心，各个中台微服务中心的颗粒度如何把控？
• 其二就是各个中心应该提供哪些API能力接口？API接口如何粗粒度和可复用。

归根到底，业务中台本质是一个体系或一个系统，它实现企业核心的业务运行机制，因而处于企业运行生态的核心位置，所有的应用系统都必须与之发生关联。中台的存在不仅仅是抽取可复用的能力，众多的可复用能力仅仅是中台的形，核心的业务数据和业务流程才是中台存在的本质。

中台建设方法论和核心框架

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

1. 能力支撑是基础（能力存在的目的是通过编排或组合支撑业务流程）
2. 中台自治是承载形式（注意中心和微服务模块的区别，一个中心还可以存在多个微服务）
3. 三层模型是骨架（实体层，协作层，活动层）
4. 五步法是指导思想（业务抽象-》高阶设计-》组件建模-》开发交付-》持续运营）

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

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

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

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

业务流程 = 业务功能或活动*M + 业务规则*N + 业务数据*K

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

中台建设的5步法

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

那企业中台规划和建设中的整体关键点在哪里？

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

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

调整的重点是业务架构+数据架构+应用架构合并思考，将应用架构中的技术架构拆分出来单独思考。由于弱化了应用系统的概念，你会看到，我们在业务架构中的业务组件模块，和应用架构中的应用组件模块完全可以合并为一个内容，而不是分开的还需去映射的两个东西。

也就是业务架构和应用架构统一了。应用架构中原理的共性应用能力支撑，类似4A，流程引擎，门户等也没有了，这些都全部剥离到了企业整体大架构框架里面。业务+数据+应用的高度融合统一，而对技术又单独的抽象剥离才是对传统企业架构最大的调整点。

另外，对于中台各个模块如何划分，划分的颗粒度，这个始终都是中台建设的一个关键点。

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

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

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

既最终的核心分析方法思路为：

业务分析分解-》矩阵分析+流程化验证试算-》多次迭代。

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

中台架构与设计

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

当然要谈这个你可以分解为技术中台，业务中台和数据中台分开来谈。

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

1. 单个微服务模块的开发是如何的？(数据，业务，规则类不同的模块设计原则）
2. 模块提供的API接口设计和开发，如何集成和统一管控（安全，限流，注册中心等）
3. 跨模块的协同能力，重点在前台如何应用中台能力，服务编排，APM，服务链监控上

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

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

数据中台建设

最后一部分谈下数据中台建设方法论方面的内容。

对于数据中台，所有人最疑惑的就是和传统的大数据平台，BI和数据仓库的区别，包括数据中台和业务中台的区别。而对于数据中台我在前面有一个最基本的理解，即数据中台就是一个分布式的ODS库，而且这个ODS库能够提供数据服务API能力给业务应用，业务协同使用，这个API能力接口本身具备一定的准实时性。

从最近对数据中台的进一步阅读和理解可以看到，数据中台是为满足业务协同需要而提供的准实时的数据服务能力这个理解没有错，理解这个的原因是和传统的BI和决策分析系统分开。传统的BI和决策分析系统更多的是提供给内部的管理决策用，而且往往不实时。

那么我上面理解哪里没有理解完全正确？

实际上关键点在数据中台不仅仅是分布式的ODS库，在前面我们看到提供业务系统的数据服务能力。这个数据服务能力可以是经过简单的数据采集集成后形成的中间表或汇总表就能够提供的数据服务能力；还有一种还是要建立数据模型，建立数据分析算法，经过分析计算后才能够得出结果的数据服务能力，类似我们经常说到的推荐引擎能力。由于有了模型，有了算法，因此你可以将其理解为一个小BI，但是这个小BI是面向业务协同的。

数据中台的设计方法论

这本书给出了建设数据中台的八字方针，具体为横向规划，纵向切入。

对于横向规划即你在构建数据中台的时候，必须考虑横向业务协同，考虑横向业务协同中带来了哪些数据层面的协同和共享需求，而这个恰好是你后续进行数据采集和集成的基础；对于纵向切入，实际上又回到了数据中台的分层建设上，比如我们常说的数据平台建设，数据模型建设，分析算法建设等。

不管是业务中台还是数据中台，我们一定要搞清楚，哪些是中台里面的技术部分，哪些是中台里面的内容部分。类似数据平台来说，里面的类似分布式存储，分布式数据库，数据采集集成工具，Hadoop框架和运行平台等都是属于里面的技术部分，而对于最终的数据域和数据对象，分析算法，数据服务API才是里面的内容部分。不论你建设哪个企业或领域的数据中台，对于技术部分差别不大，重要的是里面的数据模型和API设计。

数据中台的功能定位

数据中台需要实现数据的分层与水平解耦，并具有沉淀公共数据的能力。数据中台可分为三层，数据模型，数据服务与数据开发，通过数据建模实现跨域数据整合和知识沉淀，通过数据服务实现对数据的封装和开发，快速灵活的满足上层应用的需求，通过数据开发工具满足个性化数据和应用的需要。

综上描述，数据中台应该具备以下几项能力

1. 数据整合能力。（需要一套标准的数据采集和集成体系）
2. 数据服务能力。（将数据模型按应用要求进行服务封装，提供数据服务能力）
3. 数据开发计算能力。（数据的基本处理和加工，数据的开发，数据的分析计算）

这几项能力说完，我们对数据中台的理解和认识就更加清楚。同时给出了我们构建数据中台的分阶段迭代思路。简单来说你一开始根本没有必要构建数据中台，但是你会发现些问题，最明显的就是发现往往我需要一个数据的时候需要从多个微服务模块提供的API接口获取并自己加工组合，对于应用来说这个显然不方便，也不符合服务粗粒度的原则。

1)数据中台解决数据整合的问题，将整合后的数据服务能力统一提供给前台。

在第一步问题解决后，你才会考虑数据本书的开发和挖掘，即在数据本身的基础上，我们如何进行数据开发，挖掘数据更大的价值，同时将挖掘分析后的结果再以API接口服务方式给上层使用。

2)进行数据开发和挖掘，将计算后的有价值结果，也以API接口服务方式给上层使用。

对于第一步更多的是我前面说到的分布式ODS库+中间汇总表解决问题，而到了第二步就是需要小BI层面的能力来解决问题，即数据模型，维度表，分析计算模型。

数据中台的建设范围

企业要建设一个完整的数据中台，包括了哪些内容，这本书将数据中台架构分为两层：

1. 工具平台：包括了大数据平台，研发平台，自助分析平台，标签平台，运维平台
2. 数字资产：分析模型，算法模型，分析专题

对于这个分法暂时先保留意见，对于这篇文章的截图大家也可以看下奇点云对数据中台的一个架构体系。对于数据中台来说，我们看到本身应该是包括了底层的技术平台。

技术平台包括了数据采集集成平台，数据的存储平台，数据的处理平台，数据服务API开放平台，数据分析平台大的是Hadoop体系，但是有些小的技术工具还需要整体纳入才能够完成一个完整的体系。

在这个技术平台上我们确实可以再增加三个子系统，即一个是前生命周期的数据研发平台，一个是后生命周期的运维平台，一个是数据管控治理平台。

技术平台后就是内容方面的，内容本身又包括了我们前面说的分布式ODS库，然后是面向业务协同和面向主题决策两个维度的分域数据模型和数据中心。其次是各种分析，算法模型，推荐引擎等。

数据中台和数据资产

当我们再次提及数据资产的时候，我在思考业务系统是否是企业资产，原来我们做SOA的时候强调的可重用的API接口服务是否是企业的资产。当然这些都算做是企业重要的资产，但是你可以看到只有数据中台这个数据资产是持续性和延续性最强的。

类似我们说的有清香，酱香，浓香各种白酒一样，只有酱香型的是存储的越久味道越好，而数据资产也是这样，数据和沉淀的越久，数据最终开发和挖掘后发挥的价值也就越大。