Prosiding Seminar Nasional Manajemen Teknologi XX Program Studi MMT-ITS, Surabaya 1 Februari 2014

Transkripsi

1 IMPLEMENTASI ENTERPRISE ARCHITECTURE INTEGRATION (EAI) PADA SISTEM INFORMASI MILIK GUDANG FARMASI KESEHATAN DAN PUSKESMAS DI DINAS KESEHATAN PEMERINTAH KABUPATEN SIDOARJO Rachmat Kukuh Rahadiansyah 1) dan Febriliyan Samopa 2) 1) Program Studi Magister Manajemen Teknologi, Institut Teknologi Sepuluh Nopember, Jl. Cokroaminoto 12A, Surabaya, 60264, Indonesia 2) Jurusan Sistem Informasi, Institut Teknologi Sepuluh Nopember ABSTRAK Gudang Farmasi Kesehatan (GFK) Sidoarjo merupakan salah satu unit pelaksana teknis milik Dinas Kesehatan (Dinkes) Pemerintah Kabupaten Sidoarjo. GFK berfungsi sebagai pengendali distribusi obat di semua Puskesmas di Sidoarjo. GFK selaku pihak berwenang memiliki kebutuhan untuk memantau (monitoring) setiap kegiatan di Puskesmas. Kebutuhan akan kegiatan pemantauan inilah yang membuat integrasi sistem antara GFK dan Puskesmas menjadi suatu keharusan. Sistem terintegrasi dapat diwujudkan dengan menerapkan metode Enterprise Application Integration (EAI). Salah satu area implementasi EAI adalah di level data. Data-level EAI dapat mensinkronisasi data antar dua sistem yang berbeda (GFK dan Puskesmas) dengan menggunakan metode Pull Request. Diharapkan dengan terwujudnya integrasi sistem ini dapat memenuhi kebutuhan GFK yang berhubungan dengan pemantauan kegiatan di Puskesmas. Hasil penelitian menunjukkan bahwa EAI dapat menjadi solusi untuk memenuhi kebutuhan GFK, terutama dalam hal pemantauan obat. Pengujian non-fungsionalitas membuktikan bahwa metode Profiling dapat digunakan untuk mengetahui berapa lama waktu yang dibutuhkan untuk satu kali proses pulling data, yaitu kurang dari 1 menit (berkisar antara 0,05 0,3 detik). Kata kunci: Enterprise Application Integration, Integrasi Sistem, Pull Request PENDAHULUAN Gudang Farmasi Kesehatan (GFK) Sidoarjo merupakan salah satu unit pelaksana teknis milik Dinas Kesehatan (Dinkes) Pemerintah Kabupaten Sidoarjo. GFK bertugas sebagai pengendali distribusi obat semua Puskesmas di Sidoarjo. GFK menyimpan ± 400 jenis obat yang harus didistribusikan ke 25 Puskesmas. Puskesmas sendiri mengelola ± 350 jenis obat, untuk kemudian didistribusikan kepada masyarakat. Saat ini, GFK dan beberapa Puskesmas telah memiliki aplikasi Sistem Informasi (SI)- nya masing-masing, namun keduanya masih belum saling terintegrasi. Aplikasi SI milik GFK hanya mengelola proses bisnis di dalam GFK saja. Aplikasi SI milik Puskesmas pun hanya mengelola proses bisnis di dalam Puskesmas saja. GFK selaku distributor obat berwenang memiliki kebutuhan untuk memantau persediaan obat di setiap Puskesmas miliknya. Diantara kebutuhan tersebut adalah meminimalkan kecurangan yang dilakukan Puskesmas saat mendistribusikan obat kepada masyarakat, ikut serta secara langsung mengontrol obat yang telah kadaluarsa, dan mengetahui kecenderungan (trend) obat di suatu wilayah. Kebutuhan GFK inilah yang membuat integrasi sistem di GFK dan di Puskesmas menjadi suatu keharusan. C-3-1

2 Merujuk pada literatur-literatur tentang integrasi sistem, penulis menemukan bahwa teori / metode yang cocok sebagai solusi atas permasalahan ini adalah Enterprise Application Integration (EAI). Dengan menerapkan EAI, sistem yang terintegrasi dapat diwujudkan. Diharapkan dengan terwujudnya integrasi sistem ini dapat memenuhi kebutuhan-kebutuhan GFK yang selama ini belum bisa terwujud saat integrasi sistem belum ada. METODE Untuk menjaga agar penelitian ini berjalan dengan semestinya, dan mendapatkan hasil yang diharapkan, maka perlu adanya metodologi penelitian. Adapun metodologi yang dipakai dalam penelitian ini adalah 12-steps program yang dicetuskan oleh David S. Linthicum dalam bukunya: Enterprise Architecture Integration [1999]. Gambar 1 di bawah ini adalah flowchart dari metodologi penelitian yang penulis gunakan. Adapun cara menentukan di level mana EAI harus diimplementasikan ada pada Gambar 2. Berhasil tidaknya suatu proyek sistem terintegrasi, bergantung kepada seberapa dalam pengembang proyek menguasai teori dan metode Enterprise Architectur Integration (EAI). Istilah EAI secara umum digunakan untuk mendeskripsikan semua metode yang digunakan untuk menghubungkan berbagai sistem yang berbeda, agar tidak terjadi spaghetti architecture akibat dari monopoli API tunggal dari suatu sistem. Kesimpulannya, EAI adalah solusi bagi siapa saja yang ingin agar berbagai sistem (software) dalam organisasinya menjadi saling terintegrasi. Menurut Linthicum (1999 : 21 23), terdapat 4 area yang bisa digunakan untuk mengimplementasikan EAI, yaitu: 1. Data-Level 2. Application Interface-Level 3. Method-Level 4. User Interface-Level Requirements Gathering 1. Studi Literatur 2. Memahami Domain Permasalahan System Analysis and Design 3. Memahami Data 4. Identifikasi Application Interface 5. Identifikasi Business Events 6. Identifikasi Skenario Transformasi Data 7. Memetakan Pergerakan Informasi Application Development 8. Mengimplementasikan Teknologi Testing and Implementation 9. Uji Coba Sistem 10. Mempertimbangkan Performa Sistem 11. Mendefinisikan Nilai Bisnis Maintenance 12. Membuat Prosedur Maintenance Gambar 1. Metodologi Pengembangan EAI C-3-2

3 Mulai Logic aplikasi boleh berubah Tersedia API pada aplikasi Mau membuat API sendiri Hanya butuh data tanpa proses bisnis Application Interface-Level EAI Membuat API Mempersiapkan database migration tool Membuat method warehouse UI aplikasi bisa di screen scrapping Data-Level EAI Method-Level EAI Screen scrapping / mapping Butuh integrasi dengan proses bisnis User Interface-Level EAI Selesai Gambar 2. Penentuan Level Implementasi EAI Tabel 1. Ringkasan Data-Level EAI Data-Level EAI Kelebihan / Kemudahan Kekurangan / Kesulitan Kondisi-kondisi yang harus dipenuhi Keterangan lain Produk / Hasil Akhir 1. Sudah tersedia banyak tool untuk membantu integrasi data antar database. 2. Mengakses informasi dalam database bisa dilakukan tanpa harus mengubah struktur database itu sendiri maupun sisi logic (source code) aplikasi. 3. Sisi logic (source code) aplikasi hampir tidak perlu berubah, itu sebabnya perusahaan tidak perlu khawatir harus melakukan testing ulang pada aplikasi. 1. Database yang ada dalam perusahaan bisa sangat beragam, jumlah tabelnya pun bisa ratusan, dan didalamnya masih ada ratusan constraint, view, trigger, function, dan procedure yang harus dipahami oleh pengembang 2. Pengembang juga harus menentukan frekuensi data, apakah real-time, in-time, atau one time. 3. Data-level EAI hanya menyediakan integrasi dalam bentuk data saja, tanpa ada proses bisnis. 1. Data-level EAI baru bisa dijadikan solusi jika mengubah logic / source code aplikasi tidak bisa dilakukan. 2. Data-level EAI baru bisa terwujud jika pengembang sudah memahami teknologi database yang digunakan, kamus data seluruh tabel beserta constraint-nya, beserta aliran informasi dalam perusahaan. Pada prakteknya, sangat sulit mengintegrasikan sistem jika hanya bermodal data saja. Integrasi sistem membutuhkan data dan proses bisnis (application logic). Itu sebabnya solusi data-level EAI ini biasanya diimplementasikan bersama dengan method-level EAI. Sebuah middle-tier berupa database migration software, yang berfungsi untuk mengekstrak, memformat, dan meng-update data dari satu database aplikasi ke database aplikasi lain. C-3-3

4 Kelebihan / Kemudahan Kekurangan / Kesulitan Kondisi-kondisi yang harus dipenuhi Keterangan lain - tidak ada - Produk / Hasil Akhir Tabel 2. Rangkuman Application Interface-Level EAI Application Interface-Level EAI 1. Saat ini, sudah banyak aplikasi dilevel enterprise yang sudah siap berbagi data dan proses bisnis dengan cara menyediakan API. 2. Jika aplikasi tidak menyediakan API, pengembang tetap masih dimudahkan dengan banyaknya framework ataupun tool untuk membuat API. 1. Vendor aplikasi harus sadar pentingnya menyediakan API dalam aplikasi buatannya. 2. Jika aplikasi tidak menyediakan API, maka pengembang harus membuat API tersebut. 1. Saat data-level EAI tidak bisa menjadi solusi (karena database terlalu kompleks dan integrasi sistem membutuhkan informasi tidak hanya data, tetapi juga proses bisnis), maka application interface-level EAI ini bisa menjadi solusi alternatif 2. Informasi yang dihasilkan dari pemanggilan API harus diolah oleh sebuah middleware (bisa berupa message broker, message queuing, atau application server) untuk kemudian ditransfer ke sistem tujuan. Sistem / aplikasi sumber (source system) menghasilkan informasi yang diminta oleh sistem / aplikasi tujuan ( target system) dengan cara mengonsumsi API yang disediakan. Informasi yang dihasilkan akan diantrikan dan ditransfer via middleware. Tabel 3. Rangkuman Method-Level EAI Method-Level EAI Kelebihan / Kemudahan Kekurangan / Kesulitan Kondisi-kondisi yang harus dipenuhi 1. Mengintegrasikan sistem berdasarkan pada method (proses bisnis) aplikasi tidak hanya menciptakan kumpulan method yang siap untuk di-share, tapi juga menciptakan infrastruktur yang lebih handal. 2. Produk akhir dari method-level EAI ini (berupa method warehouse) adalah wadah yang tepat bagi method aplikasi yang tidak hanya reuse, tetapi juga siap untuk di-share, di suatu server yang tersentralisasi. 1. Pengembangan method yang reuse, siap di-share, dan tersentralisasi ini membutuhkan re-develop, re-test, dan re-deployement. Dimana kesemua hal tersebut membutuhkan waktu yang lama dan biaya yang besar. 2. Solusi method-level EAI ini juga termasuk yang paling sering gagal. Alasan gagalnya pun beragam, mulai dari infrastruktur yang belum siap sampai konflik kepentingan internal. 1. Untuk mensukseskan solusi ini, semua aplikasi yang ada harus terikat (saling terhubung) agar proses sharing proses bisnis berjalan lancar. 2. Method yang sudah jadi harus disimpan dalam sebuah distributed objects, seperti CORBA atau COM. Keterangan lain - tidak ada - Produk / Hasil Akhir Method Warehouse, adalah wadah tersentralisasi bagi method yang reuse dan siap untuk di share oleh aplikasi yang membutuhkan. C-3-4

5 Tabel 4. Rangkuman User Interface-Level EAI User Interface-Level EAI Kelebihan / Kemudahan Kekurangan / Kesulitan Kondisi-kondisi yang harus dipenuhi Keterangan lain Produk / Hasil Akhir 1. Solusi ini menjembatani apa yang tidak ada pada solusi-solusi EAI di atas, yaitu mengintegrasikan sistem dengan menyediakan sebuah user interface (UI). 2. Selama proses implementasinya, solusi ini sama sekali tidak membutuhkan pengubahan logic (source code) aplikasi. 3. Sudah tersedia tool untuk melakukan proses screen scrapping. Pengembang harus mengetahui secara detil kegunaan tiap UI yang ada, aliran input dan output data yang dihasilkan oleh UI yang bersangkutan, termasuk juga aliran informasi dan transformasinya ( raw data atau diolah terlebih dahulu) yang masuk ke database. 1. Jika perusahaan tidak punya waktu dan biaya yang cukup, maka UI-level EAI ini bisa menjadi solusi untuk Application-level EAI. 2. Solusi ini pun bisa menjadi alternatif jika memahami database aplikasi adalah hal yang hampir mustahil, yang menyebabkan data-level EAI tidak bisa dilakukan. 3. Solusi ini adalah solusi yang paling konvensional, sehingga harus menjadi opsi terakhir dalam EAI. Sekilas memang UI-level EAI mirip dengan Application Interface-level EAI, namun UI-level EAI mengolah proses bisnis dengan berfokus pada UI yang ada, bukan pada interface aplikasi ataupun database. Screen catalog, adalah wadah untuk hasil dari proses screen scrapping. HASIL DAN PEMBAHASAN Dengan mengikuti alur Gambar 2 di atas, ditambah dengan fakta dan data seputar sistem yang saat ini sedang berlangsung sebagai berikut: 1. Aplikasi SI yang ada tidak boleh terganggu jalannya / tidak boleh mengubah logic aplikasi. 2. berubahnya logic aplikasi, membuat pengembangan EAI ini tidak bisa melibatkan proses bisnis yang sedang berlangsung. 3. Aplikasi SI yang ada juga tidak bisa di-screen scrapping oleh tool bantu apapun. 4. tersedia API dalam aplikasi SI yang ada saat ini. Dapat disimpulkan bahwa implementasi EAI pada SI milik GFK dan Puskesmas akan dilakukan di level data. Ditinjau dari berbagai sumber tentang EAI dan teknologi yang bisa digunakan, penulis menemukan metode teknis yang cocok digunakan untuk mewujudkan integrasi sistem di level data adalah Pull Request. Pengujian implementasi EAI di level data ini dibagi menjadi 2 bagian, yaitu: 1. Pengujian Fungsional a. Pengujian Manual b. Pengujian Otomatis 2. Pengujian Non-Fungsional C-3-5

6 Pengujian Fungsional Dalam pengujian fungsional ini penulis akan menguji apakah implementasi di level data pada SI milik GFK dan Puskesmas dapat dilakukan. Pengujian fungsional ini akan dibagi menjadi 2 bagian, yaitu: 1. Pengujian Manual Jenis pengujian fungsional yang akan menunjukkan bagaimana sisi teknis sinkronisasi di level data bisa terwujud. 2. Pengujian Otomatis Jenis pengujian fungsionalitas yang akan mengotomatisasi proses sinkronisasi data, sehingga pengguna aplikasi tidak perlu lagi melakukan sinkronisasi data secara manual. Dalam pengujian fungsionalitas ini akan diketahui bagaimana sinkronisasi data di level data bisa terwujud. Gambar 3 menunjukkan sisi teknis sinkronisasi data terjadi pada salah satu proses bisnis GFK: Pengeluaran Obat dari GFK ke Puskesmas. Gambar 4 menunjukkan tabel EAI_Dictionary yang digunakan sebagai pencatat data jenis sinkronisasi yang dilakukan dan kapan sinkronisasi tersebut terjadi. Gambar 5 menunjukkan bagimana proses pulling data terjadi secara otomatis setelah modul pulling data dijadikan sebagai background process. Pengujian Non-Fungsional Setelah 2 pengujian fungsional (manual dan otomatis) di atas, maka perlu juga dilakukan pengujian non-fungsional. Pengujian jenis ini dilakukan untuk mengetahui dengan tepat lama waktu proses pull-data otomatis seharusnya dilakukan (Gambar 6). Untuk melakukan pengujian non-fungsional ini penulis menggunakan metode Profiling. Metode profiling ini bekerja dengan cara menghitung selisih waktu saat proses pulling data dimulai sampai selesai lalu mencatat keterangan selisih tersebut dalam sebuah log file. Gambar 3. Sinkronisasi Data Pengeluaran Obat C-3-6

7 Gambar 4. Tabel EAI_Dictionary Terisi History Sinkronisasi Gambar 5. Proses Pull Otomatis Terjadi KESIMPULAN DAN SARAN Gambar 6. Profiling dan Logging Berikut adalah kesimpulan dari penelitian ini: 1. Berdasarkan 12 langkah yang dicetuskan oleh Linthicum, implementasi EAI pada aplikasi SI milik GFK dan Puskesmas dapat dilakukan di level data. 2. Berdasarkan hasil analisa didapatkan bahwa metode teknis yang tepat adalah Pull Request 3. Pengujian sistem membuktikan bahwa EAI dapat menjadi solusi untuk memenuhi kebutuhan GFK, terutama dalam hal pemantauan obat. 4. Pengujian non-fungsionalitas membuktikan bahwa metode Profiling dapat digunakan untuk mengetahui berapa lama waktu yang dibutuhkan untuk satu kali proses pulling data. 5. Berdasarkan pengujian non-fungsionalitas juga diketahui bahwa jeda waktu yang dibutuhkan untuk 1 kali proses pulling data adalah di bawah 1 menit (berkisar antara 0,05 0,3 detik). C-3-7

8 Berikut adalah saran dari penulis agar penelitian seperti ini dan berikutnya lebih baik lagi: 1. Saat ini hanya pemantauan transaksi obat saja yang bisa disinkronisasi. Namun sebenarnya terdapat banyak kegiatan pemantauan yang bisa dilakukan oleh GFK terhadap Puskesmas, seperti pemantauan transaksi obat, pemantauan kegiatan administrasi, pemantauan produktivitas SDM, pemantauan kegiatan keuangan, dsb. 2. Bisa dilakukan pembuatan dashboard manajemen interaktif yang menampilkan kinerja tiap-tiap puskesmas yang sudah tersinkronisasi dengan GFK. DAFTAR PUSTAKA Achour, Mehdi., Betz, Friedhelm., dkk. (2013). PHP Manual. Eds: Olson, Philip. The PHP Documentation Group. Finkelstein, Clive. (2006). Enterprise Architecture for Integration, Artech House, London, UK. Gilmore, W. Jason. (2010). Beginning PHP and MySQL: From Novice to Professional, 4th Edition, Apress, USA. Linthicum, David S. (1999). Enterprise Application Integration, AddisonWesley. Sherif, Mostafa Hasyem. (2006), Handbook of Enterprise Integration, Auerbach Publications, Taylor and Francis Group, LLC., USA. Stair, Ralph., Reynolds, George. (2012). Fundamentals of Information System, 6th Edition, Course Technology, Boston, USA. Juric, Matjaz B., Loganathan, Ramesh., dkk. (2007). SOA Approach to Integration, PACKT Publishing, Birmingham, UK. Krafzig, Dirk., Banke, Karl., Slama, Dirk. (2005). Enterprise SOA: Service Oriented Architecture Best Practices. Pearson Education, Inc. C-3-8