Kenali Alat Anda: Sembilan Pertanyaan

🌐 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)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 6 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Bangun untuk Hari Ini. Rencanakan untuk Besok. Rencanakan untuk Kegagalan. · Berikutnya: Data Architect di Era AI

Pertanyaan yang dijawab modul ini: Bagaimana mengevaluasi alat apa pun, termasuk alat yang belum pernah Anda lihat?

Arsitek butuh penilaian. Tetapi penilaian tanpa pengetahuan tidak banyak gunanya. Anda tetap harus mengenal alat-alat Anda.

Saya sudah bertahun-tahun mengajar para arsitek, dan salah satu kerangka yang saya pakai adalah serangkaian pertanyaan yang seharusnya bisa Anda jawab tentang setiap alat atau kemampuan penting dalam arsitektur Anda. Awalnya saya mengajarkan delapan pertanyaan. Saya menambahkan yang kesembilan. Teknologinya berubah, Salesforce berubah, produk baru muncul dan kemampuan lama berkembang, dan AI mempercepat semuanya. Pertanyaan-pertanyaan ini tetap berlaku.

Sembilan Pertanyaan

Setiap kali Anda mempelajari atau mengevaluasi sebuah teknologi, tanyakan:

1. Apa itu?
2. Di mana itu digunakan?
3. Bagaimana cara saya menggunakannya?
4. Apa saja alternatif saya?
5. Apa kekuatannya?
6. Apa kelemahannya?
7. Bagaimana saya menjelaskannya kepada developer, pihak bisnis, dan eksekutif?
8. Bagaimana pemeliharaannya dalam jangka panjang?
9. Berapa biayanya, lisensi apa yang dibutuhkannya, dan apa batasannya?

Jika Anda bisa menjawab kesembilannya, Anda mulai memahami alat itu seperti seorang arsitek. Perhatikan apa yang tidak ada di daftar: “Bisakah saya mengonfigurasinya?” Itu penting, tetapi hanya sebagian dari mengenal sebuah alat.

Click to enlarge

1. Apa Itu?

Mulailah dengan pertanyaan yang jelas, karena orang cukup sering melewatkannya. Kita mendengar nama sebuah produk atau fitur dan langsung mulai membahas apakah akan memakainya. Perlambat. Apa sebenarnya yang dilakukannya? Masalah apa yang hendak diselesaikannya? Di mana posisinya dalam arsitektur, dan apa yang bukan dirinya? Seorang arsitek seharusnya bisa menjelaskan sebuah teknologi tanpa mengulang deskripsi pemasarannya. Jika saya tidak bisa menjelaskan sesuatu dalam beberapa kalimat, mungkin saya belum cukup memahaminya.

2. Di Mana Itu Digunakan?

Mengetahui apa yang dilakukan sesuatu tidak sama dengan mengetahui kapan ia layak masuk ke arsitektur. Masalah seperti apa yang cocok untuknya? Kondisi apa yang membuatnya tepat, dan kondisi apa yang seharusnya membuat saya curiga? Inilah langkah dari “saya tahu fitur ini” menuju “saya mengenali masalah yang diselesaikan fitur ini,” dan itu langkah yang besar. Anda tidak ingin berkeliling mencari tempat untuk memakai teknologi favorit Anda. Anda ingin mengenali masalah dan tahu alat mana yang cocok.

3. Bagaimana Cara Saya Menggunakannya?

Ya, arsitek harus memahami implementasi. Anda tidak harus membangun setiap komponen, tetapi Anda harus cukup paham untuk tahu apa yang Anda minta orang lain bangun. Ketahui cara mengonfigurasinya, cara developer bekerja dengannya, cara data masuk dan keluar, cara men-deploy dan mengamankannya, dan seperti apa wujudnya saat beroperasi. Saya tidak ingin arsitek merancang di sekitar teknologi yang hanya pernah ia lihat di slide produk. Turun tanganlah: bangun sesuatu, rusak sesuatu, lihat bagaimana ia benar-benar berperilaku. Arsitektur menjadi lebih baik ketika berpijak pada kenyataan.

4. Apa Saja Alternatif Saya?

Ini mungkin pertanyaan terpenting di daftar ini. Jika Anda hanya tahu satu cara untuk menyelesaikan sebuah masalah, Anda tidak punya keputusan arsitektur; Anda hanya punya pilihan bawaan. Setiap kali seseorang mengusulkan sebuah teknologi, saya ingin tahu apa lagi yang bisa kita lakukan. Kemampuan Salesforce yang lain? Sesuatu yang deklaratif, atau kode? Bisakah kemampuan itu berada di luar Salesforce? Bisakah kita membiarkan data di tempatnya alih-alih menyalinnya, memakai event alih-alih panggilan API, atau tidak membangun apa pun sama sekali? Alternatif menciptakan trade-off, dan trade-off adalah jantung arsitektur.

5. Apa Kekuatannya?

Setiap alat ada karena suatu alasan. Pahami apa yang benar-benar menjadi keunggulannya: apa yang dibuatnya mudah, di mana ia mudah diskalakan, kerumitan apa yang dihilangkannya, masalah apa yang diselesaikannya dengan elegan. Gunakan teknologi di tempat kekuatannya selaras dengan masalahnya. Kedengarannya jelas, tetapi sangat mudah memilih alat karena kita sudah memilikinya, tim sudah mengenalnya, alat itu baru, atau seseorang pernah melihat demonya. Itu semua bisa menjadi faktor. Tetapi itu tidak sama dengan kecocokan arsitektur.

6. Apa Kelemahannya?

Ini sama pentingnya. Setiap teknologi punya kelemahan, setiap teknologi. Jika seseorang hanya bisa menyebutkan kekuatan sebuah teknologi, Anda belum benar-benar sedang berdiskusi arsitektur. Apa yang tidak dikerjakannya dengan baik? Di mana kerumitan muncul, dan apa yang terjadi dalam skala besar? Beban operasional dan ketergantungan apa yang dibawanya? Persyaratan apa yang mendorongnya keluar dari zona nyamannya? Kelemahan tidak selalu berarti kita tidak boleh memakai teknologi itu. Itu berarti kita perlu tahu apa yang kita terima. Trade-off yang Anda pahami bisa menjadi keputusan arsitektur. Trade-off yang tidak Anda pahami bisa menjadi kejutan.

7. Bagaimana Saya Menjelaskannya kepada Berbagai Audiens?

Ini salah satu pertanyaan yang memisahkan pengetahuan teknis dari keterampilan arsitektur. Bisakah Anda menjelaskan teknologi yang sama kepada developer, kepada pihak bisnis, dan kepada eksekutif? Penjelasannya seharusnya tidak sama. Developer butuh API, perilaku transaksi, keamanan, penanganan kegagalan, dan pola implementasi. Pihak bisnis peduli pada apa yang dimungkinkannya dan bagaimana proses mereka berubah. Eksekutif peduli pada biaya, risiko, waktu, dampak organisasi, dan opsi mana yang tetap terbuka atau tertutup oleh keputusan itu. Anda tidak mengubah kebenarannya; Anda mengubah tingkat abstraksinya. Jika satu-satunya cara Anda bisa menjelaskan sebuah teknologi adalah dengan kosakata dokumentasinya, teruslah memperdalam pemahaman Anda.

8. Bagaimana Pemeliharaannya dalam Jangka Panjang?

Proyek berakhir. Sistem tidak, atau setidaknya kita berharap begitu. Seseorang harus memiliki apa yang kita bangun setelah tim proyek pergi. Itu berarti mengetahui bagaimana ia dipantau, diperbarui, dan dipecahkan masalahnya, siapa yang butuh keahlian untuk mendukungnya, bagaimana perubahan di-deploy dan diuji, dan apa yang terjadi ketika teknologinya berkembang atau Salesforce mengubah sesuatu di bawah kita. Bayangkan tiga tahun dari sekarang. Saya pernah melihat arsitektur yang sangat cerdas pada hari peluncuran dan menyiksa untuk dioperasikan sesudahnya. Itu bukan keberhasilan. Kemudahan pemeliharaan adalah bagian dari arsitektur.

9. Berapa Biayanya, Lisensi Apa yang Dibutuhkannya, dan Apa Batasannya?

Inilah pertanyaan yang saya tambahkan pada delapan pertanyaan aslinya, dan hari ini saya rasa mustahil untuk melewatkannya. Sebuah teknologi bisa menjadi solusi teknis yang sempurna tetapi tetap merupakan solusi arsitektur yang salah jika hitungan ekonominya tidak masuk. Apakah ia sudah termasuk dalam lisensi yang kita miliki, atau tambahan? Apakah lisensinya per pengguna, per pemakaian, per konsumsi, per penyimpanan, atau per transaksi? Apa yang terjadi pada biayanya ketika kita membesar?

Lalu ada batasan, dan setiap platform punya batasan: batasan API, penyimpanan, kueri, transaksi, konkurensi, throughput, dan lisensi. Sebagian keras, sebagian lunak; sebagian bisa dinaikkan dan sebagian tidak; sebagian tidak berarti pada skala kita sampai kita menambah satu nol lagi. Anda tidak perlu menghafal setiap batasan Salesforce, dan melakukannya akan menjadi cara yang buruk sekali untuk memakai waktu Anda. Anda perlu tahu bahwa batasan itu ada, mana yang penting bagi arsitektur Anda, dan kapan harus memverifikasi angka terkininya. Angkanya akan berubah. Pertanyaan arsitekturnya tetap.

Contoh Kerja: Apex Sharing

Inilah salah satu contoh yang paling sering saya pakai untuk menunjukkan pertanyaan-pertanyaan ini bekerja. Kita menerima persyaratan berbagi yang rumit, berbagi yang tidak bisa dipenuhi dengan aturan berbagi berbasis pemilik maupun berbasis kriteria. Itu membawa kita ke Apex sharing: kode yang menulis sendiri rekaman berbaginya. Jadi sekarang kita perlu tahu apa itu Apex sharing, di mana ia digunakan, cara memakainya, dan seterusnya. Ini sebuah eskalasi: Apex sharing adalah alternatif (pertanyaan 4) ketika aturan yang kita butuhkan melampaui apa yang bisa dinyatakan oleh berbagi berbasis pemilik dan berbasis kriteria.

Sekarang kelemahannya (pertanyaan 6). Misalkan kita punya komunitas pelanggan dengan 10 atau 20 juta anggota, dan kita memakai lisensi Customer Community, bukan Customer Community Plus. Mereka adalah pengguna bervolume tinggi. Mereka tidak punya peran, dan mereka sama sekali tidak memakai model berbagi: akses mereka datang dari sharing set dan share group, yang dicocokkan melalui akun dan kontak mereka. Tidak ada rekaman berbagi yang bisa ditulis Apex untuk mereka, jadi Apex sharing tidak berlaku bagi mereka. Dan pertanyaan biaya dan lisensi (pertanyaan 9) itulah yang membawa kita ke situ: pilihan lisensi menentukan alat berbagi mana yang tersedia sama sekali.

Jadi sebagaimana Apex sharing menjadi alternatif bagi aturan berbasis pemilik dan berbasis kriteria, Anda mungkin bertemu kasus di mana Anda butuh alternatif bagi Apex sharing. Dan pada titik itu benar-benar tidak ada opsi berbasis konfigurasi untuk aturan berbagi yang rumit. Akhirnya Anda menjadikan objeknya read-only dan mengendalikan akses melalui Apex. Itulah sebabnya Anda mengajukan kesembilan pertanyaan sebelum memilih, bukan sesudahnya.

Jangan Menghafal Platformnya

Ini paling penting ketika Anda sedang mempelajari arsitektur Salesforce. Jangan mencoba menghafal Salesforce. Anda tidak akan bisa: platformnya terlalu besar, dan berubah terlalu cepat. Saya sudah lama bekerja dengan Salesforce, dan saya masih terus belajar. Itu wajar.

Yang ingin saya bangun dalam diri Anda adalah sebuah kerangka untuk belajar. Ketika Salesforce merilis kemampuan baru besok, saya tidak perlu pernah melihatnya sebelumnya. Saya tahu apa yang harus ditanyakan: apa itu, di mana tempatnya, bagaimana cara memakainya, apa lagi yang bisa saya pakai, apa keunggulannya, di mana ia kesulitan, bagaimana saya menjelaskannya, bagaimana saya mengoperasikannya, dan berapa biayanya serta di mana batasannya? Sekarang saya bisa mulai mengevaluasinya. Itu jauh lebih berharga daripada menghafal satu lagi matriks fitur.

Di luar ujian: AI membuat sembilan pertanyaan ini lebih cepat dijawab, sekaligus lebih mudah dijawab dengan salah. Bertemu teknologi yang tidak Anda kenal, dan Anda bisa meminta AI menjelaskannya, membandingkan tiga pendekatan, menyusun daftar batasan dan mode kegagalan yang umum, atau berargumen menentang pemakaiannya. Itu asisten riset yang luar biasa. Tetapi ia bisa salah, ketinggalan zaman, atau dengan percaya diri mencampuradukkan dua produk atau edisi yang namanya mirip. Untuk apa pun yang memengaruhi sebuah keputusan, verifikasi: ikuti sumbernya dan periksa dokumentasi, batasan, dan lisensi terkini. Percaya, tetapi verifikasi (modul 7).

Pelajari Pertanyaannya, Bukan Hanya Jawabannya

Kita akan bertemu banyak teknologi dalam kursus ini. Saya tidak ingin Anda mengumpulkan jawaban; saya ingin Anda melatih pertanyaannya. Ketika kita membahas big object, data eksternal, Data 360, pola integrasi, atau kemampuan AI yang dirilis Salesforce enam bulan setelah bab ini ditulis, ajukan sembilan pertanyaan yang sama.

Jawabannya akan berubah. Pertanyaannya tahan lama. Itulah yang menjadikan ini kerangka arsitektur, bukan sekadar panduan belajar.

Kenali alat Anda: apa keunggulannya, apa kelemahannya, apa lagi yang bisa Anda pakai, berapa biayanya, dan di mana ia rusak. Dan pahami cukup banyak untuk menjelaskan keputusannya kepada orang-orang yang harus hidup dengannya. Begitulah seorang arsitek mempelajari teknologi.

Yang Diputuskan Arsitek di Sini

• Apakah sebuah alat cocok dengan masalahnya, dinilai dengan kesembilan pertanyaan, bukan hanya dari apakah ia bisa dikonfigurasi.
• Apa saja alternatifnya, dan apa arti biaya, lisensi, dan batasan alat itu pada skala Anda.
• Siapa yang akan memeliharanya, dan bagaimana, tiga tahun dari sekarang.
• Fakta mana tentang alat itu yang harus diverifikasi sebelum diandalkan.

Jelajahi

• About High-Volume Community or Site Users (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): pengguna bervolume tinggi (lisensi External Apps, Customer Community, High Volume Customer Portal, dan Authenticated Website) tidak punya peran; akses mereka datang dari sharing set dan share group; mereka tidak bisa dimasukkan dalam aturan berbagi berbasis pemilik, dan rekaman yang mereka miliki tidak bisa dibagikan secara manual.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): pengguna bervolume tinggi (Customer Community, High Volume Customer Portal, Authenticated Website) tidak memakai model berbagi, karena lisensi mereka tidak mendukung peran; akses bekerja dengan mencocokkan pengguna dengan lookup Akun dan Kontak, melalui sharing set atau share group. Halaman yang sama mencantumkan kapan Apex managed sharing adalah alat yang tepat.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), pertanyaan di Trailblazer Community, November 2024 (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): seorang praktisi melaporkan bahwa menyisipkan rekaman berbagi untuk pengguna bervolume tinggi gagal dengan error. Ini laporan lapangan, bukan dokumentasi resmi. (Trailblazer Community daring menjadi read-only pada 30 Oktober 2026; tautannya bisa berubah.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09, bahasa Inggris): sharing set memberi akses ke rekaman yang terkait dengan akun atau kontak pengguna.