作者 | Arunkumar Arunachalam
译者 | 明知山
策划 | 丁晓昀
程序员和非程序员通常可以在低代码 / 无代码（LCNC）平台上通过拖放的方式构建应用程序，几乎不需要编码，可以一键部署，在传统的缓慢、昂贵和效率低下的开发和部署过程提供了另一条途径。
这些平台旨在加快这一过程，提供快速的“应用程序开发和部署平台即服务”。
照片来自Felix Mittermeier（Unsplash）
LCNC 的发展状态
Nasscom 的一份报告指出，LCNC 可以减少 3 到 7 倍的开发和部署时间，减少 3 到 5 倍的成本。
甘特的一项研究表明，到 2025 年，70% 的应用程序开发将是低代码的，在低代码开发技术上的投入预计将增长到近 300 亿美元。
麦肯锡最近的一项研究显示，向公民开发者授权开发的组织在创新方面的得分比那些没有授权的组织高 33%。
想要保持竞争力的企业需要制定一个明确的 LCNC 采用战略，因为它改变了应用程序开发的范式，为创新提供了更快、更民主的方法。
为你的组织选择 LCNC
无数的 LCNC 平台（使用 WordClouds.com 生成）
市面上有超过 300 个 LCNC 平台，它们的用途、定价和锁定选项各不相同。因为有众多的选项，所以决策过程可能变得相当具有挑战性。选择满足组织长期需求的 LCNC 平台可能更为迫切。
在本文中，我将通过解释在为企业选择 LCNC 时应该找到的六个契合度来帮助你简化决策过程。
目的契合：满足需求
驱动组织构建应用程序的主要目的通常可以分为以下三种类别。
- 原型：在构建成熟的应用程序之前先验证想法；
- 一次性需求：如营销 / 活动网站；
- 持续演化的应用程序：这些通常是业务线应用程序。
对于原型和一次性需求，选择无代码平台会更好。例如，公民开发者应该使用无代码平台创建原型来验证和展示他们的需求。IT 部门随后可以将其开发成成熟的应用程序。此外，公民开发者可以使用无代码平台自行完成一次性需求，如调查或活动页面。
对于需要持续演化的应用程序，选择低代码平台更合适，因为可以通过代码来增强应用程序。如果需求很独特（不是通过模板实现的）或经常变化，那么标准的开发实践会更适合。
LCNC 平台还适合用于开发特定类型的应用程序，如网站、网页应用程序、语音应用程序、移动应用程序、API 或数据库。对于这些场景，都有相应的 LCNC 平台。因此，为特定目的选择正确的 LCNC 往往是一个好的开始，你不一定要只使用一个企业范围的 LCNC 平台。
以下是一些对应于特定类型应用程序的 LCNC 平台。
利用不同的 LCNC 平台来满足特定的需求
例如，你可以为内部 LOB 应用程序选择 OutSystems，为面向客户的活动网站选择 Webflow。
成本契合：选择正确的定价模型
LCNC 平台有着不同的定价模型。典型的许可模型提供了按终端用户、按编辑器、按应用程序、按请求数量、按数据库行或按坐席的定价模式。
例如，按终端用户定价模型以 LCNC 平台开发出的应用程序的终端用户数量为基础。
你需要为特定的目的选择合适的定价模型。例如，对于面向内部（B2E）的应用程序，你可能会考虑选择按终端用户定价模型，但对于面向客户的应用程序则不能这样，因为你的成本可能会急剧上升。
选择按终端用户定价模式应该只针对受众有限的应用程序。
锁定成本应该被视为成本契合度的一部分。你需要了解 LCNC 平台是否提供代码导出和自托管功能，以降低被锁定的风险。
运维契合：选择合适的部署类型
LCNC 平台通常提供多种托管选项。典型的托管选项包括 LCNC 供应商的云平台和你自己的自托管基础设施。
供应商的云平台提供了端到端 DevOps 工具链，这些工具链易于操作管理，并且具有成本效益。如果有大量的应用程序部署在它们的环境中，并且这些应用程序在本质上是隔离的（这意味着与部署在宿主基础设施中的应用程序的集成是有限的），那么这种优势就很明显。你还需要检查供应商的云是否为你部署的资源提供了透明度，并根据应用程序的关键程度提供分层支持。
例如，如果你在 Mendix 平台上开发了大量的应用程序，并计划在这个平台上构建更多的应用程序，那么选择 Mendix Cloud 是相对划算的，运维也很简单。
当应用程序的数量很大、相互隔离且不提供导出选项时，那么就选择供应商的云平台。
作为运维契合度的一部分，我们还应该从安全性、可观察性、性能和支持立场等方面来考察 LCNC 平台。例如，如果谜有更严格的数据需求，那么就选择提供自托管或集成自托管数据库的平台。
用户契合：平衡视角
采用 LCNC 平台涉及到三种用户角色：采购者角色、平台用户角色和企业架构师角色。平台用户角色可以进一步细分为 公民开发者 角色和专业开发者角色。我们需要平衡这三种角色的需求。
角色的平衡
采购者角色更关注成本，而企业架构师角色可能担心锁定问题，平台用户角色则更关心良好的目的契合度。
我们应该优先考虑平台用户的需求，如目的契合、定制支持、可学习性或可集成性支持，但也必须做出妥协。对于企业架构师的需求，例如标准合规性、安全性、锁定风险或服务支持，应该第二优先考虑，但不应该做出重大妥协，因为它们可能会对组织产生不利影响。采购者角色的需求，如成本，应该放在最后，但需要针对可获得的回报进行评估。
例如，LCNC 平台的白标签特性应该优先被考虑，而强制性企业安全需求应该次之。根据平台的回报来评估平台的定价模型应该放到最后考虑。
我们需要平衡这三种角色：采购者、平台用户和企业架构师。
用例契合：外部或内部
在企业中，应用程序用例大致可以分为面向外部的应用程序和面向内部的应用程序。LCNC 平台可以进一步分为公民开发者应用程序和专业开发者应用程序。
应用程序用例和 LCNC 平台用户
有些 LCNC 平台适合公民开发者构建面向员工的内部应用程序，而有些 LCNC 平台可能适合专业开发者开发面向客户的应用程序。
大多数 LCNC 平台的设计目标通常是为了加快某些类型应用程序的开发，如表单式 CRUD 应用程序或类似电子表格的应用程序。这种限制可能可以归因于平台提供的模板及其可配置选项，以及自定义编码方面的可扩展性途径。
一般来说，模板驱动的工具专注于工作流 / 自动化或类似电子表格的应用程序，更适合内部业务应用程序，而非面向客户（B2C）的应用程序。通常，B2C 应用程序通过定制的用户体验保证了更多的差异化。模板驱动的平台在定制方面存在局限性（这在 B2C 应用程序中非常需要），开发定制特性可能会花费你更多的精力。因此，通过自动生成样板元素来提高开发人者生产力（在编码和部署方面）的平台更适合 B2C 应用程序。
例如，假设两个平台提供了相似的功能，那么 TeleportHQ 可能更适合开发 B2C 网站，因为它提供了代码导出选项（并且是按编辑器定价），这比按终端用户定价的平台更好。类似地，GitHub Copilot（借助 AI 实现更快的编码）更适合构建 B2C 应用程序，因为它能够更快地编码来构建面向客户的差异化功能。
“模板驱动”的 LCNC 平台更适合内部应用，“代码赋能”型 LCNC 平台更适合外部应用程序。
组织契合：现有的因素
选择 LCNC 平台取决于现有的平台（ServiceNow、Salesforce、SAP)、现有的技术（Java、.NET）、现有的技能（公民开发者）、现有的合规标准（WCAG），还取决于与现有系统或工具的集成。
LCNC 的采用需要一个合适的治理模型，避免在公民开发者放手去做时出现应用程序泛滥和安全性问题。你还需要有一个卓越中心（Centre of Excellence，CoE）来推动 LCNC 平台的采用，并提高 相关人员（业务技术人员） 的技能。
注意现有的因素：平台、技术、技能、标准和治理模型。
在提高技能方面，有许多针对无代码和低代码平台的社区。这些社区提供了模板、论坛等。以下是一些例子：
- Nocode HQ；
- NoCodeDevs；
- NoCodeTech；
- Makerpad。
还有与 LCNC 平台相关的技术大会（如 LowCodeCon），方便使用这些平台的人相互交流。
下一步该怎么做
当你选择了一个行为，你也选择了这个行为的后果。如果你想要一个结果，最好采取会把你引向这个结果的行动。 ——Lois McMaster Bujold
对于这六个契合度，组织需要一个决策树，帮助业务技术人员和 IT 团队在传统开发、低代码平台和无代码平台之间做出选择。决策树应该考虑到这六种契合度，例如平台用户类型（公民开发者、专业开发者）和用例（外部、内部）。除了决策树之外，组织还需要举荐一组满足所有决策树场景的 LCNC 平台。
如何采用 LCNC
组织可以通过以下方式来采用 LCNC 平台。
采用 LCNC
- 基于六种契合度选择 LCNC 平台；
- 让的 IT 团队或 IT 交付伙伴进行 PoC；
- 指派一个团队评审平台的运维契合度，重点关注安全性、监控和支持。如果不合适，返回第一步；
- 对于无代码平台，可以帮助公民开发者提升技能；
- 组建 CoE 来监督采用情况和合规性。CoE 应该制定一个决策树，并划分应该使用特定 LCNC 平台的场景；
- 建立 LCNC 开发工作流；让你的公民开发者或专业开发者构建应用程序；让 IT 团队在审计和评审之后部署应用程序；
- 在公民开发者和 IT 团队之间建立运维节奏，实现持续协作；
- 跟踪省下来的开发者精力和平台成本。
IT 的角色
最后，你的 IT 团队需要在采用 LCNC 方面发挥关键作用，特别是为公民开发者采用无代码平台，他们所处的位置非常适合指导公民开发者进行创新，也适合维护企业标准，因为他们承担着维护整个 IT 资产（包括托管在 LCNC 平台上的应用程序）的责任。
IT 在 LCNC 采用流程中的角色
IT 团队的基础设施 / 运维部分可以作为“平台团队”（在《团队拓扑》一书中定义）来提升 LCNC 平台的运维能力。特定于业务组合的应用程序团队可以扮演“授权团队”的角色，指导公民开发者（在各自的业务组合中）构建应用程序，并防止应用程序泛滥。
结 论
作为采用 LCNC 的第一步，你可以在 NoCodeTech 的 LCNC 目录 以及著名的 甘特魔力象限 和 Forrester Wave 中了解更多关于 LCNC 平台的信息，你将了解到有哪些可用的选项。
接下来，你可以在你的组织中寻找简单的 B2E 应用程序或需求。例如，与合规性相关、用户数量有限、包含一两个 CRUD 的应用程序。
在有了第一个应用程序之后，本文介绍的六种契合度应该可以帮你选出一个合适的 LCNC 平台来满足你的需求。
作者简介：
Arunkumar Arunachalam 是一位技术顾问和解决方案架构师，专注于云计算转型、LCNC 和可持续 IT。他是塔塔咨询服务公司技术领导团队的一员。他喜欢探索新技术和分享知识。
原文链接：
https://www.infoq.com/articles/assessing-lcnc-platforms/
相关阅读：
十问低代码 (https://www.infoq.cn/video/lclHl49VedBpoqUVXM6h)
低代码编程及其市场机遇剖析|低代码技术内幕 (https://www.infoq.cn/article/Us10TOa418u2xwfZ19Gp)
声明：本文为 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
开源意味着不问责，我们准备好应对比 Log4Shell 更大的安全危机了吗？｜Log4j 一周年特别报道
阿里过去一年裁员达19000人；字节跳动布局中国版 ChatGPT；马斯克称下周将开源推特算法代码 ｜ Q资讯
技术裁员正在助长新的创业潮：本来犹豫要不要创业，没想到公司替我做了决定
入行 14 年，我还是觉得编程很难：给大项目写代码没意思还危险
