中台的问题，是技术的问题，还是人的问题

正文开始

【与数据同行】已开通综合、数据仓库、数据分析、产品经理、数据治理及机器学习六大专业群，加微信号frank61822702 为好友后入群。新开招聘交流群，请关注【与数据同行】公众号，后台回复“招聘”后获得入群方法。

Photo from Pexels

风乍起，吹皱一池春水

前一阵“中台，我信了你的邪”刷爆了朋友圈，以 36氪的影响和富于讲故事的叙述，让很多做过或者没做过中台的参与到中台的争论中。该文这样开头：

“中台”概念火了一年多后，露出它狰狞的一面。

多位行业人士对36氪说，由于盲目上中台，深圳一家女装企业的CIO 被开除；在华南一个有几十人的CIO（首席信息官，是Chief Information Officer的缩写）社群内，2019年由于中台项目失误导致离职、调岗的高管就有十几个。

中台，我信了你的邪

文中的记忆点大概有

1、乙方承诺什么都能干

2、为某公司提供数据中台服务，遭到了电信负责人的强烈反对，“CIO 和电商负责人拍了桌子”，最后，这位电商负责人摔门离开

3、“中台困惑”

对“中台”一度感到困惑的还有王健。作为软件及咨询公司ThoughtWorks 的首席架构师，在 2017 年底，当王健为一家国际 500 强公司客户服务中台项目时，他被客户问住了：怎么证明他所展示的中台架构是正确的？王健当时哑口无言，他心里也犯嘀咕：阿里的中台看上去是成功了，可它的成功仅仅是因为中台吗？

中台，我信了你的邪

为什么“中台”让人困惑？中台是技术的问题，还是人的问题？中台要解决什么问题？本文尝试聊一下。

不是“中台”不行，是你不行

李锟老师这样说，“橘生淮北则为枳。再好的方法，没有好的人落地，都会变成闹剧。和10几年前一窝蜂上ERP类似......关键是人的问题，里皮对国足也无能为力。”

换句话说如果36氪说的某些CIO因为中台实施不利被开了，那么大概率十几年前上ERP被开也是类似的人，无非故事又轮回了一遍，太阳下无新事。

先说一些还不错的案例吧。 

昊哥前一段还在货车帮的时候，就推动了满帮中台的建设。大部分业务性的技术研发团队已经分到各业务线，平台部门空有想法，要人没人，咋办？昊哥采取了大概几种思路：

1、获得老板支持，和业务条线一号位沟通

2、组织方面，部分平台型研发人员集中到中台团队，大部分业务型研发仍在业务条线

3、为业务负责， 向业务条线大老板承诺上线XX中台之后的效果，可衡量

4、仍在业务条线的架构师、研发TL如何能遵守中台整体的打法步骤呢？毕竟业务为王、屁股意识、抢地盘不鲜见。我大致理解昊哥采取了2个骚操作。一是这些架构师/TL是双线汇报，二是在架构规划、岗位层级、晋升考核等采取了在昊哥团队集中。这样对于一个具体的业务板块来讲，为了支持业务，跟上业务是必备基础“结果”，但是如果只固守一隅，见树木不见森林，不容易获得更好的团队发展和晋升机会。 比如你NB哄哄的攻坚的东西，可能在你的兄弟团队已经成熟了， 你还守着自己的轮子造吗？

有时候，造轮子的根本原因在于供需关系不清晰，组织没有调优，造的轮子都是“破铜烂铁“，3个团队，一个团队3个人都在造烂铁，如果把他们集中在一起就有做一个不错东西的可能性；我经常思考团队合作。所谓合作，帮忙是一时的，毕竟都有自己份内的事情要做。长期的合作是目标一致，在各取所需的局面下找价值链接。 你的团队10个人，啥都干，忙的不亦乐乎，其深度上面也难有沉淀，如果有团队帮你做好了搜索、做好了存储，你可能集中精力办有深度沉淀的事。

在把烟囱型业务收口平台化的过程中，可以逐步实施而非一刀切。每一步都可能有不同的协同团队，要回答我帮到业务什么。

当年苏宁建设中台的出发点是解决后端的SAP、前端的WCS性能差，不能很好支持业务快速发展的问题，目标明确。在这个目的驱动下，将功能从SAP、WCS中解耦出来，同时在建设过程中考虑了融合线上线下的架构、服务的重用。 

    苏宁从12年开始启动中台建设，13年上半年就初步建设完成，这一过程投入巨大。中国有这种决心的企业并不多，或者有这决心也没有这资金实力。这个建设成功的中台有什么作用呢？举一个例子：在2015年阿里苏宁相互入股，苏宁中台系统接入天猫的过程只用了7个工作日。

大道至简：企业需要的中台是什么？答案是：指挥官体系

中台是如何提出的？

网传的一种说法，是阿里高管15年参观世界上最成功的移动游戏公司supercell，这家典型的小团队模式进行开发的公司，可以最快的推出游戏内测版，如不受欢迎，可以迅速的放弃这个产品再进行新的尝试，期间几乎没有管理角色的介入，团队失败后，不但没有惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。它的核心竞争力就在多年的游戏研发中积累了非常科学的研发方法和体系，也就是中台能力。以至于很多模仿者都无法替代。

第二个故事。美军在二战时，以军为单位作战；到了越战时，以营为单位作战；到了中东战斗的时候，以7人或者11人的极小班排去作战，这是今天最灵活的军事组织，也是核心竞争力和打击能力最强的一个组织。而美军之所以能灵活作战，敢放这么小的团队到前方，是因为有非常强的导弹指挥系统，有非常强大的中台能力，能支持这样的小团队快速做判断，并且引领整个打击。

第三个故事。中台是规模化业务发展的必然，这里的中台可以默认为“业务中台”。

高大上的提法，如上图，在小前端各类业务创新的时候，能快速把握战机，调整方向快，炮火群（类比中台）支持特种小分队（类比小前端）。

说得土一点是：

u客户视角端到端的效能提升

u向客户提供一揽子服务，把简单留给客户，把复杂留给自己

u满足不断创新业务的需要

阿里玄难对此的解释：

名称变化的后面还是思想变化。原来共享平台更多的被当做资源团队，承接各个业务方的需求，为业务方在基础服务上做定制开发。而业务中台的目标是把核心服务链路 (会员、商品、交易、营销、店铺、资金结算等等) 整体当做一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。

因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。就像我们最近上线的一个新业务 2 周完成，而按原来的模式可能要 2 个月。

当然大中台的建设思路，对系统架构提出了更高的要求。必须对系统进行重新设计，实现「业务逻辑和平台逻辑分离，不同业务之间的逻辑隔离」，才能让前台业务方可以自主定制开发。当然团队定位不一样，结果不一样，团队的成长也完全不一样。所以说共享跟做中台有很本质的区别。

进一步阅读，参见：淘宝和天猫背后，阿里系原来还有这样一个不为人知的神秘组织

企业怎样判断，我这个中台到底做的好还是不好？

这里借用谢纯良的采访，建中台首先回答支持业务的效能问题。

谢纯良：第一个角度，我打一个比方，我曾经跟很多 CEO、CTO 去聊，我建议他做一些简单的判断，我说你在没有建中台之前，很多业务方提的需求到了你这里，你都会说，这个我做不了，系统不支持，还有一种回答是，这个可以做，等我六个月或九个月。如果你的中台建设得不错，同样的问题，你大概率会说：这些需求没问题，都能做，大部分都能做了，从说“no”变成说“yes”。另一个关于周期的回答，“这个可以做，给我一周或两周”，从几个月变成了几周。

第二个去判断的角度是，如果你的 IT 团队，假设总共一百个人，如果 80% 的人都在研究业务服务的能力怎么去构建，我觉得这个中台建设就成功了。

InfoQ 采访到了阿里云中间件架构总监谢纯良，听他分享关于阿里巴巴中台建设的实践与思考。

进一步阅读，参见：阿⾥巴巴技术总监全解中台架构19页ppt：中台是一把手工程

进一步探讨， 应该以终为始的看中台。灵魂三问：

一、你要解决谁的什么问题？ （what）+如何衡量成效？

二、为什么要解决？（why）+如何定义优先级？

三：如何解决，步骤如何？（how）

我们用这个“灵魂三问”的逻辑来看乔总的思考：

你要解决谁的什么问题？ （what）

中台要建设成为一个面向市场竞争，连接、协同企业内部能力的作战指挥体系，也就是指挥官体系，从而帮助企业快速响应市场变化，赢得市场。

为什么要解决？（why）

 首先要搭建一套关注用户体验的数据体系，这非常重要。如果管理者看不到企业经营管理活动各个环节用户的体验数据，何谈指挥决策？有了这些数据，内部管理才能升级为不仅仅管控，还能实时指导经营决策，基于用户体验数据驱动内部管理持续完善。

然后， 在单个业务单元（事业部）内，由用户体验数据驱动内部经营体系更完善，让协同更顺畅，这是建设事业部级别的指挥官体系。这可以类比军队里一个军种（比如陆军）的作战指挥体系更完善了。

最后，如果企业已经升级到下一个阶段，开始建设企业级别的指挥官体系。就如同美军现在的水平，拥有能够支持多军种实时协同作战的C4ISR体系。在这个阶段，可以并行考虑企业级别的架构解耦、服务重用。不过千万不要本末倒置了，完全奔着架构优化去做了，最后一定是一地鸡毛。

如何解决，步骤如何？（how）

其实上面也回答了， 从产品的用户体验数据体系，到事业部级别的指挥官体系，再到企业级别的指挥官体系。

如何衡量阶段性目标达成？

是一个值得深思的问题，我任务应该要有简单直接的数据量化衡量为好。

中台解决效率的问题，反过来，解决效率的问题必须上中台吗？

经常有朋友这样的问题：

降低开发成本提升上线效率，除了建中台是不是还有其他途径？降低多少算降低，平台也能降低成本提升上线效率，那平台是不是中台？

  从平台到中台【上】 曾解释过关于平台，中台的观点，这里摘录提炼如下：

平台化架构的思路，一般是通过把类似多个烟囱沉淀为中台来提供配置化能力达到提升效率的目的。

我们以一个5人研发团队为例来说明一下。起初团队一个产品都没有，5个人1个月干出一个简单版本的红包系统；几年之后团队增加到10人，但手头要维护10个系统。那么平均人手一个系统，这时候，又来了2个新业务，团队派出3个人去干，大约要干4个月，严重不符合前端业务的响应预期。第二个问题是重复建设，同类烟囱系统中80%的功能是类似的，从数据库模型到主要业务逻辑，都是copy-paste加补丁，一步留神又踩到一个坑。第三个问题是维护成本高。日常升级包、咨询支持服务，团队疲惫不堪。基于此，80%甚至90%的共性问题，能不能抽象出来呢？核心领域模型是否可以是稳定的呢？从下图可以看出，这是可以做到的。

在既要支持不断出现的各种业务，又要建设新平台的纠结权衡之后，我们启动了卡券平台化项目。建设路径是存量业务继续使用烟囱架构，但新业务随着新平台一起接入。第二步逐步迁移存量业务，实现烟囱系统的下线。如下图所示，卡券平台对前端业务提供统一的能力露出，由能力组装编排内部服务。研发规则运营、统一后台管理服务等。

总结下来，平台化架构有以下好处，1是快速支撑、响应业务。2是抽象共性，边界清晰。快速支撑，响应业务是以终为始的出发点。架构如果不服务业务，再高大上都是扯淡。技术不是炫技，要服务商业。再谈谈抽象共性的问题，业务平台化要解决业务共性问题，比如天猫、淘宝都有各类营销活动。那么就抽象出一个营销平台来管理营销活动、营销工具的整个的生命周期管理。并提供给前端业务使用。

平台化架构之路，支撑业务的效率可能达到了几倍，是不是万事大吉了呢？

又有新的问题出现。以电商平台为例，支付、会员、营销、产品都形成了对应的共享服务，但是对于一个新的前端业务，它要去理解各平台共享服务的职责，并协同，则并非易事。如果还涉及安全、合规、核算等，则涉及的团队更多。那么就有一个问题，已经搭了淘宝、天猫，要做聚划算需要多少人月？要做天猫国际需要多少人月？平台化的架构是尽量的走向了“各人自扫门前雪”，但对于创新的支持力度不足。互联网业务随时在试错，一些创新业务方期望是1-2周的期望上线，平台化发展动辄数月严重不能满足这样的诉求。

我们不妨去回顾那些在无数次发生过的似曾相识的场景，如下图所示：

一个线下支付的需求在对应研发团队是排期1周、研发2周，目标期望1个月完成上线。涉及到支付、金融交换、产品、风控等各团队，虽然都是1-2周的研发，但是实际整体上线可能是2个月。其间假使涉及到20个system，按最小单位1个system 1个开发1个测试算，涉及到40个人员的沟通复杂度，还没有算可能的运营人员，产品经理。同时在系统测试、联调阶段如果还遭遇若干环境问题，其效率可想而知。

总结，平台化架构由于缺乏对于前端业务一以贯之的端到端的支撑能力，平台与平台之间随时存在gap。平台化架构按照康威定律，必然是几个平台，几个团队，涉及到巨大的沟通成本而导致协作困难。平台化架构在数据化运营上存在短板，往往需要把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值。

中台化其实是平台化之后的自然阶段，它主要是带来了：

• 提供完整解决方案而不是暴露 API，给业务带来的快速创新和试错能力的提升。

• 通过数据统一治理和应用，给业务带来数据驱动的运营能力的提升。

• 通过解决信息获取成本高，系统互联互通成本高的问题，给企业带来组织效率的提升。

这里要辩证看待公司的形态。

以我了解一家A公司为例。该公司有电信的业务，有校园网的系列产品，也有若干项目；同时还有一些对日外包的项目。A公司是否需要中台？首先问要解决哪些哪些问题？ 对日外包是各种各样的交付，而校园网产品本身是否把产品迭代做好就行了？

也有人提到多渠道的问题，问题还是多渠道问题的效率问题是不是当下最大需要解决的问题，如果不是，恐有过度设计问题。

中台是技术的问题，还是人的问题？

这个问题，是大家关心的问题，但其实是一个伪命题。

借用灵魂三问的逻辑：

一、你要解决谁的什么问题？ （what）+如何衡量成效？

二、为什么要解决？（why）-包括优先级

三：如何解决，步骤如何？（how）

组织应该怎样调整，是矩阵式还是中台内聚，如何解决“业务部门老大”不听号令的问题，或者“CIO 和电商负责人拍了桌子”都是这个层面的问题。

首先要回答为什么要在此时此刻解决？竞争压力？未来趋势？生存问题？

其次要回答谁为中台建设负责，他要解决的问题是什么？给多少时间？

然后回答需要什么样的组织配套？

经常看到这样的信息，“老板让我搞一个技术中台，我不知道如何下手”，是老板傻还是你傻？ 要解决什么问题不需要对焦的吗？

中台能完全交给乙方做吗？

不能。你听说过雇佣军主导一个帝国战役的吗？中台建设注定是甲方主导的。甲方自己没有想清楚，千万别启动，否则就是劳民伤财。具体的平台和工具可以交给乙方公司做，前提是适合自己的公司。美军也没有什么都自己建设，照样全世界惹事。

乔总回答深得我心。甲方始终是中台建设的主导者，包括ERP、CRM等等莫如是。乙方可以在甲方定义问题的基础上去解决问题；丙方（咨询）可以帮助甲方寻找问题，定义问题，包括给解问题的方向。但问题还是甲方的。而且中台建设不能一蹴而就，是一个持续构建的过程。某记者说，中台如今走到了价值验证的关键路口。谬矣，中台提出不止一年，价值验证是持续的过程，可以说每一年都是“你”价值验证的关键路口。还是回到，如何定义价值期望？如何实施？如何验证的逻辑上来。

《如何构建滴滴出行业务中台》一文曾经分享过构建业务中台的四个原因：

2015 年末，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。随之，滴滴启动了中台战略整合业务系统。

决定构建业务中台主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通。

专业深度：由于是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多的工程师。每个团队都是用最快速的方式构建流程，所以技术很难做深。这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。

人力资源：从原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。但工程师的薪资都非常高，招聘大量工程师来做同样的架构，研发成本高昂。还有些时候，即使你愿意花钱，也招聘不到合适的人。

用户体验：流畅度、稳定性、扩展性、界面、交易流程等都是影响用户体验的重要因素。在当时的组织结构和研发情况下，会出现业务的应用场景不同，交易流程却相同的问题，这样很影响用户的体验。

全局打通：所有业务本质都是出行，出行本质具有协同效应。但在各自独立发展情况下，业务间完全没有协同性，在构建中台过程中，我们可以逐步把协同性建立起来。

假设一位不懂技术的老板，如何不被这四点唬住呢？只需要这样来提问：

1、你说中台更稳定了，那么系统可用率从现在多少提升到多少？

2、不管什么扩展性也好，平台能力复用也好，我可以简单理解为大规模的复用之后干相同的事情效率提升了，我要衡量提效几倍或者现有团队在完成项目之后应该释放多少人可以去做别的活？

3、业务协同性，我期望业务侧给我一个衡量指标，协同的目标是不是为了更大的成单率？

4、用户体验，如何衡量？从用户体验数据监测角度、客户服务咨询问题的角度来定义。

欢迎加入《与数据同行》社群！

猜你想看更多的文章👇