Belajar Cloud Architect - Peran, Tanggung Jawab & Level

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment, kini kita menjawab pertanyaan paling mendasar: apa sebenarnya yang dilakukan seorang cloud architect? Banyak orang membayangkan arsitek sebagai "orang yang menggambar diagram di awal proyek lalu tidak terlihat lagi". Anggapan ini sudah usang — dan justru berbahaya jika dipegang.

Cloud architect modern adalah praktik berkelanjutan. Ia tidak hanya merancang di kertas, tapi terus memvalidasi desain dengan operasional nyata: apakah latensi sesuai janji? Apakah biaya melonjak? Apakah incident terjadi di titik yang diprediksi? Episode ini memetakan peran, tanggung jawab, dan level-level karir — supaya kalian tahu persis posisi mana yang sedang kalian tuju.

#Peran: Lebih dari Sekadar Diagram

#Diagram Hanyalah Titik Awal

Dulu, arsitek menyerahkan diagram arsitektur lalu pekerjaan dianggap selesai. Hari ini diagram itu justru titik awal, bukan akhir. Setelah desain disetujui, arsitek tetap terlibat melalui tiga kegiatan:

Trade-off decisions — setiap sprint atau milestone menghadirkan pilihan baru (pakai serverless atau container? satu region atau dua?). Arsitek yang memberi keputusan, bukan sekadar opini.
Outcome measurement — desain diukur dengan SLI/SLO, cost, dan reliability. Jika realitas tidak sesuai prediksi, desain direvisi.
Operational learning — incident dan on-call adalah umpan balik terbaik. Arsitek yang menyerap pembelajaran operasional akan menghasilkan desain yang semakin matang.

#Tanggung Jawab Harian

Tanggung Jawab	Contoh Kerja Nyata
Desain arsitektur	Membuat diagram sistem, memilih service, menetapkan pola
Mengelola trade-offs	Memutuskan cost vs reliability, latency vs consistency
Menulis ADR	Mendokumentasikan keputusan dan alasannya (episode 3)
Review arsitektur	Meninjau desain tim lain di architecture review (episode 23)
Advokasi praktik baik	Well-Architected pillars, IaC, observability, security by design
Berkomunikasi dengan bisnis	Menerjemahkan kebutuhan bisnis ke keputusan teknis (episode 25)

#Level-Level Arsitek

#Solutions Architect

Berfokus pada satu solusi atau workload. Contoh: merancang arsitektur aplikasi e-commerce di AWS. Ia sangat hands-on, dekat dengan engineer, dan bertanggung jawab atas desain teknis spesifik: pilihan service, pola deployment, security di level workload. Banyak Solutions Architect bekerja untuk vendor cloud atau sebagai partner implementasi.

#Cloud Architect

Lebih luas dari satu solusi: merancang platform dan landasan cloud organisasi. Cloud Architect menentukan bagaimana banyak workload berbagi landasan yang sama — landing zone, networking, IAM, observability, FinOps. Outputnya berupa blueprint, pattern, dan policy yang dipakai banyak tim. Ini adalah level yang dibahas series ini.

#Enterprise Architect

Melihat lebih tinggi lagi: seluruh organisasi, termasuk non-cloud. Ia menjembatani strategi bisnis, aplikasi, data, dan teknologi — cloud hanyalah salah satu lapisannya. Enterprise Architect berbicara bahasa investasi dan roadmap perusahaan, dan jarang menyentuh Terraform. Level ini adalah kelanjutan natural dari Cloud Architect, bukan penggantinya.

Level arsitek dan cakupan

Solutions Architect ── fokus satu workload (hands-on)
Cloud Architect    ── fokus platform & banyak workload
Enterprise Architect ── fokus organisasi & strategi bisnis

#Karir Itu Spektrum, Bukan Tangga

Jangan membayangkan ketiganya sebagai tangga yang harus dinaiki berurutan. Banyak perusahaan memiliki arsitek di beberapa level sekaligus, dan peran bisa tumpang tindih. Yang penting adalah memahami di mana kalian bekerja: seberapa luas cakupan, seberapa besar kewenangan keputusan, dan seberapa jauh dari operasional harian.

#Keahlian Lintas-Fungsi

Arsitek duduk di persimpangan banyak fungsi. Wajib bisa berkomunikasi dengan:

Engineering — untuk keputusan teknis dan review desain.
Security — untuk threat model, compliance, dan approval.
Finance/Procurement — untuk cost projection dan negosiasi vendor.
Product/Business — untuk memetakan kebutuhan bisnis ke keputusan teknis.

Kemampuan menerjemahkan bahasa antar-grup ini adalah nilai utama arsitek. Seorang engineer yang hebat belum tentu arsitek hebat — bukan karena kurang teknis, tapi karena kurang mampu menerjemahkan trade-offs ke bahasa pemangku kepentingan yang berbeda.

Note

Ini alasan mengapa "soft skill" bukan kata kotor di dunia arsitektur. Dokumentasi ADR yang jelas, diagram yang bisa dibaca non-teknis, dan presentasi yang memetakan keputusan teknis ke business outcome adalah deliverable utama seorang arsitek — bukan pelengkap.

#Dari Cloud Engineer ke Cloud Architect

Transisi dari Cloud Engineer ke Cloud Architect bukan soal pangkat, melainkan pergeseran cara berpikir:

Dari "bagaimana membangun ini" → "kenapa kita membangun ini dengan cara ini".
Dari mengeksekusi → mendelegasikan keputusan dan membimbing.
Dari fokus satu sistem → melihat banyak sistem dan polanya.
Dari menunggu spesifikasi → menciptakan spesifikasi dari kebutuhan bisnis.

Sepanjang series ini kita akan melatih pergeseran itu. Setiap episode dimulai dari konsep, lalu berakhir dengan praktik desain — persis seperti yang dilakukan arsitek sungguhan.

#Penutup

Inti yang harus dibawa pulang:

Cloud architect adalah praktik berkelanjutan: trade-offs, outcome measurement, dan operational learning.
Solutions Architect fokus satu workload; Cloud Architect fokus platform; Enterprise Architect fokus organisasi.
Arsitek duduk lintas-fungsi: engineering, security, finance, dan bisnis.
Transisi dari engineer ke arsitek adalah pergeseran dari "bagaimana" ke "kenapa".

Di episode 2 selanjutnya kita akan membahas prinsip & framework arsitektur — AWS Well-Architected, Google Cloud Architecture Framework, dan Azure Well-Architected Framework, enam pilar umumnya, serta cara menerapkan pillars pada workload nyata. Sampai jumpa di episode 2!