搞明白企业中台架构其实很简单

上一篇我谈到中台架构能够成为企业数字化破冰者的关键就是“合”“分”“聚”三言。而构成中台的，又是“有业务”的业务中台，和“有技术”的技术中台两语。三言两语便是看上去纷繁复杂的企业中台的精髓所在。

企业数字化中台方兴未艾，各种概念、架构和产品层出不穷，说法各异，效果也参差不齐。客户在各种名词、概念、技术堆砌中迷茫不已，软件公司不知如何建设，软件用户不知如何选择。但其实只需要掌握“合”“分”“聚”和“有业务”“有技术”的三言两语精髓，就可简单明了的判断一个所谓中台产品能达到什么样的效果。

三言是指：

• 合，指虽然业务系统被拆分成了微服务，但业务和数据必须仍然是集成一体的。
• 分，指将有原来有边界的各种业务系统拆分为无边界的微服务集合。每个微服务都保持独立性，自包含，有自己的生命周期，能独立迭代和发展。
• 聚，指拆分开了的微服务必须能够将像搭积木一样快速组装应用场景。
  

两语是指：

• “有技术”指中台产品应具备支撑中台化的必要技术。包括但不限于IaaS,PaaS，Devops, 容器化，分布式，微服务，开发平台，运营平台及其它IT工具……。
• “有业务”指中台中不仅要有技术支撑，更要有大量业务内容可供客户复用而不是只有技术框架。
  

接下来我们就来分析一些典型的不完备的“中台”架构，看看依据三言两语，它们的问题出在哪里。

1）典型非中台架构

• 传统单体架构
  

可见单体架构的用边界把完整业务链条切分成多个单独的系统。每个单独系统内部是集成的，可以称之为“合”。但因为不可拆分成零部件，也就无法快速组装。同时虽然提供业务内容，但却不具备中台技术，因而它是典型的非中台。

• 互联网场景化应用架构
  

互联网场景化将完整业务拆分成很多独立场景，每个场景独立“深挖”，但场景所处的全业务链条不是每个产品设计的考虑范围。拆是拆开了，至于合和聚，它们的做法是“遇到了再说，反正可以写代码调用开放API”。可以说是管拆不管合也不管聚。虽然提供了业务场景，但却不具备完整的中台技术。通过开放API和网关虽然可以实现场景集成，但对企业来说更重要的业务集成和数据集成就完全无能为力了。因而它也是典型的非中台。

2）典型的“半”中台架构

“半”中台是指有了基本的中台架构概念，但只能满足“有技术”“有业务”两语中的一个：

• 有技术但无业务内容的半中台
  

典型有技术但无业务的半中台产品具备了完整的中台化支撑技术，也有一些公共的支撑服务，因而它是技术中台没错。由于没有业务内容，它只能是半中台。它将微服务的开发和应用系统的建设完全交给客户在项目中自行开发。

由于中台化环境的复杂度、设计复杂度和开发的复杂度都要明显高于传统单体式应用，如果缺乏配套的成熟开发工具，其学习成本和复杂度会更高。在没有可复用业务内容作为可复用资产或案例参考的情况下，初期资源成本和时间成本不仅不会降低，反而会显著攀升，最终企业还等不到远期因为复用、组装、可持续迭代等中台优势而带来的效益提升就会失去耐心或无法承受而放弃。

这类半中台产品通常脱胎于IaaS或PaaS公共服务体系，它们提供内容的运营管理，但认为业务内容是由租户自行提供的，它们不负责也不关心。由此产生的中台产品自然是有技术无内容的半中台。

• 有业务内容而无技术的半中台
  

典型的有业务无技术的半中台产品已经完成了业务系统的全部或部分的微服务化改造，可以方便的部署到外部的技术中台上，通过API网关提供业务服务。可以称之为业务中台。但由于并没有内置的技术中台，它只能向企业交付业务内容而无法将定制开发能力一并交付给用户。这类只有内容没有技术的平台难以支持用户个性化，一般只能标准化交付，甚至只能以SaaS方式提供服务而不能本地化部署。这种半中台企业要么只能用，不能改，要么个性化定制代价高昂，或者很难跟其它业务系统在流程和数据层面集成。

同时也可以看到，这种架构与传统单体式应用架构非常相似，只不过把原来的单体大系统拆成了业务更加聚合的中心化服务。虽然它解决了“拆”和“聚”的问题，但由于缺乏与技术中台的整合，各个中心与外部业务系统之间从流程和数据上看仍然是孤立的，需要依靠外部工具或者定制开发来完成整合。正所谓拆了大烟囱建了小烟囱，形似而神散。得了微服务的形而失了集成一体化的神，总体是得不偿失的。

这类半中台产品大多脱胎于SaaS服务或者传统企业管理软件的SaaS化改造。它们长期专注于企业业务内容的开发或业务运营，大量应用外部技术平台而缺乏自身技术的积累。因此只能交付现有业务内容，却无法将个性化定制能力一并交付。用户无法获得软件的自主控制和自主创新能力，使得企业数字化中台建设难以持续发展。故而称之为半中台。

3）典型的“伪”中台架构分析

“伪”中台是指，具备了中台的外表，但其实并不能真正做到可“分”，可“合”，可“聚”的三言。

• 伪中台之可聚可合不可拆
  

典型可聚可合不可拆伪中台具有一定的欺骗性。它的内核仍然是紧耦合单体结构形式，保留了业务集成性，但并未完成微服务化改造。它只是把原本封闭的业务功能以API形式开放出来，利用界面构建工具，在API层面将某些功能组织成一组界面，看上去像是可配置的微服务。用户能够利用界面工具定制个性化界面，但内部逻辑仍然是黑盒子，无法定制，也无法自由的将各种业务能力分拆组合。所以是表面可“聚”，内部可“合”，但最为关键的“拆”却没有实现。有的利用外部技术中台实现了云化部署，有的甚至只能以传统的单体方式部署。所以它只能是伪中台。

这类伪中台通常脱胎于传统专业企业管理软件和ERP软件。由于积重难返微服务化改造困难，为了赶上微服务中台化的潮流，只能用开放API，提供可定制界面的方式伪装成微服务。企业用户仅仅获得了表面上的场景定制能力，而没有最关键的业务共享复用和定制能力，可以说是换汤不换药，总有一天还得推翻重来。

• 伪中台之可拆可聚不可合
  

典型的可拆可聚不可合伪中台已经实现了微服务分布式互联网化等许多中台的构成要素，业务能力来自于可独立部署和运行的微服务，也确实可以通过API组合快速创建业务场景。但是企业只能实现场景整合，不能在流程和数据层面实现集成一体化的整合。这是因为这些微服务来源复杂，除了通用API之外，它们在规划、设计、开过过程中没有统一的规范和标准。很多微服务只知道怎么调用API，不开放源码，也不开放内部数据。即使有部分开放，也各是各的标准。因此企业根本无法深度整合它们实现企业业务的集成一体化，从而脱离了企业数字化中台重要的“合”。所以它也只能是伪中台。

这类伪中台通常来自于云市场服务。云市场上架了很多开箱即用的业务组件，企业可通过API整合它们。但是这些业务组件来自于不同的开发者，云市场并未标准化和规范化这些业务组件，自然也就五花八门。可以想象一下，一个企业采购了很多零部件，而这些零部件规格各异，材质不一，质量不同……依靠这些零部件怎么可能组装出可靠可持续的产品呢？

上面讨论了一些不完备的中台架构形式，那完整的中台架构又是什么样呢？这一篇先用完整的架构图做一个预告，下一篇我将深入讨论一下完整的中台架构。敬请期待。

完整的中台架构

---

这将会是很长的一个系列。我会持续的把我这十多年在企业数字化过程中思考、架构、方法和技术，以及我团队所研发的企业数字化中台构建平台发布出来。相信对业界是有着重要的借鉴意义的。