Bab IV Pembangunan Model Arsitektur Enterprise Pada bab ini secara khusus akan didefinisikan perencanaan arsitektur organisasi pada data, aplikasi dan teknologi. Diharapkan pada tahap ini, EAP yang diharapkan dapat terdefinisi dengan lengkap. IV.1 Arsitektur Data Arsitektur data yang akan didefinisikan kali ini adalah definisi dari pemakaian data yang akan digunakan pada arsitektur aplikasi nantinya, yang akan disampaikan pada tahap ini sesuai dengan tahapan EAP dalam arsitektur data antara lain: 1. Daftar kandidat entitas 2. Definisi entitas, atribut dan relasinya IV.1.1 Daftar Kandidat Entitas Kandidat entitas merupakan entitas yang akan menjadi bagian dari perencanaan arsitektur enterprise, sehingga penentuannya dapat didasarkan pada kondisi fungsi bisnis utama pada value chain yang telah terdefinisi sebelumnya, dengan demikian maka entitas yang akan didefinisikan adalah entitas bisnis dan berdasarkan entitas bisnis akan didefinisikan entitas data. Sesuai dengan kondisi value chain tersebut, maka daftar entitas bisnis yang dapat diidentifikasi adalah sebagai berikut: 1. Entitas Penerimaan Mahasiswa 2. Entitas Operasional Akademik 3. Entitas Penglepasan Akademik Kondisi diatas didasarkan pada Zachman Framework, pendefinisian mengenai entitas pada level dua adalah menurut owner view, dimana hubungan antar entitas digambarkan dalam bentuk hubungan diantara entitas bisnisnya. Dengan demikian maka kandidat entitas yang digambarkan merupakan entitas bisnis yang didapat dari fungsi utamanya belum merupakan penggambaran entitas pada masing-masing data. Oleh sebab itu
41
fungsi bisnis utama yang didefinisikan sebelumnya langsung dijadikan sebagai entitas bisnisnya. Untuk lebih jelasnya maka perlu diturunkan kembali dari masing-masing entitas bisnis menjadi entitas data sehingga rencana pendefinisian dari arsitektur data dapat terbentuk. Berikut kandidat entitas data dari entitas bisnis yang telah dibuat. Tabel IV.1 Tabel Kandidat Entitas Entitas Bisnis
Entitas Data
Entitas Penerimaan Mahasiswa
1. Entitas Panitia PMB 2. Entitas Soal Ujian PMB 3. Entitas Peserta PMB 4. Entitas Jenis Seleksi 5. Entitas Calon Mahasiswa 6. Entitas Seleksi Sarjana 7. Entitas Seleksi Pasca Sarjana 8. Entitas Mahasiswa 9. Entitas Dosen 10. Entitas Mata Kuliah 11. Entitas Registrasi 12. Entitas Kelas 13. Entitas Jurusan 14. Entitas Ruang Kuliah 15. Entitas Biaya 16. Entitas Jadwal Kuliah 17. Entitas Bukti Pembayaran 18. Entitas Kurikulum 19. Entitas Daftar Hadir Kuliah 20. Entitas Daftar Hadir Dosen Mengajar 21. Entitas Nilai 22. Entitas Kalender Akademik 23. Entitas Perwalian 24. Entitas Alumni 25. Entitas Stake Holder 26. Entitas Personil 27. Entitas Kehadiran 28. Entitas Pendidikan 29. Entitas Honor/Gaji 30. Entitas Anggaran 31. Entitas Realisasi 32. Entitas Perkiraan 33. Entitas Pendapatan 34. Entitas Pengeluaran 35. Entitas Mitra
Entitas Operasional Akademik
Entitas Penglepasan Akademik Entitas Personil
Entitas Keuangan
42
IV.1.2 Definisi Entitas, Atribut dan Relasi Untuk menggambarkan hubungan antar entitas, maka penggambaran konseptual relasinya akan digunakan diagram E-R. Diagram E-R Bidang Akademik merupakan model konseptual data logis yang menunjukkan hubungan antar entitas-entitas di bidang akademik UIN Sunan Kalijaga Yogyakarta. Gambar IV.1 adalah Diagram E-R secara keseluruhan untuk aktivitas utama dan aktivitas pendukung pada bidang akademik.
Gambar IV.1 Diagram E-R pada Aktivitas Utama Bidang Akademik
Diagram E-R lengkap untuk masing-masing aktifitas utama dan pendukung dilampirkan pada Lampiran M dan N. IV.2 Arsitektur Aplikasi Arsitektur aplikasi yang akan diidentifikasikan adalah untuk membantu fungsi bisnis utama dari organisasi. Hal yang akan dilakukan untuk mendefinisikan aplikasi yang dibutuhkan oleh organisasi, antara lain :
43
1. Menentukan kandidat aplikasi 2. Menghubungkan aplikasi tersebut dengan fungsi bisnis yang telah didefinisikan. 3. Menghubungkan aplikasi dengan unit organisasi UIN Sunan Kalijaga Yogyakarta IV.2.1. Menentukan Kandidat Aplikasi Untuk mendefinisikan kandidat aplikasi akan digunakan Four Stage Life Cycle sebagai alat perkiraan kebutuhan terhadap aplikasi ini. Dari dekomposisi stewardship terlihat aplikasi apa yang harus dibuat untuk membantu proses bisnis utama guna memenuhi kebutuhan organisasi di UIN Sunan Kalijaga Yogyakarta dalam hal pemenuhan informasi Akademik. Berdasarkan apa yang diperoleh dari four stage life cycle pada bagian stewardship dengan referensi pada Tabel III.1 tentang four stage life cycle untuk fungsi bisnis utama dan fungsi bisnis pendukung Manajemen Sumber Daya Manusia dan Manajemen Keuangan yang menjadi kajian tesis, maka dari dekomposisi dapat terlihat aplikasi apa yang harus dibuat untuk membantu proses bisnis utama guna memenuhi kebutuhan organisasi UIN Sunan Kalijaga Yogyakarta dalam hal pemenuhan informasi Akademik. Daftar kandidat aplikasi yang muncul disajikan pada Tabel IV.2.
Tabel IV.2 Daftar Kandidat Aplikasi No.
Grup Aplikasi
No.
Kandidat Sistem Aplikasi
1
Sistem Ujian Seleksi Masuk (USM)
1.1
Aplikasi Pendaftaran Calon Mahasiswa Baru
1.2
Aplikasi Pengelolaan Hasil Test
1.3
Aplikasi Registrasi Mahasiswa Baru
2.1
Aplikasi Administrasi Kemahasiswaan
2.2
Aplikasi Pendaftaran Ulang
2.3
Aplikasi Administrasi Rencana Studi
2.4
Sistem Manajemen Kurikulum
2
Sistem Administrasi Akademik
44
Tabel IV.2 Daftar Kandidat Aplikasi (Lanjutan) No.
Grup Aplikasi
No.
Kandidat Sistem Aplikasi
2
Sistem Administrasi Akademik
2.5
Sistem Pembayaran Mahasiswa
2.6
Sistem Perwalian
2.7
Sistem Penjadwalan Kuliah
2.8
Aplikasi Pembuatan KRS dan KTM
2.9
Aplikasi Perubahan Rencana Studi
2.10
Sistem Administrasi Perkuliahan
2.11
Sistem Penjadwalan dan Administasi Ujian
2.12
Sistem Penilaian
2.13
Aplikasi Administrasi Seminar dan Ujian Komprehensif
3
4
Sistem Administrasi Penglepasan Akademik
Sistem Manajemen SDM
2.14
Sistem Pelaporan Akademik
3.1
Sistem Pendaftaran Wisuda
3.2
Sistem Pengelolaan Alumni
3.3
Sistem Pembuatan Transkrip Nilai dan Ijazah
4.1
Sistem Rekrutmen
4.2
Sistem Pembelanjaan Pegawai
4.3
Sistem Administrasi Pegawai
4.4
Sistem Manajemen Pendidikan dan Pelatihan
4.5
Sistem Manajemen Cuti
4.6
Sistem Administrasi Perhitungan Honor dan Gaji
5
Sistem Manajemen Keuangan
5.1
Sistem Anggaran
5.2
Sistem Akuntansi
Hubungan antar aplikasi dalam bentuk skematik arsitektur aplikasi ditunjukkan seperti dalam Gambar IV.2. Sistem USM merupakan sumber data untuk operasional akademik,
45
sedangkan Sistem Manajemen SDM dan Sistem Manajemen Keuangan adalah aplikasi yang mendukung terhadap aktivitas akademik.
Gambar IV.2 Skematika Arsitektur Aplikasi
IV.2.2 Deskripsi Aplikasi Deskripsi aplikasi menjelaskan aplikasi-aplikasi yang sudah didefinisikan dalam daftar kandidat aplikasi. Deskripsi lengkap arsitektur aplikasi dapat dilihat pada Lampiran F. Deskripsi dari masing-masing grup aplikasi disajikan dalam Tabel IV.3 IV.2.3 Hubungan Aplikasi dengan Entitas Data Dari kandidat sistem aplikasi pada Tabel IV.2 terdapat 28 aplikasi yang teridentifikasi, untuk melakukan validitas terhadap definisi arsitektur aplikasi, maka dilakukan melalui tabel hubungan aplikasi dengan entitas data.
46
Untuk melihat hubungan antara aplikasi dengan entitas data yang telah teridentifikasi maka disajikan dalam matriks hubungan aplikasi pada entitas data seperti dapat dilihat pada Lampiran G. Tabel IV.3 Deskripsi Grup Aplikasi Grup Aplikasi-1
Sistem Ujian Saringan Masuk
No.
1
Nama
Sistem USM
Deskripsi
Aplikasi ini mengelola data peserta seleksi dan data hasil ujian seleksi, serta menentukan mahasiswa yang akan diterima sebagai data calon mahasiswa
Grup Aplikasi-2
Sistem Administrasi Akademik
No.
2
Nama
Sistem Administrasi Akademik
Deskripsi
Aplikasi ini diutamakan untuk mengolah data registrasi calon mahasiswa, pembayaran kuliah, pendaftaran ulang mahasiswa lama, administrasi perkuliahan, sistem penilaian hingga pelapran akademik.
Grup Aplikasi-3
Sistem Administrasi Penglepasan Akademik
No.
3
Nama
Sistem Administrasi Penglepasan Akademik
Deskripsi
Aplikasi ini mengelola data mahasiswa calon wisudawan, pembuatan transkrip nilai dan ijazah serta pengelolaan alumni.
Grup Aplikasi-4
Sistem Manajemen Sumber Daya Manusia
No.
4
Nama
Sistem Manajemen SDM
Deskripsi
Aplikasi yang mengelola data pegawai mulai dari rekrutmen, pembelanjaan pegawai, administrasi pegawai dan manajemen pendidikan dan pelatihan.
47
Tabel IV.3 Deskripsi Grup Aplikasi (Lanjutan) Grup Aplikasi-5
Sistem Manajemen Keuangan
No.
5
Nama
Sistem Manajemen Keuangan
Deskripsi
Aplikasi yang digunakan untuk mengelola data keuangan yang berhubungan dengan anggaran dan transaksi akuntansi.
IV.2.4 Hubungan Aplikasi dengan Fungsi Selain itu, validitas terhadap definisi arsitektur aplikasi, dilakukan melalui tabel hubungan aplikasi dengan fungsi.Untuk melihat hubungan antara aplikasi dengan fungsi bisnis yang telah teridentifikasi maka matriks hubungan aplikasi pada fungsi dapat dilihat pada Lampiran H. IV.3 Arsitektur Teknologi Arsitektur teknologi dalam konsep EAP mendefinisikan kebutuhan teknologi yang perlu disediakan di lingkungan bisnis untuk menjalankan arsitektur data yang dapat mengelola data berdasarkan arsitektur aplikasi, dengan kata lain arsitektur teknologi merupakan kebutuhan infrastruktur yang harus disediakan untuk mendukung jalannya data dan aplikasi yang digunakan oleh organisasi. Untuk mendefinisikan kebutuhan teknologi dalam mendukung jalannya data dan aplikasi yang telah teridentifikasi sebelumnya, maka terlebih dahulu dilakukan identifikasi terhadap prinsip dan platform teknologi yang akan digunakan. IV.3.1 Identifikasi Prinsip dan Platform Teknologi Prinsip dan platform teknologi dibuat untuk mengidentifikasi jenis platform teknologi utama yang dibutuhkan untuk mendukung lingkungan berbagi pakai (shared) data dan
48
aplikasi di UIN Sunan Kalijaga Yogyakarta. Prinsip ini ditentukan dengan mempertimbangkan tren dan perkembangan teknologi informasi, model bisnis, arsitektur data, arsitektur aplikasi, sistem dan teknologi yang ada serta permintaan dan temuan dari pelaku bisnis di dalam organisasi. Prinsip platform teknologi untuk mendukung data dan aplikasi di UIN Sunan Kalijaga Yogyakarta dijelaskan dalam Tabel IV.4. Dari hasil identifikasi prinsip dan platform teknologi pada Tabel IV.4, maka dapat ditentukan platform teknologi yang harus disediakan untuk mendukung lingkungan data dan aplikasi yang akan digunakan dalam menjalankan fungsi bisnis akademik dan pendukungnya. Kebutuhan platform teknologi yang harus disediakan selengkapnya dapat dilihat pada Lampiran I. Tabel IV.4 Prinsip Platform Teknologi No. 1.
2.
Area Prinsip Sistem Operasi
Perangkat Keras
Deskripsi 1
Sistem operasi yang jaringan organisasi.
2
Sistem operasi yang dipilih bersifat portabel (dapat dijalankan pada beberapa platform), skalabel (dapat dijalankan pada komputer berskala kecil hingga besar, interoperable (dapat dijalankan pada lingkungan yang heterogen), kompatibel (mempertahankan investasi perangkat lunak yang telah ada dan memungkinkan kemajuan teknologi diterapkan pada komponen yang telah ada)
3
Sistem operasi mendukung sejumlah perangkat lunak dan aplikasi serta tool pengembangan sistem
1
Perangkat keras harus andal dan memiliki tingkat ketersediaan yang tinggi serta mendukung teknologi yang akan datang.
2
Pemilihan teknologi perangkat keras tidak berbasis fitur teknologi tertentu dan tidak berfokus pada suatu merk.
3
Perangkat keras enterprise harus memiliki tingkat layanan dan pemanfaatan yang tinggi
49
digunakan
mendukung
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan) No. 3.
Area Prinsip Komunikasi dan Jaringan
Deskripsi 1
Kapasitas jaringan menyediakan bandwidth untuk pengembangan masa depan dan beragam format data.
2
Lingkungan jaringan disediakan dengan bandwidth yang memadai dan sekumpulan protokol standar untuk mendukung layanan jaringan dan akses realtime terhadap informasi.
3
Semua lokasi fisik dalam enterprise akan dihubungkan ke backbone jaringan. Laju dan kapasitas interkoneksi ditentukan berdasarkan lokasi
4
Semua komponen yang dimanfaatkan dalam infrastruktur jaringan enterprise harus memadai dan dapat di-upgrade serta diotorisasi dan pengelolaan dilakukan secara terpusat.
5
Semua peralatan infrastruktur jaringan harus memiliki kemampuan untuk mendapatkan dan merekam statistik kinerja jaringan.
6
4.
Aplikasi
Sistem jaringan komputer dan komunikasi data, dapat dimanfaatkan lebih lanjut untuk melakukan komunikasi suara (voice) dengan transmisi gelombang suara melalui sarana digital.
1
Dokumentasi semua aplikasi dibuat dan dikelola
2
Pengadaaan aplikasi diutamakan melalui pengembangan sendiri sebelum mempertimbangkan untuk membeli.
3
Seluruh rancangan aplikasi sebaiknya bersifat modular dan harus dapat diuji.
4
Melakukan manajemen konfigurasi terhadap aplikasi untuk menangani segala upaya perubahan dan peningkatan melalui kendali versi
50
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan) No. 5.
6.
Area Prinsip Manajemen Basis Data
Keamanan
Deskripsi 1
Data dipisahkan dari aplikasi
2
Data adalah sumber daya enterprise dan tidak dimiliki oleh suatu unit tertentu.
3
Data ditangkap sekali dari digunakan sesuai kebutuhan
4
Akses data bebas dari hal lokasi dan struktur fisik dalam pandangan pemakai
5
Data di administrasikan secara terpusat dan dikelola untuk kemudahan akses serta menganut konsep data warehouse.
6
Model basis data yang digunakan adalah basis data relasional yang relatif lebih mudah dipahami dan lebih populer.
7
Informasi yang disimpan secara online tersedia secara terus menerus dan diperbaharui secara berkala sesuai kebutuhan.
8
Pemilihan DBMS disesuaikan dengan kebutuhan enterprise
1
Kebijakan dan standar keamanan meliputi akses fisik dan elektronis.
2
Akses ke sumber daya informasi enterprise akan diawasi secara terpusat oleh unit yang berhubungan dengan teknologi informasi.
3
Otorisasi aplikasi dan data dapat diberikan oleh unit terkait.
4
Kebutuhan keamanan meliputi secrecy (kebutuhan dalam sistem informasi yang hanya boleh dibaca), availibility (kebutuhan bahwa sumber daya informasi hanya dapat diperoleh dan dipakai oleh pemakai yang berhak) dan integrity (kebutuhan bahwa sumber daya informasi hanya dapat dimodifikasi dan dipelihara oleh unit terkait yang berhak).
51
sumbernya
dan
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan) No. 6.
Area Prinsip Keamanan
Deskripsi 5
Infrastruktur server sudah didukung oleh kemampuan untuk menyandikan/meng-encrpty data penting dan harus dapat perluas untuk server yang lain.
IV.3.2 Konfigurasi Platform Teknologi Konfigurasi platform teknologi didasarkan pada kebutuhan strategi distribusi data dan aplikasi dengan meninjau lokasi bisnis. Lokasi bisnis merupakan lokasi tiap unit organisasi dalam melaksanakan aktivitas bisnisnya yang memperlihatkan tempat dimana diperlukan data dan aplikasi tertentu. Suatu lokasi bisnis dengan demikian terkait dengan unit organisasi tertentu dan fungsi bisnis apa saja yang dilakukan disana. Daftar lokasi bisnis diadopsi berdasarkan peta kampus UIN Sunan Kalijaga Yogyakarta dan Gedung Rektorat UIN Sunan Kalijaga Yogyakarta. Setiap zona terdiri dari beberapa gedung yang didalamnya terdiri dari beberapa unit atau fakultas. Tabel IV.5 menunjukkan daftar lokasi bisnis di lingkungan UIN Sunan Kalijaga Yogyakarta. Sedangkan peta kampus UIN Sunan Kalijaga Yogyakarta dapat dilihat pada Lampiran J. Tabel IV.5 Daftar Lokasi Bisnis No. Lokasi
Nama Lokasi Konseptual
1
Zona A
2
Zona B
3
Zona C
4
Zona D
5
Zona E
6
Zona F
7
Zona G
8
Gedung Rektorat
52
Strategi penempatan data dan aplikasi yang dimanfaatkan sesuai prinsip platform teknologi adalah menganut konsep client/server. Aplikasi dan data akan ditempatkan pada satu lokasi dan dapat diakses oleh seluruh pemakai. Lokasi ini diharapkan akan berada dibawah tanggung jawab Pusat Komputer dan Sistem Informasi. Selanjutnya akan ditentukan konfigurasi platform teknologi secara konseptual yang meliputi pembangunan konseptual arsitektur jaringan enterprise dan konseptual arsitektur sistem bisnis. Konseptual arsitektur jaringan enterprise meliputi operasi komputasi, masukan, keluaran, perangkat penyimpanan dan fasilitas komunikasi. Konseptual arsitektur jaringan enterprise usulan disajikan pada Gambar IV.3. Konseptual arsitektur sistem bisnis merupakan arsitektur teknologi untuk menerapkan dan menata aplikasi serta basis data di dalam suatu enterprise. Gambar IV.4 memperlihatkan usulan arsitektur sistem bisnis.
Gambar IV.3 Konseptual Arsitektur Jaringan Enterprise
53
Pada Gambar IV.3, digambarkan arsitektur usulan untuk jaringan di UIN Sunan Kalijaga Yogyakarta berdasarkan kebutuhan bisnis yang berhubungan dengan fungsi akademik. Usulan untuk tiap zona dan gedung atau unit di dalamnya adalah memiliki pengelolaan jaringan lokal masing-masing sehingga apabila terjadi kerusakan atau gangguan di lokal jaringan, tidak akan mempengaruhi jaringan lokal zona atau unit lain pada gedung lainnya, selain itu akses untuk pemakaian data dapat terkendali. Sedangkan koneksi jaringan antar zona diupayakan menggunakan koneksi fast ethernet dengan media kabel fiber optic, selain didasari karena lalu lintas data antar gedung sangat tinggi, penggunaan fast ethernet akan mempercepat perpindahan data dan informasi antar gedung karena kinerjanya yang lebih cepat. Untuk koneksi antar gedung yang letaknya agak berjauhan dapat diupayakan menggunakan media wireless LAN (point to point), karena penggunaan fast ethernet dirasakan tidak efisien lagi dan komunikasi data tidak dapat dilakukan dengan cepat. Untuk koneksi dalam gedung pada setiap zona menggunakan kabel unshielded twisted pair (UTP) karena jangkauan yang memungkinkan antar lokasi dalam gedung tersebut. Dari penggambaran arsitektur jaringan yang diusulkan, maka perlu juga mengusulkan arsitektur sistem bisnis pada organisasi UIN Sunan Kalijaga Yogyakarta ini. Sistem bisnis ini diperoleh dari bisnis utama yang diselenggarakan oleh lembaga, dimana dari setiap fungsi bisnis tersebut diturunkan hingga menjadi aplikasi. Usulan arsitektur sistem bisnis tersebut dapat dilihat pada Gambar IV.4 Pemakai dapat mengakses sistem bisnis/aplikasi dengan tujuan: 1. Operational Information Update: membuat, mengubah dan menghapus data operasional secara interaktif. 2. Operational Information Inquiry: memungkinkan aplikasi untuk mengakses data secara interaktif dan menampilkan data dalam berbagai format dan media. 3. Operational Report Review: membantu pemakai untuk mendapatkan berbagai tampilan laporan.
54
4. Ad Hoc Information Review: menyediakan fasilitas untuk mengakses data enterprise. 5. Business Rules Inquiry/Update: memungkinkan pemakai yang telah diotorisasi untuk mengubah aturan yang ditetapkan untuk operasi sistem bisnis.
Fungsi Utama
Gambar IV.4 Arsitektur Sistem Bisnis
IV.3.3 Hubungan Platform Teknologi dengan Fungsi Bisnis Penentuan teknologi yang dipilih, secara langsung dimanfaatkan untuk menjalankan bisnis dan aplikasi di lingkungan enterprise. Hubungan platform teknologi yang diusulkan ke fungsi bisnis dibuat untuk menetapkan justifikasi keberadaan dan
55
pemanfaatan platform teknologi terhadap model bisnis dan arsitektur aplikasi. Hubungan ini disajikan dalam bentuk matriks yang dapat dilihat pada Lampiran K. IV.3.4 Hubungan Platform Teknologi dengan Aplikasi Justifikasi keberadaaan serta pemanfaatan platform teknologi terhadap model bisnis dan arsitektur aplikasi disajikan juga dalam hubungan platform teknologi ke aplikasi usulan. Hubungan ini disajikan dalam bentuk matriks yang dapat dilihat pada Lampiran L.
IV.4 Rencana Implementasi Rencana penerapan merupakan rencana yang dipersiapkan untuk mengimplementasikan arsitektur enterprise. Rencana arsitektur enterprise yang akan diimplementasikan didasarkan pada model bisnis, katalog sumber daya informasi dan arsitektur-arsitektur yang telah didefinisikan sebelumnya. Langkah awal yang dilakukan adalah menyusun urutan/prioritas penerapan sistem berdasarkan arsitektur aplikasi yang telah disusun sebelumnya, sehingga dari sini dapat dilihat bahwa arsitektur enterprise yang akan diimplementasikan adalah penerapan berdasarkan urutan arsitektur aplikasi yang telah dihasilkan, dengan terlebih dahulu mengimplementasikan inisiasi perencanaan, model bisnis, katalog sumber daya informasi yang ada dan arsitektur data. Untuk arsitektur teknologi, karena yang dilakukan adalah mendefinisikan kebutuhan teknologi utama untuk mendukung aplikasi dan data, dan bukan merupakan analisis kebutuhan detil, maka penerapannya masih harus dilihat berdasarkan konsidi real yang ada nantinya. Namun setidaknya, arsitektur teknologi yang telah didefinisikan dapat memberikan gambaran umum kebutuhan teknologi yang harus disediakan untuk mendukung aplikasi dan data. IV.4.1 Urutan Implementasi Aplikasi Hubungan antara aplikasi dengan entitas data yang disajikan pada matriks aplikasi terhadap entitas data pada Lampiran G, merupakan suatu hasil dari arsitektur aplikasi yang mempunyai manfaat antara lain:
56
1. Memperlihatkan kondisi data sharing dalam arsitektur aplikasi 2. Dapat digunakan untuk membuat urutan aplikasi yang akan dibangun dengan prinsip “aplikasi yang menciptakan atau membentuk (create) data sebaiknya diterapkan sebelum aplikasi yang menggunakan atau memakai (use) data tersebut” Prinsip ini penting untuk menentukan kriteria urutan prioritas aplikasi yang akan dikembangkan sesuai dengan arsitektur yang telah dibuat. Dengan prinsip tersebut, maka pengurutan implementasi aplikasi sebagaimana disarankan dalam EAP dapat dilakukan. Tahapan yang harus dilakukan adalah dengan melakukan perubahan urutan kolom dan baris pada matriks aplikasi ke entitas data seperti pada Lampiran G, sedemikian rupa sehingga membentuk pengelompokan entri data yang bersifat create (C) dapat berkelompok. Hasil optimalisasi tersebut dapat dilihat pada Lampiran G-2. Aplikasi yang telah diurutkan dikelompokkan menjadi rencana implementasi, data depency memang bukanlah satu-satunya penentu urutan aplikasi, faktor lain seperti tingkat kebutuhan, manfaat, resiko dan dampak organisasi, biaya dan lain-lain dapat dijadikan landasan urutan implementasi aplikasi. Urutan aplikasi setelah rasionalisasi pada kebutuhan, tertera pada Tabel IV.6. Sistem aplikasi yang telah diurutkan seperti pada Tabel IV.6, merupakan aplikasi pengembangan baru karena kebijakan organisasi bahwa aplikasi yang sudah ada tidak akan digunakan lagi atau diganti keseluruhan. Sehingga usulan aplikasi yang telah diurutkan, secara keseluruhan merupakan aplikasi pengembangan baru. IV.4.2 Estimasi Pelaksanaan Penerapan Estimasi dibuat dengan tujuan untuk memperkirakan kebutuhan saat penerapan dilaksanakan. Untuk menerapkan arsitektur yang telah didefinisikan, maka estimasi meliputi: 1. Estimasi waktu 2. Estimasi biaya 3. Estimasi sumber daya
57
Tabel IV.6 Urutan Penerapan Aplikasi No Urut 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
No Aplikasi 1.1 1.2 5.1 1.3 2.2 2.4 2.5 2.3 2.6 2.7 2.10 2.9 2.11 2.12 3.1 3.2 3.3 4.1 4.2 4.3 4.5 4.6
23 24 25 26
5.2 2.1 2.8 2.13
27 28
2.14 4.4
Sistem Aplikasi
Keterangan
Aplikasi Pendaftaran Calon Mahasiswa Baru Aplikasi Pengelolaan Hasil Test Sistem Anggaran Aplikasi Registrasi Mahasiswa Baru Aplikasi Pendaftaran Ulang Sistem Manajemen Kurikulum Sistem Pembayaran Mahasiswa Aplikasi Administrasi Rencana Studi Sistem Perwalian Sistem Penjadwalan Kuliah Sistem Administrasi Perkuliahan Aplikasi Perubahan Rencana Studi Sistem Penjadwalan dan Administasi Ujian Sistem Penilaian Sistem Pendaftaran Wisuda Sistem Pengelolaan Alumni Sistem Pembuatan Transkrip Nilai dan Ijazah Sistem Rekrutmen Sistem Pembelanjaan Pegawai Sistem Administrasi Pegawai Sistem Manajemen Cuti Sistem Administrasi Perhitungan Honor dan Gaji Sistem Akuntansi Aplikasi Administrasi Kemahasiswaan Aplikasi Pembuatan KRS dan KTM Aplikasi Administrasi Seminar dan Ujian Komprehensif Sistem Pelaporan Akademik Sistem Manajemen Pendidikan dan Pelatihan
Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru Pengembangan baru
Dalam tesis ini, semua estimasi diperkirakan berdasarkan asumsi berikut: 1. Pihak manajemen memberikan komitmen yang jelas terhadap pelaksanaan proyek. 2. Selama pengembangan sistem tidak terjadi perubahan kebijakan. 3. Jangka waktu pelaksanaan selama satu tahun. 4. Sumber daya yang tersedia memadai untuk pelaksanaan penerapan.
58
5. Kualitas dan kuantitas sumber daya manusia sesuai dengan kebutuhan dan tidak terjadi perputaran staf dalam tim selama penerapan. 6. Biaya untuk keperluan penerapan memadai. 7. Spesifikasi pekerjaan didasarkan pada pengembangan aplikasi yang sudah diprioritaskan. 8. Mitra kerja dari lingkungan organisasi bersedia terlibat dan bekerja sama dalam hal memberikan informasi atau membantu kelancaran penyelenggaraan proyek pengembangan ini. Berdasarkan asumsi seperti diatas, maka dapat digambarkan estimasi jadwal penyelesaian proyek dengan melihat pada hubungan antar aplikasi yang terkait seperti yang terdapat dalam Lampiran O, serta jadwal detil penerapan pada Lampiran P. Hubungan antar aplikasi yang terkait menghasilkan antarmuka-antarmuka (interface) aplikasi dari aplikasi yang telah diurutkan. Antarmuka yang dihasilkan dituangkan dalam bentuk modul, sehingga diperoleh jumlah modul yang harus dibuat untuk keseluruhan aplikasi. Berdasarkan jumlah modul yang dihasilkan oleh setiap aplikasi dibuat perkiraan waktu penyelesaian modul yang dituangkan ke dalam jadwal detil penerapan. Dari jadwal detil penerapan ini dapat diperoleh estimasi waktu yang dibutuhkan untuk menyelesaikan penerapan aplikasi. Estimasi jadwal penyelesaian proyek dapat digambarkan pada Gambar IV.5. Estimasi jadwal penyelesaian proyek dapat berubah dengan rentang waktu yang lebih panjang apabila beberapa atau seluruh asumsi yang disebutkan diatas tidak terpenuhi. Untuk estimasi kebutuhan biaya dan sumber daya yang harus disediakan dalam penerapan ini belum dapat diberikan secara detil karena beberapa faktor diantaranya adalah kondisi keuangan organisasi, pemilihan vendor pembuat aplikasi, jumlah personil yang ada dan kemampuan personil serta sarana dan prasarana penunjang yang ada.
59
Waktu Nama Aplikasi 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Tahun Bln-1 Bln-2 Bln-3 Bln-4 Bln-5 Bln-6 Bln-7 Bln-8 Bln-9 Bln-10 Bln-11 Bln-12
Aplikasi Pendaftaran Calon Mahasiswa Baru Aplikasi Pengelolaan Hasil Test Sistem Anggaran Aplikasi Registrasi Mahasiswa Baru Aplikasi Pendaftaran Ulang Sistem Manajemen Kurikulum Sistem Pembayaran Mahasiswa Aplikasi Administrasi Rencana Studi Sistem Perwalian Sistem Penjadwalan Kuliah Sistem Administrasi Perkuliahan Aplikasi Perubahan Rencana Studi Sistem Penjadwalan dan Administasi Ujian Sistem Penilaian Sistem Pendaftaran Wisuda Sistem Pengelolaan Alumni Sistem Pembuatan Transkrip Nilai dan Ijazah Sistem Rekrutmen Sistem Pembelanjaan Pegawai Sistem Administrasi Pegawai Sistem Manajemen Cuti Sistem Administrasi Perhitungan Honor dan Gaji Sistem Akuntansi Aplikasi Administrasi Kemahasiswaan Aplikasi Pembuatan KRS dan KTM Aplikasi Administrasi Seminar dan Ujian Komprehensif Sistem Pelaporan Akademik Sistem Manajemen Pendidikan dan Pelatihan
Gambar IV.5 Jadwal Penerapan Pengembangan Aplikasi
IV.4.3 Faktor Sukses Penerapan Hal-hal esensial yang harus dipertimbangkan untuk menjamin keberhasilan penerapan arsitektur enterprise sesuai dengan tujuan-tujuan organisasi dapat disediakan melalui penentuan faktor sukses implementasi. Faktor sukses ini dapat berupa variabel yang mempengaruhi pihak manajemen dalam mencapai sasaran terhadap aktivitas saat ini dan masa mendatang. Faktor sukses penerapan diantarnya terdiri dari: 1. Keterlibatan, dukungan dan komitmen manajemen. Pimpinan UIN Sunan Kalijaga Yogyakarta harus menerapkan keputusan formal untuk keberhasilan penerapan EAP dan memberikan sanksi yang tegas kepada yang tidak mematuhi.
60
2. Penetapan unit fungsi khusus sebagai penanggung jawab implementasi. PKSI sebagai pusat sumber daya informasi perlu diberi tanggung jawab dan wewenang penuh untuk penerapan EAP. 3. Kualitas sumber daya manusia yang tersedia yang berkompetensi dengan teknologi informasi. Pihak UIN Sunan Kalijaga atau unit terkait perlu menjamin ketersediaan sumber daya manusia yang berkualitas dalam penerapan arsitektur enterprise. 4. Adanya penyelenggaraan pelatihan khusus mengenai EAP baik secara teknis maupun konsep. Umumnya penerapan membutuhkan keterampilan baru atau keterampilan lain baik secara teknis maupun manajerial, sehingga perlu diselenggarakan pelatihan secara periodik yang dikelola oleh unit atau direktorat tertentu seperti unit pelaksana teknis di lingkungan UIN Sunan Kalijaga. 5. Kemampuan untuk mengevaluasi kebutuhan akan teknologi baru. Fakultas, jurusan atau unit-unit lain di UIN Sunan Kalijaga harus mengevaluasi platform teknologi yang ada untuk mendukung dan mengelola penerapan arsitektur data dan arsitektur aplikasi apakah perlu pengadaan teknologi baru untuk mendukung penerapan arsitektur tersebut. 6. Kemampuan manajerial dan kepemimpinan yang baik. Penerapan EAP membutuhkan pandangan akan pengembangan sistem informasi yang bersifat terencana. Untuk itu diperlukan suatu peran kepemimpinan/manajerial di lingkungan UIN Sunan Kalijaga dengan pola pandangan tersebut.
61
