Belajar Enterprise Architect - Data & Information Architecture

#Pendahuluan

Setelah di episode 4 kalian membangun capability map, value stream, dan mengambil keputusan operating model Coordination untuk Bumi Niaga — proses otonom, data inti terpadu — kini saatnya menurunkan keputusan itu ke domain pertama yang terdampak: data and information architecture.

Ingat temuan episode 3: tabel customer milik BelanjaKu, user wallet milik BayarKu, dan nama penerima paket di KirimKu adalah tiga definisi "pelanggan" yang tidak saling bicara. Di bawah pola Coordination, ini tidak bisa dibiarkan — cross-sell, loyalty lintas lini, dan satu pandangan risiko nasabah semuanya mati di hambatan ini. Episode ini membahas empat alat EA untuk domain data: enterprise data model, master data management, data governance, dan data platform.

#Enterprise Data Model: Peta Informasi Organisasi

Enterprise data model (EDM) adalah peta entitas informasi penting organisasi beserta relasinya — pada tingkat konseptual, bukan skema tabel. Fokusnya pada pertanyaan bisnis: entitas apa yang bernilai, siapa yang memilikinya, dan bagaimana definisinya disepakati.

Struktur EDM yang saya rekomendasikan berlapis:

• Konseptual — 15-30 entitas inti (Pelanggan, Produk, Pesanan, Pengiriman, Akun Pembayaran, Consent) dengan relasi utama; inilah yang dibahas dengan eksekutif.
• Logis — atribut kunci dan identifier per entitas inti, terutama untuk entitas master; inilah yang dipakai tim data.
• Fisik — skema aktual per sistem; ranah engineer, hanya dirujuk dari EDM, tidak dimodelkan ulang.

Untuk Bumi Niaga, entitas paling kontroversial adalah Pelanggan. Latihan EDM memaksakan pertanyaan yang tak pernah ditanyakan: apakah "user wallet BayarKu" itu pelanggan yang sama dengan "customer BelanjaKu"? Jawaban bisnisnya ya — orang yang sama — maka model konseptual menetapkan satu entitas Pelanggan dengan banyak role: shopper, pengirim paket, pemilik wallet. Definisi tunggal, banyak peran. Itulah pekerjaan arsitektur data yang sesungguhnya: kesepakatan makna, bukan diagram ERD raksasa.

#Master Data Management: Menyelesaikan Fragmentasi

Master data adalah data referensi inti yang dipakai banyak sistem — pelanggan, produk, supplier, lokasi. MDM (Master Data Management) adalah kombinasi teknologi dan proses untuk memastikan semua sistem memakai satu versi kebenarannya.

Empat gaya arsitektur MDM, dari ringan ke berat:

Rekomendasi untuk Bumi Niaga adalah registry-first menuju coexistence: mulai dari identity resolution — menyatukan tiga identitas lewat phone/email/device ID dengan skor kecocokan — tanpa memaksa ketiga lini menulis ulang sistemnya dalam satu proyek. Registry memberi golden record untuk konsumsi analitik dan layanan baru; migrasi tulis penuh dilakukan bertahap saat tiap sistem direfresh.

#Data Governance: Aturan Main yang Hidup

Data governance adalah kerangka keputusan dan tanggung jawab atas data — bukan komite yang membuat dokumen, melainkan mekanisme agar pertanyaan data punya jalur jawaban. Komponen minimum yang harus eksis:

• Data owner — eksekutif yang memutuskan definisi, akses, dan retensi per domain data (misalnya Chief Data Officer untuk domain Pelanggan).
• Data steward — pelaksana harian yang menjaga mutu, menyetujui perubahan kamus data, menyelesaikan konflik definisi.
• Kamus data & katalog — definisi resmi tiap entitas dan atribut penting; "pelanggan aktif" artinya apa? Siapa yang memutuskan? Kamus menjawabnya.
• Kebijakan mutu & metrik — completeness, accuracy, duplication rate untuk data master; diukur rutin, bukan sekali saat proyek.

Governance yang hidup terlihat dari perilaku: ketika tim KirimKu bertanya "bolehkah pakai data wallet untuk scoring kredit?", ada jalur jelas — minta persetujuan owner domain Pelanggan, cek basis consent, catat di katalog — dan jawabannya keluar dalam hitungan hari, bukan bulan. Governance yang mati terlihat dari gejalanya: setiap pertanyaan data akhirnya naik ke meeting mingguan yang agenda-nya penuh hal lain.

Prinsip arsitektur data sebaiknya ditetapkan formal di fase ini, contohnya:

D-01  Satu definisi pelanggan di tingkat grup; variasi peran
      dinyatakan eksplisit, bukan sistem terpisah
D-02  Data master punya satu owner domain dan satu sistem
      of record per atribut kritis
D-03  Consent mengikuti data: tujuan penggunaan dicatat dan
      dapat diaudit untuk setiap konsumsi data personal
D-04  Data untuk analitik mengalir lewat platform terkelola,
      bukan ekspor ad-hoc antar sistem

Prinsip semacam ini nanti menjadi alat kerja governance di episode 9 — proposal teknis dinilai terhadap prinsip, bukan selera.

#Data Platform: Menopang Coordination

Keputusan operating model menuntut tempat data berkumpul. Bentuk modern yang layak dipertimbangkan adalah lakehouse — object storage berformat terbuka (misalnya Parquet/Iceberg) dengan layer tabel ber-versioning, dipakai baik untuk BI maupun ML. Yang lebih penting dari produknya adalah garis besar komposisinya:

Dua keputusan arsitektural yang sering diperdebatkan:

• Satu platform grup vs per lini — di bawah Coordination: satu platform grup untuk zona curated dan layanan identitas; lini bebas punya sandbox eksperimen. Hindari dua platform paralel yang mereplikasi biaya.
• BayarKu on-premise — regulasi fintech membatasi data transaksi keluar. Solusi umum: zona on-premise untuk data teregulasi, ekstraksi agregat/anonim ke platform grup dengan persetujuan regulator. Pola ini kita detail ulang saat membahas cloud dan regulasi di episode 13 dan 19.

#Praktik: Rancangan Data Architecture Bumi Niaga

Kerjakan di ea-lab/case-study/data/:

1. EDM konseptual — 15-20 entitas inti lintas tiga lini dengan relasi utama; tandai mana yang master data. Gambar di Archi (layer business/application) atau draw.io.
2. Keputusan MDM — satu halaman: gaya awal (registry), kriteria naik ke coexistence, data owner dan steward per domain, metrik mutu awal (duplication rate target).
3. Prinsip data D-01..D-06 — lanjutkan daftar di atas dengan dua prinsip tambahan hasil analisis kalian, misal soal retensi atau arsitektur consent.
4. Sketsa platform — diagram layer ingestion/storage/serving/governance, dengan zona khusus untuk batasan on-premise BayarKu.

Artefak ini menjadi baseline data domain yang akan dirujuk saat kita merancang integrasi (episode 12), kepatuhan consent (episode 19), dan fondasi AI (episode 21).

#Penutup

Inti yang harus dibawa pulang:

• EDM tingkat konseptual memaksa kesepakatan makna — untuk Bumi Niaga: satu entitas Pelanggan dengan banyak peran, menyelesaikan tiga definisi yang tercecer.
• MDM dimulai pragmatis dari registry dan identity resolution; teknologi bukan penyebab utama kegagalannya — stewardship yang absen.
• Governance hidup ditandai jalur keputusan yang jelas dan cepat: owner, steward, kamus, dan metrik mutu; prinsip data menjadi alat penilaian proposal teknis.
• Data platform mengikuti operating model: Coordination berarti satu platform grup untuk data curated plus zona khusus untuk batasan regulasi BayarKu.

Domain data sudah tertata. Di episode 6 selanjutnya kita naik ke domain application: menginventarisasi ~40 aplikasi Bumi Niaga, menilainya dengan matriks TIME, dan menyusun rencana rasionalisasi — termasuk nasib dua CRM yang duplikatif. Sampai jumpa di episode 6!