Belajar Solution Architect - Solution Architecture Review

#Pendahuluan

Setelah di episode 23 kalian bisa merancang solusi edge/IoT yang tahan internet mati dan mengelola armada perangkat bertahun-tahun, sekarang kita bahas mekanisme penjamin mutu arsitektur itu sendiri: solution architecture review. Semua kompetensi yang kalian bangun — requirement, trade-off, security, cost, resilience — bermuara ke satu momen berulang di mana kualitasnya diuji terbuka: saat desain direview.

Mengapa review layak episode sendiri? Karena review yang buruk punya dua mode gagal: rubber stamp (setuju semua, tidak ada nilai) atau sidang penghakiman (architect saling menjatuhkan, tim jadi defensif dan menyembunyikan masalah). Review yang baik adalah alat kualitas paling murah di industri perangkat lunak — satu jam tinjauan mencegah bulan-bulan rework.

#Kapan Review Dilakukan

Review bukan acara sekali di akhir. Tiga titik wajib dalam lifecycle:

1. Design review — sebelum development besar dimulai; objeknya SDD + diagram + ADR (episode 10). Ini yang paling bernilai: perubahan masih murah.
2. Operational readiness review — sebelum go-live; objeknya runbook, monitoring, DR drill, load test result (episode 15-16). Pertanyaannya bergeser: "apakah siap dioperasikan?"
3. Periodic/fitness review — berkala untuk sistem hidup; objeknya drift antara desain awal dan realitas. Arsitektur merayap — review berkala adalah cara mendeteksinya.

Plus review ad-hoc saat keputusan besar akan diubah. Aturan proporsionalitas yang sehat: skala review sebanding risiko — perubahan kecil cukup diskusi async di pull request ADR; platform baru butuh panel.

#Rubrik Review Lintas Dimensi

Inti alat kerja episode ini: rubrik yang membuat evaluasi sistematis, bukan selera. Rubrik ringkas yang saya pakai:

Cara pakai yang benar: reviewer memberi skor ringkas per dimensi (misal hijau/kuning/merah) wajib disertai temuan konkret — "merah pada cost karena estimasi tak mencantumkan egress" — bukan komentar umum. Rubrik tanpa bukti hanya teater.

#Fitness Functions: Review yang Terotomasi

Bagian modern dari disiplin ini: sebagian kriteria arsitektur bisa dijadikan fitness function — tes otomatis yang mengukur kesesuaian solusi terhadap aturannya:

Latency   : p95 endpoint checkout <= 300 ms      -> diukur load test CI
Security  : zero container running as root        -> policy scan deploy
Cost      : infra spend per tenant <= Rp 100/bln  -> laporan tagging mingguan
Coupling  : no direct cross-service DB access     -> network policy audit
Resilience: chaos kill pod -> error rate pulih < 60 s -> game day script

Manfaat strategisnya besar: review manusia fokus pada hal yang benar-benar butuh judgment (trade-off, konteks bisnis), sementara aturan objektif dijaga pipeline tiap hari. Arsitektur yang merayap (drift) langsung terdeteksi oleh fitness function, jauh sebelum periodic review kuartalan.

#Menjalankan Sesi Review yang Produktif

Struktur sesi 60 menit yang terbukti bekerja:

1. Pra-read wajib (H-2) — SDD + rubrik dikirim; peserta datang dengan catatan tertulis, bukan membaca pertama kali di ruangan.
2. Presentasi singkat (15 menit) — presenter fokus pada keputusan penting + area yang ia sendiri ragukan; kejujuran tentang kelemahan menaikkan kualitas feedback drastis.
3. Traversal terstruktur (30 menit) — bahas rubrik dimensi demi dimensi; setiap temuan dicatat dengan severity (blocking / should-fix / note).
4. Keputusan keluar (10 menit) — status eksplisit: approve / approve-with-actions / revise-and-resubmit; blocking items punya owner dan tanggal.

Peran facilitator (biasanya SA senior) menjaga dua hal: semua suara keluar (engineer junior sering melihat masalah paling tajam tapi paling malu bicara), dan diskusi tetap di ranah bukti. Kalimat penyelamat saat debat selera mulai panas: "kriteria apa di requirement yang dilanggar oleh opsi ini?" — mengembalikan semuanya ke traceability matrix episode 3.

#Mengubah Temuan Menjadi Eksekusi

Review tanpa tindak lanjut adalah ritual kosong. Disiplin pasca-review:

1. Temuan tercatat sebagai issue resmi — masuk backlog dengan label severity; blocking items menghalangi milestone berikutnya.
2. Keputusan besar lahir sebagai ADR baru — kalau review mengubah pendekatan (misal: "single-region tak memenuhi RTO"), tulis ADR pengganti, jangan patch SDD diam-diam (episode 4 dan 10).
3. Re-review terfokus — hanya bagian yang direvisi; jangan ulangi seluruh sesi untuk perubahan sempit.
4. Umpan balik ke rubrik — temuan yang berulang lintas proyek berarti perlu jadi checklist standar/golden path (episode 19); review adalah sensor kualitas organisasi, bukan hanya proyek.

Satu metrik dewasa untuk tim architect: berapa persen blocking findings yang terselesaikan sebelum deadline-nya. Angka rendah berarti review kalian teater — temuan dicatat lalu dikubur.

#Common Pitfalls Reviewer

• Bias teknologi favorit — menilai desain dari apakah memakai stack kesukaan reviewer; antidot: rubrik + pertanyaan requirement-fit.
• Hitchhiking opinions — peserta ikut-ikutan kritik tanpa membaca pra-read; antidot: catatan tertulis wajib sebelum sesi.
• Bikeshedding — jam habis untuk nama variabel, keputusan arsitektur lewat 5 menit; antidot: timebox per dimensi di agenda.
• Review tanpa konteks constraint — menuntut standar unicorn pada proyek MVP budget kecil; antidot: baca constraints SDD lebih dulu (episode 3).
• Approve dengan syarat samar — "perlu dipertimbangkan lagi scalability-nya"; antidot: setiap temuan harus konkret, terukur, dan ber-owner.

#Penutup

Inti yang harus dibawa pulang:

• Review terjadi di tiga gerbang: design (paling murah), operational readiness, dan periodic — plus ad-hoc saat keputusan besar berubah.
• Rubrik 8 dimensi dengan bukti wajib mengubah review dari selera menjadi evaluasi sistematis; traceability matrix tetap jadi jangkar.
• Fitness functions mengotomasi kriteria objektif sehingga manusia fokus pada judgment; drift arsitektur terdeteksi harian.
• Sesi produktif = pra-read + traversal terstruktur + status keluar eksplisit dengan owner dan tanggal.
• Temuan harus dieksekusi (issue, ADR baru, re-review terfokus) dan pola berulang ditingkatkan menjadi golden path organisasi.

Di episode 25 selanjutnya kita akan membahas pre-sales & advisory — peran SA di sisi komersial: mendampingi sales, menjawab RFP/R FI dengan proposal teknis yang menang, discovery klien, demo solution, effort estimation, sampai etika menjanjikan apa yang bisa dieksekusi. Sampai jumpa di episode 25!