低代码没有存在感?看看这七个赛道战况!
曾经,关于“低代码是否为行业毒瘤”的争论曾经甚嚣尘上。
然而随着数字化转型的深入,越来越多的企业开始寻求低代码和无代码解决方案,以满足对应用程序的更快交付和高度定制自动化工作流的日益增长的需求。
根据 Gartner 的数据,全球低代码和无代码应用平台的市场规模预计在 2023 年将增长 25%至 100 亿美元,2024 年将达到 123 亿美元。
一方面,低代码和无代码应用可以赋予普通业务人员开发技能、加速创新想法落地,帮助公司探索新的业务增长路径;另一方面,不能否认,低代码和无代码解决方案并非万金油,其在不同应用场景的渗透率受产品功能覆盖度和应用场景复杂度的影响。因此采用相关方案时需要进行审慎的评估。
本文将探讨低代码和无代码解决方案正在发挥作用、颠覆传统 IT 面貌的七大技术领域,有的在情理之中,有的可能在你的意料之外。
1、机器人流程自动化
机器人流程自动化即 RPA,通过自动执行与基于规则的流程相关且具有重复性的任务来确保一致的业务生产力。只要预先设计好使用规则,RPA 就可以模拟人工,进行复制、粘贴、点击、输入等操作,协助人类完成大量“规则较为固定、重复性较高、附加值较低”的工作。典型场景包括发票验真、报销审核、表单自动处理等。
在无代码与低代码系统构建的过程中,除了系统本身的结构设计十分重要以外,应用间、系统间数据流转、自动化流程处理等等,也是决定一套系统能否真正适用企业业务的核心与关键,无代码、低代码与 RPA 的结合的价值与意义也正在于此。
许多公司采用 RPA 作为对其旧有基础设施进行现代化改造的一种方式。业务人员可以使用低代码编辑器来创建在办公室、工厂和仓库之间移动数字表单的管道。低代码层可以与传统系统使用的许多协议和文件格式无缝交互。他们以最少的配置完成大部分翻译和重新格式化工作。
一些顶级的 RPA 公司包括 UiPath、SAP、Appian 和 Automation Anywhere,正致力于将 RPA 功能集成到现有的自动化平台中。
2、业务流程自动化
用于描述低代码系统的另一个常用术语是“业务流程自动化”(BPA),还有“业务流程管理”(BPM)。在此标题下的应用程序与定义为机器人流程自动化的系统之间没有太大区别。无论是 BPA、BPM 还是上文提到的 RPA,某种程度上都属于流程管理的方法,其目标都是为了优化业务流程,提升业务效率以及实现现有资源的更多价值挖掘。从功能上讲,RPA、BPA 和 BPM 都以很少的编码将各种工 具链接在一起,有很多相似之处。
这类具有代表性的著名工具包括 Zapier,Creatio,KissFlow 和 SnapLogic。其中一些工具提供了特别的重点:比如 AirSlate 希望帮助文档流经企业,它提供了用于自动化文档创建、版本控制和授权的工具。
咨询公司 Forrester 曾在 2020 年发布报告中提到,在 VUCA 时代的背景下,传统长周期、大制作的系统开发方式正在被逐渐淘汰,由无代码、低代码技术组成的低代码系统开发平台与 RPA、BPM、DPA(数字流程自动化)等技术,正在数智化大环境的推进下相互融合,逐步构建一个 RADM(快速应用交付市场),并将在未来承接主要的应用产出与交付。
3、低代码和无代码 AI 工具
一部分公司正在将人工智能算法集成到自己的低代码产品中,也有一部分公司正在销售人工智能工具。理论上,开发人员将使用 AI 作为助手。众所周知,GitHub 在用 OpenAI 的工具在存储在自己的服务器中的无数行开源代码上训练它之后,推出了 GitHub Copilot。
其他人则直接转向 OpenAI,其 API 提供了直接访问 code- davincii -002 和 code-cushman-001 等模型的功能,据说这些模型能够处理许多流行的语言,包括 C#、JavaScript、Go、Perl、PHP、Ruby、Swift、TypeScript、SQL 和 Shell 脚本。一些开源版本包括 GPT Code Clippy 和 SecondMate。
固然最突出的那批工具正努力编写大块代码来处理整个编程任务,但其他工具则没有那么雄心勃勃。例如,Captain Stack 谨慎地使用搜索引擎在 Stack Overflow 之类的论坛上找到好的答案,然后将它们修改为编辑器的代码建议。类似的项目还有 Clara Copilot、YouCompleteMe 和 Kite。
关于 AI 代码贡献质量的意见各不相同。大多数人惊讶于机器能够将可靠的解决方案拼接在一起,这些解决方案几乎可以提供所需的东西。但是,机器错误依旧需要人的关注。
很多人还没体验过低代码,这里推荐一个好用的平台,JNPF 快速开发平台。
网址:https://www.jnpfsoft.com/?infoq。
近年在市场表现和产品竞争力方面表现较为突出,采用的是最新主流前后分离框架(SpringBoot+Mybatis-plus+Ant-Design+Vue3)。代码生成器依赖性低,灵活的扩展能力,可灵活实现二次开发。
4、超级应用程序
一些开发人员正在利用集成的机会来自动化他们的工作流,这些机会出现在曾经被认为是基本的应用程序中。例如,AirTable 是数据库和强大的电子表格界面的结合,它使得电子表格用户可以相对容易地开始创建更复杂的软件。
许多主流平台都在慢慢地整合它们的工具来做同样的事情。像 SAP、Amazon、Microsoft、Salesforce 和 Google 这样的公司正在他们的产品之间添加如此多的链接,以至于用最少的代码创建复杂的工作流相当简单。例如,Amazon Web Service 用户可以编写将他们的许多产品结合在一起的 Lambda 函数。Google 后端工具通常与他们的办公产品紧密集成,从而产生可以响应其他软件或发起事件的电子表格。
5、Web 应用程序
许多知名的低代码和无代码解决方案被构建 Web 应用程序的人使用。用于编辑网页和放置图片的工具通常包括用于调整定义外观的 CSS 的功能。它们通常还允许为常见任务添加基本的 JavaScript 函数,例如销售商品或收集表单。
像 SquareSpace,Wix,Strikingly,Webflow,SITE123,WebNode,Web.com 和 Weebly 这样的公司是用一点儿自动化手段创建基本网站的主要选择。还有一些很好的开源解决方案,如 Drupal,WordPress 和 Ghost,这些解决方案也得到了提供托管服务和定制服务的公司的支持。有些人专注于特定的利基市场,例如 Pixpa,它为艺术家建立作品集网站。
像 Shopify,BigCommerce,Opencart,Adobe 的 Magento 和 Drupal Commerce 这样的公司是专门从事在线商店的网站建设者。许多用户无需代码就可以使用深度数据库创建精心设计的商店。那些需要额外功能的人通常只需要写几行代码,并将它们合并到 Web 流程中。
有些人还使用这些工具来构建桌面和移动应用程序。像 Electron,NW.js,Flutter,Neutralino 和 ReactNative 这样的框架是将 HTML,CSS 和 JavaScript 变成更接近原生应用的工具集。它们经常将像 Chromium 这样的开源浏览器与你的代码捆绑在一起,以构建像任何桌面或移动应用程序一样运行和功能的东西。有些人发现结果可能很笨拙,而且比手动编码 C++慢一点,但它们仍然很受欢迎,因为使用它们只需要熟悉构建 Web 应用程序即可。
6、数据存储
数据管理的许多部分都涉及触发事件、传递消息、同步数据流以及创建仪表板或报表。所有这些任务都可以通过工具处理。这些工具本身正变得足够复杂,几乎不需要编码经验。
数据库的安装和性能调优曾经很复杂,但现在像 Oracle 这样的公司可以很容易地给它们打上“自治”这个标签。像 Amazon,IBM,MongoDB,Google,PlanetScale 和 ExoDB 这样的公司同样提供自动管理安装和调优的托管服务。
一些公司正在构建托管数据湖和数据仓库,这些数据湖和数据仓库可以跨堆栈与数据源集成。它们带有预定义的函数,可以摄取数据、回答查询和生成报告,所有这些都只需很少的编码。一些主要选项包括 Snowflake,Databricks,Cloudera,Panopy 和 Dremio。
构建这种基础设施的工作是创建大型系统,这些系统通常被归类为更通用的术语,如商业智能平台。微软的 Power 平台、SAS 的商业智能基础设施以及 Tibco 和 Tableau 产品就是其中的几个例子。
7、通用基础设施
到目前为止提到的许多工具都是为特定用途而构建的,但并非每项工作都属于这样的利基市场。对于其余的工作负载,有一些很好的低代码选择来处理一般的杂务。其中一些工具是直接为开发人员和熟练用户构建的,这些工具通常将可视化编程编辑器与一组后端例程相结合,用于访问具有标准格式(如 JSON 或 XML)的数据库和远程服务器。
一些最受欢迎的版本包括 SAPs Build Apps(以前的 AppGyver),Make(以前称为 Integromat),Node-RED(以前来自 IBM),Clutch.io,Mendix,Quixy 和 Google 的 AppSheet。与此同时,Lansa 是一个更小范围的解决方案,它包含了简化旧 IBM 代码现代化工作的特性。
可视化编辑器依靠拖放和点击的组合来填写预定义的表单。这些产品被定位为“低代码”,因为几乎不需要编辑文本文件,也不需要担心解析器对正确标点符号的要求。尽管如此,很多更高层次的思维还是很熟悉的。作为创建者,你必须考虑数据的结构及其移动方式,即使平台将处理许多基本的杂务。
这些产品通常还包括预先开发的模块,用于使用通用协议连接到通用 API。如果我所讨论的某个更具体的工具不适合这项工作,那么更通用的解决方案通常是最佳选择。
版权声明: 本文为 InfoQ 作者【高端章鱼哥】的原创文章。
原文链接:【http://xie.infoq.cn/article/7529d50f8aa733db8b8230744】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论