Bab IV Pembentukan Arsitektur Integrasi
Bab ini memaparkan hasil evaluasi terhadap adanya kesenjangan/gap antara kondisi as-is dan to-be. Berdasarkan hasil evaluasi inilah dapat dibuat kebijakan untuk melakukan integrasi yang menghasilkan arsitektur integrasi teknis, layanan, informasi serta proses bisnis. Tahapan dan artifak yang dihasilkan dalam pembentukan arsitektur integrasi dapat dilihat pada Gambar IV.1 (4)(13).
Gambar IV.1 Tahapan Pembentukan Arsitektur Integrasi
84
85
IV.1 Mengevaluasi Gap Diantara Kondisi As-is dan To-be Pada bab sebelumnya telah dianalisis kondisi enterprise saat ini (as-is) serta kebutuhan sistem mendatang (to-be). Penilaian terhadap kondisi saat ini menunjukkan kapabilitas sistem yang sedang berjalan dan tentu saja terdapat kesenjangan (gap) diantara kondisi saat ini dengan kebutuhan untuk dapat mencapai kondisi ideal. Analisis kesenjangan dilakukan untuk melihat perbandingan antara kondisi saat ini dengan setelah penerapan arsitektur ideal. Melalui hasil evaluasi kesenjangan inilah nantinya akan dibuat kebijakan penyelesaian permasalahan integrasi.
IV.1.1 Perbandingan Data Berdasarkan matriks antara entitas dan fungsi bisnis (Gambar III.13) diperoleh gambaran ideal mengenai entitas-entitas data yang seharusnya diciptakan (created), digunakan (referenced) dan diperbaharui (updated) oleh fungsi bisnis. Berdasarkan matriks ini pula akan diidentifikasi gap antara kondisi yang sebenarnya terjadi dengan kondisi ideal. Keterhubungan antara fungsi bisnis dengan entitas yang terjadi pada kondisi saat ini digambarkan dengan sel berwarna gelap, sedangkan keterhubungan fungsi bisnis dengan entitas yang tidak terjadi saat ini digambarkan dengan sel berwarna terang (Gambar IV.2).
Gambar IV.2 menunjukkan bahwa entitas data yang dihasilkan dan digunakan pada sistem saat ini adalah pada fungsi penerimaan siswa/mahasiswa baru, kegiatan akademik, pengelolaan wisuda dan pembayaran biaya pendidikan. Aliran data yang disimbolkan dengan garis beranak panah menandakan bahwa suatu area sistem menggunakan data pada area sistem lainnya, sebagai contoh area sistem kedua yaitu akademik memiliki aliran data dari area sistem pertama yaitu penerimaan siswa/mahasiswa baru. Hal tersebut berarti bahwa sistem akademik menggunakan data pendaftar, jadwal usm dan hasil usm yang diciptakan pada sistem penerimaan siswa/mahasiswa baru.
86
Gambar IV.2 Gap Data
87
Matriks yang dihasilkan sebagai hasil analisis adanya gap pengelolaan data antara sistem yang telah berjalan dengan sistem yang diinginkan menunjukkan bahwa adanya data yang belum lengkap dalam menunjang bisnis secara menyeluruh dan juga terdapat pulau-pulau sistem yang perlu diintegrasikan karena saling terkait. Hal tersebut dapat dilihat pada Gambar IV.2 dengan adanya aliran data yang saling terkait diantara sistem. Melalui pemetaan yang telah dilakukan terhadap data pada aplikasi legacy dengan arsitektur ideal, ditemukan bahwa terdapat 4 entitas data dari keseluruhan 30 entitas data ideal atau 13.33 % yang belum tersedia pada aplikasi legacy. Jadi 86.67 % entitas data ideal sebenarnya telah dihasilkan dari aplikasi legacy. Entitas-entitas data yang belum tersedia tersebut adalah entitas jadwal usm, pangsa pasar, target dan perusahaan.
Permasalahan lain dari hasil pemetaan adalah adanya 5 atau 16.67 % entitas data acuan (master) yang dihasilkan secara berulang oleh sejumlah aplikasi legacy yaitu entitas pendaftar, mata kuliah, siswa, mahasiswa dan dosen. Sedangkan 83.33 % entitas-entitas lainnya dikelola secara mandiri oleh unit-unit organisasi sehingga memiliki beragam format dan tidak terintegrasi. Hal ini tentu saja merepotkan pengelolaan sistem karena seharusnya isi data yang sama dibuat berulang-ulang (terjadi redundansi). Berdasarkan hal inilah maka diperlukan integrasi data yang dikelola oleh aplikasi-aplikasi legacy.
IV.1.2 Perbandingan Aplikasi Berdasarkan matriks antara aplikasi dan fungsi bisnis (Gambar III.16) diperoleh gambaran ideal mengenai aplikasi-aplikasi yang seharusnya ada guna mendukung fungsi-fungsi bisnis. Berdasarkan matriks ini pula akan diidentifikasi gap antara kondisi yang sebenarnya terjadi dengan kondisi ideal. Keterhubungan antara aplikasi dan fungsi bisnis yang terjadi pada kondisi saat ini digambarkan dengan sel berwarna gelap, sedangkan keterhubungan fungsi bisnis dengan entitas yang tidak terjadi saat ini digambarkan dengan sel berwarna terang (Gambar IV.3). Aplikasi yang dihasilkan dan digunakan saat ini adalah pada fungsi penerimaan siswa/mahasiswa baru, kegiatan akademik, pengelolaan wisuda dan pembayaran biaya pendidikan. Matriks yang dihasilkan sebagai hasil analisis adanya gap
88
keberadaan aplikasi antara sistem yang telah berjalan dengan sistem yang diinginkan menunjukkan adanya aplikasi yang belum lengkap dalam menunjang bisnis secara menyeluruh.
Gambar IV.3 Gap Aplikasi
89
Tabel IV.1 Dampak Kandidat Aplikasi
Sistem Pendaftaran Calon Siswa/Mahasiswa Baru
Sistem Pengelolaan Pembayaran Pendaftaran Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa baru Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
Sistem Registrasi Ulang Siswa/Mahasiswa
Sistem Pembuatan KRS, KTS dan KTM Sistem Perwalian Sistem Perubahan Rencana Studi Sistem Penjadwalan KBM
Sistem Administrasi KBM
Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif) Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)
Sistem Pengelolaan Nilai
Sistem Pembuatan Kartu Hasil Studi
Sistem Administrasi Dosen
1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi keuangan LPP 2. Aplikasi keuangan ASM Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM Aplikasi akademik ASM Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM
X
X
Keterangan Diganti
Dimodifikasi
Aplikasi Legacy
Ditingkatkan
Kandidat Aplikasi
Dipertahankan
Dampak
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
X Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA.
X
X
X
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
X X
X
X
X
X
X
X
X
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
90
Tabel IV.1 Dampak Kandidat Aplikasi (Lanjutan)
Sistem Manajemen Kurikulum
Sistem Pelaporan Akademik
Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai
Sistem Administrasi Wisuda
Sistem Pelaporan Kegiatan Wisuda Sistem Pengelolaan Promosi Sistem Pelaporan Kegiatan Promosi Sistem Pengelolaan Dunia Industri Sistem Pengelolaan Kerjasama
1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM 1. Aplikasi akademik LPP 2. Aplikasi akademik ASM -
Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa
Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa
Diganti Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA.
X
Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA.
X
X
X
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA.
X
Pengembangan baru. Pengembangan baru. Pengembangan baru.
-
Pengembangan baru.
2.
Aplikasi akademik LPP Aplikasi akademik ASM
X
1. 2. 1.
Sistem Pengelolaan Pembayaran Honor Dosen
Keterangan
-
1. Sistem Pengelolaan Alumni
Dimodifikasi
Aplikasi Legacy
Ditingkatkan
Kandidat Aplikasi
Dipertahankan
Dampak
2.
1. 2.
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Pengembangan baru.
Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
X
X
X
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
Layanan aplikasi yang belum tersedia dalam sistem saat ini diantaranya adalah pelaksanaan usm, pengumuman hasil usm, pengawasan kbm, pengawasan ujian, pembuatan sk dosen, pelaksanaan promosi, pelaporan dan evaluasi kegiatan promosi, penetapan daftar nama dunia industri, pelaksanaan kerjasama dengan
91
dunia industri, pelaporan dan evaluasi kerjasama. Berdasarkan hasil pemetaaan antara aplikasi saat ini dengan aplikasi ideal maka dapat dianalisa dampak dari aplikasi yang terintegrasi serta enterprise-wide terhadap aplikasi legacy yang terdapat dalam IRC. Relasi antara aplikasi dalam arsitektur aplikasi dengan aplikasi legacy (Tabel IV.1) memiliki beberapa dampak yaitu : 1. Aplikasi legacy diganti oleh aplikasi dalam arsitektur aplikasi (completely replaced). 2. Aplikasi legacy dimodifikasi dalam lingkungan berbagi pakai bersama data (partially replaced). 3. Aplikasi legacy dipertahankan dengan peningkatan (retained). Terdapat 4 aplikasi dari total 29 aplikasi atau 13.79 % yang termasuk ke dalam pengembangan baru, yaitu aplikasi yang berhubungan dengan aplikasi promosi dan pengelolaan BKK. Sedangkan aplikasi lain sebesar 86.21 % dipertahankan atau dimodifikasi dari aplikasi lama (legacy) dengan melakukan integrasi.
IV.1.3 Perbandingan Teknologi Perbandingan dokumentasi teknologi yang ada dan digunakan saat ini dengan arsitektur teknologi ideal, diperoleh beberapa kesimpulan sebagai berikut : 1. Teknologi jaringan lokal (LAN) saat ini masih dapat digunakan untuk mendukung aplikasi dan data, namun perlu dipertimbangkan untuk meningkatkan konfigurasi jaringan sehingga dapat mendukung aplikasi berbasis internet. Saat ini teknologi jaringan internet telah tersedia namun hanya digunakan untuk kegiatan belajar mengajar dan belum dimanfaatkan untuk mendukung fungsi bisnis. 2. Distribusi data dan file saat ini sebagian besar terpusat di server, hal ini sangat membebani kerja server. Oleh karenanya perlu adanya pemisahan fungsi server sebagai penyedia layanan jaringan dengan penyedia data dan aplikasi. 3. Diperlukan middleware yang dapat mengkomunikasikan data dari basis data berbasis bahasa Clipper ke basis data SQL Server dan begitu juga sebaliknya. 4. Setiap aplikasi tidak menyediakan interface agar dapat berkomunikasi dengan aplikasi lain sehingga tidak dapat dilakukan integrasi antar aplikasi pada level interface.
92
IV.2 Pembentukan Arsitektur Integrasi Teknis Arsitektur integrasi teknis (Gambar IV.4) menyajikan building code bagi proyek integrasi karena berisi spesifikasi yang akan diacu oleh proyek saat memilih teknologi integrasi. Arsitektur ini terdiri atas tuntunan dan batasan rancangan mengenai bagaimana seharusnya aplikasi dikembangkan. Oleh karenanya, spesifikasi harus dapat mendefinisikan seluruh aspek arsitektur integrasi dan mudah diakses sehingga informasi dapat mudah ditemukan dan dipahami. Arsitektur teknis haruslah dikendalikan oleh business requirements dan mampu memenuhi kebutuhan di masa mendatang, sehingga mendefinisikan hal-hal berikut ini : 1. Layanan business-domain yang umum dan reusable yang dapat mendukung berbagai aplikasi. 2. Layanan teknis terstandarisasi dan umum yang dapat mendukung berbagai jenis integrasi baik yang berorientasi layanan, informasi maupun proses. 3. Service level yang harus didukung. 4. Framework keamanan yang komprehensif yang didasarkan pada kebijakan keamanan enterprise-wide yang jelas. 5. Fokus pada kemampuan untuk meningkatkan sistem informasi yang ada saat ini (legacy) dan juga produk sistem paket komersial guna menyediakan porsi
Business Process Integration Architecture
Information Integration Architecture
Service Integration Architecture
yang signifikan terhadap fungsionalitas aplikasi.
Gambar IV.4 Arsitektur Integrasi Teknis (4)
93
IV.2.1 Requirement Arsitektur Integrasi Tahapan ini didasarkan pada requirement bisnis dan hasil penilaian terhadap sistem dan teknologi integrasi saat ini, meliputi kebutuhan tipe-tipe layanan dan teknologi integrasi yang akan menjadi bagian dari infrastruktur dan juga mendefinisikan layanan-layanan yang dimanfaatkan oleh berbagai aplikasi yang berbeda, aplikasi yang perlu diintegrasikan dengan aplikasi lainnya dan jenis integrasi yang akan digunakan di enterprise.
IV.2.2 Tipe-tipe Integrasi Dalam menentukan kebutuhan arsitektur integrasi, organisasi dapat memulai dengan mengidentifikasi tipe-tipe integrasi yang perlu didukung. Hasil dari analisis terhadap pemodelan bisnis, kondisi sistem dan teknologi saat ini dan juga kebutuhan akan data, aplikasi dan teknologi yang dapat mendukung YPA sebagai satu enterprise digunakan untuk mendefinisikan kebutuhan dari tipe integrasi. Berdasarkan daftar urutan aplikasi bersifat enterprise yang memerlukan integrasi pada Tabel IV.1, maka hasil identifikasi tersebut digunakan sebagai dasar penentuan tipe integrasi pada Tabel IV.2. Nomor aplikasi pada tabel tersebut diperoleh dari hasil analisa kebutuhan akan aplikasi ideal bagi YPA yang terdaftar pada Tabel III.4.
Tabel IV.2 Tipe-tipe Integrasi No.
No. Aplikasi
1
1.1
Sistem Pendaftaran Calon Siswa/Mahasiswa Baru
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
2
1.2
Sistem Pengelolaan Pembayaran Pendaftaran
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
3
1.3
4
1.4
Kandidat Aplikasi
Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa baru Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
Tipe Integrasi
Information integration
Keterangan
Mengintegrasikan data dari seluruh unit organisasi
Aplikasi Legacy yang Diintegrasikan Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
-
Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
94
Tabel IV.2 Tipe-tipe Integrasi (Lanjutan) 5
No. Aplikasi 2.1
Sistem Registrasi Ulang Siswa/Mahasiswa
Tipe Integrasi Legacy integration
6
2.2
Sistem Pembuatan KRS, KTS dan KTM
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
7
2.3
Sistem Perwalian
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
8
2.4
Sistem Perubahan Rencana Studi
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
9
2.5
Sistem Penjadwalan KBM
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
10
2.6
Sistem Administrasi KBM
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
11
2.7
Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
12
2.8
Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
13
2.9
Sistem Pengelolaan Nilai
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
14
2.10
Sistem Pembuatan Kartu Hasil Studi
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
15
2.11
Sistem Administrasi Dosen
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
16
2.12
Sistem Manajemen Kurikulum
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
17
2.13
Sistem Pelaporan Akademik
Information integration
Mengintegrasikan data dari seluruh unit organisasi
18
3.1
Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
19
3.2
Sistem Administrasi Wisuda
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
No.
Kandidat Aplikasi
Keterangan Integrasi aplikasi yang telah ada (legacy application)
Aplikasi Legacy yang Diintegrasikan Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM
95
Tabel IV.2 Tipe-tipe Integrasi (Lanjutan) 19
No. Aplikasi 3.2
Sistem Administrasi Wisuda
Tipe Integrasi Legacy integration
20
3.3
Sistem Pelaporan Kegiatan Wisuda
Information integration
Mengintegrasikan data dari seluruh unit organisasi
21
5.3
Sistem Pengelolaan Alumni
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
22
5.4
Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA
Composite integration
Mengintegrasikan dengan komponen aplikasi yang baru akan dikembangkan
23
6.1
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
24
6.2
Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa Sistem Pengelolaan Pembayaran Honor Dosen
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
25
6.3
Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa
Information integration
Mengintegrasikan data dari seluruh unit organisasi
No.
Kandidat Aplikasi
Keterangan Integrasi aplikasi yang telah ada (legacy application)
Aplikasi Legacy yang Diintegrasikan Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
Merujuk Tabel IV.2 dan berdasarkan hasil analisa terhadap proses bisnis, kondisi sistem dan teknologi saat ini, maka kebutuhan YPA adalah melakukan integrasi terhadap aplikasi yang ada (legacy), integrasi data dari berbagai unit organisasi yang akan menghasilkan informasi terintegrasi, serta integrasi gabungan dengan aplikasi baru yang akan dikembangkan. Pada Tabel IV.2 jika diperhatikan, terdapat aplikasi yang tidak diintegrasikan yaitu aplikasi ujian saringan masuk karena kegiatan ujian saringan masuk hanya diperuntukkan bagi mahasiswa dalam jenjang pendidikan formal, sehingga hanya dikelola untuk unit organisasi ASM. Hal ini berpengaruh terhadap aplikasi yang mengelolanya dimana tidak ada kebutuhan integrasi dengan aplikasi lain. Integrasi aplikasi menjadi solusi bagi permasalahan di YPA karena adanya kebutuhan untuk tetap dapat menggunakan basis data dan layanan pada aplikasi yang ada (legacy) semaksimal mungkin, sehingga setiap unit organisasi dapat saling berbagi data dan proses tanpa
96
membuat perubahan terhadap aplikasi maupun struktur data secara terus-menerus untuk mengikuti kebutuhan bisnis.
IV.2.3 Layanan dan Teknologi Integrasi Arsitektur integrasi dapat terdiri atas sejumlah layanan integrasi yang berbeda, dan layanan-layanan ini dapat diimplementasikan dengan beragam teknologi. Arsitektur integrasi harus meliputi seluruh aspek integrasi yang diperlukan oleh organisasi sehingga didasarkan pada prinsip organisasi dan tidak ditujukan bagi pemilihan produk tertentu.
Gambar IV.5 Tipe-tipe Enterprise Application Integration (9) Sebelum melakukan integrasi, dalam hal ini adalah integrasi aplikasi, organisasi perlu memahami elemen proses dan data yang memerlukan integrasi, karena integrasi aplikasi dapat dilakukan pada berbagai level, yaitu (Gambar IV.5) : 1. Level data. Integrasi aplikasi level data (Gambar IV.6) merupakan proses serta teknik dan teknologi pemindahan data antar simpanan data. Level data menggambarkan ekstrasi informasi dari suatu basis data, pemrosesan informasi sesuai kebutuhan dan melakukan update pada basis data lain. Pengaksesan data dalam konteks integrasi aplikasi memerlukan keterhubungan antara lojik dari
97
aplikasi dan user interface guna dapat mengekstrasi atau mengisi data secara langsung ke dalam basis data.
Gambar IV.6 Integrasi Level Data (9) Terdapat banyak teknologi dan teknik untuk memindahkan data dari satu basis data ke basis data lain, diantaranya database replication software, message broker dan custom built. Software yang diletakkan antara basis data bertugas untuk melakukan ekstrasi, merubah format dan meng-update satu basis data sehingga dapat dipahami oleh basis data lain. Data direplikasi saat terdapat update pada tabel yang bersesuaian. Terdapat dua pendekatan integrasi aplikasi pada level data , yaitu (9) : b. Database-to-database Saling berbagi informasi pada level basis data, baik pada konfigurasi oneto-one, one-to-many, maupun many-to-many. Pendekatan bagi databaseto-database adalah dengan middleware basis data dan software replikasi basis data. c. Federated database Juga bekerja pada level basis data, namun tidak hanya melakukan replikasi data antara basis data, melainkan memperbolehkan pengaksesan sejumlah basis data dari berbagai brand, model skema menggunakan model basis data virtual. Model basis data virtual hanya terdapat pada perangkat lunak dan dipetakan pada basis data yang terhubung secara fisik. Penggunaan basis data virtual sebagai single point integrasi aplikasi, mengakses data dari sejumlah sistem melalui interface basis data tunggal. Manfaat dari
98
pendekatan ini adalah pada middleware untuk berbagi informasi antar aplikasi dan bukan pada custom solution. Middleware digunakan untuk menyembunyikan perbedaan dari basis data yang diintegrasikan.
2. Level application interface. Integrasi aplikasi pada level application interface (Gambar IV.7) merupakan interface yang di-expose dari packaged application atau custom application sedemikian sehingga aplikasi eksternal dapat memperoleh akses terhadap berbagai level atau layanan tanpa membuat perubahan terhadap aplikasi tersebut. Penyajian interface bertujuan untuk menyediakan akses terhadap proses bisnis dan data yang dienkapsulasi dalam aplikasi yang dibuat dan menyediakan mekanisme yang memungkinkan informasi yang dienkapsulasi dapat di-share.
Aplikasi API Sumber daya
Data
Lojik aplikasi
Middleware
Gambar IV.7 API Penghubung dengan Sumber Daya (9) Mekanisme yang dibuat untuk menghubungkan sejumlah sumber daya seperti application server, middleware layer maupun basis data merupakan application programming interface (API). API memungkinkan adanya permintaan layanan terhadap ketiga entitas tersebut guna memperoleh nilai (Gambar IV.7).
99
3. Level metoda. Integrasi aplikasi level metoda dimaksudkan untuk berbagi business logic yang terdapat dalam enterprise. Mekanisme berbagi metoda diantara aplikasi diantaranya distributed object, application server, transaction processing monitor, framework dan membuat aplikasi baru yang mengkombinasikan dua aplikasi atau lebih. Terdapat dua pendekatan dasar yaitu membuat sejumlah shared application server yang ada dalam shared physical server.
4. Level user interface. Integrasi aplikasi level user interface merupakan integrasi aplikasi dengan menggunakan user interface (dikenal juga dengan istilah screen scraping).
IV.2.4 Penentuan Komponen Data yang Diintegrasikan Integrasi aplikasi akan dimulai dengan menentukan data karena untuk kasus aplikasi di YPA, permasalahan utama terletak pada redundansi data. Hal ini memberikan gambaran bahwa apa yang sebenarnya terdapat dalam basis data. Terdapat tiga langkah dasar dalam menerapkan integrasi aplikasi level data, yaitu mengidentifikasi data, membuat katalog data dan membuat skema data. Tujuan dari penentuan data ini adalah untuk memahami dimana data berada (where), memperoleh informasi mengenai data (where) dan mengaplikasikan prinsipprinsip untuk menentukan data apa yang mengalir (which), ke mana (where) dan mengapa (why).
Hasil pemetaan antara entitas data yang dihasilkan dan digunakan aplikasi legacy pada Gambar IV.2 menunjukkan bahwa terdapat entitas yang diciptakan oleh lebih dari satu aplikasi, sebagai contoh adalah entitas pendaftar yang diciptakan oleh aplikasi penerimaan siswa LPP dan juga oleh aplikasi penerimaan mahasiswa ASM. Berdasarkan hasil pemetaan ini, diidentifikasi entitas-entitas yang akan diintegrasikan sehingga cukup dengan sekali penciptaan, maka data dapat digunakan pada aplikasi lain. Entitas data yang akan diintegrasikan adalah entitas pendaftar, mata kuliah, siswa/mahasiswa, dosen dan komponen biaya karena entitas ini diciptakan berulang kali serta digunakan pada sub sistem lainnya.
100
IV.2.4.1
Katalog Data
Pembuatan katalog dimaksudkan untuk mengetahui identitas untuk masingmasing atribut dari tiap tabel. Berdasarkan katalog inilah akan ditentukan atribut mana yang memiliki pengaruh terhadap atribut pada tabel lain sehingga akan memudahkan proses integrasi pada level data. Definisi untuk data bagi masingmasing basis data dari keempat aplikasi yaitu aplikasi akademik dan keuangan unit LPP dan ASM disajikan dalam bentuk katalog data pada lampiran F.
Aplikasi Akademik LPP
c_perguruantgg c_programstudi c_jenjang * c_dosen n_dosen i_gelar i_tmptlahir d_tgllahir i_agama i_jeniskelamin i_goldarah a_alamat a_kota a_kodepos a_telpon a_handphone a_email i_nomorktp c_jabatan c_stsjabatan c_pendidikan n_sekolah i_bidgilmu i_akta i_ijin i_nip c_ptinduk i_entry d_entry
Tabel Dosen
* kddosen nmdosen gelar tmptlahir tgllahir agama jeniskelamin alamat kota kodepos telpon pendidikan nmuniv
Tabel Siswa
tglmasuk * nis nm_sis tmp_lahir tgl_lahir jk alamat kota kodepos telpon
Tabel TmDosen
Tabel Pendaftar
* kd_pendaftaran nm_pendaftar tmp_lahir tgl_lahir jk alamat kota kodepos telpon
Aplikasi Akademik ASM
Tabel TmMahasiswa
Tabel TmSiswaPPMB
* c_pendaftaran n_namasiswa i_tempatlahir d_tgllahir i_agama i_jeniskelamin i_asalsekolah i_asalsekolahalmt i_asalsekolahthlls i_almtasal i_almtasalkota i_almtasaltlp i_alamat i_telpon i_sekolahhis i_sekolahhisml i_sekolahhissl n_orangtua i_orangtuaalmt i_orangtuakota i_orangtuajob c_jurusan c_informasiasal v_nilai n_keterangan i_entry d_entry Aplikasi Keuangan ASM
Aplikasi Keuangan LPP Tabel FmGL
Tabel FmGL Tabel Mahasiswa
Tabel Siswa
* nis nmsis tmp_lahir tgl_lahir kelamin alamat kota kodepos telpon
* kodegl namagl balance report yatidak aktiva labarugi fuseri fusere timei timee tglupdi tglupde
* kodegl namagl balance report yatidak aktiva labarugi fuseri fusere timei timee tglupdi tglupde
* nim nmmhs tmp_lahir tgl_lahir kelamin alamat kota kodepos telpon
Gambar IV.8 Skema Relasi Basis Data
c_perguruantgg c_programstudi c_jenjang c_jurusan * c_nim n_mahasiswa i_tmptlahir d_tgllahir i_agama i_jeniskelamin i_goldarah i_almtorgtua i_kotaorgtua c_kdposorgtua c_prporgtua a_alamat a_kota a_kodepos a_telpon a_handphone a_email i_tahunmasuk i_btssemester d_tglmasuk c_stsmasuk i_entry d_entry
101
IV.2.4.2
Skema Basis Data
Setelah informasi mengenai data diidentifikasi dalam bentuk katalog data, langkah selanjutnya adalah membuat skema relasi antar tabel sehingga dapat diketahui tabel yang mempengaruhi tabel lain dari antara aplikasi dalam enterprise. Skema relasi antar tabel dapat dilihat pada Gambar IV.8 yang menunjukkan keterhubungan tabel dari keempat kelompok aplikasi. Tabel-tabel yang memberikan pengaruh terhadap aplikasi lain yaitu pendaftar, siswa, mahasiswa, dosen dan komponen biaya. Tabel-tabel tersebut juga memiliki permasalahan utama yaitu dibuat lebih dari satu kali oleh lebih dari satu aplikasi yang mengakibatkan redundansi data. Sehingga permasalahan ini dapat diselesaikan dengan melakukan integrasi antar tabel-tabel tersebut.
IV.2.4.3
Penentuan Teknologi Integrasi Aplikasi
Berdasarkan kebutuhan untuk menggabungkan aplikasi yang tidak merubah lojik aplikasi serta memperhatikan skema relasi basis data dan skema aplikasi yang memerlukan pertukaran data antar aplikasi dari tabel-tabel master yang tidak memiliki keterkaitan lojik secara erat antar basis data maka disimpulkan bahwa keempat kelompok aplikasi memerlukan adanya integrasi pada tingkatan data.
Integrasi pada level data dipilih karena tidak adanya akses terhadap lojik atau source code dari masing-masing aplikasi. Integrasi dapat dilakukan pada level data dengan menempatkan software diantara basis data dari keempat aplikasi. Software ini bertugas untuk melakukan ekstraksi informasi dari suatu basis data, melakukan reformat terhadap data dengan merubah isi dan skema jika diperlukan serta melakukan update basis data. Data direplikasi diantara basis data saat terjadi update dari sisi basis data manapun ke tabel yang bersesuaian.
IV.2.4.4
Integrasi Level Data
Sebelum melakukan perpindahan data antar basis data, perlu dipahami metadata dari masing-masing basis data. Pemahaman ini sangatlah penting karena basis data dari keempat aplikasi di YPA dibuat dengan platform yang berbeda.
102
Pemahaman yang dimaksud di sini bertujuan untuk dapat mengkomunikasikan format setiap tabel yang akan diintegrasikan dari masing-masing basis data. Sebagai contoh untuk memindahkan data dosen dari basis data aplikasi akademik LPP ke basis data aplikasi akademik ASM perlu memperhatikan struktur dari masing-masing tabel. Pengabaian terhadap struktur atau format data akan mengakibatkan error baik bagi basis data sumber maupun basis data tujuan.
Keputusan lain yang harus dibuat juga terkait dengan frekuensi perpindahan data sehingga setiap terjadi event, akan memberikan signal mengenai kapan data harus disalin, apakah real time atau batch. Untuk kasus YPA, dimana data yang dipindahkan adalah data dari tabel master yang diperlukan oleh aplikasi lain dan mempengaruhi informasi di aplikasi lain, maka perpindahan harus dilakukan secara real-time. Terdapat banyak teknik dan teknologi untuk memindahkan data dari satu basis data ke basis data lain termasuk diantaranya adalah software replikasi, message brokers dan custom-built. Apapun teknologi yang digunakan, tujuan dari software tersebut adalah menyediakan kemampuan untuk mengekstrasi informasi dari basis data, melakukan reformat data (melakukan perubahan skema maupun isi) dan melakukan update di basis data lain.
Integrasi pada level data bertanggung jawab terhadap pengaksesan data dari satu aplikasi ke aplikasi lain. Oleh karenanya, level ini harus menyediakan layanan transportasi dan transformasi data. Integrasi pada level data merupakan integrasi pada tingkat rendah yang berarti proses integrasi tidak memerlukan pemahaman mengenai lojik aplikasi sehingga lojik aplikasi akan diabaikan dengan langsung melakukan pembacaan dan penulisan data dari aplikasi sumber ke aplikasi tujuan.
IV.2.4.5
Tipe Middleware
Middleware adalah software yang memfasilitasi komunikasi antara dua atau lebih sistem perangkat lunak. Tipe middleware yang dipilih untuk kasus di YPA adalah database-oriented middleware, merupakan middleware yang memfasilitasi komunikasi antara basis data, mekanisme yang mengekstraksi informasi baik dari basis data lokal maupun remote.
103
Database-oriented middleware bekerja dengan dua tipe basis data yaitu call-level interface (CLI) dan native database. CLI menyediakan akses pada sejumlah basis data melalui interface umum, banyak digunakan pada basis data relasional (contoh ODBC, JDBC). Sedangkah native database middleware tidak menggunakan API, namun mengakses feature dan fungsi basis data tertentu, hanya menggunakan mekanisme aslinya.
Alasan dipilihnya database-oriented middleware dalam kasus YPA, dikarenakan sejumlah manfaat yang dapat diperoleh, yaitu (Gambar IV.9) : 1. Interface terhadap aplikasi. 2. Kemampuan untuk dapat mengkonversi bahasa aplikasi sehingga dapat dipahami oleh basis data target. 3. Kemampuan untuk dapat mengirimkan query terhadap basis data melalui jaringan. 4. Kemampuan untuk dapat memproses query pada basis data target. 5. Kemampuan untuk dapat memindahkan tanggapan sebagai hasil dari query kembali melalui jaringan kepada aplikasi yang meminta. 6. Kemampuan untuk mengkonversi tanggapan ke dalam format yang dapat dipahami oleh aplikasi yang meminta. Kemampuan tersebut perlu didukung oleh kemampuan untuk dapat memproses permintaan secara simultan.
Gambar IV.9 Fungsi Database-Oriented Middleware (9)
IV.2.4.6
Model Middleware
Pemahaman
terhadap
karakteristik
tiap
middleware
diperlukan
untuk
mengevaluasi setiap teknologi dari vendor. Terdapat dua tipe model middleware yaitu lojik (logical) dan fisik (physical). Model middleware lojik menggambarkan
104
bagaimana informasi mengalir dalam enterprise secara konseptual, sedangkan middleware fisik menggambarkan bagaimana sebenarnya informasi mengalir dan teknologi yang digunakan.
Middleware dapat bekerja pada konfigurasi point-to-point atau many-to-many. Middleware point-to-point menghubungkan satu aplikasi dengan satu aplikasi lain misalnya aplikasi akademik LPP dengan aplikasi akademik ASM. Sedangkan middleware many-to-many menghubungkan banyak aplikasi dengan banyak aplikasi lain.
Jenis komunikasi middleware terdiri atas asynchronous dan synchronous. Middleware asynchronous merupakan middleware yang dapat memindahkan informasi antara satu atau banyak aplikasi dalam mode asinkron yang artinya bersifat decouple dan satu aplikasi tidak tergantung terhadap aplikasi lain yang terhubung saat melakukan pemrosesan sehingga tidak akan melakukan block terhadap aplikasi lain dalam melakukan pemrosesan. Sedangkan middleware synchronous bersifat tightly couple, yang sangat tergantung pada middleware untuk memproses satu atau lebih function call.
Untuk kasus YPA, maka model middleware yang cocok adalah many-to-many asynchronous. Pemilihan middleware dengan konfigurasi many-to-many untuk kasus aplikasi di YPA karena jika melihat skema relasi basis data (Gambar IV.8), maka terdapat banyak keterhubungan point-to-point. Sedangkan penggunaan jenis komunikasi asynchronous karena antar aplikasi tidak memiliki keterkaitan erat (loosely coupled) sehingga tidak perlu melakukan blocked terhadap aplikasi lain dalam melakukan pemrosesan.
IV.2.4.7
Topologi Integrasi Aplikasi
Ilustrasi pada Gambar IV.10 diberikan untuk memberikan pemahaman mengenai bagaimana suatu data disimpan antar tabel dan basis data. Sebagai contoh saat data dosen disimpan pada basis data aplikasi akademik LPP, maka akan menciptakan event, informasi baru ini akan disalin ke aplikasi akademik ASM.
105
Frekuensi perpindahan data bersifat real-time, artinya data pada suatu tabel akan di-update setiap terjadi event pada suatu tabel yang bersesuaian.
Kompatibilitas data terkait dengan sintaks dan semantik data. Permasalahan mengenai format dan struktur data merupakan permasalahan kompatibilitas sintaks data yang dapat diatasi dengan melakukan penyesuaian format dan struktur data antar aplikasi. Sedangkan permasalahan semantik data adalah dihasilkannya suatu data dari hasil gabungan dan transformasi menjadi format record baru.
Gambar IV.10 Integrasi Level Data Kasus YPA Jika memperhatikan skema relasi basis data (Gambar IV.8) dapat dilihat bahwa perpindahan data antar basis data hanya melibatkan permasalahan sintaks data, yang artinya hanya memerlukan penyesuaian struktur dan format data dari basis data sumber ke basis data tujuan. Sebagai contoh untuk memindahkan isi field kddosen dari tabel dosen di basis data akademik LPP ke field c_dosen pada tabel TmDosen di basis data akademik ASM hanya perlu memperhatikan struktur dan format data yang telah didefinisikan pada katalog data (lampiran F) yaitu penyesuaian dari tipe character berukuran 6 dengan tipe varchar berukuran 10.
106
Untuk mengintegrasikan aplikasi, maka perlu adanya pembentukan arsitektur bagi bagaimana aplikasi tersebut saling terhubung. Pada dasarnya terdapat 3 jenis arsitektur integrasi aplikasi yaitu (9) : 1. Hub-and-spoke Dengan arsitektur hub-and-spoke, tool integrasi aplikasi bertindak sebagai pusat dari aplikasi yang terhubung dan bekerja seperti hub informasi. Setiap aplikasi langsung dikoneksikan dengan hub sehingga akan mengurangi kompleksitas integrasi. Interaksi aplikasi dengan aplikasi lain dilakukan melalui hub, jadi tidak ada koneksi secara langsung antar aplikasi. Arsitektur integrasi ini memiliki kelebihan dalam meminimasi integrasi interface, memungkinkan komunikasi sinkron/asinkron, berorientasi proses bisnis, memfasilitas mengurangi
model
publish/subscribe,
kompleksitas
memungkinkan
implementasi,
memungkinkan
guna
ulang,
manajemen/
administrasi terpusat. Namun arsitektur ini juga memiliki kelemahan yaitu mengakibatkan kegagalan terpusat, kemungkinan besar terjadinya bottleneck jika integrasi dilakukan pada sistem besar dan permasalahan seputar performansi.
2. Federated Pada
arsitektur
federated,
tidak
terdapat
server
integrasi
aplikasi.
Transformasi data dan pengontrolan workflow secara langsung ditempelkan pada aplikasi melalui modul. Integrasi antar sistem direalisasikan melalui keterhubungan secara langsung. Komunikasi antara sistem menggunakan bus topology dengan format message yang bersifat product-dependent. Arsitektur ini tidak mengikuti ide integrasi enterprise karena masih terdapat koneksi point-to-point sehingga cocok untuk proyek integrasi kecil.
3. Bus topology Bus topology digunakan untuk merealisasikan komunikasi antara sistem yang berbeda. Kelemahan dari arsitektur ini adalah setiap modul harus di-install pada setiap sistem yang diintegrasikan. Komponen ini yang bertanggung jawab menghubungkan sistem yang terintegrasi dengan bus sehingga seluruh
107
aplikasi terintegrsi. Terdapat server yang mengelola seluruh workflow dan transformasi data. Manfaat dari topology ini adalah untuk memperoleh scalability dimana jumlah sistem terintegrasi tidak akan mempengaruhi performansi, memperoleh performansi yang tinggi dengan arsitektur terdistribusi dan pengelolaan yang terpusat.
Untuk kasus aplikasi di YPA, integrasi menggunakan arsitektur bus topology (Gambar IV.10), dimana setiap sistem diintegrasikan melalui bus dan transformasi data dikelola oleh server. Arsitektur ini diharapkan dapat memberikan skalabilitas pada komponen-komponen yang diintegrasikan sehingga memiliki performansi yang tinggi.
IV.3 Arsitektur Integrasi Layanan Arsitektur integrasi layanan (Gambar IV.11) mendefinisikan aplikasi bisnis sebagai komponen fungsionalitas bisnis yang dapat diguna ulang dan mudah dirubah serta bagaimana komponen-komponen tersebut saling terkait. Konsep ini merupakan
konsep
arsitektur
yang
berbasis
layanan
(service-oriented
architecture/SOA).
Dalam SOA, fungsi-fungsi bisnis atau proses yang terpisah dibuat sebagai komponen-komponen yang tidak tergantung dengan interface standar yang dapat diakses oleh aplikasi, layanan atau proses bisnis lain, dengan tidak memperhatikan platform atau bahasa pemrograman. Layanan-layanan ini dapat dikombinasikan secara fleksibel untuk mendukung proses bisnis dan fungsi yang berbeda. Tahapan-tahapan dalam membuat arsitektur integrasi layanan adalah : 1. Menentukan business events. 2. Menentukan layanan.
108
Gambar IV.11 Arsitektur Integrasi Layanan (4) IV.3.1 Business Events Business event mendefinisikan aktivitas bisnis yang harus didukung oleh sistem. Business event adalah sesuatu yang terjadi dalam business environment, terjadi pada waktu tertentu, dan harus ditanggapi oleh sistem. Penyajian aktivitas yang terjadi dalam bisnis dan sistem yang diperlukan untuk menanggapi dapat disajikan dalam bentuk events table. Terdapat dua jenis event yaitu business events dan temporal events. Business events adalah aktivitas yang terjadi dalam bisnis dan dapat dideteksi dengan mendefinisikan setiap aktivitas bisnis dalam lingkup sistem. Temporal events terjadi pada waktu yang telah ditetapkan. Temporal events terjadi karena permintaan kebijakan bisnis dimana aktivitas sistem tertentu terjadi pada waktu tertentu atau karena sistem menghasilkan output berbasis waktu. Business events yang terkait dengan proses layanan di YPA terdapat dalam Tabel IV.3 berikut : Tabel IV.3 Business Events No. Event
Business Event
E1
Pengelolaan pendaftaran calon siswa dan mahasiswa baru
E2
Pengelolaan pembayaran administrasi penerimaan calon siswa dan mahasiswa baru
Deskripsi Event Event ini dimulai dari calon siswa/mahasiswa melakukan pendaftaran. Bagian Pendaftaran unit LPP dan ASM akan melakukan pendataan. Event ini dimulai setelah calon siswa/mahasiswa melakukan pendaftaran. Siswa/mahasiswa diminta membayar biaya formulir pendaftaran di Bagian Pendaftaran unit LPP dan ASM. Bagian Keuangan bertanggung jawab terhadap pengelolaan pembayaran.
Tanggapan R1.1 Mendata calon siswa/mahasiswa
R2.1 Mengelola pembayaran pendaftaran calon siswa/mahasiswa
109
Tabel IV.3 Business Events (Lanjutan) No. Event
Business Event
E3
Penilaian hasil Ujian Saringan Masuk (USM) seleksi calon mahasiswa baru
E4
Pelaporan dan evaluasi penerimaan siswa dan mahasiswa baru
E5
Penetapan kurikulum
E6
Penentuan dosen-dosen pengajar dan wali akademik
E7
Registrasi ulang siswa dan mahasiswa
E8
Pengelolaan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
E9
Pelaksanaan perwalian (program D-3)
E10
Pengelolaan Perubahan Rencana Studi/PRS (program D-3)
E11
Pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
E12
Pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
E13
Pembuatan jadwal ujian (UTS, UAS, komprehensif)
E14
Pembuatan daftar hadir (UTS, UAS, komprehensif)
E15
Pemrosesan nilai
E16
Pencetakan Kartu Hasil Studi (KHS)
Deskripsi Event Event ini dimulai setelah mahasiswa melakukan pembayaran. Mahasiswa mengikuti USM dan hasilnya akan dikelola oleh Bagian Akademik unit ASM. Event ini dilakukan secara periodik untuk melaporkan hasil penerimaan siswa/mahasiswa baru. Laporan dibuat oleh setiap bagian yang terlibat baik unit LPP maupun ASM bagi kepentingan pihak manajemen. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menghasilkan kurikulum. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menetapkan dosen pengajar dan wali akademik. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaksanakan registrasi ulang siswa/mahasiswa. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM). Event ini dikelola Bagian Akademik unit ASM untuk melaksanakan perwalian. Event ini dikelola Bagian Akademik unit ASM untuk melaksanakanPerubahan Rencana Studi/PRS. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat jadwal Kegiatan Belajar Mengajar (KBM). Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat daftar hadir Kegiatan Belajar Mengajar (KBM). Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat jadwal ujian (UTS, UAS, komprehensif). Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat pembuatan daftar hadir (UTS, UAS, komprehensif). Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk memproses nilai. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menghasilkan KHS.
Tanggapan R3.1 Memeriksa jurusan dan program studi yang dipilih R3.2 Mengelola hasil USM
R4.1
Mengelola pelaporan penerimaan siswa/mahasiswa baru
R5.1 Mengelola kurikulum R6.1 Mengelola dosen pengajar dan wali akademik
R7.1 Memeriksa jurusan dan program studi yang dipilih R7.2 Mengelola registrasi ulang siswa/mahasiswa R8.1 Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM) R9.1 Mengelola perwalian
R10.1
Mengelola Perubahan Rencana Studi/PRS
R11.1
Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
R12.1
Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
R13.1
Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)
R14.1
Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)
R15.1
Mengelola nilai
R16.1
Mengelola pencetakan Kartu Hasil Studi (KHS)
110
Tabel IV.3 Business Events (Lanjutan) No. Event
Business Event
E17
Pelaporan dan evaluasi kegiatan akademik
E18
Pembuatan ijazah, sertifikat dan transkrip nilai
E19
Pelaporan dan evaluasi kegiatan wisuda
E20
Pengelolaan biaya pendidikan
E21
Pengelolaan honor dosen
E22
Pelaporan dan evaluasi keuangan
Deskripsi Event Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaporkan kegiatan akademik bagi manajemen. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat ijazah, sertifikat dan transkrip nilai. Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaporkan siswa/mahasiswa yang telah lulus. Event ini dilakukan Bagian Keuangan untuk mengelola pembayaran biaya pendidikan. Event ini dilakukan Bagian Keuangan untuk mengelola pembayaran honor dosen. Event ini dilakukan Bagian Keuangan untuk melaporkan pembayaran biaya pendidikan.
Tanggapan R17.1
Mengelola pelaporan kegiatan akademik bagi manajemen
R18.1
Mengelola pembuatan ijazah, sertifikat dan transkrip nilai
R19.1
Mengelola pelaporan siswa/mahasiswa yang telah lulus
R20.1
Mengelola pembayaran biaya pendidikan
R21.1
Mengelola pembayaran honor dosen
R22.1
Mengelola Pelaporan dan evaluasi keuangan
Tanggapan sistem yang didefinisikan dalam events table digunakan untuk menentukan layanan sistem yang harus disediakan. Sejumlah layanan atau fungsi telah ada pada sistem dan fungsionalitas lain yang baru mungkin muncul dan harus dikembangkan serta diintegrasikan. Deskripsi layanan mendefinisikan lingkup fungsionalitas yang diperlukan untuk melaksanakan layanan bisnis tertentu. Untuk memaksimalkan business agility dan IT investment, business service harus didefinisikan pada tingkatan yang mengoptimasi guna ulang (reuse).
IV.3.2 Layanan Tanggapan sistem yang terdefinisi dalam event table mendefinisikan layanan esensial yang harus disediakan oleh sistem. Sejumlah fungsionalitas telah ada dalam sistem legacy dan terdapat sejumlah fungsionalitas baru yang perlu diintegrasikan. Deskripsi layanan mendefinisikan lingkup fungsionalitas yang diperlukan untuk melaksakan layanan bisnis. Deskripsi layanan harus mencakup metoda yang harus didukung oleh layanan, input dan output serta deskripsi umum. Tabel IV.4 menyajikan daftar tanggapan terhadap business event, mendefinisikan apakah fungsi telah ada dalam sistem lama, atau merupakan fungsionalitas baru. Definisi layanan terkait dengan modul-modul dalam aplikasi.
111
Tabel IV.4 Layanan Tanggapan R.1.1
R.2.1
R3.1
R3.2 R4.1
Mendata calon siswa/mahas iswa Mengelola pembayaran pendaftaran calon siswa/mahas iswa Memeriksa jurusan dan program studi yang dipilih Mengelola hasil USM Mengelola pelaporan penerimaan siswa/mahas iswa baru
Kategori Layanan
Deskripsi
Menyediakan layanan pendataan calon siswa/mahasiswa
Pengelolaan penerimaan siswa/mahasiswa baru 1.
Menyediakan layanan pengelolaan pembayaran pendaftaran 2.
Pengelolaan penerimaan siswa/maha siswa baru Pengelolaan keuangan
Sistem yang Telah Ada/Baru • • • • •
• •
Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih Menyediakan layanan pengelolaan hasil USM
Pengelolaan kegiatan akademik
•
• Menyediakan layanan pembuatan laporan PMB
Pengelolaan kegiatan akademik
• •
R5.1
R6.1
R7.1
R7.2
R8.1
Mengelola kurikulum
Mengelola dosen pengajar dan wali akademik Memeriksa jurusan dan program studi yang dipilih Mengelola registrasi ulang siswa/mahas iswa Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
Menyediakan layanan pengelolaan kurikulum
Pengelolaan kegiatan akademik
Menyediakan layanan pengelolaan dosen pengajar dan wali akademik
Pengelolaan kegiatan akademik
• • • •
• •
Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih Menyediakan layanan pengelolaan registrasi ulang
Pengelolaan kegiatan akademik
•
• Menyediakan layanan pengelolaan pembuatan KTS dan KTM
Pengelolaan kegiatan akademik
•
• R9.1
Mengelola perwalian
Menyediakan layanan pengelolaan perwalian
Pengelolaan kegiatan akademik
•
Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM
Aplikasi akademik LPP Aplikasi akademik ASM
Aplikasi akademik LPP Aplikasi akademik ASM
112
Tabel IV.4 Layanan (Lanjutan) Tanggapan R10.1
Mengelola PRS
R11.1 Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM) R12.1 Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM) R13.1 Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif ) R14.1 Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif ) R15.1 Mengelola nilai
R16.1
R17.1
Mengelola pencetakan Kartu Hasil Studi (KHS)
Mengelola pelaporan kegiatan akademik bagi manajemen R18.1 Mengelola pembuatan ijazah, sertifikat dan transkrip nilai R19.1 Mengelola pelaporan siswa/mahasi swa yang telah lulus R20.1 Mengelola pembayaran biaya pendidikan
Deskripsi Menyediakan layanan pengelolaan PRS
Menyediakan layanan pengelolaan KBM
Menyediakan layanan pembuatan daftar hadir KBM
Menyediakan layanan pembuatan jadwal ujian
Menyediakan layanan pembuatan daftar hadir
Menyediakan layanan pengelolaan nilai
Menyediakan layanan pencetakan KHS
Menyediakan layanan pembuatan laporan kegiatan akademik
Menyediakan layanan pembuatan ijazah, sertifikat dan transkrip nilai
Sistem yang Telah Ada/Baru
Kategori Layanan Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan akademik
•
Pengelolaan kegiatan wisuda
•
•
•
•
•
•
•
•
•
• Menyediakan layanan pembuatan laporan siswa/mahasiswa yang telah lulus
Pengelolaan kegiatan wisuda
Menyediakan layanan pengelolaan pembayaran biaya pendidikan
Pengelolaan keuangan
• • • •
Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM
Aplikasi akademik LPP Aplikasi akademik ASM
Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi akademik LPP Aplikasi akademik ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
113
Tabel IV.4 Layanan (Lanjutan) Tanggapan R21.1
Mengelola honor dosen
Sistem yang Telah Ada/Baru
Kategori Layanan
Deskripsi Menyediakan layanan pengelolaan honor dosen
Pengelolaan keuangan
• •
R22.1 Mengelola Pelaporan dan evaluasi keuangan
Menyediakan layanan pembuatan laporan keuangan
Pengelolaan keuangan
• •
Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
IV.4 Arsitektur Integrasi Informasi Informasi dan data merupakan hal yang penting dalam proyek integrasi karena permasalahan
utama
pada
seluruh
proyek
integrasi
adalah
bagaimana
memungkinkan interoperability diantara sistem yang memiliki data dalam berbagai struktur dan format. Arsitektur integrasi informasi (Gambar IV.12) mendefinisikan infrastruktur dan proses yang memungkinkan informasi diakses pada sistem.
Gambar IV.12 Arsitektur Integrasi Informasi (4) Dalam integrasi, aliran informasi dan juga data perlu digambarkan untuk memperoleh kejelasan mengenai data dan informasi apa saja yang sebenarnya dihasilkan atau diperlukan dari atau ke sistem. Penggambaran aliran informasi dalam sistem tersebut akan menggunakan data flow diagram (DFD).
114
IV.4.1 Context Diagram Context diagram atau diagram konteks pada Gambar IV.13 terdiri atas 4 entitas eksternal yaitu dosen, pendaftar, siswa/mahasiswa dan manajemen. Entitas dosen memberikan aliran data identitas dosen ke dalam sistem. Entitas pendaftar memberikan aliran data identitas pendaftar ke dalam sistem dan menerima aliran data bukti pembayaran dari sistem. Entitas siswa/mahasiswa menerima aliran data Kartu Hasil Studi (KHS), ijazah, sertifikat dan transkrip nilai dari sistem. Manajemen menerima aliran data laporan Penerimaan Mahasiswa Baru (PMB), akademik, wisuda dan keuangan.
Bagian Keuangan
Siswa_Mahasiswa data pembayaran
ijazah transkrip sertifikat
bukti pembayaran form pembayaran khs
Bagian Akademik data dosen
data siswa_mahasiswa nilai
0
data mata kuliah
Sistem Informasi Akademik YPA
nilai identitas dosen Dosen
+ identitas pendaftar form pembayaran pendaftaran bukti pembayaran
laporan keuangan laporan wisuda laporan akademik laporan pmb
Pendaftar Manajemen
Gambar IV.13 Context Diagram IV.4.2 Data Flow Diagram (DFD) Level 1 Data flow diagram (diagram arus data) level 1 pada Gambar IV.14 terdiri atas 4 proses yaitu pengelolaan PMB, pengelolaan kegiatan akademik, pengelolaan wisuda dan pengelolaan keuangan. DFD level 1 terdiri atas sejumlah aliran data yang mengakses 11 simpanan yaitu data pendaftar, pembayaran pendaftaran, hasil usm, perwalian, kurikulum, dosen, siswa, mahasiswa, nilai, komponen biaya, dan pembayaran biaya pendidikan.
115
Perwalian PRS Data Siswa
trans perwalian prs trans perwalian prs
identitas siswa identitas siswa
Manajemen
laporan akademik
2
identitas siswa
Pengelolaan Kegiatan Akademik kurikulum
DataNilai
nilai nilai
identitas mahasiswa identitas mahasiswa Data Mahasiswa
+
nilai identitas siswa
kurikulum
Data Kurikulum
identitas dosen
identitas mahasiswa
identitas dosen
identitas dosen 3 Pengelolaan Wisuda
identitas pendaftar Data Dosen
+
laporan wisuda
Dosen Manajemen
4 identitas pendaftar
Data Pendaftar
transaksi pembayaran
Pengelolaan Keuangan
Data Pembayaran Pendaftaran identitas pendaftar transaksi pembayaran biaya pendidikan identitas pendaftar
transaksi pembayaran transaksi pembayaran laporan keuangan
1 Pengelolaan PMB bukti pembayaran
Komponen Biaya
Data Pembayaran Biaya Pendidikan
+
Komponen Biaya
laporan pmb hasil usm
identitas pendaftar
Manajemen
hasil usm Pendaftar
Data Komponen Biaya Data USM
Gambar IV.14 DFD Level 1 IV.4.3 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 1 Pengelolaan PMB Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses nomor 1 yaitu proses pengelolaan PMB pada Gambar IV.15 terdiri atas 4 proses yaitu pendataan pendaftar, pengelolaan pembayaran pendaftaran, pengelolaan usm dan pengelolaan laporan PMB. DFD tersebut terdiri atas sejumlah aliran data yang mengakses 4 simpanan yaitu data pendaftar, hasil usm, komponen biaya dan pembayaran pendaftaran.
116
1.2 [bukti pembayaran] Pendaftar
Mengelola Pembayaran Pendaftaran
[transaksi pembayaran]
Data Pembayaran Pendaftaran
[transaksi pembayaran] [komponen biaya]
[identitas pendaftar]
[identitas pendaftar] Data Komponen Biaya 1.4 Mengelola Laporan PMB
1.1 Mendata Pendaftar
[identitas pendaftar] Data Pendaftar
[laporan pmb]
Manajemen
identitas pendaftar [hasil usm] 1.3 Mengelola USM
[hasil usm] Data USM
Gambar IV.15 DFD Level 2 Dekomposisi Proses 1 IV.4.4 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 2 Pengelolaan Kegiatan Akademik Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses nomor 2 yaitu proses pengelolaan kegiatan akademik pada Gambar IV.16 terdiri atas 8 proses yaitu penetapan kurikulum, penetapan dosen/wali akademik, registrasi ulang, pengelolaan KTS/KTM, perwalian/PRS, pengelolaan jadwal, pengelolaan nilai dan pengelolaan laporan akademik. DFD tersebut terdiri atas sejumlah aliran data yang mengakses 7 simpanan yaitu data pendaftar, perwalian, kurikulum, dosen, siswa, mahasiswa dan nilai.
IV.4.5 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 3 Pengelolaan Wisuda Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses nomor 3 yaitu proses pengelolaan kegiatan akademik pada Gambar IV.17 terdiri atas 4 proses yaitu pengelolaan ijazah, pengelolaan transkrip, pengelolaan sertifikat dan pengelolaan laporan wisuda. DFD tersebut terdiri atas sejumlah
117
aliran data yang mengakses 4 simpanan yaitu data kurikulum, siswa, mahasiswa dan nilai.
Dosen
Bagian Akademik [data dosen]
[identitas dosen]
2.2
Siswa_Mahasiswa Data Dosen : 1
[identitas dosen]
Menetapkan Dosen dan Wali Akademik
Data Siswa : 1
identitas siswa
[khs]
[identitas siswa]
[identitas dosen] identitas dosen
[identitas siswa] 2.3
Bagian Akademik
2.4
Registrasi Ulang
Mengelola KTS KTM
[data siswa_mahasiswa]
2.7 Bagian Akademik
[nilai]
Mengelola nilai
2.6
[identitas mahasiswa] [identitas pendaftar]
[identitas mahasiswa]
identitas mahasiswa
[nilai]
[nilai]
Dosen
Mengelola Jadwal
+ Data Mahasiswa
Data Pendaftar
[kurikulum]
DataNilai : 1
identitas mahasiswa
2.5 Mengelola Perwalian dan PRS
kurikulum kurikulum Data Kurikulum
identitas mahasiswa identitas pendaftar [trans perwalian prs]
identitas siswa Data Siswa : 2
2.8 Mengelola Laporan Akademik
[kurikulum]
kurikulum
Perwalian PRS : 1
2.1 Menetapkan Kurikulum
[laporan akademik] Manajemen
identitas dosen
[nilai] [trans perwalian prs] DataNilai : 2
[data mata kuliah] Data Dosen : 2
Perwalian PRS : 2 Bagian Akademik
Gambar IV.16 DFD Level 2 Dekomposisi Proses 2
118
DataNilai
[nilai]
nilai
Data Siswa : 2
Siswa_Mah nilai asiswa nilai
Data Kurikulum : 1 3.1 Mengelola pembuatan Ijazah
[kurikulum]
kurikulum
[ijazah]
identitas siswa 3.2 Mengelola Transkrip Nilai
[sertifikat] 3.3 Mengelola pembuatan Sertifikat
3.4 Mengelola Laporan Wisuda
[transkrip] identitas mahasiswa Siswa_Mahasiswa
[identitas siswa]
identitas siswa
Data Mahasiswa :2
kurikulum
kurikulum
Data Kurikulum : 2 identitas siswa
[laporan wisuda]
[identitas mahasiswa] identitas mahasiswa identitas mahasiswa Data Siswa : 1
Manajemen
Data Mahasiswa : 1
Gambar IV.17 DFD Level 2 Dekomposisi Proses 3 IV.4.6 Data Flow Diagram (DFD) Level 3 Dekomposisi Proses 2.6 Pengelolaan Jadwal Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses nomor 2.6 yaitu proses pengelolaan jadwal pada Gambar IV.18 terdiri atas 2 proses yaitu pengelolaan jadwal kuliah dan ujian. DFD tersebut terdiri atas sejumlah aliran data yang mengakses 2 simpanan yaitu data kurikulum dan dosen.
119
2.6.2 Mengelola Jadwal Ujian
kurikulum
identitas dosen
Data Kurikulum
Data Dosen
[identitas dosen]
[kurikulum]
2.6.1 Mengelola Jadwal Kuliah
Gambar IV.18 DFD Level 3 Dekomposisi Proses 2.6
IV.5 Arsitektur Integrasi Proses Bisnis Tujuan integrasi adalah untuk mendukung peningkatan proses bisnis dalam rangka meningkatkan efisiensi bisnis. Integrasi level proses
mendefinisikan
interaksi diantara sistem melalui definisi business workflow. Peran arsitektur integrasi proses adalah untuk menciptakan model dan definisi proses sebagai entitas yang dikelola sehingga mudah beradaptasi terhadap perubahan bisnis. Arsitektur integrasi proses (Gambar IV.19) mendefinisikan end-to-end business process yang diotomatisasi pada sistem dengan platform yang berbeda-beda.
Gambar IV.19 Arsitektur Integrasi Proses Bisnis (4)
120
Gambar IV.20 Integrasi Proses Bisnis
121
Arsitektur integrasi proses juga penting dalam rangka penyelarasan antara teknologi informasi dengan bisnis yang dimulai dengan pemodelan proses bisnis yang dapat dipahami oleh para pelaku bisnis sehingga terdapat kesepahaman antara staf IT dengan pelaku bisnis. Proses lalu diotomatisasi berdasarkan model teresbut. Hal ini akan mengurangi adanya salah interpretasi terhadap business requirement atau kesalahan proses. Proses dapat tersebar diantara unit bisnis sehingga tidak hanya satu atau sekelompok orang saja yang memiliki suatu endto-end process. Model proses akan menyajikan pemahaman mengenai bagaimana bisnis dilakukan di dalam enterprise dan harus dikelola sebagai aset yang bernilai.
Proses bisnis (Gambar IV.20) dimulai ketika calon siswa/mahasiswa mengajukan permohonan menjadi siswa/mahasiswa dengan mengisi formulir pendaftaran disertai dengan pembayaran biaya formulir di Bagian Pendaftaran (Mentor). Bagian Pendaftaran lalu memasukkan data di formulir pendaftaran dan pembayaran biaya formulir ke aplikasi keuangan. Setelah formulir yang telah terisi diserahkan ke Bagian Pendaftaran, calon mahasiswa mengikuti Ujian Saringan Masuk (USM). Jika lulus, maka mahasiswa ASM menyerahkan biaya pendidikan semester 1 (angsuran 1) dan uang seragam di Bagian Keuangan serta mengisi fomulir biodata dan menyerahkan biodata tersebut ke Bagian Akademik. Sedangkan siswa LPP tidak mengikuti ujian saringan masuk. Bagian Keuangan akan memasukkan transaksi pembayaran ke komputer lalu memberikan bukti pembayaran rangkap ke-1 (bukti pembayaran adalah 3 rangkap, rangkap ke-2 dilampirkan dalam laporan keuangan periodik, sedangkan rangkap ke-3 diarsip) dan formulir Kartu Rencana Studi (KRS) kosong 3 rangkap pada mahasiswa. Formulir KRS yang diterima oleh mahasiswa tersebut akan digunakan untuk melakukan perwalian dengan dosen wali. KRS yang telah terisi akan didistribusikan, rangkap 1 dipegang oleh Bagian Akademik, rangkap 2 dipegang oleh dosen wali, sedangkan rangkap 3 dipegang oleh mahasiswa.
Berdasarkan formulir biodata yang masuk, Bagian Akademik mengukur seragam, kemudian memasukkan data mahasiswa baru dan menetapkan Nomor Induk Mahasiswa (NIM) atau Nomor Induk Siswa (NIS) di aplikasi akademik sehingga
122
status calon siswa/mahasiswa berubah menjadi siswa/mahasiswa. Bagian Keuangan akan memeriksa apakah data keuangan di komputer sama dengan jumlah uang fisik dan kwitansi pembayaran yang diperoleh. Setelah dilakukan pemeriksaan, maka uang fisik diserahkan ke bank dan Bagian Keuangan melakukan pengelolaan kas pada aplikasi keuangan.
Pada tahun akademik berjalan, Bagian Akademik melakukan beberapa kegiatan yang terkait dengan belajar mengajar, yaitu : 1. Menetapkan wali kelas/dosen wali. 2. Menetapkan dosen-dosen pengajar dengan terlebih dahulu melakukan rapat koordinasi dan menerbitkan SK mengajar. 3. Mengalokasikan mata kuliah (baik tetap berdasarkan paket maupun tambahan seperti beauty class, table manner, berbagai seminar dan pelatihan). Untuk semester 1 dan 2, mata kuliah yang diambil siswa/mahasiswa berupa mata kuliah paket, sedangkan untuk mahasiswa mulai semester 3 sampai dengan 6 dapat mengambil mata kuliah pada semester sebelum atau sesudahnya dengan ketentuan bahwa mata kuliah di semester ganjil hanya dapat diambil di semester ganjil, dan begitu juga mata kuliah di semester genap hanya dapat diambil di semester genap. 4. Mengalokasikan kelas berdasarkan mata kuliah dan jumlah siswa/mahasiswa yang mengambil mata kuliah. 5. Menerbitkan Kartu Tanda Siswa (KTS)/Kartu Tanda Mahasiswa (KTM), Kartu Peserta Ujian (KPU), Kartu Hasil Studi (KHS), transkrip nilai dan sertifikat bagi siswa/mahasiswa. 6. Membuat daftar hadir kuliah, UTS dan UAS bagi siswa/mahasiswa serta dosen. 7. Menerbitkan surat yang terkait dengan kegiatan akademik baik bagi orang tua siswa/mahasiswa, dosen maupun instansi/perusahaan.
Pelaksanaan UTS adalah pada pertemuan ke 7 sedangkan UAS pada pertemuan ke 14 tahun akademik berjalan. Setelah penyelenggaraan UTS dan UAS, dosen diberi waktu 1 minggu untuk mengoreksi nilai dan mengisikan nilai pada daftar hadir
123
nilai UTS atau UAS yang terdiri dari 3 rangkap, rangkap 1 dan 2 untuk Bagian Akademik sedangkan rangkap ke-3 dipegang oleh dosen yang bersangkutan. Bagian Akademik mengumumkan nilai dari nilai rangkap ke-2, sedangkan rangkap ke-1 digunakan untuk memasukkan nilai ke aplikasi akademik dan diberikan ke Bagian Keuangan untuk perhitungan honor ujian, kemudian diarsip. Pada akhir semester, Bagian Akademik akan memberikan kartu hasil studi (KHS) bagi siswa/mahasiswa dan juga wali kelas/dosen wali. Dosen wali memasukkan nilai yang tertera di KHS ke kartu kuning sehingga dapat dijadikan dasar untuk melakukan perwalian semester yang akan datang. Selain KHS, hasil kemajuan akademik siswa/mahasiswa juga dihasilkan dalam bentuk transkrip nilai. Perbedaan antara KHS dan transkrip nilai adalah KHS diterbitkan untuk menunjukkan prestasi akademik satu semester terakhir yang telah ditempuhnya, sedangkan transkrip nilai diterbitkan untuk menunjukkan prestasi akademik keseluruhan semester (dari semester satu sampai dengan semester terakhir yang telah ditempuhnya).
Setiap semester, Bagian Keuangan melakukan penagihan biaya pendidikan sebanyak 3 kali yaitu di awal semester, menjelang UTS dan menjelang UAS melalui surat penagihan angsuran biaya pendidikan untuk mahasiswa. Saat mahasiswa membayar, maka Bagian Keuangan akan memasukkan data pembayaran ke aplikasi keuangan dan memberikan bukti pembayaran rangkap ke1 (bukti pembayaran adalah 3 rangkap, rangkap ke-2 dilampirkan dalam laporan keuangan periodik, sedangkan rangkap ke-3 diarsip). Selain mengelola pemasukan dari siswa/mahasiswa, Bagian Keuangan juga mengelola pengeluaran seperti pembayaran honor/gaji dosen baik tetap maupun luar biasa yang dilakukan setiap bulan. Bagian akademik dan keuangan setiap bulan secara periodik melaporkan kegiatan akademik dan laporan keuangan kepada pihak manajemen yaitu Pembantu Direktur I dan II untuk kemudian diteruskan ke Direktur.
IV.6 Strategi Integrasi Arsitektur integrasi yang telah dibangun merupakan blueprint integrasi teknologi, layanan, informasi dan proses bisnis yang menjadi dasar bagi pengembangan dan
124
pengelolaan sistem informasi sehingga selaras dengan bisnis enterprise. Arsitektur integrasi dibangun dengan didasarkan pada dorongan bisnis kemudian pada kebutuhan data, aplikasi dan teknologi. Untuk menerapkan hasil pengembangan arsitektur, maka diperlukan strategi sehingga dapat menerapkan integrasi. Hasil dari penerapan strategi integrasi diharapkan menjadi acuan dalam implementasi kegiatan integrasi.
Tujuan dari tahapan ini adalah untuk memformulasikan dan mempersiapkan rencana untuk implementasi arsitektur enterprise. Tahapan ini juga disebut sebagai strategi migrasi yang menekankan pada strategi untuk bergerak dari bisnis saat ini ke bisnis yang diinginkan di masa mendatang berdasarkan model bisnis, information resource catalog (IRC) dan ketiga arsitektur yang telah didefinisikan pada tahapan sebelumnya.
Dalam arsitektur aplikasi terdapat 29 aplikasi. Dari ke-29 aplikasi tersebut perlu ditentukan prioritas aplikasi yang akan diimplementasikan. Perencanaan arsitektur enteprise berbeda dengan perencanaan sistem tradisional dimana data digunakan untuk mengendalikan urutan implementasi dengan menggunakan prinsip bahwa aplikasi yang menciptakan (create) data harus diimplementasikan sebelum aplikasi yang menggunakan (use) data. Prinsip ini penting dalam menentukan prioritas urutan pengembangan aplikasi bagi lingkungan yang berbagi pakai bersama data.
Matriks yang merelasikan entitas data dengan fungsi bisnis yang dihasilkan pada tahapan pembentukan arsitektur data (Gambar III.13) menunjukkan apakah suatu entitas diciptakan (created), di-update (updated) atau digunakan (referenced) oleh setiap fungsi. Sedangkan matriks yang merelasikan aplikasi dengan fungsi bisnis pada tahapan pembentukan arsitektur aplikasi menunjukkan penyebaran aplikasi melalui batasan-batasan unit organisasi (Gambar III.16).
125
Gambar IV.21 Matriks Aplikasi – Entitas
126
Kedua matriks ini yaitu antara apliksi dengan fungsi dan antara fungsi dengan entitas dapat digabungkan untuk menghasilkan matriks yang merelasikan aplikasi dengan entitas sehingga dapat menunjukkan apakah suatu aplikasi menciptakan (create), meng-update (update) atau menggunakan (reference) suatu entitas. Baris dari matriks menunjukkan aplikasi sedangkan kolom matriks adalah entitas. Hasil dari penggabungan matriks Gambar III.13 dan III.16 adalah matriks pada Gambar IV.21.
Baris dan kolom dari matriks (Gambar IV.21) disusun sedemikian sehingga entri “C/Create” membentuk area diagonal dari pojok kiri atas ke pojok kanan bawah. Baris dengan sedikit entri digeser ke atas, sedangkan baris dengan banyak entri digeser ke bawah, arah entri “C” ke sebelah kanan. Kolom dengan banyak entri digeser ke kiri, sedangkan kolom dengan sedikit entri digeser ke kanan, arah entri “C” ke atas. Area atas diagonal harus dibuat sekosong mungkin, sedangkan area bawah diagonal terdiri atas sebanyak mungkin entri “R/Reference” atau “U/Update”. Penyusunan dengan cara seperti ini akan menghasilkan daftar aplikasi dalam urutan pengembangan data-driven sehingga aplikasi yang terdapat pada area atas matriks harus diimplementasikan terlebih dahulu karena aplikasiaplikasi tersebut menciptakan data yang diperlukan oleh aplikasi-aplikasi yang berada di bawahnya.
Dengan melihat pengelompokkan aplikasi dengan menggunakan garis tebal dapat dilihat urutan implementasi aplikasi yang mengikuti rantai nilai (value chain) enterprise yang terdiri atas fungsi bisnis utama akademik dan fungsi pendukung keuangan. Hal ini menunjukkan bahwa jika melihat berdasarkan baris, dapat dilihat urutan implementasi aplikasi sedangkan kolom menunjukkan urutan penciptaan sumber daya data yang dapat dipakai bersama (data sharing).
Prinsip data dependency bukanlah satu-satunya cara yang digunakan untuk membuat urutan aplikasi, namun terdapat beberapa prioritas lain yaitu (11) : 1. Permintaan (demand) : mengukur seberapa diperlukannya suatu aplikasi dan adanya tekanan politik.
127
2. Sistem saat ini (existing system) : jika aplikasi yang ada saat ini telah cukup mendukung fungsi-fungsi bisnis, maka aplikasi dimodifikasi agar dapat dioperasikan pada shared data environment. Jika aplikasi yang ada saat ini sulit untuk dipelihara, maka perlu diganti oleh aplikasi yang baru. 3. Kemungkinan sukses/resiko (likelihood of success/risk) : kesuksesan implementasi aplikasi tergantung pada jumlah sumber daya yang diperlukan, jumlah sumber daya yang tersedia, waktu pengembangan aplikasi serta kesulitan dan kompleksitas aplikasi. Pada umumnya, aplikasi yang beresiko harus ditunda diimplementasikan setelah implementasi aplikasi dengan kemungkinan kesuksesan yang tinggi. 4. Manfaat potensial (potential benefits) : aplikasi yang memiliki rate of return yang tinggi harus diimplementasikan secepatnya. 5. Dampak organisasional (organizational impact) : Aplikasi yang kurang memberikan dampak, komitmen dan standar pada organisasi harus diimplementasikan secepatnya.
Berdasarkan urutan implementasi aplikasi data-dependency pada matriks aplikasientitas (Gambar IV.21) dan berdasarkan kebijakan dan kebutuhan YPA untuk melakukan integrasi antara data dan aplikasi, maka urutan aplikasi yang perlu diperbaiki atau diintegrasikan dengan aplikasi lain terdapat pada Tabel IV.5.
Tabel IV.5 Urutan Aplikasi No. 1 2 3 4
No. Aplikasi 1.1 1.3 1.4
Kandidat Aplikasi Sistem Pendaftaran Calon Siswa/Mahasiswa Baru Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa baru Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
2.12
Sistem Manajemen Kurikulum
5
2.1
6
2.2
Sistem Registrasi Ulang Siswa/Mahasiswa Sistem Pembuatan KRS, KTS dan KTM
7
2.11
Sistem Administrasi Dosen
Keterangan Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA. Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
128
Tabel IV.5 Urutan Aplikasi (Lanjutan) No.
No. Aplikasi
Kandidat Aplikasi
8 9 10
2.3 2.4 2.5
Sistem Perwalian Sistem Perubahan Rencana Studi Sistem Penjadwalan KBM
11
2.6
Sistem Administrasi KBM
12
2.7
13
2.8
14
2.9
Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif) Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif) Sistem Pengelolaan Nilai
15
2.10
Sistem Pembuatan Kartu Hasil Studi
16
3.1
17
3.2
Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai Sistem Administrasi Wisuda
18
3.3
Sistem Pelaporan Kegiatan Wisuda
19
2.13
Sistem Pelaporan Akademik
20
5.3
Sistem Pengelolaan Alumni
21
5.4
22
1.2
23
6.1
24
6.2
Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA Sistem Pengelolaan Pembayaran Pendaftaran Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa Sistem Pengelolaan Honor Dosen
25
6.3
Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa
Keterangan
Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA. Ditingkatkan menjadi aplikasi yang dapat memenuhi kebutuhan manajemen YPA. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Pengembangan baru. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain. Diubah menjadi aplikasi yang terintegrasi dengan aplikasi lain.
Analisa kesenjangan antara data, aplikasi serta teknologi dapat digunakan untuk membantu memberikan pertimbangan pengurutan pengembangan sistem. Pada Tabel IV.6 diuraikan urutan aplikasi yang memiliki hubungan dan pengaruh terhadap aplikasi legacy, teknologi dengan arsitektur integrasi yang telah dibuat yaitu arsitektur layanan dan arsitektur informasi serta rencana implementasinya yang diperkirakan diselesaikan dalam waktu empat tahun.
129
Tabel IV.6 Strategi Integrasi Teknologi
1.
1.
3
Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
4
Sistem Manajemen Kurikulum
5
Sistem Registrasi Ulang Siswa/Mahasiswa
6
Sistem Pembuatan KRS, KTS dan KTM
2
2.
Aplikasi akademik LPP Aplikasi akademik ASM
Aplikasi akademik ASM
2. 1. 2. 1. 2. 1. 2.
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
Integrasi Informasi
Aliran Data Masuk
M
I
T
U
T
E1
Bagian Pendaftaran, Pendaftar
1.1
Identitas pendaftar
Identitas pendaftar
P
T
T
T
T
E3
Bagian Akademik
1.3
Identitas pendaftar
Hasil usm
1.4
Transaksi pembayaran, hasil usm
Laporan PMB
2.1
B)aru
Strategi Implementasi Kwartal
No. DFD
Sistem Pendaftaran Calon Siswa/Mahasiswa Baru Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa baru
1
Integrasi Layanan
Basis
(T)etap/(Integrasi)/(
Nama Aplikasi
n/(M)odifikasi/(Ganti)
Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
Actor Terlibat
Aplikasi akademik LPP Aplikasi akademik ASM
T
I
T
U
T
E4
Bagian Pendaftaran, Bagian Akademik, Manajemen
Aplikasi akademik LPP Aplikasi akademik ASM
T
I
T
U
T
E5
Bagian Akademik
2.3
Identitas pendaftar
2.4
Identitas siswa, identitas mahasiswa
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E7
Pendaftar, Peserta Didik
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E8
Bagian Akademik, Peserta Didik
Aliran Data Keluar
Kurikulum Identitas siswa, identitas mahasiswa
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
130
Tabel IV.6 Strategi Integrasi (Lanjutan)
7
Sistem Administrasi Dosen
8
Sistem Perwalian
9
Sistem Perubahan Rencana Studi
10
11
1.
Aplikasi akademik LPP 2. Aplikasi akademik ASM Aplikasi akademik ASM
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
B)aru
Basis
(T)etap/(Integrasi)/(
n/(M)odifikasi/(Ganti)
Nama Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut
Aplikasi
Integrasi Layanan
Integrasi Informasi
Actor Terlibat
Aliran Data Masuk
Aliran Data Keluar
M
I
T
U
T
E6
Bagian Akademik, Dosen
2.2
Identitas dosen
Identitas dosen
P
T
T
T
T
E9
2.5
Identitas mahasiswa, kurikulum
Trans perwalian prs
Aplikasi akademik ASM
P
T
T
T
T
E10
Bagian Akademik, Wali Akademik, Mahasiswa Bagian Akademik, Wali Akademik, Mahasiswa
2.5
Identitas mahasiswa, kurikulum
Trans perwalian prs
Sistem Penjadwalan KBM
1.
M
I
T
U
T
E11
Bagian Akademik
2.6 .1
Identitas dosen, kurikulum
Sistem Administrasi KBM
1.
M
I
T
U
T
E12
Bagian Akademik
2.6 .1
Identitas dosen, kurikulum
2.
2.
Aplikasi akademik Aplikasi akademik Aplikasi akademik Aplikasi akademik
LPP ASM LPP ASM
Strategi Implementasi Kwartal
No. DFD
Teknologi
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
131
Tabel IV.6 Strategi Integrasi (Lanjutan) Teknologi
13
14
1.
Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)
1.
Sistem Pengelolaan Nilai
1.
2.
2.
2.
15
Sistem Pembuatan Kartu Hasil Studi
1. 2.
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(Integrasi)/(
n/(M)odifikasi/(Ganti)
Basis
Integrasi Informasi
I
T
U
T
E13
Bagian Akademik
2.6 .1
Identitas dosen, kurikulum
M
I
T
U
T
E14
Bagian Akademik
2.6 .1
Identitas dosen, kurikulum
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E15
Bagian Akademik, Dosen
2.7
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E16
Bagian Akademik
2.7
Identitas dosen, identitas siswa, identitas mahasiswa, kurikulum Identitas dosen, identitas siswa, identitas mahasiswa, kurikulum
B)aru
M
Aplikasi akademik Aplikasi akademik Aplikasi akademik Aplikasi akademik
LPP
Actor Terlibat
ASM LPP
Strategi Implementasi Kwartal
Aliran Data Masuk
Nama Aplikasi
Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)
Integrasi Layanan
No. DFD
12
Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
ASM
Aliran Data Keluar
Khs, nilai
Khs, nilai
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
132
Tabel IV.6 Strategi Integrasi (Lanjutan) Teknologi
17
18
1.
Sistem Administrasi Wisuda
1.
Sistem Pelaporan Kegiatan Wisuda
1.
2.
2.
2.
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(Integrasi)/(
n/(M)odifikasi/(Ganti)
Basis
Integrasi Informasi
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E18
Bagian Akademik
3.1 , 3.2 , 3.3
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E18
Bagian Akademik
3.1 , 3.2 , 3.3
Aplikasi akademik LPP Aplikasi akademik ASM
T
I
T
U
T
E19
Bagian Akademik, Manajemen
3.4
Identitas siswa, identitas mahasiswa, nilai, kurikulum, nilai Identitas siswa, identitas mahasiswa, nilai, kurikulum, nilai Identitas siswa, identitas mahasiswa, nilai, kurikulum
B)aru
Strategi Implementasi Kwartal
Aliran Data Masuk
Nama Aplikasi
Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai
Integrasi Layanan
No. DFD
16
Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
Actor Terlibat
Aliran Data Keluar
Ijazah, transkrip, sertifikat
Ijazah, transkrip, sertifikat
Laporan wisuda
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
133
Tabel IV.6 Strategi Integrasi (Lanjutan) Teknologi
20
21
1.
Sistem Pengelolaan Alumni
1.
Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA
2.
2.
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(Integrasi)/(
n/(M)odifikasi/(Ganti)
Basis
Integrasi Informasi
Aplikasi akademik LPP Aplikasi akademik ASM
T
I
T
U
T
E17
Bagian Akademik, Manajemen
2.8
Aplikasi akademik LPP Aplikasi akademik ASM
M
I
T
U
T
E18
Bagian Akademik
3.1 , 3.2 , 3.3
Identitas pendaftar, identitas siswa, identitas mahasiswa, nilai, identitas dosen, kurikulum, trans perwalian prs Identitas siswa, identitas mahasiswa, nilai, kurikulum, nilai
B
B
B
B
B)aru
Strategi Implementasi Kwartal
Aliran Data Masuk
Nama Aplikasi
Sistem Pelaporan Akademik
Integrasi Layanan
No. DFD
19
Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
Actor Terlibat
Aliran Data Keluar
Laporan akademik
Ijazah, transkrip, sertifikat
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
134
Tabel IV.6 Strategi Integrasi (Lanjutan)
23
24
Sistem Pengelolaan Pembayaran Pendaftaran
1.
Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa
1.
Sistem Pengelolaan Honor Dosen
2.
2.
1. 2.
25
Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa
1. 2.
Hard-
Soft-
Komuni
Data
ware
ware
kasi
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(T)etap/(U)pgrade/ (B)aru
(B)aru
Basis
(T)etap/(Integrasi)/
n/(M)odifikasi/(Ganti)
Nama Aplikasi
(P)ertahankan/(T)ingkatka
No.Urut 22
Aplikasi
Integrasi Layanan
Integrasi Informasi
Strategi Implementasi Kwartal
Actor Terlibat
No. DFD
Teknologi
Legacy
No.Event yang Dilayani
Dampak pada Aplikasi
Aplikasi keuangan LPP Aplikasi keuangan ASM
M
I
T
U
T
E2
Bagian Keuangan, Pendaftar
Aplikasi keuangan LPP Aplikasi keuangan ASM
M
I
T
U
T
E20
Bagian Keuangan, Peserta Didik
4
Aplikasi keuangan LPP Aplikasi keuangan ASM Aplikasi keuangan LPP Aplikasi keuangan ASM
M
I
T
U
T
E21
Bagian Keuangan, Dosen
4
M
I
T
U
T
E21
Bagian Keuangan, Manajemen
4
Aliran Data Masuk
Identitas pendaftar, komponen biaya, transaksi pembayara n, identitas siswa, identitas mahasiswa Identitas dosen, komponen biaya Identitas pendaftar, komponen biaya, transaksi pembayara n, identitas siswa, identitas mahasiswa
Aliran Data Keluar
Transaksi pembayara n biaya pendidikan, laporan keuangan, komponen biaya Honor dosen
Transaksi pembayara n biaya pendidikan, laporan keuangan, komponen biaya
1 2 3 4 5 6 7 8 9
1 1 1 0 1 2
135
Manfaat dari integrasi enteprise dapat direalisasikan saat suatu organisasi menggunakan strategi bisnis untuk mengendalikan strategi dan arsitektur integrasi. Berdasarkan hasil analisis terhadap as-is system, diperoleh hasil bahwa fungsi utama yaitu akademik dan juga fungsi pendukung keuangan masingmasing telah didukung oleh 4 kelompok aplikasi. Pada perjalanannya, aplikasiaplikasi tersebut dibuat oleh sejumlah vendor dalam rentang waktu yang berlainan sehingga berdampak pada perbedaan teknologi mulai dari bahasa pemrograman, database management system sampai dengan teknologi perangkat keras yang mendukungnya. Sedangkan identifikasi terhadap kebutuhan sistem mendatang (tobe system) menuntut adanya integritas diantara sejumlah entitas data serta aplikasi yang mengelolanya. Sebagian besar data, aplikasi serta teknologi saat ini dinyatakan telah dapat memenuhi kebutuhan bisnis baik saat ini maupun untuk masa mendatang, namun perlu dilakukan optimalisasi.
Kesenjangan (gap) diantara kondisi as-is dengan to-be menunjukkan bahwa optimalisasi yang dimaksud adalah melakukan kegiatan integrasi. Berdasarkan kesenjangan antara as-is dan to-be serta adanya pengendali serta requirement bisnis mengenai integrasi, maka dibuat kebijakan untuk membuat arsitektur integrasi dan melakukan implementasi integrasi. Kegiatan integrasi dibagi ke dalam kegiatan stratejik dan taktis.
Kegiatan stratejik dalam proyek integrasi adalah pembentukan arsitektur integrasi teknis, layanan, informasi dan proses. Hasil dari dokumentasi tersebut digunakan sebagai dasar untuk melakukan kegiatan taktis yaitu mengimplementasikan integrasi aplikasi, informasi composite application dan proses. Gambar IV.22 menunjukkan bagaimana hasil analisis kondisi saat ini digunakan untuk menentukan kebutuhan sistem mendatang. Berdasarkan kebijakan yang diperoleh sebagai hasil identifikasi terhadap kesenjangan serta adanya pengendali dan requirement bisnis maka dilakukan kegiatan stratejik dan taktis integrasi.
136
Gambar IV.22 Matriks Aplikasi – Entitas