Belajar Software Architect - Peran & Level | Belajar Software Architect

#Pendahuluan

Setelah di episode 0 kalian menyiapkan skill dasar dan toolkit — Structurizr, workspace ADR, dan reference repos — pada episode ini kita jawab pertanyaan paling mendasar: apa sebenarnya pekerjaan seorang software architect?

Pertanyaan ini penting karena peran ini salah dipahami secara luas. Bayangan populer: orang senior yang duduk di ruang terpisah, mengeluarkan diagram UML tebal, lalu tim "mengeksekusi". Realitas di industri modern justru hampir kebalikannya. Memahami perbedaan ini sejak awal akan menentukan apakah kalian tumbuh menjadi architect yang efektif atau menjadi bottleneck berjuluk gelar.

#Apa yang Sebenarnya Dikerjakan Architect

Richards & Ford dalam Fundamentals of Software Architecture merumuskan empat pilar pekerjaan architect. Ini kerangka yang akan kita pakai sepanjang series:

Pilar	Arti Praktis
Make architecture decisions	Memutuskan pendekatan teknis, bukan detail implementasi
Continually analyze the technology	Mengaudit lingkungan teknologi, menjaga tetap relevan
Keep alignment with business goals	Setiap keputusan terhubung ke tujuan bisnis, bukan selera pribadi
Coach and mentor engineers	Menumbuhkan kemampuan arsitektur di dalam tim

Perhatikan kata kuncinya: decisions, bukan diagrams. Diagram hanyalah artefak komunikasi dari keputusan yang sudah matang. Architect yang produktif menghabiskan hari mereka di tiga arena: rapat desain, review kode/PR strategis, dan penulisan dokumen keputusan (ADR).

Important

Prinsip emas dari Richards & Ford: architect harus tetap "hands-on" secukupnya — cukup dekat dengan kode untuk memvalidasi bahwa keputusannya bisa dieksekusi. Architect yang tidak menyentuh kode lagi dalam enam bulan cepat atau lambat mengambil keputusan yang tidak realistis.

#Jenis-Jenis Architect

Gelar "architect" mencakup beberapa peran yang sangat berbeda:

#Application Architect

Bertanggung jawab pada satu aplikasi/service: struktur modul, pilihan framework, pola desain internal. Posisi paling dekat dengan kode; biasanya evolusi alami dari senior developer.

#Solution Architect

Merancang solusi end-to-end untuk satu masalah bisnis: integrasi antar sistem, pemilihan produk vs build sendiri, estimasi biaya-risiko. Banyak bekerja dengan stakeholder non-teknis.

#Enterprise Architect

Melihat portofolio seluruh perusahaan: standar lintas divisi, governance, roadmap teknologi. Paling jauh dari kode, paling dekat dengan strategi.

#Platform Architect

Merancang platform internal yang dipakai banyak tim produk: developer experience, golden paths, self-service infrastruktur. Peran yang naik daun seiring gerakan platform engineering.

Untuk series ini fokus kita adalah application/solution level — fondasi yang sama dipakai semua jenis.

#Level Karir dan Ekspektasi

Di organisasi besar, jalurnya kira-kira seperti ini:

Jalur karier menuju architect

Senior Engineer → Staff Engineer → Architect → Principal Architect → Enterprise Architect
      │                 │              │               │
   eksekusi        desain fitur   keputusan       arah multi-tim
                                  lintas service  & portofolio

Yang berubah saat naik level bukanlah kepintaran teknis, melainkan radius keputusan dan cara kerja:

Aspek	Senior Dev	Architect
Output utama	Kode yang berjalan	Keputusan yang benar + kode saat dibutuhkan
Horizon waktu	Sprint / rilis	Tahun (evolusi sistem)
Sukses diukur dari	Fitur selesai	Sistem tetap sehat & tim bergerak cepat
Kegagalan klasik	Bug produksi	Keputusan mahal yang salah arah

Kompensasi mencerminkan radius itu: data gaji 2026 menempatkan senior architect AS di kisaran $200K+ — setara atau di atas staff engineer, karena dampak keputusannya melipatgandakan output seluruh tim.

#Konteks 2026: Peran yang Berubah

Tiga kekuatan sedang membentuk ulang pekerjaan architect:

#Kompleksitas AI

LLM kini bagian dari sistem produksi: RAG pipeline, agent orchestration, guardrail model. Architect dituntut merancang untuk ketidakpastian — output probabilistik, biaya token, latensi model. Kita bedah tuntas di episode 21.

#Cloud-Native sebagai Standar

Kubernetes, serverless, dan managed services bukan lagi pilihan eksotis. Pertanyaan architect bergeser dari "pakai cloud atau tidak" menjadi "komponen mana yang dimiliki, mana yang disewa".

#Platform Engineering

Tim produk tidak lagi mengelola infrastruktur mentah; mereka memakai platform internal. Architect semakin sering mendesain pengalaman developer — golden path, template service, self-service — bukan hanya diagram sistem.

#Kesalahan Umum Architect Baru

Sebelum lanjut, kenali jebakan-jebakan klasik:

Ivory tower — mengeluarkan standar tanpa memahami realitas eksekusi tim.
Resume-driven architecture — memilih teknology karena menarik di CV, bukan karena masalahnya.
Over-engineering — microservices untuk 3 developer; event sourcing untuk CRUD sederhana.
Keputusan tanpa dokumentasi — keputusan baik yang hilang saat orangnya resign.
Tidak pernah salah — menolak merevisi keputusan saat fakta berubah; padahal ADR pun punya status superseded.

Tip

Antidote paling ampuh untuk semua jebakan di atas adalah satu kebiasaan: tulis ADR untuk setiap keputusan penting, lengkap dengan konteks dan konsekuensinya. Dokumen memaksa kalian berpikir jernih dan membuat kalian bisa dikoreksi — dua hal yang membuat architect dipercaya.

#Penutup

Inti yang harus dibawa pulang:

Pekerjaan architect = keputusan arsitektur, analisis teknologi berkelanjutan, keselarasan dengan bisnis, dan mentoring — bukan sekadar menggambar.
Ada empat jenis utama: application, solution, enterprise, dan platform architect.
Yang berubah saat naik level adalah radius keputusan dan horizon waktu, bukan hanya kedalaman teknis.
Konteks 2026: kompleksitas AI, cloud-native standar, dan platform engineering membentuk ulang peran ini.
Hindari ivory tower dan over-engineering; tulis ADR agar keputusan bisa diaudit.

Di episode 2 selanjutnya kita masuk materi inti: architecture fundamentals — apa itu arsitektur sesuai definisi para ahli, mengapa "semuanya adalah trade-off", bagaimana quality attributes menjadi kompas keputusan, dan praktik pertama kita memetakan quality attributes untuk studi kasus nyata. Sampai jumpa di episode 2!