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

做者:天晟前端

前言

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

什么是低代码

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

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

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

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

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

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

当前市场分析

市场规模

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

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

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

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

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

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

市场分类

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

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

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

市场布局

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

探索过程

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

从 2015 年开始咱们一步一步探索,作了不少不少,不管是技术上仍是产品上。好比模型驱动、小程序搭建等。这里面的每一块均可以单出拿出来说好久。这里我举几个例子简单描述下。

钉钉审批-表单

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

中后台页面搭建

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

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

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

再后来,随着咱们的功能逐渐的完善,好比多分支、回滚等功能,前端也开始渐渐接受了,平台侧有不少页面都是用平台本身搭建的。

服务化

当时咱们部门的业务,大部分中后台系统服务端都能自交付。减小了不少前端资源。咱们本身用舒服了,因而开始想让其余团队也能使用。但每一个业务场景都不同,默认的平台没法知足其余部门的诉求。因此咱们开始作服务化。

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

好比上图的例子,场景特别有趣,每次我都会拿出这张图分享给你们:绝对布局的画布构建好后,服务端会本身作特殊解析,最终显示在石墨屏上。相似这种例子有不少。包括后面要作的在线设计都是经过服务化来完成的。

代码互转/ WebIDE

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

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

可是单纯作出码没什么挑战,咱们也考虑了不一样角色的开发。当年的 WebIDE 也很火,因而咱们经过 WebIDE 作了一套搭建和代码互转的功能。咱们创造了本身的 DSL,其实也参考了 Salesforce,有了本身的语言,不少事情都好作了,也可控。小程序也是这样的。

后面的路怎么走?

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

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

看竞品分析。

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

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

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

结论呢?固然没有。竞品分析只能帮助咱们多了解,具体的方向还须要本身去探索和挖掘。

疫情带来的变化

疫情让我看到了:

疫情,业务变化之快。 企业创新,业务变化之快。 企业发展,核心是提效降本。

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

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

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

总结

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

后面还有不少的未知等着咱们。

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

一、场景壁垒 我以为咱们须要寻找更多的「场景壁垒」,好比,疫情下,快速交付的场景,为何疫情下你们会选择宜搭而不是选择其余开发模式,由于快且场景不是特别复杂,快须要找须要快的场景,这种场景其余方式没法完成,这就是壁垒。

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

三、生态 产品完整性有了后,就能够打造开发生态,经过更多的开发者生产更多的物料、服务。同时平台能够链接更多的物料、服务。

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

五、灵活性和易用性 灵活性和易用性的平衡若是作很差,平台也很容易作差。我看过一个竞品,真的作到了代码彻底交互化,0 代码,可是,前端的逻辑用交互编排的方式,其复杂度根本没办法二次维护。

讲了这么多,并无确切的回答以前本身提的问题,由于没有彻底正确的答案,咱们仍然须要不断的探索。低代码将成为B端服务领域的基础设施,必将颠覆传统开发方式,将来可期。欢迎来一块儿探索低代码将来的发展方向,感兴趣的能够加我微信:alex-mm-ts。

查看原文

相关文章
相关标签/搜索