Belajar Solution Architect - PoC & Prototyping

#Pendahuluan

Setelah di episode 16 kalian bisa merancang performa sebagai anggaran terukur dan membuktikannya lewat load test, episode ini menjawab pertanyaan yang muncul di setiap proyek besar: bagaimana kita tahu desain ini akan bekerja sebelum menghabiskan jutaan rupiah membangunnya? Jawabannya adalah Proof of Concept — eksperimen kecil, murah, dan cepat untuk membongkar asumsi paling berisiko.

Mengapa PoC sering gagal memberi nilai? Karena dieksekusi tanpa disiplin: tanpa pertanyaan yang jelas (akhirnya membangun setengah aplikasi), tanpa criteria sukses (berakhir dengan opini), atau tanpa batas waktu (berlarut-larut jadi proyek bayangan). Pada episode ini kita bangun kerangka PoC yang ketat — kelanjutan natural dari fase validation dalam proses design episode 2.

#PoC vs Prototype vs MVP vs Spike

Empat istilah ini sering dipakai tertukar; bedakan dengan tujuan dan ukurannya:

Fokus episode ini adalah PoC — alat SA untuk validasi teknis. Aturan pemilihannya sederhana namun tegas: buat PoC hanya untuk risiko yang jika salah akan mengubah arsitektur. Kalau kegagalannya bisa ditangani dengan ganti library atau parameter config, itu bukan layak PoC — langsung saja build.

Kandidat risiko yang lazim layak PoC pada studi kasus tiket:

1. Throughput antrean + fungsi penerbitan tiket pada 5.000 event/detik.
2. Akurasi dan latensi seat-lock concurrent 50 ribu user pada Redis.
3. Perilaku failover replika database cross-region (RTO klaim episode 15).
4. Biaya riil skenario peak vs estimasi pricing calculator (episode 9).

#Menyusun Success Criteria

Jantung PoC adalah kriteria sukses yang terukur sebelum eksperimen dimulai — kalau ditulis sesudahnya, ia berubah menjadi justifikasi. Format yang saya pakai:

Pertanyaan   : Mampukah Redis cluster menahan 50 rb lock kursi serentak
               dengan latensi operasi p95 <= 20 ms?
Hipotesis    : Cluster 3 shard x 2 replika cukup pada pola akses kita.
Metrik       : p50/p95/p99 latensi lock-acquire & release;
               error rate; throughput ops/s; biaya instance per jam.
Skenario     : Ramp 0 -> 50 rb virtual user selama 10 menit,
               hold 10 menit, lalu storm release semua lock.
Lulus jika   : p95 <= 20 ms DAN error < 0.1% selama fase hold.
Gagal jika   : throttling/error >= 0.5%, ATAU butuh shard > 5
               (melampaui budget infrastruktur).
Timebox      : 5 hari kerja termasuk penulisan laporan.
Biaya        : <= Rp 2.500.000 environment sementara.

Perhatikan bahwa kriteria gagal juga eksplisit — PoC tanpa definisi kegagalan cenderung "dicoba sekali lagi" sampai entah bagaimana dianggap berhasil. Dan biaya dicantumkan: PoC adalah investasi dengan ROI berupa penghindaran risiko, harus masuk akal dibanding nilai proyek.

#Menjalankan PoC dengan Disiplin

Eksekusi PoC yang baik punya tahapan ketat:

1. Siapkan environment terisolasi — tagging biaya poc=true + auto-delete tanggal jatuh tempo (episode 9). Jangan sentuh produksi.
2. Bangun minimal — hanya jalur yang diuji. Stub sisanya. Kode PoC boleh jelek; ia akan dibuang (dan tulis itu di header file agar tak ada yang menganggapnya fondasi).
3. Ukur dengan instrumen sungguhan — metrik platform + load generator open-model (pelajaran episode 16). Screenshot dashboard adalah data, cerita bukan.
4. Dokumentasikan penyimpangan — konfigurasi yang berbeda dari rencana produksi harus dicatat, karena itulah yang akan diperdebatkan saat review.
5. Tulis temuan segera — laporan maksimal 2-3 halaman: pertanyaan, metode, hasil, kesimpulan, rekomendasi.

#Prototyping untuk Risiko Non-Teknis

Sementara PoC menjawab risiko teknis, prototipe menjawab risiko pemahaman kebutuhan — sisi lain dari requirement engineering episode 3:

• Wireframe/mockup interaktif untuk validasi alur checkout bersama user bisnis — jauh lebih murah daripada salah bangun fitur utuh.
• Wizard of Oz: proses manual yang dimainkan seolah otomatis untuk menguji apakah orang benar-benar memakai fiturnya sebelum kalian mengautomasi.
• Walking skeleton: satu request berjalan end-to-end melintasi SEMUA komponen arsitektur (gateway → service → DB → queue → consumer) dengan logika minimal. Bukan untuk user, melainkan untuk membuktikan integrasi dan pipeline deploy — sering membuka masalah infrastruktur yang tidak terlihat di diagram.

Untuk studi kasus tiket saya merekomendasikan dua eksperimen paralel di minggu-minggu awal: PoC seat-lock (risiko teknis terbesar) dan walking skeleton (risiko integrasi). Keduanya timebox satu sprint.

#Dari Hasil PoC ke Keputusan

PoC bernilai ketika hasilnya menjadi keputusan resmi, bukan obrolan koridor:

1. Analisis hasil vs criteria — lulus/gagal ditentukan oleh angka yang sudah disepakati, bukan suasana rapat.
2. Keputusan berlapis: lanjut seperti direncanakan / lanjut dengan modifikasi (misal tambah shard) / ganti pendekatan / eskalasi scope ke sponsor.
3. Rekam sebagai ADR — ADR baru merujuk laporan PoC sebagai bukti; keputusan arsitektur kini punya jejak empiris (episode 4 dan 10).
4. Bersihkan environment — hancurkan resource PoC hari itu juga; environment yatim adalah tagihan senyap klasik.

Contoh potongan ADR pasca-PoC:

Status  : Accepted
Bukti   : docs/poc/seat-lock-report.md (p95 14 ms @ 50 rb VU, error 0.02%)
Keputusan: Redis cluster mode enabled, 3 shard x 2 replika, TTL lock 10 m.
Catatan : PoC code dibuang; implementasi produksi memakai client library
          standar + circuit breaker (lihat episode 6).

Satu kalimat penting untuk stakeholder: laporan PoC juga melindungi kalian saat keputusan dipertanyakan enam bulan kemudian — jawabannya bukan "saat itu kami rasa cocok", melainkan "ini datanya".

#Common Pitfalls

• PoC tanpa charter — mulai coding dulu, mikir kriteria belakangan; hasilnya tidak bisa dipakai memutuskan apa pun.
• Timebox bocor — "dua minggu lagi pasti selesai" berkali-kali; timebox yang dilanggar kehilangan seluruh fungsinya sebagai kontrol biaya.
• Menguji hal yang sudah pasti — PoC untuk membuktikan PostgreSQL bisa insert baris buang-buang waktu; simpan amunisi untuk ketidakpastian nyata.
• Environment PoC hidup selamanya — tanpa tanggal kedaluwarsa otomatis, ia menjadi server misterius yang membayar tagihan diam-diam.
• Bias konfirmasi — tim hanya mencatat hasil yang mendukung pilihan awal. Mitigasi: minta engineer yang netral (bukan pengusul opsi tersebut) menjalankan uji.

#Penutup

Inti yang harus dibawa pulang:

• Buat PoC hanya untuk risiko yang kegagalannya mengubah arsitektur; sisanya langsung build.
• Charter PoC = pertanyaan + hipotesis + metrik + skenario + kriteria lulus dan gagal + timebox + biaya, semuanya sebelum eksperimen.
• Eksekusi terisolasi, kode dibuang, penyimpangan dicatat, laporan ringkas segera.
• Lengkapi dengan prototipe untuk risiko pemahaman kebutuhan dan walking skeleton untuk risiko integrasi.
• Nilai PoC selesai ketika ia menjadi ADR berbukti dan environment-nya dihancurkan.

Di episode 18 selanjutnya kita kembali ke security dengan lensa lebih dalam: security architecture in solution — menyusun lapisan pertahanan berlapis, zero trust untuk identitas manusia dan mesin, threat-informed design dengan MITRE ATT&CK, serta cara mendesain deteksi dan respons, bukan hanya pencegahan. Sampai jumpa di episode 18!