03企业中台架构及其核心要素

中台架构再复杂也只是三言两语的事儿

上一篇我说中台虽然是一个创造出来的名词，但它是企业数字化相关方法、技术、实践和发展的必然结果，并非人为制造而是应运而生。它的内涵是：利用微服务技术拆解业务系统成为业务组件，共享于一个开放平台，让微服务所承载的业务组件成为可复用的零部件。如同工业时代五花八门的工业化产品一样，基于有限的标准零部件创造出无限的精彩纷呈的应用场景。并因为业务组件全部位于中台并无系统边界的隔离，从而可以非常容易的集成和组装。

同时，从企业架构方法的演变过程中，可以看到软件架构中的“分分合合”。这一次中台的分合已经是完全不同的意义，不再是黑白分明，而是分中有合，合中有分。正是这一句“分中有合，合中有分”道出了中台架构区别于之前发展历程中其它架构形式的根本。

企业数字化架构方法的演进

“分合”二字伴随着企业级软件发展的整个历史过程。“合”代表了结构化设计、集中、集成、一体化、流程化、单体式……，“分”代表了面向对象设计、分散、分布式、模块化、事件驱动、服务化……。它们分别造就了传统的集成一体化ERP领域以及分布式场景的互联网To C领域的辉煌时代。

然而时代一直在变。在数字化转型的大背景下，企业对内管理和运营要求更加精益，对流程、数据、业务集成的要求更高，对外连接和创新要求在不断攀升。不论是客户还是合作伙伴和渠道，整个供应链都要打通成为经营生产流程链上的一环。对集团型企业来说，多元化生产经营已经从条块分割独立的业务形态走向多业态融合的综合经营，从而形成一个企业生态。企业经营已不再严格区分内外，业务能力逾加开放和共享，从而与客户、合作伙伴、渠道、上下游供应链及周边扩展业务互联互通共同形成产业互联网。

传统一体化的大系统已经不适应企业数字化需要，可互联网思维下的快速迭代，场景化深刻挖掘方法也没能撑起企业数字化的大旗，企业在不断的重复建设中浪费了大量资源，却始终无法沉淀企业核心竞争力。问题出在哪里呢？

以SAP、Oracle为代表的集成一体化单体式大系统的问题出在它们试图在一个单体的大平台里容纳下所有的业务——因为这样它才能够保证业务的实时集成。然而大型单体式应用庞大笨重、紧耦合、互联网化困难、集成工作量大、性能瓶颈、“慢”和“贵”等等一系列不可逾越的障碍已经让这条路走到了尽头。事实上也没有可能在一个单体平台上装下所有业务。因为在产业生态背景下，企业的业务早已不局限于内部，一个单体式平台是不可能将客户、合作伙伴、上下游供应链等等所有外部业务都一并装载到同一平台上的。分布式、跨业务、跨行业的整合是无法逃避的要求。

而互联网方法的问题则出在将软件分场景看待。互联网思维认为每个场景应该只围绕着一件事儿“深挖”。每个场景都应该分团队独立迭代，各自发展成各种App或小程序。按互联网的说法，这叫一厘米宽一公里深。这种方法只关注了某个业务场景的深度挖掘，却忽视了企业经营是一个整体的事实——企业的经营管理不论从流程上、数据上还是管理要求上，都无法切割成一个个的独立场景。在互联网思维的鼓动下，很多企业做了N多个App、公众号、小程序或入驻某个电商平台，却都只能在局部场景发挥有限的作用，不但没能从根本上改变和贯穿企业的整个主体经营，反而因为太多独立小场景让企业的经营流程变得更加支离破碎，数据孤岛现象越发严重。

事实上，不论互联网再怎么分布，场景再怎么深挖，企业必须整体经营；不论单体式集成架构再怎么集成一体实时联动，企业的业务场景也需要个性化执行和独立创新。这就暴露出来三个难以调和的矛盾：

企业经营是一个整体，但业务却常常是分场景执行的；

企业管理强调标准化，但一线业务创新却是个性化的；

企业业务流程需要管控，但同时又需要对接多种不可控的外部场景与多个规范不一的合作伙伴。

合也不行，分也不行，那该怎么办？恐怕很多人都会脱口而出，那就又分又合呗。该合的地方合，该分的地方分，不就行了吗？答案确是如此，但能做到吗？

GiSP企业数字化开放平台顶层设计

能！这是我团队在设计企业数字化开放平台GiSP时所规划的顶层架构。其中关键就在“模型”与“服务”的分离。

模型代表了“合”，它描述集成一体化的业务整体，就像电脑的主板，你能看到密密麻麻的连接线，这些连接线将各种电子元器件连接在一起。但模型本身却没有任何功能。

服务代表了“分”，它描述一项独立的业务能力。就像电子元器件，发光二极管只能发光，蜂鸣器也只能嗡嗡叫。它们是独立的，可替换的，可组装的，平时是相互无关的。但是当它们被插入主板后，各种消息命令就循着连接线传达到每一个电子元器件，从而让它们协调一致的工作，将独立的微服务“合”成一个有机的整体，从流程到数据均集成一体的工作。

电子元器件还有两个特性，那就是标准、共享与复用。所有电子元器件构成了一个标准零部件集合，并且这些零件可以共享出来，复用于多个产品。

模型层与服务层的分离解决了分与合的矛盾

而最终应用场景，则是利用微服务快速组装出来的。微服务如同积木块，业务场景设计者可以如同玩乐高积木一样，随需搭建各种个性化的业务场景。我们把这个过程称之为“聚”。聚是个性化的，是因人而异，因事而变的。但积木块是共享和标准的；虽然微服务积木块是独立“分”开的，但模型是“合”为集成的整体的，并且所有三层都架构在一个“合”为整体的技术底座上。

最后，平台层则要将支撑模型层、服务层、应用层所需的一切基础软硬件“合”成一个基础设施，通常是PaaS 与 IaaS，作为开箱即用的服务提供给软件开发者。这也是一种“合”。

在以往软件的开发结构里，基础设施之上就是应用系统了。有时会有一些“中间件”存在，但它们都是辅助性质的。但模型层与服务层不同，它们就是软件的核心，位于应用系统与基础设施之间，把它称之为“中台”，还是很贴切的。

这样，我们就完全清楚了中台化架构是如何成为企业数字化转型困难的破冰者的。正是“合”、“分”、“聚”三个行为解决了企业既要整体，也要独立；既要标准，又要个性；既要内控，也要外连的矛盾。一次性将整体并多元化经营、标准管理并个性化创新、内控并外连全部解决。而这一切，正是企业数字化转型和产业互联所必须的要素。

模型层与服务层作为中台的核心，它描述的是业务内容而非技术内容。所以中台本身是业务属性的。我们把业务属性的中台称之为“业务中台”，它是“有业务”的。但业务属性的中台无法脱离平台层而存在。平台层不但是云化、分布式、服务化、互联网化等等支撑企业数字化的技术底座，也是系统的运行硬件资源，还是模型与服务的设计、开发、部署、测试、运营支撑工具。因此我们把支撑业务中台的所有技术组合称之为“技术中台”，它是“有技术”的。“有业务”和“有技术”一起构成了企业中台架构的两个必要组成部分。

如果把“合”、“分”、“聚”称为三言，“有业务”、“有技术”称为两语。那么三言两语就是企业数字化中台的精髓所在。其中“合”与“分”尤其重要，二者少其一中台便不成立。两语次之，少其一，便只是半个中台。

掌握了三言两语，不管一个所谓的中台产品用了多少技术名词，画了多复杂的结构，用了多高明的话术，我们都能非常简单明了的一眼洞穿它是否具备中台能力。比如：

传统单体架构应用形式只管合不管拆，没有拆就不能聚；有内容，无技术。所以它不是中台架构。

互联网场景化应用形式只管拆不管合，因拆出的零件缺乏统一标准而不能聚。有内容，无完整支撑技术。所以它也不是中台架构。

这一篇通过传统ERP方法与互联网方法的问题，引出了企业信息化过程中难以调和的矛盾，从而道出了中台的三言两语精髓。

下一篇我将用三言两语讨论一些常见的“非中台”、“伪中台”、“半中台”架构的产品形态，帮助正在选型、设计、建设企业中台的读者们了解如何判断并选择一个真正的中台化产品或平台。敬请期待。

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

如果您对企业中台架构、企业数字化转型和产业互联网感兴趣，请关注我，并期待后续更新。

想了解基于这套方法和架构的企业数字化中台产品长啥样子，可以关注这个公众号。