Gartner发布2019年低代码调研报告：从下往上

Gartner 在 2019 年的低代码调研报告中，制作了 “应用金字塔”：从下往上，分别为工作组级（Workgroup Class）、部门级（Departmental Class）、企业级（Enterprise Class）、可扩展需求极强的企业级（Extreme-Scale Enterprise Class）。它划分维度就是应用所面向的用户基数（基数越大，可扩展需求也越高）；从任务关键性（Mission Criticality）、复杂性（Complexity）来看，也是逐级递增的；从数量上来看，金字塔头部少，底部多；从上往下，各级别应用与低代码越来越契合（Relevant）。也就是说：越简单的应用，越契合低代码；越不太关键的任务，也越契合低代码。

低代码适应的第一类场景，也就是应用金字塔底部的工作级或部门级的应用脚本语言 银行 中间业务平台，这类应用一个茅草屋，构建简单，使用的材料都是很“原生的”（比如原材料之一茅草一般都是就地取材），构建工具也是简单的、初级的、容易上手的（使用简单的锄头、榔头工具即可，不像构建高楼大厦需要挖土机等重型机械），构建时间一般也是很快的（找几个亲朋好友帮忙，几天就完成了），使用的也很短（以前农村里面农忙晒稻子，用的时候也就一个双抢时间，1个月那样）。

顺着这个例子，低代码开发平台期望提供“盖茅草屋”一样效果：低能力、低成本、快速构建；比如现在新冠期间，很多班级要求每天要打卡，“打卡”小应用，功能很简单，每个家长每天反馈小孩的每日的地点信息，然后班主任获得班级的汇总结果；需要收集这个信息班主任是最清楚“要求”（也就是业务性需求），如果这个班主任有一定的计算机知识，他就可以开发这个小程序，构建这个小程序最重要的材料是“打卡”收集那些信息，这些业务规格班主任最清楚，是“原生”的，开发工具最好是打开他常用的浏览器（而不是要转一个python的工具安装包等），然后就可以编辑；开发工具里面可能要创建一个页面填充一个学生地点信息的表单（工具1：锄头），然后保存到网上（工具2：调用一个save接口，类似的锄头），然后就可以测试（工具3：），最后开发一个汇总页面；在这个过程中体会不到什么专业程序的（什么数据库、SQL语句等“重型机械”）；这个小程序是仅这个班级使用就可以，疫情结束就完成了。

第一类是低代码的应用场景没有争议，当前市场上绝大多数的低代码开发平台都是瞄准这个做的；作者认为，低代码还有第二个很重要的应用场景，也就是的应用金字塔提的可扩展需求极强的企业级（Extreme-Scale Enterprise Class），这个和Gartner报告提的不太一样。

可扩展需求极强的企业级的特点是满足的用户的基数大，用户基数越大，共性需求发货的价值越大，但同时意味着差异化需求的种类越多脚本语言 银行 中间业务平台， Salesforce CRM，就支持下列11个行业。

例如，支持中小企业的钉钉，它的定位是“让工作和学习更简单”，解决的企业中人的工作和学习事情，个性化的需求更强烈，也是一个可扩展需求极强应用。

从需求实现来看，可扩展需求极强的企业级一个重要特点是：在通用业务的基础上，能快速实现差异化需求，且通用功能能有效整合在一起；从系统架构来看，为了支持差异化性需求的，都有“平台”型应用特点（后面都叫业务平台），都支持差异化定制，为了支持更高效、更低成本开发和部署定制化部分，架构上特点都是：插件组装式架构。

举一个生活中的例子（如下图），整个业务平台就像是购物中心，从构建的特点来看，分成两部分，一部分是购物中心的主体部分（稳定不变），另一部分是购物中心里面的各个门店（琳琅满目）；但是从最终的使用来看，购物中心的主体部分和各个门店是融为一体（运行态）；从构建过程来看，先由专业的建筑公司（平台软件公司，例如：salesforce）的建筑设计师对一个购物中心进行总体设计，然后开始打地基、浇筑骨架、……，整个过程都有专业的工程队进行构建，一般周期时间比较长（在中国比较快2~5遍）。

整栋大楼构建好后，里面有很多未装修的门面；每个门店由门店经营者决定自己门店的风格（差异化需求），并自己请各种的专修公司（合作伙伴/ISV）进行装修，每个门店专修的进度是不一样都是独立交付的（独立设计、开发、交付）, 经营过程中，如果某个门店是经营不善倒闭了，门店就好转让给其他人，然后这个门面重新装修（独立可替换），门店装修时间比较短，几个月就可以。

装修公司在装修房子，不会破坏楼的主体框架（遵循平台的架构原则），如不能破坏承重墙，装修公司做的工作也相对简单，一般都是一个房间内部格局的重新设计，墙面的粉刷等（需求较简单），水电、网络等使用原来大楼提供的（调用平台的接口），仅考虑待专修房间的就可以，不需要考虑整栋楼的布局等。

从构建过程的来看，平台的主体部分构建复杂，时间周期长，需要“专业建筑”队构建，涉及到多种角色的协同，且要提前考虑好给各个门店预留接口；平台的定制部分构建简单，时间段，仅需要小的“装修公司“构建即可，一般专修公司构成简单，装修过程中需要遵循平台的设计规范。

理解了业务平台的构建过程，下面重点讲低代码平台在业务平台可能会发挥的作用，对定制部分，其特点要求速度快，那么低代码平台本质就是要提供一个让“专修公司”用得顺手的工具；怎么才算好用的工具的，我们可以先一下，当前几个复杂的“业务平台”在专修门店上提供的工具。

产品

特点

平台-主体语言

插件开发语言

插件开发工具

Salesforce

新兴企业软件

Java

Apex

应用开发平台

SAP

传统企业软件

Java/C?

ABAP

？

钉钉

互联网

Java/C++?/JS

JS

？

初步来看，这里低代码的几个特点：“受限开发语言”（和低代码第一类需求类似）、平台都要提供一套插件管理机制，和业务平台的深度集成（后两点和第一类需求不同）。

当前构建一个复杂的业务平台，插件管理的机制等是各自构建的，加上业务平台本身主体复杂，导致构建一个高度扩展的“业务平台”技术难度非常大，能否提供一个统一的低代码平台（组件），这也许是低代码平台有效发力点。

2021-2-16 飞戈

参考文档：

1.《什么是低代码（Low-Code）？》

xie.infoq.cn/article/f19c1d6b5c632bd3442de682a