从No-Code到Low-Code：企业级HpaPaaS的未来大小，等了半个月，拿回来就可以穿了，衣服合身，喜欢。场景切回到今天，我们只需要看天猫和淘宝上的图片，选对尺码后下单，第二天就可以穿了。关爱，因为我们享受了更多的便利和效率。受益于这个行业制定的许多标准化模型，例如身体模型：S、L、XL、XXL，我不再需要每次都测量身高和尺寸。现在标准化生产的服装可以满足90%以上的需求。除了明星或特殊场景，它不会费心去量身定做。服装、餐饮、汽车等各行各业的发展，形成了非常成熟高效的产业链。软件研发行业也是如此。业务需求正在快速增长和变化。瓶颈。这就需要制定更多的标准和模型。标准越统一，效率就越高。有时候“放弃创意就是最大的创意”。本质是追求包容。可以预见，大多数场景将使用标准化模板来满足业务需求，而无需定制或定制程度较低。预期的软件研发态势接下来简单说说基于no-code>low-code>procode递进思路的研发体系。一个前置概念开篇之前先介绍几个概念：云计算主要分为三类服务：软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。软件即服务(SaaS)是一种通过Internet交付应用程序的模型。客户可以通过网络浏览器访问SaaS应用程序，这意味着客户无需购买、安装、维护和更新硬件或软件。SaaS提供商负责确保一切顺利运行，并且客户通常可以访问最新版本的应用程序。平台即服务(PaaS)提供云平台和工具来帮助开发人员构建和部署云应用程序。用户可以通过网络浏览器访问PaaS，因此企业无需购买和维护底层硬件和软件。借助PaaS，开发人员还可以在租赁的基础上挑选和选择他们需要的功能。借助基础架构即服务(IaaS)，企业可以按使用量付费的方式“租用”服务器、网络、存储和操作系统等计算资源。IaaS提供商托管基础设施并处理系统维护和备份等任务，因此客户无需购买硬件或聘请内部专家来管理它。在PaaS层，有一个专门支持应用在云端的开发、部署和运行的平台，称为aPaaS（Applicationplatformasaservice）。在aPaaS的基础上，提供了一个no-code&low-code的应用开发平台hpaPaaS（High-productivityaPaaS），提供业务编排、逻辑编排、模型驱动、页面驱动等快速应用开发能力layout等上面的一些概念是我个人理解的补充。不同的平台可能有不同的解释。接下来我们就来对比一下业内几家明星平台，看看它们能给我们带来哪些参考。二、业界最好的MicrosoftPowerApps：MicrosoftFamilyBucket服务集成很好，比如Excel，整个站点写代码的地方统一为Formula/Fx，和Excel类似。另外，PowerBI/PowerFlow很强大，定位hpaPaaS（low-code）；GoogleAppMaker：Google出品，GoogleFamilyBucket服务集成很好，Google的工程师文化在SCRIPTS上比较极端。后台和前端均采用开发生态的JS语法，代码提示非常友好，定位为hpaPaaS（低代码）；SaaS及综合云平台，目前市值1255亿美元；SAP：集IaaS、PaaS、SaaS于一体的云平台，与salesforce相比，使用更新的技术和更好的体验，目前市值1577亿美元；OutSystems：提供桌面IDE，最近提供的OutSystemsAI可以辅助模型设计和定位hpaPaaS（low-code）。作为后起之秀，其表现不俗，已获得多轮融资。独角兽。应用研发能力对比如下：部分产品体验：老牌谷歌和微软玩家玩hpaPaaS都非常好，体验相当细腻。自己服务的整合，包括第三方常用的服务，做的很好。OutSystems类似于微软。它提供了多种流媒体安排。在很多情况下，它不需要编写代码。它还集成了很多数据服务，比如Swagger的OpenAPI。Salesforce类似于SAP，从单个应用，到一组应用，再到快速应用开发平台、企业协作工具，再到应用容器和数据库，提供完整的生态链，与SaaS、PaaS和IaaS分层导出。几点参考：高效集成可以降低成本。这是所有玩家的心声，不容质疑。要扩大视角，覆盖90%的场景，就必须构建完整的生态链。从no-code到low-code再到pro-code都要有相应的解决方案，而且要能相互通信。打开，这是Salesforce和SAP给的经验。目前AppMaker和PowerApps主要针对的是表格、表格等垂直领域，发挥不了太大的作用。单一视场视角解决的问题是有限的。可视化流式编排可以显着提升特定场景的效率，但处理稍复杂的场景就没有乐趣了。比如AppMaker就有点粗糙，直接用SCRIPTS写表达式比较舒服。我不知道使用OutSystems的用户感觉如何。3、可视化网站建设历时已久。国内出现了很多可视化建站产品。“可视化建站”是“低代码建站”的前身。目标是在不编写代码的情况下构建站点。拖拽，但更多的是从表现层（前端）的单一领域解决问题，只能达到静态页面的效果，难以完成真正业务的闭环。总结一下突出的问题：纯粹的前端思维，比如数据服务的访问方式，缺乏像AppMaker/PowerApps一样支持DataConnectors的统一数据访问层，没有和各个系统进行有效的集成。能解决的场景也是有限的。高度复杂的企业级CRM系统并不是始终统一的。业务逻辑高度复杂，面临定制化考验。如果稍微复杂一点，就需要做更多的工作，有时甚至无法处理，没有享受到视觉建设带来的福祉。很多专业的开发者在搭建平台上无法施展才华，缺乏专业级的工具支持，比如VSCode、Git。不同角色不能有效形成协同，比如后端数据接口，无法在可视化构建工具中体现。大部分构建页面都以Schema的形式存储，代码不易diff。运行时动态渲染也会造成性能问题。...看到行业内很多优秀的设计，给我们带来了很多奇思妙想。典型的hpaPaaS架构在一定程度上完全可以解决我们标准化的场景，但是标准化的场景更面向消费者。消耗我们生产的素材沉淀和场景沉淀，这样一个纯粹的hpaPaaS平台，在处理企业级场景的时候肯定会透支。需要考虑灵活性、可扩展性和复杂性。在这个体系中，要不断生产标准化的素材和场景，不断抽象和沉淀复杂的问题，形成有效的生态循环体系。我们需要的是一种增强版的hpaPaaS平台——企业级hpaPaaS平台。4、企业级hpaPaaS以我们“企业智能事业部”为例，做一个简单的业务分类：中后台业务大部分都是和表单、表单相关的。这对于hpaPaaS平台来说是一件好事，但它真正代表了一个企业级的场景。尤其是金融、法律等系统，涉及的表格可谓魔鬼，如表格嵌套表格、表格嵌套表格（存在必须合理），无法用一套规则来描述，强大到AppMaker或PowerApps基本都有这类问题没有解决方案，主要是因为它没有提供备份机制。企业级应用的初始状态多为定制化应用。“级别的hpaPaaS平台”需要解决。更年轻的产品AppMaker和PowerApps被定义为商业级解决方案，而更成熟的SAP和Salesforce被定义为企业级解决方案。商业层面可以解决大部分常见的问题，而企业层面必须能够解决更复杂的问题，面对复杂的企业级问题，我认为至少应该做两件事：将不同场景所需的能力进行分解和分层，最后通过能力的整合来处理它们，提高灵活性；同时，有通用的解决方案和自下而上的方案，各种方案之间要遵循统一的标准，进行整合。如果非要用一句话来概括企业级的hpaPaaS能力，我觉得是从无代码到有代码的渐进能力，如下图：实现这样一个“企业级”有几大难点hpaPaaS"::从无代码到亲代码以一个简单的业务系统为例来描述这个过程。Iteration1（无代码开发）最初比较简单，符合标准化的CRUD：进行业务建模，配置业务规则；根据建立的模型选择标准化的CRUD模板，直接生产；预览和发布。迭代2（低代码开发）但有些地方需要稍微定制，比如时间戳的格式，需要在页面上显示额外的用户详细信息：打开标准化生成的产品，可视化编辑；修改关联字段timeMode的格式，增加用户信息块；保存、预览、发布。Iteration3(pro-codedevelopment)随着业务复杂度越来越高，很多业务逻辑需要写更多的代码，希望对代码进行版本控制、diff等：在WebIDE中打开标准化生成的产品;编辑视图，比如Associatedactions，定位到对应的action代码，修改逻辑；使用WebIDE提供的git功能进行代码比对和代码提交；保存、编译、预览和发布。无代码和低代码的试错成本较低。我更喜欢在启动期间使用这两种方法。随着我的业务越来越大，价值逐渐被认可，对这个产品的要求也越来越高。这个时候，我也愿意投入更多。这时候我就可以使用pro-code来细化我的项目了。这种渐进式交付能力将越来越受到尊重。在这个过程中，有一个关键点，no-code到low-code再到pro-code始终遵循一个标准，需要的时候可以随便打开。虽然我们预计未来只有10%的业务研发需要pro-code来完成，但是pro-code的相关技术体系也是必不可少的。它是一个全功能开放的底层架构，在无代码和低代码的基础上，更垂直，所以不代表10%不需要，尤其是在做企业级研发的时候，存在亲码是一颗定心丸。亲码的核心要点是：WebIDE：在亲码的设计中，可以使用桌面IDE，但未来一定属于云开发时代。桌面IDE自然地与PaaS平台分开。过去担心WebIDE技术不成熟，今天vscode引领新一代编辑器变革，带来coder、theia等功能性能完备的WebIDE技术储备，技术上无后顾之忧；Git接入：企业级产品，没那么随意，一般需要强控制，其中版本控制尤为重要。不管是pro-code还是no-code，最终的形式都是代码形式的标准产品，应该托管在Git仓库上，必要时可以回溯对比；打通可视化编辑：可视化编辑是低代码、无代码的代表功能。通过Recore（统一DSL）技术打通可视化和亲代码，介于亲代码、低代码和无代码之间。互操作性的必要条件。难点二：服务整合上面提到的产品都有这样的设计，无论是自己的服务还是别人的服务，通过一个整合平台，将它们有机的整合在一起，在任何必要的环节，都可以高效的使用。图片来源：https://developers.google.com/我们也提出了OneService的概念，期望通过OneService集成数据相关的接口或服务，打通生产中的所有环节，如下图：难点3:Vitality设计的系统更关心两个问题：它能创造多少价值？它能活多久？我认为一个具有顽强生命力的系统，应该在时间维度上持续创造价值。有以下几个要点：土壤适宜，风向强，还有政策鼓励，市场需求旺盛；持续标准化，标准化不是一个固定的结果，而是一个动态的过程，需要一种演化机制来保证标准化生态具有自清洁能力，适应行业发展；行业渗透，打通产业链上下游，将标准和理念融入行业各个节点，反哺自身生态，形成规模；共同成长，带动行业的成长，行业的成长就是自身的成长。以SAP、Salesforce为代表的5个未来可期的基于SaaS的平台，在欧美国家活得很好，在中国才刚刚起步。从过去一年的变化可以看出，国家越来越多的政策鼓励中小创新企业，意味着toB市场未来前景广阔。阿里整体趋势现在也是toB。钉钉和阿里云在这条路上越走越稳。让我们看到toB的时机已经成熟，我们现在要做的就是把本土化的SaaS平台做的更好做强。相关参考和链接https://www.sap.cn/products/business-technology-platform.html
