Baru-baru ini seseorang berkata kepada saya: “If it ain’t broken, don’t fix it.”
Kedengarannya seperti pernyataan yang sederhana, mungkin agak kuno. Seolah-olah Anda sebaiknya menghindari mengubah apa pun selama sistem masih berjalan.
Tetapi di lingkungan legacy saya mendengar sesuatu yang berbeda di dalamnya. Bukan: biarkan saja karena yang lama sudah cukup baik. Tetapi: berhati-hatilah, karena tidak ada yang tahu persis mengapa itu masih bekerja.
Dan itu adalah masalah yang sangat berbeda.
Karena ketika tidak ada yang tahu bagaimana suatu sistem benar-benar saling terhubung, menggantinya bukan lagi migrasi teknis yang mudah. Anda menarik benang tanpa mengetahui ke mana arahnya. Sebelum Anda menyadarinya, kotak Pandora terbuka.
Antarmuka lama ternyata masih diperlukan. Sebuah field yang tidak digunakan siapapun memasok laporan. Skrip malam mengkoreksi data yang diandalkan oleh tiga departemen. Penundaan aneh mencegah mesin masuk ke kondisi gagal. Pengecualian dalam kode ternyata merupakan perjanjian pelanggan lama. Daftar Excel manual ternyata merupakan bagian dari proses yang sebenarnya.
Dan kemudian Anda menemukan bahwa sistem lama bukan hanya perangkat lunak atau perangkat keras. Itu adalah memori. Tidak terdokumentasi dengan rapi, tidak dirancang dengan elegan, tidak selalu aman atau tahan masa depan — tetapi penuh dengan bertahun-tahun pengetahuan proses.
Itulah mengapa saya menemukan “If it ain’t broken, don’t fix it” sebenarnya tidak cukup tajam. Saya lebih suka merumuskanya seperti ini:
Jika tidak rusak, pertama pahami mengapa masih bekerja.
Bagaimana legacy tumbuh
Di banyak organisasi, legacy terutama dilihat sebagai beban. Bahasa pemrograman lama, database lama, server lama, PLC lama, lingkungan SCADA lama, antarmuka lama, layar lama yang tidak lagi disukai siapapun.
Dan terkadang itu wajar. Sistem lama bisa rentan. Mereka mungkin berjalan pada perangkat keras yang tidak lagi tersedia, bergantung pada perangkat lunak yang tidak ada patch-nya lagi, dan tidak memenuhi persyaratan keamanan modern, pemantauan, atau kebutuhan integrasi dengan baik.
Tetapi itu hanya satu sisi cerita. Sisi lainnya adalah bahwa sistem lama semacam itu sering kali telah bergerak bersama dengan realitas selama bertahun-tahun. Bukan dengan realitas sebagaimana pernah digambarkan dalam diagram proses, tetapi dengan realitas sebagaimana adanya. Pengecualian ditambahkan. Kemudian satu lagi. Solusi sementara menjadi permanen. Skrip yang cepat diperlukan menjadi kritis bagi bisnis. Antarmuka yang tidak disukai siapapun bertahan karena tiga proses bergantung padanya.
Saya melihat itu sendiri dari dekat. Bertahun-tahun lalu saya mengerjakan sistem kontrol di pembangkit listrik — pencairan es pada asupan udara. Di atas kertas itu adalah instalasi yang jelas dengan fungsi yang terdefinisi dengan baik. Dalam praktiknya ada seluruh lapisan logika di sekitarnya yang tidak terdokumentasi di mana pun: pengecualian untuk kondisi cuaca tertentu, penggantian manual yang ditambahkan operator selama bertahun-tahun, ketergantungan waktu yang secara diam-diam mencegah instalasi membuat dirinya sendiri bermasalah. Tidak ada yang ada dalam dokumen desain. Itu ada dalam sistem, dan dalam kepala orang-orang yang bekerja dengannya.
Begitulah legacy tumbuh. Bukan karena orang bodoh atau tidak ada yang memperhatikan, tetapi karena organisasi berubah, proses bergeser, pelanggan meminta hal yang berbeda, undang-undang berubah, mesin semakin tua, dan orang-orang menemukan solusi untuk menyelesaikan pekerjaan.
Lama tidak otomatis ketinggalan zaman
Ada kesalahpahaman yang mendasari banyak diskusi legacy: bahwa teknologi lama secara otomatis merupakan teknologi yang ketinggalan zaman. Itu tidak selalu benar.
Banyak teknologi fundamental masih sama. Database relasional masih database relasional. Jaringan TCP/IP masih jaringan TCP/IP. Di lingkungan industri pun, banyak prinsip yang mengejutkan tetap konstan: ukur, kendalikan, umpan balik, batasi, amankan, catat.
Cangkangnya berubah — tooling, antarmuka, konteks arsitektur. Pikirkan arsitektur berbasis peristiwa, zero trust, pola cloud-native. Tetapi logika yang mendasarinya sering berubah lebih sedikit dari yang orang pikirkan.
Terkadang masalahnya bukan bahwa teknologi secara fundamental ketinggalan zaman, tetapi dunia di sekitar sistem telah berubah. Sistem itu pernah harus melakukan satu tugas dalam konteks yang terdefinisi. Sekarang sistem yang sama harus terhubung dengan aplikasi modern, memasok data ke dasbor, memenuhi persyaratan keamanan baru, tersedia untuk beberapa departemen, dan sesuai dengan tata kelola yang belum ada pada saat itu.
Maka sistem itu tidak harus rusak. Itu hanya berakhir di dunia yang tidak pernah dirancang untuknya.
Proses formal tidak selalu merupakan proses yang sebenarnya
Salah satu risiko terbesar dalam modernisasi adalah memulai dari proses formal. Orang melihat dokumentasi, diagram proses, skema arsitektur, bagaimana hal-hal pernah dimaksudkan.
Itu tampaknya logis. Tetapi di lingkungan brownfield itu sering tidak cukup.
Proses yang sebenarnya ada dalam perilaku. Dalam pengecualian. Dalam langkah-langkah manual. Dalam skrip lama. Dalam nilai-nilai database yang pernah bersifat sementara. Dalam tindakan operator yang telah ada begitu lama sehingga tidak ada yang mengenalinya sebagai solusi sementara lagi. Dan seringkali sistem legacy adalah satu-satunya tempat di mana proses yang sebenarnya masih terlihat — tidak indah, tidak lengkap, tidak terdeskripsi dengan rapi, tetapi hadir.
Itulah mengapa sistem lama bisa secara teknis ketinggalan zaman dan secara fungsional masih lebih matang dari desain baru. Itu tidak nyaman, tetapi penting. Karena sistem modern yang hanya mengikuti proses formal bisa dibangun dengan sempurna dan tetap gagal dalam praktiknya. Bukan karena teknologinya buruk, tetapi karena tidak memahami organisasi yang sebenarnya.
Teknologi baru tidak menyelesaikan ketidaktahuan lama.
Modernisasi dapat menghancurkan pengetahuan
Ketika Anda mengganti sistem legacy tanpa memahami pengetahuan apa yang ada di dalamnya, Anda tidak hanya membuang teknologi lama. Anda membuang memori organisasi.
Itu jarang terjadi dalam satu ledakan besar. Itu terjadi secara halus. Setelah go-live ternyata pengecualian tertentu tidak lagi berfungsi. Laporan sedikit meleset. Mesin merespons secara berbeda. Operator mulai melakukan pemeriksaan tambahan. Pengguna menyimpan daftar Excel. Departemen membangun proses bayangan. Operasi menerima notifikasi yang tidak diantisipasi oleh siapapun.
Dan setelah beberapa bulan semua orang bertanya mengapa sistem baru menimbulkan begitu banyak masalah. Bukan karena modernisasi salah, tetapi karena sistem lama seharusnya dibaca lebih hati-hati.
Lalu bagaimana?
Bukan dengan mengganti legacy secara membabi buta. Tetapi juga bukan dengan membiarkan segalanya apa adanya. Seninya adalah membuat sistem terlebih dahulu dapat dibaca, kemudian dapat dikelola, dan baru kemudian dapat diganti.
Mulailah dengan mengamati — dan dengan berbicara. Lihat tidak hanya dokumentasi, tetapi terutama perilaku. Apa yang masuk? Apa yang keluar? Pengecualian apa yang ada? Departemen, mesin, laporan, atau keputusan mana yang bergantung pada sistem ini? Dan setidaknya sama pentingnya: bicaralah dengan orang-orang yang bekerja dengannya. Operator yang telah menjalankan mesin itu selama lima belas tahun. Administrator yang pernah menulis skrip malam itu. Perencana yang menjalankan ekspor Excel setiap Senin yang tidak diketahui siapapun ada. Pengetahuan proses yang sebenarnya sering tidak ada dalam kode atau konfigurasi, tetapi dalam kepala orang-orang. Dan pengetahuan itu menghilang jika Anda tidak melibatkan orang-orang tersebut sebelum mulai mengganti.
Buat pengetahuan proses tersembunyi menjadi eksplisit. Banyak logika tidak lagi ada dalam dokumen, tetapi dalam kode, skrip, field database, file konfigurasi, tindakan operator, daftar Excel, dan antarmuka lama. Petakan itu — bukan untuk mendokumentasikannya di laci, tetapi untuk membawanya ke dalam desain baru.
Letakkan cangkang yang aman di sekitar sistem. Tambahkan logging. Tambahkan pemantauan. Periksa backup. Batasi akses. Segmentasikan jaringan. Buat antarmuka eksplisit. Mungkin bangun lapisan API, lapisan ekspor, atau komponen middleware. Bukan untuk membuat sistem lama lebih indah, tetapi untuk membuatnya dapat dikelola.
Kemudian ganti langkah demi langkah. Pertama satu antarmuka. Kemudian satu langkah proses. Kemudian satu modul. Di mana memungkinkan, biarkan yang lama dan yang baru berjalan berdampingan untuk sementara. Bandingkan output, perilaku, kesalahan, dan pengecualian — tidak hanya secara teknis, tetapi juga secara fungsional.
Migrasi big bang terkadang tampak efisien, tetapi di lingkungan brownfield itu sering kepastian palsu. Anda menemukan kompleksitas yang sebenarnya hanya ketika sistem baru harus membawa realitas lama.
Aturannya sederhana: jangan mengganti komponen yang fungsinya belum Anda pahami. Atau lebih tajam: Anda hanya boleh mematikan sesuatu ketika Anda tahu mengapa itu pernah dinyalakan.
Modernisasi dimulai dengan pemahaman
Legacy jarang hanya masalah teknis. Ini adalah kombinasi teknologi, proses, sejarah, dan keputusan yang terlupakan.
Mereka yang hanya melihat usia sistem terutama melihat risiko. Mereka yang melihat lebih hati-hati juga melihat pengetahuan. Itu tidak berarti sistem lama harus tetap seperti adanya — beberapa sistem benar-benar perlu diganti, beberapa antarmuka berbahaya, beberapa ketergantungan tidak bertanggung jawab, beberapa teknologi tidak lagi aman atau dapat dikelola.
Tetapi bahkan begitu, modernisasi yang baik tidak dimulai dengan pembongkaran. Ini dimulai dengan pemahaman.
Apa yang sebenarnya dilakukan sistem ini? Mengapa cara kerjanya seperti ini? Pengetahuan apa yang tersimpan di dalamnya? Apa yang harus tetap ada, apa yang bisa pergi, apa yang perlu dirancang ulang?
Legacy tidak selalu muncul karena teknologi menjadi usang. Terkadang legacy muncul karena dunia di sekitar sistem berubah. Dan justru karena itu, modernisasi bukan soal mengganti yang lama dengan yang baru — melainkan dengan hati-hati mentransfer pengetahuan yang berfungsi ke dalam bentuk yang sekali lagi sesuai dengan realitas saat ini.
“If it ain’t broken, don’t fix it.”
Tetapi di atas segalanya:
“Jika tidak rusak, pertama pahami mengapa masih bekerja.”