根据Gartner最新数据显示，低代码应用程序平台（Low-Code Application Platforms，简称“LCAP”）已在全球走向主流成熟度，覆盖全球50%以上的目标受众，并预计2022年LCAP收入市场总额将达到74亿美元，同比增长28.4%。
这样的发展态势，在国内市场也能明显感觉出来，越来越多的企业和从业者真切的感受到了低代码的魅力，开始讲述在实际应用过程中低代码如何帮助企业自身发展的故事。
同时整个低代码赛道，玩家也已经越来越多元化，不仅有原生低代码、零代码厂商，连传统软件厂商和云厂商也开始进场角逐，其所推出的产品和能力也不尽相同。
不过，供给的繁盛，也让当下那些想拥抱低代码的企业挑花了眼。
那么，企业应该如何根据自身的需求找到对应的低代码工具呢？在与业内人士的的谈话中，他们给出了一些答案。
产品包罗万象
但底层仍依靠两种技术
从低代码概念热炒至今，各种各样的低代码平台在国内崭露头角，尤其是最近两年，一些SaaS平台和传统软件厂商都开始提到自身的PaaS与低代码开发能力，几乎每个软件厂商都具备低代码开发能力。
为此，Gartner今年特意将国内低代码服务商初步分为四种类型，低代码应用平台（LACP）、无代码平台厂商（CADP）、企业应用厂商（Enterprise Application）以及云服务厂商（Cloud Service Provider ）。
尽管Gartner表示这些低代码服务商在一定程度上有业务上的重合，但各自也都有边界，出发点和动因也不尽相同。
比如面向专业开发人员或业务人员等多种角色的LACP，具有强大的本地化定制支持能力，在平台开发过程中需要与领域专家或者企业IT进行联合协作，适用于服务高级别和中等级别IT成熟度企业，具体服务商包括Mendix、OutSystems、ClickPaaS等。
以表单或办公自动化应用程序，提供轻量级解决方案以满足相应市场需求的无代码平台厂商（CADP），比如钉钉宜搭、氚云、轻流等。
还包括像用友、金蝶等企业应用厂商（Enterprise Application ），此类厂商主要通过向LCAP提供打包业务功能和连接器来扩展产品，以支持不同范围的特定行业或特定领域的应用程序及解决方案。
此外，还有像阿里巴巴、百度、微软等云服务厂商（Cloud Service Provider ），这些大型云服务提供商寻求加强其云服务，以扩大销售，目标是通过基于各自云平台的解决方案，发展合作伙伴的生态系统。
从上述几种类型的出发点和动因其实不难看出，虽然大家都在谈论自己具备低代码能力，但解决的实际应用场景却有着千差万别。
“事实上，不论是LACP还是CADP或云厂商等包罗万象的标签，其实都是营销性词汇，其主要的底层技术路径主要还是表单驱动和模型驱动，因此它不管怎么称呼，还是要落到实际解决的应用场景”，ClickPaaS CEO胡柏表示。
伙伴云COO孙传江也有类似的观点，他表示从客户视角来看从来都不关心我们是谁谁谁，我们的产品是基于什么架构，客户最关心的是谁能解决我的问题。
比如像企业内部的协同OA、自动化管理等轻量级的需求，完全可以使用以表单驱动的低/无代码平台，像国内的知名厂商钉钉宜搭、氚云、轻流等在市场上都有广泛的应用。
如果涉及到企业核心业务，比如像银行业的估值减值、融资租赁、风控等企业级核心业务系统，主要依靠的还是以模型驱动为主的低代码厂商。
但不论是以表单驱动还是模型驱动为主的低代码服务商，本质上都是为企业数字化提供自动化解决方案，并加速企业数字化转型进程。
企业选品基于三点需求
由于低代码所提供的服务范围不同，因此选择一款合适的低代码工具也是非常棘手的事情。
胡柏表示，当下的企业在选择低代码时其实有三个核心诉求，第一是企业想要掌握自身数字化命运；第二是数字化能力跟得上业务变化；第三是保障数字资产安全。
掌握自身数字化命运其实分为两类，一类是简单的将零散在企业内部各个角落的需求通过表单模式进行线上化或系统化，这类相对容易掌握。
另一类是真正的管理经营业务系统，随着商业环境的变化，业务系统也进入了快速迭代的周期，核心的业务系统纯粹依靠购买往往会因周期长、不灵活等与当下动荡的商业环境脱节，因此企业需要掌握自己的数字化命运。
同样是在这种商业环境高速变化的周期里，企业的业务往往会转变的很快，这也要求企业数字化团队能在最短的周期内迅速完成响应。
最后是数字资产安全合规，当企业的内部管理和业务全面云化之后，数字资产的安全性和可靠性就会成为重中之重。
首先是拿来干什么？怎么干？葡萄城产品市场总监宁伟在接受相关媒体采访时给出过答案，企业应该考虑自身的应用场景是什么，如果是简单的轻应用，讲究短平快，不需要考虑和其他软件集成以及持续发展的问题，那么以表单驱动为主的低代码平台足以承载。
如果是从长远生命力考虑，应该全盘考虑自身的数字化体系如何构建，后期应该如何去扩展，是否可以添加自己定制的业务逻辑、规则或流程，如何去迭代等多方位问题，如果这些不能解决，那么使用低代码工具也仅仅只是解决短期的价值链，无法长久。
第二则是能否适应企业程序开发人员，老板做决定要考虑实际操作员工的使用习惯，尤其是复杂场景，低代码和专业人员适配才会锦上添花。
对于技术人员来说，学低代码开发和学一门新编程语言的难度本质上并无二致。
大多数开发人员会考虑该工具的开发流程和架构跟之前是否相似，如果能延续之前的开发经验，技术人员会成为更好的开发者，那么对于企业本身而言，在日后的维护和扩展的过程中不需要去完全依赖服务商。
当然，功能、性价比、是否能连接广泛的第三方API、框架和云服务等等因素都是企业最初在选择低代码平台时需要做足充分的准备。
弃用或换新
给企业打一针预防针
尽管当下的企业对于低代码的使用仍在初步探索阶段，但仍需要提前给企业打上一针预防针。
由于市面上SaaS或低代码产品订阅续费的商业模式，也意味着企业使用低代码工具会导致在一定程度上与服务商锁定。
如果企业停止使用既定的平台和开发工具或选择同类型功能相对丰富的平台，企业该如何解绑呢？
一方面企业既依赖该类低代码平台，另一方面又提醒企业将数字化能力掌握在自己手中，不依赖开发工具运行的平台，这其中就会产生相应的矛盾。
胡柏表示，企业一旦选择了低代码或无代码，实际上就是使用了一种新的编程方式，这也不可避免的会产生绑定效应，一旦弃用，那么在低代码A平台的数据和功能也会流失。
与此同时，续费订阅只是低代码的一种商业模式，像轻量级的应用，企业在更换或弃用时所需要的的成本不高，类似从一种Excel 表的逻辑换到另外一种。
对于复杂的应用场景而言，像国内的大型企业其实不提倡完全订阅模式，基本上还是走本地定制服务，原因在于这种复杂的应用场景替代的代价太大。
同样对于企业而言，购买一款低代码工具，是完全依赖服务商还是将工具消化成自己的能力至关重要。
这也意味着企业在最初就要足够了解自身系统技术构架，使用低代码工具时并不是完全采用原本的功能，而是转化成自己的。
像当下很多大型企业其实都是走的吸收和消化的路径，以Oracle低代码工具为例，企业一定是需要足够了解Oracle低代码架构，哪些中间件和组件是可以被替换，哪些不能被替换，这样可以快速的融合，既保障了开发效率，又节省了成本。
归根结底，低代码只是一款工具，每一款工具都有它的边界，对于喜欢All In One的企业来讲，轻量化的低代码产品并不能满足企业关键需求，同时采用新技术背后技术和实施的方法论需要建立，让标准化的工具解决定制化需求成为可能。
当下的低代码行业仍处于早期阶段，也处于百花齐放的阶段，因此企业最早在接触低代码时，很容易产生“不知所云”的感觉，这也是当下大家对低代码意见分歧最大的原因之一。
想要在迷雾中找到一条路，企业不仅要理解低代码，更要了解自己，根据自己团队的能力、需要面对的应用场景选择合适的类型入手，这样才能在选择中完美适配企业自身的发展。
– END –
