11.5 Menjaga Dokumen Tetap Hidup Selama Delivery
Setelah dokumen selesai ditulis, tantangan berikutnya adalah menjaganya tetap relevan selama delivery berlangsung. Ini adalah titik di mana banyak solution architecture mulai mati. Tim pengembang mulai coding, menemukan kendala teknis, dan mengambil keputusan cepat. Arsitek sibuk dengan inisiatif lain. Dokumen yang tadinya rapi perlahan menjadi dokumen arsip yang tidak lagi mencerminkan kenyataan.
Saya pernah melihat proyek di mana tim menemukan bahwa API eksternal yang direncanakan ternyata tidak menyediakan endpoint yang dibutuhkan. Mereka mengganti pendekatan integrasi dalam seminggu. Tapi solution architecture tidak pernah diperbarui. Tiga bulan kemudian, saat tim security melakukan review, mereka membaca dokumen lama dan menyetujui arsitektur yang sudah tidak dipakai. Masalah baru muncul di production karena security control tidak dipasang di jalur yang benar. Semua orang saling menunjuk, padahal akar masalahnya sederhana: dokumen tidak dijaga tetap hidup.
Solution architecture harus diperlakukan sebagai living document. Ia hidup karena terus diperbarui seiring perubahan yang terjadi selama pengembangan. Setiap kali tim mengambil keputusan yang mengubah asumsi awal, dokumen harus mencatatnya. Bukan untuk birokrasi, tetapi agar semua pihak tetap berada di peta yang sama.
Praktik pertama yang perlu dibangun adalah review berkala. Jadwalkan review solution architecture setiap dua minggu atau setiap akhir sprint. Review ini tidak perlu panjang. Cukup tanya: apakah ada perubahan scope? Apakah ada asumsi yang terbukti salah? Apakah ada keputusan baru yang perlu dicatat? Apakah diagram masih sesuai dengan implementasi? Jika jawabannya tidak ada perubahan, cukup catat bahwa dokumen masih valid. Jika ada perubahan, perbarui bagian yang terdampak dan beri tanda di log perubahan.
Praktik kedua adalah versioning. Setiap perubahan pada solution architecture harus memiliki versi yang jelas. Ini bukan soal nomor versi yang rumit. Cukup gunakan format tanggal dan nomor revisi, misalnya “v2025.03.15-2”. Yang penting adalah setiap versi bisa dilacak: siapa yang mengubah, apa yang berubah, dan keputusan apa yang mendasari perubahan itu. Versioning juga membantu saat tim perlu kembali ke keputusan sebelumnya karena perubahan ternyata tidak berjalan baik.
Praktik ketiga adalah menentukan ownership. Siapa yang bertanggung jawab menjaga dokumen tetap hidup? Jawabannya bukan “semua orang”. Dalam praktiknya, solution architect adalah pemilik utama. Tapi arsitek tidak bisa bekerja sendiri. Ia perlu kolaborasi dari tech lead yang tahu perubahan di level kode, product manager yang tahu perubahan scope, dan operation lead yang tahu perubahan infrastruktur. Bentuklah satu atau dua orang yang secara rutin memeriksa apakah dokumen masih sesuai. Jika tim kecil, peran ini bisa dirangkap oleh tech lead.
Yang sering dilupakan adalah bahwa menjaga dokumen tetap hidup bukan hanya tugas arsitek. Engineer yang menemukan perubahan perlu melaporkannya. Product manager yang mengubah prioritas fitur perlu memberi tahu. Operation yang menambah komponen baru perlu mencatatnya. Semua pihak perlu memahami bahwa solution architecture adalah alat bersama. Jika satu pihak diam, dokumen mati, dan semua pihak akan merasakan akibatnya nanti.
Setelah dokumen hidup dan terus diperbarui, tantangan berikutnya adalah memecah solusi menjadi bagian yang bisa dikerjakan. Solution architecture yang baik tidak hanya memberi gambaran besar, tetapi juga menunjukkan potongan-potongan kerja yang bisa dieksekusi oleh tim.