Canonical data model menyediakan bentuk bersama agar setiap sistem tidak perlu memetakan langsung ke semua sistem lain. Ide ini dapat mengurangi kombinasi mapping, tetapi model bersama juga dapat tumbuh menjadi schema raksasa yang lambat berubah dan tidak benar-benar dimiliki siapa pun.
Masalah apa yang ingin diselesaikan?
Dengan lima sistem point-to-point, setiap pasangan dapat memiliki mapping sendiri. Perubahan istilah customer, amount, atau status harus disesuaikan pada banyak koneksi. Bentuk canonical membuat sistem A memetakan ke model bersama, lalu tujuan memetakan dari model tersebut. Jumlah hubungan konseptual dapat turun dan aturan umum lebih mudah ditinjau.
Manfaat hanya muncul bila makna canonical jelas. Nama field yang seragam tetapi definisinya berbeda menciptakan konsistensi palsu. Mulai dengan pemilik serta sumber kebenaran data, bukan sekadar menyamakan nama.
Seberapa luas model sebaiknya dibuat?
Model enterprise tunggal terdengar menarik tetapi sulit menampung variasi semua domain. Model per domain—customer, order, inventory, finance—memberi boundary yang lebih realistis. Bagian lintas-domain memakai reference dan kontrak eksplisit. Hindari menambahkan field hanya karena satu consumer membutuhkannya sementara.
| Pendekatan | Kekuatan | Risiko |
|---|---|---|
| Universal enterprise | Satu kosakata | Besar dan lambat berubah |
| Per domain | Pemilik lebih jelas | Butuh kontrak antar-domain |
| Per use case | Sederhana dan cepat | Duplikasi dapat tumbuh |
Bagaimana menjaga makna saat mapping?
Setiap field memerlukan definisi, satuan, timezone, precision, aturan null, enum, dan provenance. “total” dapat berarti sebelum pajak, setelah diskon, atau nilai yang sudah dibayar. Mapping tidak boleh menebak. Jika sumber tidak menyediakan konsep canonical, nyatakan gap atau hitung melalui aturan yang disetujui.
Gunakan contoh valid dan edge case, lalu tinjau bersama pemilik domain. Artikel perbedaan tipe data antar-database membantu memisahkan konversi teknis dari perubahan makna bisnis.
Siapa mengelola versi dan perubahan?
Tetapkan pemilik schema canonical, proses proposal, klasifikasi breaking change, masa transisi, serta katalog consumer. Perubahan model bersama dapat memengaruhi banyak alur sekaligus. Kompatibilitas harus diuji terhadap consumer nyata dan data arsip, bukan hanya schema terbaru.
Gunakan API versioning dan contract testing sebagai disiplin pendukung. Field deprecated perlu tenggat serta telemetry penggunaan sebelum dihapus.
Anti-pattern apa yang perlu dihindari?
- Model menjadi salinan tabel dari satu sistem dominan.
- Field “misc” atau object bebas menampung semua pengecualian.
- Semua status dipaksa ke enum yang kehilangan makna.
- Consumer-specific field masuk ke core model tanpa review.
- Versi lama dihentikan tanpa inventaris consumer.
- Model dianggap sebagai master data tanpa otoritas bisnis.
Ia adalah kontrak pertukaran; otoritas tetap harus ditentukan per domain dan field.
Kapan model canonical layak digunakan?
Model ini bernilai ketika banyak sistem berbagi konsep stabil dan biaya mapping berulang sudah terukur. Untuk dua sistem dengan kontrak sederhana, adapter langsung mungkin lebih mudah. Mulai dari subset kecil, ukur perubahan yang dapat digunakan ulang, dan hentikan ekspansi bila governance lebih mahal daripada manfaat.
NitroNet dapat membantu memvisualkan pemetaan dan transformasi pada workflow, tetapi artikel ini tidak mengklaim model canonical bawaan atau detail implementasi. Gunakan prinsip menerjemahkan logika menjadi node dan buat nama transformasi yang menunjukkan makna, bukan hanya “map data”.
Pilih satu konsep—misalnya customer—dari CRM, billing, dan support. Jangan mencoba membuat seluruh enterprise model. Petakan hanya field yang dibutuhkan satu use case, lalu nilai berapa banyak aturan yang benar-benar dapat digunakan ulang.
- Tulis definisi customer, account, contact, dan organization sebelum menyamakan nama field.
- Tentukan otoritas setiap field karena satu entity dapat memiliki beberapa sumber kebenaran.
- Bandingkan null, default, enum, timezone, serta identifier pada ketiga sistem.
- Catat konsep yang tidak memiliki padanan dan larang mapping diam-diam ke nilai terdekat.
- Buat model per domain dengan extension terkontrol, bukan object bebas untuk semua pengecualian.
- Uji perubahan field canonical terhadap ketiga adapter dan consumer yang memakai hasil.
- Hitung mapping yang hilang, mapping baru, serta beban governance setelah proof of concept.
- Minta pemilik domain menyetujui makna model, bukan hanya tim platform atau integrasi.
Jika model mengurangi mapping berulang dan memperjelas istilah, perluas secara bertahap. Jika setiap consumer membutuhkan banyak pengecualian, model mungkin terlalu umum atau boundary domain salah. Jangan mengukur keberhasilan dari jumlah field canonical; ukur perubahan yang dapat digunakan ulang tanpa kehilangan makna.
Sebelum menambah field, minta contoh nyata dari sekurangnya dua producer dan dua consumer. Dokumentasikan arti, satuan, cardinality, nullability, sistem otoritatif, serta aturan konversinya. Bila istilah “customer” berarti pihak pembayar pada satu domain dan penerima barang pada domain lain, jangan menggabungkannya hanya karena namanya sama. Pertahankan namespace atau konteks domain yang eksplisit. Review berkala harus menghapus elemen tidak terpakai dan menjelaskan extension, sehingga model tidak berubah menjadi schema raksasa yang sulit dipahami serta semakin mahal dirawat.