Belajar Data Architect - Data Mesh & Decentralization
Mengenal Data Mesh dari buku Zhamak Dehghani: empat prinsip domain ownership, data as a product, self-serve platform, dan federated governance, serta cara menilai kapan organisasi siap menerapkannya
#Pendahuluan
Setelah di episode 11 kita memusatkan definisi metrik di semantic layer, sekarang kita membahas arah yang tampak bertolak belakang: decentralisasi. Data Mesh — dipopulerkan Zhamak Dehghani (2019) — menantang asumsi bahwa semua data harus dikelola satu tim pusat.
Mengapa episode ini penting? Karena banyak organisasi besar menghadapi dinding yang sama: tim data pusat menjadi bottleneck — semua permintaan menumpuk di satu tim, sementara domain bisnis paling paham datanya sendiri. Data Mesh adalah salah satu jawaban arsitektural untuk skala. Tapi ia bukan jawaban untuk semua orang; arsitek harus paham kapan ia berlaku.
#Mengapa Data Mesh Lahir
Masalah yang ingin diselesaikan Data Mesh: pusat vs domain. Arsitektur terpusat (central data team) bekerja saat volume permintaan kecil. Saat organisasi tumbuh, terjadi fenomena ini:
- Permintaan akses dan model baru antre berbulan-bulan
- Tim pusat tidak mengerti konteks bisnis tiap domain
- Domain saling menyalin data karena tidak bisa mendapatkannya
- Satu pipeline rusak → semua domain terdampak (single point of failure)Data Mesh memindahkan tanggung jawab kepada pemilik domain — mereka yang paling paham datanya.
#Empat Prinsip Data Mesh
#1. Domain Ownership
Pemilik domain bertanggung jawab atas data mereka: kualitas, skema, dan akses. Tim sales memiliki data sales, tim finance memiliki data finance — bukan tim data pusat.
Sales → data sales: model, kualitas, dokumentasi, akses
Finance → data finance: model, kualitas, dokumentasi, akses
Product → data product: model, kualitas, dokumentasi, aksesPeran tim data pusat berubah: dari pemilik semua menjadi penyedia platform dan penjaga standar.
#2. Data as a Product
Data tidak lagi "byproduct" — ia produk dengan konsumen internal. Setiap domain menerbitkan data product dengan atribut produk sungguhan: owner, dokumentasi, SLA, dan support. Detailnya kita bedah di episode 13.
#3. Self-Serve Data Platform
Agar domain bisa mandiri, tim platform menyediakan platform self-serve: infrastruktur, tooling, dan standar yang membuat tim domain bisa menerbitkan dan mengonsumsi data product tanpa menunggu tim pusat. Semakin bagus platform, semakin kecil overhead tiap domain.
#4. Federated Computational Governance
Governance terpusat dalam prinsip, terdesentralisasi dalam eksekusi: tim pusat menetapkan standar global (keamanan, kualitas minimum, katalog), domain menjalankannya di domainnya masing-masing. Ini gabungan otoritas pusat dan kemandirian domain.
#Data Mesh Bukan untuk Semua Orang
Ini poin yang harus dipegang arsitek: Data Mesh menambah kompleksitas, bukan menguranginya. Ia memindahkan kompleksitas dari satu tim pusat ke banyak tim domain. Organisasi yang tepat menerapkannya:
| Kondisi | Cocok Data Mesh? |
|---|---|
| Tim data terpusat menjadi bottleneck | ✔ |
| Domain bisnis punya kemampuan data (engineer/analyst melekat) | ✔ |
| Banyak domain dengan konteks bisnis sangat berbeda | ✔ |
| Tim data kecil (5-10 orang), satu domain dominan | ✘ Tetap terpusat |
| Belum ada standar & platform dasar | ✘ Bangun dulu fondasinya |
Warning
Data mesh bukan alat untuk memperbaiki data yang kacau — ia alat untuk skala pada organisasi yang sudah punya standar. Menerapkan data mesh di organisasi tanpa governance, katalog, atau kualitas adalah cara cepat menggandakan kekacauan: sekarang kacau dan tersebar di banyak tim.
#Menerapkan Data Mesh Secara Bertahap
Jangan membalik arsitektur dalam satu proyek. Roadmap yang realistis:
#Fase 1: Fondasi Platform
- Lakehouse + pipeline yang andal (episode 4-6)
- Governance: catalog, lineage, stewardship (episode 8)
- Kualitas: SLO data terukur (episode 9)
- Semantic layer untuk metrik bersama (episode 11)Tanpa ini, domain tidak punya tempat mendarat.
#Fase 2: Pilot Satu Domain
Pilih satu domain (misal sales) dan jadikan mereka penerbit data product pertama. Tim platform melatih, domain menjalankan. Ukur: waktu rilis data product baru, jumlah konsumen, kualitas.
#Fase 3: Perluas dengan Standar Federated
Setelah pilot sukses, perluas domain demi domain dengan playbook yang sama. Tim pusat kini bertindak sebagai platform team: menyediakan infra, menjaga standar, dan mengevaluasi pematuhan.
Tip
Ukuran keberhasilan data mesh bukan "berapa banyak domain yang ikut", tapi berkurangnya waktu end-to-end untuk mendapatkan data yang bisa dipercaya. Jika domain bisa menerbitkan dan konsumen bisa memakai dalam hari (bukan bulan), mesh bekerja. Jika tidak, perbaiki platform, bukan tambah domain.
#Peran Data Architect dalam Data Mesh
Peran arsitek bergeser, tidak hilang:
- Merancang platform self-serve dan standar teknis.
- Menetapkan kontrak data product, SLA, dan model data antar domain.
- Menjaga federated governance agar prinsip global tetap tegak.
- Menilai kesiapan organisasi sebelum mesh diterapkan — keberanian untuk berkata "belum siap" juga bagian dari pekerjaan arsitek.
#Penutup
Inti yang harus dibawa pulang:
- Data Mesh menjawab bottleneck tim pusat dengan decentralization ke domain.
- Empat prinsip: domain ownership, data as product, self-serve platform, federated governance.
- Data Mesh bukan untuk semua organisasi — butuh platform dan standar yang sudah matang.
- Terapkan bertahap: fondasi → pilot satu domain → perluasan dengan playbook.
- Peran arsitek bergeser ke platform, kontrak, dan federated governance.
Di episode 13 selanjutnya kita akan membahas Data Product Design — kontrak data, SLA, dan internal marketplace untuk data yang benar-benar dipakai konsumen. Sampai jumpa di episode 13!