Enam Bulan Mencoba Adopsi Architecture Decision Record

Rendy B. Junior
Jan 11 · 5 min read

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

Konsep ADR sangat sederhana. Setiap keputusan desain arsitektur (Architecture Decision) ditulis (Record-ed). Ide ini muncul dari metodologi Agile. Salah satu prinsip dalam Agile, kita tidak membuat dokumentasi yang tidak akan bisa kita jaga dan selalu perbaharui (kalau ga kuat maintain dokumentasi, jangan ditulis).

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

Proposal Ide

Saat muncul ide desain, usulan, atau saran perbaikan, yang punya ide akan membuat sebuah dokumen ADR dengan status Not Started, artinya belum mulai didiskusikan. Formatnya sederhana, ada 1) sedikit intro atau latar belakang masalah apa yang ingin dipecahkan, dan 2) proposal solusi beserta alternatif. Kami tulis dokumennya di wiki perusahaan yang bisa dilihat dan dikomentar secara online oleh siapapun di perusahaan.

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

Setiap hari Senin kami meluangkan waktu 1.5 jam (placeholder, kadang lebih kadang kurang) untuk membahas dokumen ADR yang masih dalam status Not Started. Biasanya ada beberapa ADR dibuat dalam satu minggu. ADR-ADR tersebut diantrikan untuk dibahas satu per satu.

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

Kata seseorang (saya lupa siapa) the only thing that is constant in life is change. Namun ADR dengan status Decided tidak boleh diubah atau diperbarui kembali. Alasannya karena keputusan tersebut telah didiskusikan sebelumnya, mengubahnya perlu diskusi lebih lanjut. Apalah artinya keputusan yang sudah tertulis kalau bisa seenaknya diubah.

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 adanya proses yang jelas bagaimana keputusan desain diambil, pengambilan keputusan menjadi cenderung lebih cepat. Hal yang tidak saya sangka mengingat diskusi kami hanya satu minggu sekali (kadang lebih sih, saat ada yang urgent perlu dibahas). Sebelumnya, pengambilan keputusan desain yang konseptual bisa memakan waktu banyak, menghabiskan banyak meeting dengan stakeholder yang berbeda-beda.

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

Sebelumnya, saat seseorang terpikirkan sebuah ide, ide biasa diutarakan di chat room saat rekan yang lain sedang fokus kerja. Biasanya karena rekannya sedang sibuk kerja, rekannya kurang merespon. Hal ini sederhana sebenarnya, karena rekannya merasa ini bukan waktunya merespon dan mempertimbangkan desain itu perlu waktu khusus untuk fokus. Karena kurang direspon, teman-teman tim jadi malas untuk mengutarakan ide.

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

Saat kita mendesain sesuatu, kita akan mendesain berdasarkan informasi yang kita miliki saat itu, konstrain dan situasi pada saat itu. Di masa depan, biasanya kita mempertanyakan kembali, kenapa waktu itu saya memutuskannya desainnya seperti ini ya?

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

Saat rekan kerja di luar tim bertanya, “Kenapa desain kalian seperti ini?”, kami bisa dengan mudah menjelaskannya karena semuanya tertulis dengan baik dan jelas. Rekan di luar tim pun bisa memberikan masukan dengan memberikan komentar di ADR-nya sehingga kami bisa perbaiki lagi desainnya.

Keputusan “Kecil” Tidak Masuk ADR

ADR cocok untuk mendiskusikan konsep desain yang berdampak pada banyak hal. Keputusan-keputusan yang sederhana biasanya diputuskan dalam diskusi informal sudah cukup. Hal ini karena ADR sendiri cukup mahal dalam prosesnya. Perlu membuat proposal, dan diskusinya satu minggu sekali. Tidak ada batasan yang nyata, lebih ke personal judgement saja.

Untuk Melihat State Saat Ini, Perlu Memproses Sejarah ADR

ADR muncul sebagai kritik pada dokumentasi desain konvensional. Maksudnya bagaimana? Dokumentasi desain di proyek waterfall itu biasanya tebalnya bukan main, dan sangat tidak update. Mengapa tidak update? Alaasannya sederhana, terlalu banyak untuk terus diupdate.

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

Baru saja departemen kami mendapatkan anggota tim baru dan ia senang sekali untuk bisa tahu sejarah semua desain arsitektur di dalam satu tempat. Ketika ada anggota baru, biasanya mereka mempertanyakan desain yang sebenarnya sudah ada pertimbangan di belakangnya. Dengan ADR, semuanya jelas tertulis sehingga diskusi bisa lebih efektif untuk membahas yang belum pernah dibahas sebelumnya.

Masih Belajar

Kadang ada beberapa keputusan penting yang kami lupa lewati dalam proses ADR. Kadang apa yang didokumentasikan kurang jelas. Kadang diskusinya terlalu bias. Namun sejauh ini kami melihat banyak manfaat yang berharga untuk dibagikan.

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. :)