低代码开发平台-解决SaaS应用的最后一公里

今天准备再谈下对低代码开发平台的扩展思考，最近2到3年，低代码开发平台可以算作一个小热点，不论是传统的BPM厂家，还是原来的快速开发平台厂家，包括还有一些中台建设厂家都逐步推出自己的低代码开发平台。

低代码开发平台概述

对于低代码开发平台的分析，我前面写过一篇文章可以参考：

从快速开发平台到低代码开发平台

从这篇文章大家可以对低代码平台有个初步的了解。如果简单地总结低代码开发平台，可以理解为一切皆是可配置，可建模的。而本书建模的关键又在于对业务领域和现实世界的大量实践和抽象。

对于低代码平台核心要素，我也整理过一篇文章：

低代码开发平台核心组件集成和协同分析

即LCDP平台的核心包括了上图中的数据建模，表单建模，流程建模，权限建模，报表建模和规则建模几个关键部分的内容，通过这些建模组件，包括这些组件之间本身的协同来完成一个完整业务系统和功能的构建。对于这些建模要素之间如何集成和协同，可以参考上面这篇文章详细说明，在这里不再重复叙述。

在企业数字化转型和IT架构演进中，前面也谈了围绕云原生技术来打造企业核心的技术中台能力，其中的关键点是微服务，DevOps和容器云技术。

虽然说这些技术都可以提供应用软件持续集成和交付的效率，但是并不会说明显提升软件开发的效率，而对于软件开发效率提升来说，共性技术组件的积累，灵活的开发框架，代码生成，类似流程，表单，报表等动态可配置能力仍然是关键。

因此我在前面专门写了一篇文章谈到低代码开发平台是云原生整个技术解决方案的一个关键补充，通过引入基于微服务架构的低代码开发平台，来加快微服务和模块化应用的开发，集成和部署上线效率。

具体可以参考下面这篇文章：

低代码开发平台-对云原生整体解决方案的关键补充

但是软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现的逼真程度进行验证。也就是说软件开发真正的难点是在于完成从现实世界到软件抽象世界的转换和建模，这个首要任务当前并没有一种很好的自动化完成的方法和工具。

也正是这个原因，我又写了一篇再论没有银弹的文章。

再论软件系统的复杂性-没有银弹，只有焦油坑

对低代码开发平台的分类

当我重新来思考软件系统复杂性和低代码开发平台之间的关系时候，需要找到一个方法或逻辑进一步将我前面阐述的内容描述清楚。

简单来总结下结论应该就是：

• 简单软件系统可以有银弹，但是复杂系统短期没有银弹
• 低代码平台应分为面向技术人员和面向业务人员两类

也就是说对于软件系统或软件应用首先应该分类，虽然有很多类似ERP等企业信息化软件系统，但是对于大部分小微企业来说，核心的软件应用诉求就是电子化表单+流程。也就是说希望能够将一些纸面表单电子化并统一管理起来。

对于这类应用需求是完全可以灵活实现自动化和智能配置的。

对于低代码开发平台，实际应该分为两类。

一类是类似商用的普元EOS平台，或者开源的JEECG平台。这类平台实际是面向开发和技术人员使用，并不是说完全无代码化，而是真正的叫低代码，实现低代码核心还是共性技术组件能力下沉和可复用。

但是具体的业务规则和逻辑的实现还是需要你写代码来完成，由于共性技术组件可复用，开发者可以更加专注于业务功能和业务逻辑的实现。

我们可以看下JeecgBoot网站的说明。

JeecgBoot是一款基于BPM的低代码平台！前后端分离架构 SpringBoot 2.x，SpringCloud，Ant Design&Vue，Mybatis-plus，Shiro，JWT，支持微服务。强大的代码生成器让前后端代码一键生成，实现低代码开发！JeecgBoot引领新低代码开发模式 OnlineCoding-> 代码生成器-> 手工MERGE， 帮助Java项目解决70%的重复工作，让开发更多关注业务，既能快速提高效率，节省研发成本，同时又不失灵活性！一系列低代码能力：Online表单、Online报表、Online图表、表单设计、流程设计、报表设计、大屏设计等。

这类平台面向开发人员，更像我们原来经常说到的下沉了技术组件能力的开发框架和环境，协助你实现业务和技术的解耦，让你在开发时候真正专注在业务功能和逻辑实现上面。

这类平台本身代码可见，可修改和可维护。用的技术也是主流的开源微服务开发框架，开源组件技术的集成，你也不会被绑定和限制。因此可以作为整体云原生技术解决方案的一个重要组成部分。

简单总结就是这类低代码平台不要去管具体的业务流程，业务功能和业务逻辑的实现，你只要做好共性技术组件，做好开发框架和底层技术支撑，就是一个很好的平台。

第二类低代码平台类似宜搭，轻流，奥哲，明道等。

图为奥哲低代码平台整体架构

这类低代码平台更加偏向于面向业务人员，或者更多是不直接面对底层代码的零代码开发平台，希望做到的是应用可以通过搭建积木的方式进行快速配置来实现。

我原来一直不太认可这个思路。

但是最近通过复盘和一些产品试用，整体感觉对于中小企业很多仅仅是实现表单电子化和流程化的场景，完全可以做到类似上面的零代码和快速配置。

这个实际上和很多年前OA类系统提供的各类单据快速配置功能完全一致。比如多年前类似蓝凌OA系统就已经可以实现这种需求，一个请假单功能，你完全可以自己配置单据界面，然后设计一个流程并完成挂接。

这类单据本身对象和数据建模都简单，同时单据本身也不和其他单据发生强耦合和关联关系。属于典型的电子表单+流程的需求场景。

那么这类场景一定是可以完全零代码化和可配置化的。

低代码开发解决SaaS服务最后一公里

首先对前面的内容做一个总结。即低代码平台分为面向开发人员和面向业务人员两类，第一类可以作为企业IT架构转型和云原生整体解决方案的补充；而对于第二类则面向中小型企业的表单单子化和流程化需求场景。

由于第二类本身是零代码和完全可配置的形式出现的，因此这类低代码平台不会提供私有云环境部署和集成，更多的是以SaaS应用的方式提供。

对于SaaS应用可以看到，在前面很多年发展的并不算太好。其中一个关键原因就是SaaS应用本身对用户个性化需求的满足度并不会太好，最多提供一些简单的字段，流程可配置能力，在这个能力外的个性化需求都难以满足。因此SaaS应用本身虽然实现了服务的统一化和标准化，但是本身也降低了灵活性和个性化。

如果所有用户的定制化需求SaaS应用都需要满足，那么SaaS云服务商本身又变回了传统的应用定制开发服务商，失去了云平台和云服务，发挥长尾优势的意义。

也正是这个原因，低代码开发平台正好可以作为传统的SaaS应用服务和用户之间的一个关键连接桥梁。即通过低代码开发，释放更多的可配置能力给最终的用户使用，但是本身又零编码，既满足了个性化需求，又实现了SaaS服务的统一化管理。

在这种场景下，低代码开发不是解决的开发问题，而是解决的基于业务需求快速上线应用的一体化交付问题，也就是说提供低代码开发能力只是你SaaS运营服务向用户端的一个关键延伸，你的核心还是SaaS应用服务能力提供。

当把这个关键点想清楚后，低代码平台变成了SaaS应用延伸的关键抓手。

但是当我们重新思考软件系统本身的复杂性问题的时候，可以看到很多时候并不是简单的零编码或者搭积木的方式就能够完成应用的开发和交付的。

这个时候你仍然需要去做业务抽象和建模，去做规则的开发和定制。

如果要做到进一步的可配置，你就必须抽象共性业务组件或业务能力，也就是说你需要首先在底层建立抽象的共性业务模型，其次才是支撑前端的可配置开发。

这种共性业务模型是否可抽象？

当我们的SaaS应用聚焦到一个高度垂直细分的专业领域的时候，那么这个模型本质是可以抽象和提取共性的。类似你本身就是做一个项目管理和协同SaaS应用，或者一个CRM应用。那么你就可以去抽象这类垂直应用的底层业务模型了。但是如果要扩展到所有行业，所有应用都能够抽象大而全的模型，这个本身又是违背了我前面谈到了复杂系统没有银弹的观点。

也正是这个原因，在这里给出第二类低代码开发平台的发展方向，即作为垂直细分的SaaS应用的关键延伸能力，而不是去开发一个大而全的零编码的低代码平台。

最后再次用我在没有银弹一文中的一句话作为总结。

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。降低复杂性的基本方法就是把复杂性隔离。