23.4 Menemukan Dependency Sebelum Terlambat
Anda sudah menyusun tiga opsi solusi. Masing-masing punya trade-off sendiri. Sekarang saatnya memilih, dan Anda merasa sudah siap. Tapi tunggu. Ada satu hal yang sering luput dari perhatian: apa yang harus terjadi sebelum solusi ini bisa berjalan?
Bayangkan tim memilih opsi yang paling efisien secara teknis. Ternyata opsi itu membutuhkan data dari sistem lama yang sedang dalam proses migrasi. Tim data sedang sibuk dan tidak bisa memberikan akses dalam tiga bulan ke depan. Atau opsi itu membutuhkan persetujuan dari tim security yang hanya rapat sebulan sekali. Atau opsi itu bergantung pada library baru yang belum melalui proses persetujuan vendor.
Inilah dependency. Dan masalahnya, dependency tidak selalu kelihatan di awal. Ia sering muncul sebagai kejutan di tengah jalan, saat Anda sudah terlanjur berkomitmen pada jadwal.
Seorang arsitek yang baik tidak menunggu dependency ditemukan oleh tim engineering. Ia secara aktif mencarinya sebelum implementasi dimulai. Caranya dengan bertanya: sistem apa yang harus tersedia? Data apa yang harus sudah siap? Keputusan siapa yang harus sudah diambil? Tim mana yang harus sudah selesai dengan bagian mereka? Dan yang paling penting, apa yang terjadi jika semua itu tidak terpenuhi?
Ada tiga jenis dependency yang perlu Anda petakan. Pertama, dependency teknis. Misalnya, fitur A tidak bisa jalan sebelum service B dirilis. Atau database tertentu harus sudah di-upgrade. Atau API eksternal harus sudah aktif. Kedua, dependency organisasi. Misalnya, Anda butuh keputusan dari compliance, atau butuh resource dari tim lain yang sedang sibuk. Ketiga, dependency jadwal. Misalnya, ada event tahunan yang membuat semua orang tidak bisa cuti, atau ada audit yang mengunci perubahan sistem.
Sebagai contoh, bayangkan Anda akan membangun dashboard sales yang membutuhkan data real-time dari ERP dan persetujuan keamanan. Berikut daftar periksa dependency-nya.
Berikut adalah diagram yang merangkum tiga jenis dependency beserta contoh dan dampaknya.
Setiap dependency punya potensi menjadi blokir. Blokir adalah situasi di mana Anda tidak bisa maju karena sesuatu belum siap. Dan blokir adalah musuh terbesar prediktabilitas delivery.
Setelah Anda memetakan dependency, langkah berikutnya adalah mitigasi awal. Untuk setiap dependency, tanyakan: apa yang bisa kita lakukan sekarang untuk mengurangi risikonya? Mungkin Anda perlu mulai diskusi dengan tim data lebih awal. Mungkin Anda perlu menyiapkan jalur cadangan plan jika API eksternal belum siap. Mungkin Anda perlu membuat prototype yang bisa jalan dengan data dummy dulu. Atau mungkin Anda perlu menaikkan urgensi ke manager yang bisa memprioritaskan ulang.
Mitigasi tidak harus rumit. Kadang cukup dengan satu pertanyaan: "Kalau dependency ini tidak siap, apa rencana cadangan kita?" Pertanyaan sederhana ini bisa mengubah cara tim melihat risiko.
Yang menarik, proses menemukan dependency ini juga membantu Anda membangun kredibilitas sebagai orang yang mampu membentuk masalah. Ketika Anda datang ke stakeholder dengan tiga opsi solusi dan peta dependency yang jelas, Anda tidak hanya menawarkan pilihan. Anda menunjukkan bahwa Anda sudah memikirkan apa yang bisa salah dan bagaimana mengatasinya. Ini adalah bukti bahwa Anda tidak bekerja sebagai orang yang hanya menunggu instruksi, tetapi sebagai arsitek yang membantu organisasi bergerak dengan lebih aman.
Dengan dependency yang sudah terpetakan dan mitigasi yang sudah direncanakan, Anda sekarang siap untuk langkah selanjutnya: mengkomunikasikan semua ini kepada orang yang tepat. Karena peta dependency terbaik tidak ada gunanya jika tidak sampai ke tangan yang bisa mengambil keputusan. Dan untuk itu, Anda perlu berbicara dengan bahasa yang sesuai dengan audiens Anda.
