前言

近两年，企业中台这个名词在企业的管理领域、IT规划领域、技术领域出现的频度比较高，也许在未来的几年里会逐步的走向更加红火的局面。笔者从事了多年的软件产品的开发、设计以及行业解决方案的研究工作，一直以来对“前台”、“后台”等概念并不陌生，突然有一天听到了“中台”这个概念的存在，自然而然的被这个概念吸引，并在这里记录下所见所想，愿和各路大神一道参与中台的研究与探讨。

平心而论，现在对于中台的理解和实践应该是一个各执一词的阶段，就像云、大数据等技术的理论和实践逐步演进一样，我们期待更多的有价值的观点的出现，指引着企业IT架构的演进和发展。在探讨中台构建的同时，笔者提出了结构化产品设计的方法论，并提出结构化产品设计的思路和方法，这是本文的核心论点。

什么是企业中台

企业中台的概念从不同的角度和管理层级来看可以有着不同的表述。首先、中台是一种运营模式，通过中台打破过去基于不同业务条线的运营组织模式，有效组织和协调各方资源，其根本目的是在降本增效的同时，快速响应客户的需求，实现向以客户为中心的业务运营模式转型；其次、中台可以是一个实际的企业的组织，由中台负责协调内部的生产、采购及其它的管理资源并处理和响应来自前台业务组织的请求及反馈；第三、从企业IT架构来看，中台可以是新的架构在原有各IT系统与面向客户的各应用系统之间的一个IT平台，其目的是融合并重用现有的沉淀下来的IT能力。此外，应该还有其他的表述等等。

觉得有一个比喻对中台的表述最形象和恰当：几个侦查战士在某地发现了一个高价值的敌人的目标所在，并及时的向联合作战司令部发回了攻击请求。司令部第一时间命令几千公里外的漂在太平洋上的导弹驱逐舰向目标发射导弹并把目标摧毁；与此同时，我军的无人机在执行侦查任务时发现了游弋在大洋上的敌方双航母编队，联合作战司令部立即调动我高精度侦查卫星进行定位同时命令路基弹道导弹立即进入战斗状态，并要求定位系统与导弹作战部队协同开展工作，双方共享数据链后10分钟内向敌方航母编队发起攻击。让我们还原一下，在上述的战争场景中，侦查部队、无人机部队等等就是我们企业中和最终客户打交道的各个业务组织；联合作战司令部就是企业的中台；至于海军舰队、导弹部队、天基侦查部队等等都是部署在中台上的各种战斗能力或者说服务能力。那么未来以中台模式来运营的企业如同现代化战争的联合作战一样：由前端业务组织负责收集市场信息、客户需求并进行及时的反馈；由中台受理业务组织传来的需求，在最短的时间内给出最佳解决方案并协调中台各业务能力对解决方案加以实施，这样整个企业都在以市场需求为导向，以客户为中心配置资源并高效运作。

好了，让我们把话题聚焦一下，本文的目的是从IT系统及产品的角度来对中台加以描述和讨论。那么笔者是怎么认识中台的呢：

首先，中台是能力融合的平台。大家都知道中台概念由阿里首先提出。阿里提出中台当然不是闲的没事凭空而来，这源自阿里各业务系统的演进。阿里在主营业务运营实践过程中，在不断的遇到问题解决问题的过程中，IT架构也经历了：单体应用阶段、全栈分布式应用阶段、平台化阶段、中台化阶段。其中在单体应用阶段，技术栈相对简单，一般包括浏览器、应用服务器（中间件）和数据库服务器这三层。但随着业务的发展会带来一系列问题，包括业务的扩展、响应周期、运营维护成本等；为解决这些问题，阿里的应用架构逐渐演变成分布式部署的结构，但也带来了一系列新的问题，特别是在分布式应用的早期，对于众多的服务的调度管理、调用监控以及排错变更等问题又带来了沉重的代价；随着问题的不断解决、业务模型的不断优化、能力的不断沉淀，逐步形成了诸如用户中心、订单中心、商品中心、交易中心等专业化的庞大的业务平台，我们称之为平台化阶段，到了这个阶段，各业务平台已经形成了良好的稳定的技术底座、业务基座，这里所说的业务基座包括庞大的基础的业务数据、业务模型等，（举例：比如说庞大的、繁杂的商品分类编码等）这些都是难能可贵的具有排他性的能力。企业当然要很好的最大限度的利用好这些能力，但现有的这些平台设计之初是为解决一类业务问题而设计，在重用或相互之间协同时还有诸多不便之处，这需要我们搭建一个新的IT架构层来融合已有的这些能力，这个IT架构层就是-中台。

其次，中台是快速构建、持续交付的平台。应该说中台起源的另一个背景就是企业的运营转型。在新经济形势下，企业纷纷寻求以客户为中心的转型。这种运营转型反映在为客户提供服务的IT系统上就是快速响应客户的需求，持续的更新和交付。这使得产品的设计、开发及运营逐渐趋于一体化。从这个意义来讲，中台是具备快速构建，灵活扩展能力的架构层，这要求在产品设计模式上有突破性的发展。

关于软件系统的业务抽象

刚刚接触中台概念时或者说在一段时间内很容易将中台误解为重构，但本质上不是重构，如果说要重构或新构，也是在中台这个新的IT架构层次上开始，而不去触碰原有的成熟的IT系统。我们搭建中台的目的就是融合现有的、稳定的功能及服务并能够快速构建和交付，这依赖于对各业务系统的抽象，而这一抽象的最终结果是形成对现有应用系统的标准化的表述。笔者认为从下述几个方面进行抽象是必不可少的：

1. 对各业务系统加工对象的抽象。我们以典型的电商业务为例，来看看现有哪些业务系统，如图：

图一

我们看到了诸如用户中心、订单中心、商品中心、交易中心以及其他的很多的某某中心，我们发现不管什么中心或系统也好，都是对某类对象或事物的管理，这些事物包括用户、订单、商品及交易对象等等，我们进一步把所有这些对象进行抽象，并赋予一个未来产品设计领域的标准名词-“实体”。所有这些业务系统，功能上千差万别，技术特性上可能也有不同的侧重点，但本质上都是对某类实体的操作。现在这些不同的业务系统有了共同的语言，就是实体，对实体的描述应包括：编码、名称、类型、属性的集合、属性值集合等；此外实体之间的关系由实体关系对象来描述；通过视图对象来定义在不同应用场景下实体显示的数据范围，实体可定义多个视图来满足不同的业务场景的需求。

笔者认为，对“实体”层的抽象是实现企业中台的最基本的逻辑设计，这是实现不同系统之间交互、融合的基础。各业务系统之间相互关联和响应的“数据链”是以实体为基础来表达的。下图是一个对企业客户实体的描述示例：

图二

我们看到通过实体属性来实现对实体的业务描述，一个属性可以是对另外实体或实体集合的引用等。

1. 对应用系统功能的抽象。我们是时候对众多的业务应用功能进行抽象和标准化的表述了。上述我们看到了五花八门的应用系统，和五花八门的操作界面，比如：

图三

图四

图五

图六

上述图三是采购单据的管理界面，这里是对采购单据的管理，其他的应用系统包括很多的销售单据的管理、客户的管理、供应商的管理、商品的管理等等，我们可以抽象为对任意类别的实体管理，这个管理的界面主要包括两部分内容，一个是关于所管理的实体的显示列表，另一部分就是一些操作功能。在这个图三中是以菜单的形式来实现众多的管理功能，包括新增、修改、浏览、删除、查询等。现在我们可以把所有这类的管理功能抽象为一个标准化的功能，我们取个名字-“信息管理框架”。我们现有的众多的业务系统中都包含着大量的这类功能，而无论是用什么样的技术实现，无论它的功能是通过按钮或菜单来实现，无论界面的布局以及它的UI和UE的水平如何。

上述图四所表达的是一个采购单据界面，在这个应用系统里表达为对一个具体的采购订单的浏览，也可以是其它的业务系统里的诸如“详情”、“详细信息”等等的功能。取什么名字取决于当时产品设计者的灵光闪现。但此类功能的本质是要对某个实体详细信息的展现。大家知道，涉及到具体业务的某个实体信息会很复杂，这里面不光是属性众多信息量大，更主要的是信息聚合的方式也是很复杂的。如图四所示的采购订单中，除了基本的诸如订单号、供应商、采购日期等等的采购基本信息，更主要的是采购列表信息，它包括了采购的产品、数量、金额等相关信息，这里用了一个“采购记录列表”页签的形式来加以表达。我们现在把所有这类浏览某个实体的详细信息的功能抽象为一个标准的功能-“单据框架”。此外，根据实际的业务需求，单据框架也可以很复杂，如图五可以通过一个页签来关联一个实体，可能是另外一个单据。

同理，如图六所示，我们发现在应用中有大量需要在某个时点上显示符合条件的某类实体的需求，并在显示的结果上进行选择。无论你的系统通过什么技术实现，界面的表达多么炫酷，其本质上就是满足这个需求。我们把这样一个功能加以抽象并取名-“参照框架”。

1. 对应用模式的抽象。应用模式指的是对某一功能具体实现上通过什么方式。我们知道对某一功能可通过多种的方式来实现，表现在软件界面上可以有多种不同的布局。比如，交互功能可以通过菜单实现，也可以通过按钮来实现；导航功能可以通过一个功能树来进行导航，也可以通过导航条来导航或者干脆通过一系列按钮来导航。这里举个例子，如图：

图七

这里是一个客户信息管理界面，在这里是通过在每行部署“修改”、“删除”、“浏览”按钮来实现对每条客户信息的修改、删除及查看详情等功能。这个功能也可以用图三所示的方式来实现，即把所有的功能都放到菜单中来实现。因此，我们可以把这两种方式分别称为信息管理框架的“行操作”模式和“菜单操作”模式。此外，图七左边是一个功能树，系统功能的切换是通过点击这个功能树来实现，我们可以把这个应用模式称之为“左树右表”模式。其他的当然可以有林林总总模式或方式来实现。

关于对应用模式的抽象，笔者认为能够实现对功能抽象而把具体的实现方式剥离出来就是个很大的进步。面对不同的应用，不同的技术实现，我们如果能够把应用系统的功能本质抽象出来，那么现有不同的应用之间就会有足够的“共同语言”。而界面怎么样的布局，具体的实现方式其实不是问题的本质方面。一句话，具体的实现方式不是最重要的，但如果两个应用具有相同或相近的应用模式，那么他们在重用或融合过程中会“比较方便”。所以，我们也会在可能的情况下，尽量在大量的应用模式中，提炼那些应用面最广的一些模式。并尽量固化下来，作为我们未来描述应用的标准语言。

4、总结：上述关于对业务系统抽象的分析，其中：对应用系统功能的抽象，回答了一个应用功能是干什么的问题，这对于现有成千上万个应用来说是确定的，即：无论什么类型的应用，其本质上都是实现对某类对象信息的增、删、改、查等功能；对应用模式的抽象，回答了一个应用功能是具体怎么实现的问题，这对于现有应用系统来说是不确定的，即：同样的功能不同软件系统实现的方式千差万别，我们很难穷举，似乎也没必要；对实体的抽象，回答了应用系统操作的目标对象的问题。有了这些抽象才能形成对应用系统的标准的描述。才能最终形成现有功能的重用和融合。鉴于不同观察者的思维方式肯定会有很大的不同，所以抽象的具体方式方法上也会有很大的差异，但笔者认为这里所描述的抽象方法与其他的抽象方法应该会有相似之处，因此在这里分享出来供大家参考和借鉴。

产品设计需要结构化

从上述关于对现有应用系统业务抽象的分析，可以导出本文的一个重要观点：产品设计结构化。我们现在对于产品的设计或者说做产品需求描述的时候，主要是由产品经理用原型工具画产品的原型，并基于原型来详细阐述系统的各个交互功能和界面的响应，并通过原型来具体描述界面的布局。这样的产品设计模式，让产品经理们都各显神通，想尽一切办法，学习一切能力来把产品表达得非常炫酷，但对软件产品的描述方式是千差万别的。这样的模式缺点也是很明显的：产品设计缺乏标准化的表达，也即产品经理缺乏标准的语言。这无疑使得融合现有的能力，快速交付不那么容易。此外，时间久了也很容易使得产品经理逐渐迷失自己，失去了对核心价值的把握。

那么怎么设计产品需求描述的“标准语言”以达成产品设计结构化的目标。笔者认为，这种标准表达的方法还是源自对现有众多的软件系统的抽象。因为基于这种合理的抽象后对产品的表达才能跟现有的系统有更多的“共同语言”，才能方便对现有能力的融合及快速交付。那么，基于对上述软件系统的抽象分析，我们自然的可以形成一套概念明确的、组件完整的支持复杂应用的产品设计方法，这里简单描述下其核心概念：

流程：各种软件产品其本质上是通过界面交互给使用者提供某种服务。那么这些服务都是通过使用者在应用界面的某些操作来启动的，最典型的就是点击某功能按钮、点击一个功能树的节点等等。我们把使用者通过界面操作而启动的系统服务称为流程。一个软件系统所提供的所有功能就是一系列流程的集合。如图：

图八

步骤：步骤是对流程的拆解。一个流程可以由多个步骤组成。步骤可以分为不同类别，可以是一个业务逻辑处理，可以是一个数据持久化操作，可以是数据查询，也可以是一个web界面服务。如图：

图九

从图九我们可以看到，对于一个ERP系统的入库管理功能，我们在产品设计时可以对其进行结构化的描述。用户请求入库管理功能后，会启动一个“入库管理”流程。这个入库管理流程由两个步骤组成，第一个步骤是一个业务逻辑处理，然后是返回一个管理入库单实体的信息管理界面，我们称之为信息管理框架。这里，笔者想表达下，按照这样的“流程-步骤”这样结构化的设计之后，带来的最根本的好处就是，这些步骤在中台可以方便的跟各种现有的系统进行一一对应和调用。

界面框架：众多的软件系统往往都是通过一定的用户界面来提供服务。以web应用为例，系统的最终结果都是通过一个web服务来展现。我们对众多应用的展现方式进行抽象和提炼，根据界面功能进行分类和总结，形成标准化的实现方式（或称为模式），并把这些界面方式称为“界面框架”。我们总结并提出了一些框架的概念，比如：信息管理框架、单据框架、参照框架、表型信息管理框架、树型信息管理框架、树表型信息管理框架等。如图：

图十

实体：本文在上面的章节中已经分析了关于实体的抽象。这里笔者的一个重要观点是系统的某个操作往往都是具体的实体相关的，所以在复用或调用时，直接的可重用性不是很高。如果某个操作能够跟所操作的目标实体解耦，那么直接的重用性是非常高的。这里举几个典型的操作的例子：关于某项业务的特有的业务处理，应该肯定是实体相关的，这里也不会有太多的重用的需求；关于数据的持久化操作和数据查询操作，中台系统需要下大力气开发隔离层来解耦数据持久化操作与持久化目标实体和持久化目的地；同理关于web服务，我们可以通过复杂一点的设计来解耦某个功能界面和所展示的实体，这样的好处是一次实现处处可用，可以达成快速交付的目标。此外，我们可以通过抽象出来的界面框架来表达和融合现有的应用。比如说，我们可以用一个标准的单据框架来调用现有的大多数的应用系统的单据录入功能。这里最本质的观点就是通过通用的、合理的方式对现有的应用进行表达，来实现融合。中台融合的概念不同于系统集成。

数据驱动的应用系统：结构化的产品设计带来的另一个特点或者说变化就是对于产品的设计本身也可以被结构化的存储，并且被另外一个解释程序来进行动态的解释和执行。这样的应用我们称之为数据驱动的应用，这区别于传统的代码驱动的应用程序，无论在快速构建、移植、融合以及技术无关等方面都具有巨大的灵活性和优势。

总结：结构化的产品设计不同于以往的产品设计模式，是以结构化的标准化的方式来进行产品定义，以数据驱动产品功能的产品运行模式。

中台的架构与实现

中台向前支持快速构建客户端应用系统，向后融合已有各类应用，同时根据需要支持中台自身各类数据的持久化。笔者基于产品设计、中台建设实践，提出中台逻辑架构，如图：

图十一

其中：

• 基础服务层：以服务的形式注册、管理现有的应用。我们首先应该对现有的系统功能增加微服务接口，这些接口是标准化的、无状态的RESTfull接口。对服务的描述包括网址、端口、参数及返回结果的详细说明。
• 融合层：融合层由实体管理器、应用设计器、应用运行时和服务网关构成。这里解释下应用运行时为对应用进行解释的系统模块，该模块按照系统结构化的标准规范对系统进行解析，调用相关服务，并将结果返回给用户。
• 持久化层：持久化层支持数据库、文件及内存的持久化。支持结构化数据和非结构化数据的持久化。
• 前端应用层：该层为向终端用户提供服务的各类应用。在创建各类应用的基础上逐渐会形成具有行业应用特色的行业化应用。

上述是对中台的逻辑架构的描述，具体的实现可以有不同的方式方法。笔者认为，系统的技术架构应该采用分布式的部署架构。因为中台生来就是要融合现有应用及能力。所以，我们要对现有应用进行微服务化的改造，应用的业务功能需要以微服务来表达。中台分布式系统可以采用不同的微服务技术架构来实现。同时分布式架构的技术特点在这里一样都不能少，比如对各类微服务的管理、消息中间件等技术。

基于中台的应用调用了现有的很多的应用功能，因此基于中台的应用其数据的存储也必然是分布式的。数据散落分布在原有好多业务系统的持久化层里，根据新建系统的业务需要也有些数据要存储在中台的持久化层中。关于中台的数据的规划与管理，目前的一些观点是规划并构建一个数据中台，该数据中台与本文所说的业务中台一起构成双中台。数据中台的典型功能是以数据仓库为核心包括对数据的垂直的抽取、数据的统一管理与查询等功能。数据中台支撑上层的数据产品与应用。此外，笔者认为中台的数据管理应充分遵循中台的数据分布式部署的特性，随着区块链技术的成熟落地，区块链或将在企业中台的建设中发挥基础性的作用。因为现有的不同的分布式的应用构成了天然的区块，这些区块纳入到区块链管理系统中，数据的去中心化管理、数据的一致性、数据的安全性等问题都将得到完美的解决。

开放式企业中台

至此，我们对中台做了很多的表述，我们知道它源自大型公司或有大量系统及数据沉淀的公司，那么它的理念、方法和技术自然而然的也是要服务于大型公司。可是众多的中小型企业怎么办？在能力上和大公司的差距越来越大，难道非要众多的中小企业各个都花巨大的投入来补齐这个IT的能力吗？笔者认为，不现实也不必要。未来应该由有这样能力的组织或机构充分贯彻中台的理念，应用中台的技术，跨越企业边界，搭建公共的企业中台来服务于中小企业。一个公共的、开放式的企业中台呼之欲出，因为广大的中小企业更加需要企业中台。

开放式企业中台本质上将是一个生态环境，在这里有服务提供者、服务的消费者、平台的运营方。中台有其演进和发展的过程，起初可能更多的涉及到中台的基础架构，技术相关的成分比较多，逐渐的随着中台同业务领域的结合，特别是在某些垂直行业的应用，将形成面向行业的业务能力。开放式企业中台是开放的平台，体现在，不仅仅面向广大的企业提供服务，同时公开的吸纳各类服务提供者参与到这个生态环境中来。因此，开放式企业中台无论在技术上还是业务能力上将不断得到优化和强化。