Sistem-Sistem di Sekitar Salesforce

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

Pertanyaan yang dijawab modul ini: Apa yang mengelilingi Salesforce, dan peran apa yang dimainkan setiap sistem?

Modul sebelumnya memilah datanya. Sekarang saya ingin menempatkannya di suatu tempat, dan di sinilah arsitek Salesforce sering terjebak. Kita mengenal Salesforce, jadi data pelanggan berarti Akun, data pesanan berarti Pesanan, dokumen berarti File, analitik berarti Laporan. Tetapi perusahaan tidak membeli Salesforce untuk menggantikan semua yang lain yang dimilikinya. Mungkin ada ERP yang menjalankan keuangan dan pemenuhan pesanan, data warehouse dengan riwayat bertahun-tahun, platform integrasi, penyedia identitas, sistem mitra, platform event, platform MDM, dan Data 360 yang menghubungkan beberapa di antaranya. Tugasnya bukan menghafal teknologi. Tugasnya adalah memahami apa pekerjaan setiap sistem.

Jangan Mulai dari Nama Produk

“Kami punya SAP” belum cukup memberi tahu saya. Begitu pula Snowflake, MuleSoft, Tableau, atau Data 360. Saya ingin tahu apa yang dikerjakan sistem itu dalam arsitektur ini: data apa yang dimilikinya, apa yang dibacanya, apa yang diubahnya, siapa yang memakainya, apa yang bergantung padanya, apa yang terjadi ketika ia mati. Dua perusahaan bisa memiliki produk yang persis sama dan arsitektur yang sama sekali berbeda.

Jadi saya memberi label pada sistem berdasarkan perannya. Empat peran mencakup sebagian besar:

• System of record (sistem pencatatan): tempat versi otoritatif sesuatu dipelihara.
• System of engagement (sistem keterlibatan): tempat orang mengerjakan pekerjaannya.
• System of reference (sistem referensi): tempat sebuah sistem mencari informasi yang dibutuhkannya tetapi tidak dimilikinya.
• System of insight (sistem wawasan): tempat data berkumpul untuk diukur, dianalisis, dan diprediksi.

Satu platform bisa memainkan beberapa peran, dan perannya berbeda per data. Salesforce mungkin menjadi system of record untuk kasus, system of engagement untuk agen layanan, dan konsumen data produk yang dimiliki ERP. Jadi ketika seseorang berkata “Salesforce adalah system of record kami,” lengkapi kalimatnya: system of record untuk apa?

ERP: Back Office Punya Gravitasi

ERP adalah sistem yang paling sering Anda temukan di sebelah Salesforce, menjalankan keuangan, inventaris, pembelian, pemenuhan pesanan, dan penagihan. Pola dari modul 1 (pelanggan dan produk masuk, pesanan keluar) berarti ERP memiliki produk, tetapi tenaga penjual tetap butuh produk itu di Salesforce. Baik: bawa masuk. Tetapi menyalin data tidak memindahkan kepemilikan. Salinan bukanlah otoritas.

Posisi saya: data milik ERP dibaca secara lokal dan ditulis secara terkendali. Pengguna Salesforce mendapat datanya di tempat mereka bekerja, tetapi Salesforce tidak boleh mengubah apa yang dimiliki ERP. Dan saya membuatnya terlihat di skema: bidang-bidang milik ERP diberi awalan erp_, seperti erp_Product_Number__c, sehingga siapa pun yang membaca objeknya tahu siapa pemilik setiap bidang dan berhati-hati saat mengubahnya. Awalan itu tidak menegakkan apa pun; izin, validasi, dan pola integrasilah yang melakukannya. Awalan itu mengomunikasikan maksud, dan itulah peta otoritas yang dibuat terlihat.

Data Warehouse, Data Lake, dan Lakehouse

Sistem operasional menjalankan bisnis; sistem analitis membantu memahaminya. “Tunjukkan peluang saya yang masih terbuka” adalah laporan Salesforce. “Tunjukkan lima tahun penjualan, pemenuhan pesanan, pengembalian, kasus, inventaris, dan keuangan di semua kanal” adalah masalah yang berbeda.

Anda akan bertemu tiga jenis penyimpanan analitis. Data warehouse menyimpan data terstruktur yang disiapkan untuk analisis. Data lake menyimpan data jauh lebih banyak dalam lebih banyak bentuk, sering kali mentah. Lakehouse menggabungkan keduanya: penyimpanan bergaya lake dengan analisis bergaya warehouse. Kenali ketiganya, karena semuanya muncul di lanskap. Tetapi pengalaman saya adalah lakehouse dan data mesh masih jarang di proyek Salesforce. Lanskap yang umum adalah CRM, ERP, data warehouse, dan lapisan integrasi, dengan platform lain di tempat bisnis benar-benar membutuhkannya. Pelajari arsitekturnya; jangan mengejar kosakatanya.

Analitik Tinggal di Tempat Data Tinggal

Ini salah satu posisi saya yang paling teguh: di mana analitik tinggal mengikuti di mana data tinggal. Jika laporannya hanya butuh akun, peluang, dan tenaga penjual, semuanya ada di core: laporan dan dasbor standar. Lalu bisnis meminta menambahkan faktur dari ERP. Lalu biaya produk. Lalu lima tahun pesanan dari data warehouse. Lalu aktivitas situs web. Pada titik tertentu, menyeret semua itu ke CRM operasional hanya untuk membuat laporan tidak lagi masuk akal. Begitu penyimpanan data lain terlibat, platform analitik menjadi perlu: Tableau (termasuk Tableau Next, yang dibangun di atas Data 360), atau CRM Analytics jika sudah dipakai. Platform itu penting ketika data Salesforce digabungkan dengan data warehouse. Persyaratannya bukan sekadar makin rumit; lanskapnya mengubah di mana pertanyaan itu seharusnya dijawab. Jadi saya tidak pernah memulai dengan “alat analitik yang mana?” Saya memulai dengan di mana datanya?

Saya menanyakan hal yang sama kepada kandidat CTA: “Diagram saya yang mana yang menyelesaikan ini dengan indah? Lanskap.” Jika semuanya ada di core, pakai laporan. Jika Anda punya data di repositori lain, saya ingin melihat platform analitik. Lanskap menjawab pertanyaan pelaporan sebelum ada yang membuka pembuat laporan. (Nama produknya berubah; bab Data 360 membahas posisi analitik Salesforce saat ini.)

MDM: Siapa Sebenarnya Pelanggan Ini?

Sekarang misalkan informasi pelanggan tinggal di Salesforce, ERP, e-commerce, platform loyalitas, dan sistem mitra, dan masing-masing merasa tahu siapa pelanggannya. Di situlah manajemen data master berperan: menetapkan dan mengatur identitas otoritatif data kunci di seluruh sistem. Tetapi MDM bukan “database pelanggan utama.” Pertanyaan sulitnya adalah sistem mana yang boleh membuat pelanggan, atribut mana yang dimiliki setiap sistem, bagaimana duplikat ditemukan, pengenal mana yang bertahan, dan apa yang terjadi ketika sistem-sistem tidak sepakat. Bab 6 sepenuhnya membahas hal itu. Di sini, kenali perannya: jika ada platform MDM, ia bisa menjadi otoritas penting antara Salesforce dan bagian lain perusahaan.

Lapisan Integrasi dan Event

Hubungkan setiap sistem langsung ke setiap sistem lain, dan lanskapnya cepat berubah menjadi spageti. Itulah sebabnya perusahaan punya lapisan integrasi: ESB (enterprise service bus) atau iPaaS (integration platform as a service). MuleSoft adalah yang paling sering Anda temui di lanskap Salesforce. Ia menjadi perantara, sehingga setiap aplikasi tidak perlu memahami setiap aplikasi lainnya.

Tetapi kotak MuleSoft di tengah tidak otomatis membuat integrasinya baik. Saya tetap ingin tahu apa yang melewatinya dan apa yang tidak, siapa yang mentransformasi datanya, siapa pemilik kontraknya, apa yang terjadi ketika tujuannya mati, apakah sinkron atau asinkron, dan bagaimana kita tahu sebuah pesan berhasil. Kursus Integration Architect membahasnya secara mendalam; di sini, kenali ia sebagai peran tersendiri.

Dan tidak setiap integrasi berupa sistem A memanggil sistem B. Kadang sesuatu terjadi (sebuah pesanan dibuat, sebuah pengiriman berubah status, sebuah truk masuk ke suatu wilayah), sebuah event diterbitkan, dan siapa pun yang berkepentingan menanggapinya. Event yang bergerak juga punya infrastruktur: kemampuan event milik Salesforce sendiri, event bus perusahaan, atau sistem pesan lainnya. Gambarkan mekanisme yang membawa datanya, bukan hanya database-nya.

Sistem yang Dilupakan Developer: Identitas

Ada satu kotak yang selalu saya inginkan di lanskap tetapi jarang dipikirkan developer: penyedia identitas. Developer langsung masuk ke sandbox mereka dengan nama pengguna dan kata sandi, sehingga identitas tidak terlihat selama pembangunan. Lalu UAT atau production tiba, dan tiba-tiba ada single sign-on perusahaan untuk karyawan, mungkin penyedia kedua untuk mitra, dan login sosial untuk pelanggan. Identitas selalu menjadi bagian dari arsitektur. Developernya saja yang belum melihatnya.

Penyedia identitas (IdP) adalah sistem yang mengautentikasi pengguna dan menetapkan identitas yang dipercaya Salesforce. Ia layak berada di lanskap sejak hari pertama, meskipun baru dikonfigurasi belakangan di pipeline rilis, karena siapa yang bisa masuk menentukan siapa yang bisa mencapai data.

Ada pula kendala praktis: konfigurasi identitas bisa di-deploy, tetapi tidak sepenuhnya. Konfigurasi single sign-on SAML dan penyedia autentikasi adalah tipe Metadata API, jadi keduanya ikut berjalan melalui pipeline (SamlSsoConfig (opens in a new tab)). Tetapi consumer secret penyedia autentikasi tidak lagi dikembalikan dalam respons Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), dan sertifikat biasanya berbeda per lingkungan. Rencanakan bagian yang ikut berjalan dan bagian yang tidak.

Click to enlarge

Bacalah lanskap sebagai peran, bukan logo: apa yang dimiliki, dibaca, atau diputuskan oleh setiap sistem.

Di Mana Posisi Data 360?

Data 360 memunculkan pertanyaan menggambar yang menarik. Saya menaruhnya di sebelah kanan, di bawah ESB atau MuleSoft. Alasannya adalah koneksinya: pengguna tidak pernah terhubung langsung ke sana, sementara ia terhubung langsung ke banyak sistem back-end. Jadi ia termasuk bagian dari saluran data, tempat garis-garis itu tetap pendek, bukan di luar bersama para pengguna. Gambarkan ia seperti layar lain tempat orang login, dan Anda menceritakan kisah yang salah.

Admin dan tim data memang membuka layar-layar Data 360, tetapi layar itu ada di dalam org, di core. Tenant yang mengerjakan tugasnya, data dan pemrosesannya, berjalan di luar core. Itulah sebabnya saya menyebutnya near-core (dekat core): dikelola di core, di-hosting di luar core (modul 1 menjelaskan istilahnya). Gambarnya mengikuti tenant: ia ditaruh bersama saluran data, dengan satu garis kembali ke org yang mengelolanya.

Apa yang dikerjakannya, menurut kata-kata Salesforce, mencakup zero copy: teknologi federasi data yang memungkinkan perusahaan mengakses dan mengkueri data tanpa menyalinnya (Zero Copy (opens in a new tab)). Kemampuan dan konektornya berubah cepat, jadi bab Data 360 membahasnya dengan layak alih-alih mengubah modul ini menjadi tur produk.

Baca Lanskap sebagai Tanggung Jawab

Saat melihat sebuah lanskap, jangan membaca logonya; bacalah tanggung jawabnya. ERP: apa yang dimilikinya? Data warehouse: pertanyaan apa yang dijawabnya? Platform integrasi: apa yang dipindahkannya? IdP: siapa yang diautentikasinya? MDM: identitas apa yang diaturnya? Data 360: apa yang dihubungkannya, dan untuk apa? Salesforce: apa sebenarnya tanggung jawabnya? Begitu Anda bisa menjawab semua itu, kotak-kotaknya menjadi bermakna, dan panah-panah di antaranya menjadi jauh lebih menarik. Berikutnya, kita menggambarnya dengan sengaja.

Yang Diputuskan Arsitek di Sini

• Peran apa yang dimainkan setiap sistem, melampaui nama produknya.
• Sistem mana yang otoritatif untuk setiap kumpulan data penting, dan di mana Salesforce hanya menyimpan salinan lokal.
• Apakah data milik ERP tersedia di Salesforce dengan penulisan yang terkendali, dan bagaimana kepemilikan itu terlihat di skema.
• Di mana analitik seharusnya berada, berdasarkan di mana data tinggal.
• Di mana posisi identitas, integrasi, event, dan otoritas data master di lanskap.

Lanskap dengan sepuluh persegi panjang bukanlah arsitektur; itu inventaris. Arsitektur dimulai ketika Anda bisa menunjuk setiap persegi panjang dan mengatakan mengapa ia ada di sana, apa yang dimilikinya, siapa yang memakainya, apa yang dibutuhkan Salesforce darinya, dan apa yang rusak jika Anda salah memahami perannya.

Jelajahi

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Salesforce, Zero Copy (opens in a new tab) (halaman produk), dicek 2026-10-14 (bahasa Inggris).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (bahasa Inggris).