低代码平台和社区开发者的崛起：更多解决方案还是更多问题？

本文要点

• 低代码平台是目前最热门的软件类别。在目前的投资水平下，未来会有大量由非 IT 人员开发的自定义业务应用程序供其团队使用。

• 低代码平台可以分为三种不同的类别：UI 生成软件、集成软件和转换软件。

• 社区开发者使用低代码平台为自己和团队创建解决方案，因为他们不能使用企业系统来完成某些任务。这些用户一直都存在，你可以看到他们使用 Excel 出色地完成工作。

• 社区开发者会带来两种风险。首先是集成风险，涉及到公开不应该被公开的数据。第二是转换风险，包括应用程序中的 bug 或错误计算，从而导致糟糕的业务决策。

• 低代码解决方案的可见性是管理风险的关键。为了最大化社区开发者构建的应用程序的可见性，建议你为社区开发者提供一个单一的低代码平台。你还必须在该平台上为社区开发者提供培训。

低代码平台是目前最热门的软件类别。除了数百家初创企业，在过去 24 个月里，三大云服务提供商都推出了自己的低代码平台。在目前的投资水平下，未来会有大量由非 IT 人员开发的自定义业务应用程序供其团队使用。

为了帮助你理解这一趋势将如何影响你的 IT 组织，我们将讨论低代码平台的类型，以及你的组织中将有哪些类型的员工会被低代码平台所吸引。然后，我们将探讨低代码平台如何与你的 IT 架构相匹配。最后，我们将提供在低代码世界中管理 IT 的最佳策略。

什么是低代码平台？

你可以把低代码平台想象成 Excel，它们只是用户手中的一种软件工具，在各种各样的业务场景中都很有用。通过这些工具，他们可以创建解决方案或问题。

我们将低代码平台分为三个不同的类别，每个类别将吸引组织中不同类型的用户。

1. UI 生成软件

Retool和Bubble可能是这类低代码应用程序中最著名的例子。用户可以快速创建出用户界面，与存储在平台的数据表中的数据发生交互。

来自三大云供应商的产品分别是：

1. 微软的Powerapps
   

2. 谷歌的Appsheet
   

3. AWS 的Honeycode
   

4. 集成软件

Zapier就是这种低代码应用程序的一个典型例子。用户在应用程序和触发器之间建立连接，并通过这些连接来移动数据。

3. 转换软件

这一类别比较广泛，主要目的是提升数据在应用程序之间移动的价值。这个类别包括机器学习工具（如AWS Sagemaker）、数据提取工具（如Sypht）和 RPA 软件（如UIPath）。

点击这里查看更多低代码平台。

什么是社区开发者？

社区开发者是指组织里的员工，他们用低代码平台为自己和团队创建解决方案，以解决特定的业务问题。

这些用户一直都存在，你可以看到他们使用 Excel 出色地完成工作。Excel 用户可以分成以下几种类型，这与低代码平台用户的分类方式是一样的。

1. UI 创建者：这些用户用 Excel 创建表格，并对数据进行格式化，让它们更易于阅读。他们可能会使用诸如 VLookup 公式之类的技术来链接多个工作表的数据，就像低代码用户在低代码 UI 应用程序中创建表关联一样。

2. 集成者：这些用户构建更复杂的 Excel 应用程序，用来处理导入到 Excel 中的数据或者来自数据库或 API 的数据。

3. 转换者：这些用户创建复杂的公式来完成数据转换。一些用户使用 VBA 创建函数来执行更复杂的转换任务。

社区开发者如何在组织中使用低代码平台

大多数社区开发者使用低代码平台都将经历三个阶段，其中有很多社区开发者不会超越第一或第二阶段，但有些人会进入第三阶段，并开发出可以被整个业务使用的全功能应用程序。

第一阶段——UI 生成：最初，他们将创建具有良好用户界面的应用程序，并将数据输入到应用程序中。例如，他们可以制作一个会议记录应用程序，允许用户在会议进行过程中添加会议记录。这是 UI 生成阶段。

第二阶段——集成：随着用户经验的积累，他们将进入第二个阶段，开始从外部系统和数据源获取数据。例如，他们将增强会议记录应用程序，从 Outlook 中提取日历信息，并在每次会议后给与会者发邮件，提供一份会议记录的副本。这就是集成阶段。

第三阶段——转换：最后，他们将开始创建可以执行复杂转换的应用程序。例如，他们可以通过机器学习模型运行会议记录来标记和存储会议内容，以便可以按照主题进行搜索。这就是转换阶段。

社区开发者的动机来自哪里？

社区开发者正在构建低代码应用程序，因为他们不能使用企业系统来完成某些任务。你可以将你的企业系统技术栈看成是一个马赛克。你的目标是让你的应用程序看起来像一堵平铺的墙，每个应用程序都直接连接到相邻的应用程序。

但现实情况是，合并、收购、历史异常和不断变化的业务需求意味着你的应用程序在某些领域存在重叠，而在某些领域又存在差异。正是这些差异促使社区开发者通过 Excel 电子表格或使用低代码平台来填补。在你的用户眼里，你的 IT 技术栈可能更像下面的图像，而不是上面的图像那样。

在过去，你有三个选项可用来填补技术栈中的缺口：

1. 增强企业系统，以完成所需的任务。例如，如果你的业务团队需要来自核心系统的数据（如金融系统或 ERP 系统），你的团队可以增强核心系统，将这些信息作为客户记录的一部分。

2. 开发自定义的应用程序，以解决用户的特定需求。例如，如果分契物业风险评级信息对于你的核保团队来说是有用的，你可以考虑构建一个自定义应用程序，为你的核保团队提供这些信息。

3. 购买第三方工具。例如，如果你的客户支持团队需要一种方法来监控有关你公司的推文，你可以考虑订阅 Twitter 的监控服务。

每种选项都有各自的优点和缺点。

第一个选项(增强核心系统)允许开发团队在不向技术栈中添加额外系统或应用程序的情况下提供一个解决方案来满足用户的需求。缺点是，这些解决方案需要花费时间来构建、测试和部署，并且受到团队可用资源的限制。用不了多久，需求就会超过你提供定制解决方案的能力。

第二个选项(构建自定义解决方案)通常比第一种选项更容易，但仍然需要你付出大量的努力来开发、测试、部署和支持解决方案。

第三个选项(使用第三方解决方案)可以带来功能非常全面的解决方案，但需要时间和资源来获取和集成。而且，第三方解决方案通常会包含一些与你的企业系统相重叠的功能，从而导致用户以多种方式完成同一种任务。

社区开发者为你提供了第四个选项，填补了 IT 能力的空白。从理论上讲，如果你有一小群社区开发者可以构建满足团队需求的应用程序，那么组织的 IT 能力应该会得到显著的提高。

但风险也很大。你可以把你的 IT 团队想象成一小群可以通过施展魔法来帮助你建设王国的奇才。现在想象一下，如果突然间每个人都可以施展魔法，那么你的王国会发生怎样的变化。他们可以完成伟大的事情，但也不可避免地会发生错误，你可能会发现有人无意中将你的城堡防御计划暴露给了邻国。

风险在哪里？

社区开发者会带来两种风险，我们将以使用 Excel 为例。

1. 集成风险：这种风险涉及到公开不应该公开的数据，这是最不常见但却最令人尴尬的风险。社区开发者会不经意地将数据发送到不应该发送的地方，他们会通过电子邮件发送 Excel 表格，当中包含了他们不打算发送出去的数据。例如，在 2017 年，一名波音员工无意中将 3.6 万名同事的个人信息包含 Excel 表格中，并通过邮件发送出去。通过 API 来移动数据的低代码平台极大地增加了发生这类问题的机会。

2. 转换风险：这种风险包括应用程序中的 bug 或错误计算，从而导致糟糕的业务决策，这是 Excel 解决方案中最常见的问题。一些研究表明，大多数 Excel 电子表格至少会导致一个错误的发生。这类错误的一个例子发生在去年，一个电子表格错误推迟了英国一家新医院的开业。同样地，低代码平台也会包含转换错误，但我们并不认为这些错误会比 Excel 中已经存在的错误更普遍。

点击这里查看更多 Excel 风险的例子。通读这些内容将有助于了解社区开发者可能会给你带来的风险类型。

低代码的每个阶段对于你的组织来说都有不同的风险。

第一阶段 (UI 生成)的社区开发者所带来的风险较低。他们处理的数据通常被手动输入到应用程序中，例如上面讨论的会议记录应用程序。你应该像处理电子邮件和其他沟通方式那样来处理这个问题。

第二阶段(集成)社区开发者带来的风险更高一些。他们使用低代码平台从系统读取和写入数据，如 CRM(客户关系管理)系统或外部 API（如 Clearbit），以此来增强潜在客户数据或通过 Mailgun 批量发送电子邮件。这类应用程序会执行一些功能，比如向现场人员提供来自支持系统的工作数据，或者向销售人员提供来自 CRM 的信息。这些应用程序引入了用户身份验证风险和数据安全问题。

第三阶段(转换)社区开发者带来的风险是最高的。除了读写系统和外部系统的数据之外，他们还对数据进行转换。这类应用程序包括那些利用机器学习解决方案的应用程序（如 AWS Sagemaker），以此来给组织带来独特的好处。例如，社区开发者从你的 CRM 中获取潜在客户数据，将其与从 Twitter 中提取的数据结合起来，通过 AWS Sagemaker 运行主题模型分析，并根据他们发布的主题来锁定潜在客户。

除了在集成阶段引入的风险外，这些应用程序还会带来错误转换数据的风险。例如，社区开发者构建了一种机器学习模型，用于对客户支持问题的严重程度进行分类，但你又不想让他们的模型存在性别或种族偏见，以免导致组织不为某一组客户提供服务。

下面的图显示了我们如何看待低代码平台存在的风险。

每张图显示了其中的一个阶段。每个阶段的橙色部分是 IT 组织不应该参与的应用程序的比例。每个阶段的紫色和红色部分显示了 IT 组织应该参与的应用程序的比例。红色部分显示了处理敏感数据的应用程序的比例，这些数据存在集成风险。紫色部分显示了复杂性高到 IT 团队必须参与的应用程序比例。

第一张图显示了第一类（UI 生成）应用程序。这些应用程序中的大多数都是低风险的，只有当需要对应用程序中的数据类型加以控制时，IT 才需要参与。例如，你不会使用会议记录应用程序，但你会使用病人记录应用程序。这些应用程序很少复杂到需要 IT 参与。

下图显示了与其他系统集成的第二类应用程序。这一类别包含潜在风险更高的应用程序。与第一阶段的应用程序相比，在这个阶段 IT 参与的比例更高。如图所示，紫色区域和红色区域较大，而橙色区域较小。

最后这张图显示了涉及重要数据转换功能的第三类应用程序。这个类别包含风险最高的应用程序。IT 参与的比例比第二阶段更大，如图所示，紫色区域更大，而小橙色区域更小。

总结：管理低代码平台的风险

不管你喜不喜欢，社区开发者已经在你的组织中使用 Excel 了，他们即将开始要求使用新一代的低代码平台。我们认为这一趋势势不可挡。你可以与之抗争，或者接受这个不可避免的事实，并拥抱它。如果做得好，在组织中拥有一小群社区开发者可以显著提高你的 IT 能力。

今天，大多数组织的决策者在做商业决策时使用了大量的电子表格，把组织暴露于由此带来的重大的风险之中。如果低代码平台开始取代一些电子表格，并在组织中传播，可以降低公司的整体 IT 风险。

最大化低代码解决方案的可见性是管理风险的关键。为了最大化社区开发者构建应用程序的可见性，我们建议为社区开发者提供一个单一的低代码平台。

你应该采用哪种低代码的解决方案？这可能并不是最重要的。低代码平台的功能基本上没有太大差别——低代码平台能做的事情只有这么多，而且在这一领域的投资水平意味着它们都能做这些事情。因此，如果你心中没有首选的低代码平台，那就使用你的云供应商提供的平台。如果你是微软 Azure 的用户，可以使用 Power Apps。如果你是 AWS 的客户，可以使用 Honeycode。如果你是谷歌的用户，可以使用 Appsheet。

接下来，让你的社区开发者在这个平台上接受培训。一旦他们习惯于使用特定的平台，他们就不太可能要求使用其他平台。只要你为你的用户提供一条出路来满足他们对低代码的渴望，他们就能够完成他们想要完成的事情。

最后，在你的团队中分享一些关于现有 IT 技术栈/云供应商机器学习和数据转换服务的专业知识。当你的社区开发者需要使用机器学习平台时，他们最好使用你已经使用过的平台，这样你就可以更容易地控制数据。

作者简介

Doug Hudgeon 是 Manning 出版的《商业机器学习》(Machine Learning for Business)一书的合著者。该书向用户展示了如何使用 AWS SageMaker 解决现实世界中的商业问题。他也是Managed Functions公司的首席执行官，该公司的使命是将每个业务应用程序与可操作的数据相连接。如果你的组织的业务流程过于复杂或风险太大，可以咨询 Managed Functions 公司，他们可以评估低代码应用程序的风险水平，并构建和维护集成/转换组件。另外，可以在 AWS、Azure 或谷歌云上将组件部署为原生云函数，让你的数据保留在你的环境中。

查看英文原文：

Low-Code Platforms and the Rise of the Community Developer: Lots of Solutions, or Lots of Problems?