程序员上班就两件事：挖坑、填坑。
我的朋友王架构，最近有点烦。摆在他眼前的这个坑有点大，可以用“天坑”来形容。
中台留下的"天坑"，谁来填？
那么，“天坑”怎么来的呢？一年前风风火火的“业务中台项目”留下的，在同事间，这是心照不宣的秘密。
“业务中台项目”是公司去年的明星项目，曾获得总经理颁发的“突出贡献奖”，基调都已经定好了，谁敢说中台项目不成功？
可眼前的烂摊子又怎么收拾呢？王架构摸了摸他那颗被上帝亲吻过的头颅，很是无奈，他面临的问题是：
1、“业务中台”的后续维护工作，缺乏资源。当初成立项目组，从各业务线调人，项目上线后，团队就解散了。在领导们看来，中台项目已经“成功”了，庆功宴都吃了3回了，还能有什么后续工作？项目完美收官，交给架构部维护，就这样愉快地决定了。
2、“业务中台”脱离业务，需求响应慢。王架构的团队做的是基础架构，不是应用架构，缺乏对业务的了解。让一个基础架构团队来维护“业务中台”，这显然是个外行人的决策。在公司看来，却是神来之比：中台是个架构呀，当然由架构部负责维护。
3、明星项目的“诅咒”。在大公司里这样的现象非常普遍，就是去年的“明星”项目，很可能是今年的“乞丐”项目。这个很好理解，“明星”项目就是当年的公司战略方向，而公司的战略方向每年都是不一样的，很少有同一个项目连续两年都是明星项目。
人往高处走，优秀的员工争着做明星项目。去年的“明星”项目“业务中台”，今年沦落成“乞丐”项目，根本拿不到资源。
王架构所在公司的“中台”建设，主要问题是：
1、把中台当成技术项目。作者之前也写过这个问题，“本以为中台是个技术问题，后来发现是个组织问题，最后才知道这个战略问题”，这是许多公司对中台的认知过程，这个过程所教的学费，少则几十万，多则几千万。把中台当做技术项目，所以组织上没有配合做变革。中台项目做完，项目组解散，中台项目难免“烂尾”或“年久失修”。
2、中台战略不清晰。甚至可以说没有所谓的中台战略，如果有战略，那么在组织上应该有所体现。要解决的问题也是不清晰的，究竟是降低成本，还是提升体验，不够明确聚焦。中台项目上线后，就鸣金收兵了，殊不知，中台是需要业务滋养的，项目上线仅仅只是开始而已。
这种现象普遍吗？非常普遍。老K调研了20多家互联网公司，70%在这一两年内都建立了中台，四成以上都是采用项目制的方式。跟上面的案例很相似，面临的问题也很类似。
王架构的公司是幸运的，至少中台项目是“成功”的。读者Bear就没那么幸运了。
“烂尾”的中台，锅谁来背？
Bear给我留言，讲述了他们公司的中台现状：
我们公司就是想做中台，一家saas企业应用软件供应商，先拆微服务，拆完没人管理和运维了，发现做不成中台了，现在就这散架子跑着，微服务的计算研发团队变成运营和运维。。艰苦的跑着~
从Bear的描述来看，这是一个“自下而上”的中台项目。先把SaaS架构，拆成微服务，这样有利于服务的抽取，这是中台架构演进的普遍做法，技术方案上没什么错。
拆完发现做不成中台，Bear没有说得很清楚，可能是技术问题，也可能是规划问题。拆都拆了，怎么办呢？跑着呗，微服务架构总归比原来一个大单体要健壮、可扩展一些，但是维护成本也高一些。
Bear他们公司的中台建设存在的问题是：
1、中台建设，自下而上。中台是战略层面的事情，只能自上而下，进行组织变革、业务模式变革、技术变革。少一环不联动，都极有可能失败，这个过程非常复杂，不是几个技术人员能够推动的。
2、决心不足，投入不足。从公司层面对中台建设的决心不足，导致了资源投入不足。战略上没有重视，觉得你们试试看吧，小范围跑跑，跑起来再说。现在一看，果然跑不起来。“中台没戏，都是骗人的玩意，还好我不是韭菜”，老板暗中观察，独自窃喜，为自己的“英明决策”自嗨。
这类公司就更多了，一群技术人员，觉得中台是个时髦的概念，看了几篇中台鸡汤干货，撸起袖子开始干，幸福都是奋斗出来的，天坑也是这么挖出来的。先上微服务，拆成几百个独立应用，再整成大中台。合的时候出问题了，合是合好了，就是多出了几个模块，怎么也组装不起来。哈哈哈哈，跟老K当年拆IBM笔记本的过程是一样的。
技术人员给自己挖坑，然后再默默地填上，这一挖一填之间，神奇的事情发生了：简历上漂亮了，项目得奖了，工资也涨了，就是公司倒大霉了。
总之，中台是一种很玄的东西。
