53｜思考实例（下）：到底是什么因素左右了中台的成败？

基于统一语义基础上的设施型接口还是应当存在的。就像动物都有口，肝门，手足。因为基本需求是比较稳定的 但是我觉得中台这东西真的应该第三方化，采用第三方最佳解决方案，避免过去和将来的沉没成本，也可以轻松解决生命周期，采用灵活性问题。其实企业的IT底层需求也就那些。设施性的，数据库，KV 缓存，流式操作，链路追踪，日志, 对象存储，检索，应用网关。。 流程性需求，如CI/CD , 文档方案等。有了docker, portainers 现在的基础设施的搭建很大程度上只是只受认知的限制，绝大多数的东西真的没有存在的必要。 之所以这么觉得，主要是我觉得elon musk说的，成本的关键在于最简结构，最简结构的关键在于一直删除，删除恰当的标志是每次你要创建一个东西的时候，你有10%的时间在重新搭建被删除掉的旧东西。 个人觉得。这些组件的采用不但可以基本满足驱动业务需要，也满足了快速删除的要求，满足了快速添加的要求，而且消除了额外的认知需求，而且可以随时和世界的认知、工具更新同步。 约束中间件只能采用第三方，就像香港放弃自己的汇率管制。这是相当值得的。那些真正的需求如果不具有跨越物种的流动性，如果可以证明它是更永恒的最优，而不是畸形认知的产物？ 我相信活着就是为了创建奇迹，若有造物主要创造宇宙，必有寄望。 感谢东白老师，你创建了了不起的作品，为我提供了不起的启迪，有幸见证你的足迹，我很感谢

这一章真的是对自己很冲击，在现在公司，之前有半年时间在一个中台部门，进来第一次会议，领导的话就是“我们要支持公司所有的业务，你们每个人都是特种兵，需要向我直接汇报”（集权），而这个部门仅仅只有不到70人的规模；然后由于各个业务线，有各种不同的需求，这个领导到处派人去个各个业务部门驻扎，并且“我们参与的项目就是我们的了”（不尊重知识产权），一旦或者这个业务线的业务核心，部门内部就会马上搞一套新的出来，要求这个业务部门必须用自己的，有任何更改都需要中台进行的，向外包都严格混淆源码（独家授权）；每次有什么公有版本发布，都要求所有产线都必须按照他们规则来，我参与一个业务级的项目，本来就是一个稳定性需求，由于中台的参与，一个星期拉了十几个分支，整个业务线的人都压进去了，都没搞的过来（强制推送）；这本来是一个硬件的平台级中台，一开始就是采取内外部竞争的方式，就是业务线可以自己选择使用的中台技术，但是转换成我上面描述的模式后，一年时间，几乎所有业务线都被竞争对手打的溃不成军，现场销售和业务线离职的人员剧增，而中台一直在疯狂扩张，年初的70人到年底已经340人；但是一年亏损公司十几亿的成本，连一个稳定（1w小时稳定性测试都无法通过）；年底开始大裁员，而且我由于之前在某个业务线不愿意把业务代码带回这个中台，被赶出去中台（优化，又被业务线leader捞回来了）；然后那一年，只有我后面去的部门领导强势选择中台产品稳住了阵线；到第二年，集团领导发现没有成果，开始大规模裁撤中台部门；内部戏称的“AB团”运动才告结束！！而这一年公司直接元气大伤，后面用了两年时间才缓过气来

中台开放注入是可以，但是否需有审核机制确保注入服务的质量？否则就是灾难了

1、没有人能有这样的能力能设计并落地您说的这样的中台； 2、中国人，各行各业，大家都是混口饭吃而已

jar 包太大的问题。最好还是一开始就用go语言。java的基础镜像太大。docker 镜像编译后就那么大，而且内存占用很大。go 可以不依赖基础镜像，原生运行。一般镜像就小几十兆，而且内存一般也就java 1/2以下。负载能力也更强。时间到了现在，go已经和java生态一样便利了

这个中台的实施要求太高，国内估计很少公司可以做到，而且按照你这样来实施了，中台团队的发展方向和空间在哪里？只能越做越小，最后把自己做没了，那谁有愿意去做别人嫁衣的事情？

郭老师，take away~~~撒切尔夫人说：“你要小心你的思想，因为它会变成你的语言；你要小心你的语言，因为它会变成你的行动；你要小心你的行动，因为它会变成你的习惯，而你的习惯则会成为你的命运”~~~ 专栏的思维定势部分，是删除众多中提取了4个思维定势，价值思维和实证思维、去中心化思维和成长思维。架构是从小到大演化过来的，我们不能突然想象一个完美的大厂中台架构，而是需要在每天的工作中提升思考力，用思维定势演化一个架构~~~ 另外，技术至少需要积累5000小时以上，技术是个硬伤和硬指标~~~

东白老师，请教一下：当中台建立起来后，如何推动已有（可能几十上百个）前台把功能切换接入中台呢？直观上这个切换成本会比较大，还会引入很多问题如稳定性等，且短期来看没有太大收益。

被这篇中台的各种雷区戳中了，以我看到的一家做到垄断地位的厂商的研发组织结构来看，研发组织结构以典型的总部+分部的形式，总部提供基线产品，分部适应本地需求做个性化定制，可结果是： 1、总部的产品才有销售权但离一线业务较远，各个分部无法拉分支，导致对市场变化的定制应接不暇，却又无法得到充分复用，规模效应差 2、总部的产品代码、设计文档对分部不开放，分部基于产品定制有不低的使用门槛 3、总部的产品迭代兼容性差，接口不稳定，大版本升级分部被迫修改上层实现

中台的这些不良做法，换到后台和前台也一样。问题不是因为他是中台。