程序员在工作中做两件事：挖坑和填坑。我的朋友王健最近有点烦。眼前这个坑有点大，可以用“天坑”来形容。中国和台湾留下的“天坑”谁来填？那么，“天坑”是怎么来的呢？这是同事间心照不宣的秘密，是一年前火爆的“商中台计划”留下来的。「商业中台计划」是??公司去年的明星项目。被总经理授予“突出贡献奖”。基调已经定下。谁敢说中台计划不成功？可是眼前的烂摊子怎么收拾？王知己摸了摸被上帝亲过的脑袋，很是无奈。他面临的问题是：1、“业务中心”的后续维护工作缺乏资源。一开始，成立了项目组，从各个业务条线抽调人员。项目启动后，团队解散。在领导眼里，中台项目已经“成功”，庆功宴连吃三顿。可以做哪些后续工作？项目完美结束，交由建筑部维护，算是一个愉快的决定。2、“业务中台”与业务分离，需求响应慢。王架构团队做的是基础架构，不是应用架构，缺乏对业务的理解。让一个基础设施团队来维护“业务中台”，显然是外行人的决定。从公司的角度来看，这是一个神奇的比例：中泰是一个架构，架构部当然要负责维护。3、明星项目的“魔咒”。这种现象在大公司很常见。去年的“明星”项目很可能是今年的“乞丐”项目。这很容易理解。“明星”项目是公司当年的战略方向，每年公司的战略方向都不一样。同一项目连续两年成为明星项目实属罕见。人往高处走，优秀员工争明星项目。去年的“明星”项目“业务中台”今年沦为“乞丐”项目，一点资源都没有。王继华所在公司“中台”建设存在的主要问题是：1、把中台当成一个技术项目来对待。笔者之前也写过这个问题，“我以为中台是技术问题，后来发现是组织问题，最后才意识到这个战略问题。”这是很多公司对中台的认知过程。它可以从数十万到数千万不等。中台被视为技术项目，所以机构一直没有配合改动。当中台项目完成，项目组解散，中台项目难免“烂尾”或“年久失修”。2、中台战略不明确。甚至可以说没有所谓的中台战略。如果有战略，它应该反映在组织中。解决的问题也不清楚。无论是降低成本还是提升体验，重点都不够明确。中台项目启动后，钱就撤了。众所周知，中台需要商业滋养，项目的启动只是一个开始。这种现象普遍吗？很常见。老K调查了20多家互联网公司，70%的公司在近两年内建立了中台，超过40%的公司采用项目制。和上面的案例很相似，面临的问题也很相似。王氏结构的公司是幸运的，至少中台项目是“成功的”。读者熊就没那么幸运了。“未完成”的中期谁来承担责任？Bear给我留言，跟我说了他们公司中台的现状：我们公司就是想做一个中台，一个saas企业应用软件提供商，先把微服务拆了，拆了之后没人管理维护，发现那我们做不了中台了，就这样东奔西跑，微服务的计算研发团队变成了运维。.努力奔跑~从小熊的描述来看，这是一个“自下而上”的中期项目。首先将SaaS架构拆分成微服务，有利于服务的抽取。这是中台架构演进中的普遍做法，技术方案并无不妥。拆解后发现不可能是中台。熊并没有说的很清楚。可能是技术问题，也可能是规划问题。什么都拆了怎么办？运行起来，微服务架构总是比原来的大单体更加健壮和可扩展，但维护成本也更高。Bear及其公司在中台建设中存在的问题是：1、中台建设是自下而上的。中台是战略层面的事情，只能自上而下进行组织变革、商业模式变革、技术变革。如果少了一个环节，没有联动，就很有可能失败。这个过程非常复杂，不是少数技术人员能够推动的。2、决心不够，投入不足。公司层面对中台建设的决心不够，导致资源投入不足。攻略我没怎么注意，所以我觉得你还是试试看吧，小范围跑，跑完再说。现在来看，还真跑不了。“中台没戏，都是骗人的东西，还好我不是韭菜。”老板暗暗观察，暗自窃喜，为自己的“英明决定”而自豪。这样的公司还有很多。一群技术人员认为中台是一个时髦的概念。看了几篇中泰鸡汤的文章，就撸起袖子干起来了。先上微服务，拆解成几百个独立的应用，再集成到大中型平台。拼装的时候出了点问题，拼装好了，但是多了几个模块，怎么拼都装不上。哈哈哈哈，跟老K拆IBM笔记本一样。技术人员自己挖坑，然后默默填上。在这个挖填过程中，神奇的事情发生了：简历很漂亮，项目中标了，工资也涨了。这意味着公司运气不好。总之，中台是一个非常神秘的东西。
