译 / 阿里淘系F(x) Team  - 卓风

原文链接 ,  原文作者： Jason Wong, Mark Driver, Paul Vincent

低代码应用程序开发(LCAP) 不是什么新鲜事，因为数字颠覆上的融合就已经导致了这类工具的涌入，来满足日益增长的需求。这份研究报告可以帮助应用程序负责人了解各种低代码工具和市场情况，辅助其做好选择。

总体概要

主要看点

• 200 多家供应商按“低代码”开发工具销售他们的产品，范围从简单的表单创建到全栈应用程序平台。这些供应商，作为多维市场的代表，为他们的客户提供了快速应用程序开发(RAD) 的体验。
• “0 代码”开发产品属于这种低代码工具范围，主要面向业务领域中的“非编程人员”（非专业开发人员，类似业务产品、运营人员等无实际编码经验的人员）。
• 现有的 PaaS 和 SaaS 供应商都将低代码开发作为趋势首选，甚至企业也经常使用多个低代码产品来满足不同的需求。比如：业务规则管理系统(BRMSs)、业务流程管理系统(BPMSs)、多维体验开发平台(MXDPs) 和 低代码应用程序平台(LCAPs)。
• 低代码开发目前还是用于面向企业内部员工(B2E) 的应用程序开发为主，但是随着用户体验(UX) 质量的提高和新型授权模式的放开，低代码开发也正在扩大到对 toB 和 toC 的应用场景支持。

推荐做法

为了最大程度地发挥低代码的优势，负责应用程序开发和平台策略的应用程序负责人必须：

• 对应用场景进行分类，以识别适用于低代码开发的场景，然后选择合适的低代码工具。最好选择那种对于开发人员技能要求不高并且对产品上市时间有缩短的场景。
• 给“非编程人员”提供内部有保护机制的低代码开发工具，以确保 IT 和业务方都能获得必要的监督性保障。
• 在尝试使用现有 PaaS 和 SaaS 产品中的低代码开发工具时，不要试图消费其能力范围之外的服务（这已经不在低代码能力范畴了）。
• 在面向外部的应用场景部署低代码应用程序时，要确保工具的授权模式符合 ROI 和业务价值预期。

战略规划设想

到 2024 年，低代码应用程序开发将占应用程序开发的 65％ 以上。

到 2024 年，至少有 75％ 的低代码应用程序开发工作将集中在中小型项目里，来支持非核心的工作内容。

到 2024 年，有 75％ 的大型企业将至少使用四个低代码开发工具进行 IT 应用程序开发和非编程式开发。

分析报告

引言

应用软件开发的生产力对于业务个性化和敏捷性至关重要。用于创建应用程序的技术也一直至关重要。然而，随着数字业务的兴起，需要在新环境中及经常瞬息万变的情况下实现新老流程的自动化的软件生产需求不断增长。这给 IT 负责人带来了巨大的压力，要求他们急剧地提高应用交付速度，增加价值时间。

供应商们给出的是这种低代码解决方案：通过减少或规避对专业代码（需要稀缺的企业 IT 开发人员支持）的需求依赖，来提高生产力。高德纳(Gartner) 公司正在针对这个领域内的 200+ 家供应商展开持续调查。

这份研究报告通过一种简单的模型，来辅助应用程序负责人理解供应商的三个基本部分，以及确定在选择工具时要评估的特征。

当今低代码开发技术的演进

低代码开发并不是新概念了，从很多方面来说，这个术语是 1980 年代引入的 快速应用程序开发(RAD) 工具的现代别名。这些工具的引入是用来替代传统基于文本的开发平台。早期的 快速应用程序开发(RAD) 工具关注于快速的、可迭代的开发方式（而不是传统的瀑布式方式），通过降低对整体开发人员的技能要求，来获得有约束性的功能、用户体验和性能表现。它们与同时代的其他变革（如，集成开发环境(IDE)、图形用户界面(GUI)、网络和 C/S 架构）一同迅速发展。特别是，早期的 快速应用程序开发(RAD) 工具发展了可视化的拖放机制、数据与行为的图形化模型、架构规范性的框架和模板化的组件。快速应用程序开发(RAD) 能力几乎很快就传播到了所有分布式开发平台。

在此期间，某些行业标准的可视化模型得到了发展，特别是对于应用程序的（如：数据的实体关系、对象管理的类图、流程流的流程模型和状态机的状态转换图）。这些催生了一个模型驱动的应用程序平台市场，典型代表就是 业务流程管理系统(BPMSs)，它的产生源于用于自动化业务操作和案例管理(包括人工工作流)的图形化开发流程。

今天的 业务规则管理系统(BRMS) 市场也有类似的发展，但也是从 快速应用程序开发(RAD) 原则和 AI 驱动的专家系统结合而来。新兴的 决策管理套装(DMS) 市场在持续采用这种结合产物（如最新的 DMN 决策模型）。

低代码应用程序开发的重要里程碑是 web （用于支持对应用程序的分布式访问）和云（用于标准化部署机制，支持将应用程序开发工具作为 PaaS 的顺滑体验）的出现。

这就催生了应用程序开发工具市场的两个分支：

• 快速应用程序开发(RAD) 供应商自动化了应用程序部署过程，以减少 IT 开发人员对应用程序交付的参与。在他们的云产品中，他们的应用程序可以通过相应的最小 IT 操作介入来交付。
• 主流的 SaaS 供应商利用低代码使客户能够对其平台进行自定义和扩展。 然后，他们逐步成为 SaaS + PaaS 供应商，为开发人员提供用户型业务应用程序和工具来构建新的应用程序。

如今，使用低代码开发技术（即“非编程开发”）来赋能员工来支撑大规模的部门和工作组应用程序开发（见图 1）已成为数字办公协议中的一部分。 只有“极端规模”（例如，依赖于自定义微服务）或需要专业 IT 开发能力的应用程序才处于低代码工具能力边界之外。 工作组(Workgroup) 应用程序始终是使用非编程开发工具（例如电子表格）交付的。 由业务线部门开发人员负责构建的应用程序领域已成为低代码开发工具的增长领域。 而且低代码功能性的增加也促使其成为企业平台的替代品：低代码工具继续攀登应用程序领域的金字塔。

图 1：应用程序金字塔

源：Gartner (2019.2)

高德纳(Gartner) 报告已经涵盖了在 快速移动应用程序开发(RMAD) 工具加持下的作坊式移动应用程序的低代码开发场景。 而且报告显示，“0 代码”开发工具正在向业务线销售，以使他们拥有自己的数据应用程序。 其理念是通过赋能和促进非编程开发的发展来使应用程序开发民用化（大众化）（即降低应用程序开发门槛）。

然而，从某些情况下来看，面向具有最低技能的非编程开发人员的“0 代码”工具，往往最终是依赖培训过的 IT 人员来开发的。因此，我们认为“0 代码”工具是更大的低代码工具市场的一个子集，尤其是在一直致力于解决非编程和专业开发者问题的企业级低代码平台场景下。

在应用程序开发之外，其他特定技术领域也在通过低代码方式使他们的开发人员民用化（大众化）。 例如，以集成 SaaS（iSaaS）为例，大多数供应商都提供了简化的集成开发方案，以使非专业人员可以快速集成。

低代码开发的重要性将持续增长的原因是：

• IT 和 业务部门在快速、可持续和敏捷式的开发实践中需要紧密合作的诉求，包括 数字运营(DigitalOps) 和 Mode 2 系统的变革
• 提高生产力和应用程序现代化输出能力的诉求
• IT 开发技能供需之间不断扩大的差距
• 为了满足数字化业务活动的需求，应用程序的复杂性也在不断增加，催生了更高程度的开发抽象

IT 为企业交付所有应用程序的时代已经是一去不复返了，眼下和未来，看中的是将独立式的企业 IT 和“影子 IT”进行消除，并将业务与 IT 团队进行整合，通过两者的协同实现数字产品的完整交付。低代码开发恰好是实现这一点的关键因素。

低代码开发技术的分类和评估

应用程序负责人必须意识到，低代码开发技术并不代表一个单一市场（请参见“实验依据”章节）。 相反，低代码涵盖了一系列软件开发特征，而且这些特征又以多种方式在诸多潜在细分市场中催生了快速、可迭代的或敏捷式的开发流程。

技术和流程的结合往往会吸引这几类开发者：

• 可能具有有限的软件开发技能、经验或素质能力的开发者
• 承受着巨大的压力，需要尽快提供“最小可用”或“足够好”的解决方案的开发者
• 需要应对不断变化的需求能持续快速演进应用的开发者

高德纳(Gartner) 确认了涵盖了低代码开发技术领域的三个主要细分市场：

• 低代码应用程序平台(LCAPs) —— 这是一个新类别，涵盖了高生产力的应用程序 PaaS(HPaPaaS) 以及 RAD 和 RMAD 工具。它关注在通过声明式的模型驱动和基于元数据的服务来提供快速的应用程序开发、部署和执行。这个市场包括自描述的“0 代码”应用程序开发工具，并且总体上代表了低代码技术供应商的最大部分。
• 多维体验开发平台（MXDP） —— 这些产品为专业开发人员（有时甚至是非编程开发人员）提供了一套包含前端开发工具和后端服务的集成套件，从而可以跨数字触点(digital touchpoints) 进行相应用途应用程序的扩展性开发。 它们覆盖了自定义移动应用程序、响应式 Web 和渐进式 Web 应用程序(PWA)、沉浸式用户体验以及对话式应用程序支持。 低代码是这些平台中的一种能力，但其中也有很多平台支持或提供代码 IDE。
• 流程和业务规则/决策管理系统——这类模型驱动的（因此是低代码的）开发平台可以在操作模型和程序时进行动态变化。 他们通过流程(BPMS) 和业务规则/决策(BRMS / DMS) 实现了业务操作的自动化。高德纳(Gartner) 的研究范围也扩大到了 智能业务流程管理系统(iBPMS)，包括了可持续的智能和动态流程管理系统(BPM)。 尽管“模型驱动”意味着“低代码”，但其中一些可以实现复杂的流程和决策的模型既复杂又专业，这可能需要相关专家协助才能进行开发。

在这些市场的诸多地方，包括 SaaS + PaaS 平台在内，确实出现了一些供应商以及开发工具。 因此，应用程序负责人需要在数量激增的平台与能提供最满足特定需求的供应商之间平衡好选择。 对于企业来说，在混合式应用程序平台的产品组合中使用这些市场中的五到六家供应商是很常见的。

针对这些典型的低代码平台，典型的选择决策过程如图 2 所示。

图 2：低代码开发分类决策树

源：Gartner (2019.2)

根据 高德纳(Gartner) 的经验，以下标准可以区分工具类型的选择：

• 是否需要在没有专业开发人员协助的情况下进行“非编程开发”？如果是的话，可以考虑一个具有“0 代码”能力的 低代码应用平台(LCAP)，但是要注意工具的能力范围，它们是专门为非编程开发人员设计的。
• 是否需要可持续更新的、复杂的和可管理的业务流程或决策（包括案例管理）以及相关的供应商技能和流程与决策建模的协助？ 如果是，请与供应商提供的流程或决策专家一起考虑使用 智能业务流程管理系统(iBPMS) 和/或 业务规则管理系统(BRMS) 或 决策管理套装(DMS)，但要清楚低代码的某些好处可能会在这些工具中受到限制，并且代价可能很高。
• 是否需要跨数字触点（digital touchpoints ）(例如，移动应用程序、渐进式 web 应用程序、聊天机器人)的多种应用程序类型？如果是，请考虑使用低代码的 多维体验开发平台(MXDPs)，以便跨多种交互模式扩展或增益应用程序用户体验。
• 对于所有其他业务应用场景，请考虑一个 低代码应用平台(LCAP)，它可以在一款工具中提供给你部分或全部流程自动化，满足用户体验需求，同时具有非编程开发能力，并且关注的是交付时间而不是绝对性能。

低代码开发工具的特征是什么？

对于供应商提供的所有类型的低代码开发产品，可以根据几个主要特征来进行考虑(参见图 3 )。这些特征就是构成了低代码工具和平台的主要评估标准。应用程序负责人可以根据每个特征对其功能能力的需求进行评分：

• 部署类型 - 用于给一两个开发人员体验和部署的工具可以是本地的，也可以是云化的或 PaaS，或两者都有。同时也要考虑是需要特定的云还是多个云。
• 开发人员角色 - 是为 快速应用程序开发(RAD) 物色的专业开发人员，还是普通技术开发者（例如，具有 IT 意识的业务分析师）或普通业务开发者（需要“0 代码”方式辅助），亦或是其某种组合。
• 前端vs.后端 - 对于一款全栈式应用程序，是仅需要新的用户体验设计，还是新的后端处理流程，抑或两者都需要？后端流程自动化可以包含工作流程，也可以从被监管的 业务流程管理(BPM) 式的流程设计和交付方法中获益。
• 用户体验 - 用户体验的复杂性是必需要考虑的，对于所有应用程序来说复杂性都在增加，尤其对于 B2C 应用程序更甚。对于以多模态用户体验为重点的场景，多维体验开发平台(MXDP) 方式可能是最好的，而对于内部 B2E 应用程序场景，简单的基于 web 表单的方式也就足够了。
• 服务复杂性 - 应用程序可以对数据进行创建、读取、更新、删除(CRUD) 操作，也可以对来自多个服务的操作进行集成或组合，包括驱动流程的事件处理和消费。
• 市场焦点 - 当许多工具还集中在通用领域的时候，某些工具随着相关 SaaS 的应用或简单的客户群体演变，越来越聚焦在 ERP，CRM 和供应链等专业领域上。
• 生态系统和合作伙伴 - 由于许多平台选择者对平台的能力普遍要求较高，因此一些技术特性可能不足以满足他们的诉求。 像本地支持、技能可用性和培训机会、应用商店和开发人员社区以及服务提供伙伴质量之类的问题就可能显得尤为重要。
• 治理和敏捷性 - 对于许多用户来说，度量业务 KPI 以及应用程序开发和资源使用情况的 KPI 的能力，是一种越来越大的优势。平台们正在开发一些能匹配 BPM 功能的可选功能，像记录应用程序目标、管理完整的应用程序生命周期等。
• 软件开发生命周期（SDLC）方法论 - 为应用程序开发过程乃至项目管理提供指导。AI 辅助开发也可能是种需要。

图 3：低代码开发工具的特征

源：Gartner (2019.2)

低代码应用平台(LCAPs) 代表了这些平台里最大的市场份额。低代码应用平台(LCAPs) 支持 快速应用程序开发(RAD)，使用声明性的高级编程抽象（例如，模型驱动和基于元数据的编程语言）进行部署和执行，以及单步部署。

它们相通的技术要素包括：

• 一个以模型/元数据为中心的 UI 层设计器，（至少）支持基本的 增删改查(CRUD) 应用程序设计，并且最好只需要很少编码或不需要编码
• 支持基本的数据结构定义和内置数据库的通用数据存储（如，RDBMS、NoSQL、flat文件）访问
• 通过 REST，SOAP 或其他 API，简化对外服务的访问
• 通过 API 包装它们的底层流程逻辑和数据
• 支持面向业务规则和常规业务逻辑开发的编码模型方法
• 足够的性能表现和操作延迟

企业级工具还应包含其他功能，例如：

• 用户密集访问量、数据存储量和高事务率的弹性伸缩能力
• 高可用性与容灾复原能力
• 应用程序访问，API 和数据存储的安全性
• 开发阶段（或云 PaaS 的运行时部署阶段）的 服务品质协议(SLA)
• 资源使用追踪能力
• 对开发人员和运营人员的技术支持能力

首字母缩略词和术语表

实验依据

高德纳(Gartner) 追踪了 200 多家低代码开发工具供应商。2018 年 11 月，我们对这些供应商进行了调查，发现在回应的 82 家供应商中（参见表 1 ），有 40％ 的低代码供应商，每年可以从超过 54,000 个最终用户组织中收取 25 亿美元的工具收入（包括许可和订阅） 。

在这些供应商中：

• 85% 的供应商认为自己是覆盖了用户体验、逻辑和数据的全栈，而不是专门处理应用程序的一部分
• 96％ 的供应商认为自己提供了完整的 软件开发生命周期(SDLC)，而不仅仅是设计和开发的加速器
• 88％ 的供应商提供了公有云部署，62％ 的供应商提供了私有云部署能力
• 84％ 的供应商提供了 WebIDE，30％ 的供应商提供了桌面 IDE
• 78％ 的供应商将数据库作为其工具的一部分
• 47％ 的供应商生成的代码在大多数情况下可以进行手工编辑
• 79％ 的供应商提供基于表单的用户界面，62％ 的提供移动应用程序界面，而 5％ 不到的提供了聊天机器人
• 95% 的供应商目标客户是业务线开发人员(技术型非编程开发人员)的前三个开发人员角色，而 40% 的供应商选择的头部开发人员角色是业务高级用户(业务型非编程开发人员)
• 在 top 3 的应用场景中，86% 的供应商目标应用场景是企业级应用开发，这也是 50% 的供应商选择的 top 应用场景
• 55％ 的供应商的主要终端用户类型是 B2E，而 B2B 和 B2C 的占比分别为 20％ 和 25％

调查的供应商列在表 1 中。

表 1：供应商调查问卷清单

源：Gartner (2019.2)