软件工程指南
3.8

查看英文版

3.8 互操作性与开放标准

概述与动机

互操作性（interoperability）是指两个或多个系统在无需任何一方了解对方内部运作方式的情况下，交换信息并使用所交换信息的能力。开放标准（open standard）是一种公开可得的规范，通过透明且基于共识的流程开发和维护，并且可以免费（或以公平、合理且非歧视的条件）实施，使任何人都能在无需单一供应商许可的情况下构建符合该规范的系统。为互操作性而设计，意味着构建通过这些共享的、已发布规范互相连接的系统，而不是通过定制集成（bespoke integration）（）即一次性构建、专门链接两个系统的连接器，并且每当任一方发生变化就必须重新构建。

对大型组织而言，互操作性不是锦上添花之物，而是一切其他事物赖以运行的基底。企业会收购公司、更换供应商，并把数十个内部和第三方系统拼接在一起，而开放标准正是让新组件能够插入而无需重写的关键。对政府而言，风险更高。公共服务由众多机构、多层级政府和私营供应商共同交付，没有任何单一主体掌控全局。一名申请福利的公民，可能会接触到由不同部门所拥有的身份、税务、医疗和福利系统。这些系统必须实现互操作，否则服务就会失败。公共机构也会按以年为单位的采购周期更换供应商，因此对任何单一供应商专有接口的依赖，都会变成一个漫长而昂贵的陷阱。

反复出现的失败模式，正是互操作性的反面：专有锁定（proprietary lock-in），即一个组织的数据和流程与某个供应商的非标准格式和接口深度纠缠，以至于日后更换、集成，甚至只是读取数据，都会变得代价高昂到令人望而却步。开放标准是抵御它的主要防线。本章讲述系统必须实现互操作的各个层级、使之成为可能的标准，以及如何为它进行设计、采购和认证。它与 API 和接口设计（第 2.3 章）、分布式系统（第 3.3 章）、数据战略与治理（第 7.1 章）、采购与开源（第 10.3 章），以及合规与治理（第 4.6 章）紧密相连。

关键原则

  • 互操作性是设计出来的，而不是事后补上去的。 在构建之前就决定标准，因为事后补做意味着重写接口、迁移数据。
  • 优先选择开放标准，而不是定制集成。 一个符合规范的接口服务于每一个现有和未来的合作伙伴；一个定制连接器只服务于一个。
  • 互操作性是有层级的。 如果双方对字节所代表的含义（语义层）意见不一，那么把字节传过线路（技术层）就毫无价值。
  • 意义存在于共享词汇表中。 标识符、编码体系和术语体系，才是让交换的数据可用、而不仅仅是可传输的关键。
  • 只有当你真正遵从标准时，它才是真实的。 一句未经一致性测试的”支持 FHIR“，是营销话术，不是互操作性。
  • 锁定是一个总拥有成本的决策问题。 今天便宜的专有方案，往往就是明天昂贵的被困资产。
  • 政府场景放大了这种需求。 公共服务跨越无人能够单独掌控的组织边界，因此开放标准常常是强制要求，而不是一种偏好。

建议

为互操作性的全部四个层级而设计

欧洲互操作性框架（European Interoperability Framework）及相关模型描述了四个层级，一个系统必须满足全部四个层级才能真正实现互操作。技术互操作性（technical interoperability）是管道层面的事情：在系统之间传输字节的网络、协议和传输方式（例如 HTTPS）。句法互操作性（syntactic interoperability）是对结构和格式的一致（）即消息的语法，比如 JSON（JavaScript Object Notation，一种轻量级文本数据格式）或 XML（可扩展标记语言）。语义互操作性（semantic interoperability）是对含义的一致：一个标注为 gender 的字段，或者一个代码 250.00，对双方而言意味着同一件事。组织互操作性（organizational interoperability）是流程、治理、角色和法律协议的对齐：谁被允许在何种数据共享协议下、出于何种目的，向谁发送什么内容。大多数集成项目都能拿下前两个层级，却在第三和第四个层级上失败。应把语义和组织互操作性当作第一等级的设计工作，而不是事后添加的东西。

将数据交换和 API 层标准化

针对系统如何描述和暴露自己的接口，采用开放且被广泛实施的标准。对于 Web API（应用程序编程接口，即一个系统调用另一个系统所依据的既定契约），使用OpenAPI 规范（）一种供应商中立、机器可读的 REST（表述性状态转移）API 描述方式，它既能为接口生成文档，也能生成客户端代码、服务端代码、测试用例和模拟服务（mock）。对于负载格式，优先使用 JSON，因其无处不在且易于人类阅读，在某个生态已经标准化使用 XML 的地方则使用 XML。在你需要服务之间高性能、强类型通信的地方，可以考虑使用 gRPC（一种远程过程调用框架）搭配 Protocol Buffers（Protobuf）（）一种紧凑的、按模式定义的二进制格式，它本身也是一份开放规范。关键不在于具体使用哪种技术，而在于契约是已发布的、机器可读的，并且可被独立实现的。接口设计的更多内容见第 2.3 章。

采用适用于你所在领域的公认标准

大多数行业已经收敛到特定领域的互操作性标准上。应使用它们，而不是自行发明。医疗健康领域是最典型的例子。HL7（Health Level Seven，一个标准组织及其较早的消息标准）在新项目中大多已被 FHIR（Fast Healthcare Interoperability Resources）取代，后者是一套现代标准，把临床概念（患者、观察结果、用药）建模为通过 REST API、以 JSON 或 XML 交换的 Web 资源。在金融领域，ISO 20022 是用于结构化、带有丰富注释的支付和金融消息传递的开放标准，现已被全球各地的支付系统采纳。在地理空间数据领域，OGC（开放地理空间联盟）发布了诸如 WMS 和 WFS 之类的地图与要素服务标准。其他例子还包括用于商务文档的 OASIS 和 UBL，以及用于建筑行业的 IFC（BuildingSMART）。选择公认的标准，就等于买到了一整个由符合规范的工具、供应商和受过培训的员工组成的生态系统。

把意义锚定在标识符、编码体系和本体上

语义互操作性需要共享的词汇表。使用标准标识符（identifier），使同一个真实世界的事物在任何地方都拥有相同的指代（例如一个 ISO 国家代码、一个法人实体的 LEI，或一个国家级患者标识符）。使用已发布的编码体系（code system）和术语体系（terminology，即对编码概念及其定义含义的受控列表），而不是自由文本：临床术语使用 SNOMED CT 和 LOINC，诊断使用 ICD（国际疾病分类），文本则使用 Unicode。在概念之间的关系很重要的地方，使用以 RDF 和 OWL（W3C 网络本体语言）等标准表达的本体（ontology，即一个关于概念及其相互关系的、形式化且机器可读的模型）。这些词汇表的治理是一项数据治理职责；参见第 7.1 章。

通过基于标准的模式而不是点对点连接来集成

优先选择能让集成数量保持线性增长、而不是组合式增长的架构模式。N 个系统若采用点对点连线，最多可能需要 N×(N−1)/2 个定制连接器。而这同样的 N 个系统若各自遵从一套共享标准，则只需要 N 次对该标准的实现。使用网关、已发布的 API 契约和规范化数据模型，使新的参与者只需针对标准集成一次，而不是针对每一个现有系统分别集成。这也是抵御锁定的解药：由于契约是开放的，供应商可以被替换，而无需触碰与它相连的每一方。

要求一致性和认证

只有当各实现真正遵从一套标准时，它才能产生价值。坚持使用已发布的测试套件和验证工具进行一致性测试（conformance testing，即自动检查某个实现是否满足规范的过程）（例如 FHIR 的验证工具和 Touchstone 测试，或者在你的构建流水线中进行 OpenAPI 模式验证）。在存在正式的认证（certification）项目的地方（即由独立机构对一致性进行认定，如各国的健康信息技术认证方案），优先选择已获认证的产品，并在合同中要求认证。把一致性检查嵌入到持续集成中，使偏离标准的情况导致构建失败，而不是在生产环境中才浮出水面。

权衡：优点与缺点

方式优点缺点／成本
开放标准供应商众多，不会被锁定，拥有生态工具，未来的合作伙伴集成成本低标准可能宽泛复杂，采用小众特性较慢，演进节奏受制于委员会
定制点对点集成首次连接速度快，贴合度高，前期学习成本极低成本随连接数量呈组合式增长，脆弱，每次变化都要重做，滋生锁定
专有供应商格式／API功能丰富，有供应商支持，在单一生态内起步快锁定，切换成本高，日后难以导出数据，定价权转向供应商
领域标准（FHIR、ISO 20022）含义共享，员工经过培训，与监管机构对齐学习曲线，迁移旧有数据，版本和配置文件（profile）管理开销

核心权衡在于短期便利与长期可选性之间。定制或专有集成对第一次连接而言，几乎总是搭建得更快，这正是组织之所以会在一次次”合理”的决策中逐渐滑入锁定的原因。开放标准把成本前置（学习规范、迁移现有数据、构建一致性测试），并在每一次新的合作伙伴、供应商或系统加入而无需重写时收回这笔投入。对于生命周期长、参与方众多的系统而言（）这几乎描述了每一个企业和政府平台（）基于标准的路径会决定性地胜出。对于一个真正一次性的一对一链接，定制方案或许是理性的。真正的错误，是把长期存续的平台当作一次性链接来对待。

与团队讨论的问题

  1. 你的技术集成所依赖的组织互操作性（数据共享协议、同意模型和流程对齐）由谁负责？ 大多数项目都能拿下技术层和句法层，却在组织层停滞不前：字节抵达并被成功解析，但没有任何协议规定谁可以出于什么目的、在什么同意机制下，向谁发送什么内容。在政府场景中，一位公民的数据会跨越各自拥有系统、依据不同法律依据行事的多个机构，因此一个完美的 FHIR 接口，在共享协议和同意模型建立之前是毫无价值的。带上你最重要的一次跨边界数据交换，说出双方各自的法律文书和负责人姓名，而不仅仅是 API。如果这个负责人叫不出名字，那么这次集成即便通过了每一项技术测试，依然会在生产环境中被卡住。应把这些协议当作与消息模式同等严谨的设计工件来对待。

  2. 你在多大程度上依赖某个标准的专有扩展？另一个符合规范的实现是否仍能与你对话？ 标准都留有逃生舱口，而过度使用它们，实际上就是披着开放外衣的事实锁定：你声称支持 FHIR 或 ISO 20022，但没有任何独立供应商能真正与你的”方言”互操作。这种情况是通过一次次看似合理的定制逐渐蔓延的，因此大型资产体系应该有意识地对其进行度量。带上一条真实消息，数一数它的含义有多少承载在标准字段上，又有多少承载在自定义扩展上；自定义占比越高，你的可移植性就越弱，现有供应商的定价权就越强。应优先在标准规则范围内做配置（profiling），并把发现的空白反馈回标准本身，而不是私自扩展。开放路径的全部意义，就在于供应商可以被替换而无需触碰与之相连的每一方，而扩展正在悄悄侵蚀这一点。

  3. 每一套标准你使用的是哪个版本、哪个配置文件（profile）？在整个资产体系中，由谁来治理这个选择？ “支持该标准”这句话如果缺乏版本和配置文件的纪律约束，就毫无意义，因为两个系统都可以声称支持 FHIR 或 ISO 20022，却仍然因为实现的版本或配置文件不同而无法对话。在一个拥有众多供应商、采购周期漫长的大型组织中，版本会在无声无息间逐渐分叉，直到某次集成崩溃。带上一份每一个接口的清单，列出其标准、版本和配置文件，并说出谁对保持它们对齐、规划升级负责。把版本和配置文件的检查嵌入到流水线的一致性测试中，使偏离行为导致构建失败，而不是在生产环境中浮现。没有这种治理，名义上符合规范的系统依然无法互操作，而这恰恰是开放标准本应防止的失败。

  4. 当一份合同或一个供应商声称”支持该标准”时，究竟由哪项独立测试来证明这一点？这项测试又在哪里运行？ 一个没有测试支撑的一致性声明就是营销话术，而它会在最糟糕的地方失败：在生产环境中，在资金已经易手、系统已经上线之后。对于从众多供应商处采购的大型组织而言，诱惑在于接受问卷上打的一个勾，因为坚持要求经过验证的一致性会拖慢采购流程、缩小投标人范围。带上你所依赖的每一套标准的已发布验证工具或测试套件（例如 FHIR 验证工具和 Touchstone，或 OpenAPI 模式验证），一批跑过该工具的真实消息样本，以及合同中把验收和付款与通过测试挂钩的条款。这里相互拉扯的力量是速度与证据：一款已获认证的产品可能价格更高、接入耗时更长，但一款未经验证的产品会把失败转嫁给你的集成团队。在存在国家级健康信息技术或支付认证方案的政府和受监管场景中，应在合同中要求认证，并把验证工具接入持续集成，使偏离行为导致构建失败，因为一个你从未测试过的断言，将会成为你在审计或故障期间才发现的一项负债。

  5. 你有多少集成仍是点对点的？维持这种现状的真实组合式成本是多少？ 定制的一对一连接器对于第一条链接而言是构建速度最快的方案，却是在整个资产体系中拥有成本最高的方案，因为其数量会向 N×(N−1)/2 增长，而一套共享标准只需要 N 次实现。在大型组织中，这种蔓延是通过一次次看似合理的决策逐渐累积的，直到集成地图变得无法维护，每一次系统变更都会波及十几个脆弱的连接器。带上一份按点对点与基于标准分类的集成清单、你上一次重大系统替换所触及的连接器数量，以及维护定制链接所耗费的工程时间估算。这里的张力在于，把现存的点对点连线迁移到网关或规范模型之后，是一项没有即时功能收益的真实工作量，因此除非有人量化其承载成本，否则它在路线图上总是会输给别的项目。对于要存续数十年、并持续增加参与方的企业和政府平台而言，点对点路径是一种缓慢的税负；应为集成架构指定负责人，并制定一份让新参与者通过标准接入、而不是对接每一个现有系统的计划。

  6. 在哪些地方，你正在用自由文本传达本该由已发布编码体系或术语体系承载的含义？这些词汇表由谁治理？ 语义互操作性正是大多数集成悄然失败的地方：字节抵达并被成功解析，但一个以不受约束的字符串存储的诊断、货币或国家，对发送方是一个意思，对接收方却是微妙不同的另一个意思。对大型组织而言，这种成本是不可见的，直到报表、分析，或监管机构揭露出同一个概念在三个系统中被编码成了三种不同方式。带上目前以自由文本保存的字段示例、可以替代它们的标准标识符和编码体系（临床数据使用 SNOMED CT 和 LOINC，国家和货币使用 ISO 代码，法人实体使用 LEI），以及这些自由文本所掩盖的错误率或对账工作量。相互制约的考量在于，把旧有数据映射到受控词汇表是一项繁琐、且永远无法拿来做演示的工作，因此相较于传输层，它长期资金不足。在政府场景中，一位公民的档案是由众多独立系统拼凑而成的，一个不匹配的编码可能导致福利被拒或健康记录受损，应把词汇表治理当作一项被明确指定的数据治理职责（第 7.1 章），而不是留给各团队自行处理的实现细节。

行业视角

初创企业。 速度制胜，而开放标准正是一支小团队无需构建大量连接器就能触达众多客户的方式。使用每个合作伙伴都已支持的格式（登录用 OAuth，日程用 iCalendar，事件用 webhook，负载用基于 OpenAPI 契约的 JSON），这样一次集成就能触达成千上万的客户，更换供应商时也只需改动一个适配器。避免自创格式或为每个客户的技术栈手工连线；那将是你未来无力维护的负担。标准化路径前期成本略高，但在一个你尚无法预测的市场中，能让日后的切换保持廉价。

小型企业。 由于没有集成专家、预算又紧张，应把互操作性当作一项采购决策，而不是一个构建项目来对待。优先选择已经支持你所在行业开放标准、并暴露有文档的 API 的工具，这样即便你更换供应商，数据依然可移植。在签约之前，先问一问意向供应商，如何以何种格式取出并导入你的数据，因为今天便宜的专有方案就是明天被困的资产。你自己几乎不会去运行一致性测试，因此应依赖已获认证或被广泛互操作的产品。

企业。 挑战在于跨众多团队、供应商和漫长采购周期治理互操作性。应强制要求使用领域标准（FHIR、ISO 20022、OGC）和一份已发布的 OpenAPI 契约，然后维护一份每个接口及其版本、配置文件和负责人的清单，以免名义上符合规范的系统逐渐分道扬镳。让新参与者通过网关和规范模型接入，而不是点对点连线，把一致性验证接入持续集成，并度量你有多少流量承载在标准字段上、又有多少承载在专有扩展上。把锁定和可移植性当作一项经过深思熟虑的总拥有成本立场来管理，而不是任其自然发生。

政府。 开放标准常常是强制性要求，因为公共服务跨越了没有任何单一主体能够掌控的多个机构，而供应商会按多年周期更换。应在每一份合同中要求一致性测试，并在存在相应方案的地方要求国家级认证，同时要求数据可移植性，使一个即将退出的供应商无法挟持公众的数据。把含义锚定在国家标识符和已发布的术语体系上，使一位公民的档案在各部门之间意味着同一件事，并通过明确的数据共享协议和同意模型、由指定的负责人来处理组织互操作性。透明度和公共财政利益都支持开放、可独立实现的路径，而不是任何专有的便利。

示例

初创企业。 一家构建团队生产力应用的小型初创企业，通过开放标准而不是定制连接器，与客户已有的工具对接：登录使用 OAuth，日程使用 iCalendar，事件使用 webhook。由于它使用的是每一个日历和身份提供方都已支持的格式，一次集成便能触达成千上万的客户而不是一个，日后更换支付或邮件供应商时也只需改动一个适配器。假如它为每个客户的技术栈手工构建了定制链接，那么每新增一个客户，都意味着要再编写并维护一个连接器。

企业。 一家跨国银行通过从旧有的专有消息格式迁移到 ISO 20022，实现了跨境支付的现代化。由于该标准承载的是结构化、带有丰富注释的数据（付款方、收款方、用途、监管字段），而不是自由文本，下游用于欺诈筛查、对账和报表的系统所消费的是一种统一的规范格式，而不是十几个定制解析器。当这家银行后来更换支付网关供应商时，新的供应商已经支持 ISO 20022，因此这次切换只触及网关本身，而不涉及其背后的上百个系统。开放标准把一次供应商迁移，从一场耗时多年的重建变成了一次可控的替换。

政府。 一个国家医疗服务体系需要让医院、诊所、实验室，以及一款由不同供应商在二十年间构建的面向患者的应用，安全地共享记录。它强制要求数据交换使用 FHIR：每个系统都以 FHIR 资源的形式，通过 REST API 暴露患者、观察结果和用药数据，并使用标准标识符（一个国家级患者 ID）和临床术语体系（病情用 SNOMED CT，化验结果用 LOINC），使这些编码在任何地方都意味着同一件事。供应商必须通过 FHIR 一致性验证，并持有国家级健康信息技术认证，才能接入。一个新的诊所系统只需针对 FHIR 标准集成一次，而不必为每一个既有系统分别构建定制链接，一位公民也能查看一份由众多独立系统拼合而成的统一记录。组织互操作性通过数据共享协议来处理，规定谁可以出于何种原因访问什么内容，以满足合规义务（第 4.6 章）。

商业论证：动机、投资回报率与总拥有成本

支持开放标准的财务论据，是一个关于系统整个生命周期内总拥有成本（TCO）的论据，而不是关于第一次集成标价的论据。定制集成的成本随连接数量增长，并且每次变更都要再付一次。基于标准的集成成本，每个参与方只需支付一次，并分摊到整个资产体系中。投资回报率（ROI）体现在集成人力的减少、新合作伙伴和供应商接入速度的加快、供应商表现不佳时切换成本的降低，以及避免经典的锁定税（）即唯一供应商因为没有竞争对手能够竞标而提高价格。

对领导层而言，应围绕可选性和竞争来构建这一论据。开放标准让采购保持竞争性（第 10.3 章）。当接口是公开且经过一致性测试的，多个供应商就能在平等条件下竞标，这会在连续几轮合同中压低价格、提高质量。它们也为未来去风险，因为监管变化、并购和现代化项目在数据和接口可移植的情况下都会变得更便宜。忽视标准所隐藏的最大成本，是最终被迫进行的迁移：在原供应商已经不存在或不予配合的情况下，事后从专有格式中提取数据，其代价通常是若基于标准进行设计所需前期成本的许多倍。各国政府越来越认识到这一点，因此明确强制要求使用开放标准，正是为了在数十年的时间里保护公共财政不受锁定之害。

反模式与陷阱

  • 把技术互操作性误当作全部工作。 消息抵达并被成功解析，但双方对某个字段的含义意见不一，导致数据在悄无声息间出错。
  • 名义上”基于标准”。 一款产品声称支持某个标准，却从未通过一致性测试，在实践中已经偏离标准。
  • 在存在编码体系的地方使用自由文本。 把诊断、货币或国家以不受约束的字符串存储，摧毁了语义互操作性。
  • 吞没标准的专有扩展。 过度使用某个标准的逃生舱口，以至于没有任何其他实现能够与之互操作：这是披着开放外衣的事实锁定。
  • 点对点蔓延。 每次都多加一个定制连接器，直到集成地图变成一团无法维护的组合式混乱。
  • 版本和配置文件的混乱。 对正在使用哪个版本或哪个配置文件的标准缺乏治理，导致名义上符合规范的系统依然无法互相对话。
  • 忽视组织互操作性。 完美的技术交换却因为不存在数据共享协议、同意模型或流程对齐而被卡住。
  • 自造标准。 在一套成熟且已被采纳的领域标准已经存在的情况下，还去发明一种定制格式，并从此永远背负它的维护成本。

成熟度模型

  • 第一级，启动： 集成是临时性的、点对点的。格式是专有或无文档记录的。含义靠自由文本和口耳相传的经验来传达。更换任何系统或供应商都是一个重大项目。锁定现象普遍存在，且大多不被察觉。
  • 第二级，发展： 出现了 JSON 或 XML 等通用格式，部分 API 有了文档，但实践因团队而异。互操作性大多仍停留在句法层面；语义上的一致并不统一，因项目而异。标准的选择是被动反应式的，一致性被断言但未经测试。
  • 第三级，标准化： 开放的数据交换标准（OpenAPI，以及相关的领域标准，如 FHIR 或 ISO 20022）被形成文档并在全组织范围内强制执行。共享的标识符、编码体系和术语体系提供了语义互操作性。一致性测试成为交付流水线的一部分，集成遵循基于标准的模式，而不是点对点连线。
  • 第四级，管理： 互操作性被对照基准进行衡量和控制。相关指标被跟踪和评审：基于标准与点对点集成的比例、承载在标准字段与专有扩展上的消息含义占比、流水线中一致性测试的通过率、整个资产体系中的版本和配置文件偏移，以及接入一个新参与者所需的集成前置时间和缺陷率。版本和配置文件受到治理，供应商被要求并被核实取得认证，锁定风险被量化，而不是凭感觉判断。是否采用、升级或淘汰某个接口的决策，均基于这些证据做出。
  • 第五级，编排： 互操作性在整个组织中被持续改进和整合。组织互操作性（协议、同意、流程对齐）与技术层面一起被系统性地处理，组织会向自己所依赖的标准回馈贡献，可移植性是一项永久性的设计约束。随着标准演进、参与方的加入或退出，整个资产体系不断调整，基于已度量的证据而不是事故，重新平衡集成架构和词汇表治理。

讨论议题

  1. 对于你最关键的数据交换而言，在四个层级（技术、句法、语义、组织）中，今天最薄弱的是哪一个？
  2. 如果你的主要供应商在续约时把价格翻倍，切换需要多长时间、花费多少？是什么导致了这一点？
  3. 你的哪些集成仍是点对点的？要把它们迁移到一套共享的开放标准背后，需要做些什么？
  4. 你在哪些地方存储着本可以用已发布编码体系或术语体系替代的自由文本？这些自由文本掩盖了哪些错误？
  5. 你合同中的”支持该标准”是否要求通过独立的一致性或认证测试？还是仅仅是一句断言？
  6. 有哪些开放标准强制要求（国家级或行业级）已经适用于你？你是真正满足了它们，还是只是声称满足？

关键要点

  • 互操作性意味着使用所交换的信息，而不仅仅是传输它；应为全部四个层级而设计：技术、句法、语义和组织。
  • 优先选择开放的、已发布的、可独立实现的标准，而不是定制集成和专有格式，后者会滋生锁定和组合式成本。
  • 将 API 和数据交换层标准化（OpenAPI、JSON/XML、gRPC/Protobuf），并采用你所在领域公认的标准（医疗领域的 FHIR，金融领域的 ISO 20022，地理空间领域的 OGC）。
  • 把含义锚定在共享的标识符、编码体系、术语体系和本体上；语义互操作性正是大多数集成悄然失败的地方。
  • 要求一致性测试，并在可行之处要求认证；只有当各实现被证明确实遵从标准时，标准才是真实的。
  • 依据系统整个生命周期内的总拥有成本和可选性来判断这一选择；对于长期存续、多方参与的平台（几乎所有企业和政府系统皆是如此），开放标准胜出，而政府正日益将其列为强制要求。

参考文献与延伸阅读

  • HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
  • ISO 20022, Universal financial industry message scheme (iso20022.org)
  • OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
  • Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
  • European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
  • UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
  • W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
  • SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
  • gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
  • NIST and IEEE literature on systems interoperability and conformance testing