Arsitektur Adalah Seni Trade-off

🌐 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 4 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Uji Reversibilitas · Berikutnya: Bangun untuk Hari Ini. Rencanakan untuk Besok. Rencanakan untuk Kegagalan.

Pertanyaan yang dijawab modul ini: Ketika beberapa solusi bisa berhasil, bagaimana arsitek memilih, dan bagaimana ia menjelaskan pilihannya?

Seandainya arsitektur hanya soal menemukan jawaban yang benar, semuanya akan jauh lebih mudah. Pelajari platformnya, pelajari polanya, pelajari batasannya, pilih yang tepat, selesai.

Bukan begitu cara kerja arsitektur yang sebenarnya. Keputusan yang sulit biasanya bukan antara solusi yang jelas baik dan solusi yang jelas buruk. Keputusan itu ada di antara beberapa solusi yang bisa berhasil, masing-masing dengan kelebihan dan kekurangannya, masing-masing menggeser arsitektur ke arah yang sedikit berbeda. Di situlah seorang arsitek membuktikan bahwa ia layak duduk di meja itu.

Banyak Cara untuk Menyelesaikan Masalah

Saya sudah sering memakai versi contoh ini saat mengajar para arsitek.

Bisa ada banyak cara untuk menyelesaikan sebuah masalah di Salesforce. Kadang saya memberinya angka, katakanlah sepuluh, tetapi itu analogi, bukan hitungan. Banyak opsi bermasalah sejak awal: terbentur batasan platform, melewatkan persyaratan penting, atau menimbulkan masalah keamanan atau kinerja yang tidak bisa kita terima. Opsi-opsi itu bisa cepat kita singkirkan. Sebagian lain berjalan hari ini tetapi akan bermasalah ketika datanya bertumbuh. Secara teknis berfungsi, tetapi tidak akan bertahan menghadapi pertumbuhan yang sudah kita tahu akan datang.

Yang tersisa adalah sejumlah kecil opsi yang dapat mendukung kebutuhan Anda ke depan, dan di sinilah menariknya. Masing-masing mungkin berhasil, bisa diskalakan, dan memenuhi persyaratan. Jadi mana yang benar? Mungkin semuanya. Tugas arsitek adalah memahami perbedaannya.

Bahkan sesuatu sesederhana daftar pilihan berjalan baik hari ini dan bisa bermasalah ketika datanya bertumbuh. Daftar pilihan mudah bagi pengguna. Tetapi tanyakan dari mana nilainya berasal, dan berapa banyak jumlahnya nanti. Daftar pilihan paling baik dengan kurang dari sekitar 20 nilai. Sesekali kita sampai 50, seperti negara bagian AS, dan jarang sekali lebih dari 100, seperti daftar negara, dan itu pun mulai merepotkan. Jadi untuk setiap daftar pilihan, ketahui batas atasnya. Dan mengubah nilai daftar pilihan adalah perubahan metadata, bukan perubahan data.

Pakai lookup sebagai gantinya, dan antarmuka pengguna menjadi sedikit lebih rumit. Tetapi daftarnya bisa terus bertambah tanpa batas atas, dan nilai baru bisa datang dari integrasi. Itu trade-off terhadap kemudahan penggunaan. Itulah keseimbangannya.

Click to enlarge

Optimal Tidak Berarti Sempurna

Saya memakai kata optimal dengan hati-hati. Arsitektur yang optimal bukanlah arsitektur di mana setiap keputusan individual sempurna; arsitektur seperti itu mungkin tidak ada. Arsitektur optimal adalah arsitektur yang solusinya secara keseluruhan seimbang.

Misalkan Solusi A memberi kinerja terbaik tetapi mahal dan sulit dipelihara. Solusi B lebih murah dan lebih mudah dioperasikan tetapi mengorbankan sebagian kinerja. Solusi C lebih fleksibel untuk masa depan tetapi menambah kerumitan hari ini. Mana yang optimal? Saya tidak bisa menjawab hanya dari fakta-fakta itu. Saya perlu memahami bisnisnya, persyaratannya, dan prioritasnya, serta batasan mana yang nyata dan mana yang sekadar preferensi. Arsitektur itu kontekstual. Itulah sebabnya pola yang tepat untuk satu pelanggan bisa sama sekali salah untuk pelanggan berikutnya.

Dan tugas Anda sebagai Data Architect adalah menyeimbangkan keputusan-keputusan ini. Anda akan mengambil puluhan di antaranya sendiri, atau bersama tim Anda. Ketahui keputusan mana saja itu, dan ketahui kapan sebuah keputusan berdampak lebih besar, pada biaya, waktu, atau fungsionalitas, sehingga perlu dibawa ke para pengambil keputusan utama.

Keputusan Suboptimal Bisa Menjadi Bagian dari Arsitektur yang Optimal

Ini salah satu gagasan terpenting dalam bab ini. Kadang saya dengan sadar mengambil keputusan suboptimal di satu bagian arsitektur karena keputusan itu membuat solusi secara keseluruhan menjadi lebih baik.

Mungkin saya menduplikasi sedikit data, karena menghilangkan duplikasi itu akan menimbulkan kerumitan integrasi yang tidak perlu. Mungkin saya memilih model data yang lebih sederhana, karena model yang secara teori lebih bersih akan membuat pelaporan dan penggunaan sehari-hari jauh lebih sulit. Mungkin saya menerima sedikit penurunan kinerja, karena alternatifnya menambah infrastruktur yang belum siap dioperasikan oleh organisasi.

Lihat salah satunya secara terpisah dan Anda akan bilang itu tidak optimal. Benar. Tetapi arsitektur bukan tentang mengoptimalkan setiap komponen secara sendiri-sendiri; arsitektur adalah tentang mengoptimalkan sistemnya. Keputusan yang suboptimal secara lokal bisa menjadi bagian dari arsitektur yang optimal secara global, selama kita memahami trade-off yang sedang kita ambil. Yang berbahaya adalah mengambil trade-off tanpa menyadari bahwa Anda sedang mengambilnya.

Ketahui Apa yang Anda Korbankan

Setiap kali seseorang berkata kepada saya “ini solusi terbaik,” pertanyaan saya berikutnya adalah “terbaik dalam hal apa?” Tercepat? Termurah? Paling sederhana? Paling skalabel, paling aman, paling fleksibel? Paling mudah dioperasikan, paling cepat dihadirkan, paling sedikit bergantung pada keahlian khusus? Hampir selalu ada dimensi lain di mana jawabannya bukan “terbaik.” Itulah trade-off-nya. Saya ingin tahu apa yang kita dapatkan, dan saya juga ingin tahu apa yang kita lepaskan.

Ambil dua opsi untuk sekumpulan besar data perusahaan. Yang satu menyalin data ke Salesforce, sehingga kemampuan bawaan Salesforce lebih mudah dipakai, tetapi kini kita bertanggung jawab memindahkannya, menyimpannya, menyinkronkannya, mengamankan satu salinan lagi, dan menangani latensi. Yang lain membiarkan data di tempatnya dan mengaksesnya saat dibutuhkan. Kita sudah mengurangi sebagian duplikasi, tetapi sekarang ketersediaan, kinerja kueri, ketergantungan jaringan, dan kemampuan sistem jarak jauh menjadi lebih penting. Tidak satu pun deskripsi itu memberi tahu kita mana yang harus dipilih. Deskripsi itu memberi tahu kita pertanyaan apa yang harus diajukan.

Persyaratan Tidak Semuanya Setara

Trade-off juga memaksa kita melihat bahwa tidak setiap persyaratan memiliki bobot yang sama.

Seseorang berkata, “Datanya harus tersedia seketika.” Oke, apa artinya seketika? Satu detik, sepuluh detik, satu menit? Dan mengapa? Mungkin untuk deteksi penipuan, di mana detik itu penting. Mungkin seseorang hanya tidak suka menunggu muatan malam. Itu persyaratan yang sangat berbeda, dan arsitek terus bertanya sampai kita tahu yang mana yang kita hadapi.

Saya suka persyaratan yang tahan terhadap pertanyaan: berapa besar, berapa banyak, seberapa cepat, seberapa sering, untuk siapa, dan apa yang terjadi jika tidak? “Cepat” bukanlah persyaratan arsitektur. “95 persen pembaruan pelanggan harus tersedia bagi agen layanan dalam 30 detik” jauh lebih mendekati. Sekarang kita bisa mengevaluasi trade-off.

Batasan Mengubah Jawabannya

Kadang arsitektur sama sekali tidak dibatasi oleh teknologi. Ia dibatasi oleh uang, orang, waktu, lisensi, atau kematangan organisasi.

Arsitektur yang unggul secara teknis tetapi membutuhkan tim operasional yang tidak dimiliki perusahaan bukanlah arsitektur yang baik. Kemampuan yang menyelesaikan masalah dengan elegan tetapi membutuhkan lisensi yang tidak akan dibeli pelanggan juga bukan solusinya. Dan transformasi tiga tahun yang sempurna tidak membantu perusahaan yang harus meluncur dalam delapan minggu.

Semua itu tidak berarti kita meninggalkan arsitektur yang baik karena tenggat. Itu berarti kita memahami apa yang kita kompromikan, mengapa, dan konsekuensi apa yang kita terima, dan idealnya bagaimana kita akan bergerak dari kompromi hari ini menuju arsitektur hari esok.

Arsitek Butuh Gambaran tentang “Optimal”

Ada ketegangan yang menarik di sini. Saya bilang bahwa sering kali tidak ada satu jawaban yang sempurna, dan saya juga ingin Anda menyimpan gambaran di kepala tentang seperti apa solusi yang optimal. Keduanya tidak bertentangan. Anda butuh titik acuan.

Saat melihat sebuah model data, saya ingin tahu apa yang akan saya bangun seandainya saya bisa mengoptimalkan untuk persyaratannya tanpa batasan yang tidak perlu. Lalu, ketika batasan nyata mendorong kita menjauh dari desain itu (kita meratakan sebagian model, menduplikasi sebagian data, menunda sebuah integrasi, menerima proses manual sementara), saya tidak sedang berkompromi secara acak. Saya tahu ke arah mana saya menjauh dari yang optimal, dan mengapa. Itulah seni arsitektur, dan nalurinya butuh latihan.

Gambarkan

Salah satu cara terbaik memahami sebuah trade-off adalah menggambarkannya. Diagram arsitektur bukan hiasan untuk slide presentasi; diagram adalah alat berpikir. Jika kita memilih di antara dua pendekatan, gambarkan keduanya. Di mana data tinggal, dan ke mana ia berpindah? Siapa pemiliknya? Di mana batasnya, dan di mana keamanan ditegakkan? Apa yang terjadi ketika sesuatu gagal, dan apa yang berubah saat volume bertumbuh?

Diagram memaksa ketidakjelasan muncul ke permukaan, dan memberi semua orang gambar yang sama untuk ditunjuk.

Saya belajar betapa pentingnya hal itu dalam sebuah proyek dengan perusahaan utilitas. Dari satu tinjauan ke tinjauan berikutnya, saya mendapati diri saya menjelaskan konsep yang sama berulang kali dan menarik percakapan kembali ke desain aslinya. Jadi saya mengubah cara saya memimpin rapat-rapat itu: setiap tinjauan dimulai dengan model data di layar. Bukan model terperinci dengan semua bidangnya. Model ringkasan: sebuah akun punya kontak, rekaman ini punya anak, di sinilah pekerjaannya tergantung. Sebagian besar peserta adalah eksekutif, dan itu hanya butuh beberapa menit.

Karena orang-orangnya sama dari rapat ke rapat, diagram itu menjadi bahasa bersama kami. Orang mulai memakai nama-nama di dalamnya. Pertanyaan yang berulang-ulang mulai hilang, dan rapat menjadi jauh lebih mudah. Saya menyebutnya membumikan rapat: sebuah diagram sederhana, yang ditunjukkan setiap kali, jauh lebih berharga daripada biaya membuatnya.

Tujuannya bukan kesempurnaan artistik. Kadang berupa diagram terperinci untuk para engineer, kadang lima kotak dan enam panah untuk seorang eksekutif. Tujuannya adalah kejelasan.

Jelaskan Trade-off-nya

Arsitek yang baik memaparkannya secara berurutan: inilah opsi yang kami pertimbangkan, inilah yang diberikan masing-masing, inilah biaya masing-masing, inilah opsi yang saya rekomendasikan, dan inilah alasannya.

Perhatikan bahwa rekomendasinya datang setelah trade-off. Saya tidak ingin arsitektur menjadi “Saya sudah pernah melakukan ini, percayalah.” Pengalaman sangat penting; pengalaman membantu Anda mengenali pola lebih cepat dan melihat masalah lebih awal. Tetapi pengalaman Anda seharusnya memperbaiki penalaran Anda, bukan menggantikannya. Tugas kita bukan hanya memahami arsitekturnya. Tugas kita adalah membantu organisasi memahami keputusannya, terutama ketika orang-orang yang mengambil keputusan akhir bukan arsitek.

Think Correct. Think Fast.

Anda tidak selalu punya tiga minggu untuk menganalisis setiap opsi. Kadang Anda hanya punya tiga menit. Sebuah persyaratan berubah di tengah rapat, seseorang menyebutkan batasan yang tidak Anda ketahui, atau seorang eksekutif bertanya, “Bagaimana kalau tahun depan kita butuh ini di Eropa?”

Saya memakai ungkapan Think Correct. Think Fast. (berpikir benar, berpikir cepat). Kecepatan tidak datang dari melewatkan proses berpikir. Kecepatan datang dari sudah cukup banyak berpikir sebelum saatnya tiba: Anda sudah mempelajari polanya, Anda mengenal platformnya, Anda sudah melihat kegagalan, Anda tahu pertanyaan mana yang perlu diajukan dan keputusan mana yang sulit dibatalkan. Itulah sebabnya kita mengerjakan berbagai skenario di sepanjang kursus ini. Makin banyak keputusan yang Anda analisis, makin cepat Anda mengenali bentuk keputusan berikutnya.

Saya pernah punya pelanggan yang membutuhkan pengisian formulir. Tetapi formulirnya banyak, dan pertanyaannya bisa berubah dari waktu ke waktu. Saya cepat mengenali kebutuhan akan model data survei, sebuah pola yang akan kita bahas lagi nanti dalam kursus ini. Karena saya mengenali pola dan solusinya, saya bisa membawa model data yang lebih lengkap, yang menangani persyaratan yang masih akan datang, bukan hanya yang ada di depan kami.

Arsitektur Adalah Soal Keseimbangan

Saat kita masuk lebih dalam ke arsitektur data, Anda akan menjumpai pilihan-pilihan di mana saya enggan memberi Anda aturan sederhana. Normalisasi atau diratakan? Salin datanya atau federasikan? Sinkron atau asinkron? Objek standar atau kustom? Arsipkan atau tetap online?

Ada prinsip, pola, dan batasan, dan kadang ada jawaban yang jelas salah. Tetapi sering kali tugas arsitek adalah menemukan keseimbangan yang tepat untuk sistem ini, bisnis ini, dan saat ini.

Ketahui seperti apa yang optimal. Pahami batasannya. Kenali opsi yang layak. Tunjukkan trade-off-nya. Lalu ambil keputusannya.

Itu bukan keraguan. Itulah arsitektur.

Yang Diputuskan Arsitek di Sini

• Opsi mana yang layak, dan mana yang sudah salah sekarang atau akan memburuk dalam setahun.
• Apa yang didapat dan dilepaskan oleh setiap opsi yang layak, diukur terhadap persyaratan yang tahan terhadap pertanyaan.
• Batasan mana yang nyata dan mana yang sekadar preferensi.
• Opsi mana yang direkomendasikan, setelah memaparkan trade-off-nya, dan bagaimana menjelaskannya.