Berpikir seperti Arsitek
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 1 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: ikhtisar bab · Berikutnya: Model Data Adalah Kerangkanya
Pertanyaan yang dijawab modul ini: Apa bedanya membangun dengan merancang arsitektur, dan apa sebenarnya yang dikerjakan seorang arsitek?
Hampir sepanjang karier saya, saya adalah seorang pembangun.
Saya memulai sebagai developer. Saya bekerja dengan Java dan .NET sebelum pindah ke Salesforce, dan bertahun-tahun saya merancang sistem, menulis kode, mengintegrasikan platform, mengajar para arsitek, dan meninjau arsitektur.
Namun, salah satu pelajaran terpenting yang saya dapat di sepanjang jalan adalah bahwa menjadi pembangun yang hebat dan menjadi arsitek yang hebat tidak selalu sama.
Seorang pembangun bertanya:
Bagaimana cara saya membangun ini?
Seorang arsitek harus mengajukan serangkaian pertanyaan yang berbeda:
Haruskah kita membangun ini?
Mengapa kita membangunnya dengan cara ini?
Apa saja alternatifnya?
Apa yang terjadi ketika ini menjadi lebih besar?
Apa yang terjadi ketika ini gagal?
Dan keputusan apa yang kita ambil hari ini yang tiga tahun lagi akan membuat kita berharap dulu kita memikirkannya lebih matang?
Saya ingat pernah terlibat dalam proyek untuk sebuah bisnis ritel yang memakai sistem janji temu. Saya bertanya: berapa janji temu per hari per toko? Lalu, berapa jumlah toko Anda? Dan berapa hari dalam seminggu Anda buka? Dengan cepat saya sadar bahwa kami akan memiliki jutaan janji temu hanya di tahun pertama. Itulah pertanyaan-pertanyaan yang diajukan arsitek di awal proyek.
Perubahan cara berpikir itulah inti sebenarnya dari kursus ini.
Orang yang Memegang Cetak Biru
Section titled “Orang yang Memegang Cetak Biru ”Saya sudah sering memakai analogi ini saat mengajar para arsitek.
Bayangkan sebuah lokasi konstruksi. Ada orang yang menuang beton, memasang listrik, memasang pipa, membuat rangka dinding, dan mengerjakan puluhan pekerjaan khusus lainnya. Mereka harus sangat mahir di bidangnya masing-masing.
Tetapi harus ada juga seseorang yang memegang cetak birunya.
Orang itu harus memahami bagaimana semua bagian itu saling terhubung. Ia harus menyadari ketika sesuatu yang terjadi di satu bagian proyek menimbulkan masalah di bagian lain.
Itulah arsitektur.
Di dunia teknologi, kita kadang keliru mengira bahwa arsitek hanyalah orang yang paling banyak tahu. Sebenarnya bukan itu. Memahami platform memang penting. Anda butuh kedalaman teknis. Tetapi arsitektur bukan lomba cerdas cermat.
Tugas arsitek adalah mengambil keputusan yang baik, terkadang dengan informasi yang tidak lengkap dan kebutuhan yang saling bertentangan, serta memahami konsekuensi dari keputusan-keputusan itu.
Itu keterampilan yang sangat berbeda.
Jangan Langsung Menerima Persyaratannya
Section titled “Jangan Langsung Menerima Persyaratannya ”Salah satu kebiasaan pertama yang ingin saya tanamkan pada para arsitek itu sederhana:
Tanyakan mengapa.
Seseorang berkata kepada Anda:
Kita butuh objek baru.
Mengapa?
Kita perlu bidang ini disalin ke Akun.
Mengapa?
Kita perlu semua data ini disimpan di Salesforce.
Mengapa?
Itu tidak berarti mempersulit. Itu berarti memahami kebutuhan bisnis yang sebenarnya, alih-alih langsung menerapkan solusi yang diusulkan.
Sebuah persyaratan sering datang dengan menyamar sebagai desain.
“Kita butuh objek kustom baru” belum tentu merupakan persyaratan. Persyaratannya mungkin sebenarnya “kita perlu melacak informasi ini secara terpisah.” Keduanya bukan hal yang sama.
Setelah memahami persyaratan yang sebenarnya, Anda bisa mulai menjajaki alternatif. Mungkin objek baru memang jawaban yang tepat. Mungkin informasinya lebih cocok ditempatkan di sesuatu yang sudah ada. Mungkin Salesforce sama sekali tidak seharusnya memiliki data itu.
Arsitek harus memisahkan apa yang dibutuhkan bisnis dari satu cara yang diusulkan untuk memenuhinya.
Kami pernah mengerjakan sebuah aplikasi penjualan, dan pelanggan memiliki beberapa persetujuan, masing-masing dengan penyetuju dan tanggal. Permintaan pertama mereka adalah menambahkan Penyetuju 2 dan Penyetuju 3, masing-masing dengan tanggal, sebagai bidang di Peluang. Ketika kami menggali lebih dalam, kami sadar bahwa penyetujunya bisa lebih dari dua atau tiga. Jadi kami memindahkan persetujuan ke objek anak. Permintaannya adalah bidang tambahan; persyaratannya adalah melacak setiap persetujuan, berapa pun jumlahnya nanti.
Berpikir Melampaui Persyaratan
Section titled “Berpikir Melampaui Persyaratan ”Ada dua kebiasaan yang muncul dari bertanya mengapa, dan masing-masing mendapat modulnya sendiri di bab ini.
Biasanya ada lebih dari satu jawaban. Salesforce memberi kita banyak cara untuk menyelesaikan masalah, dan sebagian di antaranya hampir langsung terlihat salah. Memilih di antara cara-cara yang berhasil adalah seni trade-off (modul 4).
Dan persyaratan yang diberikan kepada Anda bukanlah seluruh persyaratan yang Anda miliki. Tidak ada yang berkata “pastikan ini tetap berjalan ketika muatan malam hanya berhasil separuh,” tetapi itu tetap sebuah persyaratan. Saya melihat setiap desain melalui tiga lensa, bangun untuk hari ini, rencanakan untuk besok, rencanakan untuk kegagalan (modul 5).
Bayangkan seseorang yang menyewa arsitek untuk merancang sebuah gedung. Ia tidak meminta alarm kebakaran atau sistem sprinkler, atau agar gedungnya tetap berdiri saat gempa. Ia mengharapkan semua itu sebagai bagian dari pekerjaan, tanpa perlu meminta. Dunia kita bekerja dengan cara yang sama. Tidak ada yang meminta penanganan error yang baik, log, atau cara untuk pulih ketika sesuatu gagal. Arsiteklah yang harus tahu sistem mana yang termasuk dalam desain, lalu memasukkannya.
Tunjukkan Alasan Anda
Section titled “Tunjukkan Alasan Anda ”Seorang arsitek tidak seharusnya masuk ke ruangan lalu mengumumkan, “Inilah yang akan kita lakukan.”
Tugas Anda juga menjelaskan mengapa. Saya ingin para pemangku kepentingan memahami alternatif yang kami pertimbangkan dan trade-off yang terlibat. Itu tidak berarti memberikan dokumen desain 40 halaman kepada seorang eksekutif. Itu berarti mampu menjelaskan arsitektur yang sama kepada developer, kepada pihak bisnis, dan kepada eksekutif: percakapan yang berbeda tentang keputusan yang sama.
Caranya adalah dengan cetak biru dan instruksi yang jelas, seperti orang yang memegang cetak biru di lokasi konstruksi. Bagi seorang Data Architect, salah satu cetak biru terpenting adalah model data.
Jika tidak ada yang memahami mengapa sebuah keputusan diambil, besar kemungkinan suatu saat seseorang akan membatalkannya. Dan alasannya bisa saja sangat masuk akal, karena tidak pernah ada yang menjelaskan keputusan aslinya.
Arsitek Tidak Perlu Membangun Semuanya
Section titled “Arsitek Tidak Perlu Membangun Semuanya ”Ada satu peralihan lain yang bisa terasa sulit, terutama bagi mereka yang masuk ke dunia arsitektur dari jalur pengembangan.
Anda tidak harus membangun semuanya sendiri.
Saya masih suka memahami cara kerja sesuatu sampai ke tingkat yang sangat teknis, dan fondasi itu penting. Tetapi sebagai arsitek, tanggung jawab Anda menjadi lebih besar daripada implementasi Anda sendiri. Anda tidak harus membangun semuanya; Anda perlu tahu cara memberi orang-orang yang membangunnya arahan dan parameter yang tepat. Artinya, Anda cukup paham untuk membimbing pekerjaan mereka, untuk mengenali kapan sebuah usulan implementasi menimbulkan masalah arsitektur, dan untuk berpindah antara detail dan gambaran besarnya.
Kadang itu berarti menyelami sebuah kueri, API, atau model data secara mendalam.
Kadang itu berarti mundur selangkah dan bertanya apakah kita memang perlu melakukan semua itu sejak awal.
Dan makin lama, yang membangun bukan hanya manusia. Dengan AI, arsitek mungkin bekerja langsung dengan alat yang menghasilkan objek, kode, dan layarnya. Maka arahan, parameter, dan pedomannya diberikan kepada AI, dan memberikannya dengan baik makin menjadi tanggung jawab arsitek. Kita akan kembali ke hal itu di modul 7.
Itulah bagian dari perjalanan dari pembangun menjadi arsitek.
Tugas Anda Adalah Mengambil Keputusan
Section titled “Tugas Anda Adalah Mengambil Keputusan ”Pada akhirnya, arsitektur adalah tentang keputusan.
Sebagian keputusan mudah diubah. Sebagian lagi tidak.
Tata letak halaman bisa diubah. Sebuah label bisa diganti namanya.
Tetapi jika Anda memilih model data dasar yang salah, menerbitkan pengenal yang kemudian diandalkan oleh puluhan sistem, atau menaruh salinan utama data penting di tempat yang salah, berubah pikiran menjadi jauh lebih mahal.
Itulah keputusan arsitektur. Dan keputusan-keputusan semacam itulah yang menjadi fokus kursus ini.
Sebagai Data Architect, Anda akan mengambil keputusan tentang bagaimana informasi disusun, di mana ia tinggal, bagaimana ia bertumbuh, bagaimana ia berpindah, siapa yang dapat mengaksesnya, dan bagaimana bagian lain perusahaan memahaminya.
Teknologinya memang penting.
Tetapi mengetahui setiap fitur Salesforce bukanlah tujuannya.
Tujuannya adalah mengembangkan penilaian untuk mengetahui alat mana yang dipakai, kapan memakainya, apa yang Anda korbankan, dan apa yang terjadi selanjutnya.
Itulah berpikir seperti arsitek.
Dan sekarang kita bisa mulai berpikir seperti Data Architect.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Apakah sebuah permintaan merupakan persyaratan yang nyata, atau satu usulan desain untuk memenuhinya.
- Pertanyaan apa yang harus diajukan sebelum apa pun dibangun: haruskah kita, mengapa dengan cara ini, apa lagi yang bisa kita lakukan, apa yang terjadi ketika ini bertumbuh atau gagal.
- Keputusan mana yang menjadi wewenang arsitek, dan mana yang menjadi milik orang-orang yang membangun; serta arahan dan parameter apa yang diberikan kepada para pembangun, baik manusia maupun AI.
- Cara menjelaskan sebuah keputusan agar developer, pihak bisnis, dan eksekutif masing-masing memahaminya.