关于中台的思考和复盘

 数据中台可以做， 业务中台不能做。
 能力共享和聚合的入口可以做, 强嵌入的业务中台不能做。

中台

中台不是只能是微服务，中台还可以是代码复用框架，允许业务自己扩展 迭代code as service，Platform as Code

中台战略是一个节流的事情，前台才是公司业务的核心，做增量、做开源。
关于中台的思考和尝试

中台是什么

中台是一个对业务能力的抽象和共享的过程，有的公司将中台当做一个所谓的"战略"性、"革命性"的东西，仿佛不搞中台就反革命一样。
在没有集群服务、微服务思想前，所谓的中台就是良好的代码封装，也就是通过抽象和统一来获取增量价值，所以这没有什么革命性的东西，这个东西一直在做。

• 所以中台的"圈地策略"就是个及其傻逼的行为，等价于为了在一个module下各个package争抢实现。

中台的意义

中台是为了提效、为了降成本
中台是服务于前台的，是为了提效的，除了提效其他的因素不值得思考。在代码难以管理的时候----这是必然会出现的，不是有了中台就好管理了，看看接入中台前后的代码量变化就知道了----实现必要的重构。

中台的存在形式

中台不是都是微服务的形式，sdk、模板类、甚至设计模式都可以。
除了代码外的东西，"咨询服务"也是一个重要元素: 文档、客服、技术支持。

中台的问题

前台服务单个业务，目标是这个业务的增长，前台必须紧贴业务做好差异化，在竞争激烈的环境，前台需要有足够的创新能力，通用化的中台服务和创新能力冲突。

 中台服务整个集团**，**目标往往是降低成本， 加强管控， 或者是扩大规模优势 。

管控是在原本就有需求的情况下管控，不是"圈地策略"的管控。
中台解决重复造轮子的问题。避免项目间互相提防。

反创新

中台迭代慢，离需求远，是一个和业务创新矛盾。

 有说法说，一个业务靠拖拉拽就能编排出来了， 这不是创新是什么？ 事实证明这种创新完全无用。 没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式的。 真正的创新不是现有能力的线性组合。

反人性

中台自身的场景往往缺乏前瞻设计 ，是对现有场景的抽象。 而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力， 同时强迫前台团队下线一个他们研发了很久的创新。 这种行为往往造成精英人才的流失， 使得本来就受到遏制的前台创新变得更为匮乏。

过度设计

中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。 在带来了大量的运营复杂性的同时增加了用户（买家，卖家，本地运营）的学习难度。 这就是我们常讲的膨胀软件(Bloatware): 巨大， 复杂， 缓慢，低效。

丧失对客户心智的追求

中台团队的产品和研发的核心技能在于抽象和降本。 前台业务的核心能力在于对商业机会的捕捉和新商业机会的创造。 这是两种完全不同的技能，往往对应着完全不同类型的人才。一个长期在多个业务中间找共性来降本的人是不会专注在最大化前台业务增长的。

中台适用范围

在整个部门还在探索阶段的时候，中台先行，是一个很傻逼的行为。

中台的缺点

脱离一线生产和创新

当中台能力已经稳定了以后，中台部门这帮人要干什么呢？他们一定会再去考虑还有哪一些新能力能够加到我的中台里面来。但是你想一下中台部门的这一帮人，他们往往会长期的脱离一线的业务，等于他们是关起门来坐在自己屋子里在想我究竟有什么新的能力应该放到我的中台里面，脱离一线实践你新做的一些中台层的能力能怎么样去满足上层业务应用呢。

参考链接: [阿里新架构调整拆中台-我不玩了你们随意 - 知乎](https://zhuanlan.zhihu.com/p/622574660?utm_medium=social&utm_oi=984565394710872064&utm_psn=1639181523738931200&u

提效?

同质型需求足够多时才有作用，否则得不偿失。但是很多互联网产品同质化的需求并没有这么多。

便于管理

很多中台都提效不了 而是为了便于管理。避免烟囱设计的难以维护
但这里有一个很吊轨的地方，因为代码五花八门(写的烂)所以使用一个中台承接这个功能。但接入中台后代码量反而增加了，系统复杂性反而增加了。

需求阻塞

非闭环导致的沟通成本和无限排期，业务需求根本响应不过来。
不合适的需求边界切分的，对于需求通用的无止尽贪婪，需求爆炸又难以管理。

对于业务中台，微服务、网关、REST API 及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。要做好业务中台，以上方法论大概都不可或缺。

中台和组织机制

基于站队而不是基于业务组队
对哪个团队做中台或者哪个人来设计中台的决策是个自顶而下的中央决策过程。 做中台的人没有所必须的抽象能力和业务理解，类似过去封建王朝的分封的过程。受封的仅仅是生在帝王家， 有没有治理和决策能力不重要。
不尊重前台创新
中台的推行机制往往是个掠夺的过程。对业务线的创新直接复制， 不尊重发明者的知识产权和劳动。中台所到处，寸草不生。
垄断 强制推行
中台能力一旦发布， 独家专供， 哪怕功能不完善， 设计不合理也不允许业务团队复制或分支。
削足适履
中台为了做规模强制向业务线推行，业务线被迫削足适履，消耗严重。每次中台升级小的BU更是叫苦不迭，故障频发。