今天就接着上次聊到的中台实战提到的项目管理系统和采购管理系统的案例继续讲，看看数据中台方案是怎么实践的。

先回归一下上次案例的主要问题：

在A公司里项目管理系统和采购管理系统是属于独立两个业务线团队，在后台是有着两套独立的业务数据体系，这些数据由各业务线团队进行自主定义和维护的。

但在一体化平台建设中，单独对两个系统的业务数据的维护成本是非常高的，而且把两个原本是有数据关联的系统阻隔开后，那么系统对数据之间的关联应用效率就非常地低。所以我们要针对这些问题进行中台方案的构建。

步骤一：强干弱枝

在A公司的一体化平台中，包含了项目管理子系统、采购管理子系统、资产管理子系统等7个业务子系统，涵盖的数据量是非常的大。

那么，对于庞大的数据量时，我们首先要做的是把数据剥离各业务线团队，进行抽象提取，保留“主干”。将数据存储至独立的数据中心（即中台1.0）进行维护，打破各业务线团队之间的阻隔墙，此时原有的数据环节变为：

项目数据与其他各业务线生产的数据都汇总到数据中心，在数据中心对各业务线数据进行统一维护后，面对各业务线团队的数据需求，我们可以在数据中心划分各虚拟数据源以支撑各业务线团队使用。

数据中心是为整个A公司的产品基础服务提供全局的数据。

步骤二：特异性管理

在数据应用中，我们会经常遇到对不同业务线中有关联的数据进行调用的情况，例如：在采购管理系统中新增了一个采购项目，那么项目管理系统此时就需要对该采购项目进行数据新增。

所以，对其他业务线数据进行调用时，需经过这些步骤：

这时我们可以看到从其他业务线数据源调用数据时主要做了两个步骤的工作：

• 数据提取：根据业务方（项目管理系统）所要的数据范围提供数据（如，本次业务需要读取项目ID、项目名称这两个字段）；
• 数据业务格式化：根据业务方（项目管理系统）所要的数据格式进行特定数据格式/顺序生成（如，业务方A（采购管理系统）返回数据格式：项目ID=“12345”+项目名称=“项目1”；业务方B（项目管理系统）返回数据格式：项目名称->“项目1” and 项目ID->“12345”）。

看完以上两个步骤的工作，有没有感受到实际上这就是原本整个后台支撑系统巨大的工作量的重要原因。像上文提到的每次接口只能为一个业务方提供服务，而且这个接口由于数据返回格式是特定的所以具有很强的特异性，这样就导致后端开发需要不断地进行新的提供数据的接口开发工作。

这无疑是对企业资源的巨大浪费。这种情况在我们的日常工作中应该是非常常见的（此处有没有共鸣），例如：产品迭代升级中每次版本更新导致需要重新设计接口（新旧版本就同一个数据的不同封装形式的取用）；老版本数据接口与新版本的同一数据接口不同，需要重新设计编写，且需要分别维护。

对于这个问题，我是这样解决的：这两个步骤中第一个服务共性很高，很容易提取成一个公共服务。所以，我们就在数据中心提供一个标准的数据提取接口，各个业务方只需要传输需要什么字段，我们的统一数据返回接口就把数据返回至各业务方。

这样，在所有的版本中，我们始终只需要对同一批相同功能的接口进行维护（负载均衡），各个接口没有任何特异性的标准的数据提取接口，只根据请求内容进行内容返回，这样就可以大大减少重复低效的开发工作量。

针对第二步数据业务格式化的特异性特别高，我们仍将这种与业务强相关的步骤放到业务端中，由各业务线进行数据处理，加工成他们需要的组织形式再返回给客户端。

此时，后端开发人员只需要开发面向数据源的数据输入接口，也就是将收集的数据进行清洗整合成为中台的数据原材料。数据中心也就成为了中台，将各个业务数据存留在这，并提供统一的取数方法。前台人员根据需要去请求数据，将原本后台的这两个步骤统一处理后划分为：数据获取（中台）与数据业务端组合（前台）两部分：

最后

最后给大家一个个人理解中台战略，特别是业务中台的搭建是一个高度定制化的战略，如果我们想要发挥中台化战略的最大价值，就需要依据不同公司、不同业务、不同阶段的特征去定义与动态调整中台演进方向。

就像本文的项目数据中心案例一样，只有最适合当前业务的中台框架，才是真正的解决方案。

作者：叫我阿逸，公众号：人云逸云；产品道路上不断前行的产品小白

本文由 @叫我阿逸 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议