换个视角看中台的对与错

生活2019-08-09 21:00Kaituhi: 杨堃

Whakarāpopototanga中台建设，是近两年非常火热的一个话题，从产品中台，到技术中台，再到组织中台

前言

中台建设，是近两年非常火热的一个话题，从产品中台，到技术中台，再到组织中台，各种概念、理念，以及方法论被深度的研究、探讨。

对于互联网产品领域来讲，中台更多的是2B产品建设中涉及的课题，因为软件系统的抽象复用，更多的是做复杂B端系统建设中面临的问题。因此，中台产品设计，是所有B端产品经理应该深度关注的课题。

针对B端产品设计领域，中台产品到底该如何设计？有何特点？设计的本质是什么？有何挑战？本文将从全新的视角，重新审视中台产品建设，让您更加深刻地理解中台产品设计精要。

01 经典视角下的中台建设

首先，我们有必要回顾下经典的中台建设视角。一般来讲，行业内往往从组织中台、产品中台、数据中台、技术中台这四个主题切入并探讨中台建设。

组织中台：组织中台研究的是企业内部的组织结构设计，如何通过合理的权责划分，以及管理架构搭建，提高业务部门的经营能力，迅速响应市场变化，并且能够让企业提升整体跨部门跨业务线协作效率，降低运营成本，实现标准化管理。所谓组织中台的设计思路，实际上已经存在了很多年了，在集团企业中，往往采取事业部制的组织形态，再配合各种共享服务中心的建设，实现前后端业务分离，前端业务保持机动性，后端业务提供火力支援。类似于财务共享服务中心FSSC（Financial Shared Service Center），人力资源共享服务中心HRSSC（Human Rersources Shared Service Center），其实就是典型的中台管理思路下的组织形态和职能部门建设的方法，如下图。

一个常见的事业部制的组织机构图

产品中台：产品中台研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统就像搭建积木一样灵活，可以重复高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台，或业务中台产品。目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等，其中电商交易线又被更加广泛的探讨，包括了订单中台、支付中台、商品中台、促销中台等。产品中台还有另一层含义，即能够给全公司全企业提供一致服务的管理软件产品，也可以纳入产品中台的范畴，例如呼叫中心、项目管理软件。从某种程度上来讲，这些标准化软件产品也是中台产品。

数据中台：数据中台研究的是企业内部的数据管理、治理问题，以及数据产品体系和数据底层结构的搭建问题。数据中台研究的范畴，包括企业统一的数据安全、数据规范、元数据管理、数据编码管理，以及数据仓库、数据集市的拓扑架构，也包括大数据底层和运算能力建设和复用。要注意的是，数据中台更多的关心从业务和产品层面对数据的治理、管理、应用，而非技术层面问题。

技术中台：技术中台研究的是软件产品的技术实现过程中，哪些技术上的处理能力和架构可以进行抽象复用，例如消息中间件MQ，分布式计算框架Hadoop，分布式服务框架HSF，各种Open API等等。技术中台是纯粹从技术实现底层来思考基础服务和基础模块的复用能力，其设计思路和产品中台一脉相承，是技术人员需要深度思考的问题。

以上四个主题，涵盖了互联网模式下对于企业中台建设的所有课题范围，其中，对于产品经理来讲，工作相关性最强，最需要关注的是产品中台和数据中台。

实际上，上述四个主题，也正是传统企业信息化建设中非常核心的企业架构EA（Enterprise Architecture）理论，对企业业务管理的IT视角下的切分。其中组织中台对应EA中研究的企业业务架构EBA（Enterprise Business Architecture）中的组织架构治理部分，产品中台对应EA中研究企业应用架构的EAA（Enterprise Application Architecture），数据中台对应EA中研究企业数据架构的EDA（Enterprise Data Architecture），技术中台对应EA中研究企业技术架构的ETA（Enterprise Technology Artchitecture）。

关于EA的论述，可能让很多纯互联网背景的同学读起来很困惑，但实际上，互联网企业所谓的中台建设思路，逃不出经过几十年沉淀的信息技术理论框架，以及管理理论框架。而传统信息技术理论，在互联网企业的B端产品建设中具有极强的参考、借鉴价值。

然而，我们今天讨论的主题，还不是研究企业架构EA对中台建设的指导，而是尝试从更加深层次的角度，去探索产品中台、数据中台的设计本质，尤其是对于B端产品经理来讲非常核心的产品中台的设计精要。

对于产品中台，目前公认的关键要点包括如下关键词：企业级、抽象、下沉、复用，这些关键词代表了产品中台建设的特点，同时也是在企业应用架构设计中需要深层次思考的问题。（所谓企业应用架构，是指企业内部的各个软件系统，应该以什么样的形式建设、组合，从而高效的支持企业的经营运作）因此，如果要深层次的思考软件产品的企业级抽象、下沉、复用问题，可以从以下三个角度进行全新的审视，分别是：基于抽象复用的视角，基于架构合理性的视角，基于业务统一管理的视角。

我们通过从这三个视角切入，可以全面的解构中台产品设计的要义，并且可以更加全面的穷举中台建设的方法论、要点和难点。

02 基于抽象复用的视角建设中台

所谓抽象复用，是指对软件中重复的功能和模块进行抽象并下沉一层。

什么叫抽象？什么叫下沉？我们举例说明。

如下图，有两个系统I和II，其中系统I中具有模块M，系统II中具有模块N，经过分析发现，模块M和N的功能高度类似重复，完全可以抽象合并，避免重复建设。

识别共性模块

现决定将模块M和N分别从系统I和II中剥离出来，如下图。

抽离共性模块

将M和N剥离出来后，我们对其功能进行抽象合并，如下图。M和N合并后，得到模块A + B + C，其中A是M和N中共有的功能，B和C分别是针对系统I和II提供的一些定制化功能。虽然有少量功能无法做到完全合并和复用，但新模块中绝大多数功能集合A已经被高度抽象，可以被系统I和II复用。而被剥离合并后的全新模块A+B+C，将会下沉一层，作为基础服务，为系统I和II提供支持。如下图。

合并共性模块

以上案例，演示了系统功能如何被合并、抽象、下沉，这种设计思路，节约了软件研发成本，是一种非常经典的中台设计思路。

接下来，我们通过一个实践案例，进一步演示这种设计思路。

案例背景

某流量型互联网公司，变现模式主要为针对中小企业的广告售卖，业务团队包括电话销售团队（IS，Inbound Sales），外勤线下销售团队你（OS，Outbound Sales），以及客服团队。三个业务团队有着各自独立的业务系统支持其运转，每个业务系统中既有个性化功能，例如针对IS的外呼管理、针对OS的拜访管理、针对客服的关怀回访；也有功能高度类似的重复功能，例如客户管理列表，客户详情页。系统架构图如下图所示。

重复的客户详情页建设

遇到的问题

三套业务系统各自有产品研发团队维护，系统早期为了快速支持业务从而分别建设，快速响应业务诉求，为业务发展立下了汗马功劳。但随着系统的逐步成熟，其中一些问题也逐渐凸显，首要问题就是功能重复开发建设问题。虽然三个业务部门对客户关注的侧重点不同，但基本诉求是一致的，希望能看到客户所有的重要信息。因此，三个系统的客户详情页功能已经高度类似，而每次针对客户资料的调整变化，需要三个研发团队分别重复开发三遍，非常浪费人力资源。

解决方案

为了解决三套业务系统中高度类似的客户详情页的重复开发问题，也为了给业务人员提供一致的、准确的客户视图，公司决定将客户详情页模块从三个业务系统中剥离，将功能合并后，建设“统一客户视图（ECIF）”模块，该模块拥有一致的客户数据底层，并提供完整的客户信息查询服务化接口，以及可以嵌入业务系统直接使用的客户详情页面组件。“统一客户视图”将作为中台产品，为各个业务系统提供企业客户数据查询的服务以及视图。如下图。

将客户详情页抽象下沉建设统一客户视图中台

任何业务系统，既可以调用该模块的成熟接口查询客户数据并自己设计前端页面，也可以直接嵌入“统一客户视图”提供的现成的客户详情页组件，并且该页面组件还可以进行灵活的权限配置，定义针对不同的业务系统、不同用户角色的数据查看、编辑范围。

由此，我们完成了对客户详情页的抽象下沉，三套曾经重复开发的页面被合并成了一套，以后研发团队只需要维护这一套页面，研发人力得到了释放。

这就是典型的基于抽象复用的视角设计的中台产品。这种模式有一个显著特点，即软件的抽象和复用是成本问题，不影响业务。案例中，虽然有三套客户详情页被重复建设，但只是个资源浪费问题，并不会影响到业务的开展。

对软件功能模块进行抽象复用，是具有很强挑战性的工作。如果分析不当或经验不足，有可能做出错误的抽象方案。

我们总是希望能够对软件和功能进行正确的抽象决策，让抽象出的系统和模块具有高度重叠的特性，例如下图这样。

期望的抽象结果

然而受限于经验不足，或掌握的信息不足，很可能做出错误的判断和设计，做出了错误的抽象决策，最后被抽象的系统模块，并不能被充分复用，只是制造了一个畸形的别扭的模块，生硬的把一堆毫无关联的功能强行捏在一起，给研发工作反而带来的更大的麻烦，如下图。

错误的抽象结果

我们将通过实际案例，给大家演示这种设计错误。

案例背景

某互联网公司同时开展了电商业务和电影票业务。每条业务线都有独立的C端系统、后台交易系统（包括商品管理、订单管理、促销管理）来支持业务。为了追逐潮流，公司决定将两条业务线的订单中心合并，实现订单中台，如下图。

并不一定正确的订单中台

错误的决策

实际上，公司经营的B2C电商业务和影票业务，在交易形态上有较大区别，尤其体现在订单模块的设计上，订单的状态机、数据模型和财务账务处理模式完全不同，强行将两者合并后，并没有太多的共性模块和功能，最终只是表面上看起来实现了订单中台，但是里边的功能模块各自独立，各自运转，完全没有抽象和复用。

扩展难题

现在，公司管理者以为拥有了强大的“订单中台”，可以为任何新业务的快速开展提供支持。很快，公司决定开展机票售卖业务，针对机票业务，有独立的C端，商品管理，促销管理。但是当产品经理和工程师开始期待订单中台的强大能力时，遗憾的发现订单中台无法给机票业务提供任何现成的功能复用能力，机票的订单模型和电商以及影票都不相同。

机票业务线的设计人员面临一个尴尬的局面，要么“政治正确”的将机票订单中心纳入订单中台统一建设，但实际上这会严重降低开发效率，因为中台研发团队肯定不会像机票业务自己的研发团队那样重视新业务的开展；要么就抛弃订单中台，自己独立开发订单模块，但这样做又会显得订单中台没有产生该有的价值。如果你是机票业务的负责人，该怎么权衡取舍呢？此时的系统架构如下图。

订单中台并不能很好的支持机票业务

可见，订单中心，在不同业务模式下，并不一定适用于中台化建设，设计人员要有足够的思辨能力，判断产品形态上是否值得抽象下沉，是否能够提供复用能力。然而这也是软件工程设计中非常难的部分。

任何软件系统的设计，都是基于归纳法，而非演绎法，即软件设计人员总是通过对现有世界和业务的总结提炼，完成软件设计，而无法通过推测演绎，完成软件设计。设计人员无法对业务的未来做出预测，只能基于有限的经验，尽量的保证设计的灵活性和正确性。理解这一点非常重要，这会让你在软件设计、产品设计时心存敬畏之心，不会一味地追求短期无法论证的结论而产生的严重的过度设计。

以下是基于抽象复用的视角建设中台的几条建议。