搞明白企业中台架构其实很简单( 二 ) _中台架构

同时也可以看到，这种架构与传统单体式应用架构非常相似，只不过把原来的单体大系统拆成了业务更加聚合的中心化服务。虽然它解决了“拆”和“聚”的问题，但由于缺乏与技术中台的整合，各个中心与外部业务系统之间从流程和数据上看仍然是孤立的，需要依靠外部工具或者定制开发来完成整合。正所谓拆了大烟囱建了小烟囱，形似而神散。得了微服务的形而失了集成一体化的神，总体是得不偿失的。
这类半中台产品大多脱胎于SaaS服务或者传统企业管理软件的SaaS化改造。它们长期专注于企业业务内容的开发或业务运营，大量应用外部技术平台而缺乏自身技术的积累。因此只能交付现有业务内容，却无法将个性化定制能力一并交付。用户无法获得软件的自主控制和自主创新能力，使得企业数字化中台建设难以持续发展。故而称之为半中台。
3）典型的“伪”中台架构分析
“伪”中台是指，具备了中台的外表，但其实并不能真正做到可“分”，可“合”，可“聚”的三言。

伪中台之可聚可合不可拆

文章插图

典型可聚可合不可拆伪中台具有一定的欺骗性。它的内核仍然是紧耦合单体结构形式，保留了业务集成性，但并未完成微服务化改造。它只是把原本封闭的业务功能以API形式开放出来，利用界面构建工具，在API层面将某些功能组织成一组界面，看上去像是可配置的微服务。用户能够利用界面工具定制个性化界面，但内部逻辑仍然是黑盒子，无法定制，也无法自由的将各种业务能力分拆组合。所以是表面可“聚”，内部可“合”，但最为关键的“拆”却没有实现。有的利用外部技术中台实现了云化部署，有的甚至只能以传统的单体方式部署。所以它只能是伪中台。
这类伪中台通常脱胎于传统专业企业管理软件和ERP软件。由于积重难返微服务化改造困难，为了赶上微服务中台化的潮流，只能用开放API，提供可定制界面的方式伪装成微服务。企业用户仅仅获得了表面上的场景定制能力，而没有最关键的业务共享复用和定制能力，可以说是换汤不换药，总有一天还得推翻重来。

伪中台之可拆可聚不可合

文章插图

典型的可拆可聚不可合伪中台已经实现了微服务分布式互联网化等许多中台的构成要素，业务能力来自于可独立部署和运行的微服务，也确实可以通过API组合快速创建业务场景。但是企业只能实现场景整合，不能在流程和数据层面实现集成一体化的整合。这是因为这些微服务来源复杂，除了通用API之外，它们在规划、设计、开过过程中没有统一的规范和标准。很多微服务只知道怎么调用API，不开放源码，也不开放内部数据。即使有部分开放，也各是各的标准。因此企业根本无法深度整合它们实现企业业务的集成一体化，从而脱离了企业数字化中台重要的“合” 。所以它也只能是伪中台。
这类伪中台通常来自于云市场服务。云市场上架了很多开箱即用的业务组件，企业可通过API整合它们。但是这些业务组件来自于不同的开发者，云市场并未标准化和规范化这些业务组件，自然也就五花八门。可以想象一下，一个企业采购了很多零部件，而这些零部件规格各异，材质不一，质量不同……依靠这些零部件怎么可能组装出可靠可持续的产品呢？
上面讨论了一些不完备的中台架构形式，那完整的中台架构又是什么样呢？这一篇先用完整的架构图做一个预告，下一篇我将深入讨论一下完整的中台架构。敬请期待。