合集1、什么是中台

目录：TOC\o"1-3"\h\z1、最近处处惹人爱的中台到底是什么 22、中台已成风口，该及时追逐还是继续观望？ 113、中台是什么鬼？和通用平台、定制、数字化转型啥关系？ 194、中台是什么，到底要解决什么问题？ 225、中台是个什么鬼|白话中台战略 276、中台热度消退后会怎么样 397、中台的末路 438、中台的定义|白话中台战略 549、中台的本质 6110、中台，都他妈被你们说糊涂了，文内才是正宗解释，别摸石头过河了，石头早就有了 6411、中台，Whocares? 7112、一文读懂什么是中台？什么是数据中台？ 7513、要不要凑中台的热闹？ 8414、跳出执行层，从方法论层再看中台 8715、什么是中台？中台在OTA领域如何发力 9316、什么是中台，什么不是中台。所有的中台都是业务中台 9717、什么是数据中台？全面解读数据中台 10118、让人尴尬的“中台” 10619、浅谈中台 11320、漫画：什么是中台？ 12821、今天，我“中台”了一下 13922、湖说中台 14723、到底什么是数据中台？ 16424、到底啥是平台，到底啥是中台？李鬼太多，不得不说 17125、产业洞察|中台，从北大战略研究所的一座小楼启程 17626、白话中台战略-1开篇：中台是个什么鬼？ 18327、白话中台战略-2：中台到底长啥样？ 19328、阿里炒火的“中台”概念究竟是什么？ 20229、中台究竟在治什么病？ 20630、前台、中台和后台有何不同？(上) 21231、前台、中台和后台有何不同？(下) 2151、最近处处惹人爱的中台到底是什么在当下互联网圈子里要问什么最火莫过于中台这一概念了，各大公司都开始了一轮跑马圈地似的中台建设，那么到底中台是什么呢？本文我们就来谈谈这个话题。什么是前台，后台在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：一个绿色图标的应用，里面有我的A,B,C好友。而后台则是包含两个部分：企业的内部管理服务的统称，如：内部的CRM，ERP等；为前台提供服务能力的，如：数据压缩能力，并发等。后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：

图：前后台模式

总的来说就是在应用中后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。中台的白话解释在开始谈论中台之前，我们先要明白当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新业务场景。这种前后台反而是公司最省事省力的一种提供服务的解决方案。因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。实际上中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。而作为实际用户真正接触的前台业务，如：APP，小程序，网站等，必须要快速迭代新的功能才能让用户感知到。而在这个大背景下带来的矛盾就是以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原来的前后台模式的这种直接关联决定了，两者的冲突不可避免。例如：传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式（拼团，一元购等），导致每次活动页面开发的时候，不仅需要前端重新设计页面，从后台接口提供与数据表都要重新设计。这无疑大大拉长了我们的需求响应时间，很有可能会导致在活动模块还没开发完成，我们的风口就已经过去了。因此我们需要一个能最少改动就能完成大部分需求的解决方案，这就是中台。中台解决方案到底是什么呢？让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易的理解这个概念了。首先请大家想一个问题，在一家客流量非常大的餐厅中我们要如何缩短客人的等待时间呢？相信很多人的第一想法就是增加多名厨师，但是大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的，而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里，厨师人员就显得非常冗余了。而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考。也就是将做菜变为：

图：做饭那些事儿

通过这样的拆分后我们可以发现无论是做什么菜系，买菜与配菜都是共有的两个步骤，我们完全可以只需要增加一位配菜的小哥来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：

图：“中台”餐厅

这样我们每一位厨师新做一道菜时没有必要一定要从买菜，洗菜，切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究不同的创意。完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人就解决了所有问题。回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。厨师是我们的一个个业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系，而在业务多元化后洗菜，切菜，配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可，当然这里的配菜小哥就是我们的中台。所以说有了中台之后我们的前台业务就可以快速尝试迭代，不需要每件事都是从0到1开始了。让我们再站在架构的层面来看看中台对整个系统业务所起到的作用。假设我们是一个电商平台在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，就像下图：

图：传统架构下的业务系统

而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务前台的特征加入适配。这样造成的结果：后台的每一个模块都需要加入与前台适配的部分，从而大大加大了开发量；每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量；当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知的使用各项服务而不需要单独设计通道，我们的系统也就简化成了这个样子：

图：中台化后的业务系统

通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。用一句话来概括就是：中台的核心本质就是服务共享，目标是支持前台的快速创新或试错，而实现的手段是微服务架构、敏捷基础设施和公共基础服务。中台解决方案那么到这我们可以给中台解决方案下一个定义：中台解决方案的组成=能力输出+标准化中间件让我们来一个个解释。第一部分：能力输出所谓能力输出就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。并在这些业务层面中去提炼哪些模块是以共性存在的，并会在每个新开拓的业务中不断使用，然后就把他归类到中台进行建设。这也就是中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。例如我们规划了公司的核心方向是视频方向，未来可能会涉及的业务形态有：在线视频视频直播短视频分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为：在线视频编辑视频压缩多人点播完成拆分后我们就可以通过中台去实现这几个通用模块。值得提一下的是虽然这里在说中台要考虑复用性，扩展性，但是要考虑多少，考虑多深这里又是一个非常考验产品功力的地方。还是举上面的例子来说我在设计一个视频社区APP的积分商城系统时，需要将商城交易方式抽象为能力时，这里我们大体上可以抽象为如下三种交易方式：

表：交易方式示例

但是同样的疑问来了，我们仅仅为了支持一个积分商城需要将中台的复用与扩展放大要考虑引入股票交易才使用到的撮合交易模式吗？当然这里的案例比较极端我们能快速判断，但是在具体的中台规划中我们会碰到很多这种类似的范围决策，我们必须要按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。第二部分：标准化中间件（整合能力）在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分就是需要做一个将每个能力进行封装，形成一个统一的可供前台业务端方便使用的中间件。这里的统一具体表现在如下的几个方面：不同终端中的叫法与含义；定义统一化的输入输出；为什么要统一呢，以往的前后台模式中同一家公司内的不同业务如：直播项目组，短视频项目组各自为战的时候，经常会出现一个事物被不同项目因为场景化的需求，而出现两个称呼的现象，但是实际上他们本质上是同一个事物。这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍：无法快速对接。例如：就那一个用户昵称这个字段来看，在不同项目组中的应用中可能会叫：用户名称，用户昵称，称号，花名等，而在数据库中又可能会有不同的字段名称：username，UN，name等等。因此我们需要一个中心化的产物帮助我们定义好这些个通用属性，使在公司中不同的业务端都能统一。面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候，无论具体是什么业务前端都会是一个叫法，一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。最后在竞争日趋激烈的互联网行业中，如何低成本又快速的完成业务创新去占领市场是每个企业所追求的方向，而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。2、中台已成风口，该及时追逐还是继续观望？一觉醒来，中台火了，颇有一种“忽如一夜春风来，千树万树梨花开”的感觉，它成C位真的是突如其来吗？中台的前世今生中台在前几年并未被大众熟知及热捧，而在今年5月21日后，中台在百度的搜索率噌噌噌的往上涨，究其原因便可知道5月21日腾讯召开了全球数字生态大会，会议上腾讯高级副总裁汤道生提出“开放中台能力，助力产业升级”。就此中台被腾讯带火，但国内最早搞中台的其实是阿里巴巴！马云的思维向来超前2010年中国（深圳）IT领袖峰会，BAT三家的当家人就云计算发表了不同的看法：李彦宏：云计算这个东西呢，不客气一点讲，它是新瓶装旧酒。马化腾：我觉得这个事可能你过几百年、一千年后，到“阿凡达那时确实有可能，但现在还是过于早了。马云：如果我们不做云计算，将来就会死掉！9年前，不同的看法，也反映出马云思维的超前瞻性。2015年年末，阿里再次超前地开启了企业战略管理模式的大变革，喊出“小前台、大中台”的管理模式。随后几年直到现在，中台理念终于越来越被业界关注！中台缘起：与其说是一种启发其实是不谋而合2015年年中，马云带领阿里高管，前往北欧芬兰一家移动游戏公司Supercell进行商务拜访。Supercell号称是当时世界上最成功的移动游戏公司，旗下拥有《部落冲突》、《皇室战争》、《卡通农场》和《海岛奇兵》这四款超级现象级产品。令人感到惊讶的是它并非大规模团队协作，而是一家典型的以小团队模式进行游戏开发的公司，以2到5个员工、最多不超过7个员工组成独立的开发团队，称之为Cell(细胞)。这些小团队自己决定做什么样的产品，然后推出市场，看看游戏是否受欢迎，如果反馈不好，迅速放弃，再进行新的尝试。若干个小团队可以快速决策，迅速研发，期间并不需要游戏引擎、服务器等后台操心，试错成本很低，这就是高效的散兵作战模式。而且团队研发产品失败后，不用担心会受到惩罚，相反，他们还会举办庆祝仪式，因为他们从中学到了东西，这种灵活运作的开发模式，让Supercell公司大获成功。Supercell的中台，是将游戏开发过程中公共的游戏素材和算法整合，并积累非常科学的研发工具和框架体系，构建了一个功能非常强大的中台。这样强大的中台可以支持若干个小团队在短时间内开发出一款新的游戏。这家北欧企业的管理理念给此次拜访的阿里高管们很大的震撼，这与马云正在构思的事情不谋而合，正是此次拜访，让阿里巴巴的组织架构调整进程之路走得更加坚定！中台的定义究竟是什么？中台一直被热议，但要说它的准确定义，就好比一千个人眼中有一千个哈姆雷特，众说纷纭。引用王健老师在《当我们谈中台时，我们在谈些什么|白话中台战略》一文中提到的关于中台的一些理解。在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类，人们都叫它“技术中台”。在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。在有些人眼里：中台应该是组织的事情，在释放潜能，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。上述理解都对却又不够完整。中台，作为一个还在被定义的概念，正处在一个大家好像都有所感觉，但又难以捉摸清楚的状态。而且这种相对模糊的状态可能还要维持相当长的一段时间。中台的几种类型阿里人将“中台战略”形象地比喻成陆海空三军立体化协同作战，他们将中台分成六大类：❶业务中台：提供复用服务，例如用户中心、统一营销、订单中心之类的开箱即用可重用能力，好比是空军的支援能力，随叫随到；❷数据中台：提供数据分析能力、数据模型搭建，打通部门之间数据的阻碍，帮助从数据中学习改进，调整方向，充当海军，更好的协同陆军、空军；❸移动及算法中台：提供更加个性化的算法服务，增强用户体验，就像是陆军一般随机应变；❹技术中台：提供自建系统部分的技术支撑能力，解决基础设施，分布式数据库等底层技术问题，为前台提供更精良的武器装备；❺研发中台：提供自建系统部分的管理和技术实践支撑能力，可快速搭建项目、管理进度、测试、持续集成、持续交付，是前台的训练基地；❻组织中台：为各项目提供投资管理、风险管理、资源调度等，担当指挥部的职责，指挥前线，调度后方。

中台能解决什么？想知道这个就要先了解下前台和后台。前台：企业的最终用户直接使用或交互的系统，是企业与最终用户的交点，例如用户使用的网站、手机App等；后台：企业内部支撑的管理平台，每个后台系统一般管理企业的一类核心资源，例如财务系统，产品系统等。中台的加入就像桥梁一般，架起了一个缓冲带。知道了上述概念也就能知道为什么各大互联网企业都趋之若鹜的要建中台。

解决痛点一：前台与后台的冲突前台对接用户，需要快速响应前端用户的需求，也就意味着转速越快越好，只有这样才可以迅速创新迭代。后台是企业对内的，为了支撑前台越来越多的业务，后台不断地建设，系统逐渐庞大起来，所以后台系统需要扎实稳定，转速也自然是越慢越好。前台系统和后台系统的特点决定了两者的冲突不可避免。这两个不同转速的齿轮，随着企业业务的发展壮大，速率匹配将越发失衡，中台的出现就像是变速齿轮，将前后台速率进行协调匹配，缓解创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应力，企业竞争力也能随之提升。 解决痛点二：重复建设，资源浪费当企业发展到一定程度，内部就会形成一堵堵墙，资源不互通。许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，部门在各大压力下有些事可以做却觉得没有利益而不愿意做，就导致了大量的系统重复开发、重复建设，复用性低、效率低、产研资源浪费、用户体验不统一。简单来说就是一个原本可以共用的服务，被不同部门重复建设，所耗费的成本和时间可想而知是多么巨大。中台适用于哪些企业？中台正处在风口浪尖，难道所有企业都应该建设中台吗？这就得先自问，你的企业规模是否已经成长到一定程度了，当你的企业拥有了一定的业务规模和业务价值，才具备了建设中台的条件。中台的核心目标是以用户为中心的持续规模化创新，它不是凭空产生的，而是建立在业务之上！一个企业在数字化道路上行进的路线应该是“系统化、中心化、平台化、中台化”，如果你的企业还没有成功实践到平台化，还是不要费力的折腾中台了。大公司总会先遭遇发展瓶颈，想要突破就要有组织重构的魄力，小公司不要盲目跟风，时间到了，风口就来了！中台是互联网技术的应用，更是企业综合竞争力的表现形式，需要从组织结构、运营方式、管理手段上更加扁平化。面对中台是不屑or迷茫，更应该以积极的心态拥抱变化，依据企业的需要制定正确的建设策略。企业的出路何在？可以说未来所有的企业核心都会变成数据加工，而数据中台则是数据价值化的加工厂，所以无论你是大企业还是小企业，都需要数据中台的能力，在数字化发展进程的下一阶段，数据中台一定是每个企业的标准配置。依据企业的规模和业务的不同，数据中台可大可小，规模、复杂度可能都不相同，但它对业务产生的价值是一样的。因此，企业应根据自身的业务，灵活地选择数据中台的部署。这就需要企业了解一站式客户经营大数据解决方案，只有这样，才能真正帮助你实现客户经营的"数字化运营和量化管理"，通过自由组合、分步灵活部署实施，构建适合自身业务与企业发展规划的数据中台。关于更多数字化运营及数据价值，篇幅有限不能展开过多，想继续了解，请关注猿道教育大数据分析课程，通过互联网应用架构、数据架构以及人工智能架构等新的技术综合应用，真正的帮企业打造以数据为驱动的业务运营模式，提供数据运营能力，持续创造业务价值，实现利益最大化！3、中台是什么鬼？和通用平台、定制、数字化转型啥关系？中台是近两天最火的词语，对中台的理解五花八门，不同人不同理解，中台也成各公司争相效仿的技术方向，似乎中台已经成为了万能钥匙，深圳有些公司有了中台焦虑；我分享一下我的理解，不一定对，闲暇时间浏览一下，就当抛砖引玉啦。中台我的理解，就是业务平台APAAS就是把业务通用的可共用的平台抽象出来，进行服务化改造，业务应用可以调用这些服务快速开发应用。怎么理解呢？首先把这两字理解清楚，中字，说明在架构上是处在中间，其下面还有一层或几层平台，那么下面就是什么呢，我认为是基础平台和通用平台，即iaas+GPaas；同时说明上面还有东西，那是啥呢，那就是应用；第二个字就是台，台就是说明有支撑作用，可以支撑上面的业务应用；那就可以理解了中台是指基于基础平台和通用平台的业务平台，可以支持公司多个应用的业务平台快速迭代业务的研发。中台的用途1）共享、重用和复用，将业务公共模块的提供业务调用，降低成本、提高效率、节省系统上线周期；2）快速支撑业务开发，很多业务时间就是金钱，需要快速迭代业务开发，中台能够很好支撑业务快速开发3）技术输出，积累的中台子系统可以为更多公司使用，变成一个企业应用平台业务线4）快速拥抱变化，应用基于中台可以快速调整，应用就是中台能力的编排，这样可以快速开发应用5）多种终端共享，web、app、小程序、快应用都可以基于中台快速开发。举个例子，中台的理解很容易跟通用平台混淆，为了方便理解举例说明一下；1）IAAS的话就是云虚拟服务器、云存储（包括对象存储和块存储等各种存储）、云网络、vpn等网络服务；2）GPAAS就是容器服务、容器编排服务、微服务框架、分布式总线、分布式数据库、分布式缓存、大数据平台、iot平台、AI平台等通用服务；3）APASS应该是啥呢？用户管理服务，打通用户管理，实现鉴权、注册、登陆、单点登录等功能，为上面业务提供统一的用户管理；精准用户服务，把用户从各位维度进行标签化，上层应用可以通过接口调用用户画像信息，获取需要用户画像信息；精准营销服务，可以基于用户画像数据，根据营销规则通过配置来实现对满足条件用户的精准营销；支付平台，对接支付宝、微信支付、银联等支付平台，为上层应用提供支付服快递服务，对接各个快递平台或者快递统一接入平台，为应用提供快递服务；以此类推，就是提供丰富的业务服务，让应用开发变得非常容易。Services就是基于中台编排来快速开发业务，实现面向用户体验的开发，应用端体现的就是用户注册、登录、浏览产品目录，查看折扣信息、下单购买、支付，快递进展和到货牵手完整的app体验。网站、小程序、公众号是一样的，都可以基于中台开发。APaas与其他软件开发的各种概念的理解中台和定制的关系，中台使能定制，中台使定制变得更快更好，中台不是消灭定制，而是支持定制；定制是消灭不了的；最著名的SaaS软件服务商saleforce也做了50%的定制；SAP、ORACLE也都有定制的合作伙伴，我的理解是赋能定制而不是消灭定制。中台与架构设计的关系，中台是架构设计的一个理念，一个牵引，架构设计的指导思想；架构设计是实现这种理念，支撑业务快速开发。中台与通用平台的关系，通用平台是指不带有业务特征，可以无差异的支撑各种业务开发，比如数据库、分布式中间件、容器服务、微服务框架等属于通用平台；中台构建在通用平台的能力，基于业务抽象出可以重用的功能模块，为业务应用所调用，业务应用可以基于中台快速构建，敏捷迭代开发。中台与数字化转型的关系，数字化转型是企业利用数字化技术支撑企业转型，这是更大的一个话题，需要重构企业的生产运营系统；中台是技术上的一个支持方案，是可选的，不是必须的。写了这么多收个尾，也留个尾巴，中台适合哪些业务，该怎么做留着后面有时间再叙述；利用中秋假期把脑子里想到的倒出来，不专业，描述也不完整、不准确，希望各位读到本文的不吝赐教。万分感谢。4、中台是什么，到底要解决什么问题？故事的开始这个最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头，从去年到今年，接连开始组织架构的调整，意图建设中台而上周一个阳光明媚的下午茶时间，我正狗啃着手抓饼。老板忽然把我们一班人拉进会议室，语重心长跟我们说——我们要搞数据中台！虽然一个会议下来，连他都没说明白“中台”到底是什么？但秉承不懂就少说，我苟了过去...直到吃完月饼，我们来对比下有无“中台”的情况项目现状项目有很多对内/对外/辅助，但无论项目内部的如何复杂，大体的结构都是“用户前台”和“管理后台”。用户前台:面向用户、直接产生交互，页面注重设计/交互，与服务端产生数据交换引导用户完成业务流程.管理后台:面向运营人员的配置管理系统，后台为前台提供了一些简单的配置。用户前台、管理后台、用户之间的关系如下：传统模式下，项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动，要么996，要么交付推迟而且项目之间相对独立，许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时，也让开发效率越来越低。但现实是互联网进入下半场，企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果，就等同让企业处于一定的竞争劣势。为了解决以上问题，而应运而生的是“中台”概念中台概念的先行者Supercell容忍失败，甚至为失败喝彩Supercell，失败从来不是可耻的记录，而反倒是一种进步的动力。一款游戏推出遭到失败后。其管理者的反应是“太好了，这款游戏失败了，证明了我们剔除一条错误的道路”。独特的“庆祝失败”根植于其企业文化之中，潘纳宁认为：“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快，我们学习得越快，也会变得越好”。失败时成功之母，能够真正做到从失败中获取需要的信息，学习如何成功深度利用云计算/微服务等技术，升级单个员工价值Supercell采用的是亚马逊的aws服务，他们每天需要处理万亿字节的数据，这些日志将会被用来改善游戏体验。充足且统一的公共业务模块，辅助团队避免重复劳动，专注于玩法、游戏体验创作即可快速堆砌产品。提升单个员工价值的同时，也降低了试错的成本小而精的团队300人的团队被分成若干个小团队，5-7个游戏开发者组成一个小团队，开发自己的游戏，以最快的速度推出公测版，检测游戏受用户欢迎的情况。这些小团队又被称为“细胞”(cell)。团队小意味着试错成本不会太高，时间和方向也可以及时调整和转变，以满足高速变化的市场需要，对战机的把握更加敏捷，一旦发现正确目标，就可以全力投入扩大战果信息共享他们会给公司内部所有人分享所有的信息。每天早上，所有人都会收到邮件，包括每款游戏的详细数据，工作环境非常透明化。游戏表现好，所有人都看得到，如果表现不行，所有人也都知道。这样一来，会形成压力比较大的工作环境，但对于合适的人来说，这也是他们努力的动力。总结要有想法中台解决的问题往技术层面说，中台解决的问题是——

多项目

且项目相对独立，导致需要重复造轮子，如：文件上传/订单模块/支付模块/搜索模块...引起的研发周期长，程序员996了都不能灵活应对业务变化的情况往业务层面说，中台解决的是——因为项目相对独立，技术重复造引起的研发周期长

/面对市场需求总是慢半拍(不灵活)/试错成本高

/

不利于创新中台解决的方式通过

统一的公共技术模块

抽离形成服务。再次需要该服务时通过接口调用完成，避免重复造轮子，避免研发周期拉长明确业务流程，封装成公共业务流程模块。当下次走同样业务流程时直接复用。降低试错成本，有利创新到时候技术研发的就不是项目，而是这些“公共模块”形成的服务，形成的中台说了那么多，举个例子：中台实例他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：中台的架构思想改变的不只是项目结构，也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。

紧随其后，国内互联网公司也纷纷开始了各自的中台战略。阿里巴巴提出了“大中台，小前台”的战略：图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。以上就是中台概念的具体含义。水了那么多终于水到个人感受“中台概念”往小地说，就是“微服务”。但中台需要使用产品管理的方式来对待。因为中台对外提供的服务需要不停的迭代，适应业务的需求，而不是等业务来提需求。对，技术人员也要懂业务。至于产品和项目管理有什么区别？这你得找产品交流下心得、切磋下武艺~5、中台是个什么鬼|白话中台战略从去年开始，好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起，给我带来了很多的困扰和思考与收获。故事的开始源于去年的技术雷达峰会，我在会上做了一场关于平台崛起的主题分享（《TheRiseofPlatform》），这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起，以及分享从基础设施到人工智能等各个领域不断涌现的各类平台，以及平台化对于软件开发人员及企业的影响。记得当时在做演讲彩排的时候，有同事就提到过，在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空，如果你提“中台”大家会更熟悉一些。而这也是我第一次听到“中台”这个词，原来除了我们熟悉的“前台”和“后台”外，居然还有个“中台”这样一个神奇的存在。那……中台到底是什么？会不会又是另一个Buzzword呢？这个从名字上看像是从前台与后台中间硬挤出来的新断层，它与前台和后台的区别和界限到底在哪儿？什么应该放到中台，什么又应该放到前台或是后台？它的出现到底是为了解决什么问题呢？从那时开始，一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天，随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨，终于可以坐下来回顾一下这一年的实践与思考，再次试图回答这些问题，并梳理成文，与大家交流探讨。中台迷思到处都在喊中台，到处都是中台，中台这个词在我看来已经被滥用了。在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。在有些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图(豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”看完本篇你就会理解，上边的这几类“中台”划分还是靠谱的，更多我看到的情况是大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。中台到底是什么？它对于企业的意义到底是什么？当我们谈中台时我们到底在谈些什么？想要寻找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个⾓度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度，来思考中台的价值，来试图反推它存在的价值。所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：企业为什么要平台化？企业为什么要建中台？第一个问题：企业为什么要平台化？先给答案，其实很简单：因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。很残酷，但这就是这个时代最基本的企业⽣存法则。数字化企业⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：⽤户响应力。这种能力可以帮助企业在商战上先发制⼈，始终抢得先机。可以说，在互联网时代，商业的斗争就是对于用户响应力的比拼。又有点远大空是不是，我们来看⼏个经典的例子:1.

说起中台，最先想到的应该就属是阿⾥的“⼤中台，⼩前台”战略。阿⾥⼈通过多年不懈的努力，在业务的不断催化滋养下，将⾃己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。阿里中台2.海尔也早在⼗年前就已经开始推进平台化组织的转型，提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“⼈单合一”、“⽤户付薪”的创客文化，真正将平台化提⾼到了组织的⾼度。海尔组织中台3.华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火”这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火⼒支援。⼤平台炮火支撑精兵作战可⻅，在互联⽹热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。数字化平台战略而平台化恰好可以助力企业更快更好的做到这些，所以这回答了第一个问题，企业需要平台化。第二个问题：企业为什么要建中台？好，想明白了第一个问题，为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?好，这就引出了我们的第二个问题：企业为什么要建中台？来，先定义一下前台与后台因为平台这个词过于宽泛了，为了能让大家理解我在说什么，我先定义一下本篇文章上下文下我所说的前台和后台各指什么：前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。后台并不为前台而生定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，以⽀持前台快速的创新需求。此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好，转速也自然是越慢越好。所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。随着企业业务的发展壮大，因为后台修改的成本和⻛险较⾼，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。对于这样的问题，Gatner在2016年提出的一份《Pace-LayeredApplicationStrategy》报告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。而Pace-LayeredApplicationStrategy也为“中台”产生的必然性，提供了理论上的支撑。Pace-LayeredApplicationStrategyGatner:Pace-LayeredApplicationStrategy在这份报告中Gatner提出，企业构建的系统从Pace-Layered的⾓度来看可以划分为三类:SOR(Systemsofrecord)，SOD(Systemsofdifferentiation)和SOI(Systemsofinnovation)。处于不同Pace-Layered的系统因为⽬的不同，关注点不同，要求不同，变化的“速率”自然也不同，匹配的也需要采⽤不同的技术架构，管理流程，治理架构甚至投资策略。⽽前面章节我们提到的后台系统，例如CRM、ERP、财务系统等，它们⼤多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核⼼可追溯单据(例如财务单据，订单单据)为主要⽬的。它们的变更周期往往比较⻓，⽽且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低，变化成本高，变化⻛险高，变化周期⻓。⽆法满⾜由⽤户驱动的快速变化的前台系统要求。我们又要尽力保持后台(SOR)系统的稳定可靠，⼜要前台系统(SOI)能够⼩而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。正当陷入僵局的时候，天空中飘来一声IT谚语：软件开发中遇到的所有问题，都可以通过增加⼀层抽象⽽得以解决!⾄此，⼀声惊雷滚过，“中台”脚踏七彩祥云，承载着SOD(Systemsofdifferentiation)的前世寄托，横空出世。中台才是为前台而生我们先试着给中台下个定义：中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题有了“中台”这⼀新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。总结思考并回答了文初提出的两个关于中台价值的核心问题，解决了我对于中台产生的一些困惑，不知道对你有没有启发，让我最后再来总结一下：以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境，弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了这条正确的⼤道上。6、中台热度消退后会怎么样中台的概念是哪来的

2012年开始，一家研发了《海岛奇兵》《皇室战争》《部落冲突》的芬兰游戏小公司SUPERCELL以其惊人的效率和产品质量逐渐走进大众的视野，与其不足300人团队形成鲜明对比的是，他们的产品都获得了巨大的成功，平均每款游戏都能收入数亿美元。身边的人或多或少都玩过他们的游戏，与普通玩家关注他们研发的游戏不同，阿里巴巴对他们团队的产品研发方式有更大的兴趣，在实地拜访后，阿里在在2015年提出了“大中台，小前台”战略，而中台就是由此衍生出的概念，自此开始，全国的大小公司一时都在建设或规划建设自己的“中台”。什么是中台

一个能够为前台提供低成本和快速的研发成本的服务，就可以称之为广义上的中台，中台实际上是一种理念，一种计算机领域里老生常谈的理念——复用，但是仅仅是复用还不够，还需要将公司内部的核心能力抽象整理出包装成一个公共的服务提供出去，从而打破研发中的壁垒，连接信息孤岛，避免重复造轮子引起的研发资源浪费和技术构架管理混乱，从这个角度讲，中台也是公司的一种内控手段，对于业务层面而言，中台为业务提供了一个归一化、标准化管理的解决方案。

在一个公司中，随着业务形式的多样化和精细化发展，系统的迭代速度需要能跟上业务变化的节奏，稳而重的后台很难“灵活”地针对于前台的种种场景作出适应性变化。电商领域的业务中台举例，在拼多多入场时，火爆的拼团社交玩法，打了传统电商的一个措手不及，因为社交电商利用人情网可以迅速到达下沉市场，获取到更多的三四线城市和乡镇里的用户，而这片市场对于淘宝、京东、苏宁来说正好都是一片蓝海，因此，如何能够快速跟上拼多多的节奏，杀入这片市场？当然是按照拼多多的模式再造一个app投入到市场中，显而易见，拼多多本质还是电商，还是卖货的，电商能力也都是其他厂商所具备的，只需要将电商能力赋予新的“拼多多”们就好，而将电商能力快速提供出来的正是中台。

中台不是一个建好之后就不用修改的万金油一样的存在，它也需要迭代，但是与传统管理后台不同的是，中台从架构的设计之初就要求设计研发人员具备更高的设计视角，更高水平的设计能力，能够抽象出、把握住核心的业务流程。越复杂的业务，中台的设计就越底层，越能适应更多的变化，业务中特有的成分由前台去承担。什么情况下需要中台

在一个公司具有一定的规模，在同一领域有多重业务形式的时候，就可以考虑建设中台，但是在建设中台的时候需要严谨地考虑以下几个问题：中台建设需要明确中台的业务承接范围，哪些是中台做，哪些不是中台做，否则大多数别人不愿意做的工作会推到中台，让中台承接，不断扯皮。中台建设需要考虑研发团队之间的关系，避免一个研发团队承接了中台后，只承接自己团队的需求，中台迭代只照顾到了局部的需求。中台建设需要有对业务及其熟悉的人一起梳理业务现状以及发展情况，以便能达到更好地提炼抽象业务的目标。避免钻入牛角尖，中台不是一个绝对化的实体的系统，也可以一个相对虚拟的研发管理层面的概念，当然也可以通过某种形式实体化。中台建设需要有强有力的推动者，特别是在已经具有一定规模的公司中，中台化的推进工作需要很强的项目管理能力和管理者的话语权。中台不是一个系统，而是一种能提供出去的能力，一个企业在业务层面可以有很多个中台，视业务复杂情况而定中台建设好了，然后呢？

中台建设或改造完成后会进入缓慢而又漫长的迭代周期，与常规的管理系统不同，中台的迭代频率较低且慎重，通常最终有两种结局，一种是稳步迭代，能够大幅提高效率，减少成本，为前台提供更好支撑；一种是偏离规划，将中台越做越臃肿，越做越复杂，直至迭代不下去只能重构。

中台的建设迭代切忌“中台是个筐，啥都往里装”，在划分权责的时候一定要明确，否则就会成为上述的第二种情况。中台热之后回归理性

随着几年时间的探索，情况也逐渐清晰起来，热度退散后，人们不再盲目的建设中台，张口闭口全是中台，建设一个大而全的中台。而是在实践过程中，合理地评估实际情况后建设中台，并且将多个中台与诸多前台有机和谐的组合在一起，以提供更大的能量。

将中台作为一种设计能力和理念输出到每一处服务的设计中，如此这般，产品的构架和设计者的架构能力都会得到很大的提升。这也是中台热带给我们最大的启示。7、中台的末路从15年开始，到19年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主。是某些架构师和PM的新出路。各种割韭菜的讲中台的课程层出不穷。当然，吹牛逼的时候大家都是拣好的说，苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱，只凭各路英雄的演讲内容，那看起来是靠谱的。先来看看这些公开的观点，再以我（码农桃花源注：资深研发工程师）的视角还原“中台”的真相。按照码农桃花源文章的惯例，手动贴上文章的目录：公开的观点中台是什么阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价中心等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。钟华.《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》中台实际上是通用业务的下沉，企业在一个行业耕耘多年之后，一般都会形成一些公用的业务，而这些业务是可以像中间件那样进行下沉共享的。再往前推一些，也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。为什么要做中台中台解决了什么问题？其实和把程序内的公用逻辑封装为library差不多，就是尽量避免重复造轮子。一个轮子造100遍，对部门是没有任何好处的。一个系统造100遍，对企业自然是没什么帮助的。早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现“所有部门都在造差不多的系统”的现象。中台从公司战略角度，将这些行为进行了规范化，公共的部分交给公共系统部门去做。中台给企业带来的收益工程方面就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。数据方面有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。有了统一的中台，也就有了统一的数据规范。对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。创新方面这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！钟华.《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。真相中台能解决问题么？是能解决的。中台能解决所有问题么？那显然是不能的。就像微服务架构一样，架构师吹牛的时候天花乱坠，你做起来却发现这条路上全都是坑。技术方面公用业务下沉，这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装、抽象，变成Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。（码农桃花源注：新瓶装旧酒）难以应对Crosscuttingconcern根据中台进行系统拆分和部门调整之后，还是会遇到crosscuttingconcern，什么是crosscuttingconcern：Thecrosscuttingconcernisaconcernwhichisapplicablethroughouttheapplicationanditaffectstheentireapplication.Forexample:logging,securityanddatatransferaretheconcernswhichareneededinalmosteverymoduleofanapplication,hencetheyarecross-cuttingconcerns.有些需求难以避免地会影响整个流程中的所有系统。比如从技术范畴进行的一些改造(如为了完成tracing，所有系统增加traceid，并在log中默认携带)。比如从业务范畴进行的i18n改造。（码农桃花源注：i18n是国际化的意思，Internationalization去掉头尾的i和n刚好还剩下18个字符，程序员的智慧）这些改造需求一般天生就是跨系统、跨组、跨部门的，事情一带上“跨”的字眼，就不好搞了。（码农桃花源注：别人的地盘，你能做主？）举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改20+个模块，苦不堪言，连上线顺序都不一定搞得清楚。当这20+个模块又是跨部门的时候，就更难了。想要推动其它部门做一些短期看起来没啥收益的事，太难了。稳定性和灵活性的矛盾对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。就像网友经常讲的不作死就不会死，没有代码才是真正的稳定之道。Google程序员在Github上发起的行为艺术项目：nocode，没有code，就没有bug。可谓弃疗的典范。有很多中台系统被剥离之后，因为用户众多，一旦出现技术上的问题，影响面巨大。从我的实际观察来看，中台部门的系统虽然初始立项的时候声势浩大，但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”，“垃圾”在转过几手之后，后来的人基本就不太想对原来的代码进行修改了。可能有人会讲你可以重构啊。嗯，重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有！在没有测试的情况下，我们可以根据过往的系统需求文档和PRD（码农桃花源注：产品需求文档，ProductRequirementsDocument）来还原当时的业务场景，并进行测试补充。但你又发现，中台的性质（大多偏技术项目，基本没什么PM把关或者出文档）使其基本没有什么靠谱的、详尽的文档。写的复杂的中台，连业务流程都理不清楚，还想写测试，别做梦了哦。中台与前台的模糊业务边界、距离在实际实践时，中台与FT的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态，这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务，这时候用户服务就只是进行字段存储，而状态机变化则完全在外部。如果对系统内的个别数据不进行管理，那么有其它接入方接入时，就无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入，那么前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。如果想要把这些数据接管过来，那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部，这往往又会产生与中台与前台业务边界的冲突。难以给出有效的边界，就意味着无穷无尽的撕逼。这便是很多中台的两难：我接不是，不接也不是。如果去问那些中台业务部门的系统开发负责人：某些业务要不要你们来做，连这些人自己都说不清楚。人方面如果要做中台，那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。这一样会引起双方的反感：交接方：这是我们加班加点，辛辛苦苦开发出来的系统，凭什么交给别人？奋斗了半年难道就是为了给别人摘桃子？被交接方：这个系统原来的维护团队水平极低，代码就是一堆“垃圾”，他们不想搞了就随便扔给我们？凭什么啊？我们又不是接盘侠。即使贵司运气好，在系统交接过程中没有出现问题，那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态，这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样，原来的中台部门便会陷入尴尬的境地。生存空间被挤压，人也自然很难待得下去，各公司的中台部门，人跑的比香港记者都快。部门、公司、组织架构方面跨部门沟通障碍、跨部门目标差异进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标（KPI）一般是不相同的，如果相同的话，那也就没必要分多个部门了。而部门与部门之间的目标在某种程度上甚至可能有冲突，例如A部门FeatureTeam较多，主要负责业务功能迭代，需要更强的灵活性。而B部门负责中台数据，主要关心系统稳定性，也就是前文提到的灵活性和稳定性的矛盾。若此时出现crosscuttingconcern，两个部门需要在矛盾上取得一定程度的平衡，这种平衡在个别情况下是不可得的。例如在一段时间内，中台部门的目标是提高某个商业指标，让公司更赚钱/省钱。这时候前台业务提来了新的需求，这种需求是能使流程开发更加灵活的，但与中台部门的KPI不在一个航道上。中台部门显然要把需求排排优先级，把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪，不如自己实现了。前台业务也有自己的理由：“自闭环”嘛，这词真是好用。公司利益分配毫无疑问，距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。中台看起来是业务，但又是公共业务，既然是公共业务，那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中，中台的强大、便捷是重要原因。这会导致什么问题呢？没有人愿意接手中台项目，中台项目变成烫手的山芋。大佬无法在中台项目上获得红利，小弟们没法在中台项目上获得利益。中台功能确定以后，只有出事故的时候大家才想起你来。稳定运行是应该的，出事就是你的锅！利润中心？其实是成本中心最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。钟华.《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》在大多数公司，中台部门和基础架构一样，会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看，科技公司是怎么看待员工的呢？在DDD（码农桃花源注：领域驱动设计，DomainDrivenDesign）相关的书里提到两个概念：成本中心、利润中心。技术对业务参与不强的情况下，技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标，必须不情不愿地花钱去养你们这些技术团队。对应业务侧开发来说，想要改变老板的这种看法，需要让业务系统和业务人员之间进行强联动，将一部分业务人员变成系统人员架构中的业务专家角色，或者是研发人员自己变成一个业务领域专家，就是有些人常说的你得跟老板穿一条裤子。从这方面来讲，大多公司的基础架构角色就比较尴尬。业务驱动的公司，基础架构并不是其致胜要素。所以不管你做的再好，只要公司没有用技术赚钱，那么这部分的支出就只能被当作单纯的成本。当然了很多做基础的大佬也根本不在乎，公司只是个练兵场，练成了带小弟们跳槽就好。（码农桃花源注：求带！）中台也是一样的，从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值，中台便渐渐变成了他们眼中纯粹的成本中心，是公司财务的包袱而不是财富。行业方面中台建设一般要考虑公司的实际情况，这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功，公司肯定要进行跟进。但是新的模式一定意味着对原有系统、架构的挑战。试想，原来系统架构是针对线上交易设计的，突然有一天，O2O模式被证明有利可图，大多数公司都开始转向线下。原有的流程、模式当然想要复用，但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱，轻装上阵，以更低的成本更短的时间攻城略地，挤压自己的生存空间。这时候怎么办呢？大多数公司给出的方案是成立新的业务部门，在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务，又碰到了我们的老问题：跨部门合作。新部门的成功并不会让老部门多得到多少好处，配合自然不会太积极。（码农桃花源注：公司内部做事都是利益驱动）如果新部门的尝试获得了初步成功，得到了公司资源的倾斜，获得了有效的人力资源补充。之后又会带来新一轮重复造轮子，互相不合作，互相撕逼的腥风血雨。简直是一个轮回。结语经常有小伙伴说，国内某公司中台非常好，大家都在学。嗯，我倒是想问问了，如果真的做的好，某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构，和好几朵云？（码农桃花源注：曹大真敢怼！）作为一个技术人员，在各种乌七八糟、花里胡哨的概念“轰炸”下，应该能够保持理智，不要被各种人带节奏。8、中台的定义|白话中台战略HYPERLINK写“白话”这个系列主要是想通过写文章来驱动自己思考，并借此和更多人一起交流和探讨中台这个话题。幸运的是，确实有很多朋友在公众号后台给我留言来表达自己的想法，在此摘出来一个具有代表性的：“互联网的企业就是爱炒概念。本来很明白的东西，被他们一包装，就变得高深莫测了。我理解中台，就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”我很赞同这位同学的观点，中台本身就是一个比较抽象的概念，很多时候我们被那个“中”字困住了，整天在前与中、中与后的具体差别和评判标准上纠结不已。但是，就像「看板」不是“我们看到的那个板子”一样，「中台」也不一定就是代表“处于中间平台”，这两个字作为一个整体，代表了一种新的思维和理念。在最新一期的ThoughtWorks技术雷达讨论阶段，中国区的同学就把“ZhongTai”作为一个独立的技术点提交，并没有做意译，就像“Kanban”一样。那这种新的思维和理念到底是什么呢？“中台”的背后到底意味着什么？有没有价值？价值何在？这也我一直在不断询问自己的问题。要想搞清楚这些问题，我认为一个关键点就是：是否能够给「中台」这个相对抽象的概念找到一个清晰的定义。因为只有通过定义才能让抽象的概念清晰化，从而明确边界、体现价值。废话不多说，回到「中台」，如果让我给出一个定义，目前我认为最贴切的应该是：中台就是「企业级能力复用平台」很简单，有点失望是不是？但是为了找到一个靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，只有这个定义是我觉得最贴切、最简单、也最准确的，它能解释几乎所有我碰到的关于中台的问题，例如：为什么会有那么多中台，像上文提到业务中台、数据中台、搜索中台、移动中台，哪些才是中台，哪些是蹭热点的？中台与前台的划分原则是什么？中台化与平台化的区别是什么？中台化和服务化的区别是什么？中台该怎么建设？等等……这9个字看起来简单，重要的是其背后对「中台」价值的阐释，下面就让我为大家一一拆解来看。企业级首先，中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业，例如现在同样火爆的“生态”的概念。按照徐昊（ThoughtWorks中国区CTO）的说法，更贴切的叫法应该是「多前台产品团队」，这里为了简单我还是用企业级来代表。当做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀，从而希望通过能力的复用一方面消除数据孤岛、业务孤岛，一方面支撑企业级规模化创新，助力企业变革，孕育生态。所以虽然中台的建设过程虽然可以自下而上，以点及面。但驱动力一定是自上而下的，从全局视角出发的，并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门，例如CIO级别领导或是企业的战略规划部门，因为只有这些横跨多条业务线的角色和组织，才会经常去反思与推动企业级的能力复用问题。这一点也引出了中台建设的一个关键难点，就是组织架构的调整和演进以及利益的重新分配是技术所不能解决的，也是中台建设的最强阻力，这个我打算在后续的文章里详细阐述。同时企业级也是区分企业中台化与应用系统服务化的关键点，简而言之中台化是企业级、是全局视角，服务化更多是系统级、是局部视角。所以从中台的兴起与爆发可以看到一种趋势——越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要，对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。能力提到中台，最常听到的一个词就是「能力」。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。企业的能力可能包含多个维度，常见的例如计算能力，技术能力，业务能力，数据能力，AI能力，运营能力，研发能力……其中大部分的能力还可以继续细化和二次展开，从而形成一张多维度的企业能力网。我在上一篇白话中台战略-2中台到底长啥样？中已经举了一些常见的例子，这里就不赘述了。可以说，中台就是企业所有可以被「多前台产品团队」复用能力的载体。这里有一个经常碰到的问题，就是对于某一家企业来讲，你说了有这么多种不同类型的能力，到底哪些能力才是我们企业需要的？哪些是值得中台化的？优先级又怎么划分？这个问题比较大，也很难有一个统一的答案。我们现在的做法是尝试通过一系列Workshop，从业务、数据、技术等多个方面切入，通过一系列方法，结合企业愿景，市场定位和数字化现状，跨越多条业务线，试图将企业需要的能力和可复用的能力识别出来，并为落地做好规划和准备。这些会在后续写到中台如何落地的文章时再详细展开。复用讲到这儿，相信大家一定有一个疑惑，无论是企业级，多前台产品团队，还是讲能力沉淀，都不是什么新话题。很多企业在组件化、服务化平台化上搞了好多年，那「中台」到底有哪些新的启发？我的答案就是对于「复用」的关注被提高到了一个前所未有的高度。虽然我们一直讲「去重复用」讲了很多年，但仔细想想，大多平台化建设会将重点放在「去重」（消除重复）上，而对于「复用」则没有足够的关注。很多企业都号称已经建成了各种各样成熟的平台，但是我们扪心自问一下，有多少平台是业务驱动的？有多少前台产品团队又是自愿将自己的产品接入到平台上的？有多少平台建设者是在真正关注前台产品团队的平台用户体验？「去重」讲的更多是向后看，是技术驱动的；「复用」讲的更多是向前看，是业务驱动和用户驱动的。所以「去重」与「复用」虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同，做到「去重」已然非常困难，关注「复用」的就更是寥寥无几，所以：「复用」是中台更加关注的目标；「可复用性」和「易复用性」是衡量中台建设好坏的重要指标；「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。而实现更好的复用，常常从两个方向做改进：一方面将更高抽象（例如业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是，抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。另一方面就是通过对于中台能力的SaaS化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。这里还有一个很有意思的点，相对于「能力复用」其实我们更常用到的词就是「能力共享」，这两个词有些相似。但考虑到「中台」这个概念更加强调对于前台业务的支撑与赋能，除了基本的能力沉淀与共享外，也会更加关注前台的易用性和使用体验，所以我觉得「复用」更能体现出这一点。平台这里的平台主要是区别于大单体的应用或是系统。传统的企业数字化规划更多的是围绕业务架构、应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划，例如要采购或是自建哪些具体的系统，例如ERP、CRM等。当然这个过程并没有什么问题，可以理解此时这些独立的系统就承载了企业的各种能力，由于企业各业务线统一使用一个应用或系统，也自然实现了能力的复用。但问题常常出现在两个方面：一个是大单体系统的业务响应力有限，缺少「柔性」，当业务发展到一定阶段后，必然产生大量定制化需求，随着内部定制化模块的比例逐渐上升，响应力成指数下降，成为业务的瓶颈点。另一个则是系统间的打通通常比较困难，容易形成业务孤岛和数据孤岛；所以越来越多的企业开始向互联网学习，以平台化的方式重塑企业IT架构，从而给业务提供足够的「柔性」，来满足对于业务的快速响应和复用的需求。总结「企业级能力复用平台」这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释：「企业级」定义了中台的范围，区分开了单系统的服务