前段时间做调研，发现国内除了阿里云、华为云、腾讯云，很多PaaS企业，包括涂鸦（IOT PaaS）、有赞（有赞云PaaS）、徐工、吉利（工业互联PaaS）、恒生电子（Light云）等等，都正在推出或者计划推出低代码应用开发平台。文章尝试通过对应用软件研发发展阶段的分析，提供一个看待这一趋势的视角。
第一阶段，面向用户直接需求的应用软件研发
虽然软件厂商跟互联网企业有诸多不同，但是他们也有一个较为明显的共同点，就是几乎所有的研发投入都聚焦在面向用户直接需求的应用研发上（软件厂商主要是面向企业经营管理需求、互联网企业主要是面向个人工作生活的需求），很少有专门为应用集成研发的产品，也很少有专门为应用研发团队提供服务的研发团队。这一情况类比到制造业，几乎所有的软件厂商和互联网公司都是成品厂商，没有零部件厂商。所以我把这个阶段归纳为“面向用户直接需求的应用软件研发”。
但是社会发展充分证明了分工可以提升效率实现创新，于是在应用软件研发领域PaaS和中台就出现了。
第二阶段，PaaS服务（中台）
PaaS的出现实际上是对应用软件研发活动和程序员职责的一种分层，通过分离关注点、提升专业度和能力复用，降低应用软件研发的整体复杂度和提升效能。PaaS和中台起始于互联网，但是深刻影响到企业软件服务领域。关于PaaS和中台的讨论非常多，大家了解也比较多，这里就不啰嗦了。但是需要说明的是一点是，由于种种原因，起初企业构建的PaaS（中台）往往只服务于企业内部，这实际上限制了PaaS发挥的价值。
第三阶段，开放平台
开放平台的主要目的是PaaS能力的开放，把原先只面向企业内提供能力 转变为面向其他企业、组织甚至个人提供。这里有两点值得关注：
-
开放平台主要目的是PaaS能力的开放。这意味着使用这些能力的企业、组织和程序员怎么用这些能力、用来做什么、能否用好，其实并不是平台关注的核心，管理的手段也较为有限。 -
开放平台创造了增量，但增量有限。各种PaaS开放平台的推出，使得某些应用软件的构建成本大幅下降，使得很多创新企业或ISV通过组织小规模的研发团队也逐渐具备研发、交付较复杂的应用软件的能力，这是开放平台产生的增量。但由于PaaS开放平台先天定位的不足，使它的增量价值受到较大局限。
-
产品经理的困境是，如果API/SDK设计过于抽象，就会有程序员来吐槽不好用；如果设计的较为具体，则容易限制使用场景。
-
解决方案设计经理的困境是，面对几乎所有用户需求场景，IM/视频直播都只是必要条件而非充分条件。好比手上拿着最好的发动机和轮胎，但是客户要一辆车，总得给找齐各种没有的东西，还得说清楚怎么组装，这其实是挺复杂的事情。 -
解决方案交付经理的困境是，要把解决方案架构师画在PPT上的应用解决方案给实现出来交付出去，就得组织合适的研发资源，但由于这不是PaaS平台核心的业务，因此只能找生态伙伴来做。一来项目效率和质量得不到保证，二来项目交付可能无法留下有价值软件资产，项目二期迭代的时候，可能也会遇到种种困境。他需要一个既能做应用开发、又能沉淀软件资产、并且能有效组织生态的平台，但显然PaaS开放平台不适合这样的定位。
第四阶段，低代码应用开发平台（aPaaS）站上风口
-
对PaaS产品经理来说API/SDK被设计成各种低代码的组件，成为低代码应用设计体系内的一部分，可以有效降低学习和使用成本。
-
对解决方案设计经理来说，他原先画在PPT上各种客户解决方案可以变成低代码平台上的各种应用模版，可以有效拉近和客户需求之间的距离。 -
解决方案交付经理来说，低代码平台可以有效解决客户解决方案设计实现、资产沉淀、版本管理，规范生态伙伴的合作。
思考总结：
– END –
报告下载
