我说低代码快要烂大街了，向晖却想成为最烂的那个

另一篇响应陈果原文的文章：

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

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

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

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

 【陈果评】

拙文让向晖没有好好吃饭，真是过意不去，请你喝酒！

原文题目是《不要....烂大街》，主旨就是不希望低代码被过度炒作，并不是否定低代码软件本身。我认为低代码软件的企业应用特点是：

1、特定应用场景——核心系统功能延伸，短流程的表单、工作流和信息集成展示报表

2、产品生命周期 —— 多为自然生长，应付临时使用，生命周期短

3、企业架构中的定位—— 短期来看是个快速开发工具，长远看，必须搭载在企业数字化平台上，充分利用内部和外部云上的各种业务、数据和功能的服务

4、局限性 —— 可能带来数据治理、信息安全的问题

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

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

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

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

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

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

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

 【陈果评】

“低代码”如果和APaaS画上等号，与其说是技术问题，不如说是软件公司的商业模式问题。

我原文中也说到了，即使刨除那些鱼目混珠的低代码工具，现在APaaS有三个商业模式，一是从SaaS延伸的，以Saleforce，ServiceNow为代表，微软Power也可以算，可以利用SaaS上的统一数据模型、业务服务，当然大多也是利用了这些平台现成的APP分发机制和运行框架，从Salesforce近期财报看，平台业务增长最快，当然，这不仅是salesforce的低代码，还包括了Salesforce的“高代码”开发平台Heroku、云集成平台MuleSoft以及BI平台Tableau等，这其实和ERP时代从应用软件向中间件软件发展（例如SAP做NetWeaver）的道理是一样的，只是这是云时代的特点，所以国内企业软件大厂用友推出BIP，金蝶推出云苍穹/EBC，都是这个意图，根源上，这些厂商还是要靠企业用户的“钩子产品”才可能发展平台：

二是独立的APaaS平台，必须依赖企业级平台来进行应用分发，利用其他云的运行时环境，明道云属于这种模式，此外，有些所谓的“中台“厂商提供的低代码工具，我觉得也属于这种模式，

三是现有IaaS/PaaS云厂商提供低代码开发服务，由于低代码市场抬头，我观察这个趋势才刚开始，这个模式扩张后，会挤压第二个模式的生存空间。

下面这张图来自SAP的产品战略，我觉得将技术开发和用户流量结合起来的平台模式，才是低代码开发的终极模式：

低代码不是玩具

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

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

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

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

 【陈果评】

我花了不少时间看市面上主流低代码工具的演示，油管上有非常多的、完整的演示和教学视频，对低代码的工作原理、开发能力深度有所认识（如果认为我光靠视频就下断言，就不太“低代码”精神哈，所以，此判断不接受反驳😂）。

实际上，低代码抢的是自开发软件市场，我说的ERP是套装软件市场，本来是两个不同的跑道（下图），我的文章批评低代码炒作的初衷是一些厂商销售人员将低代码说得无所不能，跟“中台”一样，可以替代传统ERP等套件，这对企业IT决策者是很大的误导，而且偏偏这种误导已经让我不止一次遇到了。

低代码不是软件业革命，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的竞争远没有到烂大街的地步。

 【陈果评】

对于企业IT应用，核心系统不能覆盖到、用户又的确需要的边角功能如何满足的问题，可能又到了“自研”还是外购SaaS的纠结了。

如果“自研”，有两条路：一是IT部门给业务部门开发，二是业务部门自己用低代码工具做。其实企业自建云平台后，在核心系统之上开发应用也越来越多，我见过某大型消费品企业自建数字化平台和企业APP市场，自己开发了从厕所占坑、食堂订饭到设备维修（就是向晖说的场景）、产销计划调度等上百个APP。

低代码的确有业务部门“开发不求人”的好处，我并不否认，不过这是跟IT专业开发、外购SaaS的三个选择之一。

我们想成为最烂的那个

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

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

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

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

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

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

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

 【陈果评】

向晖这个Excel的例子很好，我来做个调研，各位读者评估一下你们企业实际业务用户中的Excel水平究竟怎样：

据我在实际中的观察，大多数企业业务用户的Excel水平是很差的，很少有像我当年在企业工作时还用Access+PB来动手的；前段时间跟一家银行IT部门切磋，他们最大苦恼是业务人员自己就没有习惯用IT和数据化工具，连Excel都懒得用，我建议他们IT人员gei给业务人员提供贴身服务，美其名曰ITBP；今天让业务人员用低代码工具同样会是一个挑战。低代码产品本身的易用性，以及易用性背后的软件工程水平，将是各家低代码厂商将着力解决的问题；同时，低代码工具面临和其他任何IT系统实施一样的变革管理问题。

所以，我非常赞成向晖提出的明道云“免费”这个举措，培养用户习惯，增强用户粘性，是第二种模式“低代码”平台的突破之路。