> 文档中心 > 一文讲透低代码

一文讲透低代码

近年来,在数字经济迅速发展的背景下,越来越多的企业开始建立健全业务系统、应用、借助数字化工具提升管理效率,驱动业务发展,促进业绩增长。在这一过程中,和许多新技术一样,低代码(Low-code)开发被推上了“风口”。
 

01 低代码的定义与发展

 
⬛ 低代码是什么?

低代码是一项可提升软件交付速度的开发技术,以降低编码工作量和开发成本为典型特征,是高级语言发展到一定程度的必然产物。

⬛ 低代码的发展历程

和许多软件开发技术一样,低代码也不是“凭空产生”的,而是软件开发技术发展的必然产物。在软件技术发展史的尺度下,观察低代码的诞生过程,能帮我们加深对低代码开发技术的了解。

 ◾背景:软件开发的生产力不断提升,但仍显不足

编程语言是每一位专业开发者最熟悉的概念,也是软件技术发展史的重要见证者。

计算机诞生于1946年,计算机的核心部件是中央处理器(CPU)。计算机之所以能够工作,是因为我们给CPU输送工作指令。这里的工作指令就是机器语言,是由0和1组成的二进制串。机器语言可以被机器直接识别,但对人很不友好,非常繁琐也容易出错。

在计算机诞生后不久,人们就发明了汇编语言。汇编语言参考了人类语言的符号,用助记符号代替二进制串。程序在执行前需通过编译程序将汇编语言还原成机器语言,再输送给CPU执行。汇编语言比机器语言更容易理解和编写,但是它仍然高度依赖于机器语言,与CPU体系架构一一对应,不同的CPU都需要不同的汇编语言和指令集(CPU能够识别的操作)。

随后,语言发展到第三个阶段:高级语言。在1957年,计算机专家发明了第一个高级编程语言Fortran语言,随后陆续发明了BASIC、C语言、C++语言、Java语言等。高级语言是指面向用户的语言,它与人类的语言规则更接近,比如,C语言当中有If … then … else …;Basic语言中的While … do等。这样的语法和人类的语言表达方式基本相同。直到今天,新的语言仍然层出不穷,全球已经累计有几千种高级编程语言。

从机器语言到高级语言,编程语言越来越接近人类的语言,学习和理解的难度逐渐降低,随之而来的,还有编程工作效率的显著提升。可以说,高级语言的生产力已今非昔比。在高级语言的基础上,为了进一步提升软件开发的效率,软件开发行业做了很多有益的尝试,其中最成功的,当属可视化、组件化和框架化三个方向。

一、可视化 Visualization

“可视化开发”是上个世纪90年代软件界最大的热点之一。最初的可视化专注于用户界面开发领域,可以让开发者通过拖拽的方式快速构建出用户界面,一些成熟的产品甚至可以做到“所见即所得”。即便与最先进的高级语言对比,使用可视化设计开发图形界面的生产率也能高出许多。

在品尝到可视化的“甜头”后,可视化开发的技术和工具迎来了大发展,其应用场景早已不仅仅应用于用户界面设计。如今的可视化开发已经涵盖了数据库设计、工作流设计、业务逻辑设计等各个领域。

全局来看,可视化开发在提高开发效率的同时,还降低了开发的技术门槛,这就让软件开发团队的构成有了更多的优化空间,如让美工参与构建用户界面,让业务人员设计业务流程等。新的团队构成除了能降低总体开发成本,还能通过减少沟通环节,提升软件团队的协同能力,加快软件交付速度。

二、组件化 Component

与可视化开发相伴而生的,是软件开发的组件化。组件(Components)伴随着高级语言产生,它的本质是可重复使用的代码。当一段代码可以在一个软件中使用,也能成为另外一个软件的一部分时,就可以被抽象成一个组件。组件的价值不仅仅在于提高代码的复用性、提高开发效率,还通过组件化的设计,也降低了整个系统的耦合度,提高了系统的可维护性。

目前组件化的开发方式非常成熟,覆盖面从文字输入等基础功能、统计函数等数据处理到报表等复杂应用场景。组件中涉及用户交互的最为常见,也被称作“控件”(Controls)。比如,开发者使用可视化设计的方式开发业务报表时,可以直接使用葡萄城提供的ActiveReports报表控件。ActiveReports可以作为一个组件的形式嵌入到各个应用程序当中,同时它也提供了一种可视化的报表设计模式,同时代表了可视化和组件化两大趋势。

三、框架化 Framework

可视化和组件化聚焦在具体的功能实现,而框架化则为整个软件和开发流程提供支撑。框架(Framework)是指可被应用开发者定制的应用骨架。就类似人类的骨骼系统一样,框架规定了应用的体系结构,阐明了整体设计、协作构件之间的依赖关系、责任分配和控制流程。

对于开发团队,框架化的价值在于提供软件的总体架构,简化了设计工作,降低对软件架构师的能力依赖,使得开发团队即使没有高水平的架构师,也可以让软件有一个很好的架构。同时,框架通过抽出非功能需求,让开发者能更加专注于业务逻辑的实现,提升了开发效率。总之,框架本身就是最佳实践的一个提炼和综合,基于专业的框架进行开发可以有效保障大型软件的处理能力、扩展性和可维护性。

◾创新:低代码的两条技术路线

可视化、组件化和框架化,通过将大量的开发工具、控件和技术文档深入到软件开发过程中,以灵活性和极限性能的小幅牺牲,换来了开发效率的大幅提升。然而,这种“量变”的效率提升,对于加速增长的软件需求,依然杯水车薪。在需求积压严重,但灵活性要求相对较低、硬件处理性能过剩的企业服务(toB)市场,开发团队急需一个可以和传统编码开发并行的技术方案,用灵活性和性能的妥协,换取成倍提升的开发效率。低代码,应运而生。

⬛ 了解低代码开发平台

低代码(Low-Code / Low-Code Development Platform / Low-Code Application Platform)是指一项可用于提升软件交付速度的开发技术和工具,以降低编码开发工作量和开发成本为典型特征,是高级语言发展到一定程度的必然产物。从实践上看,低代码技术牺牲了一定的极限性能优化和精细化交互体验,换来了数倍提升的开发效率。所以,低代码技术主要应用于企业软件开发,通常不适用于构建数据量和并发用户量巨大、对用户体验有极致要求的互联网应用。

2014年,Forrester提出了低代码的概念。低代码是一种软件开发技术,衍生于软件开发的高级语言,让使用者通过可视化的方式,以更少的编码,更快速地构建和交付应用软件,全方位降低软件的开发、配置、部署和培训的成本。

为了实现这一目标,低代码开发平台通常由4部分构成

  • 可视化设计器: 具备可视化定义UI,工作流和数据模型的设计器,且在必要时可以支持手写代码。
  • 服务器程序: 承载可视化设计器构建的应用,供最终用户通过多终端访问,具体形式如私有化部署的服务程序、运行在云端的容器或服务等。
  • 各种后端或服务的连接器: 能够自动处理数据结构,存储和检索。有些低代码开发平台将其集成到了可视化设计器中。
  • 应用程序生命周期管理器: 用于测试、暂存、构建、调试、部署和维护应用程序的自动化工具。

经过多年的发展,超百家厂商推出了大量的低代码开发平台产品。纵观这些低代码平台,除了都具有这些基本要素以外,没有两个产品是完全相同的。有些工具作用非常有限,更类似于与数据库配套的前端界面,如20世纪90年代的FoxPro;有些工具则仅专注于小众的业务需求,如客户档案管理;甚至有一些专用工具只是用低代码的术语来描述,但与实际的应用程序开发几乎没有关系。为了与其他软件开发技术进行区分,避免对IT决策者带来误导,Gartner将低代码的概念具体化,提出了低代码开发应用范围(构建包含有用户界面、业务逻辑、工作流和数据服务的完整软件应用)。针对企业级软件开发,Gartner还提出了低代码开发平台所需的必备功能。

  • Not be used only or mainly for building specific industry applications, and it must not be only a product bundled within some other solution or platform. 不能仅用于或主要应用构建特定行业的应用,不能仅限于在依赖其他解决方案或平台上运行。
  • Support development and deployment of applications by professional developers in both central IT and line of business — not just for citizen developers. 需要能提供给IT技术人员使用,不能只给平民开发者使用。
  • Develop, version, test, deploy, execute, administer, monitor and manage the applications and their relevant artifacts. 全生命周期:覆盖应用和相关资源的开发、版本管理、测试、部署、执行、管制、监控和管理的全生命周期。
  • Embed data storage features without relying on additional procured services (i.e., includes a database). 内建数据存储:内建数据存储机制,不能依赖其他的数据库等存储服务。
  • Support the design of data schema and application logic. 数据与逻辑设计:支持用来设计数据结构和应用逻辑。
  • Create rich application UIs (i.e., not only a forms builder or building an administration UI). 完整的界面设计:支持创建完整的应用界面,不能仅支持创建表单或管理界面。
  • Enable the invocation of external third-party services via APIs or event topics. 第三方集成:支持引入第三方API或事件驱动机制。
  • Support some automation of platform patching and versioning. 自动运维:提供自动化的应用升级和版本管理机制。
  • Provide single-step deployment across environments (development, test, staging, production). 多环境部署:支持针对多环境的一键部署,包括开发环境、测试环境、验证环境和生产环境。
  • Access a platform repository or marketplace for sharing components, modules, connectors and templates 社区共享:提供可供访问的应用市场,用来共享组件、模块、连接器和模板。

⬛ 低代码的技术路线

在低代码的诞生和发展进程中,有两个典型的技术路线:

路线一:将数据与业务逻辑合一的表单驱动低代码,衍生于ERP、OA中广泛使用的可配置化技术,使用体验类似于成品软件的实施;

路线二:数据与逻辑完全分离、各自独立的模型驱动低代码,是可视化开发技术发展的产物,体验上承袭了传统软件开发的生命周期。

国际主流研究机构将两种技术路线的产品分开调研,Gartner将模型驱动视为低代码开发平台的基础要求;Forrester将表单驱动的低代码平台视作“面向业务开发者的低代码开发平台”,与模型驱动的“面向专业开发者的低代码开发平台”进行了区分。

02  低代码开发者有哪些

低代码技术显著降低了软件开发的技术门槛,让更多人可以参与到软件开发中,进一步扩大软件开发者的规模,加速信息化建设。低代码的用户群体都有谁适合使用低代码技术开发软件?

从事低代码开发人员可以分成两类: 服务于企业IT部门或 软件的公司的IT技术人员(包含但不限于程序员、项目经理、实施顾问等);以及 来自业务部门,本职工作与IT无关但参与到软件开发中的业务开发者

⬛ 低代码赋能IT技术人员

 ◾什么是IT技术人员?

这里的IT技术人员是与“业务开发者”相对的概念,包含但不限于程序员,特指在企业或信息化提供商中,本职工作为企业信息化相关的技术人员。IT技术人员主要集中在企业信息化部门和为企业提供信息化服务(如外包开发、系统集成等)的软件公司中,典型岗位有项目经理、架构师、程序员、测试人员、实施和运维人员、DevOps等。

整体而言,IT技术人员具备以下特征:

  • 具备技能:通常具有计算机相关的教育背景,或通过自学的方式掌握了一定的IT技能(如编程语言、数据库管理、配置管理、系统管理等)
  • 考核指标:能否保质保量地满足本单位或客户的信息化需求是核心指标
  • 学习意愿:需要紧跟技术发展趋势,跟随团队和企业技术决策,及时更新技术能力

◾最适合转型为低代码开发的IT技术岗位

在进入低代码时代之前,各岗位的IT技术人员均已掌握了软件开发全生命周期所需的部分技术,通过简单的学习,这些IT技术人员均可转型为低代码开发者,以团队成员或个人开发者的身份构建软件应用。

当前岗位

与低代码开发者的匹配程度

需求理解

架构设计

数据库设计

界面交互设计

数据库开发

前后端开发

项目管理

系统管理

说明

架构师 ※※※※※ 架构师不但适合转型为低代码开发者,更适合成为低代码技术专家,为多个团队提供技术支持
项目经理(乙方) ※※※※※ 乙方项目经理通常具有计算机的教育背景,学习数据库设计和开发相对较容易,可以做到“开发管理一肩挑”
项目经理(甲方) ※※※※ 甲方项目经理通常缺乏项目管理经验,需要补全短板才能确保低代码开发有序展开
程序员 ※※※※ -(部分) -(部分) 对于程序员来说,低代码不过是一个新的开发语言和工具,要想发挥低代码的最大价值,需要提升需求分析能力
实施和运维人员 ※※※ 适合运维人员的转型需要学习需求分析、数据库设计知识,可行,但难度相对较高
DevOps ※※
测试人员 -(部分)

●:低代码开发者的必备技能;○:低代码开发者的重要技能;△:部分场景下低代码开发者的需要技能

◾低代码为IT技术团队带来的价值

对于软件开发这种成熟的生产模式来说,任何一项新技术的引入都需要投入学习和切换的成本,在计算该技术能带来的价值时,则需要将这个成本减掉。从编码开发到低代码开发,IT技术团队,特别是开发团队投入成本不仅限于学习该技术花费的时间,还需考虑配套的工具和方法论的学习和切换成本:

  • 学习低代码开发工具的时间投入
  • 学习低代码平台配套工具(如版本管理、CI/CD等)的时间投入
  • 适应项目管理方法的时间投入和风险

而引入低代码后,开发团队能获取的收益也不仅限于开发工作量的降低,还有与之相伴的测试工作量降低和交付周期缩短,而交付周期缩短可以有效降低返工成本。

综合上述低代码的价值公式可以概括如下:

开发和测试的工作量减少 + 因交付更敏捷带来的返工量减少 - 低代码学习成本 - 配套工具学习成本 - 方法论切换成本 = 低代码的价值

考虑到不同的低代码平台适用于不同的应用场景,上述5个参数可能存在较大差异。从实践上看,采用模型驱动的低代码开发平台开发项目规模大、复杂度高、技术要求严格的企业核心应用时,低代码带来的收益显著高于使用表单驱动的低代码开发平台构建临时性的简单应用。而后者更适合由业务人员而不是IT技术人员完成,以“解决有无问题”为目标。

详细了解:低代码平台的技术原理;低代码开发支撑软件全生命周期

参数

模型驱动低代码(核心业务应用)

表单驱动低代码(简单应用)

开发和测试的工作量减少
+ 因交付更敏捷带来的返工量减少 低 - 返工工作量较低
- 低代码学习成本 低 - 与编码开发的概念和模式更接近 中 - 需要打破现有软件开发思维
- 配套工具学习成本 低 - 可沿用现有工具 高 - 需重新考虑版本管理和DevOps流程
- 方法论切换成本 低 - 与软件工程理论兼容 高 - 需重新设计团队协作和管理方式
= 低代码的价值

◾低代码与IT技术人员的职业发展

对于程序员来说,学习模型驱动的低代码开发平台和学习一项新的语言类似,都是将之前学习和实践中积累下来的经验,套用到新的开发工具上。在适应了低代码开发平台后,IT技术人员就能通过可视化的方式,大幅减少重复性的工作,比如增删改查、页面布局和样式等,最终实现工作量的显著下降。从相对低端的重复性工作中腾出精力,才能扩宽职业发展的道路。在一个采用低代码技术开发的团队中,IT技术人员的发展路径主要有以下4条。

技术专家

低代码时代的技术专家与编码开发的架构师类似。如果对传统编码开发更感兴趣,低代码开发者可以持续钻研编程扩展,包括低代码平台的插件开发、外挂式Web API开发、软硬件集成、数据库调优等,为公司提供技术支撑。成为技术专家,意味着开发工作从面向应用需求,切换为专注于处理技术和集成方面的难题,为多个团队和项目提供技术保障。相比于没有接触过低代码开发平台的其他程序员,技术专家通常可以根据低代码平台的特点给出最有效的解决方案,并且能够充分理解和照顾来自公司其他开发者的功能和体验要求,降低沟通成本,为整个公司的软件开发工作提效。

大多数采用低代码开发模式的软件公司和企业信息化部门对技术专家岗位的需求量较少。所以,这个路线对开发者自身的技术突破能力和持续学习能力有较强的要求。通常情况下,公司会优先从编码开发团队的架构师中选择学习能力强、对新技术敏感度高的人员担任技术专家。

项目经理

低代码开发和编码开发在项目管理和软件生命周期上的方法论是一样的。所以,低代码开发团队一样需要设置项目经理的角色。考虑到低代码时代有“设计即开发”的特点,项目经理也需要具备使用低代码平台构建可操作原型,甚至参与到具体开发工作的能力,这就为低代码开发者转型成为项目经理提供了更有竞争力的条件。

相比于编码开发,数倍的生产力优势让低代码开发的团队规模更小,2-3人的微型团队就能具备编码开发时代10人团队才有的软件交付能力。更小的团队规模,让公司能同时启动更多的软件开发项目,这就需要更多的项目经理来保证需求沟通和开发管理的有效可控。所以,除了编码开发团队的项目经理之外,更多的开发者可以借助这一契机,通过承担更多项目管理工作,成为新的项目经理。需要提示的是,项目经理所需的管理知识已经形成了成熟的体系,“自学成才”是完全可行的。

业务专家

低代码具备更快的迭代速度和更低的学习门槛,这使得很多公司开始让业务人员深入参与到软件开发中来。业务人员和IT技术人员一起,前者贡献业务知识,而后者基于对计算机技术的理解,将其转换为软件。在不断的交流中,有一部分业务人员因此掌握了软件开发能力,也让一些技术人员对业务流程和背后的原理有了更深刻的理解。所以,在帮助业务人员转型为开发者的同时,技术人员也能成为业务专家,将软件开发工作中培养的系统化、逻辑化思维带到业务部门,为业务发展引入新动力。

独立开发者

低代码开发的团队规模更小,一人身兼数职也是常态,可以帮助开发者更快速地成长。在低代码的助力下,一个人同时掌握需求分析、产品设计、开发、测试以及DevOps相关的技术能力的可能性大增。如果具备覆盖软件全生命周期的能力,再加上合适的时机,“成为独立开发者”也是一个值得考虑的选项。相比于编码开发,低代码的开发效率足够帮助独立开发者建立起交付速度和成本上的优势。

⬛ 低代码赋能业务人员

 ◾什么是业务开发者?

在低代码技术被命名之前,国际知名的研究机构们就提出了“业务开发者/平民开发者”的概念。这两个概念与专业开发者对应,专指那些向业务部门汇报但开发能力来辅助业务发展的员工。这些人和向IT部门报告的专业开发者不同,他们的主要工作职责是业务发展,软件开发只是一个辅助性工作,通常不会有相关的考核指标,得到的资源也较为有限。在传统的编码开发时代,业务开发者较为少见,有能力从事辅助性软件开发的业务人员主要集中在数据分析师、软件公司的程序员(程序员的主要工作是开发软件产品或对外交付软件项目,而不是辅助性的软件工具)等具备编程能力的人群。而低代码技术的出现,让更多的业务人员可以成为业务开发者,比如构建订单管理应用的销售主管、人事档案系统的HR、库存盘点APP的库管人员等。

整体而言,业务开发者具备以下特征:

  • 具备技能:通常没有计算机相关的教育背景,部分掌握Excel等办公软件的常用功能
  • 考核指标:能否完成业务目标是核心指标,通常不包含信息化建设相关内容
  • 学习意愿:不得不参与软件开发,通常没有主动学习IT相关技术的动力和投入

◾低代码对业务开发者的价值

与帮助IT技术人员提升软件开发效率不同,低代码对于大多数业务开发者而言,是解决了“能不能开发软件”的问题。这就意味着,业务人员可以根据自身的应用场景,快速构建起对应的软件应用,减少了与IT部门协调确认的沟通成本,在IT部门资源紧缺的背景下,尽快扫清信息化死角。

业务开发者构建的应用主要有以下几类,除数据报表应用的业务逻辑复杂度较高而且通常需要与第三方系统集成,对业务开发者有较高的学习能力要求外,其他应用场景相对简单,更适合业务开发者使用低代码构建。 

应用场景

典型应用

数据一致性要求

业务逻辑与流程复杂度

多人协同操作要求

数据量与使用频率

与其他系统集成要求

替代方案

数据填报应用 支援基层报名、疫苗接种登记 Excel文件、邮件、微信群
数据报表应用 出入库周报、收支记账 ERP、Excel文件
档案管理应用 人事档案、车辆管理 OA、Excel文件
流程审批应用 合同管理、工单管理 OA、Excel/Word文档、邮件、微信群

◾业务开发者面临的管理和技术挑战

从理论上讲,业务人员从事软件开发确实有很高的价值,可以有效降低企业在信息化的投入,并尽快见到成效。然而,从管理到技术,业务开发者和IT技术人员都存在较大的差异,需要面临更大的挑战。从研究机构的数据上看,业务开发者的学习门槛和应用场景深度广度的矛盾已经成为了很多企业实施低代码技术失败的主要原因。所以,在引入低代码技术,让业务开发者承担企业信息化建设之前,企业仍然需要做好预期管理和组织管理优化,循序渐进。

软件质量:“短平快”优先于可维护性

相比于有明确发展规划和专项预算保障的IT部门,业务部门对信息化的要求通常与当前面临的问题紧密相关。有需要解决的问题,而且IT部门无法及时解决时,业务团队才会临时做出预算,为自己开发软件。

向业务部门汇报的业务开发者在软件开发上的投入更加碎片化,峰值虽然较高,但不可持续。而且,随着软件应用走上正轨,业务部门大概率会在第一时间将后续的维护工作移交给IT部门,即从业务开发者交接给IT技术人员。如果在较短的时间周期内,业务开发者没有按照预期完成软件的开发和交付,业务部门就失去了将其留在自己团队的最大理由。该项目则很可能直接搁浅或移交给IT团队,进入开发队列。而对于业务开发者而言,项目已经失败了。

所以,大多数业务开发者会更关注如何以最快的速度将应用开发完成并投入使用,实现“能用”的基础目标,而不是将精力投入到软件质量和可维护性等方面。“短平快”成为业务开发者构建应用的关键词,而这很可能互对软件的可维护性埋下不可忽视的隐患。相比之下,需要长期维护信息系统的IT部门中,IT技术人员则必须将质量与可维护性(包含功能扩展、数据一致性、系统集成等)放在重要的地位,否则就是给自己和其他团队成员“挖坑”,难以持续发展。

学习偏好:对学习投入更加敏感

不可否认,业务开发者在技术能力上可能会比IT技术人员者稍微弱一些,但这更像是业务开发者运行模式的结果,而不是原因。

为了进一步达到“短平快”的目标,应对不可持续的软件开发工作,业务开发者通常对学习投入更加敏感。除非通过当前岗位之外的工作熟练掌握了某些软件开发技能,业务开发者在学习软件开发技术中投入的每一分钟,都会拖慢项目交付的速度,扩大项目失败的风险。这是很多业务开发者最不愿意看到的情况。

抛开项目本身,相比于IT团队完善的职业发展道路和持续的实战机会,业务开发者在软件开发技术上的学习显得更加没有“性价比”。因为,业务能力才是业务开发者最显著的优势,也是其最大资本;而开发能力,还不知道什么时候才会再次用到。如何让业务开发者也有通过学习不断提升开发能力的机会和动力,是摆在业务开发者领导面前的难题。

风险偏好:对运维风险更加敏感

从学习投入低、更关注短期效果两个特点,我们不难看出业务开发者构建的应用比IT技术人员的质量风险更高一些。然而,业务团队对数据错误、系统可用性低、数据安全性差等系统运维风险的敏感性却不会因为开发者不同而展现出明显的差异。更麻烦的是,业务开发者本身处在业务团队,一旦他们构建的应用出现问题,所有损失将由该业务团队自行承担。在很多中大型企业中,这种风险不容忽视。

事实上,决定风险敏感度的首要因素是该软件的应用场景。在应用场景的类型上,企业上下对生产、销售、投资等核心业务系统的风险敏感度更高;OA、人事等边缘应用的敏感度更低。在数据操作能力上,负责人对仅读取数据的数据分析应用更加放心;而对那些需要写入数据,尤其是向核心业务系统写入数据的ERP二开等应用,要求更加严格。所以,让IT部门的技术人员专注于核心业务场景、需要写入数据的场景,边缘应用请相关业务团队的业务开发者参与,是一个被广泛接受的“最佳实践”。

 ◾“业务人员做软件”的风险与出路

2021年12月,国内知名IT媒体——T研究发布了《2021中国低代码/零代码全景产业研究报告》,其中重点关注了采用表单驱动技术路线,提供给业务开发者的使用的低代码开发平台在企业落地的挑战,并通过走访已经引入低代码但效果不如预期的企业客户,汇总了业务人员使用低代码平台开发软件应用失败的主要原因。

报告显示,“低代码的能力有限,无法支撑复杂业务场景”和“即使经过培训,业务人员依然无法顺畅使用低代码平台”两者成为失败原因的前两名。结合报告的上下文,T研究揭示了在“业务人员开发软件”的目标下,低代码平台的两难问题:既不简单易用、也不能打硬仗。

不能否认,软件开发是一个将现实中的问题用计算机所擅长的方式重新进行梳理和呈现的过程。在软件开发的过程中,开发者不但需要理解业务场景在现实中的运作逻辑,还需要具备必要的计算机相关知识,才能将其“翻译成”计算机擅长的样子。不同的应用场景中,这个翻译的难度存在很大的差异。比如,在简单的数据填报应用中,现实中的一张问卷可以直接对应为软件中的一个表单,而问卷中的问题则对应了表单中的数据字段。这类应用通常也称为“单表应用”,即便没有受过任何编程训练,甚至在大学中没有学习过计算机原理,业务开发者依然可以在低代码平台上轻松地完成整个应用的构建。但是,对于出入库管理这种业务逻辑稍显复杂的场景来说,现实中的一张出库单则需要对应成“出库单表”、“出库单明细表”、“商品元数据表”、“仓库元数据表”等多个数据表,才能确保这个应用具备一定的可维护性,并保障数据的一致性。开发这个类型的应用,需要业务开发者具备一定的计算机知识,或者至少有意愿在学习数据库相关知识上投入数小时甚至数天的时间。对于大多数企业中为业务成果负责的业务开发者来说,为了做系统而需要学习数据库知识,这种投入显然是不现实的。

综上所述,企业在为业务人员引入低代码技术时,需要清楚地认识到业务开发者所擅长的应用开发场景,正确管理对低代码技术的预期。在平台选择上,建议将平台技术能力的优先级提升到学习门槛之上,优先保障该低代码平台可以满足复杂应用场景所需,避免后期因切换低代码平台而造成返工。在实践上有如下建议,供有意推进业务人员开发软件的企业信息化决策者参考:

  • 推荐业务开发者构建使用频率不高,不需要与企业核心业务系统集成的单表型应用,如数据填报和流程管理
  • 如果业务开发者有意愿、有投入来学习更多计算机基础知识,特别是数据库相关知识,可以逐步参与到档案管理、数据报表等稍复杂的多表应用开发
  • 如果业务开发者构建的应用需要长期使用,推荐IT技术部门参与数据库结构设计等底层关键技术环节的评审,降低未来的维护成本
  • 如涉及到与核心业务系统集成,强烈推荐IT技术部门进行全程指导和审查,以确保业务开发者构建的应用不会影响到企业核心系统的稳定运行。

⬛ 混合模式低代码开发团队

◾构成:IT技术人员+业务开发者

在低代码技术普及之前,软件开发的技术门槛较高,仅有IT部门和软件公司具备开发软件的能力。这些受过专业编程训练的开发者能够将数十年来积累的软件架构和软件工程经验应用于企业信息化建设,但是受限于人才供给总量,软件开发产能严重不足。即便是预算较充裕的大型企业,在解决了核心业务场景的信息化之外,很有能拿出预算,投入到其他应用场景的开发中。软件质量尚可,但覆盖度严重不足,大量的业务流程和员工无法直接从信息化中获益。低代码技术的出现,让苦于信息化广度和深度不足的企业看到了解决信息化难题的新途径。在互联网厂商的宣传和推动下,很多企业将信息化的任务交给“业务开发者”,为业务部门配备低代码开发平台,要求他们自行解决信息化问题。但是,软件开发的技术门槛不仅在“编码”环节,还需要开发者掌握诸如数据库设计、系统架构、WebAPI交互等知识和能力,才能开发出可持续迭代的软件。事实上,业务开发者的IT技能严重不足,只能选择表单驱动的低代码和无代码开发工具,针对简单场景构建应用,而且可维护性差、难以与其他系统集成。即便拥有低代码,业务开发者依然很难为较复杂的业务提供信息化支撑。

IT技术人员供给不足,业务人员技术基础薄弱,只有将两者组合在一起,建立混合型团队,才能两全其美。混合型团队通常由IT部门领导,对信息化的结果负责,其核心人员为IT部门内部的专业技术人员,如程序员、项目经理、运维人员等(以下简称专业开发者),在为特定业务部门开发应用时,借调该部门中对软件开发感兴趣的业务人员加入团队。相比于IT部门的专业团队,混合型团队的运转对管理和技术提出了更高的挑战。除了在管理上明确借调的业务开发者与IT部门内部的专业开发者的分工之外,混合型团队的管理者还需要建立有效的技术支撑,以避免重复建设,确保软件的质量和可维护性。项目实践表明,基于模型驱动的低代码开发平台,建立低代码的数字化平台是混合型团队开展工作的最佳实践。

◾协作:低代码数字化平台战略

数字化平台的概念衍生于数据中台和数字中枢,在前两者的基础上强化了对个性化应用开发的支撑作用。数字化平台是一个软件开发平台,其下为现有的软件,其上为针对业务需求场景定制开发的各类应用。数字化平台的核心价值有两点:一是整合现有的软件的数据和能力,充分发挥IT投资的价值;二是简化应用软件的开发与迭代,用个性化应用支撑企业的数字化未来。为了实现简化应用软件开发的目标,数字化平台的落地通常基于低代码技术,所以,我们也将其成为低代码数字化平台。在应用层面上,数字化平台将面向需求侧的应用开发与面向技术侧的平台运维进行了分隔,和混合型团队的诉求高度匹配,非常适合作为混合型团队的工作模式进行推广。

第一步、IT技术人员集成现有软件,打造数字化平台

低代码数字化平台的开发的核心是对现有软件的梳理和整合。企业信息化不是一蹴而就的,不同时期上马的各个软件,如ERP、CRM、OA等成品软件和一些定制开发的软件项目,在技术上通常采用了不同的架构和系统集成用接口,如部署于局域网的ERP软件提供了.NET的二次开发SDK;SaaS模式的OA软件提供了WebAPI;而定制开发的软件项目仅能通过数据库里的数据进行交互等。这些技术和数据上的不一致,给后续的应用开发造成了不容忽视的障碍。如何能让新开发的应用与这些现有软件打通,一方面打通数据孤岛,实现业务流程一体化;另一方面减少重复建设,让IT投资保值?

实践经验上看,最佳路径是在现有软件的基础上搭建一层数字化平台,把各系统的元数据整合成一份,将现有软件的集成用接口整合成面向业务的WebAPI,提供给业务开发者。比如数字化平台提供的会计凭证生单WebAPI背后整合了ERP的SDK和定制开发系统的数据库读写。这意味着应用开发者无需关注平台上WebAPI的技术细节,而一旦需要替换或者升级现有软件,也仅需调整平台上的封装逻辑,而不会导致业务系统的大面积修改。这种整合了现有软件的数字化平台,有如下显著优势:

  • 打通数据孤岛,让业务流程更顺畅
  • 避免重复开发现有软件中已经具备的能力,让接入平台的现有软件更保值
  • 减少现有软件替换和升级对应用软件的影响,让基于平台开发的应用更保值

需要特别提示的是,在数字化平台的构建过程中,低代码开发平台需要提供双向WebAPI集成能力,不但支持调用第三方WebAPI,还需支持使用低代码开发平台构建WebAPI供平台上其他应用以及第三方应用调用。

在管理层面,数字化平台能将技术含量高,可维护性要求严格的系统集成部分从应用开发中剥离出来。让混合型团队中的专业开发者承担起所有的个性化应用的基础数据设计和系统集成工作,以确保这部分工作的质量可控。同时,在专业开发者的帮助下,业务开发者也能更方便的复用现有软件的技术能力,而不是从头实现这些复杂的业务逻辑,对于降低业务开发者的学习门槛也有不容忽视的价值。

 第二步、全团队基于数字化平台,低代码开发个性化应用

数字化平台为应用开发提供了技术基础,混合型团队管理人员还需要参照编码开发,结合低代码平台的能力,为专业开发者和业务开发者划定分工原则,并制定可执行的开发规范。

在实际工作中,平台建设中元数据和业务聚合工作是分阶段进行的。随着业务层应用的规划和实施,平台所能提供的WebAPI也会越来越多。而且,因为后续的应用开发均可直接使用之前交付的平台API,项目开发的边际成本也会随着时间的推移显著下降。但是,这并不意味着专业开发者在混合型团队中的重要性发生变化。这些具备技术能力的专业开发者可以投入到新技术的研究和验证中,将AI、IoT等先进的软硬件技术引入企业信息化建设版图,持续提升企业信息化系统的效能。

另一方面,因为技术要求较高的复杂业务逻辑开发被集中到平台建设阶段,业务开发者所需要掌握的技能水平得到了进一步下降。实践表明,经过低代码厂商数十个小时的系统化培训的,业务开发者在专业开发者的技术支持下,完全可以承担页面交互开发和简单业务逻辑开发的工作。

阶段 工作 专业开发者 业务开发者 说明
平台建设

 

现有软件的数据和接口梳理
开发和维护元数据WebAPI
开发和维护业务聚合WebAPI
建立和维护开发/测试/验证/生产环境
建立和维护代码库(如码云、Github)
平台测试(WebAPI) 因为平台没有界面,业务开发者不适合参与测试
应用开发

 

技术方案和架构设计 重点关注该应用需调用的平台WebAPI
应用级数据库设计 重点关注需要直连的现有软件数据库
开发服务端业务逻辑 专业开发者提供技术支持
开发页面和交互
应用测试 含发布到测试环境和验证环境
生产环境的应用部署与发布 重点关注数据库差分升级等环节

 
03 低代码的应用价值

低代码开发平台可以显著提升软件开发的效率,可广泛应用于各行业数字化转型升级。具体而言,开发者可以使用低代码开发平台,更简单、更快速地构建个性化应用 ,打造数字化平台 。

04  低代码发展现状 

随着互联网资本的介入,中国的低代码产业于2019年进入高速发展阶段。目前,近百家低代码厂商推出了不同类型的低代码平台产品,形成了4大商业模式 ,3种渠道模型 。不论是企业信息化部门还是软件公司都能从中找到与自身诉求和状况相匹配的解决方案。

​​​​​​艾瑞咨询《2021年低代码行业研究报告》

亿欧智库《2021中国低代码市场研究报告》

T研究《2020中国低代码平台指数测评报告》

海比研究《2021年中国低代码无代码市场研究报告》