编辑导语：中台这一概念，这两年在国内大热，不少企业接连开始组织架构的调整，意图建设中台；中台到底是什么？哪类企业可以搭建中台？本文作者对中台进行了非常详细的分析，我们一起来看一下。
《中台详解系列》共分上下两篇，本文为上篇，总计约字，因为文中涉及知识体系较为广泛，建议预留20—25分钟进行阅读。
目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识，“中台”的定义及建设规范尚未有明确定论；本系列文章旨在基于“以终为始”的思维模式，及“软件对现实世界建模”的基础条件，梳理传统软件“平台”所面临的问题；并以此为起点，结合经济学中专业化分工协作理论，为“中台”进行职能定义，再通过“中台”的职能定义给出“中台”建设的建议方案。
18年初，我初次接触到“中台”概念的时候，也不免心驰神往了一番，毕竟即使在概念漫天飞的国内IT圈，“中台”也算是天空中最亮的那颗星；现在临近年末，近3年的时间如白驹过隙，期间我有幸参与了多个“中台”项目，其中吉利汽车全球营销业务“中台”项目在整个阿里云“中台”战略中也算是比较成功的案例。
然而遗憾的是，“中台”也未能逃脱国内IT圈大热概念“站得越高，摔得越疼”的魔咒，年初茅台拆除“中台”的消息像一把利剑，戳破了“中台”的泡沫；一时间各种“马后炮”震耳欲聋，这也算对得起“中台”一直以来的热度，只是其中内容漏洞百出，让人啼笑皆非。
有“顾名思义”说“中台”是夹在前台和后台之间，起到承上启下作用的：
有引用美国经济学出版图书《平台战略》来解释“中台”的：
节选自科技自媒体“技术领导力”推文
而作为一个过来人，我觉得有必要聊一聊自己的心得，以使得大家可以对“中台”有更加客观的理解。
老规矩，咱们还是按照“是什么”、“有什么价值”、“怎么做”的顺序来聊。
一、什么是“中台”？为什么要搞“中台”？
有人说：现在大家争论“中台”样子，跟当年争论“云”一模一样；显然什么是“中台”，市面上还没有一个统一的说法，所以这里我自己给“中台”下了一个定义：
“中台”是对传统“软件平台”的升级和加强，通过在企业层面引入新的专业化职能分工、数据唯一性建模等规则；在解决软件行业“重复造轮子”问题的基础上，进一步解决了传统“软件平台”未能解决的“软件平台间职能边界划分问题”及“数据孤岛问题”。
这里有几个关键词——“企业层面”、“软件平台”、“专业化职能分工”、“数据唯一性建模”。
“中台”是对“软件平台”的自然演进这一观点，可以说在IT业界已经得到了初步的共识，阿里云的架构师也通过科技自媒体透露过阿里云对于这一问题的认知。
那“软件平台”到底是怎么演进成“中台”的呢？“软件平台”又到底为什么要演进成“中台”呢？相关工作又为什么要在企业层面完成？“专业化职能分工”、“数据唯一性建模”又是什么鬼？
鉴于所有的软件及其背后的理论、原理、概念、技术都是为了解决业务问题而产生的，就让我带着大家一边梳理“中台”产生的业务背景，一边揭开“中台”的面纱。
图片来自于阿里云业务中台云原生架构师“宇升”在自媒体上发表的《我们阿里内部是怎么做业务中台的？》一文。
1.信息化带来甜蜜的烦恼
信息技术的发展对人类的影响是空前的，但对于效率的极致追求，使得人类在信息技术大规模应用后，又发掘出了一系列新的待解决问题；比如大家一致认为“中台”核心要解决的问题——重复造轮子。
软件研发重复造轮子的问题：
为了应对市场发展及用户成长对业务增长带来的负面冲击，企业会拓展新业务，或将已经较为成熟的业务线拆分为若干条子业务线、若干子环节以开展精细化运营。
这些业务线、业务环节中，会有很多相似的业务内容，比如可能都需要广告投放、商品展示、用户激励、订单交易、支付收款等；不过不同业务线中相似业务的发生时间和细节要求并不一致。
以往为了追求效率，很多企业是通过不断为不同业务线中的相似业务定制开发相似的功能来解决这个问题的——这就产生了重复劳动，会造成研发资源的极大浪费。
更要命的是，重复造轮子还会造成“次生灾害”——运维成本的爆炸性增长。
重复造轮子造成高运维成本的问题：
一方面，针对不同业务线中的相似业务定制开发相似的功能，会导致相似功能的模型及代码有很多份，技术框架不一致，就像汽车的零件型号一样，从数量上增加了运维难度；另一方面，在实际运维工作过程中，软件中相似功能过多也很容易让运维人员记错，导致二次事故。
2.求助现实，见招拆招
幸运的是，因为软件的本质是“对现实世界建模”，所以在软件建设和应用过程中，遇到的很多问题都可以在现实世界中找到类似情况及解决方案。
为了应对“重复造轮”的问题，软件开发领域很早就引入了“平台化”模式。
平台化：
“平台化”概念最早出现在工业制造领域，更广为大众所熟知的则是汽车生产平台。
汽车上零件众多，开发一个车型涉及技术集成、零部件设计、试验验证等繁杂环节，出了名的耗资大、周期长、风险高；而绝大多数消费者，在拿到车之后，并不关心车的底盘是怎么设计的，发动机是横置的还是竖置的；他们可能更关心车是什么颜色的，座椅是不是真皮的，保险杠上的大灯好不好看。
于是乎，绝大多数汽车企业会使用相似底盘和下车体的公共架构，在这个平台结构上生产出外形功能都不尽相同的产品。这就是汽车的平台化/模块化战略。
汽车的平台化
软件的“平台化”也是类似，将可复用部分抽象成模块组件，再基于这些模块组件进行业务化串联、增量包装，就可以适应不断变化的业务需求。
不过需要说明的是，“平台”本身是个多义词，《平台革命》中的“平台”说好听点叫做掌握市场入口，说难听点就是中介，跟这里说的“平台”一点关系都没有，只怪古早时期的译制工作太粗糙。
平台是个多义词
然而对于效率的极致追求，又使得人们很快发现，就像电影、唱片、磁带等文化产品与一般的商品在生产、流转和使用过程中有着很大的差别一样，完全照搬工业制造领域的“平台化”理论好像也有问题。
软件“平台”间的职能边界问题：
“平台”的本质是模块组件，模块组件多数情况下是必须与其他模块组件进行业务化串联，甚至还需要进行增量的个性化定制包装，才能够真正解决业务问题的。
这就带来了“平台”间如何协作的问题，即“软件平台”间的职能边界是什么？
如不解决这个问题就很容易出现以下两种情况：
各协作的模块组件都不集成某一可复用能力——出现这种情况，就解决不了“重复造轮子”的问题。各协作的模块组件同时集成了某一可复用能力——出现这种情况，则会导致“软件平台”间面临类似企业组织分工常常面对的多头管理的情况：职能上，你也能干，我也能干；解决问题时，你不想干，我也不相干，最终结果就是两个模块组件都难以使用、难以迭代；这一点，做过大型软件1-n迭代的朋友应该都深有感触。在模块组件间协作时，实物产品先天有空间限制条件作为基准，比如汽车前车灯和车尾灯，就可以根据空间位置不同而解决不同的问题；而软件产品的各“平台”间就和企业的组织机构一样缺乏这种天然的协作标准。
数据孤岛问题：
“数据孤岛”这个词看起来唬人，实际上它只不过是以下3种原因造成业务数据难以统一分析、管理情况：
针对不同业务线中的相似业务定制开发相似的功能，使得不同业务线的相似功能的数据天然隔离。在针对不同业务线中的相似业务定制开发相似的功能过程中，没有对数据模型做出统一标准要求，上线后的产生的业务数据字段的命名/排序/格式/注释等不一致。在同一业务线不同功能的开发过程中，未对不同业务之间的关系进行建模，上线后的产生的业务之间的关系数据没有保存下来，以至于难以判断同一业务线不同业务之间的关联性。
而原有的“平台化”理论起源于工业制造领域，显然没有专门考虑过数据治理的问题。
虽然很多开发者在构建“软件平台”时，也会