Banyak sistem saling berbicara secara teknis, tetapi tidak saling memahami secara fungsional. Dan di situlah pekerjaan yang sebenarnya dimulai.
Sebuah ERP berpikir dalam transaksi dan kebenaran finansial. Lini produksi berpikir dalam waktu dan kesinambungan. Manajemen menginginkan dasbor. Keamanan menginginkan auditabilitas. Dan operator di lantai kebanyakan hanya ingin mesinnya besok masih melakukan apa yang dilakukannya hari ini.
Secara teknis Anda dapat menghubungkan dunia-dunia itu dengan sempurna. Sebuah API di sini, antrian pesan di sana, beberapa JSON di antaranya — selesai. Begitu juga tampilannya dalam diagram arsitektur.
Kecuali dalam praktiknya jarang berjalan seperti itu.
Middleware tidak hanya menerjemahkan protokol. Ia menerjemahkan ekspektasi.
Sebuah ERP ingin tahu sekarang apakah pesanan telah diproses. Sebuah mesin di lantai pabrik terkadang tidak bisa merespons itu sama sekali — bukan karena koneksi terputus, tetapi karena realitas fisik memiliki ritme yang berbeda dari sistem transaksi. Itu bukan bug. Itu perbedaan fundamental dalam cara kedua dunia itu memandang waktu.
Saya terus-menerus menghadapi ketidakcocokan semacam ini. Bukan sebagai pertanyaan arsitektur abstrak, tetapi sebagai masalah yang sangat konkret. Sistem kontrol yang kelebihan beban karena sistem IT melakukan polling terlalu agresif. Pesan yang ditulis ulang tiga kali sebelum tiba, dan tidak ada yang tahu mengapa lagi. Solusi sementara dari 2017 yang diam-diam menjadi tulang punggung seluruh integrasi.
Di lingkungan OT/IT ini menjadi lebih tajam.
IT dibangun di sekitar konsistensi, autentikasi, dan pengelolaan. OT berjalan pada stabilitas, ketersediaan, dan perilaku yang dapat diprediksi. Lini produksi yang berhenti selama lima detik karena sertifikat perlu diperbarui — itu bukan insiden kecil. Itu adalah kerugian produksi, dan terkadang risiko keselamatan.
Jadi di suatu tempat harus diputuskan apa arti “real-time” sebenarnya. Kesalahan mana yang dapat diterima. Siapa yang memimpin dalam konflik. Berapa lama data tetap valid. Apa yang terjadi ketika sistem mati. Tindakan mana yang boleh terjadi secara otomatis dan mana yang tidak.
Dan itu terjadi secara mengejutkan sering di middleware.
Dalam diagram di bawah Anda melihat tepat struktur itu: di atas sistem IT dengan logika dan ekspektasinya sendiri, di bawah sistem OT dengan ritme yang secara fundamental berbeda — dan middleware di antaranya sebagai lapisan yang menerjemahkan kedua dunia.
Yang Anda lihat di sana dalam praktiknya:
- Validasi pesan sebelum mencapai mesin.
- Konversi protokol antara sistem yang tidak pernah dimaksudkan satu sama lain.
- Throttling untuk melindungi lingkungan OT dari lalu lintas IT.
- Buffering ketika sistem berjalan pada kecepatan yang berbeda.
- Audit logging untuk kepatuhan dan logika fallback ketika antarmuka gagal.
Kedengarannya seperti arsitektur yang bersih. Tetapi dalam praktiknya ini tumbuh secara organik. Di bawah tekanan, selama pemadaman atau migrasi. Karena masalah perlu diselesaikan sekarang. Dan di situlah tepatnya menjadi berbahaya.
Middleware: di mana kompromi bertemu
Middleware secara diam-diam menjadi tempat di mana kompromi teknis dan organisasi bertemu. Aturan bisnis menghilang ke dalam skrip. Perbaikan sementara menjadi permanen. Tidak ada yang mendokumentasikan mengapa penundaan tertentu ada, karena pada saat dibangun itu “hanya perbaikan cepat.” Tiga tahun kemudian itu menjadi logika bisnis tersembunyi dan tidak ada yang berani menyentuhnya lagi.
Saya tidak mengatakan ini untuk menghakimi — saya telah membangunnya sendiri, di lingkungan di mana Anda tidak memiliki kemewahan melakukan tinjauan arsitektur terlebih dahulu. Tetapi justru karena itu saya tahu: middleware menuntut pemikiran arsitektur. Tidak hanya secara teknis. Juga secara organisasi. Karena pada akhirnya ini bukan tentang data. Ini tentang batas-batas — antara sistem, tim, tanggung jawab, dan realitas.
Middleware yang baik tidak menyembunyikan kompleksitas. Ia membuatnya dapat dikelola.