Belajar Data Architect - Data Architecture Review & ADR

#Pendahuluan

Setelah di episode 23 kita merancang multi-cloud, sekarang kita membahas aspek yang membedakan arsitek senior dari sekadar orang yang "suka bikin diagram": proses dan dokumentasi. Keputusan arsitektur dibuat di tengah tekanan — tenggat, politk antar tim, dan vendor yang ramah. Tanpa proses review dan dokumentasi, keputusan yang sama akan diulang dan diperdebatkan berkali-kali.

Mengapa episode ini penting? Karena keputusan arsitektur adalah investasi jangka panjang: ia memengaruhi banyak tim selama bertahun-tahun, tapi sering dibuat dalam meeting satu jam tanpa jejak. ADR dan proses review mengubah keputusan dari "kata siapa yang terkeras" menjadi "keputusan yang bisa dijelaskan, dipertanyakan, dan diubah dengan sengaja".

#Mengapa Review Arsitektur Diperlukan

Review bukan birokrasi — ia jaring pengaman untuk keputusan yang berdampak luas. Nilainya:

Menangkap blind spot: reviewer melihat risiko yang tidak terlihat pengusul.
Menjaga konsistensi blueprint: keputusan baru dicek terhadap standar (episode 17).
Mendistribusikan pengetahuan: semua orang belajar dari tiap keputusan.
Mencegah revisi mahal: menemukan kesalahan di desain (murah) lebih baik daripada di produksi (mahal).

#Architecture Decision Record (ADR)

ADR adalah dokumen singkat yang mencatat satu keputusan arsitektur beserta konteks dan alasannya. Format yang paling dipakai adalah adaptasi dari Michael Nygard:

markdown

# ADR-014: Memilih Lakehouse (Iceberg) sebagai Platform Data Utama
 
## Status
Diterima (2026-05-20)
 
## Konteks
Organisasi menanggung dua sistem (warehouse legacy + lake untuk ML)
yang datanya tidak pernah konsisten. Biaya pemeliharaan naik 30% per tahun.
 
## Keputusan
Mengadopsi lakehouse dengan Apache Iceberg sebagai single source of truth.
Data tersimpan di object storage; engine transformasi boleh berganti.
 
## Konsekuensi
Positif: satu sumber data untuk BI dan AI; portabilitas format; biaya storage turun.
Negatif: skill baru untuk tim; tooling lakehouse masih bertumbuh;
        tata kelola akses harus dibangun dari awal.
## Alternatif yang Dipertimbangkan
- Dua sistem terpisah (status quo): mahal, tidak konsisten.
- Warehouse saja: tidak melayani data tidak terstruktur & ML.
- Data lake murni: kualitas dan query BI tidak terjaga.

Struktur inti ADR: Konteks (mengapa perlu keputusan) → Keputusan (apa yang diputuskan) → Konsekuensi (positif & negatif) → Alternatif (apa yang tidak dipilih dan kenapa).

Note

Kualitas ADR diukur dari kemampuannya menjawab pertanyaan 6 bulan kemudian: "kenapa kita pakai ini?" Jika jawabannya hanya bisa datang dari orang yang hadir di meeting, ADR-nya gagal. Tulis seolah-olah pembacanya adalah arsitek baru yang tidak ada di konteks tersebut.

#Kapan Membuat ADR

Tidak semua keputusan butuh ADR — hanya keputusan yang sulit dibalik atau berdampak luas:

Keputusan	Perlu ADR?
Pilih platform data utama	✔ Ya
Pilih antara batch vs streaming untuk pipeline baru	✔ Ya
Ganti nama satu tabel	✘ Tidak (standar penamaan sudah cukup)
Ubah definisi metrik revenue	✔ Ya (memengaruhi banyak konsumen)
Tambah satu kolom di model	✘ Tidak
Perkenalkan pola baru (misal Data Vault)	✔ Ya

Aturan praktis: kalau keputusan memengaruhi banyak tim atau sulit dibalik, tulis ADR.

#Proses Review Arsitektur

#Alur review yang sehat

100%

#Prinsip proses review

Review lebih cepat dari keputusan yang sudah terlanjur — bawa usulan ke review sebelum diimplementasikan, bukan setelah.
Review berisi, bukan seremonial — beri komentar yang menyelamatkan tim dari kesalahan, bukan sekadar "LGTM".
Waktu boxed — keputusan tidak boleh menggantung berbulan-bulan. Tetapkan deadline keputusan.
Alasan penolakan terdokumentasi — "kita sudah bahas dan menolak X karena Y" mencegah diskusi yang sama terulang.
Terintegrasi dengan code review — ADR disimpan di repo (biasanya docs/adr/) dan di-review seperti kode.

#Praktik: Menjalankan Review Arsitektur

#Step 1: Buat Template ADR di Repo

Struktur folder ADR

docs/adr/
  adr-001-lakehouse-platform.md
  adr-002-data-vault-raw-layer.md
  adr-014-semantic-layer.md
  ...

Nomor berurutan, judul deskriptif, satu keputusan per file.

#Step 2: Tetapkan Siapa yang Review

Untuk keputusan lintas domain: arsitek data + owner domain terdampak + (jika menyangkut keamanan/biaya) stakeholder terkait. Untuk keputusan kecil: cukup arsitek.

#Step 3: Gunakan Checklist Review

Checklist review arsitektur

- [ ] Konsisten dengan blueprint & prinsip (episode 2, 17)?
- [ ] Dampak ke BI/AI/API yang ada sudah dipetakan (lineage)?
- [ ] Biaya & TCO sudah dihitung (episode 14)?
- [ ] Security & compliance sudah dievaluasi (episode 10, 19)?
- [ ] Opsi alternatif dipertimbangkan dan dicatat?
- [ ] Keputusan bisa dibalik? Kalau tidak, risiko ditanggung siapa?

#Step 4: Review Berkala (Rekonsiliasi)

Setahun sekali, review ADR yang sudah dibuat: apakah keputusan masih berlaku? Ada yang perlu dideprekasi (konteks berubah) dan diganti ADR baru. Arsitektur yang hidup adalah arsitektur yang keputusannya berkala ditinjau ulang.

Tip

Mulai menulis ADR retroaktif untuk 3 keputusan besar yang sudah dibuat tim kalian dalam 6 bulan terakhir — pilih platform, pilih pipeline, pilih definisi metrik. Sekalipun sudah terlambat, proses menuliskannya akan menyingkap asumsi yang selama ini tidak diucapkan — dan itu langkah pertama review yang jujur.

#Penutup

Inti yang harus dibawa pulang:

Review arsitektur adalah jaring pengaman untuk keputusan berdampak luas.
ADR mencatat konteks, keputusan, konsekuensi, dan alternatif — satu keputusan per dokumen.
ADR ditulis untuk dibaca 6 bulan kemudian, bukan untuk formalitas.
Proses review: usulan → review → keputusan → masuk blueprint, dengan waktu boxed dan penolakan tercatat.
ADR disimpan di repo, di-review seperti kode, dan direkonsiliasi berkala.

Di episode 25 selanjutnya kita akan membahas Business & Value Architecture — bagaimana menghubungkan keputusan arsitektur dengan nilai bisnis, TCO, dan strategi organisasi. Sampai jumpa di episode 25!