Belajar Enterprise Architect - Enterprise Integration

#Pendahuluan

Fase 3 dimulai. Setelah di episode 11 kalian menguasai seni memetakan stakeholder dan menggerakkan keputusan, kita masuk ke topik teknis paling menentukan kualitas landscape enterprise: integration. Ini sambungan janji episode 6 — duplikasi aplikasi Bumi Niaga hanya bisa dibiarkan selama sistem-sistem itu tak perlu saling bicara; begitu operating model Coordination berlaku, cara mereka berbicara menjadi keputusan arsitektur kelas berat.

Mengapa integrasi begitu penting di level EA? Karena ia menentukan kopling antar semua bagian organisasi digital. Keputusan integrasi yang buruk — akses database langsung, kontrak tak konsisten — menjalar jauh melebihi umur aplikasinya sendiri: lima tahun kemudian tim masih mewarisi kopling rapuh itu. Sebaliknya, strategi integrasi yang baik adalah infrastruktur kesepakatan: cara ratusan sistem berkooperasi tanpa saling menahan.

#Evolusi Pola Integrasi

Empat generasi pola yang masih hidup bersama di kebanyakan enterprise:

Penting dipahami: ini bukan evolusi yang menghapus — enterprise nyata menjalankan semuanya sekaligus. Strategi EA bukan memilih satu pemenang, melainkan menetapkan kapan pola mana dan memastikan pola lama tidak bertambah.

#Aturan Penentuan Pola

• Request-response sinkron untuk query dan transaksi yang butuh jawaban sekarang: cek stok saat checkout, verifikasi KYC. Pola: API terkelola.
• Event asinkron untuk fakta yang terjadi dan relevan bagi banyak pihak: order dibuat, pembayaran berhasil, paket terkirim. Pola: event backbone.
• Batch/file untuk volume besar non-real-time dan sistem legacy: rekonsiliasi harian ledger, feed mitra. Dikelola sebagai first-class citizen, bukan skrip liar.
• Point-to-point baru dilarang; yang eksis masuk daftar utang teknologi dengan rencana peluruhan.

#Komponen Integration Blueprint

Blueprint modern tersusun dari beberapa komponen standar yang perlu kalian kuasai namanya dan perannya:

100%

Perhatikan dua komponen yang sering dilupakan namun menentukan keberhasilan jangka panjang:

• Schema registry / contract catalog — tempat kontrak API dan skema event didaftarkan, di-versioning, dan dicari. Tanpa ini, event backbone berubah menjadi antrian tanpa dokumentasi yang ditakuti semua orang.
• Observability lintas integrasi — tracing end-to-end dan metrik per kontrak. Saat checkout gagal, pertanyaan "di mana rantainya putus?" harus terjawab dalam menit, bukan forum tebak-tebakan antar tim.

#Kasus Nyata: Menyatukan Tiga Lini

Terapkan pada Bumi Niaga. Kondisi awal episode 3: tidak ada konektivitas antar-lini, tiap lini integrasi internalnya sendiri-sendiri, plus beberapa integrasi file ad-hoc ke mitra kurir. Target blueprint-nya bertingkat:

Contoh alur konkret yang membuktikan nilai Coordination: order dibuat di BelanjaKu → event order.created dipublikasi → KirimKu membuat shipment dan mempublikasi shipment.dispatched → BelanjaKu update status tanpa polling → BayarKu mencatat settlement dari event payment.captured. Tiga sistem, nol panggilan langsung antar mereka, semua lewat kontrak terdaftar. Inilah wujud teknis dari "satu pengalaman pelanggan".

#Governance Integrasi

Integrasi adalah area di mana governance episode 9 paling terasa. Aturan main minimum yang layak ditulis ke prinsip arsitektur:

• Kontrak baru wajib terdaftar di catalog sebelum produksi; breaking change wajib versi mayor dan periode deprecation.
• Data personal dalam event/API melewati klasifikasi consent (episode 5) — topik customer.updated membawa field apa saja itu keputusan owner data, bukan developer.
• Setiap integrasi punya owner dan SLO; konektor tanpa owner dimusnahkan atau diadopsi formal.

Prinsip-prinsip ini persis yang akan diuji ARB saat tim KirimKu mengajukan "akses langsung DB wallet" ala exception record episode 9 — jalurnya sudah siap.

Prinsip-prinsip ini persis yang akan diuji ARB saat tim KirimKu mengajukan "akses langsung DB wallet" ala exception record episode 9 — jalurnya sudah siap. Dan satu metrik integrasi yang layak dipantau di dashboard: jumlah konektor point-to-point hidup — angka yang wajib turun, bukan naik, tiap review kuarteran.

#Praktik: Integration Blueprint Bumi Niaga

Kerjakan di ea-lab/case-study/application/integration-blueprint.md:

1. Inventarisasi integrasi eksisting — tambah kolom "integrasi keluar/masuk" ke portfolio episode 6; hitung berapa point-to-point yang masih hidup.
2. Diagram target — gambarkan blueprint komponen (gateway, backbone, flows, registry) di Archi/draw.io dengan posisi ketiga lini.
3. Definisikan 5 event inti — order.created, shipment.dispatched, payment.captured, customer.registered, consent.changed; tulis producer, konsumen, dan payload ringkas masing-masing.
4. Aturan governance — rumuskan tiga prinsip integrasi lengkap dengan rasional, siap masuk folder principles.

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:

• Empat pola integrasi hidup berdampingan; strategi EA menetapkan kriteria pemilihan — sync untuk transaksi, event untuk fakta lintas sistem — dan menghentikan lahirnya point-to-point baru.
• Blueprint modern = gateway + event backbone + managed flows, ditopang schema registry dan observability lintas rantai; dua yang terakhir menentukan usia panjangnya.
• Alur order.created sampai settlement membuktikan operating model Coordination secara teknis: tiga lini berkolaborasi tanpa kopling langsung.
• Integrasi adalah medan utama governance: kontrak terdaftar, versi dikelola, consent mengikuti data, dan setiap koneksi punya owner.

Landscape kini terhubung — tapi di mana semuanya berjalan? Di episode 13 kita bahas cloud & hybrid enterprise: merumuskan enterprise cloud strategy untuk workload yang tersebar AWS-GCP-onpremise, pola migrasi 6R, dan cara mengelola multi-cloud tanpa bangkrut oleh kompleksitasnya. Sampai jumpa di episode 13!