编辑导语：中台这一概念，这两年在国内大热，不少企业接连开始组织架构的调整，意图建设中台；中台到底是什么？哪类企业可以搭建中台？本文作者对中台进行了非常详细的分析，我们一起来看一下。

《中台详解系列》共分上下两篇，本文为上篇，总计约8100字，因为文中涉及知识体系较为广泛，建议预留20—25分钟进行阅读。

目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识，“中台”的定义及建设规范尚未有明确定论；本系列文章旨在基于“以终为始”的思维模式，及“软件对现实世界建模”的基础条件，梳理传统软件“平台”所面临的问题；并以此为起点，结合经济学中专业化分工协作理论，为“中台”进行职能定义，再通过“中台”的职能定义给出“中台”建设的建议方案。

18年初，我初次接触到“中台”概念的时候，也不免心驰神往了一番，毕竟即使在概念漫天飞的国内IT圈，“中台”也算是天空中最亮的那颗星；现在临近2020年末，近3年的时间如白驹过隙，期间我有幸参与了多个“中台”项目，其中吉利汽车全球营销业务“中台”项目在整个阿里云“中台”战略中也算是比较成功的案例。

然而遗憾的是，“中台”也未能逃脱国内IT圈大热概念“站得越高，摔得越疼”的魔咒，年初茅台拆除“中台”的消息像一把利剑，戳破了“中台”的泡沫；一时间各种“马后炮”震耳欲聋，这也算对得起“中台”一直以来的热度，只是其中内容漏洞百出，让人啼笑皆非。

有“顾名思义”说“中台”是夹在前台和后台之间，起到承上启下作用的：

有引用美国经济学出版图书《平台战略》来解释“中台”的：

节选自科技自媒体“技术领导力”推文

而作为一个过来人，我觉得有必要聊一聊自己的心得，以使得大家可以对“中台”有更加客观的理解。

老规矩，咱们还是按照“是什么”、“有什么价值”、“怎么做”的顺序来聊。

一、什么是“中台”？为什么要搞“中台”？

有人说：现在大家争论“中台”样子，跟当年争论“云”一模一样；显然什么是“中台”，市面上还没有一个统一的说法，所以这里我自己给“中台”下了一个定义：

“中台”是对传统“软件平台”的升级和加强，通过在企业层面引入新的专业化职能分工、数据唯一性建模等规则；在解决软件行业“重复造轮子”问题的基础上，进一步解决了传统“软件平台”未能解决的“软件平台间职能边界划分问题”及“数据孤岛问题”。

这里有几个关键词——“企业层面”、“软件平台”、“专业化职能分工”、“数据唯一性建模”。

“中台”是对“软件平台”的自然演进这一观点，可以说在IT业界已经得到了初步的共识，阿里云的架构师也通过科技自媒体透露过阿里云对于这一问题的认知。

那“软件平台”到底是怎么演进成“中台”的呢？“软件平台”又到底为什么要演进成“中台”呢？相关工作又为什么要在企业层面完成？“专业化职能分工”、“数据唯一性建模”又是什么鬼？

鉴于所有的软件及其背后的理论、原理、概念、技术都是为了解决业务问题而产生的，就让我带着大家一边梳理“中台”产生的业务背景，一边揭开“中台”的面纱。

图片来自于阿里云业务中台&云原生架构师“宇升”在自媒体上发表的《我们阿里内部是怎么做业务中台的？》一文。

1. 信息化带来甜蜜的烦恼

信息技术的发展对人类的影响是空前的，但对于效率的极致追求，使得人类在信息技术大规模应用后，又发掘出了一系列新的待解决问题；比如大家一致认为“中台”核心要解决的问题——重复造轮子。

软件研发重复造轮子的问题：

为了应对市场发展及用户成长对业务增长带来的负面冲击，企业会拓展新业务，或将已经较为成熟的业务线拆分为若干条子业务线、若干子环节以开展精细化运营。

这些业务线、业务环节中，会有很多相似的业务内容，比如可能都需要广告投放、商品展示、用户激励、订单交易、支付收款等；不过不同业务线中相似业务的发生时间和细节要求并不一致。

以往为了追求效率，很多企业是通过不断为不同业务线中的相似业务定制开发相似的功能来解决这个问题的——这就产生了重复劳动，会造成研发资源的极大浪费。

更要命的是，重复造轮子还会造成“次生灾害”——运维成本的爆炸性增长。

重复造轮子造成高运维成本的问题：

一方面，针对不同业务线中的相似业务定制开发相似的功能，会导致相似功能的模型及代码有很多份，技术框架不一致，就像汽车的零件型号一样，从数量上增加了运维难度；另一方面，在实际运维工作过程中，软件中相似功能过多也很容易让运维人员记错，导致二次事故。

2. 求助现实，见招拆招

幸运的是，因为软件的本质是“对现实世界建模”，所以在软件建设和应用过程中，遇到的很多问题都可以在现实世界中找到类似情况及解决方案。

为了应对“重复造轮”的问题，软件开发领域很早就引入了“平台化”模式。

平台化：

“平台化”概念最早出现在工业制造领域，更广为大众所熟知的则是汽车生产平台。

汽车上零件众多，开发一个车型涉及技术集成、零部件设计、试验验证等繁杂环节，出了名的耗资大、周期长、风险高；而绝大多数消费者，在拿到车之后，并不关心车的底盘是怎么设计的，发动机是横置的还是竖置的；他们可能更关心车是什么颜色的，座椅是不是真皮的，保险杠上的大灯好不好看。

于是乎，绝大多数汽车企业会使用相似底盘和下车体的公共架构，在这个平台结构上生产出外形功能都不尽相同的产品。这就是汽车的平台化/模块化战略。

汽车的平台化

软件的“平台化”也是类似，将可复用部分抽象成模块组件，再基于这些模块组件进行业务化串联、增量包装，就可以适应不断变化的业务需求。

不过需要说明的是，“平台”本身是个多义词，《平台革命》中的“平台”说好听点叫做掌握市场入口，说难听点就是中介，跟这里说的“平台”一点关系都没有，只怪古早时期的译制工作太粗糙。

平台是个多义词

然而对于效率的极致追求，又使得人们很快发现，就像电影、唱片、磁带等文化产品与一般的商品在生产、流转和使用过程中有着很大的差别一样，完全照搬工业制造领域的“平台化”理论好像也有问题。

软件“平台”间的职能边界问题：

“平台”的本质是模块组件，模块组件多数情况下是必须与其他模块组件进行业务化串联，甚至还需要进行增量的个性化定制包装，才能够真正解决业务问题的。

这就带来了“平台”间如何协作的问题，即“软件平台”间的职能边界是什么？

如不解决这个问题就很容易出现以下两种情况：

• 各协作的模块组件都不集成某一可复用能力——出现这种情况，就解决不了“重复造轮子”的问题。
• 各协作的模块组件同时集成了某一可复用能力——出现这种情况，则会导致“软件平台”间面临类似企业组织分工常常面对的多头管理的情况：职能上，你也能干，我也能干；解决问题时，你不想干，我也不相干，最终结果就是两个模块组件都难以使用、难以迭代；这一点，做过大型软件1-n迭代的朋友应该都深有感触。

在模块组件间协作时，实物产品先天有空间限制条件作为基准，比如汽车前车灯和车尾灯，就可以根据空间位置不同而解决不同的问题；而软件产品的各“平台”间就和企业的组织机构一样缺乏这种天然的协作标准。

数据孤岛问题：

“数据孤岛”这个词看起来唬人，实际上它只不过是以下3种原因造成业务数据难以统一分析、管理情况：

• 针对不同业务线中的相似业务定制开发相似的功能，使得不同业务线的相似功能的数据天然隔离。
• 在针对不同业务线中的相似业务定制开发相似的功能过程中，没有对数据模型做出统一标准要求，上线后的产生的业务数据字段的命名/排序/格式/注释等不一致。
• 在同一业务线不同功能的开发过程中，未对不同业务之间的关系进行建模，上线后的产生的业务之间的关系数据没有保存下来，以至于难以判断同一业务线不同业务之间的关联性。

而原有的“平台化”理论起源于工业制造领域，显然没有专门考虑过数据治理的问题。

虽然很多开发者在构建“软件平台”时，也会关注数据治理，使得软件的“平台化”可以在一定程度上缓解“数据孤岛”；但因为“软件平台”本身还面临着职能边界的问题，即不同“软件平台”可能集成同一可复用能力，所以其无法从根本上解决问题。

为此，市场上长时间流行着一套“临时解决方案”——外接“数仓”，具体步骤是：

• 先进行业务分析；
• 再梳理原有各系统的数据结构；
• 然后在新的“数据仓库”中重新建模；
• 接下来将原有各系统中的数据字段与新的“数据仓库”中数据字段建立映射关系；
• 然后再执行脚本提取历史数据；
• 最后启动定时器定时提取原有各系统中增量数据。

看这个过程就知道，这一通操作下来的成本肯定是低不的，实际上这么浩大的工程确实也只有那些银行或大型上市公司才能负担的起。

另外这个解决方案还有着一堆的毛病，比如说，这个新的“数据仓库”不直接支持业务，里面的建模合理吗？原有各系统都不知道哪一年、那个团队、根据什么样的业务规则、用哪种语言和技术框架做的，还能梳理清楚吗？数据迁移时的数据映射关系写错了是不是一定要等错误的数据阻塞业务了才能够发现？定时取增量数据的时效性如何保障？取数时如何保障数据不会丢失？未来的新系统咋办？

3. “中台”崛起

这个世界上的概念从来都不是没来由的，就像前人们会引入“平台”理论来解决“重复造轮子”的问题一样，背负着解决“软件平台间职能边界划分问题”、“数据孤岛问题”的使命，中台诞生了。

在解决“软件平台间职能边界划分问题”上，“软件平台”间缺乏先天条件作为协作基准；但万幸的是我们还可以求助现实世界，这里推荐的是“微观经济学”领域中的“协作理论”，它是经过了高度总结的，在各个领域中都有着丰富且成功的应用案例。

协作：

定义：个体组合在一起协力完成工作，协作分为简单协作和复杂协作；简单协作是没有专业分工的协作，复杂协作则是建立在专业分工基础上的。（摘自现代经济词典）

从定义中我们可以看出，传统情况下“软件平台”间的协作即是“简单协作”，而“中台”则需要采用“复杂协作”，即专业化分工协作，来解决“软件平台”间“简单协作”所暴露出的问题。专业化分工有以下两种原则。

工艺专业化：按照工艺阶段或工艺设备相同性的原则来建立生产单位，即按不同的生产工艺特征，建立不同的生产单位。

特点：“三同一不”；三同——同类型的机器设备、同工种工人 、相同工艺方法；一不——不同的劳动对象。（摘自现代经济词典）

对象专业化：按照业务对象来划分生产单位的原则，即按不同的劳动对象，建立不同的生产单位。

特点：“三不一同”；三不——不同类型的机器设备、不同工种工人、不同工艺方法；一同——相同的劳动对象。（摘自现代经济词典）

因为相关经济学原理比较早的应用于实物领域，所以这两个原则中的各名词都是比较贴近实物场景的，不过这不影响我们理解其中含义。

我们可以基于软件行业的要素特征对上述原则进行名词上的替换：

能力专业化：按照业务方案阶段或模型、方法相同性的原则来建立生产单位，即按不同的业务能力方案特征，建立不同的生产单位。

特点：“多同一不”；多同——相同模型 、相同方法、相同服务等；一不——不同的业务对象。

对象专业化：按照业务对象来划分生产单位的原则，即按不同的业务对象，建立不同的生产单位。

特点：“多不一同”；多不——不同模型 、不同方法、相同服务等；一同——相同的业务对象。

在解决“数据孤岛问题”上，业务间关系数据缺失的情况比较好解决，也不影响“中台”理论的构建，就暂且不讨论了；而从其余情况的产生原因上我们就可以看出，要解决它们最好的办法就是“从头到尾相似的数据就只有一份”。

在“软件平台”间“简单协作”的情况下，很难达成这个目标；而如果 “软件平台”间采用“复杂协作”，即专业化职能分工，我们只要将分工后的“软件平台”进行数据唯一性建模，就可以达成“从头到尾相似的数据就只有一份”的目标。

而不管是要进行“软件平台专业化分工”，还是“数据唯一性”建模，显然都要在企业层面进行拉通，而不是各个子产品间各自为政。

综上所属，我给“中台”下了本章节开头的定义：即“中台”是对“平台”的升级，承担着企业层面软件能力资源的专业化、职能化管理，生产数据归一的职责。

二、“中台”带来新的机会

新事物必然带来新的机会。

这里我们就先来聊一聊“中台”给市场内主要参与角色——“企业”和“云服务商”带来的机会；另外，因为我自己是产品经理，所以也会聊一聊产品经理之于“中台”的角色定位。

1. 企业——“中台”是什么不重要，能解决什么问题最重要

“thought works”的首席咨询师王健在谈论他对“中台”的看法时说到：“中台是什么不重要，能解决什么问题最重要。”对于这句话我深以为然。

而令人遗憾的是，以“茅台中台项目”为代表的一系列失败的“中台”项目案例，似乎让场内玩家在“中台能解决什么问题”上纷纷失去了方寸；甚至连阿里巴巴CEO逍遥子也公开表示：“中台”并不适用于每家公司的每个阶段；在独立业务拓展期、突破期，一定用独立团、独立师、独立旅建制来做，否则就会变成瓶颈；但发展到一定阶段，出现太多山头时，就要关停并转、要合并同类项；问管理要效率，取消重复性建设。（消息来自36氪）

对于这样的观点我并不能认同，原因有3：

1）无论是阿里云还是其他场内玩家，对于“中台”这么重视，不都是因为其可以解决“重复造轮子”的问题，从而解放研发人力，最终保障创新业务有足够的人力资源支持吗？那什么样的企业业务发展速度最快？人力成本压力最大呢？当然是创业期和拓展期的企业。

2）在很多企业进行产品经理或架构师招聘时，都有这么一条——能够设计可拓展型系统，而要保障系统的拓展性，系统模块间的专业化分工设计必不可少；实际上，为了追求效率而绕开软件各模块的职能划分环节，直接采用砌式产品研发，使得软件系统功能耦合严重，最终导致系统难以迭代必须重构的情况，在IT业界比妹子还常见；对于一些创业期和拓展期来说，这种问题的影响是近乎致命的。

3）“数据孤岛问题”很可能会让创业期和拓展期的企业辛苦收集的业务数据一文不值，亡羊补牢式的数据采集及治理方案所需的人力和资金成本，很可能高于前期软件各模块间的专业化分工设计和数据唯一性建模；而如果采用“中台”方案，即便一开始的建模合理性不足，也会因为数据就一份而很容易进行迁移或字段的升级。

所以我认为不管你的项目是to b还是to c的，只要不是单纯to vc圈钱的，且具备以下两点条件，在进行IT建设时就可以、也应该考虑“中台”。

• 有明确的商业规划。
• 远期目标包含业务线的拓展或业务线的细分。

而包括阿里巴巴CEO逍遥子在内的很多人，认为创业期和拓展期的企业不适合上“中台”，本质上是对初创企业IT建设能力低下与“中台”建设成本高昂之间难以调和的矛盾的担心。

但软件作为信息技术的一种应用形态，它的核心特点之一就是边际成本会越来越低，创业期和拓展期的企业就算做不起“中台”，难道还买不起吗？就算买不起，难道还租不起吗？而这就给云服务商在“中台”市场上的发挥留下了充足的想象空间。

2. 云服务商——弯道超车，在此一举

包括阿里云、腾讯云在内的众多云服务商，近年来一直都是在硬件和基础组件的基础上，尽可能丰富自己的工具生态，以提高自身在客户面前的竞争力。

比如阿里云就陆续推出了quick bi、quick audience等一系列工具产品；如果云服务商能够提供“中台”相关saas、paas产品，无疑可以将自身的竞争力提升到顶点。

原因也有3：

1）“中台”本身就带有强烈的业务属性，企业进行对“中台”的各项能力进行串联即可完成产品的搭建，这对企业人力的解放是空前的，无疑具备极大的市场需求。

并且我想说，这才是一般企业与信息技术之间最合理的关系；说到底信息技术也只是一个工具，就像当年的电话，也没见哪家企业自己建基站、造电话机，企业核心要做的是研究“怎么用电话帮助自己的业务增长”，并将相关方法落地。

2）就像不同的企业在部门专业化职能分工上有一定区别一样，“中台”模块间的专业化职能分工业务可以按照不同原则进行划分，只要合理就好；比如我司会因为部署需要，把权益中心在拆分为会员卡中心、积分中心、卡券中心等——这使得企业在使用云服务商的“中台”服务进行业务编排时写得“胶水代码”变成了命题作文，难以复用；这可以提高企业更换云服务商的成本，换句话说就是可以提高云服务商的客户粘性。

3）而在业务域数据唯一性建模时，云服务商可以采用独特的数据字段命名、排序、格式、注释等方式，甚至采用独特的数据存储环境；这也可以提高企业更换云服务商的成本，同时自身的中台产品迭代时客户的数据却可以便捷的进行迁移。

在具体操作上，针对创业期和拓展期的企业可提供saas产品，开箱即用，让其轻装上阵；针对发展到一定阶段的企业，也可以像华为买断ARM的芯片架构使用授权一样，支持其买断产品使用权限，甚至进行本地化部署。

3. 产品经理——虎口夺食，咱们一起建模吧

最近，产品经理圈子弥漫着一股悲观情绪——“互联网的下半场不需要产品经理”，究其原因是因为大量编辑器的出现，使得很多“界面经理”感受到了威胁。

我一贯认为后台产品经理需要重点关注业务结构，交互界面次之；而“中台”对于“专业化职能分工”及“数据唯一性建模”的强烈需求，势必会将业务结构设计推向软件行业舞台的中心。

“软件平台”的“专业化职能分工”加“数据唯一性建模”我们姑且统称为业务建模。

关于业务建模是否需要产品经理参与这件事，我思考了很久，也与身边的多位技术架构师进行了多次深入讨论，最终我的结论是——业务建模是需要产品经理的参与。

“中台”所承载的进行“软件平台”的“专业化职能分工”的使命，具有强烈的业务属性；而软件产品经理这一角色，设立的核心目的之一就是将研发人员从痛苦的业务研究中解放出来。

就像我一位现就职于菜鸟的前同事（技术架构师）在怼“界面经理”时所说的：“都说软件是对现实世界建模，我哪有空了解现实世界是什么样子的？如果我把现实世界摸清楚了，我不就是产品经理了吗？”

换个角度来说，作为将研发人员从业务研究中解放出来的角色，产品经理本身就没有办法把真实世界直接搬到研发人员面前。

产品经理所提供的的业务流程图、规格清单、功能流程图、RP原型稿、PRD说明文档等本质上都是对显示世界的一种模型化表达，只不过“中台”对于“专业化职能分工”加“数据唯一性建模”的需求，使其对产品经理业务建模能力的要求提高了很多。

现实世界、业务模型、技术模型

之前就有消息说，国内某大型企业内部要求旗下所有产品经理必须懂技术，现在想来，应该是管理层发现了产品经理建模能力的重要性，而粗暴的将其解读为需要产品经理懂技术吧？

不过，不管“中台”产品的建设对产品经理的业务建模能力要求有多高， 业务建模需要掌握的只是无外乎都是要掌握如下知识：

• 建模思想：对现实世界的认知视角，如面向过程、面向对象以及封装概念等。
• 建模方法：对现实世界的描述方法，如领驱动设计等。
• 建模工具：对现实世界的描述工具，以及输出物载体，如UML等。
• 建模方案：什么情况下采用什么思想什么方法什么工具进行建模，输出物需要怎么展示的案例。

国内目前还缺乏针对业务建模系统化的方法论，我自己通过一直以来对各种建模思想的研究，摸索了一套相对适合产品经理的业务建模方法论，相关内容我后面都会单独写专题文章介绍。

三、说句心里话

软件是对现实世界的一种数据化呈现，而现实世界中的人类文明发展了几千年，有很多基础理论可以支持软件理论的发展，比如文章一开始提到的“平台”，又比如“面向对象”认知模式。

1. 面向对象

人类认识世界的一种视角，比如：张三交了一个新朋友，张三关注到这位新朋友的职业是医生，就想着以后生病了可以找这位朋友，这就是典型的面向对象思维；如今面向对象思维广泛应用于软件设计领域。

而目前市场中对“中台”的种种解读，大多缺乏基础原理支持，并且这种情况在IT行业并不鲜见，比如所谓的用户心理学。

2. 用户心理学

我翻遍了整个网络，也没能找到这个概念的系统化解释；而我本专业有一门学科叫做“微观经济学”，学科定义就是：研究经济个体（个人或团队）如何支配自己的稀缺资源，比如时间、人脉、资金等。

作为入行多年的产品经理，我能够理解“对于营销概念的争吵可以增加热度”的逻辑。

但“中台”概念已经够火了，“中台”概念火热的背后是市场对于效率的渴求，而目前这些缺乏基础原理支持的解读显然与这样的目标背道而驰，这会进一步增加市场对“中台”概念的误解。

本文也只是我的一家之言，不过我想只有基础理论严肃分析，实实在在的解决问题，形成案例，才能保障一个“概念”可以长久的产出价值。

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

题图来自Unsplash，基于CC0协议