Selama sebagian besar sejarah TI perusahaan, integrasi merupakan peristiwa yang sesekali terjadi. Sistem berukuran besar, berumur panjang, dan jumlahnya sedikit. Menghubungkan dua di antaranya adalah sebuah proyek dengan awal dan akhir, dan batas organisasi kurang lebih juga merupakan batas sistemnya. Dunia itu telah lenyap. Organisasi besar pada umumnya kini menjalankan ratusan aplikasi, sebagian besar disediakan sebagai layanan dan dimiliki oleh vendor alih-alih oleh departemen TI. Kapabilitas baru datang melalui langganan, bukan melalui pembangunan, dan setiap langganan mengharapkan pertukaran data dengan segala hal di sekitarnya.

Hal ini mengubah pusat gravitasi arsitektur. Ketika kapabilitas dibangun secara internal, keputusan sulitnya adalah tentang apa yang harus dibangun. Ketika kapabilitas dibeli, keputusan sulitnya adalah tentang bagaimana hal-hal yang dibeli itu terhubung dan seberapa banyak masing-masing mengetahui tentang yang lain. Strategi yang dapat dikomposisi, entah dibingkai sebagai best-of-breed, MACH, atau sekadar pengadaan yang pragmatis, hanya sebaik integrasi yang mengikat bagian-bagiannya. Sebuah organisasi dapat merakit sekumpulan aplikasi yang sangat baik dan tetap menghadirkan pengalaman yang tidak koheren jika pesanan, pelanggan, dan inventaris memiliki makna yang berbeda secara halus di setiap batas.

Hal ini penting sekarang karena alasan yang spesifik: laju perubahan telah melampaui toleransi terhadap keterikatan yang erat. Ketika sistem diganti sekali dalam satu dekade, integrasi yang rapuh dan harus ditulis ulang selama setiap penggantian masih dapat ditanggung. Ketika sistem ditambahkan, ditukar, dan dipensiunkan secara terus-menerus, setiap koneksi yang terikat erat menjadi pajak yang berulang. Biaya integrasi yang buruk dulu dibayar sesekali lalu dilupakan. Kini biaya itu dibayar setiap kuartal, dalam bentuk proyek yang tertunda, permintaan perubahan yang beriak lebih jauh dari yang diperkirakan siapa pun, dan kesadaran perlahan bahwa tidak ada yang bisa dengan aman menyentuh sistem inti karena terlalu banyak hal lain yang bergantung pada bentuk data yang persis. Inilah sebabnya arsitektur integrasi telah bergeser dari detail pengiriman menjadi kendala di tingkat dewan direksi terhadap seberapa cepat bisnis dapat berubah.

Prinsip pertama arsitektur integrasi adalah bahwa sebuah koneksi merupakan sebuah relasi, dan relasi yang tahan lama membutuhkan sebuah kontrak. Antarmuka di antara dua sistem bukanlah detail implementasi salah satu di antaranya. Ia merupakan kesepakatan bersama tentang apa yang akan dipertukarkan, dalam bentuk apa, dengan makna apa, dan dengan jaminan apa. Ketika kesepakatan itu eksplisit, kedua sisi dapat mengubah bagian internalnya secara bebas selama mereka menghormatinya. Ketika kesepakatan itu implisit, ditemukan dengan memeriksa data apa pun yang kebetulan tiba, setiap perubahan internal menjadi potensi kerusakan di tempat lain. Sebuah API paling baik dipahami bukan sebagai potongan kode melainkan sebagai janji yang dipublikasikan.

Prinsip kedua adalah keterikatan yang longgar, yang sering disebut namun lebih jarang dipahami. Keterikatan adalah sejauh mana satu komponen harus mengetahui, dan berubah bersama, komponen lain. Ia memiliki beberapa dimensi: keterikatan dalam format data, dalam waktu, dalam lokasi, dalam teknologi, dan dalam model internal yang diekspos sebuah sistem. Antarmuka yang dirancang dengan baik meminimalkan semuanya. Konsumen tidak perlu mengetahui di mana penyedia berjalan, teknologi apa yang digunakannya, apakah ia tersedia pada saat itu juga, atau bagaimana ia menyusun basis datanya. Konsumen hanya perlu mengetahui kontraknya. Keterikatan yang longgar bukanlah ketiadaan ketergantungan. Ia adalah ketergantungan yang dimediasi melalui antarmuka yang stabil dan sengaja dibuat sempit alih-alih melalui bagian internal yang mentah.

Prinsip ketiga adalah bahwa antarmuka harus mengekspresikan domain, bukan implementasi. Antarmuka yang membocorkan struktur tabel penyedia, kode internalnya, atau kekhasan teknisnya memaksa setiap konsumen untuk memahami dunia privat penyedia. Antarmuka yang diekspresikan dalam bahasa bisnis, pesanan, pengiriman, pelanggan, faktur, menyembunyikan dunia privat itu dan tetap stabil bahkan ketika implementasi di baliknya dibangun ulang. Inilah makna yang lebih dalam dari lapisan integrasi: ia bukan sekadar tempat di mana koneksi secara fisik lewat, melainkan tempat di mana makna dari lanskap dibuat eksplisit dan konsisten, sehingga sekumpulan sistem yang heterogen dapat menghadirkan satu set antarmuka yang tunggal dan koheren kepada segala hal yang perlu bekerja lintas sistem tersebut.

Pergeseran dominan dalam beberapa tahun terakhir adalah perpindahan dari permintaan dan respons sebagai default menuju peristiwa sebagai warga kelas satu. Dalam model sinkron, sebuah sistem meminta sesuatu dari sistem lain lalu menunggu. Ini wajar untuk kueri, tetapi mengikat keduanya dalam waktu: pemanggil tidak dapat melanjutkan kecuali yang dipanggil tersedia dan cepat. Integrasi berbasis peristiwa membalikkan ini. Sebuah sistem mempublikasikan sebuah fakta tentang sesuatu yang telah terjadi, sebuah pesanan telah dibuat, sebuah pembayaran telah lunas, sebuah alamat telah berubah, dan sistem lain bereaksi terhadap fakta itu menurut jadwalnya sendiri. Penerbit tidak mengetahui atau peduli siapa yang mendengarkan. Pemisahan temporal inilah yang memungkinkan sebuah lanskap menyerap beban, menoleransi pemadaman parsial, dan menambahkan konsumen baru tanpa menyentuh produsen.

Platform berbasis pesan dan streaming telah matang sehingga hal ini praktis dilakukan dalam skala besar. Log yang tahan lama dan broker pesan menyediakan tulang punggungnya, dan disiplin memperlakukan aliran peristiwa sebagai sumber kebenaran bersama telah menyebar dari ceruk menjadi arus utama. Bersamaan dengan ini, API-first telah menjadi asumsi operasional alih-alih aspirasi: kontrak dirancang dan disepakati sebelum implementasi, dan semakin sering kontrak itu dideskripsikan dalam spesifikasi yang dapat dibaca mesin yang menghasilkan dokumentasi, kode klien, dan validasi. Apa yang dilakukan OpenAPI untuk API sinkron, spesifikasi yang serupa kini lakukan untuk antarmuka asinkron berbasis peristiwa.

Dua gerakan lebih lanjut patut disebut. Yang pertama adalah perlakuan terhadap API sebagai produk alih-alih sebagai hasil sampingan proyek. Sebuah produk API memiliki pemilik, sebuah siklus hidup, sekumpulan konsumen yang diperlakukan sebagai pelanggan, dan kebijakan versi yang disengaja, entah ia diekspos secara internal, kepada mitra, atau kepada publik. Yang kedua adalah munculnya platform integrasi terkelola dan gateway yang memusatkan perhatian lintas potong, keamanan, throttling, observabilitas, transformasi, sehingga hal-hal ini diselesaikan sekali alih-alih diimplementasikan ulang di setiap koneksi. Tren ini bukan menuju satu teknologi tunggal melainkan menuju sekumpulan kapabilitas berlapis: gateway untuk lalu lintas sinkron, broker dan stream untuk aliran asinkron, dan platform integrasi yang memungkinkan tim menyusun aliran tanpa membangun setiap adapter secara manual.

Arsitektur integrasi yang baik dibedakan bukan berdasarkan teknologi apa yang digunakannya melainkan properti apa yang dijaminnya. Yang pertama adalah kontrak yang eksplisit dan berversi dengan disiplin kompatibilitas mundur. Konsumen harus mampu bergantung pada sebuah antarmuka tanpa rasa takut bahwa perubahan yang senyap akan merusak mereka, dan penyedia harus mampu berevolusi tanpa mengoordinasikan rilis yang tersinkronisasi lintas setiap konsumen sekaligus. Ini berarti perubahan yang bersifat menambah secara default, penomoran versi yang jelas ketika kerusakan tak terhindarkan, dan periode yang terdefinisi di mana yang lama dan yang baru berdampingan. Antarmuka tanpa strategi versi adalah kerusakan yang sedang menunggu jadwal.

Properti kedua adalah idempotensi dan toleransi terhadap pengiriman yang tidak sempurna. Jaringan gagal, pesan dicoba ulang, dan duplikat tiba. Integrasi yang mengasumsikan pengiriman tepat-sekali, berurutan, dan selalu berhasil adalah integrasi yang akan merusak data pertama kali kenyataan tidak sependapat. Merancang operasi sedemikian rupa sehingga menerima peristiwa yang sama dua kali tidak berbahaya, dan sehingga peristiwa dapat diproses ulang, bukanlah kasus tepi. Ia adalah dasar bagi segala hal yang bersifat asinkron.

Yang ketiga adalah pilihan yang disengaja antara orkestrasi dan koreografi. Orkestrasi menempatkan koordinator pusat yang bertanggung jawab atas sebuah proses, yang jelas dan mudah dipahami tetapi memusatkan keterikatan di satu tempat. Koreografi membiarkan komponen bereaksi terhadap peristiwa tanpa dirigen pusat, yang sangat terurai tetapi lebih sulit diamati dan dipahami secara keseluruhan. Tidak ada yang benar secara abstrak. Keterampilannya adalah mengetahui mana yang digunakan di mana: orkestrasi untuk proses yang membutuhkan pemilik yang jelas dan keadaan yang dapat diaudit, koreografi untuk penyebaran fakta lintas banyak konsumen independen.

Yang keempat adalah pengekangan diri terkait makna bersama. Kosakata umum di seluruh lanskap bernilai, tetapi ambisi untuk mendefinisikan satu model universal bagi setiap entitas, yang dipaksakan di mana-mana, cenderung runtuh di bawah bebannya sendiri. Pendekatan yang matang meminjam dari domain-driven design: mengakui bounded context di mana kata yang sama secara sah bermakna berbeda, menerjemahkan di batas-batasnya, dan menjaga definisi kanonis di tempat-tempat yang benar-benar mengurangi gesekan alih-alih di mana-mana atas dasar prinsip. Tugas lapisan integrasi adalah memediasi makna, bukan memaksa setiap sistem masuk ke dalam satu kamus yang tidak cocok dengan satu pun di antaranya dengan baik.

Spageti titik-ke-titik adalah kegagalan klasik dan paling mahal. Setiap integrasi baru dibangun langsung di antara dua sistem, karena itulah jalur tercepat bagi proyek yang ada di hadapan Anda. Setelah cukup banyak proyek, lanskap menjadi jaring yang padat di mana setiap sistem mengetahui banyak sistem lain, tidak ada yang bisa melihat keseluruhan, dan perubahan apa pun beriak secara tak terduga. Jumlah koneksi yang mungkin bertumbuh sebanding dengan kuadrat jumlah sistem, dan demikian pula beban pemeliharaannya. Tragedinya adalah bahwa setiap tautan titik-ke-titik individual merupakan keputusan lokal yang masuk akal. Spageti itu adalah properti yang muncul dari tidak pernah merancang lapisannya.

Monolit terdistribusi adalah kegagalan yang menyamar sebagai arsitektur modern. Sistemnya terpisah, tetapi begitu terikat erat melalui panggilan sinkron dan asumsi bersama sehingga tidak ada yang bisa disebarkan secara independen. Perubahan pada satu sistem menuntut perubahan dan rilis yang terkoordinasi lintas beberapa sistem. Ini lebih buruk daripada sebuah monolit, karena ia memiliki seluruh keterikatan sebuah monolit ditambah kerumitan operasional sebuah sistem terdistribusi. Ini biasanya merupakan hasil dari memisahkan sistem secara fisik tanpa menguraikannya secara logis.

Model kanonis yang menelan perusahaan adalah kegagalan sentralisasi yang berlebihan. Upaya yang bermaksud baik untuk mendefinisikan satu model data bersama menjadi sebuah hambatan: setiap integrasi harus dipetakan ke skema universal yang meluas, setiap perubahan pada skema itu memengaruhi semua orang, dan model itu tumbuh baroque saat ia berusaha mengakomodasi setiap kasus khusus. Obat untuk spageti menjadi penyakitnya sendiri. Rantai sinkron yang cerewet adalah jebakan terkait, di mana satu tindakan pengguna menyebar menjadi rangkaian panjang panggilan yang memblokir lintas banyak sistem, sehingga tautan yang paling lambat atau paling tidak andal menentukan perilaku keseluruhan, dan satu timeout di suatu tempat jauh di dalam rantai muncul sebagai kegagalan yang tak dapat dijelaskan di puncak. Penyimpangan kontrak melengkapi rangkaian ini: antarmuka ada tetapi tidak terdokumentasi dan tidak dikelola, versi berkembang biak secara informal, dan tidak ada yang dapat mengatakan dengan yakin siapa mengonsumsi apa, sehingga tidak ada yang dapat dipensiunkan dengan aman.

Nashua memperlakukan integrasi sebagai sebuah arsitektur yang harus dirancang, bukan tumpukan konektor yang harus dikirimkan. Titik awalnya selalu adalah peta yang jujur tentang lanskap saat ini: sistem apa saja yang ada, bagaimana mereka sebenarnya bertukar data hari ini, di mana tautan titik-ke-titik telah menumpuk, dan mana di antaranya yang membawa aliran yang kritis bagi bisnis. Peta ini seringkali merupakan kali pertama sebuah organisasi melihat bentuk sebenarnya dari konektivitasnya, dan di situlah risiko yang nyata dan peluang yang nyata menjadi terlihat. Kami menahan godaan untuk melompat ke teknologi target sebelum masalahnya dipahami.

Dari peta itu kami bekerja bersama organisasi untuk mendefinisikan arsitektur referensi integrasi: lapisan-lapisan dan tanggung jawabnya, batas-batas di mana makna diterjemahkan, pilihan antara sinkron versus berbasis peristiwa untuk setiap kelas aliran, dan standar untuk kontrak, penomoran versi, dan penanganan kesalahan. Ini secara sengaja diinformasikan oleh teknologi tetapi tidak dipimpin oleh teknologi. Arsitektur referensi menyatakan properti apa yang harus dimiliki setiap integrasi sebelum ia menetapkan gateway, broker, atau platform mana yang menyediakannya, sehingga perkakas melayani rancangan alih-alih mendikte rancangan.

Pengiriman bersifat inkremental dan dipandu bukti. Mengurai lanskap yang telah tumbuh titik-ke-titik selama bertahun-tahun tidak dilakukan dalam satu program tunggal, dan berupaya melakukannya justru merupakan salah satu mode kegagalan. Kami mengidentifikasi aliran-aliran di mana penguraian membeli kebebasan terbanyak, memperkenalkan lapisan integrasi di sekitarnya terlebih dahulu, dan membiarkan pola itu membuktikan dirinya sebelum memperluasnya. Setiap antarmuka baru dirancang sebagai kontrak dengan seorang pemilik, didokumentasikan dalam spesifikasi yang dapat dibaca mesin, dan didaftarkan sehingga konsumennya diketahui. Seiring waktu lanskap mengumpulkan katalog API yang merupakan aset sejati: inventaris yang dapat dijelajahi dan dikelola tentang apa yang dapat dihubungkan oleh organisasi dan bagaimana caranya. Kami memadukan ini dengan sisi operasional, observabilitas, keamanan di batas, dan manajemen siklus hidup, karena integrasi yang tidak dapat dimonitor dan diberi versi dalam produksi merupakan sebuah liabilitas terlepas dari seberapa elegan rancangannya tampak di atas kertas.

Perbedaan yang dibawa Nashua adalah kombinasi antara disiplin arsitektural dengan pengiriman yang mencapai produksi. Banyak organisasi memiliki diagram lapisan integrasi yang mereka harap mereka miliki, dan sebuah kenyataan yang tampak sama sekali berbeda. Kesenjangan di antara keduanya tidak ditutup dengan diagram yang lebih kuat. Ia ditutup dengan bekerja berdampingan dengan tim yang membangun dan mengoperasikan koneksi, dengan menjadikan pola yang benar sebagai pola yang mudah, dan dengan mengelola kontrak serta versi dengan ketelitian yang cukup untuk aman dan pragmatisme yang cukup untuk terus bergerak. Kami memegang pandangan jangka panjang atas arsitektur referensi dan pandangan jangka pendek atas aliran yang harus dikirimkan kuartal ini, dan kami menolak membiarkan salah satunya diam-diam menyabotase yang lain.

Ada pula sebuah konsekuensi praktis yang mengubah apa yang boleh diasumsikan oleh pekerjaan ini. Ketika sebuah penugasan memerlukan kapabilitas yang belum ada, ia tidak perlu menunggu siklus pengadaan atau peta jalan vendor. enterprise platform dibangun untuk mengakomodasi hampir semua fitur dengan cepat, melalui agentic engineering: apa yang dibutuhkan dideskripsikan dalam bahasa yang lugas dan dihasilkan dengan cepat, tetapi selalu di dalam prinsip arsitektur yang kokoh dan di bawah penjaminan mutu yang ketat, sehingga kecepatan tidak pernah mengorbankan koherensi, keamanan, atau kendali. Efeknya bersifat strategis alih-alih sekadar praktis. Ia menggeser garis buat-atau-beli, menjaga opsionalitas tetap murah, dan membiarkan arsitektur mengikuti strategi alih-alih strategi tunduk pada apa pun yang kebetulan ada di rak.

Yang bertahan setelah pekerjaan kami bukanlah ketergantungan pada kami. Ia adalah sebuah lanskap yang sistemnya terhubung melalui antarmuka yang disengaja dan terdokumentasi alih-alih kekusutan asumsi privat, dan sebuah organisasi yang dapat menambahkan, mengganti, dan mempensiunkan sistem tanpa setiap perubahan menjadi proyek arkeologi. Itulah imbal hasil sejati dari arsitektur integrasi: bukan sebuah teknologi, melainkan kemampuan untuk berubah yang telah dipulihkan. Ketika jaringan penghubung dirancang dengan cermat, lanskap yang heterogen berhenti berperilaku seperti sekumpulan silo yang saling bertikai dan mulai berperilaku seperti satu bisnis, dan sistem berikutnya yang dibeli organisasi menjadi sebuah tambahan alih-alih sebuah ancaman. Membantu klien kami mencapai dan mempertahankan keadaan itu, secara tenang dan tahan lama, adalah tempat di mana Nashua membuat perbedaan.