11.4 Menulis Trade-off untuk Semua Pihak
Bayangkan Anda sudah menyelesaikan diagram context dan component. Tim engineer mulai mengangguk paham. Tapi tiba-tiba kepala produk bertanya, "Kalau kita pakai database yang ini, apakah fitur real-time dashboard bisa jalan di minggu pertama?" Anda menjawab bahwa ada trade-off: kecepatan real-time membutuhkan infrastruktur tambahan yang butuh waktu setup. Kepala produk mengerutkan dahi. Ia tidak paham kenapa sebuah pilihan database bisa menunda fitur yang sudah dijanjikan ke klien.
Di sinilah solution architecture sering gagal. Bukan karena diagramnya salah, tapi karena konsekuensi dari setiap keputusan tidak ditulis dalam bahasa yang bisa dipahami non-engineer. Engineer mungkin sudah paham bahwa pilihan database tertentu mempengaruhi latency, konsistensi, dan biaya operasional. Tapi kepala produk, operation, security, dan manajemen tidak tinggal di dunia itu. Mereka butuh terjemahan: apa arti pilihan teknis ini bagi jadwal, biaya, risiko, dan pengalaman pengguna.
Trade-off bukan catatan teknis. Ia adalah jembatan antara keputusan arsitektur dan keputusan bisnis. Setiap kali Anda memilih satu opsi, Anda menutup opsi lain. Tugas Anda bukan hanya mencatat pilihan itu, tetapi menjelaskan apa yang hilang dan apa yang didapat.
Mulailah dengan menulis asumsi. Setiap solusi berdiri di atas asumsi: jumlah pengguna, pola traffic, ketersediaan data, kecepatan koneksi, atau perilaku pengguna. Asumsi ini perlu ditulis eksplisit karena jika ternyata salah, solusi bisa runtuh. Tulis asumsi dalam bahasa sederhana. Misalnya: "Asumsi: rata-rata pengguna mengakses aplikasi dua kali sehari. Jika ternyata sepuluh kali, arsitektur saat ini perlu diubah karena kapasitas server tidak dirancang untuk beban itu." Kalimat ini langsung bisa dipahami manajer produk dan operation.
Keputusan terbuka adalah bagian yang sering disembunyikan. Banyak arsitek enggan menulis bahwa ada keputusan yang belum diambil. Mereka takut terlihat tidak siap. Padahal keputusan terbuka adalah informasi berharga bagi bisnis. Jika Anda belum memutuskan apakah akan memakai cloud publik atau on-premise, tulis itu. Jelaskan konsekuensinya: selama belum diputuskan, tim tidak bisa memesan server, tidak bisa mulai integrasi dengan sistem internal, dan timeline akan terganggu. Dengan begitu, manajemen tahu bahwa mereka perlu mengambil keputusan itu minggu ini, bukan bulan depan.
Konsekuensi harus ditulis per pihak. Satu keputusan teknis bisa berdampak berbeda pada tiap pemangku kepentingan. Ambil contoh keputusan memakai microservices. Bagi engineer, artinya tim bisa deploy independen. Bagi operation, artinya perlu alat monitoring yang lebih canggih. Bagi bisnis, artinya fitur bisa dirilis lebih cepat tetapi biaya operasional naik. Bagi security, artinya permukaan serangan lebih luas dan perlu review tambahan. Tulis semua ini dalam satu tabel atau paragraf terstruktur agar setiap pihak bisa langsung melihat dampak pada dirinya.
Bahasa yang dipakai harus konkret. Jangan menulis "terdapat potensi peningkatan latency." Tulis "pengguna akan merasakan jeda 2 detik saat pertama kali membuka halaman." Jangan menulis "biaya operasional berpotensi naik." Tulis "biaya server bulanan naik dari 10 juta menjadi 25 juta jika jumlah pengguna mencapai 50 ribu." Angka dan skenario membuat konsekuensi terasa nyata.
Dengan trade-off yang jelas, asumsi yang eksplisit, dan keputusan terbuka yang diakui, solution architecture berubah dari dokumen teknis menjadi alat pengambilan keputusan bisnis. Kepala produk bisa memutuskan apakah fitur real-time layak ditunda demi biaya yang lebih rendah. Manajemen bisa memutuskan apakah investasi infrastruktur tambahan sebanding dengan value yang didapat. Security bisa menyiapkan review lebih awal.
Setelah semua trade-off ditulis, tibalah saatnya menjaga dokumen ini tetap hidup selama proses delivery. Sebab keputusan bisa berubah, asumsi bisa terbukti salah, dan trade-off perlu ditulis ulang.
