海比研究院专访有信云产品VP:个性化的问题必须通过引擎的思想来解决


近日,中国软件网、海比研究院共同发起了关于2022中国低代码无代码市场研究访谈,有信云产品VP郑秋明受邀进行了线上交流。


低代码刚出现的时候,市场概念相对朴素,用户较容易理解。各类厂商入局后,为了提升差异化竞争能力,纷纷提出各种概念,例如表单驱动、模型驱动、数据驱动、工作流引擎等。对此,海比研究院的行业专家与有信云产品VP郑秋明进行了长达2小时的线上访谈,深入交流了关于低代码、无代码的市场环境及有信云自身的理解与实践。


由于访谈篇幅较长,现摘录部分分享,也欢迎各位行业大咖共同分享与交流。


   Q - 海比研究院   A - 有信云产品VP郑秋明   


...


Q:我们访谈过很多业内的厂商,发现大家会着重提到表单驱动、模型驱动和数据驱动,在您看来这三大驱动是指什么,之间的差异点是什么?


A:厂商已经把驱动讲成一种营销话术了,某某驱动听起来就很高级,实际这三个驱动是针对不同场景的,且不是一个分类关系。


先说说模型驱动,早在2000年左右就已经开始提了,本质是一种比较通用的软件思想。模型来源于业务,业务是场景下的业务,因此需要将它抽象成可视化的模型,从而把这一个复杂、多细节的业务抽象成几张图,可视化的去理解。


今天大部分的软件开发,包括低代码、无代码都是模型驱动的。而模型背后的核心是对象关系。商品是对象,订单是对象,商品和订单是什么关系?一个复杂的系统,可能有几百个对象,把对象连接起来,这就是一个基础的模型,这是我理解的模型驱动,它其实是蛮通用的思想。


而表单驱动与数据驱动是业务上的说法。市面上很多低代码、无代码平台抽丝剥茧后即是一个个表单,里面填一些数据,填完数据之后可以提交、浏览、删除。数据驱动跟表单驱动还有点相对,不太一样的地方在于对业务数据的处理。比如做可视化图表,数据表跟数据表之间怎么连接?连接后怎么做可视化的报表、可视化的图形?怎么对业务进行支持?这就是数据驱动。


所以三者还是比较抽象的营销话术。对于普通用户或甲方企业而言,根本不需要在乎。


不管你什么驱动,只要能够满足我的问题就行了。


Q:低代码、无代码,表单驱动、模型驱动、数据驱动,两组概念之间是否存在对应关系?


A:完全没有。


比如模型驱动,通常不是用于低代码、无代码场景的,而是近二三十年来软件编程的一直遵循的模型思想。所以模型驱动还是蛮普遍的,不局限于无代码、低代码、SaaS,做个电商也会需要。


表单和数据,部分厂商可能只做了表单,没有很强的数据,但个人觉得一个好的无代码或低代码平台,一定是表单+数据的,只是有一些侧重。否则业务很难闭环,很难给甲方提供一个真实可用的应用。


Q:但从终端客户角度,三者(驱动)给人的直观感受是表单驱动更传统简单,而模型与数据驱动更贴合IT变DT时代调性。


A:确实,且我看到的大部分平台三种驱动都有。如果问我们是什么驱动,我们不说驱动。在有信云PaaS平台上,我们称之为引擎,来源于对不同业务场景地抽象,不同的引擎对应着相应的能力。


Q:刚才讨论了市场大环境的一些看法,也有聊到有信云,那就麻烦郑总介绍一下有信云和刚提的引擎吧。


A:有信云的一站式业务在线PaaS平台,最早从18年开始。有信云与其他厂商最大的差异在于有信云是做社交电商市场起步的,当然也有像经销管理、门店管理,当年我们甚至根本不知道什么是低代码无代码。


现实中的问题是我们接触的每一家甲方公司,诉求都不一样。有信云一直服务的是KA,因此很难做一个标准化产品。理想中是做一个经销商管理系统之后,A公司可以用,B公司可以用,C公司也可以用。但市场不是这样的,哪怕是订单。A公司订单不校验库存,可以超卖;B公司订单要限购;C公司订单有很多会员规则。


怎么办?有信云一直在思考这个问题,慢慢地积累了一些独有的能力——对客户具体的业务场景进行抽象,形成了一些业内大家常说的引擎。


我们发现个性化的问题必须通过引擎的思想来解决。如社交电商一定要分钱,怎么合理地分给一级代理商,二级代理商?按地区来分,按团队来分,按商品来分还是按什么分?于是有了有信云PaaS上的分佣引擎。不管怎么分,都可以通过引擎写几行代码分到、分好。


再比如每个公司都有自己的流程,要不要库存校验,要不要限购,要不要会员价等等。于是就有了所谓的订单流,订单流本质上是一个流程引擎,订单是它的一种场景,然后跟着做了售后流、审批流、业务流等,于是把它抽象成了一个流程引擎。


但哪怕电商场景已经足够复杂,仍有很多场景是不能穷举的。于是,如商品、订单等我们称之为标准对象,依此类推如果是做会议室管理,对象就是会议室;想做进销存肯定就有库存对象;比如我们有客户是做核酸的,核酸检验报告的提交表单就是一个对象。这些帮助我们抽象出了对象引擎,慢慢就有了很多个引擎相应的能力。



之后逐渐接触到了低代码、无代码,发现我们并不像国内的很多其他厂商,学着国外的产品起来的。国外早在80年代就有了低代码的概念,低代码、无代码的市场理念与产品形态是从国外起家的。


而有信云从电商应用起家,电商里又分了门店经销,发展到现在我们发现自身有几个很大的差异点,这里可以分享一下。


第一,有信云是国内唯一一家做企业外部经营数字化的低代码公司。简单来讲,你去问国内比较知名的低代码厂商能不能做一个电商应用?他们会说不行,因为我们真的去问过,基本都是做CRM类的。


Q:为什么做不出来?在他们的低代码平台上。


A:这里就涉及到第二个差异点。有信云也是唯一一家可以将订单流、退货流、商品流等流程可视化的低代码公司。


电商应用是外部连接应用,它有几道很重要的坎。


第一点,它的连接范围是最广泛的。现在市面上绝大部分低代码、无代码厂商的连接范围是企业内部,有信云PaaS的连接范围包括企业内部、合作伙伴,尤其是经销商、代理商、广告商等等,最后就是C端客户。


第二个坎是电商相关流程的配置能力可视化难以实现,因为电商是极其复杂的。光商品就有十几个对象。商品本身有单品,然后有商品规格、商品价格、商品详情,还有对象之间的关系,才构成了商品本身。商品复杂,订单又很复杂,店铺也很复杂,支付也很复杂,人货钱场单都很复杂。所以有信云预制了这些,像前面提到的,不要限购,要预售,要会员价等等,在有信云的PaaS平台可以直接配置和调整。


第三个坎是并发。为什么很多国内的to B应用不好用,或者说用起来慢、卡?本质原因在于用户量不大,都是企业内部人员用,并发的支撑能力并不强。但一个电商应用,有信云部分客户一次秒杀可能就过来几十上百万人。外部应用对并发量的要求非常之高,对于技术架构也是有要求的。


国内的大部分低代码、无代码平台核心架构还是宏服务,所有的对象放一起。有信云的微服务架构可以让需要高并发的场景单独做成微服务,每个微服务之间,内部高聚合,外部低耦合。再之,我们做了很多这种技术上的优化与迭代,使得在外部的高并发场景下都能满足。


这三个门槛,导致大部分的低代码、无代码平台做不了外部业务数字化的应用,尤其是以电商为代表的这一类应用。这也就是我们的第二个差异点。


第三个差异点,在国内低代码领域,有信云是唯一一家推出自己的DSL语言的公司,命名为EXAP。EX即拓展,extension,APP则是application,应用,即应用拓展。EXAP是一个类Java的语言,但语法量是Java的1/50。


DSL,D代表着domain,只适用于我们的领域,代码导出后是无法使用的。只适用于有信云PaaS,意味着我们可以把这东西做得很简单。


比如写订单模块,起码要有5年的后端开发经验,对订单模块非常之熟悉。但在有信云PaaS上不需要。你可能只是一个大专毕业生,要嵌一段代码去校验一下订单的库存,只需要拖一个组件过来,用DSL语言写一小段代码,就可以跑通整个订单流。它不需要一个资深的Java开发,只需要理解业务逻辑,懂一点代码,就可以写复杂的订单应用。


...

解决方案
客户成功
关于有信云
—————————————————————————————————————————————————————————
公司全称:广州有信科技有限公司
电话:400-003-1009
邮箱:marketing@youxin.cloud
友情链接:芝麻小客服   办公易
Copyright ©️ 2018-2024 有信云 All Right Reserved
产品相关
关注我们
在线咨询