云信息模型

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

核心要点

• CIM 是一种共享的、开放的数据模型，而不是一种产品。 它定义了通用的业务概念及其关系，以便不同的应用程序可以交换数据，而无需定制的一次性映射。
• 它作为开放标准进行治理。 CIM 在联合开发基金会（Joint Development Foundation，Linux 基金会的一部分）下开源，并欢迎来自供应商、企业和更广泛社区的贡献者。
• 内容按主题区域（Subject Areas，即域）进行组织。 每个域代表一个主要业务概念，并以多种格式（包括图表）发布，以便架构师和工程师可以逐步采用。
• 核心价值是降低集成的脆弱性。 规范模型（Canonical model）用一个许多系统都可以映射的稳定目标，取代了点对点的转换代码。
• 采用是一项设计决策，而不是一个开关。 您可以选择采用哪些域、如何映射源系统以及如何随着时间的推移治理扩展。

数据互操作性的新标准

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

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

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

CIM 解决的问题是结构性的，而不是偶然的。当每个系统都使用自己的“方言”时——一个将客户称为“联系人（Contact）”，另一个称为“参与方（Party）”，第三个称为“账户（Account）”——集成团队最终需要维护一个不断增长的成对映射网络。每个新应用程序都会使所需的转换数量成倍增加，并且任何一个系统中的模式（schema）更改都可能产生连锁反应并破坏下游管道。规范模型改变了这一问题的形式：不再是 N 个系统相互映射，而是每个系统仅映射一次到共享词汇表。

为什么点对点集成会失效

具体了解促使采用共享模型的失效模式会有所帮助。

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

• 组合爆炸式增长。 在点对点映射中，转换路径的数量大致随系统数量的平方增长。添加第十个应用程序的成本远高于添加第二个应用程序。
• 语义漂移。 两个团队可能都在“映射客户”，但对于客户是指个人、组织还是计费关系仍存在分歧。数据在流动，但含义却在分叉。
• 脆弱的变更管理。 一个源系统中的字段重命名或新增的必需属性，会强制所有触及该字段的消费者进行修改。
• 逻辑重复。 验证、去重和身份解析规则在每个集成中被重复实现，而不是定义一次。
• 供应商锁定压力。 当集成逻辑与特定供应商的模式纠缠在一起时，切换或增加供应商就变成了一个重新平台化的项目。

像 CIM 这样的规范模型并不能消除映射工作——每个源系统仍然需要映射到该模型。它消除的是这种工作的倍增。您为每个系统构建一个到共享模型的映射，而模型本身则提供了它们之间稳定的契约。

CIM 的组织方式：主题区域

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

这种面向域的结构对于采用至关重要。您很少需要一次性采用整个模型。典型的企业从涉及其最痛苦集成的域开始，验证该方法，然后逐步扩展。常见的起点往往是几乎每个系统中都会出现的概念：

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

• 参与方 / 客户 (Party / Customer) — 您与其开展业务的人员和组织，以及他们扮演的角色。
• 产品 (Product) — 您销售、提供或管理的内容，包括目录和分类。
• 账户与关系 (Account and relationship) — 参与方如何与产品、合同以及彼此相关联。
• 交互与活动 (Interaction and activity) — 连接上述内容的事件、交易和参与。

由于每个主题区域都随附图表和多种表示格式，架构师可以审查概念模型，工程师可以使用机器可读的形式，业务利益相关者可以验证概念是否符合实际。这种多格式方法是一种深思熟虑的设计选择：如果一个模型只有工程师能读懂，它往往会偏离业务含义。

CIM 与其他方法的比较

CIM 是实现互操作性的多种选项之一。做出正确选择意味着要理解权衡。

方法	定义	优势	权衡
点对点映射	每对系统之间的直接转换	两个系统时很简单；无需共享治理	组合式增长；脆弱；逻辑重复
规范模型 (CIM 风格)	每个系统映射到的共享的、与应用程序无关的词汇表	线性映射工作量；稳定契约；可跨项目复用	需要治理和共识；每个系统仍需映射
行业数据标准	针对特定行业（如医疗、金融）的垂直标准	深度领域覆盖；符合监管要求	范围狭窄；可能不涵盖跨行业的企业概念
供应商数据模型	将平台的原生模式作为集成中心公开	工具集成紧密；在单一供应商生态内速度快	锁定风险；其他供应商必须符合该方的模型
API 优先 / 读时模式	按 API 定义契约；在消费时解析含义	灵活；启动快	语义一致性依赖于自律；大规模治理较难

实用指南：当您拥有许多系统、跨域概念和长期集成环境时，请使用规范模型。当范围确实仅限于两个系统且短期有效时，请使用点对点。行业标准和 CIM 是互补的——垂直标准可以为某个域提供参考，而 CIM 则提供跨领域的企业词汇。

如何在实践中采用 CIM

采用是一系列深思熟虑的决策，而不是一次单一的迁移。一个可行的模式如下：

1. 选择一个痛点高、边界明确的集成。 选择一个映射痛点真实且范围足够小的域，以便快速证明价值。
2. 清点源系统及其模式。 记录每个系统在您选择的主题区域中如何定义这些概念，以及它们不一致的地方。
3. 将每个系统映射到 CIM 域。 为每个系统构建一个到共享模型的映射。将这些映射视为版本化工件，而非一次性脚本。
4. 预先定义扩展策略。 决定如何处理 CIM 尚未涵盖的概念——扩展应记录在案、命名一致，并在具有广泛用途时建议提交给联盟。
5. 建立治理。 分配映射的所有权、变更审核流程以及与上游 CIM 更新同步的节奏。
6. 逐个域扩展。 复用第一个域的映射模式和治理，以降低下一个域的成本。

有两个警告值得明确说明。首先，规范模型增加了一个层级——它并非没有成本，其回报来自于在多个集成中的复用，而非单个集成。其次，映射是真正的工作所在；模型为您提供了一个稳定的目标，但仍需要有人决定每个源字段如何与之对应，且该决策需要业务端的输入，而不仅仅是工程端。

治理、许可与贡献

CIM 作为 联合开发基金会 (Joint Development Foundation) 的一部分开源，该基金会在 Linux 基金会 下运行。这种结构对于评估它的企业至关重要：Linux 基金会是协作、供应商中立开源项目的成熟家园，而联合开发基金会提供了专门为开发和运营标准及规范项目而设计的法律框架。

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

对于企业数据架构师来说，这种治理模型的实际意义是：

• 供应商中立性。 没有单一供应商控制规范，降低了模型被塑造为有利于某一平台的风险。
• 开放贡献。 任何人都可以提出更改，这意味着模型可以演进以反映现实世界的集成需求，而不是依赖单一的路线图。
• 面向规范的流程。 联合开发基金会模型围绕制定和维护规范而构建，这与采购和架构审查中采用和引用标准的方式一致。

我们鼓励并向所有人开放贡献。贡献通常采取新主题区域或优化主题区域、更正与澄清、示例图以及来自实际集成项目的反馈形式。最有价值的贡献通常来自那些遇到特定映射问题并能描述解决该问题的概念的从业者。

参与其中

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

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

除了电子邮件，自然的参与方式是审查您感兴趣的领域已发布的主题区域，尝试将您的一个系统映射到某个域，并将您发现的差距反馈给社区。由于主题区域的数量和范围随联盟和贡献而增长，模型的改进程度与用户提交的实际集成问题的数量成正比。

常见问题

云信息模型 (Cloud Information Model) 到底是什么？

CIM 是一种与应用程序无关的开放数据模型，它定义了通用的业务概念及其关系，以便不同的应用程序可以通过共享词汇表交换数据。它由一个开放联盟制作并作为开放规范发布。它不是一个您安装的产品，而是一个您将系统映射到的模型。

CIM 适合谁？

它面向企业数据架构师、集成和 ETL 工程师、应用程序和平台供应商以及开源贡献者。任何需要连接具有不同模式的多个云端和本地系统的人都是潜在用户。供应商从中受益，因为共享模型减少了与其产品集成所需的定制工作。

CIM 如何治理和许可？

CIM 作为联合开发基金会的一部分开源，该基金会在 Linux 基金会下运行。这提供了一个供应商中立、面向规范的治理框架。该结构旨在保持模型对贡献开放，且独立于任何单一供应商的控制。

CIM 与供应商的原生数据模型有何不同？

供应商的原生模型针对该供应商的产品和生态系统进行了优化；将其作为集成中心往往会造成锁定。CIM 被设计为与应用程序无关，因此没有单一平台定义词汇表。权衡在于 CIM 需要跨团队的治理和共识，而供应商模型在供应商自己的工具链中开箱即用。

如果我使用 CIM，我还需要编写映射吗？

是的。每个源系统仍然需要映射到共享模型。好处是，您为每个系统编写一个到 CIM 的映射，而不是为每对系统编写单独的转换。这将组合式的映射工作量转变为大致线性的工作量，并为您提供一个能经受单个系统变更的稳定契约。

我如何开始采用 CIM？

从一个主题区域中单一的、痛点高且边界明确的集成开始。清点源模式，将每个系统映射到 CIM 域，定义扩展和治理策略，并将映射视为版本化工件。一旦第一个域证明了价值，就逐个域扩展，复用您建立的模式和治理。

进一步阅读

• Linux Foundation — 维基百科
• Linux Foundation — 维基百科