建设企业中台？你可能缺一个低代码平台！
00
引言
[中台] 是IT圈这两年热议的一个话题，与此同时 [低代码开发平台] 的概念也正在逐渐被关注。两个概念的兴起并不是一种巧合，他们都是由时代发展的趋势（人类技术与社会环境变化的速度不断被刷新，企业在史无前例的环境巨变之中面临越来越多的不确定性）召唤而来，他们都是为了解决 [快速响应] 而生。
中台是互联网行业为快速响应业务需求提出的一种架构思想，低代码开发平台则是为了简化和加速开发而形成的一种平台产品。本文将就中台架构思想和低代码开发平台在该思想中的定位与应用展开探讨。
01
中台架构思想
网上关于中台的文章有很多，各有不同视角和解读，个人推荐王健老师的《白话中台》系列和杨堃老师的《换个视角看中台的对与错》（顺便向大家推荐杨堃老师的《决胜B端》，虽然不是写中台的，但对企业级产品设计与架构的从业者还是会有很大帮助的）。《白话中台》系列比较系统全面地对中台作了解读，侧重底层原理与定义；《换个视角看中台的对于错》则是从三个不同的视角探讨了中台建设不同的目的、挑战和建议。以下是本人综合参考各家观点后的个人理解与总结。
1.1 为什么要建设中台？
2015年阿里受芬兰Suppercell游戏公司启发，提出了 “大中台，小前台” 理念对阿里进行组织升级（不仅仅是技术架构），这是当下热议的中台话题的起源。如果追溯与中台类似的思想，与之有关的还有海尔的自营体，华为的“让听得见炮火的人呼叫炮火”，这些思想都源自类似的背景与目的。
【背景】 - 企业内外环境的复杂性和变化速率不断提升，原有的组织方式越来越难以应对这些变化，导致前端/前台（泛指接近客户、业务和需求的一端）无法作出快速响应，最终可能导致企业走向失败。
【目的】 - 通过组织结构调整，提高前端/前台的灵活性和响应能力。
最初，这些思想主要针对组织层面，当阿里提出 “大中台，小前台” 理念后，这一思想开始向IT架构层面延伸。作为互联网企业，IT系统建设需要应对的变化和响应度相较传统企业更高，矛盾更突出，因此由阿里这样的企业提出中台架构思想也在情理之中。但并不意味着其他企业不适合这种架构思想，因为大家所处的时代背景一样，提升前台响应能力的需求也一样，所以具有同样的借鉴意义。
1.2 如何定义中台？
中台的定义，众说纷纭，个人比较认同《白话中台》中的观点：中台就是 企业级能力复用平台。另外一个形象的比喻是：中台好比是前台与后台间的变速齿轮，调和了前后台步速的矛盾，解决了前台对高度灵活性和快速响应的需求，也满足了后台稳定性的要求。
关于前后台的定义是相对的，不同的视角，或针对不同的对象定义都不同，总体而言，前台是偏发散的，多交互的，更动态和活跃的那端，后台则是偏收敛的，较稳定的，更静态的那端。
例如：从IT系统角度来看，与用户交互的一端是发散的，属于前台；服务器，数据库一端是收敛的，属于后台。
前台是发散的一端，是运用与演绎，后台是收敛的一端，是归纳与抽象
无论你用PC，小程序还是APP，无论用户来自哪个地方，交互形式如何，功能如何，最终都会收敛成服务器端数据库的数据或文件。IT架构就是从前台到后台的路径规划与设计。
当前台有不同的运用与演绎需求时，需要开通不同的路径抵达后台，如果每个需求都是由前台单独开辟一条专线直达后台，那么建设成本和周期都会很高，这时重合度最高的部分就可以合并建设为主干线，重合度低的部分就是支线。
【传统前后台模式】 - 全专线模式
【理想型中台模式】 - 主干网 + 支线模式
【现实型中台模式】 - 主干网 + 支线 + 专线模式
主干线的汇总就是主干网，主干网的作用与定位就是中台。
另外Gatner在2016年的《Pace-Layered Application Strategy》报告中，提出的步速分层（Pace-Layered） 理论与当前的中台理论是异曲同工。SOR(Systems of record )，SOD(Systems of differentiation)和SOI(Systems of innovation)分别对应后台，中台和前台。
1.3 中台如何建设？
建设中台时，以 企业级能力复用平台 这样一个定义作为指导会比较清晰。主流观点认为中台分为业务中台，数据中台，技术中台，研发中台，组织中台等：
业务中台：提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力，为战场提供了空军支援能力，随叫随到，威力强大；
数据中台：提供数据分析能力，帮助从数据中学习改进，调整方向，为战场提供了海军支援能力；
算法中台：提供算法能力，帮助提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
技术中台：提供自建系统部分的技术支撑能力，帮助解决基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
研发中台：提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付，是前台特种兵的训练基地；
组织中台：为项目提供投资管理、风险管理、资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。
字典中台：为项目提供国际、国家、业界等标准规范字典并保持及时更新
我们建设中台需要把所有这些都建立吗？当然不会，企业可以根据自身情况，酌情分步建设。以上分类个人认为只是提供思考和分析框架，他们之间本身可能是相互融合，由不同的产品与技术集成在一起的一个大平台。其实真正的核心就是业务中台或应用中台更准确，其他均是从其他专业视角或维度，直接或间接支持他的。
中台到底改如何建设？个人按前面的主干网+支线+专线的模型（以下简称“主干网模型”），提供以下思路供参考。
在主干网模型中，每种能力需求构成一条道路需求，因此一个前台应用一般都由多条道路支持构成。主干线的建设归属中台团队，支线的建设归属前台应用团队，专线的建设视情况确定归属。
企业建设中台是一个长期的过程，这个过程中主要面临两类建设任务，一是改造，二是新建。
改造项目：将原有的专线分析梳理，确定出若干个主干线，组成主干网（能力复用平台），弃用部分原有的专线，新建支线接入主干网，同时保留部分专线（个性化需求，暂不适合或无法抽象复用的能力）。
新建项目：根据需求分析需要建设的道路数量，可以借道主干网的，只要建设支线即可。有些需求比较个性化则直接建设专线。还有些需求有一定通用性和复用性，主干网里还没有，那么可以分段建设，主干线由中台团队建设，剩余的支线部分由前台团队建设。
在中台建设过程中，许多人都谈到了团队分工界面与建设效率的问题，这种矛盾多半发生在新建项目中。前台团队识别一部分能力属于复用能力应该由中台提供，但当前中台不具备，这时需要中台新建（或调整）此能力，但中台团队的建设速率天然要比前台团队慢（因为中台的变更和建设需要评估更多的影响），加上中台需要同时处理来自不同前台团队的需求，此时就可能出现拖累前台团队开发的情况。此时，有人会说搞了中台怎么反而让前台不灵活，变慢了。
如果能清醒的认识，中台建设是一个长期的过程，而且是更加侧重面向未来的，那么以上问题就相对容易解决。
在主干网能力还不够完善时，他的支持能力自然是有限的，出于快速响应需求的角度，既然建专线可以更快，当然可以允许先建专线，将来再改造即可。
但既然识别这是未来需要改造的项目，那么可以考虑事先留好交接点，交接点前端的部分是将来的支线，将来会完全保留，不需要再改造或新建。后端将来会被主干线替代，可以尽量低成本方式建设，只要能走通即可。
中台建设核心的挑战在于合理规划主干线长度和建设时机。主干线长度对应的是抽象度：主干线短，抽象度高，复用性强，但支线路就越长，前台建设量大；主干线长，抽象度低，复用性弱，但支线可以更短，前台建设量小。
这种尺度的拿捏取决于中台架构者的把握，所以人才是决定中台建设成败的关键。除了人才，合适的平台型产品也可以很好地助力中台建设，近期渐热的低代码开发平台应该就是一种不错的选择。
02
低代码开发平台
2.1 低代码平台的前世今生
低代码开发平台（Low-Code Development Platform）最早由全球知名的研究机构Forrester提出，Gartner则以全民开发者（Citizen Developer）概念从另一个视角阐述对企业级应用开发趋势的观察 —— 低代码开发平台将赋能组织与个人，大幅提升应用开发效率，业务方/需求方，领域专家（非专业IT人员）也有能力直接参与应用的构建与开发。
低代码开发平台的本质是对程序开发过程的重构，将可读性差，只有经过专业学习和训练才能掌握的代码编程开发模式，变成可读性强，可视化的，普通人都能掌握的配置 + 片段代码开发模式。
当年Windows通过图形化操作替代DOS代码指令，将操作系统普及，使得计算机成为每个人都能操作的工具。21世纪进入互联网时代后，计算机不再仅仅是一个单体工具，他更重要的身份是各类系统或应用程序的终端。整个社会对应用系统的需求急速增长，从而也不断推动着开发模式的变革。
人们从开发的组织与管理模式（例如敏捷理论），开发语言，开发框架和开发平台等各个维度在寻求开发效率的提升与突破。低代码开发平台有点像当年的Windows，旨在通过更加简单易懂的操作模式，降低使用门槛，让更多人可以直接参与系统开发，减少需求方与开发者之间的沟通损耗。
低代码的概念虽然这些年才被提出，但其思想实践却由来已久。从广义来讲，Office套件中的EXCEL和ACCESS应该算是最早的低代码平台，普通人可以用一部分功能，复杂点的通过函数或SQL实现，再复杂点的可以通过VBA编程实现。
与“低代码”一起常被提到的一个词是“无代码”，无代码的概念其实是早于低代码，曾经有很多产品都宣称自己是无代码开发，现在看开，用”低代码“才是更准确和更现实的。低代码首先必须包含了无代码的特征，否则它就是仅仅是一个程序员才能用的开发框架。但如果完全是无代码，那么它必然就成了一个封闭的系统，失去了更大的灵活扩展空间和对外交互集成能力。
当前市场上的低代码开发平台产品大多来自以下几个方向：
第0类：原生的低代码开发平台玩家，早于低代码概念被提出前就在此领域深耕。由于无法被用户识别，可能曾用无代码，快速开发平台，甚至以下面第1类的流程产品的名义面向客户。
第1类：由传统BPM/工作流产品升级转型（无代码部分的能力突破了流程约束，可以覆盖非流程化的，松散型的功能点开发）而成。
第2类：已经具备一定规模，产品较成熟的SaaS厂商，基于解决客户定制化需求而研发的aPaaS。
第3类：以轻量的前端表单场景切入，基于用户累计过程中逐步完善后端能力的aPaaS。
以上第0类和第1类的产品更适合打造企业中台。
2.2 低代码平台带来了什么改变？
引入低代码开发平台，企业将从以下几个方面获得收益：
【赋能企业创新】 - 更多创新可以快速上线，试错和迭代
【减少信息孤岛】 - 各专业领域的应用可以基于统一的平台构建，或与统一平台集成互通（把烟囱式应用移植到同一平台）
【提升系统稳定性】 - 更少的代码，更少的BUG
【降低系统总成本】 - 同时减少建设成本（人工，时间）和维护成本，提升系统可维护性（降低人员流动对系统的影响）
另外，低代码开发平台最重要的意义是改变了应用程序开发过程的分工模式，大幅降低了开发阶段中专业开发资源（编码开发人员）的配比，开发速度得到前所未有的提升。
低代码开发平台将业务功能构建与技术实现作了更合理的分工。业务功能构建不再依赖编码技能，而是基于平台预置的可视化组件，通过拖拽配置（即无代码开发）实现，当业务功能构建缺少某个组件能力时，则通过片段代码或者补足组件（即低代码开发）。
传统的开发模式，可抽象为三类角色的分工 - 业务专家（不一定是业务人员，代指准确掌握需求的人），PM（项目/产品经理），技术专家（代指所有资深的和不资深的编码人员），其典型开发过程简化描述如下：
1. 业务专家：将业务构建的需求描述给PM
2. PM：理解消化后转述（不管是口述还是文档）给技术专家
3. 技术专家：实现业务功能构建
4. 业务专家：核实业务功能构建是否正确
5. 业务专家/PM/技术专家：业务专家说：“这不是我想要的”，之后开始修改N轮，期间可能出现无数次互撕，项目可能就此失败
6. 运气不错，应用程序胜利上线
当然上线后也有问题，需求发生变化时，需要重走以上流程，此时PM和技术专家可能都已离岗或离职，谁也无法再搞清之前系统的情况了，维护也无从谈起。
采用低代码平台的开发模式，业务专家和PM角色可以合一，比如叫作 应用专家（对应前面提到的Citizen Developer），业务功能构建不再交由技术专家，而是直接由应用专家完成。技术专家退到幕后，并不直接参与业务构建，仅仅是为应用专家提供技术支持。
上图是对两种开发模式简化的对比模型（数字为虚拟假设，重点是说明成本结构的变化）：
低代码平台模式开发总成本可以大幅降低，主要来自于
1. 项目中的沟通成本减少（角色精简，重复投入减少）
2. 开发和技术支持成本的减少
开发和技术支持在项目总成本中的比重降低，需求调研与设计占据更多的比重——创造性工作比例提升
设计和开发的过程主体担当者发生根本性的转移和变化——岗位能力要求更科学
在此模型中，应用专家是系统建设的主力，他可以从需求调研到系统开发构建一贯到底（此处忽略初级应用专家与高级应用专家组团合作的细节，简单视作一个角色）。
在传统开发模式下，这种一贯到底的专家是极其稀缺的。首先他必须经过长期的代码开发训练和实战，积累足够的代码开发能力，其次，他必须对业务熟悉，有业务经验还能懂管理。
但是有了低代码开发平台，应用专家的角色就不再局限与从专业代码开发人员中产生。任何能准确把握需求的人员，具备一定的逻辑能力，稍加学习都能扮演应用专家的角色。一般初步掌握一个低代码开发平台在1周以内，通过1-2个应用开发即可达到中级水平，想成为更高级的应用专家，具备复杂架构能力则取决于个人能力的差异了。
代码开发人员则不必关心业务逻辑，他们只要专注技术能力的支持，在当前低代码平台封装的技术能力（标准组件）无法满足应用专家开发需要时，他们提供技术能力的支持即可，业务功能还是由应用专家把控。
低代码开发平台下，应用专家+技术专家模式是一种全新的分工模式，可以更合理，更高效地组织应用开发。但是当前企业转型到这种模式可能还需要一个长期的过程。
因为由业务部门转岗为应用专家这种成长的线路，短期内暂时还不太会被企业意识到和采纳，只有当低代码平台普及到一定程度，这种全新的岗位角色才会得到充分识别和单独组织管理。
最后，有一点需要澄清，低代码平台可以极大的帮助企业提升应用开发效率，但它并不能解决需求梳理，分析，规划与设计的工作。如果一家低代码开发平台厂商告诉你，使用他们的平台可以提升5-10倍开发速度，这个可以信。但是如果他们告诉你项目周期可以从6个月缩短到1个月，那你要好好掂量一下了。因为真正的开发工作，一般仅仅占整个项目1/3 - 1/2，其余的时间为需求调研，分析，设计和测试。这些时间并不是低代码平台可以节省的，能力出色的应用专家可以帮助企业压缩这部分项目周期，但也需要一个基本合理周期（尤其是甲乙方合作模式）。
2.3 如何用低代码平台构建企业中台
低代码平台本身是技术中台，可用于搭建业务中台
对照前文所述的几类中台，低代码开发平台本身对应技术中台，是技术中台的一种工具选择，通过它可以高效地搭建业务中台。不同于其他技术中台，低代码平台可以让企业更加轻松的驾驭，即使没有充足的专业技术资源（程序员）同样可以建立自己的业务中台。
上图引用自维略信息 JOGET DX产品介绍，我们以此为例，介绍如何利用低代码开发平台构建企业中台。
总体而言，我们将从以下三个方面展开中台建设：
1. 连接：低代码平台与企业已有系统的集成
2. 抽象：低代码平台业务复用能力的构建
3. 运用：基于低代码平台新建应用
以上三个方面并没有先后的依赖，企业完全可以根据自身情况逐步迭代完成，这也是低代码平台作为技术中台构建业务中台的优势之一。其中第2部分“抽象”是业务中台成功与否的关键，这部分如前文提过的，更加依赖成熟人才对业务抽象颗粒度的把握。
2.3.1 低代码平台与企业已有系统的集成
通过低代码平台与企业已有系统的集成，可以解决业务中台与已有系统的连接。系统集成通常分为用户集成和数据集成。用户集成可以由低代码平台分别与各系统对接实现SSO，也可以通过第三方统一身份认证服务平台对接，甚至可以基于低代码平台构建统一身份认证服务。
数据集成也可以有多种方式实现，可以通过数据库层或API接口实现，具体根据需要接入的系统实际情况决定。因为企业现有系统可能是私有部署的标准产品或原生开发的系统，也可能是租用的SAAS系统，每个系统能够支持的集成方式各不相同，甚至有些系统根本无法提供集成接口。这时用采用RPA实现集成也是一种行之有效的方案，具体可以参考上一篇《低代码平台+RPA+AI，从ERP到数字化转型》。
2.3.2 低代码平台业务复用能力的构建
业务复用能力的抽象是最难也是最具挑战的工作，期间不仅面临抽象颗粒的决策，还面临不同实现方案的抉择。我们以抽象统一客户视图为例，可能的做法有多种。假设当前企业的CRM和ERP系统都有客户信息，现在希望中台提供一个统一客户视图，供其他新建的应用系统使用。
方法一：不管新老系统，均切换到中台的统一服务
将CRM和ERP两个系统的客户数据汇总后，导入低代码平台，由低代码平台提供统一的客户视图服务，原CRM和ERP系统都统一调用低代码平台的服务，未来新应用系统也都统一调用低代码平台的服务，这是最理想的模式。
但事实原有的CRM和ERP一般都是第三方提供的标准产品，这种改造是难以实现的。即便原应用是自研开发，技术可行，但由于涉及的功能改造太多也不太具备可行性。
方法二：老系统自身功能不变，将老系统客户数据同步到中台，新应用采用中台的统一服务
将CRM和ERP系统的客户数据分别同步到低代码平台，根据两个系统客户数据的唯一性规则，将客户数据合并，形成中台统一客户视图。如果新应用系统也会产生新的客户数据，则需要在低代码平台增加向CRM和ERP系统反写客户数据的接口。
上述从CRM和ERP同步数据到低代码平台和从低代码平台反写客户到CRM和ERP系统的方案又有多种技术方案。每种方案对应的稳定性，数据时效性和系统性能表现都不同，需要架构设计者结合实际情况作出合理的设计决策。
方法三：持久化的客户数据统一留存在一个老系统（比如CRM系统），由中台调用CRM客户数据为其他应用提供服务
这种模式下，统一客户视图的能力其实在CRM中，中台则扮演了一个能力路由的角色。中台同时负责其他老系统与CRM的同步衔接和新系统的能力服务。这种模式下，新系统调用中台接口，由中台统一向CRM接口请求，处理后再由中台反馈给前台新系统。老系统的同步衔接则有更多可能的技术方案去实现，情况类似方法二。
以上，简单探讨一下低代码平台构建业务复用能力可能的方式，企业实际建设过程中远不止以上三种，本文不再展开赘述。
2.3.3 基于低代码平台新建应用
基于低代码平台新建应用大致可以分为两类，一是直接在低代码平台上创建应用，二是以前后端分离模式开发，低代码平台提供API支持。如前JOGET DX中台架构图中，一种是右上角绿色的前端应用是直接基于低代码平台构建的，另一种是中上青色的前端应用则是通过低代码平台提供的API支持构建的（比如小程序）。
举个例子，比如公司想建一个卖产品的小程序，产品数据已由低代码平台从ERP系统获得，然后通过API提供给小程序端。客户下单后，客户信息会通过低代码平台写入CRM系统（假设客户数据按上述方案三执行），订单数据则通过低代码平台驱动RPA机器人录入ERP系统。
03
总结
如果您的企业正尝试以中台思想构建应用体系，低代码开发平台是一个非常值得尝试的选择，他可以帮助企业在最小的资源投入下，逐步建立业务中台。但也并不是所有低代码平台都适合用于企业中台建设，在选择平台时应重点考察以下几个方面：
良好的集成性：尽可能多的标准化集成能力（与市场主流产品的用户集成，与专业系统的标准化数据集成接口）
开放性和可扩展性：作为技术中台应该有很好的开放性，便于集成各类新技术，同时提供插件架构，便于技术能力的扩展
强大的接口开发与管理能力：除了具备在自身平台上快速开发应用的能力，平台应该具备便捷的接口开发能力和完善的接口管理能力，从而可以支持更多传统代码开发模式的应用中台（企业内部API集市）。例如，一般的接口可以通过无代码方式定义，个性化和复杂逻辑的接口可以用厂商中立的技术以低代码方式开发。另外，平台可以将相同的接口分发给不同的前端应用使用，并且有完善的接口日志管理支持。
应用性能管理（APM）能力：作为企业中台需要支撑众多应用运行，因此低代码平台应该同时具备应用性能管理的能力。因为作为开发平台，上面任何一个应用的设计/开发缺陷或应用场景的突变都可能引发平台的故障，这时就需要平台有性能监控预警和故障排查能力，才能确保平台的稳定运行。另外DevOps，云原生等特性也需要一同评估。
未来中台架构思想还会不断迭代升级。但无论基于何种理论或思想，低代码开发平台都会实实在在地带给企业数字化转型的便利，它也许会成为继ERP之后，企业信息化又一个划时代的产品。