クラウド情報モデル

CIM へようこそ。CIM は、統合を簡素化し、イノベーションを加速するアプリケーションに依存しない（application-agnostic）データモデルです。

重要なポイント

• CIM は、オープンでアプリケーションに依存しないデータモデル です。ビジネス概念（顧客、注文、製品など）の共有ボキャブラリーであり、これにより、特注のポイントツーポイントマッピングを行わずに、さまざまなクラウドシステムとオンプレミスシステムがデータを交換できるようになります。
• これは、特定のコストのかかる問題を解決するために存在します。 すべてのアプリケーションが独自のデータモデルを搭載しているため、統合チームは、脆弱でイノベーションを遅らせるカスタム変換コードを作成し、保守することになります。
• これはオープンスタンダードとして管理されており、コンソーシアムによって作成され、Linux Foundation の一部である Joint Development Foundation の下でオープンソース化されているため、誰でも貢献、レビュー、採用することができます。
• コンテンツはサブジェクトエリア（ドメイン） に編成されており、それぞれが主要なビジネス概念を表しています。設計は、例示図を含む複数の形式で公開されています。
• CIM は製品ではなくモデルです。 CIM は意味と構造を定義します。独自のシステム内でデータをどのようにマッピング、保存、移動するかは、引き続きユーザーが選択します。

データ相互運用性の新しい標準

CIM は、エンタープライズ製品を接続するための標準ベースのソリューションを提供するために設立されたオープンコンソーシアムによって作成されています。CIM を使用すると、クラウドネイティブアプリケーション全体で、シームレスでカスタマイズされたパーソナライズドエクスペリエンスを作成できます。

デジタルトランスフォーメーションを加速し、あらゆるチャネルにわたって顧客にパーソナライズされたエンゲージメントを提供するために、多くの企業が複数のクラウドおよびオンプレミスアプリケーションを採用しています。それぞれに独自のデータモデルが付属しており、開発者は、異なるシステム間でデータをマッピングおよび変換するために必要なカスタムコードを構築、テスト、管理せざるを得ません。このプロセスは、デジタルトランスフォーメーションを加速させるどころか、イノベーションを遅らせ、統合の脆弱化を招きます。

CIM は、データ統合の苦痛を軽減するための最新のオープン仕様です。CIM は、異なるデータ形式間で簡単に通信するための定義された標準を提供します。Joint Development Foundation（Linux Foundation の傘下）の一部としてオープンソース化されており、あらゆる貢献者を歓迎します。

アプリケーション固有のデータモデルが破綻する理由

CIM が対処する根本的な問題は、単一のアプリケーションが不適切なデータモデルを持っているということではありません。ほとんどのモデルは、その境界内では完全に合理的です。問題は、それらを多数接続したときに起こる組み合わせの爆発です。

典型的なエンタープライズスタックを考えてみましょう。CRM、ERP、マーケティングオートメーションプラットフォーム、サポートデスク、データウェアハウス、そしていくつかの部門別 SaaS ツールです。各システムが「顧客」、「アカウント」、「注文」、「製品」について独自の概念を持っている場合、データを共有する必要があるシステムのすべてのペアに、それぞれ独自のマッピングが必要になります。統合の数はシステム数のほぼ2乗で増加し、各マッピングは文書化されておらず、所有者もいない小さなロジックとなり、誰かが永久に保守しなければなりません。

関連: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

この症状は、統合の実務に携わったことがある人なら誰でも馴染みがあるはずです。

• セマンティックドリフト（意味の乖離）。 CRM における「顧客」は請求先エンティティを意味し、サポートデスクではチケットを提出する人を意味します。同じ単語に2つの意味があり、誰も書いたことを覚えていないマッピングによって、静かに調整されています。
• 脆弱なパイプライン。 ベンダーがフィールド名を変更したり列挙型（enum）を変更したりすると、マッピングが古い形式に対してハードコードされていたため、午前2時に ETL ジョブが失敗します。
• 作業の重複。 参照すべき共有リファレンスがないため、2つのチームが同じ2つのシステム間でほぼ同一の変換処理を個別に構築します。
• データによるベンダーロックイン。 プラットフォームからの移行に費用がかかるのは、ソフトウェアのせいではなく、そのスキーマに紐付いた蓄積された変換ロジックのためです。

アプリケーションに依存しない共有モデルは、この根本原因を解決します。N対Nのマッピングの代わりに、各システムは一度だけ共通モデルにマッピングされ、共通モデルが意味を担います。

「アプリケーションに依存しない」とは実際には何を意味するのか

「アグノスティック（agnostic）」という言葉は曖昧に使用されることが多いため、設計哲学について正確に定義する価値があります。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

アプリケーションに依存しないモデルは、単一のベンダー製品によって所有されておらず、また特定の製品用に最適化されていません。ビジネス概念を、あるアプリケーションの内部テーブルを反映した形式ではなく、ドメインエキスパートが認識できる用語（顧客、注文、製品、場所など）で記述します。その中立性こそが、それを有用な「ハブ」にするのです。相互運用するために、参加者が競合他社の世界観を採用する必要はありません。

これは、他の中立的な交換標準の背後にあるものと同じアーキテクチャ上の本能です。Resource Description Framework (RDF) と schema.org が Web に物事を記述するための共有ボキャブラリーを提供し、EDI とその後の UBL (Universal Business Language、OASIS 標準) がサプライチェーンにトランザクションの共有形式を提供したのと同様に、CIM はエンタープライズアプリケーションに中核的なビジネスエンティティの共有ボキャブラリーを提供することを目指しています。違いはスコープと現代性です。CIM は、バッチファイル交換ではなく、接続された API 駆動のクラウドおよびオンプレミスの世界をターゲットにしています。

有用なメンタルモデルは、Gregor Hohpe と Bobby Woolf の Enterprise Integration Patterns で普及した、エンタープライズ統合の カノニカルデータモデル (canonical data model) パターンです。実際、CIM は共同で維持されるカノニカルモデル（ハブアンドスポーク統合トポロジにおける「ハブ」）ですが、1つの企業内で非公開に作成されたものではなく、オープンでバージョン管理され、組織間で共有されるものです。

CIM の構成：サブジェクトエリアとドメイン

共同で定義されたコンテンツは、ドメイン、すなわち サブジェクトエリア に編成されます。各サブジェクトエリアは主要なビジネス概念を表します。CIM の設計は、例示図を含め、ドメインごとに複数の形式で利用可能です。サブジェクトエリアの数と範囲は、コンソーシアムの拡大と貢献に応じて増加していきます。

実際には、これは CIM を単一のモノリシックなスキーマではなく、関連モデルのライブラリ として考えるべきであることを意味します。典型的なサブジェクト領域は、当事者（party）とアカウント、製品とカタログ、注文と取引、およびそれらを結び付ける関係など、認識可能なビジネス上の関心事を中心に構成されています。各領域はダイアグラムと機械可読な定義とともに公開されるため、モデル全体が完成するのを待つことなく、異なるチームが異なるタイミングで異なる領域を採用できます。

この構造から、いくつかの実務上の影響が導き出されます。

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

• 段階的に導入する。 初日からエンタープライズ全体を CIM にマッピングする必要はありません。最も課題となっているサブジェクト領域（通常は顧客または注文ドメイン）から始めて、徐々に拡大してください。
• フォークではなく拡張する。 CIM に必要な概念が不足している場合、このオープンモデルは拡張できるように設計されています。プライベートフォークを維持すると、乖離（ドリフト）が生じて相互運用性のメリットが失われるため、拡張機能を還元（コントリビュート）することが好ましいです。
• ダイアグラムは正解（source of truth）ではなく、ドキュメントとして扱う。 例示されたダイアグラムは人間向けであり、ツールが消費すべきなのは機械可読な定義です。

統合ランドスケープにおける CIM：決定方法

CIM は、統合の複雑さを制御するためのいくつかの選択肢のうちの 1 つです。適切に選択するには、問題に合わせてツールを選ぶ必要があります。以下の表は、エンタープライズデータアーキテクトが通常検討する主なアプローチを対比したものです。

アプローチ	内容	最適なケース	主なトレードオフ
ポイントツーポイントマッピング	2 つのシステム間で直接変換するカスタムコード	システムが 2 つのみ、スキーマが安定しており、短期間の運用である場合	スケールしない。N対Nの爆発的増加。脆弱
カノニカルモデル (CIM など)	各システムが一度だけマッピングする共有の中立モデル	システム数が多く、ベンダーを跨ぎ、長期的な統合が必要な場合	事前のモデリング工数。ガバナンスが必要
ベンダー iPaaS コネクタ	統合プラットフォームが提供する事前構築済みコネクタ	一般的な SaaS の組み合わせ、制御よりも速度を優先する場合	コネクタ固有のセマンティクス。潜在的なロックイン
業界標準インターチェンジ (EDI, UBL, HL7 など)	ドメイン固有のメッセージ形式	規制がある、または確立された垂直市場（バーティカル）	範囲が狭い。多くの場合バッチ指向
データ仮想化 / フェデレーション	中央集約せずにソースを跨いでクエリを実行	分析、読み取り主体のアクセス	セマンティックな競合を単独では解決できない

決定のヒューリスティックは単純です。共有エンティティの意味について合意しなければならないシステムが数個以上あり、かつそれらが異なるベンダーのものである場合、カノニカルモデルを導入する価値は十分にあります。 システムが 2 つだけで、今後増える予定がないのであれば、ポイントツーポイントで十分です。ニーズが純粋に分析的で読み取り専用であれば、フェデレーションで事足りるかもしれません。ただし、フェデレーションはセマンティックな問題を解決するのではなく、単に問題を移動させているだけであることに注意してください。

CIM は周囲のツールに代わるものではなく、それらを補完するものです。ETL または ELT パイプライン（Apache Airflow、dbt、または商用プラットフォームなどで構築されたもの）が引き続きデータの移動を担い、CIM はデータが到着した後のデータの意味を定義します。Apache Kafka などのメッセージブローカーが引き続き転送を担い、CIM はイベントの形状を定義します。モデルが「契約」であり、ツールが「配管」です。

どこから始めましょうか: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

ガバナンス、ライセンス、そして財団が重要な理由

CIM は、Linux Foundation の傘下で運営される Joint Development Foundation の一部としてオープンソース化されています。これは些細な詳細ではなく、企業が安心して CIM を基盤に構築できる中心的な理由です。

Linux Foundation は、コラボレーティブなオープンソースプロジェクトのための確立された中立的な拠点であり、Joint Development Foundation は、標準や仕様を共同で開発するための軽量な法的枠組みを提供します。CIM がそこでホストされていることは、以下を意味します。

• 中立的な管理。 単一のベンダーがモデルを支配することはないため、CIM の採用がそのまま競合他社のロードマップを採用することを意味しません。
• オープンな貢献。 ベンダー、企業、個人の貢献者など、誰でも変更を提案でき、そのプロセスは透明です。
• 予測可能なライセンス。 財団がホストする仕様は通常、広範でロイヤリティフリーな採用を目的とした条件となっており、これは標準を評価する法務や調達チームにとって極めて重要です。

社内で提案を行うアーキテクトにとって、このガバナンスの話は技術的な内容と同じくらい重要である場合が多いです。「Linux Foundation 下のオープン標準である」という説明は、標準の採用を阻む問い（誰が管理しているのか？ ベンダーが撤退したらどうなるのか？ 自社の拡張機能を還元できるか？）に対する答えになります。

はじめに：実践的な導入パス

共有モデルの採用は、技術的な取り組みであると同時に組織的な取り組みでもあります。現実的な手順は以下の通りです。

1. 共有エンティティのインベントリを作成する。 複数のシステムに現れるビジネス概念（通常は顧客、製品、注文、場所）を特定します。これらが候補となります。
2. 1 つのサブジェクト領域と 1 つの統合を選択する。 モデルを検証するため、最も課題が大きく、かつ影響範囲（blast radius）が小さい統合を選択します。単一のレポートパイプラインや、1 つの新しいアプリケーションのオンボーディングが理想的です。
3. 各システムを一度だけ CIM にマッピングする。 各ソースシステムから CIM 表現へ、および CIM から各ターゲットへの変換を構築します。システム間を直接マッピングしたいという衝動を抑えてください。
4. 拡張機能を文書化する。 CIM でカバーされていない概念がある場合は、その拡張を明示的に記録し、還元することを検討してください。
5. 所有権を確立する。 管理者がいないカノニカルモデルは形骸化します。マッピングの管理と上流の変更追跡を担当するチームまたは役割を割り当ててください。
6. バージョン管理とテストを行う。 アプリケーションコードと同様に、モデルとそのマッピングをテスト付きのバージョン管理された成果物として扱ってください。

最も一般的な失敗パターンは、CIMを「生きた契約」ではなく、一度限りのモデリング作業として扱うことです。成功している組織は、APIを扱うのと同じように、モデルをバージョン管理し、テストし、所有し、意図的に進化させています。

CIMに貢献するパートナー

CIMはコンソーシアムによる取り組みであり、その価値は参加者が増えることで高まります。パートナーは、サブジェクトエリア（Subject Area）のコンテンツを提供し、提案をレビューし、モデルの方向性の形成を支援します。この取り組みはオープンであるため、貢献は大手ベンダーに限定されません。実際の統合に課題を抱えている企業や、ドメインの専門知識を持つ個人の実践者も同様に歓迎されます。

お問い合わせ

CIMイニシアチブへの参加にご興味がありますか？ぜひ、詳細についてお気軽にメールでお問い合わせください。メールでお問い合わせください。

よくある質問

クラウド情報モデル (CIM) とは何ですか？

CIMは、アプリケーションに依存しないオープンソースのデータモデルであり、企業がクラウドおよびオンプレミスのアプリケーション間で交換する必要があるビジネス概念について、標準に基づいた共有ボキャブラリーを提供します。これはオープンコンソーシアムによって作成され、Linux Foundationの一部であるJoint Development Foundationの下でホストされています。その目的は、脆弱なポイントツーポイント統合で必要となるカスタムマッピングコードを削減することです。

CIMは製品ですか、それとも仕様ですか？

CIMは仕様（モデルと定義のセット）であり、実行可能な製品ではありません。CIMは共有エンティティの意味と構造を定義します。ETL/ELTツール、メッセージブローカー、ストレージは、引き続きご自身で選択していただきます。配管そのものではなく、統合という配管が実装すべき「契約」であると考えてください。

CIMはベンダーの統合プラットフォームとどう違うのですか？

統合プラットフォーム（iPaaSやコネクタライブラリ）はデータを移動させ、多くの場合、構築済みのコネクタを提供しますが、それらのコネクタにはベンダー固有のセマンティクスが組み込まれています。CIMは中立的でベンダーに依存しないため、特定のプラットフォームの世界観に縛られることはありません。この2つは補完的な関係にあり、あらゆる統合プラットフォーム内でCIMをカノニカルモデル（標準モデル）として使用できます。

CIMのサブジェクトエリアとは何ですか？

サブジェクトエリア（Subject Areas、またはドメインとも呼ばれます）はモデルの構成単位であり、それぞれが顧客、製品、注文などの主要なビジネス概念を表します。設計は例示図を含む複数の形式で公開されており、コンソーシアムやコミュニティによるコンテンツ提供に伴い、サブジェクトエリアのセットは拡大していく予定です。

CIMが自社の概念をカバーしていない場合、拡張することはできますか？

はい。CIMは拡張されるように設計されており、中立的な財団の下でオープンソースであるため、コントリビューションプロセスを通じて追加を提案できます。共有モデルを拡張して還元することは、プライベートフォークを維持することよりも強く推奨されます。プライベートフォークは時間の経過とともに乖離し、そもそもCIMを採用した動機である相互運用性のメリットを損なうためです。

CIMを導入すべきなのは誰ですか？

共有エンティティの意味について合意する必要がある、異なるベンダーの多くのアプリケーションを運用している組織にとって最も価値があります。これは、エンタープライズデータアーキテクトや統合エンジニアにとって典型的な状況です。また、アプリケーションおよびプラットフォームベンダーにとっても、自社のスキーマを中立的なモデルに合わせることで、顧客が製品を統合しやすくなるというメリットがあります。安定したシステムが2つしかない場合は、より単純なポイントツーポイントマッピングで十分かもしれません。

さらに読む

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia