Data Mesh: Apakah Relevan untuk Perusahaan di Indonesia

Data mesh adalah pendekatan mengelola data yang memindahkan kepemilikan dari satu tim pusat ke tiap divisi yang paling paham datanya. Tim data pusat berubah jadi penyedia platform, bukan lagi tukang jahit semua permintaan.

Istilah ini muncul dari tulisan Zhamak Dehghani tahun 2019, dan sejak itu kepakai di banyak konferensi.

Pertanyaan yang lebih penting buat kamu: perusahaan tempat kamu kerja beneran butuh atau enggak?

Apa itu data mesh?

Data mesh adalah cara mengatur organisasi data yang membagi tanggung jawab per domain bisnis, bukan per tahapan teknis. Tiap divisi yang menghasilkan data juga bertanggung jawab menyajikannya dalam bentuk yang siap dipakai divisi lain. Tim pusat menyediakan alat dan aturan main, lalu memastikan definisi bersama tetap konsisten.

Bandingin sama pola lama. Di pola terpusat, tim data yang isinya 6 orang harus paham data penjualan, keuangan, gudang, dan pemasaran sekaligus.

Mereka nggak akan pernah sepaham orang gudang soal kenapa ada kolom "status_retur" yang isinya lima kode aneh. Jadi antrean permintaan numpuk dan kualitas datanya tetap goyah.

Empat prinsip data mesh

Tulisan asli data mesh principles di situs Martin Fowler menyebut empat prinsip. Ini versi bahasa manusianya.

1. Kepemilikan data per domain. Divisi penjualan yang punya data penjualan, termasuk tanggung jawab atas kualitasnya. Bukan tim data pusat.

2. Data sebagai produk. Data yang kamu terbitkan punya nama, pemilik, dokumentasi, jaminan kesegaran, dan kontak kalau rusak. Sama kayak produk software.

3. Platform layan-mandiri. Tim domain nggak boleh dipaksa bikin pipeline dari nol. Tim platform nyediain perkakas standar biar orang finance bisa nerbitin data tanpa jadi data engineer.

4. Tata kelola federasi. Definisi bersama kayak "pelanggan aktif" disepakati wakil dari tiap domain, lalu ditegakkan otomatis lewat pengujian. Bukan lewat rapat bulanan.

Prinsip keempat ini yang paling sering dilewatin, dan itu yang paling mahal akibatnya.

Data mesh vs gudang data terpusat

Aspek	Terpusat	Data mesh
Pemilik data	Tim data pusat	Tiap domain bisnis
Kecepatan awal	Cepat	Lambat, butuh koordinasi
Skala ke 20 tim	Antrean menumpuk	Lebih tahan
Biaya orang	Rendah	Tinggi, tiap domain butuh orang data
Risiko definisi bercabang	Rendah	Tinggi kalau tata kelolanya lemah
Cocok untuk	Di bawah 3 tim penghasil data	Di atas 5 tim dengan produk berbeda

Perhatiin baris biaya orang. Data mesh butuh minimal satu orang yang ngerti data di tiap domain.

Kalau perusahaan kamu susah cari satu data analyst aja, prinsip pertama udah nggak bisa jalan sejak hari pertama.

Kapan data mesh masuk akal buat perusahaan Indonesia?

Aku pakai daftar cek ini waktu ditanya klien. Kalau jawabannya "ya" untuk 4 dari 6 poin, baru layak dibahas serius.

1. Ada lebih dari 5 tim yang bikin dan pakai data mereka sendiri
2. Antrean permintaan ke tim data pusat lebih dari 3 minggu secara rutin
3. Sumber data lebih dari 50, dari sistem yang beda-beda
4. Tiap domain udah punya minimal 1 orang yang bisa nulis SQL
5. Udah ada praktik kontrol versi dan pengujian otomatis di tim teknologi
6. Manajemen siap ngasih anggaran orang, bukan cuma anggaran tool

Dari pengalaman aku ngobrol sama tim data di beberapa perusahaan Jakarta dan Surabaya, poin 4 dan 6 yang paling sering gagal.

Banyak yang pengin data mesh karena kepengin arsitekturnya kelihatan modern. Padahal masalah aslinya cuma satu: nggak ada yang bertanggung jawab kalau angka salah.

Dan masalah itu bisa dipecahkan tanpa merombak arsitektur.

Contoh kasus: jaringan minimarket 34 cabang

Aku pernah bantu jaringan minimarket dengan 34 cabang di Jawa Tengah. Tim datanya 3 orang, sumber datanya 7 sistem.

Keluhan awalnya klasik: laporan omzet mingguan selalu telat 2 hari, dan angka dari tim keuangan sering beda sama angka dari tim operasional.

Waktu aku telusuri, selisihnya rata-rata 4,7 persen. Penyebabnya bukan arsitektur. Tim keuangan ngitung omzet setelah retur, tim operasional ngitung sebelum retur.

Perbaikannya nggak butuh data mesh. Cuma butuh tiga hal:

• Satu dokumen definisi metrik yang disepakati dua tim
• Satu tabel ringkasan harian yang jadi rujukan tunggal
• Lima query pengujian yang jalan otomatis tiap pagi

Query pengujiannya sesederhana ini.

SELECT order_id, COUNT(*) AS jumlah
FROM dp_penjualan_harian
GROUP BY order_id
HAVING COUNT(*) > 1;

Kalau ada baris yang keluar, berarti ada transaksi kegandaan dan laporan pagi itu ditahan.

Selisih 4,7 persen tadi turun jadi di bawah 0,3 persen dalam 6 minggu. Tanpa mengubah satu pun komponen infrastruktur.

Itu yang aku maksud waktu bilang kebanyakan perusahaan Indonesia belum butuh data mesh. Yang mereka butuh adalah kontrak data dan pemilik yang jelas.

Yang bisa kamu ambil dari data mesh tanpa menerapkannya penuh

Empat prinsip tadi bisa dipinjam sebagian. Ini yang paling murah dan paling cepat kerasa.

Tempelkan nama pemilik di tiap tabel penting. Satu kolom di katalog, isinya nama orang. Bukan nama tim.

Bikin kontrak data sederhana. Tiga janji aja cukup: kunci unik, kolom wajib nggak boleh kosong, dan batas keterlambatan muat data.

SELECT MAX(tanggal_muat) AS terakhir_dimuat
FROM dp_penjualan_harian;

Kalau umurnya lebih dari 24 jam, kirim peringatan.

Sepakati definisi metrik secara tertulis. Simpan di satu tempat yang bisa dilihat semua orang, dan catat tanggal perubahannya.

Otomatiskan pengujian. Data quality yang dicek manual bakal berhenti dicek dalam 3 minggu.

Empat langkah itu ngambil sekitar 80 persen manfaat data mesh dengan sekitar 10 persen biayanya.

Kesalahan umum soal data mesh

Nganggap data mesh itu produk yang bisa dibeli. Nggak ada vendor yang bisa jual data mesh, karena isinya pembagian tanggung jawab.

Ngedesentralisasi tanpa tata kelola. Tiap domain bikin definisi metric sendiri, lalu angka di rapat direksi nggak pernah cocok.

Mindahin beban ke domain tanpa mindahin orangnya. Tim marketing disuruh punya data product tapi nggak dikasih tambahan orang. Hasilnya data product yang nggak pernah diperbarui.

Lupa ETL tetap harus jalan. Data mesh nggak menghapus pekerjaan pemindahan dan pembersihan data. Cuma memindahkan siapa yang ngerjain.

Ngukur sukses dari jumlah data product. Yang layak diukur itu berapa lama waktu tunggu permintaan data dan berapa sering angkanya salah.

FAQ

Apa itu data mesh dalam satu kalimat?

Data mesh adalah cara mengelola data dengan memberi tiap divisi tanggung jawab penuh atas data yang mereka hasilkan, lalu mewajibkan mereka menyajikannya sebagai produk yang bisa dipakai divisi lain. Tim pusat berubah peran jadi penyedia platform dan penjaga aturan bersama, bukan lagi pihak yang ngerjain semua permintaan data.

Apa bedanya data mesh dan data warehouse?

Data warehouse itu soal teknologi penyimpanan terpusat. Data mesh itu soal siapa yang bertanggung jawab atas datanya. Kamu tetap bisa pakai warehouse di dalam data mesh, bedanya tiap domain punya wilayahnya sendiri dan bertanggung jawab atas kualitas isinya. Jadi dua istilah ini bukan pilihan yang saling meniadakan.

Berapa besar perusahaan yang cocok pakai data mesh?

Patokan kasarnya, kalau kamu punya lebih dari 3 tim yang bikin data sendiri dan tim data pusat udah jadi antrean panjang, baru masuk akal. Di bawah itu, koordinasinya lebih mahal daripada masalah yang dipecahkan. Perusahaan dengan satu tim data di bawah 10 orang hampir selalu lebih untung pakai warehouse terpusat.

Apakah data mesh butuh tool khusus?

Nggak ada tool yang bikin kamu otomatis punya data mesh, karena ini soal pembagian tanggung jawab, bukan produk. Yang biasanya dibutuhkan adalah katalog data, sistem kontrol versi buat definisi metrik, dan pengujian otomatis. Semua itu bisa dibangun pakai perkakas yang mungkin udah kamu punya sekarang.

Apa risiko terbesar kalau salah menerapkan data mesh?

Definisi metrik jadi bercabang. Tiap divisi bikin versi omzet dan pelanggan aktifnya sendiri, lalu angka di rapat direksi nggak pernah cocok. Ini kebalikan dari tujuan awalnya. Pencegahannya ada di prinsip keempat, tata kelola federasi, yang mewajibkan definisi bersama disepakati dan diuji otomatis.

Penutup

Data mesh menjawab masalah organisasi besar: tim data pusat jadi leher botol waktu jumlah domain tumbuh.

Kalau perusahaan kamu punya 3 tim dan 7 sumber data, masalahmu kemungkinan besar bukan itu. Di kasus minimarket 34 cabang tadi, selisih 4,7 persen hilang cuma dengan satu dokumen definisi dan lima query pengujian.

Pinjam prinsipnya, tunda arsitekturnya. Pemilik yang jelas, kontrak data, dan pengujian otomatis udah nutup sebagian besar rasa sakitnya.

Mau mulai dari query pengujian pertama? Latihan nulisnya ada di NgulikSQL. Lanjut baca juga cara nyusun ringkasan eksekutif satu halaman biar temuanmu kepakai di rapat.