UNIVERSITAS INDONESIA PERANCANGAN ARSITEKTUR TEKNOLOGI INFORMASI: STUDI KASUS KEMENTERIAN PEKERJAAN UMUM KARYA AKHIR ATINA DWI PALUPI

UNIVERSITAS INDONESIA

PERANCANGAN ARSITEKTUR TEKNOLOGI INFORMASI: STUDI KASUS KEMENTERIAN PEKERJAAN UMUM

KARYA AKHIR

ATINA DWI PALUPI 1206194291

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JANUARI 2014

Perancangan arsitektur ..., Atina Dwi Palupi, Fasilkom UI, 2014

UNIVERSITAS INDONESIA

PERANCANGAN ARSITEKTUR TEKNOLOGI INFORMASI: STUDI KASUS KEMENTERIAN PEKERJAAN UMUM

KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

ATINA DWI PALUPI 1206194291

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JANUARI 2014


HALAMAN PERNYATAAN ORISINALITAS

Karya Akhir ini adalah hasil karya saya sendiri, dan semua sumber baik yang dikutip maupun dirujuk telah saya nyatakan dengan benar.

Nama

:

Atina Dwi Palupi

NPM

:

1206194291

Tanda tangan

:

Tanggal

:

6 Januari 2014

ii


HALAMAN PENGESAHAN

Karya Akhir ini diajukan oleh Nama NPM Program Studi Judul Karya Akhir

: : : : :

Atina Dwi Palupi 1206194291 Magister Teknologi Informasi Perancangan Arsitektur Teknologi Informasi: Studi Kasus Kementerian Pekerjaan Umum

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia.

DEWAN PENGUJI

iii


KATA PENGANTAR

Puji syukur saya panjatkan kepada Allah SWT, karena atas berkah, hidayah dan rahmat-Nya, saya dapat menyelesaikan Karya Akhir ini. Penulisan Karya Akhir ini dilakukan dalam rangka memenuhi salah satu syarat untuk menyelesaikan studi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia. Saya sangat menyadari bahwa tanpa bantuan dan bimbingan dari berbagai pihak dari awal perkuliahan hingga penyelesaikan Karya Akhir ini, sangatlah sukar bagi saya untuk menyelesaikannya. Oleh karena itu, saya mengucapkan terima kasih kepada: 1. Dr. Achmad Nizar Hidayanto, selaku dosen pembimbing yang telah meluangkan waktu, tenaga dan pikiran dalam mengarahkan saya dalam penyusunan Karya Akhir ini. 2. Seluruh Dosen dan Civitas Akademika Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia 3. Kementerian Komunikasi dan Informatika RI sebagai instansi pemberi beasiswa Government Chief Information Officer (GCIO). 4. Ayah Dahlan Anis dan Ibunda Sri Susilah yang selalu memberikan support dan do’a tiada henti. Tiada hal yang lebih ampuh dari do’a kedua orang tua sehingga saya mendapatkan kesempatan dan kemudahan untuk melanjutkan pendidikan ini dan menyelesaikannya. 5. Ayah dan Ibu mertua tercinta, Ayah Sardi dan Ibu Marsi Surtinah yang selalu memberikan do’a restu dan dukungan selama ini. 6. Suamiku tercinta, Dany Pus Apriyanto. Atas ridho, dukungan, do’a dan restunya, saya bisa menyelesaikan Karya Akhir ini. 7. Putriku tercinta, Talita Zikria Anindita yang menjadi semangat kepada penulis menyelesaikan studi ini. 8. Bapak Ir. Rema Suwenda, MM (Kepala Bidang Penyelenggaraan Sistem Jaringan dan Aplikasi, Pusdata Kementerian Pekerjaan Umum) yang

telah

meluangkan

waktunya

untuk

dapat

iv


berkonsultasi,

memberikan arahan terkait dengan ilmu maupun kebijakan dalam penyusunan Karya Akhir ini. 9. Bapak Arif Ardhian, Ari Gunawan dan rekan-rekan di Pusdata yang telah meluangkan waktu untuk membantu Karya Akhir ini. 10. Teman dan sahabat seperjuangan MTI-GCIO yaitu Bayu, Ika, Pak Eko, Nurzaitun, Pita, Mbak Susan, Mbak Galuh, Pak Seno, Mbak Shofa, Septi, Mbk Chairina, Anday, Nia, Mas Bambang, Devid, Bari, Fefe, Mas Hari, Mas Heru, Pak Joni, Nanda, Mas Aji, Mas Syofian, Mas Tosan, Yuli dan teman2 lain yang tidak bisa saya sebutkan satu per satu. Semoga kebersamaan, keceriaan dan kekeluargaan ini tidak berhenti sampai disini. 11. Mas Wiryo, terima kasih atas segala bantuannya. 12. Serta semua pihak yang tidak bisa saya sebutkan satu per satu. Semoga semua kebaikan yang kita lakukan mendapat Ridho dan pahala dari Allah SWT.

Sebagai harapan, semoga Karya Akhir ini dapat membawa banyak manfaat bagi perkembangan ilmu dan teknologi informasi.

v


HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini: Nama NPM Program Studi Departemen Fakultas Jenis Karya

: : : : : :

Atina Dwi Palupi 1206194291 Magister Teknologi Informasi Ilmu Komputer Karya Akhir

Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Noneksklusif (Non-exclusive RoyaltyFree Right) atas karya ilmiah saya yang berjudul: PERANCANGAN ARSITEKTUR TEKNOLOGI INFORMASI : STUDI KASUS KEMENTERIAN PEKERJAAN UMUM Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Noneksklusif ini Universitas Indonesia berhak menyimpan, mengalih media/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat, dan mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan nama saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di Pada tanggal

: :

Jakarta 6 Januari 2014

vi


ABSTRAK Nama NPM Program Studi Judul Karya Akhir

: : : :

Atina Dwi Palupi 1206194291 Magister Teknologi Informasi Perancangan Arsitektur Teknologi Informasi: Studi Kasus Kementerian Pekerjaan Umum

Sesuai dengan Peraturan Menteri Pekerjaan Umum Nomor 08/PRT/M/2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, Kementerian Pekerjaan Umum mempunyai tugas menyelenggarakan urusan di bidang pekerjaan umum dalam pemerintahan untuk membantu Presiden dalam menyelenggarakan pemerintahan Negara. Demi menjalankan proses penyelenggaraan urusan di bidang pekerjaan umum yang berkualitas, maka Kementerian juga harus memiliki infrastruktur Teknologi Informasi (TI) yang handal. Demi mewujudkan infrastruktur yang handal diperlukan perencanaan arsitektur teknologi informasi agar terwujud keselarasan penerapan TI terhadap strategi bisnis organisasi sebagai acuan dalam pengambilan keputusan TI jangka panjang yang efektif dan efisien. Penelitian ini bertujuan untuk menghasilkan rancangan arsitektur TI untuk Kementerian Pekerjaan Umum. Penelitian ini berdasarkan kerangka kerja The Open Group Architecture Framework Architecture Development Method (TOGAF ADM). Penelitian ini menggunakan pendekatan dengan mengumpulkan data primer dengan melakukan wawancara ke pihak pengelola TI di Kementerian Pekerjaan Umum serta mengumpulkan data sekunder melalui cetak biru TIK Kementerian Pekerjaan Umum serta kebijakan terkait TIK. Hasil penelitian ini diantaranya: (1) Dari hasil perancangan menggunakan TOGAF ADM diperoleh 22 kandidat aplikasi baru yang diusulkan untuk dikembangkan di Kementerian Pekerjaan Umum.(2) Menghasilkan 10 prinsip arsitektur. (3) Hasil perancangan arsitektur teknologi berupa rancangan private cloud. Kata Kunci : cloud computing; TOGAF ADM; virtualisasi

vii

Universitas Indonesia


ABSTRACT Nama NPM Program Studi Judul Karya Akhir

: : : :

Atina Dwi Palupi 1206194291 Magister Teknologi Informasi Design of Information Technology Architecture : A Case Study at Ministry of Public Works

According to the Regulation of the Minister of Public Works No. 08/PRT/M/2010 on the Organization and Administration of the Ministry of Public Works, the Ministry of Public Works has the task of organizing affairs in the field of public works in the government to assist the President in carrying out the State government. For doing the affairs of the implementation process in the quality of public works, the ministry must also have an infrastructure of Information Technology (IT) are reliable. Reliable infrastructure in order to realize the necessary planning information technology architecture to realize the alignment of the application of IT to the organization's business strategy as a reference for long-term IT decisions are effective and efficient. This research aims to deliver a design of information and technology architecture for the Ministry of Public Works. This research is based on The Open Group Architecture Framework Architecture Development Method (TOGAF ADM) framework. This research approach to collect primary data by conducting interviews to IT manager in the Ministry of Public Works and collecting secondary data through ICT blueprint Ministry of Public Works and ICT related policies. Results of this research are: (1) From the results of the design using the TOGAF ADM acquired 22 new applications candidate are proposed to be developed Ministry of Public Works. (2) Generate 10 principles of architecture. (3) The results of technology architecture is private cloud. Keywords : cloud computing; TOGAF ADM; virtualization

viii



DAFTAR ISI

HALAMAN PERNYATAAN ORISINALITAS ...................................................... ii HALAMAN PENGESAHAN .................................................................................... iii KATA PENGANTAR ................................................................................................ iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI .............................. vi KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ................................. vi ABSTRAK ................................................................................................................. vii ABSTRACT .............................................................................................................. viii DAFTAR ISI ............................................................................................................... ix DAFTAR GAMBAR .................................................................................................. xi DAFTAR TABEL ..................................................................................................... xii DAFTAR LAMPIRAN ............................................................................................ xiii BAB 1 PENDAHULUAN ........................................................................................... 1 1.1 Latar Belakang ................................................................................................. 1 1.2 Rumusan Masalah ............................................................................................ 3 1.3 Tujuan dan Manfaat Penelitian ........................................................................ 4 1.4 Ruang Lingkup Penelitian ................................................................................ 4 1.5 Sistematika Penulisan ...................................................................................... 4 BAB 2 LANDASAN TEORI ...................................................................................... 6 2.1 Arsitektur Teknologi Informasi ....................................................................... 6 2.1.1 Arsitektur Perusahaan (Enterprise Architecture)...................................... 6 2.1.2 Kerangka Kerja EA (Enterprise Architecture Framework) ...................... 7 2.1.3 Pemilihan EA Framework ....................................................................... 16 2.1.4 Framework Arsitektur Teknologi Informasi berbasis Cloud Computing 18 2.2 Cloud Computing ........................................................................................... 22 2.2.1 Definisi Cloud Computing ...................................................................... 22 2.2.2 Karakteristik Cloud Computing .............................................................. 22 2.2.3 Model Layanan pada Cloud Computing ................................................. 23 2.2.4 Model Pengembangan Cloud Computing ............................................... 24 2.3 Analisa Rantai Nilai (Value Chain) ............................................................... 27 2.4 RAID (Redundant Array of Independent Disks) ............................................ 30 2.5 Telaah Penelitian Sebelumnya ....................................................................... 33 2.6 Metodologi Penelitian Kualitatif .................................................................... 35 2.7 Theoritical Framework (Kerangka Teoritis).................................................. 38 BAB 3 METODOLOGI PENELITIAN .................................................................. 40 3.1 Tahapan Penelitian ......................................................................................... 40 3.2 Instrumen Penelitian ...................................................................................... 45 BAB 4 PROFIL ORGANISASI ............................................................................... 46 4.1 Kementerian Pekerjaan Umum ...................................................................... 46 4.1.1 Profil Bisnis Organisasi .......................................................................... 46 4.1.2 Struktur Organisasi ................................................................................. 47 4.2 Pusdata (Pusat Pengolahan Data) ................................................................... 48 4.2.1 Profil Bisnis Organisasi .......................................................................... 48 ix



4.2.2 Tugas Pokok dan Fungsi ......................................................................... 49 BAB 5 ANALISIS DAN PEMBAHASAN .............................................................. 51 5.1 Tahap 4. Preliminary ..................................................................................... 51 5.1.1 Masukan (input) Fase Preliminary ......................................................... 51 5.1.2 Proses (steps) pada Fase Preliminary ..................................................... 52 5.1.3 Keluaran (output) Fase Preliminary ....................................................... 52 5.2 Tahap 5. Requirement Management .............................................................. 63 5.2.1 Architecture Vision ................................................................................. 63 5.2.2 Bussiness Architecture ............................................................................ 63 5.2.3 Information System Architecture ............................................................ 63 5.2.4 Technology Architecture ......................................................................... 64 5.2.5 Opportunities and Solutions ................................................................... 64 5.3 Tahap 6. Architecture Vision ......................................................................... 65 5.3.1 Masukan (input) Fase Architecture Vision ............................................. 65 5.3.2 Proses (steps) pada Fase Architecture Vision ......................................... 71 5.3.3 Keluaran (output) Fase Architecture Vision ........................................... 72 5.4 Tahap 7. Business Architecture ...................................................................... 76 5.4.1 Masukan (input) Fase Business Architecture .......................................... 76 5.4.2 Proses (steps) pada Fase Business Architecture...................................... 76 5.4.3 Keluaran (output) Fase Business Architecture ........................................ 84 5.5 Tahap 8. Information System Architecture .................................................... 89 5.5.1 Masukan (input) Fase Information System Architecture ........................ 89 5.5.2 Proses (steps) pada Fase Information System Architecture .................... 90 5.5.3 Keluaran (output) Fase Information System Architecture ...................... 90 5.6 Tahap 9. Technology Architecture ............................................................... 141 5.6.1 Masukan (input) Fase Technology Architecture ................................... 141 5.6.2 Proses (steps) pada Fase Technology Architecture ............................... 142 5.6.3 Keluaran (output) Fase Technology Architecture ................................. 142 5.7 Tahap 10. Opportunities and Solutions........................................................ 163 5.7.1 Masukan (input) Fase Opportunities and Solutions.............................. 163 5.7.2 Proses (steps) pada Fase Opportunities and Solutions ......................... 164 5.7.3 Keluaran (output) Fase Opportunities and Solutions............................ 164 BAB 6 PENUTUP.................................................................................................... 173 6.1 Kesimpulan .................................................................................................. 173 6.2 Saran............................................................................................................. 174 DAFTAR PUSTAKA .............................................................................................. 175 LAMPIRAN ............................................................................................................. 179

x



DAFTAR GAMBAR

Gambar 2.1 Zachman framework.................................................................................. 8 Gambar 2.2 Siklus TOGAF ADM .............................................................................. 11 Gambar 2.3 Enterprise continuum .............................................................................. 13 Gambar 2.4 Cloud computing open architecture overview diagram .......................... 19 Gambar 2.5 Model visual dari definisi cloud computing menurut NIST .................... 27 Gambar 2.6 Analisa rantai nilai .................................................................................. 28 Gambar 2.7 Siklus action research ............................................................................. 36 Gambar 2.8 Theoritical framework ............................................................................. 38 Gambar 3.1 Tahapan penelitian .................................................................................. 41 Gambar 4.1 Struktur organisasi Kementerian Pekerjaan Umum ................................ 48 Gambar 4.2 Struktur organisasi Pusdata ..................................................................... 49 Gambar 5.1 Input, steps, output dari fase preliminary................................................ 51 Gambar 5.2 Input, steps, output fase architecture vision............................................ 65 Gambar 5.3 Rantai nilai Kementerian PU .................................................................. 75 Gambar 5.4 Input, steps, output fase business architecture........................................ 76 Gambar 5.5 Functional decomposition diagram ........................................................ 84 Gambar 5.6 Input, steps, output fase information system architecture ....................... 89 Gambar 5.7 Landscape aplikasi as is ........................................................................ 108 Gambar 5.8 Application and user location diagram dari aplikasi saat ini ............... 109 Gambar 5.9 Landscape aplikasi Kementerian PU .................................................... 128 Gambar 5.10 Landscape aplikasi: status keberadaan................................................ 129 Gambar 5.11 Landscape aplikasi seluruh Satminkal ................................................ 131 Gambar 5.12 Konsep data warehouse Kementerian PU .......................................... 134 Gambar 5.13 Rancangan SOA .................................................................................. 136 Gambar 5.14 Input, steps, output pada fase technology architecture ....................... 141 Gambar 5.15 Koneksi jaringan internet Kementerian PU ke Satminkal .................. 142 Gambar 5.16 Grafik lima dimensi Kementerian Pekerjaan Umum .......................... 144 Gambar 5.17 Rancangan private cloud Kementerian PU ......................................... 148 Gambar 5.18 Rancangan topologi cluster pada host-71 ........................................... 150 Gambar 5.19 Rancangan topologi cluster pada host-72 ........................................... 151 Gambar 5.20 Rancangan topologi cluster pada host-73 ........................................... 152 Gambar 5.21 Rancangan topologi cluster pada host-74 ........................................... 153 Gambar 5.22 Rancangan topologi cluster pada host-75 ........................................... 154 Gambar 5.23 Rancangan topologi cluster pada host-76 ........................................... 155 Gambar 5.24 Rancangan topologi cluster pada host-77 ........................................... 156 Gambar 5.25 Rancangan topologi cluster pada host-78 ........................................... 157 Gambar 5.26 Input, steps, output pada fase opportunities and solutions ................. 163 Gambar 5.27 Konsolidasi server ............................................................................... 165 Gambar 5.28 Empat atribut teknik virtualisasi ......................................................... 166

xi



DAFTAR TABEL

Tabel 2.1 Perbandingan EA framework ...................................................................... 17 Tabel 2.2 Jenis-jenis RAID ......................................................................................... 30 Tabel 3.1 Pemetaan data sekunder .............................................................................. 43 Tabel 5.1 Prinsip bisnis : ease of access ..................................................................... 54 Tabel 5.2 Prinsip bisnis : business continuity ............................................................. 55 Tabel 5.3 Prinsip bisnis: recovery ............................................................................... 56 Tabel 5.4 Prinsip aplikasi: open standard ................................................................... 57 Tabel 5.5 Prinsip aplikasi: ease of use ........................................................................ 58 Tabel 5.6 Prinsip data: data is an asset ....................................................................... 59 Tabel 5.7 Prinsip data: data sharing ........................................................................... 59 Tabel 5.8 Prinsip data: secure ..................................................................................... 60 Tabel 5.9 Prinsip teknologi: sharing ........................................................................... 61 Tabel 5.10 Prinsip teknologi: industrial standard ...................................................... 62 Tabel 5.11 Stakeholder map matrix ............................................................................ 72 Tabel 5.12 Proses bisnis utama Dirjen Penataan Ruang ............................................. 77 Tabel 5.13 Proses bisnis utama Dirjen Sumber Daya Air........................................... 78 Tabel 5.14 Proses bisnis utama Dirjen Bina Marga .................................................... 79 Tabel 5.15 Proses bisnis utama Dirjen Cipta Karya ................................................... 79 Tabel 5.16 Proses bisnis utama Badan Pembinaan Konstruksi .................................. 80 Tabel 5.17 Proses bisnis utama Badan Penelitian dan Pengembangan ....................... 81 Tabel 5.18 Proses bisnis pada Inspektorat .................................................................. 82 Tabel 5.19 Proses bisnis utama Kesekretariatan ......................................................... 82 Tabel 5.20 Sistem informasi (as is) pada Pusat Pengolahan Data (Pusdata) .............. 91 Tabel 5.21 Sistem informasi (as is) pada Sekretariat Jenderal ................................... 94 Tabel 5.22 Sistem informasi (as is) pada Dirjen Penataan Ruang .............................. 96 Tabel 5.23 Sistem informasi (as is) pada Dirjen Sumber Daya Air ........................... 97 Tabel 5.24 Sistem informasi (as is) pada Dirjen Bina Marga ..................................... 98 Tabel 5.25 Sistem informasi (as is) pada Dirjen Cipta Karya .................................. 100 Tabel 5.26 Sistem informasi (as is) pada Badan Pembinaan Konstruksi ................. 103 Tabel 5.27 Sistem informasi (as is) pada Badan Penelitian dan Pengembangan ..... 105 Tabel 5.28 Sistem informasi (as is) pada Inspektorat Jenderal................................. 107 Tabel 5.29 Analisis dukungan aplikasi / SI level Satminkal ..................................... 111 Tabel 5.30 Analisis dukungan sistem informasi level Pusdata ................................. 119 Tabel 5.31 Kebutuhan sistem informasi khusus (per Satminkal) ............................. 121 Tabel 5.32 Kebutuhan sistem informasi umum ........................................................ 125 Tabel 5.33 Data component catalog pada arsitektur data (as is) .............................. 132 Tabel 5.34 Analisis kesenjangan aplikasi ................................................................. 138 Tabel 5.35 Ikhtisar analisis kondisi infrastruktur (as is) ........................................... 146 Tabel 5.36 Spesifikasi mesin virtual (virtual machine) dalam private cloud Kementerian PU ...................................................................................... 158 Tabel 5.37 Analisis kesenjangan TI .......................................................................... 162 Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur..................... 168

xii



DAFTAR LAMPIRAN Lampiran 1 : Transkrip Wawancara 1 ....................................................................... 179 Lampiran 2 : Transkrip wawancara 2 ....................................................................... 180 Lampiran 3 Kepmen PU Nomor: 489A/KPTS/M/2007 ........................................... 184

xiii



BAB 1 PENDAHULUAN

Bab ini membahas mengenai latar belakang, rumusan masalah, pertanyaan penelitian, tujuan penelitian, manfaat penelitian, ruang lingkup penelitian serta sistematika penulisan. 1.1 Latar Belakang Sesuai dengan Peraturan Menteri Pekerjaan Umum Nomor 08/PRT/M/2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, Kementerian Pekerjaan Umum mempunyai tugas menyelenggarakan urusan di bidang pekerjaan umum dalam pemerintahan untuk membantu Presiden dalam menyelenggarakan

pemerintahan

Negara.

Demi

menjalankan

proses

penyelenggaraan urusan di bidang pekerjaan umum yang berkualitas, maka Kementerian juga harus memiliki infrastruktur teknologi informasi (TI) yang handal. Demi mewujudkan infrastruktur TI yang handal diperlukan perancangan arsitektur teknologi informasi agar terwujud keselarasan penerapan TI terhadap strategi bisnis organisasi sebagai acuan dalam pengambilan keputusan TI jangka panjang yang efektif dan efisien. Pusat Pengolahan Data (Pusdata) Kementerian Pekerjaan Umum merupakan salah satu Satuan Administrasi Pangkal (Satminkal) di bawah Sekretariat Jenderal Kementerian Pekerjaan Umum. Tugas pokok dari Pusdata menurut Peraturan Menteri PU Nomor 08/PRT/M/2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, yaitu melaksanakan pembinaan, pengembangan, pengelolaan dan penyediaan data infrastruktur bidang pekerjaan umum serta penyelenggaraan sistem informasi mendukung manajemen Kementerian. Pusdata memanfaatkan TI sebagai alat bantu dalam menjalankan tugas pokok tersebut agar efektif dan efisien dalam mendukung kinerja Kementerian Pekerjaan Umum. Sehingga sangat memerlukan sebuah perancangan infrastruktur TI yang mendukung implementasi layanan yang memanfaatkan TI dalam organisasi Kementerian

Pekerjaan 1

Umum.



2

Saat ini, Kementerian Pekerjaan Umum memiliki 30 server yang terbagi menjadi dua tempat, yaitu 20 server pada data center 1 (di gedung Pusdata) dan 10 server pada data center 2 (di gedung utama baru). Selain server-server tersebut, masih terdapat perangkat komputasi lain yang masih bersifat silo-silo di pusdata dan di masing-masing Satminkal. Hal ini mengakibatkan sulitnya koordinasi baik dalam hal kepemilikan dan pengembangan teknologi dan kapasitas serta interoperabilitas data antar Satminkal (Ardhian, 2013). Saat ini sistem informasi yang digunakan masih terpisah-pisah dan belum terintegrasi. Misalnya, di satminkal Badan Pembinaan Konstruksi memiliki 8 sistem informasi yang berbasis web. Kedelapan sistem informasi tersebut belum sepenuhnya mendukung pengambilan keputusan bagi pimpinan namun baru sebatas pengelolaan data. Penyajian yang lebih informatif belum terlaksana akibat sistem masih terpisah-pisah. Pusdata saat ini juga memiliki sistem informasi seperti SIGI, loket pelayanan peta, geotagging, e-Procurement, SIM Komunikasi Data Kementerian PU yang berperan dalam penyajian informasi lintas satminkal dalam rangka pengambilan keputusan pada level Kementerian masih bersifat parsial, sehingga penyajian informasi kepada pimpinan belum komprehensif. Selain kondisi sistem informasi tersebut, kondisi infrastruktur TI juga masih kurang efisien dalam pengelolaannya. Hal ini bisa dilihat dalam hal pengadaan perangkat komputasi terutama server. Secara umum, Satminkal yang membangun dan mengimplementasikan aplikasi baru selalu melakukan pengadaan server baru. Hal ini selain membutuhkan waktu dan sumber daya yang tinggi bagi pengelola untuk mengaktifkannya (mulai dari instalasi server, sistem operasi, instalasi database dan lain-lain), pengadaan 1 server untuk 1 aplikasi membutuhkan penambahan ruang penyimpanan fisik server, sedangkan tiap Satminkal memiliki ruang kendali TI yang terbatas. Dalam rencananya ke depan, pihak Pusdata memiliki pandangan mengenai terwujudnya integrasi data serta berbagi bersama infrastruktur TI antara satu Satminkal dengan Satminkal yang lain di Kementerian Pekerjaan Umum. Universitas Indonesia


3

Karya Akhir ini membahas perancangan arsitektur teknologi informasi pada Kementerian Pekerjaan Umum menggunakan kerangka kerja The Open Group Architecture Framework (TOGAF). Perancangan arsitektur dilakukan dengan membatasi ruang lingkup yang terdiri atas enam fase awal dari TOGAF ADM yang mencakup

preliminary, architecture

vision, business

architecture,

information system architecture, technology architecture dan opportunities and solutions. Karya akhir ini akan memberikan usulan solusi yang bisa diterapkan dalam rangka menjalankan rencana pihak Pusdata untuk mewujudkan integrasi data serta berbagi bersama infrastruktur TI antara satu Satminkal dengan Satminkal yang lain di Kementerian Pekerjaan Umum. 1.2 Rumusan Masalah Dari uraian latar belakang di atas, secara umum permasalahan yang dihadapi yaitu: 1. Pengelolaan infrastruktur TI masih kurang efisien dalam hal pengadaan perangkat komputasi terutama server. 2. Kebutuhan

akan

keberadaan

rancangan

arsitektur

TI

untuk

menterjemahkan kebutuhan dalam membangun integrasi data serta berbagi bersama infrastruktur TI pada Kementerian Pekerjaan Umum ke dalam sebuah dokumen sehingga dapat digunakan sebagai acuan atau pedoman tertulis dalam pembangunan infrastruktur TI berikutnya. Untuk dapat mengatasi permasalahan tersebut di atas, Kementerian Pekerjaan Umum harus memiliki arsitektur teknologi informasi yang mampu memberikan gambaran dan suatu usulan yang mampu mengakomodasi kebutuhan organisasi terhadap layanan TI. Sehingga dapat disimpulkan untuk pertanyaan penelitian (research question) yang utama dari beberapa permasalahan di atas adalah: “Bagaimana rancangan arsitektur teknologi informasi yang sesuai untuk Kementerian Pekerjaan Umum” ?



4

1.3 Tujuan dan Manfaat Penelitian Secara umum tujuan dari penelitian ini adalah menghasilkan rancangan arsitektur TI untuk Kementerian Pekerjaan Umum. Sedangkan manfaat yang diharapkan dari hasil penelitian ini adalah: 1. Manfaat untuk organisasi (Kementerian Pekerjaan Umum), yaitu rancangan

arsitektur

TI

dapat

digunakan

sebagai

acuan

dalam

pembangunan infrastruktur TI berikutnya. 2. Manfaat untuk bidang akademik, yaitu menjadi bahan referensi bagi penelitian selanjutnya terutama dalam pembuatan rancangan arsitektur TI. 1.4 Ruang Lingkup Penelitian Sumber studi kasus dan pengambilan data dilakukan langsung di unit kerja setingkat eselon 2 pada Kementerian Pekerjaan Umum, yaitu Pusat Pengolahan Data (Pusdata) serta melakukan studi literatur terkait dengan topik bahasan karya akhir. Observasi dilakukan terhadap entitas TI termasuk data center. Perancangan arsitektur TI dilakukan dengan membatasi ruang lingkup yang terdiri dari enam fase awal dari TOGAF ADM yang mencakup: preliminary, architecture vision, business architecture, information system architecture, technology architecture dan opportunities and solutions. 1.5 Sistematika Penulisan Penulisan dalam penelitian ini disusun dengan sistematika penulisan dengan membagi beberapa pembahasan yang dikelompokkan ke dalam bab-bab sebagai berikut: 1. Bab 1 Pendahuluan, yang membahas mengenai latar belakang, rumusan masalah, pertanyaan penelitian, tujuan penelitian, manfaat penelitian, ruang lingkup penelitian serta sistematika penulisan. 2. Bab 2 Landasan Teori, yang membahas mengenai teori-teori yang berhubungan dengan topik penelitian, telaah penelitian sebelumnya, teori mengenai metodologi yang relevan serta pembuatan theoritical framework. Universitas Indonesia


5

3. Bab 3 Metodologi Penelitian, yang membahas mengenai metodologi penelitian yang digunakan sebagai panduan dalam melakukan penelitian. 4. Bab 4 Profil Organisasi, yang membahas secara umum profil organisasi yang menjadi objek penelitian. 5. Bab 5 Analisis dan Pembahasan, yang memberikan penjelasan atas datadata yang dikumpulkan dan analisis terhadap data yang diperoleh dan selanjutnya akan dijabarkan hasil (output) dari penelitian. 6. Bab 6 Kesimpulan dan Saran, yang berisi kesimpulan dari penelitian yang dilakukan dan saran yang dapat digunakan sebagai usulan terhadap penelitian selanjutnya.



BAB 2 LANDASAN TEORI

Bab ini membahas mengenai teori-teori yang berhubungan dengan topik penelitian, telaah penelitian sebelumnya, teori mengenai metodologi yang relevan serta pembuatan theoritical framework. 2.1 Arsitektur Teknologi Informasi 2.1.1 Arsitektur Perusahaan (Enterprise Architecture) Arsitektur dapat didefinisikan sebagai sebuah blueprint yang menjelaskan bagaimana semua elemen TI dan manajemen bekerja bersama dalam satu kesatuan dan memberikan gambaran eksplisit mengenai hubungan antara proses manajemen dengan TI yang sekarang dan yang diharapkan (Handley, 2008) dalam (Lusa & Sensuse, 2011). Sedangkan pengertian enterprise umumnya disamakan dengan pengertian organisasi atau perusahaan. Setiap kumpulan perusahaan atau institusi yang memiliki seperangkat tujuan atau mandat tunggal. Pada konteks ini, enterprise tidak hanya terbatas pada perusahaan, sebuah divisi atau departemen suatu perusahaan atau suatu jaringan organisasi dengan geografis yang berbeda yang terkait dengan tujuan tertentu, organisasi pemerintah dan seterusnya (Minoli, 2008). Pengertian enterprise architecture (EA) telah berkembang dalam beberapa tahun. Beberapa pengertian enterprise architecture, diantaranya adalah: 1. Dalam TOGAF (The Open Group, 2009), enterprise architecture diartikan sebagai: “An effective enterprise architecture is critical to business survival and success and is the indispensable means to achieving competitive advantage through IT” Arsitektur perusahaan yang efektif merupakan hal yang penting bagi keberlangsungan dan keberhasilan bisnis dan sangat diperlukan untuk mencapai

daya

saing

melalui 6

teknologi

informasi.



7

2. Menurut

System

and

Software

Consortium,

“enterprise

architecture

berhubungan dengan misi, tujuan dan sasaran organisasi untuk memproses pekerjaan dan hal teknis atau infrastruktur teknologi informasi yang diperlukan untuk mengeksekusinya” (Urbaczewski, 2006). 3. Architecture enterprise adalah (i) basis aset informasi strategis, (ii) informasi yang diperlukan untuk melakukan misi, (iii) teknologi yang diperlukan untuk melakukan misi, dan (iv) transisi proses untuk menerapkan teknologi baru dalam menanggapi perubahan kebutuhan dan termasuk (i) arsitektur dasar, (ii) arsitektur target dan (iii) arsitektur pengurutan (Hagan, 2004).

Dalam mengembangkan enterprise architecture, terdapat beberapa alat bantu pendefinisian komponen-komponen dalam sistem tersebut. Alat bantu ini dikenal sebagai kerangka kerja arsitektur. Sebuah kerangka kerja arsitektur umumnya merupakan sekumpulan cara pandang terhadap organisasi. Kebanyakan kerangkakerangka kerja terdiri dari 4 domain dasar, yaitu (1) arsitektur bisnis, (2) arsitektur informasi, (3) arsitektur sistem aplikasi dan (4) arsitektur teknologi infrastruktur (Minoli, 2008). 2.1.2 Kerangka Kerja EA (Enterprise Architecture Framework) Enterprise architecture framework mengidentifikasikan jenis informasi yang dibutuhkan untuk mendeskripsikan arsitektur enterprise, mengorganisasikan jenis informasi dalam struktur logis dan mendeskripsikan hubungan antara jenis informasi tersebut. Informasi dalam arsitektur enterprise sering dikategorikan dalam model-model atau sudut pandang arsitektural (Setiawan, 2009). Dalam

mengembangkan

enterprise

dikembangkan sendiri suatu EA

architecture,

perlu

diadopsi

atau

framework. Terdapat berbagai macam

framework yang dapat dimanfaatkan untuk pengembangan enterprise architecture seperti: Zachman Framework, Federal Enterprise Architecture Framework (FEAF),

DoD

Architecture

Framework

(DoDAF),

Treasury

Enterprise

Architecture Framework (TEAF), The Open Group Architecture Framework (TOGAF) dan lain-lain.



8

2.1.2.1 Zachman Framework Salah satu framework untuk pengembangan enterprise architecture adalah framework yang diperkenalkan oleh Zachman atau disebut dengan Framework Zachman. Framework Zachman merupakan suatu alat bantu yang dikembangkan untuk memotret arsitektur organisasi dari berbagai sudut pandang dan aspek, sehingga didapatkan gambaran organisasi secara utuh Zachman dalam (Setiawan, 2009). Framework Zachman untuk arsitektur enterprise dapat diilustrasikan seperti pada Gambar 2.1.

Gambar 2.1 Zachman framework Sumber: (Zachman, 1997)

Keenam baris pada Gambar 2.1 menyajikan enam pandangan (perspektif), sebagaimana yang dipandang oleh perencana, pemilik, perancang, pembangun dan functioning enterprise. Penjelasannya adalah sebagai berikut: a. Planner atau perencana: menetapkan objek dalam pembahasan, latar belakang, lingkup dan tujuan enterprise.



9

b. Owner atau pemilik: penerima atau pemakai produk atau jasa akhir dari enterprise. c. Designer atau perancang: perantara antara apa yang diinginkan oleh pemilik dan apa yang dapat dicapai secara teknis dan fisik. d. Builder atau pembangun: pengawas atau pengatur dalam menghasilkan produk atau jasa akhir. e. Subkontraktor: bertanggung jawab membangun dan merakit bagian-bagian dari produk atau jasa akhir. f. Functioning enterprise: wujud nyata dari produk atau jasa akhir

Karakteristik Zachman Framework antara lain: (1) mengkategorikan deliverables dari EA, (2) kegunaan EA yang terbatas, (3) banyak diadopsi di seluruh dunia, (4) perspektif view yang kurang menyeluruh, (5) merupakan tool untuk perencanaan. Jadi, dapat disimpulkan keunggulan dari Zachman sebagai berikut (Minoli, 2008): a. Framework ini sangat mudah dipahami, karena mengacu kepada organisasi secara umum dan menggambarkan tools dan metodologi secara independen. b. Semua komponen dapat dipetakan untuk menemukan kondisi yang paling cocok dengan organisasi. c. Adanya klasifikasi memungkinkan untuk mengidentifikasikan seluruh bagianbagian berbeda dari infrastruktur TI melalui perspektif yang beda dalam logika yang berbeda. Dengan demikian, akan lebih banyak daftar komponen yang lebih teratur untuk dianalisa.

2.1.2.2 Federal Enterprise Architecture Framework (FEAF) FEAF dikembangkan oleh oleh Federal Agency yang melewati batas multiple inter-agency.

FEAF

menyediakan

standar

untuk

mengembangkan

dan

mendokumentasikan deskripsi arsitektur pada area yang menjadi prioritas utama. FEAF membagi arsitektur menjadi area bisnis, data, aplikasi dan teknologi, di mana sekarang FEAF juga mengadopsi Zachman framework dan metodologi perencanaan EA oleh Spewak (Minoli, 2008). Struktur komponen FEAF diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis, penggunaan teknologi, aliran informasi dan Universitas Indonesia


10

investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan mengimplementasikan lingkungan operasional di top-level dan mendukung implementasi dari sistem TI. Objektif dari FEAF memungkinkan pemerintahan federal dan organisasinya mencapai hal berikut (Minoli, 2008): a. Meningkatkan teknologi dan mengurangi pengeluaran TI yang berlebih di pemerintahan. b. Memfasilitasi integrasi TI dan sharing data antar institusi. c. Menggunakan praktik arsitektur yang umum. d. Membantu institusi bertemu mandat legislatif enterprise architecture-nya.

2.1.2.3 The Open Group Architecture Framework (TOGAF) The Open Group Architecture Framework (TOGAF) merupakan salah satu framework yang umum menjadi acuan dalam membangun arsitektur enterprise. TOGAF menyediakan metode dan tool untuk membantu dalam pembangunan, pengelolaan dan implementasi arsitektur enterprise. Keseluruhan aktivitas tersebut dilakukan melalui model proses yang iteratif, didukung oleh beberapa best practice dan berprinsip menggunakan ulang aset-aset arsitektur yang sudah ada. Metode-metode yang digunakan dalam TOGAF disebut dengan Architecture Development Method (ADM) (The Open Group, 2009). ADM merupakan metode generik yang merupakan sekumpulan tahapan aktivitas atau fase yang berjalan secara sekuens yang digunakan dalam memodelkan pengembangan

arsitektur

enterprise.

Aktivitas

dalam

ADM

meliputi

pembangunan framework arsitektur, membangun isi dan komponen arsitektur, proses transisi atau migrasi dari sistem saat ini dan tata kelola dari realisasi arsitektur. ADM terbagi atas 8 fase aktivitas utama terurut dan iteratif dan sebuah fase awal. TOGAF ADM seperti pada Gambar 2.2 merupakan metode yang bersifat fleksibel yang mampu menyesuaikan dengan perubahan kebutuhan selama perancangan dilakukan.



11

Gambar 2.2 Siklus TOGAF ADM Sumber : (The Open Group, 2009)

2.1.2.3.1 TOGAF ADM Output Ketika menerapkan ADM, terdapat 2 jenis output yang dihasilkan dari masing-masing fase, yaitu: 1. Deliverable Merupakan keseluruhan hasil dari penerapan metode yang secara spesifik telah di-review, disetujui dan ditandatangani oleh seluruh pihak yang terlibat. Deliverable menggambarkan output dari keseluruhan proses dan terdokumentasikan untuk menjadi Architecture Repository yang menjadi referensi implementasi arsitektur pada saat tersebut. 2. Artifact Merupakan hasil kerja yang lebih spesifik dan menggambarkan arsitektur berdasarkan sisi pandang tertentu. Contohnya adalah network diagram untuk menggambarkan arsitektur dari sisi jaringan komputer. Artifact diklasifikasikan menjadi katalog (daftar objek), matrik (relasi antar Universitas Indonesia


12

objek) dan diagram (gambaran objek). Architecture deliverable terdiri atas beberapa artifact. 2.1.2.3.2 Prinsip Pengembangan Arsitektur Dalam proses pengembangan arsitektur enterprise, TOGAF ADM menetapkan 3 prinsip sebagai ukuran kesuksesan pengembangan arsitektur yang dilakukan oleh organisasi. Ketiga prinsip tersebut dapat dijelaskan sebagai berikut: 1. Prinsip Enterprise Pengembangan arsitektur yang dilakukan diharapkan mendukung seluruh bagian organisasi, termasuk unit-unit organisasi yang membutuhkan. Hasil desain menyediakan sebuah dasar dalam menentukan keputusan bagi seluruh organisasi dan sekumpulan instruksi dalam mencapai tujuan bisnis. 2. Prinsip Teknologi Informasi Menyediakan panduan dalam penggunaan dan pembangunan seluruh sumber daya dan aset TI dalam organisasi. Prinsip TI menekankan bahwa keberadaan sumber daya TI harus menjamin produktivitas bisnis. 3. Prinsip Arsitektur Perancangan arsitektur sistem merupakan hasil konsensi (kesepakatan) dari seluruh pihak yang terkait dalam organisasi dan mendukung kebutuhan proses bisnis organisasi. 2.1.2.3.3 Enterprise Continuum Umumnya cukup sulit untuk membangun sebuah arsitektur tunggal terintegrasi yang mampu memenuhi semua kebutuhan bisnis organisasi untuk keseluruhan waktu keberlangsungan bisnis. Oleh karena itu diperlukan penyesuaian desain yang bukan hanya menggunakan satu desain tetapi menggunakan beberapa desain arsitektur yang memiliki fungsi berbeda dan mampu saling terintegrasi. Dengan memecah atau mempartisi desain arsitektur menjadi beberapa desain, maka mempermudah dalam pemecahan masalah atau kebutuhan bisnis menjadi komponen yang mudah dikelola.



13

Setiap partisi nantinya akan dibangun menjadi solusi teknologi tertentu dan nantinya menjadi baseline pengembangan desain arsitektur selanjutnya. Gambar 2.3 berikut menggambarkan mengenai enterprise continuum.

Gambar 2.3 Enterprise continuum Sumber : (The Open Group, 2009)

2.1.2.3.4 Tahapan Architecture Development Method Pada Gambar 2.2, tampak bahwa metode TOGAF ADM terdiri dari 8 fase utama yang dilakukan secara bertahap. Secara umum, TOGAF merupakan kerangka kerja untuk membangun dan mengelola arsitektur TI. Dalam aktivitas membangun baseline arsitektur TI , 2 fase yaitu implementasi tata kelola dan manajemen perubahan arsitektur bersifat opsional. Tahapan dari masing-masing fase TOGAF ADM dijabarkan sebagai berikut: 1. Fase Pendahuluan (Preliminary) Pada tahap awal dilakukan persiapan yang diperlukan untuk membangun arsitektur enterprise. Aktivitas yang dilakukan umumnya adalah pendataan sumber informasi seperti narasumber dan dokumentasi yang terkait. Fase ini terdiri dari fase persiapan yang bertujuan untuk Universitas Indonesia


14

mengkonfirmasi komitmen dari manajemen, penentuan framework dari prinsip arsitektur yang akan digunakan pada pengembangan enterprise architecture. 2. Fase Visi Arsitektur (Architecture Vision) Aktivitas yang dilakukan pada fase architecture vision meliputi identifikasi visi dan misi serta strategi bisnis organisasi. Arsitektur TI yang dimiliki merupakan masukan dalam proses pembangunan arsitektur yang baru. Umumnya aktivitas pada fase ini berisikan studi literatur dari dokumentasi organisasi untuk mendapatkan pandangan awal. 3. Fase Arsitektur Bisnis (Business Architecture) Aktivitas yang dilakukan pada fase business architecture adalah mendefinisikan kondisi awal arsitektur bisnis, menentukan model bisnis atau aktivitas bisnis yang diinginkan berdasarkan skenario bisnis. Dilakukan gap analysis antara target dan kondisi awal dari arsitektur bisnis dan merencanakan strategi yang sesuai sebagai solusinya. 4. Fase Arsitektur Sistem Informasi (Information System Architecture) Pada fase information system architecture lebih menekankan pada aktivitas

bagaimana

arsitektur

sistem

informasi

dikembangkan.

Pendefinisian arsitektur sistem informasi dalam tahapan ini meliputi arsitektur aplikasi dan arsitektur data yang akan digunakan oleh organisasi. Arsitektur aplikasi lebih menekankan pada bagaimana kebutuhan aplikasi direncanakan dengan menggunakan Application Portfolio Catalog. Artifact dari fase ini meliputi: User Location Diagram dan lain-lain (The Open Group, 2009). Arsitektur data lebih memfokuskan pada bagaimana data digunakan untuk kebutuhan fungsi bisnis, proses dan layanan. 5. Fase Arsitektur Teknologi (Technology Architecture) Aktivitas yang dilakukan pada fase technology architecture adalah membangun desain arsitektur teknologi yang nantinya direalisasikan untuk memenuhi kebutuhan implementasi desain sistem informasi. Pada tahap ini didefinisikan kondisi awal arsitektur teknologi dan target desain Universitas Indonesia


15

teknologi dalam bentuk teknologi portofolio yang meliputi perangkat lunak dan perangkat keras. 6. Fase Peluang dan Solusi (Opportunities and Solutions) Aktivitas yang dilakukan pada fase opportunities and solutions adalah mengkaji manfaat, peluang, tantangan dan solusi yang meliputi arsitektur sebelumnya dalam proses transisi dari desain awal menuju desain target. Hasil dari kajian tersebut dapat menjadi landasan pemilihan arsitektur yang akan diimplementasikan. 7. Fase Perencanaan Migrasi (Migration Planning) Pada fase migration planning, rencana migrasi disusun secara matang untuk menjamin proses implementasi berlangsung dengan lancar. Membangun blok-blok rencana implementasi dan menyusun rencana prioritasi implementasi berdasarkan kebutuhan bisnis dan jaminan ketersediaan layanan. Teknik pemodelan dapat menggunakan matrik penilaian dan keputusan kebutuhan utama dan pendukung dalam organisasi terhadap implementasi sistem informasi. 8. Implementation Governance Aktivitas yang dilakukan pada fase implementation governance adalah membangun rekomendasi tata kelola TI sebagai hasil implementasi yang telah dilaksanakan. Tujuan dari adanya tata kelola adalah untuk menjamin keberlangsungan hasil implementasi sesuai dengan desain arsitektur dan berhasil memenuhi tujuan awal pembangunan arsitektur. Dalam membangun tata kelola TI dapat dipadukan dengan framework yang spesifik untuk tata kelola seperti COBIT. 9. Architecture Change Management Aktivitas yang dilakukan pada fase architecture change management adalah mengawasi perkembangan teknologi dan perubahan kondisi bisnis organisasi sebagai referensi rencana perubahan arsitektur. Perubahan dari arsitektur yang baru memerlukan rencana manajemen perubahan untuk menentukan siklus pengembangan arsitektur selanjutnya. Capacity



16

planning merupakan salah satu aspek penilaian dalam merencanakan perubahan arsitektur TI. 2.1.3 Pemilihan EA Framework Untuk memilih sebuah EA Framework terdapat kriteria yang berbeda yang bisa dijadikan sebagai acuan, misalnya (Setiawan, 2009): a. Tujuan dari EA dengan melihat bagaimana definisi arsitektur dan pemahamannya, proses arsitektur yang telah ditentukan sehingga mudah untuk diikuti, dukungan terhadap evolusi arsitektur. b. Masukan untuk aktifitas EA seperti pendorong bisnis dan masukan teknologi. c. Keluaran dari aktifitas EA seperti model bisnis dan desain transisional untuk evolusi dan perubahan. Framework merupakan sebuah bagian penting dalam mendesain EA yang seharusnya memiliki kriteria: a. Reasoned Framework yang masuk akal yang dapat memungkinkan pembuatan arsitektur yang bersifat deterministik ketika terjadi perubahan konstrain dan tetap menjaga integritasnya walaupun menghadapi perubahan bisnis dan teknologi serta demand yang tak terduga. b. Cohesive Framework yang kohesif memiliki sekumpulan perilaku yang akan seimbang dalam cara pandang dan scope-nya. c. Adaptable Framework haruslah bisa beradaptasi terhadap perubahan yang mungkin sangat sering terjadi dalam organisasi. d. Vendor-independent Framework haruslah tidak tergantung pada vendor tertentu untuk benarbenar memaksimalkan benefit bagi organisasi. e. Technology-independent f. Domain-neutral



17

Domain-neutral adalah atribut penting bagi framework agar memiliki peranan dalam pemeliharaan tujuan organisasi. g. Scalable Framework haruslah beroperasi secara efektif pada level departemen, unit bisnis, pemerintahan dan level korporat tanpa kehilangan fokus dan kemampuan untuk dapat diaplikasikan.

Dari kriteria tersebut bila dipetakan ke dalam beberapa framework yang sudah dibahas sebelumnya maka hasilnya ditunjukkan pada Tabel 2.1.

Tabel 2.1 Perbandingan EA framework Sumber : (Setiawan, 2009)

No

1 2 3 4

5 6 7 8 9 10 11

Kriteria Definisi arsitektur dan pemahamannya Proses arsitektur yang detil Support terhadap evolusi arsitektur Standarisasi

Architecture Knowledge Base Pendorong bisnis Input Teknologi Model bisnis Desain transisional Neutrality Menyediakan prinsip arsitektur

Zachman Parsial

FEAF Ya

TOGAF Ya. Pada fase preliminary Ya. ADM dengan 9 fase yang detil Ya. Ada fase migration planning Ya. Menyediakan TRM, standards information Ya

Ya

Tidak

Tidak

Ya

Tidak

Tidak

Tidak

Ya

Parsial Tidak Ya Tidak

Ya Ya Ya Ya

Ya Tidak

Tidak Tidak. Hanya untuk karakterist ik FEAF

Ya Ya Ya Ya. Hasil fase migration planning Ya Ya

Dalam prakteknya, EA Framework tidak ada yang sempurna, masing-masing memiliki kelebihan dan kekurangan. Bahkan penggunaan EA framework di masing-masing enterprise bisa menjadi berbeda. Hal ini tergantung dengan karakteristik dari enterprise itu sendiri, fokus yang ingin dicapai dan lain-lain. Universitas Indonesia


18

Dari hasil pemetaan kriteria tersebut dapat ditarik kesimpulan untuk studi kasus enterprise dimana masih belum terdapat EA dan keperluan untuk pengembangan EA yang mudah dan jelas maka EA framework yang cocok adalah TOGAF. Terkait dengan hal tersebut, pada studi kasus penelitian ini yaitu Kementerian Pekerjaan Umum saat ini belum terdapat EA dan terdapat keperluan untuk pengembangan EA yang mudah, sehingga penelitian ini menggunakan TOGAF sebagai kerangka kerja atau framework untuk menghasilkan arsitektur teknologi informasi untuk Kementerian Pekerjaan Umum. 2.1.4 Framework Arsitektur Teknologi Informasi berbasis Cloud Computing Secara singkat, teknologi cloud computing bergantung pada beberapa teknologi kunci yaitu teknologi virtualisasi dan service oriented architecture (SOA) (Zhang & Zhou, 2009). Teknologi virtualisasi mengatur bagaimana replikasi dari sistem operasi, middleware dan aplikasi disediakan dan dialokasikan pada mesin fisik sesuai dengan lokasi yang benar. Replikasi tersebut dapat dengan mudah dipindahkan dari satu lokasi ke lokasi lainnya kapan pun tanpa mengganggu jalannya proses yang lain. Konsep virtualisasi akan menghemat penggunaan lisensi dari sistem operasi, middleware atau aplikasi lainnya. Contoh penerapan teknologi ini dapat ditemukan dalam layanan virtual private server hosting. Dalam layanan hosting tersebut, beberapa client yang menyewa jasa web hosting dapat ditempatkan dalam satu server yang sama, namun masing-masing client dapat mengatur konfigurasi server dan perangkat lunak di dalamnya tanpa mempengaruhi client yang lainnya. Jadi seolah-olah setiap client memiliki server-nya masing-masing. Sedangkan SOA merupakan perkembangan arsitektur sistem atau perangkat lunak yang digunakan untuk componentization, reusability, extensibility and flexibility (Zhang & Zhou, 2009). Untuk membangun skalabilitas dari cloud computing platform, diperlukan peran SOA tersebut sehingga setiap komponen dalam cloud computing dapat digunakan kembali (reusable), dapat



19

berkomunikasi tanpa terhambat oleh platform serta dapat dapat ditambah dan dikurangi dengan mudah. CLOUD COMPUTING OPEN ARCHITECTURE (CCOA) Cloud Computing Open Architecture (CCOA) merupakan salah satu model arsitektur teknologi informasi berbasis cloud computing yang pertama kali diusulkan oleh Liang-Jie Zhang dan Qun Zhou pada tahun 2009 (Zhang & Zhou, 2009). Cloud Computing Open Architecture (CCOA) memiliki tiga tujuan yang akan membantu institusi dalam mengembangkan arsitektur yang baik untuk cloud computing. Tujuan pertama adalah mencari jalan untuk menciptakan suatu platform yang scalable dan configurable untuk cloud computing. Tujuan kedua adalah untuk mengusulkan kumpulan layanan umum yang akan dishare dan disediakan untuk pengguna. Tujuan ketiga adalah untuk memaksimalkan potensi nilai bisnis dari infrastruktur cloud computing. Cloud Computing Open Architecture (CCOA) memiliki 7 prinsip. Prinsip tersebut merupakan integrated co-innovation and co-production framework yang membantu penyedia layanan cloud, cloud partner dan pengguna layanan cloud untuk bekerja sama. Ketujuh prinsip dalam CCOA terangkum dalam Gambar 2.4.

Gambar 2.4 Cloud computing open architecture overview diagram (Sumber: Zhang & Zhou, 2009)



20

Pada Gambar 2.4 di atas dapat dilihat bahwa dalam Cloud Computing Open Architecture terdapat 7 prinsip, yaitu: 1.

Prinsip 1 : Integrated Ecosystem Management for Cloud Arsitektur yang dibangun harus dapat terintegrasi dan mendukung sepenuhnya lingkungan manajemen perusahaan. Lingkungan manajemen yang dimaksud tidak hanya meliputi lingkungan internal perusahaan namun juga lingkungan yang berkenaan dengan vendor, rekanan dan pengguna dari layanan cloud. Masing-masing stakeholder yang berhubungan dengan penyediaan layanan dalam arsitektur berbasis cloud computing harus dapat dengan mudah mengatur, memonitor, mengawasi dan menggunakan layanan tersebut. Sesuai dengan diagram model CCOA di atas, pada sisi client (user) terdapat komponen cloud client dashboard yang disediakan untuk mempermudah pengguna dalam mengatur ketersediaan layanan yang diinginkannya. Cloud client dapat menambahkan dan mengurangi layanan sesuai dengan kebutuhannya dengan mudah dan cepat. Pada sisi vendor atau penyedia layanan cloud terdapat cloud vendor dashboard yang akan dengan mudah mengatur dan mengontrol layanan yang ditawarkan. Permintaan layanan oleh client juga dapat dengan mudah terdeteksi dan terlayani. Cloud vendor dapat mengetahui dengan mudah ketersediaan sumber daya dalam arsitektur cloud computing. Sedangkan dari sisi

cloud

partner,

dashboard

berguna untuk

mempermudah pihak yang bersangkutan dalam menyediakan komponenkomponen atau layanan-layanan baru yang diperlukan oleh cloud vendor. 2.

Prinsip 2: Virtualization for Cloud Infrastructure Prinsip yang kedua dari CCOA adalah teknologi virtualization dalam pengaturan infrastruktur. Virtualization terdiri dari dua jenis, yaitu virtualization dari segi hardware (perangkat keras) dan virtualization dari sisi software (perangkat lunak). Penerapan teknologi virtualization akan menjadikan penambahan hardware dan software dapat dengan mudah dilakukan tanpa mengganggu proses secara keseluruhan. Universitas Indonesia


21

3.

Prinsip 3: Service Orientation for Common Reusable Services Pada bagian ini, diatur berbagai layanan yang ditawarkan. Layanan terdiri dari 2 jenis, yaitu cloud horizontal business services yang terdiri dari berbagai layanan yang dapat menyederhanakan kompleksitas dari aplikasi middleware, database dan tools. Contoh layanan dalam jenis ini antara lain layanan untuk monitoring, billing tool dan customer relationship management (CRM). Sedangkan jenis layanan yang kedua yaitu cloud vertical business services yang meliputi layanan yang berkenaan dengan lingkungan luar, seperti layanan untuk pengiriman dan pembayaran.

4.

Prinsip 4: Extensible Provisioning and Subscription for Cloud Prinsip keempat dari CCOA mengatur layanan provisioning dan subscription. Kedua layanan ini sangat penting untuk mengatur dan mengukur penggunaan layanan oleh client.

5.

Prinsip 5: Configurable Enablement for Cloud Offerings Prinsip kelima berhubungan dengan layanan kemudahan dalam pengaturan keseluruhan infrastruktur.

6.

Prinsip 6: Unified Information Representation and Exchange Framework Pertukaran

informasi

dan

komunikasi

antar

komponen

dalam

infrastruktur cloud computing menjadi sangat penting karena tanpa adanya prinsip ini keseluruhan infrastruktur tidak dapat berjalan dengan baik.

Protokol standar yang digunakan dalam bagian ini adalah

eXtensible Markup Language (XML), Resource Description Framework (RDF) dan Web Services Resources Framework (WSRF). 7.

Prinsip 7: Cloud Quality and Governance Cloud quality dan governance memiliki peran yang penting dalam menjamin kualitas dan ketersediaan layanan dalam cloud computing.



22

2.2

Cloud Computing

2.2.1 Definisi Cloud Computing Secara garis besar definisi cloud computing menurut NIST (Mell & Grance, 2011) yaitu sebuah mekanisme dimana sekumpulan sumber daya TI yang saling terhubung, baik infrastruktur maupun aplikasi, dimiliki dan dikelola sepenuhnya oleh penyedia layanan, sehingga memungkinkan pengguna untuk menggunakan resource atau sumber daya tersebut secara on-demand melalui network, baik yang sifatnya jaringan private maupun public. 2.2.2 Karakteristik Cloud Computing Menurut NIST, terdapat 5 karakteristik sehingga sistem tersebut disebut Cloud Computing, yaitu: a. Resource Pooling Sumber daya komputasi (storage, CPU, memory, network bandwidth dsb) yang dikumpulkan oleh penyedia layanan untuk memenuhi kebutuhan banyak pengguna. Sumber daya komputasi ini bisa berupa sumber daya fisik ataupun virtual dan juga bisa dipakai secara dinamis oleh para pengguna untuk memenuhi kebutuhannya. b. Broad Network Access Kapabilitas layanan dari penyedian layanan tersedia melalui jaringan dan bisa diakses oleh berbagai jenis perangkat, seperti smartphone, tablet, laptop, workstation dsb. c. Measured Service Tersedia layanan untuk mengoptimasi dan memonitor layanan yang dipakai secara otomatis. Dengan monitoring system ini kita bisa melihat berapa resource komputasi yang telah dipakai, seperti: bandwidth, storage, processing, jumlah pengguna aktif dan lain-lain. Layanan monitoring ini sebagai bentuk transparansi antara penyedia dan pengguna layanan. d. Rapid Elasticity Kapabilitas dari layanan bisa dipakai oleh pengguna secara dinamis berdasarkan kebutuhan. Pengguna layanan bisa menaikkan atau menurunkan Universitas Indonesia


23

kapasitas layanan. Kapasitas layanan yang disediakan ini biasanya tidak terbatas dan pengguna layanan bisa dengan bebas dan mudah memilih kapasitas yang diinginkan setiap saat. e. On-demand Self Service Pengguna layanan bisa melakukan konfigurasi secara mandiri terhadap layanan yang ingin dipakai melalui sebuah sistem, tanpa perlu interaksi manusia dengan pihak 2.2.3 Model Layanan pada Cloud Computing Dilihat dari model layanannya, cloud computing dapat dibagi menjadi 3 model, yaitu Software as a Service (SaaS), Platform as a Service (PaaS) dan Infrastructure as a Service (IaaS) (Demarest & Wang, 2010). a. Software as a Service (SaaS) Pada model ini, pengguna layanan dapat menggunakan suatu aplikasi atau perangkat lunak yang berada dalam infrastruktur berbasis cloud. Aplikasi dapat diakses melalui berbagai perangkat kecil seperti web browser. Dalam model ini, pengguna tidak dapat mengatur atau mengontrol jaringan, server, sistem operasi, penyimpanan, serta fungsi lainnya yang tidak disediakan oleh aplikasi yang bersangkutan. Contoh dari model cloud ini adalah Google Docs. b. Platform as a Service (PaaS) Pada model ini, pengguna layanan dapat membangun sendiri aplikasi yang diperlukan menggunakan bahasa pemrograman yang sudah disediakan. Namun demikian, pengguna layanan tidak dapat

mengatur dan mengontrol

infrastruktur lainnya seperti jaringan, server, sistem operasi dan media penyimpanan. Pengguna layanan hanya dapat mengatur konfigurasi yang berhubungan dengan aplikasi yang dibuat. Contoh dari jenis layanan cloud computing ini adalah Google Apps dan Microsoft Azure. c. Infrastructure as a Service (IaaS) Pada model ini, pengguna layanan memiliki kendali penuh terhadap pengaturan processor, media penyimpanan, jaringan dan sumber daya lainnya. Konsumen juga dapat menambahkan aplikasi, perangkat lunak dan fungsionalitas lainnya



24

dari layanan. Contoh dari model ini adalah Amazon Elastic Compute Cloud (EC2) dan Amazon Simple Storage Service (Amazon S3). 2.2.4 Model Pengembangan Cloud Computing a. Public Cloud Public cloud merupakan layanan cloud computing yang disediakan untuk masyarakat umum. Pengguna layanan bisa langsung mendaftar ataupun memakai layanan yang ada. Banyak layanan public cloud yang gratis dan ada yang perlu membayar untuk bisa menikmati layanannya (Budiyanto, 2012). Contoh Public Cloud yang gratis: GoogleMail, Facebook, Twitter, LiveMail dsb. Contoh Public Cloud yang berbayar: Sales Force, Office365, GoogleApps dsb Keuntungan public cloud: Pengguna layanan tidak perlu berinvestasi untuk membangun dan memelihara infrastruktur, platform ataupun aplikasi. Pengguna layanan hanya memakai secara gratis (untuk layanan yang gratis) atau membayar sebanyak pemakaian (pay as you go). Dengan pendekatan ini, kita bisa mengurangi dan mengubah biaya Capital Expenditure (Capex) menjadi Operational Expenditure (Opex). Kerugian public cloud: Sangat tergantung dengan kualitas layanan internet (koneksi) yang kita pakai. Jika koneksi internet mati, maka tidak ada layanan yang dapat diakses. Untuk itu, perlu dipikirkan secara matang infrastruktur internetnya. b. Private Cloud Private cloud merupakan layanan cloud computing yang disediakan untuk memenuhi kebutuhan internal dari organisasi atau perusahaan. Biasanya departemen TI akan berperan sebagai service provider (penyedia layanan) dan departemen lain menjadi service consumer (pengguna layanan). Sebagai service provider, tentu saja departemen TI harus bertanggung jawab agar layanan bisa berjalan dengan baik sesuai dengan standar kualitas layanan yang telah ditentukan oleh perusahaan, baik infrastruktur, platform maupun aplikasi yang ada.



25

Contoh layanannya: SaaS : Web Application, Mail Server, Database Server untuk keperluan internal. PaaS : Sistem Operasi + Web Server + Framework + Database untuk internal. IaaS : Virtual Machine yang bisa di-request sesuai dengan kebutuhan internal. Keuntungan private cloud: Menghemat bandwidth internet ketika layanan itu hanya diakses dari jaringan internal. Proses bisnis tidak tergantung dengan koneksi internet, akan tetapi tetap tergantung dengan koneksi jaringan lokal (intranet). Kerugian private cloud: Investasi besar, karena pihak perusahaan atau organisasi sendiri yang harus menyiapkan infrastrukturnya. Butuh tenaga kerja untuk memelihara dan menjamin layanan berjalan dengan baik. c. Hybrid Cloud Hybrid cloud merupakan gabungan dari layanan public cloud dan private cloud yang diimplementasikan oleh suatu perusahaan atau organisasi. Dalam hybrid cloud ini, pihak perusahaan atau organisasi bisa memilih proses bisnis mana yang bisa dipindahkan ke public cloud dan proses bisnis mana yang harus tetap berjalan di private cloud. Contoh:  Perusahaan A pada suatu negara tertentu menyewa layanan dari GoogleApp Engine (public cloud) sebagai sarana yang dipakai untuk aplikasi yang mereka buat. Di negara tersebut terdapat aturan bahwa data nasabah dari sebuah perusahaan tidak boleh disimpan pada pihak ketiga. Untuk menaati aturan yang ada, data nasabah dari perusahaan A tetap disimpan pada database mereka sendiri (private cloud), dan aplikasi akan melakukan konektivitasnya ke database internal.  Perusahaan B menyewa layanan dari Office365 (public cloud). Karena perusahaan B tersebut sudah mempunyai banyak user yang tersimpan di Active Directory yang berjalan di atas Windows Server mereka (private



26

cloud) akan lebih efektif kalau Active Directory tersebut dijadikan identity untuk login ke Office365. Keuntungan hybrid cloud: - Keamanan data terjamin karena dapat dikelola sendiri. - Lebih leluasa untuk memilih mana proses bisnis yang harus tetap berjalan di private cloud dan mana proses bisnis yang bisa dipindahkan ke public cloud dengan tetap menjamin integrasi dari keduanya. Kerugian hybrid cloud: Untuk aplikasi yang membutuhkan integrasi antara public cloud dan private cloud, infrastruktur internet harus dipersiapkan dengan baik. d. Community Cloud Community cloud merupakan layanan cloud computing yang dibangun eksklusif untuk komunitas tertentu. Pengguna layanan berasal dari organisasi yang mempunyai perhatian yang sama atas sesuatu atau beberapa hal, misalnya standar keamanan, aturan, compliance dan lain sebagainya. Community cloud ini bisa dimiliki, dipelihara dan dioperasikan oleh satu atau lebih organisasi dari komunitas tersebut, pihak ketiga ataupun kombinasi dari keduanya. Keuntungan community cloud: Bisa bekerja sama dengan organisasi lain dalam komunitas yang mempunyai kepentingan yang sama. Kerugian community cloud: Ketergantungan antar organisasi jika tiap-tiap organisasi tersebut saling berbagi sumber daya.



27

Gambar 2.5 berikut merupakan model visual dari definisi cloud computing:

Gambar 2.5 Model visual dari definisi cloud computing menurut NIST Sumber : (CSA, 2009)

2.3

Analisa Rantai Nilai (Value Chain)

Analisa rantai nilai (Value Chain) pertama kali diusulkan oleh Michael Porter pada tahun 1985 yang mencatat bahwa “setiap perusahaan adalah kumpulan kegiatan yang dilakukan untuk merancang, memproduksi, memasarkan, memberikan dan mendukung produk atau layanan. Semua kegiatan tersebut dapat direpresentasikan dengan menggunakan rantai nilai. Nilai rantai hanya dapat dipahami dalam konteks unit bisnis” (Ward & Peppard, 2002). Model dasar dari analisa rantai nilai Porter seperti ditunjukkan pada Gambar 2.6.



28

Gambar 2.6 Analisa rantai nilai Sumber : (Ward & Peppard, 2002)

Analisa rantai nilai mengidentifikasi dan menginventarisasikan area-area fungsi bisnis, yaitu dengan pengelompokkan area-area fungsional ke dalam 2 aktivitas, yaitu: 1. Aktivitas-aktivitas utama (primary activities), yang berupa: a. Logistik masukan (inbound logistics): aktivitas yang berhubungan dengan penerimaan, penyimpanan dan menyebarkan masukan. b. Operasi (operations): aktivitas yang mentransformasikan masukan menjadi keluaran menjadi produk akhir. c. Logistik keluaran (outbound logistics): aktivitas yang berhubungan dengan menyebarkan produk/jasa ke pelanggan. d. Pemasaran dan penjualan (marketing and sales): aktivitas yang berhubungan dengan pemasaran dan penjualan seperti promosi dan sebagainya. e. Layanan (service): aktivitas yang berhubungan dengan penyedia layanan untuk meningkatkan pemeliharaan produk seperti pelatihan, perbaikan dan perawatan. 2. Aktivitas-aktivitas pendukung (support activities), yang berupa: a. Infrastruktur perusahaan (firm infrastructure): aktivitas yang terkait dengan biaya serta aset yang berhubungan dengan manajemen umum, Universitas Indonesia


29

akuntansi dan keuangan, keamanan dan keselamatan sistem informasi dan fungsi lainnya. b. Manajemen sumber daya manusia (human resources management): aktivitas yang terkait dengan penerimaan, pelatihan, pengembangan dan kompensasi untuk semua tipe personil dan mengembangkan tingkat keahlian pekerja. c. Pengembangan teknologi (technology development): aktivitas yang terkait dengan biaya yang berhubungan dengan produk, perbaikan proses, perancangan peralatan, pengembangan perangkat lunak komputer, sistem telekomunikasi, kapabilitas basis data baru dan pengembangan dukungan sistem berbasis komputer. d. Pengadaan (procurement): aktivitas yang terkait dengan bagaimana sumber daya diperoleh seperti fungsi pembelian input yang digunakan dalam organisasi rantai nilai.



30 2.4

RAID (Redundant Array of Independent Disks)

Disk Array adalah susunan beberapa disk, diatur untuk meningkatkan performa dan reliabilitas sistem penyimpanan hasil. Performa ditingkatkan melalui data stripping. Data stripping mendistribusikan data pada beberapa disk sehingga seakan-akan merupakan 1 disk tunggal yang memiliki performansi tinggi. Reliabilitas ditingkatkan melalui redundansi. Redundansi dilakukan dengan tujuan apabila disk gagal, data redundan dapat digunakan untuk mengkonstruksi isi disk yang gagal tersebut. Disk array yang mengimplementasi kombinasi data stripping dan redundansi disebut redundant arrays of independent disks atau RAID (Ramakrishnan & Gehrke, 2004). Terdapat beberapa jenis RAID seperti terlihat pada Tabel 2.2. Tabel 2.2 Jenis-jenis RAID Level

Cara Kerja

Contoh

Kelebihan

Kekurangan

RAID 1

Separuh dari jumlah hard disk yang diposisikan sebagai RAID 1 digunakan sebagai mirror. Dengan kata lain bahwa hanya satu hard disk sebagai penyimpanan data, yang lain berfungsi sebagai mirror atau backup data dari hard disk lainnya.

Dua hard disk berkapasitas 250Gb dikonfigurasikan dengan RAID 1, maka hanya satu hard disk (250 Gb) yang dapat digunakan sebagai penyimpanan data, hard disk yang lain (250 Gb) digunakan sebagai mirror atau backup

Jika salah satu hard disk yang berfungsi sebagai penyimpanan data bermasalah, maka hard disk mirror akan secara otomatis menggantikan hard disk yang rusak atau bermasalah, data tetap utuh.

RAID 1 bisa dikatakan mahal, karena hanya setengah dari jumlah hard disk yang dapat dijadikan tempat penyimpanan data.

Gambar



31 Tabel 2.2 Jenis-jenis RAID (lanjutan) Level

Cara Kerja

Contoh

Kelebihan

Kekurangan

RAID 5

Data disebar pada masing-masing hard disk dan masing-masing hard disk terdapat sebuah parity yang bisa dianalogikan sebagai image dari masingmasing blok data hard disk lainnya. Efisiensi penyimpanan data menggunakan 3 hard disk adalah 66.7%, bila menggunakan 4 hard disk, efisiensi menjadi 75%. Data disebar pada 4 hard disk dan masingmasing hard disk terdapat 2 parity yang bisa dianalogikan sebagai image dari masing-masing blok data hard disk lainnya. Efisiensi penyimpanan data menggunakan 4 hard disk adalah 50%.

3 hard disk berkapasitas 250 Gb dikonfigurasi RAID 5, maka kapasitas yang dapat digunakan untuk penyimpanan data adalah 500 Gb (66.7% * 750 Gb), sisa kapasitas yang tidak terdeteksi digunakan untuk penyimpanan parity.

Memiliki performa read yang bagus dan performa write yang bagus.

Penulisan data lebih lambat dibanding RAID 0 dan RAID 1. Hanya memperbolehkan satu hard disk gagal.

4 hard disk berkapasitas 250 Gb dikonfigurasi RAID 6, maka kapasitas yang dapat digunakan untuk penyimpanan data adalah 500 Gb (50% * 1000 Gb), sisa kapasitas yang tidak terdeteksi digunakan untuk penyimpanan parity.

Memiliki Penulisan data lebih lambat performa read dibanding RAID 0, RAID 1 yang bagus dan dan RAID 5. performa write yang bagus. Mengijinkan 2 hard disk gagal.

RAID 6

Gambar



32 Tabel 2.2 Jenis-jenis RAID (lanjutan) Level

Cara Kerja

Contoh

Kelebihan

Kekurangan

RAID 1+0

Hard disk yang dikonfigurasi dalam RAID 1+0 bisa dikatakan striping dan mirror, dengan kata lain data yang disimpan dalam hard disk akan dipecah (stripe) dan didistribusikan ke separuh total hard disk dari RAID 1+0 tersebut, setengahnya lagi digunakan sebagai mirror dari hasil stripe yang lain. RAID 1+0 merupakan penggabungan antara RAID 0 dan 1.

4 hard disk berkapasitas 250 Gb dikonfigurasi dengan RAID 1+0, maka kapasitas yang dapat digunakan untuk penyimpanan data adalah 500 Gb dan data yang disimpan akan distripping atau dibagikan diantara kedua hard disk tersebut, 2 hard disk yang lain berfungsi sebagai mirror.

Bisa dikatakan sama dengan RID 1, namun performa dari baca tulis hard disk meningkat dibanding RAID 1 karena lebih cepat dalam read/write. Perlindungan data kuat selama masing-masing hard disk dalam anggota group tidak rusak lebih dari satu.

Tergolong mahal seperti RAID 1 karena hanya separuh yang bisa digunakan untuk penyimpanan data.

Gambar



33

2.5

Telaah Penelitian Sebelumnya

Berdasarkan hasil studi literatur, didapat beberapa hasil penelitian yang memiliki korelasi dengan penelitian yang akan dilakukan. Didapat empat hasil penelitian yang menjadi referensi dalam penelitian ini. Beberapa penelitian tersebut antara lain: 1. Achmad Solichin melalui Karya Akhirnya pada Magister Teknologi InformasiUI berjudul “Pemodelan Arsitektur Teknologi Informasi Berbasis Cloud Computing Untuk Institusi Perguruan Tinggi di Indonesia” pada tahun 2010. Kesimpulan yang relevan dengan penelitian ini yaitu pemodelan arsitektur TI pada Dikti berdasarkan model cloud computing selama ini menjadi terkenal sebagai model komputasi di masa depan. Usulan yang dihasilkan adalah dengan membangun suatu pusat sentralisasi data dan aplikasi pada suatu lokasi sehingga mengurangi adanya redundansi dan efisiensi penggunaan aplikasi. Dari model arsitektur tersebut, Dikti menjadi cloud provider bagi pengguna layanan yang berada pada masing-masing perguruan tinggi. Teknik utama untuk membangun infrastruktur cloud computing adalah dengan menerapkan solusi virtualisasi. 2. Gigih Forda Nama melalui Karya Akhirnya pada Magister Teknologi Informasi-UI berjudul “Perancangan Infrastruktur Teknologi Informasi Adaptif Pada Universitas Lampung” pada tahun 2013. Kesimpulan yang relevan dengan penelitian ini yaitu : 

Hasil perancangan infrastruktur teknologi informasi pada penelitian ini menghasilkan rancangan yang bersifat adaptif dengan mengadopsi konsep teknologi cloud computing, sehingga proses bisnis dapat berjalan efektif, efisien dan tangkas (agile) mengikuti pola perubahan yang diinginkan manajemen.



Berdasarkan

hasil

perancangan

cloud

computing

yang

telah

dirumuskan, terdapat 5 cluster private cloud dan 104 jumlah Virtual Machine (VM) node sesuai pengelompokkan kebutuhan pattern aplikasi dengan prinsip failover dan redundancy layanan.



34 

Pemodelan arsitektur enterprise dari penelitian ini dapat memberikan panduan dalam membuat cetak biru untuk pengembangan sistem informasi dan teknologi informasi untuk mendukung Tridharma perguruan tinggi Unila.

3. Yosua Suhandi melalui Karya Akhirnya pada Magister Teknologi Informasi-UI berjudul “Perancangan Enterprise Architecture Pada PT.XYZ Menggunakan TOGAF ADM Berbasiskan Cloud Computing: Studi Kasus PT.XYZ” pada tahun 2013. Kesimpulan yang relevan dengan penelitian ini yaitu: 

Berdasarkan proses identifikasi solusi arsitektur bisnis, manajemen PT.XYZ menginginkan terjadinya automatisasi hubungan perusahaan dengan pelanggannya. Maka pada proses analisis kesenjangan arsitektur bisnis, dengan menggunakan layanan cloud computing maka dapat tercipta automatisasi proses bisnis dan kemudahan monitoring proses bisnis oleh manajemen perusahaan.



Berdasarkan proses identifikasi solusi arsitektur teknologi, solusi cloud computing memungkinkan terciptanya infrastruktur yang selalu siap untuk digunakan kapan saja dan di mana saja, bersifat adaptif terhadap perubahan yang terjadi, serta dapat digunakan secara bersama-sama oleh banyak pengguna. Maka pada proses analisis arsitektur teknologi, tidak diperlukan pengadaan aset TI yang berlebih dan mahal, namun yang diperlukan untuk menggunakan sistem informasi cloud computing ini menjadi mudah dan jelas, bahkan kebanyakan pelanggan telah memiliki aset tersebut. Aset yang dimaksud adalah pc, laptop, smartphone maupun tablet yang memiliki konektivitas internet.

4. Liang-Jie Zhang and Qun Zhou melalui jurnalnya pada IEEE International Conference on Web Services pada tahun 2009. Penelitiannya menghasilkan suatu konsep yang dinamakan Cloud Computing Open Architecture (CCOA). CCOA merupakan salah satu model arsitektur teknologi informasi berbasis cloud computing yang memiliki tiga tujuan yang akan membantu institusi dalam mengembangkan arsitektur yang baik untuk cloud computing. Tujuan pertama adalah mencari jalan untuk menciptakan suatu platform yang scalable dan configurable untuk cloud computing. Tujuan kedua adalah untuk Universitas Indonesia


35

mengusulkan kumpulan layanan umum yang akan di-share dan disediakan untuk pengguna. Tujuan ketiga adalah untuk memaksimalkan potensi nilai bisnis dari infrastruktur cloud computing. 2.6

Metodologi Penelitian Kualitatif

Dalam penelitian ini, perlu dilakukan pemahaman mengenai

research

methodology. Studi literatur berikut menjelaskan mengenai research methodology berupa action research. Action Research merupakan bentuk penelitian yang dilakukan secara kolaborasi antara peneliti dan responden atau narasumber dalam situasi tertentu yang menjadi objek penelitiannya. Dalam penelitiannya, setelah melakukan identifikasi masalah, peneliti menawarkan solusi kepada responden atau narasumber. Dari solusi tersebut, responden atau narasumber memberikan feed back, bisa berupa hasil pemikiran, rekomendasi, perbaikan dan lain-lain. Kemudian, dari feed back tersebut, peneliti melakukan revisi yang selanjutnya menjadi solusi versi 1 dan begitu seterusnya hingga responden atau narasumber mendapatkan solusi terbaik dan menerima solusi tersebut. Action Research dilakukan melalui Forum Group Discussion (FGD) atau wawancara. Deskripsi yang paling lazim digunakan, action research menjelaskan 5 (lima) tahap yang digambarkan melalui siklus proses yang ideal dari perumusan action research. Pendekatan ini membutuhkan pembentukan infrastruktur sistem client atau lingkungan penelitian. Kemudian dilakukan iterasi atau pengulangan pada lima tahap, yaitu: (1) Diagnosing, (2) Action Planning, (3) Action Taking, (4) Evaluating dan (5) Specifying learning. Gambar 2.9 menjelaskan mengenai lima tahap dalam action research (Myers, 2002).



36

Diagnosing

Action Planning

Specifying learning Clientsystem infrastructur e

Action Taking

Evaluating

Gambar 2.7 Siklus action research Sumber : (Myers, 2002)

Gambar 2.7 memperlihatkan siklus action research. Client-system infrastructure merupakan spesifikasi dari lingkungan penelitian. Client-system infrastructure terdiri dari responden atau narasumber yang menentukan batas dari lingkungan penelitian dan memberikan input dan output bagi peneliti. Lima tahap dalam action research meliputi: 1. Diagnosing, pada tahap ini dilakukan identifikasi masalah utama yang menyebabkan keinginan organisasi (objek penelitian) untuk melakukan perubahan atau perbaikan. Hal ini meliputi interpretasi dari masalah organisasi yang kompleks, tidak melalui pengurangan dan penyederhanaan, tapi dilakukan secara menyeluruh. Diagnosa ini akan membangun asumsi teoritikal tertentu (yaitu working hypothesis) mengenai sifat organisasi dan kelompok masalah. 2. Action Planning, pada tahap ini dilakukan dengan menentukan rencana aksi dengan menggunakan theoritical framework, yang menjelaskan kondisi yang diinginkan oleh organisasi di masa depan dan perubahan yang akan dilakukan. 3. Action Taking, pada tahap ini dilakukan dengan mengimplementasikan rencana aksi. Peneliti dan responden atau narasumber berkolaborasi dalam lingkungan objek penelitian.



37

4. Evaluating, pada tahap ini dilakukan dengan menentukan efek dari aksi yang dilakukan dan akibat yang ditimbulkan dari aksi tersebut terhadap penyelesaian masalah. 5. Specifying learning, merupakan tahap terakhir, biasanya dilakukan secara terus menerus. Dari tahapan ini diperoleh pengetahuan atau kesimpulan dari action research apakah berhasil atau tidak dalam penyelesaian masalah. Apabila belum berhasil, maka pengetahuan tersebut digunakan sebagai dasar dalam melakukan Diagnosing dalam persiapan untuk melakukan action research selanjutnya.



38

2.7

Theoritical Framework (Kerangka Teoritis)

Berdasarkan studi literatur yang dilakukan, maka penulis melakukan proses dekomposisi atas seluruh teori, selanjutnya menuangkannya dalam bentuk theoritical framework penelitian yang bisa dilihat pada Gambar 2.8.

Keputusan Menteri Pekerjaan Umum Nomor: 489A/KPTS/M/2007

Enterprise Architecture

Tentang Penunjukan Unit Kliring Data dan

Framework

Informasi Departemen Pekerjaan Umum. TOGAF

Cetak Biru TIK Kementerian Pekerjaan Umum

Perancangan Arsitektur Teknologi Informasi Pemeringkatan e-Government Indonesia (PeGI), dimensi Infrastruktur Dokumen PeGI 2012

Teknologi Cloud Computing NIST (Mell & Grance, 2011)

Best Practice untuk Prinsip Arsitektur TI berbasis Cloud Computing (Zhang & Zhou, 2009)

Gambar 2.8 Theoritical framework

Pada Gambar 2.8 dapat dilihat mengenai rangkuman dari teori yang dipelajari serta menjadi dasar dalam penelitian ini. Perancangan arsitektur TI dilakukan sebagai upaya Pusdata dalam memenuhi Keputusan Menteri Pekerjaan Umum Nomor 489A/KPTS/M/2007 Tentang Penunjukan Unit Kliring Data dan Informasi Departemen Pekerjaan Umum. Cetak Biru TIK Kementerian Pekerjaan Umum juga menjadi salah satu rujukan dalam pembuatan rancangan arsitektur TI. Dalam melihat dimensi infrastruktur pada pemeringkatan e-Government Indonesia (PeGI) 2012, diperoleh referensi mengenai arsitektur usulan berupa Disaster Recovery Center (DRC). Konsep enterprise architecture framework didapat dengan teori TOGAF. Konsep teknologi cloud computing didapat dari NIST (Mell & Grance, 2011). Perancangan arsitektur TI dengan menggunakan prinsip



39

arsitektur berbasis cloud computing dari best practice yang pernah dilakukan oleh Zhang & Zhou (Zhang & Zhou, 2009).



BAB 3 METODOLOGI PENELITIAN Bab ini membahas mengenai metodologi penelitian yang digunakan sebagai panduan dalam melakukan penelitian. 3.1

Tahapan Penelitian

Metodologi penelitian atau research methodology yang digunakan yaitu action research yang dilakukan secara kolaborasi antara peneliti dengan narasumber dalam lingkungan yang dijadikan objek penelitian. Dalam penelitian ini juga dilakukan berdasarkan teori-teori dan best practice yang diperoleh dari studi literatur untuk mendapatkan rancangan arsitektur teknologi informasi. Kolaborasi antara peneliti dengan narasumber dilakukan melalui pengamatan (observasi) secara langsung, mengumpulkan bahan-bahan dokumen terkait seperti peraturan maupun kebijakan-kebijakan dan wawancara dengan pihak yang berkepentingan untuk mendapatkan informasi permasalahan yang terjadi pada saat ini, kebutuhan serta harapan di masa datang mengenai infrastruktur TI. Pada Gambar 3.1 memperlihatkan tahapan penelitian yang digunakan dan langkah-langkah yang akan dilakukan.

40



41

Tahapan Penelitian

Kegiatan Penelitian

Tinjauan Kondisi Saat Ini

Mulai Tahap 1: - Observasi - Wawancara

Tahap 1. Identifikasi Masalah Tahap 2. Pengumpulan Data & Studi Literatur

Tahap 2: - Studi Literatur - Pengumpulan data primer dan sekunder Tahap 3: - Observasi - Wawancara

Tahap 3. Pengolahan dan Analisis Data

Tahap 4: Mengkonfirmasi komitmen dari stakeholder, penentuan framework dan prinsip arsitektur

Tahap 4. Preliminary

Tahap 5: Menyediakan proses pengelolaan kebutuhan arsitektur sepanjang fase pada siklus ADM

Perancangan Arsitektur

Tahap 6. Architecture Vision

Tahap 6: Memastikan bahwa rancangan arsitektur yang akan dibuat selaras dengan kebutuhan organisasi

Tahap 7. Business Architecture Tahap 8. Information System Architecture

Tahap 5. Requirement Management

Tahap 8: Mengembangkan arsitektur target untuk domain data dan domain aplikasi

Tahap 9. Technology Architecture

Tahap 9: Mendefinisikan arsitektur teknologi yang nantinya direalisasikan untuk memenuhi kebutuhan implementasi desain sistem informasi

Tahap 10. Opportunities and Solution

Tahap 11. Kesimpulan dan Saran

Tahap 7: Memilih sudut pandang terhadap arsitektur yang bersesuaian dengan bisnis dan memilih teknik dan tools yang tepat

Tahap 10: Mengevaluasi dan memilih cara implementasi arsitektur serta konsolidasi analisis gap dari fase-fase sebelumnya Selesai

Tahap 11: Penarikan kesimpulan penelitian

Gambar 3.1 Tahapan penelitian



42

Pada Gambar 3.1 terlihat bahwa tahapan penelitian dibagi menjadi sebelas tahapan, yaitu: 1. Identifikasi Masalah Pada tahap identifikasi masalah dilakukan identifikasi permasalahan yang terjadi secara umum pada sistem TI Kementerian Pekerjaan Umum pada saat ini. Penjelasan mengenai tahap ini bisa dilihat pada Bab Pendahuluan. 2. Pengumpulan Data dan Studi Literatur Setelah mendapatkan perumusan masalah, mempelajari teori dan konsep melalui studi literatur, maka mulai dilakukan pengumpulan data yang dibutuhkan. Terdapat dua aktifitas pengumpulan data yang dilakukan, yaitu: 1. Pengumpulan data primer dilakukan melalui pengamatan kondisi sistem TI yang ada saat ini, diskusi dan wawancara serta komunikasi melalui e-Mail dengan pengelola infrastruktur TI khususnya dalam hal ini yaitu pihak Pusdata (Pusat Pengolahan Data). Wawancara dilakukan selama 5 kali dengan melibatkan 2 narasumber, diantaranya:  Bapak Rema Suwenda, Kepala Bidang Penyelenggaraan Sistem Jaringan dan Aplikasi, Pusdata, Kementerian PU. Pihak yang memiliki kewenangan dalam pengelolaan infrastruktur TI di Kementerian PU sangat diperlukan dalam penelitian ini. Dengan melakukan wawancara terhadap narasumber yang bersangkutan diharapkan data terkait kebijakan, peraturan dan arahan ke depan mengenai pengelolaan TIK di Kementerian Pekerjaan Umum bisa didapatkan.  Bapak Arief Ardhian, Kepala Sub Bidang Manajemen Jaringan. Narasumber melakukan

yang

bersangkutan

penyiapan

bahan

memiliki

kewenangan

perencanaan,

pengelolaan

dalam dan

pengembangan sarana dan prasarana jaringan komunikasi dan informasi serta keamanan dan sistem operasi jaringan. 2. Pengumpulan data sekunder dilakukan melalui kajian terhadap dokumen internal, seperti Cetak Biru TIK Kementerian Pekerjaan Umum, peraturan pemerintah atau pimpinan pada Kementerian PU. Selain itu juga digunakan Universitas Indonesia


43

data berupa penelitian sejenis yang pernah dilakukan beserta dengan artikelartikel best practice dalam melakukan penelitian sejenis. Tabel 3.1 berikut memperlihatkan pemetaan data sekunder terhadap penggunaannya dalam penelitian.

Tabel 3.1 Pemetaan data sekunder No Data Sekunder 1. Cetak Biru TIK Kementerian Pekerjaan Umum

2.

Penggunaan dalam penelitian  Data mengenai proses bisnis Kementerian Pekerjaan Umum  Data mengenai kondisi sistem informasi dan infrastruktur saat ini Peraturan Menteri PU Nomor Data terkait tugas pokok dan fungsi 08/PRT/M/2010 tentang Kementerian Pekerjaan Umum. Organisasi dan Tata Kerja Kementerian Pekerjaan Umum

3. Pengolahan dan Analisis Data Setelah data terkumpul dengan cukup, maka dilakukan pengolahan dan analisis terhadap data tersebut melalui observasi dan wawancara. Hasil analisis data dituliskan ke dalam tahap selanjutnya pada masing-masing pembuatan arsitektur. 4. Fase Preliminary Fase

preliminary

merupakan

fase

persiapan

yang

bertujuan

untuk

mengkonfirmasi komitmen dari stakeholder, penentuan framework dan prinsip arsitektur yang akan digunakan pada pengembangan infrastruktur TI berbasis cloud computing. 5. Tahap Requirement Management Tujuan dari tahap requirement management adalah menyediakan proses pengelolaan kebutuhan arsitektur sepanjang fase pada siklus ADM, mengumpulkan, menginventarisir dan mengidentifikasi seluruh kebutuhan enterprise, menyimpan lalu memberikannya kepada fase TOGAF ADM yang relevan.



44

6. Fase A : Architecture Vision Tujuan dari fase architecture vision yaitu untuk memastikan bahwa rancangan arsitektur yang akan dibuat selaras dengan kebutuhan organisasi. 7. Fase B : Business Architecture Fase business architecture bertujuan untuk (1) memilih sudut pandang terhadap arsitektur yang bersesuaian dengan bisnis dan memilih teknik dan tools yang tepat, (2) mendeskripsikan arsitektur bisnis saat ini dan target pengembangannya serta analisis kesenjangan antara keduanya. 8. Fase C : Information Systems Architectures Fase Information Systems Architecture bertujuan untuk mengembangkan arsitektur target untuk domain data dan domain aplikasi. Pada arsitektur aplikasi, menentukan aplikasi untuk memproses data dan mendukung bisnis. Masukan dari arsitektur aplikasi berupa : (1) prinsip aplikasi, (2) output dari business architecture. Sedangkan keluaran dari fase arsitektur aplikasi berupa: (1) arsitektur aplikasi saat ini, (2) usulan arsitektur aplikasi dan (3) analisis kesenjangan. 9. Fase D : Technology Architecture Fase technology architecture bertujuan untuk mendefinisikan arsitektur teknologi

yang

nantinya

direalisasikan

untuk

memenuhi

kebutuhan

implementasi desain sistem informasi. Masukan untuk fase ini adalah prinsip teknologi, analisis kesenjangan dari information system architecture. Keluaran dari fase ini adalah artifact dari arsitektur TI beserta analisis kesenjangan teknologi informasi. 10. Fase E : Opportunities and Solutions Fase opportunities and solutions bertujuan untuk mengevaluasi dan memilih cara implementasi arsitektur serta konsolidasi analisis kesenjangan dari fasefase sebelumnya. Masukan untuk fase ini adalah output atau keluaran dari fase-fase sebelumnya, hasil analisis kesenjangan. Keluaran dari fase ini adalah pola solusi.



45

11. Kesimpulan dan Saran Membuat kesimpulan dari penelitian yang dilakukan dan saran yang dapat digunakan sebagai usulan terhadap penelitian selanjutnya. 3.2

Instrumen Penelitian

Instrumen penelitian merupakan alat bantu dalam mendapatkan data. Data primer yang diperoleh melalui wawancara memiliki beberapa pertanyaan-pertanyaan kunci sebagai berikut: 1. Latar belakang pembangunan data center yang baru (DC 2) 2. Keberadaan dokumen perencanaan arsitektur TI 3. Struktur organisasi pengelola TI di Kementerian PU 4. Kondisi aplikasi atau sistem informasi saat ini 5. Kondisi teknologi atau perangkat TI saat ini 6. Latar belakang pemilihan solusi private cloud



BAB 4 PROFIL ORGANISASI

Bab ini membahas secara umum profil organisasi yang menjadi objek penelitian, yaitu Kementerian Pekerjaan Umum dan Satminkal (Satuan Administrasi Pangkal) setingkat eselon 2 sebagai pengelola TI Kementerian. 4.1 Kementerian Pekerjaan Umum Bagian ini menjelaskan secara umum mengenai organisasi yang menjadi objek penelitian, yaitu Kementerian Pekerjaan Umum. Penjelasan ini meliputi profil bisnis organisasi, visi dan misi organisasi serta struktur organisasi. 4.1.1 Profil Bisnis Organisasi Sesuai dengan Peraturan Menteri Pekerjaan Umum Nomor : 08/PRT/M/2010 Tanggal 8 Juli 2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, ditetapkan bahwa Kementerian Pekerjaan Umum mempunyai tugas menyelenggarakan urusan di bidang pekerjaan umum dalam pemerintahan untuk membantu Presiden dalam menyelenggarakan pemerintahan negara. Dalam melaksanakan tugasnya, Kementerian Pekerjaan Umum menyelenggarakan fungsi: 1. perumusan, penetapan dan pelaksanaan kebijakan di bidang pekerjaan umum; 2. pengelolaan barang milik / kekayaan negara yang menjadi tanggung jawab Kementerian Pekerjaan Umum; 3. pengawasan atas pelaksanaan tugas di lingkungan Kementerian Pekerjaan Umum; 4. pelaksanaan bimbingan teknis dan supervisi atas pelaksanaan urusan Kementerian Pekerjaan Umum di daerah; dan 5. pelaksanaan kegiatan teknis yang berskala nasional.

46



47

4.1.2 Struktur Organisasi Berdasarkan Peraturan Menteri Pekerjaan Umum Nomor : 08/PRT/M/2010 Tanggal 8 Juli 2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, ditetapkan susunan Organisasi Kementerian Pekerjaan Umum terdiri atas: 1.

Wakil Menteri Pekerjaan Umum;

2.

Sekretariat Jenderal;

3.

Direktorat Jenderal Penataan Ruang;

4.

Direktorat Jenderal Sumber Daya Air;

5.

Direktorat Jenderal Bina Marga;

6.

Direktorat Jenderal Cipta Karya;

7.

Inspektorat Jenderal;

8.

Badan Pembinaan Konstruksi;

9.

Badan Penelitian dan Pengembangan;

10. Staf Ahli Bidang Keterpaduan Pembangunan; 11. Staf Ahli Bidang Ekonomi dan Investasi; 12. Staf Ahli Bidang Sosial Budaya dan Peran Masyarakat; 13. Staf Ahli Bidang Hubungan Antar Lembaga; 14. Staf Ahli Bidang Pengembangan Keahlian dan Tenaga Fungsional; 15. Pusat Pengolahan Data; 16. Pusat Pendidikan dan Pelatihan; 17. Pusat Komunikasi Publik; 18. Pusat Kajian Strategis; dan 19. Pusat Pengelolaan Barang Milik Negara.



48

Gambar struktur organisasi Kementerian Pekerjaan Umum dapat dilihat pada Gambar 4.1.

Gambar 4.1 Struktur organisasi Kementerian Pekerjaan Umum Sumber : (Kementerian Pekerjaan Umum, 2011)

4.2 Pusdata (Pusat Pengolahan Data) 4.2.1 Profil Bisnis Organisasi Pusdata berada di bawah Menteri Pekerjaan Umum melalui Sekretariat Jenderal bersama

dengan

pusat-pusat

yang

lain

seperti

Pusat

Penelitian

dan

Pengembangan, Pusat Pendidikan dan Pelatihan, Pusat Pengelolaan Barang Milik Negara. Walaupun sama-sama di bawah Menteri, Direktorat Jenderal dan Pusdata berada di tingkat yang berbeda. Kepala Pusdata dijabat oleh eselon 2 sedangkan Direktorat Jenderal dan Badan dijabat oleh eselon 1.



49

Pusdata sendiri dibagi dalam bidang, balai dan ditambah bagian tata usaha untuk membantu administrasi. Kepala bidang dan balai tersebut dijabat oleh eselon 3. Struktur organisasi Pusdata dapat dilihat pada Gambar 4.2.

Gambar 4.2 Struktur organisasi Pusdata Sumber : (Kementerian Pekerjaan Umum, 2011)

4.2.2 Tugas Pokok dan Fungsi Berdasarkan Peraturan Menteri Pekerjaan Umum Nomor : 08/PRT/M/2010 Tanggal 8 Juli 2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, ditetapkan bahwa Pusat Pengolahan Data mempunyai tugas melaksanakan pembinaan, pengembangan, pengelolaan dan penyediaan data infrastruktur bidang pekerjaan umum serta penyelenggaraan sistem informasi mendukung manajemen Kementerian.



50

Dalam

melaksanakan

tugasnya

tersebut,

Pusat

Pengolahan

Data

menyelenggarakan fungsi: 1. penyusunan program pengolahan data 2. pembinaan dan pengembangan pengolahan data 3. penyelenggaraan sistem informasi 4. pengelolaan dan penyediaan data spasial / peta 5. pengelolaan dan penyediaan data literal / numerik 6. pelaksanaan urusan tata usaha dan rumah tangga Pusat

Pusdata terdiri atas bagian tata usaha, bidang pengembangan dan analisis data, bidang penyelenggaraan sistem jaringan dan aplikasi dan kelompok jabatan fungsional.



BAB 5 ANALISIS DAN PEMBAHASAN

Bab ini memberikan penjelasan atas data-data yang dikumpulkan dan analisis terhadap data yang diperoleh dan selanjutnya akan dijabarkan hasil (output) dari penelitian. Bab ini merupakan kelanjutan dari tahap sebelumnya, yaitu tahap 1 sampai dengan tahap 3 yang telah dijelaskan pada Bab Metodologi Penelitian. 5.1

Tahap 4. Preliminary

Fase preliminary merupakan fase persiapan yang bertujuan untuk mengkonfirmasi komitmen dari stakeholder, penentuan framework dan prinsip arsitektur yang akan digunakan pada pengembangan infrastruktur TI. Gambar 5.1 memperlihatkan mengenai input, steps dan output dari fase preliminary ini.

Input: 1. Rencana Strategis 2. Cetak Biru TIK

Steps: 1. Perumusan Masalah 2. Penentuan Ruang Lingkup 3. Pemilihan framework arsitektur 4. Identifikasi Prinsip Arsitektur

Output: 1. Komitmen Manajemen 2. Framework arsitektur 3. Prinsip Arsitektur

Gambar 5.1 Input, steps, output dari fase preliminary

5.1.1 Masukan (input) Fase Preliminary Dalam mempersiapkan arsitektur yang akan dibuat diperlukan suatu pemahaman mengenai permasalahan yang sedang terjadi di organisasi, dalam hal ini Kementerian Pekerjaan Umum. Pemahaman tersebut dilakukan dengan cara kajian terhadap dokumen terkait, yaitu Rencana Strategis, Cetak Biru TIK Kementerian Pekerjaan Umum serta dokumen yang lain. 51



52

5.1.2 Proses (steps) pada Fase Preliminary Steps atau tahapan atau proses dalam fase preliminary ini dilakukan dengan cara observasi terhadap objek penelitian, dalam hal ini Kementerian Pekerjaan Umum dengan Pusdata (Pusat Pengolahan Data) sebagai pengelola TIK nya. Pada fase ini juga dilakukan dengan cara kajian terhadap dokumen terkait sebagai input dari fase ini. Ada beberapa tahap atau proses dalam fase preliminary ini, diantaranya: 1. Perumusan Masalah Perumusan masalah ini sudah dijelaskan pada sub bab 1.2 (Rumusan Masalah). 2. Penentuan Ruang Lingkup Ruang lingkup dalam penelitian ini sudah dijelaskan pada sub bab 1.4 (Ruang Lingkup Penelitian). 3. Pemilihan Framework Arsitektur Pemilihan framework arsitektur sudah dijelaskan pada sub bab 2.1.3 (Pemilihan EA framework). 4. Identifikasi Prinsip Arsitektur Setelah dilakukan pemilihan framework arsitektur, selanjutnya identifikasi prinsip arsitektur. Dalam TOGAF, prinsip arsitektur dibagi menjadi 4, yaitu prinsip bisnis, prinsip aplikasi, prinsip data dan prinsip teknologi. 5.1.3 Keluaran (output) Fase Preliminary Setelah dilakukan pemahaman terhadap masalah yang terjadi, ruang lingkup penelitian, pemilihan framework arsitektur, maka didapatkan beberapa output atau keluaran dari fase preliminary ini, diantaranya: 5.1.3.1 Komitmen Manajemen Dukungan manajemen merupakan salah satu faktor suksesnya pembuatan arsitektur enterprise. Oleh karena itu sebelum masuk ke dalam tahapan selanjutnya dari perancangan arsitektur perlu dipastikan terlebih dahulu komitmen dari manajemen agar proses selanjutnya berlangsung baik. Pada tahapan ini telah diperoleh dukungan manajemen di Kementerian Pekerjaan Umum. Komitmen manajemen dituangkan dalam Keputusan Menteri Pekerjaan Universitas Indonesia


53

Umum Nomor: 489A/KPTS/M/2007 Tentang Penunjukan Unit Kliring Data dan Informasi Departemen Pekerjaan Umum. 5.1.3.2 Framework Arsitektur Seperti yang telah dijelaskan sebelumnya pada sub bab 2.1.3 mengenai pemilihan EA Framework, maka dalam penelitian ini digunakan TOGAF (The Open Group Architecture Framework). 5.1.3.3 Prinsip Arsitektur Menurut The Open Gorup (The Open Group, 2009), prinsip arsitektur merupakan pedoman yang digunakan untuk menjelaskan dan mendukung strategi organisasi untuk memenuhi misinya. Prinsip arsitektur mendefinisikan pedoman dalam penggunaan dan pembangunan sumber daya dan aset TI dalam organisasi. Prinsip arsitektur yang digunakan dalam penelitian ini diperoleh dari hasil wawancara dengan narasumber yang terkait dan hasil adopsi dari best practice yang terdapat pada CCOA (Cloud Computing Open Architecture). Prinsip yang digunakan terbagi atas 4 sesuai dengan arsitektur yang akan dibuat, yaitu prinsip bisnis, aplikasi, data dan teknologi.



54

a.

Prinsip Bisnis Terdapat 3 prinsip yang menjadi pedoman dalam perancangan arsitektur bisnis. Prinsip bisnis ini dapat dilihat pada Tabel 5.1 sampai 5.3.  Ease of Access Tabel 5.1 Prinsip bisnis : ease of access Kode Prinsip

P1

Nama

Ease of access – kemudahan akses layanan

Sumber Referensi Pernyataan

Wawancara Transkrip wawancara 2 Akses layanan pemerintahan bidang pekerjaan umum yang semakin mudah.

Dasar Pemikiran

Layanan kepada publik yang berbasis TIK belum sepenuhnya terintegrasi dan mengakomodasi one stop service berupa layanan terpadu.

Implikasi

 Mendorong layanan terpadu Kementerian PU baik yang bersifat intra Satminkal maupun antar Satminkal.  Mendukung usaha untuk memperluas akses publik atas layanan terpadu Kementerian PU melalui penyediaan kapasitas akses dan konektifitas yang memadai.



55  Business Continuity Tabel 5.2 Prinsip bisnis : business continuity Kode Prinsip

P2

Nama

Business continuity – terjaminnya kelangsungan bisnis

Sumber Referensi

CCOA (Cloud Computing Open Architecture) Sub Bab 2.1.4, yaitu prinsip 7: Cloud Quality and Governance. Proses operasional TIK harus dapat berjalan normal tanpa

Pernyataan

adanya interupsi dari luar. Gangguan internal pada perangkat dan komponen komputasi pada arsitektur cloud computing

tidak mengganggu jalannya bisnis secara

signifikan. Dasar Pemikiran

Aplikasi dan teknologi informasi merupakan media komunikasi pemilik layanan dengan entitas bisnisnya, sehingga diperlukan arsitektur cloud computing yang terjamin kehandalannya dalam mendukung aplikasi TI yang berjalan di atasnya.

Implikasi

Rancangan

sistem

perlu

mempertimbangkan

aspek

ketersediaan layanan.



56  Recovery Tabel 5.3 Prinsip bisnis: recovery Kode Prinsip

P3

Nama

Recovery – pengembalian layanan dari terjadinya gangguan


Wawancara Transkrip wawancara 2 Sistem harus dirancang untuk siap menghadapi gangguan yang dapat terjadi. Kesiapan tersebut dinilai dari kecepatan kembalinya layanan setelah gangguan terjadi pada sistem.

Dasar Pemikiran

Layanan TI akan mendukung keberlangsungan bisnis, sehingga rancangan arsitektur harus mempertimbangkan keandalan layanan tersebut. Gangguan yang terjadi dapat mengakibatkan terganggunya layanan akan tetapi dapat dipulihkan dengan cepat tanpa hilangnya kualitas layanan secara signifikan. Rancangan arsitektur yang baru selain mempertimbangkan faktor kualitas ketersediaan perlu juga mempertimbangkan faktor pemulihan dari gangguan yang mungkin terjadi seperti gempa bumi, kebakaran dan kesalahan pengelolaan data.

Implikasi

 Perlu dibuat disaster recovery planning sebagai acuan perencanaan arsitektur dan proses bisnis ketika gangguan terjadi.  Pemilihan

perangkat

mempertimbangkan

faktor

kemampuan toleransi perangkat terhadap gangguan dan solusi pemulihan terbaik yang mungkin dilakukan bagi perangkat tersebut



57

b. Prinsip Aplikasi Terdapat 2 prinsip yang menjadi pedoman dalam perancangan arsitektur aplikasi. Prinsip aplikasi ini dapat dilihat pada Tabel 5.4 sampai 5.5.  Open Standard Tabel 5.4 Prinsip aplikasi: open standard Kode Prinsip

P4

Nama

Open

standard-

Aplikasi

dibangun

menggunakan

pendekatan standar terbuka. Sumber Referensi Pernyataan

CCOA (Cloud Computing Open Architecture) Sub Bab 2.1.4, yaitu prinsip 6: Unified Information Representation and Exchange Framework. Standar terbuka ditujukan untuk mempermudah pembangunan sistem dan integrasi antar aplikasi.

Dasar Pemikiran

Penggunaan standar terbuka mempermudah pembangunan aplikasi dan menghindari terjadinya vendor lock-in yang didasarkan atas standar vendor. Komunikasi antar aplikasi akan lebih mudah terjadi bila masing-masing aplikasi memiliki standar yang sama dan umumnya bisa dilakukan melalui standar terbuka. Contoh penggunaan standar terbuka seperti penggunaan protocol HTTP sebagai antar muka dan XML sebagai format pertukaran data.

Implikasi

Standar terbuka yang dipilih harus sederhana dan didukung teknologi yang cukup di pasaran.



58  Ease of Use Tabel 5.5 Prinsip aplikasi: ease of use Kode Prinsip

P5

Nama

Ease of use – Kemudahan dalam penggunaan


Wawancara Transkrip wawancara 2 Aplikasi dan proses

penggunaannya

harus

mudah

digunakan dan tidak menjadi sumber gangguan dalam pengelolaan sistem secara keseluruhan. Dasar Pemikiran

Produktivitas dan kualitas layanan dipengaruhi oleh alat bantu pengelolaan sistem dalam hal ini aplikasi. Semakin mudahnya penggunaan aplikasi, maka transisi penggunaan dari aplikasi lama menuju aplikasi baru menjadi lebih cepat dan tidak mengganggu proses bisnis. Aplikasi yang mudah digunakan dapat mengurangi tingkat stress pengguna dan mengurangi lama proses.

Implikasi

 Aplikasi yang digunakan harus sesuai dengan proses bisnis.  Antar muka aplikasi terstruktur dan mudah dipahami melalui alat bantu seperti manual dan pelatihan



59

c. Prinsip Data Terdapat 3 prinsip yang menjadi pedoman dalam perancangan arsitektur data. Prinsip data ini dapat dilihat pada Tabel 5.6 sampai 5.8. 

Data is an Asset Tabel 5.6 Prinsip data: data is an asset

Kode Prinsip

P6

Nama

Data is an asset - Data merupakan aset yang sangat penting


Wawancara Transkrip wawancara 2 Sebagai aset, data perlu dikelola dengan baik dan disebarkan kepada sistem yang memerlukan dalam rangka meningkatkan performansi kerja dan kualitas layanan.

Dasar Pemikiran

Di antara aset yang lain, data tergolong aset yang tidak tampak secara fisik akan tetapi memiliki tingkat nilai yang sangat berharga. Kehilangan data berdampak langsung terhadap proses kerja dan berisiko melumpuhkan sistem.  Sistem harus menjamin ketersediaan data melalui

Implikasi

teknologi proteksi data.  Adanya perlindungan terhadap data dari kerusakan secara logis akibat akses yang tidak berhak seperti terkena virus dan akses dari pengguna yang tidak berhak.



Data Sharing Tabel 5.7 Prinsip data: data sharing

Kode Prinsip

P7

Nama

Data sharing- Data dapat digunakan secara bersama-sama


Wawancara Transkrip wawancara 2 Data harus dapat diakses oleh pihak internal dan eksternal dan terintegrasi antar aplikasi.

Dasar Pemikiran

Akses yang cepat dan mudah menjadi salah satu penilaian kualitas layanan TI yang disediakan oleh sebuah sistem. Data

yang

dapat

digunakan

secara

bersama-saam

mempermudah akses terhadap data tersebut. Data yang



60

cepat diakses akan memberikan kecepatan dalam proses pengambilan keputusan. Implikasi

Arsitektur data harus mampu menunjukkan bahwa data dapat digunakan bersama-sama baik pada level Satminkal maupun level Kementerian.



Secure Tabel 5.8 Prinsip data: secure

Kode Prinsip

P8

Nama

Secure- Data harus dalam kondisi aman, bebas dari gangguan


Wawancara Transkrip wawancara 2 Data harus diamankan agar terhindar dari akses pihak yang tidak berhak yang berisiko mengganggu jalannya bisnis.

Dasar Pemikiran

Pengguna yang tidak berhak dapat melakukan perubahan terhadap data yang ada sehingga mengacaukan proses bisnis ketika data yang telah diubah digunakan. Walaupun tidak diubah, pengguna yang tidak berhak dapat menyebarkan data yang didapat dan digunakan oleh pihak lain sebagai referensi dalam proses melakukan gangguan terhadap layanan. Kedua aktivitas tersebut dapat mengganggu jalannya proses bisnis dan menimbulkan kerugian yang senilai dengan total nilai keseluruhan sistem.

Implikasi

Adanya manajemen keamanan yang ditujukan untuk memproteksi data.



61

d. Prinsip Teknologi Terdapat 2 prinsip yang menjadi pedoman dalam perancangan arsitektur teknologi. Prinsip teknologi ini dapat dilihat pada Tabel 5.9 sampai 5.10.  Sharing Tabel 5.9 Prinsip teknologi: sharing Kode Prinsip

P9

Nama

Sharing- Teknologi harus dapat dipakai bersama oleh lebih dari satu layanan atau fungsi.


CCOA (Cloud Computing Open Architecture) Sub Bab 2.1.4, yaitu prinsip 2: Virtualization for Cloud Infrastructure. Pemanfaatan teknologi harus dilakukan secara optimal melalui penggunaan sumber daya bersama

Dasar Pemikiran

Setiap perangkat teknologi umumnya memiliki spesifikasi kemampuan

yang

sudah

distandarkan.

Di

dalam

implementasinya, ada kecenderungan kemampuan tersebut tidak dipergunakan secara maksimal dikarenakan salah perencanaan. Beberapa layanan atau fungsi yang memiliki kesamaan kebutuhan spesifikasi sumber daya seperti perangkat keras dan lunak dapat menggunakan secara bersama sumber daya tersebut. Implikasi

 Diwujudkan dengan melakukan virtualisasi infrastruktur TI  Penggunaan teknologi yang mampu menyeragamkan kebutuhan sumber daya dari tiap layanan sehingga mempermudah proses pengelolaan terhadap infrastruktur teknis yang berbeda jenis.



62  Industrial Standard Tabel 5.10 Prinsip teknologi: industrial standard Kode Prinsip

P10

Nama

Industrial standard- teknologi yang digunakan mengacu kepada standar industri.


CCOA (Cloud Computing Open Architecture) Sub Bab 2.1.4, yaitu prinsip 5: Configurable Enablement for Cloud Offerings. Penggunaan teknologi yang memiliki standar industri luas menjamin keberlangsungan hidup sistem.

Dasar Pemikiran

Perangkat akan lebih mudah dikelola apabila telah menggunakan standar industri yang sudah memiliki maturitas tinggi. Hal ini dimungkinkan karena tersedianya sumber

daya

pendukung

seperti

dukungan

layanan

dokumentasi dan kontinuitas produk yang digunakan. Tetapi tetap perlu dilakukan penilaian terhadap ketersediaan standar terbuka dari perangkat yang digunakan sebagai prasyarat dalam proses integrasi antar sistem. Implikasi

 Penggunaan teknologi yang sudah umum di pasaran, memiliki tingkat maturitas teknologi terbaik.  Adanya dukungan layanan yang baik seperti support 24x7 dan dokumentasi yang baik dan cukup.  Mendukung

standar

terbuka

yang

memungkinkan

interoperabilitas dengan sistem lain.



63

5.2

Tahap 5. Requirement Management

Tujuan dari tahap requirement management adalah menyediakan proses pengelolaan

kebutuhan

arsitektur

sepanjang

fase

pada

siklus

ADM,

mengumpulkan, menginventarisir dan mengidentifikasi seluruh kebutuhan enterprise, menyimpan lalu memberikannya kepada fase TOGAF ADM yang relevan. Referensi yang dibutuhkan pada fase ini diantaranya Renstra Kementerian Pekerjaan Umum, Cetak Biru TIK Kementerian Pekerjaan Umum, Standard Operational Procedure (SOP). Fase requirement management termasuk fase yang penting karena terkait dengan rencana strategis dan kebijakan manajemen. Pengembangan teknologi informasi harus sesuai dengan requirement management organisasi. Detil requirement management terkait dengan teknologi informasi yang akan dibangun adalah sebagai berikut:

5.2.1 Architecture Vision Visi Kementerian Pekerjaan Umum

yaitu

“Tersedianya Infrastruktur

Pekerjaan Umum dan Permukiman yang Andal untuk Mendukung Indonesia Sejahtera 2025”. Visi tersebut merupakan sebuah gambaran yang akan diwujudkan oleh Kementerian Pekerjaan Umum pada tahun 2025, dimana infrastruktur pekerjaan umum dan permukiman yang terbangun telah memenuhi kualifikasi teknis sesuai perkembangan dan kemajuan teknologi serta beroperasi secara optimal seiring dengan tuntutan kualitas kehidupan masyarakat. 5.2.2 Bussiness Architecture Arsitektur bisnis merupakan gambaran kegiatan yang dilakukan setiap hari secara sistematis berdasarkan visi dan misi organisasi. Dengan arsitektur bisnis dapat diketahui proses bisnis pada Kementerian Pekerjaan Umum. Dengan diketahuinya proses bisnis maka dapat dilakukan penetapan tugas dan tanggung jawab, sehingga fungsi bisnis yang ada dapat berjalan dengan baik.

5.2.3 Information System Architecture Pada tahap ini lebih menekankan pada bagaimana arsitektur sistem informasi dikembangkan. Requirement management pada fase information system Universitas Indonesia


64

architecture ditinjau dari 2 aspek, yaitu application architecture dan data architecture. Penjelasan kedua aspek tersebut adalah sebagai berikut: 1. Application Architecture (arsitektur aplikasi) Secara garis besar, organisasi membutuhkan aplikasi yang dapat dibedakan dalam aplikasi khusus dan aplikasi umum. Aplikasi khusus utamanya diperlukan untuk mendukung proses-proses bisnis utama Kementerian yang ada di masing-masing satminkal. Sedangkan aplikasi umum adalah aplikasi yang mendukung proses bisnis pendukung. 2. Data Architecture (arsitektur data) Pada arsitektur data, organisasi membutuhkan sumber data yang terpusat dan terintegrasi dengan tujuan meningkatkan koordinasi dan sinkronisasi dari operasi pengolahan data serta dapat menyediakan informasi yang digunakan antar satminkal, bersifat akurat dan tepat waktu. Dengan data yang terintegrasi diharapkan informasi yang disajikan benar dan akurat. 5.2.4 Technology Architecture Pada arsitektur teknologi, organisasi membutuhkan pembangunan arsitektur teknologi untuk tujuan integrasi data dan berbagi bersama infrastruktur TI. 5.2.5 Opportunities and Solutions Pada

opportunities

pembangunan

dan

and

solutions,

pengembangan

organisasi teknologi

memiliki cloud

rencana

computing.

dalam Dalam

mengembangkan teknologi cloud computing, dibutuhkan kesiapan infrastruktur teknologi informasi.



65

5.3

Tahap 6. Architecture Vision

Sebelum melakukan perancangan arsitektur, terlebih dahulu dilakukan identifikasi visi arsitektur. Tujuan dari fase architecture vision yaitu untuk memastikan bahwa rancangan arsitektur yang akan dibuat selaras dengan kebutuhan organisasi. Identifikasi yang dilakukan pada fase ini direpresentasikan melalui aspek visi dan misi, tujuan organisasi, sasaran strategis, ruang lingkup dan stakeholder. Gambar 5.2 memperlihatkan mengenai input, steps dan output dari fase architecture vision.

Input: 1. Visi dan Misi Organisasi 2. Tujuan Organisasi 3. Sasaran Strategis Organisasi 4. Prinsip Arsitektur

Steps: Identifikasi stakeholder

Output: 1. Peran dan tanggung jawab stakeholder 2. Ruang Lingkup dan batasan 3. Value Chain Diagram

Gambar 5.2 Input, steps, output fase architecture vision

5.3.1 Masukan (input) Fase Architecture Vision Terdapat 4 hal yang menjadi input atau masukan pada fase architecture vision ini, diantaranya: 1. Visi dan Misi Organisasi Visi Kementerian Pekerjaan Umum “Tersedianya Infrastruktur Pekerjaan Umum dan Permukiman yang Andal untuk Mendukung Indonesia Sejahtera 2025”



66

Misi Kementerian Pekerjaan Umum a. Mewujudkan penataan ruang sebagai acuan matra spasial dari pembangunan nasional dan daerah serta keterpaduan pembangunan infrastruktur pekerjaan umum dan permukiman berbasis penataan ruang dalam rangka pembangunan berkelanjutan. b. Menyelenggarakan pengelolaan SDA secara efektif dan optimal untuk meningkatkan kelestarian fungsi dan keberlanjutan pemanfaatan SDA serta mengurangi risiko daya rusak air. c. Meningkatkan aksesibilitas dan mobilitas wilayah dalam mendukung pertumbuhan ekonomi dan meningkatkan kesejahteraan masyarakat dengan penyediaan jaringan jalan yang andal, terpadu dan berkelanjutan. d. Meningkatkan kualitas lingkungan permukiman yang layak huni dan produktif melalui pembinaan dan fasilitasi pengembangan infrastruktur permukiman yang terpadu, andal dan berkelanjutan. e. Menyelenggarakan industri konstruksi yang kompetitif dengan menjamin adanya keterpaduan pengelolaan sektor konstruksi, proses penyelenggaraan konstruksi yang baik dan menjadikan pelaku sektor konstruksi tumbuh dan berkembang. f. Menyelenggarakan Penelitian dan Pengembangan serta Penerapan: IPTEK, norma, standar, pedoman, manual dan/atau kriteria pendukung infrastruktur PU dan permukiman. g. Menyelenggarakan dukungan manajemen fungsional dan sumber daya yang akuntabel dan kompeten, terintegrasi serta inovatif dengan menerapkan prinsip-prinsip good governance. h. Meminimalkan penyimpangan dan praktik-praktik KKN di lingkungan Kementerian PU dengan meningkatkan kualitas pemeriksaan dan pengawasan profesional.



67

2. Tujuan Organisasi Sebagai penjabaran atas visi Kementerian PU, maka tujuan yang akan dicapai oleh Kementerian PU dalam periode 2010-2014 adalah: a. Meningkatkan kualitas penyelenggaraan penataan ruang untuk terlaksananya pengembangan wilayah dan pembangunan nasional serta daerah yang terpadu dan sinergis bagi terwujudnya ruang yang aman, nyaman, produktif dan berkelanjutan. b. Meningkatkan keandalan sistem jaringan infrastruktur pekerjaan umum dan pengelolaan sumber daya air untuk meningkatkan daya saing melalui pertumbuhan ekonomi nasional, ketahanan pangan, ketahanan air dan ketahanan energy. c. Meningkatkan kualitas lingkungan permukiman dan cakupan pelayanan infrastruktur dasar bidang permukiman untuk meningkatkan kesejahteraan masyarakat. d. Meningkatkan

kapasitas

pengawasan

pengendalian

pelaksanaan

dan

akuntabilitas kinerja untuk mencapai efektivitas dan efisiensi pelayanan publik bidang pekerjaan umum. e. Meningkatkan kapasitas kelembagaan dan SDM aparatur dan jasa konstruksi serta penelitian dan pengembangan bidang pekerjaan umum dan permukiman untuk meningkatkan kinerja pelayanan bidang pekerjaan umum dan jasa konstruksi. 3. Sasaran Strategis Organisasi Adapun sasaran strategis berdasarkan 5 tujuan Kementerian PU yang akan dicapai meliputi: a. Tujuan 1 Meningkatkan kualitas penyelenggaraan penataan ruang untuk terlaksananya pengembangan wilayah dan pembangunan nasional serta daerah yang terpadu dan sinergis bagi terwujudnya ruang yang aman, nyaman, produktif dan berkelanjutan.



68

Sasaran Terwujudnya perumusan dan pelaksanaan kebijakan dan standarisasi teknis bidang penataan ruang, dengan outcome-nya: Tercapainya kesesuaian program pusat dan daerah dengan rencana tata ruang dalam rangka pengembangan wilayah dan pembangunan nasional serta daerah, dan terselesaikannya norma, standar, prosedur dan kriteria bidang penataan ruang sesuai peraturan perundang-undangan. b. Tujuan 2 Meningkatkan keandalan sistem jaringan infrastruktur pekerjaan umum dan pengelolaan sumber daya air untuk meningkatkan daya saing melalui pertumbuhan ekonomi nasional, ketahanan pangan, ketahanan air dan ketahanan energi. Sasaran a. Meningkatnya keberlanjutan dan ketersediaan air untuk memenuhi berbagai kebutuhan, dengan outcome-nya: Meningkatnya kinerja pengelolaan sumber daya air. b. Berkurangnya luas kawasan yang terkena dampak banjir, dengan outcomenya: Meningkatnya kinerja pengelolaan sumber daya air. c. Meningkatnya layanan jaringan irigasi dan rawa, dengan outcome-nya: Meningkatnya kinerja pengelolaan sumber daya air. d. Meningkatnya kapasitas jalan nasional sepanjang 19.370 km, dengan outcome-nya:  Meningkatnya panjang peningkatan struktur/pelebaran jalan.  Meningkatnya panjang jalan baru yang dibangun. e. Meningkatnya kualitas layanan jalan nasional dan pengelolaan jalan daerah, dengan outcome-nya:  Meningkatnya fasilitasi penyelenggaraan jalan daerah untuk menuju 60% kondisi mantap.  Meningkatnya kondisi mantap jaringan jalan nasional.  Meningkatnya penggunaan jalan nasional.



69

c. Tujuan 3 Meningkatkan kualitas lingkungan permukiman dan cakupan pelayanan infrastruktur dasar bidang permukiman untuk meningkatkan kesejahteraan masyarakat. Sasaran 1. Meningkatnya kualitas kawasan permukiman dan penataan ruang dengan outcome-nya: a. Terlaksananya pembangunan rusunawa. b. Berkurangnya kawasan kumuh perkotaan. c. Meningkatnya jumlah kabupaten/kota yang menerapkan NSPK dalam pengembangan kawasan permukiman sesuai rencana tata ruang wilayah/kawasan bagi terwujudnya pembangunan permukiman. d. Terwujudnya revitalisasi kawasan permukiman dan penataan bangunan. 2. Meningkatnya kualitas layanan air minum dan sanitasi permukiman perkotaan, dengan outcome-nya: a. Meningkatnya jumlah kabupaten/kota yang menerapkan NSPK dalam pengembangan kawasan permukiman sesuai rencana tata ruang wilayah/kawasan bagi terwujudnya pembangunan permukiman. b. Meningkatnya jumlah pelayanan sanitasi. c. Terlaksananya pembinaan kemampuan Pemda/PDAM. d. Meningkatnya cakupan pelayanan air minum. e. Berkurangnya potensi timbunan sampah. 3. Meningkatnya

kualitas

infrastruktur

permukiman

perdesaan/kumuh/nelayan dengan pola pemberdayaan masyarakat, dengan outcome-nya: a. Meningkatnya jumlah kelurahan/desa yang ditingkatkan infrastruktur permukiman perdesaan/kumuh/nelayan. b. Menurunnya kesenjangan antar wilayah. 4. Meningkatnya kualitas pengaturan, pembinaan dan pengawasan pada pembangunan infrastruktur permukiman, dengan outcome-nya:



70

a. Meningkatnya jumlah kabupaten/kota yang menerapkan NSPK dalam pengembangan kawasan permukiman sesuai rencana tata ruang wilayah/kawasan bagi terwujudnya pembangunan permukiman. b. Tersedianya infrastruktur tanggap darurat/kebutuhan mendesak. 5. Tujuan 4 Meningkatnya

kapasitas

pengawasan

pengendalian

pelaksanaan,

dan

akuntabilitas kinerja untuk mencapai efektivitas dan efisiensi pelayanan publik bidang pekerjaan umum. Sasaran Terwujudnya

peningkatan

kepatuhan

dan

akuntabilitas

kinerja

penyelenggaraan infrastruktur yang bebas Kolusi, Korupsi dan Nepotisme (KKN) dengan outcome-nya: Meningkatkan kualitas pengawasan dan pembinaan serta pemeriksaan terhadap pelaksanaan tugas di lingkup Kementerian PU. 6. Tujuan 5 Meningkatkan kapasitas kelembagaan dan SDM aparatur dan jasa konstruksi serta penelitian dan pengembangan bidang pekerjaan umum dan permukiman untuk meningkatkan kinerja pelayanan bidang pekerjaan umum dan jasa konstruksi. Sasaran 1. Meningkatnya

koordinasi,

administrasi

dan

kualitas

perencanaan,

pengaturan, pengelolaan keuangan dan Barang Milik Negara (BMN), dengan outcome-nya: Terwujudnya pelayanan administrasi pemerintah yang baik di lingkungan Kementerian Pekerjaan Umum. 2. Meningkatnya kualitas kelembagaan dan Sumber Daya Manusia (SDM) aparatur, dengan outcome-nya: Terwujudnya pelayanan administrasi pemerintah yang baik di lingkungan Kementerian Pekerjaan Umum. 3. Meningkatnya kualitas prasarana, pengelolaan data, informasi dan komunikasi public, dengan outcome-nya: Terwujudnya dukungan sarana dan prasarana komunikasi dan informasi yang memadai di lingkungan Kementerian Pekerjaan Umum.



71

4. Meningkatnya kapasitas dan kinerja pembina jasa konstruksi di pusat dan daerah, dengan outcome-nya: a. Meningkatnya kualitas kelembagaan, SDM dan kebijakan pembina jasa konstruksi pusat dan daerah. b. Memberikan arah pertumbuhan dan perkembangan konstruksi untuk mewujudkan struktur usaha konstruksi yang kokoh, andal, berdaya saing tinggi. c. Meningkatnya kompetensi SDM konstruksi sesuai standar kompetensi kerja nasional dan internasional. 5. Meningkatnya IPTEK dan NSPM (K) siap pakai, dengan outcome-nya: a. Meningkatnya Litbang yang masuk bursa pilihan teknologi siap pakai. b. Meningkatnya kesiapan IPTEK untuk diterapkan stakeholder. c. Diberlakukannya SPMK dan teknologi oleh stakeholder. d. Diterimanya rekomendasi IPTEK oleh stakeholder. e. Peningkatan layanan penyelenggaraan Litbang. 4. Prinsip Arsitektur Prinsip Arsitektur sudah dijelaskan pada sub bab 5.1.3.3. 5.3.2 Proses (steps) pada Fase Architecture Vision Pada fase ini dilakukan identifikasi stakeholder beserta tugasnya dalam rangka mengemban dan mencapai visi dan misi, tujuan dan sasaran strategis organisasi. Berdasarkan Peraturan Menteri Pekerjaan Umum Nomor : 08/PRT/M/2010 Tanggal 8 Juli 2010 tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum, ditetapkan susunan Organisasi Kementerian Pekerjaan Umum terdiri atas 19 unit, yang semuanya menjadi pihak stakeholder dalam pembangunan arsitektur teknologi informasi yang menjadi objek penelitian ini. Sembilan belas unit tersebut diantaranya: 1.

Wakil Menteri Pekerjaan Umum

2.

Sekretariat Jenderal

3.

Direktorat Jenderal Sumber Daya Air

4.

Direktorat Jenderal Bina Marga

5.

Direktorat Jenderal Cipta Karya Universitas Indonesia


72

6.

Inspektorat Jenderal

7.

Badan Pembinaan Konstruksi

8.

Badan Penelitian dan Pengembangan

9.

Staf Ahli Bidang Keterpaduan Pembangunan

10. Staf Ahli Bidang Ekonomi dan Investasi 11. Staf Ahli Bidang Sosial Budaya dan Peran Masyarakat 12. Staf Ahli Bidang Hubungan Antar Lembaga 13. Staf Ahli Bidang Pengembangan Keahlian dan Tenaga Fungsional 14. Pusat Pengolahan Data 15. Pusat Pendidikan dan Pelatihan 16. Pusat Komunikasi Publik 17. Pusat Kajian Strategis 18. Pusat Pengelolaan Barang Milik Negara 5.3.3 Keluaran (output) Fase Architecture Vision Dari hasil identifikasi stakeholder beserta tugasnya dalam rangka mengemban dan mencapai visi dan misi, tujuan dan sasaran strategis organisasi, maka dihasilkan beberapa output atau keluaran sebagai berikut: 5.3.3.1 Peran dan tanggung jawab stakeholder Menurut The Open Group (The Open Group, 2009), pada fase architecture vision dihasilkan output berupa artifact yang dinamakan stakeholder map matrix. Tabel 5.11 berikut ini memperlihatkan mengenai stakeholder map matrix. Tabel 5.11 Stakeholder map matrix Stakeholder Tugas Wakil Menteri Wakil Menteri Pekerjaan Umum mempunyai tugas membantu Pekerjaan Umum Menteri Pekerjaan Umum dalam memimpin pelaksanaan tugas Kementerian Pekerjaan Umum. Sekretariat Sekretariat Jenderal mempunyai tugas melaksanakan Jenderal koordinasi pelaksanaan tugas, pembinaan dan pemberian dukungan administrasi kepada seluruh unit organisasi di lingkungan Kementerian Pekerjaan Umum. Direktorat Jenderal Direktorat Jenderal Penataan Ruang mempunyai tugas Penataan Ruang merumuskan serta melaksanakan kebijakan dan standarisasi teknis di bidang penataan ruang sesuai peraturan perundangundangan.



73

Tabel 5.11 Stakeholder map matrix (lanjutan) Stakeholder Direktorat Jenderal Sumber Daya Air

Tugas Direktorat Jenderal Sumber Daya Air mempunyai tugas merumuskan serta melaksanakan kebijakan dan standarisasi teknis di bidang sumber daya air sesuai peraturan perundangundangan.


Direktorat Jenderal Bina Marga mempunyai tugas merumuskan serta melaksanakan kebijakan dan standarisasi teknis di bidang bina marga. Direktorat Jenderal Cipta Karya mempunyai tugas merumuskan serta melaksanakan kebijakan dan standarisasi teknis di bidang cipta karya sesuai dengan peraturan perundang-undangan. Inspektorat Jenderal mempunyai tugas melaksanakan pengawasan intern di lingkungan Kementerian Pekerjaan Umum

Direktorat Jenderal Cipta Karya



Badan Pembinaan Konstruksi mempunyai tugas melaksanakan pembinaan konstruksi.


Badan penelitian dan pengembangan mempunyai tugas melaksanakan penelitian dan pengembangan di bidang pekerjaan umum.

Staf Ahli Bidang Keterpaduan Pembangunan

Staf Ahli Bidang Keterpaduan Pembangunan mempunyai tugas memberikan telaahan kepada Menteri Pekerjaan Umum mengenai masalah keterpaduan pembangunan.

Staf Ahli Bidang Ekonomi dan Investasi

Staf Ahli Bidang Ekonomi dan Investasi mempunyai tugas memberikan telaahan kepada Menteri Pekerjaan Umum mengenai masalah ekonomi dan investasi.

Staf Ahli Bidang Staf Ahli Bidang Sosial Budaya dan Peran Masyarakat Sosial Budaya dan mempunyai tugas memberikan telaahan kepada Menteri Peran Masyarakat Pekerjaan Umum mengenai masalah sosial budaya dan peran masyarakat Staf Ahli Bidang Staf Ahli Bidang Hubungan Antar Lembaga mempunyai tugas Hubungan Antar memberikan telaahan kepada Menteri Pekerjaan Umum Lembaga mengenai masalah hubungan antar lembaga. Staf Ahli Bidang Staf Ahli Bidang Pengembangan Keahlian dan Tenaga Pengembangan Fungsional mempunyai tugas memberikan telaahan kepada Keahlian dan Menteri Pekerjaan Umum mengenai masalah pengembangan Tenaga Fungsional keahlian dan tenaga fungsional.



74

Tabel 5.11 Stakeholder Map Matrix (lanjutan) Stakeholder Tugas Pusat Pengolahan Pusat Pengolahan Data mempunyai tugas melaksanakan Data pembinaan, pengembangan, pengelolaan dan penyediaan data infrastruktur bidang pekerjaan umum serta penyelenggaraan sistem informasi mendukung manajemen Kementerian. Pusat Pendidikan Pusat Pendidikan dan Pelatihan mempunyai tugas dan Pelatihan melaksanakan pembinaan, pengembangan dan penyelenggaraan pendidikan dan pelatihan teknis, fungsional dan kepemimpinan serta pemberdayaan dan pembinaan SDM di Kementerian Pekerjaan Umum. Pusat Komunikasi Pusat Komunikasi Publik mempunyai tugas melaksanakan Publik penyebarluasan informasi kebijakan dan program pelaksanaan penyelenggaraan pembangunan bidang pekerjaan umum, pelayanan informasi publik, serta urusan tata usaha dan protokoler pimpinan Kementerian. Pusat Kajian Pusat Kajian Strategis mempunyai tugas melaksanakan Strategis pengkajian dan perumusan kebijakan dan strategi pembangunan, fasilitasi pengembangan investasi, evaluasi pelaksanaan kebijakan dan strategi pembangunan, kinerja pembangunan, serta penyebarluasan informasi kebijakan bidang pekerjaan umum dan penataan ruang. Pusat Pengelolaan Pusat Pengelolaan Barang Milik Negara mempunyai tugas Barang Milik melaksanakan perencanaan, pembinaan, pengawasan, Negara pengendalian dan penatausahaan serta pemindahtanganan dan pemanfaatan barang milik negara dan kekayaan negara pada tingkat Kementerian Pekerjaan Umum.

5.3.3.2 Ruang Lingkup dan Batasan Perancangan arsitektur dilakukan dengan membatasi ruang lingkup yang terdiri atas enam fase awal dari TOGAF ADM yang mencakup preliminary, architecture vision, business architecture, information system architecture, technology architecture dan opportunities and solutions.

5.3.3.3 Value Chain Diagram Rantai nilai (value chain) Porter digunakan dalam memodelkan arsitektur bisnis dengan mendefinisikan area fungsional utama (primarily activities) dan area fungsional pendukung (support activities) (Ward & Peppard, 2002). Gambar 5.3 merupakan rantai nilai yang ada pada Kementerian Pekerjaan Umum.




Kesekretariatan (perencanaan dan kerjasama Luar Negeri, kepegawaian dan ortala, keuangan, umum dan hukum) dan Pusat di bawah koordinasi Sekretaris Jenderal

Melaksanakan Kebijakan di Bidang Penataan Ruang

Melaksanakan Kebijakan di Bidang Sumber Daya Air

Melaksanakan Kebijakan di Bidang Bina Marga

Melaksanakan Kebijakan di Bidang Cipta Karya

Melaksanakan Pembinaan Konstruksi

Melaksanakan Penelitian dan Pengembangan di Bidang Pekerjaan Umum

Tersedianya Infrastruktur Pekerjaan Umum dan Permukiman yang Andal untuk Mendukung Indonesia Sejahtera 2025

Support Activities

75

Primary Activities

Gambar 5.3 Rantai nilai Kementerian PU Dari Gambar 5.3 di atas, pemodelan fungsi bisnis menurut analisa rantai nilai, terbagi menjadi aktivitas utama pada Kementerian Pekerjaan Umum, yaitu melaksanakan kebijakan di bidang penataan ruang, melaksanakan kebijakan di bidang sumber daya air, melaksanakan kebijakan di bidang bina marga, melaksanakan kebijakan di bidang cipta karya, melaksanakan pembinaan konstruksi dan melaksanakan penelitian dan pengembangan di bidang pekerjaan umum. Sedangkan aktivitas pendukung, yaitu kesekretariatan (perencanaan dan kerjasama Luar Negeri, kepegawaian dan ortala, keuangan, umum dan hukum) dan Pusat di bawah koordinasi Sekretaris Jenderal serta Inspektorat Jenderal.



76

5.4

Tahap 7. Business Architecture

Fase business architecture bertujuan untuk (1) memilih sudut pandang terhadap arsitektur yang bersesuaian dengan bisnis dan memilih teknik dan tools yang tepat, (2) mendeskripsikan arsitektur bisnis saat ini dan target pengembangannya serta analisis kesenjangan antara keduanya. Dalam penelitian ini berusaha untuk tidak mengubah proses bisnis yang ada, karena semua prosedur dan ketetapan pemerintah maupun manajemen sudah terbentuk dan dijalankan. Oleh karena itu, dalam fase business architecture ini tidak terdapat arsitektur bisnis target atau kondisi to be dan analisis kesenjangan. Gambar 5.4 memperlihatkan mengenai input, steps dan output dari fase business architecture.

Input: Output dari fase architecture vision

Steps: Identifikasi proses bisnis

Output: Artifact : Functional Decomposition Diagram

Gambar 5.4 Input, steps, output fase business architecture 5.4.1 Masukan (input) Fase Business Architecture Input atau masukan pada fase ini adalah output atau keluaran dari fase sebelumnya (fase architecture vision), berupa value chain diagram. 5.4.2 Proses (steps) pada Fase Business Architecture Setelah mendapatkan masukan berupa value chain diagram, maka selanjutnya dilakukan identifikasi proses bisnis.



77

Dari analisis pada Gambar 5.3, terdapat 6 aktifitas utama dan 2 aktifitas pendukung pada Kementerian Pekerjaan Umum. Penjelasan mengenai hasil analisis value chain diagram terdapat pada Tabel 5.12 sampai Tabel 5.19. 1.

Aktifitas Utama a. Penataan Ruang Tabel 5.12 Proses bisnis utama Dirjen Penataan Ruang No

1.

2.

3.

4.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Bina Program dan Penyusunan kebijakan dan strategi penataan Kemitraan ruang Penyusunan program dan anggaran penataan ruang Evaluasi kinerja penyelenggaraan jalan Pengelolaan Informasi dan Komunikasi Pembinaan kemitraan Penataan Ruang Wilayah Penyusunan kebijakan dan strategi penataan Nasional ruang nasional Pengaturan tata ruang nasional Penyusunan tata ruang nasional Koordinasi lintas sektoral dan wilayah Monitoring-evaluasi tata ruang nasional Penataan Ruang Penyusunan kebijakan dan strategi penataan Perkotaan ruang kota Pengaturan tata ruang kota Pembinaan tata ruang kota Pengembangan tata ruang kota strategis Pengendalian tata ruang kota Pembinaan Penataan Penyusunan kebijakan tata ruang daerah Ruang Daerah Wilayah wilayah Pengaturan tata ruang daerah wilayah Pembinaan teknis tata ruang daerah wilayah Pengendalian tata ruang daerah wilayah



78

b. Sumber Daya Air Tabel 5.13 Proses bisnis utama Dirjen Sumber Daya Air No

1.

Proses Bisnis Level Direktorat Jenderal Bina Program

Proses Bisnis Level Direktorat

2.

Bina Penatagunaan Sumber Daya Air

3.

Pengelolaan Sungai dan Pantai

4.

Pengelolaan Irigasi dan Rawa

5.

Bina Operasi Pemeliharaan (OP)

dan

Penyusunan kebijakan dan strategi pengelolaan sumber daya air Penyusunan program dan anggaran pengelolaan sumber daya air Evaluasi kinerja pengelolaan sumber daya air Pengelolaan Informasi dan Komunikasi Pengelolaan kerjasama luar negeri Pengelolaan hidrologi dan kualitas air Perencanaan Wilayah Sungai Pengaturan dalam pengelolaan SDA Pembinaan kelembagaan Pengendalian pemanfaatan SDA Perencanaan teknis sungai dan pantai Pembinaan pengelolaan sungai dan pantai Pembinaan pengelolaan prasarana konservasi dan sedimen Perencanaan teknis irigasi dan rawa Pembinaan pengelolaan irigasi dan rawa Pembinaan pengelolaan air baku dan air tanah Perencanaan operasi dan pemeliharaan Pembinaan pelaksanaan OP sungai dan pantai Pembinaan pelaksanaan OP bendungan Pembinaan pelaksanaan OP irigasi dan rawa Penanggulangan bencana



79

c. Bina Marga Tabel 5.14 Proses bisnis utama Dirjen Bina Marga No

1.



Penyusunan kebijakan dan strategi penyelenggaraan jalan Penyusunan program dan anggaran penyelenggaraan jalan Pengelolaan pembiayaan dan investasi jalan Pengembangan sistem manajemen penyelenggaraan jalan Evaluasi kinerja penyelenggaraan jalan Pengelolaan informasi dan komunikasi Bina Teknik Pembinaan teknis jalan Pembinaan teknis jembatan Pembinaan teknis lingkungan dan keselamatan jalan Pembinaan teknis jalan tol dan jalan perkotaan Pengadaan tanah Bina Pelaksanaan Pengendalian penyelenggaraan jalan Wilayah Pembinaan penyelenggaraan jalan

2.

3.

d. Cipta Karya Tabel 5.15 Proses bisnis utama Dirjen Cipta Karya No

1.

2.

3.



Penyusunan kebijakan dan strategi Penyusunan program dan anggaran Pengelolaan pembiayaan dan investasi Pengelolaan data dan informasi Evaluasi kinerja Pengembangan Perencanaan teknis pemukiman Pemukiman Pengembangan pemukiman baru Peningkatan pemukiman wilayah Pembinaan pengembangan pemukiman Penataan Bangunan dan Perencanaan teknis penataan bangunan dan Lingkungan lingkungan Pembinaan wilayah Pembinaan pengelolaan gedung dan rumah negara Pembinaan penataan bangunan dan wilayah



80

Tabel 5.15 Proses bisnis utama Dirjen Cipta Karya (lanjutan) No

4.

5.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Pengembangan Air Perencanaan teknis pengembangan air minum Minum Pengembangan investasi penyediaan air minum Pembinaan wilayah Pengembangan investasi Pengaturan dan pembinaan kelembagaan Pengembangan Perencanaan teknis pengembangan penyehatan lingkungan penyehatan lingkungan pemukiman pemukiman Pembinaan air limbah Pembinaan drainase Pembinaan persampahan Pengaturan dan pembinaan kelembagaan

e. Pembinaan Konstruksi Tabel 5.16 Proses bisnis utama Badan Pembinaan Konstruksi No

1.

2.

3.

4.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Pembinaan usaha dan Pembinaan pengembangan usaha kelembagaan Pembinaan regulasi usaha dan perizinan Pembinaan bidang kelembagaan Pembinaan Pembinaan pemilihan penyedia barang dan penyelenggaraan jasa konstruksi Pembinaan administrasi kontrak Pembinaan teknik konstruksi berkelanjutan Pembinaan sumber daya Pengembangan pola investasi investasi Perumusan kebijakan bidang material dan peralatan Perumusan kebijakan pembinaan pasar dan daya saing Pembinaan kompetensi Penyusunan bakuan kompetensi konstruksi dan pelatihan konstruksi Pengembangan keahlian konstruksi Penyusunan dan evaluasi program pelatihan konstruksi



81

f. Penelitian dan Pengembangan Tabel 5.17 Proses bisnis utama Badan Penelitian dan Pengembangan No

1.

2.

3.

4.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Penelitian dan Penyusunan program dan anggaran pengembangan sumber penelitian dan pengembangan SDA daya air Pengelolaan sumberdaya kelitbangan SDA Penyusunan dan diseminasi standar SDA Penelitian dan Penyusunan program dan anggaran pengembangan jalan dan penelitian dan pengembangan jalan dan jembatan jembatan Pengelolaan sumber daya kelitbangan jalan dan jembatan Penyusunan dan diseminasi standar jalan dan jembatan Penelitian dan Penyusunan program dan anggaran pengembangan penelitian dan pengembangan pemukiman pemukiman Pengelolaan sumber daya kelitbangan pemukiman Penyusunan dan diseminasi standar pemukiman Penelitian dan Penyusunan program dan anggaran pengembangan sosial, penelitian dan pengembangan aspek sosial, ekonomi dan lingkungan ekonomi dan lingkungan Pengelolaan sumber daya kelitbangan aspek sosial, ekonomi dan lingkungan. Penyusunan dan diseminasi standar aspek sosial, ekonomi dan lingkungan



82

2.

Aktivitas Pendukung a. Inspektorat Tabel 5.18 Proses bisnis pada Inspektorat No

1.

2.

3.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Pengawasan intern Penyiapan rencana dan program pengawasan wilayah wilayah Pelaksanaan pemeriksaan wilayah Penyusunan laporan hasil pengawasan wilayah Pemantauan tindak lanjut pemeriksaan wilayah Pengawalan pelaksanaan program wilayah Pemeriksaan pengadaan wilayah Penelitian awal wilayah Evaluasi kinerja program/kegiatan wilayah Pengawasan aset / barang milik negara di wilayah Pengawasan intern khusus Penyiapan rencana dan program pengawasan Pelaksanaan pemeriksaan satuan kerja pusat dan khusus/investogatif Penyusunan laporan hasil pengawasan Pengelolaan pengaduan masyarakat Evaluasi laporan akuntabilitas kinerja instansi pemerintah Reviu laporan keuangan Pemeriksaan ex officio Evaluasi laporan hasil Analisa data hasil pengawasan pengawasan Pemantauan tindak lanjut hasil pengawasan

b. Kesekretariatan dan Pusat di Bawah Koordinasi Sekretaris Jenderal Tabel 5.19 Proses bisnis utama Kesekretariatan No

1.

2.

Proses Bisnis Proses Bisnis Level Direktorat Level Direktorat Jenderal Perencanaan dan Pengelolaan perencanaan umum, program, kerjasama luar negeri anggaran dan monitoring pencapaian perencanaan Pengelolaan kerjasama luar negeri Pengelolaan pegawai dan Pengelolaan kepegawaian yang mencakup ortala personalia, pengembangan pegawai dan mutasi Pengelolaan organisasi dan tata laksana



83

Tabel 5.19 Proses bisnis utama Kesekretariatan (lanjutan) No

3.

4.

5. 6.

7.

8.

9.

10.

Proses Bisnis Level Direktorat Jenderal Keuangan


Perbendaharaan Anggaran dan Pengembangan Penerimaan Negara Bukan Pajak Verifikasi dan Akuntansi Pembinaan badan usaha dan layanan umum Pengelolaan Umum Pengelolaan ketatausahaan kementerian: tata naskah dinas, kearsipan Pengelolaan rumah tangga kementerian: keamanan, kendaraan, poliklink Pengelolaan prasarana fisik kementerian: pemeliharaan gedung, listrik, telp, air Penanganan Hukum dan Pengelolaan peraturan perundang-undangan Per-UU-an Pemberian bantuan hokum Kajian Strategis Mengkaji, merumuskan kebijakan dan strategi pembangunan, serta mengevaluasi pelaksanaannya Mengkaji dan memfasilitasi pengembangan investasi Mengevaluasi kinerja pembangunan Menyebarluasan kebijakan bidang pekerjaan umum dan penataan ruang serta urusan administrasi teknik/ketatausahaan Pengelolaan Barang Pengelolaan Barang Milik Negara yang Milik Negara meliputi: perencanaan, pembinaan, pengawasan, pengendalian dan penatausahaan serta pemindahtanganan dan pemanfaatan barang milik negara Komunikasi Publik Penyebarluasan informasi kebijakan dan program pelaksanaan penyelenggaraan pembangunan bidang pekerjaan umum Pelayanan informasi publik Tata usaha dan protokoler pimpinan Kementerian Pendidikan dan pelatihan Pembinaan, pengembangan dan penyelenggaraan pendidikan dan pelatihan teknis, fungsional dan kepemimpinan Pemberdayaan dan pembinaan SDM di Kementerian Pekerjaan Umum Pengolahan Data Melakukan pengembangan dan analisa data Menyediakan layanan infrastruktur Pengembangan aplikasi dan website Pengembangan peta tematik dan literal



84

5.4.3 Keluaran (output) Fase Business Architecture Setelah dilakukan identifikasi proses bisnis, maka output atau keluaran yang didapatkan berupa functional decomposition diagram. Artifact: Functional Decomposition Diagram Tujuan dari functional decomposition diagram ini adalah untuk menggambarkan kemampuan organisasi yang relevan dalam pengembangan arsitektur TI. Dengan melihat kemampuan organisasi dari perspektif fungsional, memungkinkan pembangunan model arsitektur secara cepat tentang fungsi organisasi. Setelah functional decomposition diagram dibuat, maka ruang lingkup pembangunan arsitektur TI yang akan dibangun dapat ditentukan dengan mudah (The Open Group, 2009). Gambar 5.5 berikut ini menunjukkan artifact dari fase business architecture, yaitu functional decomposition diagram.

Fungsi Pendukung

Fungsi Utama Penelitian dan Pengembangan

SEKRETARIAT JENDERAL

INSPEKTORAT

Koordinasi kegiatan Kementerian Pekerjaan Umum

Penyiapan perumusan kebijakan

Perumusan kebijakan bidang penataan ruang

Perumusan kebijakan bidang sumber daya air

Perumusan kebijakan bidang bina marga

Perumusan kebijakan bidang cipta karya

Penyusunan kebijakan teknis

Penyusunan kebijakan teknis

Koordinasi dan penyusunan rencana dan program

Pelaksanaan pengawasan intern

Pelaksanaan kebijakan bidang penataan ruang

Pelaksanaan kebijakan bidang sumber daya air

Pelaksanaan kebijakan bidang bina marga

Pelaksanaan kebijakan bidang cipta karya

Pelaksanaan pembinaan konstruksi

Pelaksanaan penelitian dan pengembangan

Pembinaan dan pemberian dukungan administrasi

Pelaksanaan pengawasan

Penyusunan NSPK bidang penataan ruang

Penyusunan NSPK bidang sumber daya air

Penyusunan NSPK bidang bina marga

Penyusunan NSPK bidang cipta karya

Pemantauan, evaluasi dan pelaporan

Pemantauan, evaluasi dan pelaporan

Pembinaan dan penyelenggaraan organisasi

Penyusunan laporan

Pemberian Bimtek dan evaluasi




Pelaksanaan administrasi


Koordinasi dan penyusunan peraturan perundang-undangan


Pelaksanaan administrasi Dirjen




Penataan Ruang

Sumber Daya Air

Bina Marga

Cipta Karya

Pembinaan Konstruksi

Penyelenggaraan pengelolaan barang milik/kekayaan Negara Pelaksanaan tugas lain yang diberikan oleh Menteri Pekerjaan Umum

Gambar 5.5 Functional decomposition diagram



85

Dari Gambar 5.5, dapat dilihat bahwa fungsi organisasi dapat dibagi menjadi 2, yaitu fungsi utama dan fungsi pendukung. 1. Fungsi Utama a. Penataan Ruang, memiliki fungsi:  perumusan kebijakan di bidang penataan ruang sesuai dengan perundang-undangan;  pelaksanaan kebijakan di bidang penataan ruang sesuai dengan perundang-undangan

yang meliputi

perwujudan tata ruang

nasional, penyiapan rencana terpadu pengembangan infrastruktur jangka menengah, penyelenggaraan penataan ruang wilayah nasional, pulau, kawasan rawan bencana dan kawasan strategis nasional, serta penyiapan dukungan pelaksanaan koordinasi penataan ruang secara nasional;  penyusunan norma, standar, prosedur dan kriteria di bidang penataan ruang sesuai dengan peraturan perundang-undangan;  pemberian bimbingan teknis dan evaluasi di bidang penataan ruang sesuai dengan peraturan perundang-undangan; dan  pelaksanaan administrasi Direktorat Jenderal. b. Sumber Daya Air, memiliki fungsi:  perumusan kebijakan di bidang sumber daya air sesuai peraturan perundang-undangan yang meliputi konservasi, pendayagunaan dan pengendalian daya rusak pada sungai danau, waduk, bendungan, irigasi, air tanah, air baku, rawa, tambak dan pantai;  pelaksanaan kebijakan di bidang sumber daya air sesuai peraturan perundang-undangan yang meliputi penyusunan program dan anggaran, evaluasi kinerja pelaksanaan kebijakan, pengembangan sistem pembiayaan dan pola investasi, serta penanggulangan darurat dan rehabilitasi kerusakan infrastruktur sumber daya air akibat bencana alam;  penyusunan norma, standar, prosedur dan kriteria di bidang sumber daya air sesuai peraturan perundang-undangan; Universitas Indonesia


86  pemberian bimbingan teknis dan evaluasi di bidang sumber daya air sesuai peraturan perundang-undangan meliputi pembinaan hidrologi, perencanaan wilayah sungai, pembinaan pelaksanaan konstruksi, pembinaan aset sumber daya air, pembinaan operasi dan

pemeliharaan,

pengendalian

pemanfaatan,

pembinaan

kelembagaan pemberdayaan masyarakat; dan  pelaksanaan administrasi Direktorat Jenderal.

c. Bina Marga, memiliki fungsi:  perumusan kebijakan di bidang bina marga yang meliputi penyelenggaraan jalan nasional, provinsi, kabupaten, kota dan desa;  pelaksanaan kebijakan di bidang bina marga meliputi pengaturan, pembinaan, pembangunan dan pengawasan jalan nasional, provinsi, kabupaten, kota dan desa, serta penanggulangan darurat dan rehabilitasi kerusakan jalan akibat bencana alam;  penyusunan norma, standar, prosedur dan kriteria di bidang bina marga;  pemberian bimbingan teknis dan evaluasi di bidang bina marga meliputi pengaturan, pembinaan, pembangunan dan pengawasan jalan nasional, provinsi, kabupaten, kota dan desa; dan  pelaksanaan administrasi Direktorat Jenderal Bina Marga. d. Cipta Karya, memiliki fungsi:  perumusan kebijakan di bidang cipta karya sesuai dengan peraturan perundang-undangan yang meliputi permukiman perkotaan dan perdesaan, tata bangunan dan lingkungan, air minum, air limbah, persampahan dan drainase, serta bangunan gedung dan rumah negara;  pelaksanaan kebijakan di bidang cipta karya sesuai dengan peraturan perundang-undangan meliputi penyusunan program dan anggaran, evaluasi kinerja pelaksanaan kebijakan, pengembangan sistem pembiayaan dan pola investasi, serta fasilitasi kegiatan Universitas Indonesia


87

strategis nasional, termasuk penanggulangan bencana alam dan kerusuhan sosial;  penyusunan norma, standar, prosedur dan kriteria di bidang cipta karya sesuai dengan peraturan perundang-undangan;  pemberian bimbingan teknis dan evaluasi bidang cipta karya sesuai dengan peraturan perundang-undangan; dan  pelaksanaan administrasi Direktorat Jenderal. e. Pembinaan Konstruksi, memiliki fungsi:  penyusunan kebijakan teknis, rencana dan program pembinaan konstruksi dan investasi di bidang infrastruktur meliputi usaha dan kelembagaan, penyelenggaraan konstruksi, sumber daya investasi serta kompetensi dan pelatihan konstruksi;  pelaksanaan pembinaan konstruksi dan investasi di bidang infrastruktur meliputi usaha dan kelembagaan, penyelenggaraan konstruksi, sumber daya investasi serta kompetensi dan pelatihan konstruksi;  pemantauan, evaluasi dan pelaporan pelaksanaan pembinaan konstruksi dan investasi di bidang infrastruktur meliputi usaha dan kelembagaan, penyelenggaraan konstruksi, sumber daya investasi serta kompetensi dan pelatihan konstruksi; dan  pelaksanaan administrasi Badan Pembinaan Konstruksi.

f. Penelitian dan Pengembangan, memiliki fungsi:  penyusunan kebijakan teknis, rencana dan program penelitian dan pengembangan di bidang pekerjaan umum;  pelaksanaan penelitian dan pengembangan di bidang pekerjaan umum, meliputi perencanaan, pelaksanaan dan pengawasan penerapan dalam rangka alih teknologi serta perumusan standar, pedoman dan manual;  pemantauan, evaluasi dan pelaporan pelaksanaan penelitian dan pengembangan di bidang pekerjaan umum; dan  pelaksanaan administrasi Badan Penelitian dan Pengembangan Universitas Indonesia


88

2. Fungsi Pendukung a. Sekretariat Jenderal, memiliki fungsi:  koordinasi kegiatan Kementerian Pekerjaan Umum;  koordinasi dan penyusunan rencana dan program Kementerian Pekerjaan Umum;  pembinaan dan pemberian dukungan administrasi yang meliputi ketatausahaan, kepegawaian, keuangan, kerumahtanggaan, arsip dan dokumentasi Kementerian Pekerjaan Umum;  pembinaan dan penyelenggaraan organisasi dan tata laksana, kerja sama dan hubungan masyarakat;  koordinasi dan penyusunan peraturan perundang – undangan dan bantuan hukum;  penyelenggaraan pengelolaan barang milik / kekayaan negara; dan  pelaksanaan tugas lain yang diberikan oleh Menteri Pekerjaan Umum. b. Inspektorat, memiliki fungsi:  penyiapan perumusan kebijakan pengawasan intern di lingkungan Kementerian Pekerjaan Umum;  pelaksanaan pengawasan intern di lingkungan Kementerian Pekerjaan Umum terhadap kinerja dan keuangan melalui audit, reviu, evaluasi, pemantauan dan kegiatan pengawasan lainnya;  pelaksanaan pengawasan untuk tujuan tertentu atas penugasan Menteri Pekerjaan Umum;  penyusunan laporan hasil pengawasan di lingkungan Kementerian Pekerjaan Umum; dan  pelaksanaan administrasi Inspektorat Jenderal.



89

5.5

Tahap 8. Information System Architecture

Fase Information Systems Architecture bertujuan untuk mengembangkan arsitektur target untuk domain data dan domain aplikasi. Pada arsitektur aplikasi, menentukan aplikasi untuk memproses data dan mendukung bisnis. Masukan dari arsitektur sistem informasi berupa : (1) prinsip aplikasi, (2) prinsip data, (3) output dari business architecture. Sedangkan keluaran dari fase arsitektur aplikasi berupa: (1) arsitektur aplikasi, (2) arsitektur data dan (3) analisis kesenjangan. Gambar 5.6 memperlihatkan mengenai input, steps dan output dari fase information system architecture.

Input: 1. Prinsip aplikasi 2. Prinsip data 3. Output business architecture

Steps: Identifikasi arsitektur aplikasi dan data saat ini dan usulan serta membuat analisis kesenjangan

Output: Artifact : - Arsitektur aplikasi: (Arsitektur aplikasi saat ini, analisis arsitektur aplikasi, arsitektur aplikasi dan data usulan -Arsitektur data - Analisis Kesenjangan

Gambar 5.6 Input, steps, output fase information system architecture 5.5.1 Masukan (input) Fase Information System Architecture Input atau masukan dari fase ini adalah prinsip aplikasi, prinsip data dan output dari fase business architecture. Prinsip aplikasi dan prinsip data menjadi acuan dalam pembangunan arsitektur sistem informasi atau information system architecture.



90

5.5.2 Proses (steps) pada Fase Information System Architecture Tahapan dari fase arsitektur sistem informasi (information system architecture) berupa identifikasi arsitektur aplikasi dan arsitektur data saat ini dan usulan serta membuat analisis kesenjangan. 5.5.3 Keluaran (output) Fase Information System Architecture Output atau keluaran dari fase ini dilihat dari 2 aspek arsitektur, yaitu arsitektur aplikasi dan arsitektur data. 5.5.3.1 Arsitektur Aplikasi (as is) Tujuan dari pembuatan arsitektur aplikasi yaitu mendefinisikan sistem aplikasi yang dibutuhkan untuk memproses data dan mendukung proses bisnis. Perancangan arsitektur aplikasi terdiri dari arsitektur aplikasi saat ini dan analisis aplikasi. Sebagian sistem informasi digunakan oleh semua atau sebagian besar unit kerja seperti SIMKA, Renja, RKAKL, e-procurement, e-monitoring, SIMAK-BMN. Sebagian lainnya hanya digunakan oleh unit kerja bersangkutan. Berikut ini, sistem informasi dibagi berdasarkan pemilik sistem informasi tersebut. Sebagian sistem informasi sebenarnya milik pihak luar seperti milik Kementerian Keuangan, Bappenas tetapi unit kerja yang mengkoordinasikan penggunaan aplikasi tersebut dianggap sebagai pemilik atau pihak yang bertanggung jawab atas sistem informasi tersebut. Tabel 5.20 sampai Tabel 2.28 berisikan sistem informasi saat ini pada masingmasing satminkal.



91 a. Pusdata Tabel 5.20 Sistem informasi (as is) pada Pusat Pengolahan Data (Pusdata) No 1.

Kode Aplikasi SI_1

Nama SIGI

Deskripsi Deskripsi Fungsional: Aplikasi berisi: a. Sebaran infrastruktur PU saat ini b. monitoring paket pekerjaan berbasis spasial c. rencana tata ruang d. data asset PU

Status Aktif

maupun di SIGI

Aplikasi menggunakan ArcGIS

SI_2

Geotagging

Deskripsi Fungsional: a. Data yang digunakan diambil dari emonitoring (URL per project dimasukkan secara manual) b. Data yang digunakan diambil juga dari eprocurement Arsitektur Teknis:

- Memanfaatkan Google Earth - Diletakkan di server e-proc

 Dikembangkan dan dikelola oleh PAD  Data paket terkait program rencana ada di geotagging  Ke depannya diharap menjadi media remote monitoring

Arsitektur Teknis:

2.

Keterangan Tambahan

Aktif

project  Seharusnya peta-peta spasial ini bisa digabungkan datanya antara SIGI, geotagging maupun Aplikasi Loket Pelayanan Peta. Kalaupun digabung, fungsi koordinasi atau manajemen aplikasi ada di PAD, namun konten diisi oleh Badan atau Satminkal lain, misal dasar peta dari Balai Pemetaan Tematik, Data Statistik dari Balai Informasi Literal dsb.  Dikembangkan dan dikelola oleh PAD  Sedang dikembangkan(disempurnakan) menjadi ereporting, dengan tambahan pemanfaatan data dari aplikasi e-monitoring / e-procurement secara otomatis  Seharusnya peta-peta spasial ini bisa digabungkan datanya antara SIGI, Geotagging maupun Aplikasi Loket Pelayanan Peta. Kalaupun digabung, fungsi koordinasi/manajemen aplikasi ada di PAD, namun konten diisi oleh Badan atau Satminkal lain, misal dasar peta dari Balai Pemetaan Tematik, Data Statistik dari Balai Informasi Literal dsb.



92 Tabel 5.20 Sistem informasi (as is) pada Pusat Pengolahan Data (Pusdata) (lanjutan) No 3.

Kode Aplikasi SI_3

Nama SIM Komunikasi Data Kementerian PU

Deskripsi Deskripsi Fungsional: a. Digunakan untuk input data dasar b. Ke depannya digunakan untuk input data aset PU c. Dilengkapi dengan fitur upload foto dan video

Status Dalam pengemba ngan

Keterangan Tambahan Saat ini belum ada server-nya, harapannya disediakan server khusus untuk aplikasi ini.

Arsitektur Teknis:

a. Memanfaatkan Google Earth b. Menumpang di server e-proc 4.

SI_4

PU.Net

Deskripsi Fungsional:

Aktif

Berisi seluruh data ke-PU-an

dan memudahkan penelusuran

Arsitektur Teknis:

5.

SI_5

e-Procurement

Platform : PHP Deskripsi Fungsional: Digunakan untuk memfasilitasi kegiatan tender atau pengadaan Arsitektur Teknis: Platform : PHP

 Digunakan oleh seluruh Satminkal  Harapannya struktur menu dan tampilan lebih futuristic

Aktif

 Digunakan seluruh Satminkal  e-Proc belum terintegrasi dengan e-Monitoring  e-Proc diisi oleh setiap Satminkal setiap kali ada proyek pengadaan yang memenuhi syarat masuk e-Proc



93 Tabel 5.20 Sistem informasi (as is) pada Pusat Pengolahan Data (Pusdata) (lanjutan) No 6.

Kode Aplikasi SI_6

Nama LPP (Loket Pelayanan Peta)

Deskripsi Deskripsi Fungsional: Fitur atau icon yang ada pada LPP ada 5, yaitu: a. Peta infrastruktur Indonesia (dipakai database-nya) b. Peta Data Bencana c. Peta Kabupaten/Kota : dasar peta dari BIG (peta rupa bumi), di dalamnya ditambahkan juga peta Land Use dan infrastruktur d. Citra Satelit untuk pemantauan projectproject strategis atau besar e. Peta tematik lainnya:peta yang diproduksi oleh satminkal, lebih spesifik. Misalnya: Peta koridor ekonomi (dari Pusra), Peta sebaran Buldozer, Peta air minum MDG’s

Status Dalam pengemba ngan

Keterangan Tambahan

 Dikembangkan oleh Balai Pemetaan Tematik  Ada harapan aplikasi ini terintegrasi dengan Balai Informasi Literal (BIL).

Arsitektur Teknis:

7.

SI_7

Data proyek strategis

Platform:Chameleon (web based) dan untuk database, direncanakan menggunakan oracle untuk enterprise, tetapi sementara sedang dicoba menggunakan SQL Deskripsi Fungsional: Berfungsi menampilkan proyek-proyek strategis dari semua Satminkal berdasarkan eprocurement. Arsitektur Teknis: Aplikasi berbasis web dengan platform PHP

Aktif

Aplikasi dikelola oleh Balai Informasi Literal Pusdata Kementerian PU



94 b. Sekretariat Jenderal dan Pusat-Pusat di Bawah Koordinasi Sekretariat Jenderal (di luar Pusdata) Tabel 5.21 Sistem informasi (as is) pada Sekretariat Jenderal No 1.

2.

3.

Kode Aplikasi SI_8

Nama Renja

Deskripsi Deskripsi Fungsional: Aplikasi ini berfungsi untuk memasukkan (input) Usulan Rencana Kerja Anggaran Arsitektur Teknis: Desktop system menggunakan VB

Status Aktif

SI_9

RKAKL

Aktif Deskripsi Fungsional: Aplikasi ini berfungsi mendata rencana kerja yang sudah diperiksa oleh Kemenkeu. Aplikasi ini akan menghasilkan DIPA Arsitektur Teknis: Desktop system menggunakan VB

SI_10

e-Monitoring (offline)

Aktif Deskripsi Fungsional: Diperuntukkan untuk entri data status capaian proyek bersama detil realisasi anggarannya Arsitektur Teknis: Desktop system menggunakan VB.net dan database Ms.Access

Keterangan Tambahan

 SI Renja dibuat oleh Bappenas  Digunakan di semua Satminkal dan dikoordinasi oleh Biro PKLN  SI Renja akan diganti dengan SPAN oleh Kementerian Keuangan yang berbasis web  Harapannya, disediakan aplikasi yang memungkinkan unit terkait juga bisa mengakses renjanya minimal view.  SI RKAKL dibuat oleh Kementerian Keuangan  Digunakan di semua Satminkal dan dikoordinasi oleh Biro PKLN  SI RKAKL akan diganti dengan SPAN oleh Kementerian Keuangan yang berbasis web  Harapannya, disediakan aplikasi yang memungkinkan unit terkait juga bisa mengakses RKA nya minimal view.  Digunakan di setiap Satminkal dan dikoordinasi oleh Biro PKLN  Harapannya sistem ini langsung integrasi dengan emonitoring online dengan catatan bandwidth jaringan memadai.



95 Tabel 5.21 Sistem informasi (as is) pada Sekretariat Jenderal (lanjutan) No 4.

Kode Aplikasi SI_11

Nama e-Monitoring (online)

Deskripsi Deskripsi Fungsional:

a. Diperuntukkan untuk meng-upload data yang sudah di entry oleh e-Monitoring offline. Setiap file yang di-upload < 200 Kb, rata-rata berukuran 70-80 Kb b. Digunakan juga untuk menampilkan status proyek di setiap Satminkal

Status Aktif

Keterangan Tambahan

 Digunakan di setiap Satminkal dan dikoordinasi oleh Biro PKLN  Harapannya, sistem ini langsung integrasi dengan fasilitas input-nya dengan dengan catatan bandwidth jaringan memadai.  Sistem ke depan sebaiknya terintegrasi dengan eprocurement.

Arsitektur Teknis: Sistem berbasis web menggunakan PHP dan database Ms.Access



96 c. Direktorat Jenderal Penataan Ruang Tabel 5.22 Sistem informasi (as is) pada Dirjen Penataan Ruang No 1.

2.

Kode Aplikasi SI_12

SI_13

Nama

Deskripsi

Status

Keterangan Tambahan

Database RTRW

Dalam Deskripsi Fungsional: Aplikasi yang menyimpan dan pengembangan menampilkan rencana tata ruang wilayah dalam bentuk visual Arsitektur Teknis: Aplikasi: PHP Aplikasi Dalam Deskripsi Fungsional: Informasi Aplikasi yang menyimpan dan pengembangan Audio Visual menampilkan rencana tata ruang wilayah DJPR dalam bentuk audio visual Arsitektur Teknis: Aplikasi: PHP



97 d. Direktorat Jenderal Sumber Daya Air Tabel 5.23 Sistem informasi (as is) pada Dirjen Sumber Daya Air No 1.

Kode Nama Aplikasi SI_14 PDSDA (Pengolah Data Sumber Daya Air)

Deskripsi Deskripsi Fungsional: PDSDA mengelola: a. Database daerah aliran sungai b. Mencakup sungai, danau, waduk, irigasi, hidrologi dll

Status Aktif

Arsitektur Teknis:

a. Menggunakan Quantum GIS b. Stand alone, dengan platform pengembangan Delphi dan db firebird 2.

SI_15

PAI (Pengelolaan Aset Irigasi)

Aktif Deskripsi Fungsional: PAI mengelola: a. Database daerah dan skema jaringan irigasi b. Mencakup kondisi, fungsi, sisa umur, kekritisan, level of service prioritas kegiatan pengelolaan aset : rehabilitasi, operasi, alokasi air Arsitektur Teknis:

a. Menggunakan Quantum GIS b. Stand alone, dengan platform pengembangan Delphi dan db firebird 3.

SI_16

Web SDA

Deskripsi Fungsional:

Aktif

Menampilkan informasi ke-SDA-an

Keterangan Tambahan

 Aplikasi PDSDA dan PAI dapat diakses langsung dari daerah (berbasis web), tetapi untuk input data belum realtime. Input data dilakukan melalui desktop system berbasis Delphi, untuk selanjutnya database di-upload melalui aplikasi yang web based.  Aplikasi didukung oleh EIS walaupun masih terbatas.  Aplikasi PDSDA dan PAI dapat diakses langsung dari daerah (berbasis web), tetapi untuk input data belum realtime. Input data dilakukan melalui desktop system berbasis Delphi, untuk selanjutnya database di-upload melalui aplikasi yang web based.  Aplikasi didukung oleh EIS walaupun masih terbatas. Web SDA diharapkan lebih dinamis dan informatif.

Arsitektur Teknis: Berbasis web dengan platform PHP



98 e. Direktorat Jenderal Bina Marga Tabel 5.24 Sistem informasi (as is) pada Dirjen Bina Marga No 1.

Kode Aplikasi SI_17

Nama

Deskripsi

Status

Keterangan Tambahan

IRMS (Indonesian Integrated Deskripsi Fungsional: Aktif Road Management System) Aplikasi yang digunakan untuk membantu perencana jalan dalam menghimpun data dan merencanakan program pemeliharaan jalan Nasional dan Provinsi. Selain itu, aplikasi ini juga dirancang untuk menjadi alat pemantau kondisi. IRMS terdiri dari beberapa modul, yaitu: a. Sistem pangkalan data b. Sistem perencanaan pemeliharaan jalan c. Sistem pemrograman pemeliharaan jalan d. Sistem penganggaran pemeliharaan jalan Arsitektur Teknis: Aplikasi : Power Builder 9

2.

SI_18

Database: Sybase SIMPAJATAN Aktif Deskripsi Fungsional: (Sistem Informasi Manajemen Sistem yang digunakan untuk melakukan pemantauan Penanganan Jalan dan Jembatan) kemajuan teknis penanganan jalan dan jembatan tiap dua minggu sekali. Arsitektur Teknis: Aplikasi: PHP



99 Tabel 5.24 Sistem informasi (as is) pada Dirjen Bina Marga (lanjutan) No 3.

4.

5.

Kode Aplikasi SI_19

Nama SIPP (Sistem Pemantauan Proyek)

SI_20

Leger Jalan

SI_21

POK (Petunjuk Kegiatan)

Deskripsi Informasi Deskripsi Fungsional: Sistem yang digunakan melakukan pemantauan, pengawasan dan pengendalian terhadap proyek-proyek di Bina Marga. Ruang lingkup SIPP mulai DIP, prakontrak, pelaksanaan kontrak masing-masing paket, rencana pekerjaan yang ada sampai dengan realisasi keuangannya. SIPP offline digunakan untuk memasukkan dan mengirimkan data ke pusat. Sedangkan SIPP online digunakan untuk menampilkan laporan-laporan berdasarkan data yang diterima dari SIPP offline Arsitektur Teknis: Aplikasi : SIPP Online PHP Deskripsi Fungsional: Sistem Informasi yang memuat informasi mengenai perkembangan suatu ruas jalan. Arsitektur Teknis: Operasional Deskripsi Fungsional: Aplikasi yang digunakan untuk membuat Laporan POK yang terdiri dari Lembar Kontrol, Struktur, Lingkup, Jadwal Pelaksanaan, Rincian Kegiatan dan Summary Rincian Pembahasan Kegiatan. Arsitektur Teknis: Aplikasi: VisualFoxPro Database : dBase

Status

Keterangan Tambahan

Aktif

Dalam pengemban gan

-

Aktif



100 f. Direktorat Jenderal Cipta Karya Tabel 5.25 Sistem informasi (as is) pada Dirjen Cipta Karya No 1.

2.

3.

Kode Aplikasi SI_22

SI_23

SI_24

Nama

Deskripsi

Sistem Informasi Bidang Deskripsi Fungsional: Pengembangan Pemukiman Aplikasi yang dapat digunakan sebagai alat bantu pengambilan keputusan untuk meningkatkan kelengkapan norma, standar, pedoman dan manual dalam menunjang penyelenggaraan infrastruktur dan permukiman bagi masyarakat. Arsitektur Teknis: SIM Prasarana dan Sarana Deskripsi Fungsional: Agropolitan Aplikasi yang dapat membantu pengembangan sarana dan prasarana agropolitan dalam rangka pengembangan ekonomi lokal. Arsitektur Teknis: Sistem Informasi Manajemen Deskripsi Fungsional: Evaluasi Kinerja (SIMEKA) Sistem informasi yang digunakan untuk membantu mengevaluasi kinerja. Evaluasi kinerja tersebut meliputi evaluasi rencana, kebijakan, program dan kegiatan. SIMEKA menampilkan data yang di-entry dalam bentuk tabel dan grafik (trend line, cross-section dan combination) yang dijadikan sebagai bahan analisis evaluasi kinerja oleh tenaga ahli. Arsitektur Teknis: Aplikasi: PHP

Status

Keterangan Tambahan

Aktif

Dalam pengembangan

Aktif



101 Tabel 5.25 Sistem informasi (as is) pada Dirjen Cipta Karya (lanjutan) No 4.

5.

6.

Kode Aplikasi SI_25

SI_26

SI_27

Nama

Deskripsi

Sistem Informasi PPIP Deskripsi Fungsional: (Pembinaan Pembangunan Sistem informasi yang digunakan untuk memetakan kemiskinan Infrastruktur Pedesaan ) infrastruktur pedesaan secara nasional. Arsitektur Teknis: Sistem Informasi Program Deskripsi Fungsional: Pemberdayaan Masyarakat Sistem informasi yang digunakan untuk membantu integrasi program pemberdayaan masyarakat di Ciptakarya. Program pemberdayaan masyarakat dibagi dalam dua bagian besar, yaitu pemberdayaan masyarakat perkotaan (NUSSP dan P2KP) dan pedesaan (RIS PNPM, PAMSIMAS dan PISEW). Arsitektur Teknis: Sistem Informasi Manajemen Deskripsi Fungsional: SPAM IKK Sistem Informasi yang digunakan untuk proses pengelolaan air minum, mulai dari perencanaan, pelaksanaan, monitoring dan evaluasi penyediaan air minum di setiap kawasan. Arsitektur Teknis: Aplikasi : PHP

Status

Keterangan Tambahan

Aktif

Dalam pengembangan

Dalam pengembangan



102 Tabel 5.25 Sistem informasi (as is) pada Dirjen Cipta Karya (lanjutan) No 7.

Kode Aplikasi SI_28

Nama SIM PNPM Mandiri

Deskripsi

Status

Keterangan Tambahan

Aktif Deskripsi Fungsional: SIM PNPM Mandiri merupakan SIM yang digunakan untuk pengelolaan program PNPM mandiri dari Bappenas yang meliputi usulan kegiatan hasil perencanaan masyarakat, realisasi kegiatan, realisasi dana, organisasi masyarakat yang terbentuk dan lain sebagainya. SIM ini dilengkapi dengan Geographic Information System (GIS) yang memungkinkan pengguna untuk melakukan analisa spasial Arsitektur Teknis: Aplikasi : Java



103 g. Badan Pembinaan Konstruksi Tabel 5.26 Sistem informasi (as is) pada Badan Pembinaan Konstruksi No 1.

Kode Aplikasi SI_29

Nama SIP JaKI (Sistem Informasi Pembinaan Jasa Konstruksi)

Deskripsi Deskripsi Fungsional: Berisi: a. Informasi Pembinaan b. Data Tim Pembina se-NKRI c. Permen tentang SPM d. Daftar izin usaha Jasa Konstruksi

Status Dalam pengembangan

Keterangan Tambahan

 Dikembangkan dan dikelola oleh Pusat 1  Sistem yang ada di BP Konstruksi dapat diintegrasikan seluruhnya.

Arsitektur Teknis:

2.

SI_30

SIM JaKon

Platform pengembangan: PHP & MySQL Aktif Deskripsi Fungsional: Aplikasi ini mengelola: a. Data sertifikat tenaga ahli b. Data sertifikat badan usaha atau lembaga Arsitektur Teknis: Platform pengembangan:

a. Client : VB.Net b. Website : PHP c. Database : MySQL

 Dikembangkan dan dikelola oleh Pusat 1  Saat ini SIM Jakon masih dikelola oleh PPUK (Pusat 1), tapi kedepannya SIM Jakon akan dikelola oleh LPJK  Harapannya SIM Jakon terintegrasi dengan eProcurement karena untuk proses tender, data sertifikat tenaga ahli dan badan usaha ada di SIM Jakon  Sistem yang ada di BP Konstruksi dapat diintegrasikan seluruhnya.



104 Tabel 5.26 Sistem informasi (as is) pada Badan Pembinaan Konstruksi (lanjutan) No 3.

4.

Kode Aplikasi SI_31

SI_32

Nama Web Konstruksi

Deskripsi

Status

BP Deskripsi Fungsional: Aktif Aplikasi ini menggambarkan informasi seputar BP Konstruksi.

Arsitektur Teknis: Platform pengembangan: PHP & MySQL Web Pusat Deskripsi Fungsional: Aktif 1(PPUK) Aplikasi ini menggambarkan informasi seputar PPUK Arsitektur Teknis: Platform pengembangan: PHP & MySQL

Keterangan Tambahan Sistem yang ada di BP Konstruksi dapat diintegrasikan seluruhnya.

Sistem yang ada di BP Konstruksi dapat diintegrasikan seluruhnya.



105 h. Badan Penelitian dan Pengembangan Tabel 5.27 Sistem informasi (as is) pada Badan Penelitian dan Pengembangan No 1.

2.

3.

Kode Aplikasi SI_33

SI_34

SI_35

Nama

Deskripsi

Status

Sistem Tata Deskripsi Fungsional: Aktif Naskah Dinas Aplikasi yang digunakan untuk persuratan Elektronik elektronis, pengarsipan elektronis, penelusuran surat dan disposisi dan agenda harian. Arsitektur Teknis: Aplikasi: PHP Aplikasi info Deskripsi Fungsional: Aktif standar Info untuk standar yang dikeluarkan sebagai hasil kajian pusat di daerah. Aplikasi Aktif Deskripsi Fungsional: Agenda Dukungan manajemen dan dukungan teknis kegiatan lainnya Badan Litbang (Penjadwalan pejabat agenda pejabat). Balitbang

Keterangan Tambahan Diharapkan dapat diimplementasikan berupa : paperless office dan digital signature.

Rencana akan ada pengembangan database untuk jurnal, paper dan list atau daftar tenaga ahli di tiap balai secara online. Sebaiknya aplikasi ini dapat digunakan di seluruh PU agar bisa terintegrasi.



106 Tabel 5.27 Sistem informasi (as is) pada Badan Penelitian dan Pengembangan (lanjutan) No 4.

5.

Kode Aplikasi SI_36

SI_37

Nama Sistem Akuntansi Penggunaan Anggaran (SAKPA)

Deskripsi

Status

Aktif Deskripsi Fungsional: Aplikasi yang digunakan untuk mengolah data (Penyusunan laporan) dalam Sistem Akuntansi Kuasa Pengguna Anggaran. Laporan yang dihasilkan oleh SAKPA antara lain LRA Pendapatan & LRA Belanja, LRA Pengembalian Pendapatan & Pengembalian Belanja, Neraca Percobaan & Neraca, Laporan Realisasi Anggaran.

Arsitektur Teknis: Aplikasi : VisualFoxPro Database: MySQL SIMAK Aktif Deskripsi Fungsional: BMN(Sistem Aplikasi yang digunakan untuk membantu Informasi mencatat, membukukan dan Manajemen mempertanggungjawabkan data Barang AkuntansiMilik Negara (BMN). Barang Milik Negara Barang Milik yang dimaksud antara lain Aset Tetap, Aset Negara) Bersejarah, Aset tetap yang dihentikan dari penggunaan aktif, Aset tidak berwujud, Ekstrakomptabel. Arsitektur Teknis: Aplikasi: VisualFoxPro Database : MySQL

Keterangan Tambahan Sistem dibuat oleh Direktorat Sistem Perbendaharaan Ditjen Perbendaharaan. Aplikasi ini akan diganti oleh SPAN (Sistem Perbendaharaan dan Anggaran Negara).

Sistem dibuat oleh Direktorat Sistem Perbendaharaan Ditjen Perbendaharaan



107 i. Inspektorat Jenderal Tabel 5.28 Sistem informasi (as is) pada Inspektorat Jenderal No 1.

Kode Aplikasi SI_38

Nama Sistem Informasi Manajemen Pengawasan

Deskripsi

Status

Aktif Deskripsi Fungsional: Sistem Informasi yang digunakan untuk mengelola laporan hasil pemeriksaan (LHP) dan tindak lanjut pemeriksaan (temuan) termasuk LHP dari BPKP. Modul yang sudah berjalan yaitu setting Satker, Surat Perintah Tugas(SPT), LHP dan LHP BPKP. Sedangkan modul yang akan dikembangkan yaitu Pengaduan Masyarakat dan Pelaporan. Arsitektur Teknis: Aplikasi: PHP Database : MySQL

Keterangan Tambahan Sistem Informasi ini dipergunakan oleh Bagian Evaluasi Hasil Pengawasan. Inspektorat dab Wilayah dan Khusus belum memiliki aplikasi yang digunakan untuk menjalankan fungsinya dari mulai perencanaan, supervise, pengumpulan dan pengujian bukti, pengembangan temuan, dokumentasi.



108

Artifact 1 : Landscape aplikasi (as is) Landscape aplikasi merupakan diagram yang menunjukkan pemetaan aplikasi pada Satminkal dilihat dari 2 area berdasarkan value chain yang dibuat sebelumnya, yaitu aplikasi pada aktivitas utama dan aplikasi pada aktivitas pendukung. Gambar 5.7 merupakan landscape aplikasi dari arsitektur aplikasi saat ini (as is). SIM PNPM Mandiri

POK Leger Jalan

Aplikasi Informasi Audio Visual DJPR Database RTRW

SIPP

PAI

SIMPAJATAN

PDSDA

IRMS

Sumber Daya Air

Sekretariat Jenderal

Inspektorat

SIMAK-BMN Sisfo PPM

Web Pusat 1

PPIP

Web SDA

Penataan Ruang

SPAM IKK

Web BP Konstruksi

SIMEKA

Bina Marga

SIM Agropolitan Sisfo Pengemb. Pemukiman

SIM JaKon SIP JaKI

Cipta Karya

Aplikasi pada Aktivitas Utama Aplikasi pada Aktivitas Pendukung

Renja


SAKPA Aplikasi Agenda Aplikasi Info Standar Sistem TNDE

Balitbang

SIM Pengawasan

RKA-KL e-Monitoring (offline) e-Monitoring (online)

Gambar 5.7 Landscape aplikasi as is Dari Gambar 5.7 di atas memperlihatkan bahwa distribusi aplikasi pada Satminkal dibagi menjadi 2 area, yaitu aplikasi pada aktivitas utama dan aplikasi pada aktivitas pendukung. Pada area aplikasi pada proses bisnis utama terdapat 26 aplikasi inti sedangkan pada area aplikasi pada proses bisnis pendukung terdapat 5 aplikasi. Artifact 2 : Application and User Location Diagram (as is) Application and User Location Diagram menunjukkan distribusi aplikasi dari sisi geografis. Diagram ini digunakan untuk menggambarkan tentang aplikasi yang dipakai oleh user atau pengguna; distribusi di mana aplikasi dieksekusi dan atau dipakai dalam thin client scenarios; distribusi di mana aplikasi dibangun, diuji coba dan dikembangkan dan lain-lain (The Open Group, 2009).



109 Gambar 5.8 merupakan application and user location diagram dari arsitektur aplikasi saat ini. Cipta Karya

Penataan Ruang SI_12

SI_13

SI_22

SI_23

SI_24

Sekretariat Jenderal Sumber Daya Air

SI_25

SI_26

SI_28

SI_27

Inspektorat SI_8

SI_9

SI_10 SI_38

SI_14

Balai SDA

SI_11 SI_15

SI_16 Balitbang

Bina Marga

SI_17

SI_18

SI_20

SI_21

Pembinaan Konstruksi SI_29

SI_30

SI_31

SI_32

SI_19

Pusdata

SI_1

SI_2

SI_3

SI_4 SI_5

SI_7

SI_6

SI_33

SI_34

SI_36

SI_37

SI_35

Gambar 5.8 Application and user location diagram dari aplikasi saat ini



110

Dari Gambar 5.8 dapat dilihat bahwa: 

Aplikasi e-Monitoring (online) dengan kode aplikasi SI_11 merupakan aplikasi yang berada di Sekretariat Jenderal (Biro PKLN). Aplikasi ini berbasis web dan diakses oleh seluruh Satminkal yang digunakan untuk meng-upload data yang sudah di-entry oleh e-Monitoring offline. Skema keterhubungan yang menunjukkan arah akses dari Satminkal ke Sekretariat Jenderal ditunjukkan dengan garis berwarna hitam.



Aplikasi PU.Net dan e-Procurement dengan kode aplikasi SI_4 dan SI_5 merupakan aplikasi yang berada di Pusdata. Aplikasi ini berbasis web dan diakses oleh Satminkal. Web PU.Net berisi seluruh data ke-PU-an sedangkan aplikasi e-Procurement digunakan untuk memfasilitasi kegiatan tender atau pengadaan. Skema keterhubungan yang menunjukkan arah akses dari Satminkal ke Pusdata ditunjukkan dengan garis berwarna hijau.



Aplikasi PDSDA (Pengolah Data Sumber Daya Air) dengan kode aplikasi SI_14 dan PAI (Pengelolaan Aset Irigasi) dengan kode aplikasi SI_15 merupakan aplikasi yang berada di Direktorat Jenderal Sumber Daya Air. Kedua aplikasi ini dapat diakses langsung dari daerah atau Balai SDA.



111

5.5.3.2 Analisis Arsitektur Aplikasi Saat Ini Setelah melakukan identifikasi terhadap arsitektur aplikasi saat ini, maka selanjutnya melakukan analisis terhadap arsitektur tersebut. Analisis ini meliputi dua sudut pandang, yaitu analisis level Satminkal dan analisis level Pusdata. Analisis dukungan aplikasi atau sistem informasi pada level Satminkal dapat dilihat pada Tabel 5.29 berikut ini: Analisis Level Satminkal Tabel 5.29 Analisis dukungan aplikasi / SI level Satminkal No

Unit Kerja

1.

Sekretariat Biro Jenderal dan Kepegawaian Pusat-pusat di bawah koordinasinya

Sistem Analisis Dukungan Informasi Saat Terhadap Proses Ini Bisnis 1. Sistem  Dukungan atas Informasi proses bisnis Manajemen transaksional: Kepegawaian a. Pengelolaan (SIMKA) data CPNS, 2. Sistem pegawai Penerimaan b. Pengelolaan CPNS data mutasi 3. Sistem pegawai Pencetakan c. Pengelolaan Berkas data pejabat 4. Administrasi d. Administrasi CPNS tanda 5. Website Biro penghargaan Kepegawaian e. Administrasi dan Ortala Penegakan disiplin  Dukungan atas proses bisnis analitikal: Penyusunan laporan rutin.



112

Tabel 5.29 Analisis dukungan aplikasi / SI level Satminkal (lanjutan) No

Unit Kerja Biro Keuangan

Biro Umum

Sistem Informasi Saat Ini 1. Sistem Informasi SPM (Surat Perintah Membayar) 2. Sistem Akuntansi Penggunaan Anggaran (SAKPA). 3. Aplikasi Gaji PNS 4. SIMAK BMN (Sistem Informasi Manajemen AkuntansiBarang Milik Negara) 1. Sistem Tata Naskah Dinas Elektronik 2. Sistem Kearsipan Elektronik (SKE)

Analisis Dukungan Terhadap Proses Bisnis  Dukungan atas proses bisnis transaksional a. Pelaksanaan administrasi keuangan b. Pelaksanaan anggaran c. Administrasi barang milik Negara  Dukungan atas proses bisnis analitikal Penyusunan laporan keuangan

 Dukungan atas proses bisnis transaksional: Pengelolaan ketatausahaan Kementerian: tata naskah dinas, kearsipan.  Dukungan atas proses bisnis analitikal: Belum ada



113


Unit Kerja Biro Perencanaan dan Kerjasama Luar Negeri

Biro Hukum

Sistem Informasi Saat Ini 1. Renja 2. RKA-KL 3. e-Monitoring (offline) 4. e-Monitoring (online)





1. Web Biro  Hukum 2. Web Peraturan Perundangan 3. Web Perpustakaan 4. Web untuk pendataan Rumah Negara 5. e-Forum



Pusat Kajian Aplikasi  Strategis persuratan internal



Analisis Dukungan Terhadap Proses Bisnis Dukungan atas proses bisnis transaksional: a. Program dan anggaran b. Pemantauan dan evaluasi Dukungan atas proses bisnis analitikal: Sistem yang ada sebagian besar belum memenuhi dukungan terhadap EIS bagi pimpinan. eMonitoring sudah mendukung EIS tetapi data yang ditampilkan sering tidak sesuai dengan realisasi. Dukungan atas proses bisnis transaksional: a. Agregator beberapa web di Biro Hukum b. Penyimpanan Naskah Akademis c. Penyimpanan Peraturan Perundangan d. Penyimpanan daftar buku-buku e. Penyimpanan daftar penanganan masalah Dukungan atas proses bisnis analitikal: Belum ada Dukungan atas proses bisnis transaksional: Kajian dan evaluasi pelaksanaan kebijakan dan strategi Dukungan atas proses bisnis analitikal: Belum ada



114


Unit Kerja Pusat Pendidikan dan Latihan

Sistem Informasi Saat Ini Sistem Informasi Diklat





1. Sistem  Informasi Pengolahan Informasi (Database Publikasi dan  Dokumentasi)  2. Sistem Informasi Pengolahan Informasi (Database Laporan Pimpinan) 3. Sistem Kepegawaian 4. Database Pustaka Pusat SIMAK Mendukung proses akuntansi Pengelolaan BMN(Sistem sesuai standar yang diatur Barang Milik Informasi oleh Kementerian Keuangan. Negara Manajemen Akuntansi-Barang Milik Negara) Inspektorat Jenderal Sistem Informasi  Dukungan atas proses Evaluasi Laporan bisnis transaksional: Hasil Evaluasi Hasil Pengawasan Pengawasan  Dukungan atas proses bisnis analitikal: Belum ada Pusat Komunikasi Publik

2.

Analisis Dukungan Terhadap Proses Bisnis Dukungan atas proses bisnis transaksional: Pemasukan data penyelenggaraan Diklat (Peserta, Widya Iswara, jadwal) Dukungan atas proses bisnis analitikal: Belum ada Dukungan atas proses bisnis transaksional: a. Kepegawaian b. Kepustakaan Dukungan atas proses bisnis analitikal: Belum ada



115

Tabel 5.29 Analisis dukungan aplikasi / SI level Satminkal (lanjutan) No 3.

4.

Unit Kerja Direktorat Jenderal Ruang

Tata


Sistem Informasi Analisis Dukungan Terhadap Saat Ini Proses Bisnis 1. Aplikasi  Dukungan atas proses bisnis Database transaksional: RTRW a. Pengelolaan data dan 2. Aplikasi informasi Informasi penyelenggaraan tata Audio Visual ruang. DJPR b. Sosialisasi 3. Website  Dukungan atas proses bisnis Penataan Ruang analitikal: Belum ada 1. PDSDA  Dukungan atas proses bisnis (Pengolah Data transaksional: Sumber Daya a. Bina program Air) b. Penatagunaan SDA 2. PAI c. Sungai dan pantai (Pengelolaan d. Irigasi dan sawah Aset Irigasi) e. Operasi dan Web SDA pemeliharaan SDA  Dukungan atas proses bisnis analitikal: Aplikasi yang ada belum sepenuhnya mendukung EIS bagi pimpinan.



116


Unit Kerja

5.


Sistem Informasi Saat Ini 1. IRMS (Interurban Road Management System) 2. SIMPAJATAN (Sistem Informasi Manajemen Penanganan Jalan dan Jembatan) 3. SIPP(Sistem Pemantauan Proyek) 4. Leger Jalan 5. Informasi Tanggap Darurat 6. POK (Petunjuk Operasional Kegiatan) 7. Website Bina Marga

Analisis Dukungan Terhadap Proses Bisnis  Dukungan atas proses bisnis transaksional: a. Penyusunan program dan anggaran penyelenggaraan jalan. b. Pengelolaan pembiayaan dan investasi jalan c. Pengembangan sistem manajemen penyelenggaraan jalan d. Evaluasi kinerja penyelenggaraan jalan e. Pembinaan teknis lingkungan dan keselamatan jalan f. Pengendalian penyelenggaraan jalan g. Pembinaan penyelenggaraan jalan  Dukungan atas proses bisnis analitikal: Belum ada



117


Unit Kerja Direktorat Jenderal Cipta Karya

Sistem Informasi Saat Ini 1. Sistem Informasi Bidang Pengembangan Pemukiman 2. SIM Prasarana dan Sarana Agropolitan 3. Sistem Informasi Manajemen Evaluasi Kinerja 4. Sistem Informasi PPIP (Pembinaan Pembangunan Infrastruktur Pedesaan) 5. Sistem Informasi Program Pemberdayaan Masyarakat 6. Sistem Informasi Manajemen SPAM IKK 7. SIM PNPM Mandiri 8. Sistem Informasi Pengaturan Kegiatan Penataan Bangunan dan Lingkungan 9. Sistem Informasi & Database Kawasan Kumuh Perkotaan & Penyusunan Profil Permukiman Kumuh Pada 8 Kota Metropolitan 10. Sistem Informasi Bantuan Teknis Penyelenggaraan Bangunan Gedung Negara 11. Website Cipta Karya

Analisis Dukungan Terhadap Proses Bisnis  Dukungan atas proses bisnis transaksional: a. Pengembangan pemukiman baru b. Peningkatan pemukiman wilayah c. Pengembangan air minum d. Penataan bangunan dan lingkungan e. Pembinaan Pengelolaan Gedung dan Rumah Negara f. Evaluasi kinerja  Dukungan atas proses bisnis analitikal: Belum ada



118


Unit Kerja Badan Pembinaan Konstruksi

8.

Badan Penelitian Pengembangan

Sistem Informasi Saat Ini 1. Web BP Konstruksi 2. SIM JaKon 3. SIP JaKI 4. Web Pusat 1 (PPUK) 5. Web Pusat 2 (PPPK) 6. Web Pusat 3 (PPSDI) 7. Web Pusat 4 (PPKPK) 8. Sistem Informasi Sumber Daya Investasi (SISDI)

Analisis Dukungan Terhadap Proses Bisnis  Dukungan atas proses bisnis transaksional: a. Pembinaan usaha dan kelembagaan b. Pembinaan penyelenggaraan konstruksi c. Pembinaan sumber daya investasi d. Pembinaan kompetensi dan pelatihan konstruksi  Dukungan atas proses binis analitikal: Sistem yang ada belum sepenuhnya mendukung pengambilan keputusan bagi pimpinan, baru sebatas pengelolaan data. Penyajian yang lebih informatif belum terlaksana akibat sistem yang masih terpisah-pisah.

dan 1. Tata Persuratan (Pemantauan Alur  Dukungan atas proses bisnis transaksional: Surat) a. Persuratan b. Info untuk standar yang dikeluarkan sebagai 2. Aplikasi Info Standar hasil kajian pusat di daerah 3. Aplikasi Agenda kegiatan pejabat c. Dukungan Manajemen dan Dukungan Balitbang Teknis Lainnya Badan Litbang (Penjadwalan agenda pejabat)  Dukungan atas proses bisnis analitikal: Belum ada



119

Analisis Level Pusdata Pembahasan untuk level Pusdata didetailkan lebih spesifik dengan mempertimbangkan keberadaan Pusdata yang harus menjadi unit kliring data berdasarkan Keputusan Menteri PU Nomor: 489A/KPTS/M/2007. Posisi Pusdata dalam hal ini krusial sebagai unit kerja yang memfasilitasi keberadaan sistem informasi yang akan digunakan oleh pimpinan Kementerian dalam melakukan monitoring kinerja Kementerian dan pengambilan keputusan. Beberapa peran terkait sistem informasi lainnya juga diidentifikasi di bagian ini. Analisis dukungan aplikasi atau sistem informasi pada level Pusdata dapat dilihat pada Tabel 5.30 berikut ini: Tabel 5.30 Analisis dukungan sistem informasi level Pusdata No 1.

2.

Kebutuhan Peran Sistem Informasi

Sistem Informasi Saat Ini

Pengelolaan konsistensi data-data master lintas Satminkal dalam rangka keberjalanan Pusdata sebagai unit kliring data dan informasi Penyajian informasi lintas Satminkal dalam rangka pengambilan keputusan pada level Kementerian.

Saat ini sedang dilakukan pengembangan data warehouse di Pusdata.

1. 2. 3. 4. 5.

SIGI Loket Pelayanan Peta Geotagging e-Procurement SIM Komunikasi Kementerian PU

Analisis Dukungan Terhadap Proses Bisnis

 Dukungan atas proses bisnis transaksional: a. Penyusunan dan pengembangan pengolahan data b. Penyelenggaraan sistem informasi c. Pengolahan dan penyediaan data spasial dan literal  Dukungan atas proses bisnis analitikal: Data Sistem-sistem yang ada sebagian besar masih parsial, sehingga penyajian informasi kepada pimpinan belum komprehensif.



120

Tabel 5.30 Analisis dukungan sistem informasi level Pusdata (lanjutan) No 3.

4.

5.

Kebutuhan Peran Sistem Informasi

Sistem Informasi Saat Ini

Penyediaan layanan yang 1. PU.Net memungkinkan dipublikasikannya 2. Data Proyek Strategis informasi kementerian kepada publik, yang operasionalnya akan 3. Web Balai Literal dilaksanakan oleh Pusat Komunikasi

Penyediaan layanan yang bersifat umum dan digunakan oleh semua unit kerja, di luar layanan spesifik Satminkal Penyediaan layanan yang memungkinkan terjadinya kolaborasi berbagai unit kerja dan staf Kementerian.

e-Procument

1. e-Mail 2. Portal 3. Teleconference

Analisis Dukungan Terhadap Proses Bisnis  Dukungan atas proses bisnis transaksional: a. Penyusunan dan pengembangan pengolahan data b. Penyelenggaraan Sistem Informasi c. Pengolahan dan penyediaan data spasial dan literal  Dukungan atas proses bisnis analitikal: Sistem-sistem yang ada sebagian besar masih parsial, sehingga penyajian informasi kepada pimpinan belum komprehensif. Memberikan dukungan terhadap proses bisnis pengadaan

Dukungan yang memungkinkan terjadinya kolaborasi berbagai unit kerja dan staf Kementerian.



121

1. Identifikasi Kebutuhan Sistem Informasi Secara garis besar sistem informasi dapat dibedakan dalam sistem informasi khusus dan sistem informasi umum. Sistem informasi khusus adalah sistem informasi yang bersifat spesifik dan berbeda-beda antar Satminkal. Sistem informasi khusus ini utamanya diperlukan untuk mendukung proses-proses bisnis utama Kementerian yang ada di masing-masing Satminkal. Sedangkan sistem informasi umum adalah sistem informasi yang mendukung proses bisnis pendukung. Kebutuhan Sistem Informasi Khusus (per Satminkal) Tabel 5.31 berikut ini menjelaskan mengenai kebutuhan sistem informasi khusus (per Satminkal). Tabel 5.31 Kebutuhan sistem informasi khusus (per Satminkal) No

Satminkal

A.

Direktorat Jenderal Penataan Ruang

B.


Kebutuhan Sistem Informasi Deskripsi 1. Datawarehouse – Business Intelligence untuk Aplikasi yang dapat melakukan summary terhadap data-data yang Penataan Ruang dimiliki Dirjen Penataan Ruang sehingga dapat disajikan untuk mendukung keputusan. 2. Portal intranet Aplikasi yang digunakan untuk komunikasi dan sharing informasi di internal Satminkal. 3. Manajemen dokumen dan surat Aplikasi untuk pengelolaan berbagai dokumen dan persuratan secara dijital, termasuk di dalamnya document flow. 4. EIS (Executive Information System) Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan. 1. Manajemen dokumen dan surat Aplikasi untuk pengelolaan berbagai dokumen dan persuratan secara dijital, termasuk di dalamnya document flow.



122

Tabel 5.31 Kebutuhan sistem informasi khusus (per Satminkal) (lanjutan) No

Satminkal

Kebutuhan Sistem Informasi 2. EIS (Executive Information System)

3. Portal Intranet PISDA (Portal Informasi Sumber Daya Air) dan dikembangkan bertahap menjadi cyber-collaboratory.

4. Datawarehouse – Business Intelligence untuk sumber daya air

1. Datawarehouse – Business Intelligence untuk Bina Marga C.


2. Portal intranet 3. Manajemen dokumen dan surat

Deskripsi Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan. Antarmuka berbasis web (web-based interface) yang mengintegrasikan berbagai produk dan jasa informasi SDA yang tersebar dan dikelola oleh Pengelola SISDA-PU dari berbagai tingkatan. PISDA merupakan jalan masuk utama (main entry point) yang berbasis web untuk mengakses informasi SDA di Indonesia secara cepat. PISDA juga merupakan sarana untuk menunjang proses pelayanan masyarakat, sekaligus memfasilitasi partisipasi dan dialog publik di dalam perumusan kebijakan terkait SDA. Aplikasi yang dapat melakukan summary terhadap data-data yang dimiliki Dirjen SDA sehingga dapat disajikan untuk mendukung keputusan. Cikal bakal aplikasi ini sudah ada dalam SISDA tetapi belum memenuhi semua kebutuhan user dan pimpinan. Aplikasi yang dapat melakukan summary terhadap data-data yang dimiliki Direktorat Jenderal Bina Marga sehingga dapat disajikan untuk mendukung keputusan. Aplikasi yang digunakan untuk komunikasi dan sharing informasi di internal Satminkal. Aplikasi untuk pengelolaan berbagai dokumen dan persuratan secara dijital, termasuk di dalamnya document flow.



123


Satminkal

Kebutuhan Sistem Informasi 4. EIS (Executive Information System)

Deskripsi Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan.

1. Manajemen dokumen dan surat

D.

E.

F.

Direktorat Jenderal Cipta Karya



Aplikasi untuk pengelolaan berbagai dokumen dan persuratan secara dijital, termasuk di dalamnya document flow. 2.EIS (Executive Information System) Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan. 3. Portal intranet Aplikasi yang digunakan untuk komunikasi dan sharing informasi di internal Satminkal. 4. Datawarehouse – Business Intelligence untuk Aplikasi yang dapat melakukan summary terhadap data-data Cipta Karya yang dimiliki Dirjen Cipta Karya sehingga dapat disajikan untuk mendukung keputuasn. 1. Sistem Informasi Manajemen Audit Sistem yang membantu dalam merencanakan, mengorganisasi, melaksanakan dan mengevaluasi proses audit yang terjadi di lingkungan Kementerian PU. 1. SIM Jakon Aplikasi ini mengelola data sertifikat badan usaha dan data sertifikat tenaga ahli. Aplikasi ini mendukung tugas Pusat 1. 2.SIM Jaki Aplikasi ini mengelola informasi Pembinaan, Data Tim Pembina se-NKRI dan Permen tentang SPM. Di dalamnya terdapat juga daftar izin usaha jasa konstruksi. 3. Portal intranet Aplikasi yang digunakan untuk komunikasi dan sharing informasi di internal Satminkal.



124


Satminkal

Kebutuhan Sistem Informasi

Deskripsi

4. Manajemen dokumen dan surat

G.


Aplikasi untuk pengelolaan berbagai dokumen dan persuratan secara dijital, termasuk di dalamnya documet flow. 5.EIS (Executive Information System) Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan. 6.Datawarehouse – Business Intelligence untuk Aplikasi yang dapat melakukan summary terhadap data-data pembinaan konstruksi. yang dimiliki BP Konstruksi sehingga dapat disajikan untuk mendukung keputusan. 1.Portal intranet Aplikasi yang digunakan untuk komunikasi dan sharing informasi di internal Satminkal. 2.EIS (Executive Information System) Sistem informasi yang mampu menyajikan berbagai informasi bagi level eksekutif (pimpinan) yang dapat membantu dalam mengambil kebijakan. 3.Datawarehouse - Business Intelligence untuk Aplikasi yang dapat melakukan summary terhadap data-data Balitbang. yang dimiliki Balitbang sehingga dapat disajikan untuk mendukung keputusan.



125

Kebutuhan Sistem Informasi Umum Tabel 5.32 berikut ini menjelaskan mengenai kebutuhan sistem informasi umum. Tabel 5.32 Kebutuhan sistem informasi umum No

Proses Bisnis

A.

Proses-proses bisnis umum

Kebutuhan Sistem Informasi Keterangan 1. SI Pengelolaan Pengadaan (e- Pengelolaan Pengadaaan disesuaikan dengan Peratruan Procurement) Presiden Nomor 54 Tahun 2010 Tentang Pengadaan Barang/Jasa Pemerintah; Peraturan Presiden Nomor 70 Tahun 2012 Tentang Perubahan Kedua Atas Perpres 54/2010; Peraturan Presiden Nomor 84 Tahun 2012 Tentang Pengadaan di Papua dan Papua Barat. 2. SI Pengelolaan Keuangan Memfasilitasi pembuatan rencana kerja anggaran, memfasilitasi pengelolaan penggunaan anggaran dan beban serta realisasi proyek. 3. SI Pengelolaan Kepegawaian Memfasilitasi pengaturan user, manajemen sistem menu, backup dan restore , kemampuan filtering, manajemen data referensi. 4. SI Pengelolaan Hukum Berfungsi untuk melakukan pendaftaran kasus hukum yang akan dilakukan asistensi atau bantuan hukum. 5. SI Monitoring Program (e- Berfungsi untuk melakukan interfacing dengan aplikasi lain Monitoring) dan integrasi data. Termasuk di dalamnya adalah kemampuan mengambil data DIPA dari aplikasi RKAKL sebagai acuan melakukan monitoring kinerja anggaran. 6. SI Pengelolaan Diklat Berfungsi untuk menyusun rencana kegiatan / agenda diklat; penyusunan materi dan kurikulum untuk tiap-tiap diklat.



126

Tabel 5.32 Kebutuhan sistem informasi umum (lanjutan) No

Proses Bisnis

B.

Pengelolaan konsistensi data-data master lintas Satminkal dalam rangka keberjalanan Pusdata sebagai unit kliring data dan informasi.

Kebutuhan Sistem Informasi Keterangan 7. SI Kolaborasi Program dan Sistem informasi ini merupakan kebutuhan khusus untuk Proyek mengakomodasi kebutuhan pengelolaan program dan proyek lintas Kementerian dan Lembaga, di mana PU menjadi leading sector. 1. Datawarehouse Memfasilitasi penyimpanan data secara terpusat dengan struktur data yang sudah disiapkan. ETL (Extract Transform Loading) mampu memfasilitasi pengambilan data secara otomatis dari datawarehouse setiap Satminkal yang dilengkapi dengan kemampuan sinkronisasi dan validasi.

1. Sistem Informasi Geografis atau Berfungsi untuk menampilkan peta infrastruktur di Indonesia. GIS (Geographic Information Systems)

C.

Penyajian informasi lintas Satminkal dalam rangka monitoring dan pengambilan 2. EIS / e-Reporting keputusan pada level Kementerian

Berfungsi untuk pembuatan laporan dalam data statistik atau grafik. Terdapat dashboard yang menampilkan berbagai informasi yang diperlukan pengguna yang ditampilkan dalam tampilan dashboard, tetapi kedalaman analisisnya tidak seperti modul dashboard pada BI.



127

Tabel 5.32 Kebutuhan sistem informasi umum (lanjutan) No

Proses Bisnis

Kebutuhan Sistem Informasi 3. Business Intelligence

D.

Penyediaan layanan yang memungkinkan dipublikasikannya informasi Kementerian kepada publik, yang operasionalnya akan dilaksanakan oleh Pusat Komunikasi

E.

Penyediaan layanan yang memungkinkan terjadinya kolaborasi berbagai unit kerja dan staff Kementerian

Keterangan  Memfasilitasi berbagai proses analisis terhadap data yang sudah dikumpulkan dalam datawarehouse.  Memfasilitasi berbagai proses data mining untuk memperoleh informasi mengenai apa yang akan terjadi atas suatu kondisi.  Memfasilitasi ditampilkannya berbagai informasi yang diperlukan pengguna yang disajikan dalam tampilan dashboard untuk mengambil sebuah keputusan yang tepat. Data yang ditampilkan merupakan data hasil analisis dari data-data terstruktur dan tidak terstruktur. 1. Portal Publik (PU.Net) Upgrading terhadap sistem yang ada saat ini sehingga semua website ke-PU-an terkoordinasi dengan baik di server Pusdata dan tidak terpencar di server publik diluar kampus PU Pattimura. Selain itu dilakukan juga penyeragaman layout website Satminkal sesuai dengan desain yang perlu disepakati secara bersama. 1. SI Kolaborasi Internal (Portal Memungkinkan terjadinya upload dan download data serta Intranet) pengiriman file; memfasilitasi terjadinya aktivitas social network internal PU. 2. Otomasi Perkantoran Modul yang berfungsi untuk mengatur alur persuratan. 3. Teleconference Memfasilitasi kegiatan koordinasi dengan satker/pusat di daerah jika diperlukan sewaktu-waktu dan mendesak, sehingga akan lebih efisien waktu.



128

2. Peta Arsitektur Aplikasi Kementerian PU Berdasarkan analisis kebutuhan sistem informasi di tiap-tiap Satminkal dan juga di tingkat pusat, dapat disusun sebuah landscape aplikasi seperti Gambar 5.9. Blok Dukungan Pengambilan Keputusan EIS / e-Reporting

Business Intelligence

GIS

Konsolidasi Data Warehouse (Spasial & Non Spasial)

Blok Aplikasi Utama Satminkal Tata Ruang

Cipta Karya


Sumber Daya Air

Bina Marga

Balitbang

Pengembangan Sistem

IT Service Management (Pengelolaan layanan dan keamanan informasi, aplikasi dan infrastruktur TIK)

Infrastruktur Integrasi

e-Procurement

Keuangan

Kepegawaian

Diklat

Hukum

Portal Intranet

Otomasi Perkantoran

e-Monitoring

SI Kolaborasi Program dan Proyek

Portal Publik

Teleconference

Manajemen Organisasi

Kolaborasi

Blok Aplikasi Pendukung

Blok Akses Publik

Gambar 5.9 Landscape aplikasi Kementerian PU

Aplikasi dikelompokkan ke dalam 4 blok besar, yaitu: 1. Blok dukungan pengambilan keputusan yang sebagian besar bersifat analitikal dan berhubungan dengan pengolahan dan penyajian informasi untuk kebutuhan pengambilan kebijakan di level Kementerian. 2. Blok aplikasi utama Satminkal berisi aplikasi-aplikasi utama yang secara spesifik perlu ada di setiap Satminkal. 3. Blok aplikasi pendukung yang berisi aplikasi-aplikasi yang mendukung keberjalanan proses bisnis umum yang terjadi di Kementerian PU. Aplikasi-aplikasi ini umumnya dikembangkan dan dikelola Pusdata dan Sekjen.



129

4. Blok akses publik berisi aplikasi-aplikasi untuk kepentingan akses publik dan berhubungan dengan entitas eksternal. Setiap blok aplikasi tersebut diintegrasikan dengan infrastruktur integrasi. Status aplikasi terdiri dari 3 kategori: 1. Aplikasi baru yang harus dikembangkan, diberi warna merah 2. Aplikasi lama dengan perbaikan dan upgrade , diberi warna kuning 3. Aplikasi lama yang masih sesuai dan layak dipertahankan, diberi warna biru. Berdasarkan status keberadaannya, berikut ini adalah analisis kondisi sistem informasi yang sudah dipetakan ke dalam landscape aplikasi seperti terlihat pada Gambar 5.10.

Blok Dukungan Pengambilan Keputusan EIS / e-Reporting

Business Intelligence

GIS

Datawarehouse (Spasial & Non Spasial)

Blok Aplikasi Utama Satminkal Tata Ruang

Cipta Karya


Sumber Daya Air

Bina Marga

Balitbang

Pengembangan Sistem

Infrastruktur Integrasi

e-Procurement

Keuangan

Kepegawaian

Diklat

Hukum

Portal Intranet

Otomasi Perkantoran

e-Monitoring

SI Kolaborasi Program dan Proyek

Blok Aplikasi Pendukung

Upgrade/ modifikasi

Portal Publik

Teleconference

Manajemen Organisasi

Baru

IT Service Management (Pengelolaan layanan dan keamanan informasi, aplikasi dan infrastruktur TIK)

Kolaborasi

Blok Akses Publik

Aplikasi Saat Ini

Gambar 5.10 Landscape aplikasi: status keberadaan



130

Landscape aplikasi setiap Satminkal dibagi ke dalam 3 blok aplikasi, yaitu: 1. Blok aplikasi analitikal, berisi aplikasi-aplikasi yang berhubungan dengan

pengolahan

dan

penyajian

informasi

untuk

kebutuhan

pengambilan kebijakan di level direktorat dan untuk menunjang pengambilan keputusan di level Kementerian. 2. Blok aplikasi transaksional, berisi aplikasi-aplikasi yang berhubungan dengan penanganan kegiatan rutin transaksional. 3. Blok aplikasi kolaborasi, berisi aplikasi-aplikasi yang mendukung proses kolaborasi antar unit dan antar fungsi.



131

Gambar 5.11 memperlihatkan landscape aplikasi di seluruh Satminkal. Kolaborasi Bina Marga Portal intranet

Penataan Ruang Portal intranet

Bina Marga

IRMS

Man.Dok dan Surat

Analitikal

Transaksional

Bina Marga SIMPAJATAN

Leger Jalan

POK

Penataan Ruang Database RTRW

SIPP

Aplikasi Informasi Audio Visual DJPR

Penataan Ruang

Man.Dok dan Surat

Cipta Karya Portal intranet Man.Dok dan Surat

SDA Man.Dok dan Surat

Cipta Karya SIM Prasarana dan Sarana Agropolitan

Sistem Informasi Bidang Pengembangan Pemukiman Sistem Informasi Program Pemberdayaan Masyarakat

PPIP

Sistem Informasi Manajemen SPAM IKK

PAI

Portal intranet Man.Dok dan Surat

Baru

SIMEKA Datawarehouse dan Business Intelligence

Web SDA

EIS

SDA Datawarehouse dan Business Intelligence

BP Konstruksi SIP JaKI (Sistem Informasi Pembinaan Jasa Konstruksi)

SIM JaKon

EIS

BP Konstruksi Web BP Konstruksi

Balitbang Portal intranet

EIS

SIM PNPM Mandiri

SDA PDSDA (Pengolah Data Sumber Daya Air)

Datawarehouse dan Business Intelligence

Cipta Karya

Portal intranet

BP Konstruksi

EIS Datawarehouse dan Business Intelligence

Web Pusat 1(PPUK)

Balitbang

Upgrade/ modifikasi

Datawarehouse dan Business Intelligence EIS

Sistem Tata Naskah Dinas Elektronik

Aplikasi info standar

Aplikasi Agenda kegiatan pejabat Balitbang

Sistem Akuntansi Penggunaan Anggaran (SAKPA)

Balitbang SIMAK BMN(Sistem Informasi Manajemen Akuntansi-Barang Milik Negara)

Datawarehouse dan Business Intelligence EIS

Aplikasi Saat Ini

Gambar 5.11 Landscape aplikasi seluruh Satminkal Universitas Indonesia


132

5.5.3.3 Arsitektur Data (as is) Tujuan pembuatan arsitektur data yaitu untuk mendefinisikan tipe dan source (sumber) data yang dibutuhkan untuk mendukung proses bisnis organisasi dengan cara yang mudah dipahami oleh stakeholders, lengkap dan konsisten. Dalam pembuatan arsitektur data perlu diperhatikan bahwa arsitektur data ini tidak berfokus pada desain database. Tujuan dari fase ini adalah mendefinisikan entitas data yang relevan terhadap proses bisnis organisasi, tidak untuk mendesain sistem penyimpanan secara fisik maupun lojik. Namun, relasi atau keterhubungan antara file dan database saat ini dapat diidentifikasi dan mungkin menunjukkan perbaikan atau peningkatan proses bisnis yang signifikan (The Open Group, 2009). Artifacts dari fase arsitektur data ini dapat berupa Data Component Catalog. Data Component Catalog Tujuan dari data component catalog, yaitu untuk mengidentifikasi dan mengelola semua data yang digunakan di dalam organisasi meliputi entitas data dan komponen data di mana data disimpan. Katalog tersebut dapat dilihat pada Tabel 5.33 berikut ini: Tabel 5.33 Data component catalog pada arsitektur data (as is)

1. 2. 3. 4. 5.

Kode Data DT_1 DT_2 DT_3 DT_4 DT_5

6. 7. 8. 9.

DT_6 DT_7 DT_8 DT_9

No

10. DT_10 11. DT_11

Nama Data

Owner / pemilik data

Data CPNS, pegawai Data Mutasi Pegawai Data Pejabat Data Pelaksanaan Anggaran Data BMN (Barang Milik Negara) Data Arsip dan Naskah Dinas Data Program dan Anggaran Data Peraturan Perundangan Data Pelaksanaan Kebijakan dan Strategi. Data Penyelenggaraan Diklat Data Publikasi dan Dokumentasi

Biro Kepegawaian, Sekjen Biro Kepegawaian, Sekjen Biro Kepegawaian, Sekjen Biro Keuangan, Sekjen Biro Keuangan, Sekjen Biro Umum, Sekjen Biro PKLN, Sekjen Biro Hukum, Sekjen Pusat Kajian Strategis, Sekjen Pusdiklat, Sekjen Pusat Komunikasi Publik



133

Tabel 5.33 Data component catalog pada arsitektur data (as is) (lanjutan) Kode Data 12. DT_12 13. DT_13 14. DT_14 No

15. 16. 17. 18. 19.

DT_15 DT_16 DT_17 DT_18 DT_19

20. DT_20 21. DT_21 22. DT_22 23. DT_23 24. DT_24 25. DT_25

Nama

Owner / pemilik data

Data Laporan Pimpinan Data Kepustakaan Data Barang Milik Negara

Pusat Komunikasi Publik Pusat Komunikasi Publik Pusat Pengelolaan Barang Milik Negara Data Hasil Pengawasan Inspektorat Jenderal Data RTRW Dirjen Tata Ruang Data Sumber Daya Air Dirjen SDA Data Aset Irigasi Dirjen SDA Data Penanganan Jalan dan Dirjen Bina Marga Jembatan Data Kawasan Kumuh Dirjen Cipta Karya Perkotaan Data Sumber Daya Investasi Badan Pembinaan Konstruksi Data Hasil Kajian Balitbang Data Spasial dan Literal Pusdata Data Pengadaan Barang dan Pusdata Jasa Data Proyek Strategis Pusdata



134

5.5.3.4 Arsitektur Aplikasi dan Data Usulan (to be) Pada bagian ini diuraikan mengenai arsitektur aplikasi dan data usulan (to be) yang mengacu pada prinsip aplikasi dan prinsip data yang telah disebutkan sebelumnya. 5.5.3.4.1 Konsep data warehouse Kementerian PU Secara garis besar, arsitektur aplikasi dan arsitektur data usulan ini menggunakan konsep data warehouse dan integrasi aplikasi menggunakan konsep SOA (Service Oriented Architecture). Pada gambar 5.12 memperlihatkan konsep data warehouse Kementerian PU.

Gambar 5.12 Konsep data warehouse Kementerian PU

Konsep data warehouse kementerian pekerjaan umum dapat digambarkan seperti Gambar 5.12 tersebut diatas. Berikut penjelasan dari Gambar 5.12 diatas:

1. Pada

Fungsi Satminkal terdapat aplikasi-aplikasi yang mereka miliki

sebagai proses yang masing-masing berdiri sendiri. Mengelola data dan informasi terkait dengan kebutuhan internal masing-masing satminkal, pada masing-masing satminkal dibentuk sebuah database sementara yang berfungsi sebagai backup dari database transaksi yang berjalan. Pada setiap satminkal di sediakan sebuah aplikasi ETL (Extract Transform dan Load) sederhana untuk melakukan proses cleansing dan transformasi data Universitas Indonesia


135

yang nantinya akan digunakan untuk menyimpan data ke staging area masing-masing satminkal. 2. Di masing-masing Satminkal perlu dibangun sebuah database staging area dimana fungsi dari staging area ini adalah untuk menyimpan hasil proses ETL masing-masing Satminkal. Staging area dapat merupakan fasilitas database internal dari Pengelola TIK masing-masing satminkal. 3. Dalam Arsitektur diatas dijelaskan juga pemanfaatan sebuah middle ware berbasis SOA (Services Orientied Architecture) dalam bentuk aplikasi ESB (Enterprise Services Bus) yang dipasang di server Pusdata, ESB merupakan sebuah aplikasi server yang dapat mengkomunikasikan pertukaran data antar platform. Dimana pada rancangan arsitektur data warehouse ini digunakan sebagai jembatan untuk proses ETL dari staging area ke data warehouse.

Pada Proses selanjutnya ESB, tidak hanya sebatas sebagai jembatan untuk Proses ETL dari staging area ke data warehouse utama, tetapi jika pada saat implementasinya staging area juga sebagai data warehouse untuk masing-masing Satminkal, maka ESB dapat dimanfaatkan untuk menarik data langsung dari staging area Satminkal ke dalam proses representasi data, baik untuk keperluan BI (business intelligence), data mining ataupun dashboard.



136

5.5.3.4.2 Rancangan SOA (Service Oriented Architecture) Rancangan SOA yang diusulkan dengan tujuan mengintegrasikan aplikasi dan data yang ada di Kementerian Pekerjaan Umum bisa dilihat pada Gambar 5.13.

5 Presentation

6

Portal, Mobile dll

4

Proses Bisnis Kementerian PU

3 Services

Service 1

Service 2

Service 3

Service N

Application Layer

Aplikasi 1

Aplikasi 2

Aplikasi 3

Aplikasi N

2

Integration Architecture

Business Process Choreography

1 Data Layer DB

DB

DB

DB

Gambar 5.13 Rancangan SOA

Dari Gambar 5.13 dapat dilihat bahwa komposisi rancangan SOA dibagi menjadi 6 layer, yaitu data layer, application layer, service, business process choreography dan presentation. 1. Layer 1 : Data Layer, terdiri dari database dari masing-masing aplikasi. Database ini bisa berbeda-beda jenisnya, contoh: MySQL, Ms.Access, dan lain-lain. Fungsi dari data layer yaitu mendefinisikan data-data yang akan diintegrasikan. 2. Layer 2 : Application Layer, terdiri dari aplikasi-aplikasi yang akan saling terintegrasi. Aplikasi ini juga bisa berbeda platform, contoh platform: PHP, .Net, Java, dan lain-lain. Contoh aplikasi : e-Procurement, e-Monitoring dan lain-lain.



137

Fungsi dari application layer yaitu mendefinisikan aplikasi-aplikasi yang berisi data yang akan diintegrasikan. 3. Layer 3 : Service Layer, terdiri dari services atau layanan-layanan yang dihasilkan dari aplikasi yang terdapat pada application layer. Service layer ini berfungsi untuk mengenkapsulasi lojik dari aplikasi terhadap lojik dari bisnis. 4. Layer 4 : Business Process Choreography, pada layer ini semua proses bisnis yang ada di dalam sistem didefinisikan (dibuat rule nya) dan dijalankan dengan menggunakan services atau layanan-layanan yang terdapat pada service layer. 5. Layer 5 : Presentation, hasil dari business process choreography ditampilkan pada layer ini (presentation layer) . Contoh media untuk menampilkan hasil tersebut antara lain: Portal, Mobile SMS dan lain-lain. 6. Layer 6 : Integration Architecture, layer ini representasi dari ESB (Enterprise Service Bus). Pada layer ini terdapat protokol yang digunakan untuk integrasi data, salah satunya menggunakan SOAP (simple object access protocol) yang berisi dokumen text dengan format XML (extensible markup language).



138 5.5.3.5 Analisis Kesenjangan Aplikasi Analisis kesenjangan (Gap Analysis) menggambarkan perbedaan antara kebutuhan aplikasi (to be) dengan kondisi saat ini (as is). Analisis kesenjangan tersebut dapat dilihat pada Tabel 5.34. Tabel 5.34 Analisis kesenjangan aplikasi AS IS

Aplikasi Portal intranet

TO BE Cipta Karya

SDA

BP Konstruksi

Balitbang

New

New

Upgrade

New

New

New

New

New

New

Bina Marga

Penataan Ruang

New

New

Manajemen Kolaborasi

dokumen

dan

surat

Transaksional

IRMS SIMPAJATAN Leger Jalan POK Database RTRW Aplikasi Informasi Audio Visual DJPR Sistem Informasi Bidang Pengembangan Pemukiman

Retain Retain Retain Retain Upgrade Upgrade

Upgrade



139 Tabel 5.34 Analisis kesenjangan aplikasi (lanjutan) AS IS

Aplikasi Bina Marga

Transaksional

SIM Prasarana dan Sarana Agropolitan Sistem Informasi Manajemen SPAM IKK PPIP SIM PNPM Mandiri PDSDA PAI Web SDA SIP JaKI Web BP Konstruksi SIM JaKON Web Pusat 1 (PPUK) Sistem TNDE Aplikasi agenda pejabat Aplikasi info standar

Penataan Ruang

TO BE Cipta Karya

SDA

BP Konstruksi

Balitbang

Upgrade

Upgrade Upgrade Upgrade Upgrade Retain Retain Upgrade Retain Upgrade Retain Retain Retain Retain



140 Tabel 5.34 Analisis kesenjangan aplikasi (lanjutan) AS IS

Aplikasi Bina Marga

Penataan Ruang

New New Retain

New New

Transaksional SIMAK BMN EIS DW & BI SIPP SIMEKA

TO BE Cipta Karya

SDA

BP Konstruksi

Balitbang

New New

New New

New New

Retain New New

Retain



141

5.6

Tahap 9. Technology Architecture

Fase technology architecture bertujuan untuk mendefinisikan arsitektur teknologi yang nantinya direalisasikan untuk memenuhi kebutuhan implementasi desain sistem informasi. Masukan untuk fase ini adalah prinsip teknologi, analisis kesenjangan dari information system architecture. Keluaran dari fase ini adalah artifact dari arsitektur TI beserta analisis kesenjangan teknologi informasi. Gambar 5.14 memperlihatkan mengenai input, steps dan output dari fase technology architecture.

Input: 1. Prinsip teknologi 2. Analisis gap dari IS Architecture.

Steps: Identifikasi arsitektur TI saat ini dan usulan serta membuat analisis kesenjangan

Output: Artifact: 1. Arsitektur Teknologi saat ini 2. Analisis Kondisi Infrastruktur Secara Umum 3. Arsitektur Teknologi Usulan (to be) 4. Analisis kesenjangan TI.

Gambar 5.14 Input, steps, output pada fase technology architecture

5.6.1 Masukan (input) Fase Technology Architecture Input atau masukan untuk fase ini yaitu prinsip teknologi yang telah disebutkan pada sub bab 5.1.3.3. Prinsip teknologi tersebut diantaranya: sharing dan industrial standard. Prinsip sharing berarti teknologi harus dapat dipakai bersama oleh lebih dari satu layanan atau fungsi. Industrial standard berarti teknologi yang digunakan mengacu kepada standar industri. Analisis kesenjangan dari IS Architecture juga menjadi masukan untuk fase ini. Universitas Indonesia


142

5.6.2 Proses (steps) pada Fase Technology Architecture Setelah merancang arsitektur sistem informasi, maka didapatkan artifact dari arsitektur sistem informasi. Untuk mengimplementasikan aplikasi-aplikasi tersebut dibutuhkan infrastruktur TI yang mendukung keberlangsungan fungsi aplikasi-aplikasi tersebut. Dalam fase ini dilakukan identifikasi arsitektur TI saat ini lalu merancang arsitektur usulan berbasis cloud computing serta membuat analisis kesenjangan.

5.6.3 Keluaran (output) Fase Technology Architecture 5.6.3.1 Arsitektur Teknologi Saat Ini (as is) 1. Infrastruktur Satminkal Berikut ini merupakan gambaran kondisi umum infrastruktur di satminkal yang mencakup: LAN satminkal di kantor pusat, hubungan dengan unit-unit kerja di luar kantor pusat serta data center. Topologi Jaringan Kementerian Pekerjaan Umum [Koneksi Jaringan ke Satminkal]

Firewall

Internet

Icon Legend Internet

Internet Router

Data Center

Firewall

Server Farm

Perangkat Kendali Jaringan

Server Web

Catalyst Express Catalyst 5505

Access Point Alur akses web Alur akses internet Alur lalu lintas data internal

Server Aplikasi

Catalyst 6509

Area Legend

Internal Area User Access Area

Bina Biro Hukum Marga

R.Menteri

Cipta BP Konstruksi Karya

Itjen

Tata Ruang

SDA

Provider Area

Pusdata Biro Perencanaan

Gambar 5.15 Koneksi jaringan internet Kementerian PU ke Satminkal



143

Pada Gambar 5.15 dapat dilihat mengenai koneksi jaringan internet Kementerian Pekerjaan Umum ke Satminkal. Pada gambar tersebut dapat dilihat bahwa pengelolaan infrastruktur TI terpusat pada data center.

2. LAN Kantor Kementerian Sistem jaringan komputer terpadu di Kementerian Pekerjaan Umum dibangun sejak tahun 1995. Sistem jaringan komputer ini menghubungkan komputer di tiap-tiap unit kerja untuk memperlancar arus komunikasi data antar unit kerja di kantor pusat Kementerian Pekerjaan Umum. Jaringan lokal Kementerian PU ini terdiri dari sekitar 1.500 komputer dan memiliki akses ke Internet dengan bandwidth sebesar 450 Mbps. Akses ke internet memakai jalur dari 2 ISP (Internet Service Provider). ISP pertama memiliki bandwidth sebesar 250 Mbps dan ISP kedua memiliki bandwidth sebesar 200 Mbps. Topologi jaringan yang digunakan di Kementerian PU adalah menggunakan topologi Star Bus, terdiri dari sekitar 150 VLAN yang disediakan untuk melayani akses jaringan tetapi setelah diamati tidak semua VLAN digunakan. Infrastruktur jaringan internet Kementerian Pekerjaan Umum saat ini didukung oleh >=20 unit server, 10 hub utama dan peralatan pendukung yang lain, di mana sebagian perlu diremajakan. Jaringan ini juga telah tersambung sekitar 1.800 unit komputer PC yang tersebar di lingkungan Kementerian PU.

3. Hasil Pemeringkatan e-Government Indonesia Tingkat Kementerian Tahun 2012 Pemeringkatan e-Government Indonesia (PeGI) untuk tingkat Kementerian merupakan kegiatan yang dilaksanakan oleh Direktorat e-Government, Direktorat Jenderal Aplikasi Informatika, Kementerian Komunikasi dan Informatika (KEMKOMINFO) yang melibatkan seluruh Kementerian di Republik Indonesia. Kegiatan PeGI ini dilakukan untuk melihat peta kondisi pemanfaatan Teknologi Informasi dan Komunikasi (TIK) di tingkat Kementerian. PeGI diharapkan dapat meningkatkan pengembangan dan pemanfaatan TIK di lembaga pemerintah di seluruh wilayah Indonesia. Dalam Universitas Indonesia


144

kegiatan PeGI, telah ditetapkan 5 dimensi yang akan dikaji, yaitu: kebijakan, kelembagaan,

infrastruktur,

aplikasi

dan

perencanaan

(Direktorat

e-

Government, 2012). Hasil PeGI pada tahun 2012 menunjukkan bahwa Kementerian Keuangan menduduki peringkat pertama dengan nilai rata-rata seluruh dimensi adalah 3.51. Posisi kedua ditempati oleh Kementerian Pekerjaan Umum dengan nilai rata-rata seluruh dimensi 3.32. Kemudian diikuti oleh Kementerian Perindustrian, Kementerian Pendidikan dan Kebudayaan dan Kementerian Tenaga Kerja dan Transmigrasi dengan nilai masing-masing 3.3, 3.24 dan 3.

Gambar 5.16 Grafik lima dimensi Kementerian Pekerjaan Umum Sumber : (Direktorat e-Government, 2012)



145

Pada Gambar 5.16 memperlihatkan grafik lima dimensi Kementerian Pekerjaan Umum. Pada dimensi infrastruktur khususnya, nilai untuk Kementerian Pekerjaan Umum adalah BAIK. Hal ini ditunjukkan oleh beberapa indikator sebagai berikut: a. Indikator positifnya adalah: 

Telah direncanakan dan dilaksanakan perbaikan fasilitas data center dan kendali TIK beserta fasilitas aplikasi yang seluruhnya dikendalikan oleh pusat data untuk kegunaan bersama bagi semua unit eselon 1.



Sudah dilaksanakan penyatuan kendali jaringan komunikasi data di tingkat Kementerian untuk kepentingan bersama.

b. Indikator negatifnya adalah: Belum memiliki disaster recovery plan maupun disaster recovery center untuk menghadapi kondisi darurat apapun.

Saran perbaikan untuk dimensi infrastruktur adalah: Meski proses informasi di Kementerian ini lebih bersifat fungsional yang tidak time critical, tetap diperlukan perencanaan kelangsungan business dalam keadaan darurat dan penyediaan disaster recovery centre (Direktorat e-Government, 2012). 5.6.3.2 Analisis Kondisi Infrastruktur Secara Umum Berikut ini adalah analisis kondisi infrastruktur yang dipetakan ke dalam 5 domain, yaitu: 1. LAN Kantor Kementerian 2. Koneksi Kantor Kementerian dengan Unit Kerja di luar 3. Koneksi Internet 4. Data Center (DC) 5. Disaster Recovery Center (DRC)



146

Tabel 5.35 memperlihatkan ikhtisar analisis kondisi infrastruktur. Tabel 5.35 Ikhtisar analisis kondisi infrastruktur (as is) Domain LAN Kantor Kementerian

Ikhtisar Kondisi Umum  Koneksi dalam lingkungan Kementerian (jalan Pattimura) sudah menyediakan kapasitas broadband.  Desain konfigurasi LAN saat ini sepenuhnya menggunakan topologi STAR, yang memiliki potensi risiko continuity karena tidak adanya redundansi Koneksi Kantor  Koneksi dengan kapasitas yang memadai khususnya Kementerian untuk unit kerja besar di daerah yang masih terbatas, dengan Unit Kerja kecuali Bina Marga dan SDA yang sudah membangun di luar WAN dengan unit kerja terkait  Di luar Bina Marga dan SDA, koneksi ke kantor pusat Kementerian saat ini terbatas menggunakan internet atau VPN Koneksi Internet Koneksi internet yang disediakan oleh Pusdata masih dirasakan belum memadai oleh Satminkal, sehingga beberapa Satminkal merencanakan atau sudah memiliki koneksi internet sendiri Data Center (DC)  Perangkat komputasi seperti server, storage dll saat ini berada di Pusdata dan masing-masing Satminkal  DC yang ada saat ini belum terstandarisasi, seperti merujuk kepada best practice TIA-942 Disaster Recovery Belum adanya DRC yang memfasilitasi continuity services Center (DRC) dari layanan-layanan TI baik yang diselenggarakan oleh Pusdata maupun Satminkal.



147

5.6.3.3 Arsitektur Teknologi Usulan (to be) 1. Rancangan private cloud Kementerian Pekerjaan Umum Model pengembangan cloud computing yang sesuai dengan kondisi Kementerian PU saat ini adalah private cloud sedangkan model layanan yang diterapkan berupa IaaS (Infrastructure as a Service) (Ardhian, 2013). Model pengembangan private cloud dipilih karena Kementerian PU saat ini ingin berfokus pada pembangunan infrastruktur TI secara mandiri serta ingin meningkatkan kemampuan pegawai dalam hal pembangunan dan pemeliharaan infrastruktur TI. Selain itu, dengan implementasi private cloud ini, transaksi dan lalu lintas data antar Satminkal dalam Kementerian lebih terjaga karena data dimiliki dan berada di Kementerian Pekerjaan Umum, bukan di tangan pihak ketiga sedangkan implementasi awal dari model layanan IaaS diwujudkan dengan pembangunan sistem virtualisasi server (Ardhian, 2013). Gambar 5.17 memperlihatkan rancangan private cloud Kementerian Pekerjaan Umum.



148

Rancangan infrastruktur private cloud Kementerian Pekerjaan Umum

Internet ISP (line 1)

Internet ISP (line 2) 200 Mbps

250 Mbps

Router Juniper

Catalyst Cisco 6500

Firewall

Firewall

Switch Switch

Server cloud PU

1. 2. 3. 4.

Virtual Machine : Poliklinik e-Office Perencanaan Web Setjen dst...

Cluster Production 1

1. 2. 3. 4.

Virtual Machine : e-Office BP Konstruksi Pusdiklat-SIMD e-Recruitment dst...

1. 2. 3. 4.

Virtual Machine : Intranet Peta Jalan Bebas Hambatan Satminkal BPSPAM dst...



Gambar 5.17 Rancangan private cloud Kementerian PU Menurut VMware (VMware, What is a cluster?, 2013a) , cluster diartikan sebagai: “A cluster is a group of hosts that share resources and a management interface. When you add a host to a cluster, the host’s resources become part of the cluster’s resources. The cluster manages the resources of all hosts within it.” Cluster merupakan sekumpulan host yang saling membagi sumber daya dan pengelolaan antar muka. Pada saat penambahan host ke sebuah cluster, sumber daya host tersebut menjadi bagian dari sumber daya di dalam cluster. Cluster mengelola sumber daya dari semua host yang berada di dalamnya.



149

Sedangkan menurut VMware (VMware, What is a host?, 2013b), host diartikan sebagai: “A host is a computer that uses virtualization software to run virtual machines. Typically, a host is a computer running ESX or ESXi software.” Host merupakan komputer yang menggunakan perangkat lunak virtualisasi untuk menjalankan mesin virtual. Secara khusus, host merupakan komputer yang menjalankan perangkat lunak ESX atau ESXi. Dari gambar 5.17 mengenai rancangan infrastruktur private cloud Kementerian Pekerjaan Umum dapat diketahui bahwa koneksi internet menggunakan jalur komunikasi dari 2 ISP (Internet Service Provider). Selain sebagai alternatif jalur untuk mengantisipasi gangguan, namun juga untuk menambah inventarisasi IP publik pada Kementerian Pekerjaan Umum. Dari 2 jalur tersebut terhubung ke server cloud di data center 2 (DC 2). Secara lojik, rancangan private cloud dibagi menjadi 3 cluster, yaitu:  Cluster Production 1 terdiri dari 8 mesin virtual.  Cluster Production 2 terdiri dari 25 mesin virtual.  Cluster Production 3 terdiri dari 15 mesin virtual.

Dalam rancangan private cloud Kementerian PU, terdapat 8 host. Dalam hal ini host diartikan sebagai perangkat komputasi secara fisik berupa server. Gambar 5.18 sampai gambar 5.25 berikut memperlihatkan topologi cluster pada masingmasing host.



150

Rancangan topologi cluster pada host-71

Icon Legend Host

ISP-1

Cluster Production-1 Cluster Intranet CK-142

VM (virtual machine) Cluster Production

ISP Koneksi VM ISP-1

Poliklinik

Host-71

Cluster Production-2

Koneksi VMISP-2 Koneksi Host VM

LPJK-SIKI06

Koneksi VMCluster

ISP-2

Test DB


Gambar 5.18 Rancangan topologi cluster pada host-71

Dari gambar 5.18 dapat dilihat bahwa host-71 secara fisik membagikan sumber dayanya kepada 3 cluster dan mesin virtual yang ada di dalamnya.



151


Icon Legend LPJK-SIKI05

Host

ISP-2

Cluster Production-3 Cluster Jalan Bebas Hambatan

VM (virtual machine)

Pusdiklat-SIPK_84.15

LPJK-SIKI02

ISP Host-72

Koneksi VM ISP-1

Cluster Production

Koneksi VMISP-2 DoubleTake-Eproc ISP-1

Koneksi Host VM Koneksi VMCluster

PDC

Cluster Production-2 Web-Setjen






152


Icon Legend Host


ISP-1

Cluster LPJK-SIKI04 CK-143


Host-73

ISP

ISP-2

Koneksi VM ISP-1

Itjen Kepeg


Koneksi VMISP-2 Koneksi Host VM

PROXY-CK

Koneksi VMCluster

Cluster Production


Gambar 5.20 Rancangan topologi cluster pada host-73 Dari gambar 5.20 dapat dilihat bahwa host-73 secara fisik membagikan sumber dayanya kepada 3 cluster dan mesin virtual yang ada di dalamnya.



153


Icon Legend ISP-2

Host

Cluster e-Recruitment



Satminkal-Sipetbm

ISP Pusdata-OpenCA

Koneksi VM ISP-1

Host-74 CK-145

Koneksi VM- ISP-2 Koneksi Host -VM

Cluster Production

Koneksi VMCluster

ISP-1

Intranet-Peta






154


Icon Legend ISP-1

Host

Cluster Host-75 VM (virtual machine)

BDC


ISP Koneksi VM ISP-1 Koneksi VM- ISP-2

Cluster Production

Koneksi Host -VM Koneksi VMCluster





155


Icon Legend ISP-1 Host

Cluster

Net_flow

CK-144

TestMail

siMAYA



Cluster Production

Host-76


ISP Koneksi VM ISP-1

e-Office BP Kons

Koneksi VM- ISP-2 Web_BP Kons

LPJKSIKI08


Poliklinik

ISP-2





156


Icon Legend Cluster Production-2

Host

Windows 2008

Cluster

PPBMN


e-Mon Backup

ISP-1 ISP CK-146

Cluster Production

Koneksi VM ISP-1

Host-77

Koneksi VM- ISP-2 Satminkal_ BPSPAM


ISP-2

WIM-SPI

LPJKSIKI07






157


Icon Legend ISP-2 Host

Pusdatalocal


Cluster

Pusdiklat -SIMD


RHEL 6.4

CK-141

ISP

Cluster Production

Koneksi VM ISP-1

Host-78

Koneksi VM- ISP-2 LPJKSIKI03


Koneksi Host -VM

eOffice_peren canaan

LPJKSIKI09

ISP-1

Koneksi VMCluster






158

2. Spesifikasi mesin virtual (virtual machine) Dalam Implementasi IaaS (Infrastructure as a Service) Kementerian Pekerjaan Umum Dari Gambar 5.17 dapat dilihat bahwa rancangan private cloud yang dibuat terdiri dari 3 cluster di mana masing-masing cluster terdapat mesin virtual. Tabel 5.36 berikut ini memperlihatkan spesifikasi mesin virtual yang terdapat di masing-masing cluster. Dalam tabel ini hanya memberikan contoh sebagian (diambil 3 contoh) dari mesin virtual untuk masing-masing cluster. Pemberian alokasi terhadap mesin virtual yang baru didasarkan pada ketersediaan storage pada masing-masing cluster.

Tabel 5.36 Spesifikasi mesin virtual (virtual machine) dalam private cloud Kementerian PU

No 1. 2. 3.

No 1. 2.

3.

Nama Cluster : Production-1 Storage : 18,69 TB Host Virtual Processor Machine 76 Poloklinik 2,1 GHz 78 e-Office 2,1 GHz Perencanaan 72 Web Setjen 2,1 GHz Nama Cluster : Production-2 Storage : 21,36 TB Host Virtual Processor Machine 76 e-Office BP 2,1 GHz Konstruksi 78 2. 2,1 GHz PusdiklatSIMD 74 3. e8,7 GHz Recruitment

Memory OS 4 Gb 4 Gb 4 Gb

Memory

Ubuntu Linux (64-bit) Windows Server 2008 (64-bit) Windows Server 2008 (64-bit)

OS

4 Gb

CentOS 4/5/6 (64-bit)

4 Gb

Windows Server 2008 (64-bit)

32 Gb

Windows Server 2008 (64-bit)



159

Tabel 5.36 Spesifikasi mesin virtual (virtual machine) dalam private cloud Kementerian PU (lanjutan)

No 1. 2. 3.

Nama Cluster : Production-3 Storage : 49,75 GB Host Virtual Processor Machine 74 Intranet 2,1 GHz Peta 72 Jalan Bebas 2,1 GHz Hambatan 77 Satminkal 2,1 GHz BPSPAM

Memory

OS

4 Gb

Windows Server 2008 (64-bit) Windows Server 2008 (64-bit) Windows Server 2008 (64-bit)

4 Gb 2 Gb

Dari Tabel 5.36 di atas dapat dilihat bahwa tiap cluster terkait dengan storage. Tiap cluster memiliki kapasitas storage yang berbeda-beda. Dari topologi cluster yang digambarkan sebelumnya dapat dilihat mesin virtual apa saja yang terdapat dalam cluster tersebut. Penambahan mesin virtual dilakukan dengan melihat kapasitas storage yang tersisa dalam cluster tersebut. Jika kapasitas storage masih cukup sebagai ruang mesin virtual yang baru, maka mesin virtual baru akan ditambahkan pada cluster tersebut.

3. KEAMANAN PRIVATE CLOUD Keamanan dalam arsitektur teknologi informasi berbasis private cloud dapat dilihat dari berbagai aspek. Pembahasan faktor keamanan sangat perlu diperhatikan agar layanan yang diberikan memiliki kualitas yang baik. Berikut ini beberapa hal yang menjadi usulan dalam rangka menjaga keamanan pada jaringan private cloud: a. Keamanan pada perangkat fisik Ancaman terhadap keamanan pada perangkat fisik seperti perangkat komputer, server, router, storage dan perangkat fisik lainnya paling banyak terjadi akibat pencurian. Kontrol keamanan yang dilakukan Pusdata saat ini berupa pembatasan akses masuk ke dalam data center. Pada data center 1, pembatasan akses masuk terbatas pada orang-orang tertentu (hanya dari pihak manajemen jaringan, Pusdata) menggunakan finger print. Pada data center 2, pembatasan akses masuk terbatas pada orang-orang tertentu (hanya Universitas Indonesia


160

dari pihak manajemen jaringan, Pusdata) menggunakan access card. Kontrol keamanan yang ada sekarang harus lebih ditingkatkan terutama dari segi kedisiplinan mengenai siapa saja yang berhak masuk ke dalam data center. b. Keamanan dari Aspek Otoritas Akses Otoritas akses yang dimaksud yaitu berupa hak akses terhadap aplikasi yang terdapat pada data center. Saat ini baik di data center 1 maupun data center 2 terdapat lima orang yang bertugas sebagai administrator aplikasi. Aplikasi yang dimaksud diantaranya aplikasi untuk memonitor kondisi jaringan, aplikasi pengelolaan sumber daya (resource) dalam implementasi virtualisasi server serta pengelolaan database. Kelima administrator ini hanya memiliki 1 jenis user dan password yang digunakan untuk login. Hal ini bisa menjadi sebuah kerawanan karena jika terjadi perubahan kondisi, konfigurasi maupun data tidak bisa diketahui admin mana yang melakukan perubahan tersebut. Log aktivitas yang terdapat di aplikasi hanya menunjukkan user, password dan waktu aktivitas tersebut, namun tidak bisa menunjukkan data user yang sebenarnya. Usulan terhadap aspek ini berupa pembuatan user dan password yang berbeda untuk masing-masing administrator, penggunaan password yang benar yaitu minimal 8 karakter dan kombinasi. c. Network Access Control (NAC) NAC diperlukan untuk mengelola akses seluruh perangkat yang akan tersambung ke jaringan intranet kantor pusat Kementerian PU (desktop, laptop, perangkat mobile) harus terdaftar terlebih dahulu. Pengelolaan pendaftaran terhadap perangkat yang berhak mengakses jaringan intranet kantor pusat Kementerian PU dilakukan oleh Pusdata. Usulan mengenai implementasi NAC ini diperlukan untuk mengatur akses perangkat ke dalam jaringan. Hal ini diperlukan untuk memperkecil peluang akses jaringan internal dari pihak yang tidak memiliki hak akses misalnya dari pencurian data dan lain-lain.



161

d. Pengaturan Port Usulan mengenai pengaturan port pada seluruh perangkat jaringan dan server di data center meliputi : - pengaktifan port hanya dilakukan pada aplikasi atau layanan yang membutuhkan; - akses untuk melakukan remote maintenance hanya dapat dilakukan melalui VLAN tertentu. Hal ini bertujuan untuk meminimalisir terbukanya celah kerawanan yang bisa memberikan peluang bagi hacker untuk melakukan aktivitas kejahatan di dunia maya. e. Audit Keamanan Informasi Audit keamanan informasi sebagai proses pengumpulan dan evaluasi bukti (evidence) untuk menentukan sejauh mana sistem informasi dapat melindungi aset serta teknologi informasi yang ada telah memelihara integritas data sehingga keduanya dapat diarahkan kepada pencapaian tujuan Kementerian PU secara efektif. Proses audit keamanan informasi bisa dilakukan melalui kerjasama dengan institusi pemerintah lainnya seperti GOV-CSIRT (Government Computer Security Incident Response Team), Kementerian Komunikasi dan Informatika Republik Indonesia.



162 5.6.3.4 Analisis Kesenjangan Teknologi Informasi Analisis kesenjangan (Gap Analysis) menggambarkan perbedaan antara teknologi usulan (to be) dengan teknologi saat ini (as is). Analisis kesenjangan tersebut dapat dilihat pada Tabel 5.37. Tabel 5.37 Analisis kesenjangan TI TO BE

Infrastruktur

Storage Data Center

Switch

MySQL

Java

VisualFox Pro &dBase

Power Builder 9&Sybase

Delphi &Firebird

VB.Net &Ms.Acce ss

VB

Virtual Server

System Software

Infrastruktur

DRC

AS IS

PHP ArcGIS VB VB.Net &Ms.Access Delphi &Firebird Power Builder 9&Sybase VisualFoxPro &dBase Java MySQL Hub New

ArcGIS

PHP

System Software

Add

Add

Retain Retain Retain Retain Retain Retain Retain Retain Retain Upgrade Add



163

5.7

Tahap 10. Opportunities and Solutions

Fase opportunities and solutions bertujuan untuk mengevaluasi dan memilih cara implementasi arsitektur serta konsolidasi analisis kesenjangan dari fase-fase sebelumnya. Masukan untuk fase ini adalah output atau keluaran dari fase-fase sebelumnya, hasil analisis kesenjangan. Keluaran dari fase ini adalah pola solusi. Gambar 5.26 memperlihatkan mengenai input, steps dan output dari fase opportunities and solutions.

Input: 1. Arsitektur Bisnis 2. Arsitektur Sistem Informasi 3. Arsitektur Teknologi

Steps: Melakukan konsolidasi hasil analisis kesenjangan yang dilakukan pada fase sebelumnya.

Output: Pola Solusi

Gambar 5.26 Input, steps, output pada fase opportunities and solutions

5.7.1 Masukan (input) Fase Opportunities and Solutions Input atau masukan untuk fase ini yaitu arsitektur bisnis, arsitektur sistem informasi dan arsitektur teknologi. Arsitektur tersebut meliputi arsitektur usulan (to be) yang merupakan usulan dalam memenuhi kebutuhan organisasi dan mengatasi berbagai masalah TI yang terjadi.



164

5.7.2 Proses (steps) pada Fase Opportunities and Solutions Setelah membuat dan menganalisis arsitektur bisnis, sistem informasi dan teknologi serta melakukan analisis kesenjangan antara kondisi arsitektur saat ini (as is) dan arsitektur usulan (to be), maka dilakukan konsolidasi hasil analisis kesenjangan tersebut untuk mendapatkan pola solusi yang akan diterapkan. 5.7.3 Keluaran (output) Fase Opportunities and Solutions Output atau keluaran dari fase ini berupa pola solusi. Pola solusi ini memberikan gambaran dan penjelasan bagaimana solusi tersebut bisa diterapkan dengan mengacu prinsip arsitektur yang telah dibuat pada fase preliminary. 5.7.3.1 Konsolidasi Server Melalui Virtualisasi 1. Konsolidasi Server Konsolidasi server bertujuan untuk meningkatkan efisiensi pemanfaatan sumber daya komputer dengan cara mengurangi jumlah server atau jumlah lokasi server pada suatu organisasi. Dengan konsolidasi server maka semua fungsi yang sebelumnya ditangani oleh beberapa server yang berbeda akan ditangani oleh sebuah server dengan kapasitas yang lebih besar. Penerapan konsolidasi server dapat mengatasi permasalahan “server sprawl”, yaitu situasi dimana terdapat sejumlah server dengan utilisasi rendah yang menghabiskan banyak sumber daya seperti listrik, ruangan, maintenance dan lain-lain (Muhamad Isa, 17 Juni 2006). Hasil riset yang pernah dilakukan oleh Gartner menunjukkan bahwa penerapan konsolidasi server di beberapa organisasi dapat mengurangi total cost of ownership (TCO) hingga jutaan USD per tahun, namun setiap tipe konsolidasi menghasilkan tingkat penghematan yang berbeda. Besarnya penghematan sangat bervariasi tergantung kepada tingkat konsolidasi yang diterapkan. Meskipun konsolidasi server dapat meningkatkan efisiensi penggunaan sumber daya server, namun implementasinya membutuhkan konfigurasi yang kompleks

sehingga

cukup

menyulitkan

bagi

yang

baru

memulai

menerapkannya. Untuk mengatasi masalah kompleksitas ini, virtualisasi server merupakan solusi yang lebih mudah untuk diimplementasikan. Gambar 5.27 memperlihatkan mengenai konsolidasi server. Universitas Indonesia


165

Gambar 5.27 Konsolidasi server Dengan penerapan virtualisasi server, maka semua server yang ada ditransformasikan menjadi server-server virtual yang semuanya berjalan di atas sebuah server fisik dengan kapasitas yang besar. Masing-masing server virtual tersebut tetap menjalankan sistem operasi dan aplikasi yang sama dengan sebelumnya. Karena secara fisik hanya terdapat sebuah server, maka biaya yang dikeluarkan untuk pengelolaan virtualisasi server akan dapat dihemat. 2. Virtualisasi Virtualisasi memungkinkan beberapa sistem operasi untuk berjalan secara bersamaan dan terisolasi di dalam suatu lingkungan komputasi dalam bentuk komputer virtual pada satu komputer fisik yang secara dinamis memisahkan dan membagi-bagi sumber daya fisik seperti CPU, memory, disk dan perangkat fisik lainnya (Rasian, 2009). Bila dibandingkan dengan teknik komputasi menggunakan server fisik, teknik virtualisasi memiliki 4 atribut yang tidak dimiliki oleh server fisik. Kombinasi dari 4 atribut inilah yang menjadikan teknik virtualisasi cocok sebagai solusi konsolidasi server fisik (Cisco Systems, 2011). 1.

Isolation, sebuah server virtual memiliki lingkungan tersendiri yang tidak terpengaruh dan mempengaruhi server virtual lainnya.

2.

Multiplicity, server virtual memiliki kemampuan untuk menggunakan bersama sumber daya fisik dengan server virtual lainnya.

3.

Abstraction, server virtual bersifat independent terhadap jenis komponen fisik sehingga dapat berjalan di segala jenis server. Universitas Indonesia


166

4.

Encapsulation, sebuah virtual server menyimpan kondisi atau state terakhir sistemnya dalam sebuah file yang mudah dipindahkan.

Pada Gambar 5.28 memperlihatkan empat atribut teknik virtualisasi.

Gambar 5.28 Empat atribut teknik virtualisasi Sumber : (Cisco Systems, 2011)



167

5.7.3.2 Solusi Ketersediaan Layanan Berdasarkan rekomendasi dari hasil pemeringkatan e-Government Indonesia (PeGI) terhadap Kementerian Pekerjaan Umum dilihat dari dimensi infrastruktur bahwa perlu dilakukan perencanaan kelangsungan bisnis dalam keadaan darurat dan penyediaan disaster recovery center. Perencanaan pembangunan DRC ini juga dilakukan sebagai upaya dalam menjaga ketersediaan layanan. 5.7.3.3 Solusi Proteksi Data Mengacu pada prinsip data yang telah dijelaskan di fase preliminary, yaitu data merupakan aset penting harus dalam kondisi aman atau secure. Sistem harus menjamin ketersediaan data melalui teknologi proteksi data. Untuk melindungi data dari kerusakan teknis, pengelolaan disk sebagai media penyimpanan melalui teknik Redundant Array of Independent Disk (RAID). Solusi RAID yang diusulkan dalam rancangan private cloud Kementerian Pekerjaan Umum yaitu RAID 5. Jenis RAID 5 dianggap sesuai dengan kondisi Kementerian PU saat ini karena dalam pengelolaan hard disk nya relatif lebih sederhana dan tidak memerlukan biaya yang cukup tinggi jika dibandingkan RAID 1 (Ardhian, 2013). RAID 5 menyediakan performa yang tinggi untuk permintaan besar dan kecil. Pemilihan RAID 5 juga karena alasan efisiensi, yaitu penggunaan resource khususnya storage. 5.7.3.4 Pemetaan Rancangan Arsitektur Terhadap Prinsip Arsitektur Rancangan arsitektur TI Kementerian Pekerjaan Umum yang berbasis cloud computing harus dapat memenuhi kebutuhan bisnis organisasi yang sebelumnya dirumuskan dalam bentuk prinsip-prinsip arsitektur. Untuk menilai kesesuaian hasil rancangan terhadap prinsip arsitektur, maka perlu dilakukan pemetaan rancangan arsitektur terhadap prinsip arsitektur. Penggunaan prinsip arsitektur dalam perancangan tidak bisa berdiri sendiri namun saling berkaitan antara satu prinsip dengan prinsip yang lain sehingga dalam pemetaannyapun juga saling berkaitan. Pemetaan rancangan arsitektur terhadap prinsip arsitektur dapat dilihat pada Tabel 5.38.



168

Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur Area evaluasi Bisnis

Prinsip Arsitektur P1. Ease of Access

Hasil Rancangan Rancangan

arsitektur

bisnis

berfokus

kepada kemampuan untuk menyediakan layanan terpadu Kementerian. Poin penjelasan dalam dokumen:

P2. Business Continuity

Sub Bab 5.5.3.4 Arsitektur Aplikasi dan Data Usulan (to be) Halaman: 134 Rancangan arsitektur mempertimbangkan aspek ketersediaan layanan. Perencanaan pembangunan DRC dilakukan sebagai upaya

dalam

menjaga

ketersediaan

layanan. Poin penjelasan dalam dokumen:

P3. Recovery

5.7.3.2 Solusi Ketersediaan Layanan Halaman: 167 Rancangan arsitektur mempertimbangkan faktor pemulihan dari gangguan yang mungkin terjadi seperti gempa bumi, kebakaran dan kesalahan pengelolaan data. Dengan rancangan DRC diharapkan mampu memenuhi kondisi tersebut. Poin penjelasan dalam dokumen: 5.7.3.2 Solusi Ketersediaan Layanan Halaman: 167



169

Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur (lanjutan) Area evaluasi Aplikasi

Prinsip Arsitektur P4.Open Standard

Hasil Rancangan Untuk

mempermudah

integrasi

antar

aplikasi yang terpisah-pisah, maka antar aplikasi harus menggunakan suatu standar protokol terbuka. Keseluruhan aplikasi harus mendukung standar protokol yang umum

seperti

HTTP

dan

XML.

Rancangan aplikasi diwujudkan dengan pembuatan ESB (Enterprise Service Bus) dengan basis SOA dengan memakai XML. Poin penjelasan dalam dokumen:

P5. Ease of Use

Sub Bab 5.5.3.4 Arsitektur Aplikasi dan Data Usulan (to be) Halaman: 134 Rancangan aplikasi yang digunakan harus sesuai dengan proses dan memiliki antar muka yang mudah dipahami. Hal ini diwujudkan dengan arsitektur aplikasi yang diusulkan berbasis web seperti portal intranet , executive information system dan lain-lain. Poin penjelasan dalam dokumen: Sub Bab 5.5.3.4 Arsitektur Aplikasi dan Data Usulan (to be) Halaman: 134



170

Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur (lanjutan) Area evaluasi Data

Prinsip Arsitektur P6. Data is an Asset

Hasil Rancangan Data merupakan aset penting harus dalam kondisi aman atau secure. Hal tersebut diimplementasikan melalui teknik RAID. Jenis RAID yang dipilih yaitu RAID 5. Poin penjelasan dalam dokumen: 5.7.3.3 Solusi Proteksi Data Halaman: 167

P7. Data Sharing

Arsitektur

data

harus

mampu

menunjukkan bahwa data dapat digunakan bersama-sama.

Hal

ini

ditunjukkan

dengan integrasi aplikasi beserta datanya baik berupa kolaborasi, transaksional maupun

analitikal,

dapat

digunakan

bersama (sharing) dan disimpan dalam data warehouse. Poin penjelasan dalam dokumen: Sub Bab 5.5.3.4 Arsitektur Aplikasi dan Data Usulan (to be) Halaman: 134



171

Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur (lanjutan) Area evaluasi

Prinsip Arsitektur P8. Secure

Hasil Rancangan Adanya manajemen keamanan secara global yang ditujukan untuk memproteksi keseluruhan

sistem.

Hal

tersebut

diimplementasikan melalui teknik RAID. Jenis RAID yang dipilih yaitu RAID 5. Poin penjelasan dalam dokumen: 5.7.3.3 Solusi Proteksi Data Halaman: 167 Teknologi

P9. Sharing

Penggunaan

teknologi

yang

mampu

menyeragamkan kebutuhan sumber daya dari tiap layanan sehingga mempermudah proses pengelolaan terhadap infrastruktur teknis yang berbeda jenis. Hal ini diwujudkan dengan konsolidasi server melalui virtualisasi. Poin penjelasan dalam dokumen: 5.7.3.1

Konsolidasi

Server

Melalui

Virtualisasi Halaman: 164



172

Tabel 5.38 Pemetaan rancangan arsitektur terhadap prinsip arsitektur (lanjutan) Area evaluasi

Prinsip Arsitektur P10. Industrial Standard

Hasil Rancangan Teknologi komputasi yang disolusikan merupakan solusi teknologi umum yang sudah cukup matang dalam dunia industri. Teknologi

virtualisasi

sudah

umum

digunakan

sebagai

solusi

untuk

meningkatkan

efisiensi

penggunaan

server. Dengan dukungan dari banyak produsen akan mempermudah pemilihan perangkat pendukung yang diperlukan untuk mengelola infrastruktur TI. Poin penjelasan dalam dokumen: 5.7.3.1

Konsolidasi

Server

Melalui

Virtualisasi Halaman: 164



BAB 6 KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan dari penelitian yang dilakukan dan saran yang dapat digunakan sebagai usulan terhadap penelitian selanjutnya. 6.1

Kesimpulan

Berdasarkan hasil pembahasan di dalam penelitian ini, diperoleh beberapa kesimpulan sebagai berikut: 1. Dengan melihat jumlah Satminkal atau unit kerja yang ada di Kementerian Pekerjaan Umum yang memiliki akses informasi yang cukup banyak, baik berupa akses internal (intranet) maupun eksternal (internet) serta kondisi aplikasi yang masih silo-silo meskipun antar Satminkal memiliki fungsi aplikasi yang sama (SI yang bersifat umum, contoh: RKA-KL), maka arsitektur teknologi informasi yang sesuai untuk diterapkan adalah arsitektur yang berbasis layanan (service oriented architecture) dan menggunakan teknologi virtualisasi. Kedua teknologi tersebut merupakan langkah awal dalam membangun cloud computing. 2. Arsitektur bisnis menghasilkan artifact : functional decomposition diagram yang terdiri dari 6 fungsi utama dan 2 fungsi pendukung. Fungsi utama, diantaranya: penataan ruang, sumber daya air, bina marga, cipta karya,

pembinaan

konstruksi

dan

balitbang.

Fungsi

pendukung

diantaranya: sekretariat jenderal dan inspektorat. Lebih lengkapnya bisa dilihat pada Sub Bab 5.4.3 pada halaman 84. 3. Arsitektur sistem informasi menghasilkan konsep data warehouse dan rancangan SOA Kementerian PU. Lebih lengkapnya bisa dilihat pada Sub Bab 5.5.3.4.2 pada halaman 136. 4. Arsitektur teknologi menghasilkan rancangan private cloud Kementerian PU. Lebih lengkapnya bisa dilihat pada Sub Bab 5.6.3.3 pada halaman 148.

173



174

5. Pola solusi yang dihasilkan diantaranya konsolidasi server melalui virtualisasi, pembangunan DRC (Disaster Recovery Center) serta solusi proteksi data dengan menggunakan RAID 5. Lebih lengkapnya bisa dilihat pada Sub Bab 5.7.3.1, 5.7.3.2 dan 5.7.3.3 pada halaman 164. 6.2

Saran

Terkait dengan proses penelitian dan penyusunan rancangan arsitektur teknologi informasi ini, terdapat beberapa saran-saran dan usulan penelitian selanjutnya sebagai berikut: 1. Pengembangan

sistem

informasi

baru

yang

bersifat

terintegrasi

memerlukan perencanaan dan dokumentasi atas seluruh sistem informasi tersebut. 2. Rancangan teknologi yang dihasilkan dalam penelitian ini dapat digunakan untuk penelitian selanjutnya dalam mengukur tingkat performansi data center sebelum dan sesudah implementasi cloud computing. 3. Rancangan teknologi yang dihasilkan dalam penelitian ini dapat digunakan untuk penelitian selanjutnya dalam mengukur konsumsi energi (energi listrik khusunya) serta penghematan yang bisa dilakukan dengan menerapkan virtualisasi server dalam rangka mendukung gerakan Green ICT. 4.

Berdasarkan usulan terkait solusi ketersediaan layanan, dapat dijadikan sebagai bahan kajian dalam hal penyusunan rencana penanggulangan bencana.



175

DAFTAR PUSTAKA

Anggeriana, H. (2011). Retrieved October 30, 2013, from Book of Cloud Computing: http://www.scribd.com/doc/45899074/Book-of-Cloud-Computing Anggoro, A. W. (2010). Penerapan Service Oriented Architecture (SOA) Untuk Aplikasi Naskah Dinas dengan Menggunakan Web Service. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Ardhian, A. (2013, July 9). Kondisi Infrastruktur Kementerian PU. (A. D. Palupi, Interviewer) Asduki, E. P. (2012). Perencanaan Standarisasi Infrastruktur TI yang Adaptif Sesuai Kebutuhan Strategis Organisasi: Studi Kasus Pusdatin Kementerian Perdagangan. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Budiyanto, A. (2012). CloudIndonesiA.ORG.

Pengantar

Cloud

Computing.

Jakarta:

Cisco Systems, I. (2011). Cisco White Paper : Server Virtualization: Branching Out of the Data Center. Retrieved November 7, 2013, from http://www.cisco.com/en/US/prod/collateral/modules/ps10598/white_paper_c11611291.pdf cPanel. (2013). Web Hosting Management, Simplified. Retrieved 10 15, 2013, from http://www.cpanel.net/: http://www.cpanel.net/ CSA. (2009, April). Security Guidance for Critical Areas Of Focus in Cloud Computing V2.1. Retrieved October 15, 2013, from http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf Demarest, G., & Wang, R. (2010). Oracle Cloud Computing. Redwood Shores, CA: Oracle. Direktorat e-Government, D. A. (2012). Pemeringkatan e-Government Indonesia Tingkat Kementerian Tahun 2012. Jakarta: Kementerian Komunikasi dan Informatika. Erl, T. (2005). Service-Oriented Architecture. New Jersey: Pearson Education, Inc. Geelan, J. (2009, January 24). Twenty-One Experts Define Cloud Computing. Retrieved September 11, 2013, from http://cloudcomputing.syscon.com/node/612375/



176

Gunawan. (2009). Penyempurnaan Rancangan Infrastruktur Disaster Recovery Center Dalam Mendukung Disaster Recovery Plan Bank X. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Hagan, P. J. (2004). Guide to the (Evolving) Enterprise Architecture Body of Knowledge. Virginia: Mitre, McLean. Jayaswal, K. (2006). Administering Data Center, Servers, Storage and Voice Over IP. Indianapolis: Wiley Publishing, Inc. Kementerian Pekerjaan Umum. (2011). Cetak Biru TIK Kementerian Pekerjaan Umum. Jakarta: Kementerian Pekerjaan Umum. Kementerian Pekerjaan Umum. (2011). Organisasi. Retrieved 11 22, 2013, from http://www.pu.go.id/content/show/15 Kementerian Pekerjaan Umum. (8 Juli 2010). Peraturan Menteri Pekerjaan Umum Nomor : 08/PRT/M/2010 Tentang Organisasi dan Tata Kerja Kementerian Pekerjaan Umum. Jakarta: Kementerian Pekerjaan Umum. Kementerian Pekerjaan Umum. (31 Desember 2010). Rencana Strategis Kementerian Pekerjaan Umum 2010-2014. Jakarta: Kementerian Pekerjaan Umum. Kominfo, K. K. (2012). Buku Putih Komunikasi dan Informatika Indonesia 2012. Jakarta: Balitbang SDM, Kementerian Kominfo. Krutz, R. L., & Vines, R. D. (2010). Cloud Security: A Comprehensive Guide to Secure Cloud Computing. Indianapolis, Indiana: Wiley Publishing, Inc.,. Lusa, S., & Sensuse, D. I. (2011). Kajian Perkembangan dan Usulan Perancangan Enterprise Architecture Framework. Jurnal Seminar Nasional Aplikasi Teknologi Informasi 2011(SNATI 2011) (pp. G-67). Yogyakarta: Seminar Nasional Aplikasi Teknologi Informasi 2011(SNATI 2011). Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. Special Publication 800-145. Gaithersburg: National Institute of Standards and Technology. Minoli, D. (2008). Enterprise Architecture A to Z: Framework, Business Process Modelling, SOA and Infrastructure Technology. United States Of America: Auerbach Publications. Muhamad Isa, S. (17 Juni 2006). Penerapan Konsolidasi Server Menggunakan Teknologi Virtualisasi. Seminar Nasional Aplikasi Teknologi Informasi 2006 (SNATI 2006) (pp. 97-102). Yogyakarta: Seminar Nasional Aplikasi Teknologi Informasi.



177

Munir, M. (2012). Perancangan Infrastruktur Teknologi Informasi Adaptif Untuk Sistem Informasi dan Komputerisasi Haji Terpadu (SISKOHAT) Direktorat Jenderal Penyelenggaraan Haji dan Umroh Kementerian Agama RI. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Myers, M. (2002). Qualitative Research in Information Systems. Thousand Oaks, CA: Sage Publishing. Nama, G. F. (2012). Perancangan Infrastruktur Teknologi Informasi Adaptif Pada Universitas Lampung. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. PT. Mitranet Mitra Utama. (2013). Pengembangan Datawarehouse Kementerian PU. Jakarta: PT.Mitranet Mitra Utama. Ramakrishnan, R., & Gehrke, J. (2004). Sistem Manajemen Database Edisi-3 (Edisi Terjemahan). Yogyakarta: ANDI Yogyakarta bekerja sama dengan McGraw-Hill Education. Rasian, R. (2009). Perbandingan Kinerja Pendekatan Virtualisasi. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Robertson, B., & Sribar, V. (2001). The Adaptive Enterprise: IT Infrastructure Strategies to Manage Change and Enable Growth. United States Of America: Intel Press. Sessions, R. (2007, May). A Comparison of the Top Four Enterprise-Architecture Methodologies. Retrieved March 30, 2013, from A Comparison of the Top Four Enterprise-Architecture Methodologies: http://msdn.microsoft.com/enus/library/bb466232.aspx Setiawan, E. B. (2009). Pemilihan EA Framework. Seminar Nasional Aplikasi Teknologi Informasi (SNATI). Yogyakarta: Seminar Nasional Aplikasi Teknologi Informasi (SNATI). Solichin, A. (2010). Pemodelan Arsitektur Teknologi Informasi Berbasis Cloud Computing Untuk Instansi Perguruan Tinggi di Indonesia. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Sudarsana, I. G. (2011). Perancangan Model Arsitektur Teknologi Informasi Adaptif dan Berbasis Layanan Pada Data Center. Jakarta: Program Studi Magister Teknologi Informasi Fasilkom UI. Suhandi, Y. (2012). Perancangan Enterprise Architecture Pada PT.XYZ Menggunakan TOGAF ADM. Jakarta: Porgram Studi Magister Teknologi Informasi Fasilkom UI. The Open Group. (2009). The Open Group Architecture Framework (TOGAF). New York: The Open Group. Universitas Indonesia


178

Urbaczewski, L. (2006). A Comparison Of Enterprise Architecture Frameworks. Paper Of Issues In Information Systems, Vol. VII, No.2. VMware. (2013a). What is a cluster? VMware. VMware. (2013b). What is a host? VMware. Ward, J., & Peppard, J. (2002). Strategic Planning for Information System (Third Edition 2002). West Sussex: John Wiley & Sons Ltd. Wijaya, I. (n.d.). Teknologi RAID. Retrieved November 8, 2013, from http://tenggosoft.wordpress.com/server/harddiskha/sistem-raid/ Zachman, J. A. (1997). The Framework for Enterprise Architecture: background, description and utility. Canada: Zachman International, Inc. Zhang, L.-J., & Zhou, Q. (2009). CCOA: Cloud Computing Open Architecture. IEEE International Conference on Web Services (p. 607). IEEE Computer Society.



179

LAMPIRAN

Lampiran 1 : Transkrip Wawancara 1 Narasumber Jabatan

: :

Pewawancara Tempat

: :

Bapak Ir.Rema Suwenda, MM (RMS) Kepala Bidang Penyelenggaraan Sistem Jaringan dan Aplikasi Pusat Pengolahan Data Sekretariat Jenderal, Kementerian Pekerjaan Umum Atina Dwi Palupi (ATN) Pusdata , Kementerian PU

Hari Pelaksanaan Waktu

: :

Jum’at, 1 Februari 2013 13.00 - selesai

Transkrip Wawancara ATN

: Assalamu’alaikum. Pak Rema, perkenalkan saya Atina, pegawai di Satminkal Pusbin SDI (Pusat Pembinaan Sumber Daya Investasi). Saat ini saya sedang persiapan menyusun karya akhir di MTI-UI. Saya memiliki ide untuk mengambil topik karya akhir yaitu mengenai infrastruktur TI. Menurut Bapak, topik apa yang sekiranya menjadi rencana atau program dari Pusdata terkait infrastruktur TI?

RMS

: Wa’alaikumsalam. Dalam hal terkait infrastruktur TI, saat ini Pusdata memiliki rencana untuk implementasi cloud computing.

ATN

:

Terkait hal tersebut, apa yang menjadi kewenangan atau kebijakan Pusdata untuk mengelola infrastruktur TI dalam mengimplementasikan cloud computing?

RMS

:

Pusdata memiliki kewenangan dalam hal pengadaan perangkat, konfigurasi perangkat, instalasi, sosialisasi dan lain-lain. Dalam hal terkait teknis, anda bisa menanyakan langsung kepada kepala dan staf sub bidang manajemen jaringan.

ATN

:

Baik Pak. Terima kasih atas informasinya. Selanjutnya saya akan koordinasi dengan kepala dan staf sub bidang manajemen jaringan.



180

Lampiran 2 : Transkrip wawancara 2 Narasumber Jabatan

: :

Pewawancara Tempat

: :

Bapak Arief Ardhian (ARF) Kepala Sub Bidang Manajemen Jaringan Bidang Penyelenggaraan Sistem Jaringan dan Aplikasi Pusat Pengolahan Data Sekretariat Jenderal, Kementerian Pekerjaan Umum Atina Dwi Palupi (ATN) Pusdata , Kementerian PU

Hari Pelaksanaan Waktu

: :

Selasa, 9 Juli 2013 10.00 - selesai

Transkrip Wawancara ATN

:

Assalamu’alaikum.

Perkenankan

saya

Atina

ingin

menanyakan

beberapa hal kepada Bapak terkait rencana implementasi cloud computing yang akan dilakukan oleh Pusdata. Hal ini akan menjadi referensi dalam menyusun karya akhir saya. ARF

:

Wa’alaikumsalam. Baik silakan.

ATN

:

Apakah saat ini sudah terdapat dokumen perencanaan arsitektur TI yang digunakan sebagai pedoman pembangunan infrastruktur TI?

ARF

:

Belum.

ATN

:

Menurut Bapak, apakah perlu untuk memiliki dokumen enterprise architecture? Apa manfaatnya?

ARF

:

Sangat perlu. Keberadaan rancangan arsitektur TI untuk menterjemahkan kebutuhan TI dalam membangun infrastruktur TI pada Kementerian PU sangat diperlukan sebagai acuan atau pedoman tertulis dalam pembangunan infrastruktur TI berikutnya.

ATN :

Apa yang melatarbelakangi (permasalahan yang menyebabkan) pembangunan data center yang baru pada Kementerian PU? Apakah terdapat tujuan untuk menyatukan data center yang sebelumnya tersebar di masing-masing Satminkal?



181

Transkrip Wawancara

ARF :

Pembangunan data center baru untuk meningkatkan pelayanan TI. Hal ini dilakukan dengan cara melakukan penarikan server dari masingmasing Satminkal untuk diletakkan di data center yang baru. Jika Satminkal belum memiliki server namun membutuhkannya, maka Satminkal tersebut bisa melakukan permintaan pelayanan kepada Pusdata, baik untuk pengadaan server maupun administrasi dengan memanfaatkan server yang ada di data center yang baru.

ATN

:

Berapa jumlah server yang ada di Kementerian Pekerjaan Umum?

ARF

:

Saat ini Kementerian Pekerjaan Umum memiliki 30 server yang terbagi menjadi dua tempat, yaitu 20 server pada data center 1 (di Gedung Pusdata) dan 10 server pada data center 2 (di Gedung utama baru). Selain serverserver tersebut, masih terdapat perangkat komputasi lain yang masih bersifat silo-silo di Pusdata dan di masing-masing Satminkal. Hal ini mengakibatkan sulitnya koordinasi baik dalam hal kepemilikan dan pengembangan teknologi dan kapasitas serta interoperabilitas data antar Satminkal.

ATN :

Berapa jumlah aplikasi TI yang aktif ?Bagaimana pembagian level atau tingkat kepentingan dari seluruh aplikasi tersebut?

ARF :

Terdapat aplikasi sejumlah server yang aktif, yaitu >= 20 aplikasi. Pembagian level kepentingannya dilihat dari scope penggunaannya.  Seluruh Kementerian(High): webmail, emon,eproc  Aplikasi untuk Satminkal (Medium)  Website di tiap Satminkal (Low)

ATN :

Ada berapa SI sebagai layanan bisnis dan berapa sistem pendukung operasionalnya?

ARF :

Kepemilikan aplikasi:  Milik Satminkal: <= 10 server (Biro kepegawaian, biro keuangan dll)  Nitip : >= 10 aplikasi  Aplikasi Pusdata sendiri : >= 6

ATN :

Apakah masih terdapat server yang tidak aktif dalam posisi “on” dimana masih mengkonsumsi daya listrik?



182

Transkrip Wawancara

ARF :

Di dalam data center Kemen PU terdapat 1 server untuk 1 aplikasi (dedicated) sehingga tidak ada yang server yang idle. Jika dalam waktu 6 bulan tidak aktif, maka Pusdata akan mematikannya (off).

ATN :

Apakah ada server yang bersifat hibah?

ARF :

Ada. 1 set server dari Bakosurtanal. Diberikan pada akhir tahun 2012. Fungsinya sebagai penghubung data Bakosurtanal dengan entitas di Kemen PU.

ATN :

Menurut informasi yang saya dapat dari Pak Rema, pihak Pusdata memiliki rencana untuk implementasi teknologi cloud computing. Mengapa anda merekomendasikan untuk cloud computing? Apa jenis layanannya dan model pengembangannya?

ARF :

Agar pengelolaan infrastruktur bisa lebih efisien. Sementara baru memiliki rencana untuk pembangunan IaaS (Infrastructure as a Service) dengan model pengembangan private cloud. Model pengembangan private cloud dipilih karena Kementerian PU saat ini ingin berfokus pada pembangunan infrastruktur TI secara mandiri serta

ingin

meningkatkan

kemampuan

pegawai

dalam

hal

pembangunan dan pemeliharaan infrastruktur TI. Selain itu, dengan implementasi private cloud ini, transaksi dan lalu lintas data antar Satminkal dalam Kementerian lebih terjaga karena data dimiliki dan berada di Kementerian Pekerjaan Umum, bukan di tangan pihak ketiga sedangkan implementasi awal dari model layanan IaaS diwujudkan dengan pembangunan sistem virtualisasi server. ATN

:

Menurut Bapak, dalam membuat rancangan arsitektur TI berbasis cloud computing, apa saja yang harus dijadikan acuan atau pedoman? Dalam hal ini prinsip arsitektur?



183

Transkrip Wawancara ARF

:

Akses terhadap layanan yang disediakan oleh Pusdata pada khususnya dan Kementerian PU pada umumnya semakin mudah dilakukan dan mendorong layanan terpadu Kementerian PU. Dalam rangka menyediakan layanan publik menggunakan TI, bisa saja mengalami beberapa gangguan, misalkan gempa bumi, kebakaran ataupun kesalahan pengelolaan data. Diharapkan TI mampu memulihkan layanan dengan cepat tanpa hilangnya kualitas layanan.

ATN

:

Terkait dengan data, apa saja yang harus diperhatikan dalam pengelolaannya pak?

ARF

:

Data harus aman, baik secara fisik maupun lojik. Selain itu, data juga bisa digunakan bersama-sama, dapat diakses oleh inter Satminkal maupun antar Satminkal.

ATN

:

Masih mengenai data. Kira-kira untuk memproteksi data, teknik apa yang mungkin dilakukan oleh Pusdata dan apa alasannya?

ARF

:

Pada saat ini, teknik proteksi data yang mungkin bisa dilakukan oleh Pusdata yaitu dengan menerapkan teknik RAID 5. Jenis RAID 5 dianggap sesuai dengan kondisi Kementerian PU saat ini karena dalam pengelolaan hard disk nya relatif lebih sederhana dan tidak memerlukan biaya yang cukup tinggi jika dibandingkan RAID 1.

ATN

:

Terkait dengan teknologi, apa saja yang harus diperhatikan dalam persiapan dan pengelolaannya?

ARF

:

Teknologi atau infrastruktur yang ada sebisa mungkin bisa sharing dalam penggunaannya.

ATN :

Bagaimana struktur organisasi TI atau yang mengelola semua sumber daya TI di PU?

ARF :

Secara struktur, pengelola TI ada di masing-masing Satminkal maupun di Pusdata. Khusus untuk pengelolaan data center, dilakukan oleh sub bidang manajemen jaringan, Pusdata.



184

Lampiran 3 Kepmen PU Nomor: 489A/KPTS/M/2007 Keputusan Menteri Pekerjaan Umum Nomor: 489A/KPTS/M/2007 Tentang Penunjukan Unit Kliring Data dan Informasi Departemen Pekerjaan Umum.



185



186



187



UNIVERSITAS INDONESIA PERANCANGAN ARSITEKTUR TEKNOLOGI INFORMASI: STUDI KASUS KEMENTERIAN PEKERJAAN UMUM KARYA AKHIR ATINA DWI PALUPI

Recommend Documents