8.7 Architecture Decision Record sebagai Pengikat Alasan
Kepala teknologi perusahaan logistik itu akhirnya memutuskan prioritas pertama: membangun data warehouse. Alasannya masuk akal. Tanpa data warehouse, dashboard real-time tidak bisa berfungsi. Tanpa dashboard, operasional tidak bisa diukur. Tanpa pengukuran, sulit membangun argumen untuk mengganti sistem warisan.
Tiga bulan kemudian, ia dipanggil direksi. “Kenapa kita mulai dari data warehouse?” tanya direktur operasional. “Saya pikir prioritas pertama adalah mengganti sistem warisan yang sering ngadat.” Kepala teknologi itu menjelaskan alasannya. Direktur operasional mengangguk, tapi rapat terasa canggung. Seandainya ia punya catatan keputusan yang bisa diperlihatkan, ia tidak perlu menjelaskan dari awal.
Inilah yang disebut architecture decision record, atau ADR. ADR adalah dokumen singkat yang mencatat keputusan arsitektur, alasan di baliknya, dan opsi yang dipertimbangkan. Bukan dokumen seratus halaman. Cukup satu atau dua halaman per keputusan. Fungsinya sederhana: mengikat alasan agar tidak hilang seiring waktu.
Setiap ADR biasanya berisi beberapa hal. Konteks: situasi saat keputusan diambil. Opsi yang dipertimbangkan: apa saja alternatif yang dievaluasi. Keputusan: pilihan yang diambil. Alasan: kenapa pilihan itu dipilih. Dan konsekuensi: apa yang terjadi setelah keputusan dijalankan. Tidak perlu format baku. Yang penting konsisten dan bisa ditemukan kembali.
Berikut adalah template ADR sederhana yang bisa langsung kamu gunakan:
# ADR-001: [Judul Keputusan]
## Konteks
[Situasi atau masalah yang mendorong keputusan ini]
## Opsi yang Dipertimbangkan
- Opsi A: [deskripsi singkat]
- Opsi B: [deskripsi singkat]
- Opsi C: [deskripsi singkat]
## Keputusan
[Pilihan yang diambil, misal: Opsi A]
## Alasan
[Argumen utama mengapa opsi tersebut dipilih, misal: biaya lebih rendah, skalabilitas lebih baik]
## Konsekuensi
[Dampak positif dan negatif setelah keputusan dijalankan]
Simpan setiap ADR sebagai file Markdown terpisah di repositori agar mudah ditemukan dan direview.
Berikut adalah diagram alur yang merangkum struktur ADR dan perannya dalam roadmap arsitektur:
Setiap ADR menjadi simpul yang mengikat alasan di balik setiap langkah roadmap, sehingga keputusan tidak hilang ditelan waktu.
Mengapa ADR penting untuk roadmap? Pertama, roadmap arsitektur bukan dokumen statis. Ia akan berubah seiring berjalannya waktu. Enam bulan lagi, mungkin ada teknologi baru, perubahan regulasi, atau prioritas bisnis yang bergeser. Tanpa ADR, tim akan bertanya: “Kenapa dulu kita memutuskan membangun data warehouse dulu?” Dan tidak ada yang ingat. Kedua, ADR membantu review. Ketika arsitek baru bergabung atau konsultan datang, mereka bisa membaca ADR dan memahami logika di balik roadmap tanpa perlu wawancara satu per satu.
Ketiga, ADR mencegah keputusan berulang. Dalam organisasi besar, sering terjadi tim yang berbeda mengambil keputusan serupa tanpa tahu bahwa keputusan sudah pernah diambil. Dengan ADR yang terdokumentasi, tim bisa mencari decision log dan melihat apa yang sudah diputuskan. Ini menghemat waktu dan tenaga.
Keempat, ADR menjadi alat komunikasi. Kepala teknologi bisa menunjukkan ADR ke direksi saat ditanya kenapa prioritas tertentu dipilih. Bukan untuk membela diri, tapi untuk menunjukkan bahwa keputusan diambil dengan pertimbangan yang jelas. Direksi tidak perlu menjadi ahli arsitektur. Mereka hanya perlu melihat bahwa ada proses berpikir yang rapi.
Di era AI, ADR menjadi semakin relevan. AI bisa membantu menulis draft ADR berdasarkan notulen rapat. AI bisa mencari ADR lama ketika ada keputusan baru yang mirip. AI bahkan bisa menyarankan opsi yang belum dipertimbangkan berdasarkan ADR dari organisasi lain. Tapi inti ADR tetap manusia: kejujuran mencatat alasan, termasuk alasan yang ternyata salah. Karena keputusan yang salah pun berharga jika dicatat dengan baik.
Kepala teknologi itu mulai membuat ADR untuk setiap keputusan besar di roadmap-nya. ADR pertama: mengapa data warehouse menjadi prioritas. ADR kedua: mengapa memilih platform cloud tertentu. ADR ketiga: mengapa tiga sistem warisan tidak diganti sekaligus. Ia menyimpan semua ADR di repositori yang bisa diakses tim dan direksi. Kini, ketika ditanya, ia tidak perlu menjelaskan panjang lebar. Ia cukup berkata: “Silakan lihat ADR nomor satu.”
Setelah ADR menjadi kebiasaan, roadmap arsitektur tidak lagi sekadar daftar inisiatif. Ia menjadi kumpulan keputusan yang tercatat rapi, siap direview, siap diubah, dan siap dijelaskan. Kepala teknologi itu tidak lagi khawatir lupa alasan. Yang ia khawatirkan sekarang adalah bagaimana menghubungkan semua keputusan ini ke solusi nyata yang akan dibangun tim. Dan itu membawanya ke pertanyaan berikutnya: bagaimana roadmap arsitektur menjadi jembatan antara arah strategis dan eksekusi solusi.
