中台到底是个什么鬼？（内含案例）
2019/3/4 7:00:00王健 正略管理评论
作者：王健
来源：公众号“健荐”
从去年开始，好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起，给我带来了很多的困扰、思考与收获。
故事的开始源于去年的技术雷达峰会，我在会上做了一场关于平台崛起的主题分享(《The Rise of Platform》)，这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起，以及分享从基础设施到人工智能等各个领域不断涌现的各类平台，以及平台化对于软件开发人员及企业的影响。
记得当时在做演讲彩排的时候，有同事就提到过，在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空，如果你提“中台”大家会更熟悉一些。
而这也是我第一次听到“中台”这个词，原来除了我们熟悉的“前台”和“后台”外，居然还有个“中台”这样一个神奇的存在。
那…… 中台到底是什么？会不会又是另一个Buzzword呢？这个从名字上看像是从前台与后台中间硬挤出来的新断层，它与前台和后台的区别和界限到底在哪儿？什么应该放到中台，什么又应该放到前台或是后台？它的出现到底是为了解决什么问题呢？
从那时开始，一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天，随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨，终于可以坐下来回顾一下这一年的实践与思考，再次试图回答这些问题，并梳理成文，与大家交流探讨。
中台迷思
到处都在喊中台，到处都是中台，中台这个词在我看来已经被滥用了。
在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
看完本篇你就会理解，上边的这几类“中台”划分还是靠谱的，更多我看到的情况是大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。
中台到底是什么？它对于企业的意义到底是什么？当我们谈中台时我们到底在谈些什么？
想要寻找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个 ?度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度，来思考中台的价值，来试图反推它存在的价值。
所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：
企业为什么要平台化？
企业为什么要建中台？
第一个问题：
企业为什么要平台化？
先给答案，其实很简单：
因为在当今互联网时代，?户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
不断快速响应、探索、挖掘、引领?户的需求，才是企业得以?存和持续发展的关键因素。
那些真正尊重用户，甚?不惜调整?己颠覆?己来响应?户的企业将在这场以?户为中心的商业战争中得以?存和发展；?反之，那些在过去的成就上故步?封，存在侥幸?理希望?户会像之前一样继续追随?己的企业则会被用户淘汰。
很残酷，但这就是这个时代最基本的的企业?存法则。
平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：?户响应力。这种能力可以帮助企业在商战上先发制?，始终抢得先机。
可以说，在互联网时代，商业的斗争就是对于用户响应力的比拼。
又有点远大空是不是，我们来看?个经典的例子:
说起中台，最先想到的应该就是阿?的“?中台，?前台”战略。阿?通过多年不懈的努力，在业务的不断催化滋养下，将?己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
海尔也早在?年前就已经开始推进平台化组织的转型，提出了“平台?营体?撑?线?营体”的战略规划和转型?标。构建了“?单合一”、“?户付薪” 的创客文化，真正将平台化提?到了组织的?度。
华为在几年前就提出了“?平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象地诠释了大平台?撑下小前台的作战策略。这种极度灵活又威力巨?的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火?支援。
可?，在互联?热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。
而平台化恰好可以助力企业更快更好地做到这些，所以这回答了第一个问题，企业需要平台化。
第二个问题：
企业为什么要建中台？
好，想明白了第一个问题，为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
好，这就引出了我们的第二个问题：企业为什么要建中台？
先定义一下前台与后台
因为平台这个词过于宽泛了，为了能让大家理解我在说什么，我先定义一下本篇文章我所说的前台和后台各指什么：
前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源(数据+计算)，例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
后台并不为前台而生
定义了前台和后台，对于第二个问题(企业为什么要建中台)，同样先给出我的答案：
因为企业后台往往并不能很好地支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。
但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往?法被前台系统直接使用，或是受到各类限制?法快速变化，以?持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的?轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；?后台由于?对的是相对稳定的后端资源，?且往往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。
所以，随着企业业务的不断发展，这种“前台+后台”的?轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大，因为后台修改的成本和?险较?，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个?泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“?户响应?”，用户满意度降低，企业竞争力也随之不断下降。
对于这样的问题，Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次)，不同的层次采用完全不同的策略。
而Pace-Layered Application Strategy也为“中台”产生的必然性，提供了理论上的支撑。
Pace-Layered Application Strategy
在这份报告中Gatner提出，企业构建的系统从Pace-Layered的?度来看可以划分为三类: SOR(Systems of record )、SOD(Systems of differentiation)和SOI(Systems of innovation)。
处于不同Pace-Layered的系统因为?的不同，关注点不同，要求不同，变化的“速率”自然也不同，匹配的也需要采?不同的技术架构，管理流程，治理架构甚至投资策略。
前面章节我们提到的后台系统，例如CRM、ERP、财务系统等，它们?多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核?可追溯单据(例如财务单据，订单单据)为主要?的。它们的变更周期往往比较?，?且由于法律、审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低、变化成本高、变化?险高、变化周期?，?法满?由?户驱动的快速变化的前台系统要求。
我们又要尽力保持后台(SOR)系统的稳定可靠，?要前台系统(SOI)能够?而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。
正当陷入僵局的时候，天空中飘来一声IT谚语：
软件开发中遇到的所有问题，都可以通过增加?层抽象?得以解决!
此，?声惊雷滚过，“中台”脚踏七彩祥云，承载着SOD (Systems of differentiation) 的前世寄托，横空出世。
我们先试着给中台下个定义：
中台是真正为前台而生的平台(可以是技术平台，业务能力甚至是组织机构)，它存在的唯一目的就是更好地服务前台规模化创新，进而更好地响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的?组“变速?轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像Pace-Layered中的SOD，提供了比前台(SOI)更强的稳定性，以及?后台(SOR)更高的灵活性，在稳定与灵活之间寻找到了?种美妙的平衡。
有了“中台”这?新的Pace-Layered断层，我们既可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应?；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”?援。
所以，企业在平台化的过程中，需要建设自己的中台层(同时包括技术中台，业务中台和组织中台)。
阶段性小结
思考并回答了文初提出的两个关于中台价值的核心问题，解决了我对于中台产生的一些困惑，不知道对你有没有启发，让我再来总结一下：
1. 以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能?和规模化创新能力，是互联?时代企业综合竞争?的核?体现。平台化包括中台化只是帮助企业达到这个目标的?段，并不是?标本身。
2. 中台(?论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应?困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的?盾，提供?个中间层来适配前台与后台的配速问题，沉淀能?，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应?。
3.所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于?户的响应?才是最重要的。?平台化或是中台化，只是恰巧走在了了这条正确的?道上。
中台到底长啥样？
数据业务双中台
提起中台，绕不开也是最先想到的应该都是阿里巴巴的数据业务双中台。毕竟阿里的“大中台小前台”战略人尽皆知，其威力也是显而易见的。
以阿里这么大的体量，经过了这么多年的厮杀，在互联网快速迭代创新的竞争环境中，仍然可以保持快速迭代创新，上演了一场接一场现实版的大象跳舞，中台战略的成功居功至伟。
(摘自《企业核心业务数字化转型最佳实践》)
阿里的数据业务双中台堪称经典，上图摘取自钟华(古谦)于刚刚结束的2018云栖大会《企业核心业务数字化转型最佳实践》分享。
从图中可见，阿里中台主要体现为由业务中台和数字中台并肩构成的双中台，并肩扛起了所有前台业务。
业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。
数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
业务中台与数据中台相辅相成、互相支撑，一起构建起了战场强大的后方炮火群和雷达阵。
移动中台
同样来自于2018年云栖大会杭州站，在移动研发平台EMAS专场上，阿里巴巴高级技术专家泠茗带来的分享中就为我们揭开了阿里移动中台的面纱。
(摘自《数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器》)
可见阿里的移动中台是构建在业务&数据中台之上，为更好更快地利用中台能力、快速迭代移动端产品，又生生地挤(或是说沉淀)出了一个新的中台层。
移动中台建立在业务数据双中台之上，更靠近移动前端战场，我们可以类比成战场上的坦克群，近距离支撑一线战场。
技术中台
大中台小前台，并不代表前台不重要，相反，大中台的建设就是为了更好地服务好小前台，大中台的威力也需要靠小前台的引导才能真正发挥和体现出来。
就像是深入敌后的前台特种部队如果定位不到敌人的精确位置，就算有再强大的水陆空中台炮火群，也只是一群废铁而已。
大中台小前台战略，其实是给小前台的构建提出了更高的要求，就像我们对于特种兵的要求也比一般的士兵高出很多一样。
那如何快速构建出短小精悍，武器精良，战斗力十足的特种兵前台应用，充分发挥和释放出中台炮火群的威力，就需要依靠这里提到的技术中台。
(摘自《阿里技术手册-研发篇》)
技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台数据中台的快速建设。
如果将业务数据双中台比喻成强大的中台炮火群，可以直接对敌人进行进攻。那技术中台的作用就有些间接，有点像前台特种兵身上各种先进的武器装备。精良易用的武器装备，可以在大幅缩短前台特种兵的建设周期的同时大幅提高单兵作战能力，令敌人胆寒。
研发中台
软件开发是一项工程，涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注与开发效能管理的平台叫做研发中台。
如果说技术中台为前台应用提供了基础设施重用的能力，那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。
(摘自《阿里技术手册-研发篇》)
上图摘自阿里的技术手册，展示了阿里的效能事业部一直致力于构建的阿里研发效能平台，有兴趣的同学可以去了解一下阿里自家的云效平台。
(DevOps云平台)
总之，开发效能是构建前中台应用过程中必不可少的重要一环。这方面的实践和能力通过沉淀，结合快速开发框架平台，例如微服务开发平台，就形成了企业的研发中台。
如果将技术中台比喻成前台特种兵的武器装备，那效能中台就是前台特种兵的管理训练基地以及可以快速将战士运送到一线战场的机动运输部队。
组织中台
以上无论是业务中台、数据中台、技术中台、研发中台……都是围绕技术展开的，也是企业在中台建设中最关注的方面。
但真正实际经历过几次企业级中台的建设后，我深刻地体会到：围绕技术展开并不是基于在中台构建中技术的重要性，而是因为技术的改进相对简单。
而中台建设真正困难的是组织上的重构，这往往是大家有意无意避而不谈的。
中台战略的成功、能否实现技术架构与组织架构的匹配，是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部，海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。
举个实际的例子，在很多企业中一个新项目的启动，从筹划到申请经过层层审批和评审，短则一两月，多则需要几个月的时间。要知道在当前所处的互联网时代，几个月都够人家App都上线了。
(摘自《释放潜能-平台型组织的进化路线图》)
为了真正解决企业创新在组织层面的摩擦和阻力，构建真正的平台型组织。《释放潜能-平台型组织的进化路线图》提出了上图这样一个平台型组织的组织结构。
组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估(项目甄别)、投资管理、投后管理(孵化与风控)，真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新。
如果还用前边军队的比喻，那组织中台是什么呢？可能你已经想到了，对，就是战场指挥部。
小结
列举了这么多各式各样的中台，最后都扯到了组织层面，是不是有种越听越晕的感觉，是不是感觉什么东西加个“中台”的后缀都可以靠到中台上来，估计很快就会看到例如AI中台，VR中台，搜索中台，算法中台……对了，算法中台已经有了……
让我们引用一段阿里玄难在接受极客公园采访时提到对于中台的一段我非常认同的描述：
本文中我们一直提到的一个词就是“能力”，从玄难的这段采访也可以看出，在阿里“能力”也是中台的核心。
甄别是不是中台还要回到中台要解决的问题上，我认为一切以”以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台：
业务中台提供重用服务，例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
数据中台提供了数据分析能力，帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；
移动及算法中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
技术中台提供了自建系统部分的技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
研发中台提供了自建系统部分的管理和技术实践支撑能力，帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
组织中台为我们的项目提供投资管理，风险管理，资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。
所以，评判一个平台是否称得上中台，最终评判标准不是技术也不是长什么模样，最终还是得前台说了算，毕竟前台才是战争的关键，才是感受得到战场的残酷，看得见用户的那部分人。
前台想不想用，爱不爱用，好不好用，帮了前台多大的忙，从中台获得了多大的好处，愿意掏出多少利润来帮助建设中台，这才是甄别中台建设对错好坏的唯一标准。 对于中台来讲，前台就是用户，以用户为中心，在中台同样适用。
—THE END—
责编：Agnes
http://weixin.100md.com
返回 正略管理评论 返回首页 返回百拇医药