Bangun untuk Hari Ini. Rencanakan untuk Besok. Rencanakan untuk Kegagalan.

🌐 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 5 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Arsitektur Adalah Seni Trade-off · Berikutnya: Kenali Alat Anda: Sembilan Pertanyaan

Pertanyaan yang dijawab modul ini: Bagaimana merancang untuk persyaratan hari ini sambil merencanakan pertumbuhan dan kegagalan?

Salah satu kesalahan paling mudah dalam arsitektur adalah merancang hanya untuk persyaratan yang ada di depan mata. Kita punya proyek, backlog, dan persyaratan. Kita membangun sesuatu yang memenuhinya. Berhasil, dan kita menyatakan kemenangan. Enam bulan kemudian bisnis berubah, atau datanya bertumbuh, atau unit bisnis lain ingin memakainya, atau kita mengakuisisi perusahaan, atau sistem baru perlu diintegrasikan, atau sesuatu gagal tanpa ada yang merencanakannya.

Semua itu seharusnya tidak mengejutkan seorang arsitek. Kita tidak bisa memprediksi semua yang akan terjadi, tetapi kita bisa merancang dengan kesadaran bahwa sesuatu pasti akan terjadi. Itulah sebabnya saya melihat arsitektur melalui tiga lensa:

Bangun untuk hari ini. Rencanakan untuk besok. Rencanakan untuk kegagalan.

Anda butuh ketiganya.

Click to enlarge

Bangun untuk Hari Ini

Arsitektur dimulai dari masalah yang benar-benar kita hadapi. Kedengarannya jelas, tetapi arsitek bisa melakukan kesalahan yang berlawanan dengan pemikiran jangka pendek: kita bisa merancang secara berlebihan. Bagaimana kalau kita mengakuisisi dua belas perusahaan, punya satu miliar pelanggan, berekspansi ke 40 negara, dan setiap sistem butuh integrasi waktu nyata? Mungkin saja. Tetapi apakah itu kemungkinan nyata, atau kita sedang mengarang masalah? Arsitektur bukan tentang membangun sistem paling canggih yang bisa kita bayangkan. Arsitektur adalah tentang membangun sistem yang sesuai.

Jadi mulailah dari hari ini: apa yang dibutuhkan bisnis, volume, pengguna, dan transaksi yang sebenarnya, seberapa sering data berubah dan seberapa cepat ia harus berpindah, siapa yang butuh akses, serta dari mana data berasal dan ke mana ia pergi. Dan yang paling penting: mengapa? Jawaban-jawaban itu memberi kita sesuatu yang konkret untuk dirancang.

Cari Persyaratan yang Tersirat

Persyaratan yang diberikan kepada Anda belum tentu merupakan seluruh persyaratan yang Anda miliki. Hampir selalu ada persyaratan tersirat.

Bisnis berkata, “Kita butuh data pelanggan di Salesforce.” Oke. Berarti seseorang harus memiliki data itu dan memutuskan seberapa segar data itu harus. Kita perlu tahu apa yang terjadi ketika sistem sumber mati, bagaimana kita akan tahu ketika sinkronisasi gagal, dan pihak mana yang menang ketika Salesforce dan sumbernya tidak sepakat. Kita butuh periode retensi, model akses, keputusan tentang bidang sensitif, dan cara untuk memperbaiki data yang buruk.

Tidak satu pun dari itu ada di user story. Semuanya tetap arsitektur. Bagian besar dari menjadi arsitek adalah belajar mengenali pertanyaan-pertanyaan yang belum diajukan.

Ketahui Angka-Angka Anda

Saya terus-menerus mendorong para arsitek untuk mengukur. Jangan bilang datanya banyak; katakan berapa banyak. Sepuluh ribu, sepuluh juta, seratus juta, satu miliar? Semua itu arsitektur yang sangat berbeda. Jangan bilang integrasinya sering berjalan: setiap jam, setiap menit, seribu kali per detik? Jangan bilang kita bertumbuh dengan cepat. Seberapa cepat?

Jika saya tidak punya angka yang lebih baik, patokan saya adalah pertumbuhan 30 persen per tahun. Itu bukan prediksi; itu alat pemaksa. Jika seseorang bilang kita punya 10 juta rekaman hari ini, saya tidak ingin diskusinya berhenti di 10 juta. Dengan 30 persen per tahun, kita akan berada di sekitar 13 juta tahun depan, 17 juta tahun berikutnya, dan sekitar 22 juta setahun setelahnya. Sekarang mari bicara soal desain. Jika bisnis bilang 30 persen itu tidak masuk akal, bagus: beri saya angka yang sebenarnya. Intinya adalah menjadikan pertumbuhan bagian dari diskusi arsitektur.

Saya menyebutnya Jumlah Nol ala Steve (Steve’s Number of Zeros). Satu nol tambahan bisa mengubah arsitektur Anda sepenuhnya. Sepuluh ribu, seratus ribu, satu juta, sepuluh juta, seratus juta: fiturnya tidak berubah, dan persyaratannya mungkin tidak berubah, tetapi arsitekturnya bisa berubah.

Ingat janji temu dari modul 1? Mari kita beri angka yang sebenarnya. Lebih dari 1.200 lokasi, 100 janji temu per lokasi per hari, enam hari seminggu, sekitar 305 hari setahun. Itu lebih dari 36 juta janji temu di tahun pertama. Setiap kunjungan membuat dua rekaman, jadi lebih dari 73 juta rekaman. Sekarang simpan riwayat lima tahun, dengan pertumbuhan 30 persen per tahun, dan jumlahnya melewati 650 juta rekaman. Fitur yang sama, persyaratan yang sama. Beberapa nol lagi, dan arsitekturnya sangat berbeda.

Rencanakan untuk Besok

Begitu memahami hari ini, saya melihat ke depan: apa yang cukup mungkin berubah? Volume adalah salah satunya, tetapi hari esok bukan hanya soal lebih banyak. Hari esok juga bisa berarti berbeda: lebih banyak produk, unit bisnis, dan negara; persyaratan privasi yang berbeda; kanal dan integrasi baru; merger atau akuisisi; strategi data master atau platform analitik yang baru; agen AI yang mengonsumsi informasi yang dulu dirancang hanya untuk manusia.

Itulah sebabnya saya sangat peduli apakah arsitektur bisa bertumbuh lewat penambahan alih-alih perubahan terus-menerus. Jika bisnis menambah produk, bisakah model menampungnya? Jika sistem lain butuh datanya, bisakah kita menyediakannya dengan rapi? Jika volume melonjak, apakah kita punya ruang untuk bergerak? Jika struktur bisnis berubah, apakah kita harus membongkar model datanya? Kita tidak berusaha memprediksi masa depan dengan sempurna. Kita berusaha agar tidak terpojok oleh desain kita sendiri.

Jangan Membangun Hari Esok Hari Ini

Ada keseimbangan di sini. Merencanakan untuk besok tidak berarti membangun sistem hari esok hari ini. Jika kita punya 100.000 rekaman dan mungkin punya 100 juta dalam lima tahun, bukan berarti kita membangun arsitektur 100 juta rekaman sekarang. Itu bisa membawa biaya dan kerumitan yang belum kita butuhkan.

Pertanyaan yang ingin saya jawab adalah: bisakah arsitektur hari ini berkembang menjadi arsitektur hari esok? Jika kita bisa memulai dengan sederhana dengan jalan yang jelas ke depan, itu sering lebih baik daripada membayar biaya kerumitan bertahun-tahun lebih awal. Bahayanya bukan memulai dari yang kecil. Bahayanya adalah memulai di suatu tempat yang tidak punya jalan ke mana pun.

Rencanakan untuk Kegagalan

Sekarang bagian yang tidak disukai siapa pun untuk dibicarakan: segala sesuatu bisa gagal. Saya belum pernah merancang sistem di mana setiap komponen selalu tersedia selamanya, setiap integrasi berhasil, setiap pengguna memasukkan data yang sempurna, dan setiap sistem eksternal berperilaku persis seperti yang didokumentasikan. Jadi jangan merancang sistem seperti itu.

Tanyakan apa yang bisa gagal, lalu tanyakan apa yang terjadi ketika itu gagal. Sebuah integrasi kehabisan waktu. Sebuah API menolak permintaan. Muatan malam memproses 800.000 rekaman dan gagal pada 200.000. Sistem sumber mati. Seorang pengguna memasukkan data yang tidak valid. Sebuah pengenal eksternal muncul dua kali. Sistem hulu mengubah format sebuah nilai tanpa mengubah nama bidangnya. Sebuah proses berhasil di satu sistem dan gagal di sistem lain. Ini bukan kasus tepi yang langka. Beginilah wujud production yang sebenarnya.

Keberhasilan Sebagian Tetaplah Kegagalan yang Harus Anda Pahami

Kegagalan sebagian sangat berbahaya dalam arsitektur data. Bayangkan memindahkan satu juta rekaman, dan prosesnya melaporkan bahwa ia selesai. Bagus. Tetapi apakah yang tiba satu juta, atau 999.997, dan tiga mana yang hilang? Mungkin 200.000 gagal, sebagian dibuat dua kali, atau semuanya tiba tetapi beberapa bidang gagal ditransformasi.

“Job selesai” tidak sama dengan datanya benar. Seorang data architect memikirkan rekonsiliasi: bagaimana kita tahu apa yang seharusnya terjadi, apa yang benar-benar terjadi, dan selisihnya? Lalu apa yang kita lakukan terhadapnya?

Inilah yang saya lakukan ketika sistemnya menjadi rumit. Rekaman berpindah dari A ke B, dari kiri ke kanan. Lalu B mengirim sesuatu kembali: konfirmasi untuk setiap rekaman yang diterima dan disimpannya. Sekarang A bisa membandingkan apa yang dikirimnya dengan apa yang dikonfirmasi. Jika setiap rekaman punya konfirmasi, prosesnya berhasil. Jika ada konfirmasi yang hilang, prosesnya tidak berhasil, apa pun kata status job-nya, dan kita tahu persis rekaman mana yang harus dikejar: coba lagi, teruskan ke seseorang, atau bunyikan peringatan.

Click to enlarge

Gagal dengan Anggun

Ketika kegagalan terjadi, saya ingin tahu apa yang dilakukan sistem selanjutnya: apakah ia mencoba lagi, dan apakah secara otomatis atau tidak; apa yang terjadi jika transaksi yang sama diproses dua kali; ke mana rekaman yang gagal pergi, dan apakah rekaman yang baik tetap mengalir melewati yang buruk; siapa yang diberi peringatan, dengan informasi apa, dan bagaimana mereka mengulang kegagalan itu; dan bagaimana pengguna mengetahui ada yang salah.

Dan yang paling penting: bisakah kita pulih tanpa memperburuk masalahnya? Strategi coba lagi yang menciptakan data duplikat bukanlah strategi pemulihan yang baik. Arsitektur yang baik mengasumsikan kegagalan dan memberi kita jalan kembali.

Pantau Apa yang Penting

Merencanakan kegagalan tanpa pemantauan sebenarnya bukan merencanakan. Jika sebuah integrasi gagal pukul 2.00 dini hari dan tidak ada yang menyadarinya sampai seorang pelanggan menelepon tiga hari kemudian, kita tidak punya arsitektur operasional. Kita hanya punya harapan.

Tentukan apa yang perlu bisa diamati: apakah prosesnya berjalan, berapa lama waktunya, berapa rekaman yang diproses, berapa yang berhasil dan gagal? Apakah volumenya tiba-tiba berbeda dari biasanya? Apakah antreannya bertambah, apakah error meningkat? Arsitektur tidak berakhir ketika deployment berhasil. Seseorang harus mengoperasikan sistem ini besok, dan itu bagian dari desain.

Berpikirlah ke Tiga Arah

Terus terapkan ketiga lensa itu di sepanjang sisa kursus ini. Saat merancang model data: apakah berjalan hari ini, bisakah bertumbuh besok, dan apa yang terjadi ketika datanya salah atau tidak lengkap? Sebuah integrasi: apakah ia memindahkan data hari ini, bisakah ia menangani volume dan sistem esok hari, dan apa yang terjadi ketika salah satu sisi mati? Volume data besar: apa yang kita punya hari ini, ke mana arah angkanya, dan bagaimana kita pulih ketika sebuah operasi besar hanya berhasil sebagian?

Teknologinya berubah dari bab ke bab. Pertanyaannya tidak.

Arsitektur Hidup Sepanjang Waktu

Seorang developer kadang bisa melihat sebuah persyaratan dan bertanya, “Apakah ini berjalan?” Arsitek harus bertanya lebih jauh: apakah ini berjalan hari ini, apakah ini masih berjalan besok, dan apa yang terjadi ketika ini sama sekali tidak berjalan? Ketiga pertanyaan itu membawa kita melampaui implementasi, masuk ke kehidupan sistem itu.

Anda tidak akan bisa memprediksi setiap persyaratan masa depan atau mencegah setiap kegagalan. Itu bukan tujuannya. Tujuannya adalah membangun sesuatu yang sesuai dengan apa yang kita ketahui hari ini, menyisakan ruang untuk bergerak besok, dan punya rencana ketika kenyataan tidak mau bekerja sama.

Bangun untuk hari ini. Rencanakan untuk besok. Rencanakan untuk kegagalan. Kita akan memakai ketiga lensa itu berulang kali.

Yang Diputuskan Arsitek di Sini

• Berapa volume dan pertumbuhan yang sebenarnya, dan angka mana yang akan mengubah desain.
• Persyaratan tersirat mana yang belum dinyatakan oleh bisnis.
• Bagaimana desain hari ini bisa berkembang menjadi desain hari esok, tanpa membangun sistem hari esok sekarang.
• Apa yang terjadi ketika sesuatu gagal: pemulihan, rekonsiliasi, dan pemantauan.