Bab IV Pembentukan Arsitektur Integrasi

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