Lewati ke konten

Menautkan Bukanlah Mengelola sebagai Master

Juga tersedia dalam 28 bahasa

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

Bab 6 dari Data Architect, Bagian 1: Menjadi Data Architect. Sebelumnya: Kualitas dan Tata Kelola Data.

“Kita butuh satu sumber kebenaran.” Itu salah satu ungkapan yang paling sering diulang dalam arsitektur, dan salah satu yang paling jarang diperiksa. Untuk apa? Ambil satu akun. ERP mungkin memiliki nama resmi, alamat penagihan, dan batas kreditnya; Salesforce memiliki account executive dan tingkat dukungannya; platform persetujuan memiliki preferensi pemasarannya. Tiga otoritas dalam satu rekaman, dan itu wajar. Jadi ketika seseorang berkata “Salesforce adalah satu sumber kebenaran kami untuk pelanggan,” pertanyaan saya berikutnya selalu: kebenaran yang mana?

Bab ini tentang menjawab pertanyaan itu dengan sengaja. Otoritas ditetapkan atribut demi atribut. Menautkan rekaman bukanlah mengelolanya sebagai master. Dan Salesforce memberi Anda alat yang berbeda untuk pekerjaan yang berbeda: manajemen duplikat dan penggabungan di dalam satu org; resolusi identitas Data 360 untuk satu tampilan lintas sumber; platform MDM khusus ketika nilai harus diputuskan sekali lalu dikirim kembali ke mana-mana. Bab ini diakhiri dengan Checkpoint 1, tempat Bagian 1 disatukan pada Steve Trucking.

Seorang arsitek dan pemilik ERP memberi kode warna pada satu rekaman pelanggan, bidang demi bidang, sesuai sistem yang memiliki masing-masing

Gambar dibuat dengan AI.

  • Kebenaran per atribut. Tanyakan di mana setiap potongan data dibuat, diedit, dan dirujuk, dan seberapa cepat ia berubah. Tunjukkan otoritas eksternal di skema dengan awalan sistem, seperti sap_ atau erp_.
  • Prospek itu berbeda. Prospek tinggal di Salesforce sebelum ERP mengenalnya; otoritas ERP berlaku setelah konversi.
  • Registri adalah norma di proyek Salesforce, disusul konsolidasi dan koeksistensi; MDM terpusat yang murni jarang.
  • Gabungkan hanya jika ada pemenang yang jelas. Simpan duplikat dari muatan eksternal ketika Anda mungkin perlu menelusuri balik; penggabungan menghancurkan riwayat itu. Dan putuskan apa yang terjadi pada rekaman-rekaman anaknya: pindahkan, jangan dimuat, atau simpan pada rekaman yang tidak aktif.
  • Profil terpadu adalah peta; golden record adalah keputusan. Ini bisa membingungkan banyak orang: resolusi identitas menghasilkan satu individu terpadu, tetapi bukan golden record.
  • Ketatnya pencocokan adalah keputusan risiko. Di tempat pencampuran itu mahal, lakukan pencocokan lebih sedikit dengan sengaja.
  • Tiga alat untuk tiga pekerjaan: penggabungan, resolusi identitas, MDM.
  • Hierarki dikelola oleh beberapa master. Putuskan otoritas cabang demi cabang.
  • “Yang paling sulit adalah yang dua arah.” Integrasi dua arah tidak menciptakan dua master. Putuskan bidang mana yang bergerak bersama sebagai satu transaksi sebelum tabrakan pertama terjadi.
  • Buat data master terlihat. Sebuah bidang yang menyatakan bahwa ini data master (kunci dari ERP atau sebuah penanda) yang menentukan apakah rekaman bisa diedit, bukan tipe rekaman.
  • Kita tidak mengendalikan ERP-nya. Yang kita kendalikan adalah cara kita merepresentasikannya di Salesforce: satu pelanggan di dua ERP bisa menjadi sebuah hierarki, rekaman-rekaman yang setara, atau satu akun dengan satu rekaman anak per ERP, tergantung seberapa baik klien menjaga ERP-ERP-nya tetap sinkron.
PekerjaannyaAlatnyaApa yang dilakukannya terhadap sumber
Duplikat di dalam satu org, dengan pemenang yang jelasManajemen duplikat dan penggabunganMenggabungkan hingga tiga rekaman; sisanya masuk ke Tempat Sampah
Satu identitas dan satu tampilan lintas sumberResolusi identitas Data 360Menautkannya; tidak mengubah satu pun (sebuah registri)
Satu nilai yang dikelola, dikirim kembali ke setiap sistemPlatform MDM khususMemutuskan nilainya dan mendistribusikannya (koeksistensi atau terpusat)

Enam modul dan satu tantangan, masing-masing dapat dibaca secara mandiri.

  1. Satu Sumber Kebenaran per Atribut. Peta otoritas, golden record hibrida, dan sinyal kepercayaan.
  2. Empat Cara Mengelola Data Master. Registri, konsolidasi, koeksistensi, dan terpusat, dan mengapa model bersama bukanlah kebenaran bersama.
  3. Pencocokan, Penggabungan, dan Survivorship. Harga sebuah kecocokan palsu, apa yang sebenarnya dilakukan penggabungan di Salesforce (dan apa yang terjadi pada rekaman-rekaman anaknya), dan survivorship sebagai pernyataan tentang kepercayaan.
  4. Peta Bukanlah Keputusan. Aturan pencocokan dan metode pencocokan, aturan rekonsiliasi, dan mengapa profil terpadu bukan golden record.
  5. Ketika Otoritas Dibagi. Permintaan vs pembaruan, putaran dan tabrakan, hierarki yang dikelola oleh beberapa master, serta satu pelanggan di dua ERP.
  6. Tantangan Checkpoint 1, lalu Checkpoint 1: Steve Trucking, Arsitektur Pilihan Saya. Coba tantangannya lebih dulu: gambarkan dan pertahankan desain Bagian 1, lalu bandingkan dengan desain saya, dan lihat apa yang berubah dari lanskap di bab 4.

Setelah selesai, uji diri Anda dengan panduan belajar bab ini: daftar periksa untuk ujian, kebiasaan di luar ujian, istilah penting, dan beberapa pertanyaan. Panduan itu menutup Bagian 1; panduan belajar Bagian 1 menyatukan keenam bab.

  • Sistem mana yang otoritatif untuk setiap atribut penting, dan bagaimana hal itu terlihat di model.
  • Gaya pengelolaan master mana yang cocok untuk setiap domain data, dan seberapa besar otoritas yang diberikan kepada lapisan pengelola master.
  • Kapan menggabungkan, kapan menautkan, dan siapa pemilik setiap aturan survivorship.
  • Seberapa ketat pencocokan seharusnya, berdasarkan harga sebuah kecocokan palsu.
  • Di mana data dua arah dan hierarki bersama butuh batas yang eksplisit.

Di luar ujian: agen butuh satu identitas untuk bertindak, dan itu menaikkan taruhannya ke dua arah. Pencocokan berlebihan menjadi insiden privasi, dan agen yang “memperbarui pelanggan” harus menulis ke system of record setiap atribut, bukan ke profil terpadu. Setiap modul diakhiri dengan apa yang diubah AI.

Berikutnya: Bagian 2 dimulai dengan Merancang untuk Skala (coming soon).