vs code 代码提示不全_一文搞懂 HPAPaaS / Low-Code(低代码) / No-Code(零代码)

c3152203653476c1ecb6694509ca5d08.png

近三年的时间,一直投身于低代码平台的研究与产品研发工作,对相关的概念比较敏感,也关注了业内的众多大、小V和各路IT博主,受益匪浅。遗憾的是,似乎很多人对该领域的基础概念的认知却相对模糊,业内也未达成共识,一篇Garnter报告被解读成为N种概念,甚至被误读。这种现象着实令人唏嘘,豆爸特意找到了Gartner从2017年~2019年连续三年在该领域的研究报告,力图从根本上还原真相,希望通过本文的解析,能够比较清晰的解释清楚这些概念及其关系。

0、术语约定

HPAPaaS:High-Productivity Application Platform as a Service,高生产力PaaS平台

Low-Code:Low-Code Application Platform,低代码应用平台

No-Code:No-Code Development Tools,零代码开发工具

1、HPAPaaS Vs. 零代码

Gartner在2017年4月份发布了一份关于HPAPaaS(Enterprise High-Productivity Application Platform as a Service)魔力象限的报告,该领域在2017年之前从未被提及,属于一个新的领域。Garnter在报告中也比较明确的定义了HPAPaaS的定义——“application infrastructure functionality enriched with cloud characteristics and offered as a service” with “high productivity” supporting “declarative, and model driven design and one-step deployment.”从产品范畴上,包括了BPM PaaS和快速开发平台等细分领域。而在2018年的报告中,Gartner沿用了这一概念。

有意思的是,到了2019年发布的最新的Garnter报告(《Magic Quadrant for Enterprise Low-Code Application Platforms》)中,移除了原HPAPaaS的细分领域,让步给了Low-Code的概念,并在这份报告中比较明确的写了如下内容:

This “Magic Quadrant for Enterprise Low-Code Application Platforms” replaces 2018’s “Magic Quadrant for Enterprise High-Productivity Application Platform as a Service.” Its definition relaxes the requirement for each vendor to be a cloud PaaS vendor, though all the vendors included in this Magic Quadrant have PaaS capabilities anyway.

这样的一段描述,相当于给在Gartner报告中HPAPaaS的概念盖棺定论了,但需要澄清的是,虽然Garnter报告中不再明确使用HPAPaaS这个概念,但并不意味着这个概念的消亡,不论是国外、国内,这个概念本身仍然被使用。这里想特别说明的是:从这个概念的源头提出者而言,HPAPaaS是被丢弃的概念,取而代之的是Low-Code Application Platform(本文将简写为Low-Code/低代码)。

在2019年的Low-Code报告中,Gartner给定了未来5年的市场预期,由此可见,Low-Code在未来5年时间内极具前景:

  • 到2024年,四分之三的大型企业将使用至少四种低代码开发工具进行IT应用程序开发和公民开发(citizen development,可以认为是非IT背景的用户进行开发,例如:业务用户/产品经理/业务顾问等)。
  • 到2024年,低代码应用程序开发将承担65%以上的应用程序开发活动。

简单做个总结,当我们再提到HPAPaaS的时候,可以认为其等同于Low-Code、低代码,无需刻意进行区分,而实际上,从Garnter的定义和报告细节中,可以发现Low-Code(低代码)的概念甚至会比HPAPaaS略大一些。

2、Low-Code(低代码) Vs. No-Code(零代码)

同样是在2019年的Gartner的Low-Code报告中,对Low-Code和No-Code的关系进行了相对准确的解读:

Gartner has covered low-code development for mobile apps used in the workplace under rapid mobile app development (RMAD) tools (see “Market Guide for Rapid Mobile App Development Tools”). We have also observed that no-code development tools are being marketed toward lines of business as a way for them to own their data applications. The idea is to “democratize” application development by enabling and facilitating citizen development (see “Citizen Development Success Depends on an Equal Partnership Between Business and IT Leaders”).
However, the no-code tools targeted at minimally skilled citizen developers often end up requiring trained IT staff for certain use cases. Therefore, we consider no-code tooling as a subset of the larger low-code tool market, especially as enterprise-class low-code platforms increasingly strive to address both citizen and professional developers.

根据Gartner报告的定义,实际上No-Code的理念与Low-Code并不冲突,这就和很多国内的厂商/某些”专家”的定义不同。两者的关系可以认为是从属关系,即No-Code(零代码)从属于Low-Code(低代码)的范畴,如果进行解释,可以认为:

  • “所谓的”零代码产品,并未脱离低代码产品族群,而是低代码领域的子集;
  • 低代码产品的前端UI构建方案中,重要的实现方式,就是通过零代码的理念或组件。

从Gartner的报告中,“搬运”过来两者的关系图:

f3cfa8f310dc26e63f3ad62844e38dcb.png

3、HPAPaaS / Low-Code / No-Code关系

分别搞清楚了HPA PaaS与Low-Code的概念、Low-Code和No-Code的关系,我们就可以对三者之间的关系进行一个归纳了:

  • HPAPaaS = Low-Code
  • Low-Code > No-Code 或 No-Code ∈ Low-Code

注:这里的归纳可能并不完全严谨,仅参考Gartner报告,作为概念区分使用。

4、低代码平台的特性简述

搞清楚了几个概念的差异和关系,我们把焦点回到Low-Code部分,来看看符合什么样特性的产品,属于比较合格的Low-Code产品。很遗憾,翻遍了国内外的各类资料,包括Gartner连续三年的报告、魔力象限第一象限的头部产品描述,也都没能够找到一份标准的、达成共识的概念。

最终还是回到Gartner的报告,其中提到了一份低代码领域的分支报告——《Low-Code Development Technologies Evaluation Guide》,这其中有一段对于Low-Code平台的横向对比标准的描述,也就是不同的供应商的产品,其在Low-Code能力方面,可以横向比对哪些因素。实际上,关于低代码平台的特性,也可以借由这些因素窥探一二。

38c91e6b9c4700b1674623bb45ece36c.png

如上图可见,Gartner列示了9个不同的比较因素,并在之后进行了归纳,说明了目前主流的Low-Code产品具备的能力,分为两个部分:

1)通用技术能力:

  • 以模型/元数据为驱动的UI实现方式,最好是通过零代码的方案实现
  • 能够在线进行基本的数据结构(底层为数据库)的数据结构定义
  • 支持以SOAP、REST或其他类型的API的方式实现对外部接口的调用
  • 支持以API的方式,对外提供平台自身的数据/服务
  • 支持模型、可视化的代码或业务流程的开发实现
  • 高性能和低时延

2)作为企业级平台的进阶能力:

  • 高扩展性,例如:用户数、交易量、数据量等
  • 高可用性与灾难恢复
  • 应用访问、API、数据存储的安全性
  • 部署SLA或支持运行时部署(PaaS类产品)


我们可以借由此进行约定,符合上述的大部分能力要求的,可认为是Low-Code(低代码)平台。而在企业级应用解决方案中,会发现有不少传统IT人熟知的产品也是符合上述能力要求的,例如:BPM平台、iPaaS平台、国内的某些OA产品等,因此,在具体应用时,需根据组织自身的情况进行合理的选择。

5、企业(组织)选型建议

Gartner非常贴心的在其报告中给出了Low-Code产品的选型、决策树,可作为选型的参考:

f1b8cef6e01763a5f27c76bf65fda482.png

根据这个决策树,不但可以大致理解其决策的依据,也可以基本理清了No-Code、Low-Code、传统的BPM等方案之间的关系。为了方便理解,我们把几个关键的角色因子进行简述:

  • 是否需要公民开发(e.g. 业务顾问/业务用户配置式开发),如结果为是,那么跳转到是否需要专业开发人员介入,反之则继续判断是否需要多终端交互访问;
  • 是否需要专业开发人员介入,如选择为否,则直接可选型No-Code(零代码)工具产品,或选择Low-Code平台的零代码能力应用;
  • 是否需多终端交互访问,如选择为是,则选择MXDP(Multiexperience development platforms)类产品,进行定制化开发,如为否,则继续决策是否有经常需要变化或比较复杂的业务需求(尤其关联流程等);
  • 是否有经常需要变化或比较复杂的业务需求(尤其关联流程等),如选择为是,则选型BPM平台为主 + MXDP类型产品进行前端辅助构建的方式,如为否,则选择Low-Code为主的平台。


结合豆爸的个人实战经验来看,这个决策树基本是可行的,但维度最终的落脚点,即目前Low-Code产品和BPM平台产品的界限越来越模糊,为便于理解上面的决策树,可以将这里的iBPM理解为传统的BPM产品、LCAP理解为模型/表单驱动的Low-Code产品(虽然目前很多Low-Code产品也包括了流程特性,但其流程相对传统的BPM来说偏弱)。

主要参考文献:

1、《A Look at Gartner’s 2017 Magic Quadrant for Enterprise High-Productivity Application PaaS》, https:// solutionsreview.com/clo ud-platforms/a-look-at-gartners-2017-magic-quadrant-for-enterprise-high-productivity-application-paas/
2、《Magic Quadrant for Enterprise Low-Code Application Platforms》, https://www. gartner.com/doc/reprint s?id=1-1FKNU1TK&ct=190711&st=sb
3、《Low-Code Development Technologies Evaluation Guide》, https://www. gartner.com/doc/reprint s?id=1-6IJBUFN&ct=190411&st=sb
4、《Magic Quadrant for Enterprise High-Productivity Application Platform as a Service》, https://www. gartner.com/en/document s/3695317/magic-quadrant-for-enterprise-high-productivity-app
5、《What is a HPaPaaS – and do you need one?》, https://www. encanvas.com/what-is-a- hpapaas-and-do-you-need-one/
6、《What is hpaPaaS and Why Should it Matter to You?》, https://www. neutrinos.co/what-is-hp apaas/#:~:text=As%20per%20Gartner%2C%20hpaPaaS%20refers,deployment%20and%20other%20composite%20capabilities.
7、《What Is Citizen Development and How to Govern It》, https://www. outsystems.com/blog/pos ts/citizen-developer/
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值