金融業や通信業において、顧客に販売した個々の商品を管理する単位は「契約エンティティ」でした。契約エンティティのKEY（識別子）は、証書番号や保険番号あるいは電話番号です。昔はこれらのIDがあれば、契約の管理のみならず契約者や支払者を管理するのも簡単でした。
しかし、現在はそうではありません。複数種類の商品に関わる契約を横断して、顧客を名寄せできなければなりません。しかも「充分広い範囲で充分速く」です。契約IDや顧客名での名寄せは不正確であり、顧客に対して顧客IDを発番することが必須の条件になります。
経営戦略がそれを前提にしている以上、Tobeのエンタープライズデータアーキテクチャを設計しているとき、複数の契約にまたがる顧客IDを設けるのは当然です。
ところが、この種の顧客IDは、オーナとなるユーザが不在であったり、中途半端に実現された既存のIDがあるために実現が難しいことがあります。現時点で対応できないという理由で、「顧客IDを設けるのは将来的には必要だが今回は見送ろう」という意見が飛び出します。
データアーキテクチャのTobeの正しさは、経営戦略や新規業務要件を充足していることです。したがって、エンタープライズアーキテクトは「統合した顧客IDをどう実現するか」と知恵を出すことが重要です。できない理由を次々ともってくる反対派を納得させ、真に事業を支援するアーキテクチャを実現したいものです。
