为什么PaaS平台企业都在搞低代码？--RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展

前段时间做调研，发现国内除了阿里云、华为云、腾讯云，很多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平台能力，这将有利于低代码应用场景的完善，也将有利于生态的繁荣。今天互相走出的这一步，可能改变甚至塑造未来软件研发模式。