云信息模型

欢迎使用 CIM，这是一个与应用程序无关的数据模型，它可以简化集成并加速创新。

关键要点

• CIM 是一种开放的、与应用程序无关的数据模型 —— 这是一个关于业务概念（客户、订单、产品等）的共享词汇表，允许不同的云端和本地系统交换数据，而无需定制的点对点映射。
• 它的存在是为了解决一个特定的、昂贵的问题： 每个应用程序都自带一套数据模型，导致集成团队最终不得不编写和维护脆弱的自定义转换代码，从而减慢了创新速度。
• 它作为一个开放标准进行治理，由一个联盟制定，并在 Linux 基金会旗下的联合开发基金会（Joint Development Foundation）下开源 —— 因此任何人都可以贡献、审查和采用它。
• 内容按主题区域（Subject Areas，即域）组织，每个主题区域代表一个主要的业务概念，其设计以多种格式发布，包括示例图表。
• CIM 是一个模型，而不是一个产品。 它定义了含义和结构；您仍然可以选择如何在自己的系统中映射、存储和移动数据。

数据互操作性的新标准

CIM 由一个开放联盟创建，旨在提供一种基于标准的解决方案来连接企业产品。借助 CIM，您可以跨云原生应用程序创建无缝且量身定制的个性化体验。

为了加速数字化转型并为每个渠道的客户提供个性化参与，许多公司采用了多种云端和本地应用程序。每个应用都自带一套数据模型，这迫使开发人员构建、测试和管理必要的自定义代码，以便在不同系统之间映射和转换数据。这一过程非但没有加速数字化转型，反而减慢了创新速度并导致集成变得脆弱。

CIM 是一种现代的开放规范，有助于减轻集成数据的痛苦。CIM 提供了一个定义的标准，以便在不同的数据格式之间轻松通信。作为联合开发基金会（隶属于 Linux 基金会）的一部分开源，我们欢迎任何和所有贡献者。

为什么特定于应用程序的数据模型会失效

CIM 解决的核心问题并不是某个单一应用程序的数据模型不好。大多数模型在其自身边界内都是完全合理的。问题在于当你连接许多此类系统时，会发生组合爆炸。

考虑一个典型的企业技术栈：一个 CRM、一个 ERP、一个营销自动化平台、一个支持台、一个数据仓库以及一些业务线 SaaS 工具。如果每个系统对“客户”、“账户”、“订单”和“产品”都有自己的定义，那么每对需要共享数据的系统都需要一套自己的映射。集成的数量大致随系统数量的平方增长，且每个映射都是一段微小的、缺乏文档且无主逻辑，必须由某人永久维护。

Related: Fivetran — The fully managed ELT pipeline that just keeps running.

对于任何从事过集成实践的人来说，这些症状都很熟悉：

• 语义漂移。 CRM 中的“客户”是指计费实体；而在支持台中，它指的是提交工单的人。同一个词，两种含义，由一个没人记得是谁写的映射在默默地调和。
• 脆弱的管道。 供应商重命名了一个字段或更改了一个枚举值，导致 ETL 作业在凌晨 2 点失败，因为映射是针对旧结构硬编码的。
• 重复劳动。 两个团队在相同的两个系统之间独立构建了几乎相同的转换逻辑，因为没有一个共享的参考标准可以指向。
• 数据导致的供应商锁定。 迁移出某个平台的成本昂贵，不是因为软件本身，而是因为与该模式绑定的累积转换逻辑。

共享的、与应用程序无关的模型从根源上解决了这个问题：不再是 N 对 N 的映射，而是每个系统仅映射一次到通用模型，由通用模型承载含义。

“与应用程序无关”的实际含义

有必要精确定义其设计理念，因为“无关（agnostic）”这个词经常被宽泛地使用。

Our pick: Workato — Automation-led iPaaS that business teams can actually build on.

与应用程序无关的模型不属于任何单一供应商的产品，也不为其优化。它使用领域专家可以识别的术语（如客户、订单、产品、位置）来描述业务概念，而不是使用镜像某个应用程序内部表的术语。这种中立性使其成为了一个有用的“枢纽（hub）”：参与者无需采用竞争对手的世界观即可实现互操作。

这与其他中立交换标准背后的架构直觉相同。正如资源描述框架 (RDF) 和 schema.org 为 Web 提供了描述事物的共享词汇表，正如 EDI 和后来的 UBL（通用商业语言，一项 OASIS 标准）为供应链提供了共享的交易格式，CIM 旨在为企业应用程序的核心业务实体提供共享词汇表。区别在于范围和现代性：CIM 针对的是互联的、API 驱动的、云端与本地共存的世界，而非批处理文件交换。

一个有用的心智模型是企业集成中的**规范数据模型（canonical data model）**模式，该模式在 Gregor Hohpe 和 Bobby Woolf 的《企业 集成模式》一书中被推广。实际上，CIM 就是一个协作维护的规范模型 —— 即枢纽-辐射（hub-and-spoke）集成拓扑中的“枢纽” —— 但它是一个开放的、版本化的且跨组织共享的模型，而非在一家公司内部私下发明的。

CIM 的组织方式：主题区域和域

协作定义的内容被组织成域，或称为主题区域（Subject Areas）。每个主题区域代表一个主要的业务概念。每个领域的 CIM 设计都有多种格式可用，包括示例图表。主题区域的数量和范围将随着联盟的发展和贡献而增长。

在实践中，这意味着您应该将 CIM 视为一个相关模型的库，而不是一个单一的庞大模式。典型的主题区域围绕可识别的业务关注点聚集 —— 例如，参与方和账户、产品和目录、订单和交易，以及将它们联系在一起的关系。由于每个区域都发布了图表和机器可读的定义，不同的团队可以在不同时间采用不同的区域，而无需等待整个模型全部完成。

这种结构带来了一些实际影响：

Related: Matillion — Push-down ELT built for cloud data warehouses.

• 渐进式采用。 您不需要在第一天就将整个企业映射到 CIM。从痛点最深的主题区域（通常是客户或订单域）开始，然后逐步扩展。
• 扩展而非分叉。 当 CIM 缺乏您需要的概念时，该开放模型设计为可扩展的。贡献扩展回原模型优于维护私有分叉，因为分叉会导致漂移并失去互操作性的优势。
• 将图表视为文档，而非事实来源。 示例图表是给人类看的；机器可读的定义才是您的工具应该消费的内容。

集成环境中的 CIM：如何决策

CIM 是降低集成复杂性的多种方案之一。做出正确选择需要将工具与问题相匹配。下表对比了企业数据架构师通常权衡的主要方法。

方法	定义	最佳适用场景	主要权衡
点对点映射	在两个系统之间直接翻译的自定义代码	仅有两个系统，模式稳定，短期需求	无法扩展；N 对 N 爆炸；脆弱
规范模型（如 CIM）	每个系统仅映射一次的共享中立模型	多系统、跨供应商、长期集成	前期建模工作量；需要治理
供应商 iPaaS 连接器	来自集成平台的预构建连接器	常见的 SaaS 组合，速度优先于控制	连接器特定的语义；潜在的锁定
行业交换标准 (EDI, UBL, HL7 等)	特定领域的标准消息格式	受监管或成熟的垂直行业	范围狭窄；通常面向批处理
数据虚拟化 / 联合	跨源查询而无需集中化	分析类、以读取为主的访问	本身无法解决语义冲突

决策启发式很简单：如果您有多个系统必须就共享实体的含义达成一致，且这些系统来自不同的供应商，那么规范模型将物有所值。 如果您只有两个系统且不打算增加，点对点映射即可。如果您的需求纯粹是分析性和只读的，联合（federation）可能足够 —— 但请注意，联合只是转移了语义问题而非解决了它。

CIM 是对其周围工具的补充，而非替代。ETL 或 ELT 管道（使用 Apache Airflow、dbt 或商业平台构建）仍然负责数据的移动；CIM 定义数据到达后的含义。Apache Kafka 等消息代理仍然负责传输；CIM 定义事件的形状。模型是合同，工具是管道。

If you are shopping: Boomi AtomSphere — Enterprise iPaaS for hybrid cloud-to-on-prem integration.

治理、许可以及基金会的重要性

CIM 作为 联合开发基金会（Joint Development Foundation） 的一部分开源，该基金会在 Linux 基金会 旗下运行。这并非一个微小的细节 —— 它是企业能够安全地基于 CIM 构建的核心原因。

Linux 基金会是一个成熟的中立协作开源项目之家，而联合开发基金会为协作开发标准和规范提供了一个轻量级的法律结构。在其中托管 CIM 意味着：

• 中立管理。 没有单一供应商控制该模型，因此采用它并不意味着采用了竞争对手的路线图。
• 开放贡献。 任何人（供应商、企业、个人贡献者）都可以提出更改，且过程透明。
• 可预测的许可。 基金会托管的规范通常采用旨在促进广泛、免版税采用的条款，这对于评估标准的法律和采购团队至关重要。

对于在内部进行论证的架构师来说，治理故事通常与技术内容一样重要。“这是一个 Linux 基金会下的开放标准”回答了那些足以扼杀标准采用的问题：谁控制它？如果供应商退出会发生什么？我们可以贡献我们的扩展吗？

入门：实用的采用路径

采用共享模型既是一项组织活动，也是一项技术活动。一个务实的步骤序列如下：

1. 清点共享实体。 识别出现在多个系统中的业务概念 —— 通常是客户、产品、订单和位置。这些是您的候选对象。
2. 选择一个主题区域和一个集成点。 选择痛点最高、影响范围（blast radius）最小的集成点来验证模型。单一的报告管道或一个新应用程序的入驻是理想选择。
3. 将每个系统映射到 CIM 一次。 构建从每个源系统到 CIM 表示的转换，以及从 CIM 到每个目标的转换。抵制直接进行系统到系统映射的冲动。
4. 记录您的扩展。 在 CIM 未涵盖某个概念的地方，明确记录该扩展并考虑将其贡献回原模型。
5. 建立所有权。 没有管理员的规范模型会衰败。指定一个团队或角色负责映射以及跟踪上游更改。
6. 版本化和测试。 将模型及其映射视为带有测试的版本化工件，就像对待应用程序代码一样。

最常见的失败模式是将 CIM 视为一次性的建模练习，而非一个活的合同。成功的组织像对待 API 一样对待模型：版本化、测试、有所有权且审慎演进。

为 CIM 做出贡献的合作伙伴

CIM 是一个联盟的共同努力，其价值随参与度的增加而增长。合作伙伴贡献主题区域内容、审查提案并帮助塑造模型的方向。由于这项工作是开放的，贡献并不局限于大型供应商 —— 真正面临集成痛点的企业和具有领域专业知识的个人从业者同样受到欢迎。

联系我们

您有兴趣加入 CIM 计划吗？太棒了！请随时给我们发送电子邮件以获取更多信息。Email Us。

常见问题

什么是云信息模型 (CIM)？

CIM 是一种与应用程序无关的开源数据模型，它为企业需要在云端和本地应用程序之间交换的业务概念提供共享的、基于标准的词汇表。它由一个开放联盟制定，并由 Linux 基金会旗下的联合开发基金会托管。其目的是减少脆弱的点对点集成所需的自定义映射代码。

CIM 是产品还是规范？

CIM 是一个规范 —— 一个模型和一组定义 —— 而不是一个可运行的产品。它定义了共享实体的含义和结构；您仍然可以选择自己的 ETL/ELT 工具、消息代理和存储。将其视为您的集成管道所实现的合同，而不是管道本身。

CIM 与供应商的集成平台有何不同？

集成平台（iPaaS 或连接器库）移动数据并通常提供预构建的连接器，但这些连接器采用了特定于供应商的语义。 CIM 是中立且独立于供应商的，因此它不会将您锁定在某个平台的世界观中。两者是互补的：您可以使用 CIM 作为任何集成平台内的规范模型。

CIM 的主题领域是什么？

主题领域（也称为域）是模型的组织单元，每个单元代表一个主要业务概念，例如客户、产品或订单。设计以多种格式发布，包括示例图表，并且随着联盟和社区贡献更多内容，主题领域集预计会不断增长。

如果 CIM 没有涵盖我们的概念，我们可以扩展它吗？

是的。 CIM 旨在扩展，并且由于它是在中立基金会下开源的，因此您可以通过贡献流程提出添加内容。扩展共享模型并回馈比维护私有分叉更可取，因为私有分叉会随着时间的推移而产生偏差，并丧失最初推动采用 CIM 的互操作性优势。

谁应该采用 CIM？

对于运行来自不同供应商的许多应用程序的组织来说，这是最有价值的，这些应用程序必须就共享实体的含义达成一致——这是企业数据架构师和集成工程师的典型情况。应用程序和平台供应商还可以通过将其架构与中立模型保持一致而受益，这使得客户可以更轻松地集成其产品。如果您只有两个稳定的系统，则更简单的点对点映射可能就足够了。

进一步阅读

• Linux 基金会 — 维基百科
• 联合发展基金会 — 维基百科
• 企业集成模式 — 维基百科
• 资源描述框架 (RDF) — 维基百科