10.4 Data: Milik Siapa, Bagaimana Bentuknya, dan Ke Mana Alirnya

Integrasi membawa konsekuensi pada data: siapa pemiliknya, bagaimana bentuknya, dan bagaimana alurnya. Ini adalah pertanyaan yang sering dianggap sepele sampai seseorang menemukan bahwa dua sistem menyimpan data customer yang sama tetapi isinya berbeda. Atau tim data science menghabiskan dua minggu membersihkan data karena tidak ada yang tahu format mana yang benar. Atau bagian legal tiba-tiba bertanya, “Data customer kita ada di server mana saja?”

Bayangkan tim Anda sudah memutuskan untuk membangun sistem rekomendasi dengan mengambil data dari CRM dan sistem transaksi. Semua terlihat rapi di diagram arsitektur. Tapi begitu implementasi dimulai, tim CRM berkata, “Kami hanya menyediakan akses ke data pelanggan aktif, bukan data historis.” Sementara tim transaksi berkata, “Kami punya data pembelian, tapi field product_id tidak sama dengan yang dipakai di katalog.” Tiba-tiba integrasi yang tampak sederhana berubah menjadi proyek mapping data yang memakan waktu berminggu-minggu.

Di sinilah data view menjadi penting. Data view adalah cara arsitek melihat data sebagai aset yang harus dikelola, bukan sekadar sesuatu yang lewat di antara sistem. Pertanyaan pertama yang harus dijawab adalah: siapa pemilik data? Dalam organisasi yang tidak jelas kepemilikannya, setiap tim bisa merasa memiliki data yang sama, atau lebih buruk, tidak ada yang merasa bertanggung jawab atas kualitasnya. Pemilik data bukan berarti tim yang menyimpan data, tetapi tim yang bertanggung jawab memastikan data itu akurat, konsisten, dan bisa dipercaya.

Diagram berikut memperjelas bagaimana data mengalir dari berbagai sumber menuju source of truth, lalu ke sistem rekomendasi, dengan label pemilik dan format data yang berbeda.

flowchart TD CRM[CRM\nPemilik: Tim Sales\nFormat: customer_id, name, email] -->|sinkronisasi harian| DW[(Data Warehouse\nSource of Truth)] TX[Transaksi\nPemilik: Tim Finance\nFormat: cust_id, product_id, amount] -->|sinkronisasi real-time| DW XLS[Excel Sales\nPemilik: Tim Sales\nFormat: nama, produk, harga] -->|import manual| DW DW -->|data konsolidasi| REC[Sistem Rekomendasi\nPemilik: Tim Data Science] DW -->|data bersih| BI[BI Dashboard\nPemilik: Tim Analitik] subgraph Keterangan A[product_id di TX != product_id di Katalog] B[Excel tidak memiliki field customer_id] end

Lalu ada source of truth. Ketika data customer bisa berasal dari CRM, dari sistem lama, dari file Excel yang dikirim sales, atau dari form pendaftaran website, mana yang benar? Source of truth adalah satu sistem yang ditetapkan sebagai referensi utama. Sistem lain boleh menyimpan salinan, tetapi jika ada perbedaan, yang dipakai adalah versi dari source of truth. Ini kedengarannya sederhana, tetapi dalam praktiknya banyak organisasi tidak pernah menetapkannya secara eksplisit.

Bentuk data juga perlu diperjelas. Schema apa yang dipakai? Apakah data dikirim dalam format JSON, XML, atau protobuf? Apakah field-fieldnya sudah disepakati antar tim? Apakah ada standar penamaan yang konsisten? Tanpa kesepakatan ini, setiap integrasi akan membutuhkan transformasi data yang berbeda-beda, dan kode transformasi itu akan menumpuk menjadi utang teknis yang sulit diurus.

Berikut contoh definisi skema data customer dalam YAML yang mendokumentasikan format, kepemilikan, dan status source of truth.

schema:
  name: Customer
  namespace: com.company.crm
  type: record
  fields:
    - name: customerId
      type: string
    - name: name
      type: string
    - name: email
      type: string
    - name: phone
      type: [string, null]
    - name: address
      type: Address
  owner: Tim CRM
  sourceOfTruth: true

Aliran data juga harus dipetakan. Data masuk dari mana, diproses di mana, disimpan di mana, dan dikirim ke mana? Apakah ada data yang keluar organisasi? Apakah ada data yang perlu dienkripsi saat transit? Apakah ada data yang harus dihapus setelah jangka waktu tertentu? Pertanyaan-pertanyaan ini bukan hanya teknis, tetapi juga menyangkut kepatuhan terhadap regulasi seperti UU Perlindungan Data Pribadi.

Data lifecycle juga perlu dirancang. Data lahir, digunakan, disimpan, diarsipkan, dan akhirnya dihapus. Tidak semua data perlu disimpan selamanya. Retention policy harus jelas: data transaksi mungkin perlu disimpan sepuluh tahun untuk keperluan audit, tetapi data log sementara bisa dihapus setelah tiga bulan. Tanpa lifecycle, biaya penyimpanan membengkak dan risiko kebocoran data meningkat.

AI bisa membantu di sini. Alat-alat AI sekarang bisa membaca diagram arsitektur dan dokumen integrasi, lalu menghasilkan data flow diagram secara otomatis. Mereka juga bisa memvalidasi apakah data flow yang dirancang konsisten dengan source of truth yang ditetapkan. Bahkan, AI bisa membantu mendeteksi anomali: misalnya, jika ada data yang mengalir ke sistem yang tidak tercantum dalam dokumentasi. Tapi ingat, AI hanya alat bantu. Keputusan tentang kepemilikan data, schema, dan lifecycle tetap harus dibuat oleh manusia yang memahami konteks bisnis dan organisasi.

Setelah data view jelas, arsitek bisa melanjutkan ke lapisan berikutnya: bagaimana memastikan data itu aman dari akses yang tidak berhak.

Trade-off Matrix
Trade-off Matrix