Belajar Software Architect - Platform & Product Architecture

#Pendahuluan

Setelah di episode 22 kalian membangun program evaluasi arsitektur — mini-ATAM dan fitness functions yang gagal keras di CI — pada episode ini kita menghadapi konsekuensi pertumbuhan studi kasus kita: dengan ekstraksi payment/shipping (ep12-15), AI platform (ep21), dan puluhan service baru, tim Acme kini mengerjakan sistem yang terlalu luas untuk dikoordinasikan lewat kebiasaan lama.

Setiap tim mulai menyalin pipeline CI milik tim lain (versi sedikit beda), setiap service logging dengan formatnya sendiri, dan onboarding engineer baru butuh tiga minggu. Gejalanya satu: platform dibangun berulang-ulang secara tidak sadar. Jawaban architect modern adalah menjadikannya sadar — merancang platform internal sebagai produk, dengan pengguna, roadmap, dan metrik adopsi.

#Dari Proyek ke Produk Internal

Platform thinking dimulai dari pergeseran cara pandang:

Tim platform yang sehat bertindak seperti product team: interview "pelanggan" (engineer produk), ukur kepuasan, iterasi. Perbedaannya dengan produk komersial hanya di satu hal — penggunanya adalah rekan kerja yang bisa (dan akan) menghindari platform jika nilainya tidak jelas.

#Golden Paths: Jalan Pintas yang Direkomendasikan

Golden path (istilah Spotify) adalah jalur bawaan yang sudah menggabungkan semua keputusan arsitektur yang telah kita ratifikasi sepanjang series ini — dalam bentuk yang tinggal dipakai:

acmectl new service --name loyalty \
    --template typescript-modular \
    --owner team-growth
 
# yang otomatis didapat developer:
# - repo + struktur modul sesuai boundary rules (ep7)
# - CI: lint, test, SBOM scan, cosign sign (ep19)
# - deploy manifest + admission policy compliant (ep18)
# - observability: trace, metrics, log standar (dimensi tenant ep20)
# - entry di service catalog dengan owner terdaftar

Satu perintah itu adalah kristalisasi dua puluh episode keputusan. Inilah cara architect skala pengaruhnya: tidak lewat review manual tiap service, tapi lewat jalan berpaving yang lebih mudah daripada jalur liar.

Prinsip desain golden path:

1. Fast path default, escape hatch tersedia — deviasi tetap mungkin, tapi dengan review eksplisit; bukan tembok.
2. Path mencerminkan ADR aktif — saat ADR berubah, template berubah; path tidak boleh menyimpang dari keputusan tertulis.
3. Versioned & communicated — perubahan template diumumkan seperti rilis produk, bukan diam-diam.

#Komponen Internal Developer Platform

Platform matang tersusun dari beberapa blok — kalian sudah mengenal semuanya dari series ini:

Service Catalog   : siapa own apa, status fitness function,
                    dependensi antar service (ep7, ep22)
Scaffolding       : golden path templates per jenis service
Self-Service Infra: provision env/database/queue tanpa tiket,
                    guardrails via policy as code (ep18)
Observability     : golden signals seragam, dashboard per service,
                    dimensi tenant wajib (ep20)
Scorecards        : skor kesehatan service (security posture,
                    reliability SLO, cost efficiency) per tim
Docs Portal       : ADR terindeks (ep6), runbook, diagram C4

Keputusan build vs buy untuk lapisan ini: service catalog & portal nyaris selalu dimulai dari solusi open-source (Backstage adalah standar de facto) dikustomisasi — membangun dari nol jarang bernilai. Yang benar-benar proprietary dan bernilai adalah templates dan policies kalian: itulah pengetahuan arsitektur Acme dalam bentuk kode.

#Mengukur Developer Experience

Platform tanpa metrik akan kehilangan funding di rapat anggaran pertama. Ukuran yang membuktikan nilai:

DORA metrics (lead time, deployment frequency, change failure rate, MTTR) adalah bahasa bersama yang dipahami eksekutif — gunakan sebagai kerangka, tambahkan metrik spesifik platform seperti time-to-first-deploy dan adopsi.

#Praktik: Charter Platform Studi Kasus

Mari ratifikasi platform charter Acme — dokumen pendiri yang menjaga tim platform tetap pada misinya:

misi: >
  Memangkas jarak antara commit dan produksi menjadi hitungan
  jam, dengan security/compliance/reliability built-in,
  tanpa tim produk harus menjadi ahli infrastruktur.
pelanggan: 14 tim produk, 60+ engineer
produk_v1:
  catalog: backstage + ownership metadata wajib
  scaffolding: 2 golden path (ts-modular, go-worker)
    - boundary rules & CI gates baked-in (ep7, ep19)
  self_service: provision postgres schema + topic kafka
    via policy-guarded API, SLA provisi 5 menit
  scorecard: security posture, SLO compliance, cost per req
non_goals:
  - mengelola runtime aplikasi (tetap milik tim produk)
  - gate deploy manual (self-service, policy otomatis)
metrik_sukses:
  - time-to-first-deploy 5 hari (dari 3 minggu)
  - adopsi golden path 80% dalam 2 kuartal
  - lead time turun 40% tahunan
prinsip:
  - nilai dulu baru mandat; escape hatch selalu ada
  - platform sendiri punya SLO & on-call
  - roadmap dari interview engineer, bukan hipotesis atasan

Perhatikan bagian non_goals — batasan apa yang TIDAK dikerjakan platform sama pentingnya dengan daftar fiturnya. Tim platform yang mencoba mengelola runtime aplikasi orang lain akan berubah menjadi bottleneck yang dikucilkan; yang memberi self-service dengan guardrails menjadi multiplier.

#Kesalahan Umum

• Platform by mandate tanpa DX — memaksa adopsi dengan kebijakan sementara jalurnya lebih lambat daripada cara lama; hasilnya shadow platform dan permusuhan.
• Membangun Backstage-killer — berbulan-bulan membangun portal custom sebelum satu golden path jadi; tooling beli/kopi, templates bangun sendiri.
• Roadmap dari atas — membangun fitur platform yang keren bagi manajemen tapi tak menjawab pain point engineer; adopsi mandek.
• Platform tanpa SLO sendiri — registry/catalog down dua hari dan tak ada yang bertanggung jawab; platform adalah produk, produk punya SLA.
• Mengukur output bukan outcome — melapor jumlah fitur platform alih-alih lead time dan adopsi; funding pun hilang.
• Golden path yang membeku — template tidak pernah di-update setelah ADR berubah; path perlahan menjadi legacy yang menyesatkan.

#Penutup

Inti yang harus dibawa pulang:

• Platform internal adalah produk: punya pelanggan (engineer), roadmap dari pain point, dan sukses diukur dari adopsi serta dampak — bukan jumlah fitur.
• Golden paths mengemas keputusan arsitektur (boundary, CI gates, observability) menjadi satu perintah scaffold — cara architect menskalakan pengaruh tanpa review manual.
• IDP tersusun dari service catalog, scaffolding, self-service infra dengan policy guardrails, scorecard, dan docs — beli lapisan umumnya, bangun templates & policies kalian.
• Metrik DX (time-to-first-deploy, DORA, adopsi, cognitive load survey) adalah bahasa untuk membela investasi platform di hadapan bisnis.
• Studi kasus kini punya platform charter lengkap — termasuk non-goals yang menjaga tim platform fokus sebagai enabler, bukan gatekeeper.

Di episode 24 selanjutnya kita menghadapi realitas yang pasti datang: sistem yang ada harus berubah. Evolution & migration architecture — pola strangler fig, expand-contract untuk data, anti-corruption layer, dan cara menyusun migration plan yang punya rollback di setiap langkah. Sampai jumpa!