Enam Bulan Mencoba Adopsi Architecture Decision Record

Awal semester dua 2018, saya dan tim memulai sebuah proyek internal yang memulai sesuatu dari nol. Memulai dari awal artinya ada banyak hal yang perlu diriset, didesain, dan diputuskan. Hal tersebut juga berarti banyak diskusi tentang alternatif solusi apa yang terbaik.

Beruntung di awal proyek kami menemukan sebuah alat yang tepat untuk tantangan tersebut, yaitu Architecture Decision Record (ADR).

Apa itu ADR dan Bagaimana Adopsinya

Detail dari konsep sederhana ini terasa sekali manfaatnya. Dalam mengadopsi konsep ADR, berikut yang kami lakukan.

Proposal Ide

Saya merasakan manfaat yang luar biasa karena teman-teman tim jadi terbiasa untuk selalu menuangkan ide secara terstruktur untuk didiskusikan lebih lanjut. Alternatif solusi juga ditulis besarta kelebihan dan kekurangannya sehingga mengurangi bias konfirmasi akan keputusan yang diambil.

Saya tahu kebiasaan ini sudah menjadi kultur tim saat saya mendengar rekan mengutarakan ide lalu temannya berkata, “Ide bagus tuh, di-ADR-in aja biar kita bisa diskusikan”. ADR sudah menjadi kata kerja.

Diskusi Desain

Secara bergantian, anggota tim yang membuat ADR akan menjelaskan kembali proposal ide yang telah ditulisnya serta kelebihan dan kekurangannya. Dalam diskusi ini pertimbangan setiap alternatif diperdalam, karena setiap orang biasanya punya sudut pandang yang berbeda-beda. Contohnya debat pragmatis vs idealis, haruskah kita kejar fungsionalitas atau desain yang baik untuk kebaikan jangka panjang?

Dengan komposisi tim yang beragam, biasanya keputusan menjadi semakin matang dan berimbang. Sangat penting untuk membiarkan anggota tim yang lebih jarang berbicara untuk mengutamakan pendapatnya.

Setelah kami cukup puas dengan trade off-nya, kami ubah ADR sesuai kesepakatan dan ketok palu bahwa ADR ini berubah status menjadi Decided. Bila masih ada yang perlu diriset, kami ubah menjadi statusnya menjadi In Progress untuk dibahas kembali di diskusi desain minggu berikutnya.

Saat Desain Harus Berubah

Lalu bagaimana bila sebuah desain memang perlu berubah?

ADR baru bisa dibuat untuk memperbarui ADR lama. Kalau UUD istilahnya amandemen, hehe. Isinya menjelaskan bagian mana dari ADR lama yang perlu diperbaiki atau diubah, bisa saja seluruhnya. Baik di ADR baru ataupun di ADR lama, dibuat tautan ke semua ADR terkait sehingga runutan sejarahnya jelas.

Biasanya di ADR lama, di judulnya kami beri tanda bahwa ada ADR baru yang mengubahnya (misal kami beri judulnya dengan prefiks DEPRECATED). Tidak ada cara baku, ini cara kami supaya mudah dibaca saja.

Apa yang Kami Pelajari setelah Enam Bulan Mengadopsi

Keputusan Desain Lebih Cepat Diambil

Dengan jelasnya proses, pengambilan keputusan jadi lebih cepat. Misalnya kami bisa menganalisis siapa saja yang perlu diajak untuk ikut memutuskan dan menambahkannya pada diskusi desain mingguan.

Semakin Banyak Ide Desain yang Diutarakan Anggota Tim

Dengan adanya ADR, wadahnya jelas, kapan mesti merespon juga jelas. Saya melihat ide semakin banyak diutarakan teman-teman tanpa beban khawatir tidak direspon atau tenggelam di chat room.

Retrospeksi Menjadi Lebih Mudah — Continuous Improvement

ADR merekam semuanya sehingga retrospeksi desain lebih mudah. Artinya continuous improvement. Ketika tidak direkam, bisa jadi kita terjebak di keputusan yang berputar-putar tanpa menuju ke arah yang lebih baik.

Alat Komunikasi Antar-Tim

Keputusan “Kecil” Tidak Masuk ADR

Untuk Melihat State Saat Ini, Perlu Memproses Sejarah ADR

ADR menjadi solusi karena yang ditulis bukan state terakhir, tapi setiap perubahan desain yang dilakukan. Kekurangannya, bila kita hendak melihat arsitektur keseluruhan saat ini, kita perlu memperoses ADR dulu dari awal hingga akhir.

Hal ini menurut saya malah bagus karena biasanya kita perlu memperlihatkan state terakhir untuk keperluan tertentu saja, misalnya presentasi ke VP. Sehingga saya bisa pilih bagian spesifik mana yang akan saya presentasikan, perlu sedetail apa, dan seterusnya. Pengalaman saya untuk membuat dokumentasi itu kita perlu memikirkan audience, dan sulit untuk membuat dokumentasi yang tailored for everyone (or impossible?).

Mudah Ketika ada Rekan Tim Baru untuk Memahami Semuanya

Masih Belajar

Perlu diperhatikan, bahwa ADR adalah sebuah alat yang perlu disesuaikan dengan karakter tim dan organisasi. ADR cocok bagi kami namun belum tentu cocok dengan karakter organisasi yang berbeda. Prakteknya pun tidak harus sama, selama prinsipnya tetap didapatkan.

Saya menggunakan ADR untuk software architecture, design, dan development. Saya rasa prinsip yang sama juga bisa diaplikasikan di bidang lain.

Semoga bermanfaat. :)

Crazy dad. Data technology enthusiast. Youtube: Insinyur Data

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store