Belajar Enterprise Architect - Technology Architecture

#Pendahuluan

Setelah di episode 6 portofolio aplikasi Bumi Niaga mendapat disposisi TIME dan roadmap rasionalisasi, kita tiba di domain dasar yang menopang semuanya: technology architecture. Ini domain favorit engineer — dan justru karena itu penuh jebakan bias: mudah sekali memulai dari teknologi lalu mencari masalah yang cocok, persis kebalikan arah dependensi yang kita sepakati di episode 3.

Tiga isu konkret menunggu jawaban di Bumi Niaga: landscape tercecer di AWS (BelanjaKu), GCP (KirimKu), dan on-premise (BayarKu); identitas terpisah tiga tempat; dan tidak ada konektivitas antar-lini. Episode ini membahas cara EA bekerja di domain teknologi: strategy sebelum tools, standards yang hidup, dan roadmap yang mengelola usia teknologi.

#Strategi Infrastruktur: Pilihan-Pilihan Besar

Technology architecture di level EA bukan soal memilih instance type — melainkan beberapa keputusan struktural yang menentukan fleksibilitas dan biaya bertahun-tahun:

#Topology Cloud: Satu, Multi, atau Hybrid

Pembeda pentingnya: multi-cloud by design vs by accident. Yang pertama punya justifikasi eksplisit per workload; yang kedua lahir dari keputusan lokal anak perusahaan dan membayar dua kali untuk segalanya. Diagnosis Bumi Niaga: multi-cloud by accident. Namun jawabannya belum tentu migrasi massal — biaya re-platforming tiga landscape harus dibandingkan manfaatnya. Rekomendasi pragmatis yang akan kita olah di praktik: tetapkan cloud primer per workload category, bukan perusahaan; samakan identity layer; bangun konektivitas antar-cloud; dan evaluasi konsolidasi saat momen natural (renewal, refresh, migrasi aplikasi bertanda Migrate).

#Landing Zone dan Fondasi Bersama

Apa pun cloudbuya, fondasi yang distandardisasi adalah nilai EA paling nyata di domain ini: landing zone — blueprint akun/proyek, network topology, IAM baseline, logging, tagging, dan guardrail keamanan yang otomatis dipakai setiap workload baru. Manfaatnya terukur: workload baru naik dalam hari dengan kontrol bawaan, bukan bulan dengan audit menyusul.

Untuk identitas terpisah tiga tempat, arah standarnya jelas: satu identity provider enterprise (SSO + SCIM provisioning) yang difederasikan ke semua cloud dan aplikasi SaaS. Ini prasyarat zero trust yang kita bahas di episode 14, dan fondasi akses yang diaudit untuk BayarKu.

#On-Premise BayarKu: Tetap atau Pindah?

Regulasi membuat sebagian data transaksi fintech sulit keluar dari fasilitas milik sendiri. Posisi EA yang sehat bukan "cloud bagus, pindahkan" melainkan klasifikasi: workload mana yang regulasinya mengizinkan region/cloud lokal, mana yang harus on-premise, dan apakah model colocation/private cloud memenuhi syarat regulator dengan biaya lebih efisien. Keputusan ini selalu diambil bersama compliance — dan kita peruncing lagi di episode 19.

#Technology Standards: Pagarnya Inovasi

Standar teknologi adalah daftar pilihan yang sudah disepakati agar ratusan keputusan harian tidak dilakukan berulang-ulang. Bentuk yang saya rekomendasikan adalah tiered list:

TIER 1 - STRATEGIC (default, self-service, didukung penuh)
  compute    : containerized services di Kubernetes managed
  data store : PostgreSQL managed, object storage
  messaging  : Kafka-compatible event streaming
  identity   : enterprise IdP (SSO wajib)
TIER 2 - APPROVED (boleh dengan justifikasi singkat)
  cache      : Redis; search: Elasticsearch/OpenSearch
TIER 3 - DEPRECATED (tidak boleh workload baru)
  Java 8 runtime; database Oracle baru; bare-metal ad-hoc
EXCEPTIONS : via ARB (episode 9), expiry date wajib

Tiga hal yang membuat standards ditaati: (1) tier strategic benar-benar enak dipakai — templated, termonitor, cepat; (2) jalur exception resmi dan cepat, sehingga tidak ada insentif diam-diam; (3) daftar direview rutin — standar basi lebih merusak reputasi daripada tidak ada standar.

#Kelola Obsolescence: Usia adalah Risiko

Setiap teknologi punya umur ekonomi. EA menjadikan penuaan ini terkelola, bukan kejutan: catat end-of-life di portfolio (kolom teknologi & usia dari episode 6), tetapkan ambang alarm (misalnya EOL kurang dari 18 bulan), dan anggarkan migrasinya sebagai program berkala — bukan proyek darurat saat support berhenti. Metrik sederhana yang layak dilaporkan ke CIO: persentase workload di Tier 3, jumlah exception aktif, dan usia median stack utama. Angka-angka ini nanti masuk dashboard value EA di episode 25.

#Konektivitas Antar-Lini: Opsi Jaringan

Prasyarat fisik dari seluruh integrasi logika episode 12 adalah jaringan yang menghubungkan tiga environment. Tiga opsi utama dengan trade-off-nya:

Rekomendasi Bumi Niaga: dedicated interconnect AWS-GCP untuk trafik produksi, site-to-site ke DC BayarKu dengan enkripsi end-to-end, dan routing policy tertulis — termasuk aturan bahwa traffic data teregulasi hanya melalui jalur private yang terdaftar (nanti menjadi bagian privacy zone di episode 19). VPN tetap dipertahankan sebagai jalur cadangan DR, diuji berkala — jalur darurat yang tak pernah dites bukan jalur darurat.

#Praktik: Tech Roadmap Bumi Niaga

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

1. Keputusan topology — satu halaman: klasifikasi workload (commerce, logistics ops, regulated fintech, analytics), cloud primer per kategori, dan posisi on-premise BayarKu; sertakan justifikasi trade-off vs full consolidation.
2. Landing zone blueprint — sketsa struktur akun/proyek untuk AWS dan GCP, IAM federasi ke IdP tunggal, tagging standard, dan logging baseline.
3. Technology standards tiered — isi Tier 1/2/3 lengkap dengan konteks ketiga lini; tambahkan jalur exception dengan expiry.
4. Tech roadmap — tiga wave: (a) identity federation + interconnect antar-cloud, (b) landing zone + migration of flagged apps dari episode 6, (c) obsolescence batch pertama; tandai dependensi silang ke roadmap aplikasi.

#Kesalahan Umum Technology Architecture

Dua jebakan klasik domain ini: keputusan topology diambil per tim tanpa peta grup (lahirlah multi-cloud by accident yang kalian diagnosis), dan standards ditulis lalu tak pernah direview sampai isinya melarang teknologi yang sudah punah — standar basi merusak kredibilitas semua standar lain.

• Standar yang tak pernah direview — daftar tier yang melarang teknologi sudah punah lebih merusak kredibilitas daripada tidak ada standar; review semesteran wajib.
• Landing zone sebagai proyek sekali-jadi — fondasi dibangun lalu ditinggal; tanpa pemilik dan roadmap, guardrailnya perlahan dilangkahi oleh kebutuhan mendesak.

Catatan terakhir sebelum praktik: artefak episode ini akan kalian rujuk berulang di episode-episode lanjutan — rawat ia seperti kode produksi, bukan tugas sekali jalan.

#Penutup

Inti yang harus dibawa pulang:

• Technology architecture dimulai dari keputusan struktural — topology cloud, landing zone, identitas — bukan pemilihan produk; diagnosis "multi-cloud by accident" berbeda obatnya dengan "multi-cloud by design".
• Standards bertingkat yang hidup menghemat ribuan keputusan kecil; syaratnya: tier strategic yang enak dipakai, exception yang resmi dan berbatas waktu, review rutin.
• On-premise BayarKu adalah keputusan regulasi-plus-biaya yang diambil bersama compliance, bukan dogma cloud-first.
• Obsolescence dikelola sebagai metrik dan anggaran berkala — bukan kejadian darurat.

Empat domain arsitektur kini punya baseline: business (ep 4), data (ep 5), application (ep 6), technology (hari ini). Di episode 8 selanjutnya kita menyatukannya: menerjemahkan strategi bisnis menjadi IT strategy dan roadmap enterprise — teknik menyusun strategic themes, transition states, dan roadmap EA yang meyakinkan dewan direksi. Sampai jumpa di episode 8!