写点什么

2B 领域下低代码的探索之路

  • 2021-03-14
  • 本文字数:4218 字

    阅读完需:约 14 分钟

2B 领域下低代码的探索之路

前言

大家好,我是钉钉宜搭前端一个小团队的负责人天晟,在阿里做了五年的低代码。今天的分享我们不讲技术细节,主要会分享下我们这五年的探索过程和当前的市场分析,希望能给大家带来一个对低代码搭建不一样视角的认识。

什么是低代码

说起低代码(Low-Code)这个词,是在 2014 年,Forrester Research 第一次正式使用低代码来描述这个市场。国内也就是近几年开始流行的,以前我们这边叫「可视化搭建」,可视化搭建讲起来有个很大的缺点,就是很容易和数据可视化傻傻分不清楚。我还记得,2018 年的时候,当时做一个分享,主题是 「泛可视化搭建的解决方案」,我老板的老板说建议我把「泛可视化」改为「低代码」,我当时回复说不改,低代码听着有点 low,「泛可视化」高大上些。后来也不知道什么时候开始习惯了一口一个低代码,而且衍生了 Node-Code/Pro-Code。现在回想起来,当时是自己 low。


看下业界领军者对低代码的定义:

outsystems: 「低代码是一种软件开发方法,可以更快地交付应用程序,并且只需很少的手工编码。低代码平台是一组工具,这些工具可以通过建模图形界面来可视化应用程序开发。可以使开发人员可以跳过手工编码,从而加快了将应用程序投入生产的过程。」


mendix: 「低代码开发是一种可视化应用开发方法。通过低代码开发,不同经验水平的开发人员能够通过图形用户界面,使用拖放式组件模型驱动逻辑来创建 Web 和移动应用。低代码开发平台减轻了非技术开发人员的压力,帮其免去了代码编写工作,同时也为专业开发人员提供了支持,帮助他们提取应用开发过程中的繁琐底层架构与基础设施任务。业务和 IT 部门的开发人员可以在平台中协同,创建、迭代和发布应用,而所需时间只是传统方法的一小部分。这种低代码应用开发方法可针对不同用例开发各种类型的应用,包括将原有应用升级为支持 IoT 的智能应用。」


可以提炼出几个词:模型/建模、图形界面、拖放组件、加快、减轻。连起来就是:通过模型/建模、图形界面拖放组件可以加快应用开发,减轻了非技术开发人员的压力。其实从前端的角度看,低代码的鼻祖应该是它:

image.png

从我目前阶段的理解,低代码是这个:

image.png

当前市场分析

市场规模

根据 Forrester 的报告,2019 年该领域的规模估计为 38 亿美元,预计在 2021 年这一赛道的市场规模将增长到 152 亿美元,75% 的应用程序将在低代码平台中开发。到 2022 年该市场规模将达到 212 亿美元。


根据 Gartner 预测,到 2021 年应用开发需求的市场增长,将至少超过企业 IT 交付能力的 5 倍。到 2024 年全球约有 65% 的应用程序都将涉及低代码开发(Forrester 、Gartner 全球最具影响力的独立研究咨询公司)。

image.png

1、领导者:行业领导者既要表现出超强的执行能力(好的产品与良好的销售业绩相匹配),又要表现出具有远见(产品创新和相称的营销策略)的战略计划。LCAP 的领导者主要包括云 SaaS 提供商(Microsoft、Salesforce、ServiceNow),专业的低代码提供商(Mendix、OutSystems)以及混合 RPA 和低代码应用程序供应商(Appian)。这些供应商具有强大产品能力、市场影响力以及用户体验。


2、挑战者:在市场占有率、产品能力方面与领导者的差距并不是很大,未来有能力成为该行业领导者。


3、特定领域者:不仅可以提供低代码应用平台技术,还混合了其他技术,例如,RPA、业务流程挖掘、BPM 等技术。他们是 LCAP 行业的中流砥柱,拥有良好的发展空间。


4、远见者:远见者具有良好的合作生态以及市场发展策略,在产品创新方面也有很强的能力。但是在业务执行方面与领导者有着较大的差距。相信随着时间的推移他们会更上一层楼。

市场分类

image.png

目前我看到的市场上主要有两类:

一种是基于表单驱动,核心能力是表单、流程、报表,在一定的场景下,可以快速的做业务交付,上手成本也比较低。比如:宜搭、简道云、明道云、氚云等。


另一种是基于模型驱动,核心是领域模型、业务沉淀、完整性,有一定的技术壁垒,上手成本相对比较高。比如:Outsystems / Mendix / PowerApps / 奥哲云枢 / 金蝶云苍穹等。

市场布局

image.png

拿 PowerApps 来举例,上面四个分别是 云 + 端 + 协同 + 低代码。已经是很大、很先进的布局了。从中我们能看到低代码平台只是其中的一部分。独木不成舟,独木舟,虽然简易也能用,但毕竟能力有限。

探索过程

用两句话来概括下:1. 始于表单终于表单;2.从技术到产品。


image.png

从 2015 年开始我们一步一步探索,做了很多很多,无论是技术上还是产品上。比如模型驱动、小程序搭建等。这里面的每一块都可以单出拿出来讲很久。这里我举几个例子简单描述下。

钉钉审批-表单

image.png

钉钉审批,这个搭建当时只有 8 个组件,功能也很简单,和现在相比也和易用。毕竟简单,这个仅仅是我们的开始,之后一发不可收拾。

中后台页面搭建

image.png

后来我们开始做中后台页面搭建,但在开始推广时,却受到了很大的阻力。


我们开始给前端用,技术同学是来写代码的,就排斥这种高不成低不就的搭建平台产品,而且功能又不全,大家意见很大。后来,我们给服务端开发用,当然服务端也是排斥的,不只排斥搭建,就像让一个写 Java 的人做前端的页面就是排斥。


但没办法,前端资源就是不足,再加上从上层开始推,那一年,效果突出。有些服务端的同学用的简直飞起,他们做页面特别快,没有联调成本,接口都是自己定义的,想怎么搞就这么高,而且代码写的很规整。


再后来,随着我们的功能逐渐的完善,比如多分支、回滚等功能,前端也开始渐渐接受了,平台侧有很多页面都是用平台自己搭建的。

服务化

当时我们部门的业务,大部分中后台系统服务端都能自交付。减少了很多前端资源。我们自己用舒服了,于是开始想让其他团队也能使用。但每个业务场景都不一样,默认的平台无法满足其他部门的诉求。所以我们开始做服务化。


服务化就是我可以让其他团队也快速拥有低代码搭建的能力,并且可以做定制,比如组件定制、设计器面板定制。这样思路就打开了,不仅能支持其他团队的中后台场景,凡是和搭建相关的场景,都可以做。


image.png

比如上图的例子,场景特别有趣,每次我都会拿出这张图分享给大家:绝对布局的画布构建好后,服务端会自己做特殊解析,最终显示在石墨屏上。类似这种例子有很多。包括后面要做的在线设计都是通过服务化来完成的。

代码互转/ WebIDE

随着我们的用户量越来越多,复杂功能的实现和后续的可维护性受到了很多的挑战。


典型的例子是:开始我的需求比较简单,用搭建快速完成了,但后面的需求评估下来发现搭建满足不了。于是我们开始做出码,将搭建产物转成代码,继续开发。


但是单纯做出码没什么挑战,我们也考虑了不同角色的开发。当年的 WebIDE 也很火,于是我们通过 WebIDE 做了一套搭建和代码互转的功能。我们创造了自己的 DSL,其实也参考了 Salesforce,有了自己的语言,很多事情都好做了,也可控。小程序也是这样的。


image.png

后面的路怎么走?

灵魂三问:1. 如何能把价值再做大?2. 低代码 or 零代码?3. 用户是谁?


再问:能否商业化呢?要不要商业化呢?如何商业化?


看竞品分析。


Salesforce / Power Platform / 金蝶云苍穹,他们的 PaaS 都是有明确支撑的业务领域,CRM / ERP。PaaS 是基于自身的 SaaS 长出来的。我们要主打那块业务?哪块业务能找到市场?


如果单纯的做 PaaS,感觉最后做出的可能还是工具。工具类的竞品,像 Outsystems/ Mendix,他们提供是软件工具、方法和架构,可以快速建模、测试、部署、管理等,是一套完整应用开发的闭环(测试、部署、调试、稳定性等)。所以,单纯做工具,最后被收购?像 Mendix。还是支撑 SaaS 为目标?我们要打的 SaaS 行业蛋糕还有吗?另外还要考虑多租、二开等,技术复杂度极高。


再看看国内,简道云,背后是帆软-数据出身,氚云-流程出身。两个产品都偏零代码,产品体验做的都很不错。猜测应该都是先有独立的能力,后发展后低代码平台的。


结论呢?当然没有。竞品分析只能帮助我们多了解,具体的方向还需要自己去探索和挖掘。

疫情带来的变化

疫情让我看到了:


  • 疫情,业务变化之快。

  • 企业创新,业务变化之快。

  • 企业发展,核心是提效降本。


去年因为我留杭过年,所以参与到了疫情项目,用宜搭来做健康打卡,从大年三十一连续在家干了两周,7 * 24 小时待命。


健康打卡应该大部人都用过,看着简单,其实背后有很多复杂,有针对员工的,有针对 HR 的,还有针对海外的。需求变化之快,今天加个高风险城市,明天加个海外地区,需要各种定制。一个前端,全链路完成,快速试错、快速上线。如果没有宜搭,真搞不定。后面我也去其他类似的竞品看过了,我们这边的定制场景还真都无法完成。


这次项目让我更深刻的认识了宜搭产品的价值。

总结

image.png

2B 领域下的低代码适合用冰山理论来解释。部分人认为的,包括 5 年前的我也是这样认为的,拖拽设计器 == 低代码。后来在深入做了两年后,发现有物料、多端、出码、布局、逻辑、国际化、监控、模板、协议、服务化、帮助体系这么多功能要做。再往后做,要从 2B 的视角去看,就像之前微软的那边的局部,云、协同、端。


后面还有很多的未知等着我们。

image.png

再回到现实,总结五个点。

1、场景壁垒

我觉得我们需要寻找更多的「场景壁垒」,比如,疫情下,快速交付的场景,为什么疫情下大家会选择宜搭而不是选择其他开发模式,因为快且场景不是特别复杂,快需要找需要快的场景,这种场景其他方式无法完成,这就是壁垒。


2、完整性

用户需要在这个一个平台上能把所有研发相关的事情全部做完。完整性也包括了可维护性。可控的开发质量、维护性和升级成本;二次需求开发。


3、生态

产品完整性有了后,就可以打造开发生态,通过更多的开发者生产更多的物料、服务。同时平台可以连接更多的物料、服务。


4、连接

这里的连接有两层含义,一个是产品之前的连接,一个是数据的连接。产品的连接可以产生 1 + 1 > 2 的效果。目前的趋势,是在改变传统的 ERP/CRM 大而复杂的软件系统。越来越多小而灵活的应用产生,而且随着企业的创新需求变化越来越快,系统越来越多,但不能做成烟囱,数据的连接尤其重要。


5、灵活性和易用性

灵活性和易用性的平衡如果做不好,平台也很容易做差。我看过一个竞品,真的做到了代码完全交互化,0 代码,但是,前端的逻辑用交互编排的方式,其复杂度根本没办法二次维护。

image.png

讲了这么多,并没有确切的回答之前自己提的问题,因为没有完全正确的答案,我们仍然需要不断的探索。低代码将成为 B 端服务领域的基础设施,必将颠覆传统开发方式,未来可期。欢迎来一起探索低代码未来的发展方向,感兴趣的可以加我微信:alex-mm-ts。


本文转载自阿里巴巴中间件(ID:Aliware_2018)

原文链接:2B 领域下低代码的探索之路

2021-03-14 08:004603

评论 3 条评论

发布
用户头像
市场分类有点问题,表单流程类只是垂直低代码领域中一个小领域,不足以构成一类。可能按通用低码平台和垂直低码平台合适些
2021-08-24 09:50
回复
用户头像
我理解的低代码是对能力的打包输出,站的角度更高一些,而不是单纯的用拖拽和dsl来代替代码,那样就太细节了,细到最后发现跟直接用代码写没啥区别。
2021-03-18 11:09
回复
用户头像
说的算中肯,但还没到点上
2021-03-15 10:30
回复
没有更多了
发现更多内容

AWS x 红帽 | 以客户需求为驱动,加速开放混合云落地

亚马逊云科技 (Amazon Web Services)

云计算 红帽 AWS

2021 十大技术趋势扑面而来,你准备好了吗?

李忠良

区块链 人工智能 云计算 大数据 架构

Prometheus学习笔记之查询【基础篇】

卓丁

Prometheus Monitor 监控告警 普罗米修斯 PromQL

28 天带你玩转 Kubernetes-- 第二天(K8s介绍)

Java全栈封神

Kubernetes k8s k8s入门 28天写作 k8s历史

前端性能优化之指标

知识乞丐

大前端 28天写作

如果梦境取决于一串代码「幻想短篇 2/28」

道伟

28天写作

28 天带你玩转 Kubernetes-- 第二天(K8s 介绍)

Java全栈封神

Kubernetes k8s k8s入门 28天写作 k8s历史

Activemq Jms 简单示例

Java 消息队列 JMS Activemq

Spring Cloud Gateway (七)处理流程解析

Java 网关 SpringGateway

推荐系统解构

DataFunTalk

大数据

同理心

lidaobing

28天写作 了不起的盖茨比

海明威《老人与海》

抗哥

28天写作

中国金融科技权威盛会点赞了这个来自 AWS 的金融行业解决方案

亚马逊云科技 (Amazon Web Services)

云计算 AWS

28天瞎写的第二百一三天:背代码的故事

树上

代码 28天写作

大作业二

Geek_83908e

架构师一期

justauth-spring-boot-starter V1.3.5 发布成功

RD

OAuth 2.0 justauth 第三方登录

Springboot 开发环境搭建和项目启动

武哥聊编程

Java springboot SpringBoot 2 28天写作

python 基本数据类型-1

赵开忠

Python 28天写作

洞察

JiangX

创业 投资 认知 28天写作 洞察

爱奇艺SOAR探索与实践

爱奇艺技术产品团队

安全

SpringBoot 系列 2——SpringBoot原理分析

程序员的时光

程序员 springboot 七日更 28天写作

详细教程丨如何利用Rancher和Kong实现服务网格?

Rancher

微服务 k8s

价值创造

JiangX

创业 投资 认知 28天写作 价值

【薪火计划】09 - 员工激励理论

AR7

管理 28天写作

大作业 1

郎哲

追寻人生的意义

三只猫

28天写作

架构师训练营大作业

Shunyi

「架构师训练营第 1 期」

想不想get和湖南卫视一样的现代直播?

亚马逊云科技 (Amazon Web Services)

优化无止境,爱奇艺中后台 Web 应用性能优化实践

爱奇艺技术产品团队

大前端

领域驱动设计在爱奇艺打赏业务的实践

爱奇艺技术产品团队

架构 DDD

关于私域流量与社群的思考

.

28天写作

2B 领域下低代码的探索之路_架构_阿里巴巴中间件_InfoQ精选文章