3 Konsep Sistem Terintegrasi Posted on : 5/22/2009 10:43:00 AM

Dalam konteks sistem informasi, sistem terintegrasi (integrated system) merupakan sebuah rangkaian proses untuk menghubungkan beberapa sistem-sistem komputerisasi dan software aplikasi baik secara fisik maupun secara fungsional. Sistem terintegrasi akan menggabungkan komponen sub-sub sistem ke dalam satu sistem dan menjamin fungsi-fungsi dari sub sistem tersebut sebagai satu kesatuan sistem.

Sistem terintegrasi merupakan tantangan menarik dalam software development karena pengembangannya harus terus mengacu pada konsistensi sistem, agar sub-sub sistem yang sudah ada dan tetap dimanfaatkan secara operasional masih tetap berfungsi sebagaimana mestinya baik ketika proses mengintegrasikan sistem maupun setelah terintegrasi. Tantangannya adalah bagaimana merancang sebuah mekanisme mengintegrasikan sistem-sistem tersebut dengan effort paling minimal – bahkan jika diperlukan, tidak harus melakukan refactoring atau re-developing lagi sistem-sistem yang sudah ada.

Ada beberapa metode yang dapat dipergunakan dalam membangun sistem terintegrasi, sebagaimana yang direferensikan berdasarkan artikel dari Wikipedia yaitu :

• Vertical Integration, merupakan proses mengintegrasikan sub-sub sistem berdasarkan fungsionalitas dengan menghubungkan sub-sub sistem yang sudah ada tersebut supaya bisa berinteraksi dengan sistem terpusat dengan tetap berpijak pada arsitektur sub sistem yang lama. Metode ini memiliki keuntungan yaitu dapat dilakukan dengan cepat dan hanya melibatkan beberapa entitas development yang terkait dalam proses pembuatan sistem lama. Kelemahannya, metode ini tidak memungkinkan untuk mengimplementasikan fungsi-fungsi baru atau proses bisnis baru ke dalam sub-sistem yang sudah ada – karena effort lebih tinggi ada di proses “mempelajari” arsitektur sistem lama dan menjadikannya acuan untuk membuat sistem terintegrasi. Untuk menghadirkan ekspansi fungsionalitas atau proses bisnis baru adalah harus membuat sub-sistem baru.
• Star Integration, atau lebih dikenal sebagai spaghetti integration, adalah proses mengintegrasikan sistem dengan cara menghubungkan satu sub sistem ke semua sub-sub sistem lainnya. Sebuah fungsi bisnis yang diimplementasikan dalam sebuah sub sistem akan di-broadcast ke semua sub-sub sistem lain yang dependen terhadap fungsi bisnis tersebut supaya dapat dipergunakan sebagaimana mestinya. Untuk integrasi sistem dengan ruang lingkup kecil atau menengah dan dengan pemisahan fungsi bisnis yang jelas dan spesifik, metode integrasi ini layak untuk dipertimbangkan. Namun jika fungsi bisnis banyak terlibat di beberapa sub sistem secara dependen, pada akhir proses integrasi sistem akan terlihat sedikit “kekacauan” dalam diagram – proses interkoneksi antar sub sistem akan tampak seperti spaghetti. Efeknya, biaya perawatan dan ekspansi sistem di masa yang akan datang akan memerlukan effort yang sangat berat untuk mempelajari skema integrasi sistem berikut dependency-nya.
• Horizontal Integration, atau ada yang mengistilahkan dengan Enterprise Service Bus (ESB), merupakan sebuah metode yang mengintegrasikan sistem dengan cara membuat suatu layer khusus yang berfungsi sebagai interpreter, dimana semua sub-sub sistem yang sudah ada akan berkomunikasi ke layer tersebut. Model ini lebih menawarkan fleksibilitas dan menghemat biaya integrasi, karena yang perlu difokuskan dalam implementasi proses pengintegrasian hanya layer interpreter tersebut.  Untuk menangani ekspansi proses bisnis juga hanya perlu diimplementasikan di layer interpreter itu juga, dan sub sistem baru yang akan menangani interface dari proses bisnis ekstensi tersebut akan berkomunikasi langsung ke layer dan layer akan menyediakan keperluan-keperluan data/interface untuk sub sistem lain yang memerlukannya.

Metode Enterprise Service Bus (ESB) ini – seperti yang dilansir dari Wikipedia juga – memiliki banyak kelebihan jika diadopsi dalam merancang arsitektur sistem terintegrasi, yaitu antara lain :

1. Lebih cepat dalam melakukan penyesuaian dengan sistem yang telah ada
2. Meningkatkan fleksibilitas, mudah untuk diperbaharui mengikuti perubahan keperluan sistem (system requirements)
3. Membuat standar sistem sehingga bisa diaplikasikan di sub sistem mana pun
4. Porsi pekerjaan software development lebih banyak di “konfigurasi” daripada “menulis code” untuk integrasi
5. Dapat diterapkan mulai ruang lingkup kecil hingga di level enterprise

Namun metode horizontal integration atau Enterprise System Bus (ESB) yang tampaknya ideal ini bukan berarti tidak ada kelemahan. Beberapa kelemahan yang cukup signifikan pengaruhnya antara lain :

1. Pembuatan standar sistem dalam Enterprise Message Model banyak berkutat di aspek analisis dan manajerial, biaya analisis benar-benar tinggi karena perlu berkolaborasi dengan analis-analis yang bertanggung jawab terhadap arsitektur dan desain sistem-sistem yang telah ada.
2. Secara khusus memerlukan perangkat keras (hardware) yang spesifik, seperti misalnya business-logic-server yang independen dan tidak integral dengan salah satu atau sebagian dari sub sistem yang telah ada.
3. Perlu tambahan tenaga (SDM) berupa Middleware Analyst yang akan mengkonfigurasi, merawat, dan mengoperasikan layer Enterprise Service Bus.
4. Karena biasanya ESB mempergunakan XML sebagai bahasa komunikasi antar sistem, tentu akan memerlukan resources dan komputasi berlebih untuk melakukan parsing-reparsing dalam komunikasi data.
5. Memerlukan effort yang cukup tinggi dalam mengimplementasikan ESB karena cukup banyak layer/tingkatan aplikasi yang harus ditangani, tidak hanya aplikasi-aplikasi interface dari sub-sub sistem saja, melainkan juga layer interpreter yang juga memiliki karakteristik sebagai aplikasi juga.

Pada akhir kisah, merancang dan membuat sebuah sistem terintegrasi -- memang bukan merupakan pekerjaan yang ringan. Apalagi kalau sejak awal pengembangan sistem-sistem terpisah yg sudah ada itu tidak dirancang untuk saling diintegrasikan satu sama lain. 

Tapi itulah hidup..., kita tidak bisa tau (sistem kita) besok bakal jadi bagaimana -- terus berkembang, atau berakhir di rak-rak penyimpanan CD usang di ruang arsip yang berdebu.

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

0 Dampak Evaluasi Implementasi dalam SDLC Posted on : 5/01/2009 06:11:00 PM

Di facebook gw, ada message di inbox yg berasal dari salah satu friend gw. Isinya *dia nanya* begini :

Maaf baru aja add tp dah repoti

need help u makalah gw, sebenernya sumber kesalahan suaru software tu dari mananya? apakah selalu desainnya, atau mungkin ga implementasinya? need referensi yang sahih buat dasarnya

thx 4 ur att.

Gw bukan mo mengomentari "kenapa beliau ngga nanya via imel aja? tp kenapa lewat FB yg mana fungsi utamanya bukan untuk imel-imel-an, melainkan untuk narcis-narcis-an.." ~ bukan. Gw mo nyoba jawab pertanyaan dia, coz sebenarnya gw juga sering (SERING-BANGEDD) mengalami masalah berupa kesalahan di software yg tim gw bikin, itu sebenarnya karena kita kurang evaluasi di faktor mana-nya?

Kira-kira begini hasil pemikiran gw :

Kalo dirunut-runut, ada beberapa tahap dasar dari sebuah siklus pengembangan sistem (SDLC), yaitu :

1. Perencanaan
2. Analisis
3. Desain
4. Konstruksi
5. Implementasi
6. Maintenance/support

Produk sistem yang dihasilkan itu sendiri, akan dinikmati oleh user di dalam fase IMPLEMENTASI (beda artinya dengan KONSTRUKSI -- walau banyak miskonsepsi mengenai ini dalam materi-materi Rekayasa Perangkat Lunak, bahwa proses "coding" itu adalah proses "implementasi". Bukan! Itu konstruksi.).

Nah, masalahnya -- seperti case yang coba dibedah temen gw tsb, kalo ada kesalahan dalam suatu produk software -- itu yang salah ada di fase mana?

Hmm... jawabannya : semua fase dalam SDLC selalu menimbulkan potensi munculnya sebuah kesalahan.

Yaa, kita ngga perlu membahas kalo programmer juga manusia, punya rasa punya hati, juga punya khilaf ^_^ ~ itu manusiawi. Tapi mari sekali-sekali kita simak bagaimana sebenarnya SDLC itu sendiri. Silakan perhatikan gambar di bawah ini : 

Dari gambar di atas, dapat dideduksikan bahwa sebuah "perulangan" fase terjadi jika : 

• kesalahan program (error/bug)
• ketidakcocokan solusi sistem (software) dengan teknologi baru
• terdapat masalah-masalah dan keperluan bisnis yang baru
• solusi sistem (software) sudah tidak layak lagi

Untuk proses terjadinya "revisi" karena kesalahan program, step dalam SDLC yang harus di-ulangi adalah di fase KONSTRUKSI. Artinya, perbaiki code atau mungkin coding ulang.

Sedangkan kalo ketidak-cocokan solusi dengan teknologi baru -- misalnya, ekspansi pembayaran cash menjadi pembayaran debit/kartu kredit atau karena upgrading DBMS atau karena pengen dirombak ke platform teknologi terbaru (contohnya, yg tadinya di-coding-in under DOS menjadi di-coding-in under Windows, atau dibikin dari VB6 pengen diganti jadi .NET) -- fase DESAIN harus diulangi dan implikasinya, fase KONSTRUKSI juga harus diulangi.

Kalo terdapat masalah-masalah dan proses bisnis baru? Misalnya: ternyata sistem yg udah terimplementasi dengan baik ini diharuskan TERINTEGRASI dengan sistem di atasnya yg lebih besar; atau terdapat penambahan beberapa requirement baru yang belum terfasilitasi di sistem existing. Kalo itu yang terjadi, proses SDLC mau-ngga-mau harus diulangi dari fase ANALISIS, trus DESAIN lagi, trus CODING lagi deh...

Dan yang paling parah, yg ini nih : ternyata setelah IMPLEMENTASI sekian tahun lamanya, solusi sistem yang terimplementasi di aplikasi existing ini udah bener-bener usang dan ngga layak pakai. Mau tetap dipertahankan untuk dioperasikan, salah. Kalo itu yang terjadi, PERENCANAAN ULANG! ~ tapi, diambil sisi positifnya aja. Perencanaan ulang dan mengulang segalanya dari awal lagi, kan artinya PROJECT BARU. hehehe... loemayan laah daripada loe manyun. ^_^

Sebagaimana lagu PeterPan, memang benar bahwa TAK ADA YANG ABADI. Bahkan sistem dan aplikasi. Tahun 2000 lalu, seiring dengan launching-nya Windows Millennium, Bill Gates mengatakan : DOS udah mati. Sah-sah saja. Ngga ada yang benar-benar perlu disesali.

Kalo dapat komplain dari end-user atau stakeholder pemesan sistem yang kita bangun, syukurilah... Itu artinya kita tetap menjaga relasi dengan dia dan menjaga perputaran siklus development kita tetap berjalan. Stakeholder yang bijaksana, tentunya mengerti sedalam-dalamnya bahwa setiap terjadi perubahan sistem PASCA-IMPLEMENTASI akibat ini-itu, pasti ada biayanya. Dan pada kenyataannya pun, kita sebagai system-developer juga sering mbikin proposal bukan cuman judulnya "proposal pembuatan sistem" atau "proposal pengembangan sistem" -- tapi juga "proposal pemutakhiran sistem". Waaa, sering bangedd nie muncul di Media Indonesia tender-tender di instansi pemerintah yang bertemakan PEMUTAKHIRAN. Artinya : update sistem lama, entah starting point-nya dari re-code, re-design, re-analysis, atau ... REVOLUSI!

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani