Belajar Enterprise Architect - Sustainability Architecture

#Pendahuluan

Setelah di episode 23 kalian mengelola M&A TransNusa, ada dimensi yang dalam beberapa tahun terakhir berpindah dari halaman CSR ke neraca dan regulasi: sustainability. Episode ini membahas Green IT dan sustainability architecture — bagaimana keputusan arsitektur harian (region cloud, efisiensi workload, lifecycle hardware, arsitektur data) masuk ke akuntansi karbon organisasi.

Mengapa EA harus peduli? Tiga alasan yang naik urgensinya tiap tahun: regulasi pelaporan keberlanjutan menjangkau perusahaan besar termasuk supply chain mereka; investor dan mitra B2B menanyakan jejak karbon sebagai syarat kontrak; dan — yang paling dekat dengan pekerjaan kita — efisiensi energi hampir selalu berjalan searah dengan efisiensi biaya. Workload yang hemat FLOP hemat listrik dan hemat tagihan. Sustainability adalah kasus langka di mana tujuan etis dan bisnis biasanya tidak bertabrakan.

#Akuntansi Karbon Digital: Scope 1-3

Bahasa bersama dunia ini adalah tiga scope emisi standar GHG Protocol:

Perhatikan posisi pentingnya bagi kita: mayoritas jejak digital grup ada di Scope 3 — emisi AWS/GCP adalah emisi kita secara akuntansi, hanya dicatat di kolom mereka. Provider cloud besar sudah melaporkan carbon footprint per customer via dashboard; tugas EA adalah memasukkan angka itu ke cost model (episode 15) sehingga setiap unit melihat dua kolom: biaya rupiah dan biaya karbon. Metrik ganda inilah pintu masuk paling praktis untuk sustainability di arsitektur.

#Keputusan Arsitektur yang Menggerakkan Karbon

Green architecture bukan disiplin baru — ia lensa tambahan pada keputusan yang sudah kalian buat. Daftar tuas dengan dampak terbesar:

• Region & sumber energi — region cloud berbeda intensitas karbonnya drastis (grid hidro/geothermal vs batubara). Untuk workload non-latency-critical seperti batch analitik dan ML training (episode 21), menjadwalkan pekerjaan ke region/jam hijau memangkas emisi tanpa mengubah kode. Latensi tetap menang untuk checkout — trade-off eksplisit per workload.
• Efisiensi software — kode boros = server lebih banyak = karbon lebih banyak. Rightsizing FinOps (episode 15), arsitektur event yang menghindari polling liar (episode 12), dan cache yang benar adalah dekarbonisasi tak langsung yang nyata.
• Data lifecycle — storage "murah" ternyata karbon permanen: log retention tak berujung, replikasi dataset massal lintas cloud (yang sudah kita larang karena egress di episode 13), dan cold data tanpa tiering. Kebijakan retention adalah keputusan hijau.
• Lifecycle hardware on-premise — DC BayarKu: extend life vs refresh efisien, pembelian bekas berkualitas, e-waste via partner tersertifikasi. Keputusan obsolescence roadmap episode 7 kini punya dimensi kedua.
• Arsitektur aplikasi — monolith yang over-provisioned 24/7 vs scale-to-zero untuk layanan idle; edge caching yang mengurangi transfer. Semuanya keputusan yang sudah kalian kenal, dilihat lewat lensa energi.

#Carbon-Aware Design Patterns

Beberapa pola konkret yang bisa langsung ditulis ke standards:

G-01  Batch & training job wajib carbon-aware scheduling:
      prefer region/jam dengan grid rendah karbon.
G-02  Retention maksimal semua storage WAJIB terdefinisi;
      default log produksi 90 hari kecuali regulasi lain.
G-03  Layanan non-kritis wajib support scale-to-zero;
      idle compute >30 hari otomatis masuk report waste.
G-04  Keputusan region baru mencantumkan intensitas karbon
      grid sebagai salah satu kriteria penilaian.
G-05  Laporan bulanan: kgCO2e per unit economics (ep 15)
      selain biaya rupiah - dashboard yang sama, kolom ekstra.

Perhatikan G-05: carbon intensity per unit bisnis — gram CO2e per order, per paket, per transaksi — adalah cara elegan menggabungkan sustainability dengan unit economics yang sudah kalian bangun. Tren menurun saat volume naik = pertumbuhan decoupled dari emisi; itulah kalimat yang dicari dewan direksi dan regulator.

#Studi Kasus Mini: Batch Carbon-Aware di Bumi Niaga

Contoh paling konkret dari aturan G-01: job training model rekomendasi (episode 21) berjalan enam jam per malam. Alih-alih terkunci di satu region, orchestrator memilih region dengan grid paling bersih pada jam eksekusi — legal selama data training direplikasi sesuai kebijakan dan latensi tak relevan untuk batch. Estimasi industri: pengurangan 30-60% emisi batch job tanpa menyentuh kode model, murni lewat penjadwalan.

Perhatikan pola tabelnya: workload latency-sensitive mendapat strategi efisiensi, sisanya mendapat strategi penjadwalan — dua kategori, dua alat, tanpa konflik dengan SLO mana pun.

#Pelaporan dan Governance Hijau

Sustainability report yang serius butuh data yang bisa diaudit — dan di sinilah fondasi series bekerja lagi: tagging infrastruktur (episode 7) memungkinkan atribusi emisi per unit; repository (episode 10) menyimpan keputusan beserta justifikasi karbonnya; ARB checklist (episode 9) menambah satu pertanyaan: "apa dampak energi dari proposal ini?" — cukup estimasi kasar, tapi harus ada jawabannya. Untuk pelaporan formal Scope 3, ambil data resmi dari dashboard sustainability provider cloud dan konsolidasikan di level grup — proses kuarteran ringan, bukan proyek tahunan.

#Praktik: Green Blueprint Bumi Niaga

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

1. Carbon baseline — estimasi profil emisi digital grup: konsumsi cloud ketiga lini (dari cost model episode 15), DC BayarKu, dan device fleet; klasifikasikan ke scope.
2. Aturan G-01..G-06 — lengkapi daftar di atas dengan satu aturan tambahan hasil analisis kalian; format konsisten prinsip episode 9.
3. Region strategy update — revisi keputusan topology episode 13 dengan kolom intensitas karbon; tandai workload mana yang bisa carbon-aware schedule.
4. Dashboard hijau — tambahkan kolom kgCO2e ke unit economics episode 15; tulis narasi direksi 150 kata tentang tren dan dua rencana aksi.

#Quick Wins 90 Hari

Jika organisasi baru mulai, tiga langkah pertama dengan rasio dampak-usaha terbaik: aktifkan dashboard carbon provider cloud dan masukkan angkanya ke laporan bulanan yang sudah ada; tetapkan retention default untuk storage terbesar (biasanya log); dan jadwalkan batch non-kritis ke jam/region grid lebih bersih. Ketiganya tak butuh proyek baru — hanya lensa karbon pada keputusan yang sudah berjalan. Dalam satu kuarter, angka baseline pertama kalian sudah cukup andal untuk memulai percakapan serius dengan finance dan direksi.

Dua batasan yang sebaiknya dilaporkan jujur sejak awal:

• Data karbon provider bersifat estimasi dan tertunda berbulan-bulan — sah untuk tren dan prioritisasi, belum untuk klaim presisi publik
• Pelaporan formal Scope 3 tetap milik tim sustainability dengan metode resmi; EA menyediakan data operasional, bukan menggantikan auditor karbon

Dengan itu, lensa karbon resmi menjadi bagian dari cara Bumi Niaga mengambil keputusan arsitektur — dan kalian punya satu dimensi nilai lagi untuk dibawa ke ruang direksi.

#Penutup

Inti yang harus dibawa pulang:

• Jejak digital mayoritas ada di Scope 3; langkah pertama EA adalah memasukkan angka karbon provider ke cost model sehingga tiap unit melihat rupiah dan CO2e bersamaan.
• Tuas green architecture adalah keputusan yang sudah kalian kelola: region, efisiensi workload, data lifecycle, hardware lifecycle — sustainability adalah lensa tambahan, bukan proyek paralel.
• Carbon-aware patterns (scheduling, retention wajib, scale-to-zero) ditulis sebagai aturan bernomor agar bisa digovernance-kan seperti prinsip lain.
• Laporkan absolut dan intensity per unit sekaligus; hindari gaming metrik, dan biarkan dashboard unit economics membawa cerita decoupling ke direksi.

Tinggal dua episode menuju garis finis. Di episode 25 kita jawab pertanyaan yang akan muncul di rapat anggaran: apa buktinya tim EA bernilai? EA maturity & value measurement — model penilaian kematangan, dashboard metrik nilai, dan siklus perbaikan kontinu yang menilai ulang pilihan framework kalian sendiri dari episode 2. Sampai jumpa di episode 25!