陈果说低代码快要烂大街了,我却想成为最烂的那个

分享 零代码明道云  收藏
0 / 632

2.jpg

文/明道云创始人任向晖

我很喜欢的一位博主陈果昨天发了一篇公众号文章《低代码,不要以比“中台”还快的速度烂大街》。愤世嫉俗的口吻总是能够吸引眼球,果不其然,等我读到的时候,阅读量已经过万了。

我的事业身家都在零代码/低代码领域了,他又是我一直很认同企业数字化专家,还专门写一篇文章来批判低代码,搞得我晚饭都没吃好。

我当然理解他的意思,也认同文章中部分的观点。很多低代码产品缺乏新意,只是可视化开发工具的延伸,很多厂商有概念炒作的嫌疑,自然让业内砖家忍不住要抄起几块砖。在陈果之前,还有一家知名 IT 咨询企业的 CTO 在视频号上有过类似的表达,他的口气真是不屑一顾。市场有多少低代码,就有多少“低代码是个伪命题”的评价。我也发现传统企业软件的咨询师普遍看衰低代码,而企业 IT 管理者则普遍关注低代码。点评的人是真不知道做事情的难。

我是利益相关人士,从业于低代码领域,且看好低代码未来。我不能让这些唱衰的妄断影响用户的心智,但也不会空洞地挥舞低代码的大旗。我要尽全力说明清楚低代码的本质是什么,为什么这一代产品和过去有本质不同,为什么它的发展会有益于整个企业 IT 市场,为什么烂大街并非一件坏事。

低代码/零代码的实质是什么?

陈果可能认为低代码平台的实质是代码依赖度更低的开发工具。其实并不是这样。包括明道云在内的这一代零代码/低代码(为简便起见,后面我统称低代码)平台的实质是“应用平台”(APaaS),低代码只是它的使用特征之一。所谓应用平台,就是 DevOps(应用开发和运维体系)的对立面。应用不再需要通过原生高级语言(Java,PHP,C#等)编写,也不再需要完整的软件开发角色分工(DBA,后端开发,前段开发,交互设计,界面设计,测试等)。真正意义上的 APaaS 是不会有 IDE 环境的,也不会有代码编译,更不会有搭建应用运行环境的繁复过程。应用通过 APaaS 搭建(我避免使用开发这两字),搭建完成后,就在 APaaS 上直接运行。

APaaS 对用户结构的改变是不言而喻的。因为摒弃了 DevOps 过程,非软件开发人员终于可以直接参与到应用建设的过程。有人说,市场上并不缺少开发者,为什么一定要消除对他们的依赖呢?事实是市场上就是缺开发者,更缺的是能力强的应用开发者,因为他们大多数人都在科技行业从业,很少会直接助力一般行业的数字化建设。

即使有优秀的软件开发者,为了产出高质量的企业应用,依然需要很多专业环节,比如需求分析、系统架构、产品交互设计等等。这些专业过程极其费神,也非常昂贵。对于大部分的企业软件实现,这些过程大多数是草率处理或者被忽略的。

应用平台的妙处就在于把这些专业过程全部通过平台来模式化实现,虽然牺牲了一定的灵活性,但提供了高质量和高效率。我们仅仅为了一个数据详情页,是十多位产品设计和前端开发迭代数十次以后才达到理想水平的。

模式化实现企业应用到底对灵活性的牺牲大不大呢?其实并不大。大多数的企业应用都是由业务数据的增删查改操作,工作流执行和管理,以及对业务数据的分析汇报等模式组成的。这也难怪很多企业软件都长得非常类似。即便是通过原生技术栈定制开发,开发实现过程也极度相似。所以在原生开发市场,也出现了大量的开源框架,让开发者可以提高效率。比如国内开发者常常使用 Activity 这个开源工作流框架来实现 Workflow,用 Ants 这个前端框架来快速实现企业应用的前端界面。这也难怪陈果认为低代码并没有节省多少开发的时间。但正是这种模式近似性,让 APaaS 有了普及运用的可能。实际上,也正是因为这种灵活度的牺牲,APaaS 可以非常专注在企业中后台应用实现上,对其他类型的应用开发心无旁骛。陈果认为低代码并不能用来开发所有的软件,这当然是对的。

至于市场上依然有一部分 APaaS 会生成源代码,并允许用户调整源代码,甚至使用第三方编译环境,我认为这才是陈果说的“新瓶装旧酒”。它们的实质依然是开发工具,只是可视化程度高,对代码编写的依赖度小。很不幸,在这个领域最知名的厂商 Outsystems 就是这么一个模式。即使是 IDE 模式的 APaaS 也有价值,它至少大幅缩短了开发周期,但他们还是依赖程序员,没有接受过软件开发训练的人员是很难掌握的。

低代码不是玩具

人总有望文生义的认知偏见。说是“零代码”,“低代码”,那必定就是简单的工具。简单的工具就只能打造简单的应用,这是毫无道理的武断。Photoshop 和 After Effects 能够创造出的华彩无比的影像作品和动画,你从来没听说过要写代码;能不能写代码从来不是评价软件工具先进性的指标。过去没有,以后也不会有。尤其当应用平台已经脱身于开发工具市场之外,它提供的就是一个搭建应用的应用,至于能够设计和搭建出什么样的应用,主要依赖的是用户的创作能力,而不是工具本身能够决定的。

如果真的像陈果说的,低代码产品只可以用来完成简单的工作流和表单流转的应用,那我们不必大费周章。在 APaaS 之外,已经有很多轻量级的 SaaS 工具可以做到了。而且,传统的 OA 套件也都能够创建自定义的业务对象和流程,根本轮不到 APaaS 来替补。

实际上,今天的 APaaS 能够承载的业务复杂度是可以相当高的。明道云在金融业的 ISV 伙伴已经复刻出类似于 BMC Remedy 这样的 ITSM 套件,虽然没有覆盖 100% 的业务环节,但把其中个性化程度高的流程部分解决得非常好;我们在税务科技领域的合作伙伴普华永道,完整地提供房地产行业的税务精算系统;可口可乐亚太技术中心利用明道云搭建了实验室数据管理系统,我们在交通运输的标杆客户佛山地铁和北京地铁都已经将 APaaS 用在了非常高频的设备管理、安全管理等环节上。佛山铁路投资集团甚至专门建立了零代码实验室,让项目专家直接上手设计和搭建应用。这些事实陈果可能不知道,但是我必须让潜在用户群体知道。我们明明做了一个弹跳杆,却被业内砖家说成是垫脚石,这是有失公允的。

当然,我也承认,现代 APaaS 产品有一个建立用户信任的过程。在这个阶段,很多用户选择将 APaaS 用在一些局部的简单环节,先进行成熟度和可靠性验证,这是完全可以理解的。但这个过渡现象不是我们产品的标尺。

低代码不是软件业革命,So What?

陈果指出低代码并非软件业的革命,这玩意早就有了。完全正确,第一代应用平台产品诞生在上个世纪末,距离现在已经 20 多年了。是革命,也早就革命完了。我们 2B 创业者追求并非是革命机会,而是渐进的改进机会。渐进的改进,幅度大一些,持久一些,才是创造商业价值的有力途径。革命期的 IT 产品几乎必然是低性能的,残破不全的,只能够服务先锋性客户的。陈果先生想必非常熟悉 Gartner 的 Hype 曲线(技术成熟度曲线),APaaS 品类早已过了那个过山车的顶峰,今天正在走进“寻常企业家”。所以 Gartner 开始把 APaaS 作为魔力象限的研究范围。

当一个市场开始渐进改进之时,正是它开始走向成熟的时点。这时候,先发优势和后发优势都有效。APaaS 的前身——快速开发工具(RAD)身上的缺陷开始被消除,产品能力越来越强,用户体验越来越好,有效的商业模式也开始被探索出来。在这样的市场中,创业企业不必再承受过大的不确定性风险,看好增长的市场机遇。尤其是低代码市场还没有明显的领先企业,创业者和投资人当然都卯足了劲。这也是为什么过去两年中,新出现的低代码产品比较多的原因。

不仅有这四十多家创业公司参与,阿里和腾讯都推出了自己的低代码产品。如果不是革命,只是改进,那么为什么整个市场会投入如此大的关注呢?归根结底还是因为市场大,需求旺盛。

APaaS 可以满足不同层次的市场需求。首先它肯定能够完胜传统定制开发,即便一个项目不是 100% 能够依靠 APaaS 实现,也可以将 APaaS 作为主要的基石,额外做一些扩展开发即可。仅仅定制开发一项,能够覆盖的市场规模就极为惊人。在中国广泛存在的区域性软件服务企业中,大部分从事的都是定制开发服务。过去,这些需求被散乱的开发人天所满足,未来,APaaS 将成为主要的交付基石。

其次,APaaS 平台可以积累各种行业应用的数据模型和解决方案,通过高水平的抽象后,它也能够替代一部分专有性要求较低的行业软件产品。我们在服务实践中发现,像制造、工程、专业服务等领域,所谓的行业应用产品都可以被 APaaS 替代,因为他们大多是半成品,真正要落地到每家企业,还是要做比较多的实施工作,这本质上和 APaaS 的实现投入是一样的。而 APaaS 还能够提供额外的灵活度。

第三,很多企业都有了“中台”的理念。当业务规模成长到一定阶段时,企业希望能够从各个应用或子系统中抽取关键业务对象数据,从而实现企业范畴内的数据一致性和共享性。APaaS 真是特别适合干这个工作。通过一些简单的集成开发,汇入数据到 APaaS 上,再通过 APaaS 所提供的 API 对外进行服务。买一套 APaaS,基本就拥有了一个数据中台的实质。这对规模以上企业是有很强吸引力的。你可以说数据中台的建设需要很多专业技术栈,但是对绝大多数行业来说,APaaS 的内置能力就已经够了八九成了,剩下的一些细节完全可以靠补充和扩展来解决。我们的一个跨境电商客户,每天 40 万左右的订单和运单,每个单据都有三到四个工作流要实时触发,完全运行在我们的云平台上。

低代码产品的确在增多。多归多,相比较其他领域,LCAP 或 APaaS 市场的进入门槛依然比较高。我看到 2020 年发布的最长的一个厂商列表也不过 40 多家(这其中很多依然是快速开发工具的性质)。但是在同期,CRM 产品可能有数百家,就连生产执行系统(MES)产品和厂商都有这么多。相比较各自的市场容量,APaaS 的竞争远没有到烂大街的地步。

我们想成为最烂的那个

我其实是多么希望低代码烂大街啊。什么叫烂大街?就是人尽皆知呗。川菜烂大街,广东菜烂大街,火锅烂大街,那是因为它们都是餐饮业的主流。低代码之于企业软件,烂大街的一天就是成为主流的一天。所以,我们明道云就想成为烂大街上最烂的那个,火锅店中的海底捞。

问题是,成为海底捞真的不容易。海底捞在餐饮业依靠独特的服务理念赢取了顾客口碑,在企业软件行业,这把钥匙是什么呢?我想了二十年也没得到确定的唯一答案。但是对于 APaaS 来说,我觉得最重要的可能是“易用性”。

易用性是打开营销获客、产品价值、渠道拓展和客户服务四个魔盒的通用钥匙。解决一个问题,就等于同时解决了四个问题。尤其是像 APaaS 这样的复杂产品,易用性显得难能可贵。去年,国内出现了好几家完全模仿 Airtable 的产品,我想他们都看中的是 Airtable 的易用性。

陈果认为 APaaS 面向“公民开发者”是不现实的。我认为不仅现实,而且太重要了。企业的数字化问题凭什么都要程序员解决?如果真的是这样,那几十年来的 Excel 高手们都是干什么的?理解业务,熟悉业务,掌握数字化工具,是越来越多企业内部寻求的人才对象。APaaS 服务的就是这样一群专业用户,通过他们可以间接服务到各行各业的企业。这样的人才当然不是烂大街,但是总归比受过专业训练的程序员多得多,更重要的是他们同时是需求的提出者和满足者,省却的沟通和协作成本是惊人的。陈果先生担心低代码产品离不开专业用户的使用,这是对的,但是不要忽视这个庞大群体的存在。

所以,我们相信并坚决地服务非开发人员掌握 APaaS 产品,把产品的易用性永远放在首要位置。一个再强大的产品,如果难以掌握,是不可能烂大街的。相反,把一个复杂产品做得容易理解,容易上手,容易解决问题,真的是一件特别有成就感的事情。我们在产品设计评审时,最常见的挑战就是功能的可理解性,而不是功能的多寡。如果我们自己内部都不能达成统一理解的,就绝对不会发布给客户。

我们自信把明道云的功能和易用性平衡得很好。市场也给了我们积极的回应。在产品推出后的 19 个月中,我们的客户上至中国人民银行这样的国家机构,下到几十人的电商团队都可以很好地运用。接下来,我们要做一个更让自己烂大街的动作。通过这篇文章,我想预告给大家,明道云将在今年春节前推出“免费版”,让人人都可以成为应用开发者的口号真正落实。好的产品,就应该放下门槛,让更多人可以接触到。

海底捞很厉害,能够免费吃的海底捞更厉害。欢迎大家下个月到免费的明道云来吃火锅。