Salesforce Hanyalah Satu dari Banyak Sistem

🌐 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 1 dari 6 dalam bab Memahami Data Perusahaan, bab 4 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Berikutnya: Jenis-Jenis Data Perusahaan

Pertanyaan yang dijawab modul ini: Mengapa seorang data architect menggambar apa yang ada di sekitar org sebelum merancang org-nya?

Saat mengajar kandidat CTA, pekerjaan rumah setelah hari pertama selalu sama. Baca skenarionya. Mulai lanskap sistemnya dari kanvas kosong. Baru setelah itu coba buat model datanya. Bukan objeknya, bukan detail integrasinya: lanskapnya. Saya ingin melihat apa yang ada di sekitar Salesforce sebelum kita memutuskan apa yang seharusnya ada di dalamnya.

Itu perubahan sudut pandang bagi banyak profesional Salesforce. Jika sepanjang karier Anda adalah admin atau developer, Salesforce dengan sendirinya menjadi pusat dunia Anda. Anda membuka Setup, membuat objek, membangun flow, menulis Apex, dan mengintegrasikan sistem lain ke dalam Salesforce. Semuanya seolah dimulai dari org. Seorang arsitek harus menarik kameranya mundur, karena di sebuah perusahaan Salesforce hanyalah satu dari banyak sistem, dan cukup sering ia bukan sistem yang memiliki datanya.

Gambarkan Lanskapnya Lebih Dulu

Bab 2 membangun model logis, dan bab 3 bertanya bagaimana model itu hidup di Salesforce. Sekarang saya akan memperbesar masalahnya. Sebelum memutuskan apa yang seharusnya dimiliki Salesforce, saya ingin memahami perusahaan di sekitarnya. Sistem apa saja yang sudah ada? Di mana pelanggan dibuat, produk didefinisikan, pesanan dimulai, faktur dihasilkan? Di mana identitas tinggal? Di mana analitik dikerjakan, di mana dokumen disimpan, di mana riwayatnya berada? Sistem mana yang butuh data Salesforce, dan sistem mana yang diandalkan Salesforce?

Pertanyaan-pertanyaan itu mengubah arsitekturnya. Jadi saya mulai dari kanvas kosong, menaruh Salesforce di tengah, dan menggambar semua yang ada di sekelilingnya. Modul 4 menunjukkan persis bagaimana saya menatanya. Untuk sekarang, pelajarannya sederhana: jangan merancang org sebelum Anda memahami dunia tempat ia harus hidup.

Salesforce Sering Kali Bukan System of Record

Ambil sebuah perusahaan yang sangat umum: Salesforce ditambah sebuah ERP, sistem perencanaan sumber daya perusahaan seperti SAP atau Oracle, yang menjalankan keuangan, produk, inventaris, pembelian, dan pemenuhan pesanan. Sekarang ajukan pertanyaan sederhana: di mana pelanggan tinggal?

Bisa di Salesforce, di ERP, atau di keduanya, dan di situlah menariknya. Tenaga penjual mungkin mengelola prospek sebagai Akun di Salesforce, sementara ERP menerbitkan nomor pelanggan resmi begitu mereka menjadi pelanggan yang membayar. Produk dan harga? Kemungkinan besar ERP. Inventaris? Hampir tidak pernah Salesforce. Pesanan mungkin dicatat di Salesforce dan dipenuhi di ERP; faktur datang dari ERP; layanan tinggal di Salesforce; analitik terbagi antara laporan Salesforce dan data warehouse. Tiba-tiba model data Salesforce kita yang rapi bukan lagi model data perusahaan. Ia hanya salah satu bagiannya.

Integrasi yang Saya Lihat Berulang Kali

Integrasi paling umum yang saya lihat berjalan seperti ini: pelanggan, produk, dan harga mengalir ke Salesforce dari ERP, dan pesanan mengalir keluar. Ganti dengan SAP, Oracle, atau ERP lain apa pun; bentuknya tetap sama. ERP memegang golden record untuk pelanggan dan produk, jadi aliran-aliran itu datang dari kanan, masuk ke Salesforce. Tim penjualan menutup transaksi di Salesforce, jadi pesanan bermula di sana lalu kembali ke ERP untuk dipenuhi, ditagih, dan dicatat dalam pembukuan.

Aliran-aliran itu bukan sekadar integrasi. Aliran-aliran itu memberi tahu saya di mana perusahaan meyakini kebenaran tinggal.

Panah Satu Arah Membuat Saya Gelisah

Setiap kali saya melihat integrasi yang hanya punya satu aliran, saya mulai khawatir. Di tingkat atas, seseorang menggambar satu panah: pesanan dari Salesforce ke ERP. Baik. Sekarang lihat lebih dalam. Bagaimana saya bisa mengirim pesanan ke ERP jika saya tidak tahu pelanggannya, produknya, atau harganya? Pesanan itu harus terkait dengan pelanggan yang sudah ada di ERP, dan setiap barisnya harus berupa SKU yang sudah dijual ERP. Saya tidak bisa mengirim item baris untuk produk yang tidak ada di sisi seberang. Jadi sebelum panah pesanan itu bisa bekerja, aliran balik harus ada, berjalan ke arah sebaliknya.

Itulah pertanyaan yang saya ajukan untuk setiap panah: aliran ini bergantung pada apa? Panah tingkat atas yang bisa Anda lihat biasanya membutuhkan aliran balik yang belum Anda gambar.

Lihat lebih dalam lagi dan Anda menemukan perjalanan pulangnya. Salesforce mengirim pesanan. Lalu apa? Apakah diterima atau ditolak? Apakah sudah dikirim, dikirim sebagian, atau dibatalkan? Apakah sudah ditagih? Apakah ada orang di Salesforce yang perlu tahu? Mungkin tidak ada. Tetapi seseorang seharusnya bertanya. Jika tidak ada yang kembali, tidak apa-apa. Beri tahu saya alasannya.

Perusahaan Tidak Terbentuk Sekaligus

Lanskap menjadi rumit sebagian karena tidak ada yang membangunnya sekaligus. Data datang bergelombang. Mula-mula file: rekaman berformat tetap, lalu file berpembatas seperti CSV. Lalu database relasional untuk data operasional. Lalu data warehouse untuk menyatukannya demi analisis. Lalu database NoSQL untuk dokumen, pasangan kunci-nilai, dan graf yang tidak rapi masuk ke dalam tabel. Lalu data lake untuk data mentah dan semi-terstruktur dalam jumlah sangat besar, dan lakehouse yang menggabungkan keduanya. Event stream, seperti Kafka atau event bus Salesforce, memindahkan data saat sesuatu terjadi, bukan dalam batch setiap malam. Dan kini federasi, di mana data tidak harus disalin ke satu tempat sebelum platform lain bisa memakainya.

Teknologinya belum menjadi pokok bahasan. Pokoknya adalah ini: gelombang baru jarang membuat gelombang lama menghilang. Masuklah ke sebuah perusahaan besar dan Anda akan menemukan semuanya sekaligus: database relasional, ERP, Salesforce, data warehouse, data lake, kiriman SFTP, API, aliran event, spreadsheet yang masih dikirim lewat email oleh seseorang setiap Jumat, dan satu sistem yang ditakuti semua orang untuk disentuh karena pembuatnya sudah pensiun enam tahun lalu. Itulah perusahaan yang sedang Anda rancang arsitekturnya, bukan yang ada di brosur produk.

Sistem yang Berbeda Ada karena Alasan yang Berbeda

Itu juga sebabnya saya tidak pernah memulai dengan “bagaimana kita memasukkan semua data ke Salesforce?” Mengapa saya ingin semuanya ada di sana? Salesforce mungkin tempat terbaik bagi tim penjualan dan layanan untuk bekerja dengan pelanggan. Itu tidak menjadikannya sistem keuangan, data warehouse perusahaan, penyimpanan telemetri, arsip dokumen, atau rumah bagi setiap klik, pembacaan GPS, dan transaksi historis yang pernah dihasilkan perusahaan.

Bab 3 bertanya di mana data ini seharusnya tinggal? untuk satu org. Di tingkat perusahaan, pertanyaan yang sama menjadi lebih besar: kadang Salesforce memiliki datanya, kadang ia menyimpan salinan, kadang hanya rujukan, dan kadang ia sama sekali tidak seharusnya memilikinya.

Core, Off-Core, dan Hyperforce

Ada batas lain yang perlu dipahami: bahkan “Salesforce” bukanlah satu runtime dan satu database. Di bab 3, di core berarti tempat data berada: di meja Anda, di objek-objek milik org itu sendiri. Di sini kata-kata yang sama menggambarkan di mana sebuah produk berjalan. Anda akan mendengar arsitek memakai keduanya.

Secara historis, runtime Core menjadi tempat sebagian besar platform. Hari ini Salesforce menggambarkan platformnya sebagai ratusan layanan independen yang digerakkan metadata, dengan Core tetap menjadi satu-satunya system of record untuk metadata aplikasi (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Itulah sebabnya Anda akan mendengar arsitek mengatakan sebuah kemampuan berjalan on core atau off core.

Hal ini sudah penting jauh sebelum platformnya terpecah menjadi layanan-layanan. Ketika saya bertanya kepada kelas mengapa Salesforce membeli SteelBrick untuk quoting, bukan Apttus, jawaban yang saya cari sederhana: SteelBrick dibangun 100% di core. Flow dan trigger tinggal di core, jadi produk yang dibangun di sana ikut mendapatkan metadata, kustomisasi, dan otomatisasi platform. Produk quoting itu sejak itu telah digantikan oleh Revenue Cloud, tetapi pelajarannya tidak. Lalu ada near-core (dekat core), dan Data 360 adalah contoh yang saya pakai. Data 360 bukan core. Tenant-nya berada di luar core: data dan mekanisme yang memprosesnya berjalan di lakehouse-nya sendiri, di samping database relasional org, bukan di dalamnya (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Tetapi layar yang Anda pakai untuk menyiapkan dan mengendalikannya ditampilkan di core, di dalam org. Jadi cara paling tepat yang bisa saya rumuskan: dikelola di core, di-hosting di luar core. Tidak ada data atau pemrosesan yang benar-benar berjalan di Core; UI di Core mengendalikan tenant di luar core. Lalu, tentu saja, ada segala sesuatu yang berada di luar core karena sama sekali bukan Salesforce.

Saya kurang peduli menghafal produk mana yang berjalan di mana tahun ini, karena itu berubah, dibandingkan dengan kebiasaannya: sebuah batas bisa memengaruhi perpindahan data, latensi, identitas, integrasi, dan residensi data. Jadi jangan berasumsi bahwa karena sebuah produk bernama Salesforce, datanya berada tepat di sebelah rekaman Akun Anda. Lihat arsitekturnya yang sebenarnya.

Lalu ada Hyperforce: infrastruktur Salesforce yang dibangun untuk public cloud dan didefinisikan sebagai kode, alih-alih pusat data milik Salesforce sendiri seperti sebelumnya, yang memberi pelanggan lebih banyak pilihan tentang di mana data mereka berada (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Itu penting, dan modul 5 akan kembali membahasnya. Tetapi arsitektur infrastruktur bukanlah arsitektur data perusahaan. Memindahkan sebuah org ke public cloud tidak memberi tahu Anda siapa pemilik pelanggan, di mana inventaris tinggal, di mana analitik berjalan, atau data mana yang boleh melintasi batas negara. Hyperforce bisa membentuk sebagian keputusan itu, terutama soal residensi. Hyperforce tidak menggantikan pengetahuan tentang lanskapnya.

Lanskap Datang Sebelum Kotaknya

Jadi inilah kebiasaannya. Seseorang memberi Anda sebuah skenario. Jangan mulai membangun solusi Salesforce. Pertama, temukan sistem-sistemnya: ERP, penyedia identitas, data warehouse, platform integrasi, sistem mitra, kanal pelanggan, penyimpanan dokumen. Lalu temukan data yang berpindah di antaranya: pelanggan, produk, pesanan, faktur, dokumen, event, identitas. Lalu tanyakan siapa pemilik masing-masing. Baru setelah itu putuskan apa yang seharusnya ada di Salesforce. Jika tidak, Anda merancang sebuah kotak tanpa tahu apa yang terhubung dengannya.

Click to enlarge

Langkah 1 dari 3: org yang kita desain, sendirian. Dari sini, ia tampak seperti seluruh dunia.

Click to enlarge

Langkah 2 dari 3: perluas pandangan. Salesforce adalah satu sistem di antara banyak sistem (modul 4 mengajarkan tata letak ini).

Click to enlarge

Langkah 3 dari 3: panah-panah pertama. Pelanggan, produk, dan harga masuk dari ERP, pesanan keluar: panah-panah ini menunjukkan di mana perusahaan meyakini kebenaran berada.

Lanskap Mengubah Model Data

Inilah sebabnya hal ini penting bagi seorang data architect. Bab 2 mengatakan pelanggan adalah entitas penting. Baik. Lalu lanskap mengatakan ERP adalah sumber otoritatif untuk pelanggan. Itu mengubah model fisiknya. Salesforce mungkin tetap menyimpan Akun lokal, karena orang memakainya setiap hari, tetapi sekarang kita butuh pengenal ERP sebagai External ID; kita perlu tahu bidang mana yang boleh diubah Salesforce (saya menandai bidang milik ERP dengan awalan erp_, seperti yang akan kita lihat di modul 3); seberapa cepat perubahan ERP tiba; apakah Salesforce bisa membuat pelanggan sebelum ERP mengetahuinya; dan apa yang terjadi ketika keduanya tidak sepakat. Itu bukan pertanyaan integrasi untuk nanti. Itu pertanyaan arsitektur data, dan lanskaplah yang menyingkapnya.

Begini salah satunya menggigit. Seorang tenaga penjual mengonversi prospek dari sebuah perusahaan minuman besar, membuat Akun, memenangkan transaksi, dan pelanggan itu dikirim ke ERP. Tetapi perusahaan sudah berbisnis dengan perusahaan minuman itu selama bertahun-tahun, dan ERP sudah memilikinya. Sekarang ada dua. Apakah tenaga penjual itu seharusnya bisa membuat Akun tersebut sama sekali? Bab 5 dan 6 kembali membahasnya; lanskap adalah tempat Anda melihatnya datang.

Yang Diputuskan Arsitek di Sini

• Sistem apa saja yang mengelilingi Salesforce, dan peran apa yang dimainkan masing-masing.
• Sistem mana yang memiliki setiap jenis data penting, sebelum memutuskan seberapa banyak yang disimpan Salesforce.
• Apa yang mengalir ke Salesforce, apa yang mengalir keluar, dan apa yang kembali.
• Data mana yang seharusnya dimiliki, disalin, dirujuk, difederasikan, diarsipkan, atau dibiarkan saja oleh Salesforce.
• Batas platform dan infrastruktur mana yang penting, alih-alih berasumsi bahwa semua yang bermerek Salesforce tinggal di satu tempat.

Peralihan dari developer menjadi arsitek sering kali bukan soal mempelajari satu fitur lagi. Peralihan itu adalah belajar kapan berhenti melihat Salesforce: tarik kameranya mundur, ikuti datanya, temukan siapa pemilik kebenarannya, lalu kembali dan putuskan apa seharusnya tugas Salesforce.

Jelajahi

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).