データ基盤の「構成」には、実際のテクノロジーの依存関係を反映し、影響分析、トラブルシューティング、サービス マッピングなどの運用上のユース ケースをサポートする方法で CI 関係をモデル化することが含まれます。「アプリケーション サーバーがアプリケーションをホストする」シナリオでは、複数のアプリケーション サーバーが 1 つ以上のアプリケーションをホストできることが説明されています。ほとんどのエンタープライズ 環境では、その逆も真です。アプリケーションは、複数のアプリケーション サーバーにまたがってホストできます (たとえば、水平スケーリング、クラスタ デプロイメント、アクティブ / アクティブ アーキテクチャ、同じアプリケーションの異なる階層またはコンポーネント用の別々のサーバーなど)。
両方の側が複数の関連レコードを持つことができるため、正しい論理関係は多対多です。
* 1台のアプリケーションサーバーで複数のアプリケーションをホストする
* 1つのアプリケーションを複数のアプリケーションサーバーでホストできます。
ServiceNow CMDBでは、多対多の関係はCMDBリレーションシップモデル（親子関係）によって表現され、プラットフォームはサーバーとアプリケーションをリンクする複数のリレーションシップレコードを、不自然な単一参照制約を課すことなく保存できます。これにより、CMDBの品質が向上し、特にインシデントトリアージ（「このサーバーがダウンした場合、どのアプリケーションが影響を受けるか？」）や変更影響分析（「このアプリケーションコンポーネントを変更した場合、どのサーバーが影響を受ける可能性があるか？」）において、より強力な成果が得られます。
一対多または多対一のモデルでは、サーバーを一つのアプリケーションに限定したり、アプリケーションを一つのサーバーに限定したりすることになり、一般的なホスティングパターンと合致しないため、CMDBの有用性と精度が低下します。

ミドルウェアは、適切なサービス抽象化と依存関係マッピングをサポートするために、アプリケーションサービスとしてモデル化されるべきである。

データ基盤において、「ガバナンス」には、運用プロセスと資産ライフサイクルプロセスが信頼できる状態を維持できるよう、密接に関連するデータドメイン間の一貫性を維持することが含まれます。ハードウェアエンドポイント（およびその他の資産担保アイテム）の場合、資産レコードとCIレコードは、多くの場合、財務的観点と、財務的観点という2つの観点から、同じ現実世界のアイテムを表します。
ライフサイクル管理（資産）と運用／サービスコンテキスト（構成アイテム）を同期します。自動同期により、資産と構成アイテムで所有者、場所、ステータスが異なるといったずれが生じ、レポートエラー、不適切な履行決定、監査上の問題が発生するのを防ぎます。
このプラットフォームは、アセットが変更されたときにCIを更新し、CIが変更されたときにアセットを更新する、標準搭載の同期ロジック（一般的にはビジネスルールと関連設定として実装される）による同期をサポートしています。これにより、どのチームがどのレコードを更新しても、レコードの整合性が維持されます。したがって、アセットからCIへの更新ロジック（A）とCIからアセットへの更新ロジック（B）の両方をアクティブにすることが、データを自動的に同期させるための正しい方法です。
オプションCは同期に必須ではありません。意図は、後で実行されるバッチジョブではなく、レコードの変更によって駆動されるほぼリアルタイムの一貫性です。他の保守作業のためにスケジュールされたジョブが存在する可能性はありますが、それらは資産/構成アイテムの同期を維持するための主要なメカニズムではありません。オプションDはデータ品質の原則として重要です（理想的には、物理​​的なアイテムに対して1つの資産が1つの構成アイテムにマッピングされます）が、「1対1のマッピングを保証する」こと自体は自動化メカニズムではありません。自動化はアクティブな同期ロジックによって実現されるため、AとBが正解となります。

識別ルールは、構成アイテム（CI）を一意に識別する方法を決定します。適切な識別基準（例：シリアル番号＋ホスト名）により、IREを介して複数のソース間で重複したCIが作成されることを防ぎます。

データ基盤部門は、技術的負債を削減し、アップグレードの安全性を向上させるため、可能な限りカスタムスクリプトではなく、標準搭載の同期メカニズムを使用することを強く推奨しています。このシナリオでは、エンドポイントデータがCIレコードに取り込まれており、資産管理チームは、資産管理プロセスに対応する資産レコードを自動的に同期させる必要があります。
推奨される方法は、アセットとそれに関連する構成アイテム（CI）間のフィールドをマッピングおよび同期するために特別に設計されたアセットCIフィールドマッピングを使用することです。「担当者」のマッピングルールを作成または更新することで、スクリプトを作成することなく、プラットフォームが制御されたサポート可能な方法で値を複製できるようになります。この方法は、標準構成、明確なガバナンス、最小限のカスタムコードといったベストプラクティスに合致しています。
オプションB（スクリプトによるビジネスルール）は技術的には機能しますが、保守リスク、テストのオーバーヘッド、およびアップグレード時の脆弱性といった問題が生じます。これは、標準機能が存在する場合にData Foundationsが警告しているまさにその種類の技術的負債です。オプションA（ドットウォーキング）はユーザーエクスペリエンスを変更し、アセットフィールドに実際に値を入力するわけではありません。派生値を表示するだけであり、アセットフィールドが設定されていることを想定したレポート作成、エクスポート、統合、またはライフサイクルワークフローなど、アセットチームのニーズを満たせない可能性があります。したがって、最も優れた自動化されたベストプラクティスソリューションは、アセットCIフィールドマッピングです。