如果从SaaS之类来看这个问题是看的不够仔细的，感觉部分产品经理不太能理解这个是什么，所以可以换一种方式来说

1.low-code投资属于战略布局

2.为什么要投资low-code

一句话说明白

面向过程编程（POP）：PC互联网，大家在电脑上玩扫雷

面向过程到面向对象编程(OOP)：移动互联网时代，OOP支撑起了超越pc端时代庞大的体系和业务

面向对象到面向服务编程（SOP）：未来互联网的工具基础支持

而low-code就是面向服务的一种尝试落地,硬要说的话也不要说SaaS,而应该先说FaaS和BaaS。

而且未来它的前景并不是SaaS，准确说它推动的SaaS体系和当今的SaaS是不一样的。有些创业公司起这个名字是为了适应当下大家的认知和当下的业务。

今年 low-code 平台有些逐渐要火起来的苗头了，但大部分的人还是在套概念蹭热度，少有人能想清楚这其中的逻辑。在我看来大部分 low-code 平台所吹的内容要么过于复杂是在重复造一个新的编程平台，要么就是在用另外一种方式重新发明 SaaS。

有些人也会拿已经成熟的诸如 Microsoft PowerApps 这种产品来说事儿，没错确实微软也是把它当作 low-code 来宣传的，但不要忘了有个非常坚实的 SaaS 平台 Microsoft 365 作为基础在那儿。

我这里整理了三个问题，可以用来针对性的检验一个 low-code 平台是否靠谱。

一、可以确定 low-code 平台的出现是为了提升效率。而提升效率则意味着要么某些动作被自动化了，要么就是某些功能被复用了。low-code 通过模型定义和组合操作来实现最终的业务，那么，

• 所被自动化和被复用的是哪些东西？
• 为什么这些东西必须使用 low-code 平台才能实现自动化或者复用？

二、low-code 平台一个重要的点是可以以一种非代码的方式呈现业务流程，并且可以进行动态的改进。而改进的点无非是模型变动或者业务逻辑变动。那么，

• 如何反映这些变动？
• 如何进行模型变动的迁移？
• 如何验证业务逻辑变动的正确性？
• 也即，low-code 平台是如何进行配置管理和持续集成的？

三、low-code 平台能够让不了解代码的人也能做到实现和定制业务流程。那么根据康威定律，

• 适用于 low-code 平台的组织架构是什么样子的？
• 业务人员、IT 运维和研发人员是什么样的配比？
• 以及业务、IT 和研发人员三者之间以什么样的工作方式协同？

其实挺期待能有一个满意的答案的。

还真去翻了一下这是什么东西，感觉还是太技术了，跟真实需求的关系有这么强烈么？资本市场跟风起来，完全不是人，像共享单车，像咖啡，都是这么吹泡泡吹出来的。

最终还是回到Gartner的报告，其中提到了一份低代码领域的分支报告——《Low-Code Development Technologies Evaluation Guide》，这其中有一段对于Low-Code平台的横向对比标准的描述，也就是不同的供应商的产品，其在Low-Code能力方面，可以横向比对哪些因素。实际上，关于低代码平台的特性，也可以借由这些因素窥探一二。 

如上图可见，Gartner列示了9个不同的比较因素，并在之后进行了归纳，说明了目前主流的Low-Code产品具备的能力，分为两个部分：

1）通用技术能力：

以模型/元数据为驱动的UI实现方式，最好是通过零代码的方案实现

能够在线进行基本的数据结构（底层为数据库）的数据结构定义

支持以SOAP、REST或其他类型的API的方式实现对外部接口的调用

支持以API的方式，对外提供平台自身的数据/服务

支持模型、可视化的代码或业务流程的开发实现

高性能和低时延

2）作为企业级平台的进阶能力：

高扩展性，例如：用户数、交易量、数据量等

高可用性与灾难恢复

应用访问、API、数据存储的安全性

部署SLA或支持运行时部署（PaaS类产品）

我们可以借由此进行约定，符合上述的大部分能力要求的，可认为是Low-Code（低代码）平台。而在企业级应用解决方案中，会发现有不少传统IT人熟知的产品也是符合上述能力要求的，例如：BPM平台、iPaaS平台、国内的某些OA产品等，因此，在具体应用时，需根据组织自身的情况进行合理的选择。 

Gartner非常贴心的在其报告中给出了Low-Code产品的选型、决策树，可作为选型的参考：

根据这个决策树，不但可以大致理解其决策的依据，也可以基本理清了No-Code、Low-Code、传统的BPM等方案之间的关系。为了方便理解，我们把几个关键的角色因子进行简述：

是否需要公民开发（e.g. 业务顾问/业务用户配置式开发），如结果为是，那么跳转到是否需要专业开发人员介入，反之则继续判断是否需要多终端交互访问；

是否需要专业开发人员介入，如选择为否，则直接可选型No-Code（零代码）工具产品，或选择Low-Code平台的零代码能力应用；

是否需多终端交互访问，如选择为是，则选择MXDP（Multiexperience development platforms）类产品，进行定制化开发，如为否，则继续决策是否有经常需要变化或比较复杂的业务需求（尤其关联流程等）；

是否有经常需要变化或比较复杂的业务需求（尤其关联流程等），如选择为是，则选型BPM平台为主 + MXDP类型产品进行前端辅助构建的方式，如为否，则选择Low-Code为主的平台。

这个决策树基本是可行的，但维度最终的落脚点，即目前Low-Code产品和BPM平台产品的界限越来越模糊，为便于理解上面的决策树，可以将这里的iBPM理解为传统的BPM产品、LCAP理解为模型/表单驱动的Low-Code产品（虽然目前很多Low-Code产品也包括了流程特性，但其流程相对传统的BPM来说偏弱）。

低代码、无代码平台这两年的快速发展，离不开黑天鹅的影响，黑天鹅带了的全行业数字化转型，推动了全民数字化发展，但是传统IT服务商提供的定制服务，周期长、投入高，而低代码平台快速搭建、便于解耦、成本低的特性就很好的适应现在大规模的IT开发场景。

一个企业从HR系统、呼叫系统、CRM、ERP、WMS、TMS等等，以前都是独立的孤岛，由不同的IT服务商提供，而低代码平台，则可以通过一套低代码平台统一配置出来，减少成本、同时能统一风格，只要系统架构整体设计无误，就可以搭建出一套企业完备的系统架构，实现数据互联互通，便于企业管理。

其次，大部分传统企业因为业务处理方式不同，几乎每个企业针对系统都有定制化开发的需求，而传统的Saas服务针对定制化需求很难做到合适的适配，低代码平台则可以很好通过插件式的模块插入来实现，很好的兼容原有系统体系。

现有国内外的低代码平台，IVX、简道云、Mendix，Outsystems、氚云等等平台已经开始运营验证其商业模式是否能形成很好良性循环，但是目前低代码赛道尚未形成明确的市场环境，现有投资者很可能大赚一笔，也可能折戟沉沙。

国内现在投资环境很大的情况是，有很好的资金本金，但是缺少良好的投资项目，所以一旦某个赛道初露苗头，大批投资人就会蜂拥而上，纷纷压码。

如有不同意见，欢迎给位的分析讨论。

从经济学的角度看，我觉得这些低代码、零代码平台/工具的出现，本质上是企业交易费用上升导致的，企业需要寻找一种更低成本的方式去降低交易费用。

比如，企业内部有一些需求，原本只能通过自己招人来开发，现在可以通过这种低代码、零代码的工具来直接搭出来，购买服务的成本比起养一支团队的成本要低很多。

当然，并不是所有需求都能通过这种低代码、零代码工具来解决的，会遇到一个边界，这个边界就是当养一只团队的成本跟购买这种低代码工具的服务（可能还包含增值服务、私有部署、定制开发等）的成本基本上相当，这个时候企业可能会选择自己养团队来做这个事情。

但是，只要低代码、零代码平台/工具，在帮助企业提供解决方案这件事情上能够保持比企业自己养团队去解决的成本更低，那么他们就会有市场。

大方向是对的，但是业务的细节有待商榷。

目前我看到的感觉比较靠谱的只有阿里云的宜搭，但整个商业上还没有跑顺。还有一些平台，他们但产品过于细节、过于技术、过于不接地气。怎么在接地气和商业上做到平衡，是这条赛道的关键点。

市场规模角度，这条赛道极佳。

组织架构角度，这里容不下巨兽。

估计会有1～3家百亿美金级别的公司，这就是极限了。

我前前后后思考这件事大概两年了，有兴趣可以找我私聊。我相信足够聪明的人和有意愿沟通的人是能找到我的联系方式的。

希望能有同道。

有个好朋友做的ClickPaaS，在海外资本市场很受欢迎。

国内我就 知道 明道。

市场肯定是有的。toB 行业，就像相同领域，都有细节差别，没有任何一个产品可以完美匹配，几乎都需要二开，那么如果是个 零代码或者低代码平台，仅需要在系统内调整一下即可，大大提高效率。

例如我现在一个项目，甲方业务流程一会一变，一个月变5次，开发都疯了，全都是无用功，甲方还不满意认为进度太慢。如果是个零代码平台，仅需要从新配置下流程，画一下表单，权限等即可分分钟搞定。

占坑先

关于可能性

第一次看到LowCode和No Code的时候（下文我们简称I/N），我的第一反应是Microsoft Excel和PowerBI。Excel这个，大家再熟悉不过了，很多人的日常工作都能用到。对于I/N的实际应用来说，Microsoft的Excel可能是做得最成功的应用之一。对于非深度使用者，可能只是用于简单的数据记录，制作柱状图，饼状图，折线图，再做一个求和，平均值，标准差等；高阶一点的使用者，需要做数据透视表，数据筛选查重，以及基于某些特定数据分析用途的解析；再高阶一点的，运用Excel中支持的各种简单的代码，进行数据的抓取和分析，诸如：

用于查找出生日期的：=TEXT

用于查找重复内容的：IF

用于查找某些条件的内容的：（FERROR(INDEX

正是Excel表格功能之强大，覆盖的应用场景之广，且对于low-code，甚至是no-code者的友好度是如此之高，于是，很多开始进入这个领域，比如WPS。凯撒查阅了一下对于I/N的定义，不妨总结一下I/N能够取代手动编译的价值，需要做到如下几点：

可视化建模（visualmodelling): 这是一种相比于一行一行枯燥，抽象的句法的编译过程，可视化的建模可以在视觉上能够更加容易让编译人员和使用者看到编译的效果，特别是对于那些对代码熟悉程度较低的群体

可拓展性（scalability)和安全性：low code平台需要更加的安全，且该系统的可拓展性强

傻瓜式操作：无需复杂，抽象的句法，编译者只需要根据自己需要的模型，进行拖拽和组合；素材/组件智能批量生成、结合端智能、个性化推荐等技术

专业开发工具：针对专业开发者的 IDE 中提供部分可视化辅助工具，如微信小程序 IDE

基于上面说的几点，我们再回过头来看看excel，作为工具属性的产品，是不是基本上已经完美的发挥了这三点特性？

I/N的概念早在70年代被提出，发展到今天才小试牛刀，让我们看到了一些商业价值，但是，依旧没有形成一个非常清晰且行之有效的商业模式。写代码这件事背后的逻辑是非常复杂的，而这些代码语言的逻辑需要编辑者去亲自处理，这些复杂，抽象，以及程序员的编译语言和用户需要的应用展示的切合度，都是无可避免。如果开发人员简化了语言，那么，做出来的东西就好比是一辆玩具车，从螺丝钉到螺母，都和真实的汽车一模一样，但是，无论仿真度高达多少，甚至是100%，玩具车依旧是玩具车，无法在真实的马路上行驶。因此，我们也不难总结出，I/N 不得不提的几点：

其一，无法对于整个生态的掌控：low-code平台无法及时且有效的处理所有新出现的问题。这一点群里的各位产品或者程序猿应该都知道，实际产品的研发或者运行中，总是会出现临时的新问题，而这一些很难从已经建好模的low code平台中得到满足，因为low-code平台的底层逻辑对于使用者来说是一个黑匣子，他们很难根据实际情况去随机应变。

其二，可读性局限，缺乏个性化定制：我们来想象一下，当A程序猿在编译之前B程序猿编译的一个app的某个页面的时候，会出现什么？那就是A程序猿会先琢磨B程序猿编写的逻辑，使用的结构等等。对于low code平台来说，这些底层的逻辑是封闭的。凯撒没有写过代码，但是和产品，技术都开过会，经常听到他们在讨论的时候，会先基于底层结构的编译，再到功能实现去探讨，到底谁说的对，说的可行。想想一些针对一个完全封闭的系统，是否意味着能够编译出来的应用的可塑性大大降低？