コンテンツにスキップ
SteveTechArcSteveTechArc Courses

つなぐことはマスター管理ではない

ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Data Architectコース第6章、第1部：データアーキテクトになる。前へ：データの品質とガバナンス。

「信頼できる唯一の情報源が必要です」。アーキテクチャで最もよく繰り返され、最も検討されていない言葉の一つです。何についての？　一つの取引先を例にとりましょう。ERPがその正式名称、請求先住所、与信限度額を所有し、Salesforceが担当の営業責任者とサポートの階層を所有し、同意管理のプラットフォームがマーケティングの好みを所有しているかもしれません。一つのレコードに3つの権威、そしてそれは普通のことです。ですから誰かが「Salesforceが顧客についての私たちの唯一の情報源です」と言ったら、私の次の問いはいつもこうです。どの真実ですか？

この章は、その問いに意図的に答えることについての章です。権威は属性ごとに割り当てられる。 レコードをつなぐことは、それをマスター管理することではありません。そしてSalesforceは、仕事ごとに違う道具を与えてくれます。一つの組織の中では重複管理とマージ。複数のソースをまたぐ一つの見方にはData 360のID解決。値を一度決めてあらゆる場所に送り返さなければならないときには、専用のMDMプラットフォーム。最後はチェックポイント1で、第1部がSteve Truckingの上で一つにまとまります。

アーキテクトとERPの担当者が、一つの顧客レコードを、項目ごとにそれを所有するシステムで色分けしていく

画像はAIで生成しました。

この章の立場

Section titled “この章の立場 ”
  • 属性ごとの真実。 それぞれのデータがどこで作成され、編集され、参照され、どれくらい速く変わるのかを問う。外部の権威は、sap_やerp_のようなシステムの接頭辞でスキーマに示す。
  • 見込み客は違う。 ERPが知る前からSalesforceにいる。ERPの権威は変換の後に適用される。
  • Salesforceのプロジェクトではレジストリ型が普通で、 次にコンソリデーション型と共存型。純粋な集中型MDMはまれ。
  • 勝者がはっきりしているときだけマージする。 さかのぼる必要があるかもしれないなら、外部からのロードの重複は残しておく。マージはその履歴を壊す。そして子レコードをどうするかを決める。移すのか、ロードしないのか、非アクティブなレコードに残すのか。
  • 統合プロファイルは地図であり、ゴールデンレコードは判断である。 ここは混乱しやすいところです。ID解決は統合された個人を作りますが、ゴールデンレコードは作りません。
  • 照合の厳しさはリスクの判断である。 混ぜ合わせると高くつくところでは、意図的に照合を控えめにする。
  • 3つの仕事に3つの道具： マージ、ID解決、MDM。
  • 階層は複数のマスターを持つ。 権威は枝ごとに決める。
  • 「一番難しいのは双方向の連携だ」。 双方向の連携が、2つのマスターを生むわけではない。最初の衝突が起きる前に、どの項目を一つのトランザクションとして一緒に動かすかを決める。
  • マスターデータを見えるようにする。 編集できるかどうかを決めるのは、これがマスターデータだと示す項目（ERPのキーやフラグ）であって、レコードタイプではない。
  • 私たちはERPを制御できない。 制御できるのは、それをSalesforceでどう表すかだ。2つのERPにいる一人の顧客は、階層にするのか、対等なレコードにするのか、ERPごとに子を持つ一つの取引先にするのか。それは、クライアントがERP同士をどれだけ同期させているかで決まる。

3つの仕事に3つの道具

Section titled “3つの仕事に3つの道具 ”
仕事道具ソースに何をするか
一つの組織の中の重複で、勝者がはっきりしている重複管理とマージ最大3つのレコードをマージし、ほかはごみ箱へ
複数のソースをまたぐ一つの識別と一つの見方Data 360のID解決つなぐが、どれも変えない（レジストリ）
統制された一つの値を、すべてのシステムに送り返す専用のMDMプラットフォーム値を決めて配布する（共存型または集中型）

この章の道筋

Section titled “この章の道筋 ”

6つのモジュールと一つの課題があり、それぞれ単独でも読めます。

  1. 属性ごとに一つの真実の源。 権威の地図、ハイブリッドなゴールデンレコード、そして信頼の兆候。
  2. データをマスター管理する4つの方法。 レジストリ型、コンソリデーション型、共存型、集中型。そして共通のモデルが共通の真実ではない理由。
  3. 照合、マージ、サバイバーシップ。 誤った照合のコスト、Salesforceのマージが実際に何をするのか（そして子レコードに何が起きるのか）、そして信頼についての表明としてのサバイバーシップ。
  4. 地図は判断ではない。 一致ルールと一致方法、調整ルール、そして統合プロファイルがゴールデンレコードではない理由。
  5. 権威が共有されるとき。 依頼と更新の違い、ループと衝突、複数のマスターを持つ階層、そして2つのERPにいる一人の顧客。
  6. チェックポイント1の課題、 そして**チェックポイント1：Steve Trucking、私ならこう設計する。** まず課題に取り組んでください。第1部の設計を描いて弁護し、それから私のものと比べ、第4章のシステム全体像から何が変わるかを見てみましょう。

読み終えたら、章の学習ガイドで理解度を確認しましょう。試験のためのチェックリスト、試験の先にある習慣、覚えておきたい用語、そしていくつかの問いがあります。これで第1部が終わります。第1部の学習ガイドが6つの章をまとめています。

ここでアーキテクトが決めること

Section titled “ここでアーキテクトが決めること ”
  • 重要な属性のそれぞれについて、どのシステムが権威を持つか。 そしてそれがモデルにどう表れるか。
  • それぞれのデータ領域にどのマスター管理のスタイルが合うか。 そしてマスター管理の層にどれだけの権威を与えるか。
  • いつマージし、いつつなぐか。 そして誰がそれぞれのサバイバーシップのルールを所有するか。
  • 照合をどれくらい厳しくすべきか。 誤った照合のコストに基づいて。
  • 双方向のデータと共有された階層に、どこで明示的な境界が必要か。

試験の先へ： エージェントには行動の対象となる一つの識別が必要で、それは両方向に賭け金を引き上げます。照合しすぎればプライバシーのインシデントになり、「顧客を更新する」エージェントは、統合プロファイルではなく、それぞれの属性の記録システムに書き込まなければなりません。各モジュールの最後で、AIが何を変えるかを扱います。

さらに学ぶ

Section titled “さらに学ぶ ”

次へ： 第2部は大規模に向けた設計 *(coming soon)*から始まります。