雲端資訊模型

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

要點

• CIM 是一種共享的、開放的資料模型，而不是一種產品。 它定義了通用的業務概念及其關係，以便不同的應用程式可以交換數據，而無需定制的一次性映射。
• 它作為開放標準進行管理。 CIM 在聯合開發基金會（Joint Development Foundation，Linux 基金會的一部分）下開源，並歡迎來自供應商、企業和更廣泛社區的貢獻者。
• 內容以主題區域（Subject Areas，即域）進行組織。 每個域代表一個主要業務概念，並以多種格式（包括圖表）發布，因此架構師和工程師可以逐步採用它。
• 核心價值是降低整合的脆弱性。 規範模型（Canonical model）以一個許多系統都可以映射至其上或從其映射出的穩定目標，取代了點對點的翻譯程式碼。
• 採用是一項設計決策，而不是一個開關。 您可以選擇採用哪些域、如何映射來源系統，以及如何隨著時間的推移管理擴充。

資料互通性的新標準

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

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

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

CIM 解決的問題是結構性的，而不是偶然的。當每個系統都講自己的方言時——一個將客戶稱為「聯絡人」，另一個稱為「參與者」，第三個稱為「帳戶」——整合團隊最終得維護一個不斷增長的成對映射網絡。每個新應用程式都會使所需的轉換數量成倍增加，並且任何一個系統中的任何模式（schema）變更都可能向外傳播並破壞下游管道。規範模型改變了這個問題的形式：不再是 N 個系統相互映射，而是每個系統僅需映射一次到一個共享詞彙表。

為什麼點對點整合會失敗

具體了解激發共享模型需求的故障模式會有所幫助。

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

• 組合增長。 透過點對點映射，轉換路徑的數量大致隨系統數量的平方增長。添加第十個應用程式的成本遠高於添加第二個應用程式。
• 語意漂移。 兩個團隊可能都執行了「映射客戶」，但在客戶究竟是個人、組織還是計費關係方面仍然存在分歧。數據在流動，但意義卻有所分歧。
• 脆弱的變更管理。 一個來源系統中的欄位重新命名或新增的必需屬性，會強制所有接觸該欄位的消費者進行修改。
• 重複的邏輯。 驗證、重複資料刪除和身份解析規則在每個整合中被重新實現，而不是定義一次。
• 供應商鎖定壓力。 當整合邏輯與特定供應商的模式糾纏在一起時，切換或增加供應商就變成了一個重新平台化的專案。

像 CIM 這樣的規範模型並不能消除映射工作——每個來源系統仍然需要對應到該模型。它消除的是該工作的「倍增」。您為每個系統建立一個到共享模型的映射，而模型本身則提供它們之間穩定的契約。

CIM 的組織方式：主題區域

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

這種面向域的結構對於採用至關重要。您很少需要一次性使用整個模型。典型的企業從涉及其最痛苦整合的域開始，驗證該方法並逐步擴展。常見的起點往往是幾乎每個系統中都會出現的概念：

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

• 當事人 / 客戶（Party / Customer） — 與您有業務往來的人員和組織，以及他們所扮演的角色。
• 產品（Product） — 您銷售、提供或管理的產品，包括目錄和分類。
• 帳戶與關係（Account and relationship） — 當事人如何與產品、合約以及彼此相關。
• 互動與活動（Interaction and activity） — 連結上述內容的事件、交易和參與。

由於每個主題區域都以圖表和多種表示格式發布，因此架構師可以審查概念模型，工程師可以使用機器可讀的形式，而業務利害關係人可以驗證概念是否與現實相符。這種多格式方法是一種深思熟慮的設計選擇：如果一個模型只有工程師能讀懂，它往往會偏離業務意義。

CIM 與其他方法的比較

CIM 是實現互通性的多種選擇之一。做出正確選擇意味著需要了解其權衡。

方法	內容	優勢	權衡
點對點映射 (Point-to-point mapping)	每對系統之間的直接翻譯	對於兩個系統來說很簡單；無需共同治理	呈組合爆炸式增長；脆弱；邏輯重複
規範模型 (Canonical model, CIM 樣式)	每個系統映射到的共享且與應用程式無關的詞彙表	線性映射工作量；穩定的合約；可跨專案重複使用	需要治理和共識；每個系統仍需進行映射
行業數據標準	特定行業（例如醫療保健、金融）的垂直標準	深度領域覆蓋；符合監管要求	範圍狹窄；可能不涵蓋跨行業的企業概念
供應商資料模型	將平台的原生架構 (native schema) 作為整合中心公開	緊密的工具整合；在單一供應商生態系統中速度快	鎖定風險；其他供應商必須符合單一方的模型
API 優先 / 讀取時模式 (schema-on-read)	每個 API 定義合約；含義在消費時解析	靈活；啟動快速	語義一致性取決於紀律；大規模治理較困難

實務指南：當您擁有許多系統、跨域概念且整合環境長期存在時，請使用規範模型。當範圍確實僅為兩個系統且為短期需求時，請使用點對點映射。行業標準與 CIM 是互補的 —— 垂直標準可以為特定領域提供資訊，而 CIM 則提供跨切面的企業詞彙。

如何在實務上採用 CIM

採用是一系列深思熟慮的決定，而非單一的遷移。一個可行的模式如下所示：

1. 選擇一個痛點高且界限明確的整合。 選擇一個映射痛點真實存在且範圍足夠小的領域，以便快速證明價值。
2. 盤點來源系統及其架構 (schemas)。 記錄每個系統在您選擇的主題領域 (Subject Area) 中如何稱呼這些概念，以及它們不一致的地方。
3. 將每個系統映射到 CIM 域。 為每個系統建立一個到共享模型的映射。將這些映射視為版本化工件，而非一次性腳本。
4. 預先定義您的擴充策略。 決定如何處理 CIM 尚未涵蓋的概念 —— 擴充應記錄在案、命名一致，並在廣泛有用的情況下建議回饋給聯盟。
5. 建立治理機制。 指派映射的所有權、變更的審核流程，以及與上游 CIM 更新同步的頻率。
6. 逐域擴展。 重複使用第一個領域的映射模式和治理經驗，以降低下一個領域的成本。

有兩個警告值得明確說明。首先，規範模型增加了一個層級 —— 它並非免費，其回報來自於多個整合之間的重複使用，而非單一整合。其次，映射才是真正的工作所在；模型為您提供了一個穩定的目標，但仍需要有人決定每個來源欄位如何對應到該模型，而這項決策需要業務端的投入，而不僅僅是工程端。

治理、授權與貢獻

CIM 作為 Joint Development Foundation 的一部分開源，該基金會在 Linux Foundation 旗下運作。這種結構對於評估它的企業至關重要：Linux Foundation 是成熟的協作、供應商中立開源專案之聚集地，而 Joint Development Foundation 則提供了專為開發和營運標準與規範專案而設計的法律框架。

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

對於企業資料架構師來說，這種治理模型的實際意義是：

• 供應商中立性。 沒有任何單一供應商控制規範，這降低了模型被塑造為有利於某一平台的風險。
• 開放貢獻。 任何人都可以提出變更，這意味著模型可以不斷演進以反映現實世界的整合需求，而非單一的路線圖。
• 規範導向的流程。 Joint Development Foundation 的模型圍繞著制定和維護規範而構建，這與採購和架構審查中採用和引用標準的方式保持一致。

我們鼓勵並向所有人開放貢獻。貢獻通常採取新設或精煉的主題領域、更正與澄清、範例圖表以及來自實際整合專案的回饋形式。最有價值的貢獻通常來自於遇到特定映射問題並能描述解決該問題之概念的從業者。

參與其中

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

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

除了電子郵件，自然的參與方式是查看您感興趣領域已發布的主題領域，嘗試將您的系統之一映射到某個域，並將您發現的差距帶回社區。由於主題領域的數量和範圍隨著聯盟和貢獻的增加而增長，因此模型的改進程度與使用者帶來的實際整合問題數量成正比。

常見問題

雲端資訊模型 (Cloud Information Model) 到底是什麼？

CIM 是一種與應用程式無關的開放資料模型，它定義了常見的業務概念及其關係，以便不同的應用程式可以透過共享詞彙表交換資料。它由一個開放聯盟製作並作為開放規範發布。它不是一個您安裝的產品，而是一個您將系統映射到的模型。

CIM 適合誰？

它面向企業資料架構師、整合與 ETL 工程師、應用程式和平台供應商以及開源貢獻者。任何需要連接具有不同架構的多個雲端和本地系統的人都是潛在使用者。供應商能從中受益，因為共享模型減少了與其產品整合所需的客製化工作。

CIM 如何治理和授權？

CIM 作為聯合開發基金會 (Joint Development Foundation) 的一部分而開源，該基金會在 Linux 基金會下運作。這提供了一個供應商中立、以規範為導向的治理框架。該結構旨在保持模型對貢獻開放，且獨立於任何單一供應商的控制。

CIM 與供應商的原生資料模型有何不同？

供應商的原生模型針對該供應商的產品和生態系統進行了最佳化；將其採用為整合中心往往會造成供應商鎖定 (lock-in)。CIM 的設計旨在與應用程式無關 (application-agnostic)，因此沒有單一平台能定義其詞彙。權衡之處在於 CIM 需要跨團隊的治理與共識，而供應商模型則可在該供應商的工具中直接使用。

如果我使用 CIM，我還需要編寫映射 (mappings) 嗎？

是的。每個來源系統仍然需要一個到共享模型的映射。其好處在於，您為每個系統編寫一個到 CIM 的映射，而不是為每對系統編寫單獨的轉換。這將組合式的映射工作量轉化為大致線性的工作量，並為您提供一個能承受單一系統變動的穩定契約。

我該如何開始採用 CIM？

從一個主題領域 (Subject Area) 中單一的高痛點且邊界明確的整合開始。盤點來源綱要 (schemas)，將每個系統映射到 CIM 域，定義擴充與治理政策，並將映射視為版本化工件。一旦第一個域證明了其價值，即可逐個域地擴展，重複使用您已建立的模式與治理。

進一步閱讀

• Linux Foundation — 維基百科
• Linux Foundation — 維基百科