11.1 Dokumen yang Dipakai, Bukan Disimpan
Bayangkan Anda baru saja menyelesaikan rapat dengan tim produk. Sebuah ide aplikasi baru sudah disetujui. Semua orang antusias. Tim produk sudah membayangkan fitur-fiturnya. Tim bisnis sudah menghitung potensi pendapatannya. Tim engineer sudah membayangkan teknologi yang akan dipakai. Lalu seseorang berkata, “Kita perlu solution architecture dulu.”
Beberapa hari kemudian, seorang arsitek mengirim dokumen setebal empat puluh halaman. Semua orang membaca bagian yang relevan dengan mereka, lalu dokumen itu disimpan di folder bersama. Tidak ada yang membukanya lagi sampai tiga bulan kemudian, ketika tim engineer menemukan bahwa desain yang dipilih tidak cocok dengan data yang tersedia. Saat itu, dokumen sudah usang. Tim harus mengambil keputusan ulang tanpa catatan yang jelas.
Situasi ini terjadi di hampir semua organisasi yang pernah saya lihat. Solution architecture document diperlakukan seperti dokumen proyek yang harus ada di checklist, bukan sebagai alat kerja yang dipakai setiap hari. Padahal, tujuan dokumen ini bukan untuk diarsipkan. Tujuannya adalah untuk empat hal: alignment, decision, delivery, dan evidence.
Alignment artinya semua pihak melihat solusi yang sama. Tim bisnis, engineer, operation, security, dan manajemen harus punya pemahaman yang selaras tentang apa yang akan dibangun, mengapa dibangun seperti itu, dan apa konsekuensinya. Tanpa alignment, setiap tim berjalan dengan asumsinya sendiri. Hasilnya adalah solusi yang tidak memenuhi ekspektasi, atau malah tidak bisa dioperasikan.
Decision artinya dokumen ini adalah tempat keputusan dicatat. Setiap solusi penuh dengan pilihan: pakai teknologi A atau B, integrasi langsung atau melalui middleware, data disimpan di database relasional atau di data lake. Keputusan-keputusan ini harus tercatat dengan jelas, termasuk siapa yang memutuskan dan apa pertimbangannya. Tanpa catatan keputusan, tim akan mengulang diskusi yang sama berulang kali.
Delivery artinya dokumen ini harus membantu tim membangun. Engineer harus bisa membaca diagram dan memahami komponen apa yang harus dibuat. Operation harus bisa menyiapkan infrastruktur. Security harus bisa melakukan review. Dokumen yang baik adalah dokumen yang menjawab pertanyaan-pertanyaan praktis selama pengembangan.
Evidence artinya dokumen ini menjadi bukti bahwa keputusan diambil dengan pertimbangan yang matang. Ketika ada masalah di kemudian hari, tim bisa kembali ke dokumen ini untuk melihat apa yang diputuskan, mengapa diputuskan, dan apa asumsinya. Ini penting untuk audit, troubleshooting, dan pembelajaran organisasi.
Solution architecture document yang baik bukanlah dokumen mati. Ia adalah dokumen hidup yang diperbarui sepanjang pengembangan. Ia ditulis untuk dibaca, digunakan, dan dirujuk. Ia tidak perlu tebal. Ia perlu cukup jelas untuk membuat semua pihak bergerak ke arah yang sama.
Pertanyaan berikutnya: apa isi minimum yang harus ada agar dokumen ini benar-benar dipakai, bukan disimpan? Itu menjadi fokus subbab berikutnya.
