Belajar Data Architect - Data Product Design

#Pendahuluan

Setelah di episode 12 kita memahami data mesh dan prinsip "data as a product", sekarang kita masuk ke praktiknya: bagaimana merancang data product yang benar. Banyak organisasi mengklaim punya data product, tapi isinya hanya dataset yang dibuang ke katalog tanpa kontrak, SLA, atau pemilik yang jelas — itu bukan produk, itu dump file.

Mengapa episode ini penting? Karena data product adalah unit konsumsi data di arsitektur modern: kontraknya menentukan siapa bisa memakai apa dan dengan jaminan apa. Produk yang dirancang baik membuat konsumen mandiri; produk yang asal jadi membuat konsumen kembali menumpuk pertanyaan ke tim pusat.

#Apa Itu Data Product

Data product adalah unit data yang bisa dikonsumsi secara mandiri oleh konsumen internal: memiliki pemilik, dokumentasi, kualitas yang dijamin, dan jaminan (SLA). Konsumen memakainya tanpa perlu memahami internal pipeline di baliknya — seperti memakai API.

Komponen data product

OWNER       → tim yang bertanggung jawab (steward + engineer)
DOCUMENTATION → deskripsi, skema, contoh, kontak dukungan
QUALITY     → skor kualitas & SLO yang dipantau
ACCESS      → mekanisme akses & approval yang jelas
SLA         → jaminan freshness, availability, dan dukungan
MARKETPLACE → tempat ditemukan konsumen

#Kontrak Data

Data contract adalah perjanjian eksplisit antara produsen dan konsumen data: skema, semantik, dan jaminan. Analoginya seperti kontrak API: konsumen tahu bentuk data yang akan datang dan apa yang dijamin.

Contoh data contract (ringkas)

data_product: sales.orders_daily
version: 1.2.0
owner: tim-sales-data
 
schema:
  - { name: order_date, type: date, nullable: false }
  - { name: revenue,    type: decimal, nullable: false }
  - { name: channel,    type: string, nullable: true }
  - { name: order_id,   type: string, nullable: false, unique: true }
 
semantics:
  revenue: "pendapatan bersih pesanan berstatus done"
  channel: "paid, organic, referral"
 
sla:
  freshness: pukul 03:00 WIB setiap hari
  availability: 99.9% per bulan
  quality_slo: row_count ≥ 95% median 30 hari
  response_time: dukungan dalam 1 hari kerja

Kontrak menjawab pertanyaan yang selalu diajukan konsumen: kolom ini artinya apa? Boleh dipakai untuk apa? Kapan datanya datang? Siapa yang saya hubungi kalau rusak?

Note

Kontrak data seharusnya disimpan sebagai kode (misal YAML di repo yang sama dengan transformasi) dan diverifikasi otomatis di CI: setiap perubahan skema akan memunculkan diff — konsumen terpengaruh mendapat notifikasi sebelum dirilis, bukan setelah produksi rusak.

#SLA dan SLO untuk Data Product

Data product butuh jaminan terukur. Bedakan dua hal:

Istilah	Arti	Contoh
SLO	Target internal yang dipantau	Freshness 30 menit, quality 95%
SLA	Janji eksternal pada konsumen	Data tersedia 03:00, dukungan 1 hari

SLA data product yang umum:

Dimensi SLA data product

FRESHNESS     → seberapa baru data saat konsumen melihatnya
AVAILABILITY  → persentase waktu data bisa diakses
QUALITY       → ambang kualitas minimum (null, duplikat, anomali)
SUPPORT       → kecepatan respons saat konsumen melapor
CHANGE NOTIFICATION → pemberitahuan perubahan skema/semantik

Poin penting: SLA hanya bisa dijanjikan jika SLO dipantau. Jangan menjanjikan "data selalu fresh pukul 03:00" kalau tidak ada monitoring yang membuktikannya (episode 9).

#Internal Data Marketplace

Data marketplace adalah tempat konsumen menemukan, mengevaluasi, dan meminta akses data product — biasanya dibangun di atas data catalog (episode 8) dengan tambahan lapisan "toko":

Fitur marketplace data internal

- Pencarian: cari berdasarkan istilah bisnis
- Pratinjau: contoh data, skema, dokumentasi
- Rating & review: umpan balik konsumen
- Metrik pemakaian: siapa memakai apa
- Akses: request + approval tercatat
- Trust badge: skor kualitas, freshness, SLO status

Marketplace yang baik menyelesaikan dua masalah sekaligus: discovery (data mudah ditemukan) dan trust (konsumen tahu mana yang layak dipakai).

#Praktik: Mendefinisikan Data Product

#Step 1: Pilih Satu Data Product

Mulai dari data yang paling banyak dikonsumsi dan paling sering dipermasalahkan (misal orders_daily).

#Step 2: Isi Kontrak

Tulis kontrak data product (skema, semantik, SLA, owner) sebagai file YAML di repo, dan daftarkan di katalog.

#Step 3: Pasang SLO dan Monitoring

Terapkan SLO freshness & quality dari episode 9, dengan alert ke owner.

#Step 4: Publish ke Marketplace

Publikasikan di katalog/marketplace: dokumentasi lengkap, skor kualitas, dan alur akses yang jelas.

#Step 5: Evaluasi Pemakaian

Ukur siapa yang memakai, ulasan konsumen, dan berapa lama permintaan akses diproses. Produk yang tidak dipakai dievaluasi: hilangkan, atau perbaiki supaya layak pakai.

Tip

Kekuatan sebuah data product diukur dari waktu konsumen dari menemukan sampai memakai dan berapa sedikit pertanyaan yang harus ditanyakan ke owner. Produk yang bagus menjawab pertanyaan lewat dokumentasi dan kontraknya, bukan lewat tanya-berantai di chat.

#Penutup

Inti yang harus dibawa pulang:

Data product = owner + dokumentasi + kualitas + SLA + akses + marketplace.
Data contract adalah perjanjian skema, semantik, dan jaminan antara produsen dan konsumen.
SLA hanya bisa dijanjikan jika SLO dipantau — janji tanpa monitoring adalah kebohongan.
Marketplace internal menyelesaikan discovery dan trust sekaligus.
Ukur produk dari waktu konsumen sampai bisa memakai — bukan dari jumlah dataset yang diterbitkan.

Di episode 14 selanjutnya kita akan membahas Cost & FinOps Data — bagaimana memodelkan, melacak, dan mengoptimasi biaya platform data yang semakin besar. Sampai jumpa di episode 14!