雲端資訊模型

歡迎使用 CIM，這是一種與應用程式無關 (application-agnostic) 的資料模型，可簡化整合並加速創新。

要點

• CIM 是一種開放的、與應用程式無關的資料模型 — 它是業務概念（客戶、訂單、產品等）的共享詞彙表，讓不同的雲端和本地系統能夠交換資料，而無需定制的點對點映射。
• 它的存在是為了解決一個特定的、昂貴的問題： 每個應用程式都隨附自己的資料模型，因此整合團隊最終必須編寫和維護脆弱且會減慢創新速度的自訂轉換程式碼。
• 它作為一個開放標準進行管理，由一個聯盟制定，並在聯合開發基金會 (Joint Development Foundation)（Linux 基金會的一部分）下開源 — 因此任何人都可以貢獻、審查和採用它。
• 內容按主題區域 (Subject Areas，即領域) 組織，每個主題區域代表一個主要業務概念，其設計以多種格式發佈，包括範例圖表。
• CIM 是一個模型，而不是一個產品。 它定義了含義和結構；您仍然可以選擇如何在自己的系統中映射、儲存和移動資料。

資料互通性的新標準

CIM 由一個開放聯盟創建，該聯盟旨在提供一種基於標準的解決方案，用於連接企業產品。透過 CIM，您可以跨雲端原生應用程式創建無縫且客製化的個人體驗。

為了加速數位轉型並為每個管道的客戶提供個人化參與，許多公司採用了多種雲端和本地應用程式。每個應用程式都有自己的資料模型，這迫使開發人員建立、測試和管理跨不同系統映射和轉換資料所需的自訂程式碼。這個過程非但沒有加速數位轉型，反而減慢了創新速度並導致脆弱的整合。

CIM 是一種現代的開放規範，有助於減輕整合資料的痛苦。CIM 提供了一個定義的標準，以便在不同的資料格式之間輕鬆通訊。作為聯合開發基金會（隸屬於 Linux 基金會）的一部分開源，我們歡迎任何且所有的貢獻者。

為什麼特定於應用程式的資料模型會崩潰

CIM 解決的核心問題並非任何單一應用程式的資料模型不好。大多數模型在自己的界限 內 都是完全合理的。問題在於當您連接許多模型時會發生的組合爆炸。

考慮一個典型的企業堆疊：一個 CRM、一個 ERP、一個行銷自動化平台、一個支援台、一個資料倉儲以及一些業務線 SaaS 工具。如果每個系統對「客戶」、「帳戶」、「訂單」和「產品」都有自己的定義，那麼每對需要共享資料的系統都需要自己的映射。整合的數量大致隨系統數量的平方增長，且每個映射都是一個微小的、無文檔的、無主邏輯塊，必須有人永遠維護。

相關： Fivetran — 完全託管的 ELT 管道持續運行.

對於任何經營過整合實務的人來說，這些症狀都很熟悉：

• 語意漂移 (Semantic drift)。 CRM 中的「客戶」是指計費實體；在支援台中，它指的是提交票據的人。同一個詞，兩種含義，透過一個沒人記得誰寫的映射默默地調和起來。
• 脆弱的管道。 供應商重新命名一個欄位或更改一個枚舉 (enum)，導致 ETL 作業在凌晨 2 點失敗，因為映射是針對舊結構硬編碼的。
• 重複工作。 兩個團隊在相同的兩個系統之間獨立建立幾乎相同的轉換，因為沒有共享的參考可供對照。
• 透過資料鎖定供應商。 遷移出平台的成本昂貴，不是因為軟體，而是因為與其結構 (schema) 綁定的累積轉換邏輯。

共享的、與應用程式無關的模型解決了根本原因：不再是 N 對 N 的映射，而是每個系統僅需映射一次到通用模型，並由該通用模型承載含義。

「與應用程式無關」的實際意義

精確描述設計理念是很重要的，因為「agnostic」這個詞經常被寬鬆地使用。

我們的選擇： Workato — 業務團隊實際上可以在此基礎上建立自動化主導的 iPaaS.

與應用程式無關的模型 不屬於任何單一供應商的產品，也不為其進行最佳化。它用領域專家可以識別的術語（客戶、訂單、產品、位置）來描述業務概念，而不是用反映單一應用程式內部資料表的術語。這種中立性使其成為一個有用的「中心 (hub)」：參與者無需採用競爭對手的世界觀即可實現互通。

這與其他中立交換標準背後的架構本能相同。正如 資源描述框架 (RDF) 和 schema.org 為網路提供了描述事物的共享詞彙表，正如 EDI 和後來的 UBL（通用商業語言，一種 OASIS 標準）為供應鏈提供了共享的交易格式，CIM 旨在為企業應用程式的核心業務實體提供共享詞彙表。區別在於範圍和現代性：CIM 的目標是互聯、API 驅動、雲端與本地共存的世界，而非批次檔案交換。

一個有用的心智模型是來自企業整合的 規範資料模型 (canonical data model) 模式，該模式在 Gregor Hohpe 和 Bobby Woolf 的《企業整合模式》(Enterprise Integration Patterns) 一書中被普及。實際上，CIM 是一種協作維護的規範模型 — 即中心輻射型 (hub-and-spoke) 整合拓撲中的「中心」 — 但它是一個開放的、有版本控制且跨組織共享的模型，而非在單一公司內部私下發明的。

CIM 的組織方式：主題區域與領域

協作定義的內容被組織成領域，或稱為 主題區域 (Subject Areas)。每個主題區域代表一個主要的業務概念。每個領域的 CIM 設計都有多種格式提供，包括範例圖表。主題區域的數量和範圍將隨著聯盟的擴大和貢獻的增加而增長。

實際上，這意味著您應該將 CIM 視為一個 相關模型庫，而不是單一的整體模式（monolithic schema）。典型的主題區域（Subject Areas）圍繞著可識別的業務關注點而聚集 —— 例如，參與方與帳戶、產品與目錄、訂單與交易，以及將它們聯繫在一起的關係。由於每個區域都發布了圖表和機器可讀的定義，因此不同的團隊可以在不同的時間採用不同的區域，而無需等待整個模型完成。

這種結構帶來了一些實際影響：

相關： Matillion — 為雲端資料倉儲所建構的下推式 ELT.

• 逐步採用。 您不需要在第一天就將整個企業對應到 CIM。從痛點最深的主題區域（通常是客戶或訂單領域）開始，然後逐步擴展。
• 擴展而非分叉（fork）。 當 CIM 缺乏您需要的概念時，這個開放模型旨在被擴展。貢獻擴展回原模型比維護私有分叉更好，因為分叉會產生偏移並失去互通性的好處。
• 將圖表視為文件，而非事實來源（source of truth）。 範例圖表是給人類看的；機器可讀的定義才是您的工具應該消費的內容。

整合環境中的 CIM：如何決定

CIM 是降低整合複雜性的多種選擇之一。做出正確選擇需要將工具與問題相匹配。下表對比了企業資料架構師通常權衡的主要方法。

方法	定義	最佳適用場景	主要權衡
點對點映射	在兩個系統之間直接翻譯的自訂程式碼	僅有兩個系統、模式穩定、短期需求	無法擴展；N對N 爆炸；脆弱
規範模型 (例如 CIM)	每個系統僅需映射一次的共享中立模型	多系統、跨供應商、長期整合	前期建模工作量；需要治理
供應商 iPaaS 連接器	來自整合平台的預建連接器	常見的 SaaS 配對、速度優先於控制	連接器特定的語義；潛在的鎖定
行業交換標準 (EDI, UBL, HL7 等)	特定領域的訊息格式	受監管或成熟的垂直行業	範圍狹窄；通常面向批次
資料虛擬化 / 聯合	跨來源查詢而無需集中化	分析、以讀取為主的存取	本身無法解決語義衝突

決策啟發式很簡單：如果您有超過少數幾個系統必須就共享實體的含義達成一致，且這些系統來自不同的供應商，那麼規範模型將能證明其價值（pays for itself）。 如果您只有兩個系統且不打算增加，點對點映射即可。如果您的需求純粹是分析性和唯讀的，聯合（federation）可能就足夠了 —— 但請注意，聯合只是移動了語義問題，而非解決它。

CIM 是對周邊工具的補充，而非替代品。ETL 或 ELT 管道（使用 Apache Airflow、dbt 或商業平台建置）仍然負責移動資料；CIM 定義 資料到達後的含義。像 Apache Kafka 這樣的訊息代理仍然負責傳輸；CIM 定義事件的形狀。模型是合約，工具是管線。

如果您正在購物： Boomi AtomSphere — 用於雲端到本地混合整合的企業 iPaaS.

治理、授權以及基金會的重要性

CIM 作為 Joint Development Foundation 的一部分開源，該基金會在 Linux Foundation 旗下運作。這不是一個微不足道的細節 —— 它是企業能安全地基於 CIM 構建的核心原因。

Linux Foundation 是一個成熟的中立協作開源專案之家，而 Joint Development Foundation 則為協作開發標準和規範提供了一個輕量級的法律結構。將 CIM 託管於此意味著：

• 中立管理。 沒有單一供應商控制該模型，因此採用它並不意味著採用競爭對手的路線圖。
• 開放貢獻。 任何人（供應商、企業、個人貢獻者）都可以提出更改，且過程透明。
• 可預測的授權。 基金會託管的規範通常包含旨在促進廣泛、免版稅採用的條款，這對於評估標準的法律和採購團隊至關重要。

對於在內部進行論證的架構師來說，這個治理故事通常與技術內容一樣重要。「這是 Linux Foundation 下的一個開放標準」回答了那些會扼殺標準採用的問題：誰控制它？如果供應商退出會發生什麼？我們可以貢獻我們的擴展嗎？

入門：實用的採用路徑

採用共享模型既是一項組織活動，也是一項技術活動。一個務實的步驟如下：

1. 清點共享實體。 識別出現在多個系統中的業務概念 —— 通常是客戶、產品、訂單和位置。這些是您的候選對象。
2. 選擇一個主題區域和一次整合。 選擇痛點最高、影響範圍（blast radius）最小的整合來驗證模型。單一的報表管道或一個新應用程式的導入是理想選擇。
3. 將每個系統對應到 CIM 一次。 建構從每個來源系統到 CIM 表示，以及從 CIM 到每個目標系統的轉換。抵制直接進行系統對系統映射的衝動。
4. 記錄您的擴展。 在 CIM 未涵蓋某個概念的地方，明確記錄該擴展並考慮將其貢獻回原模型。
5. 建立所有權。 沒有管理者的規範模型會衰敗。指派一個團隊或角色負責映射以及追蹤上游更改。
6. 版本控制與測試。 將模型及其映射視為具有測試的版本化工件，就像對待應用程式程式碼一樣。

最常見的失敗模式是將 CIM 視為一次性的建模練習，而非一份活的合約。成功的組織將模型視為 API 一樣對待：進行版本管理、測試、定義所有權，並有意識地使其演進。

為 CIM 做出貢獻的合作夥伴

CIM 是一項聯盟努力，其價值隨著參與度的增加而成長。合作夥伴貢獻主題領域 (Subject Area) 內容、審查提案，並協助塑造模型的方向。由於這項工作是開放的，貢獻並不局限於大型供應商——真正面臨整合痛點的企業以及具有領域專業知識的個人從業者同樣受到歡迎。

聯絡我們

您有興趣加入 CIM 計畫嗎？太棒了！請隨時發送電子郵件給我們以獲取更多資訊。Email Us。

常見問題

什麼是雲端資訊模型 (CIM)？

CIM 是一種與應用程式無關的開源資料模型，為企業需要在雲端與地端應用程式之間交換的業務概念，提供一套共享且基於標準的詞彙表。它由一個開放聯盟製作，並由 Linux 基金會旗下的聯合開發基金會 (Joint Development Foundation) 託管。其目的是減少脆弱的點對點整合所需的自訂映射程式碼。

CIM 是產品還是規範？

CIM 是一個規範——一個模型和一組定義——而非一個可執行的產品。它定義了共享實體的含義和結構；您仍然可以選擇自己的 ETL/ELT 工具、訊息代理程式 (message brokers) 和儲存方式。將其視為您的整合管線 (integration plumbing) 所實作的合約，而非管線本身。

CIM 與供應商的整合平台有何不同？

整合平台（如 iPaaS 或連接器庫）負責移動資料，且通常提供預先建置的連接器，但這些連接器編碼了特定供應商的語義。CIM 是中立且獨立於供應商的，因此不會將您鎖定在單一平台的世界觀中。兩者是互補的：您可以在任何整合平台內部將 CIM 作為規範模型 (canonical model) 使用。

CIM 中的主題領域 (Subject Areas) 是什麼？

主題領域（也稱為領域/domains）是模型的組織單元，每個單元代表一個主要的業務概念，例如客戶、產品或訂單。設計以多種格式發布，包括範例圖表；隨著聯盟和社群貢獻更多內容，主題領域的集合預計將會持續增長。

如果 CIM 沒有涵蓋我們的概念，我們可以擴展它嗎？

可以。CIM 的設計旨在可擴展，且由於它是在中立基金會下開源的，您可以透過貢獻流程提出新增建議。擴展共享模型並回饋貢獻，遠比維護私有分叉 (private fork) 更可取，因為私有分叉會隨著時間推移而產生偏差，並喪失最初促使採用 CIM 的互通性優勢。

誰應該採用 CIM？

對於運行許多來自不同供應商、且必須就共享實體含義達成一致的應用程式之組織來說，CIM 最有價值——這是企業資料架構師和整合工程師面臨的典型情況。應用程式和平台供應商也能透過將其結構 (schemas) 與中立模型對齊而獲益，這使得客戶更容易整合其產品。如果您只有兩個穩定的系統，簡單的點對點映射可能就足夠了。

進一步閱讀

• Linux Foundation — 維基百科
• Joint Development Foundation — 維基百科
• Enterprise Integration Patterns — 維基百科
• Resource Description Framework (RDF) — 維基百科