谁还在信中台啊？

👉目录

1 还有谁在坚持“中台”？

2 第二类人：实际业务管理者

3 AI 时代的中台启示

2020年一月，36氪发表了一篇10万+阅读的技术文章《中台，我信了你的邪》。有幸作为文章中唯一正面主角露脸，因为通篇文章，貌似只有百果园自认为中台实施是成功的。五年过后，中台仍然是各持一说，甚至中台的“鼓吹者”也在23年传出“去中台”的说法。

作为严谨的技术人员，我们当然不能人云亦云，事物本身就是一体两面，我们今天做一个复盘，在复盘的过程中，自己学到了知识，以后的工作能够更好开展，才是本文的核心。

关注腾讯云开发者，一手技术干货提前解锁👇

鹅厂程序员面对面新一季直播继续，每周将邀请鹅厂明星技术大咖深入讲解技术话题，更有精美周边等你来拿，记得提前预约直播～👇

深度了解20+腾讯云最新黑科技；5小时直播，百份周边送不停。

01

还有谁在坚持“中台”？

技术常有常新，一旦没有新的名词，那就需要创造一个，否则企业没有升级换代的动力，技术公司业务也就没有增长的空间，几十年来，一直如此，我们耳熟能详的几个字母的缩写词，一直在迭代。

中台热潮过后，能够沉淀下来的才是“中台”这个概念背后的真正有价值的东西。

销售人员恨不得每个月都有新名词，一旦不被关注，立刻弃之如敝履，只有实际使用中台并获得真正收益的人，才会体会到其中的好处，目前支持“中台”理念的人，一定都是实际运用的受益者。

第一类人：不破不立，利用中台概念打破业务墙，辅以合适工具，重新整合了技术平台并持续收益的技术人员。

大家都知道，信息系统是最典型的屎山根源，业务快速变化，底层架构老化，只能一层一层打补丁，到最后，业务系统混杂，明明只是改动了A，而B系统却崩溃了。偏偏在没有预算的情况下，根本不可能进行迭代，从而陷入恶性循环：业务迭代，IT改软件，按下葫芦浮起瓢，一次修改，多次擦屁股，有限的人力捉襟见肘，业务认为技术不给力，技术有苦难言，拿不到预算，更不可能投入进行底层迭代。

当时借着“中台”概念热炒的时候，如果争取到一笔大的预算，同时下定决心迭代，利用“中台”光环获得更多的缓冲时间来压制业务的新需求和阵痛，即使不能满盘皆赢，也能大大缓解业务给予的技术压力。

简单说，就是借用“中台”这个概念融资，获得时间和资源，从而化解之前欠下的“技术债务”。债务少了，利息少了，压力减了，做事也就顺畅了。

02

第二类人：实际业务管理者

我们想象一个场景，一个集团公司，下属N个子品牌，都是独立的法人公司，每家公司都有自己签约的物流企业进行服务，但是由于各品牌在中国发展区域重点的不同，一旦业务扩张，可能这个已签约的物流企业并不是成本和效率的最优解，那么多合作合同，贪腐更是不可避免。

这时候需要怎么办呢？集团成立了一个新的部门，负责和全国的物流公司打交道，而原来的子品牌全部取消自己的物流签约，任何物流需求都在信息系统中自动分解、派单、追踪。不用实际落地，我们的经验就可以告诉我们，这样效率提升，成本下降。因此我们可以说，企业建立了一个物流中台。

未来企业成立任何子品牌，都只需要将发货地、收货地、包裹特征上传给这个物流中台，就可以很容易的对接上优质的物流体系。

更进一步，物流体系还可以外延到企业的上下游生态，中台的灵活性在变化迅速的互联网年代，优势明显。

透过以上两个例子，我们看到了“中台”的实际意义，但是也一定会看到有更多的“中台“失败者和案例。在AI智能化如火如荼的今天，我们如果想和当年中台概念热炒一样，趁势而为，我们需要怎么做呢？我们必须再回过头去看一下那些失败案例，避免重蹈覆辙。

中台的失败有很多种，最常见的也是最凶险的就是“未达到预期“。

预期是个很奇妙的东西，没有的话，就没有投入，投入后达不到，同样是死。之所以有人提到，不上中台是等死，上中台是找死，就是这个预期的问题。不上中台，意味着IT没有给领导正确的画饼，一个如此没有想象力和规划能力的IT留着干什么？预期过高，落地拉跨，一个如此没有执行力和落地能力的IT留着干什么？

大家都知道，上中台不仅仅是个技术活，但是技术活是我们的本职工作，中台在上线之前的几大承诺中最重要的就是“业务中台化以后可以非常灵活的快速开展新业务的尝试”，通过中台对业务的抽象，把所有业务复杂的环节解构，同时辅以微服务的K8S系统的超强伸缩性，达到“复用”的目的，从而大大减少开发的时间。

真的是这样么？中台只是将一部分的可复用的业务逻辑变成了服务，但是，真正一线需要的是什么呢？还需要加上UI，加上前端逻辑，加上批量处理操作，加上特殊的业务判断，这样一来，真正节省的开发时间可能只是1/5或更少，甚至原来的屎山可能只是改头换面，挪了个地方，从C++的源代码库，挪到了Java代码库而已。

花了钱，却没有立刻变强，热炒的中台立刻被反噬，变成了臭大街。

软件开发从来都是一个系统工程而不是一两个工具的颠覆，对中台架构理解不深的同学往往会掉入技术陷阱，而忽略了业务的本质。

我们先梳理一下中台要成立的几个核心要点：

1）领域划分：必须明确的划分领域，在领域内可以随意调用，跨领域必须有统一可调配的接口。通过领域划分，核心是解决“牵一发动全身”的问题。自己域内的事情自己处理，找外援一时爽快，但是外援一旦出问题，你就是那个被牵连的。

2）解耦：中台的核心是解耦，在域层面的解耦之后，最小粒度的服务也必须与权限、业务逻辑、组织、流程进行解耦，大量失败的中台就是在这一步偷了懒，貌似微服务，其实只是把业务模块换了个名字和容器，不解耦就意味着没有将“屎臭分子链”打断，屎山看起来变成了宝塔，本质还是一座屎山。

3）配套工具。没有配套工具的解耦面临的最大问题就是：一旦解耦，这些新的权限、逻辑、流程、结构，放在何处？堆在一起的话，代码实现又变成了“硬逻辑”，更谈不上拼装，所以必须有一个“逻辑平台”，或者说“逻辑中台”来进行存放与管理，在目前看来，这个合适的逻辑中台就是低代码平台。使用过低代码平台的同学都知道，它承载了业务的各种逻辑，并且高效的将各业务中台有机的连接在一起，因为一旦没有链接又会形成新的数据孤岛，又走回了老路。

4）组织与团队，中台的管理和调度，不仅仅是一个技术的工作，需要有专门的组织来进行梳理和管控，否则时间一长，功能退缩，又回到了老路上。

我看了很多企业的中台建设过程，数据中台相对技术独立完整，比较成熟，但是离开以上四点的业务中台，必败无疑。

03

AI 时代的中台启示

回到开始的话题，AI智能化时代来了，中台的失败成功案例又会给我们哪些启发呢？

首先，AI智能化的根基，在企业端，绝对不是硬件或者软件，而是企业和行业知识，没有内部专业知识的AI，只是一个玩具而已，所以，企业要优先构建知识管理部门，这一步越早迈出越好，我们看到很多企业买好了硬件，选好了系统，再开始进行知识整理，等到几个月后知识整理的差不多了，新的硬件和系统已经出来，之前购买的软硬件价值大幅缩水，一旦上线没有那么“好用“、“AI幻觉”再闹几个笑话，被业务抱怨就是IT下课的导火索。

其次，通过聊天窗口的Chat，对大型企业的生产力提升有限，我们必须引入一个可以灵活配置与优化的管理平台，也就是常说的“Agent智能体平台“，简单的说，他就像OA流程编排系统，将人的操作和AI的操作“连接起来”，解耦以后的另一个好处则是可以发现很多很多“业务入口”其实可以被简单的AI 智能体所优化。智能化年代一个重要特点就是原来的键盘+鼠标构成的UI形式会被改变，虽然不至于是什么都用语音，至少可以将原来大量的录入、条件选择，变为更智能化的端对端操作。

再次，不要过度画饼，AI始终会有一定的幻觉，没有内部知识的校正和核对，AI，尤其是多段AI连接的多重智能体，可能会将起始的微小错误放大至不可接受的地步，作为非业务方的IT，识别这些错误的能力非常有限，业务部门如果也忽略过去，后面的锅你猜会让谁来背呢？

最后，AI体系的端对端导致知识和数据的界限进一步模糊，也意味着IT的安全管理需要更加严格和规范，千里之堤，溃于蚁穴，切记切记。

-End-

原创作者｜沈欣

感谢你读到这里，不如关注一下？👇

📢📢Google Pay是怎么设计它的支付钱包系统的？点击下方立刻探索👇

你觉得中台带来了哪些改变？欢迎评论留言补充。我们将选取1则优质的评论，送出腾讯云定制文件袋套装1个（见下图）。4月22日中午12点开奖。