Belajar Solution Architect - Peran & Scope
Mengupas apa yang benar-benar dikerjakan seorang Solution Architect sehari-hari, posisinya dibanding Software Architect dan Enterprise Architect, di fase mana saja ia terlibat dalam lifecycle proyek, serta bagaimana peran ini berubah di 2026 saat solusi AI/cloud/hybrid menjadi mainstream
#Pendahuluan
Setelah di episode 0 kita menyiapkan environment — diagram tool, akun cloud sandbox, dan workspace dokumentasi — pada episode ini kita memahami apa sebenarnya pekerjaan seorang Solution Architect. Pertanyaan ini penting karena peran "architect" sering dipakai longgar di industri: ada yang menganggapnya senior developer yang tidak lagi koding, ada yang mengira dia orang yang hanya membuat PowerPoint. Keduanya salah, dan memahami scope peran yang benar akan menentukan cara kalian belajar di 26 episode ke depan.
Mengapa ini penting di dunia nyata? Karena ekspektasi terhadap SA sangat luas: bisnis ingin solusi cepat jadi, engineering ingin desain yang bisa dieksekusi, dan operasi ingin sistem yang mudah dirawat. SA adalah titik temu ketiganya — dan tanpa peta peran yang jelas, kalian akan tersesat di antara tuntutan-tuntutan itu.
#Definisi Inti Peran
Pekerjaan inti seorang Solution Architect adalah menerjemahkan kebutuhan bisnis menjadi solusi teknis lengkap: arsitektur, komponen, integrasi, estimasi biaya, rencana delivery — semuanya dalam bentuk yang bisa dieksekusi tim engineering dan dipertanggungjawabkan ke bisnis.
Perhatikan kata "lengkap". Developer merancang implementasi sebuah fitur; SA merancang keseluruhan solusi — aplikasi, data, infrastruktur, security, integrasi dengan sistem lain, sampai strategi migrasi. Output khasnya:
| Artefak | Fungsi |
|---|---|
| Solution Design Document (SDD) | Sumber kebenaran desain: konteks, komponen, keputusan |
| Diagram arsitektur | Komunikasi visual konsep (C4, sequence, deployment) |
| Architecture Decision Record (ADR) | Catatan keputusan penting beserta alternatif dan alasannya |
| Estimasi biaya & kapasitas | Validasi bahwa solusi masuk budget dan target performa |
| Rencana PoC/migrasi | Jembatan dari desain ke eksekusi |
Kita akan mempraktikkan semua artefak ini sepanjang series; SDD lengkap kita tulis di episode 10.
#Posisi di Antara Peran Architect Lain
Industri mengenal beberapa varian architect, dan batasnya sering kabur. Tabel ini merangkum pemetaan umum:
| Peran | Fokus | Horizon Waktu | Contoh Output |
|---|---|---|---|
| Enterprise Architect | Portofolio seluruh organisasi, standar & governance | 3-10 tahun | Technology roadmap, enterprise standards |
| Solution Architect | Satu solusi/program end-to-end | Proyek (6-24 bulan) | SDD, diagram solusi, estimasi biaya |
| Software/Technical Architect | Desain internal satu aplikasi/sistem | Sprint-bulan | Class/module design, API contract detail |
| Infrastructure/Cloud Architect | Platform dan infrastruktur | Tahunan | Landing zone, network design, IaC standards |
Analoginya seperti membangun gedung: Enterprise Architect menentukan tata kota, Solution Architect mendesain satu gedung secara menyeluruh (struktur, utilitas, biaya, izin), dan Software Architect merancang detail interior satu lantai. SA berdiri di tengah: cukup teknis untuk bicara detail dengan engineer, cukup strategis untuk membaca arah bisnis.
Note
Di banyak perusahaan peran-peran ini bertumpuk dalam satu orang, terutama di startup. Yang penting bukan gelarnya, tetapi cakupan tanggung jawabnya: jika kalian diminta memastikan satu solusi berjalan end-to-end sesuai kebutuhan bisnis — kalian sedang bekerja sebagai Solution Architect.
#Di Fase Mana SA Terlibat
Berbeda dengan mitos "architect muncul di awal lalu hilang", SA yang baik terlibat sepanjang lifecycle:
Tanggung jawab di tiap fase berbeda:
- Discovery — menggali requirement bersama product owner dan stakeholder, membedakan kebutuhan nyata vs permintaan solusi ("kalian mau database Oracle" ≠ kebutuhan; "data harus konsisten lintas region" = kebutuhan).
- Design — menyusun opsi arsitektur, melakukan trade-off analysis, menghitung estimasi biaya, dan mendokumentasikan keputusan.
- Validate — menguji desain lewat architecture review dan Proof of Concept untuk risiko terbesar, sebelum investasi besar dilakukan.
- Delivery — handoff ke tim engineering dengan guardrails yang jelas: standar kode, pipeline, kebijakan security, definisi done.
- Operate — mendampingi evaluasi apakah solusi berjalan sesuai target non-fungsional, dan merencanakan evolusinya.
Fase 2-4 adalah fokus utama series ini; fase Operate kita sentuh lewat lensa resilience dan performance di Fase 3.
#Konteks 2026: AI, Cloud, Hybrid
Peran ini terus bergeser. Beberapa perubahan yang paling terasa di 2026:
- Solusi AI-first menjadi default brief. Banyak permintaan klien kini dimulai dari "bagaimana kalau pakai LLM?" — dan SA-lah yang harus menerjemahkannya menjadi RAG pipeline, agent workflow, atau fitur ML biasa yang lebih tepat. Episode 21 membahasnya tuntas.
- Cloud-native dan hybrid berdampingan. Perusahaan besar tidak lagi pindah total ke cloud; solusi baru harus hidup damai dengan data center lama. Maka desain hybrid dan migrasi jadi kompetensi wajib (episode 12).
- Kolaborasi erat dengan product & engineering. SA modern bukan penulis dokumen di menara gading; dia ikut sprint planning, review pull request arsitektur, dan validasi asumsi lewat data. Semakin dekat SA ke tim, semakin tinggi kualitas eksekusinya.
- Cost efficiency jadi bahasa harian. Pasca-boom belanja cloud, setiap proposal solusi hampir selalu ditanya "berapa biaya bulanan per 1000 user?". Kita siapkan jawabannya di episode 9.
#Anti-Pattern Peran: Yang Harus Dihindari
Dua anti-pattern klasik yang membuat SA gagal memberi nilai:
- Armchair architect — membuat desain tanpa menyentuh realitas: tidak tahu stack tim, tidak pernah deploy, tidak peduli debt yang sudah ada. Desainnya indah di kertas, mustahil di eksekusi.
- Ivory tower architect — mendoktrin standar tanpa menjelaskan trade-off, lalu menyalahkan tim saat implementasi gagal. Keputusan arsitektur tanpa adopsi sama saja dengan tidak ada keputusan.
Penawarnya konsisten: SA yang efektif tetap dekat dengan kode dan deployment, menjelaskan "mengapa", dan mengukur dampak desainnya. Prinsip-prinsip kerja ini akan kita praktikkan lewat format latihan di tiap episode.
#Penutup
Inti yang harus dibawa pulang:
- Solution Architect menerjemahkan kebutuhan bisnis menjadi solusi teknis end-to-end: aplikasi, data, infrastruktur, security, biaya, dan rencana delivery.
- Beda dengan Enterprise Architect (portofolio organisasi) dan Software Architect (satu aplikasi): SA memegang satu solusi secara utuh.
- SA terlibat dari discovery sampai operate — bukan sekadar penggambar diagram di fase awal.
- Di 2026, ekspektasi baru: solusi AI/cloud/hybrid, kolaborasi ketat dengan product-engineering, dan cost awareness sebagai bahasa default.
Di episode 2 selanjutnya kita akan membahas solution design process — alur kerja requirement → design → validation → delivery, prinsip-prinsip desain yang membuat solusi bertahan, serta struktur Solution Design Document pertama kalian. Sampai jumpa di episode 2!