Belajar Software Architect - Architecture Evaluation (ATAM)

#Pendahuluan

Setelah di episode 21 kalian merancang sistem AI production-grade — RAG, vector store, agent dengan guardrails — muncul pertanyaan yang jarang diajukan tepat waktu: bagaimana kita tahu semua keputusan arsitektur ini benar? Bukan benar secara teori, tapi layak terhadap requirement nyata yang akan dihadapi sistem dua tahun ke depan.

Jawaban profesionalnya bukan intuisi senior semata. Ada metode terstruktur — ATAM (Architecture Tradeoff Analysis Method) — yang sudah dipakai industri selama dua dekade, dan ada generasi penerusnya di era DevOps: fitness functions, penilaian arsitektur yang berjalan otomatis di setiap build. Episode ini menyatukan keduanya dengan satu tujuan: menemukan risiko arsitektur saat harganya masih murah — di meja review, bukan di incident bridge.

#Mengapa Arsitektur Perlu Dinilai Eksplisit

Karakter arsitektur bersifat cross-cutting: performa, keamanan, dan modularity tidak hidup di satu file yang bisa dibaca reviewer — mereka tersebar di ribuan keputusan kecil. Kesalahan arsitektur pun punya kurva biaya paling brutal: salah pilih gaya komunikasi antar service hari ini = refactor lintas tim setahun kemudian.

Evaluasi eksplisit memberi tiga nilai:

1. Menemukan risiko lebih awal — sebelum implementasi mengunci keputusan buruk.
2. Membuat trade-off sadar dan terdokumentasi — melanjutkan disiplin ADR episode 6.
3. Menyamakan pemahaman stakeholder — business tahu quality attribute mana yang dibayar dan mana yang dikorbankan.

#ATAM Secara Ringkas

ATAM penuh adalah proses multi-hari dengan evaluator eksternal. Yang dibutuhkan architect praktisi adalah inti metodenya, yang bisa dijalankan dalam setengah hari:

1. Presentasikan arsitektur   → C4 container/component (ep6)
2. Kumpulkan skenario kualitas → utility tree, prioritas stakeholder
3. Petakan keputusan → skenario → bagaimana desain menjawab tiap
   skenario prioritas tinggi?
4. Identifikasi sensitivity point → keputusan yang sangat memengaruhi
   satu atribut kualitas
5. Identifikasi tradeoff point → keputusan yang saling menekan dua
   atribut (cache: performa naik, konsistensi turun)
6. Daftarkan risks & non-risks → risiko terdokumentasi dengan rencana
   mitigasi, bukan sekadar catatan rapat

#Utility Tree: Jantung Evaluasi

Utility tree menerjemahkan "kami ingin sistem cepat dan aman" yang kabur menjadi skenario terukur:

Performance
  (H,M) Checkout p95 < 800ms pada 500 req/dtk peak flash sale
  (H,H) Asisten AI TTFT < 2 dtk pada jam sibuk merchant
Security
  (H,H) Kompromi satu pod tidak membaca data tenant lain
  (M,L) Rotasi credential tanpa downtime
Modifiability
  (H,M) Modul pricing baru rilis tanpa deploy ulang monolith penuh
Scalability
  (M,M) Tambah 1000 tenant baru tanpa perubahan arsitektur

Notasi (dampak, kesulitan) membantu fokus: skenario (H,H) dieksplorasi penuh — itulah tempat arsitektur paling mungkin retak. Perhatikan bahwa skenario kita bukan hipotetis: flash sale, noisy neighbor, dan TTFT asisten AI semuanya datang langsung dari episode 11, 20, dan 21.

#Fitness Functions: Evaluasi yang Berjalan Otomatis

ATAM adalah snapshot titik waktu; arsitektur terus bergerak setelahnya. Fitness function adalah jawaban era modern: test otomatis yang memverifikasi karakteristik arsitektur di setiap build — istilah dari Building Evolutionary Architectures (Ford, Parsons, Kua).

Contoh konkret untuk studi kasus kita — menjaga boundary modul episode 7 tetap utuh secara otomatis:

import { rule } from "dependency-cruiser";
 
// aturan: modul transaksional tidak boleh saling import
const noCrossModule = {
    name: "no-cross-module-import",
    severity: "error",
    from: { path: "^src/modules/(ordering|inventory|shipping)" },
    to: {
        path: "^src/modules/(ordering|inventory|shipping)",
        pathNot:
            "^src/modules/($1)/", // hanya boleh ke dirinya sendiri
    },
};
 
// pelanggaran boundary gagal keras di CI —
// bukan catatan code review yang bisa dilewati
export default [noCrossModule];

Pola fitness function yang layak diadopsi:

Tabel itu sebenarnya audit jejak series ini: setiap episode sudah meninggalkan satu fitness function. Itu bukan kebetulan — arsitektur yang baik selalu bisa dinyatakan sebagai aturan yang dapat diverifikasi.

#Ritme Architecture Review

Selain otomasi, manusia tetap dibutuhkan untuk hal yang tak bisa diotomasi — trade-off baru, konteks bisnis berubah, drift desain. Ritme yang sehat:

• Design review per inisiatif besar — sebelum implementasi, format mini-ATAM: presentasi C4, tiga-tiga skenario prioritas, daftar risiko.
• Quarterly health review — cek drift: apakah dependency graph masih sesuai diagram? ADR mana yang superseded tapi kode belum mengikuti? Scorecard fitness function mana yang merah?
• Post-incident architecture review — insiden besar sering mengungkap sensitivity point yang terlewat; ubah temuan jadi skenario baru dan (bila bisa) fitness function.

Keputusan evaluasi juga mengikuti prinsip reversibility: review mendalam untuk keputusan one-way door (gaya arsitektur, model data inti), ringan untuk two-way door.

#Praktik: Rencana Evaluasi Studi Kasus

Mari ratifikasi program evaluasi Acme:

mini_atam:
  pemicu: inisiatif lintas modul / keputusan one-way door
  peserta: architect, tech lead modul terkait, SRE, security
  input: diagram C4 level component + utility tree update
  output: daftar risk/non-risk + sensitivity/tradeoff points,
    tiap risk punya owner dan mitigasi bertanggal
fitness_functions_ci:
  - dependency-cruiser boundary rules (tiap PR)
  - api contract diff vs OpenAPI (tiap PR)
  - perf budget checkout p95 800ms staging (nightly)
  - sbom scan fail-on high + cosign verify (tiap build)
quarterly_health_review:
  agenda: drift diagram vs realitas, status ADR hygiene,
    scorecard fitness functions, skenario baru dari insiden
  output: update utility tree + backlog arsitektur berprioritas
post_incident:
  aturan: setiap SEV1 menghasilkan minimal satu skenario baru
    atau satu fitness function baru
metrik_program:
  - jumlah risk tertutup per kuartal
  - coverage: % aturan arsitektur yang terotomasi

Perhatikan entri post_incident — aturan sederhana "setiap SEV1 menghasilkan satu skenario/fitness function baru" adalah cara sistem belajar dari kegagalannya, dan dalam setahun ke depan utility tree kalian akan didominasi skenario yang benar-benar terjadi, bukan tebakan.

#Kesalahan Umum

• Review sebagai teater slide — presentasi cantik tanpa skenario terukur; hasilnya pujian, bukan risiko yang ditemukan.
• Skenario tanpa angka — "harus cepat dan aman" tidak bisa dinilai, dilupakan, atau dijadikan fitness function.
• Fitness function yang tidak jalan di CI — aturan yang dijalankan manual akan dilanggar tepat saat deadline; otomasi adalah syarat, bukan bonus.
• Temuan tanpa owner — daftar risiko panjang tanpa penanggung jawab dan tanggal hanyalah arsip kecemasan.
• ATAM penuh untuk segala hal — proses multi-hari untuk keputusan two-way door membunuh momentum; sesuaikan kedalaman review dengan irreversibility keputusan.
• Review tanpa konteks bisnis — menilai arsitektur tanpa tahu attribute mana yang dibeli pelanggan menghasilkan optimasi di tempat yang salah.

#Penutup

Inti yang harus dibawa pulang:

• Arsitektur harus dinilai eksplisit dan lebih awal — kesalahan arsitektur termahal saat ditemukan di produksi, termurah di meja review.
• ATAM ringkas memberi kerangka: presentasi arsitektur, utility tree skenario terukur, pemetaan keputusan-skenario, identifikasi sensitivity & tradeoff points, daftar risiko dengan mitigasi.
• Fitness functions membuat evaluasi kontinu: dependency rules, contract diff, perf budget, chaos drill, security gate — aturan arsitektur yang gagal keras di CI.
• Review manusia tetap diperlukan untuk trade-off dan konteks: design review per inisiatif, quarterly health check, post-incident learning.
• Studi kasus kini punya program evaluasi lengkap: mini-ATAM berpemicu, empat fitness function di CI, dan aturan belajar-dari-insiden.

Di episode 23 selanjutnya kita naik satu tingkat abstraksi: platform & product architecture — bagaimana architect memikirkan internal platform sebagai produk, golden paths yang membuat developer jatuh cinta, dan metrik developer experience yang membuktikan nilainya. Sampai jumpa!