Uji Reversibilitas
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)
Modul 3 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Model Data Adalah Kerangkanya · Berikutnya: Arsitektur Adalah Seni Trade-off
Pertanyaan yang dijawab modul ini: Bagaimana membedakan keputusan arsitektur dari keputusan biasa?
Arsitek mengambil banyak sekali keputusan.
Tetapi tidak setiap keputusan adalah keputusan arsitektur.
Itu pembedaan yang penting. Jika kita memperlakukan setiap keputusan sebagai arsitektur, kita akan menghabiskan seluruh waktu untuk memperdebatkan hal-hal yang relatif mudah diubah. Jika kita tidak mengenali keputusan yang benar-benar bersifat arsitektur, kita bisa mengambil keputusan lima menit hari ini yang butuh lima tahun untuk diurai kembali.
Jadi bagaimana kita membedakannya?
Saya suka mengajukan satu pertanyaan sederhana:
Seberapa sulit keputusan ini dibatalkan nanti?
Saya menyebutnya Uji Reversibilitas.
Makin sulit sesuatu dibatalkan, dan makin banyak hal lain yang akan bergantung padanya, makin besar perhatian arsitektur yang layak ia dapatkan.
Sebagian Keputusan Murah untuk Diubah
Section titled “Sebagian Keputusan Murah untuk Diubah ”Mari mulai dari yang sederhana.
Kita menamai sebuah bidang Customer Category. Enam bulan kemudian, bisnis memutuskan bahwa semua orang sebenarnya menyebutnya Customer Segment. Kita mengubah labelnya. Mungkin ada sedikit dokumentasi yang perlu diperbarui dan sedikit pelatihan pengguna, tetapi ini bukan peristiwa arsitektur yang besar. Meski begitu, kita harus tetap hidup dengan nama API aslinya, karena mengubahnya membawa konsekuensi yang jauh lebih besar. Jadi ini mungkin hanya berarti menangani perubahan label, dan kebingungan yang bisa menyertainya.
Kita mengambil keputusan. Kita berubah pikiran. Kita melanjutkan.
Sekarang bandingkan dengan keputusan yang lain.
Kita membuat sebuah pengenal untuk pelanggan. Kita menentukan artinya, formatnya, dan sistem mana yang membuatnya. Lalu kita menerbitkannya.
Salesforce memakainya. Data warehouse memakainya. Platform integrasi memakainya. Portal pelanggan memakainya. Lima aplikasi lain mulai menyimpannya. Laporan dan pipeline data memakainya. Mungkin akhirnya pelanggan juga melihatnya.
Tiga tahun kemudian, seseorang berkata:
Sepertinya dulu kita tidak seharusnya merancang pengenal itu dengan cara itu.
Itu percakapan yang sangat berbeda.
Perbedaannya bukan karena satu keputusan lebih teknis daripada yang lain.
Perbedaannya adalah reversibilitas.
Begini contohnya. Misalkan bisnis selama ini membuat kuncinya dari sebagian nama pelanggan ditambah sebuah angka. Itu berjalan bertahun-tahun, karena belum pernah ada yang harus mengganti nama. Lalu, setahun atau lebih kemudian, sebuah nama benar-benar berubah, dan tiba-tiba kuncinya tidak lagi cocok dengan pola yang diharapkan oleh data lainnya. Ini salah satu alasan mengapa kunci tidak boleh membawa makna apa pun.
Arsitektur Menciptakan Gravitasi
Section titled “Arsitektur Menciptakan Gravitasi ”Sebuah keputusan arsitektur cenderung mengumpulkan banyak hal di sekitarnya. Saya menganggapnya sebagai gravitasi.
Pilih sebuah model objek, dan otomatisasi akan dibangun di sekitarnya.
Pilih sebuah kunci, dan sistem lain mulai menyimpannya.
Pilih di mana data master tinggal, dan integrasi mulai mengalir ke dan dari sana.
Pilih sebuah model berbagi, dan proses bisnis mulai bergantung pada siapa yang bisa melihat apa.
Pilih sebuah pola integrasi, dan sistem-sistem mulai bergantung pada waktu dan perilakunya.
Makin lama keputusan itu ada, makin besar gravitasinya. Pada akhirnya, mengubah keputusan aslinya berarti mengubah semua yang telah terkumpul di sekitarnya.
AI juga merasakan gravitasi itu. Alat AI bekerja dari apa yang sudah ada di sistem: begitu sebuah elemen desain kunci ada di sana, setiap interaksi AI sesudahnya memperlakukan elemen itu sebagai fakta dan terus membangun di atasnya, dan terus membangun di atasnya, dan terus membangun di atasnya. Keputusan itu bergema ke depan melalui banyak keputusan lain, dan tidak ada manusia yang pernah kembali meninjau keputusan aslinya. Setiap generasi menambah gravitasinya.
Itulah sebabnya ungkapan model data sebagai “kerangka” itu penting. Kita berhati-hati bukan karena perubahan itu buruk. Kita berhati-hati karena ketergantungan membuat perubahan menjadi mahal.
Ajukan Dua Pertanyaan
Section titled “Ajukan Dua Pertanyaan ”Saat melihat sebuah keputusan desain, saya mengajukan dua pertanyaan:
Seberapa sulit ini dibatalkan?
Seberapa banyak yang akan bergantung padanya?
Keduanya berkaitan, tetapi tidak identik. Sesuatu bisa mudah diubah secara teknis tetapi memiliki ratusan pengguna. Dulu orang sering mengganti label objek standar agar lebih jelas, misalnya Akun menjadi “Pelanggan”. Mudah dilakukan. Lalu sistem lain ingin memakai Akun untuk Mitra, dan tidak bisa. Hal lain mungkin hanya punya sedikit pengguna tetapi butuh migrasi yang sangat besar untuk diubah, seperti nama API sebuah objek yang dirujuk di banyak tempat secara internal. Tidak ada orang luar yang melihatnya, tetapi nama yang salah terus membingungkan tim. Keduanya layak diperhatikan.
Pikirkan beberapa keputusan data yang umum:
- Objek Salesforce mana yang merepresentasikan konsep bisnis ini?
- Apa pengenal uniknya?
- Sistem mana yang menjadi system of record?
- Apakah data ini disalin ke Salesforce atau diakses di tempat lain?
- Apakah ini satu objek atau beberapa objek yang saling berhubungan?
- Siapa pemilik datanya, dan berapa lama kita menyimpannya?
- Apa batas akses default kita?
- Bagaimana data ini berpindah antarsistem?
Semua itu sangat berbeda dengan memutuskan di mana sebuah bidang muncul di halaman Lightning. Desain halaman juga penting. Hanya saja, harga dari sebuah kesalahan berbeda.
Pikirkan Radius Ledakannya
Section titled “Pikirkan Radius Ledakannya ”Cara lain memandang reversibilitas adalah radius ledakan: jika saya mengubah keputusan ini, apa lagi yang ikut bergeser?
Misalkan sesuatu yang kita modelkan sebagai bidang ternyata perlu menjadi objek anak. Itu bukan sekadar perubahan skema. Apa yang terjadi pada data yang sudah ada? Pada laporan, integrasi yang mengharapkan bidang itu, Apex dan Flow yang merujuknya, keamanan, analitik, atau agen AI yang tindakannya bergantung pada struktur aslinya?
Makin besar radiusnya, makin hati-hati kita seharusnya mengambil keputusan awalnya.
Itu juga sebabnya arsitek harus melihat melampaui bagian sistemnya sendiri. Dari dalam Salesforce, sebuah perubahan mungkin terlihat mudah. Dari sudut pandang perusahaan, perubahan itu mungkin memengaruhi dua belas sistem lain.
Keputusan Perusahaan dan Keputusan Salesforce
Section titled “Keputusan Perusahaan dan Keputusan Salesforce ”Seorang Data Architect berpikir di dua tingkat.
Di dalam Salesforce, kita memutuskan objek, hubungan, kunci, volume, akses, otomatisasi, dan bagaimana data berperilaku di platform.
Di seluruh perusahaan, kita mengajukan pertanyaan yang lebih luas. Di mana sebenarnya Pelanggan tinggal? Siapa pemilik Produk? Sistem mana yang membuat Pesanan? Apa pengenal otoritatif kita? Informasi mana yang disalin antarsistem, dan mana yang tetap di tempatnya?
Kedua tingkat itu harus terhubung. Saya pernah melihat implementasi Salesforce yang model internalnya sangat masuk akal jika dilihat sendiri, tetapi tidak cocok dengan perusahaan di sekelilingnya. Itu tidak cukup. Struktur Salesforce perlu direpresentasikan di tingkat perusahaan, dan keputusan perusahaan perlu mengalir kembali ke Salesforce.
Arsitektur adalah lalu lintas dua arah.
Perlambat Keputusan yang Mahal
Section titled “Perlambat Keputusan yang Mahal ”Salah satu bahaya di dunia teknologi adalah keputusan yang paling mudah diimplementasikan bisa tampak seperti keputusan yang paling mudah diambil. Keduanya bukan hal yang sama.
Membuat objek kustom baru itu mudah. Membuat bidang baru itu mudah. Menghubungkan API baru makin mudah, dan AI membuat semuanya lebih mudah lagi.
Tetapi kemudahan implementasi hampir tidak memberi tahu kita apa pun tentang biaya sebuah keputusan arsitektur.
Sebelum mengambil keputusan yang sulit dibatalkan, perlambat cukup lama untuk bertanya: Masalah apa yang sebenarnya kita selesaikan? Alternatif apa yang sudah kita pertimbangkan? Apa asumsi kita? Apa yang terjadi saat volume bertumbuh, dan saat bisnis berubah? Apa lagi yang akan bergantung pada ini? Apa yang terjadi jika kita salah?
Kita tidak butuh peninjauan enam bulan setiap kali membuat objek. Yang kita butuhkan adalah pemikiran yang sebanding dengan harga sebuah kesalahan. Jika itu objek untuk satu departemen atau subsistem, Anda bisa bergerak lebih cepat. Jika itu data referensi, objek pelanggan yang utama, atau sesuatu yang dipakai lintas sistem, luangkan waktu untuk memikirkannya dengan matang.
Tuliskan Alasannya
Section titled “Tuliskan Alasannya ”Ada masalah lain dengan keputusan penting: orang lupa mengapa keputusan itu diambil.
Seseorang melihat sebuah arsitektur tiga tahun kemudian dan bertanya, “Kenapa ada orang yang merancangnya seperti ini?” Kadang jawabannya memang desainnya buruk. Itu terjadi. Tetapi kadang ada alasan yang sangat baik: keterbatasan platform yang kini sudah tidak ada, persyaratan regulasi, sistem lain yang tidak bisa mendukung pendekatan yang lebih disukai, atau trade-off yang sengaja diterima demi mengejar tenggat.
Jika kita hanya mencatat apa yang kita putuskan dan bukan mengapa, arsitek berikutnya tidak punya cara untuk mengetahuinya.
Untuk keputusan yang signifikan, tuliskan. Tidak perlu dokumen 50 halaman. Catatan keputusan yang berguna bisa sangat ringkas:
Konteks: Masalah apa yang kita selesaikan?
Opsi: Alternatif realistis apa yang kita pertimbangkan?
Keputusan: Apa yang kita pilih?
Konsekuensi: Apa yang kita dapatkan, dan apa yang kita lepaskan?
Pemilik: Siapa yang bertanggung jawab atas keputusan ini?
Tinjauan: Alasan atau tanggal apa yang seharusnya membuat kita meninjaunya kembali?
Nilainya bukan pada dokumennya. Nilainya ada pada terjaganya alasan di balik keputusan.
Dan ketika sebuah keputusan berubah, jangan hapus yang asli. Gantikan dengan yang baru. Keputusan yang tepat pada 2027 mungkin tidak lagi tepat pada 2030, karena volume, bisnis, Salesforce, dan pemahaman kita semuanya berubah. Yang ingin saya simpan adalah ceritanya: inilah konteksnya, inilah keputusannya dan alasannya, inilah yang berubah, dan inilah yang kita putuskan sekarang. Itu jauh lebih berharga daripada berpura-pura kita selalu tahu jawabannya.
Di luar ujian: AI memperpendek jarak dari keputusan ke ketergantungan. Alat AI bisa mengusulkan model data dalam hitungan detik, lalu membuat objek, otomatisasi, kode integrasi, dan antarmuka pengguna di atasnya. Dulu sebuah keputusan yang meragukan butuh berbulan-bulan pengembangan sebelum banyak hal bergantung padanya; sekarang ketergantungannya datang hampir seketika. Jadi tinjau keputusan-keputusan di balik hasilnya, bukan hanya hasilnya. AI bisa membantu: ia bisa menyusun daftar opsi, menantang asumsi, dan membuat draf catatan keputusan. Tetapi arsitek tetap yang memutuskan, dan makin sulit sebuah keputusan dibatalkan, makin penting penilaian manusia itu.
Ketahui Keputusan Mana yang Penting
Section titled “Ketahui Keputusan Mana yang Penting ”Salah satu keterampilan yang ingin saya bangun dalam diri Anda adalah mengetahui ke mana perhatian Anda harus dicurahkan.
Jangan mengubah setiap pilihan konfigurasi menjadi konferensi tingkat tinggi arsitektur.
Tetapi jangan pula sembarangan mengambil keputusan yang akan dijalani organisasi selama sepuluh tahun ke depan.
Tanyakan:
Seberapa sulit ini dibatalkan?
Seberapa banyak yang akan bergantung padanya?
Jika jawabannya sangat sulit dan banyak sekali, kemungkinan besar Anda telah menemukan sebuah keputusan arsitektur.
Perlambat. Pahami persyaratannya. Jajaki alternatifnya. Tunjukkan trade-off-nya. Ambil keputusannya. Dan tuliskan alasannya.
Tujuan arsitektur bukanlah mengambil keputusan yang tidak pernah bisa berubah.
Tujuannya adalah mengenali keputusan-keputusan yang berubah pikiran atasnya akan mahal.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Keputusan mana yang bersifat arsitektur: sulit dibatalkan, dengan banyak hal yang bergantung padanya.
- Seberapa besar perhatian yang diberikan pada setiap keputusan, sebanding dengan harga sebuah kesalahan.
- Keputusan mana yang dituliskan, beserta konteks, opsi, konsekuensi, pemilik, dan titik tinjauannya.
- Bagaimana keputusan Salesforce selaras dengan keputusan perusahaan.
Jelajahi
Section titled “Jelajahi ”- Object Relationships Overview (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): dalam hubungan master-detail, akses dan kepemilikan rekaman detail mengikuti master-nya, dan menghapus master akan menghapus detailnya.
- Considerations for Object Relationships (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): lookup hanya bisa diubah menjadi master-detail jika setiap rekaman memiliki nilai di dalamnya; perubahan ini mengubah model berbagi (menjadi Controlled by Parent), dan tipe hubungan menentukan tipe laporan standar mana yang tersedia.
- Roll-Up Summary Field (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09; dicek ulang 2026-10-12, bahasa Inggris): ringkasan roll-up hanya ada pada hubungan master-detail, dan harus dihapus sebelum master-detail dapat diubah menjadi lookup.