Belajar Solution Architect - Solution Design Process

#Pendahuluan

Setelah di episode 1 kita memahami peran dan scope seorang Solution Architect — menerjemahkan kebutuhan bisnis menjadi solusi end-to-end — kini saatnya membahas bagaimana pekerjaan itu dieksekusi. Proses adalah kerangka yang membuat hasil kalian konsisten: tanpa proses, dua proyek yang ditangani SA yang sama bisa menghasilkan kualitas desain yang berbeda jauh tergantung mood dan tekanan deadline.

Mengapa proses ini penting di dunia nyata? Karena kegagalan solusi hampir selalu bisa dilacak ke langkah proses yang dilompati: requirement tidak dikonfirmasi, alternatif tidak dibandingkan, desain tidak divalidasi, atau handoff tidak lengkap. Proses yang baik tidak menjamin sukses, tetapi membuat kegagalan terdeteksi lebih awal, saat biaya perbaikannya masih murah.

#Peta Besar: Empat Fase

Proses solution design modern dapat diringkas menjadi empat fase yang saling menyambung:

Perhatikan panah mundur dari validation ke requirement: desain yang gagal validasi harus kembali mengklarifikasi asumsinya. Dan panah putus-putus dari delivery menunjukkan bahwa pembelajaran operasional selalu mengalir balik menjadi input requirement berikutnya. Proses ini iteratif, bukan waterfall satu arah.

#Fase 1: Requirement

Di fase ini SA bekerja bersama product owner dan stakeholder untuk memetakan:

• Tujuan bisnis — apa masalahnya, apa ukuran suksesnya.
• Functional requirements — apa yang sistem harus lakukan.
• Non-functional requirements — seberapa baik ia harus melakukannya (performa, availability, security).
• Constraints — batasan budget, deadline, regulasi, dan skill tim.

Kita akan mendalami teknik requirement mapping di episode 3. Aturan emas fase ini: jangan mulai mendesain sebelum requirement terkonfirmasi tertulis — mayoritas proyek gagal bukan karena desain jelek, tetapi karena mendesain masalah yang salah.

#Fase 2: Design

Desain disusun bertingkat, dari abstrak ke konkret:

Kesalahan umum pemula: langsung melompat ke level fisik ("pakai Lambda, pakai DynamoDB") sebelum level konseptual matang. Akibatnya solusi terkunci pada vendor sejak awal dan trade-off penting tidak pernah dieksplorasi.

#Fase 3: Validation

Sebelum desain diklaim selesai, uji dengan dua cara murah:

1. Architecture review — presentasikan desain ke rekan architect/engineer senior untuk mencari lubang: skenario failure, bottleneck, celah security. Checklist review kita bahas di episode 24.
2. PoC terarah — bangun prototype kecil hanya untuk risiko paling besar (misal: apakah throughput queue cukup?). PoC yang baik punya timebox dan success criteria ketat; kita praktikkan penuh di episode 17.

#Fase 4: Delivery

Desain yang disetujui diserahkan ke tim engineering sebagai paket lengkap: SDD, diagram final, ADR, estimasi, guardrails (standar coding, pipeline, kebijakan security), dan rencana milestone. Handoff yang baik berarti tim bisa mulai bekerja tanpa harus menebak niat architect. Episode 10 membahas struktur dokumennya.

#Prinsip Desain yang Menjaga Solusi Sehat

Sepanjang empat fase itu, beberapa prinsip menjadi kompas saat mengambil keputusan:

• Loose coupling — kurangi dependensi antar-komponen via kontrak API/event yang stabil; perubahan satu bagian tidak boleh merobek bagian lain.
• Design for failure — asumsikan semua komponen bisa gagal; rancang retry, fallback, dan degradation sejak awal (dibahas tuntas di episode 15).
• Least privilege — setiap komponen hanya mendapat izin minimum yang dibutuhkan (episode 8).
• Simplicity first — pilih desain paling sederhana yang memenuhi requirement; kompleksitas adalah hutang yang ditagih tiap incident.
• Decide with data — kapasitas, biaya, dan performa diestimasi dengan angka, bukan perasaan.

Prinsip-prinsip ini bukan daftar hafalan — mereka akan muncul berulang kali dalam konteks konkret: saat memilih arsitektur (episode 4), mendesain integrasi (episode 6), atau menyiapkan DR (episode 15).

#Praktik: Kerangka Solution Design Doc

Saatnya latihan pertama. Buat file docs/sdd-template.md di folder lab kalian dengan kerangka berikut — inilah tulang punggung dokumen yang akan kita isi sepanjang series:

# Solution Design Document: [Nama Proyek]
 
## 1. Konteks & Tujuan Bisnis
Masalah, tujuan terukur, stakeholder utama.
 
## 2. Requirements
### Functional    (daftar bernomor FR-01, FR-02, ...)
### Non-functional (NFR-01: target + cara diukur)
### Constraints   (budget, deadline, regulasi, skill tim)
 
## 3. Arsitektur yang Diusulkan
Diagram konseptual -> logis -> fisik.
 
## 4. Keputusan Penting (ADR ringkas)
Keputusan | Alternatif | Alasan | Konsekuensi
 
## 5. Estimasi Biaya & Kapasitas
Asumsi traffic, breakdown bulanan, skenario pertumbuhan.
 
## 6. Risiko & Mitigasi
Risiko | Dampak | Mitigasi | Owner
 
## 7. Rencana Delivery
Milestone, PoC yang diperlukan, definisi selesai.

Isi bagian 1 dan 2 dengan studi kasus pertama kalian — misalnya "sistem tiket event yang diproyeksikan 50.000 user serentak saat penjualan dibuka". Jangan isi bagian 3-7 dulu; itulah bahan episode-episode berikutnya.

#Common Pitfalls

Beberapa jebakan klasik dalam menjalankan proses ini:

• Analysis paralysis — terus meneliti opsi tanpa pernah memutuskan. Antidot: timebox tiap fase dan sepakati "cukup baik untuk maju".
• Skipping NFR — fokus ke fitur sampai production kena masalah performa/security. Antidot: NFR wajib ada sejak template (lihat bagian 2 di atas).
• Big design up front total — mendesain semuanya detail sekali jalan lalu realita berubah. Antidot: desain detail untuk milestone terdekat, garis besar untuk sisanya.
• Dokumen yang tidak dirawat — SDD usang jadi misinformasi. Antidot: jadikan update SDD bagian dari definition of done tiap perubahan besar.

#Penutup

Inti yang harus dibawa pulang:

• Solution design mengikuti siklus requirement → design → validation → delivery, iteratif dan dengan umpan balik dari operasi.
• Desain disusun tiga level: konseptual → logis → fisik; jangan melompat langsung ke pemilihan produk.
• Validasi murah lebih dulu: architecture review dan PoC terarah sebelum investasi besar.
• Prinsip (loose coupling, design for failure, least privilege, simplicity) adalah kompas pengambilan keputusan.
• Template SDD sudah siap di lab kalian dan akan terisi sepanjang series.

Di episode 3 selanjutnya kita akan membahas requirements to solution — cara membedakan functional vs non-functional requirement, menulis NFR yang terukur, serta memetakan setiap requirement menjadi keputusan solusi lewat traceability matrix. Sampai jumpa di episode 3!