前言
鉴于套装核心应用软件产品的实施复杂性，以及无法很好地满足企业深度定制化与无法快速应对不断变化的业务需求带来的挑战，越来越多的企业希望能够利用低代码技术来实施自主/合作开发其企业级应用。那么企业如何选择合适的低代码技术平台，以及如何利用低代码平台来开发企业级应用呢？以下将分三个方面进行阐述：
企业级核心应用特点；
面向企业级应用的低代码平台应具备的能力；
利用低代码技术构建企业级应用的最佳实践；
上期介绍了第一方面企业级核心应用特点，今天为大家介绍第二方面面向企业级应用的低代码平台应具备的能力。
面向企业级应用的低代码平台应具备的能力
面向企业级应用的低代码平台除了具备典型低代码平台的基本能力外，应该具备以下关键能力：
面向业务的软件设计模式
有些低代码平台采用“以人的活动为中心”的软件设计模式，这类平台关注前端页面展示及人机交互，对于追求用户体验的客户来说具有一定的吸引力。但是对于像核心业务系统这样的复杂应用，这种设计模式就有些力不从心了，因为这类应用除了要处理人工决策流外，还要处理大量的商流、资金流、物流、数据流等，其中会包括很多复杂的业务规则和计算。开发这类应用系统需要面向业务设计模式的低代码技术平台，例如：模型驱动架构(ModelDriven Architecture-MDA）、领域驱动设计（Domain Driven Design-DDD）。
关于MDA：MDA是OMG（国际对象管理组织）2001年继CORBA架构推出的全新的软件开发框架，MDA从技术架构上彻底实现了平台无关性，通过模型的抽取与建立来实现免代码开发，从而保护了用户已建立的“业务逻辑大厦”的安然无恙。MDA可理解为围绕支持模型驱动开发过程的一系列标准的框架，这些标准包括：统一建模语言UML5、元对象机制MOF6等。MDA架构思想，抽取了技术无关性的业务模型和平台有关性的平台执行引擎，继而实现了软件由模型化建模的零代码开发模式，使普通IT人员也能构建出足够复杂、专业的软件系统。
关于DDD：领域驱动设计是一套综合软件系统分析和设计的面向对象建模方法（2004年首先由Eric Evans提出），强调应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题，强调避免以人的活动为中心的思考方法。目前越来越多的受到业界的关注，并被用于许多大型软件系统的设计与开发中。
能够处理复杂业务流程的流程引擎技术
与我们在OA系统中的以人工决策处理的审批流（这类流程更关注节点路由的灵活选择）不同，业务流程相对来说要复杂的多。业务流程管理需要能够处理复杂的业务活动形式（包括：并行活动、串行活动、子活动、重复活动等）外，还需要能够响应来自其它系统或流程发出的各种信号；除了能够处理人工任务外，更需要处理自动化任务；业务流程更关注的是自动完成复杂的业务规则及数据计算，而不是仅完成表单数据的传递。
因此，符合bpmn2.0规范的流程引擎技术应该是必备。
关于bpmn2.0：bpmn（Business Process Model and Notation，即业务流程建模语言），在2004年5月由BPMI Notation Working Group对外发布，这就是BPMN 1.0 规范。后BPMI并入到OMG组织，并在2011年推出BPMN2.0标准。目前bpmn已经成为事实上的行业标准，国际各大知名IT厂商都支持bpmn2.0。
对象管理组织（英文Object Management Group,缩写为OMG）是一个国际协会，开始的目的是为分布式面向对象系统建立标准，现在致力于建立对程序、系统 和 业务流程建模的标准，以及基于模型的标准。
能够定义复杂业务规则的规则引擎技术
企业级应用系统中要处理的业务规则非常多、业务规则所关联的业务对象很多、业务规则应用的应用场景也各不相同（我们称为3多），同时这些业务要素也经常处于变化之中，这样印证了一句俗语“惟一不变的是变化”。我们在开发这类应用时最初的解决方案是通过硬代码的方式来实现这些业务规则，这种解决方案的不足之处是代码复杂、开发周期长，同时也无法很好地解决业务规则变化的问题。由于是紧耦合模式，对于一个地方的修改都可能会给其它正常功能模块带来无法预知的影响，正所谓“牵一发而动全身”。
为了解决变化的需求，人们首先采用了参数配置的模式来解决（我们常用的ERP系统通常都有大量的后台配置页面，有些后台配置页面甚至会比前端业务处理页面还要多，例如：SAP/R3、Oracle/EBS等）。但这种解决方案不是以业务人员容易理解的语言和形式来进行规则配置，也无法满足细颗粒度灵活配置业务规则的需求。
为了更好地解决上述问题，一种新的技术便应运而生：规则引擎技术。规则引擎技术将业务规则、业务对象等要素从主处理流程代码剥离，通过一个独立的管理系统对这些要素进行统一管理、可视化业务规则建模（甚至允许业务人员参与规则的定义和修改）和规则的高效执行，最终对外提供统一的服务接口。利用规则引擎技术不但能够很好地解决规则可配置化的需求，同时还大大地降低了应用系统代码的复杂性，使得应用系统的鲁棒性得以极大地提升。
因此企业级应用的低代码平台应该拥有一个好的规则引擎。一个合格的规则引擎应该能够实现：对业务对象的有效管理、可视化配置业务规则、支持多种业务规则模式、高效的计算规则执行器、集成流程引擎、规则服务化等关键要素。
能够定义复杂业务对象及数据模型的技术
企业级应用所要处理的业务对象模式都比较复杂，普通的页面展示模型及基于关系数据库的关系模型无法很好地描述这些复杂的业务对象，这也是人们认为传统的基于前端页面交互式的低代码开发平台无法用于开发复杂应用的主要原因。因此，企业级应用的低代码平台应该具备很强的定义和处理复杂业务对象模型的能力。
典型的复杂业务对象包括：
SDT（ Structured DataType）对象 -- 一种结构化、集合类的复杂数据类型对象，常用于描述复杂的业务对象，例如JSON等；
Transaction对象 -- 一种基于关系模式的高级抽象与扩展层对象，作用与传统的数据库关系对象类似；
DataProvider对象 -- 基于SDT数据类型的实例化数据对象，常用于复杂的数据转换及数据传递管道；
业务流程图 -- 可执行的业务流程的可视化展现；
Query对象 -- 可以从数据源返回一组数据集，通过可视化模式定义复杂的数据处理逻辑；
Procedure对象 -- 能够处理任何业务逻辑的处理单元；
API对象 -- 可以将第三方API转换成内部使用的普通业务对象等。
能够提供可复用业务组件的知识库
从对企业应用的剖析可以看出，企业级应用承载了多个相互关联的企业核心业务流程；这些流程由许多的低层级流程片段（子流程）所组成，而这些流程片段又对各种业务对象进行不同/相同的处理；每个流程片段的流程节点又由不同的处理模块/页面来组成。进一步分析我们发现这些不同的流程片段/功能模块有很多具有相同的或类似的属性。我们可以通过组件化、配置化的方法来实现这些模块的开发，然后再通过搭积木的方法来组成不同的应用子系统。
因此企业级低代码平台应该能够提供可复用业务组件的知识库，这种能够不断积累的知识库将会使得企业级应用开发更敏捷，IT系统支撑企业业务拓展能力更强，企业应对市场变化更从容。
能够方便实现与第三方系统整合的流程整合能力与数据整合能力等
我们知道企业级应用需要与许多第三方系统进行大量的交互，开发人员在开发企业级应用时便需要针对这些第三方系统开发大量的接口模块来实现。有过开发接口程序经历的技术人员都知道接口开发工作既繁琐又容易出错，这也使得接口开发工作占据了整个软件开发工作相当大的比重。
为了降低接口开发的难度和工作量，同时又能够保证接口开发质量，企业级低代码平台应该能够针对第三方系统所常用的不同技术和架构提供有效的接口整合解决方案，并能够将接口程序的底层代码进行封装，让开发人员像调用本地对象那样调用相关接口。同时又能够将本地业务组件方便地封装成标准协议接口服务，以便于第三方系统的调用。
能够支持多种部署模式，不受平台本身的限制
随着基于Docker容器技术的虚拟化技术的成熟，越来越多的企业开始拥抱Docker技术，企业级低代码平台应该能够支持基于Docker技术的虚拟化部署模式；在支持“云”部署方面，应该能够支持公有云、混合云及私有云的部署模式。考虑到应用整合需求及数据安全性，企业一般都不会选择将其企业级应用部署到到云端，因此，支持本地化部署将是企业级应用的首选。
根据低代码平台的软件生成的两大技术（源代码生成技术、模型解析技术）的分析，源代码生成技术能够使得所生成的软件应用脱离开发运行平台进行独立部署，这使得软件系统部署灵活性更高、更容易与企业自身的IT基础架构相兼容，同时也避免受低代码云平台技术架构能力不足的限制。
支持高度可配置化，以满足不同环境、不同规模、不同业务场景的特定要求
企业由于其IT战略的不同、IT建设的路线不同及IT团队能力舒适区的不同，便造成了对于其实施的软件运行环境要求、IT基础架构兼容性要求、网络运行安全级别要求等方面有很大的差别。这就要求低代码平台所生成的软件系统能够通过部署配置化来适应这些不同的要求。
另外，企业要发展，软件也要跟着发展（软件应该是“活的”）。
MXDP
随着IT技术的快速发展，各种各样的智能设备层出不穷，为了提高企业全员业务协同的效率，企业希望能够很好地利用这些智能设备来实现业务协同。这样软件运行环境也变得越来越复杂，人们不仅仅希望能够快速构建各种应用软件，更希望能够一次开发同时在不同的设备上部署和运行，实现一次开发，多渠道部署。为了满足这样的需求，一种新的低代码技术便应运而生：MXDP（Multiexperience Development Platforms），即多渠道体验低代码开发平台。
MXDP主要用于帮助开发者以更高的效率、更快的速度，开发出跨平台的软件系统。现实中，MXDP不仅是前端的开发工具，为了提升开发效率，通常还会提供后端到前端（BFF）集成套件，一站式完成系统开发工作。从这个角度上看，MXDP与目前最火热的“低代码”在价值方面是一致的，只不过MXDP更专注于为前端提供跨平台特性，同时在前后端自由定制方面提出了更高的要求。
可以说，企业级低代码平台应该同时具备MXDP的能力。
支持团队开发
由于企业级应用的业务模块多，软件开发量大，很少能够通过1-2个开发人员就能够完成。一般来说企业级应用需要在统一的架构设计基础上，通过多个开发团队并行协同开发来完成。因此企业级低代码平台应该能够很好地支持团队协同开发，并能够提供完善的版本管理机制。
支持DevOps
随着软件生命周期的延长，尤其是自主软件研发的兴起，企业不再仅仅关注软件第一次上线时的功能是否完全满足自身的需求，企业更关注软件的后期迭代升级以满足企业不断变化的需求。换句话，软件全生命周期管理越来越受到企业的关注。作为企业级低代码平台应该对于软件生命周期管理的最佳实践：DevOps提供支撑，尤其是其中的关键环节CI/CD（软件持续集成与持续发布）。
自动化测试
实施DevOps离不开自动化测试手段，通过自动化测试手段可以大大降低QA人员的工作量并把软件可能存在的缺陷消灭在软件上线之前。企业级低代码平台应该能够提供针对UITest及UnitTest的自动化测试集成工具。
完善的网络安全解决方案
随着移动办公的兴起，越来越多的企业员工使用智能移动设备来透过互联网来访问企业内部应用系统，这就使得企业应用系统网络安全保护变得日益重要。企业级低代码平台应该提供针对网络安全保护方面的完善的解决方案，尤其是对于网络安全风险：OWASP TOP10 2016/2017提供有效的对策。
Future Proof保障
在IT技术飞速发展的今天，技术落后就意味着软件系统缺乏竞争力，软件系统的价值就会打折扣。为了使所开发的软件系统能够充分利用不断出现的先进IT技术，企业级低代码平台就必须能够给客户提供Future Proof（永不落后的技术）的保障，这样才能够给客户最大的价值
写在最后
能够满足上述需求的低代码平台能够让软件开发人员更关注于业务本身，而平台将提供其它技术保障，这样才能够使得开发团队在较低的投入（包括：人力成本、资金成本、时间成本等）下开发出能够满足企业级应用要求的应用系统，并通过后期的运维保障机制使得软件的生命周期更长，软件建设投资回报率更高。
本篇文章《企业级低代码平台应具备哪些要素？》分为三期为大家介绍：
第一期：企业级核心应用特点；
第二期：面向企业级应用的低代码平台应具备的能力；
第三期：利用低代码技术构建企业级应用的最佳实践；
关注我们，阅读不迷路。