Kamus, Silsilah Data, dan Klasifikasi

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 3 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Mencegah Data Buruk Masuk · Berikutnya: Hukum Privasi Membentuk Desain

Pertanyaan yang dijawab modul ini: Bagaimana Anda mencatat arti data, dari mana asalnya, dan seberapa sensitif ia?

Anda mewarisi sebuah org. Akun punya 900 bidang, di antaranya Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c, dan Account_Status__c. Mana yang memberi tahu Anda apakah seseorang benar-benar pelanggan? Anda membuka deskripsinya. Tiga kosong. Satu berbunyi “Customer Type.” Terima kasih. Satu menyebut berasal dari ERP; satu lagi dibuat enam tahun lalu oleh seseorang yang sudah lama pergi. Sekarang bayangkan Anda bukan arsiteknya melainkan sebuah integrasi, tim pelaporan, atau agen. Organisasi itu punya banyak data. Itu tidak berarti ia tahu arti datanya.

Di situlah metadata menjadi arsitektur, melalui tiga pertanyaan yang saling terkait tetapi tidak sama:

• Kamus: apa arti data ini?
• Silsilah data (lineage): dari mana asalnya?
• Klasifikasi: bagaimana ia harus diperlakukan?

Dua Jenis Metadata

Metadata ada dua jenis, dan Anda membutuhkan keduanya. Metadata bisnis adalah arti data itu bagi bisnis: definisinya, pemiliknya, aturan pemakaiannya, seberapa sensitif data itu. Metadata teknis adalah bagaimana data itu dibangun dan berpindah: objek dan bidangnya, tipe dan panjangnya, nama API-nya, skemanya, pemetaan dari satu sistem ke sistem lain, silsilah dari sumber ke tujuan. Nama API dan tipe sebuah bidang memberi tahu pengembang cara memakainya; definisi dan pemiliknya memberi tahu semua orang lain apakah boleh memakainya. Ketika keduanya tidak sejalan, atau salah satunya tidak ada, di situlah integrasi dan laporan menjadi salah.

Pengetahuan untuk ujian. Bedakan metadata bisnis (makna, definisi, pemilik, aturan, sensitivitas: kamus bisnis dan klasifikasi) dari metadata teknis (objek, bidang, tipe, nama API, skema, pemetaan, dan silsilah data).

Mulailah dari Maknanya

Bab 3 menetapkan aturannya: setiap bidang mendapat deskripsi. Bukan “Customer Status” untuk bidang bernama Customer Status, melainkan sesuatu seperti “Hubungan komersial mitra saat ini dengan Steve Trucking. Diisi dari ERP setelah aktivasi. Jangan dipakai untuk kualifikasi prospek.” Sekarang saya tahu artinya, dari mana asalnya, dan untuk apa ia tidak boleh dipakai. Itulah awal sebuah kamus bisnis: definisi bersama untuk data yang penting. Apa itu pelanggan? Pelanggan aktif? Apa arti Delivered? Apa yang dihitung sebagai tepat waktu? Kedengarannya jelas sampai Anda mengumpulkan lima departemen dalam satu ruangan: Keuangan punya satu definisi, Penjualan definisi lain, Operasional definisi ketiga, data warehouse definisi keempat, dan seseorang membangun dasbor di atas definisi kelima. Masalahnya bukan karena tidak ada yang bisa berbahasa yang sama. Masalahnya adalah perusahaan belum menyepakati artinya.

Sebuah kamus bisa tinggal di spreadsheet atau alat dokumentasi, tetapi definisi-definisi pentingnya perlu berada dekat dengan tempat orang memakai data. Di platform, itu adalah deskripsi bidang, teks bantuan, dan metadata klasifikasi. Di analitik, ini lebih penting lagi: “pendapatan” tidak boleh berarti satu hal di dasbor eksekutif dan hal lain di kueri seorang analis. Untuk itulah ada lapisan semantik, dan model semantik Data 360 menyimpan definisi terkelola seperti metrik, dimensi, dan hubungan di atas data fisiknya (Create a Semantic Model in Data 360 (opens in a new tab)). Teknologinya berubah; persyaratannya tidak: data penting butuh makna yang disepakati.

Dan mulailah dari maknanya, bukan dari teknologinya. Kamus yang dimulai dengan objek, bidang, tipe, dan nama API mendokumentasikan implementasinya. Kamus yang dimulai dengan istilah bisnis mendokumentasikan perusahaannya:

Istilah bisnis	Arti	Tempat direpresentasikan
Mitra Ritel	Peritel yang dilayani Steve Trucking, berdasarkan kontrak	Akun Salesforce; pelanggan di ERP keuangan
Pengiriman	Satu pengiriman ke satu Penerima, di satu alamat, pada satu hari	Saat ini RouteDesk; perintah kerja setelah pengiriman pindah ke Salesforce
Penerima	Orang yang menerima sebuah pengiriman	Detail Penerima pada pengiriman
Delivered	Selesai sesuai definisi operasional yang disepakati	Status pengiriman
Pengiriman tepat waktu	Selesai dalam jendela waktu pengiriman yang disepakati	Metrik turunan

Click to enlarge

Satu makna, banyak representasi teknis.

Lalu Tanyakan dari Mana Asalnya

Begitu saya tahu arti sebuah nilai, saya ingin tahu dari mana asalnya. Itulah silsilah data. Nama resmi sebuah mitra di Salesforce: apakah seorang sales mengetiknya, apakah ERP mengirimnya, apakah sebuah integrasi mentransformasinya, apakah Data 360 menyatukannya, apakah ia dihitung, apakah AI yang menghasilkannya? Semua itu memengaruhi seberapa besar saya memercayainya dan apa yang boleh saya lakukan dengannya. Ingat rekaman sementara dari modul 2: dua akun bisa sama-sama bertuliskan “Keystone,” satu dibuat oleh sales kemarin, satu lagi dari ERP dengan pengenal otoritatif. Teks yang sama, silsilah yang berbeda, perlakuan yang berbeda.

Silsilah data bukan hanya diagram seribu tabel milik data engineer. Untuk data penting, saya ingin menjawab pertanyaan-pertanyaan praktis: di mana ia bermula, sistem mana yang otoritatif, apa yang mentransformasinya, sistem mana yang mendapat salinannya, apa yang terakhir mengubahnya, dan bisakah saya menelusuri sebuah nilai turunan kembali ke sumber-sumbernya? Lanskap di bab 4 mengatakan bahwa sistem-sistem saling terhubung. Silsilah data mengatakan apa yang terjadi pada data di sepanjang jalan.

Sebagian silsilah data datang dengan sendirinya: ID ERP di akun, Created By dan Last Modified By, log integrasi, dokumen pemetaan. Data 360 menambahkan bidang silsilah data ke objek datanya yang mencatat sumber data dan objek sumber untuk setiap rekaman (Data Lineage Fields (opens in a new tab)). Tetapi jangan berasumsi silsilah data muncul hanya karena sistem-sistemnya terintegrasi. Kadang silsilah data yang paling berguna adalah satu bidang: Source System = Keystone. Dan jika sumbernya penting bagi tata kelola, buat ia andal secara mekanis, diisi oleh integrasi, bukan diketik oleh manusia.

Data turunan paling membutuhkan silsilah data. Misalkan Steve Trucking menghitung risiko keterlambatan pengiriman dari posisi truk, jendela waktu pengiriman, dan riwayat rute, dan dispatch memakainya untuk menentukan prioritas. Dari mana nilai “tinggi” itu berasal? Tambahkan sebuah agen yang memberi tahu Penerima “kiriman Anda terlambat,” dan Anda perlu tahu apa yang menjadi dasarnya, dan seberapa segar datanya. Makin jauh Anda bergerak dari nilai yang disimpan ke nilai yang dihitung, disatukan, diprediksi, dan dihasilkan, makin penting silsilah datanya.

Klasifikasi Menjawab Pertanyaan yang Berbeda

Sekarang: bagaimana ia harus diperlakukan? Nama Penerima, alamat pengiriman, nomor telepon, catatan pengiriman, status pengiriman, nomor truk, pusat distribusi, Mitra Ritel, foto: semuanya tidak sama sensitifnya. “Dalam pengiriman” bukanlah nomor telepon, dan kode DC bukanlah foto bagian dalam rumah seseorang. Salesforce memungkinkan Anda mencatat ini di setiap bidang, standar atau kustom: Data Owner, Field Usage, Data Sensitivity Level, dan Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Bab 3 menyebutnya bidang taksonomi, beserta alasan mengapa bidang-bidang itu penting: tandai sebuah bidang sebagai PII atau GDPR dan proses-proses bisa menemukannya, mulai dari alat masking hingga lapisan kepercayaan AI (trust layer) Salesforce, yang bisa mencegah nilai yang ditandai sampai ke model bahasa besar (LLM). Satu peringatan dari bab 3: Salesforce kini menonaktifkan masking LLM itu untuk agen, karena masking bisa menghilangkan konteks yang dibutuhkan agen (Klasifikasikan yang Penting: Bidang Taksonomi). Jadi klasifikasi tetap harus menggerakkan kontrol-kontrol lainnya.

Posisi saya di sini disengaja: klasifikasikan bidang-bidang yang sensitif, bukan setiap bidang. Saya tidak ingin tiga bulan dihabiskan untuk mengklasifikasikan ribuan bidang agar seseorang bisa melaporkan “100% terklasifikasi” lalu tidak ada yang memakainya. Nomor telepon Penerima: ya. Alamat rumah: ya. Catatan pengiriman yang mungkin berisi kode gerbang dan “ada anjing di halaman”: ya. Foto yang mungkin memperlihatkan orang atau sebuah rumah: tentu saja. Label tampilan internal? Bukan tempat energi tata kelola seharusnya dicurahkan. Itu tidak berarti bidang tanpa dokumentasi bisa diterima. Dua pekerjaan yang berbeda: dokumentasi bersifat luas; klasifikasi bersifat sengaja. Itulah yang membuat klasifikasi tetap bermakna.

Taksonomi yang Bisa Dipakai Orang

Klasifikasi butuh kosakata, sebuah taksonomi. Bawaan Salesforce adalah Public, Internal, Confidential, Restricted, dan MissionCritical; organisasi Anda mungkin menginginkan labelnya sendiri. Saya tidak menetapkannya. Buatlah mudah dipahami: jika ada 47 kategori dan tidak ada orang di luar tim privasi yang bisa membedakan kategori 31 dari 32, itu tidak membantu. Taksonomi yang baik menghubungkan sebuah label dengan perilaku. Jika sebuah bidang adalah data pribadi yang sensitif, siapa yang bisa melihatnya, bisakah ia masuk ke sandbox, keluar dari wilayahnya, muncul di analitik, berapa lama disimpan, bolehkah agen memakainya? Sekarang klasifikasi benar-benar bekerja.

Klasifikasi Tanpa Penegakan Hanyalah Hiasan

Tandai nomor telepon Penerima sebagai sensitif tanpa mengubah hal lain, dan Anda baru menulis dokumentasi. Berguna, tetapi tata kelola melangkah lebih jauh: klasifikasi seharusnya menggerakkan izin, penyamaran, enkripsi, retensi, persetujuan, perpindahan data, pemakaian sandbox, audit, dan akses AI. Sebagian dari itu adalah keputusan desain arsitek; sebagian platform kini menerapkan tag dan klasifikasi langsung dalam kebijakan, seperti yang dilakukan tata kelola Data 360 (Data Governance in Data 360 (opens in a new tab)). Dan menandai sebuah bidang sebagai Restricted tidak mencegah siapa pun membacanya. Klasifikasi menyatakan bagaimana sebuah bidang seharusnya diperlakukan; keamananlah yang membuatnya terjadi. Urutannya: identifikasi datanya, pahami, klasifikasikan yang penting, lalu terapkan kontrol yang diminta oleh klasifikasi itu.

Click to enlarge

Tiga pertanyaan tentang data Anda, dan yang ketiga harus menggerakkan sesuatu.

Data Referensi Juga Butuh Metadata

Kode negara, status pengiriman, kode DC, pengenal mitra, alasan pembatalan: semuanya terlihat sederhana sampai dua sistem tidak sepakat. Satu bilang CANCELLED, yang lain CANCELED, yang ketiga CNCL, yang keempat 9. Data referensi butuh definisi, pemilik, sumber, siklus hidup ketika nilai berubah, dan pemetaan ketika sistem merepresentasikannya secara berbeda. Nilai-nilai kecil bisa menggerakkan proses yang sangat besar. Bab 6 membahasnya lebih jauh.

Ketiganya Bersama-sama

Ambil nomor telepon Penerima. Kamus: nomor yang dipakai untuk menghubungi orang yang menerima sebuah pengiriman tertentu. Silsilah data: dari manifes Mitra Ritel. Klasifikasi: data pribadi. Sekarang pertanyaan-pertanyaan arsitekturnya menjadi mungkin: bolehkah kru melihatnya, dan berapa lama (ringkasannya bilang hanya untuk titik pemberhentian mereka sendiri, hanya di hari itu); bisakah ia masuk ke sandbox; apakah Snowflake membutuhkannya; bolehkah agen memakainya; apa yang terjadi setelah pengirimannya selesai?

Sekarang ambil status pengiriman. Kamus: keadaan operasional pengiriman saat ini. Silsilah data: diisi oleh proses pengiriman Steve Trucking dan dikirim balik ke setiap mitra melalui integrasinya masing-masing. Klasifikasi: operasional, tidak sensitif. Data yang berbeda, perlakuan yang berbeda. Itulah intinya.

Saya tidak memperlakukan metadata sebagai dokumentasi yang dibuat setelah arsitektur yang sebenarnya selesai. Jika saya tidak bisa menyebutkan arti sebuah bidang, saya tidak memahami model datanya. Jika saya tidak tahu dari mana sebuah nilai berasal, saya tidak memahami integrasinya. Jika saya tidak tahu apakah ia sensitif, saya tidak memahami keamanannya. Metadata menggambarkan arsitektur, dan kadang menggerakkannya.

Di luar ujian: apa yang diubah AI. Klasifikasi sedang menjadi sakelar untuk apa yang boleh diambil atau diulang oleh agen, dan silsilah data harus menjangkau sampai ke jawaban atau tindakan agen. Jika sebuah agen memberi tahu Penerima bahwa kirimannya terlambat, arsitektur seharusnya bisa menyebutkan apa yang menjadi dasarnya, dari mana asalnya, dan apakah agen boleh memakainya. “Di suatu tempat di Salesforce” bukanlah silsilah data, dan “data pelanggan” bukanlah klasifikasi.

Yang Diputuskan Arsitek di Sini

• Istilah bisnis mana yang butuh definisi terkelola, agar sistem dan tim tidak memberi satu kata arti yang berbeda-beda.
• Bagaimana nilai-nilai penting menyimpan cukup silsilah data untuk menunjukkan sumber, otoritas, dan transformasinya.
• Bidang mana yang membawa makna sensitivitas atau kepatuhan sehingga mendapat klasifikasi eksplisit.
• Taksonomi mana yang dipakai organisasi, dan apakah orang bisa menerapkannya secara konsisten.
• Bagaimana klasifikasi menggerakkan kontrol yang nyata alih-alih dibiarkan tidak terpakai.

Sebelum Anda mengelola data, ketahui apa yang Anda miliki: apa artinya, dari mana asalnya, bagaimana ia harus diperlakukan. Dokumentasikan secara luas, klasifikasikan dengan sengaja, simpan silsilah data di tempat yang penting. Jika tidak, Anda tidak sedang mengelola data. Anda hanya memilikinya.

Jelajahi

• Bantuan Salesforce, Data Classification Metadata Fields (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
• Bantuan Salesforce, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab), dan Create a Semantic Model in Data 360 (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).