• 发文
  • 评论
  • 微博
  • 空间
  • 微信

高低代码平台边界12问

EAWorld 2022-11-09 11:07 发文

当下的IT市场,低代码大行其道。本质上,低代码是一种抽象理念+配套工具的衍生成果,在IT历史里一直存在。我们更需要关注的是处理好高低开的关系,形成融合方案,方能帮助企业级应用更敏捷的建设。

普元数智研究院首席顾问顾伟、喻吉林通过访谈形式共同围绕目前企业低代码开发建设的市场背景、实施问题、高低开融合等常见问题作了详细解答。

访谈问题概览:

1. 怎么看低代码平台这个市场热点?

2. 低代码平台实施遇到过哪些问题?

3. 高代码平台和低代码平台如何融合?

01.

怎么看低代码平台这个市场热点

Q1:低代码开发平台的目标用户群到底是谁?

喻吉林:我们更多地希望赋予现在的低代码开发平台“行业”或“业务”的含义,让更广泛的人群能够参与到平台使用中。所以,平台不仅仅是一个通用的技术平台,它需要随着业务积累,形成更行业化的模型和元素。

事实上,低代码开发平台的目标,最终一定是在某个行业或领域能够更好地服务于大众,但低代码开发平台并不是仅仅服务于初级人员,用以提升初级人员的业务能力;低代码开发平台更多地是服务于有一定业务知识积累,有一定的业务建模能力的业务专业人员。见过一些工程师,拿着低代码平台开始无序的建设系统,最终的成果依然不及预期,其根本原因是缺少对于业务模型的理解。只有持续运用建模思维提升自己对业务模型的理解,才能够在低代码的使用中得心应手,更加可以提升自身的架构能力。

Q2:以前也有企业做低代码,为何反响一般?

喻吉林:低代码市场很大,国内大小厂商都在做低代码,但获得的收入一般。我认为,低代码不是银弹,本身来说,无论服务于哪个行业,都有其自身的边界。

低代码平台有它的边界和局限性,早期的低代码平台,往往并不能解决所有的问题。建设系统时存在各种不支持的场景,如果总是想着利用低代码自身的功能绕过去,必然给程序带来众多“坏味道”,那自然反响不会好。所以,低代码的建设,更应该关注将典型的业务场景抽象出来,形成标准化的业务模型、业务流程和业务规则,同时提供必要的扩展接口和替换接口,与高代码实现很好的扩展融合,也正是我们不断探索实践中的发展方向。

Q3:国内外对低代码热点的看法上,有什么差异?
顾伟:国外的低代码,通常是通过在线IDE模式来呈现,本质上首先是开发工具,然后才是业务的逐步积累和生态的持续打通。国内的低代码,更多是领域应用的快速配置或生成,通常还会伴随一些BI场景。
另外,国外低代码很注重完整解决方案(比如和原有技术的融合、DevOps等),而国内的大部分低代码会有一个相对封闭的问题,这个是需要逐步解决的,不能最终变成一个新孤岛的引入。

02.

低代码平台实施遇到过哪些问题

Q4:普元低代码平台聚焦的要点有哪些?

顾伟:第一个是适配。“敏捷化”的试错试对很重要。其实我们也做过两个大版本,第一版中,我们追求的是快速地页面设计、流程配置等,在这个过程中,我们发现,模型、UI、标准等在开发中,尤其面向大型的银行,央企时,会有不少问题。比如UI性能不够怎么办?数据模型怎么优化?个性化需求实现不了怎么交付?

所以在第二版中,我们聚焦重点变了,期望在不影响企业现有的技术和管理前提下,能够更好的进行适配。比如,企业已经有流程平台了,那就不要再带一个流程引擎进去了,而是应该和企业现有的流程平台做好适配。
另一个是安全。前段时间“护网行动”中很有感触,安全现在肯定是国家、企业的重点,低代码平台所开发出来的各类资源,能不能具备细粒度API安全、数据安全特性,也是我们的重要关注点。
Q5:到底是数据模型驱动,还是UI模型驱动?

喻吉林:数据模型驱动。现实生活中,用户的交互UI可能更合适,但UI只是我们某些展现形式,核心价值是由背后的模型来决定的。

本质上,由核心数据模型驱动企业业务,需要通过模型的不断抽象和丰富,来解决业务上的困惑,而不只通过UI界面。UI界面是从UI体验工程师出发的,这种方式能够很好地解决用户交互问题,但企业级建模不止有UI模型,UI模型只是企业建模中的一部分。单纯从UI模型出发,并不能解决业务建模的核心问题,脱离企业业务模型谈UI就有些本末倒置的。

Q6:到底是生成代码,还是解析执行?

顾伟:我选择走“生成代码”的模式。需要说明的是,不是说一定要生成出代码,然后走传统高开模式,而是能够生成代码,保障高性能和可维护性。高低开融合,本质上期望的是资源都在一套引擎里运行,切勿一套原生运行、另一套解析执行。如果大家追求应用的性能、个性化、维护性等,建议低开具备生成代码的能力。

Q7:个性化需求一般怎么处理?

顾伟:个性化需求本质上也是一种抽象不够的问题,说白了就是还没有抽象出低开能力来应对。现阶段我们是通过高低开融合来解决这个问题的,随着对场景的逐步积累,相信我们能够更好地应对原来不支持的场景。

Q8:应用和数据的隔离性怎么保障?

顾伟:本质上,高代码和低代码,应该是一套隔离模式。以前高代码,大家的应用和数据基本上是完全隔离的,但为什么到低代码的时候,有些人好像会觉得无所谓了呢?我认为是不对的。

普元低代码,具备和高代码一样的隔离架构设计,高和低共同组成了一个物理上独立的应用,而不是共享在一个平台进程里运行。

03.

高代码平台和低代码平台如何融合

Q9:高代码和低代码平台应该怎么分工?

顾伟:高代码和低代码,最终共同形成了一个完整应用,应用一部分靠高代码实现复杂逻辑和计算,另一部分是则靠低代码实现快速业务。高低开融合,要做到的就是让低开不会成为新的孤岛,所以企业在建设低代码时,一定要结合现有的技术和服务。

或者换一种说法,当下要Java逻辑实现的,肯定是高代码,如果能抽象的自然要低代码。从技术层面,比如写一个流程选参与者的动态计算,那一般是高代码;如果做一层业务化,选择已经做好的规则,比如我的领导,我的下属这种业务上的角色,自然就逐步低代码了,这就是一个合理分工和边界移动的过程。

Q10:高代码和低代码引擎如何能做到一致?

顾伟:高低开融合的核心就是引擎,且必须是一套引擎,包括页面引擎,流程引擎,服务编排引擎,API引擎,访问数据引擎等。如果没有统一引擎,势必会建设成两块东西,比如按会产生冲突,无法融合。在高代码平台基础上补充低代码,需要先花一段时间建设融合引擎的能力,然后定制符合你引擎的低代码平台,不要弄成新的一套平台,最终没法融合管理。

Q11:普元高低代码融合平台优势在哪里?

顾伟:优势之一:我们这版高低代码融合,合理地做了工作切分,这样我们所面向的相对复杂的业务系统支撑力会更大。

优势之二:我们不会特别去改变企业的技术架构,我们更多走的是适配思路,对既有的流程引擎也好,数据引擎也好,通过开放集成,最大化地形成利旧。

Q12:市场会如何发展?客户需求会如何发展?

喻吉林:我展望的低代码平台一定是未来的发展趋势。很多年后,我们不太可能称它为“低代码开发平台”,“Low”这个词就没了。比如,十几年前你买了一部新手机,别人会问你,你买的是“智能”手机还是手机(诺基亚等带键盘的功能手机)?那时对手机的概念就是“有键盘”的手机,如今我们提到手机,想到的肯定是没有键盘的手机。从“智能手机”到“手机”的历程,“智能”这个词就被去掉了,但是“智能“早已深入人心。我相信,未来所有平台都应该朝向更轻量级的代码、更智能化的编码迈进,这是开发平台的标配。

未来的开发平台必将是低代码开发平台,但终将形成一套新的开发平台和新的开发模式,解决应用或业务的问题。每个时期都会有新鲜的血液替代原有的血液,低代码平台是我能看到的一个趋势,新的趋势让我终将看到新一代的开发平台,一定会有一个更开放的模式,帮助更多人参与IT建设中。

低代码平台在业界是否会大卖?我认为,它终将成为我们固有的一个基础设施,能为我们解决很多问题。现在发展也不晚,因为目前没有任何厂商独领风骚,我的判断还没真正定型,都在用各自的方式诠释低代码开发平台,形成未来新的开发模式。上文在《高低开走向融合,是低成本应用建设的最终解决之道》基础上对高低开融合落地作了进一步阐述,欢迎留言交流。

声明:本文为OFweek维科号作者发布,不代表OFweek维科号立场。如有侵权或其他问题,请及时联系我们举报。
2
评论

评论

    相关阅读

    暂无数据

    EAWorld

    微服务,DevOps,数据治理,...

    举报文章问题

    ×
    • 营销广告
    • 重复、旧闻
    • 格式问题
    • 低俗
    • 标题夸张
    • 与事实不符
    • 疑似抄袭
    • 我有话要说
    确定 取消

    举报评论问题

    ×
    • 淫秽色情
    • 营销广告
    • 恶意攻击谩骂
    • 我要吐槽
    确定 取消

    用户登录×

    请输入用户名/手机/邮箱

    请输入密码