从概念走向现实：数据中台到底有什么用

Posted 2021-02-21

自从阿里提出的“小前台、大中台”之后，“中台”的概念纷至沓来，甚至一些现有系统、架构都纷纷贴上了各种中台的标签。对此，这个“看上去很美”的概念也引起了不少质疑：数据中台到底有什么用？每一家企业都需要数据中台吗？日前，“CIO& IT经理精英汇”社群对此展开了热议，不同行业的企业IT负责人发表了看法。本文将从数据中台是什么、数据中台适合哪些企业、构建数据中台要做哪些准备三个方面多角度解读数据中台。

概念先行的“中台”是什么

讨论中，多数群组成员对“数据中台”保持审慎的态度。有人认为“这两年中台感觉是雷声大、雨声小”；有人觉得“中台还停留在概念阶段，不大用到 ，所以不怎么了解”；还有的表示“虽然现在也在搞中台，但感觉找不到入口”。

没有中台的时代，项目需求稳定时，“前台”和“后台”两个部分已足以支撑。但随着经济和社会发展，如何快速响应用户需求成为了主要矛盾，不断迭代和试错才能让企业在竞争中立于不败。这时如何避免重复造轮子、提升开发效率才是应该思考的关键。中台就是在这样的背景下应运而生。

“中台”本身是一个比较抽象的概念，业内也是众说纷纭，莫衷一是。ThoughtWorks负责中台咨询业务的总负责人王健提出过一个相对清晰的定义：中台是“企业级能力复用平台”。中台建设根本上是为了“弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，提供一个中间层来适配前台与后台的配速问题。”

从这个定义，我们至少可以对“中台”的特征有基本的理解：“企业级”表明中台视角是跨域跨业务线的；“能力复用”说明了中台的核心价值在于可复用性，“平台”提示了中台的实现形式是平台化的手段和沉淀。因此，前台需要复用的东西都可以放到中台来，中台的构建最终是为了提升快速响应力，赋能前台业务。数据中台就是中台里比较重要的一个类型，其能力核心在于数据复用，直击“数据人员不懂业务，业务人员不懂数据”的痛点。

传统的数据平台一般都是先去考虑我有什么数据，然后我能干什么。但数据中台则是从业务出发，考虑的是要解决这类业务问题需要什么样的数据服务，确定了服务价值再想办法去采集和处理数据。通过把需要共享的数据沉淀到中台来，经由服务封装，形成前台可以用的数据产品，通过API的方式按需或者按权限分享给不同的业态去调用，提高数据利用效率，加速业务迭代、试错和创新。

【CIO观点】

建设数据中台，首先梳理业务规范，把不同业务线的相同点进行梳理。由业务部门提供需求，IT部门主导组织业务部门构建需求蓝图。
——劲浪体育信息部副总监 蒲意

不做数据中台会死吗？

数据中台能引起广泛关注，关键之处就在于让众多企业看到了“数据距离业务更近”的可能性。这种价值主要体现在三个方面：

其一，破除数据孤岛，让数据流动起来。在企业业务发展过程中所累积的大量数据,往往分散在各个业务单元和组织内部。数据中台则能通过对数据统一管理，帮助企业整合数据，形成良性的数据资产管理。

其二，提升可复用性，便于数据共享。在企业内部，往往多个系统都需要对接某项主数据，主数据就只能被多次抽取，无论是抽取压力、维护难度及一致性要求都很高。数据中台将数据加工后封装成一个公共的数据产品或服务，就可以达成“一次治理、多次复用”。

其三，快速响应需求，让数据驱动业务。用户永远是善变的，随着市场竞争越发激烈，业务部门越来越需要快速响应变化。而数据中台则协调了敏态前台和稳态后台的平衡，让应用开发的专注应用，让数据开发的专注数据，推进了源数据产生业务价值的速度。

当然由于行业、场景的差异，很多企业对于做数据中台还是持犹疑态度。问题在于：是否所有企业都应该建数据中台？更极端一点，不做中台会不会死？简单来说，中台是基于业务建立的，因此只有当企业的业务和架构都发展到一定阶段、一定规模时，中台的建设才有必要。归根到底，数据中台解决的是集团作战下的效率问题。

对于初创企业来说，起步阶段的核心还是存活，根本没有必要考虑建设数据中台。而对具有一定规模的企业来说，如果业务场景比较丰富，组织架构的膨胀已经在部门与部门间形成比较多的“各占山头、重复建设”的状况，就有必要考虑建设数据中台的可能了。再深入一点，企业需要考虑清楚：当前市场变化的速度如何？数据孤岛是否制约了团队效率？有没有对于数据通用服务的需求？需求高不高？频率大概是多少？考虑清楚后应该大致会有个答案。

【CIO观点】

个人觉得，数据中台还是要考虑长远的规划，是避免二次实施造成浪费的一种布局。而对于大部分的中型企业来说要多考虑后期运维，要在可靠性、易用性上多加考虑。不能把希望全部寄托在一次外部实施。
——某多业务集团IT经理 汪磊

踩“坑”预警：三思而后行

建设数据中台，有采购和自建两种方式，这与企业的所属行业特点、数据现状、业务需求、建设预算等密切相关。简言之，如果使用采购的形式，找服务过同行业且有成功案例的乙方，能避开很多坑；如果自己开发，就要充分考虑时间和开发成本。

在筹谋阶段，有这样几个因素可以作为重点参考：

1. 争取一把手的支持。数据中台项目一般来说涉及部门多，对接系统广，实操复杂，有一把手的支持，会少去很多部门之间的扯皮过程，更利于项目推进。
2. 把握建设节奏。因为中台建设推进比较缓慢，但业务线在发展中却可能时时变化。要平衡诉求与建设进度的矛盾，就涉及到先做什么、后做什么的规划。加上因为用户需求多样，想象中一线到底的建设可能变成多线交织，难以拆解。因此具体建设目标也要三思而后行，避免沦落“脚痛医脚、头痛医头”的窘境。
3. 做好数据治理。对于数据基础比较差、数据质量参差不齐的企业来说，这点尤为重要。这个问题不解决，极有可能半途而废。
4. 永不脱离业务价值。数据中台如果不为业务服务，那就没有价值。因此打好数据基础后，需要把业务场景梳理清楚，基于业务场景提供的数据服务更易于被业务部门所接受。
5. 客观评估人员能力。做数据中台的难度相对普通产品不在一个量级。如果不能客观评估人员水平，有可能陷入泥潭无法脱身。

【CIO观点】

IT部门要考虑清楚使用数据中台的目的是什么，不要为了中台而中台。没有实际价值的投资就是浪费时间，就是盲目跟风。还有对于自身价值体系的反思，重构也是必要的环节。
——某多业务集团IT经理 汪磊

以上只是部分讨论内容，更多内容欢迎加群讨论。CIO & IT经理精英汇2群加群方法：公众号CIO进化论中回复【社群】。