加速数字化转型：深度解析 API 成熟度模型

如果数字化转型得当，可以影响一个组织的各个方面。然而，API 成熟度成为数字化转型需要解决的一个常见的问题。API 是推动业务增长的桥梁，但随着 API 被广泛使用，可能会出现 API 蔓延。在解决日常业务问题的过程中，没有计划和管理的 API 激增会导致 API 蔓延。API 蔓延说明有大量的 API 正在被创建，部署 API 的分布式基础设施也在发生物理扩散。

公司看到他们的 API 正以前所未有的速度在全球范围内蔓延。对于希望在分布式基础设施之间保持高质量和卓越体验的组织来说，API 蔓延给他们带来了一个独特的挑战。

管理大规模的 API 需要自上而下的监督，它还需要一种实用的方法，并从旨在统一 API 的 API 程序计划开始。程序应该将 API 打包成产品或服务来推动 API 的采用，并促进对其整个生命周期的管理。问题在于，创建一个可行的程序来管理 API 成熟度是一个缓慢的过程。

本文将为构建成熟的 API 计划提供一个框架，这个框架使用了一个可以促进 API 驱动业务演化的四层 API 程序成熟度模型。

什么是 API 成熟度模型

关于 API 的成熟度和生命周期，我们可以用两个阶段来描述：API 成熟度和 API 程序成熟度。

API 成熟度与设计和开发相关，遵循的过程与软件开发成熟度一致。API 成熟度确保 API 符合公认的 API 规范，比如 REST。在讨论 API 成熟度时，你讨论的是为特定应用程序或目的而创建的一组 API。

API 程序成熟度主要是从整个公司层面来看的，即公司为满足各种业务目标而积累的大量 API。对于 API 程序成熟度来说，将 API 构建成统一的服务是有必要的。API 程序成熟度模型为通过简化 API 来促进业务创新提供了基准。

API 程序成熟度模型

API 程序成熟度从技术和业务的角度评估 API 的非功能性指标。API 的技术指标包括性能、安全性、体验和可伸缩性。API 的业务指标与间接影响时间和成本的流程和生产力的改进有关。

与其他业务流程一样，API 程序也应该从小处开始，然后逐渐演化。API 程序的结构必须能够遵循持续的改进周期。指标应该随着 API 程序从较低成熟度级别过渡到较高成熟度级别而得到改进。

在开始你的 API 成熟度模型之旅之前，你必须首先将 API 视为一种工具。然后，在模型的演进过程中，随着达到更高的成熟度级别，你需要基于 API 为日常业务所带来的能力将其视为组件、模型或生态系统。

API 程序成熟度的四个级别

如果你将 API 程序成熟度视为企业数字化转型整体方法的一部分，API 程序可以分为四个成熟度级别：

级别 1：“API 的暗黑时代”——API 作为数据采集工具

从历史上看，构建 API 是为了方便数据采集，Salesforce 和 Amazon 的早期 API 就是最好的例子。这类 API 的主要目的就是用于标准化跨多个业务应用程序的数据共享。

API 程序成熟度的第一个级别是为可以提供单一事实来源的数据采集创建标准化的数据访问接口。这些 API 按照不同的业务功能分类。例如，你可以有分别用来访问财务、销售、员工和客户数据的 API。

当你建立了 API 设计和架构最佳实践，你的组织就达到了 API 程序成熟度级别 1。一些最佳实践包括：

• 在设计 API 时要考虑到集成便利性和可重用性；

• 所有的 API 都保持一致的接口；

• 在设计中结合版本控制，同时支持多个客户端；

• 确保 API 的可伸缩性，适应不断变化的用户需求。

这些 API 相对简单，不需要高级的可编程功能。级别 1 也可以定义为一种相对不成熟的、手动的 API 部署方法。手动部署的个体 API 不支持 API 生命周期管理，技术的重点放在了将 API 构建为独立的工具上。

级别 2：“API 的复兴时代”——API 作为流程集成组件

回顾 API 的发展历史，从 2000 年代开始，当它们开始被用作连接器来集成不同的系统时，迎来了它们的复兴时代。单点登录（SSO）就是一个典型的例子。SSO 时一种被广泛使用的 API 集成工具，用于对用户进行身份验证，让用户能够安全访问多个应用程序和第三方服务。

当你的组织达到 API 程序成熟度级别 2 时，你的 API 程序将使用基于组件的方法。应用程序被分解为单独的组件，每个组件都可以独立于应用程序的其他部分进行开发和测试，然后再集成成一个完整的应用程序。这种方法降低了复杂性，易于维护，并提高了可伸缩性。

API 将作为集成不同业务和特定领域流程的组件捆绑在一起。这些 API 包简化了运营和工作流，将多个部门连接起来，甚至可以集成与外部合作伙伴的工作流与交互。

当你达到级别 2 时，你的组织就迈出了将 API 应用于业务的第一步。在级别 2，API 被视为组件，为你提供了标准化和可重用的 API 目录。级别 2 通过 CI/CD（持续集成/持续交付）管道实现标准化和自动化，改进了开发周期，从而推进了 API 开发和生命周期管理。

级别 3：“API 的启蒙时代”——API 作为统一体验的平台

在 API 复兴时代，API 被视为组件，以此来简化集成和提升可重用性。级别 3 是 API 的启蒙时代，它更进一步，让 API 变得对用户更加友好和有价值。

当你达到级别 3，API 就不再被视为改进业务工作流的组件或独立的工具。这一级别关注的是构建 API 套件，通过创建互连的体验来驱动更好的工作流程。API 组件的作用在于，API 提供者可以在设计和构建 API 时对应用程序进行分解。而 API 套件的作用在于，API 提供者可以对功能进行分组，让 API 消费者可以与它们集成，从而获得更好的体验。

例如，物流公司依靠卡车和送货车车队来维持业务的连续性。它可以使用 API 套件来监控和管理其车队的各个方面。在级别 3，你需要一个精心设计的包含多个 API 的 API 套件来监控卡车、绘制路线、提供性能分析，等等。

在级别 3，API 是用户体验（UX）的关键。API 套件成为面向用户的应用程序的支柱。在上面的卡车车队示例中，公司用于车队管理的前端软件依赖于 API 来驱动最终的用户体验，因此 API 套件成为为整个软件包提供接口的后端平台。

当你达到了级别 3，API 程序将起着至关重要的作用，因为 API 套件成了任务关键型的服务。在这个阶段，API 消费者做了大量的投入，API 的可靠性和成熟度就变得非常重要。处于级别 3 的 API 程序都达到了一定程度的技术成熟度，包括：

• 部署：API 套件进行批量部署，与 API 生命周期阶段和版本控制紧密结合。

• 性能：API 支持云原生环境，可以获得更好的可伸缩性和弹性工作负载。

• 安全性：启用多层安全机制，确保严格的认证和授权过程。

• 自动化：CI/CD 管道是完全自动化的，包含了严格的 API 测试。

• 体验：自助式 API 门户有助于开发人员快速上手。

级别 4：“API 的自由化时代”——API 作为业务转型的生态系统

当你的组织达到了 API 程序成熟度级别 4 时，你将拥有完全外部化的 API。API 演进的最后阶段更多地是由业务需求而不是技术驱动的。在这个级别，你可能已经有了一个运行良好的技术栈，并且正在推动内部和合作伙伴采用 API，因为 API 带来了很多业务价值。下一个合乎逻辑的进程是通过货币化将这种价值外部化。

在级别 4，你将采用一种新的方法——API 即产品。在这个级别，你可以通过服务订阅模型向客户提供 API。API 即产品可以作为独立服务或补充服务来提供，具体根据公司的业务性质来决定。无论采用哪种方式，API 都紧密集成到了你的产品、营销和销售中，因此每个人都可以通过协作来推动这种新兴的价值流。

在级别 4，API 程序成为业务增长的引擎。是否已经达到级别 4 的一些指标包括：

API 治理

你有一个专门的 API 产品管理小组。这个小组确保所有 API 都是基于一组预定义的规则开发的。它还定义了 API 生命周期进展策略，确保 API 具备架构和安全合规性。

API 可观测性

你的团队不仅能够对 API 进行监视，还能够捕获 API 业务逻辑的内部状态，收集与性能有关的数据。

API 生态系统

你建立了一个 API 社区，让开发人员和消费者有交换意见和寻求支持的地方。API 论坛进一步增强了 API 生态系统，推动 API 的采用。

API 程序改进周期

这个世界上没有完美的 API 程序。任何一个 API 治理框架都必须进行定期审计，确定 API 程序的当前成熟度级别。

无论处于哪一个 API 成熟度级别，采用 DevOps 方法并通过持续的小 Sprint 来提高 API 成熟度都是必要的。要采用 DevOps 方法，需要在组织范围内建立共识，实现更敏捷、更快的小增量改进周期。

理想的 API 程序改进周期包括五个阶段。

评估和探索

第一个阶段是在技术和业务层面评估 API 程序的当前状态，并探索改进它的可能性。当然，技术成熟度要先于业务成熟度，应该是级别 1 和级别 2 的核心关注点。

在探索需要改进的领域时，可以设定一些小目标，而不是试图从一个级别直接跳到下一个级别。你可以在内部定义子级别，改进 API 程序的某个特定方面，例如部署自动化、安全性或可伸缩性。

设计与建议

第二个阶段是改进周期中最关键的决策点。在这个阶段，你需要梳理来自不同利益相关者的技术规范和业务目标。然后，你可以建议对底层 API 管理技术栈做出修改，这些修改应该是当前改进周期的一部分。

构建与实现

第三个阶段是改进周期的实现阶段。这个阶段包含了基于建议的开发和配置增强。

测试与监控

在第四个阶段，你开始通过测试来驱动 API。在这个阶段，你通过监控重要的性能和改进指标来判断 API 改进周期的总体有效性。这个阶段可能会很长，因为你需要在第三阶段和第四阶段之间来回转换，直到可以从指标上看到可度量的改进。

启动新的 API 程序

一旦完成了测试和监控阶段，并且看到了真正的改进，就来到了最后一个阶段——生产部署。在这个阶段，你将新的 API 程序产品化，并启动和运行它们。

如何提升你的 API 程序成熟度

这里给出的不同级别的 API 程序成熟度提供了一条带有逻辑里程碑的清晰路径，帮助你的组织从低级别 API 实现过渡到高级 API 实现，但这里还有一个更重要的挑战需要你去解决。

API 程序象征着组织范围内采用其他 API 的氛围。将 API 的发展定位成推动业务增长的主要引擎之一，这是一个理想的愿景。然而，要让 API 程序取得成功，必须将其构建成横向的跨部门和团队的功能。

在大多数企业中，每一个部门都需要其他部门的清晰度和可见性，这也是为什么需要大量工作来执行治理和标准化的原因之一。缺乏可见性会增加创建重复 API 的可能性。

孤立的 API 团队可能会带来一些挑战，例如缺乏沟通、理解和可见性。彼此孤立的团队为建立 API 开发集成策略带来了挑战。此外，每个团队可能有不同的优先级，导致整个过程出现延迟和错误。此外，团队彼此孤立会导致协作和知识共享的机会变少，而这些本来可用于提高正在开发的 API 的质量。

横向的 API 程序功能跨越了这种部门间的孤岛，有助于确保 API 的统一治理和标准化。

以下是一些你可以用来应对持续改进周期挑战的规则。

由外而内建立共识

由外而内的方法需要对业务工作流进行分析，围绕它们设计出正确的数字体验。与由内而外的方法相比，由外而内的方法在捕获各种利益相关者的期望方面要有效得多。

自上而下的文化转变

寻求推动全公司文化转变的最佳实践是一个极具争议的话题。由于成功的 API 程序需要水平对齐，因此采用自上而下而不是自下而上的方法可以降低出现 API 蔓延的可能性。

自上而下的 API 开发方法有几个优势，例如缩短发布时间、缩短开发周期和更容易维护。它还为 API 架构提供了更大程度的清晰度，使得开发人员能够更容易地知道他们必须做些什么以及他们在整个项目中的职责。此外，自上而下的方法可以减少与 API 安全性、可靠性和文档相关的工作量。

战略观点

API 程序成熟度的初始级别是将 API 视为技术工具包的一部分。记住，这是一种短期的战术视角。随着 API 程序的不断发展，必须不断努力构建战略愿景，让 API 程序带来可通过业务级 KPI 来度量的价值。

达到最高的 API 程序成熟度级别需要时间和精力，同时还要管理利益相关者的期望。但不管怎样，开发成熟的 API 程序将为加速业务创新和增长带来新的机会。

作者简介：

Darshan Shivashankar 是 APIwiz 的创始人兼首席执行官。APIwiz 是一个低代码 API 运营平台，旨在通过简化 API 生命周期管理来提高生产力和实现大规模治理。他有 12 年帮助企业进行数字化转型的经验。他曾为电信、医疗保健和金融行业的大型企业领导和实现 API 程序。

原文链接：

https://www.infoq.com/articles/api-maturity-model/

相关阅读：

API 设计评审已死，API 设计评审万岁

API 网关和负载均衡器，到底怎么选？