Belajar Staff Engineer - Architecture Ownership

#Pendahuluan

Setelah di episode 3 kita melatih technical leadership — influence tanpa otoritas, trust, dan direction setting — pada episode ini kita menerapkannya pada artefak paling khas level staff: architecture ownership. Senior engineer berkontribusi pada desain; staff engineer memiliki arsitektur lintas tim: menjaga koherensi sistem, mengambil keputusan sulit, dan memastikan keputusan itu terdokumentasi serta dipatuhi.

Ownership di sini bukan berarti menulis semua desain sendiri. Artinya kalian bertanggung jawab atas kualitas keputusan arsitektur area tersebut — siapa pun yang membuatnya, kalian yang memastikan prosesnya sehat dan hasilnya koheren.

#Apa Artinya Memiliki Arsitektur Lintas Tim

Kepemilikan arsitektur mencakup empat tanggung jawab:

1. Koherensi — sistem-sistem tim yang berbeda menyatu sebagai satu kesatuan, bukan kumpulan pulau dengan pola acak.
2. Keputusan sulit — pertanyaan yang tidak bisa dijawab satu tim (build vs buy, konsistensi vs ketersediaan, monolit vs layanan) mendapat jawaban yang disepakati.
3. Dokumentasi hidup — ADR dan diagram arsitektur mutakhir; orang baru bisa memahami mengapa sistem seperti ini.
4. Evolusi — arsitektur dievaluasi berkala; keputusan lama boleh digantikan saat konteks berubah.

Pitfall yang harus dihindari: arsitek taman — orang yang hanya menggambar diagram indah tanpa pernah menanggung konsekuensi operasionalnya. Ownership sesungguhnya termasuk ikut on-call saat desain kalian bermasalah.

#Kerangka Menganalisa Trade-off

Inti arsitektur adalah trade-off. Empat kerangka yang paling sering berguna:

#1. Konsistensi vs Ketersediaan

Saat partisi jaringan terjadi, sistem terdistribusi harus memilih: tolak permintaan (CP) atau lanjut dengan risiko data usang (AP). Keputusannya selalu domain-specific — pembayaran cenderung CP, feed sosial cenderung AP. Yang wajib dari kalian: keputusan ini eksplisit per service, bukan implisit dari framework.

#2. Build vs Buy vs Adopt

Aturan praktis 2026: buy untuk infrastruktur non-inti (identitas, email, observability), build untuk logika bisnis yang menjadi keunggulan kalian, adopt open source saat fleksibilitas lebih penting daripada kenyamanan managed.

#3. Biaya Sekarang vs Nanti

Setiap keputusan punya "bunga" — utang teknisnya. Pertanyaan yang tepat bukan "apakah ini cepat?" melainkan "berapa bunga bulanan yang kita setujui?". Sebuah shortcut yang menghemat dua minggu tapi memperlambat semua tim 10% selama setahun adalah pinjaman mahal — hitunglah eksplisit.

#4. Reverse-Testing dengan Kegagalan

Sebelum finalisasi, uji proposal dengan pertanyaan kebalikan: "Bagaimana cara ini gagal dalam 18 bulan?" Traffic 5x? Tim baru masuk? Vendor naikkan harga 3x? Desain yang tak punya jawaban untuk skenario gagalnya sendiri belum siap diratifikasi.

#Menulis ADR yang Benar-benar Dibaca

ADR (Architecture Decision Record) adalah unit mata uang ownership kalian. Tiga aturan agar ADR hidup:

• Satu keputusan, satu ADR — dokumen gabungan "arsitektur sistem" akan busuk; keputusan atomik mudah dinilai ulang.
• Status eksplisit — Proposed, Accepted, Superseded. Saat keputusan diganti, tandai ADR lama Superseded by ADR-NNN alih-alih menghapus.
• Konsekuensi terukur — tulis apa yang menjadi sulit, sehingga evaluasi ulang punya baseline.

Contoh ADR ringkas yang sudah memakai templat episode 0:

# ADR-007: Feed aktivitas memakai model eventually consistent
 
Tanggal: 2026-08-16 · Status: Accepted · Terdampak: feed, notif, analytics
 
## Konteks
Feed membaca dari 6 sumber data. Konsistensi kuat lintas sumber
menaikkan latensi p95 dari 120 ms menjadi 480 ms pada load test.
 
## Opsi
1. Strong consistency via distributed lock — latensi tinggi, kompleks.
2. Eventual consistency + staleness budget 30 detik — latensi rendah,
   UI perlu indikator "baru saja diperbarui".
 
## Keputusan
Opsi 2. Feed adalah fitur toleransi usang; angka engagement tidak
terbukti sensitif terhadap staleness 30 detik (eksperimen A/B).
 
## Konsekuensi
Wajib: staleness monitor per sumber, alarm jika melebihi 60 detik.
Risiko diterima: urutan event bisa tertukar sesaat saat traffic spike.

#Menjalankan Architecture Review

Review arsitektur yang sehat bukan sidang penghakiman, melainkan mesin quality-control. Pola yang berhasil di banyak organisasi:

Prinsip yang menjaga review tetap produktif:

• Async dulu — komentar tertulis sebelum rapat; rapat hanya untuk ketidaksepakatan yang tersisa.
• Blokir berbasis konsekuensi — keberatan valid harus menyebut konsekuensi konkret ("ini membuat rollback butuh migrasi data"), bukan preferensi ("saya lebih suka X").
• Time-boxed — review yang berlarut-larut lebih merusak daripada keputusan suboptimal yang dievaluasi ulang nanti.

#Studi Kasus: Satu Keputusan Besar dari Nol

Mari rangkai semuanya. Situasi: tiga tim sedang membangun integrasi masing-masing dengan LLM provider berbeda, biaya inference naik tak terkendali, dan tiap tim menulis ulang retry, caching, dan guardrail yang sama.

Jalur ownership yang benar:

1. Deteksi pola lintas tim — dari review RFC rutin, kalian melihat tiga desain duplikat.
2. Framing masalah — kumpulkan angka: biaya inference per tim, waktu yang habis membangun plumbing yang sama (±6 person-minggu per tim).
3. Opsi dan reverse-testing — pusatkan lewat gateway internal vs biarkan tiap tim mandiri vs beli platform vendor. Uji ketiganya dengan skenario harga API naik 3x dan kebutuhan audit log.
4. ADR-012: gateway LLM internal — satu pintu untuk routing model, caching prompt, budget per tim, dan logging teraudit.
5. Architecture review async — tiga tim memberi masukan; satu keberatan soal single point of failure diselesaikan dengan mode degraded (fallback langsung ke provider).
6. Ratifikasi dan paved road — SDK wrapper, contoh kode, dan checklist adopsi; pilot di tim pertama sebelum rollout.

Perhatikan: kalian tidak menulis semua kodenya. Kepemilikan kalian ada pada proses dan kualitas keputusan — itulah leverage arsitektur.

#Penutup

Inti yang harus dibawa pulang:

• Architecture ownership = tanggung jawab atas koherensi, keputusan sulit, dokumentasi hidup, dan evolusi lintas tim.
• Analisa trade-off pakai kerangka: konsistensi vs ketersediaan, build/buy/adopt, bunga utang teknis, dan reverse-testing kegagalan.
• ADR atomik dengan status eksplisit dan konsekuensi terukur adalah unit mata uang kalian.
• Review arsitektur sehat: async dulu, keberatan berbasis konsekuensi, time-boxed, hasilnya tercatat sebagai ADR.

Di episode 5 selanjutnya kita akan membahas cross-team collaboration — cara menyelaraskan beberapa tim yang punya target berbeda, mengelola dependency antar tim, dan menyusun alignment plan yang membuat inisiatif lintas tim tidak berantakan. Sampai jumpa di episode 5!