近些年，以阿里开始布道的中台化概念，在IT圈盛行一时，腾讯、京东等一线互联网公司随之跟进，甚至包括以华为，海尔为例的传统科技企业。一时间，IT界逢人必谈平台，整合，下沉，去中心化，中台化。
老规矩，我们先来灵魂三问：
1. 什么是中台？为什么要建中台？什么样的企业适合建中台？
2. 建中台的最大阻碍是什么？怎么保障顺利落地？
3. 中台的商业模型和盈利模式？
在回答这个问题之前，我们先抛一些带感的目标，看下中台化以后有哪些sexy的地方：
中台事业部年度营收（可能是公司内虚拟结算）：1个亿
业务创新效率提升200%
对用户的响应速度提升200%
大中台，小前台，避免重复造轮子，业务团队小而美
后台服务出口统一，性能、安全性、稳定性有保障，易用性统一
言归正传，我们来回答上面几个灵魂拷问。
有中台，必有前台和后台。我们先给这三个概念下一个定义。
前台：创新驱动，快速变化的端类产品，特点是用户响应力要求高。例如我们的web端，PC端软件，Android/IOS移动端产品。
后台：稳定可靠，变化周期相对较慢的资源管理类平台，特点是慢。例如我们的资产管理服务，交易管理服务，商品数据管理服务。
可以看出，前台和后台就像是两个转速差异很大的齿轮，非要凑在一起，必然会付出很大的成本。如果为了适配前台的需求，势必会对后台的稳定性造成极大的影响，如果要保证后台的稳定，前台的响应速度又得不到满足。
好在软件领域这么一句金句：任何的软件问题，都可以通过抽象一层来解决。
中台：以用户为中心的持续规模化创新，专为前端而生。
还是比较抽象，我们举一些业内的实际案例：
神策的数据中台，数据中台是一种特殊的业务中台，功能齐全，服务稳定可靠，涵盖了从数据收集，整理，清洗到应用场景化的完备功能，接入周期短，可以在极短的时间内构建业务自己的数据平台，总之一句话，确实是好用。使用的客户也越来越多。
Marketin，业内一家做营销中台的SAAS级平台，同样的，接入很快，服务稳定可靠，基本2周内就可以搭建起业务方的营销系统，功能涵盖了从客户到素材，活动，渠道，甚至还有对营销的经营分析。
中台战略中的“大中台、小前台“阵型，主要有这个四个特征：
1、团队协同效率最高。前端团队小而美，容易在最短时间内达成意见的统一和行动步调的一致。
2、对战机的把握更加敏锐。在前端的小团队正如一个小的创业团队，如何生存是团队首先考虑的问题，这样的环境会更容易逼迫出团队成员的能量和潜能对当前的战机的感知会更加敏锐。
3、调整方向更加快捷。分别投入200人和投入10个人去完成一个任务，当发现任务的方向有错误时，200人的团队调整方向所花费的时间和资源一定远超过10个人的团队。
4、一旦发现正确目标，全力投入扩大战果。这样的中台阵型，一旦前端的作战团队找到了正确的攻击目标，接下来一个远程呼唤，后端的中台炮火群会瞬间摧毁目标，这就是中台阵型发挥威力的最佳体现。
总之，“小前端、大中台”的中台阵型，是一种反应更加敏捷高效的组织形态，即以内部小前端去实现与外部多种个性化需求的匹配对接。这种更为扁平化的组织形态，已成为互联网时代越来越多企业组织变革的标配。
其实中台这个概念是2015年阿里首提，起源还要说到马云在2015年带高管到芬兰考察号称全球最成功的游戏公司supercell，这家公司牛逼在什么地方呢，我们来看一下数据：
2015年App游戏排行榜Top10，Supercell占据大半江山。
2015年员工150人，税前利润15亿美元。
员工人均贡献超过3.5亿人民币。
每款游戏研发团队2~5名员工，产品迭代速度非常快。
supercell为什么可以做到这么高的产品迭代速度呢，基本上几个人几周就可以做出一款新的游戏，然后快速推向市场，如果市场反响好，则迅速集中火力攻城略地，如果市场反馈不好，也可以迅速放弃，并且果断投入下一个游戏的开发当中。
原来supercell花了6年的时间，来沉淀游戏领域公共和通用的开发素材、算法，持续积累、迭代，每次需要开发一个新游戏的时候，所需要的素材、算法基本是现成的，开箱即用。
2016年，腾讯以86亿美元收购了supercell84.3%的股权。
中台在概念上可以分为技术中台，数据中台和业务中台。
技术中台的本质：流程自动化。例如我们的中间件，IAAS平台。
数据中台的本质：数据资产化。例如神策。
业务中台的本质：应用场景化。例如常见的交易中台、营销中台。
很多人会觉得，中台是不是大公司，一线互联网公司才能玩的东西，其实不是，公司适不适合建中台，需要问自己3个问题：
互联网核心能力是否存在短板？
跨业务或项目的共享做得够不够？
业务创新多不多，需求变化多、快？
如果都满足，那不用怀疑，你现在的公司适合建设中台。
互联网的思维，强调的是速度，中台化的价值可以从3个方面来讲：
对用户的价值：满足用户对快速响应力的诉求
对业务创新的价值：快速试错，快速迭代
对成本和效率的价值：解决重复建设的问题，提升业务创新效率
如果业务创新的成本是50人年，可能会犹豫，但如果是10人月呢？
如果研发的成本可以降低30%，效率提升50%？
如果对用户的响应速度可以提升100%？
如果新的创新业务，新的市场，只需要一个月甚至更短，机会？
那中台化建设和业务方是什么样的关系呢？
中台化本质上是一种架构，一种应用场景化的架构，架构无法决定市场的成功或者失败，但是作为土壤，可以不断孵化新的物种。架构不是解决该做什么的问题，而是解决创新效率的问题。
但是做中台，一定要贴近并了解业务。在大中台小前台的战略中，业务会下沉到中台进行沉淀、积累和迭代。业务方就是中台的直接用户，如果中台都不了解业务，如何能让业务方用得爽，并且持续将业务持续下沉到中台，久而久之，业务方会觉得还不如自建，中台也会成为在业务方之间夹缝中生存的部门，失去中台与业务平等对话的权利。我甚至觉得，中台团队甚至该有固定的接口人坐到业务团队中，参与业务方的业务讨论会和需求讨论会，如果团建的时候业务方不请你，中台就危险了。
我们来谈一下中台化建设中两个敏感的问题：组织架构和业务切割。
很多出来分享中台建设的专家都不愿意谈组织架构的问题，谈组织架构意味着要动利益和金钱，肯定会有很多矛盾和冲突。建中台的钱该谁出，中台的人该从哪儿来。
阿里早期的共享事业部（中台的前身）也曾遇到类似的问题，早期从淘宝的研发团队中成立了共享事业部，抽象了电商中公共的商品，交易，评价，物流等平台，用于支撑淘宝和天猫的发展，但是业务方都不愿意接入，共享事业部再怎么加班也无法满足两个团队的需求，无法具备与业务的平等对话权，慢慢得成为夹缝中生存的存在。
建中台，一定是自上而下的，一定要是公司中具备足够话语权的VP来牵头，比如阿里的CTO张剑锋（行癫），京东是徐雷，我个人认为，中台的推行，高层领导的决心和意志非常重要。
建设中台不能天天喊口号，如果既不敢调动资源，也不敢调整组织架构，还整天担心对前台业务的影响，难以承担失败可能带来的风险，这很难成功。中台承载的是企业最核心的业务能力，最核心的差异化竞争力，是战略层面的事情，没有战略层面的决心和耐心坚持下来就很难看到成果，有的时候，中台建设确实也需要“因为相信，所以看见”。
关于业务切割，业务方都有私心，能否放弃对业务的完全控制权，换回来的是更低成本、更高效率、更高质量的服务，更强的能力，更安全的系统。
可以理解，在业务团队和在中台，优先级肯定不完全一致，但是我们要相信我们的中台团队，要从自建轮子，自建烟囱，改为向中台提需求。同时，中台团队也要从版本模式，项目模式改变成迭代模式和运营模式，持续迭代和业务创新，真正匹配业务方的响应力诉求。
中台和前台的业务边界需要明确，但是又很难明确，所以中台的业务架构师要沉到业务方，和业务团队一起讨论业务和技术方案。让前台可以放心将后背交给中台团队，转而聚焦到业务的发展上。
一个中台团队，一般我们会按领域分成业务中心，每个业务中心都会包含业务架构师、产品、研发、数据、运维，当然，在人力紧张时，部分资源可以共用。但是不建议中台需要的研发资源还需要分部门或者跨中心调用，无形中给本就容易在夹缝中生存的中台补上一刀。
最后我们来聊一下中台的商业模式和盈利模型。
中台团队的成本一般包括，人力成本，运维成本，第三方资源成本，中台的产出可以是SAAS级平台，接口调用，数据服务，对于类似于个性化推荐，还可以直接产生盈利。
我们以业务方的接口调用量来计费为例，当然一般在公司内部不可能实际结算，大部分公司会采用虚拟结算。业务方使用中台服务，产生价值，向中台付接口使用费用理所应当，同时对中台团队，也更能体现研发的实际价值。
虚拟结算模型：
业务方结算金额 = 当期服务调用次数 * 服务调用单价
当然，中台也可以直接售卖SAAS级平台，比如神策，在中台的盈利点上，上图已经做了说明，就不一一列举。
在向业务方收费的同时，我们对中台还是要有考核机制。
中台的绩效考核会考虑服务稳定性、业务创新、服务接入量以及客户满意度四项指标。其中，服务稳定是重中之重，这部分的考核比重会占整体的 40% 左右；适当允许一定数量因为创新业务上线带来的事故，鼓励团队创新，这部分可能会在 25% 左右；吸引更多前端业务方接入，一般会占 20% 左右，剩下的是客户满意度。
最后，中台的推动者，一定要有大格局，大气魄，把中台的建设推到战略高度，沉淀公司的核心能力，并解决重复造轮子的问题，提升业务创新效率。中台的建设是星辰大海。
