クラウド情報モデル

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

重要なポイント

• CIM は共有のオープンデータモデルであり、製品ではありません。 共通のビジネス概念とその関係を定義することで、個別の使い捨てマッピングを作成することなく、異なるアプリケーション間でデータを交換できます。
• オープンスタンダードとして管理されています。 CIM は Linux Foundation の一部である Joint Development Foundation の下でオープンソース化されており、ベンダー、企業、およびより広範なコミュニティからの貢献者を歓迎しています。
• コンテンツはサブジェクトエリア（ドメイン）に整理されています。 各ドメインは主要なビジネス概念を表し、ダイアグラムを含む複数の形式で公開されているため、アーキテクトやエンジニアは段階的に導入できます。
• 核となる価値は、統合の脆弱性を軽減することです。 カノニカルモデル（正規モデル）は、ポイントツーポイントの変換コードを、多くのシステムがマッピング可能な安定したターゲットに置き換えます。
• 導入は設計上の決定であり、単なる切り替えではありません。 どのドメインを採用するか、ソースシステムをどのようにマッピングするか、そして時間の経過とともに拡張機能をどのように管理するかを選択します。

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

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

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

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

CIM が対処する問題は、偶発的なものではなく構造的なものです。すべてのシステムが独自の方言を話している場合（あるシステムは顧客を「連絡先（Contact）」と呼び、別のシステムは「当事者（Party）」、また別のシステムは「アカウント（Account）」と呼ぶなど）、統合チームは増大し続けるペアごとのマッピングの網を維持することになります。新しいアプリケーションが追加されるたびに必要な変換の数は倍増し、いずれか一つのシステムでスキーマ変更が行われると、それが波及して下流のパイプラインを破壊する可能性があります。カノニカルモデルはこの問題の構造を変えます。N 個のシステムが相互にマッピングし合うのではなく、各システムが共有語彙に一度だけマッピングすれば済むようになります。

ポイントツーポイント統合が破綻する理由

共有モデルの導入動機となる失敗モードを具体的に見てみましょう。

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

• 組み合わせ爆発的な増加。 ポイントツーポイントのマッピングでは、変換パスの数はシステム数のほぼ2乗で増加します。10番目のアプリケーションを追加するコストは、2番目を追加するよりもはるかに高くなります。
• セマンティックドリフト（意味の乖離）。 2つのチームが共に「顧客をマッピング」していても、顧客が個人なのか、組織なのか、あるいは請求関係なのかについて意見が一致しないことがあります。データは流れますが、意味が乖離していきます。
• 脆弱な変更管理。 1つのソースシステムでフィールド名が変更されたり、新しい必須属性が追加されたりすると、それに触れるすべてのコンシューマー側で修正を強制されます。
• ロジックの重複。 バリデーション、重複排除、およびアイデンティティ解決のルールが一度だけ定義されるのではなく、統合ごとに再実装されます。
• ベンダーロックインの圧力。 統合ロジックが特定のベンダーのスキーマと密結合している場合、ベンダーの切り替えや追加は再プラットフォーム化プロジェクトとなってしまいます。

CIM のようなカノニカルモデルは、マッピング作業を完全に排除するものではありません。すべてのソースシステムは依然としてモデルへのマッピングを必要とします。排除されるのは、その作業の「掛け算的な増加」です。システムごとに共有モデルへのマッピングを1つ構築すれば、モデル自体がシステム間の安定した契約（コントラクト）を提供します。

CIM の構成：サブジェクトエリア

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

このドメイン指向の構造は、導入において重要です。モデル全体を一度に必要とすることは滅多にありません。一般的な企業は、最も困難な統合に関わるドメインから開始してアプローチを実証し、徐々に拡大します。一般的な開始点は、ほぼすべてのシステムに登場する以下のような概念です：

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

• 当事者 / 顧客 (Party / Customer) — 取引先の個人や組織、およびそれらが果たす役割。
• 製品 (Product) — 販売、提供、または管理する対象（カタログや分類を含む）。
• アカウントと関係 (Account and relationship) — 当事者が製品、契約、および相互にどのように関連するか。
• インタラクションとアクティビティ (Interaction and activity) — 上記を結びつけるイベント、トランザクション、およびエンゲージメント。

各サブジェクトエリアはダイアグラムと複数の表現形式で公開されているため、アーキテクトは概念モデルをレビューでき、エンジニアは機械可読形式を利用でき、ビジネスステークホルダーは概念が現実と一致しているか検証できます。このマルチフォーマットアプローチは意図的な設計上の選択です。エンジニアにしか読めないモデルは、ビジネス上の意味から乖離する傾向があるためです。

CIM と他のアプローチとの比較

CIM は、相互運用性を実現するためのいくつかの選択肢のうちの一つです。最適な選択をするには、トレードオフを理解することが重要です。

アプローチ	概要	強み	トレードオフ
ポイントツーポイントマッピング	システムの各ペア間での直接変換	2つのシステム間ではシンプル。共有ガバナンスが不要	組み合わせ数に応じて爆発的に増加する。脆弱。ロジックが重複する
正規モデル (CIMスタイル)	各システムがマッピングされる、アプリケーションに依存しない共有ボキャブラリー	マッピングの手間が線形。安定したコントラクト。プロジェクト間で再利用可能	ガバナンスと合意が必要。システムごとのマッピングは引き続き必要
業界データ標準	特定のセクター（ヘルスケア、金融など）向けの垂直標準	ドメインを深くカバー。規制への準拠
ベンダーデータモデル	統合ハブとして公開されるプラットフォーム固有のネイティブスキーマ	ツールとの緊密な統合。単一ベンダーのエコシステム内では高速	ロックインのリスク。他のベンダーが一方の当事者のモデルに準拠する必要がある
APIファースト / スキーマオンリード	APIごとに定義されたコントラクト。消費時に意味を解決する	フレキシブル。すぐに開始できる	意味の一貫性は規律に依存する。大規模なガバナンスが困難

実践的なガイダンス：多数のシステム、クロスドメインの概念、および長期的な統合ランドスケープがある場合は、正規モデルを使用してください。スコープが実際に2つのシステムのみで、短期間である場合は、ポイントツーポイントを使用します。業界標準とCIMは補完的な関係にあります。垂直標準は特定のドメインに知見を提供し、CIMは横断的なエンタープライズボキャブラリーを提供します。

実際にCIMを導入する方法

導入は単一の移行ではなく、一連の意図的な決定の積み重ねです。実行可能なパターンは次のようになります：

1. 苦痛が大きく、境界が明確な統合を選択する。 マッピングの苦痛が顕著であり、かつ価値を迅速に証明できるほどスコープが十分に小さいドメインを選択します。
2. ソースシステムとそのスキーマのインベントリを作成する。 選択したサブジェクトエリアにおいて、各システムが概念をどのように呼んでいるか、およびどこで不一致があるかを文書化します。
3. 各システムをCIMドメインにマッピングする。 システムごとに共有モデルへのマッピングを1つ構築します。これらのマッピングは使い捨てのスクリプトではなく、バージョン管理された成果物として扱います。
4. 拡張ポリシーを事前に定義する。 CIMがまだカバーしていない概念をどのように扱うかを決定します。拡張は文書化し、一貫した命名を行い、広く有用である場合はコンソーシアムに提案されるべきです。
5. ガバナンスを確立する。 マッピングの所有権、変更のレビュープロセス、および上流のCIMアップデートとの同期頻度を決定します。
6. ドメインごとに拡張する。 最初のドメインで得られたマッピングパターンとガバナンスを再利用し、次のドメインへの導入コストを下げます。

2つの注意点を明確に述べておきます。第一に、正規モデルはレイヤーを追加するため、コストがゼロではありません。その見返りは単一の統合からではなく、多くの統合にわたる再利用から得られます。第二に、実際の作業の核心はマッピングにあります。モデルは安定したターゲットを提供しますが、各ソースフィールドがそれにどう対応するかを誰かが決定する必要があり、その決定にはエンジニアリングだけでなくビジネス側のインプットが必要です。

ガバナンス、ライセンス、および貢献

CIMは、Linux Foundationの下で運営されているJoint Development Foundationの一部としてオープンソース化されています。この構造は、導入を検討する企業にとって重要です。Linux Foundationは、協力的でベンダー中立なオープンソースプロジェクトの確立された拠点であり、Joint Development Foundationは、標準および仕様プロジェクトの開発と運用のために特別に設計された法的枠組みを提供しています。

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

エンタープライズデータアーキテクトにとって、このガバナンスモデルの実際的な意味は以下の通りです：

• ベンダー中立性。 単一のベンダーが仕様を支配しないため、モデルが特定のプラットフォームに有利なように形成されるリスクが軽減されます。
• オープンな貢献。 誰でも変更を提案できるため、単一のロードマップではなく、現実世界の統合ニーズを反映してモデルを進化させることができます。
• 仕様指向のプロセス。 Joint Development Foundationのモデルは仕様の作成と維持を中心に構築されており、これは調達やアーキテクチャレビューにおいて標準が採用・参照される方法と一致しています。

貢献は奨励されており、すべての人に開かれています。貢献は通常、新規または改良されたサブジェクトエリア、修正と明確化、例示図、および実際の統合プロジェクトからのフィードバックという形で行われます。最も価値のある貢献は、多くの場合、特定のマッピング問題に直面し、それを解決する概念を記述できる実践者からもたらされます。

参加方法

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

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

メール以外での自然な参加方法は、関心のあるドメインの公開済みサブジェクトエリアを確認し、自社システムの1つをドメインにマッピングしてみて、そこで見つかったギャップをコミュニティにフィードバックすることです。サブジェクトエリアの数と範囲はコンソーシアムと貢献によって拡大するため、モデルはユーザーがもたらす実際の統合問題の数に比例して改善されます。

よくある質問

クラウド情報モデル（CIM）とは正確には何ですか？

CIMは、アプリケーションに依存しないオープンデータモデルであり、共通のビジネス概念とその関係を定義することで、異なるアプリケーションが共有ボキャブラリーを通じてデータを交換できるようにするものです。オープンコンソーシアムによって作成され、オープン仕様として公開されています。インストールする製品ではなく、システムをマッピングするためのモデルです。

CIMは誰のためのものですか？

エンタープライズデータアーキテクト、統合およびETLエンジニア、アプリケーションおよびプラットフォームベンダー、そしてオープンソース貢献者を対象としています。異なるスキーマを持つ複数のクラウドシステムとオンプレミスシステムを接続する必要があるすべての人にとって、潜在的なユーザーとなります。ベンダーにとっては、共有モデルにより自社製品との統合に必要なカスタム作業が軽減されるため、メリットがあります。

CIMはどのように管理され、ライセンスが付与されていますか？

CIM は、Linux Foundation の下で運営されている Joint Development Foundation の一部としてオープンソース化されています。これにより、ベンダー中立で仕様指向のガバナンス フレームワークが提供されます。この構造は、モデルへの貢献をオープンに保ち、単一ベンダーの制御から独立させることを目的としています。

CIM はベンダーのネイティブ データ モデルとどう違うのですか？

ベンダーのネイティブ モデルは、そのベンダーの製品とエコシステムに最適化されています。これを統合ハブとして採用すると、ベンダーロックインが発生しやすくなります。CIM はアプリケーションに依存しない（application-agnostic）ように設計されているため、単一のプラットフォームが語彙を定義することはありません。トレードオフとして、ベンダー モデルはそのベンダーのツール内ですぐに使用できるのに対し、CIM はチーム間でのガバナンスと合意が必要になります。

CIM を使用する場合でもマッピングを記述する必要がありますか？

はい。すべてのソース システムにおいて、引き続き共有モデルへのマッピングが必要です。利点は、システムのペアごとに個別の変換を作成するのではなく、システムごとに 1 つのマッピングを CIM に対して記述すれば済むことです。これにより、組み合わせ的なマッピング作業がほぼ線形的な作業になり、個々のシステムの変更に影響されない安定したコントラクト（契約）を得ることができます。

CIM の導入を開始するにはどうすればよいですか？

まずは 1 つのサブジェクト領域（Subject Area）の中で、課題が多く、境界が明確な単一の統合から始めてください。ソース スキーマのインベントリを作成し、各システムを CIM ドメインにマッピングし、拡張機能とガバナンス ポリシーを定義し、マッピングをバージョン管理された成果物として扱います。最初のドメインで価値が証明されたら、確立したパターンとガバナンスを再利用して、ドメインごとに拡張していきます。

さらに読む

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia