Belajar System Analyst - Enterprise Architecture Awareness

#Pendahuluan

Setelah di episode 22 kalian mampu menganalisis sistem berbasis AI/LLM, kita naik satu tingkat pemandangan. Selama ini kita mengerjakan TokoKita pada skala sistem: POS, program member, asisten stok. Namun organisasi adalah kumpulan puluhan sistem yang saling hidup — dan di sinilah konsep enterprise architecture (EA) masuk. Episode ini membahas kesadaran EA yang dibutuhkan analyst: kerangka TOGAF, empat domain arsitektur, dan praktik pemetaan kapabilitas.

Mengapa analyst perlu peduli EA? Karena kegagalan proyek sering bukan karena desain sistemnya buruk, melainkan karena desain itu berbenturan dengan arah organisasi: aplikasi baru menduplikasi fungsi yang sudah dimiliki sistem lain, menyimpan data yang sudah punya sumber kebenaran resmi, atau memakai teknologi yang dilarang kebijakan TI. Analis yang sadar-EA menangkap benturan itu saat desain — murah; analis yang tidak akan menemukannya saat integrasi atau audit — mahal. Analogi mudahnya: SA merancang sebuah rumah; EA menjaga agar kota tetap layak huni — jaringan air, zonasi, kode bangunan. Rumah terbaik pun tak berguna kalau dibangun menutup jalur pipa utama.

#Apa Itu Enterprise Architecture

EA adalah disiplin yang memandang organisasi secara utuh dalam empat lapisan beserta aturan evolusinya:

1. Business architecture — kapabilitas bisnis, proses, organisasi: apa yang dilakukan perusahaan.
2. Data architecture — entitas data penting dan sumber kebenarannya: data apa yang dimiliki dan siapa yang berhak mengelola.
3. Application architecture — aplikasi/perangkat lunak dan interaksinya: sistem apa yang melayani proses.
4. Technology architecture — infrastruktur: server, cloud, jaringan, platform: dijalankan di mana dan bagaimana.

Beserta lapisan-lapisan itu, EA menghasilkan dua artefak yang paling relevan bagi kalian:

• Prinsip arsitektur — aturan main lintas proyek, contoh: buy before build, single source of truth, cloud-first, security by default. Proyek boleh mengajukan pengecualian, tetapi harus sadar dan terdokumentasi.
• Roadmap transformasi — urutan prioritas perubahan beberapa tahun ke depan. Proyek yang sejalan roadmap lebih mudah mendapat sponsor; yang melawannya harus punya alasan sangat kuat.

#TOGAF dalam Satu Halaman

TOGAF (The Open Group Architecture Framework) adalah kerangka EA paling banyak dipakai di industri. Intinya bukan teori rumit, melainkan siklus kerja bernama ADM (Architecture Development Method):

Siklus itu membaca seperti daftar tugas yang sudah sering kalian kerjakan: fase Visi ≈ BRD ringkas; fase Bisnis ≈ process modeling episode 8; fase Sistem Informasi ≈ ERD episode 9 dan SDD episode 7; fase Migrasi ≈ modernization roadmap episode 16; fase Tata Kelola ≈ UAT dan change management episode 14-15. Artinya: analisis kalian sudah bekerja di dalam ADM — kesadaran EA hanya membuat posisinya eksplisit, sehingga artefak yang kalian hasilkan bisa dipakai ulang oleh arsitek tanpa penerjemahan ulang.

Kalian tidak perlu bersertifikat TOGAF untuk menjadi analyst yang baik. Yang dibutuhkan adalah awareness: tahu di fase mana pekerjaanmu berada, prinsip apa yang mengikatmu, dan keputusan mana yang harus dieskalasi.

#Prinsip EA dalam Praktik Sehari-hari

Empat prinsip umum dan implikasinya pada pekerjaan analisis TokoKita:

Pola penggunaannya saat analisis: ketika kalian hendak menambah tabel, endpoint, atau aplikasi baru, berhenti sebentar dan tanyakan "adakah yang sudah memiliki ini?" Pertanyaan lima detik itu mencegah duplikasi yang biayanya dirasakan bertahun-tahun — persis logika gap analysis episode 16, tapi diterapkan sebelum membangun, bukan sesudah.

#Praktik: Peta Kapabilitas TokoKita

Artefak EA yang paling berguna untuk analyst level awal adalah capability map versi ringkas: daftar kapabilitas bisnis, sistem yang mendukungnya, dan statusnya. Hasil untuk TokoKita:

Dari tujuh baris itu lahir insight yang langsung mempengaruhi backlog: pembelian masih rapuh (peluang), laporan terfragmentasi (risiko — beberapa tim membuat angka sendiri, melanggar single source of truth), dan layanan pelanggan belum terstruktur. Peta ini juga tempat fitur-fitur yang kita bangun ditempatkan pada konteksnya: asisten stok dari episode 22 adalah penyempurna kapabilitas manajemen stok — bukan sistem baru — sehingga wajar ia membaca dari sumber data yang sama dengan POS.

# Peta Kapabilitas TokoKita v1.0
 
## Kapabilitas x Sistem
(lihat tabel 7 kapabilitas; sumber: wawancara pemilik,
observasi cabang, review langganan SaaS aktif)
 
## Prinsip yang diadopsi
EA-01 buy-before-build   -> semua kebutuhan non-inti
                            mulai dari pasar SaaS
EA-02 single source      -> stok: DB POS; pelanggan:
                            modul member; keuangan:
                            SaaS akuntansi
EA-03 security-by-default-> warisan SEC-01..SEC-10
 
## Gap & risiko utama
G-01 pembelian belum terdigitalisasi (peluang)
G-02 laporan ganda sumber (risiko keputusan)
G-03 kanal CS personal (risiko kontinuitas)
 
## Aturan pakai
Tiap proposal fitur baru wajib menyebut kapabilitas
yang disentuh + prinsip yang relevan -> review bulanan.

Bagian "Aturan pakai" adalah cara kecil membuat kesadaran EA bertahan melewati hype mingguan: setiap ide fitur harus menyebut kapabilitas mana yang disentuh — sehingga diskusi langsung berada pada konteks organisasi, bukan hanya fitur.

#Kesalahan Umum

1. Menganggap EA urusan arsitek senior saja — keputusan analyst harian (tabel baru, integrasi baru, alat baru) adalah keputusan arsitektur organisasi versi mini. Menyerahkannya semua ke orang lain sama dengan melepas kendali mutu desain.
2. Menyalin prinsip enterprise besar ke warung — TOGAF penuh untuk bank dengan ratusan sistem; TokoKita cukup satu halaman peta. Sesuaikan bobot kerangka dengan ukuran organisasi — formalitas berlebihan membunuh nilai yang ingin dijaga.
3. Membangun salinan data demi kemudahan — "biar cepat, kita tarik salinan stok ke aplikasi baru" melahirkan dua kebenaran yang berbeda diam-diam. Jika salinan tak terhindarkan, requirement wajib memuat strategi sinkronisasi dan kedaluwarsa.
4. Proyek bayangan tanpa jejak EA — aplikasi dipakai sebagian karyawan tanpa melewati review apa pun; suatu hari ia memegang data kritis yang tak ada backupnya. Peta kapabilitas membuat keberadaan sistem-sistem seperti ini terlihat.
5. Prinsip sebagai dogma — buy-before-build bukan larangan membangun; inti diferensiasi bisnis (logika loyalty program misalnya) justru layak dibangun sendiri. Prinsip adalah default yang bisa dikecualikan dengan alasan tertulis, bukan tembok.

#Penutup

Inti yang harus dibawa pulang:

• EA memandang organisasi lewat empat lapisan — bisnis, data, aplikasi, teknologi — plus prinsip dan roadmap yang mengikat semua proyek.
• TOGAF ADM adalah siklus yang fase-fasenya sudah kalian kerjakan dalam bentuk artefak analisis; kesadaran EA membuat posisi dan kontribusi kalian eksplisit.
• Prinsip-prinsip (single source of truth, buy before build, security by default) dipakai sebagai pertanyaan cepat di setiap keputusan desain.
• Capability map TokoKita memunculkan gap nyata (pembelian rapuh, laporan ganda) dan menjadi konteks resmi bagi setiap proposal fitur baru.

Peta organisasi kalian sudah ada — sekarang kita pastikan keputusan di atasnya diambil dengan bukti, bukan selera. Di episode 24 selanjutnya kita membahas data-driven decision analysis: merancang KPI dan metrik yang benar-benar merepresentasikan tujuan bisnis, membangun framework pengukuran untuk TokoKita, dan membaca data tanpa terjebak statistik palsu. Pastikan tetap semangat!