Belajar Enterprise Architect - Business Architecture

#Pendahuluan

Setelah di episode 3 kalian memetakan empat domain arsitektur dan melihat arah dependensinya — bisnis menentukan data, aplikasi, dan teknologi — saatnya menyelam ke domain paling atas: business architecture. Ini titik nol seluruh analisis EA; tanpa jawaban atas pertanyaan "bisnis apa yang kita jalankan dan bagaimana kita ingin beroperasi", keputusan aplikasi dan teknologi tidak punya dasar penilaian yang objektif.

Mengapa episode ini krusial? Karena mayoritas landscape TI yang berantakan tidak lahir dari teknologi yang salah, melainkan dari keputusan business architecture yang tidak pernah diambil secara eksplisit. Tiga definisi "pelanggan" yang kalian temukan di Bumi Niaga bukan bug database — itu gejala pertanyaan yang belum terjawab: apakah grup ini ingin beroperasi secara terpadu atau otonom. Alat untuk menjawabnya kita bangun hari ini.

#Kapabilitas: Satuan Bahasa Bisnis

Kapabilitas adalah kemampuan organisasi melakukan sesuatu yang bernilai — misalnya "Pricing", "Order Management", "Fraud Detection". Tiga sifat yang membuat kapabilitas menjadi satuan ideal komunikasi EA:

• Stabil — kapabilitas bertahan puluhan tahun meski sistem dan proses berganti; "Fulfillment" tetap relevan meski gudang otomasi penuh.
• Independen dari solusi — kapabilitas menjawab what, bukan how; begitu kalian menyebut nama sistem di dalamnya, itu bukan lagi kapabilitas.
• Reusable lintas lini — satu kapabilitas "Customer Management" dipakai ketiga lini Bumi Niaga, sehingga menjadi titik diskusi investasi bersama.

Uji cepat penamaan yang baik: frasa nomina, bisa dilengkapi kata "kemampuan untuk", dan tidak mengandung nama teknologi. "Manajemen Stok" lolos; "Sistem WMS" gagal.

#Capability Map Level 1-3

Capability map disusun bertingkat. Kunci kedalaman: cukup sedalam keputusan yang perlu dibuat, tidak lebih.

Aturan praktis yang saya pakai: seluruh grup dipetakan L1-L2 penuh, lalu L3 hanya untuk area yang sedang jadi subjek keputusan besar. Untuk program unifikasi data Bumi Niaga, L3 dibuka di Customer Management saja — bukan di seluruh peta. Peta yang seragam dalam-nya adalah pemborosan.

L1 Customer Management
├── L2 Customer Profile          # profil pelanggan lintas lini
│   ├── L3 Identity Resolution   # menyatukan identitas antar sistem  <-- fokus program
│   └── L3 Preference Management
├── L2 Loyalty & Engagement      # poin, promo personal
└── L2 Consent Management        # persetujuan penggunaan data (regulasi!)

Perhatikan baris terakhir: consent management sering luput karena terdengar legal, padahal ia kapabilitas bisnis yang menentukan desain platform data — kita akan menyentuhnya lagi di episode 5 dan 19.

#Jebakan Umum Saat Membangun Capability Map

• Memodelkan proses, bukan kapabilitas — "Terima Pesanan Malam Hari" adalah langkah proses; kapabilitasnya "Order Capture". Proses berubah cepat, kapabilitas stabil.
• Mencampur level — L1 "Finance" bersebelahan dengan L2 "Invoice Matching" pada satu kolom peta; rapikan hierarki sebelum analisis apa pun.
• Chasing MECE sempurna — dua kapabilitas boleh tumpang tindih sedikit; perdebatan tak berujung soal batas kapabilitas adalah biaya tanpa nilai.

#Value Stream: Alur Nilai bagi Pemangku Kepentingan

Jika capability map menjawab apa yang bisa dilakukan organisasi, value stream menjawab bagaimana nilai tercipta bagi peluang stakeholder — rangkaian tahapan end-to-end dari perspektif pelanggan, bukan departemen. Bedanya dengan proses bisnis: value stream berpusat pada stakeholder dan tingkatannya tinggi (5-8 tahap), proses berpusat pada aktivitas operasional dan detail.

Value stream BelanjaKu untuk perjalanan belanja online:

Nilai analisisnya muncul saat tiap tahap dipotong silang dengan dua hal: momen friksi pelanggan dan kapabilitas yang menopangnya.

Satu tabel semacam ini sudah cukup untuk rapat investasi: gap "Delivery Tracking" menjelaskan mengapa KirimKu butuh event tracking terpadu — argumen yang jauh lebih kuat daripada "teknologi lama". Teknik ini bernama value stream mapping tingkat EA, dan ia jembatan wajib antara bahasa bisnis dan backlog teknologi.

#Operating Model: Keputusan Paling Mahal di Business Architecture

Operating model (kerangka Ross, Weill, dan Robertson dari MIT CISR) adalah keputusan tentang dua sumbu: seberapa jauh proses distandardisasi dan seberapa jauh data diintegrasikan lintas unit bisnis. Persilangannya menghasilkan empat pola:

Keputusan ini mahal karena ia menentukan segalanya di hilirnya: apakah identitas pelanggan harus satu (integrasi data tinggi), apakah ketiga lini harus pakai CRM yang sama (standardisasi tinggi), dan seberapa besar mandat tim EA pusat. Salah membaca pola berarti dua-duanya: investasi integrasi yang sia-sia untuk grup diversification, atau silo yang menyakitkan untuk grup coordination.

Untuk PT Bumi Niaga, analisisnya begini: ketiga lini berbagi pelanggan yang sama (orang yang belanja di BelanjaKu membayar dengan BayarKu dan dikirim KirimKu), tetapi karakter operasionalnya sangat berbeda — ritel musiman, logistik berbasis rute, fintech teregulasi. Standardisasi proses penuh akan membunuh kekhasan tiap lini, tetapi tanpa integrasi data, potensi cross-sell dan satu pandangan pelanggan mustahil. Jawabannya: Coordination — proses otonom per lini, data inti terpadu.

Keputusan seperti ini dicatat sebagai ADR tingkat enterprise:

# ADR-EA-001: Operating Model PT Bumi Niaga
 
Status   : Accepted (2026-08)
Konteks  : 3 lini berbagi pelanggan, karakter operasional berbeda,
           40 aplikasi duplikatif, 3 definisi pelanggan
Keputusan: COORDINATION - proses otonom per lini,
           data pelanggan & produk terpadu di tingkat grup
Implikasi:
- MDM pelanggan wajib ada (episode 5)
- CRM boleh berbeda per lini, API kontrak wajib seragam (episode 12)
- Mandat EA: standar data & integrasi; proses bisnis milik lini
Review   : ulangi analisis saat akuisisi baru (episode 23)

#Praktik: Capability Map dan Keputusan Operating Model Bumi Niaga

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

1. Capability map L1-L2 seluruh grup — targetkan 25-35 L2 mencakup ketiga lini plus kapabilitas korporat (Finance, HR, Risk & Compliance). Workshop imajiner: daftar kapabilitas dari deskripsi tiap lini di episode 0.
2. Drill-down L3 — buka L3 hanya di Customer Management, karena sanjungannya ke program unifikasi data.
3. Value stream mapping — lengkapi tabel tahap/friksi/kapabilitas untuk BelanjaKu, lalu ringkas versi KirimKu (Book → Pickup → Transit → Deliver → Settle).
4. ADR operating model — isi template di atas; tulis justifikasi kenapa bukan Unification maupun Diversification, dan daftar implikasinya ke domain lain.

Simpan baik-baik. ADR-001 ini akan dirujuk hampir setiap episode ke depan — mulai dari episode berikutnya, saat keputusan "data pelanggan terpadu" kita turunkan menjadi rancangan data architecture konkret.

#Penutup

Inti yang harus dibawa pulang:

• Business architecture berdiri di atas tiga artefak: capability map (apa yang bisa dilakukan), value stream (bagaimana nilai tercipta), dan operating model (bagaimana unit-unit ingin beroperasi bersama).
• Kapabilitas adalah satuan bahasa yang stabil dan bebas teknologi; peta cukup sedalam kebutuhan keputusan — L1-L2 penuh, L3 selektif.
• Value stream menghubungkan friksi pelanggan dengan gap kapabilitas — bahan argumen investasi terkuat di hadapan manajemen.
• Operating model adalah keputusan termahal: untuk Bumi Niaga kita memilih Coordination — proses otonom, data inti terpadu — dan menaikannya menjadi ADR-EA-001.

Di episode 5 selanjutnya kita masuk domain data: merancang enterprise data model, menyelesaikan tiga definisi "pelanggan" lewat master data management, menyusun data governance, dan memilih bentuk data platform yang menopang keputusan Coordination tadi. Sampai jumpa di episode 5!