Pukul dua pagi, tabel pelanggan.csv di TokoKita terdeteksi berisi baris ganda, dan grup insiden langsung bungkam pada satu pertanyaan: siapa yang bertanggung jawab atas tabel ini? Semua orang tahu cara memperbaiki datanya, tetapi tidak ada yang berhak memutuskan perlukah pipeline dihentikan atau pelanggan dihubungi. Masalahnya bukan teknis melainkan kepemilikan — aset tanpa owner adalah aset yang tidak akan pernah dirawat sampai masalah muncul. Bab ini membahas cara mendefinisikan ownership yang jelas (owner, steward, eskalasi, SLA), menyimpannya sebagai registry yang bisa diaudit otomatis, dan membagi peran saat insiden data lewat tabel RACI.
Owner, Steward, dan Domain Owner #
Ownership yang sehat membagi tanggung jawab pada tiga peran yang berbeda. Data owner adalah pihak yang memegang akuntabilitas akhir atas aset — biasanya tim bisnis yang memahami arti datanya, misalnya tim transaksi atas tabel pesanan. Data steward menjalankan perawatan sehari-hari: memeriksa kualitas, menjaga definisi kolom, dan menjadi kontak pertama saat ada pertanyaan. Domain owner memegang lingkup yang lebih luas — seluruh data di satu domain bisnis — dan menjadi titik eskalasi ketika keputusan melampaui satu aset.
Satu prinsip yang tidak bisa ditawar: setiap aset harus punya tepat satu owner. Kepemilikan bersama atas aset yang sama selalu berakhir sebagai kepemilikan kosong, karena masing-masing pihak mengira pihak lain yang menjaga.
Registry Ownership sebagai Kode #
Definisi ownership yang hanya hidup di dokumen presentasi akan basi dalam hitungan bulan. TokoKita menyimpannya sebagai registry YAML yang di-review seperti kode — setiap entri menyatakan owner, steward, jalur eskalasi, dan SLA pemulihan saat aset bermasalah:
# Registry ownership TokoKita: aset -> owner, steward, eskalasi, SLA.
aset:
pesanan.parquet:
owner: tim-transaksi
steward: Dewi
eskalasi: kepala-data
sla_pemulihan_jam: 4
pelanggan.csv:
owner: tim-crm
steward: Budi
eskalasi: kepala-data
sla_pemulihan_jam: 8
log_lama.csv:
owner: tim-platform
steward: Sari
eskalasi: kepala-data
sla_pemulihan_jam: 24Registry saja tidak cukup — registry harus terus dicocokkan dengan katalog dari Chapter Data Catalog, karena aset baru lahir setiap minggu tanpa sempat didaftarkan. Skrip berikut membandingkan kedua sumber dan menemukan dua jenis masalah sekaligus: aset di katalog yang tidak punya owner, dan entri registry untuk aset yang sudah tidak ada:
"""Audit ownership: bandingkan aset di katalog dengan registry; temukan aset tanpa owner."""
import json
from pathlib import Path
import yaml
REGISTRY = Path(__file__).parent / "registry.yaml"
KATALOG = Path(__file__).parent / "catalog.json"
def tampilkan_registry(aset_set):
print(f"=== Registry ownership: {len(aset_set)} entri ===")
print(f"{'Aset':<24}{'Owner':<14}{'Steward':<8}{'Eskalasi':<12}SLA")
for nama, info in sorted(aset_set.items()):
print(f"{nama:<24}{info['owner']:<14}{info['steward']:<8}"
f"{info['eskalasi']:<12}{info['sla_pemulihan_jam']} jam")
def audit(aset_set, katalog):
"""Aset di katalog tanpa entri registry = aset tanpa owner (orphan)."""
nama_katalog = {entri["nama"] for entri in katalog}
nama_registry = set(aset_set)
orphan = sorted(nama_katalog - nama_registry)
basi = sorted(nama_registry - nama_katalog)
print(f"=== Audit: katalog ({len(katalog)} aset) vs registry ({len(aset_set)} entri) ===")
print("Aset tanpa owner (ada di katalog, tidak ada di registry):")
for nama in orphan:
print(f" - {nama}")
print("Entri basi (ada di registry, tidak ada di katalog):")
for nama in basi:
print(f" - {nama}")
cakupan = len(nama_katalog & nama_registry)
print(f"Cakupan ownership: {cakupan}/{len(katalog)} aset "
f"({cakupan / len(katalog):.0%})")
return orphan
def jalankan():
aset_set = yaml.safe_load(REGISTRY.read_text())["aset"]
katalog = json.loads(KATALOG.read_text())
tampilkan_registry(aset_set)
audit(aset_set, katalog)
if __name__ == "__main__":
jalankan()Output yang Dihasilkan:
=== Registry ownership: 3 entri ===
Aset Owner Steward Eskalasi SLA
log_lama.csv tim-platform Sari kepala-data 24 jam
pelanggan.csv tim-crm Budi kepala-data 8 jam
pesanan.parquet tim-transaksi Dewi kepala-data 4 jam
=== Audit: katalog (4 aset) vs registry (3 entri) ===
Aset tanpa owner (ada di katalog, tidak ada di registry):
- produk.csv
- staging_voucher.parquet
Entri basi (ada di registry, tidak ada di katalog):
- log_lama.csv
Cakupan ownership: 2/4 aset (50%)Mari kita telaah baris-baris kode di atas:
- Baris 21-24 (dua himpunan): nama aset dari katalog dan dari registry masing-masing dikumpulkan menjadi himpunan. Operasi himpunan kemudian menemukan masalah dua arah: selisih katalog minus registry, dan sebaliknya.
- Baris 23-24 (
orphandanbasi):orphanadalah aset yang hidup di sistem tapi tak bertuan;basiadalah entri registry untuk aset yang sudah dihapus — keduanya sama-sama menyesatkan pembaca registry. - Baris 32-34 (cakupan): proporsi aset katalog yang punya owner. Angka ini pantauan mingguan yang sehat; angka yang turun berarti aset baru lahir lebih cepat daripada proses registrasinya.
Hasil auditnya jelas: produk.csv dan staging_voucher.parquet belum bertuan, dan cakupan ownership baru 50%. Entri log_lama.csv juga perlu dibersihkan dari registry karena asetnya sudah pensiun.
RACI saat Insiden Data #
Saat insiden terjadi, kecepatan keputusan bergantung pada kejelasan peran. Tabel RACI memetakan siapa yang mengerjakan (Responsible), siapa yang memegang akuntabilitas keputusan (Accountable), siapa yang dikonsultasikan (Consulted), dan siapa yang cukup diberi informasi (Informed):
| Aktivitas insiden | Data Owner | Data Steward | Data Engineer |
|---|---|---|---|
| Validasi laporan masalah | A | R | C |
| Perbaikan pipeline dan data | I | A | R |
| Keputusan menghentikan konsumen data | A | C | R |
| Komunikasi ke pengguna data | A | R | I |
| Post-mortem dan pencegahan | A | R | C |
Perhatikan polanya: pekerjaan teknis jatuh ke steward dan engineer, tetapi setiap keputusan yang berdampak bisnis — menghentikan konsumen, mengomunikasikan ke pelanggan — selalu punya satu Accountable, dan posisi itu dipegang owner.
Onboarding Aset Baru: Handshake Ownership #
Audit mingguan menemukan aset tanpa owner, tetapi pencegahan terbaik terjadi saat aset dibuat. Handshake ownership adalah daftar periksa wajib sebelum pipeline baru boleh menulis aset pertamanya:
- Tentukan owner (satu tim, satu nama) dan steward; tulis keduanya di registry pada pull request yang sama dengan kode pipeline.
- Sepakati SLA pemulihan dan jalur eskalasi — siapa yang dihubungi di luar jam kerja.
- Daftarkan aset ke katalog lengkap dengan tags dan klasifikasi.
- Sepakati jadwal review: registry dibaca ulang tiap kuartal, entri basi dibersihkan, owner yang pindah tim diganti.
Kerangka peran owner-steward ini diadopsi dari praktik manajemen data yang dirangkum DAMA International dalam DAMA-DMBOK . Registry yang bersih dan RACI yang jelas menuntaskan pertanyaan “siapa” — tinggal satu lapisan terakhir tata kelola: bagaimana seluruh aturan ini ditulis sebagai kebijakan yang bisa dievaluasi mesin, pokok bahasan Chapter Compliance dan Kebijakan Data.