Belajar Software Architect - Pre-Requisites Skill & Setup Environment

#Pendahuluan

Selamat datang di series Belajar Software Architect! Series ini akan membawa kalian menguasai peran Software Architect — orang yang merancang struktur sistem software: quality attributes, trade-offs, keputusan teknis jangka panjang, dan arah evolusi produk. Total ada 28 episode yang tersusun dalam enam fase, dari architecture fundamentals, styles & patterns, quality attributes & design, microservices & cloud-native, hingga AI systems & architecture leadership.

Mengapa peran ini penting di dunia kerja? Karena keputusan arsitektur adalah keputusan paling mahal untuk diubah. Framework bisa diganti dalam sebulan; struktur sistem yang salah membutuhkan bertahun-tahun untuk diluruskan. Perusahaan membayar premium untuk orang yang bisa membuat keputusan ini dengan benar — kompensasi senior architect di AS menembus $200K+.

Episode 0 ini adalah peta jalan kalian: kita pastikan skill dasar terpenuhi, lalu menyiapkan toolkit praktik yang dipakai konsisten sepanjang series. Berbeda dari series coding murni, lab kita berupa diagram, dokumen keputusan, dan studi kasus desain.

#Skill Dasar yang Wajib Dimiliki

#Pengalaman Coding Senior (3-5 Tahun)

Arsitektur bukan karier pintasan untuk menghindari kode. Kalian wajib sudah nyaman:

• Satu bahasa secara mendalam — Go, Java, TypeScript, atau Python; cukup satu, asal sampai level idiom dan ekosistemnya.
• Desain di tingkat modul — class, package, interface, dependency injection.
• Debugging lintas batas service — membaca log terdistribusi, melacak request antar proses.
• Code review & mentoring — karena sebagian besar pekerjaan architect adalah memengaruhi kode orang lain.

Jika kalian masih junior, selesaikan dulu jalur learn-backend atau setara. Arsitektur tanpa pengalaman implementasi menghasilkan diagram indah yang tidak pernah bisa dibangun.

#Sistem Terdistribusi

Hampir semua keputusan arsitektur modern terjadi di konteks terdistribusi. Pastikan kalian paham konsep-konsep ini minimal pada level intuisi:

Tidak perlu hafal formula — yang dibutuhkan adalah kemampuan memprediksi apa yang rusak ketika dua komponen berkomunikasi lewat jaringan.

#Design Thinking

Architect bekerja dari masalah ke solusi, bukan sebaliknya. Tiga kebiasaan yang harus terlatih:

1. Menanyakan "mengapa" sebelum "bagaimana" — kenapa fitur ini ada, siapa penggunanya, apa batasannya.
2. Berhenti di abstraksi yang tepat — detail cukup untuk mengambil keputusan, tidak lebih.
3. Menerima trade-off secara eksplisit — setiap pilihan mengorbankan sesuatu; tugas architect adalah memilih apa yang dikorbankan.

#Perangkat Software yang Disiapkan

#Diagram Tool dengan Dukungan C4

Diagram adalah bahasa utama architect. Untuk series ini siapkan salah satu:

• Excalidraw (gratis, cepat) — untuk sketch informal saat diskusi.
• draw.io / diagrams.net (gratis) — diagram formal dengan shape library lengkap.
• Structurizr DSL + Lite (open-source) — diagram sebagai kode; inilah yang kita pakai di episode 6.

Install Structurizr Lite via Docker agar bisa langsung mencoba:

mkdir -p ~/arch-lab/structurizr && cd ~/arch-lab/structurizr
curl -o docker-compose.yml https://raw.githubusercontent.com/structurizr/lite/master/docs/docker-compose.yaml
docker compose up -d
# buka http://localhost:8080

#Workspace ADR (Architecture Decision Records)

ADR adalah catatan tertulis atas setiap keputusan arsitektur penting — topik besar episode 6. Buat strukturnya sekarang:

~/arch-lab/
├── structurizr/          # diagram C4 as code
├── adr/
│   ├── template.md       # templat ADR standar tim
│   └── 0001-record-architecture-decisions.md
├── fitness/              # fitness functions & script pengecekan
└── case-studies/         # studi kasus desain per episode

Isi template.md dengan format dasar:

# N. Judul Keputusan
 
## Status
Proposed | Accepted | Superseded oleh ADR-XXX
 
## Konteks
Apa masalahnya? Apa kekuatan & kendala yang memengaruhi keputusan?
 
## Keputusan
Apa yang kita putuskan?
 
## Konsekuensi
Apa yang menjadi lebih mudah, apa yang menjadi lebih sulit?

#Reference Repos untuk Dipelajari

Arsitektur terbaik dipelajari dari contoh nyata. Clone beberapa repo open-source yang arsitekturnya matang:

cd ~/arch-lab && mkdir reference && cd reference
git clone --depth 1 https://github.com/vercel/next.js.git
git clone --depth 1 https://github.com/elastic/logstash.git
git clone --depth 1 https://github.com/sourcegraph/sourcegraph.git

Perhatikan cara mereka membagi module/package, mendokumentasikan keputusan (docs/, ADR), dan menjaga boundary antara domain.

#Perangkat Hardware

Kabar baik: pekerjaan arsitektur ringan untuk hardware. Laptop dengan RAM 8 GB sudah cukup untuk Structurizr, editor, dan container Docker sesekali. Yang benar-benar dibutuhkan adalah layar besar (diagram butuh ruang pandang) dan akses cloud free tier untuk episode cloud-native — AWS/GCP/GCP free tier atau akun trial Vercel/Fly.io sudah memadai.

#Verifikasi Environment

Sebelum lanjut, pastikan semua siap:

docker compose version          # untuk Structurizr Lite
ls ~/arch-lab/adr/template.md   # templat ADR ada
git -C ~/arch-lab init          # workspace jadi repo (opsional tapi disarankan)

#Ringkasan Prasyarat

Rangkuman yang sudah kalian siapkan di episode 0:

• Skill: coding senior di satu bahasa, intuisi sistem terdistribusi, design thinking.
• Tool: Excalidraw/draw.io untuk sketch, Structurizr Lite untuk diagram as code.
• Dokumen: workspace ~/arch-lab dengan folder adr/, fitness/, dan case-studies/.
• Referensi: minimal satu repo open-source besar untuk dibedahi strukturnya.

Jika ada yang belum terpenuhi, lengkapi dulu sebelum lanjut. Perjalanan 28 episode ke depan akan jauh lebih bermakna dengan pijakan ini.

#Penutup

Inti yang harus dibawa pulang:

• Architect dibangun di atas pengalaman coding, bukan penggantinya — minimal 3-5 tahun.
• Sistem terdistribusi adalah konteks wajib: network unreliable, latency, idempotency.
• Toolkit architect: diagram tool C4, workspace ADR, dan reference repos.
• Semua artefak arsitektur hidup di git agar punya riwayat.

Di episode 1 selanjutnya kita akan membahas peran & level software architect — apa yang sebenarnya dikerjakan architect sehari-hari, jenis-jenis architect (application, solution, enterprise, platform), posisinya di organisasi, dan bagaimana konteks 2026 dengan AI serta platform engineering mengubah peran tersebut. Pastikan environment kalian sudah siap, karena perjalanan Belajar Software Architect baru saja dimulai!