猫先生官方网站但与此同时，关于中台究竟是什么，却是众说纷纭。引用王健老师在《当我们谈中台时，我们在谈些什么 白话中台战略》一文中提到的关于中台的一些理解，就能看出一些端倪。

　　在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它

　　在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它

　　在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它

　　这些理解都对，但也都有不够准确或不够完整的部分。中台，作为一个还在被定义当中的概念，正处在一个大家都有感觉，但又难以被定义的状态。而且可预见的是，这种相对模糊的状态可能还要维持相当长的一段时间。

　　与此同时，在查阅了大量资料、并与京东等大厂的中台相关负责人沟通后，我们发现，目前行业内对于中台讨论的视角还是多偏于战略或组织架构层面，而中台更多是因为公司业务在发展到某一阶段时，遇到瓶颈与障碍后，为解决实际问题而提出的解决方案。

　　虽然基于战略的角度去看，确实能够让大家视野开阔，从更高维度理解中台。但战略是基于实际业务而制定的，如果撇开业务去空谈，就如同空中楼阁，还是无法了解中台到底是什么。

　　接下来，我们将会站在实际业务的角度，探讨一下中台的“前世今生”，以及如果想要成为一个中台产品经理，你应该具备哪些能力。

　　市面上讲到中台，一定会提到两个例子，一个是13年马云参观supercell，然后在15年确定了阿里的中台战略；另一个是华为的中台战略转型，也就是那句著名的“让听得见炮火的人指挥战斗”。

　　这似乎会给大家一个错觉，似乎中台是一种自上而下的战略选择。老板觉得中台好，所以要搭建中台。

　　不过，现实情况，或许与绝大多数人想象不太一样，中台的产生，并非完全是自顶向下的战略设计，也并非是为了追随某种行业风口，而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时，中台的概念恰好对应了这个问题，所以大家接受了中台。

　　过去几年中，借着移动互联网的红利，许多公司都高速发展，进行大规模业务拓展，业务拓展的速度足够快，对公司自然是好事，但是随着而来的问题就是，公司内部出现了大量的重复建设和资源浪费的现象。

　　公司刚开始只有淘宝，后来意识到B2C模式的业务也会是电商领域重要的组成部门，所以出现了天猫，随着天猫的不断发展，逐渐独立成一个部门，但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立，各自运行。

　　等到10年左右，阿里开始上线、聚划算等业务的时候发现，这些业务针对的领域虽然各不相同，但是他需要用到的系统功能也高度类似，主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍，这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求，为什么还要继续开发新系统呐？

　　在这个大的背景之下，阿里内部将共享服务部的职权不断提升，统一将各个业务业务部门重复使用，反复建设的功能和系统统一规划和管理。

　　比如说，滴滴在15年末开始启动自己的中台战略，这与滴滴当时的业务发展阶段也是相关的。

　　2015 年末，滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。

　　这些业务虽然会有一些差别，但是核心系统和流程都是类似的。如果各自独立开发，也会出现各种各样的问题。

　　比如说，开发成本过高，滴滴旗下的每个业务，其实都是可以单独支撑起一家公司的，如果每个业务都独立做到极致，那么开发成本和人力成本就会非常巨大，而如果为了控制成本，就把系统的建设放缓，则意味着，无论是核心系统本身的质量，还是对外的用户体验都不太好。

　　在这样的背景下，滴滴也开始考虑将诸多业务，以及各个城市的系统统一规划，统一建设，提升服务前台的能力。

　　其实，刚刚我们提到的，以及许多正在实践中台业务的公司，都有类似的问题，这些问题，大约会是两类——

　　一类是，许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。

　　另一类是，早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。

　　这两类问题，在软件开发领域，有专门的名称，叫做“重复造轮子”和“烟囱式架构”。这两类问题本质上是企业在发展过程当中，为了解决当下的业务问题，快速上线了很多功能，而欠下了许多技术债，当企业进入成熟期之后，发现这些问题的存在，严重影响了企业的运行效率和运营成本。

　　如何能够机制化，产品化地解决这些问题，能够更好地通过产品的形式，将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发，进而更好地帮助前台业务部门更多地关注业务，提高业务运营效率，进而提升企业竞争力，是企业开发中台的基本出发点。

　　现阶段，大多数提出中台战略或是建设大中台的公司，大多都有类似的困境。业务高速发展多年，许多问题积重难返或者大量在解决“重复造轮子”的问题，中台这个概念，很多情况下是因为契合了大公司业务的发展的情况，而被大家广泛认可。

　　前面的内容，我们大致介绍了中台要解决的问题。这给我们一种感觉是，中台是只有大公司才能做的事情，因为毕竟只有大公司在会有这种多条业务线，需要大量通用功能的场景，也只有只有大公司有能力拿出如此大的资源打造个中台。

　　现实情况也如我们所说，很多公司的中台业务，实际业务发展到一定阶段，进入一个瓶颈之后，为了能够应对接下来的问题，才一点一点从内部开始推动解决之前的问题。

　　中台作为一种产品设计思路，或者系统架构思路，并不受限于公司的规模，理论上讲，任何一家即将或者正在面临业务高速增长的状态时，都很值得利用和借鉴中台的思路，将目前业务当中大量可复用的功能和场景进行梳理，为业务的高速增长做好准备。

　　对于很多中小公司，当他们走出生存困境，进入到高速发展阶段时，会遇到很多的问题，但大概率会遇到的一个问题是，过往的业务模型，产品能力很有可能没法完全承接住大规模用户增长带来的压力。

　　而当你具体到每个用户的时候，你又能发现，他们遇到的问题你之前都遇到过，只不过，因为一下来的太多，你没法像过去一样提供达预期，甚至超预期的服务时，对方就会产生不满。

　　很多公司在这个阶段的选择都是为了临时解决一个问题，快速上线一个功能，也不是不可以，只不过，很有可能你的解决方案会不断带来新的问题，最后陷入到功能太过复杂，以至于积重难返的地步猫先生官方网站。

　　所以，在有可能的情况下，公司将一些大概率长期有价值的功能，专门模块化，进行开发和优化，确保即使业务规模进一步扩大，也能够满足业务需求。甚至，随着能力或方法论的不断优化，甚至有可能某一天成为整个行业的方法论。

　　这个过程，就很像是在高速飞行过程中修飞机一样。一方面，机翼已经千疮百孔，摇摇欲坠，另一方面，发动机还在运转，你还能往前飞，但你知道，如果再进入到下一场战斗，你不见得还能确保飞机不会坠落，所以，必须抢在下一次战斗前把飞机修好。

　　随着业务的发展，你对飞机的要求，也不仅仅是修好，可能会希望，能够提前预防一些问题。或者，知道你的飞机哪里战斗力最强，就把哪里做到最好。或许，就能够回避之后的一些问题。

　　当然，需要提示的一点是，对于中小公司而言，中台的理念不见得是单独拉几十人搭建一个中台产研团队，可以将一些关键流程先行标准化，把一些反复出现的场景当中的解决方案进行沉淀，部分需要产品化的功能先行产品化，可能对于一家业务刚刚开始起步的公司来说，就已经很重要了。

　　之前的内容，我们其实花了很大的篇幅来讨论，为什么会有中台，中台解决怎样的问题，以及中台适用怎样的场景。

　　但是，具体到业务场景当中，中台产品经理又在做什么事情，解决怎样的问题？如果想要成为一名优秀的中台产品经理，又会遇到怎样的困难和挑战？

　　我们采访了一些大公司的中台部门之后，会发现，中台产品经理面对很多挑战，其中，最主要要是最困难的挑战，主要集中在这样两个方面。

　　很多产品经理并不是从一开始就从事中台相关的事宜，也不是一开始就有中台这样的定位。更多情况下，他们是从前台业务部门，或者以业务为导向的产研部门转型到中台产研部门。

　　在业务部门或者以业务为导向的产研部门，最核心的目的就是达成业务目标，要求你速度足够快、功能高效地解决当下的业务问题，当前业务发展的效率是最关键的。

　　至于说，这个功能将来有没有可能适用于别的场景，有没有可能解决别的问题，这个问题实在是没那么重要。

　　对于中台产品经理来说，必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。

　　当你在业务部门的时候，响应业务是相对轻松的。但是，在中台部门，响应多个业务，就没有那么轻松了。

　　就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候，你只要和对接的业务人员沟通清楚需求就OK了，毕竟，你只要了解这一个或对应的多个部门的业务需求即可，业务目标相对比较明确。

　　你会发现，同样一个需求，A部门的流程和B部门流程完全不同，或者，流程是相似的，但到具体细节的时候，却有很大差异。

　　更可怕的是，同样一个问题，由于业务的发展阶段不同，对于问题的态度也全然不同：有的部门业务已经非常成熟，自己流程也很清晰，所以不太希望你来调整他们现有的流程；但是，有的部门还处于探索期，还没有遇到你提出的问题，可能压根就不理你。这时，对于中台产品经理的挑战就非常大。

　　他们可能会将大量的精力耗散于不同部门之间的沟通协调，反复对同一个需求进行确认，很长时间没有明显突破。这个时候，就要求中台产品经理有很强的沟通、协调和协作能力。

　　并且，因为他们接下来要做的解决方案，是要服务于多个业务。这个时候，需要中台产品经理有很强的逻辑思考能力，看到不同需求之间的共性需求，并提炼出一个产品化的解决方案。

　　甚至于，对于一些尚未遇到这个问题的业务部门，可能还要帮他们前置地思考解决方案。

　　既需要沟通协作的软技能，又需要逻辑抽象的硬思考，这可能才是中台产品经理最有挑战的地方。

　　虽然有挑战，但是也不见得没有方法。对于中台产品经理来说，刚刚我们提到的内容，也只是帮助中台产品经理，对于中台产品这个岗位所要面临的挑战和工作，能够有一些初步框架性的理解。

　　但是，在实际业务场景当中要解决的很多复杂问题，受限于篇幅，我们还没有详细讨论。

　　对于中台产品而言，他们的能力要求其实跨越非常大。一方面，需要极强的逻辑思维和战略分析能力，能够看到业务当中的关键流程，理解业务接下来的发展方向，并将其转化为产品功能，与研发一起实现。另一方面，又需要极强的沟通和交流能力，能够在与多个业务线，需求、背景、想法各不相同的相关方一起，推动完成相关功能的实现。

　　某种意义上，能够掌握掌握这两种似乎有些对立思维，并能够灵活运用，可能距离成为一个优秀的中台产品经理，就不太远了。

　　最后，如果你想了解更多关于产品经理的干货和内容，欢迎关注@三节课！如果觉得内容对你有帮助，欢迎点个赞，比心心～❤️

　　因为烟囱多了每个都要一个开发维护的产研团队，专门的服务器，专门的管理，贵啊

　　然后，非闭环导致的沟通成本和无限排期，业务需求根本响应不过来，效率下降了

　　自从阿里巴巴现任 CEO 逍遥子在2015年提出”大中台，小前台”战略以来，关于”什么是中台”，可谓是一石激起千层浪，大量文章在描述什么是中台。而不懂的人看完后依旧是云里雾里，我们经常听到一些词：”业务中台”，”技术中台”, “系统中台”等，我相信很多同学都会懵逼。

　　本文为作者眼中对中台的理解，中台可广义可狭义，理解到其本质含义更为重要。不同于其他由非技术人员编写的中台释义，本文会严格考虑系统实现的可操作性，时刻带着这种落地感来诠释中台。

　　也希望通过此文指引更多的企业走向正确的中台之路，而不要被那些花里胡哨的概念误导，最后落到舍本逐末、烂尾收场的尴尬境地。

　　最广为流传的故事应当是2015年年中马云参观 SuperCell 后感慨这家公司单个员工的创造价值为何如此之大——这家创造了年税前利润15亿美元的公司，却只有不到200名员工。

　　SuperCell 这家公司可能大家可能没听说过，但它出品的游戏比如《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等相信大家多少有所耳闻。这家公司的组织结构也是另类的，传统公司中越是上层，权利也越大，需求、产品定义都是由上至下的，如下图所示：

　　而在 SuperCell，CEO 权力很小，CEO 自称是”世界上权利最小的 CEO“，其实这正是一种睿智，自己反而轻松了，类似老子提出的“无为之治”，老祖宗的很多道理真的是放之天下皆可。先看下 SuperCell 的组织结构：

　　他们的工作模式是这样的：谁都可以发起新的游戏创意，然后给组织几个人去实施，做出来看看，行不行，火了就进一步推广，风靡一把；火不起来，玩家不活跃，那这个创意立即终止，再来一个新的继续搞。

　　这个想法其实他们不是第一个，很多公司都内部竞争，都有多产品实施。它们的牛逼之处还是在于上线一个游戏竟然只要若干人的小组就可以完成，笔者了解到的大公司中很多互相竞争的项目团队各自都是百人规模，还频繁在招人。

　　SuperCell 的快速业务试错模式固然是值得学习的，但支撑这些快速变化的却是背后的那套游戏构建系统。相信很多人，尤其是男生，都会偶尔有个想法：”要是能开发出这样那样玩法的游戏就好了“。

　　现在若是有一个平台，你只需要配置各种事件对应的反馈、游戏的一些设定、建筑的风格等，再配备几个美工，对游戏中的物体进行按需美化，这些操作之后，平台就会给你生成一款全新的符合你设计的游戏，这是多么高效、轻松、低成本的一件事。

　　相信只要熟悉这套系统，谁都可以在极短的时间内，完成一个新游戏的创建。事实证明，SuperCell 的这套新游戏研发系统已经炉火纯青了，《皇室战争》和《海岛奇兵》这两个游戏，如果您都玩过，你会发现它们的游戏画风极为相似，本人曾一度以为它们是一款游戏，只是做了APP升级。

　　就是这么一个逻辑，对前去参观的马老师一行人来说，犹如醍醐灌顶，豁然开朗。做管理做企业的领导们在看到“新”的高效的模式的时候，总是会想着我们公司是不是也可以这么搞？网上流言中台是马老师提出的无从考证，本人所知的情况是逍遥子内发的邮件最先提到了这个概念。

　　根据广泛的理解，前台一般对应着一个具体的商业模式以及配套的用户应用（App、小程序等），对应阿里的中台架构图（2.1部分会提到），前台就是一个个BU业务线。注意，这张图里压根就没有后台。

　　还有一种推理帝们的说法是，后台对应了面向内部人员的运营配置、前台对应了面向用户的客户端，所以中台就是衔接它两的。笔者想提醒下，这是压根不是技术人员提出来的，当年张建锋接到马老师的中台作业，也纳闷了半天，百思不得其解。

　　高层管理们不会这么理性的技术化的看待前中后台的关系，个人猜测他们的逻辑是，用户看得到的这些叫前台，这之后看不见的所有的支撑平台叫后台，由于考虑到需要直接支撑前台，所以搞了一个前无古人，后无来者的叫法——中台，连专业代码二十年的阿里各大技术元老们都涨了见识。

　　笔者看来，在管理层眼中的中台和后台（这里的后台跟技术理解的后台管理系统也不是同一件事）并无差异，只是强调这跟之前看不见的后台是有差异的，他们希望中台这部分能打造成为一个公共后台，而不是竖烟囱式的后台。

　　说了这么多，总结下本文通用的中台定义：前台的支撑系统，基础设施层之上的通用业务层，具体由通用的业务领域能力和与其对应的后台系统共同组成。

　　其中前台特有领域和中台领域之间的比例是按前台业务差异性不同而变化的，有些场景下，中台领域可以做的非常厚，厚到前台就剩一个前端应用（APP、小程序、PC站等）；有些场景下，中台可能只能做有限的抽象。

　　笔者的另外一个观点是——中台是一个相对的概念，除了整个集团能谈中台，在各个前台领域中，前台研发团队仍然可以做自己的“小中台”，用于服务自身商业模式下的多变的一类业务产品。这种关系是多级的。本质都是在做复用设计。

　　个人非常欣赏埃隆·马斯克经常提及的“第一性原理”，从本质来思考，SuperCell 公司并不是一开始就有一个“大中台、小前台”的战略在指引自己，而是任何一家游戏公司，要想做得好，不完全是追求短期利益，都会走向这条路。

　　事实上，超级细胞自身从来没有公开提出什么“中台”的概念。只从游戏工厂这种产品模式来说，SuperCell 也不是第一家这样做的公司，所有玩过暴雪的 WarCraft（魔兽争霸）的同学都知道，它不仅仅是一款即时战略游戏，它还是一个游戏制造器，通过创建一个新的地图，配置剧情，任何人都可以很快的上手并创建一个自己的玩法。

　　游久网就是这么一个专门提供不同魔兽争霸地图的网站。虽然看不到超级细胞的游戏创造后台系统，我们可以看看魔兽争霸的游戏编辑器是啥样的：

　　通过任务系统和事件系统，我们还可以定制出各种剧情。为了展示下魔兽地图编辑器（WE）有多变态，以下几幅游戏截图，都是来自于自定义的地图。

　　单说游戏工厂这种产品或游戏创作模式，暴雪的游戏团队绝对是全球顶尖的。在超级细胞的官网介绍中也曾提到，他们的很多员工都是魔兽世界的铁粉。

　　然而人们关注的往往是成功的对象，暴雪最近几年在手游领域除了炉石传说这种卡牌类的，几乎没出啥游戏。PC游戏做的再好，知名度也很难与全民参与度更高的手游相比。

　　与这些先驱游戏公司类似的，超级细胞的“中台”系统本质也是一个游戏工厂，是游戏行业里的一种高复用性、高度可自定义、高度开放式设计的软件系统。当然了，这个工厂生产的东西可能只是一套虚拟的游戏逻辑，具体的用户端APP还是需要依靠研发团队进一步加工和研发的。

　　个人猜想，马老师一行人回去之后，对标超级细胞一想，这么大一个公司，每天有那么多想法和创意，每个创意、产品都搞一个五脏俱全的团队去实施那得浪费多少人力成本？

　　要是有一个强大的系统，可以让各种想法和创意快速试错，推向市场、反馈、迭代，行就推广，不行就终止，那该多高效。所以才有了后来的“大中台、小前台”战略，为的是给业务打造快速试错的平台，

　　他们理解的中台实质就是一个业务产品工厂，可以通过“配置大于研发的约定”快速构建业务前台，这对应了超级细胞的各种游戏。

　　前台只是一层皮（这层皮也不仅仅是前端，还可以包括后面的前台领域系统），基础设施只是一套没血肉的骨架，位于中间的看不见的血肉才是软件系统的核心，如果这些血肉每次都要重建，那么将严重阻碍新业务创新、试错的速度。

　　和平台方法论并无差异——抽象通用能力+开放设计，这两者比例多大，不好说，这里也不想耍流氓那样用个二八定律去糊弄大家，相信不同的业务场景这个比例多少会有些不同。

　　四个字——系统复用。复用也分层次，也有复用程度之分，通过抽象出各种配置来支撑定制化这件事的本质也是复用——复用配置系统。

　　专注领域复用能力建设、配置大于研发。这个点看似很简单，但是极具艺术性，配置如何做到化繁为简很关键，如果发现配置复杂度比研发还大，那就瞎了。

　　2016 ATF 阿里技术论坛于4月15日在清华大学举办，主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中，业务平台从零到有，同时又逐步演进为业务中台。

　　下面是个人梳理的可能与阿里中台战略提出有关的一个时间线年淘宝事业部成立，推进以淘宝为中心的电商系统。

　　2008年，从淘宝事业部中抽出了一拨人，成立了天猫（最初期也叫淘宝商城）。天猫瞬间变火，业务话语权飙升，于是晋升成了天猫事业部，与淘宝事业部并驾齐驱。但是由于主要的技术团队都还是淘宝的，所以你懂的，很多公司毛病之一——意识太强，所以天猫的需求优先级总是比不过淘宝自身的。天猫业务团队自然就不爽了。另外，到这个时候，天猫和淘宝的大部分业务系统都是各自建设的，但都是由淘系研发团队负责。

　　2009年，共享业务事业部应运而生。领导层发现上述的问题后，决定成立一个与淘宝事业部、天猫事业部平级的事业部，用来处理他们的公共业务。这么看起来似乎很棒，但却带来了另一个问题，共享业务事业部自身没有前台业务，自然话语权比较小，所以逐渐演变成一个两头受气、吃力不讨好的角色。纵使研发天天加班，也填满不了铺天盖地的需求。

　　2015年年底，集团“大中台，小前台”战略正式启用。逍遥子张勇在邮件里写道：

　　“构建符合DT时代的更创新灵活的‘大中台、小前台’组织机制和业务机制：作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”

　　尝到了共享业务事业部的甜头后，加上前往超级细胞获得的灵感，集团大胆的走出了激进的一步——构建集团中台，纳入更多的BU。此时的整个中台的大致结构如下： 其中玄难负责业务中台事业群，致力于构建和推行整个集团的业务中台。

　　2019年，玄难离职创业，方向为电商中台。坊间一个比较靠谱的说法是：2015年阿里制订了一个15~18的三年中台战略，但到19年还没有任何建树，所以中台大将玄难不得不引咎辞职。

　　，如下图所示，中台的影子已悄然不见，取而代之的是出现了很多能力型BU和基础基建，这标志着中台回归本质化——复用，既然是复用，自然是被复用的能力型BU躺在下面，面客业务性BU在上面各自发展。

　　至今，官方和小道消息都没有具体中台有没有做成的消息，说没有做成吧，淘系电商业务平台（也可以叫中台）确实支撑了好多BU。但是支撑归支撑，要是中台做不大，前台做不小，可能还是达不到管理层的目标。

　　笔者猜测，由于管理层过度的理想化，导致技术实施时困难重重，毕竟复用性并不是想做多大就可以做多大的，支撑的业务模式越多，抽象出来的通用复用性就越底层。这就达不到小前台的效果，前台还是需要一定规模的研发团队，事实证明，目前阿里的各个BU仍然各自都有着大量的研发团队。

　　该部分没有什么参考文献，全部为个人的观点。笔者做软件设计和研发已有12年，作为一名架构师和码农，个人最怕的就是自己因为害怕走出舒适区而陷入“极端陷阱”。

　　陷入极端陷阱后引发的问题是，当时你以一个高层领导的身份急着去拍了一个方案，实际上还有很多细节没想明白，这样大概率的结果就是项目烂尾。

　　阿里集团业务繁杂度远高于超级细胞，中台范围应当细化，不适全局中台。治理小区和治理国家固然有一些类似的点和方法论，但是问题规模变大后，很多小规模下的方法也会变得不再适用，这是一个广泛被认可的观点。

　　超级细胞的业务范围很专一，就是手游，所以它可以很容易就做成游戏工厂。放到阿里这样的大集团，业务种类繁杂，性质大相径庭，何必强融？像淘宝、一淘、天猫，这些其实换汤不换药，那么即便没有中台战略，架构师也知道很多业务逻辑可以复用，要说阿里架构师没有超级细胞的架构师懂？怎么可能。

　　时至今日，中台的理念已经深入所有互联网人的心，阿里集团各个BU也在打着自己的中台算盘。全局大中台虽未建成，单各个事业部都开始在研发中试着使用中台思维去思考自己的研发体系。中台的理念一定是没错的，只是要因地制宜，切忌一刀切。早期，大家只会思考基础设施的复用性，产品如各种中间件等，现在大家开始关心另外一个问题了——这个业务能不能做成一个通用能力

　　中台，未必要大。前台，未必就小。能避免低水平重复性劳动的研发体系，就是可以被称为优秀的研发模式。

　　(1) 定义需要快速变化、试错的前台业务（业务线、产品线）如果您都无法清晰的定义自己的业务线，那么可以先内部脑暴一下。先基于现有的业务线讨论，再继续讨论未来可能发展的业务线) 领域分析和模块划分

　　先申明下，该图只是提供一种参考，着重去说明复用设计的通用步骤，不具备实际的参考意义，各企业应当结合自身的具体现状具体分析。图中每一列相同的颜色代表它们可以做成一套系统，给各个前台复用。

　　用户中心一般不带有具体的业务信息，这部分是可以做成全局统一的，也方便统计用户画像。当然了，各个业务线除了对接这个统一的用户中心外，还是要各自记录一些跟自身业务相关的用户信息，比如金融用户的征信信息等，这种信息可能还需要由另外的系统来承载——比如征信中心。

　　同样的商家结算，一般都是B2B之间的资金往来，业务不同仅仅影响的是交易凭证的描述不同，其他的结算方式等完全可以复用。

　　商品中心，看起来各个业务都有商品中心，但是各个业务线的商品结构可能存在差异，比如金融和传统电商的商品中心，其实现逻辑应当是不一样的。当然，硬要把金融产品标上价格，打上SKU去传统电商前台去卖，也是可以的，只是这种方式带来的问题需要事先想好怎么克服，例如，谁来配置这些SKU，谁来进行商品售后等等。

　　一般涉及货物差异性的业务，都会用到评价中心，这是对商户货物品质的一种用户反馈。而在金融行业的贷款业务看来一般不会对不同的资金提供方去做评价，不排除其他业务会有，比如基金业务等。

　　而有些领域是业务特有的，比如电商经常需要用到竞价中心，它负责对手商品价格的抓取和匹配等。

　　针对我们上文找出的存在复用可能性的领域（每一列里颜色相同的领域块），架构师需要识别出其边界和专注解决的问题，最后安排不同的产研团队去实施。各个领域块的研发团队在实施时应当尽可能的抽象公共业务逻辑，并且将无法通用的环节做成开放式的。

　　只要按照这个思想创建的系统，即便没有配置后台，上层业务系统对接也是极其轻松的。这里推荐另一篇笔者的文章

　　，它讲述的就是一种搭建通用大后端的系统架构，按照柔性的定义，这也是中台——它可以支撑新业务应用快速研发。

　　前两年阿里内部很火的NBF、TMF框架[10]，可以快速的通过配置和少量研发帮助阿里集团内的其他BU搭建业务项目，说的神乎其神，除了一两个用来打广告的案例之外，真实用的BU并不多，文献[11]

　　中台的建设应当围绕单一职责的领域能力去构建，单一能力又可以提供一些简单配置来实现定制化使用（就像一款款的中间件那样）

　　所以号称自己可以快速搭建某行业任何业务系统的“万能工厂”，多半是陷入了“极端陷阱”，最后只能是庸人自扰，舍本逐末。

　　万能工厂的做法不可取，这种方法的本质是简单问题复杂化，分布式前台业务的集中式抽象，若是前台业务逻辑本身就相似，那么不用系统工厂也能做的很通用；若是差异很大的前台业务，用了系统工厂可能更难如期交付。

　　不同的前台可以有自己的产品工厂，比如金融业务可以有自己的贷款产品工厂、电商业务可以有自己的商品中心等。在写该部分的时候，由于内容很抽象，笔者在极力寻找生活中的例子来帮助读者理解笔者的意图。

　　关于这个部分，可以这样来比拟：如果您某天特别想吃川菜，可以选择自己买菜来做；如果你想能定时吃到按照自己口味做的菜又不想自己做，你可以开个该菜系的小饭馆，请个川菜厨师；如果你还想吃湖南菜，那么你可以尝试招聘一个又会川菜又会湖南菜的厨师（类似业务线是存在抽象复用的可能性的）；

　　如果你心血来潮，想着自己还喜欢看书，就想着开一个超级工厂，可以生产你想要的任何东西（食物、书和其他），很可能您会落到一个舍本逐末、烂尾收场的境地。因为本来成立这个工厂就是为了节省成本，而建设它的投入已经远大于分别去搭建按现有需求所需的小生产线了。

　　即便万幸你的超级工厂建成了，你也会发现它的内部很可能也是一条条小生产线组成的，写书和炒菜毕竟差的太远了。这个例子告诉我们以下几点：

　　不要激进的去框定一个万能中台的目标，落到实处，为前台老百姓们切切实实的解决一些实在的问题。

　　[12]。笔者看完的感受是：广观各大互联网中台建设，都是打着中台的幌子在进行复用性设计战略实施，而且他们的战略实施都有个规律，都是从稳固底部做起，从下至上。似乎只有大阿厂是锚定了一个理想化终态从上至下的大搞特搞的。

　　从本质上看，全局中台没有意义，但能想的很清楚的领域能力一定要提供出来，比如用户、物流、支付、营销、数据管理等，能减轻多少上层的负担是多少，不必逞强。另外，前台业务的研发团队是需要保留的，他们需要基于全局的通用基础能力去构建属于自己业务的“小”中台。

　　打个比喻：路由器实现了手机、平板以及其他硬件和宽带的数据链接，有了路由器，硬件之间相互独立，又协同工作，可以做到快速交换数据，实现互通。

　　数据来自于饿了么、美团、小程序...等等，通过中台系统，可以把这些数据统一接入订单库

　　2、数据聚合通过中台聚合订单，对外提供「订单API」。门店Pos系统通过订单API获取订单打印小票，库存系通过订单API扣减库存，财务系统通过订单API结账。

　　企业如果后续要上新系统，比如会员、积分子系统等都可以直接和中台接口对接，获取到全渠道的业务数据，快速完成系统搭建，响应业务需求。

　　Thoughtworks王健《白话中台战略系列》中提到一个观点，业务「配速」，是理解中台系统出现的一个很好的切入点：

　　大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。

　　总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。文中也引用了Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告，即按照“步速”将企业的应用系统划分为三个层次，对应前台，中台，后台。

　　简单讲，中台类似一个变速齿轮，将前台的快速响应和后台的复杂，稳定可靠，变化周期相对较慢的矛盾适配起来，快速驱动业务创新的同时，又保持了IT架构的稳定。

　　比如在中东战争期间，美军的作战单位大都是10人左右的小团队，而支持他们的却是强有力的空军精准轰炸、舰艇远程打击、超强的救援与补给能力等等，这一切实际上都是依靠庞大的中台体系来实现的。现代战争的一个基本趋势是，随着“战场-基地-本土” 效率系统日趋完善，前线作战单元越来越小，但战斗力却越来越强，正是源于其后强大的中台能力。对于国内互联网科技公司而言，建立中台的灵感据说受到了一家位于赫尔辛基的游戏公司Supercell的深刻影响。这家由腾讯投资的公司仅有不到300名员工，却能在短短几年间接连推出《海岛奇兵》、《皇室战争》等十多款全球爆款游戏产品，成为最会赚钱的明星游戏公司。Supercell虽然员工数量很少，但通过设置强大的技术中台来支持众多的极小团队进行游戏研发，最终产生了惊人的创造力和利润价值。

　　平台是指连接两个或两个以上明显不同群体的服务中介，其本质特征为双边或多边市场属性，即平台上的不同群体之间往往具有正的交叉网络外部性，很多商业模式也由此而生。中台的本质是对通用能力的“封装”并以接口或组件的形式共享，其上的使用群体之间是否具有交叉网络外部性并不是它的核心属性。前述的Supercell中台战略以技术研发为主要维度。但实际上，中台的范畴要比这丰富的多，目前比较常见的包括技术中台、数据中台、业务中台、产品中台、研发中台、移动中台、组织中台等等，其中“技术中台+数据中台”的双峰模式最为流行。不同的公司在不同的发展阶段需要解决不同的痛点，因此中台战略的类型也就各不相同。实际上，就连同一种中台类型，其包含的能力也是多种多样。比如数据中台就可能包括数据整合能力、数据开发计算能力、数据服务能力、用户中台、内容中台、应用中台等多个维度，技术中台又可细分为通信中台、AI中台、安全中台等等维度，而且在服务的丰富度和共享性、系统的灵活性（参数可配置、流程可修改、插件可定制）等方面也都千差万别。从字面意思理解，中台的概念是相对于前台和后台来讲的。前台是公司与外部用户（或客户）交互的界面，后台则包括公司的财务、法务、管理、仓储物流、计算能力等等基础性资源。那么，很自然的一个问题就是，公司有了前台和后台，为什么还要再有一个中台？或者说，中台与前台、后台的理论边界在哪里？这实际上是一个基本的企业理论的权衡问题。诺贝尔经济学奖得主罗纳德•科斯（Ronald H. Coase）在其《企业的性质》一文中，对企业与市场这两种配置资源的主要方式及二者之间的边界进行了深刻的分析，从而被认为首次打开了企业理论的黑箱。他认为，企业和市场配置资源的方式分别为行政指令和价格机制，二者是相互替代的。当企业内部的组织成本低于市场主体之间交易成本的时候，企业就产生了。但是，科斯的企业理论并不能很好地解释科技公司的中台战略，因为中台的效率参照系并不是外部的市场价格机制，而是更多地取决于公司内部的后台及前台的资源组织方式与中台资源组织方式的博弈与权衡。当中台的资源组织方式效率高于后台（或前台）的时候，中台战略的强大生命力就会喷涌而出。数字科技的快速渗透同时正在触发传统行业领域公司组织形态的大变革，弹性调整变得更为可行，组织固化的时代必将一去不复返。前台小团队灵活对接用户，中台沉淀通用能力进行更高效的赋能支持，后台则重点打造基础能力和管理保障，这样的组织架构将会越来越流行。特别是随着产业互联网的发展，ABC（AI、Big Data、Cloud Computing）等通用技术正在向传统行业渗透，互联网科技公司的中台组织形态也必将“随风潜入夜”，融入社会经济方方面面，推动各个经济领域公司组织理论与实践的新一轮繁荣创新。本文节选自 腾讯研究院《科技公司的中台战略：理念溯源、组织边界及其实施之道∣企鹅经济学》作者：吴绪亮 腾讯研究院首席经济学顾问