跳至主要內容
Cloud Information Model 一個開放且不限於特定應用程式的資料模型,用於連接企業雲端與地端應用程式。

本網站部分連結為聯盟行銷連結:若您透過該連結購買,我們可能會獲得佣金,且不會增加您的額外費用。這絕不會影響我們的推薦建議。詳情請參閱我們的聯盟行銷聲明。 聯盟行銷聲明.

參與其中

雲端資訊模型 (Cloud Information Model, CIM) 於 2019 年在 Linux 基金會旗下成立,既是一個成員聯盟,也是一個社群。成員在工作小組 (Working Groups) 中共同協作,定義並使用通用的開放資料模型,影響現有與未來的標準,並建立開放解決方案以解決常見問題。

CIM 的存在是因為企業資料分散在數十個應用程式中,每個應用程式都有自己的專有模式 (schema)、命名約定和語義。Salesforce 中的客戶、SAP 中的客戶以及自研計費系統中的客戶都被稱為「客戶」——但他們很少就客戶「是什麼」、哪些屬性具有權威性,或者客戶、訂單與產品之間的關係應如何表達達成一致。CIM 的答案是一個共享的、與應用程式無關的模型,任何系統都可以映射 (map) 到該模型,因此整合工作變成了映射練習,而非自訂的翻譯專案。

要點

  • CIM 是一個 Linux 基金會專案(成立於 2019 年),發布了一個開放的、基於標準的資料模型,並將其轉換為多種格式,以便異質系統可以採用。
  • 參與級別分為:指導成員 (Steering Members)、貢獻者成員 (Contributor Members) 和更廣泛的 CIM 社群,權限隨著級別提升而逐漸擴大。
  • 目前單一的工作小組負責定義新的主題領域 (Subject Areas)、映射和 API 要求——這是實質技術工作進行的地方。
  • 貢獻不僅僅是代碼:提出主題領域、參與共識投票以及加入工作小組,都是塑造標準的一流方式。
  • 該模型刻意保持格式中立,這使得關係型、圖形型和 API 導向的消費者可以共享同一個規範定義 (canonical definition)。

為什麼共享資料模型很重要

大多數整合痛點在於語義而非技術。ETL 管道、iPaaS 平台和 API 閘道已經成熟;出問題的是意義層 (meaning layer)。當兩個系統對於「帳戶」是指計費實體還是公司層級結構存在分歧時,每個下游報告、連接 (join) 和對帳都會繼承這種歧義。

像 CIM 這樣的規範模型透過提供中立的參考點來解決此問題。每個系統不再需要將 N 個系統相互映射(N×N 問題),而是將每個系統映射一次到規範模型(N×1 問題)。這與能源領域使用的通用資訊模型 (Common Information Model, IEC 61970/61968) 和醫療保健領域使用的 HL7 FHIR 資源等標準背後的架構原理相同——即透過特定領域的規範模型,讓獨立構建的系統能夠互通。

CIM 的範圍更廣且更橫向:它針對出現在 CRM、ERP、商務和供應鏈系統中的常見業務實體——客戶、產品、訂單、供應商及其相互關係。其目標不是取代這些系統的本機模型,而是作為一個共享詞彙表置於其之上。

工作小組範圍

我們採用基於標準的方法開發了雲端資訊模型 (CIM),並將其轉換為多種格式。這種方法使採用不同技術的企業能夠採用 CIM,同時也為貢獻者提供支持並促進更大的 CIM 生態系統成長。

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

具體來說,「多種格式」意味著相同的底層模型可以由不同的工具鏈使用——例如,作為關係型或文件儲存的模式定義、作為實體與關係的圖形,以及作為 API 合約的基礎。使用關係型資料倉儲的團隊、使用圖形資料庫的團隊以及構建 REST 或 GraphQL 服務的團隊,都可以使用同一個事實來源 (source of truth),而非三個分歧的定義。

這種格式中立性是一種經過深思熟慮的設計選擇,並伴隨實際的權衡:

  • 優點: 沒有任何單一供應商的工具享有特權,因此採用 CIM 不會受限於必須購買特定平台。
  • 優點: 模型可以獨立於任何序列化格式而演進。
  • 缺點: 貢獻者必須仔細思考哪些構造是真正規範的,哪些僅是特定格式的產物 (artifacts)。
  • 缺點: 必須維護格式之間的轉換工具,且往返轉換 (round-tripping) 並非總是無損的。

對於評估是否採用 CIM 的架構師來說,實際問題在於您的整合表面是否由「共享」業務實體主導。如果大多數映射是一次性的且特定於領域,則規範模型會增加開銷。如果您在多個系統中重複映射相同的少數實體,則 N×1 的簡化將帶來顯著效益。

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

雲端資訊模型工作小組

目前,CIM 有一個工作小組,負責定義新的主題領域、映射和 API 要求。

主題領域 (Subject Area) 是模型的連貫切片——例如,圍繞某個業務領域的實體和關係分組。提出主題領域是成員可以做出的最有影響力的貢獻之一,因為它決定了標準接下來涵蓋的內容。映射將主題領域連接到現實世界的系統和格式;API 要求則捕捉消費者對基於該模型構建之服務的需求。

如果您正在考慮加入工作小組,決定貢獻方向的一個有用方法是詢問:

  1. 哪些實體在您的組織中導致最多的整合返工? 這些是提出主題領域提案的候選對象。
  2. 您的系統在哪些方面已經達成一致,在哪些方面默默地存在分歧? 分歧之處正是映射能增加最大價值的地方。
  3. 您的下游消費者實際上需要從 API 取得什麼? 這將決定 API 的要求。

由於目前只有一個工作小組,因此新貢獻者的實際路徑通常是加入該工作小組並提出一個主題領域 (Subject Area),而不是組成一個新小組。提議設立「新」工作小組是為較高層級保留的權利,且最好保留給真正截然不同的工作領域,否則會使現有工作小組負擔過重。

會員等級與福利

CIM 的參與分為層級,每個層級擁有的權利逐漸擴大。下表總結了 CIM 發布的福利。

福利指導會員 (Steering Member)貢獻者 (Contributor)CIM 社群 (CIM Community)
使用 CIM 模型發佈版本✓✓✓
隨時了解 CIM 進展與創新✓✓✓
向 CIM 聯盟貢獻想法✓✓✓
可提出主題領域✓✓✓
存取受限與私人資源✓✓
有資格加入工作小組✓✓
為工作小組做出貢獻✓✓
提議新的工作小組✓✓
計入主題領域的最低支持法定人數✓✓
參與共識投票✓✓
為 CIM 路線圖做出貢獻✓✓
推動 CIM 的整體策略方向✓
有資格加入指導委員會✓
有資格擔任工作小組主席職位✓
有資格投票採用內容作為 CIM 標準的一部分✓
可就技術問題提出上訴✓
可就程序問題提出上訴✓

*指導會員申請 — 貢獻者會員可以申請指導會員資格。

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

如何閱讀等級

這些層級對應於 Linux 基金會專案中常用的開源治理模式:一個可以使用輸出並貢獻想法的廣泛社群、一個負責實際工作的貢獻者層級,以及一個掌控策略與正式採用的指導層級。在實踐中最重要的區別是:

  • CIM 社群 是進入點。您可以採用已發布的模型並貢獻想法,而無需正式的工作角色。如果您正在為某個專案評估 CIM 或希望以非正式方式影響方向,這將非常合適。
  • 貢獻者 是技術影響力所在。加入工作小組、為其做出貢獻、提出主題領域以及參與共識投票都屬於此層級。如果您的目標是塑造標準而不僅僅是使用它,那麼這就是您應該追求的層級。
  • 指導會員 擁有治理權利:策略方向、指導委員會資格、工作小組主席資格,以及將內容正式投票採納為 CIM 標準一部分的權利。貢獻者會員可以申請指導會員資格。

一個微妙但重要的細節:「計入主題領域的最低支持法定人數」是貢獻者及以上層級的權利。法定人數規則的存在是為了確保某個主題領域不會僅憑單一參與者的力量而被採用——這是基於共識的標準機構中常見的治理保障措施。如果您的組織在意某個特定主題領域能否被採納,那麼擁有貢獻者層級的參與才能讓您計入該門檻。

如何參與:實用途徑

如果您是 CIM 新手,合理的順序是:

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

  1. 從 CIM 社群開始。 查看已發布的模型和 FAQ,並確定您的系統實體與 CIM 主題領域重疊之處。
  2. 貢獻想法。 即使在社群層級,您也可以向 CIM 聯盟提出想法——這是一種測試您的用例是否引起共鳴的低承諾方式。
  3. 如果您想實際參與工作,請轉為貢獻者。 這將解鎖工作小組參與、主題領域提案和共識投票。
  4. 如果您的組織希望幫助設定方向並參與正式採用投票,請申請指導會員資格。

特別是對於開源貢獻者來說,模型的格式中立性意味著除了模型內容本身之外,還有空間貢獻工具(如格式轉換器、驗證器、映射產生器)。對於平台和應用程式供應商而言,將產品的 schema 對應到 CIM 是降低客戶整合成本的一種方式,這通常是一個競爭優勢。

治理、標準與上訴

CIM 遵循基於標準的方法,這意味著有一套定義明確的內容提案、審查和採用流程。在指導層級擁有正式的「上訴」權(包括技術和程序上訴)是成熟標準治理的標誌。這意味著爭議有明確的解決路徑,而非以非正式方式解決。

這反映了成熟標準組織的運作方式。Linux 基金會主辦了許多此類專案,並提供法律和治理框架(包括商標、IP 和反壟斷政策),使競爭對手能夠在共享基礎設施上協作。如果您正在評估企業級採用 CIM,Linux 基金會的隸屬關係是一個有意義的信號:這意味著該模型由中立的基金會管理,而非由單一供應商擁有,從而降低了未來許可或方向變更的風險。

相關資訊

  • 常見問題
  • 會員費
  • 目前 SteerCo 成員名單
  • 貢獻者網頁表單
  • CIM 模型資源
  • CIM 簡報
  • CIM 格式
  • CIM 新聞
  • GitHub 儲存庫
  • 新聞部落格
  • 聯絡方式

常見問題

什麼是雲端資訊模型?

雲端資訊模型 (CIM) 是 Linux 基金會於 2019 年成立的一個開放數據模型與成員社群。它定義了一個通用的、與應用程式無關的業務實體模型,以便雲端和地端系統可以透過共享語義,而非自訂的點對點映射來實現互通。

誰可以加入 CIM,費用是多少?

CIM 具有三個參與層級:指導成員 (Steering Member)、貢獻者 (Contributor) 和 CIM 社群 (CIM Community)。社群層級是最廣泛的進入點,而貢獻者成員可以申請指導成員資格。會員費由 CIM 單獨公布,因此請參閱「會員費」頁面以獲取最新金額,而非自行假設成本。

CIM 中的主題領域是什麼?

主題領域 (Subject Area) 是模型中一個連貫的切片,涵蓋一組相關的實體與關係。提議主題領域是貢獻者層級的權利,也是影響標準涵蓋內容最直接的方式之一。主題領域還受到最低支持法定人數 (quorum) 的限制,以防止僅基於單一參與者的意願而採納。

我需要成為指導成員才能做出貢獻嗎?

不需要。貢獻者成員可以加入工作小組、為其做出貢獻、提議主題領域並參與共識投票。指導成員資格則增加了治理權利,例如決定策略方向、獲得指導委員會資格,以及對採納內容作為 CIM 標準一部分的正式投票權。

CIM 與其他資料標準有何關係?

CIM 是一種專注於通用業務實體的橫向跨行業模型,與特定領域的規範模型(例如能源部門的通用資訊模型 IEC 61970/61968 或醫療保健的 HL7 FHIR)形成對比。其格式中立的設計使其能補充而非取代您現有系統的原生模型。

為什麼格式中立對於採納很重要?

因為它允許使用不同技術堆疊(關聯式資料倉儲、圖形資料庫和 API 服務)的團隊使用單一的規範定義,而不需要維護分歧的結構描述 (schemas)。權衡之處在於必須維護轉換工具,且格式之間的往返轉換並不總是無損的,因此團隊應根據其實際的整合需求來驗證映射。

進一步閱讀

常見問題

什麼是雲端資訊模型?

雲端資訊模型 (CIM) 是 Linux 基金會於 2019 年成立的開放資料模型和成員社群。它定義了一個通用的、與應用程式無關的業務實體模型,以便雲端和本地系統可以透過共享語義而不是自訂的點對點映射進行互通。

誰可以加入 CIM,費用是多少?

CIM 有三個參與層級:指導成員、貢獻者和 CIM 社群。社區層是最廣泛的切入點,而貢獻者會員可以申請指導會員資格。會員費由 CIM 單獨公佈,因此請參閱會員費頁面以了解當前數據,而不是假設成本。

CIM 中的學科領域是什麼?

主題區域是模型的連貫部分,涵蓋一組相關實體和關係。提議主題領域是貢獻者層級的權利,也是影響標準涵蓋內容的最直接方法之一。主題領域也受到最低支持法定人數的限制,這防止了基於單一參與者的採用。

我需要成為指導成員才能做出貢獻嗎?

不需要。貢獻者成員可以加入工作小組、為工作小組做出貢獻、提出主題領域並參與共識投票。指導會員資格增加了治理權利,例如策略方向、指導委員會資格以及正式投票採納內容作為 CIM 標準的一部分。

CIM 與其他資料標準有何關係?

CIM 是一種專注於常見業務實體的橫向跨行業模型,與能源部門的通用資訊模型 (IEC 61970/61968) 或醫療保健的 HL7 FHIR 等特定領域的規範模型形成鮮明對比。其格式中立的設計使其能夠補充而不是取代您已運行的系統的本機模型。

為什麼格式中立對於採用很重要?

因為它允許具有不同技術堆疊(關係倉庫、圖形資料庫和 API 服務)的團隊使用一種規範定義,而不是維護不同的模式。權衡是必須維護翻譯工具,並且格式之間的往返並不總是無損的,因此團隊應該根據其實際整合需求來驗證映射。進一步閱讀 - [工作小組](https://en.wikipedia.org/wiki/Working_group) — 維基百科 - [Linux 基金會](https://en.wikipedia.org/wiki/Linux_Foundation) — 維基百科


了解 Boomi 如何處理您的混合整合地圖

用於雲端到本地混合整合的企業 iPaaS