Belajar Enterprise Architect - Architecture Domains
Mengenal empat domain arsitektur enterprise — business, data, application, dan technology — plus security sebagai cross-cutting concern: apa fokus tiap domain, artefak khasnya, bagaimana ketergantungan antar-domain bekerja, dan praktik pertama domain mapping pada studi kasus PT Bumi Niaga
#Pendahuluan
Setelah di episode 2 kalian mengenal TOGAF, Zachman, dan ArchiMate — metode, ontologi, dan notasi kerja EA — episode ini membedah anatomi yang dipetakan oleh semua framework itu: architecture domains. Empat domain klasik — business, data, application, dan technology — adalah cara standar dunia untuk memecah kompleksitas arsitektur organisasi menjadi lapisan yang bisa dikelola.
Mengapa pembagian domain penting? Karena pertanyaan "bagaimana arsitektur perusahaan ini?" terlalu besar untuk dijawab sekaligus. Dengan domain, pertanyaannya menjadi empat pertanyaan yang jawabnya jelas dan berhubungan terstruktur: bisnis apa yang dijalankan, data apa yang dibutuhkan, aplikasi apa yang mengolahnya, dan infrastruktur apa yang menopangnya. Hampir semua artefak EA yang akan kita buat sepanjang series — capability map, blueprint integrasi, tech roadmap — hidup di dalam salah satu domain ini.
#Empat Domain Utama
#Business Architecture
Domain paling atas menjawab apa yang dilakukan organisasi — independen dari sistem apa pun. Isinya: kapabilitas (kemampuan bisnis), value stream, proses, struktur organisasi, dan produk. Artefak khasnya capability map dan business model. Kesalahan klasik pemula adalah melewatkan domain ini dan langsung bicara aplikasi — padahal tanpa business architecture, tidak ada dasar untuk menilai apakah sebuah aplikasi layak ada. Episode 4 membahasnya secara utuh.
#Data and Information Architecture
Menjawab informasi apa yang bernilai bagi organisasi: model data enterprise, entitas master (pelanggan, produk, aset), aliran data antar unit, serta governance-nya — siapa memiliki data, bagaimana mutunya dijaga. Perhatikan kata "information", bukan sekadar database: yang dikelola EA adalah makna dan kepemilikan data, sementara detail tabel adalah ranah data engineer. Episode 5 khusus untuk domain ini.
#Application Architecture
Menjawab aplikasi apa yang dimiliki dan bagaimana mereka berinteraksi: portofolio aplikasi, fungsi masing-masing, integrasi antar aplikasi, dan lifecycle-nya. Output tipikalnya application portfolio map dan integration blueprint. Di banyak organisasi inilah domain paling kacau — puluhan tahun akumulasi aplikasi dengan fungsi tumpang tindih; kita merapikannya di episode 6 dan 12.
#Technology Architecture
Menjawab infrastruktur dan platform apa yang menopang semuanya: compute, network, storage, platform cloud, tooling, plus standar teknologi dan roadmap obsolescence-nya. Ini domain yang paling akrab bagi engineer, tetapi hati-hati bias: teknologi adalah penopang, bukan titik awal. Episode 7 membahasnya.
Tabel ringkas yang layak kalian tempel:
| Domain | Pertanyaan Inti | Artefak Khas | Audiens Utama |
|---|---|---|---|
| Business | Bisnis apa yang dijalankan? | Capability map, value stream | CEO, kepala divisi |
| Data | Informasi apa yang bernilai? | Enterprise data model, data flow | CFO, CDO, data owner |
| Application | Aplikasi apa yang menopang? | Portfolio map, integration view | CIO, head of IT |
| Technology | Infrastruktur apa yang dasar? | Tech standards, platform roadmap | CTO, infra team |
#Security: Cross-Cutting Concern
Framework modern menambahkan security & risk sebagai aspek yang melintasi keempat domain, bukan domain kelima yang berdiri sendiri. Logisnya: keamanan data relevan di domain data, hardening platform relevan di technology, kontrol akses aplikasi relevan di application, dan kepatuhan proses relevan di business. Menempatkan security sebagai silo terpisah adalah anti-pattern klasik yang membuatnya selalu "urusan tim lain". Kita angkat tuntas di episode 14, 18, 19, dan 20.
#Ketergantungan Antar-Domain
Empat domain ini tersusun bertingkat dengan arah dependensi yang konsisten:
Arah panah itulah yang menjelaskan urutan kerja EA yang benar: kebutuhan bisnis menentukan data apa yang penting, data menentukan aplikasi seperti apa, aplikasi menentukan teknologi. Ketika urutan ini terbalik — misalnya divisi membeli platform canggih dulu lalu mencari masalah yang cocok — kalian sedang menyaksikan penyebab paling umum landscape TI yang berantakan.
Namun realitanya bukan waterfall satu arah: iterasi ADM dari episode 2 memutar domain-domain ini bolak-balik. Yang harus dijaga adalah dasar penilaian: setiap keputusan teknologi harus bisa ditelusuri balik sampai ke kebutuhan bisnis. Traceability inilah nilai praktis dari pengaturan domain.
#Praktik: Domain Mapping Bumi Niaga
Sekarang kita isi keempat domain untuk studi kasus. Kerjakan di ea-lab/case-study/ — hasilnya akan jadi baseline yang direvisi sepanjang series.
Business (ringkas dulu; detail episode 4): BelanjaKu menjalankan kapabilitas merchandising, pricing, order management, fulfillment; KirimKu routing, armada, tracking; BayarKu onboarding KYC, ledger, settlement.
Data: entitas pelanggan tersebar — BelanjaKu punya tabel customer sendiri, BayarKu punya user wallet, KirimKu hanya kenal nama penerima paket. Tiga definisi "pelanggan" berbeda: masalah arsitektur data nyata yang akan diselesaikan episode 5.
Application: inventaris awal menemukan pola duplikasi klasik grup usaha — dua CRM, tiga sistem notifikasi (email/SMS), dua BI tool. Setiap anak perusahaan membangun solusi serupa secara mandiri.
Technology: BelanjaKu di AWS, KirimKu di GCP, BayarKu masih on-premise karena regulasi; identitas terpisah tiga tempat; tidak ada network connectivity antar lini.
Dari mapping singkat ini sudah muncul daftar isu lintas domain — duplikasi aplikasi (application), fragmentasi identitas pelanggan (data), dan inkonsistensi platform (technology) — semuanya bermuara pada keputusan business architecture tentang seberapa terpadu grup ini ingin beroperasi. Itulah bukti bahwa business architecture layak didahulukan, topik episode berikutnya.
Note
Saat melakukan domain mapping pertama kali, targetkan kedalaman dua level saja dan batasi waktu maksimal dua minggu. Tujuannya peta yang cukup baik untuk mendiskusikan prioritas — bukan inventaris sempurna. Peta sempurna yang terlambat lebih tidak berguna daripada peta kasar yang tepat sasaran.
#Kesalahan Umum dalam Mengelola Domain
- Melewati business domain — langsung ke diskusi aplikasi/teknologi; hasilnya rekomendasi cerdas untuk masalah yang salah.
- Domain sebagai silo tim — tim data tidak tahu rencana tim aplikasi; padahal nilainya justru di relasi antar-domain.
- Detail berlebihan sejak awal — memodelkan 5000 proses bisnis saat yang dibutuhkan hanyalah 30 kapabilitas; model EA hidup dari tingkat abstraksi yang tepat.
- Baseline tidak pernah diperbarui — peta current state yang usang membuat semua analisis gap salah; aturan mainnya: perubahan landscape wajib tercermin di repository (episode 10).
Warning
Waspadai "domain war": tiap kepala divisi klaim domain miliknya dan menolak pandangan lintas domain. Solusinya bukan debat struktur, melainkan tunjukkan nilai lintas-domain dengan kasus konkret — seperti tiga definisi pelanggan di Bumi Niaga yang tak bisa diselesaikan oleh domain mana pun sendirian.
#Penutup
Inti yang harus dibawa pulang:
- Empat domain — business, data, application, technology — adalah cara standar memecah kompleksitas arsitektur organisasi; security melintasi semuanya, bukan domain kelima.
- Dependensi mengalir dari atas ke bawah: bisnis menentukan data, data menentukan aplikasi, aplikasi menentukan teknologi — traceability balik ke kebutuhan bisnis adalah uji kebenaran keputusan.
- Domain mapping pertama Bumi Niaga sudah menyingkap tiga isu nyata: duplikasi aplikasi, fragmentasi data pelanggan, dan inkonsistensi platform — semuanya bermuara pada keputusan operating model.
- Kelola domain dengan tingkat abstraksi yang tepat dan baseline yang dirawat; model EA bernilai dari digunakan untuk keputusan, bukan dari kelengkapannya.
Di episode 4 selanjutnya kita menyelam ke domain pertama dan paling fundamental: business architecture — cara membangun capability map L1-L3, membaca value stream, memilih operating model ala Ross/Weill/Robertson, dan menentukan nasib integrasi ketiga lini PT Bumi Niaga. Sampai jumpa di episode 4!