Enterprise Data Mesh Architecture & Federated Governance Engine

Tujuan Modul Belajar (Study Handbook Objective):

Modul ini disusun khusus sebagai Masterclass & Architecture Handbook untuk mempelajari arsitektur data modern dari dasar (*from scratch*) hingga implementasi produksi (*production-grade*). Mengupas tuntas Framework Data Mesh, perbedaannya dengan Data Warehouse & Lakehouse, studi kasus nyata multifinance alat berat (PT NusaFinance), kepatuhan regulasi privasi Indonesia (UU PDP No. 27/2022 & OJK), serta 10 Simulasi Pertanyaan Wawancara Data Architect.

ANALOGI DAPUR RESTORAN VS FOOD COURT OTONOM:

1. TRADISIONAL MONOLITH (DAPUR TERPUSAT):
   [Dapur Masakan Padang] ──┐
   [Dapur Sushi Jepang]    ──┼──> [3 Chef Data Pusat] ──> [Etalase Makanan Campur] ──> [Pelanggan Bingung]
   [Dapur Steak Western]   ──┘         ▲ Kelelahan & Antrean Panjang
                                       ▲ Tidak Paham Resep Masakan
                                       ▲ Backlog 3-6 Minggu

2. DATA MESH (FOOD COURT STANDAR TINGGI):
   [Stand Padang (Domain A)]  ──> [Menu Rendang Terstandar (Data Product)] ──┐
   [Stand Sushi (Domain B)]   ──> [Menu Salmon Terstandar (Data Product)]  ──┼──> [Konsumen Bebas Memilih]
   [Stand Steak (Domain C)]   ──> [Menu Wagyu Terstandar (Data Product)]   ──┘     (Diperiksa Otomatis oleh
                                                                                   Standar BPOM/CI-CD)

┌────────────────────────────────────────────────────────────────────────────────────────┐
│                        4 PILAR FUNDAMENTAL DATA MESH                                   │
├───────────────────────────┬───────────────────────────┬────────────────────────────────┤
│ 01. DOMAIN OWNERSHIP      │ 02. DATA AS A PRODUCT     │ 03. SELF-SERVE DATA PLATFORM   │
│ Tim domain bisnis         │ Data analitik dikemas     │ Abstraksi infrastruktur yang   │
│ memiliki & merawat data   │ sebagai produk bernilai   │ memudahkan tim domain merilis  │
│ analitik mereka sendiri.  │ tinggi dengan SLA resmi.  │ data product tanpa pusing infra│
├───────────────────────────┴───────────────────────────┴────────────────────────────────┤
│ 04. FEDERATED COMPUTATIONAL GOVERNANCE                                                 │
│ Standar keamanan, audit regulasi, dan interoperabilitas ditegakkan lewat kodingan CI   │
└────────────────────────────────────────────────────────────────────────────────────────┘

EKOSISTEM OPERASIONAL PT NUSAFINANCE:
┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ TAMBANG BATUBARA│       │ KELAPA SAWIT    │       │ PROYEK INFRA    │
│ Kalimantan Timur│       │ Riau & Sumsel   │       │ Tol Trans Jawa  │
│ (Excavator 20T) │       │ (Dump Truck)    │       │ (Bulldozer D8R) │
└────────┬────────┘       └────────┬────────┘       └────────┬────────┘
         └─────────────────────────┼─────────────────────────┘
                                   ▼
                    [PT NusaFinance Data Ecosystem]
      ┌─────────────────────────────────────────────────────────┐
      │ • 14,800 Kontrak Pembiayaan Aktif (Nilai Miliaran Rp)   │
      │ • 8,400 Mesin Terhubung Telematika IoT (Jam & GPS)      │
      │ • 45 Kantor Cabang di Seluruh Indonesia                 │
      │ • Kewajiban Regulasi: OJK & UU PDP No. 27/2022          │
      └─────────────────────────────────────────────────────────┘

TOPOLOGI 5 DOMAIN PT NUSAFINANCE & ALIRAN RISK 360:

 ┌─────────────────────────────────────────────────────────────────────────────────────────┐
 │                                   TOPOLOGI DOMAIN MESH                                  │
 │                                                                                         │
 │   ┌──────────────────────┐   ┌──────────────────────┐   ┌───────────────────────────┐   │
 │   │  1. CORE LEASING     │   │  2. ASSET EQUIPMENT  │   │  3. CREDIT RISK & SCORING │   │
 │   │  Entitas: Kontrak,   │   │  Entitas: Mesin IoT, │   │  Entitas: Underwriting,   │   │
 │   │  Tenor, Pokok Utang, │   │  Jam Operasi, GPS,   │   │  Probabilitas Default,    │   │
 │   │  Bunga Pembiayaan    │   │  Kondisi Jaminan     │   │  Peringkat Risiko OJK     │   │
 │   │  Schema:             │   │  Schema:             │   │  Schema:                  │   │
 │   │  domain_leasing      │   │  domain_equipment    │   │  domain_risk              │   │
 │   └──────────┬───────────┘   └──────────┬───────────┘   └─────────────┬─────────────┘   │
 │              │                          │                             │                 │
 │              ▼                          ▼                             ▼                 │
 │     [leasing_dp port]          [equipment_dp port]            [risk_dp port]            │
 │              │                          │                             │                 │
 │              └──────────────────┐       │       ┌─────────────────────┘                 │
 │                                 │       │       │                                       │
 │   ┌──────────────────────┐      ▼       ▼       ▼       ┌───────────────────────────┐   │
 │   │  4. CUSTOMER & KYC   │   ┌──────────────────────┐   │  5. BILLING & TREASURY    │   │
 │   │  Entitas: Identitas, │──>│  CROSS-DOMAIN        │   │  Entitas: Invoice,        │   │
 │   │  NIK, NPWP, PT Debitur│  │  RISK 360 ENGINE     │<──│  Pelunasan, Arrears,      │   │
 │   │  (UU PDP Masked View)│   │  Kueri: <15 Menit    │   │  Days Past Due (DPD)      │   │
 │   │  Schema:             │   │  (Trino In-Memory)   │   │  Schema:                  │   │
 │   │  domain_crm          │   └──────────────────────┘   │  domain_finance           │   │
 │   └──────────┬───────────┘                              └─────────────┬─────────────┘   │
 │              ▼                                                        ▼                 │
 │        [crm_dp port]                                           [finance_dp port]        │
 └─────────────────────────────────────────────────────────────────────────────────────────┘

ANATOMI LENGKAP SEBUAH DATA PRODUCT:
┌────────────────────────────────────────────────────────────────────────────────┐
│                          BATAS UNIT DATA PRODUCT                               │
│                                                                                │
│  [Input Ports] ──────> [Engine Transformasi] ────────> [Private Data Store]    │
│  (CDC / Kafka / API)   (dbt / Python / PySpark)         (Tabel Internal Rahasia)│
│                                                                 │              │
│                                                                 ▼              │
│  [Port Observabilitas] <────────────────────────────── [Public Output Ports]   │
│  • SLA Kesegaran Data                                   • View SQL (ANSI)      │
│  • Kontrak ODCS YAML                                    • File Parquet / S3    │
│  • Garis Silsilah (Lineage)                             • REST API Read-Only   │
└────────────────────────────────────────────────────────────────────────────────┘

-- ============================================================================
-- DOMAIN 01: CORE LEASING (OUTPUT PORT RESMI)
-- ============================================================================
CREATE SCHEMA IF NOT EXISTS leasing_dp;

CREATE OR REPLACE VIEW leasing_dp.active_portfolio AS
SELECT 
    contract_id,
    borrower_id,
    asset_id,
    principal_amount::NUMERIC(15, 2) AS principal_idr,
    tenor_months,
    interest_rate_pct::NUMERIC(5, 2) AS annual_interest_pct,
    disbursement_date,
    maturity_date,
    contract_status,
    updated_at AS data_freshness_timestamp
FROM domain_leasing.contracts
WHERE contract_status IN ('ACTIVE', 'RESTRUCTURED', 'GRACE_PERIOD');

-- ============================================================================
-- DOMAIN 02: ASSET TELEMATICS IOT (OUTPUT PORT RESMI)
-- ============================================================================
CREATE SCHEMA IF NOT EXISTS equipment_dp;

CREATE OR REPLACE VIEW equipment_dp.telematics_summary AS
SELECT 
    asset_id,
    machine_category,          -- Excavator, Bulldozer, Dump Truck
    brand_model,               -- Komatsu PC200-8, CAT 320D
    total_operating_hours,
    last_known_latitude,
    last_known_longitude,
    telematics_signal_status,   -- ONLINE, SIGNAL_LOST, GEOFENCE_VIOLATION
    collateral_health_tier,     -- TIER_1_OPTIMAL, TIER_2_WARNING, TIER_3_CRITICAL
    last_ping_timestamp
FROM domain_equipment.telematics_snapshots;

-- ============================================================================
-- DOMAIN 04: CUSTOMER CRM (OUTPUT PORT DENGAN MASKING DINAMIS UU PDP)
-- ============================================================================
CREATE SCHEMA IF NOT EXISTS crm_dp;

CREATE OR REPLACE VIEW crm_dp.borrower_directory AS
SELECT 
    borrower_id,
    company_name,
    business_sector,
    -- Masking Deterministik UU PDP: Hanya 4 digit awal & 4 digit akhir yang terlihat
    CASE 
        WHEN pg_has_role(CURRENT_USER, 'role_compliance_auditor', 'USAGE') THEN nik_raw
        ELSE CONCAT(SUBSTRING(nik_raw, 1, 4), '********', SUBSTRING(nik_raw, 13, 4))
    END AS nik_masked,
    CONCAT(SUBSTRING(phone_number, 1, 4), '****', SUBSTRING(phone_number, 9, 4)) AS contact_masked,
    registered_province,
    kyc_compliance_status
FROM domain_crm.borrowers;

ALUR PENGUJIAN KONTRAK DI GITHUB ACTIONS (SHIFT-LEFT):

[Developer Domain] ──> Membuat Pull Request dengan Perubahan Skema
                                │
                                ▼
[GitHub Actions CI] ──> Menjalankan Validator computational_contract_validator.py
                                ├── 1. Validasi Sintaks ODCS YAML
                                ├── 2. Cek Kompatibilitas SemVer (Cegah Breaking Change)
                                ├── 3. Uji Kualitas Data (Great Expectations)
                                └── 4. Scanner Regex UU PDP (Cegah NIK 16-Digit Polos)
                                │
                      ┌─────────┴─────────┐
                      │                   │
                   [LULUS]             [GAGAL]
                      │                   │
                      ▼                   ▼
             [Deploy ke Staging]   [PR Diblokir Otomatis]
             [Katalog Diperbarui]  [Developer Diberi Notifikasi Error]

version: 2.1.0
kind: DataContract
metadata:
  domain: Core Leasing
  dataProduct: Active Lease Portfolio
  ownerEmail: squads-leasing@nusafinance.co.id
  repository: github.com/nusafinance/mesh-domain-leasing
  classification: Internal Confidentially Restricted

dataset:
  name: leasing_dp.active_portfolio
  physicalType: relational-view
  refreshInterval: 0 * * * * # Eksekusi Setiap Jam
  sla:
    freshnessMinutes: 60
    availabilityPct: 99.8

schema:
  - name: contract_id
    type: string
    primaryKey: true
    required: true
    tests:
      - unique
      - not_null
      - regex: "^CTR-[0-9]{4}-[A-Z]{3}-[0-9]{4}$"

  - name: borrower_id
    type: string
    required: true
    foreignKey: crm_dp.borrower_directory.borrower_id

  - name: asset_id
    type: string
    required: true
    foreignKey: equipment_dp.telematics_summary.asset_id

  - name: principal_idr
    type: numeric
    required: true
    tests:
      - greater_than: 10000000 # Minimal pembiayaan Rp 10 Juta

  - name: tenor_months
    type: integer
    required: true
    tests:
      - between: [6, 84] # Jangka waktu 6 s/d 84 bulan

  - name: contract_status
    type: string
    required: true
    tests:
      - accepted_values: ['ACTIVE', 'RESTRUCTURED', 'GRACE_PERIOD']

governance:
  complianceFrameworks:
    - OJK_POJK_35_2018
    - INDONESIA_UU_PDP_NO_27_2022
  piiMaskingPolicy: strict-port-enforced

-- Membuat role konsumen analitik dan auditor kepatuhan
CREATE ROLE role_data_consumer;
CREATE ROLE role_compliance_auditor;

-- Cabut akses ke skema internal rahasia
REVOKE ALL ON SCHEMA domain_leasing FROM role_data_consumer;
REVOKE ALL ON SCHEMA domain_crm FROM role_data_consumer;

-- Berikan izin HANYA ke public output ports
GRANT USAGE ON SCHEMA leasing_dp TO role_data_consumer;
GRANT SELECT ON ALL TABLES IN SCHEMA leasing_dp TO role_data_consumer;

GRANT USAGE ON SCHEMA crm_dp TO role_data_consumer;
GRANT SELECT ON ALL TABLES IN SCHEMA crm_dp TO role_data_consumer;

-- ============================================================================
-- PT NUSAFINANCE RISK 360 FEDERATED ANALYTICAL ENGINE
-- Menghubungkan 4 output port otonom dalam satu kueri SQL federasi (Waktu: 420ms)
-- ============================================================================
WITH Risk360Summary AS (
    SELECT 
        l.contract_id,
        c.borrower_id,
        c.company_name,
        c.business_sector,
        c.nik_masked,
        c.registered_province,
        
        -- Finansial Kontrak (Domain Leasing)
        l.principal_idr,
        l.tenor_months,
        l.annual_interest_pct,
        l.contract_status,
        
        -- Fisik Alat Berat & Lokasi (Domain Equipment IoT)
        e.asset_id,
        e.machine_category,
        e.brand_model,
        e.total_operating_hours,
        e.telematics_signal_status,
        e.collateral_health_tier,
        
        -- Riwayat Keterlambatan Bayar (Domain Finance Billing)
        f.current_dpd,
        f.consecutive_late_months,
        
        -- Penilaian Kredit & Skor Default (Domain Risk Underwriting)
        r.credit_score,
        r.probability_of_default,
        
        -- Klasifikasi Risiko Komposit Dinamis
        CASE 
            WHEN f.current_dpd > 90 OR e.collateral_health_tier = 'TIER_3_CRITICAL' 
                THEN 'SEVERELY_IMPAIRED'
            WHEN f.current_dpd > 30 OR e.telematics_signal_status = 'SIGNAL_LOST' 
                THEN 'ELEVATED_WATCHLIST'
            WHEN r.probability_of_default > 0.15 
                THEN 'MODERATE_MONITORING'
            ELSE 'HEALTHY_PERFORMING'
        END AS composite_risk_classification

    FROM leasing_dp.active_portfolio l
    INNER JOIN crm_dp.borrower_directory c 
        ON l.borrower_id = c.borrower_id
    INNER JOIN equipment_dp.telematics_summary e 
        ON l.asset_id = e.asset_id
    INNER JOIN finance_dp.payment_performance f 
        ON l.contract_id = f.contract_id
    LEFT JOIN risk_dp.underwriting_scores r 
        ON l.borrower_id = r.borrower_id
)
SELECT 
    composite_risk_classification,
    COUNT(contract_id) AS total_contracts,
    ROUND(SUM(principal_idr) / 1000000000.0, 2) AS total_exposure_idr_billion,
    ROUND(AVG(current_dpd), 1) AS avg_days_past_due,
    ROUND(AVG(total_operating_hours), 0) AS avg_machine_hours
FROM Risk360Summary
GROUP BY composite_risk_classification
ORDER BY total_exposure_idr_billion DESC;

HASIL EVALUASI DATSIS KESELURUHAN:
• Skor Rata-rata Mesh: 4.67 / 5.00 (Meningkat +117% dibandingkan Monolith lama: 2.15 / 5.00)
• Data Product Terbaik: crm_dp.borrower_directory (4.85 / 5.00 berkat perlindungan UU PDP sempurna)

# ============================================================================
# LANGKAH 1: Jalankan lingkungan pengujian multi-domain terisolasi
# ============================================================================
docker compose -f docker-compose.mesh-test.yml up -d --build

# ============================================================================
# LANGKAH 2: Eksekusi validator kontrak komputasional ODCS
# ============================================================================
python scripts/computational_contract_validator.py \
  --contract configs/contracts/leasing_contract_v2.yaml \
  --db-url postgresql://test_admin:test_secret@localhost:5432/nusafinance_test

# ============================================================================
# LANGKAH 3: Jalankan uji kebocoran data privasi UU PDP
# ============================================================================
pytest tests/governance/test_uu_pdp_compliance.py -v

# ============================================================================
# LANGKAH 4: Uji integrasi kueri analitik lintas domain Risk 360
# ============================================================================
pytest tests/integration/test_risk_360_cross_domain_join.py -v

Model Jawaban Arsitek:

Data Mesh bukan peluru perak (*silver bullet*) dan berbahaya jika dipaksakan ke organisasi kecil. Jangan adopsi Data Mesh jika:

1. Organisasi hanya memiliki 1–2 domain bisnis dan tim engineering di bawah 30 orang. Koordinasi terdesentralisasi justru akan menambah beban birokrasi. Solusi modular Data Warehouse (dbt + BigQuery/Snowflake) jauh lebih murah dan efisien.

2. Kedewasaan software engineering masih rendah (tidak ada budaya Git, CI/CD, atau automated test).

3. Syarat kedewasaan minimal: memiliki minimal 3–5 domain bisnis yang berdiri sendiri, mengalami bottleneck antrean data terpusat (>3 minggu), serta ada komitmen manajemen untuk mendanai data engineer di tiap tim domain.

Model Jawaban Arsitek:

Terapkan disiplin Semantic Versioning (SemVer) pada Port Output: MAJOR.MINOR.PATCH.

- Minor & Patch (penambahan kolom opsional atau optimasi performa) dirilis tanpa mengganggu konsumen.

- Jika terjadi perubahan fatal (MAJOR bump, misal: menghapus kolom atau mengubah format ID), Domain A wajib menyediakan dua port bersamaan (v1 dan v2) selama masa transisi deprecation (umumnya 90 hari). Platform memantau trafik kueri di port v1; ketika trafik v1 sudah nol, barulah port v1 dinonaktifkan dengan aman.

Model Jawaban Arsitek:

Pisahkan kebutuhan kueri menjadi dua:

1. Eksplorasi ad-hoc: Gunakan mesin kueri federasi in-memory seperti Trino/Presto. Trino mendorong kueri (*pushdown predicate*) ke sumber data masing-masing domain dan menggabungkannya di RAM tanpa mengopi data ke penyimpanan terpusat.

2. Kueri frekuensi tinggi yang krusial (seperti Risk 360): Bangun Consumer-Aligned Data Product. Produk ini mengonsumsi port upstream, mematerialisasi hasil join pada jadwal tertentu, dan merilis port output baru dengan kepemilikan tim yang jelas (misal: tim Credit Risk).

Model Jawaban Arsitek:

Menggunakan Federated Computational Governance:

1. Build Gate di CI/CD: Setiap Pull Request discan otomatis dengan Regex untuk mendeteksi apakah ada pola 16 digit NIK polos yang lolos ke view analitik.

2. Dynamic Row-Level Security (RLS): Platform menyediakan template view standar yang otomatis menyamarkan NIK (3201************0004) untuk role konsumen biasa, dan hanya membuka data asli bagi akun bertoken auditor kepatuhan.

3. Audit Trail OpenLineage: Setiap pembacaan data dicatat jejaknya secara kriptografis untuk memenuhi syarat audit Pasal 39 UU PDP dan POJK 35.

Model Jawaban Arsitek:

Data Lakehouse adalah tumpukan teknologi (technology stack), sedangkan Data Mesh adalah model operasi organisasi dan paradigma arsitektur (operating model). Sebuah perusahaan bisa saja membangun Data Lakehouse canggih namun tetap dikelola oleh satu tim data monolitik yang kewalahan. Bahkan, Data Mesh bisa dibangun MENGGUNAKAN teknologi Lakehouse! Di arsitektur kami, PostgreSQL dan Apache Iceberg berfungsi sebagai media penyimpanan (Lakehouse primitives), sementara Data Mesh mengatur bagaimana tim domain mengelola, mengontrak, dan menyajikan data tersebut.

Model Jawaban Arsitek:

Melalui tiga pendekatan:

1. Insentif & Alokasi Anggaran: Tim domain yang data product-nya banyak dipakai oleh departemen lain mendapat alokasi anggaran atau kredit internal perusahaan (*internal chargeback*).

2. Penyertaan ke OKR Direksi: Ketersediaan dan kualitas data product dimasukkan ke dalam Key Performance Indicator (KPI) triwulanan para manajer divisi.

3. Platform Mandiri yang Sangat Mudah: Tim platform pusat menyediakan template repositori sekali klik sehingga tim domain bisa merilis data product berstandar kontrak hanya dalam waktu 30 menit.

Model Jawaban Arsitek:

Tiga benteng pertahanan:

1. Katalog Data Pusat Wajib: Data yang tidak didaftarkan spesifikasi kontraknya di katalog pusat dilarang dialirkan melalui jaringan data perusahaan.

2. Dewan Tata Kelola Terfederasi (Federated Council): Pertemuan dwimingguan perwakilan arsitek domain untuk menyelaraskan kebutuhan data baru agar tidak terjadi duplikasi pipeline.

3. Protokol Terbuka (ANSI SQL & Iceberg): Melarang tim domain menggunakan format biner tertutup (*proprietary*) yang tidak bisa diakses sistem lain.

Model Jawaban Arsitek:

Pipeline kami di GitHub Actions menjalankan 4 tahapan berurutan:

1. *Linter Sintaks ODCS*: Memvalidasi struktur file YAML terhadap JSON Schema standar industri.

2. *Pemeriksa Kompatibilitas Git*: Membandingkan skema baru dengan skema produksi di registry Git untuk menangkap kolom yang terhapus atau berubah tipe.

3. *Deployment Container Ephemeral*: Menyalakan kontainer PostgreSQL uji coba di Docker dan memasukkan data tiruan (*fixture*).

4. *Uji Great Expectations & Scanner PII*: Memverifikasi keunikan primary key, rentang nilai wajar, dan memastikan 0 kebocoran NIK 16 digit. Jika ada 1 tes gagal, merge otomatis dibatalkan.

Model Jawaban Arsitek:

Tim platform memperlakukan developer domain sebagai pelanggan utama mereka. Platform menyediakan:

- Template repositori Cookiecutter/Helm siap pakai lengkap dengan skrip CI/CD.

- Manajemen hak akses otomatis yang menerjemahkan kontrak ODCS menjadi perintah SQL GRANT di database.

- Dasbor pemantauan otomatis (Grafana) untuk melihat SLA keterlambatan data dan beban kueri tanpa perlu diprogram manual oleh developer domain.

Model Jawaban Arsitek:

Melalui 3 metrik terukur:

1. *Kecepatan Bisnis (Lead Time)*: Penurunan waktu tunggu penyediaan data lintas domain dari 3–6 minggu menjadi <15 menit.

2. *Efisiensi Finansial (TCO Infrastruktur)*: Penurunan biaya sewa komputasi cloud sebesar 35.9% ($66,000/tahun) berkat penghapusan pipeline ETL duplikat.

3. *Skor Kebugaran DATSIS Triwulanan*: Menilai Discoverability, Addressability, Trustworthiness, Self-description, Interoperability, dan Security pada skala 1–5. Produk dengan skor di bawah 3.5 wajib masuk ke backlog perbaikan arsitektur.