通过 API 或微服务把 ERP 平台的功能释放到前端，让业务人员可以把这些强大的功能，汇入到自己的流程和界面中，解决业务中特定的问题，这已是 ERP 平台的大势所趋。
有了 C 语言，计算机世界的建造工具其实已经完成了，UNIX 就是例证。但是，后来出现了上百种语言，为什么？因为，C 语言对于很多人来说太过专业了，开发的效率低，所以出现了 Python、Java、NodeJs、Javascript 等众多语言，协助在不同的场景建造应用系统。而在这众多的计算机语言中，基本可以分为两类：一类是 C，一类是非 C。
低代码是非 C 的，也就是业内说的胶水程序语言。胶水程序语言是用来连接软件组件的程序设计语言，通常指脚本语言或解释性语言，广义上，Shellscripts、Python、Ruby、Lua、Tcl、Perl、PHP 等都可以用作这个范围。底层的重要部件，对算法和运算要求高的部分，用 C 做开发，建立基础的类库（不是框架），然后用效率比较低的脚本语言或解释类语言调用 C 的类库，整合在一起完成应用的功能。C 是从汇编语言基础上发展来，解决汇编语言的低效率，而再往上，C 又被其他语言做为基础，这就是计算机世界的分层和解耦。
ERP 系统是对企业经营过程的全方位映射和数字化模拟。国内的用友和金蝶作为 ERP 主流提供商，在新的 ERP 平台中，都提出了低代码开发。其用意和目标，也是解决开发的效率与复杂度，把 Java 或 C 等专业人员开发的 ERP 功能，作为通用的底层服务或部件，供用户或业务运维人员通过简单的胶水语言调用，组合以快速入门和使用。通过 API 或微服务把 ERP 平台的功能释放到前端，让业务人员可以把这些强大的功能，汇入到自己的流程和界面中，解决业务中特定的问题，这已是 ERP 平台的大势所趋。
随着低代码概念的兴起，国内市面上迅速涌现了大量的低代码平台，这些代码平台与 ERP 的低代码平台相比有哪些区别？
核心区别是 ERP 平台的低代码和 ERP 功能有机融合，而独立的低代码是胶水程序，是用以粘合两种以上不同功能部件的程序；而且，ERP 平台中的低代码，可以操作的对象是整个 ERP 平台或生态。尤其是近年来，ERP 在架构上，做了微服务改造。先不论这种架构对企业的适应性或微服务划分设计的合理与否，只此一项，就相当于在北京的中轴线上建造了一条地铁。而如果没有 ERP 基础的资源，那这条地铁可能就是相当于修建在了撒哈拉沙漠，其价值不可同日而语。也就是说，ERP 平台下的低代码有更多的可操作、组合的资源对象。
即使如此，也不能说 ERP 中的低代码就能完胜其他的独立平台，因为 ERP 中的低代码的先天优势来自 ERP 平台，而不是平台中的低代码部分或能力。ERP 通过微服务或 API 是在授权范围内提供服务的，所以，对于第三方的独立的代代码平台，一样可以得到 ERP 的基础资源服务。而 ERP 之外的专业低代码平台，可能具备的优势，又是 ERP 自带的低代码望尘莫及的。主要包括以下几个方面：
低代码和服务的有机融合：低代码和专业代码都是代码的形式和范畴；低代码的模型必须建立在专业代码或组件形态之上；在低代码可视化设计过程中，前后端随时都可以进行专业开发，而且是可逆可持续迭代的，不会因为采用了专业开发就失去了低代码开发的能力。而 ERP 中的低代码平台，对于模型是几乎不提供的，他认为你的能力范围，应该仅限于 ERP 的模型或实体对象。而且，因为是低代码，基本不会提供设计模式对这些模型的深度封装或继承。
技术框架：专业低代码开发平台的前后端，会采用业界主流技术框架，符合大中型企业开发团队的技术栈。比如后端 GoLang、Java Spring、NodeJs、前端 React 或 Vue，就是目前企业应用的一些框架和规范标准。这些工具或框架的开发能力是无限制的，设计之初就用于开发一切的组件、功能或界面。而 ERP 的低代码只使用自己的语言和资源体系，即使是模仿或采用了主流技术的结构，也是不会从低代码角度提供全面的能力方案，一是过于复杂，二是对 ERP 平台的安全或升级带来太大的成本。
开发工具：专业低代码开发平台支持开发者使用专业的 IDE 开发工具。Eclipse、IDEA、VSCode。这些集成的开发工具，是离开发人员最近的一层技术工具，换掉这些工具，相当于去掉了他们一半的能力。另外，专业开发工具并不仅限于 IDE 工具，还包括构建工具（Maven）、测试工具（JMeter）、质量工具（SonarQube）和各种框架已经开成的配置和类库等，没有这些做为开发基础，基本要开发人员重新造轮子。
团队协作：开发人员需要低代码支持团队协作和版本管理工具，Git 或 Svn，支持版本管理和分支管理。ERP 平台里可能会有版本管理工具，但那个不是 Git，ERP 平台本身也不是为了服务于开发工具，就没有这方面的基因。所以，复杂功能的开发迭代，团队协作在 ERP 的低代码中几乎是不存在的。
代码调试：无论是什么代码，在完整运行前，都需要完成调试和专业测试，每一行代码都要求可以调试跟踪，白盒测试，灰度发布。对 ERP 而言，既然低代码只是个附赠，怎么会提供这类功能，调试的方式就只限于运行态下手工看效果，这大约是程序开发 30 年前的状态，完全不可能应对复杂程序和功能的构建。
支持组件开发扩展：组件是系统资源的核心，是软件重用的基础。专业低代码一方面要提供丰富的组件，另一方面必须提供完善的组件开发规范和开发工具，支持开发者自定义组件，同时要提供组件市场和组件的生命周期管理，组件发布、更新、升级和版本管理。让开发者可以通过组件封装进行代码高度复用，扩展低代码开发平台本身，真正发挥低代码快速开发的优势，持续积累，自主可控。ERP 平台的低代码没有组件扩展，只能使用既定的 API 服务功能。因为，要保持简单。
支持独立部署：基于专业低代码平台开发的应用，源码能够独立于低代码平台编译、构建和部署，可以完全独立于低代码平台运行。在任何的云主机上都可以正常部署和运行，成本极低，而且可以使用云资源的弹性和扩展。ERP 上的低代码平台不可以离开 ERP 平台，这样的平台没有十几台服务器和若干中间件和数据库的配合，以及厂商专业人员服务和 License 授权，是不可能部署成功的。
其他的区别还包括，DevOps，云原生架构支持，企业级集成能力等等。都是独立第三方低代码与 ERP 中低代码平台的重要差异。
ERP 低代码的核心价值
只有变化是不变的。
外界环境的快速变化速度，快于 ERP 产品的迭代和发布速度。内部业务的变化，要求 ERP 有不断满足新业务和业务变化的能力。这些能力不能在系统初始化和配置的时候确定和提供。只能通过模式创新实现对变化的适应，是企业数字化转型的初衷。
让业务人员进入开发的初步领域，是低代码的目标之一。让业务人员自己把需求在平台上实现出来，是一个美好的愿望，至少可能退一步，让不懂开发技术和程序设计的 ERP 顾问做这部分工作。用可视化工具和控件，做一个界面，收集一些数据，就像微信小程序的数据收集或接龙，谁都可以定制一个类似的应用。但是后端的复杂接口，就不是为这些人员准备的了。所以 ERP 的低代码工具就有了多个分裂的用户对象，然而当一种药可以治很多种疾病时，对具体某一种病的疗效就一定会衰减或损失。所以，在复杂应用的构建能力上就比不上专业的低代码工具了。
但是，既然大家都是这么一个性质和范围的工具，相差的能力也不会是无可接受，况且我们要做的只是建立一个简单流程和数据的收集，其他的数据处理又可以交给 ERP 这个航空母舰。所以 ERP 的低代码一下又高大上起来了。
专业低代码的发展现状
2014 年，全球权威咨询机构 Forrester 首次在报告中引入了低代码的概念。在 2018 年 Gartner 提出了应用平台即服务（application Platform as a Service，aPaaS）和集成平台即服务（integration Platform as a Service，iPaaS）的概念。最近 Gartner 在最新的报告中认为技术提供商仍然需要发展更深一层的工具，支持较为专业的开发者构建 “定制化应用”，这也与我们提出的专业低代码的概念不谋而合。
国外低代码整体方面发展比国内早，相关人员也更早的意识到低代码和专业代码融合的问题。目前主流的思想基本上都认为低代码平台需要专业代码的能力才能更好地为开发者服务。低代码开发平台需要提供面向专业开发者的低代码开发工具，支持 JAVA、C#、JS 等专业的开发语言，支持生成原生代码，支持独立于平台进行部署，基本上能够满足专业开发人员的相关需求。
国内低代码整体方面发展较国外来说相对较晚，但近几年由于数字化进程的加快，目前整体水平也发展很快。像前面我们提到的阿里、华为、中兴包括其他的一些低代码平台厂商都逐渐意识到低代码在某些方面的困境与不足，纷纷开展了相关低代码和专业代码融合的探索。
低代码的发展和未来
面向企业应用的低代码开发，必须按模型组织企业应用所必须的门户、组织、权限、工作流、报表、消息、集成等各种业务支撑能力，以通过模型规则、逻辑编排或脚本代码等方式进行复杂业务逻辑扩展。这些特性随着 ERP 平台架构转向容器和微服务，已经全面提供低代码的调用能力，所谓可用的积木块呈现全面化和足够细分的颗粒化，让低代码在跳跃到代码之外，甚至不使用代码的情况下，也能快速搭建企业内部特殊的业务模块。
其次，支持进行统一构建、统一部署，并且能够支持专业 DevOps 工具链，实现全过程的自动化部署。
第三是扩展性，对于 ERP 之外的功能，通过接入第三方或公共服务的计算服务，也可能是远程授权的微服务接口，获得无限的扩展能力，并且与 ERP 之外的应用系统打通，形成数据和业务层的互动。
第四是性能，虽然 ERP 的平台已经提供了数据库连接、WEB 服务、弹性扩展等等功能和非功能的全面服务体系，但是这个体系的规划和设计实现是以 ERP 为中心目标的，并不是在所有场景下都可以适用，所以对于某些具体的性能要求或稳定性要求极高的场景下，仍是低代码平台不容易覆盖的。这就需要在部署方面，采用足够灵活的架构，第三方的服务足够强大或有足够弹性扩展的能力，好在这些在云原生的架构里，都已经有很好的解决方案。
最后，是让整个工具链更加简单易用，降低学习成本，实现企业应用软件研发效率的全面提升。让更多业务人员或实施顾问都可以深入地参与到使用低代码平台进行系统开发和建设中，让低代码开发的内容成为 ERP 这棵大树的枝叶，让企业应用根植于企业，长得更枝繁叶茂。
参考文献
Why a Low-Code Platform Should Have Pro-Code Capabilities
- Low-Code vs Pro-Code: Why They are not Mutually Exclusive
