用友开发者中心

PaaS平台企业为何纷纷转向低代码开发

前段时间做调研,发现国内除了阿里云、华为云、腾讯云,很多PaaS企业,包括涂鸦(IOT PaaS)、有赞(有赞云PaaS)、徐工、吉利(工业互联PaaS)、恒生电子(Light云)等等,都正在推出或者计划推出低代码应用开发平台。文章尝试通过对应用软件研发发展阶段的分析,提供一个看待这一趋势的视角。

第一阶段,面向用户直接需求的应用软件研发

在互联网普及之前很长一段时间,软件厂商主导了应用软件研发,典型的产品是各种ERP、CRM软件。这个阶段的应用软件研发从业务层面可以归结为,根据企业(或组织)生产、经营、管理等各方面的需求、结合科学管理知识,研发出软件系统并应用到企业(或组织)的过程;从IT技术层面可以归结为,基于IOE软硬件平台,使用各种通用编程语言,采用瀑布流的组织方式,研发出应用软件的过程。互联网初始发展阶段,从IT层面很大程度上借鉴了软件厂商的经验。随着互联网基础设施的完善、入网人数快速增加,互联网应用软件出现爆发式的增长,技术和软件研发模式发生了巨大的变化,包括去IOE、云计算、大数据等等,充分体现了需求牵引生产力的发展。

虽然软件厂商跟互联网企业有诸多不同,但是他们也有一个较为明显的共同点,就是几乎所有的研发投入都聚焦在面向用户直接需求的应用研发上(软件厂商主要是面向企业经营管理需求、互联网企业主要是面向个人工作生活的需求),很少有专门为应用集成研发的产品,也很少有专门为应用研发团队提供服务的研发团队。这一情况类比到制造业,几乎所有的软件厂商和互联网公司都是成品厂商,没有零部件厂商。所以我把这个阶段归纳为“面向用户直接需求的应用软件研发”。

但是社会发展充分证明了分工可以提升效率实现创新,于是在应用软件研发领域PaaS和中台就出现了。

第二阶段,PaaS服务(中台)

PaaS主要来源于应用软件研发过程中共性的、具有较高可复用价值的需求和能力。我觉得大致可以分为三类,一类是可共用的技术性产品,比如大数据、人工智能、IoT平台等;第二类是在一定范围内可以被标准化的领域服务产品,比如商品、订单、支付服务等;第三类是流量和关系链为核心流量平台,比如微信、钉钉的小程序平台。这些PaaS可以为上层应用软件研发提供独特的能力。PaaS从软件服务向组织职责延伸,就形成了所谓的中台。

PaaS的出现实际上是对应用软件研发活动和程序员职责的一种分层,通过分离关注点、提升专业度和能力复用,降低应用软件研发的整体复杂度和提升效能。PaaS和中台起始于互联网,但是深刻影响到企业软件服务领域。关于PaaS和中台的讨论非常多,大家了解也比较多,这里就不啰嗦了。但是需要说明的是一点是,由于种种原因,起初企业构建的PaaS(中台)往往只服务于企业内部,这实际上限制了PaaS发挥的价值。

第三阶段,开放平台

当PaaS能力越来越通用化、标准化,价值逐渐被市场认可的时候,自然就形成了构建开放平台的动机。即使有些企业没有明确“开放平台”的叫法,但实际上在打造对外服务的PaaS平台时其实做了开放平台的事情:比如租户、账户体系、资源授权管理、计量计费以及各种维度监控和数据统计等能力。

开放平台的主要目的是PaaS能力的开放,把原先只面向企业内提供能力 转变为面向其他企业、组织甚至个人提供。这里有两点值得关注:

  • 开放平台主要目的是PaaS能力的开放。这意味着使用这些能力的企业、组织和程序员怎么用这些能力、用来做什么、能否用好,其实并不是平台关注的核心,管理的手段也较为有限。
  • 开放平台创造了增量,但增量有限。各种PaaS开放平台的推出,使得某些应用软件的构建成本大幅下降,使得很多创新企业或ISV通过组织小规模的研发团队也逐渐具备研发、交付较复杂的应用软件的能力,这是开放平台产生的增量。但由于PaaS开放平台先天定位的不足,使它的增量价值受到较大局限。
  • 我们来看一个例子,某互联网企业在运营推广其IM/视频PaaS平台的时候遇到了如下困境:
  • 产品经理的困境是,如果API/SDK设计过于抽象,就会有程序员来吐槽不好用;如果设计的较为具体,则容易限制使用场景。
  • 解决方案设计经理的困境是,面对几乎所有用户需求场景,IM/视频直播都只是必要条件而非充分条件。好比手上拿着最好的发动机和轮胎,但是客户要一辆车,总得给找齐各种没有的东西,还得说清楚怎么组装,这其实是挺复杂的事情。
  • 解决方案交付经理的困境是,要把解决方案架构师画在PPT上的应用解决方案给实现出来交付出去,就得组织合适的研发资源,但由于这不是PaaS平台核心的业务,因此只能找生态伙伴来做。一来项目效率和质量得不到保证,二来项目交付可能无法留下有价值软件资产,项目二期迭代的时候,可能也会遇到种种困境。他需要一个既能做应用开发、又能沉淀软件资产、并且能有效组织生态的平台,但显然PaaS开放平台不适合这样的定位。
  • 这些困境真实体现了PaaS开放平台在满足应用软件研发需求方面的不足,只有有效解决上述这些问题,才能充分发挥PaaS平台价值,这也成为PaaS企业进一步发展的动力。

第四阶段,低代码应用开发平台(aPaaS)站上风口

低代码应用开发平台能比较好的解决PaaS平台在支撑应用软件研发最后一公里上的不足,进一步拓宽PaaS的增量价值,这是不少PaaS企业开始着手打造低代码的直接动机。

  • 对PaaS产品经理来说API/SDK被设计成各种低代码的组件,成为低代码应用设计体系内的一部分,可以有效降低学习和使用成本。
  • 对解决方案设计经理来说,他原先画在PPT上各种客户解决方案可以变成低代码平台上的各种应用模版,可以有效拉近和客户需求之间的距离。
  • 解决方案交付经理来说,低代码平台可以有效解决客户解决方案设计实现、资产沉淀、版本管理,规范生态伙伴的合作。
  • 由于PaaS本身代表了某些垂直领域较高的技术和场景壁垒,因此基于PaaS推出低代码开发平台在某些领域天然具备技术或者场景的优势。另一方面,我们也看到很多没有PaaS基因的低代码平台推出,这些平台可以考虑主动对接集成一些PaaS平台能力,这将有利于低代码应用场景的完善,也将有利于生态的繁荣。今天互相走出的这一步,可能改变甚至塑造未来软件研发模式。

思考总结:

梳理和思考事物发展的脉络,有助于发现事实的真相。PaaS是互联网发展过程中自然形成的一种解构应用软件研发的方式,低代码则是抽象特定领域场景应用软件研发的一种方式,两者有比较好的互补性。认识到这一点,将有助于PaaS及低代码平台的产品设计。

来源:低码时代,内容仅供参考。

2023-10-09 14:55:36