到了去年底，阿里巴巴董事长兼CEO张勇在湖畔大学分享时也说：如果一个企业奔着中台做中台，就是死。
其实中台到底 解决了什么问题，怎么落地，都是落地全靠临时发挥了。
大体量的系统，谈中台才有意义！
软件架构，都是逐步演进的，跨度太大，一方面公司没有这方面的财力、人力等你来搞，另一方面技术方面也会存在短板障碍，很容易存在“将就先搞后续完善优化”的思想。
架构演进，静下心来，看看中台真的适合你么？看完下文，你或许心里会更有数。
1、中台源
2009 年阿里共享业务事业部诞生，它在多年后承接了阿里的中台的重任
2010 年 6 名资深游戏开发者创立了 Supercell 公司，旗下拥有《部落冲突》，《皇室战争》，《海岛奇兵》，《卡通农场》这四款超现象级产品。
2015 年中，据说马云带领高管拜访了芬兰赫尔辛基的 Supercell。Supercell 公司员工不多，Supercell 每个团队员工不超 7 人，团队自己决定做什么产品，实现产品快速开发。这次访问据说给阿里高管带来了极大的震撼，于是大家开始思考快速发展的信息时代中公司的架构到底应该是怎么样的。
2015/12 阿里 CEO 逍遥子的一封内部邮件打响了阿里内部进行“大中台，小前台”组织架构升级的指示
2015 年末，滴滴启动中台战略，构建业务中台主要出于四方面：专业深度，人力资源，用户体验，全局打通
2017/12 滴滴分享了如何构建自己的中台
2018/1 京东进行组织架构调整
2018 下半年，爱奇艺开始规划做中台
2018/7 百度总裁陆奇离职
2018/12 京东宣布采用前台，中台，后台的组织架构
2018/12 百度内部宣布进行架构调整
2019/3 字节跳动对外透露正在搭建“直播大中台”
2019/5/6 上半年，知乎创始人于第二届数字中国建设峰会接受专访时提到知乎的中台
2019/5/21 腾讯召开了全球数字生态大会，会上腾讯高级副总裁提出了“开放中台能力，助力产业升级”和“开源协同”和“自研上云”，然后“中台”立马就被带火了。从百度搜索指数可以明显发现，从 5/21 起中台搜索量指数往上涨
2019/8/9 小米在 ITex 供需博览会上提出小米中台进行业务 + 数据 + 技术建设
2019/10 爱奇艺在 QCon 全球软件开发大会上对爱奇艺中台进行介绍
一、大厂的中台
1、腾讯
All in产业互联网。腾讯的技术委员会，对标的是阿里巴巴的中台事业部，而不是外界所解读的对标阿里“达摩院”。整合带来的最大好处就是技术的标准化，而这一切显然是为其中台战略做铺垫——标准化意味着腾讯可以更高效地把自己的能力交付给客户
2、百度
建立可复用的中台能力。百度中台的技术思路：提供完备的通用能力、定制能力，持续完善领域技术沉淀能力。业务视角， 中台提供了灵活的可定制业务框架， 使得业务可以聚焦业务特有逻辑的开发
3、小米
业务+数据+技术。小米业务中台建设三年战略，包含了持续优化、构建中以及待新建的系统，纵向分为企业战略、业务执行、业务支撑、数据治理四部分。
4、滴滴
构建最合适的业务中台。在对业务和产品进行更好建模的基础上，进行了“五化”：服务化、异步化、配置化、插件化、数据化
5、京东
打造共建、共享、标准化的数据中台。目前京东集团已形成零售、数科、物流、保险、健康等多元化的业务格局，各业务都进入到精细化运营阶段，对于数据精细化运营提出了更高的需求。京东过往十多年业务发展沉淀下来的海量数据，需要通过数据中台的建设形成宝贵的数据资产，以打造强有力的数据智能能力。
6、网易
胖中台、标准中台、平台组织。标准中台组织由各个能力组和工具、规范/流程/方法论组成；当标准中台组织对业务的介入程度不足以支撑中台的实现，就需要更加接近业务的定向组来参与，这就形成了胖中台组织；而能力臻于成熟，工具、流程都实现标准化，标准中台组织也可以退化成平台组织。
7、用友
3+2+1。近两年随着对中台理念、架构及配套研发运营体系的深入理解和落地，用友的iuap平台逐步演变为基于统一中台内核的3+2+1架构，即3大中台，2大服务，1个面向用友所有客户和生态的统一开发平台。
8、知乎
大中台小前台。前台有三个业务团队，分别是社区事业部、商业化事业部以及会员事业部，其中社区事业部被认为是知乎一切事业的根源和基础；商业化团队主要负责知乎的品牌广告、信息流广告，以及相关的商业化活动；会员事业部，就是此前主打知识服务的知乎大学更名而来。技术实行中台制，也就是说知乎所有业务团队共用技术团队。
二、端和台
前后台和前后端是在不同维度的思考。端是在代码层面上的区别，台是展现形式上的区别。
前端：通俗的讲，对应项目里头写的 html，js，css 等代码，显示前端页面。
后端：通俗的讲，对应项目里头写的 bean，dao，controller，service 等业务逻辑代码，逻辑功能。
前台：前台中有前端和后端，由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
中台：中台是前台和后台的中间层，因为我们发现后台系统掌管着核心数据，随着企业业务扩大，后台系统应该保证其修改率降低稳定性提高，那我们业务拓展了，用户需求增加了该怎么办呢？
如果大量的业务逻辑直接在前台实现，不仅效率很低而且前台也变得臃肿不易修改，这就形成了烟囱式单体应用，IT 界有句话说：软件开发中遇到的所有问题都可以通过增加一层抽象来解决。中台是基于这样的思想，把前台臃肿的业务逻辑沉淀到中台，为前台减负，把后台众多的服务抽象到中台，为后台扩展。
后台：后台中也有前端和后端，由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
四、各个中台分类
数据中台：通过数据技术，对海量数据进行采集计算存储加工等工作，还要统一标准。数据中台把后台的数据统一好之后形成标准数据，再进行存储，进而为前台提供资源。
技术中台：在技术平台的基础上增加了业务属性。
业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台
五、中台之坑
1、团队组织的错误
许多团队管理者会认为增加人力是最好的，因为他们认为人员增多会带来效能的提高，但按照敏捷的思想，小团队工作效能更高。
2、业务拆分的问题
业务架构者对业务拆分不够清晰，会导致开发中造成到两混乱信息，是团队的管理和维护成本大大增加。
3、微服务的滥用
中台的建设是从下而上的，中台的需要是从上而下的。微服务不是靠量来取胜，是靠与实际业务的匹配来取胜，设置一个独立的业务单元，单独提供一个系统的微服务。举例来说：某个项目中台设计之初，拆出了 80 个微服务，20 个共同组件，应用服务器 90 台，人员维护的成本极高。优化以后，微服务缩减到 30个，应用服务器只需要 40台。
4、系统的过度设计
大部分微服务架构人们只能看到其结果却看不到其架构过程，但其实不是这样的，它既不是一步到位架构出来的也没有必要这么做，因为架构最基本规律就是解决当前的需求即可，它无需对没有出现的问题负责。
5、前台试错的迷失
小前台快速迭代，快速试错，但是成功必经是少数，试错单位越小，试错的次数越多，越容易被人们忽略，这样的前台可能就被架空了，怎么做呢？完善的管理制度加上前台团队人员得是高精尖人才，类似 supercell 试错后举办聚会（管理制度）和 cell 中成员都是顶级人才（人员选择）解决这一问题，supercell 还有个很大的优势就是公司本身人数就不多，这对管理起到了一定的帮助作用。
6、利益的划分
假使某个中台组件支持了几个不同的前台，结果到最后只有一个前台活了过来，其他都死了，那么每个团队最后的利益该如何分配呢，要知道这几个死了的前台死因可能不仅仅是产品的不合格，更多的可能是具有某种机遇成分。
7、组织架构的调整问题
此处包含组织架构调整太艰难该如何做，还有中台团队前期生存艰难的问题，都在在下面中台插曲中会讲到。
8、不同公司中台架构照搬
这是不可以的！这是因为架构这种东西必须得在公司原有的基础上调整，再一个就是每个公司业务逻辑，部门等都不相同，架构照搬是不实际的。
9、中台团队领导选择问题
该选择什么样的领导来带中台呢？给出一个最佳模板人选：技术出身，并且要十分熟悉公司的业务场景，超强沟通能力和沟通意愿，公司核心员工，在公司内部工作时间长，公司内部人缘广泛。照着这个模板寻找即可。
六、中台建设过程中常见景象
1、中台部门往往前期生存困难
这个问题可以说是组织架构演进过来的，各个公司前期对中台采用试点的方式，往往效果可能是中台部门起初总是在夹缝中求生存，这是因为中台部门既要满足所在公司多个不同前台的需求，指给中台提出了巨大的挑战，可能每次都难以达到前台的要求，再一个就是前台作为战场上直接杀敌的士兵具有更多的话语权，而中台则是后方强有力的补给支援，即使前台和中台权利级别一样，前台可能具备更多的话语权，这对中台的生存更加不利，中台极有可能在初期就流产。
因此初期必须得给中台的发展打一剂强心针，而不是任由中台发展。怎样才能让中台话语权更大？只有让它实实在在成为产品的必经阶段就行了，那如何做呢？公司可以强制规定，前台产品产出必须得经过中台这一阶段，并且放宽初期中台的产出结果，这相当于给中台进行权利的补充。
2、人员变动（包括调岗和辞退）
人员进行部门调整可以理解，但是人员辞退，这是因为比如偏底层的技术人员在垂直业务领域可能不再需要。这几年是互联网的寒冬，今年被大厂“辞退”的员工数量也蛮多，所以我怀疑是有一部分原因是大厂在建设中台，进行组织架构调整的结果，互联网的寒冬可能不是那么“寒”。
3、很多企业会进行数据中台和技术中台的建设
很多企业可能会先进行数据中台和技术中台的建设，然后业务中台可能是留有空缺。这是因为大部分公司对技术层面和数据层面划分较为清晰，做技术平台或者数据平台的团队可以立马拉过来继续做一个技术中台或者数据中台，对组织架构的调整较少，公司做起这两个中台较为容易。而如果要做业务中台就必定是要动组织架构的，动组织架构就意味着动利益分配，这其实就已经卡死很多公司了。再加上有的公司业务复杂的话，这又是一道屏障。
4、中台部门的消亡
中台迈过初期夹缝生存的难关后可能还面临一个凋零消亡的问题，这与各个公司的组织管理有关，如果一个中台部门不与前台部门建立良好关系，又没与后台部门建立良好联系，那么这个中台就危险了，不知那一天就会猝死在突发的利益冲突中。所以项目上可以安排中台和前台和后台专门对接，专门建立联系，这个得看管理者自己的管理策略。
5、中台团队的选人
企业一般开始会从前台调人，其中一定包含了能力极强的业务架构师角色，一部分技术通过招聘方式，还有一部分通过内部培养的形式。
6、先做再调组织还是先条组织再做
组织架构如何调整这一问题为何各大厂没有详细讲明？首先如果要做中台，那么组织架构是必调的，调整组织架构就意味着权利和利益分配的调整，一旦涉及到利益和权利的切分，这个话题就变的有意思了（怎么感觉和美国想禁枪一样），所以企业要是想改组织架构，那得在做每一步选择前都要慎之又慎，这不得不依托管理者能力，以及公司内部全员了解中台的重要性
喜欢就点个"在看"呗，留言、转发朋友圈
