Belajar Solution Architect - Data-Driven Solutions

#Pendahuluan

Setelah di episode 21 kalian bisa menerjemahkan brief AI menjadi solusi RAG atau agent yang terukur dengan eval dataset, episode ini melihat ke belakang panggung: data sebagai bahan bakar keputusan. Solusi yang kita rancang selama 21 episode menghasilkan banjir event — transaksi, klik, pemindaian QR — dan pertanyaan arsitekturnya kini: bagaimana mengubah banjir itu menjadi insight yang dipakai manajemen tiap pagi dan model ML setiap hari?

Mengapa ini ranah SA? Karena platform analitik yang salah desain punya dua mode gagal klasik: terlalu lambat (laporan kemarin baru siap hari Kamis) atau terlalu mahal (tagihan warehouse melebihi biaya aplikasinya). Keduanya adalah keputusan arsitektur yang salah sejak awal, bukan masalah tooling belakangan.

#Dari Episode 7 ke Platform Analitik Utuh

Episode 7 sudah meletakkan fondasi: OLTP dipisah dari analitik via CDC, raw zone immutable di object storage, modeled zone di warehouse. Platform lengkapnya kini kita susun end-to-end:

Perhatikan bahwa semua konsumsi (BI, ML, metrics API) menarik dari satu sumber kebenaran — lakehouse. Duplikasi pipeline per konsumen adalah awal dari "kenapa angka finance beda dengan dashboard marketing?" — pertanyaan yang menandakan governance gagal.

#Batch vs Real-Time: Pilih Sesuai Nilai Keputusan

Keputusan arsitektur pertama adalah kecepatan. Prinsipnya bukan "real-time lebih keren", melainkan berapa nilai informasi yang hilang per jam keterlambatan:

Untuk studi kasus tiket: laporan penjualan harian cukup micro-batch; dashboard antrian checkout saat sale butuh near real-time; deteksi pembelian anomali/fraud layak streaming penuh. Banyak tim jatuh ke jebakan membangun semuanya streaming — biaya 5-10x untuk insight yang tak pernah butuh detik.

Teknologi streaming yang wajib kenal: Kafka/Kinesis/PubSub sebagai transport (episode 6), stream processor (Flink, Spark Structured Streaming, Kafka Streams) untuk windowing/agregasi, dan sink ke lakehouse/warehouse. Pola pentingnya exactly-once semantics pada agregasi — tanpa itu, restart processor menggandakan hitungan penjualan.

#Lakehouse dan Table Format Modern

Lapisan penyimpanan analitik modern berada di atas object storage dengan table format: Apache Iceberg (dan saudaranya Delta Lake/Hudi). Kenapa ini penting bagi SA? Karena table format memberi properti database di atas file parquet murah:

• ACID transactions — beberapa job bisa menulis tabel sama tanpa korupsi.
• Time travel & versioning — audit dan reproducibility: "tampilkan data seperti kemarin jam 9" jadi query biasa.
• Schema evolution — tambah kolom tanpa rewrite seluruh tabel.
• Engine agnostic — tabel Iceberg bisa dibaca Spark, Trino, Flink, bahkan engine warehouse provider — mencegah lock-in engine.

Arsitektur lakehouse praktis untuk mayoritas perusahaan Indonesia: object storage (murah, tak terbatas) + Iceberg + query engine sesuai workload. Warehouse managed tetap valid bila tim ingin zero-ops, tapi pahami trade-off biaya scan dan lock-in-nya (episode 4).

#Transformasi sebagai Kode

Pelajaran paling bernilai dari era data engineering modern: transformasi dikelola seperti software, bukan script lepas:

models/
├── staging/     # 1:1 dengan sumber, hanya rename/cast/clean
│   └── stg_orders.sql
├── intermediate/# logika bisnis bertingkat, reusable
│   └── int_ticket_sales_daily.sql
└── marts/       # konsumsi akhir: dashboard, metrik resmi
    └── fct_revenue_daily.sql

Aturan yang menjaga kepercayaan:

1. Satu definisi metrik — revenue didefinisikan sekali di layer marts; semua dashboard merujuk sana. Definisi ganda = dua rapat mingguan memperdebatkan angka.
2. Test data otomatis — uniqueness primary key, not null, referential integrity; test gagal = pipeline berhenti, bukan dashboard menipu diam-diam.
3. Lineage — grafik dependensi model membuat dampak perubahan sumber terlihat sebelum eksekusi.
4. Data contract dengan tim aplikasi — skema event disepakati dan di-versioning; perubahan breaking harus lewat koordinasi (lanjutan kontrak API episode 6, versi datanya).

#ML Pipeline dan Feature Store

Ketika analitik naik kelas menjadi prediktif, dua komponen baru masuk arsitektur:

#Feature Store

Fitur (misal: frekuensi pembelian user 30 hari terakhir) sering dihitung ulang oleh tiga tim dengan tiga definisi berbeda — inilah sumber bug training-serving skew: model dilatih dengan angka X, produksi menyajikan Y. Feature store menyelesaikan dengan satu definisi fitur, dua serving mode: offline batch untuk training, online low-latency untuk inference.

#Siklus MLOps Minimal

Data (lakehouse) -> Feature store -> Training -> Evaluasi vs baseline
-> Registry model (versioned, approved) -> Deploy inference
-> Monitoring drift & performa -> Retrain trigger

Standar minimum agar tidak membahayakan bisnis: model ter-versioning di registry (bukan file di laptop), evaluasi membandingkan dengan baseline sebelum deploy, dan monitoring drift — distribusi input bergeser (perilaku user berubah) membuat akurasi merosot diam-diam. Model tanpa monitoring adalah aset yang menyusut tanpa diketahui.

#Governance Metrik: Agar Angka Dipercaya

Platform terbaik sia-sia jika bisnis tak percaya angkanya. Tata kelola ringkas yang efektif:

• Metrik kamus (metric dictionary) — tiap metrik resmi punya definisi, formula, owner, dan refresh schedule; satu halaman per metrik.
• Certified vs exploratory — dashboard certified melewati review definisi; eksplorasi bebas tapi ditandai non-resmi.
• Data quality SLA — freshness (umur data maksimal), completeness (baris wajib), accuracy checks; pelanggaran SLA jadi alarm, bukan catatan kaki.
• Akses berdasarkan klasifikasi — lanjutan data classification episode 19: PII tidak masuk dashboard umum; agregasi dulu.

Ukuran keberhasilan platform data bukan jumlah dashboard, melainkan keputusan yang berubah karena datanya: promo dialihkan, kapasitas sale disesuaikan, fitur dihentikan. Saat mempresentasikan platform ini ke sponsor, ceritakan dalam bahasa itu (episode 11).

#Common Pitfalls

• Big data infrastructure untuk small data — cluster Spark untuk tabel 10 GB; PostgreSQL + cron sering selesai dalam sehari. Ukur dulu volumenya.
• Pipeline tanpa idempotency — rerun job menggandakan data; semua transformasi batch harus aman dieksekusi ulang (partition overwrite, merge).
• Dashboard zoo — ratusan dashboard tanpa owner; mayoritas mati tapi tetap dirawat. Audit berkala: dashboard tanpa viewer 90 hari → hapus.
• Streaming semua hal — kompleksitas exactly-once, state management, backpressure untuk kebutuhan yang puas dengan laporan per jam.
• Model tanpa owner pasca-launch — tim data pindah proyek, drift tak terpantau; setiap model production wajib punya owner dan retrain cadence.

#Penutup

Inti yang harus dibawa pulang:

• Pilih latensi ingestion dari nilai keputusan per use case — micro-batch untuk mayoritas, streaming hanya yang benar-benar butuh detik.
• Lakehouse dengan table format modern (Iceberg dkk.) memberi ACID, time travel, schema evolution, dan bebas engine di atas storage murah.
• Transformasi dikelola sebagai kode: staging-intermediate-marts, satu definisi metrik, test data, lineage, dan data contract.
• Feature store mencegah training-serving skew; MLOps minimal = registry versioned, evaluasi vs baseline, monitoring drift.
• Governance metrik (kamus, certified dashboard, data quality SLA) adalah yang membuat angka dipercaya dan dipakai mengambil keputusan.

Di episode 23 selanjutnya kita akan membahas edge & IoT solutions — merancang solusi ketika komputasi harus turun mendekati sumber data: topologi edge-cloud, protokol IoT dan telemetri massal, strategi offline-first untuk konektivitas tak andal, serta manajemen armada perangkat dalam skala ribuan. Sampai jumpa di episode 23!