Belajar Enterprise Architect - Architecture Governance

#Pendahuluan

Setelah di episode 8 kalian menyusun EA roadmap dengan strategic themes, gap analysis, dan transition states, muncul pertanyaan praktis: siapa yang menjaga ratusan keputusan harian tetap di jalur itu? Jawabannya adalah architecture governance — dan ini juga jawaban atas janji di episode 2: keputusan framework kalian kini diturunkan menjadi desain governance konkret.

Governance adalah tempat reputasi EA ditentukan. Dilakukan buruk, ia menjadi forum tanda tangan yang dihindari semua tim dan dilewati diam-diam. Dilakukan baik, ia adalah layanan percepatan: tim dapat jawaban cepat, standar yang jelas, dan paved road yang enak. Perbedaannya bukan pada keberadaan aturan, melainkan pada desain mekanismenya — itulah materi episode ini.

#Prinsip Arsitektur: Konstitusi Organisasi

Fondasi governance adalah prinsip arsitektur — pernyataan kebijakan tingkat tinggi yang memandu keputusan saat trade-off muncul. Kalian sudah membuat contohnya sendiri: prinsip data D-01..D-04 di episode 5. Struktur prinsip yang baik:

Nama     : API-first Integration
Pernyataan: Akses data antar aplikasi WAJIB via API/event kontrak;
            akses database langsung lintas sistem dilarang.
Rasional : Kopling longgar, evolusi sistem independen,
             audit trail tunggal (mendukung theme #1 & regulasi).
Implikasi : Setiap sistem expose contract versioned;
             gateway & schema registry disediakan platform team.
Konflik  : Prioritas di atas performa point-to-point ad-hoc.

Jumlah ideal: 8-15 prinsip. Kurang dari itu berarti kalian belum berpikir; lebih dari itu berarti kalian menulis kebijakan operasional, bukan prinsip. Setiap prinsip harus punya rasional dan implikasi — prinsip tanpa rasional akan dilanggar pada tekanan deadline pertama, karena tidak ada argumen yang bisa dikutip saat konflik.

#Architecture Review Board: Desain yang Efektif

ARB (Architecture Review Board) adalah forum penilaian keputusan arsitektur signifikan. Desain ARB yang gagal vs berhasil sering hanya berbeda di beberapa parameter:

Definisi "signifikan" harus tertulis eksplisit agar tim tidak menebak-nebak: menyentuh data master, integrasi baru lintas unit, teknologi di luar tier list, biaya infrastruktur di atas ambang, dan semua exception. Sisanya adalah otoritas tim produk sendiri — dan ARB yang bijak justru menyatakan itu keras-keras, karena scope yang terlalu luas adalah cara tercepat membunuh legitimasi forum.

Alur intake yang ringkas:

Perhatikan bahwa mayoritas proposal idealnya tidak pernah sampai ke rapat: pre-check asinkron menyelesaikan yang standar, rapat hanya untuk yang benar-benar kontroversial. ARB yang setiap minggu mengadili dua puluh proposal adalah gejala standarnya buruk atau scopenya bocor.

#Policy dan Pengegakannya

Di bawah prinsip ada policy — aturan operasional yang bisa diuji: "semua workload produksi wajib logging terstruktur", "data personal tidak keluar region X". Kekuatan governance modern datang dari otomasi: sebanyak mungkin policy ditegakkan oleh mesin, bukan oleh rapat. Pola umumnya berjenjang:

• Guardrail otomatis — policy-as-code di pipeline dan landing zone: tagging wajib, enkripsi default, blokir bucket publik. Pelanggaran gagal sebelum deploy; tidak ada drama.
• Review manusia — untuk keputusan yang butuh konteks: arsitektur integrasi, pilihan teknologi non-tier.
• Audit berkala — untuk hal yang tak bisa otomatis: drift konfigurasi, akses orphan.

Semakin banyak yang berpindah dari lapis kedua ke lapis pertama, semakin cepat organisasi bergerak dengan kontrol yang sama. Inilah makna governance-by-design, dan fondasinya (landing zone, tier standards) sudah kalian bangun di episode 7.

#Exception: Katup Pengaman yang Terkontrol

Tidak ada governance yang waras tanpa jalur exception — realita operasional menuntut kompromi sesekali. Yang membedakan governance matang adalah exception-nya terdokumentasi, berbatas waktu, dan terhitung risikonya:

ID        : EXC-2026-014
Proposal  : KirimKu akses DB wallet BayarKu langsung utk rekonsiliasi
Justifikasi: API settlement belum ready, deadline regulator 30 hari
Risiko    : kopling skema; mitigasi: read-only view, no schema change
Expiry    : 90 hari - auto-revoke; renewal butuh ARB penuh
Follow-up : API settlement masuk wave 1 roadmap (owner: platform)

Metrik kesehatan governance yang layak dipantau: waktu rata-rata keputusan (target di bawah 5 hari), jumlah exception aktif dan expired, persentase keputusan yang revisinya minor. Angka-angka ini masuk dashboard EA di episode 25.

#Praktik: Governance Framework Bumi Niaga

Kerjakan di ea-lab/templates/ dan ea-lab/case-study/governance/:

1. Daftar prinsip — rumuskan 10 prinsip enterprise Bumi Niaga (mulai dari D-01..D-04 kalian, tambah domain integrasi, security, cloud, build-vs-buy), masing-masing dengan rasional dan implikasi.
2. ARB charter — satu halaman: scope signifikan eksplisit, komposisi, frekuensi, SLA, bentuk keputusan.
3. Intake form + flow — buat template isian 10 field maksimal dan diagram alur sesuai mermaid di atas.
4. Simulasi — uji framework dengan dua kasus: proposal notifikasi service terpusat (harus approve cepat via standar) dan permintaan exception DB langsung ala EXC-2026-014 (harus lewat exception record).

Framework ini akan kita rawat dan ukur sepanjang sisa series — termasuk penilaian ulang saat organisasi berubah agile di episode 22 dan maturity assessment di episode 25.

#Penutup

Inti yang harus dibawa pulang:

• Governance berdiri di atas prinsip (konstitusi 8-15 pernyataan dengan rasional eksplisit), policy yang bisa diuji, dan forum keputusan untuk yang ambigu.
• ARB sehat punya scope signifikan yang tertulis, SLA keputusan, komposisi lintas fungsi — dan mendesain mayoritas proposal agar tak pernah sampai ke rapat.
• Pengegakan berpindah dari manusia ke mesin: guardrail otomatis di pipeline dan landing zone adalah bentuk governance paling murah dan paling patuh.
• Exception bukan musuh — yang berbahaya adalah exception diam-diam; catat, batasi waktu, mitiga risiko, dan hitung jumlahnya sebagai metrik.

Mesin pengawal sudah jalan. Di episode 10 selanjutnya kita bangun rumahnya: EA repository dan dokumentasi — struktur repository yang hidup di Archi dan ea-lab kalian, disiplin dokumentasi minimalis, serta kapan dan mengapa organisasi butuh tool EA komersial seperti LeanIX. Sampai jumpa di episode 10!