Pengembangan dan implementasi sebuah sistem aplikasi umumnya dilakukan untuk memenuhi kebutuhan tertentu dari organisasi/perusahaan. Walaupun tentu saja kita tidak menutup mata akan adanya sistem yang diimplementasikan tanpa justifikasi kebutuhan yang jelas, misalnya sekedar untuk tujuan penyerapan anggaran, “dropping” aplikasi yang tidak jelas manfaat dan tujuannya, dsj. Tulisan ini tidak akan membahas kelompok inisiatif pengembangan/implementasi aplikasi yang tidak jelas tersebut.
Jadi, pengembangan/implementasi sebuah sistem aplikasi seharusnya dilakukan untuk memenuhi kebutuhan dari organisasi. Sehingga ukuran keberhasilan dari pengembangan/implementasi tersebut adalah terpenuhinya kebutuhan bisnis dari organisasi tersebut. Sedangkan kebutuhan bisnis itu sendiri memiliki karakteristik generik seperti:
(1) Bersifat tidak tunggal namun saling terkait. Pada umumnya sebuah organisasi memiliki banyak kebutuhan yang saling terkait satu dengan lainnya, misalnya kebutuhan keuangan, persediaan, produksi, distribusi, pemasaran, dsb.
(2) Bersifat dinamis. Kebutuhan bisnis terus berubah seiring lingkungan kompetitif yang melingkupinya.
Kombinasi 2 karakteristik tersebut di atas ternyata terbukti merupakan kombinasi “Lethal” nan mematikan bagi setiap organisasi. Bagaimana tidak? Ketika sebuah proyek pengembangan/implementasi aplikasi selesai dilaksanakan, muncul tuntutan untuk mengintegrasikannya dengan sistem lain yang telah ada sebelumnya. Kemudian ketika integrasi sudah selesai dilakukan, ternyata kebutuhan bisnisnya sudah berubah lagi. Perubahan ini tentu sedikit banyak menuntut perubahan pada satu atau lebih sistem aplikasi yang terkait. Sehingga kemudian ada perubahan pada sistem aplikasinya, maka hal ini juga akan berdampak kepada diperlukannya penyesuaian pada integrasinya. Dan seterusnya setiap ada proyek perubahan pada salah satu sistem, maka akan diinisiasi pula proyek integrasi nya. Hal inilah yang membuat sebagian pihak frustasi dan beranggapan bahwa integrasi sistem itu merupakan proyek tanpa akhir, it’s a never ending project. Sebagian pihak tersebut pasrah dengan adanya fenomena kepulauan informasi (islands of informations) sehingga akhirnya menimbulkan masalah-masalah lain seperti redundansi data, tingginya effort untuk rekonsiliasi, serta rendahnya integritas data.
Untuk menganalisis apakah anggapan tersebut di atas memang benar-benar tak terhindarkan, ada baiknya kita coba identifikasi opsi-opsi yang mungkin dilakukan terkait permasalahan integrasi sistem ini.
Opsi Pertama merupakan opsi yang paling simple dari sisi teknis, yaitu tidak melakukan integrasi karena tidak ada yang perlu diintegrasikan. Mengapa? Karena seluruh kebutuhan dipenuhi oleh sebuah sistem. Sehingga dengan opsi ini tidak muncul kebutuhan perbaikan jembatan antar pulau informasi (aplikasi), karena semuanya berada pada satu pulau. Namun demikian dapat dikatakan hampir mustahil untuk mendapatkan solusi untuk seluruh kebutuhan organisasi dari sebuah produk off-the-shelf secara lengkap. Disamping itu opsi ini juga menyebabkan tingginya ketergantungan kepada vendor, proprietary interfaces, dan juga mungkin untuk beberapa kebutuhan tertentu solusi yang ditawarkan oleh produk tersebut bukanlah solusi terbaik (best of breed).
Opsi Kedua adalah dengan membeli suatu pre-designed gateway yang ditawarkan oleh beberapa supplier. Keuntungan dari opsi ini adalah biaya yang relatif lebih murah, yang sebenarnya wajar saja karena biaya pengembangan gateway oleh supplier ini dibagi ke seluruh pembelinya. Namun demikian opsi ini juga memiliki beberapa risiko seperti harus secara kontinu membeli update dari gateway tersebut setiap kali ada update versi dari sistem yang dihubungkan. Dan risiko yang paling berbahaya dari opsi ini adalah ketika hubungan antara 2 supplier sistem yang akan diintegrasikan itu bermasalah, maka gateway pun menjadi dalam bahaya.
Opsi Ketiga adalah membangun sendiri gateway antar pulau aplikasi yang ada. Keuntungan dari opsi ini tentu adalah kebebasan untuk melakukan kustomisasi sampai benar-benar sesuai dengan keinginan, dan dalam jangka pendek dapat memberikan manfaat strategis bagi perusahaan. Namun opsi ini memiliki risiko tinggi terhadap kemungkinan banyaknya permasalahan yang tidak/belum terlihat saat ini, terlalu banyaknya keinginan, kemungkinan bergantung pada suatu antarmuka sistem yang bersifat proprietary, tingkat stabilitas sistem yang rendah dan tentunya effort pemeliharaan yang tinggi. Bayangkan harus memelihara interface dari sejumlah sistem yang dibuat oleh pihak-pihak yang beragam dengan teknik interfacing yang berbeda-beda, pengguna yang berbeda, dst. Akan benar-benar menjadi pekerjaan yang super melelahkan bagi pengelola TI perusahaan.
Disamping ketiga opsi tersebut di atas, belakangan tersedia pula opsi keempat yaitu menggunakan “jembatan” yang bersifat terbuka (open system) yang berorientasi pada layanan (Service Oriented Architecture/SOA). Menggunakan opsi ini, mempermudah kita dalam memelihara integrasi sistem, karena opsi ini menyediakan sebuah jembatan yang dapat dipakai bersama untuk berbagi layanan antar sistem. Layanan yang dapat dibagi-pakai itu “cukup” didaftarkan pada jembatan bersama itu sehingga dapat dipakai oleh sistem lain yang membutuhkan. Opsi ini dapat menyelamatkan perusahaan dari proyek integrasi tanpa akhir. Dengan cara ini, pilihan best of breed (memilih sistem terbaik pada sektornya masing-masing) pun menjadi memiliki solusi. Pemeliharaan sistem pun akan menjadi lebih mudah, karena fokus dapat diarahkan hanya pada jembatan bersama itu, atau sering juga diistilahkan dengan Enterprise Service Bus (ESB). Namun demikian, sebagaimana opsi-opsi lainnya, opsi ini juga memiliki kelemahan karena fleksibilitas yang ditawarkan tersebut dapat menyebabkan degradasi performansi tertentu. Tentu proses yang melalui suatu custom interface seperti ini akan memiliki performansi yang lebih rendah dibanding kalau menggunakan sesuatu yang sudah fixed. Opsi ini juga memiliki syarat bahwa semua sistem yang akan diintegrasikan juga harus mendukung SOA, jika tidak maka perlu langkah-langkah transisi yang harus dilalui sampai terbentuk benar-benar SOA based system integration.
Jadi dari opsi-opsi tersebut diatas terlihat bahwa opsi keempat adalah opsi yang paling mungkin untuk menghindarkan perusahaan dari usaha integrasi yang melelahkan dan tanpa akhir, walaupun effort yang dibutuhkan di awal cukup besar. Namun ketika sudah terbentuk sebuah sistem yang terintegrasi berbasis SOA, maka persoalan integrasi akan terasa tidak seruwet sebelumnya. Apalagi kalau opsi keempat ini misalnya dikombinasikan dengan opsi pertama, yaitu mengusahakan sebanyak mungkin sistem sudah dalam “satu pulau” in itself (misal: paket ERP tertentu). Baru kemudian sistem-sistem sisanya diintegrasikan dengan keseluruhan sistem secara enterprise-wide dengan berbasis pada opsi keempat ini. Dengan demikian kinerja sistem pun juga tidak terlalu terganggu. Opsi ini memberikan harapan bahwa integrasi bukanlah sebuah proyek tanpa akhir. Walaupun tentu saja tidak ada solusi generik yang dapat tepat untuk semua sistuasi dan organisasi. Dan, untuk dapat sukses menerapkan opsi ini terdapat critical success factors baik teknis dan nonteknis yang perlu diperhatikan. Semoga dapat saya lanjutkan pada tulisan lainnya. Semoga bermanfaat.[adm/manajemen-ti]
Oleh: Umar Alhabsyi, ST, MT, CISA, CRISC.
Sumber: Manajemen-TI
Catatan Umar Alhabsyi 