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
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 Entitas Operasional Akademik 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
Entitas Penglepasan Akademik 24. Entitas Alumni 25. Entitas Stake Holder Entitas Personil 26. Entitas Personil
27. Entitas Kehadiran 28. Entitas Pendidikan 29. Entitas Honor/Gaji Entitas Keuangan 30. Entitas Anggaran
31. Entitas Realisasi 32. Entitas Perkiraan 33. Entitas Pendapatan 34. Entitas Pengeluaran 35. Entitas Mitra
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.
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
Gambar IV.1 Diagram E-R pada Aktivitas Utama Bidang Akademik
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 Sistem Administrasi
Akademik
2.1 Aplikasi Administrasi Kemahasiswaan 2.2 Aplikasi Pendaftaran Ulang
2.3 Aplikasi Administrasi Rencana Studi 2.4 Sistem Manajemen Kurikulum
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
2.14 Sistem Pelaporan Akademik 3 Sistem Administrasi
Penglepasan Akademik 3.1 Sistem Pendaftaran Wisuda 3.2 Sistem Pengelolaan Alumni
3.3 Sistem Pembuatan Transkrip Nilai dan Ijazah 4 Sistem Manajemen
SDM 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,
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.
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.
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
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. Area Prinsip Deskripsi
1. Sistem Operasi 1 Sistem operasi yang digunakan mendukung 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 2. Perangkat Keras 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
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan)
No. Area Prinsip Deskripsi
3. Komunikasi dan Jaringan
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 real- time 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
6
Semua peralatan infrastruktur jaringan harus memiliki kemampuan untuk mendapatkan dan merekam statistik kinerja jaringan.
Sistem jaringan komputer dan komunikasi data, dapat dimanfaatkan lebih lanjut untuk melakukan komunikasi suara (voice) dengan transmisi gelombang suara melalui sarana digital.
4. Aplikasi 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
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan)
No. Area Prinsip Deskripsi
5. Manajemen Basis Data
1 Data dipisahkan dari aplikasi
2 Data adalah sumber daya enterprise dan tidak dimiliki oleh suatu unit tertentu.
3
4
5
Data ditangkap sekali dari sumbernya dan digunakan sesuai kebutuhan
Akses data bebas dari hal lokasi dan struktur fisik dalam pandangan pemakai
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
6. Keamanan 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).
Tabel IV.4 Prinsip Platform Teknologi (Lanjutan)
No. Area Prinsip Deskripsi
6. Keamanan 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
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
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.
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.
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
Fungsi Utama
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:
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
Tabel IV.6 Urutan Penerapan Aplikasi No
Urut
No
Aplikasi Sistem Aplikasi Keterangan
1 1.1 Aplikasi Pendaftaran Calon Mahasiswa Baru Pengembangan baru 2 1.2 Aplikasi Pengelolaan Hasil Test Pengembangan baru
3 5.1 Sistem Anggaran Pengembangan baru
4 1.3 Aplikasi Registrasi Mahasiswa Baru Pengembangan baru 5 2.2 Aplikasi Pendaftaran Ulang Pengembangan baru 6 2.4 Sistem Manajemen Kurikulum Pengembangan baru 7 2.5 Sistem Pembayaran Mahasiswa Pengembangan baru 8 2.3 Aplikasi Administrasi Rencana Studi Pengembangan baru
9 2.6 Sistem Perwalian Pengembangan baru
10 2.7 Sistem Penjadwalan Kuliah Pengembangan baru
11 2.10 Sistem Administrasi Perkuliahan Pengembangan baru 12 2.9 Aplikasi Perubahan Rencana Studi Pengembangan baru
13 2.11 Sistem Penjadwalan dan Administasi Ujian Pengembangan baru
14 2.12 Sistem Penilaian Pengembangan baru
15 3.1 Sistem Pendaftaran Wisuda Pengembangan baru 16 3.2 Sistem Pengelolaan Alumni Pengembangan baru 17 3.3 Sistem Pembuatan Transkrip Nilai dan Ijazah Pengembangan baru
18 4.1 Sistem Rekrutmen Pengembangan baru
19 4.2 Sistem Pembelanjaan Pegawai Pengembangan baru
20 4.3 Sistem Administrasi Pegawai Pengembangan baru
21 4.5 Sistem Manajemen Cuti Pengembangan baru 22 4.6 Sistem Administrasi Perhitungan Honor dan
Gaji Pengembangan baru
23 5.2 Sistem Akuntansi Pengembangan baru
24 2.1 Aplikasi Administrasi Kemahasiswaan Pengembangan baru 25 2.8 Aplikasi Pembuatan KRS dan KTM Pengembangan baru 26 2.13 Aplikasi Administrasi Seminar dan Ujian
Komprehensif
Pengembangan baru 27 2.14 Sistem Pelaporan Akademik Pengembangan baru 28 4.4 Sistem Manajemen Pendidikan dan Pelatihan 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.
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.
Waktu
Nama Aplikasi
1 Aplikasi Pendaftaran Calon Mahasiswa Baru 2 Aplikasi Pengelolaan Hasil Test
3 Sistem Anggaran
4 Aplikasi Registrasi Mahasiswa Baru 5 Aplikasi Pendaftaran Ulang 6 Sistem Manajemen Kurikulum 7 Sistem Pembayaran Mahasiswa 8 Aplikasi Administrasi Rencana Studi 9 Sistem Perwalian
10 Sistem Penjadwalan Kuliah 11 Sistem Administrasi Perkuliahan 12 Aplikasi Perubahan Rencana Studi 13 Sistem Penjadwalan dan Administasi Ujian 14 Sistem Penilaian
15 Sistem Pendaftaran Wisuda 16 Sistem Pengelolaan Alumni
17 Sistem Pembuatan Transkrip Nilai dan Ijazah 18 Sistem Rekrutmen
19 Sistem Pembelanjaan Pegawai 20 Sistem Administrasi Pegawai 21 Sistem Manajemen Cuti
22 Sistem Administrasi Perhitungan Honor dan Gaji 23 Sistem Akuntansi
24 Aplikasi Administrasi Kemahasiswaan 25 Aplikasi Pembuatan KRS dan KTM
26 Aplikasi Administrasi Seminar dan Ujian Komprehensif 27 Sistem Pelaporan Akademik
28 Sistem Manajemen Pendidikan dan Pelatihan
Bln-7 Bln-8 Bln-1 Bln-2 Bln-3 Bln-4
Tahun
Bln-9 Bln-10 Bln-11 Bln-12 Bln-5 Bln-6
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.
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.
