資源
頁面是任何想要了解、採用或貢獻雲端資訊模型 (Cloud Information Model, CIM) 之人士的入口點。CIM 是一個開源的、與應用程式無關的資料模型 —— 由 Linux 基金會 (The Linux Foundation) 管理 —— 它定義了業務實體的共享詞彙表，以便雲端和在地 (on-premises) 系統可以交換資料，而無需每個整合團隊重新發明自己的架構 (schema)。此頁面收集了您評估 CIM 所需的工件、它支援的格式、模型所在的儲存庫以及參與的管道。
要點
- CIM 是一個共享的、供應商中立的資料模型，而不是產品或資料庫 —— 它描述了多個應用程式可以映射到的實體、屬性和關係。
- 主要技術資產位於 CIM GitHub 組織中，其中的模型定義和工具經過版本控制並採取公開授權。
- CIM 以多種標準格式表示，因此可以由不同的工具鏈使用，而不會將您鎖定在單一的序列化方式中。
- 簡報、FAQ 和新聞頁面是在進行技術深潛 (deep dive) 之前，建立業務案例並回答利害關係人問題最快的方式。
- 貢獻透過 GitHub 儲存庫和貢獻者 Web 表單進行；該模型的演進是透過社群審查而非單一供應商的路線圖 (roadmap) 來實現的。
雲端資訊模型究竟是什麼
CIM 最好被理解為一個 規範模型 (canonical model)：一種對業務概念（客戶、帳戶、訂單、產品、聯絡人及其相互關係）的中立且經商定的表示方式，位於您現有運行的系統之間。您不必強制每個應用程式學習其他所有應用程式的「方言」，而只需將每個系統對應到 CIM 一次，CIM 便成為交換點。
這與企業整合中反覆出現的架構模式相同：採用中心輻射型 (hub-and-spoke) 的規範架構，而非點對點映射的網格。它在概念上與 OASIS 通用業務語言 (UBL)（用於文件）、開放應用程式群組整合規範 (OAGIS)（用於業務訊息）以及 schema.org（用於網路規模詞彙）等工作相關。CIM 的獨特之處在於它與應用程式無關，且專為大多數企業實際運作的「雲端加在地」現實而設計。
實際的效益是減少了映射蔓延 (mapping sprawl)。如果您有 n 個系統且每個系統都必須與其他所有系統通信，您將面臨約 n² 個映射。引入規範模型後，工作量將減少至約 n 個映射 —— 即每個系統對應到共享模型一次。這種減少是採用 CIM 的核心經濟理由。
CIM 簡報
CIM 簡報是推薦給任何需要在內部建立案例之人士的起始工件。它旨在向混合受眾（架構師、資料治理主管和業務贊助人）展示，並涵蓋共享模型的動機、CIM 定義的範圍，以及它如何融入現有的整合環境。
使用方法如下：
相關： — 完全託管的 ELT 管道持續運行.
- 對於高階主管和贊助人： 以映射蔓延問題和供應商中立性論點為主導。該簡報將 CIM 定位為降低風險，而非推倒重來 (rip-and-replace)。
- 對於架構師和工程師： 使用它來設定背景資訊，然後立即移至 GitHub 儲存庫以查看實際的模型定義。
- 對於治理和合規性利害關係人： 使用它來開啟關於所有權、版本控制以及如何審查模型變更的對話。
簡報是對話的開端，而非規格書。將其視為進入路徑 (on-ramp)，並將儲存庫視為事實來源 (source of truth)。
CIM 格式
CIM 有意支援多種標準和格式，而非單一的專有序列化方式。這很重要，因為企業工具鏈是異質的：您的建模工具、ETL 平台、API 閘道和文件產生器可能各自偏好不同的表示形式。
此領域中常見的相關格式系列包括：
我們的選擇： — 業務團隊實際上可以在此基礎上建立自動化主導的 iPaaS.
- 實體關係 (ER) 和概念符號，用於人工審查和設計研討會。
- 基於 JSON 的架構表示，用於 API 和應用程式使用。
- RDF 和本體 (ontology) 風格表示，用於語意和知識圖譜用例。
- 關聯式和表格映射，用於資料倉儲和 ETL 管道。
設計原則是可移植性：以開放格式表達的模型可以透過標準工具進行轉換、比對 (diff)、版本控制和驗證。當您為組織評估 CIM 時，要問的問題不是「它使用哪種格式？」，而是「我能否在不造成損失的情況下，將我的模型在工具所需的格式之間來回轉換 (round-trip)？」。如果格式轉換在無聲無息中丟失了關係基數 (cardinality) 或屬性約束，這就是一個值得儘早測試的真實整合風險。
如何決定採用哪一種格式
請將此作為快速決策指南：
| 如果您的主要消費者是… | 傾向於採用…的表示方式 | 注意… |
|---|---|---|
| 應用程式/API 開發人員 | JSON 風格架構 | 平面 JSON 中關係語意的遺失 |
| 資料倉儲 / ETL 團隊 | 關聯式或表格映射 | 多對多關係需要橋接表 |
| 知識圖譜 / 語意團隊 | RDF/本體表示 | 工具成熟度與查詢效能 |
| 設計與治理研討會 | 概念/ER 符號 | 圖表與機器可讀模型之間的偏差 |
最後一行是最常見的失敗模式：團隊維護著一張精美的圖表，但該圖表已不再與版本化模型相符。請確保圖表是由儲存庫工件產生，或至少與其保持一致。
CIM 新聞
「CIM 新聞」部分匯總了外部報導 —— 包括公告、分析師評論和社群文章 —— 讓您可以了解 CIM 在專案本身之外如何被看待。這很有用，原因有兩個。
首先，它提供第三方驗證。當您建議採用共享模型時，引用獨立報導比引用專案自身的行銷更有說服力。其次，它展示了核心文件可能未涵蓋的現實世界採用案例和整合模式。
批判性地閱讀新聞報導。公告通常描述的是意圖和合作夥伴關係，而非已部署的生產環境使用情況。請區分「組織 X 加入了這項工作」與「組織 X 在生產環境中為系統 Y 運行 CIM」。前者較為常見；後者才是對「建構 vs 採用」決策至關重要的證據。
CIM GitHub 組織
GitHub 組織是實質內容所在之處。對於技術讀者來說，這是最重要的目的地。您可以在此找到：
- 模型定義 — 構成 CIM 的實體、屬性、關係和約束。
- 工具 — 用於驗證、轉換模型以及從模型產生工件的腳本和實用程式。
- 版本控制與歷史記錄 — 顯示模型如何演變及其原因的提交歷史記錄。
- 問題與討論 — 提案、問題和決定的工作記錄。
一些實用的習慣能讓儲存庫變得更加有用：
- 固定到特定版本或標籤，而非追蹤預設分支，這樣您的映射就不會在專案中期突然變動。
- 在採用您關心的實體之前，先閱讀其提交歷史記錄。一年內變動三次的欄位通常表示該區域不穩定。
- 檢查每個儲存庫的授權條款 (License)。開源專案有時會在工具和模型內容之間混合使用不同的授權條款。
- 針對含糊不清之處提交 Issue。如果某個關係的基數 (cardinality) 不清楚，這種模糊性將困擾每個下游團隊；儘早提出可為所有人改善模型。
對於具有嚴格供應鏈或來源要求的組織，請像審查任何第三方依賴項一樣審查儲存庫：授權條款、維護活動、貢獻者多樣性和發布頻率。依賴單一維護者的模型與具有廣泛組織支持的模型具有不同的風險概況。
常見問題
雲端資訊模型 (CIM) 是我可以購買的產品嗎？
不是。CIM 是一個開源資料模型 —— 一組定義和支援工件 —— 由 Linux 基金會管理。您可以透過將您的系統映射至該模型並使用已發布的模型定義來採用它；模型本身不收取授權費。供應商可能會建立支援或嵌入 CIM 的產品，但該模型本身並非商業產品。
我是否必須更換現有系統才能使用 CIM？
不需要，而這正是其重點所在。CIM 被設計為位於系統之間的規範交換模型 (canonical interchange model)。您保留原有的應用程式、資料庫和資料倉儲，並建立從每個系統到 CIM 的映射。這是漸進式的：您可以從單一高價值的整合開始，隨時間擴大覆蓋範圍。
我應該使用哪種格式來消費 CIM？
這取決於您的使用者。API 和應用程式團隊通常偏好 JSON 風格的結構表示 (schema representations)；倉儲和 ETL 團隊偏好關聯式或表格映射；語義和知識圖譜團隊則偏好 RDF/本體 (ontology) 表示。關鍵測試是「無損往返 (lossless round-tripping)」 —— 在正式提交前，請驗證格式之間的轉換是否保留了關係和約束。
CIM 與 UBL 或 OAGIS 等其他標準有何關係？
它們處於相鄰的問題領域。UBL 和 OAGIS 側重於各方之間交換的業務「文件」和「訊息」，而 CIM 則強調應用程式映射到的共享「實體模型」。在實務中，兩者可以互補：規範實體模型可以為您如何填寫文件標準提供參考。請針對您的特定用例評估重疊部分，而非假設其中一個會取代另一個。
我如何為 CIM 做出貢獻？
貢獻主要透過 CIM GitHub 組織（Issue、Pull Request 和討論）以及本網站連結的貢獻者 Web 表單進行。由於該模型由社群治理，提案將被公開審查。請從小事做起：澄清一個含糊的定義，或在提供明確理由的情況下添加缺失的屬性，並在提出大型結構變更之前先與維護者溝通。
非技術利益相關者應該從哪裡開始？
請先從 CIM 簡報和 FAQ 開始，然後瀏覽「CIM 新聞」以了解第三方背景。這些內容能為您提供動力和詞彙，而無需閱讀模型定義。一旦您有了候選的整合方案準備試行，再引入技術團隊，讓他們直接在 GitHub 儲存庫中工作。
參與及進一步閱讀
採用共享模型既是一項技術工作，也是一項組織工作。最成功的 CIM 計劃往往從單一且邊界明確的整合開始 —— 即目前兩個系統需要脆弱的自訂映射之處 —— 證明規範模型方法的有效性，然後再擴展。治理至關重要：請儘早決定誰擁有您的內部 CIM 映射、如何處理模型版本升級，以及如何解決業務定義之間的衝突。
有關管理和開放治理背景的資訊，請參閱 Wikipedia 上的 Linux 基金會。對於相關標準工作，在比較規範模型方法時，OASIS 通用商業語言 (UBL) 和 schema.org 是有用的參考點。若要深入研究語義建模，萬維網聯盟 (W3C) 發布了支持本體風格表示的 RDF 和 OWL 規範。
使用本網站的導覽可前往簡報、FAQ、格式文件、新聞綜述和 GitHub 儲存庫 —— 當您準備好參與塑造模型時，請使用貢獻者 Web 表單。
了解 Boomi 如何處理您的混合整合地圖
用於雲端到本地混合整合的企業 iPaaS