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

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

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

【 第一类人】一线技术人员

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

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

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

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

【第二类人】实际业务管理者

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

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

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

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

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

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

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

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

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

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

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

【中台的意义】

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

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

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

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

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