Belajar Enterprise Architect - Regulatory Architecture

#Pendahuluan

Setelah di episode 18 kalian merumuskan security strategy dengan maturity assessment dan risk appetite, episode ini menyelam ke cabang yang paling tidak bisa dinegosiasikan: regulatory architecture — disiplin menerjemahkan regulasi menjadi struktur dan kontrol arsitektural.

Untuk Bumi Niaga ini bukan topik hipotetis: BayarKu hidup di bawah pengawasan regulator fintech, seluruh grup memproses data pribadi jutaan pelanggan di bawah UU PDP Indonesia, dan rencana ekspansi lintas negara membawa sentuhan GDPR Eropa. Regulasi yang diperlakukan sebagai proyek compliance tahunan akan terus mahal; diperlakukan sebagai properti arsitektur, ia menjadi biaya operasional yang wajar dan dapat dibuktikan kapan pun.

#Memetakan Landscape Regulasi

Langkah pertama: inventarisasi obligasi per yurisdiksi dan domain. Format peta yang saya pakai — regulasi x lingkup x obligasi inti x sanksi:

Peta ini bukan dokumen legal — itu ranah hukum. Nilai tambah EA adalah kolom yang sering tak ada di dokumen lawyer: implikasi arsitektural tiap obligasi. Notifikasi breach 3x24 jam bermakna: logging sentral + deteksi anomali harus eksis (episode 14). Right to erasure bermakna: data master terpusat membuat penghapusan satu perintah; data tercecer di 40 aplikasi membuatnya mustahil — keputusan MDM episode 5 ternyata juga keputusan compliance.

#Data Protection by Design

Inti regulatory architecture untuk data pribadi adalah menanamkan prinsip perlindungan sejak desain. Terjemahan praktisnya dalam artefak yang sudah kalian bangun:

• Klasifikasi data (episode 14) menjadi bahasa bersama: field regulasi ditandai, dan setiap konsumsi data baru wajib menyatakan klasifikasinya.
• Consent management sebagai kapabilitas (episode 4 sudah menandainya): layanan pusat mencatat tujuan pemakaian per subjek; event consent.changed di backbone (episode 12) menyebarkan statusnya real-time.
• Minimisasi & purpose limitation: pipeline analitik memakai pseudonymisasi; environment nonprod tanpa data produksi mentah; tiap konsumen event menyatakan basis legalnya di registry kontrak.
• Residency & transfer: data KYC tetap on-premise (episode 13); agregat keluar hanya lewat jalur yang disetujui; ekspansi EU memicu penilaian transfer mechanism sebelum go-live.

Pola arsitektur yang lahir dari daftar ini adalah privacy zone: segmen infrastruktur tempat data teregulasi diproses dengan kontrol ketat, egress terkontrol, dan akses diaudit — generalisasi dari pola hybrid BayarKu.

#Audit Readiness: Dari Panik ke Ekspor

Audit tahunan yang sehat adalah konsekuensi dari dua hal yang sudah kalian bangun: kontrol yang otomatis dan bukti yang tersimpan sendiri. Prinsipnya:

Kontrol                        Bukti otomatis            Frekuensi
Akses data KYC role-based      Log akses -> SIEM alert   Kontinu
Retensi log 1 tahun            Policy storage lifecycle  Otomatis
Segregasi prod/nonprod         Scan config landing zone  Mingguan
Notifikasi breach <3x24 jam    Playbook + tabletop log   Per semester
Right-to-erasure SLA 30 hari   Metrik ticket erasure     Bulanan

Latihan internal tiap semester — mock audit atas satu regulasi acak — menjaga matriks ini hidup dan mendeteksi kontrol busuk sebelum auditor asli melakukannya. Biaya latihan semacam ini trivial dibanding panik tiga bulanan tradisional, dan hasilnya terukur: waktu persiapan audit turun dari bulan ke hari.

#Peran DPO dan Pembagian Kerja dengan Legal

Regulasi perlindungan data menuntut DPO (Data Protection Officer) — dan kebingungan klasik organisasi adalah mengira DPO menggantikan EA dalam urusan data. Kenyataannya keduanya komplementer dengan pembagian yang jelas:

Pola kerja yang sehat: DPO menerjemahkan hukum menjadi requirement; EA menerjemahkan requirement menjadi arsitektur; keduanya bertemu di review kuarteran di atas artefak yang sama — bukan lewat rangkaian email panik saat insiden atau audit mendekat.

#Menangani Perubahan Regulasi

Regulasi bergerak; arsitektur harus punya radar. Proses ringkas yang efektif: legal/compliance meneruskan draft atau perubahan regulasi ke EA; EA melakukan impact assessment arsitektural — entitas data apa tersentuh, sistem mana terdampak (via repository episode 10!), kontrol baru apa dibutuhkan, estimasi effort dan timeline — lalu hasilnya masuk intake roadmap (episode 8). Karena landscape terdokumentasi dengan relasi eksplisit, analisis dampak "aturan baru soal data anak" berhenti menjadi tebakan dan menjadi query.

#Praktik: Regulatory Map Bumi Niaga

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

1. Regulatory map — lengkapi tabel empat regulasi di atas dengan kolom implikasi arsitektural per baris; tambahkan satu regulasi fiktif draft tentang data anak-anak.
2. Privacy zone design — sketsa zona data teregulasi: komponen yang boleh masuk, aturan egress, dan kontrol aksesnya.
3. Matriks bukti audit — 8-10 kontrol utama dengan bukti otomatis dan frekuensinya; tandai dua kontrol yang saat ini tak punya bukti otomatis.
4. Impact assessment drill — tulis analisis dampak 1 halaman untuk draft data-anak: entitas EDM yang tersentuh, sistem terdampak dari portfolio episode 6, dan usulan wave mitigasi.

#Kesalahan Umum Regulatory Architecture

Sebelum praktik, tiga pola gagal yang layak diwaspadai sejak awal:

• Menunggu regulasi final — kontrol yang dirancang dari draft arah pasar hampir selalu bernilai strategis apa pun isi akhirnya; menunggu berarti membangun terburu-buru dengan harga premium.
• Compliance sebagai proyek sekali-jalan — sertifikat diperoleh lalu kontrolnya melapuk tanpa pemeliharaan; tanpa bukti otomatis dan review berkala, audit berikutnya kembali panik seperti sebelumnya.
• Mengcopy checklist industri mentah — obligasi tiap yurisdiksi dan lisensi berbeda; peta kepatuhan harus lahir dari konteks data flow organisasi sendiri, bukan dari template konsultan yang tak menyentuh landscape nyata.
• Memperlakukan DPO sebagai lawan — hubungan EA-DPO yang adversarial menghasilkan dua kebenaran; satu artefak bersama lebih mahal dibangun tapi jauh lebih murah dirawat.

Bila sumber daya terbatas, dua prioritas yang selalu benar: konsolidasi data master lebih dulu — ia memudahkan erasure, consent, dan audit sekaligus — lalu bukti otomatis untuk kontrol yang paling sering diminta regulator.

Simpan seluruh artefak episode ini di folder regulatory repository — saat draft regulasi berikutnya tiba, impact assessment kalian tinggal mengisi templat yang sudah menunjuk entitas dan sistem yang tepat.

#Penutup

Inti yang harus dibawa pulang:

• Regulatory architecture dimulai dari peta obligasi dengan kolom implikasi arsitektural — kolom itulah nilai tambah EA di atas dokumen legal.
• Data protection by design menanamkan regulasi ke artefak yang sudah ada: klasifikasi, consent capability, minimisasi pipeline, dan privacy zone.
• Audit readiness = kontrol otomatis + bukti tersimpan sendiri + mock audit berkala; persiapan audit yang panik adalah gejala kontrol manual.
• Perubahan regulasi dikelola lewat radar dan impact assessment yang memanfaatkan EA repository — landscape terdokumentasi membuat analisis dampak jadi query, bukan tebakan.

Blok security lanjutan tuntas. Di episode 20 kita menutupnya dengan pertanyaan tertua di dunia operasional: apa yang terjadi saat semuanya gagal? Resilience and continuity — business impact analysis, pola DR per tier, dan budaya latihan yang membuat rencana bukan sekadar dokumen. Sampai jumpa di episode 20!