信頼できる唯一の情報源
上記のようなSSOTの「理想的な」実装は、ほとんどの企業でまず不可能である。これは、多くの組織が複数の情報システムを持っており、それぞれのシステムが同じ実体(顧客など)に関連するデータにアクセスする必要があるためである。多くの場合、これらのシステムはベンダーから既成のまま購入されており、自明な方法で変更することはできない。各システムはそれぞれ、独自のバージョンの共通データまたは実体を格納する必要があるため、独自にレコードのコピーを保持する必要がある(したがって、上記で定義されたSSOTアプローチに直ちに違反する)。例えば、ERP(エンタープライズリソースプランニング)システム(SAPやOracle e-Business Suiteなど)は顧客レコードを保存するかもしれない。一方、 CRM(顧客関係管理)システムにも顧客レコード(またはその一部)のコピーが必要であり、倉庫発送システムにも顧客データの一部またはすべて(出荷先住所など)のコピーが必要な場合がある。ベンダーが変更をサポートしていない場合、これらのレコードを SSOT へのポインターで置き換えることが常に可能であるとは限らない。
複数の情報システムがあるような組織で、信頼できる唯一の情報源を実装したい場合、次の4つのサポートアーキテクチャが一般的に使用される。
エンタープライズサービスバス(ESB)
マスターデータ管理(MDM)
データウェアハウス(DW)
サービス指向アーキテクチャ(SOA)
エンタープライズサービスバス(ESB)を使用すると、組織内の任意個のシステムが、別のシステムで変更されたデータの更新を受信できる。信頼できる唯一の情報源を実装するには、任意の実体に対して、正しいデータソースを特定する必要がある。この実体への変更(作成、更新、および削除)は、ESB を介して公開される。そのデータのコピーを保持する必要がある他のシステムは、この更新を購読し、それに応じて独自のレコードを更新する。任意の実体について、マスターとなるデータソースを特定する必要があり、これはしばしばゴールデンレコードと呼ばれる。任意のシステムは、特定の実体(顧客など)に関する情報を公開することもできるし、他の実体(製品など)に関する情報について別のシステムからの更新を購読することもできる。
別のアプローチとして、ポイントツーポイントのデータ更新があげられる。しかし、システムの数が増えるにつれて指数関数的にコストがかかるため、このアプローチはITアーキテクチャとしては支持されなくなっている。