Berpikir seperti Data Architect
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)
Panduan belajar untuk bab 1 kursus Data Architect. Baca dulu tujuh modulnya; halaman ini membantu Anda memeriksa apa yang sudah melekat.
Tentang panduan belajar ini. Panduan ini disusun hanya dari konten kursus ini sendiri dan daftar tujuan yang tercantum dalam panduan ujian resmi Salesforce. Panduan ini tidak pernah didasarkan pada soal ujian yang sebenarnya, dan tidak mengklaim tahu apa yang keluar di ujian. Jika Anda sudah mengikuti ujiannya, mohon jangan kirimkan soal-soalnya kepada saya: perjanjian sertifikasi melarang membagikannya, dan menghafal jawaban memang cara yang salah untuk menjadi arsitek.
Bab ini memang lebih sedikit memuat fakta ujian, dan itu disengaja. Bab ini tentang cara berpikir seorang arsitek, dan tidak ada tujuan ujian yang khusus menjadi miliknya. Tetapi ujiannya dibangun dari skenario: sebuah bisnis, beberapa angka, sebuah batasan, dan beberapa jawaban yang bisa berhasil. Kebiasaan dalam bab ini adalah cara Anda membaca skenario-skenario itu. Jadi daftar periksa di bawah ini menyebutkan tujuan mana yang didukung setiap poin, alih-alih mengklaim bahwa poin itu diuji secara langsung.
Untuk Ujian
Section titled “Untuk Ujian ”Centang satu per satu sambil berjalan. Setiap poin bertaut ke tempat ia diajarkan.
Membaca skenario seperti arsitek (mendukung setiap tujuan)
- Saya memisahkan persyaratan yang sebenarnya dari desain yang membawanya (“kita butuh bidang Penyetuju 2 dan Penyetuju 3” dibandingkan “kita perlu melacak setiap persetujuan”). (Jangan Langsung Menerima Persyaratannya)
- Saya mencari persyaratan tersirat yang tidak dinyatakan siapa pun: kepemilikan, kesegaran data, kegagalan, retensi, akses. (Cari Persyaratan yang Tersirat)
- Saya memberinya angka: volume per hari, per tahun, dengan pertumbuhan, dan saya menyadari kapan satu nol tambahan mengubah jawabannya. (Ketahui Angka-Angka Anda)
- Di antara beberapa jawaban yang berhasil, saya membandingkan apa yang didapat dan dilepaskan masing-masing terhadap persyaratan dan batasan yang dinyatakan. (Ketahui Apa yang Anda Korbankan, Batasan Mengubah Jawabannya)
- Saya memperlakukan biaya, lisensi, dan batasan sebagai bagian dari kecocokan sebuah alat, bukan pertimbangan belakangan. (Sembilan Pertanyaan)
Model data (mendukung DM-1)
- Saya bisa menilai sebuah model dari apakah ia mendukung bisnis, bisa bertumbuh bersamanya, dan berkinerja. (Mendukung. Bertumbuh. Berkinerja.)
- Saya bisa mengenali model yang terlalu datar (Bidang 1, Bidang 2, Bidang 3), ternormalisasi berlebihan, atau dibangun di atas objek standar yang salah. (Terlalu Datar, Terlalu Rumit, atau Memang Salah)
- Saya tahu mengapa daftar pilihan cocok untuk daftar yang pendek dan stabil, sedangkan lookup cocok untuk daftar yang terus bertambah atau datang dari integrasi. (Banyak Cara untuk Menyelesaikan Masalah)
- Saya tahu bahwa kunci yang membawa makna (misalnya sebagian dari nama) akan rusak ketika makna itu berubah. (Sebagian Keputusan Murah untuk Diubah)
Mengubah apa yang sudah ada (mendukung DM-1 dan SDM-2)
- Saya tahu mengapa mengubah tipe sebuah bidang, atau menjadikan bidang yang sudah ada Required, bisa merusak sesuatu di kemudian hari, dan mengapa platform memblokir perubahan tipe selama kode atau flow merujuk bidang itu. (Berhati-hatilah Saat Mengubah Kerangkanya)
- Saya tahu polanya: tambahkan, jangan ubah; hentikan secara bertahap, jangan mengejutkan, dan bahwa Field Usage dapat menandai sebuah bidang sebagai kandidat penghentian. (Berhati-hatilah Saat Mengubah Kerangkanya)
- Saya tahu fakta master-detail di balik Uji Reversibilitas: akses dan kepemilikan rekaman detail mengikuti master-nya, menghapus master menghapus detailnya, ringkasan roll-up membutuhkan master-detail, dan lookup hanya bisa diubah menjadi master-detail jika setiap rekaman memiliki nilai. (Uji Reversibilitas, Jelajahi)
Lisensi dan berbagi (mendukung SDM-1)
- Saya tahu bahwa pengguna komunitas bervolume tinggi (Customer Community di antaranya) tidak punya peran dan tidak memakai model berbagi, sehingga akses mereka datang dari sharing set dan share group, dan Apex sharing tidak bisa menjangkau mereka. (Contoh Kerja: Apex Sharing)
Kegagalan (mendukung MIG-1 dan bab-bab integrasi)
- Saya tahu bahwa “job selesai” tidak sama dengan datanya benar, dan bagaimana rekonsiliasi menemukan rekaman yang tidak sampai. (Keberhasilan Sebagian Tetaplah Kegagalan yang Harus Anda Pahami)
Di Luar Ujian
Section titled “Di Luar Ujian ”Ujian adalah batas bawah, bukan batas atas. Inilah kebiasaan dari bab ini yang dibutuhkan seorang arsitek, entah ada pertanyaan ujian tentangnya atau tidak.
- Seseorang harus memegang cetak birunya. Arsitektur adalah mengambil keputusan yang baik dengan informasi yang tidak lengkap, dan mengetahui konsekuensinya.
- Model data adalah kerangkanya. Semua hal lain dibangun di atasnya.
- Uji Reversibilitas: seberapa sulit ini dibatalkan, dan seberapa banyak yang akan bergantung padanya?
- Arsitektur menciptakan gravitasi. Ketergantunganlah yang membuat perubahan mahal, bukan perubahan itu sendiri.
- Pikirkan radius ledakannya, di dalam Salesforce dan di seluruh perusahaan. Arsitektur adalah lalu lintas dua arah.
- Tuliskan alasannya: konteks, opsi, keputusan, konsekuensi, pemilik, tinjauan. Gantikan dengan yang baru; jangan dihapus.
- Terbaik dalam hal apa? Keputusan suboptimal bisa menjadi bagian dari arsitektur yang optimal, jika Anda tahu Anda sedang mengambilnya.
- Simpan gambaran tentang yang optimal, agar Anda tahu ke arah mana Anda menjauh darinya, dan mengapa.
- Think Correct. Think Fast. Kecepatan datang dari pemikiran yang sudah dilakukan sebelum saatnya tiba.
- Bangun untuk hari ini. Rencanakan untuk besok. Rencanakan untuk kegagalan. Dan pakai pertumbuhan 30 persen ketika tidak ada yang memberi Anda angka.
- Pelajari sembilan pertanyaannya, bukan hanya jawabannya.
- AI adalah pendorong roket. Menghasilkan bukanlah menilai, yang tidak bisa dibatalkan tetap tidak bisa dibatalkan, dan tinjauan manusia bukan sekadar seremoni. Percaya, tetapi verifikasi.
Istilah Penting
Section titled “Istilah Penting ”| Istilah | Dalam satu baris |
|---|---|
| Keputusan arsitektur | Keputusan yang sulit dibatalkan, dengan banyak hal yang bergantung padanya |
| Uji Reversibilitas | Seberapa sulit ini dibatalkan, dan seberapa banyak yang akan bergantung padanya? |
| Gravitasi | Ketergantungan yang terkumpul di sekitar sebuah keputusan dari waktu ke waktu |
| Radius ledakan | Semua hal lain yang ikut bergeser ketika sebuah keputusan berubah |
| Catatan keputusan | Konteks, opsi, keputusan, konsekuensi, pemilik, dan titik tinjauan, dibuat ringkas |
| Trade-off | Apa yang didapat sebuah opsi, dan apa yang dilepaskannya untuk mendapatkannya |
| Persyaratan tersirat | Sesuatu yang diharapkan bisnis tanpa meminta, seperti pemulihan ketika sebuah muatan gagal |
| Jumlah Nol ala Steve | Satu nol lagi pada volume bisa mengubah seluruh arsitektur |
| Rekonsiliasi | Membandingkan apa yang seharusnya terjadi dengan apa yang benar-benar terjadi, rekaman demi rekaman |
| Penghentian bertahap (deprecate) | Menandai sesuatu sebagai akan dihentikan, lalu mempensiunkannya secara terencana, alih-alih mengubahnya di tempat |
| Pengguna bervolume tinggi | Pengguna komunitas (Customer Community di antara lisensinya) tanpa peran, di luar model berbagi |
| Skema yang membengkak | Objek dan bidang yang menumpuk karena murah untuk dibuat, sampai tidak ada yang merancang modelnya |
Uji Diri
Section titled “Uji Diri ”Skenario singkat dengan gaya kursus ini. Tentukan jawaban Anda sebelum membukanya.
1. Tim penjualan meminta bidang Penyetuju 2 dan Penyetuju 3, masing-masing dengan tanggal, di Peluang. Apa yang Anda tanyakan, dan apa yang mungkin Anda bangun?
Tanyakan mengapa, dan berapa banyak persetujuan yang mungkin ada. Jika bisa lebih dari dua atau tiga, persyaratannya adalah melacak setiap persetujuan, bukan menambah bidang: sebuah objek anak, satu rekaman per persetujuan. Baca lagi Jangan Langsung Menerima Persyaratannya.
2. Seseorang ingin mengganti label sebuah bidang, dan orang lain ingin mengubah format pengenal pelanggan yang sudah disimpan oleh lima sistem. Mana yang layak mendapat lebih banyak perhatian Anda, dan mengapa?
Pengenalnya. Label murah untuk diubah. Pengenal itu gagal dalam Uji Reversibilitas: sulit dibatalkan, dan sudah banyak yang bergantung padanya. Curahkan perhatian sebanding dengan harga sebuah kesalahan. Baca lagi Sebagian Keputusan Murah untuk Diubah.
3. Sebuah bidang teks sudah dipakai bertahun-tahun. Bisnis sekarang ingin bidang itu menyimpan angka. Apa pendekatan Anda?
Jangan mengubahnya di tempat. Cari apa saja yang bergantung padanya (Flow, Apex, laporan, integrasi, agen) dan apa yang terjadi pada data lamanya. Biasanya: tambahkan bidang baru, migrasikan secara terencana, lalu hentikan bidang lama secara bertahap. Baca lagi Berhati-hatilah Saat Mengubah Kerangkanya.
4. 1.200 lokasi, 100 janji temu per lokasi per hari, sekitar 305 hari setahun, dua rekaman per janji temu, disimpan lima tahun, pertumbuhan 30 persen. Kira-kira berapa rekaman, dan mengapa itu penting?
Sekitar 73 juta rekaman di tahun pertama (36,6 juta janji temu, masing-masing dua rekaman), dan lebih dari 650 juta selama lima tahun dengan pertumbuhan. Fitur yang sama, beberapa nol lagi, arsitektur yang sangat berbeda. Baca lagi Ketahui Angka-Angka Anda.
5. Muatan malam melaporkan "selesai" untuk satu juta rekaman. Bagaimana Anda tahu bahwa prosesnya berhasil?
Anda melakukan rekonsiliasi. Sisi penerima mengonfirmasi setiap rekaman yang disimpannya; pengirim membandingkan apa yang dikirimnya dengan apa yang dikonfirmasi. Konfirmasi yang hilang berarti prosesnya tidak berhasil, apa pun kata status job-nya, dan memberi tahu Anda rekaman mana yang harus dicoba lagi, diteruskan ke seseorang, atau dijadikan peringatan. Baca lagi Keberhasilan Sebagian Tetaplah Kegagalan yang Harus Anda Pahami.
6. Sebuah komunitas dengan 15 juta pengguna Customer Community membutuhkan akses rekaman yang rumit. Seseorang mengusulkan Apex sharing. Apa masalahnya?
Mereka adalah pengguna bervolume tinggi: tanpa peran, di luar model berbagi, jadi tidak ada rekaman berbagi yang bisa ditulis Apex. Akses datang dari sharing set dan share group. Lisensinyalah yang menentukan alat berbagi mana yang tersedia. Baca lagi Contoh Kerja: Apex Sharing.
7. Sebuah alat AI menghasilkan dua puluh objek untuk aplikasi baru dalam hitungan menit. Apa tugas arsitek sekarang?
Memutuskan apakah seharusnya kita cukup punya lima. Memahami modelnya cukup baik untuk mempertahankannya: mengapa objek dan hubungan ini, di mana kunci dan data masternya, apa yang terjadi dalam skala besar. Memverifikasi fakta yang diandalkannya. Menghasilkan bukanlah menilai. Baca lagi Implementasi yang Murah Menggeser Nilainya.
Jelajahi
Section titled “Jelajahi ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Bantuan Salesforce (dicek 2026-09-25, bahasa Inggris): daftar resmi tujuan ujian dan bobotnya. Selalu periksa versi terkininya sebelum Anda mendaftar ujian.