Belajar Cloud Architect - Architecture Review & Governance
Tanpa review, arsitektur menyimpang diam-diam; tanpa governance, keputusan tersebar tanpa arah. Episode ini membangun mekanisme Architecture Review Board (ARB), sistem ADR yang hidup, dan governance yang menyeimbangkan kontrol dengan kecepatan tim
#Pendahuluan
Di episode 3 kalian mulai mendokumentasikan keputusan dengan ADR, dan di episode 11 menjadikan infrastruktur sebagai kode. Sekarang pertanyaannya naik level: bagaimana organisasi menjaga kualitas arsitektur seiring waktu? Tanpa mekanisme, arsitektur menyimpang diam-diam — satu tim memakai pola A, tim lain pola B, dan platform menjadi hutan.
Episode ini membangun governance arsitektur: Architecture Review Board untuk review yang terstruktur, sistem ADR yang hidup (bukan arsip), dan governance yang tidak mencekik kecepatan tim.
#Architecture Review Board (ARB)
#Apa Itu ARB
ARB adalah forum rutin yang meninjau desain arsitektur penting sebelum diimplementasi. Anggotanya: arsitek senior, lead engineer, perwakilan security dan operations. Tujuannya bukan "mengizinkan atau menolak" dengan birokrasi — melainkan mendeteksi masalah lebih awal dan berbagi pembelajaran.
#Kapan Review Diperlukan
Tidak semua perubahan butuh ARB — itu akan melumpuhkan tim. Tetapkan ambang:
[ ] Menambah pola arsitektur baru (event-driven, saga, dll)
[ ] Memilih teknologi/platform baru
[ ] Mengubah batas service / domain (episode 12)
[ ] Melibatkan data baru yang sensitif
[ ] Memperkenalkan titik kegagalan baru (SPOF)
[ ] Keputusan dengan dampak lintas-timPerubahan kecil (menambah endpoint, mengubah config) tidak perlu ARB — cukup review kode biasa.
#Agenda Review yang Efektif
Review yang baik menilai keputusan, bukan dokumen:
- Konteks bisnis: masalah apa yang diselesaikan?
- Trade-offs: apa yang dikorbankan, dan kenapa (episode 3)?
- Kepatuhan: framework pillars (episode 2), security (episode 7), cost (episode 9)?
- Risiko: apa yang bisa gagal, dan bagaimana pulihnya (episode 8)?
- Output: daftar temuan + keputusan, bukan opini panjang.
Note
ARB terbaik itu singkat dan berorientasi keputusan. Target 30-45 menit per review, fokus pada temuan berisiko tinggi, dan berakhir dengan daftar aksi yang jelas. ARB yang berubah jadi "komite yang menguji dokumen" justru akan ditinggalkan tim.
#ADR: Sistem yang Hidup
#Dari Arsip ke Alur Kerja
ADR di episode 3 adalah dokumen; di episode ini ia menjadi sistem. Governance ADR yang baik punya siklus hidup:
#Prinsip Sistem ADR
- ADR di repository — di samping kode, direview seperti pull request (episode 11).
- Status eksplisit — proposed/accepted/rejected/superseded; tidak ada ADR "mengambang".
- Superseded, bukan dihapus — keputusan lama tetap tersimpan sebagai jejak sejarah.
- Katalog terindeks — daftar semua ADR dengan ringkasan, mudah dicari.
- ADR wajib untuk keputusan signifikan — jika tidak ada ADR, keputusan itu tidak terdokumentasi.
#Contoh Siklus
ADR-001 "Managed Database" (episode 3) — diterima dan diimplementasi. Setahun kemudian organisasi butuh kontrol penuh → ADR-014 "Self-managed PostgreSQL" ditulis, men-supersede ADR-001, dengan konteks kenapa keputusan berubah. Sejarah keputusan tetap lengkap — inilah nilai asli sistem ADR.
#Governance yang Tidak Mencekik
#Kontrol vs Kecepatan
Governance yang terlalu ketat membuat tim menghindarinya; yang terlalu longgar membuat platform berantakan. Kunci: kontrol di titik yang memberi nilai, kebebasan di sisanya.
| Lapisan | Kontrol Ketat | Kebebasan |
|---|---|---|
| Infrastructure platform | Ya — landing zone, IaC, policy (episode 11) | — |
| Aplikasi tim | — | Ya — framework, library, struktur |
| Keputusan berdampak lintas-tim | Ya — ARB | — |
| Keputusan lokal tim | — | Ya — tim bertanggung jawab |
#Enforcement via Kode, Bukan Rapat
Governance paling efektif ditegakkan lewat kode, bukan rapat (tema episode 11):
- Policy-as-code — aturan kepatuhan dijalankan otomatis di pipeline.
- Template & blueprints — start yang benar lebih mudah daripada yang salah.
- Guardrails — kontrol yang tidak bisa dilewati (deny policy, episode 18).
- Dashboards — visibilitas kepatuhan, bukan "laporan yang diminta".
#Misal dalam Praktik
Tim ingin memakai service baru. Alih-alih rapat panjang, pipeline menjalankan policy: apakah service ini masuk daftar yang diizinkan? Apakah konfigurasinya memenuhi standar? Keputusan cepat, objektif, dan konsisten — inilah governance modern.
#Praktik: Review Arsitektur Workload
Kerangka menjalankan review + governance:
- Tetapkan kriteria wajib ARB yang jelas (pola baru, teknologi, data sensitif).
- Bangun alur ADR: draft → review → status → superseded; di repository.
- Enforce via kode: policy-as-code, blueprint, guardrail, dashboard.
- Jadwalkan review berkala workload existing — bukan hanya yang baru (episode 2).
- Ukur kesehatan: berapa ADR diimplementasi, berapa temuan ARB terbuka.
#Penutup
Inti yang harus dibawa pulang:
- ARB meninjau keputusan penting, bukan semua perubahan; review 30-45 menit berorientasi keputusan.
- Sistem ADR: status eksplisit, superseded bukan dihapus, di repository.
- Governance = kontrol di platform, kebebasan di aplikasi tim.
- Enforce via kode (policy-as-code), bukan rapat.
- Review berkala workload existing — arsitektur yang tidak ditinjau menyimpang diam-diam.
Di episode 24 selanjutnya kita akan membahas modernization & legacy — strategi replatform/refactor, strangler pattern, dan cloud adoption framework. Sampai jumpa di episode 24!