Belajar Technical Product Manager - Architecture & System Thinking

#Pendahuluan

Setelah di episode 3 kita belajar menguji feasibility ide settlement T+0 lewat spike, risk register, dan feasibility memo, kini kita bekali diri dengan kemampuan yang membuat semua diskusi itu mungkin: membaca dan memahami arsitektur sistem.

Mengapa TPM wajib bisa ini? Karena hampir semua trade-off produk penting tersembunyi di arsitektur: kenapa fitur X lambat dikirim, kenapa fitur Y mahal dioperasikan, kenapa vendor Z mengunci roadmap. TPM yang tidak bisa membaca arsitektur akan selalu mendengar penjelasan tanpa bisa menantangnya. System thinking adalah bahasa ibu peran ini.

#Membaca Arsitektur Berlapis (C4)

Cara paling pragmatis memahami sistem apa pun adalah pendekatan C4: lihat dari empat tingkat zoom. Untuk TPM, dua tingkat pertama sudah sangat memadai:

• Level 1 — Context: sistem kita sebagai satu kotak, dikelilingi user dan sistem eksternal. Menjawab: siapa yang berinteraksi dengan kita?
• Level 2 — Container: aplikasi, database, queue di dalam sistem. Menjawab: apa saja bagian besarnya dan bagaimana mereka berbicara?
• Level 3-4 (component, code): wilayah utama architect dan engineer.

Beginilah container diagram NusaPay yang akan sering kita pakai:

100%

Latihan membacanya: telusuri satu transaksi QRIS dari kiri ke kanan. Request merchant masuk lewat gateway, payment service memilih channel adapter, hasilnya diterbitkan sebagai event ke event bus, settlement service mengumpulkan event untuk pencatatan ledger, lalu mengirim file ke bank partner. Sekali kalian bisa menceritakan alur ini dengan kalimat sendiri, separuh system thinking kalian sudah terbentuk.

Pertanyaan yang langsung muncul dari diagram — dan inilah jenis pertanyaan TPM:

• Kenapa settlement lewat event bus, bukan dipanggil langsung oleh payment service?
• Apa yang terjadi pada transaksi yang event-nya gagal terkirim?
• Kalau bank partner down, dana merchant di mana?

#Trade-off Klasik yang Wajib Dikenali

Arsitektur adalah seni memilih antara hal baik yang saling bertabrakan. Empat trade-off yang paling sering muncul dalam pekerjaan TPM:

#Konsistensi vs Availability

Ketika dua node database tidak bisa berkomunikasi, sistem harus memilih: menolak request (menjaga konsistensi) atau tetap menerima (menjaga availability). Di NusaPay: saldo merchant untuk limit payout — lebih baik tolak payout sesaat daripada payout melebihi saldo. Keputusan seperti ini adalah keputusan produk yang kebetulan lahir di ruang arsitektur, dan TPM harus ikut memutuskan.

#Sinkron vs Asinkron

Panggilan sinkron (request menunggu jawaban) sederhana tetapi rapuh dan lambat di rantai panjang; asinkron lewat queue cepat dan tahan gangguan tetapi sulit dilacak dan akhirnya konsisten. Aturan praktis untuk produk: operasi yang user menunggu hasilnya di layar (cek status pembayaran) cocok sinkron; operasi yang user hanya butuh tahu nanti (notifikasi, settlement) cocok asinkron.

#Build vs Buy vs Partner

Contoh NusaPay: channel QRIS dibangun sendiri (inti bisnis), KYC dibeli dari vendor (komoditas), settlement T+0 dieksplorasi via partnership bank (regulasi). Kerangka sederhananya: bangun yang membedakan Anda, beli yang komoditas, bermitra saat regulasi menjadi penghalang utama.

#Monolith vs Services

Jangan terjebak dogma. Monolith cepat dikembangkan di tim kecil dan mudah di-debug; services memberi isolasi kegagalan dan skala tim. Pertanyaan TPM yang tepat bukan "kapan pindah microservices?" melainkan "batasan mana yang membuat tim kami lambat sekarang?" — kadang jawabannya malah sebaliknya: terlalu banyak service untuk ukuran tim.

#Constraints: Batasan yang Tidak Tertulis di Diagram

Setiap arsitektur adalah produk dari constraint-nya. Saat review arsitektur, cari tahu batasan tak terlihat ini:

• Regulasi: data kartu wajib tersimpan sesuai standar PCI (episode 14); data pribadi tunduk UU PDP (episode 19).
• Legacy: ledger lama masih jadi sumber kebenaran untuk periode sebelum migrasi.
• Tim: jumlah engineer dan distribusi skill membatasi pilihan desain yang realistis.
• Vendor: kontrak processor pembayaran menentukan fitur yang bisa ditawarkan.

Constraint bukan alasan pesimisme — ia bahan baku strategi. Bet event-driven NusaPay di episode 2 lahir persis dari constraint batch harian yang membatasi produk T+0.

#Daftar Pertanyaan TPM saat Architecture Review

Bawa daftar ini ke setiap sesi review desain:

1. Masalah apa persisnya yang diselesaikan desain ini, dan bagaimana kalau kita tidak melakukannya?
2. Apa alternatif yang ditolak, dan kenapa?
3. Komponen mana yang paling berisiko gagal, dan apa dampaknya ke user?
4. Bagaimana kita tahu sistem ini sehat setelah rilis — metrik apa yang dipantau?
5. Bagaimana cara rollback jika ternyata salah?
6. Apakah desain ini membuat fitur berikutnya lebih murah atau lebih mahal?

Pertanyaan keenam adalah pertanyaan strategi yang terselubung: desain yang baik membuka pintu, desain buruk memasang gembok.

#Praktik: Architecture Brief Satu Halaman

Latihan episode ini: tulis architecture brief untuk fitur settlement T+0 opsi A (batch siang) — satu halaman berisi: diagram sederhana alur baru, dua trade-off utama yang dipilih beserta alasannya, constraint yang berlaku, dan metrik kesehatan pasca-rilis. Simpan di folder 05-quality workspace kalian; dokumen ini akan kita pakai ulang di episode 13 saat membahas SLO.

#Penutup

Inti yang harus dibawa pulang:

• Gunakan pendekatan C4: bagi TPM, kuasai level context dan container; latih dengan menceritakan alur transaksi end-to-end.
• Kenali empat trade-off klasik: konsistensi vs availability, sinkron vs async, build vs buy/partner, monolith vs services — semuanya adalah keputusan produk.
• Constraint (regulasi, legacy, tim, vendor) adalah bahan baku strategi, bukan alasan.
• Enam pertanyaan review di atas membuat kalian hadir di ruang arsitektur sebagai pemutus, bukan penonton.

Di episode 5 selanjutnya kita menerjemahkan semua pemahaman ini ke artefak harian TPM: Requirements & Spesifikasi Teknis — struktur PRD teknis, non-functional requirements yang terukur, acceptance criteria yang testable, dan jebakan-jebakan penulisan requirement yang bikin tim salah bangun. Sampai jumpa!