Belajar Software Architect - Architecture Fundamentals

#Pendahuluan

Setelah di episode 1 kita memahami peran & level architect — keputusan, analisis berkelanjutan, keselarasan bisnis, dan mentoring — pada episode ini kita membangun fondasi cara berpikir yang dipakai setiap hari: apa itu arsitektur, apa itu quality attributes, dan mengapa semua keputusan arsitektur pada dasarnya adalah trade-off.

Episode ini adalah episode paling konseptual di seluruh series. Jangan dilewati: setiap materi berikutnya — styles, patterns, microservices, cloud-native — hanyalah penerapan dari tiga konsep yang kita pelajari di sini. Architect yang gagal biasanya bukan karena tidak tahu teknologinya, melainkan karena tidak punya kerangka untuk memutuskan.

#Apa Itu Arsitektur

Definisi kerja terbaik datang lagi dari Richards & Ford:

Arsitektur adalah struktur-struktur penting dari sistem software, beserta keputusan-keputusan yang sulit diubah.

Dua kata kuncinya: penting (significant) dan mahal diubah (costly to change). Konsekuensinya menarik — arsitektur bersifat relatif terhadap konteks:

Perhatikan bahwa pilih framework versi X biasanya bukan arsitektur (mudah diganti), tetapi terikat pada satu vendor queue tertentu adalah arsitektur (mahal diubah). Uji "mahal diubah" ini adalah alat penyaring pertama saat kalian menimbang apakah suatu hal layak diperlakukan sebagai keputusan formal.

#Quality Attributes: Kompas Keputusan

Jika semua keputusan arsitektur adalah trade-off, kita butuh alat untuk menyatakan apa yang dikorbankan. Alat itu adalah quality attributes — karakteristik kualitas sistem di luar fungsionalitas:

• Performance — seberapa cepat sistem merespons.
• Scalability — seberapa mampu sistem menangani beban bertambah.
• Availability/Reliability — seberapa sering sistem bisa diandalkan.
• Security — seberapa tahan sistem terhadap ancaman.
• Maintainability/Testability/Deployability — seberapa mudah sistem dimodifikasi oleh manusia.

Fungsionalitas menjawab "apa yang sistem lakukan"; quality attributes menjawab "seberapa baik ia melakukannya". Dan hampir semua diskusi arsitektur terjadi di wilayah kedua.

#Hukum Trade-off

Inilah aksioma nomor satu arsitektur, dirumuskan Richards & Ford:

Everything in software architecture is a trade-off. ("First Law of Software Architecture")

Contoh konkret yang akan kita temui berkali-kali:

Konsistensi kuat (ACID)      ↔  throughput & latensi rendah
Microservices                ↔  kompleksitas operasional
Cache agresif                ↔  risiko data basi
Abstraksi fleksibel          ↔  biaya pemahaman awal
Replikasi lintas region      ↔  konsistensi akhir (eventual)

Konsekuensi penting dari hukum ini: tidak ada arsitektur "benar" atau "salah" secara absolut — hanya ada arsitektur yang lebih atau kurang cocok untuk quality attributes yang dituntut konteksnya. Saat wawancara atau review desain, jawaban "tergantung" memang benar, tetapi hanya bernilai jika kalian lanjut dengan "...tergantung atribut mana yang kalian prioritaskan; jika X maka A, jika Y maka B".

#Architectural Thinking

Bagaimana bentuk konkret cara berpikir ini dalam pekerjaan harian? Empat kebiasaan:

#1. Berpikir dalam Struktur dan Interaksi

Setiap sistem punya dua dimensi: komponen (modul, service, data store) dan interaksi (sinkron HTTP, async event, shared file). Bug arsitektural hampir selalu lahir dari interaksi, bukan dari isi komponen. Latih diri melihat garis penghubung, bukan kotaknya saja.

#2. Mengidentifikasi Bagian yang Mahal Diubah

Saat mendesain, tanyakan untuk setiap elemen: jika dua tahun lagi keputusan ini salah, berapa biaya koreksinya? Yang mahal — pilihan database utama, protokol antar service, model kepemilikan data — layak diberi waktu berpikir ekstra dan didokumentasikan sebagai ADR.

#3. Menerjemahkan Kebutuhan Bisnis ke Quality Attributes

Stakeholder jarang berkata "kita butuh availability 99,95%". Mereka berkata "checkout tidak boleh mati saat flash sale". Tugas architect menerjemahkan kalimat bisnis menjadi target terukur — inilah jembatan yang membuat arsitektur selaras dengan bisnis.

#4. Menunda Detail Tanpa Menunda Keputusan

Architect efektif tahu kapan berhenti: cukup detail untuk mengambil keputusan dan mengomunikasikannya, tidak sampai desain class-level yang seharusnya milik tim implementasi.

#Praktik: Memetakan Quality Attributes Studi Kasus E-commerce

Mari praktikkan. Studi kasus yang akan kita pakai berulang di series ini: toko online mid-size — 500 ribu pengguna aktif bulanan, flash sale mingguan pukul 20.00, checkout via payment gateway pihak ketiga.

Langkah pertama: daftar kebutuhan bisnis → quality attributes:

"Checkout tidak boleh mati saat flash sale"
   → Availability tinggi + graceful degradation
"Halaman produk harus terasa instan"
   → Performance: latency p99 di bawah 300 ms untuk read path
"Pengguna tumbuh 2x tiap tahun"
   → Scalability horizontal tanpa redesign besar
"Data pembayaran harus akurat, tak boleh dobel"
   → Consistency kuat di domain payment
"Tim product rilis fitur tiap minggu"
   → Deployability & maintainability tinggi

Langkah kedua: urutkan. Semua penting, tetapi arsitektur lahir dari prioritas. Untuk kasus ini:

priorities:
  - rank: 1
    attribute: availability
    target: "99.9% untuk jalur checkout; degradasi terukur untuk sisanya"
  - rank: 2
    attribute: performance
    target: "p99 read path di bawah 300 ms; p99 checkout di bawah 800 ms"
  - rank: 3
    attribute: consistency
    target: "kuat pada payment & inventory checkout; eventual di luar itu"
  - rank: 4
    attribute: scalability
    target: "menahan 10x traffic flash sale dengan autoscaling"
  - rank: 5
    attribute: deployability
    target: "deploy harian tanpa downtime"

Catat pola yang muncul: availability dan consistency saling berebut (hukum trade-off!). Checkout saat traffic puncak memaksa kita memilih: tolak order ketika inventory ragu (memilih consistency), atau proses dengan saga dan kompensasi (memilih availability). Belum ada jawaban benar di episode ini — yang penting pertanyaannya sudah eksplisit dan terdokumentasi.

#Kesalahan Umum Pemula

• Mengoptimalkan attribute yang tidak dituntut. Membangun multi-region untuk aplikasi internal 50 pengguna adalah pemborosan yang nyata.
• Memperlakukan semua attribute setara. Tanpa prioritas, setiap diskusi desain jadi perang selera.
• Mengira performance = scalability. Sistem bisa cepat untuk 100 user dan kolaps di 10 ribu; keduanya attribute berbeda dengan tactics berbeda.
• Lupa bahwa maintainability juga attribute. Sistem yang cepat tapi mustahil diubah oleh tim adalah sistem yang gagal lambat.

#Penutup

Inti yang harus dibawa pulang:

• Arsitektur = struktur penting + keputusan yang mahal diubah; uji "mahal diubah" adalah penyaring pertama.
• Quality attributes adalah bahasa untuk menyatakan kebutuhan non-fungsional: performance, scalability, availability, security, maintainability.
• Semua adalah trade-off — tidak ada arsitektur benar absolut, hanya yang cocok dengan prioritas attribute konteksnya.
• Architectural thinking: lihat struktur & interaksi, identifikasi yang mahal diubah, terjemahkan bisnis ke attribute terukur, dan tahu kapan berhenti di detail.
• Kalian sudah memetakan quality attributes studi kasus e-commerce sebagai artefak pertama di workspace kalian.

Di episode 3 selanjutnya kita membahas architectural styles — layered, microservices, event-driven, dan modular monolith: karakteristik masing-masing, trade-off yang mereka bawa, dan bagaimana memilih style untuk studi kasus e-commerce yang quality map-nya baru saja kita tulis. Sampai jumpa di episode 3!