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

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

文章插图

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

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

两语是指：

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

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

传统单体架构

文章插图

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

互联网场景化应用架构

文章插图

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

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

文章插图

典型有技术但无业务的半中台产品具备了完整的中台化支撑技术，也有一些公共的支撑服务，因而它是技术中台没错。由于没有业务内容，它只能是半中台。它将微服务的开发和应用系统的建设完全交给客户在项目中自行开发。
由于中台化环境的复杂度、设计复杂度和开发的复杂度都要明显高于传统单体式应用，如果缺乏配套的成熟开发工具，其学习成本和复杂度会更高。在没有可复用业务内容作为可复用资产或案例参考的情况下，初期资源成本和时间成本不仅不会降低，反而会显著攀升，最终企业还等不到远期因为复用、组装、可持续迭代等中台优势而带来的效益提升就会失去耐心或无法承受而放弃。
这类半中台产品通常脱胎于IaaS或PaaS公共服务体系，它们提供内容的运营管理，但认为业务内容是由租户自行提供的，它们不负责也不关心。由此产生的中台产品自然是有技术无内容的半中台。

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

文章插图

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