数字化转型中的低代码评估与决策指南 | IDCF

导读

低代码大潮蜂拥而来！

• Forrester观点：“随着更多公司看到采用该平台满足其业务需求的好处，低代码市场预计2022年将增长到212亿美元。”
• Gartner观点：“84％的企业已在转向低代码，因为它具有减轻IT资源压力，提高上市速度并使企业参与数字资产开发的能力。”
• IDC观点：“到2024年，低代码将占所有应用程序开发活动的65％以上。”

低代码已然成为数字化转型中不可回避的重要技术领域。本文在研读Gatner报告基础上结合中国实情给出相应观点。

很多企业对于低代码的讨论极为混乱，不同角色语言难以统一似齐梁世界。我们首先要明确低代码的标准定义，这是多方讨论与评价的关键基础。

（低代码在数字化工厂的应用）

一、到底什么是低代码

（低代码发展时间轴）

低代码开发不是新事务，最早来源于1980s出现的快速应用程序开发(RAD) 工具。

低代码开发始于Forrester的博采群议而形成定义。

（翻译：此平台可通过最精简的手工coding以及在安装、培训与部署方面的最小前期投入，实现快速的业务应用交付。）

Forrester对于低代码的态度实在是彰明较著，直接阐明低代码之核心价值：

• 低代码开发平台能够实现业务应用的快速交付。

根据Forrester调研，大部分公司反馈低代码平台使之开发效率提升5-10倍。

（低代码控件封装）

• 低代码开发平台能够降低业务应用的开发成本。

低代码开发在软件全生命周期流程上的投入更低、简单重复性研发资源投入更少。（这势必带来研发从业者的恐慌从而带来抵触）。

作为新型开发工具，低代码开发平台可减少代码量、简化开发流程、缩短开发周期、提高开发效率、节约开发成本、帮助用户更好地设计和实现需求，用户只需聚焦业务逻辑，而非关注代码编写。

（开发从传统向低代码过渡）

二、低代码平台的三个核心能力

最普遍的AD&D（移动应用开发与交付），通常需以下三个核心能力以实现其平台能力：aPaaS、MADP、BPM。

其中

• aPaaS是应用程序平台即服务的缩写（云服务的一种），可为应用程序服务提供开发、部署环境。aPaaS平台提供以下功能：迭代构建应用程序、即时提供应用软件、按需扩展应用程序以及集成应用程序与其他服务。（参见Gartner定义）
• MADP（移动应用程序开发平台）能够更好地应对企业数字化业务与创新性需求，是低代码开发能力的重要补充；同时，国外诸多低代码开发平台也在逐渐加强对移动应用开发的支撑能力。
• BPM平台注重流程化开发，目的是通过系统性的改善企业内部的商业流程来提升组织效率，目前的BPM平台前端主要是基于表单来实现快速开发，样式比较固定，后端通过分析BPMN流程图（业务流程建模标注）来完成一步步的流程开发。

（自动化BPM）

在国内，同时具备MADP、aPaaS、BPM能力的平台已在集成三层能力（有时他们自己也不知道，这叫低代码，虽然是他们在践行的），包括简道云、活字格、搭搭云等，这些平台已具备一定技术壁垒以及开发业态积累。

（低代码平台阵营）

（国内低代码市场格局中的应用衍生品牌）

（2021低代码厂商Top10 《互联网周刊》、eNet研究院、德本咨询联合发布）

开放研发环境、沉淀低代码技术能力与行业业务逻辑储备是低代码可最终嵌入企业肌体的关键。

三、低代码的开发过程

• 明确需求。
• 选择API。
• 在可视化设计器中绘制工作流程、数据模型、用户界面，并与客户确认。
• 连接API。
• 按需在前端添加写代码、自定义SQL查询或视图或编码对接第三方API。
• 测试用户接受度。
• 部署到生产环境，点击发布。

此时我们相信对于低代码的认识可进一步明晰了。确实我们传统上最擅长的车轨共文在这个领域的应用极为欠缺，这跟我们所用的技术基因以及标准仍然以西方为主、但又有了本土化的错综复杂的实践有关。在数字化转型中尤其需要这么一个专业权威实现关键认识、各类标准上的车轨同文，标准化本身是转型的基础。

（传统开发与低代码开发的过程区别）

四、低代码形势判断

4.1 进化从未停止

上文提到的80年代RAD工具引入用来替代传统基于文本的开发平台。

它们与时俱进，与集成开发环境(IDE)、图形用户界面(GUI)、网络和 C/S 架构等一同迅速发展。

早期的RAD工具开拓了可视化拖放机制、数据与行为的图形化模型、架构规范性的框架和模板化组件几大关键能力。

如洪水一般，这新生物快速传播到所有分布式开发平台！并推动业态快速进化。

（从低代码看生态演变、大势所趋、万路归宗）

在此期间，某些行业标准的可视化模型得到了发展和沉淀，如：数据的实体关系、对象管理的类图、流程模型和状态机的状态转换图。

同理，衍生出来的还有业务规则管理系统(BRMS) 市场，将快速应用程序开发(RAD) 和AI能力 融合于一身。决策管理套装(DMS) 市场也在持续采用这种结合产物（如最新的 DMN决策模型）。

（RAD与AI）

低代码应用程序开发的重要里程碑其实就是WEB（用于支持对应用程序的分布式访问）和云（实现标准化部署机制、在PaaS中实现顺畅应用开发）的出现。这就催生了应用程序开发工具市场的两个分支：

• 快速应用程序开发(RAD) 供应商将应用程序部署过程实现自动化。在他们的云产品中，普遍追求：应用程序通过最少、最小人员操作介入交付。
• 主流的 SaaS 供应商利用低代码使客户能够对其平台进行自定义和扩展。然后，他们逐步成为行业SaaS + PaaS 供应商，复用行业资源、为其他同行业开发人员提供面向用户的业务程序与技术来构建下一个应用程序...

如今，使用低代码开发技术（即“非编程开发”）以赋能员工、支撑大规模应用程序开发已成为某些企业数字化办公协议中的一部分。

工作组应用程序始终是使用非编程开发工具（例如电子表格）交付的。由业务线部门开发人员负责构建的应用程序已成为促使低代码开发工具生长的重要领域。

而且低代码功能的暗流涌动似的增加、也必然将成为某些非主要企业平台的潜在替代品：低代码工具从未停止攀登应用程序领域的金字塔。

4.2 低代码or零代码

随着低代码的发展，大家准备将其推向极致，也即，隔壁大爷也能用的“0 代码”工具，这对开发行业将是颠覆性的。尽管，我们认为“0 代码”工具是低代码工具市场的一个极小细分，且暂未实现。

（0代码的发展过渡）

Gartner报告显示，“0 代码”开发工具正在进军业务测的应用，触及到业务数据从而进一步稳固自身应用程序。同时，通过赋能和促进非编程开发的发展来使应用程序开发大众化，构建大环境低代码之势。

（0代码软件形态分类）

IT 部门人员为企业交付所有应用程序的日子可以翻页了。历史无情、在资本驱动下的科技行业更是无情，更是只关注当下和未来，独立的企业IT和影子IT未来都将被消除，业务与IT团队必将整合，共同实现数字产品的全栈交付。低代码开发恰好是实现这一点的关键因素也是前提基础。

4.3 从单一技术走向产品组合

市面上已有200多家供应商以“低代码”的方式推出产品，服务范围覆盖从简单的表单创建到全栈应用程序平台，为企业客户提供快速应用程序开发(RAD) 服务。

“0代码”开发产品亦属此类低代码工具范畴，主要面向业务领域中“非编程人员”（类似业务人员、产品设计人员、运营人员等无实际编码经验的人员）。

低代码开发目前尚以用于面向企业内部员工(B2E) 的应用开发为主，但伴随用户体验(UX) 要求的提高以及新型授权模式的逐步放开，低代码开发开始了其高掌远跖之路，从技术后台逐渐走向to C甚至to B的应用支持。

当前的问题不在于用不用低代码，而在于哪些场景适用低代码？但使用中必须有所准备。

（寻找适合的低代码场景）

接下来我们切入正题，如何评价低代码！

五、战略选择、决策、评估与应用

低代码涉及到的应用程序开发(LCAP) 乃循常习故、并非横空出世，数字化革新的过程中不过是自然而然衍生此类已有技术能力蜂拥而入，来满足日益增长的多元化的诉求。

（拖拉拽自动形成流程）

企业数字化转型中在考虑规划与技术资源匹配的时候，对于低代码工具和市场情况的客观而科学的判断，难以绕开。

5.1 战略选择

iResearch对低代码的场景覆盖率相对乐观 ：

• 中小型企业95%+场景可采用低代码搭建；
• 中大型企业70%+...；
• 在某些垂直应用场景中，如即时通信等领域，在低代码基础上还要其他插件补充的情况下，覆盖率大约50%+...

（低代码覆盖率）

而个人认为Gartner的评述更为客观：

• 取代趋势。到 2024 年，低代码应用程序开发将占应用程序开发 65％ 以上。
• 适用领域。到 2024 年，至少 75％ 的低代码应用程序开发工作将集中在中小型项目里，聚焦非核心的工作内容。
• 逐步接受。到 2024 年，有 75％ 的大型企业将至少使用四个低代码开发工具进行IT 应用程序开发和非编程式开发。

这给信息化、数字化负责人带来巨大压力，他们必须尽快提高应用交付速度、摒除时间浪费、聚集增值领域。

应时应势而生！

此时很多供应商们不约而同的提出低代码解决方案：通过减少或规避对专业编程（需IT开发专岗支持）的需求依赖，来提高生产力。

5.2 供应商综合判断维度

Gartner追踪了200多家低代码开发工具供应商。

在这些供应商中：

• 96％ 供应商认为自己提供了完整的软件开发生命周期(SDLC)支持，而不仅仅是扮演设计和开发加速器的角色；
• 95% 供应商目标客户是业务线开发人员；
• 88％ 供应商提供了公有云部署；
• 85% 供应商认为自己已覆盖用户体验、逻辑和数据的全栈，而不仅专门处理应用程序的一部分；
• 84％ 供应商提供了 WebIDE；
• 79％ 供应商提供基于表单的用户界面；
• 78％ 供应商将数据库作为其工具的一部分；
• 62％ 的供应商提供了私有云部署能力；
• 62％ 供应商提供移动应用程序界面；
• 47％ 供应商生成的代码在大多数情况下可以进行手工编辑；
• 40% 供应商选择的开发人员角色定位为业务高级用户；
• 30％ 供应商提供了桌面IDE；
• 5％ 不到提供聊天机器人。

在 top 3 的应用场景中：

• 86% 供应商目标应用场景是企业级应用开发；
• 55％ 供应商主要终端用户类型是 B2E；
• 而 B2B 和 B2C 的占比分别仅为 20％ 和 25％

（慧友云商低代码B2C样例 5.3 低代码开发技术的分类与评价）

数字化转型负责人必须意识到，低代码开发技术并不是一个静态的单一市场，而是相反。

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

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

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

• 低代码应用程序平台(LCAPs) —— 这是一个新类别，涵盖了高生产力的应用程序
  PaaS(HPaPaaS) 以及 RAD 和 RMAD 工具。它关注通过声明式的模型驱动和基于元数据的服务来提供快速的应用程序开发、部署和执行。这个市场包括自描述的“0代码”应用程序开发工具，并且总体上代表了低代码技术供应商的最大部分。
• 多维体验开发平台（MXDP） —— 这些产品为专业开发人员（有时甚至是非编程开发人员）提供了一套包含前端开发工具和后端服务的集成成熟套件，从而可以跨数字触点(digital touchpoints) 进行相应用途应用程序的扩展性开发。

• 流程和业务规则/决策管理系统——这类模型驱动的（因此是低代码的）开发平台可以在操作模型和程序时进行动态变化。他们通过流程(BPMS) 和业务规则/决策(BRMS / DMS) 实现了业务操作的自动化。Gartner的研究范围也扩大到了智能业务流程管理系统(iBPMS)，包括了可持续的智能和动态流程管理系统(BPM)。尽管“模型驱动”意味着“低代码”，但其中一些可以实现复杂的流程和决策的模型既复杂又专业，这可能需要相关专家协助才能进行开发。

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

（低代码决策树 源：Gartner (2019.2)）

5.4 关于低代码的决策

根据Gartner的经验，决策标准参考如下：

• 是否需要在没有专业开发人员协助的情况下进行“非编程开发”？

如果是，可以考虑一个具有“0 代码”能力的低代码应用平台(LCAP)，同时要注意工具的能力支撑范围。

• 是否需要可持续更新的、复杂的和可管理的业务流程或决策以及相关的供应商技能和流程与决策建模的协助？

如果是，须与供应商提供的流程专家一起考虑使用智能业务流程管理系统(iBPMS) 、业务规则管理系统(BRMS) 或 决策管理套装(DMS)，但要清楚低代码的哪些优势可能会在这些工具使用中受到限制，并且带来较高代价。

• 是否需要跨数字触点（digital touchpoints ）(例如，移动应用程序、渐进式 web 应用程序、聊天机器人)的多种应用程序类型？

如果是，须考虑使用低代码的多维体验开发平台(MXDPs)，以便跨多种交互模式扩展或增益应用程序用户体验；对于所有其他业务应用场景，则须考虑一个低代码应用平台(LCAP)，它可以在一款工具中提供给你部分或全部流程自动化，满足用户体验需求，同时具有非编程开发能力，并且聚焦服务质量而非单纯性能本身。

5.5 关于低代码服务的评估维度

对于供应商提供的所有类型的低代码开发产品，可以根据几个主要特征来进行评价。这些特征构成了低代码工具和平台的主要评估标准。数字化转型负责人可根据每个特征对其能力需求进行评分：

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

5.6 关于低代码产品工具的评估维度

（低代码能力特征）

BPM = business process management; CRUD = create, read, update, delete; DIY = do it yourself; SDLC = software development life cycle
图源：Gartner (2019.2)

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

共性技术要素包括：

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

作为企业级工具，还应考虑以下功能的评价，例如：

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

5.7 低代码采用的关键建议

若要充分发挥低代码价值，须要求负责应用程序开发和平台策略的负责人必须注意以下事项：
对应用场景进行分类，识别当下适应、适用、适配于低代码开发的场景。

选择恰当的低代码工具。建议选择对开发技能要求不高，尤其要适用于实现加快产品上市的关键场景。

给“非编程人员”（包括IT和业务方）提供的低代码开发工具必须具备相应的安全性保障、监督性保障与可用性保障。

一旦进入使用阶段，尤其产生局部效果以后，不要有移天易日之心、妄图过渡消费低代码能力、仓促扩大使用边界。

一旦决定将低代码应用于业务创新场景部署，要确保该工具的合规授权、并经评估可实现ROI、实现业务目的。

六、结语

国内关于低代码的探讨经常陷入误区——低代码如何实现，而忽略了面向业务让业务怎么实现的问题，因此容易陷入一波又一波关于低代码有用或者无用的争吵，此类争吵实属无用。

对于低代码供应商来说找到核心用户、客户的核心业务场景、明晰业务流程非常关键。

（服务于谁又将取代谁）

而对于要选择应用低代码的企业来说， 决定恰当的场景以及关于低代码服务于谁、取代谁、如何安置的决策等则比低代码工具的选择更为关键！

来源：球迷Long笔记
作者：Geissbauer，Long
主要参考译文：https://www.gartner.com/en/do...
作者：Paul Vincent, Mark Driver, Jason Wong
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

7月每周四晚8点，【冬哥有话说】研发效能工具专场，公众号留言“研发效能”可获取地址

• 7月8日，周文洋《微软DevOps工具链的 "爱恨情仇"（Azure DevOps）》
• 7月15日，待定
• 7月22日，张扬《基础设施即代码的⾃动化测试探索》
• 7月29日，胡贤彬《自动化测试，如何做到「攻防兼备」？》