前一阵“中台，我信了你的邪”刷爆了朋友圈，以 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个人，啥都干，忙的不亦乐乎，其深度上面也难有沉淀，如果有团队帮你做好了搜索、做好了存储，你可能集中精力办有深度沉淀的事。

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

环球易购CTO乔新亮总，曾在苏宁科技集团副总裁期间领导了苏宁中台的建设。乔总分享道

当年苏宁建设中台的出发点是解决后端的SAP、前端的WCS性能差，不能很好支持业务快速发展的问题，目标明确。在这个目的驱动下，将功能从SAP、WCS中解耦出来，同时在建设过程中考虑了融合线上线下的架构、服务的重用。
苏宁从12年开始启动中台建设，13年上半年就初步建设完成，这一过程投入巨大。中国有这种决心的企业并不多，或者有这决心也没有这资金实力。这个建设成功的中台有什么作用呢？举一个例子：在2015年阿里苏宁相互入股，苏宁中台系统接入天猫的过程只用了7个工作日。
大道至简：企业需要的中台是什么？答案是：指挥官体系

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

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

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

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

说得土一点是：

客户视角端到端的效能提升
向客户提供一揽子服务，把简单留给客户，把复杂留给自己
满足不断创新业务的需要

阿里玄难对此的解释：
名称变化的后面还是思想变化。原来共享平台更多的被当做资源团队，承接各个业务方的需求，为业务方在基础服务上做定制开发。而业务中台的目标是把核心服务链路 (会员、商品、交易、营销、店铺、资金结算等等) 整体当做一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。
因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。就像我们最近上线的一个新业务 2 周完成，而按原来的模式可能要 2 个月。

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

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

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

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

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

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

本文转载自技术琐话公众号。

原文链接：https://mp.weixin.qq.com/s/rHe1nf3jrGxoyZmWt-R25g

创作场景

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