Belajar Principal Engineer - Architecture Governance

#Pendahuluan

Setelah di episode 4 kalian menulis strategy doc — keputusan lintas domain dengan kill switch eksplisit — muncul pertanyaan lanjutan yang menentukan apakah strategy itu benar-benar bekerja: bagaimana memastikan ratusan keputusan harian di puluhan tim tetap selaras, tanpa kalian hadir di semua rapat?

Jawabannya adalah architecture governance. Kata ini punya reputasi buruk karena versinya sering berupa gerbang birokrasi yang membenci developer. Governance yang baik justru sebaliknya: ia membuat keputusan benar menjadi jalur termudah. Di episode ini kita merancangnya dari nol.

#Mengapa Org Butuh Governance

Tanpa governance, org mengalami pola yang bisa diprediksi:

Fragmentasi senyap — setiap tim memilih teknologi "terbaik untuk konteks kami"; dua tahun kemudian org punya tujuh message queue dan tidak ada yang ahli penuh di salah satunya.
Keputusan besar diam-diam — integrasi vendor mahal dibeli tanpa review; ketahuan saat kontrak sudah tanda tangan.
Standar hantu — standar tertulis ada di wiki tapi tidak ada yang tahu ia masih berlaku atau tidak.

Governance menjawab semuanya dengan satu mekanisme: titik temu keputusan yang ringan, cepat, dan terdokumentasi.

#Architecture Review Board (ARB)

ARB adalah forum inti governance. Desain yang terbukti bekerja:

Aspek	Rekomendasi	Alasan
Anggota	4-6 orang: principal (pimpinan), 2-3 staff engineer rotasi, security/platform rep	Kecil = keputusan cepat
Ritme	Mingguan, maksimal 60 menit	Forum bulanan menciptakan antrean panjang
Input	RFC maksimal 6 halaman + demo bila perlu	Dokumen panjang tidak dibaca
Output	Accept / Accept with conditions / Reject with guidance	Selalu ada jalur maju
SLA keputusan	5 hari kerja	Review lambat = tim melewati proses

Aturan emas ARB: keputusan ditulis. Setiap sesi menghasilkan catatan singkat — apa yang diputuskan, kondisinya, dan alasannya — masuk ke log keputusan org. Keputusan yang tidak tertulis akan diadukan ulang tiga bulan lagi.

#Tier Review Berbasis Risiko

Bukan semua desain layak lewat ARB. Tier berdasarkan ledakan dampak jika salah:

Tier review arsitektur

TIER 1 - ARB wajib
└── Sistem baru lintas tim, data sensitif, vendor &gt; ambang budget,
    perubahan pada sistem identitas/pembayaran
 
TIER 2 - Review async oleh principal/staff domain
└── Service baru dalam satu domain, skema data lintas tim
 
TIER 3 - Otonomi penuh tim
└── Perubahan internal service, tooling lokal tim

Prinsipnya sama dengan spektrum kontrol di episode 4: semakin lintas batas, semakin tinggi tier-nya.

#Paved Roads: Standar yang Disukai

Standar paling efektif bukan larangan melainkan jalan beraspal (Netflix menyebutnya paved road): tooling dan template resmi yang membuat cara standar juga cara termudah.

Contoh nyata paved road:

Template service baru: observability, health check, dan security scanning sudah terpasang.
Pipeline deploy bawaan platform yang lebih cepat daripada DIY.
Library internal auth yang satu baris pemanggilannya.

Ketika paved road bagus, 90% tim memilihnya tanpa diperintah — dan ARB hanya menangani sisa 10% deviasi yang sadar akan pilihannya.

Important

Ukur kesuksesan paved road dengan adopsi, bukan kelengkapan fitur. Jika kurang dari 70% service baru memakainya, masalahnya ada di pengalaman pengguna paved road-nya — bukan di kepatuhan tim.

#Charter Governance

Rancang governance secara eksplisit agar tidak bergeser menjadi birokrasi. Simpan charter ini di wiki org:

decisions/governance-charter.md

# Architecture Governance Charter
 
## Tujuan
Keputusan teknis org saling kohesif, cepat, dan terdokumentasi -
bukan menghambat delivery.
 
## Mekanisme
1. ARB mingguan (60 menit) - tier 1 decisions, SLA 5 hari kerja.
2. Review async tier 2 - respon maksimal 2x24 jam kerja.
3. Log keputusan publik: semua outcome tertulis, dicari, terhubung RFC.
 
## Prinsip Operasi
- Deviasi selalu boleh DENGAN biaya yang dinyatakan - tidak ada larangan buta.
- Standar kedaluwarsa dievaluasi tiap semester; default-nya pencabutan.
- Semua anggota ARB rotasi tiap 2 kuartal agar pengetahuan menyebar.
 
## Eskalasi
Tim yang keberatan: ajukan revisi standar lewat RFC - bukan bypass.

Perhatikan prinsip default pencabutan: standar harus membenarkan dirinya sendiri setiap semester. Ini mencegah akumulasi aturan zombie yang membuat governance dibenci.

#Anti-Pattern Governance

Empat kegagalan klasik yang harus kalian hindari:

Anti-Pattern	Gejala	Koreksi
Gerbang polisi	Tim menyembunyikan keputusan dari ARB	Turunkan friksi: tier ringan, SLA tegas
Teater slide	Review penuh estetika, minim substansi	Wajibkan RFC tertulis + demo
Standar abadi	Wiki penuh dokumen 2019 tak tersentuh	Review semesteran, default revoke
Veto tunggal	Satu orang memblokir semua	Keputusan kolektif, dissent direkam

Gejala paling penting untuk dipantau adalah yang pertama: tim mulai menyembunyikan keputusan. Itu sinyal pasti bahwa friksi governance sudah melebihi nilainya.

Warning

Jika kalian mendapati tim melakukan fait accompli — deploy dulu, kabari belakangan — jangan balas dengan mengencangkan aturan. Balas dengan menanyakan titik friksi mana yang membuat mereka memilih diam; biasanya jawabannya adalah durasi review, bukan substansinya.

#Praktik: Rancang Governance Org Kalian

Petakan keputusan tiga bulan terakhir di org kalian — kelompokkan ke tier 1/2/3.
Tulis charter dengan templat di atas; sepakati SLA dengan lead tim sebelum forum pertama.
Jalankan ARB perdana dengan agenda maksimal dua RFC — uji durasinya.
Mulai log keputusan publik sejak keputusan pertama; transparansi adalah legitimasi.

#Penutup

Inti yang harus dibawa pulang:

Governance yang baik membuat keputusan benar menjadi jalur termudah, bukan gerbang birokrasi.
ARB sehat: kecil (4-6 orang), mingguan, SLA 5 hari, output selalu tertulis di log keputusan.
Tier review berbasis dampak ledakan; mayoritas keputusan seharusnya tidak pernah sentuh ARB.
Paved roads adalah bentuk standar paling kuat — ukur dengan tingkat adopsi, bukan fitur.

Di episode 6 selanjutnya kita membahas leading complex initiatives — cara memimpin inisiatif 0→1 berskala organisasi seperti migrasi platform dan program AI: framing masalah, memastikan sponsorship, blueprint eksekusi bertahap, dan cara mendaratkan inisiatif sampai benar-benar selesai. Sampai jumpa di episode 6!