i
SKRIPSI
PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN
TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI
KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN
KOTA TANGERANG SELATAN)
Disusun Oleh:
Ines Putri Karunia
NIM: 1110093000041
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
2015M/1435H
i
SKRIPSI
PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN
TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI
KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN
KOTA TANGERANG SELATAN)
Disusun Oleh:
Ines Putri Karunia
NIM: 1110093000041
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
2015M/1435H
ii
SKRIPSI
PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN
TOGAF ARCHITECTURE DEVELOPMENT METHOD
(STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN
PERMUKIMAN KOTA TANGERANG SELATAN)
Oleh:
Ines Putri Karunia
NIM: 1110093000041
Skripsi
Sebagai Salah Satu Syarat Untuk Memperoleh Gelar Sarjana Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Syarif Hidayatullah
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
2015M/1435H
iii
PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN
TOGAF ARCHITECTURE DEVELOPMENT METHOD
(STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN
PERMUKIMAN KOTA TANGERANG SELATAN)
Skripsi
Diajukan kepada Fakultas Sains dan Teknologi
Untuk Memenuhi Persyaratan Memperoleh
Gelar Sarjana Sistem Informasi (S.SI)
Oleh :
Ines Putri Karunia
NIM : 1110093000041
Menyetujui,
Pembimbing I
Elvi Fetrina, MIT
NIP. 19740625 200901 2 005
Pembimbing II
Evy Nurmiati, MMSI
NIP.
Mengetahui,
Ketua Program Studi Sistem Informasi
Nia Kumaladewi, MMSI
NIP. 19750412 200710 2 002
iv
PENGESAHAN UJIAN
Skripsi yang berjudul “Perancangan Enterprise Architecture Menggunakan
TOGAF Architecture Development Method (Studi Kasus: Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan)” telah diuji dan dinyatakan
lulus dalam sidang munaqosyah Fakultas Sains dan Teknologi UIN Syarif
Hidayatullah Jakarta pada hari 6 Agustus 2015. Skripsi ini telah diterima sebagai
salah satu syarat untuk memperoleh gelar sarjana strata (S1) pada program studi
Sistem Informasi.
Jakarta, 26 Agustus 2015
Menyutujui,
Penguji I Penguji II
A’ang Subiyakto, M.Kom Suci Ratnawati, MTI
NIP. 1976021920070 1 002 NIP.
Pembimbing I Pembimbing II
Elvi Fetrina, MIT Evy Nurmiati, MMSI
NIP. 19740625200901 2 005 NIP.
Mengetahui,
Dekan Fakultas Sains dan Teknologi Ketua Prodi Sistem Informasi
Dr. Agus Salim, S.Ag, M.Si Nia Kumaladewi, MMSI
NIP. 197208161999031003 NIP. 1975041200710 2 002
v
PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-
BENAR HASIL KARYA SENDIRI DAN BELUM PERNAH DIAJUKAN
SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN
TINGGI ATAU LEMBAGA MANAPUN.
Jakarta, 9 Juli 2015
Ines Putri Karunia
vi
ABSTRAK
Ines Putri Karunia (1110093000041), Perancangan Enterprise Architecture
Menggunakan TOGAF (Studi Kasus: Dinas Tata Kota, Bangunan dan
Permukiman Kota Tangerang Selatan). Dibawah Bimbingan ELVI FETRINA,
MIT dan EVY MURMIATI, MMSI.
Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan
(DTKBDP) merupakan instansi milik pemerintah dibawah pimpinan
pemerintahan daerah kota Tangerang Selatan. DTKBDP mempunyai peran
penting dalam melaksanakan kegiatan pembangunan dan perbaikan sarana
pemerintahan dan non pemerintahan kota Tangerang Selatan, serta mempunyai
tanggung jawab dalam memberikan pelayanan perizinan pada setiap bangunan
atau permukiman yang akan dibangun di Tangerang Selatan. Dalam
perkembangannya, DTKBDP telah memiliki infrastruktur teknologi yang cukup
bagus, namun aplikasi yang digunakan dalam mendukung pelaksanaan tugasnya
hanyalah aplikasi standar yang tidak saling terintegrasi. Hal ini disebabkan karena
tidak adanya perencanaan teknologi informasi dan sistem informasi yang selaras
dengan proses bisnis dalam DTKBDP. Tidak adanya database management
system mejadikan penyimpanan dokumen, data serta informasi tidak tersusun
dengan baik. Oleh karena itu dibutuhkan suatu perancangan enterprise
architecture sebagai kerangka dasar solusi bisnis untuk menyelesaikan masalah
dalam mengoptimalkan penggunaan TI yang dimiliki. Penelitian ini menggunakan
TOGAF (The Open Group Architecture Framework) yang terdiri dari fase
preliminary, arsitektur visi, arsitektur bisnis, arsitektur sistem informasi, arsitektur
teknologi peluang dan solusi, serta rencana migrasi. Dari semua fase tersebut akan
dihasilkan blueprint arsitektur dan roadmap implementasi aplikasi untuk
DTKBDP.
Kata Kunci : DTKBDP, enterprise architecture, teknologi informasi, sistem
informasi, database management system, TOGAF
V Bab + 204 Halaman + 55 Gambar + 40 Tabel + 22 Pustaka + Lampiran
Pustaka Acuan (20, 2005-2013)
vii
KATA PENGANTAR
Alhamdulillahhirobal’alamin. Dengan mengucapkan puji dan syukur
kehadirat Allah SWT yang telah memberikan rahmat dan hidayah-Nya sehingga
penulis dapat menyelesaikan skripsi ini. Shalawat serta salam tak lupa tersirah
untuk Nabi Muhammad SAW beserta keluarga dan sahabatnya. Amiin.
Skripsi yang berjudul “Perancangan Enterprise Architecture
Menggunakan TOGAF Architecture Development Metod (Studi Kasus: Dinas
Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan-DTKBDP)
ini disusun sebagai salah satu syarat untuk mendapatkan gelar Sarjana Sistem
Informasi pada Universitas Islam Negeri Syarif Hidayatullah Jakarta, dan
akhirnya telah rampung diselesaikan oleh penulis dengan sebaik-baiknya.
Berkenaan dengan selesainya penyusunan skripsi, maka dengan rasa
syukur serta hormat penulis mengucapkan terima kasih pada semua pihak yang
telah memberikan bantuan, bimbingan, dan pengarahan serta dukungan moril dan
materil. Oleh karena itu, dalam kesempatan ini penulis mengucapkan terima kasih
yang sebesar-bersanya kepada:
1. Bapak Dr. Agus Salim, M.Si selaku Dekan Fakultas Sains dan Teknologi
UIN Syarif Hidayatullah Jakarta.
2. Ibu Nia Kumaladewi, MMSI selaku Ketua Program Studi Sistem
Informasi.
viii
3. Ibu Elvi Fetrina, MIT selaku Dosen Pembimbing I yang dengan sabar
membimbing penulis, memberikan ilmu dan motivasi selama proses
penyusunan skripsi.
4. Ibu Evi Nurmiati, MMSI selaku Dosen Pembimbing II yang dengan sabar
membimbing penulis, memberikan ilmu dan motivasi selama proses
penyusunan skripsi.
5. Seluruh dosen prodi Sistem Informasi yang telah memberikan ilmunya.
6. Bapak Heri Asari S.Kom, Msi, selaku pembimbing dari Bidang IT
DTKBDP.
7. Untuk semua staff dan pegawai DTKBDP yang telah membantu penulis
dalam memperoleh kelengkapan data yang dibutuhkan.
8. Ayah dan mama, H. Abi Sindu Harto dan Marlina, kedua orangtuaku yang
sangat aku cintai dan sayangi, terimakasih telah merawat dan
membimbingku hingga sekarang atas cinta dan kasih sayang serta motivasi
dan doa yang selalu diberikan kepada anakmu ini. Tanpa kalian aku
bukanlah apa-apa.
9. Terimakasih juga kepaa adik-adikku, Ira dan Anya yang secara tidak
langsung turut membantu dan memberikan dukungan dalam
menyelesaikan skripsi ini.
10. Untuk Pulung Wibowo, SE terimakasih atas semangatnya serta dukungan
untuk penulis, sehingga skripsi ini bisa selesai.
11. Untuk SIB wati, omah, alep, putri, minyi, tiwi, ika, ibon dan nda.
Terimakasih selama 5 tahun ini kalian sudah menjadi sahabat bahkan lebih
ix
dari sahabat, suka dan duka kita lewati ebrsama. Semoga kita bisa meraih
kesuksesan dimasa depan. Amin.
12. Seluruh teman kelas Sistem Infromasi B 2010, semga kekompakkan kita
bisa bertahan hingga selamanya.
13. Terimakasih untuk keluarga serta sahabat-sahabat sepermainan yang juga
turut memberikan dukungan kepada penulis.
14. Dan pihak-pihak yang terkait dan berjasa dalam proses pembuatan skripsi
ini yang mungkin tidak dapat disebutkan satu persatu tanpa mengurangi
rasa hormat terimakasih untuk kalian semua dari penulis.
Akhir kata, penulis berharap skripsi ini bermanfaat bagi semua pihak
terutama kawan-kawan Sistem Informasi UIN Syarif Hidayatullah Jakarta, baik
sebagai karya tulis berupa informasi, perbandingan maupun dasar penelitian
materi lebih lanjut.
Jakarta, 29 Juni 2015
Ines Putri Karunia
x
DAFTAR ISI
HALAMAN SAMPUL.................................................................................... I
HALAMAN JUDUL......................................................................................... ii
HALAMAN PERSETUJUAN PEMBIMBING............................................. iii
HALAMAN PENGESAHAN UJIAN ............................................................ iv
HALAMAN PERNYATAAN.......................................................................... V
ABSTRAK .......................................................................................................... Vi
KATA PENGANTAR .................................................................................. Vii
DAFTAR ISI .................................................................................................... X
DAFTAR GAMBAR ..................................................................................... Xiii
DAFTAR TABEL ........................................................................................... Xiv
BAB I PENDAHULUAN
1.1 Latar Belakang ........................................................................................ 1
1.2 Rumusan Masalah .................................................................................... 6
1.3 Batasan Masalah ....................................................................................... 7
1.4 Tujuan Penelitian ....................................................................................... 8
1.5 Manfaat Penelitian ..................................................................................... 9
1.6 Metode Penelitian ..................................................................................... 10
1.6.1 Metode Pengumpulan Data .............................................................. 10
1.6.2 Metode Perancangan ....................................................................... 10
1.7 Sistematika Penulisan ............................................................................... 13
xi
BAB II LANDASAN TEORI
2.1 Pengertian Perancangan .................................................................................... 15
2.2 Konsep Dasar Sistem Informasi....................................................................... 15
2.2.1 Pengertian Sistem............................................................................... 15
2.2.2 Pengertian Informasi........................................................................ 16
2.2.2.1 Kualitas Informasi................................................................ 17
2.2.3 Pengertian Sistem Informasi ............................................................ 17
2.3 Konsep Dasar Enterprise Architecture......................................................... 18
2.3.1 Pengertian Enterprise ...................................................................... 18
2.3.2 Pengertian Architecture.................................................................... 19
2.3.3 Pengertian Enterprise Architecture.................................................. 19
2.4 The Open Group Architecture Framework (TOGAF)............................... 21
2.4.1 TOGAF Architecture Development Method (ADM)....................... 22
2.4.2 Preliminary ..................................................................................... 24
2.4.3 Requirement Management............................................................... 26
2.4.2.1 Phase A : Architecture Vision.............................................. 27
2.4.2.2 Phase B : Business Architecture ......................................... 28
2.4.2.3 Phase C : Information Systems Architecture....................... 31
2.4.2.4 Phase D : Technology Architecture..................................... 33
2.4.2.5 Phase E : Opportunities and Solution ................................. 35
2.4.2.6 Phase F : Migration Planning............................................. 36
2.4.2.7 Phase G : Implementation Governance............................... 37
2.4.2.8 Phase H : Architecture Change Management..................... 39
xii
2.4.3 Kelebihan dan Kekurangan TOGAF................................................ 40
2.5 Tools Perancangan Arsitektur .................................................................... 41
2.5.1 Principle Catalog............................................................................ 41
2.5.2 Flowchart........................................................................................ 44
2.5.3 Value Chain ..................................................................................... 48
2.5.4 Stakeholder Map Matrix ................................................................. 50
2.5.5 Archimate........................................................................................ 51
2.5.6 Rich Picture..................................................................................... 52
2.5.7 Data Dissemination Diagram.......................................................... 53
2.5.8 Unified Modelling Laguage (UML) ............................................... 55
2.5.8.1 Sejarah UML....................................................................... 63
2.5.9 Principle Catalog ............................................................................ 64
2.5.10 Technology Portofolio Catalog .................................................... 65
2.5.11 Communication Engineering Diagram ........................................ 66
2.5.13 Matriks Analisis Gap..................................................................... 69
2.6 Metode Pengembangan Sistem rapid Application Development (RAD).. 69
2.6.1 Perencanaan Syarat (Requirement Planning).................................. 71
2.6.2 Proses Desain (Design Project)....................................................... 72
2.6.3 Implementasi (Implementation)....................................................... 73
2.7 Penelitian Sejenis....................................................................................... 73
BAB III METODOLOGI PENELITIAN
3.1 Metode Pengumpulan Data ................................................................... 47
3.1.1 Metode Observasi ........................................................................... 47
xiii
3.1.2 Metode Wawancara ......................................................................... 48
3.1.3 Metode Studi Pustaka ...................................................................... 50
3.1.4 Metode Studi Literatur .................................................................... 50
3.2 Metode Perancangan Enterprise Architecture ........................................... 55
3.2.1 Tahapan TOGAF.............................................................................. 55
3.2.2 Alasan Penulis Menggunakan TOGAF............................................ 60
3.3 Kerangka Berpikir Penelitian..................................................................... 61
BAB IV PERANCANGAN ENTERPRISE ARCHITECTURE
4.1 Preliminary Phase..................................................................................... 91
4.1.1 Prinsip-prinsip Perancangan Enterprise Architecture...................... 92
4.1.2 Identifikasi 5W+1H........................................................................ 96
4.2 Requirement Management........................................................................ 98
4.2.1 Kondisi Sistem Berjalan................................................................... 98
4.2.2 Issue Organisasi................................................................................ 110
4.2.3 Solusi Aktivitas................................................................................. 113
4.2.4 Data Inventaris Sarana dan Prasarana Pendukung TIK................... 115
4.3 Phase A : Architecture Vision................................................................... 115
4.3.1 Profil Instansi................................................................................... 115
4.3.2 Visi dan Misi Instansi..................................................................... 116
4.3.3 Struktur Organisasi dan Tupoksi DTKBDP................................... 117
4.3.4 Analisis Value Chain...................................................................... 121
4.3.5 Struktur Organisasi Usulan............................................................ 128
4.3.6 Pelatihan yang Diusulkan............................................................... 131
xiv
4.3.7 Hubungan Stakeholder dengan Aktivitas Organisasi...................... 133
4.4 Phase B: Business Architecture................................................................ 136
4.4.1 Pemetaan Layanan Bisnis, Proses Bisnis, dan Fungsi Bisnis di
DTKBDP.................................................................................................... 136
4.4.2 Rancangan Architecture Business.................................................... 145
4.5 Phase C: Information System Application................................................. 154
4.5.1 Application Architecture.................................................................. 154
4.5.5.1 Arsitektur Aplikasi Permohonan Rekomendasi IMB........... 158
4.5.5.2 Arsitektur Aplikasi Rekomendasi SLF................................. 160
4.5.5.3 Arsitektur Aplikasi SPK Lelang........................................... 161
4.5.5.4 Arsitektur Aplikasi Progress Bangunan............................... 163
4.5.5.5 Arsitektur Aplikasi E-inventaris........................................... 164
4.5.5.6 Arsitektur Aplikasi E-keuangan........................................... 165
4.5.2 Data Architecture............................................................................. 166
4.5.2.1 Data Dissemination Diagram................................................ 167
4.5.2.2 Class Diagram....................................................................... 168
4.6 Phase D: Technology Architecture............................................................. 174
4.6.1 Infrastruktur Jaringan....................................................................... 174
4.6.2 Platform Teknologi........................................................................... 178
4.6.3 Konfigurasi Hardware dan Software............................................... 180
4.6.4 Technolgy Portofolio Catalog........................................................... 182
4.7 Phase E: Opportunities and Solution......................................................... 183
4.7.1 Analisis Gap..................................................................................... 183
4.8 Phase E: Migration Planning.................................................................... 194
4.8.1 Urutan Implementasi........................................................................ 194
xv
4.8.2 Roadmaps......................................................................................... 198
4.8.2.1 Penjelasan Roadmaps........................................................... 199
BAB V PENUTUP
5.1 Kesimpulan................................................................................................ 203
5.2 Saran........................................................................................................... 204
DAFTAR PUSTAKA
LAMPIRAN-LAMPIRAN
xvi
Daftar Gambar
Gambar 2.1 ADM Process (The open Group, 2009).................................. 23
Gambar 2.2 Diagram Value chain (Porter, 1985)..................................... 49
Gambar 2.3 Contoh Rich Picure................................................................ 52
Gambar 2.4 Data Dissemination Diagram................................................. 54
Gambar 2.5 Contoh Model Use Case Diagram........................................ 59
Gambar 2.6 Contoh Model Class Diagram........................................... 62
Gambar 2.7 Contoh Communication Engineering Diagram.................... 67
Gambar 2.8 Platform Decomposition Diagram......................................... 68
Gambar 2.9 Fase Rapid Application Development (RAD)....................... 71
Gambar 3.1 Kerangka Penelitian.............................................................. 89
Gambar 4.1 Sistem Berjalan................................................................. 99
Gambar 4.2 Flowchart Sistem Berjalan Level 0................................... 102
Gambar 4.3 Flowchart Sistem Berjalan Bagian Rekomendasi IMB......... 104
Gambar 4.4 Flowchart Sistem Berjalan Bagian Rekomendasi SLF.......... 105
Gambar 4.5 Flowchart Sistem Berjalan Bagian Pendataan Hasil
Musrembang......................................................................... 106
Gambar 4.6 Flowchart Sistem Berjalan Bagian Design........................... 107
Gambar 4.7 Flowchart Sistem Berjalan Bagian Progress Bangunan...... 108
Gambar 4.8 Flowchart Sistem Berjalan Bagian Keuangan...................... 109
Gambar 4.9 Flowchart Sistem Berjalan Bagian Inventaris..................... 110
Gambar 4.10 Struktur Organisasi DTKBDP................................................ 117
Gambar 4.11 Value Chain............................................................................ 122
Gambar 4.12 Struktur Organisasi Usulan DTKBDP.................................... 128
Gambar 4.13 Tree Diagram Pemetaan Layanan, Proses Bisnis dan Fungsi
Bisnis
DTKBDP............................................................................... 138
Gambar 4.14 Layanan Bisnis di DTKBDP................................................. 139
Gambar 4.15 Proses Bisnis Pada Layanan IMB DTKBDP......................... 139
Gambar 4.16 Proses Bisnis Pada Layanan Pembangunan DTKBDP.......... 140
xvii
Gambar 4.17 Fungsi Bisnis pada Proses Bisnis Pendaftaran.................... 140
Gambar 4.18 Fungsi Bisnis pada Proses Bisnis Persidangan..................... 141
Gambar 4.19 Fungsi Bisnis pada Proses Bisnis Verifikasi Berkas SLF..... 142
Gambar 4.20 Fungsi Bisnis pada Proses Bisnis Pendataan....................... 142
Gambar 4.21 Fungsi Bisnis pada Proses Bisnis Design.............................. 143
Gambar 4.22 Fungsi Bisnis pada Proses Bisnis Progress Bangunan......... 144
Gambar 4.23 Solusi Arsitektur Bisnis.......................................................... 147
Gambar 4.24 Solusi Arsitektur Bisnis Rekomendasi IMB&SLF..................148
Gambar 4.25 Solusi Arsitektur Bisnis SPK Lelang........................................149
Gambar 4.26 Solusi Arsitektur Bisnis Solusi Bisnis Progress Bangunan...151
Gambar 4.27 Solusi Arsitektur Bisnis E-inventaris...................................... 152
Gambar 4.28 Solusi Arsitektur Bisnis E-keuangan....................................... 153
Gambar 4.29 Arsitektur Aplikasi................................................................. 157
Gambar 4.30 Arsitektur Aplikasi Permohonan Rekomendasi IMB............. 158
Gambar 4.31 Arsitektur Aplikasi Rekomendasi SLF................................ 160
Gambar 4.32 Arsitektur Aplikasi SPK Lelang......................................... 161
Gambar 4.33 Arsitektur Aplikasi Progress Bangunan................................ 163
Gambar 4.34 Arsitektur Aplikasi E-inventaris........................................... 164
Gambar 4.35 Arsitektur Aplikasi E-keuangan........................................... 165
Gambar 4.36 Data Dissemination Diagram............................................. 167
Gambar 4.37 Arsitektur Data Aplikasi IMB dan SLF................................ 169
Gambar 4.38 Arsitektur Data Aplikasi SPK Lelang................................... 170
Gambar 4.39 Arsitektur Data Aplikasi Progress Bangunan........................ 171
Gambar 4.40 Arsitektur Data Aplikasi E-inventaris.................................. 172
Gambar 4.41 Arsitektur Data Aplikasi E-keuangan................................... 173
Gambar 4.42 Arsitektur Jaringan Awal Keseluruhan DTKBDP................ 176
Gambar 4.43 Arsitektur Jaringan Usulan Keseluruhan DTKBDP.............. 177
Gambar 4.44 Platform Teknologi.............................................................. 178
Gambar 4.45 Roadmap Aplikasi................................................................. 198
xviii
DAFTAR TABEL
Tabel 2.1 Contoh Principle Catalog.............................................................................. 41
Tabel 2.2 Simbol Penghubung Flowchart...................................................................... 45
Tabel 2.3 Simbol Proses Flowchart............................................................................... 46
Tabel 2.4 Simbol Input-Output...................................................................................... 47
Tabel 2.5 Contoh Stakeholder Map Matrix.................................................................... 50
Tabel 2.6 Daftar Simbol Use Case Diagram................................................................. 57
Tabel 2.7 Daftar Simbol Class Diagram........................................................................ 61
Tabel 2.8 Principle Catalog........................................................................................... 64
Tabel 2.9 Technology Portofolio Catalog...................................................................... 66
Tabel 3.1 Perbandingan Penelitian Sejenis.................................................................... 79
Tabel 3.2 Daftar Simbol Kerangka Penelitian................................................................ 90
Tabel 4.1 Principle Catalog........................................................................................... 94
Tabel 4.2 5W+1H........................................................................................................... 96
Tabel 4.3 Permasalahan dalam Aktivitas Organisasi..................................................... 111
Tabel 4.4 Solusi Aktivitas.............................................................................................. 113
Tabel 4.5 data Inventaris Sarana dan Prasarana Pendukung TIK.................................. 115
Tabel 4.6 Target Value Chain........................................................................................ 126
Tabel 4.7 Daftar Pelatihan Usulan................................................................................. 131
Tabel 4.8 Stakeholder Map Matrix................................................................................ 133
Tabel 4.9 Penjelasan Keterlibatan Stakeholder di Setiap Aktivitas............................... 134
Tabel 4.10 Pemetaan Kendala.......................................................................................... 145
Tabel 411 Application Portofolio.................................................................................... 154
xix
Tabel 4.12 Konfigurasi Hardware................................................................................... 180
Tabel 4.13 Konfigurasi Software..................................................................................... 181
Tabel 4.14 Technology Portofolio Catalog...................................................................... 182
Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF............................................... 186
Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang.................................................. 187
Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan...................................... 188
Tabel 4.18 Analisis Gap Arsitektur Bisnis E-keuangan.................................................. 189
Tabel 4.19 Analisis Gap Arsitektur Bisnis E-inventaris.................................................. 189
Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP.................................................. 190
Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP........................................................ 191
Tabel 2.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP.................................... 192
Tabel 2.23 Analisis Gap Matriks Aplikasi Terhadap Data.............................................. 194
Tabel 2.24 Front Office System........................................................................................ 195
Tabel 4.25 Back Office System......................................................................................... 195
Tabel 4.26 Urutan Implementasi...................................................................................... 197
Tabel 4.27 Roadmap Aplikasi Tahun 2015...................................................................... 199
Tabel 4.28 Roadmap Aplikasi Tahun 2016...................................................................... 201
Tabel 4.29 Roadmap Aplikasi Tahun 2017...................................................................... 202
xx
Simbol Use Case Diagram
(Sugiarti, 2013)
Simbol Deskripsi
Use Case
Fungsionalitas yang disediakan sistem sebagai
unit-unit yang saling bertukar pesan antar unit
atau aktor; biasanya dinyatakan dengan
menggunakan kata kerja di awal frase nama
use case.
Nama Use Case
Orang, proses, atau sistem lain yang
berinteraksi dengan sistem informasi yang
akan dibuat di luar sistem informasi yang
akan dibuat itu sendiri; biasanya dinyatakan
menggunakan kata benda di awal frase nama
aktor.
Asosiasi (association)
Komunikasi antara aktor dan use case yang
berpartisipasi pada use case.
Ekstensi (extend)
Relasi use case tambahan ke sebuah use case
dimana use case yang ditambahkan dapat
berdiri sendiri walau tanpa use case
tambahan; biasanya use case tambahan
memiliki nama depan yang sama dengan use
case yang ditambahkan.
<<extend>>
xxi
Generalisasi (generalization)
Hubungan generalisasi dan spesialisasi
(umum – khusus) antara dua buah use case
dimana fungsi yang satu adalah fungsi yang
lebih umum dari lainnya.
Menggunakan (include)
Relasi use case tambahan ke sebuah use case
dimana use case yang ditambahkan
memerlukan use case ini untuk menjalankan
fungsinya atau sebagai syarat dijalankan use
case ini. Dua sudut pandang mengenai include
di use case, yaitu :
1. Include berarti use case yang ditambahkan
akan selalu dipanggil saat use case tambahan
dijalankan.
2. Include berarti use case yang tambahan
akan selalu melakukan pengecekan apakah
use case yang ditambahkan telah dijalankan
sebelum use case tambahan dijalankan.
Kedua sudut pandang tersebut dapat
digunakan salah satu atau keduanya,
tergantung pada pertimbangan dan sudut
pandang yang dibutuhkan.
<<include>>
xxii
Simbol Deskripsi
Kelas
Kelas pada struktur sistem.
Antarmuka (interface)
Sama seperti konsep interface
dalam pemrograman berorientasi
objek.
Asosiasi (association)
Relasi antar kelas dengan makna
umum; biasanya disertai dengan
multiplicity.
Asosiasi berarah (directed
association)
Relasi antar kelas dengan makna
kelas yang satu digunakan oleh
kelas yang lain; biasanya disertai
dengan multiplicity.
Generalisasi (generalization)
Relasi antar kelas dengan makna
generalisasi – spesialisasi (umum –
khusus).
Kebergantungan (depedency) Relasi antar kelas dengan makna
nama_kelas
+Attribute
+Operation()
Simbol Use Case Diagram
(Sugiarti, 2013)
xxiii
Simbol Business Service, Business Process, Business Function
(The Open Group, 2009)
Business Function
Elemen tindakan berdasarkan pada
sekumpulan kriteria yang dipilih
(kriteria yang dibutuhkan sumber
daya bisnis).
Triggering
Triggering menjelaskan tentang
hubungan sebab-akibat antara
proses-proses.
Flow
Flow menjelaskan tentang
pertukaran informasi diantara
proses bisnis dan fungsi bisnis.
kebergantungan antar kelas.
Simbol Keterangan
Business Service
Layanan yang memenuhi kebutuhan
bisnis untuk customer internal atau
eksternal organisasi.
Business Process
Elemen tindakan berdasarkan pada
urutan aktivitas. Proses bisnis
dimaksudkan untuk menetapkan
sekumpulan produk atau layanan
bisnis.
i
1
BAB I
PENDAHULUAN
1.1 Latar Belakang
Peranan sistem informasi dan teknologi dalam menjalankan proses bisnis
di era informasi saat ini sangat diperlukan. Teknologi merupakan salah satu solusi
terpenting untuk mengatasi dan membantu manusia dalam kehidupannya.
Semakin tinggi kebutuhan manusia akan teknologi, semakin tinggi pula kualitas
teknologi yang diharapkan.
Perkembangan teknologi informasi dalam dunia bisnis, ini akan menuntut
organisasi untuk melakukan perubahan dengan diterapkannya suatu perencanaan
bisnis yang matang agar dapat berjalan sesuai yang diharapkan perusahaan. Agar
suatu perencanaan bisnis bisa berjalan dengan baik, maka diperlukan sebuah tool
yang dapat digunakan untuk menyediakan struktur dasar organisasi pada
perusahaan secara menyeluruh serta dapat menggambarkan hubungan antar aspek-
aspek yang ada didalamnya. Tool yang dimaksudkan dalam hal ini adalah
Enterprise Architecture (EA).
Dinas Tata Kota, Bangunan dan Permukiman (DTKBDP) Kota Tangerang
Selatan terbentuk berdasarkan peraturan walikota No.59 Tahun 2009. Dinas Tata
Kota, bangunan dan Permukiman merupakan instansi milik pemerintah dibawah
pimpinan pemerintahan daerah kota Tangerang Selatan. Dinas Tata Kota,
Bangunan dan Permukiman mempunyai peran penting dalam melaksanakan
2
kegiatan pembangunan atau pemeliharaan sarana dan prasarana pemerintahan atau
non pemerintahan yang berada di kota Tanggerang Selatan, serta mempunyai
tanggung jawab dalam memberikan pelayanan perizinan pada setiap bangunan
atau permukiman yang akan dibangun disekitar daerah kota Tangerang Selatan.
Dalam menjalankan tupoksi tersebut, Dinas Tata Kota, Bangunan dan
Permukiman dituntut untuk menyiapkan kebutuhan-kebutuhan yang diperlukan,
salah satunya adalah infrastruktur SI/TI untuk membantu mencapai tujuan yang
telah ditetapkan.
Namun dalam pelaksanaannya Dinas Tata Kota, Bangunan dan
Permukiman belum menggunakan perencanaan Enterprise Architecture.
Sehingga proses bisnis tersebut belum berjalan secara optimal. Dinas Tata Kota,
Bangunan dan Permukiman mempunyai lebih dari satu perangkat komputer yang
dimiliki oleh setiap bagian di dalam organisasi, namun investasi tersebut dirasa
belum mampu menunjang proses bisnis seperti yang terjadi pada pelayanan proses
bisnis untuk pengajuan permohonan perizinan mendirikan bangunan (IMB) di
daerah Tangerang Selatan yang masih menggunakan ms.office, dikarenakan
mereka belum mempunyai suatu aplikasi khusus untuk melaksanakan kegiatan
pelayanan pada IMB. Selain menyediakan pelayanan IMB, DTKBDP juga
melaksanakan pembangunan dan perbaikan di Tangerang Selatan, namun dalam
pelaksanaan proses pencatatan pembangunan, pemeliharaan bangunan, dana untuk
proses pembangunan dan perbaikan bangunan, serta pada proses pelaksanaan
lelang juga masih menggunakan ms.office, pada pelaksanaan lelang DTKBDP
masih harus mencari sendiri kontraktor yang nantinya akan membangun bangunan
3
tersebut. Serta untuk mengetahui progress bangunan, pencatatan BMN (Barang
Milik Negara) dan keuangan, DTKBDP belum mempunyai sistem khusus,
sehingga pencatatan tersebut dilakukan hanya menggunakan ms.office. Hal ini
juga disebabkan oleh tidak adanya database management system yang dimiliki.
Maka dari itu diperlukan suatu perancangan arsitektur TI dalam Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan untuk dapat
mengintegrasikan sistem informasi dan database dalam DTKBP Tangsel.
EA merupakan suatu perencanaan, perancangan dan pengelolaan
infrastruktur SI/TI, serta mampu mengintegrasikan SI/TI didalam suatu arsitektur.
Menurut The Open Group (2009), dapat disimpulkan Enterprise Architechture
adalah blueprint organisasi yang menentukan bisnis, informasi, dan teknologi
yang digunakan agar tercapai misi organisasi. Enterprise Architecture berfungsi
sebagai penyedia cetak biru atau kerangka dasar (blueprint) untuk sistem dan
selama proses berlangsungnya proyek pengembangan sistem tersebut. EA
dikonsentrasikan pada infrastruktur yang meliputi hardware, software dan
network untuk dapat bekerja secara bersama dengan misi, sasaran, dan tujuan
organisasi untuk menjalankan proses bisnis organisasi dengan didukung oleh
Teknologi Informasi. Berbagai macam paradigma dan metode dapat digunakan
dalam perancangan enterprise architecture diantaranya adalah Zachman, TOGAF,
FEA dan gartner.
The Open Group Architecture Framework (TOGAF) merupakan salah
satu acuan kerangka kerja untuk melakukan pengembangan, penerapan, dan
pengelolaan arsitektur di bidang Teknologi Informasi pada sebuah
4
organisasi/perusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsip-
prinsip yang memberikan keleluasaan dalam memilih teknik pemodelan yang
digunakan dan merupakan panduan gabungan dari berbagai framework
pengembangan arsitektur (FEAF, TEAF, DoDAF, dsb).
“TOGAF memberikan metode yang detail mengenai bagaimana
membangun, mengelola dan mengimplementasikan arsitektur enterprise dan
sistem informasi yang disebut dengan Architecture Development Method (ADM)
(Surendro, 2009)”. Menjelaskan bagaimana menemukan sebuah arsitektur
perusahaan/organisasi secara khusus berdasarkan kebutuhan bisnisnya dan proses.
Selain itu TOGAF memiliki Resource Base yang memberikan sumber-sumber
informasi berupa guidelines, templates, checklists, latar belakang informasi dan
detil material pendukung yang membantu arsitek di dalam penggunaan ADM.
Resource Base juga menyediakan banyak material referensi.
Berbeda dengan TOGAF, framework Zachman adalah framework EA
yang menyediakan enam sudut pandang yang dijelaskan dalam sebuah cube.
Keenam sudut pandang tersebut adalah planner, owner, designer, builder,
subcontractor, builder, dan functioning.
Sedangkan FEAF menyediakan sebuah struktur untuk mengembangkan,
memelihara dan mengimplementasikan lingkungan operasional di top-level dan
mendukung implementasi dari sistem TI, namun FEAF tidak memiliki proses
arsitektur yang detil dan tidak ada standarisasinya.
5
Terdapat beberapa penelitian di bidang EA menggunakan TOGAF yang
mendukung kesiapan dan kemampuan menggunakan TI, diantaranya oleh Vivi
Vydiani (2013) yang membuat Perancangan Model enterprise Architecture
Dengan Menggunakan TOGAF ADM Pada PT. SATYA KARYA UTAMA, Riffa
Ruffaida (2012), Perancangan Arsitektur Teknologi Informasi Rumah Sakit
dengan TOGAF (The Open Group Architecture Framework), dan Syafrizal
(2013), Perencanaan Arsitektur Enterprise Menggunakan Kerangka Kerja Togaf
Pada Kantor Pelayanan Umum dan Perizinan Kabupaten Solok Selatan). Ketiga
penelitian ini dilakukan untuk menganalisis kebutuhan dari infrastruktur teknologi
informasi secara menyeluruh dan terpadu untuk mencapai visi dan misi lembaga
menggunakan TOGAF.
Dengan permasalahan dan fakta yang sudah diuraikan diatas, maka
penulis tertarik untuk membuat perancangan Enterprise Architecture dalam
perencanaan SI/TI di Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan dengan menggunakan framework TOGAF ADM (The Open
Group Architecture Framework). Oleh sebab itu, penulis mengajukan penelitian
sesuai dengan latar belakang yang telah diuraikan diatas dengan judul
“PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN
TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI KASUS
DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA
TANGERANG SELATAN)”.
6
1.2 Rumusan Masalah
Berdasarkan latar belakang yang sudah dipaparkan di atas, maka dapat
diidentifikasi masalah sebagai berikut.
1) Dinas Tata Kota, Bangunan dan Permukiman belum memiliki arsitektur
sistem informasi untuk menyelaraskan strategis SI/TI dengan strategi
bisnis.
2) DTKBP belum memiliki arsitektur sistem informasi untuk merancang
proses integrasi aplikasi DTKBP dan sistem basis data.
3) DTKBP belum memiliki arsitektur bisnis untuk merancang kegiatan di
dalam DTKBP yang meliputi, pelayanan permohonan perizinan serta
proses pembangunan sarana dan prasarana pemerintahan dan non
pemerintahan serta administrasi.
4) DKTBP belum memiliki arsitektur teknologi yang berguna untuk
kepentingan investasi hardware, software, dan networking.
Dari masalah yang telah diidentifikasi, maka dapat dirumuskan masalah
“Bagaimana membuat perancangan enterprise architecture untuk
mengoptimalkan kegiatan dan layanan di dalam Dinas Tata Kota, Bangunan
dan Permukiman agar dapat berjalan dengan efektif dan efisien?”
7
1.3 Batasan Masalah
Berdasarkan dari rumusan masalah di atas, maka batasan dari penelitian
ini adalah :
1) Penelitian ini dilakukan di Dinas Tata Kota, Bangunan dan Permukiman
Kota Tangerang Selatan pada keseluruhan divisi organisasi.
2) Bisnis proses yang dilakukan hanya membahas proses tahapan awal
melakukan permohonan mendirikan pembangunan, survei lokasi proyek
sampai mendapatkan surat perizinan pembangunan. Serta untuk internal
DTKBDP sampai pada tahap proses pembangunan dan perbaikan sarana
dan prasaran di Tangerang Selatan. Dan tidak membahas bagian SDM.
3) Framework yang digunakan pada penelitian ini adalah The Open Group
Framework (TOGAF) dengan menggunakan Architecture Development
Method (ADM) sebagai metode pengembangan arsitektur. Penelitian ini
dibatasi hanya pada fase preliminary, arsitektur visi, arsitektur bisnis,
arsitektur sistem informasi, arsitektur teknologi, peluang dan solusi, serta
perencanaan migrasi. Penelitian ini tidak membahas fase implementasi dan
manajemen perubahan arsitektur.
4) Tools yang digunakan dalam penelitian ini untuk menggambarkan model
arsitektur, yaitu UML (Unified Model Language), Principle Catalog,
Technology Portfolio Catalog, Communication Engineering Diagram,
Matrix Gap Analysis dan Analisis Value Chain. Diagram UML yang
digunakan, yaitu Use Case Diagram, Activity Diagram, dan Class
Diagram.
8
1.4 Tujuan Penelitian
Tujuan umum dari penelitian ini adalah menghasilkan rancangan
Enterprise Architecture pada Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan. Sedangkan tujuan khusus dari penelitian ini menghasilkan:
1. Rancangan suatu kerangka kerja berdasarkan konsep EA dengan
menggunakan metode TOGAF Architecture Development Method.
2. Analisis kebutuhan dari EA secara menyeluruh dan terpadu yang
dibutuhkan oleh perusahaan.
3. Rancangan Arsitektur Visi Perusahaan untuk melakukan identifikasi dan
memprioritaskan komponen dari arsitektur saat ini.
4. Rancangan Arsitektur Bisnis Perusahaan yang menggambarkan strategi
produk dan layanan serta aspek lingkungan bisnis (organisasi, fungsi,
proses, dan informasi) berdasarkan pada prinsip bisnis, tujuan bisnis, dan
penggerak strategi.
5. Rancangan Arsitektur Sistem Informasi yang terdiri atas arsitektur data
yang menetapkan tipe dan sumber utama data yang diperlukan untuk
mendukung proses bisnis dan arsitektur aplikasi yang menetapkan jenis
sistem aplikasi utama yang dibutuhkan untuk mengolah data dan
mendukung bisnis.
6. Rancangan Arsitektur teknologi yang memetakan komponen aplikasi
yang telah ditetapkan pada fase arsitektur aplikasi ke dalam satu set
komponen teknologi yang mewakili komponen software dan hardware.
9
7. Rancangan Peluang dan Solusi untuk menghasilkan sebuah implementasi
keseluruhan dan strategis migrasi dan sebuah rencana implementasi.
8. Rancangan Perencanaan Migrasi untuk memilih proyek implementasi
yang bervariasi menjadi urutan prioritas.
1.5 Manfaat Penelitian
Diharapkan dengan adanya penelitian ini dapat memberikan manfaat
berikut :
1. Memberikan gambaran tentang keselarasan proses bisnis dengan teknologi
untuk pengembangan arsitektur SI/TI pada Dinas Tata Kota, Bangunan
dan Permukiman.
2. Memberikan blueprint sebagai landasan untuk pengembangan SI/TI.
3. Memberikan pemahaman terhadap penggunaan metode TOGAF
Architecture Development Method dalam merancang Enterprise
Architecture.
4. Sebagai referensi utuk penelitian selanjutnya dibidang kajian Enterprise
Architecture.
10
1.6 Metodologi Penelitian
1.6.1 Metode Pengumpulan Data
Metodologi ini terdiri dari dua macam, yaitu metodologi pengumpulan
data dan perancangan Enterprise Architecture. Metodologi pengumpulan data-data
yang telah dilakukan penulis adalah sebagai berikut :
1. Observasi dengan cara mengamati langsung objek untuk mendapatkan
data responden (Hartono, 2008).
2. Wawancara, merupakan komunikasi dua arah untuk mendapatkan data
responden (Hartono, 2008).
3. Studi Pustaka, dengan mencari sumber data sekunder yang akan
mendukung penelitian (Nazir, 2005).
1.6.2 Metode Perancangan
Untuk metodologi perancangan Enterprise Architecture adalah
menggunakan metodologi TOGAF ADM. Ada 7 tahapan yang akan dilakukan
pada skripsi ini, yaitu:
1. Preliminary Phase
Fase preliminary merupakan tahap awal untuk persiapan
perencanaan arsitektur enterprise. Tahapan ini dilakukan agar proses
pemodelan arsitektur dapat terarah dengan baik. Tahapan ini
menghasilkan prinsip-prinsip arsitektur yang merupakan bagian dari
11
kebijakan teknologi informasi perusahaan yang akan mempengaruhi
keseluruhan proses desain dan untuk meyakinkan setiap orang yang
terlibat di dalamnya bahwa pendekatan ini berkomitmen untuk
kesuksesan proses arsitektur.
2. Phase A : Architecture Vision
Fase A bertujuan untuk menciptakan keselarasan pandangan
bagaimana pentingnya EA untuk pencapaian tujuan perusahaan dan
menentukan lingkup dari arsitektur yang akan dikembangkan dan
memetakan strategi. Visi arsitektur adalah kesempatan utama untuk
menjual keuntungan dari pengembangan yang disarankan kepada
pembuat keputusan enterprise sehingga memungkinkan tujuan bisnis
tanggap kepada penggerak strategis, sesuai dengan prinsip dan mencapai
maksud dan tujuan stakeholder, klarifikasi tujuan tersebut dan
menunjukkan bagaimana tujuan dapat dicapai oleh pengembangan
arsitektur yang disarankan.
3. Phase B : Business Architecture
Pada fase B, aspek bisnis dari proyek akan diperiksa. Fase ini
melibatkan pemodelan secara ekstensif dari arsitektur saat ini
menggunakan alat bantu seperti model business use case.
12
4. Phase C : Information System Architecture
Fase C berfokus pada arsitektur data dan arsitektur aplikasi. Pada
arsitektur data, harus ditentukan tipe dan sumber data utama yang
diperlukan untuk mendukung bisnis. Pada arsitektur aplikasi, ditentukan
jenis aplikasi penting untuk memproses data dan mendukung bisnis.
Kemudian, dibuat matriks dari aplikasi saat ini dan arsitektur aplikasi
tujuan, melakukan analisis gap dan melakukan korelasi fungsi bisnis
dengan aplikasi tujuan.
5. Phase D : Technology Architecture
Fase D berupa untuk memetakan komponen aplikasi yang
didefinisikan dalam arsitektur aplikasi menjadi satu set komponen
teknologi yang mewakili komponen software, hardware, dan jaringan,
dengan cara membeli ke pihak luar atau dikonfigurasi sendiri oleh
perusahaan ke dalam platform teknologi.
6. Phase E : Opportunities dan Solutions
Pada fase E akan dievaluasi model yang telah dibangun untuk
arsitektur saat ini dan target. Identifikasi proyek utama akan dilaksanakan
untuk mengimplementasikan arsitektur tujuan dan klasifikasi sebagai
pengembangan baru atau penggunaan kembali sistem yang sudah ada.
13
7. Phase F : Migration Planning
Pada fase F akan dilakukan analisis risiko dan biaya. Tujuan fase ini
untuk memilih proyek implementasi yang bervariasi menjadi urutan
prioritas. Aktivitasnya mencakup penaksiran ketergantungan, biaya,
manfaat dari proyek migrasi yang bervariasi.
1.2 Sistematika Penulisan
Dalam penyusunan skripsi ini, dilakukan pembahasan dengan membagi
kedalam 5 bab. Pembagian tersebut dapat dijelaskan dengan struktur sebagai
berikut :
BAB I PENDAHULUAN
Bab ini menguraikan tentang latar belakang masalah,
rumusan masalah, batasan masalah, tujuan dan manfaat
penelitian, metode penelitian yang digunakan dan
sistematika penulisan.
BAB II LANDASAN TEORI
Dalam bab ini akan diuraikan mengenai landasan teori yang
digunakan dalam pembahasan penulisan skripsi ini dan
sumber landasan teori tersebut.
BAB III METODOLOGI PENELITIAN
Pada bab ini berisi uraian metode penelitian yang
mencakup metode pengumpulan data dan metode
14
perancangan pada Dinas Tata Kota, Bangunan dan
Permukiman.
BAB IV PERANCANGAN ENTERPRISE ARCHITECTURE
Bab ini menjelaskan perancangan Enterprise Architecture
Dinas Tata Kota, Bangunan dan Permukiman menggunakan
TOGAF berdasarkan analisis dari data data yang telah
diperoleh.
BAB V PENUTUP
Bab ini berisikan beberapa kesimpulan dan saran serta
rekomendasi atas penelitian yang telah dilakukan.
i
15
BAB II
LANDASAN TEORI
2.1 Pengertian Perancangan
Perancangan adalah sebuah proses untuk mendefinisikan sesuatu yang akan
dikerjakan dengan menggunakan teknik yang bervariasi serta di dalamnya
melibatkan deskripsi mengenai arsitektur serta detail komponen dan juga
keterbatasan yang akan dialami dalam proses pengerjaannya (Rizky, 2011).
Proses perancangan memiliki tiga unsur penting yakni : pengetahuan
mengenai teknik perancangan, kebutuhan sistem, serta kendala yang mungkin
terjadi (Rizky, 2011).
2.2 Konsep Dasar Sistem Informasi
2.2.1 Pengertian Sistem
Menurut Jogiyanto (2005), “Sistem adalah suatu kumpulan komponen
yang saling berhubungan satu dengan yang lainnya untuk mencapai sebuah tujuan
tertentu”. Menurut Agus Mulyanto (2009), “Sistem adalah kumpulan elemen-
elemen yang berinteraksi untuk mencapai suatu tujuan tertentu sebagai satu
kesatuan”. Selain itu ada pengertian lain tentang sistem menurut Sanyoto
Gondodiyoto (2007), “Sistem adalah kumpulan elemen-elemen atau sumber daya
yang saling berkaitan secara terpadu, dan bertujuan untuk mencapai tujuan
tertentu”.
15
16
Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem adalah
suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul
bersama-sama untuk melakukan suatu kegiatan atau menyelesaikan suatu sasaran
tertentu.
2.2.2 Pengertian Informasi
Definisi informasi menurut Agus Mulyanto (2009), “Informasi
merupakan pengetahuan dari hasil pengolahan data-data yang berhubungan
menjadi sebuah kesimpulan, pengolahan data yang dibentuk agar berguna bagi
pemakainya”. Menurut Sanyoto Gondodiyoto (2007), “Informasi adalah
merupakan data yang sudah diolah menjadi bentuk yang lebih berguna dan lebih
berarti (bermanfaat) bagi penerimanya, menggambarkan suatu kejadian dan
kesatuan nyata yang dapat dipahami dan dapat digunakan untuk pengambilan
keputusan, sekarang maupun untuk masa depan”.
Dari beberapa pengertian diatas, dapat disimpulakan informasi
merupakan hasil dari pengolahan data. Sedangkan data merupakan kenyataan
yang menggambarkan suatu kejadian-kejadian yang nyata. Data sering kali
disebut sebagai bahan mentah dari informasi. Melalui proses transformasi, data
dibuat menjadi bermakna.
17
2.2.2.1 Kualitas Informasi
Menurut Jogiyanto (2005) untuk dapat berguna, maka informasi harus
didukung oleh tiga pilar sebagai berikut:
1. Relevan (Relevance), informasi harus mempunyai manfaat bagi
pemakainya.
2. Tepat Waktu (Timeliness), informasi harus tepat waktu datang
kepada penerima, dan tidak boleh terlambat.
3. Akurat (Accurate), informasi harus benar-benar nyata, dan tidak
boleh terjadi kesalahan-kesalahan yang nantinya akan menyesatkan
penerima informasi. Informasi yang disampaikan harus jelas maksud
dan tujuannya.
2.2.3 Pengertian Sistem Informasi
Menurut Agus Mulyanto (2009), “Sistem informasi merupakan suatu
komponen yang terdiri dari manusia, teknologi informasi, dan prosedur kerja yang
memproses, menyimpan, menganalisis, dan menyebarkan informasi untuk
mencapai suatu tujuan”.
Adapula pengertian lain tentang sistem informasi menurut Jogiyanto
(2005), “Sistem informasi adalah suatu sistem di dalam suatu organisasi yang
merupakan kombinasi dari orang-orang, fasilitas, teknologi, media, prosedur-
prosedur dan pengendalian yang ditujukan untuk mendapatkan jalur komunikasi
penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada
18
manajemen dan yang lainnya terhadap kejadian-kejadian internal dan eksternal
yang penting dan menyediakan suatu dasar informasi untuk pengambilan
keputusan yang cerdik.”
Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem
Informasi mencakup sejumlah komponen (manusia, komputer, teknologi
informasi dan prosedur kerja), ada sesuatu yang diproses yaitu data menjadi
informasi, dan dimaksudkan untuk mencapai suatu sasaran atau tujuan.
2.3 Konsep Dasar Enterprise Architecture
2.3.1 Pengertian Enterprise
Enterprise merupakan kumpulan perusahaan atau organisasi yang
memiliki beberapa tujuan tertentu. Menurut para ahli, enterprise dapat
didefinisikan sebagi berikut :
1. “Enterprise bukan hanya perusahaan (company) yang berorientasi
kepada profit saja, tetapi juga bisa berupa organisasi non-profit atau
nirlaba. Seperti pemerintah, institusi pendidikan ataupun organisasi
amal” (Surendro, 2009).
2. “Enterprise diartikan sebagai semua kumpulan organisasi yang
memiliki sekumpulan tujuan. Enterprise dapat merupakan sebuah
agen pemerintahan, sebuah korporasi keseluruhan, divisi korporasi,
departemen tunggal atau sebuah rantai organisasi yang berhubungan
tetapi berjauhan secara geografis” (The Open Group, 2009).
19
Menurut definisi diatas, dapat disimpulkan bahwa enterprise adalah suatu
kumpulan perusahaan atau organisasi yang mempunyai tujuan bisnis untuk
mencapai tujuan perusahaan/organisasi.
2.3.2 Pengertian Architecture
Menurut Surendro (2009), “Architecture merupakan suatu perencanaan
yang diwujudkan dengan model dan gambar dari bagian/komponen dari sesuatu
dengan berbagai sudut pandang”. Enterprise Architecture diperlukan karena
merupakan sebagai dasar sistem organisasi yang terdiri dari sekumpulan
komponen yang memiliki hubungan satu sama lainnya serta memiliki
keterhubungan dengan lingkungan sistem, dan memiliki aturan untuk perancangan
dan evaluasi (The Open Group, 2009).
Architecture pada awalnya hanyalah sebuah prinsip dan istilah yang
digunakan untuk membuat bangunan, tetapi didalam konteks teknologi informasi,
architecture diperlukan untuk membangun sebuah sistem.
2.3.3 Pengertian Enterprise Architecture
Enterprise Architecture merupakan perancangan proses bisnis dan
teknologi disetiap organisasi dan perusahaan, dan kemudian diintegrasikan untuk
mencapai suatu tujuan tertentu. Menurut Surendro (2009), Enterprise Architecture
merupakan kumpulan prinsip, metode, dan model yang bersifat masuk akal yang
20
digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi
enterprise, struktur organisasi, sistem informasi dan sistem infrastrukturnya”.
Menurut The Open Group (2009) dapat disimpulkan Enterprise
Architechture adalah blueprint organisasi yang menentukan bisnis, informasi, dan
teknologi yang digunakan agar tercapai misi organisasi.
Enterprise Architecture dikonsentrasikan pada infrastruktur yang
meliputi hardware, software dan network untuk dapat bekerja secara bersama
dengan misi, sasaran, dan tujuan organisasi untuk menjalankan proses bisnis
organisasi dengan didukung oleh Teknologi Informasi. Berbagai macam
paradigma dan metode dapat digunakan dalam perancangan enterprise
architecture diantaranya adalah Zachman, TOGAF, FEAF dan gartner.
The Open Group Architecture Framework (TOGAF) merupakan salah
satu acuan kerangka kerja untuk melakukan pengembangan, penerapan, dan
pengelolaan arsitektur di bidang Teknologi Informasi pada sebuah
organisasi/perusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsip-
prinsip yang memberikan keleluasaan dalam memilih teknik pemodelan yang
digunakan dan merupakan panduan gabungan dari berbagai framework
pengembangan arsitektur (FEAF, TEAF, DoDAF, dsb).
“TOGAF memberikan metode yang detail mengenai bagaimana
membangun, mengelola dan mengimplementasikan arsitektur enterprise dan
sistem informasi yang disebut dengan Architecture Development Method (ADM)
(Surendro, 2009)”. Menjelaskan bagaimana menemukan sebuah arsitektur
21
perusahaan/organisasi secara khusus berdasarkan kebutuhan bisnisnya dan proses.
Selain itu TOGAF memiliki Resource Base yang memberikan sumber-sumber
informasi berupa guidelines, templates, checklists, latar belakang informasi dan
detil material pendukung yang membantu arsitek di dalam penggunaan ADM.
Resource Base juga menyediakan banyak material referensi.
Berbeda dengan TOGAF, framework Zachman adalah framework EA
yang menyediakan enam sudut pandang yang dijelaskan dalam sebuah cube.
Keenam sudut pandang tersebut adalah planner, owner, designer, builder,
subcontractor, builder, dan functioning.
Sedangkan FEAF menyediakan sebuah struktur untuk mengembangkan,
memelihara dan mengimplementasikan lingkungan operasional di top-level dan
mendukung implementasi dari sistem TI, namun FEAF tidak memiliki proses
arsitektur yang detil dan tidak ada standarisasinya.
2.4 The Open Group Architecture Framework (TOGAF)
The Open Group Architecture Framework (TOGAF) merupakan sebuah
framework dan sebuah metode untuk mengembangkan data dan melaksanakan
Enterprise Architecture. TOGAF memegang peranan penting membantu proses
pengembangan arsitektur, memungkinkan pengguna TI membangun solusi
berbasis sistem terbuka untuk kebutuhan bisnis mereka.
22
Menurut The Open Group (2009), ada empat jenis arsitektur yang
umumnya diterima sebagai bagian dari keseluruhan Enterprise Architecture, yaitu
:
a. Business architecture, yaitu mendefinisikan bagaimana proses bisnis
untuk mencapai tujuan organisasi.
b. Data architecture, adalah penggambaran bagaimana penyimpanan,
pengelolaan, dan pengaksesan data pada perusahaan.
c. Application architecture, merupakan pendeskripsian bagaimana suatu
aplikasi dirancang dan bagaimana interaksi dengan aplikasi lain.
d. Technology architecture, yaitu gambaran mengenai infrastruktur
perangkat lunak dan perangkat keras yang mendukung aplikasi dan
bagaimana interaksinya.
2.4.1 TOGAF Architecture Development Method (ADM)
TOGAF Architecture Development Method meyediakan teruji dan
berulang dalam pengembangan arsitektur yang dibutuhkan perusahaan (The Open
Group, 2009). ADM merupakan hasil kerjasama generik yang berisikan
sekumpulan aktifitas yang mempresentasikan progresi dari setiap fase ADM dan
model arsitektur yang digunakan dan dibuat selama tahap pengembangan
Enterprise Architecture (Surendro, 2009).
Prinsip pengembangan enterprise dengan menggunakan metodelogi
TOGAF ADM terdiri dari tiga bagian, yaitu :
23
1. Prinsip-prinsip enterprise, mendukung keputusan bisnis di seluruh
bagian organisasi/perusahaan.
2. Prinsip-prinsip teknologi informasi, mengarahkan penggunaan
sumber daya teknologi informasi di seluruh bagian
organisasi/perusahaan.
3. Prinsip-prinsip arsitektur, mengembangkan arsitektur proses
organisasi/perusahaan dan arsitektur implementasinya. Pada prinsip
ini dipengaruhi oleh rencana organisasi/perusahaan, strategi, faktor
pasar, sistem dan teknologi yang ada dalam organisasi/perusahaan.
ADM mempunyai 9 fase seperti gambar berikut :
Gambar 2.1 ADM process ( The Open Group, 2009)
24
2.4.2 Preliminary
Fase preliminary merupakan tahap awal yang merupakan persiapan
arsitektur enterprise. Tahapan ini dilakukan agar proses pemodelan arsitektur
dapat terarah dengan baik. Tujuan dari fase preliminary adalah untuk meyakinkan
setiap orang yang terlibat didalamnya bahwa pendekatan ini berkomitmen untuk
kesuksesan dari setiap arsitektur yang akan dibuat.
Pada fase preliminary dilakukan identifikasi “who”, “what”, “why”,
“when”, dan “where” dari arsitektur itu sendiri (The Open Group, 2009).
1. “What” adalah ruang lingkup dari usaha arsitektur.
2. “Who” adalah siapa yang akan memodelkannya, siapa orang yang
bertanggung jawab untuk mengerjakan arsitektur tersebut, di mana
mereka akan dialokasikan dan bagaimana peranan mereka.
3. “How” adalah bagimana mengembangkan Enterprise Architecture,
menentukan Framework dan metode yang akan digunakan untuk
menangkap informasi.
4. “When”” adalah kapan tanggal penyelesaian arsitektur.
5. “Why” adalah mengapa arsitektur ini dibangun, hal ini berhubungan
dengan tujuan organisasi yaitu bagaimana arsitektur dapat memenuhi
tujuan organisasi.
6. “Where” adalah menunjukkan lokasi kerja dari organisasi.
Memungkinkan organisasi berada di satu bangunan, beberapa kantor
25
atau di sekeliling dunia. Jika semua lokasi organiasi saling
terkoneksi maka diperlukan identifikasi terlebih dahulu.
Preliminary Phase memiliki input, serta langkah-langkah, dan berupa
output sebagai berikut:
a. Input
1. Prinsip-prinsip dan tujuan aktivitas.
b. Langkah-Langkah
1. Mendefinisikan dan membuat prinsip-prinsip arsitektur.
2. Menentukan ruang lingkup setiap unit-unit inti yang terlibat secara
langsung dalam perencanaan strategis sitem informasi.
c. Output
1. Prinsip-prinsip perencanaan strategis sistem informasi (principles
catalog). Prinsip-prinsip tersebut akan menjadi dasar dalam
pengembangan perencanaan startegis sistem informasi yang akan
menghasilkan beberapa arsitektur. Prinsip-prinsip tersebut akan
dijelaskan dalam principle catalog.
2. Tabel identifikasi 5W (What, Who, Why, When, Where) + 1H (How),
yang nantinya tabel ini akan menjelaskan dan menguraikan apa saja
yang akan dilakukan pada objek penelitian, siapa saja yang akan
mengerjakan serta bertanggung jawab dengan objek penelitian,
bagaimana cara kerja pada objek penelitian, kenapa pekerjaan dalam
objek dilakukan dan dimana tempat penelitian tersebut. Dalam
26
penelitian ini, objek penelitian penulis dilakukan di Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan (DTKBDP)
2.4.3 Requirement Management
Reuqirement Management adalah proses pengelolaan kebutuhan
arsitektur di seluruh fase TOGAF ADM. Tujuan dari proses ini adalah untuk
menentukan kebutuhan arsitektur enterprise, kebutuhan itu disimpan lalu
dimasukkan ke dalam fase yang sesuai (The Open Group, 2009)
Sumber daya yang harus dikembangkan dalam tahapan ini adalah
skenario aktivitas. Skenario aktivitas mencakup process business (alur aktivitas)
dan issue (permasalahan dalam organisasi). Process business yang dimaksud
adalah penjelasan sistem yang sedang berjalan pada organisasi.
Requirement Management memiliki input, serta langkah-langkah, dan
berupa output sebagai berikut:
a. Input
1. Keadaan sistem pada saat ini.
2. Data inventaris sarana dan prasarana pendukung TIK.
b. Langkah-langkah
1. Menganalisa kekurangan dan kelebihan dari kondisi sistem pada saat
ini.
2. Identifikasi permasalahan dari kondisi sistem pada saat ini.
3. Membuat solusi dari setiap permasalahan pada kondisi sistem saat ini.
27
c. Output
1. Tabel permasalahan organisasi, yang menjelaskan daftar permasalahan
dari setiap aktivitas organisasi.
2. Tabel solusi aktivitas, yang berisi tentang permasalahan dari setiap
aktivitas beserta solusi yang akan mengatasi permasalahan tersebut.
3. Tabel solusi sistem informasi, pada tabel ini hampir sama dengan tabel
solusi altivitas. Tetapi, perbedaannya ada pada kolom solusi. Pada
tabel ini, solusi yang akan diberikan sudah menyebutkan sistem atau
aplikasi apa saja yang nantinya seharusnya digunakan dalam mengatasi
permasalahan organisasi.
2.4.4 Phase A : Architecture Vision
Fase ini untuk menciptakan keselarasan pandangan bagaimana
pentingnya EA untuk pencapaian tujuan organisasi. Elemen kunci dalam fase ini
adalah visi, misi, strategi, serta tujuan perusahaan yang telah didokumentasikan.
Kesemuanya itu dibutuhkan untuk menetapkan visi arsitektur yang baru.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Menentukan/menetapkan proyek.
2. Mendefinisikan tujuan dan penggerak bisnis.
3. Review prinsip arsitektur termasuk prinsip bisnis.
4. Mendefinisikan apa yang di dalam dan luar ruang lingkup.
5. Mendefinisikan batasan-batasan.
28
6. Mengidentifikasi kebutuhan bisnis dan visi arsitektur.
Fase visi arsitektur memiliki input, langkah-langkah dan output sebagai
berikut:
a. Input
1. Prinsip aktivitas, sasaran aktivitas dan penggerak aktivitas.
b. Langkah-langkah
1. Menguraikan tujuan aktivitas, penggerak aktivitas, dan kendala
aktivitas.
2. Mendefinisikan apa saja yang ada di dalam dan di luar ruang
lingkup arsitektur pada saat ini.
3. Mengembangkan visi arsitektur.
c. Output
1. Mengidentifikasi semua aktivitas yang ada di dalam organisasi.
identifikasi tersebut dihasilkan dalam value chain, diagram yang
mengidentifikasi dan mengelompokkan seluruh aktivitas mana
saja yang nantinya akan masuk ke dalam kelompok aktivitas
utama dan aktivitas pendukung.
2. Hasil identifikasi stakeholder dengan aktivitas yang ada dalam
organisasi untuk mengetahui keterlibatan setiap stakeholder
dalam organisasi, dan untuk mengetahui kebutuhan stakeholder
dalam pembuatan arsitektur. Identifikasi ini nantinya akan
dijelaskan dalam stakeholder map matrix, matriks yang akan
29
menjelaskan hubungan antara stakeholder dengan aktivitas dalam
organisasi.
2.4.5 Phase B : Business Architecture
Pada fase ini bertujuan untuk menguraikan deskripsi arsitektur bisnis
dasar, mengembangkan tujuan arsitektur bisnis dari proyek. Mengembangkan
target arsitektur bisnis yang menjelaskan bagaimana pelaksanaan kebutuhan
perusahaan untuk mencapai tujuan bisnis dalam mendukung visi arsitektur yang
telah disetujui. Mendefinisikan kondisi awal arsitektur bisnis, menentukan
pemodelan dari arsitektur saat ini serta yang diinginkan menggunakan alat bantu
seperti model proses bisnis atau model business usecase.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Melengkapi arsitektur bisnis.
2. Melakukan Gap analysis.
3. Mengembangkan deskripsi arsitektur bisnis saat ini untuk
mendukung arsitektur bisnis target.
4. Mengidentifikasi reference model, sudut pandang dan tools.
5. Menentukan kandidat calon roadmap.
6. Membuat dokumen definisi arsitektur.
7. Menyelesaikan arsitektur bisnis.
30
Fase arsitektur bisnis memiliki input, langkah-langkah, dan output
sebagai berikut :
a. Input
1. Kondisi aktivitas pada saat ini.
b. Langkah-langkah
1. Mengembangkan deskripsi arsitektur aktivitas dasar.
2. Melakukan analisis gap.
3. Membuat arsitektur bisnis (aktivitas).
c. Output
1. Pemodelan arsitektur bisnis menggunakan archimate.
2. Rancangan arsitektur bisnis yang digambarkan menggunakan rich
picture.
3. Struktur organisasi usulan, merupakan rancangan struktur
organisasi yang baru untuk menunjang kinerja organisasi dan
kinerja sistem informasi agar dapat berjalan dengan baik.
Arsitektur bisnis dapat dijelaskan meggunakan beberapa konsep tambahan
berdasarkan orientasi layanan, yaitu konsep business service (layanan bisnis),
business process (proses bisnis), dan business function (fungsi bisnis).
a. Business Service
Business Service merepresentasikan kemampuan yang menawarkan
nilai tambah untuk lingkungan dan kemampuan ini direalisasikan
secara internal dan independen (The Open Group, 2009).
31
b. Business Process
Business Process merepresentasikan alur kerja atau aliran nilai yang
terdiri atas proses atau fungsi lebih kecil. Tujuan dari business process
adalah untuk memuaskan customer (The Open Group, 2009).
c. Business Function
Business Function menetapkan elemen perilaku berdasarkan pada
sekumpulan kriteria terpilih. Business function mengelompokkan
perilaku berdasarkan pada sumber daya bisnis, kemampuan,
kompetensi dan pengetahuan yang dibutuhkan. Busniess function
adalah tugas-tugas khusus yang dilakuan dalam sebuah organisasi The
Open Group, 2009).
2.4.6 Phase C : Information Systems Architecture
Pada fase ini bertujuan untuk mendefinisikan tipe dan sumber utama
data yang diperlukan untuk mendukung bisnis. Pada tahap ini tidaklah
memperhatikan perancangan database, hanya menjelaskan pengembangan dari
arsitektur sistem informasi untuk mendukung fase A yang telah disetujui.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Arsitektur data, tujuannya adalah mendefinisikan entitas data yang relevan
dengan enterprise yang berhubungan dengan perusahaan, tetapi tidak
memperhatikan perancangan database.
32
Arsitektur data memiliki input, langkah-langkah, dan output sebagai
berikut:
a. Input
1. Data principles saat ini, berisi prinsip-prinsip mengenai data yang
mendukung bisnis pada organisasi seperti prinsip penggunaan data
tersebut.
b. Langkah-langkah
1. Mengembangkan deskripsi dasar arsitektur data.
2. Mengembangkan deskripsi target arsitektur data.
3. Melakukan analisis gap.
4. Menyelesaikan arsitektur data.
c. Output
1. Rancangan diagram yang mengubungkan data, layanan bisnis dan
aplikasi. Rancangan tersebut menggunakan data dissemination
diagram.
2. Rancangan tipe data dan hubungan antara entiti data penting untuk
mendukung aktivitas pada organisasi. Rancangan tersebut
digambarkan dalam class diagram.
2. Arsitektur aplikasi, tujuannya adalah mendefinisikan berbagai jenis sistem
aplikasi utama yang diperlukan untuk memproses data dan bisnis, tidak
berhubungan dengan rancangan sistem aplikasi.
33
Arsitektur aplikasi memiliki input, langkah-langkan, dan output sebagai
berikut :
a. Input
Application principles, berisi tentang prinsip-prinsip yang mengenai
aplikasi yang digunakan pada organisasi, seperti prinsip penggunaan
aplikasi tersebut.
b. Langkah-langkah
1. Melakukan analisis gap.
2. Mengembangkan deskripsi dasar arsitektur apikasi
3. Mengembangkan deskrispi target arsitektur aplikasi.
4. Menyelesaikan arsitektur aplikasi.
c. Output
1. Hasil identifikasi tersebut dijelaskan menggunakan application
portofolio catalog.
2. Rancangan penempatan distribusi aplikasi yang digunakan user di
dalam organisasi. rancangan tersebut digambarkan oleh application
and user location diagram.
3. Rancangan penggambaran interaksi antara aktor (user) dan perannya
dalam setiap aplikasi. Rancangan ini akan digambarkan dalam usecase
diagram.
34
2.4.7 Phase D : Technology Architecture
Tujuan dari fase ini adalah untuk mengembangkan arsitektur teknologi
yang diinginkan yang sesuai dengan arsitektur data dan aplikasi, yang mewakili
perangkat lunak dan komponen perangkat keras, alternatif teknologi sampai
pelaksanaan analisis kesenjangan.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Mengidentifikasi model, sudut pandang dan tools yang digunakan.
2. Mengembangkan baseline arsitektur teknologi.
3. Mengembangkan deskripsi target arsitektur teknologi.
4. Membuat analisis gap.
5. Menentukan kandidat roadmap.
6. Menanggulangi seluruh dampak arsitektur.
7. Membuat review untuk stakeholder.
8. Menyelesaikan arsitektur teknologi.
9. Membuat dokumen definisi arsitektur.
Fase arsitektur teknologi memiliki input, langkah-langkah, dan output
sebagai berikut :
a. Input
1. Technology principles saat ini, berisi prinsip-prinsip mengenai
teknologi yang digunakan untuk mendukung aktivitas pada organisasi.
b. Langkah-langkah
1. Melakukan analisis gap.
35
2. Menyelesaikan arsitektur teknologi.
3. Mengembangkan deskripsi dasar arsitektur teknologi.
4. Mengembangkan deskripsi target arsitektur teknologi.
c. Output
1. Rancangan komunikasi dalam arsitektur teknologi, seperti rancangan
jaringan yang melibatkan hardware untuk membuat suatu komunikasi
jaringan. Rancangan tersebut digambarkan dalam communication
engineering diagram.
2. Platform decomposition diagram menggambarkan platform teknologi
yang mendukung sistem informasi.
3. Identifikasi teknologi yang sudah digunakan dalam sistem yang
berjalan pada organisasi. hasil tersebut dapat dijelaskan menggunakan
technology portofolio catalog.
2.4.8 Phase E : Opportunities and Solution
Pada fase ini bertujuan untuk berkonsentrasi pada rencana pembuatan
implementasi awal dan identifikasi penyampaian arsitektur yang telah ditetapkan
pada fase sebelumnya. Pada tahapan ini pula akan dievaluasi model yang telah
dibangun untuk arsitektur saat ini dan target, identifikasi proyek utama yang akan
dilaksanakan untuk mengimplementasikan arsitektur tujuan dan klasifikasi
sebagai pengembangan baru atau penggunaan kembali sistem yang sudah ada.
36
Beberapa tahap yang dilakukan di fase ini adalah:
1. Menentukan atribut key corporate change.
2. Menetapkan batasan-batasan bisnis.
3. Menggabungkan hasil analisis gap dari fase Business Architecture
sampai Technology Architecture.
4. Membuat ulasan persyaratan fungsi bisnis yang terkait.
5. Menggabungkan persyaratan operasi.
6. Mengesahkan ketergantungan.
7. Menetapkan kesiapan dan resiko transformasi bisnis.
8. Merumuskan implementasi dan migrasi.
9. Mengidentifikasi paket kerja kelompok utama.
10. Mengidentifikasi arsitektur transisi.
11. Membuat roadmap arsitektur dan implementasi migrasi.
Fase peluang dan solusi memiliki input, langkah-langkah dan output sebagai
berikut :
a. Input
1. Hasil analisis gap dari arsitektur bisnis, data, aplikasi dan teknologi.
b. Langkah-langkah
1. Merumuskan implementsi dan strategi migrasi.
2. Menentukan kendala aktivitas untuk implementasi.
3. Meninjau kembali dan menggabungkan hasil analisis gap dari fase B
sampai fase D.
37
c. Output
1. Hasil analisis gap gabungan dari fase arsitektur bisnis sampai
arsitektur teknologi
2.4.9 Phase F : Migration Planning
Pada fase ini bertujuan untuk memilih proyek implementasi yang bervariasi
menjadi urutan prioritas. Aktivitas mencakup penilaian ketergantungan, biaya,
manfaat dari proyek migrasi yang bervariasi. Prioritas proyek akan berjalan untuk
membentuk dasar dari perencanaan implementasi detail dan rencana migrasi.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Menetapkan nilai bisnis untuk setiap paket kerja.
2. Memperkirakan kebutuhan sumberdaya, waktu proyek dan waktu
pengiriman.
3. Mengutamakan migrasi proyek berdasarkan perkiraan biaya dan
resiko.
4. Menyelesaikan rencana implementasi dan migrasi.
Fase rencana migrasi memiliki input, langkah-langkah dan output
sebagai berikut:
a. input
1. Implementation and migration plan, suatu rencana untuk menjadwalkan
migrasi data dan implementasi aplikasi.
38
b. Langkah-langkah
1. Menetapkan model bisnis pada setiap proyek.
2. Membuat roadmap implementasi arsitektur dan perencanaan migrasi.
3. Memastikan interaksi kerangka kerja manajemen untuk rencana
implementasi dan migrasi.
4. Lebih memprioritaskan proyek migrasi melalui pelaksanaan penilaian
biaya.
c. output
1. Roadmap implementasi aplikasi.
2.4.10 Phase G : Implementation Governance
Pada fase ini, proyek dilaksanakan sebagai program rencana kerja,
serta pengelolaan proyek untuk mencapai keberhasilan arsitektur yang diinginkan.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Menetapkan ruang lingkup dan prioritas implementasi dengan
manajemen pengembangan.
2. Mengidentifikasi sumberdaya dan kemampuan.
3. Melakukan penetapan solusi pengembangan pada setiap
implementasi.
4. Menjalankan Enterprise Architecture yang telah dibuat/dirancang.
5. Mengimplementasikan manajemen bisnis dan operasi IT.
39
6. Mengadakan post-implementation dan menyelesaikan
implementasi.
Fase tata kelola implementasi memiliki input, langkah-langkah dan
output sebagai berikut :
a. Input
1. Architecture roadmap
b. Langkah-langkah
1. Mengidentifikasi sumber daya.
2. Menerapkan bisnis operasi dan IT.
3. Melaksanakan tinjauan pasca implementasi dan menutupnya.
c. Output
1. Kontrak arsitektur yang telah ditandatangani
2.4.11 Phase H : Architecture Change Management
Tujuan fase ini adalah untuk memastikan bahwa arsitektur mencapai
target bisnis serta untuk menentukan/menetapkan proses manajemen perubahan
arsitektur untuk Enterprise Architecture yang baru. Proses ini menyediakan
monitoring berkelanjutan dari hal-hal seperti pengembangan teknologi baru dan
menentukan apakah akan dilakukan siklus pengembangan Enterprise Architecture
berikutnya.
Beberapa tahap yang dilakukan di fase ini adalah:
1. Menetapkan nilai realisasi proses.
40
2. Menetapkan monitoring tools.
3. Mengelola resiko.
4. Menyediakan analisis untuk manajemen arsitektur.
5. Menyediakan kebutuhan perubahan.
6. Mengelola proses tata kelola.
7. Mengaktifkan proses untuk menerapkan perubahan.
Fase manajemen perubahan arsitektutur memiliki input, langkah-langkah, dan
output sebagai berikut :
a. Input
1. Inovasi teknologi bisnis dan perubahan strategi.
b. Langkah-langkah
1. Mengelola resiko
2. Menyebarkan tools monitoring.
c. Output
1. Kontrak arsitektur yang telah diperbarui.
2. Perubahan kerangka arsitektur dan prinsip-prinsip.
3. Arsitektur yang diperbarui untuk proses pemeliharaan.
41
2.4.12 Kelebihan dan Kekurangan TOGAF
Salah satu kelebihan menggunakan TOGAF adalah karena sifatnya yang
fleksibel dan bersifat open source. TOGAF memandang enterprise architecture
ke dalam empat kategori. Keempat kategori tersebut adalah business architecture,
application architecture, data architecture, dan technology architecture
(Setiawan, 2009).
Secara umum TOGAF memiliki struktur dan komponen sebagai berikut:
1. Architecture Development Method (ADM)
Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci
bagaimana mementukan sebuah enterprise architecture secara spesifik
berdasarkan kebutuhan bisnisnya.
2. Foundation Architecture
Merupakan sebuah framework-within-a-framework dimana didalamnya
tersedia gambaran hubungan untuk pengumpulan arsitektur relevan, juga
menyediakan bantuan petunjuk pada saat terjadinya abstraksi level yang
berbeda. foundation Architecture dapat dikumpulkan melalui ADM.
3. Resource Base
Pada bagian ini terdapat informasi mengenai guidelines, templates,
checklist, latar belakang informasi dan detail material pendukung yang
membantu arsitek dalam penggunaan ADM.
Kekurangan framework TOGAF:
42
1. Tidak adanya template standar untuk seluruh domain (misalnya untuk
membuat blok diagram).
2. Tidak ada artefak yang dapat digunakan ulang (ready made).
2.5 Tools Perancangan Arsitektur
2.5.1 Principle Cataloga
Bertujuan dari katalog ini adalah untuk menangkap bisnis dan prinsip-
prinsip yang menggambarkan solusi atau arsitektur yang seharusnya seperti apa.
Nantinya prinsip-prinsip ini digunakan untuk mengevaluasi dan menyetujui hasil
dari arsitektur bisnis. Prinsip ini juga digunakan sebagai tools untuk membuat tata
kelola arsitektur yang mempunyai inisiatif perubahan. (The Open Group, 2009).
Tabel 2.1 Contoh Principle Catalog
No Prinsip Tujuan
1. Keputusan arsitektur harus
mengacu pada tujuan
strategis dan proses bisnis
pada Dinas Tata Kota,
Bangunan dan Pemukiman.
Mendukung kemampuan adaptasi
terhadap proses bisnis
Memperkuat hubungan antara
infrastruktur dan proses bisnis
serta lebih mudah menyelaraskan
proses bisnis ketika perubahan
terjadi.
2. Pengelolaan arsitektur ini Meningkatkan kemampuan untuk
43
diusahakan mudah. berbagi data dan sumber daya lain
dalam pelayanan kepada
pengguna dan membantu
kerjasama antar divisi.
3. Arsitektur yang
dikembangkan harus aman.
Dapat meminimalisasi dampak
atas bencana alam.
Mampu bertahan dari serangan
eksternal seperti virus, worm,
hack, syware, crack, phising,
denial of service.
4. Data Previlege
(Perlindungan Data)
Untuk melindungi dari akses
pihak-pihak yang tidak
berwenang.
Mengatur stakeholder dalam
mengolah data.
5. Arsitektur dirancang agar
mudah melakukan
penambahan dan
pengembangan.
Memungkinksn respon yang lebih
cepat apabila ada perubahan yang
dapat berakibat pada infrastruktur
yang bersifat adaptif.
6. Penerapan arsitektur multi-
tier dan arsitektur berbasis
komponen.
Memudahkan kegiatan
penggantian komponen yang
rusak (meningkatkan
availability).
44
Memudahkan duplikasi dan
upgrading modul.
7. Menggunakan open
technology.
Menghindari ketergantungan pada
vendor.
Menjamin dukungan produk yang
kuat terhadap teknologi.
Meminimalisasi training manusia
yang harus dilakukan setiap kali
ada perubahan dalam pilihan
vendor.
8. Data yang konsisten. Tersedianya kebutuhan bagi pihak
yang membutuhkan.
Meminimalkan resiko akan
kerancuan jika ada
pengembangan yang akan
dikerjakan.
2.5.2 Flowchart
Flowchart merupakan gambar atau bagan yang memerlihatkan urutan
dan hubungan antar proses beserta intruksinya. Gambaran ini dinyatakan
dengan simblo. Setiap simbol menggambarkan proses tertentu, sedangkan
45
hubungan antar proses digambarkan dengan garis penghubung. Flowchart
merupakan cara penyajian dari suatu algoritma (Ladjamudin, 2005).
Terdapat dua macam flowchart yang menggambarkan prosess komputer,
yaitu :
1. System Flowchart
Bagan yang menggambarkan proses dalam sistem dengan
menunjukkan alat media input, output serta jenis media penyimpanan
dalam proses pengolahan data.
2. Program flowchart
Bagan yang memperlihatkan urutan intruksi yang digambarkan
dengan simbol tertentu untuk emmecahkan masalah dalam suatu
program.
Flowchart disusun dengan simbol. Simbol ini dipakai sebagai alat bantu
menggambarkan proses di dalam program. Simbol-simbol yang akan digunakan
dapat dibagi menjadi tiga bagian, yaitu simbol penghubung/alur (flow direction
symbols), simbol proses (processing sysmbols), dan simbol input-output (input-
output symbols). Dengan uraian sebagai berikut.
1. Simbol penghubung/alur (Flow Direction Symbols)
Simbol yang digunakan untuk menghubungkan antara simbol yang satu
dengan yang lain. Simbol ini disebut juga connecting line. Simbol-simbol tersebut
adalah sebagai berikut:
46
Tabel 2.2 Simbol Penghubung Flowchart
Simbol Penjelasan
Arus/Flow
Untuk menyatakan jalannya arus
suatu proses.
Communication Link
Untuk menyatakan bahwa adanya
transisi suatu data/informasi dari
satu lokasi ke lokasi lainnya.
Connector
Untuk menyatakan sambungan
dari suatu proses ke proses lainnya
dalam halaman/lembar yang sama.
Off-line Connector
Untuk menyatakan sambungan
dari satu proses ke proses lainnya
dalam halaman/lembar yang
berbeda.
2. Simbol Proses (Processing Symbols)
Simbol yang menunjukkan jenis operasi pengolahan dalam suatu
proses/prosedur. Simbol-simbol tersebut adalah sebagai berikut.
47
Tabel 2.3 Simbol Proses Flowchart
Simbol Penjelasan
Proses/penugasan
Untuk kegiatan pemrosesan input, pada
simbol ini dapat menuliskan operasi-
operasi yang dikenakan pada input.
Manual
Untuk menyatakan suatu tindakan
(proses) yang tidak dilakukan oleh
komputer (manual).
Decision/logika
Untuk menunjukkan suatu kondisi
tertentu yang akan menghasilkan dua
kemungkinan jawaban, ya atau tidak.
Predefined Process
Pengolahan untuk member harga awal.
Terminal
Untuk menyatakan permulaan atau
akhir suatu program.
48
Keying Operation
Untuk menyatakan segala jenis operasi
yang diproses dengan menggunakan
suatu mesin yang mempunyai
keyboard.
Offline-Line Storage
Untuk menunjukkan bahwa data dalam
simbol ini akan disimpan ke suatu
media tertentu.
Manual Input
Untuk memasukkan data secara manual
dengan menggunakan online keyboard.
3. Simbol Input-Output (Input-Output Symbols)
Tabel 2.4 Simbol Input-Output Flowchart
Simbol Penjelasan
Input-Output Untuk menyatakan proses input
dan output tanpa tergantung
dengan jenis peralatannya.
Punched Card
Untuk menyatakan input berasal
dari kartu atau output ditulis ke
kartu.
49
Magnetic-tape Unit
Untuk menyatakan input berasal
dari pita magnetic atau output
disimpan ke pita magnetic.
Disk Storage
Untuk menyatakan input berasal
dari disk atau output disimpan disk.
Document
Untuk mencetak laporan ke printer.
Display
Untuk menyatakan peralatan
output yang digunakan berupa
layar (video dan komputer).
2.5.3 Value Chain
Porter (1985), dalam buku karangan Jogiyanto (2005), value chain
meliputi kegiatan-kegiatan yang terdiri dari kegiatan-kegiatan atau aktivitas-
aktivitas, yaitu:
1. Aktivitas utama, yang meliputi penanganan dan penyimpanan bahan
mentah yang berupa inbound logistics, operations, outbond logistics,
marketing and sales, dan services.
50
2. Aktivitas pendukung yaitu infrastruktur perusahaan, yang berupa
firm infrastructure, human resources management, technology
development, dan procurement.
Untuk mencapai keunggulan kompetitif, dua aktivitas besar yang terdiri
dari sembilan kegiatan tersebut harus mempunyai nilai yang efektif dan efisien.
Nilai disetiap kegiatan harus dapat menciptakan nilai dimasing-masing kegiatan.
Gambar 2.2 : Diagram Value Chain (Porter, 1985)
2.5.3 Stakeholder Map Matrix
Tujuan dari Stakeholder Map Matrix ini adalah untuk mengidentifikasi
stakeholder untuk keterlibatannya di dalam aktivitas utama dan aktivitas
pendukung (The Open Group, 2009).
51
Tabel 2.5 Contoh Stakeholder Map Matrix
Stakeholder
Aktivitas
Tat
a R
uan
g
Bid
. B
angunan
Bid
. T
eknik
Su
bb
ag.
Tat
a U
sah
a
Pem
ohon
Bag
. K
euan
gan
Kep
ala
Din
as
Pem
erin
tah
Non P
emer
inta
h
Aktivitas Utama
1. Rekomendasi IMB &SLF
2. Hasil Musrembang
3. Sidang
4. Survey Lokasi
5. DPA
6. Lelang Proyek
7. Rekomendasi IMB &SLF
8. Bangunan
Aktivitas Pendukung
1. Manajemen Keuangan
2. SDM
3. Inventaris
4. Perencanaan Bisnis Strategis
Pada tabel 2.5 digambarkan keterlibatan stakeholder terhadap aktivitas
yang ada di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang
52
Selatan. Kolom pada matriks tersebut merupaka stakeholder yang ada di Dinas
Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Baris pada
matriks tersebut merupakan aktivitas-aktivitas yang ada pad DTKBDP. Warna
biru yang ada dalam matriks tersebut menandakan siapa saja stakeholder yang
terlibat dalam setiap aktivitas.
2.5.4 Archimate
Archimate adalah bahasa pemodelan untuk menggambarkan enterprise
architecture. ada standarisasi archimate, terbagi menjadi 3 layer, yaitu layer
teknologi, layer bisnis, dam layer aplikasi.
a. Layer bisnis
1. Konsep struktural antara peran bisnis, pelaku usaha dan entitas
yang melakukan prilaku seperti proses bisnis atau fungsi. Proses
bisnis disini menandakan tanggung jawab untuk satu atau lebih
proses bisnis atau fungsi bisnis.
2. Peran bisnis ditetapkan pada pelaku usaha. Pelaku usaha bisa
berupa individu atau kelompok masyarakatdan sumber daya yang
memiliki status permanen dalam organisasi.
b. Layer aplikasi
Konsep untuk layer ini adalah komponen aplikasi. Konsep ini
digunakan untuk memodelkan entitas struktural dalam lapisan aplikasi
dari perangkat lunak lengkap atau sistem informasi.
53
c. Layer teknologi
Konsep struktural untuk lapisan teknologi ini adlaah node. Konsep ini
digunakan untuk memodelkan entitas struktural dlaam lapisan
teknologi.
2.5.5 Rich Picture
Merupakan penggambaran sistem atau situasi dengan menggunakan
gambar-gambar. Gambaran keseluruhan dari orang, objek, proses, struktur, dan
maslah pada keseluruhan proses bisnis yang ada di organisasi.
Subbag. Rumah Tangga
Aplikasi E-inventaris
2. Kelola Data Inventaris
Bagian Keuangan
3. View Laporan Inventaris
Bidang Teknik
1. Input Data Inventaris
Bidang Bangunan
1a. Input Data Inventaris
Gambar 2.3 Contoh Rich Picture
Menjelaskan bahwa pada pencatatan penggunaan inventaris di DTKBDP,
setiap bidang harus melakukan login terlebih dahulu kedalam sisem, kemudian
setiap bidang harus menginput data inventaris yang mereka gunakan setiap bulan.
Subbag. Rumah tangga melakukan login kedalam sistem untuk mengelola
data inventaris yang digunakan setiap bidang di DTKBDP. Bagian keuangan
melihat laporan inventaris melalui sistem E-inventaris.
54
2.5.6 Data Dissemination Diagram
Data Dissemination Diagram menunjukkan hubungan antara entitas data,
layanan bisnis dan komponen aplikasi. Diagram ini menunjukkan bagaimana
entitas logis secara fisik diwujudkan dengan komponen aplikasi. Kemudian,
menggambarkan replika data dan sistem uta,a untuk data (The Open Group,
2009).
Gambar 2.4 Data Dissemination Diagram
Pada gambar 2.4 menggambarkan hubungan layanan Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan, aplikasi, dan data. Di
aplikasi IMB dan SLF terdapat data level, data user, data pegawai, data customer,
data tanah, data SLF, data IMB dan data bangunan. Aplikasi SPK Lelang terdapat
55
data level, data user, data pegawai, data kontraktor, data material, data DPA, data
design proyek dan data lelang. Aplikasi progress bangunan terdapat data level,
data user, data pegawai, data proyek, data pengawas, data progress, dan data
kontraktor. Aplikasi E-inventaris terdapat data user, data level, data pegawai dara
registrasi_BMN, data peralatan, data kendaraan, data tanah, data bangunan dan
data aset_tak_berwujud. Aplikasi E-keuangan terdapat data level, data pegawai,
data periode, data klasifikasi_pengeluaran, data user, data pengeluaran dan data
general_ledger.
2.5.7 UML
Unified Modelling Laguage (UML) adalah salah satu alat bantu yang
sangat handal di dunia pengembangan sistem yang berorientasi objek. Hal ini
disebabkan karena UML menyediakan bahasa pemodelan visual yang
memungkinkan bagi pengembang sistem untuk membuat cetak biru atas visi
mereka dalam bentuk yang baku, mudah dimengerti serta dilengkapi dengan
mekanisme yang efektif untuk berbagi dan mengkomunikasikan rancangan
mereka dengan yang lain.
UML merupakan kesatuan dari bahasa pemodelan yang dikembangkan
oleh Booch, Object Modelling Technique (OMT) dan Object Oriented
Engineering (OOSE). Metode Booch dari Grady Booch sangat terkenal dengan
nama metode Design Object Oriented. Metode ini menjadikan proses analisis dan
design ke dalam empat tahapan iteratif, yaitu: identifikasi kelas-kelas dan obyek-
56
obyek, identifikasi semantik dari hubungan obyek dan kelas tersebut, perincian
interface dan implementasi.
Desain sistem pada UML disusun oleh simbol-simbol yang terbentuk
menjadi diagram model. Berikut adalah simbol yang digunakan pada desain
sistem ini. UML memiliki beberapa diagram diantaranya (Munawar, 2005):
1. Diagram Use Case
Use Case adalah deskripsi fungsi dari sebuah sistem dari perspektif
pengguna. Use case bekerja dengan cara mendeskripsikan tipikal interaksi antara
user (pengguna) sebuah sistem dengan sistemnya sendiri melalui sebuah cerita
bagaimana sebuah sistem dipakai (Munawar, 2005).
Usecase merupakan konstruksi untuk mendeskripsikan bagaimana
sistem akan terlihat di mata pengguna potensial. Use case terdiri dari sekumpulan
skenario yang dilakukan oleh seorang actor (orang, perangkat keras, urutan waktu
atau sistem yang lain). Use case adalah alat bantu terbaik guna menstimulasi
pengguna potensial untuk mengatakan tentang suatu sistem dari sudut
pandangnya. Diagram use case mempunyai 3 notasi yang menunjukkan aspek dari
sistem, yaitu actor (pengguna), use case dan relationship (Munawar, 2005).
Berikut adalah simbol-simbol yang ada pada diagram use case:
(sugiarti, 2013):
57
Tabel 2.6 Daftar Simbol Use Case Diagram
Simbol Deskripsi
Use Case
Fungsionalitas yang disediakan sistem
sebagai unit-unit yang saling bertukar
pesan antar unit atau aktor, biasanya
dinyatakan dengan menggunakan kata
kerja di awal frase nama use case.
Nama Use Case
Orang, proses, atau sistem lain yang
berinteraksi dengan sistem informasi
yang akan dibuat di luar sistem
informasi yang akan di buat itu sendiri ;
biasanya dinyatakan menggunakan kata
benda di awal frase nama aktor.
Asosiasi (Association)
Komunikasi antara aktor dan use case
yang berpartisipasi pada use case.
Ekstensi (Extend)
<<extend>>
Relasi use case tambahan ke sebuah use
case dimana use case yang
ditambahkan dapat berdiri sendiri
walau tanpa use case tambahan;
biasanya use case tambahan memiliki
nama depan yang sama dengan use case
58
yang ditambahkan.
Generalisasi (Generalitation)
Hubungan generalisasi dan spesialisasi
(umum-khusus) antara dua buah use
case dimana fungsi yang satu adalah
fungsi yang lebih umum dari lainnya.
Menggunaan (Include)
Relasi use case ke sebuah use case
dimana use case yang ditambahkan
memerlukan use case ini untuk
menjalankan fungsinya atau sebagai
syarat dijalankan use case ini. Dua
sudut pandang mengenaik use case,
yaitu :
1. Include berarti use case yang
ditambahkan akan selalu
dipanggil saat use case tambahan
dijalankan.
2. Include berarti use case yang
tambahan akan selalu melakukan
pengecekan apakah use case
yang ditambahkan telah
59
dijalankan sebelum use case
tambahan dijalankan. Kedua
sudut pandang tersebut dapat
digunakan salah satu atau
keduanya, tergantung pada
pertimbangan dan sudut pandang
yang dibutuhkan.
Gambar 2.5 Contoh Model Use Case Diagram
Pada gambar 2.5 menjelaskan use case diagram di sistem SPK lelang.
Arsitektur bisnis SPK Lelang memiliki 7 aktor dan 10 use case yang dapat
dilakukan dalam sistem SPK lelang. Aktor yang terlibat yaitu, admin, bagian
Pemerintah Kota
Input Hasil Musrembang Bagian Keuangan
Input DPA
Bidang Teknik
Input Design Proyek
Kontraktor
Input Proposal Proyek
Sekretariat
Memilih Kontraktor
Kepala Dinas
Pengesahan Proyek
View Laporan Proyek
Log in
Log Out
<<include>>
Admin
Manajemen User
60
keuangan, pemerintah kota, kontraktor, bidang teknik, kepala dinas dan
sekretariat.
Use case yang terlibat dalam SPK lelang yaitu, login,logout, manajemen
user, input hasil musrembang, input DPA, input design proyek, input proposal
proyek, memilih kontraktor, pengesahan proyek, dan view laporan proyek.
2. Diagram Kelas
Class Diagram adalah deskripsi objek-objek dengan property, perilaku
(operasi) dan relasi yang sama. Disamping itu class diagram bisa memberikan
pandangan global atas sebuah sistem. Class dalam notasi UML digambarkan
kotak. Nama class menggunakan huruf besar di awal kalimatnya dan diletakkan di
atas kotak. Bila class mempunyai nama yang terdiri dari 2 (dua) suku kata atau
lebih, maka semua suku kata digabungkan tanpa spasi dengan huruf awal tiap
suku kata menggunakan huruf besar. Atribute adalah property dari sebuah class.
Atribute ini melukiskan batas nilai yang mungkin ada pada obyek dari class.
Sebuah class mungkin mempunyai nol atau lebih atribute (Munawar, 2005).
Operation adalah sesuatu yang dilakukan oleh sebuah class atau yang
anda (atau class yang lain) dapat lakukan sebuah class. Responsibility adalah
keterangan tetang apa yang akan dilakukan class yaitu apa yang akan dicapai oleh
atribute dan operation (Munawar, 2005).
61
Tabel 2.7 Daftar Simbol Class Diagram
Simbol Penjelasan
Kelas
Kelas pada struktur sistem.
Antarmuka (Interface)
Sama seperti konsep interface
dalam pemrograman
berorientasi objek.
Asosiasi (Assosiation)
Relasi antar kelas dengan
makna umum; biasanya disertai
dengan multiplicity.
Asosiasi berarah (Directed
Association)
Relasi antar kelas dengan
makna kelas yang satu
digunakan oleh kelas yang lain;
biasanya disertai dengan
multiplicity.
Generalisasi (Generalization)
Relasi antar kelas dengan
makna generalisasi –
spesialisasi (umum – khusus)
62
Kebergantungan (Depedency)
Relasi antar kelas dengan
makna kebergantungan antar
kelas.
Gambar 2.6 Contoh Model Class Diagram
Pada gambar 2.6 menjelaskan Class Diagram di sistem IMB dan SLF.
Arsitektur data IMB dan SLF memiliki 8 kelas, yaitu Level, user , Pegawai,
Customer, Tanah, Bangunan, SLF, dan IMB.
Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu sampai
Level
+id_level+nama_Level
+tambah()+hapus()
Customer
+Id_Customer+Nama_Customer+TTL+Telp+Alamat+KTP+Akta
+Tambah()+Hapus()+Ubah()
Bangunan
+Id_Bangunan+Nama_Bangunan+Fungsi_Bangunan+Jenis_Bangunan+Luas_Bangunan+Lokasi_Bangunan
+Tambah()+Hapus()+Ubah()
Tanah
+Id_Tanah+Status_Tanah+Status_Penggunaan+Pemilik_Tanah+Batas_Tanah
+Tambah()+Hapus()+Ubah()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
*1
1..*
1
1..*
1
1..*1
1
1
IMB
+No_IMB+Tanggal_IMB+Id_Customer+Id_Tanah+Id_Bangunan+Masa_Berlaku_IMB+Pengesahan
+Tambah()+Hapus()+Ubah()+Print()
SLF
+No_SLF+Tanggal_SLF+Id_Customer+Id_Tanah+Id_Bangunan+Masa_Berlaku_SLF+Pengesahan
+Tambah()+Hapus()+Ubah()+Print()
1..*1
1..* 1
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
1
1
1
1..*
63
banyak) terhadap kelas tanah dan bangunan. Kelas bangunan memilik multiplicity
11 (satu ke satu) terhadap kelas tanah. Kelas IMB dan SLF memiliki
multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas pegawai.
Kelas user memiliki multiciply 11 (satu ke satu) terhadap pegawai dan kelas
user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak)
terhadap kelas customer.
2.5.6.1 Sejarah UML
Pada akhir tahun 80-an dan awal 90-an, di gunakan beberapa metode
berorientasi objek yang berbeda-beda. Yang paling terkenal adalah metode Booch
dari Grady Booch Object Modeling Technique (OMT) dari James Rumbaugh
(OMT), dan Object Oriented Software Engineering (OOSE) dari Ivar Jacobson.
Banyaknya teknik yang di gunakan membatasi kemampuan untuk memakai
model-model pada proyek lain (mengurangi reuse) dan tim pengembang.
Konsekuesinya, teknik ini menghambat komunikasi antara anggota tim dan
pengguna, yang mengakibatkan banyak terjadi error di dalam proyek. Masalah ini
dan lainnya mendorong di lakukannya usaha untuk mendesain bahasa pemodelan
standar (Whitten et al. 2006).
Pada tahun 1994, Grady Booch dan James Rumbaugh sepakat bergabung
untuk menggunakan metode pengembangan berorientasi objek dengan tujuan
membuat proses standar tunggal untuk mengembangkan sistem berorientasi objek.
Ivar Jacobson bergabung pada tahun 1995, dan mereka bertiga fokus membuat
sebuah bahasa pemodelan objek standar sebagai ganti dari pendekatan atau
64
metode berorientasi objek standar. Berdasarkan keja mereka dan hasil kerja
lainnya pada industri, Unified Modeling Language (UML) versi 1.0 di rilis pada
tahun 1997 (Whitten et.al, 2006).
2.5.7 Principle Catalog
Catalog ini digunakan untuk menetapkan beberapa prinsip bisnis dan
arsitektur perusahaan dalam memberikan solusi arsitektur yang tepat untuk
perusahaan. Catalog ini juga dapat digunakan untuk mengevaluasi implementasi
arsitektur serta menilai perubahan tata kelola arsitektur yang terjadi. (The Open
Group, 2011).
Tabel 2.8 Principle Catalog
No Prinsip Tujuan
1. Keputusan arsitektur harus
mengacu pada tujuan
strategis dan proses bisnis
pada Dinas Tata Kota,
Bangunan dan Pemukiman.
Mendukung kemampuan adaptasi
terhadap proses bisnis
Memperkuat hubungan antara
infrastruktur dan proses bisnis
serta lebih mudah menyelaraskan
proses bisnis ketika perubahan
terjadi.
2. Pengelolaan arsitektur ini
diusahakan mudah.
Meningkatkan kemampuan untuk
berbagi data dan sumber daya lain
dalam pelayanan kepada
65
pengguna dan membantu
kerjasama antar divisi.
3. Arsitektur yang
dikembangkan harus aman.
Dapat meminimalisasi dampak
atas bencana alam.
Mampu bertahan dari serangan
eksternal seperti virus, worm,
hack, syware, crack, phising,
denial of service.
4. Data Previlege
(Perlindungan Data)
Untuk melindungi dari akses
pihak-pihak yang tidak
berwenang.
Mengatur stakeholder dalam
mengolah data.
2.5.8 Technology Portofolio Catalog
Catalog ini digunakan untuk mengidentifikasi daftar teknologi yang
digunakan dalam perusahaan, seperti hardware, infrastructure software, dan
application software. Technology portfolio yang sudah disetujui akan menjadi
dasar standar teknologi perusahaan yang dapat mendukung siklus hidup produk
menajemen teknologi dan beberapa versi teknologi selanjutnya (The Open Group,
2011).
66
Tabel 2.9 Technology Portofolio Catalog
Pada tabel 2.9 dijelaskan teknologi apa saja yang dibutuhkan dan akan
digunakan DTKBDP dalam arsitektur teknologi usulan untuk setiap aplikasi yang
akan dibangun.
2.5.9 Communications Engineering Diagram
Diagram ini menjelaskan maksud komunikasi antar aset dalam arsitektur
teknologi. Adanya koneksi logis antara clienT dan server dalam mengidentifikasi
batasan jaringan dan jaringan infrastruktur yang diperlukan secara fisik untuk
mengimplementasikan koneksi tersebut. Diagram ini tidak menjelaskan format
informasi ataupun konten, tetapi menjelaskan alamat protokol dan kapasitas (The
Open Group, 2009).
67
Gambar 2.7 : Contoh Communication Engineering Diagram
2.5.10 Platform Decomposition Diagram
Menurut The Open Group (2009), platform decomposition diagram
menggambarkan platform teknologi yang mendukung operasional arsitektur
sistem informasi. Diagram ini mencakup semua aspek platform infrastruktur dan
menyediakan gambaran platform teknologi pada organisasi.
68
Gambar 2.8 platform Decomposition Diagram
Pada gambar 2.8 menjelaskan platform teknologi menggambarkan bahwa
keseluruhan sistem yang diusuljan sudah berbasis web. Pada level client interface,
user eksternal dapat mengakses aplikasi yang berada di website DTKBDP melalui
web browser dan internet. User internal dapat mengakses keseluruhan sistem
aplikasi di website DTKBDP melalui internet atau jringan lokal (LAN) Apache
web server digunakan untuk mendukung berjalannya aplikasi berbasis web.
Aplikasi berbasis web dibangun menggunakan bahasa pemrograman PHP
(Hypertext Preprocessor). Bahasa pemrograman ini akan mengambil data dari
data storage.
69
2.5.11 Matriks Analisis Gap
Menurut The Open Group, 2009 matrik ini menunjukan suatu ruang
lingkup dari sebuah paket pekerjaan yang harus diimplementasikan sebagai
bagian dari transformasi Road Map yang lebih luas dengan penggambaran
baseline architecture yang ada pada saat ini dan pergambaran target arsitektur
target. Premis dasar adalah untuk menyoroti kekurangan antara Arsitektur Dasar
dan Arsitektur Sasaran, yaitu item yang telah sengaja dihilangkan, sengaja
ditinggalkan, atau belum ditetapkan.
Sebuah langkah penting dalam mengevaluasi arsitektur adalah untuk
mempertimbangkan apa yang mungkin telah dilupakan. Arsitektur harus
mendukung semua kebutuhan pengolahan informasi penting dari organisasi.
Sumber yang paling penting dari gaps yang harus dipertimbangkan adalah
kekhawatiran stakeholder yang belum dibahas dalam karya arsitektur
sebelumnya.
2.6 Metode Pengembangan Sistem Rapid Application Development (RAD)
Metodologi pengembangan sistem adalah suatu aktivitas, metode, praktik
terbaik dan peralatan terotomatisasi yang digunakan para stakeholder untuk
mengembangkan dan secara berkesinambungan memperbaiki sistem informasi
dan perangkat lunak (Whitten et al, 2006). Pengembangan sistem informasi
merupakan penyusunan suatu sistem untuk menggantikan sistem yang lama secara
keseluruhan atau memperbaiki sistem yang telah ada.
70
Rapid Application Development (RAD) yaitu suatu pendekatan
berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode
pengembangan serta perangkat-perangkat lunak (Kendall & Kendall, 2006). Rapid
Application Development (RAD) adalah sebuah model proses
perkembangan software sekuensial linier yang menekankan siklus perkembangan
yang sangat pendek. Model RAD ini merupakan adaptasi “kecepatan tinggi” dari
model sekuensial linier dimana perkembangan cepat dicapai dengan
menggunakan pendekatan konstruksi berbasis pada komponen.
Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim
pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu
yang sangat pendek (kira-kira 45 sampai 90 hari). Model pengembangan ini
melingkupi aktivitas-aktivitas sebagai berikut :
1. Fase Perencanaan Syarat (Requirement Planning)
2. Fase Proses Desain (Workshop Design)
3. Fase Implementasi (Implementation)
Model pengembangan software tradisional memiliki tahapan-tahapan yang
harus diselesaikan secara bertahap, sedangkan pada pengembangan menggunakan
Rapid Application Development (RAD), pengembang sistem dapat menyelesaikan
sebuah modul sampai diimplementasikan tanpa harus menunggu seluruh sistem
selesai. Berikut ini adalah gambaran mengenai perbedaan dari model
71
pengembangan sistem secara tradisional dan dengan menggunakan Rapid
Application Development (RAD).
Gambar 2.9 Fase Rapid Application Development (RAD)
2.6.1 Perencanaan Syarat (Requirement Planning)
Pada tahap ini, user dan analis melakukan semacam pertemuan untuk
melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi
kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah
adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan
proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya
dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi
sehingga informasi yang dibutuhkan untuk masing – masing user dapat terpenuhi
dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief
Information Office (CIO) atau bagian perencana strategis terutama untuk
mengembangkan suatu aplikasi untuk mendapatkan informasi yang lebih detail
72
akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint
Aplication Development.
2.6.2 Proses Desain (Design Workshop)
Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan –
perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst.
Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk
mencapai tujuan, karena user bisa langsung memberikan komentar apabila
terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul
menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa
melihat satu dengan yang lain tanpa ada halangan. Apabila memungkinkan, maka
masing-masing user diberikan satu komputer yang terhubung satu dengan yang
lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung
memberikan komentar. Hal ini sering kali disebut dengan Group Decision
Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu
langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat
untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari
aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya
dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan
tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat.
Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang
sudah dikembangkan untuk selanjutnya dilakukan perbaikan- perbaikan. Dengan
demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.
73
2.6.3 Implementasi (Implementation)
Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh
user dan analyst, maka pada tahap ini programmer mengembangkan desain
menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara
keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah
terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada
saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat
serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa
keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat
memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak
perlu dijalankan secara paralel dengan sistem yang baru.
2.7 Penelitian Sejenis
1. “Perencanaan Strategis Sistem informasi/Teknologi Informasi
Menggunakan Kerangka The Open Architecture framework (TOGAF)
(Studi Kasus: Pemda kabupaten Sumba Barat)”.
Skripsi ini disusun oleh Raimond Lukito Widiatmo pada tahun 2012.
Tujuan pembuatan skripsi ini adalah untuk menyusun enterprise
Architecture pada Pemda Kabupaten Sumba Barat agar tata kelola dan
administrasi berjalan dengan efektif dan efisien. Kekurangan pada skripsi
ini adalah penulis hanya menggunakan 4 phase dalam penelitiannya.
74
Dirasa sangat tidak optimal, karena Pemda Sumba Barat dipastikan
membutuhkan usulan sistem yang maksimal.
2. “Perencanaan Infrastruktur Teknologi Informasi di Lembaga
Penelitian (UIN) Syarif Hidayatullah Jakarta Menggunakan
TOGAF Architecture Development Method (ADM)”.
Skripsi ini disusun oleh Aenun Jariyatul Umami (Fakultas Sains dan
Teknologi Informasi, UIN Syarif Hidayatullah Jakarta, 2013) dengan
tujuan menganalisis kebutuhan dari infrastruktur teknologi Informasi
secara menyeluruh dan terpadu untuk mencapai visi dan misi Lemlit
menggunakan TOGAF. Kelebihan dari penelitian ini adalah perencanaan
Enterprise Architecture menghasilkan suatu dokumentasi perencanaan
infrastruktur teknologi informasi yang terintegrasi untuk mendukung
kebutuhan organisasi dan memberikan pensejajaran antara proses bisnis
Lemlit dengan teknologi informasi yang mengiringinya.
Kekurangan dari penelitian ini adalah analisis dan perencanaan
infrastruktur teknologi informasi dibatasi hanya pada fase Preliminary
Phase, Architecture vision (Tahapan A), Bussiness architecture (Tahapan
B), Information system architecture (Tahapan C), dan Technology
architecture (Tahapan D).
75
3. Menggunakan TOGAF Architecture Development method Pada
PT. Satya Karya Utama”.
Skripsi ini disusun oleh Vivi Fyandiani Pratiwi pada tahun 2013
dengan tujuan memberikan usulan enterprise architecture agar proses
bisnis pada PT. Satya Utama yang bergerak dalam bidang property, design
interior, furniture dan jasa konsultan dapat berjalan dengan efektif dan
efisien. Adapun kelebihan pada penelitian ini adalah tingkat analisis yang
dinilai sangat detail. Dimulai dari pendahuluan sampai arsitektur
teknologi, sehingga memudahkan para stakeholder untuk memahami
rancangan arsitektur TI tersebut.
Kekurangan pada skripsi ini adalah tidak adanya relasi antara
entitas data-data yang akan digunakan sehingga menyulitkan
pekembangan lebih lanjut yang terkait dengan hubungan data-data.
i
76
BAB III
METODOLOGI PENELITIAN
3.1 Metode Pengumpulan Data
Pembuatan penelitian ini dilakukan menggunakan beberapa metode yang
dapat membantu penulis baik dalam hal pengumpulan data maupun informasi
yang diperlukan untuk mendapatkan kebenaran materi uraian pembahasan. Oleh
karena itu, riset atau penelitian dilakukan guna mendapatkan data dan referensi
yang diperlukan.
Teknik pengumpulan data ini dilakukan agar data-data yang dibutuhkan
dalam penelitian ini dapat terpenuhi dan supaya tercapainya tujuan penelitian.
Teknik pengumpulan data yang dipilih tergantung pada faktor utama dan jenis
data. Berikut merupakan metode dari pengumpulan data yang dilakukan untuk
mendapatkan data dan referensi yang dibutuhkan.
3.1.1 Metode Observasi
Menurut (Jogiyanto, 2008) , “Observasi (observation) merupakan teknik
atau pendekatan untuk mendapatkan data primer dengan cara mengamati langsung
obyek datanya”. Pengamatan ini dilakukan dengan melihat langsung proses dan
kegiatan bisnis yang berjalan pada studi kasus Dinas Tata Kota, Bangunan dan
Permukiman Kota Tangerang Selatan. Observasi dilakukan pada bulan Agustus
2014 yang bertempat di Jl. Raya Puspiptek, Setu, Ruko Boulevard No.A1 & A2
76
77
Serpong-Tangerang Selatan. Kegiatan ini dilakukan untuk melihat proses bisnis
yang terjadi, dan segala kegiatan atau mencari data yang diperlukan untuk
penelitian. Hasil observasi yang didapat adalah:
a. Sejarah singkat Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan, visi dan misi yang ada.
b. Profil Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang
Selatan.
c. Sistem berjalan yaitu bagaimana proses pengajuan permohonan
perizinan dan perencanaan penataan kota di Tangerang Selatan.
Teknik observasi ini dimulai dengan melakukan pengamatan langsung
terhadap proses bisnis dan strategi bisnis yang ada pada Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan, apa saja yang menjadi
dukungan agar proses bisnis bisa berjalan sesuai dengan yang diinginkan
perusahaan. Lalu mengamati apakah teknologi informasi sudah digunakan secara
selaras dengan proses bisnis tersebut.
3.1.2 Metode Wawancara
Metode ini dilakukan untuk membantu mencari informasi yang berkaitan
dengan kegiatan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang
Selatan. Dalam hal ini wawancara dilakukan dengan pihak yang dianggap
mengetahui semua hal yang bertujuan untuk mendapatkan data dan informasi
yang berkaitan dengan proses bisnis Dinas Tata Kota, Bangunan dan Permukiman
78
Kota Tangerang Selatan. Penelitian ini menggunakan wawancara untuk
mengumpulkan data yang diperlukan berkaitan dengan proses bisnis perusahaan
dan aliran input-proses-output untuk mempertahankan dan mengembangkan
bisnis serta untuk meningkatkat profit perusahaan.
Dari hasil wawancara tersebut, kemudian dikumpulkan data dan
informasi berupa tugas dan fungsi tiap-tiap unit kerja, permasalahan apa saja yang
dihadapi dalam pelaksanaan tugas dan fungsi unit kerja, serta pemanfaatan TI
terhadap tiap-tiap unit kerja. Berikut beberapa daftar pertanyaan yang dimaksud:
1. Bagaimana gambaran secara umum mengenai aktifitas bisnis yang
ada pada Dinas tata Kota, Bangunan dan Permukiman?
2. Bagaimana dengan pengelolaan Sistem informasi yang ada pada
Dinas tata Kota, Bangunan dan Permukiman?
3. Apa yang menjadi fokus bisnis utama pada Dinas tata Kota,
Bangunan dan Permukiman?
4. Apakah Dinas tata Kota, Bangunan dan Permukiman sudah memiliki
Enterprise Architecture?
5. Bagaimana mengenai infrastruktur jaringan yang ada pada Dinas tata
Kota, Bangunan dan Permukiman?
Tabel transkrip wawancara yang dilakukan di Dinas tata Kota, Bangunan
dan Permukiman dengan dua narasumber dalam wawancara ini akan dilampirkan
pada halaman lampiran 1.
79
3.1.3 Metode Studi Pustaka
Metode studi pustaka ini dilakukan dengan cara mencari sumber data
sekunder yang akan mendukung penelitian. Metode ini dilakukan dengan
mengumpulkan data dan informasi yang dijadikan sebagai acuan perancangan
model Enterprise Architecture, referensi-referensi tersebut berasal dari buku-buku
terkait maupun publikasi dari hasil penelitian, artikel, situs internet serta sumber
informasi lain yang berkaitan dengan penelitian ini diantaranya mengenai konsep
sistem informasi, enterprise architecture, TOGAF, TOGAF ADM, serta meliputi
tools yang digunakan dalam perancangan enterprise architecture ini.
3.1.4 Studi Literatur
Tabel 3.1 Perbandingan Penelitian Sejenis
Penulis/Tahun Judul Keterangan Kekurangan &
Kelebihan
Vivi Fidyani
Pratiwi
Perancangan
Model
Enterprise
Architecture
dengan
Menggunakan
TOGAF PT.
Satya Karya
Utama
Menghasilkan
sebuah prinsip dalam
pembuatan arsitektur
perusahaan dan
menghasilkan
blueprint rancangan
arsitektur, namun
perancangan
enterprise
Kelebihan
penelitian
menghasilkan
sebuah prinsip
dalam pembuatan
arsitektur
perusahaan, dan
menghasilkan
blueprint
80
architecture hanya
sampai pada tahap
ke empat saja, yaitu
tahap technology
architecture.
rancangan
arsitektur
Kekurangan
perancangan
enterpeise
architectire
hanya sampai
dengan taha[ ke
empat saja.
Anis
Khairunnisa
Perancangan
Strategis
Sistem
Informasi
menggunakan
TOGAF pada
PT. Dian Nikel
Mining
Merancang
perencanaan
strategis dan
menghasilkan
blueprint dan
roadmap. Namun
penempatan hanya
dilakukan dalam
beberapa fase
arsitektur bisnis,
sistem informasi dan
teknologi, belum
dijelaskan dalam
fase TOGAF ADM.
Kelebihan
penelitian ini
menghasilkan
perencanaan
strategis dan
menghasilkan
blueprint dan
roadmap.
Kekurangan ada
di penempatan
hanya dilakukan
dalam beberapa
fase arsitektur
bisnism sistem
81
informasi dan
teknlogi namun
belum dijelaskan
dalam fase
ADM.
Muchtar Aham Rancang
Bangun
Arsitektur
Teknologi
Informasi pada
Pelayanan
Rumah Makan
menggunakan
TOGAF ADM.
Merancang dan
mengimplementasika
n areitektur
teknologi informasi
menggunakan
TOGAF ADM,
namun sistem hanya
terfokus pada
pelayanan dan
pembayaran saja.
Kelebihan pada
penelitian ini
adalah penelitian
dilakukan
mengenai
arsitektur
teknologi
informasi
menggunakan
TOGAF.
Kekurangan
sistem hanya
terfokus pada
pelayanan dan
pembayaran saja.
Raimond Lukito
Widiatmo
Perencanaan
Strategis
Sistem
Meyusun ususlan
SI/TI bagi emda
Kabupaten Sumba
Kelebihan pada
penelitian ini
adalah
82
Informasi/Tek
nologi
Informasi
menggunakan
kerangka
TOGAF (Studi
Kasus: Pemda
Kabupaten
Sumba Barat)
Barat agar tata
laksana dan sistem
administrasi
pemerintahan dapat
berjalan lebih efektif
dan efisien, namun
perancangan EA
hanya pada sampai
tahap technology
architecture saja.
menghasilkan
model enterprise
architecture yang
dapat digunakan
sebagai pandual
pengelolaan
SI/TI dalam
jangka waktu 5
tahun kedepan.
Kekurangannya
adalah
perancangan EA
hanya sampai
dengan tahap ke
empat saja.
83
3.2 Metode Perancangan Enterprise Architecture
Untuk metodologi perancangan Arsitektur Teknologi Informasi adalah
menggunakan metodologi TOGAF ADM. Ada enam tahap dalam metodologi
TOGAF ADM yang digunakan penulis yaitu:
3.2.1 Tahapan TOGAF
1. Fase Preliminary
Fase ini tentang mendefinisikan bagaimana melakukan perancangan
diperusahaan yang bersangkutan. Pada fase ini akan dilakukan beberapa tahapan
sebagai berikut:
1. Menentukan prinsip-prinsip sebagai acuan pengembangan arsitektur.
Prinsip-prinsip tersebut juga memodelkan karakteristik dari arsitektur
teknologi informasi yang akan dikembangkan.
2. Menentukan scope dari apa yang akan dibuat (What).
3. Menentukan siapa saja actor yang terlibat dalam pengembangan
arsitektur (Who).
4. Menentukan dimana lokasi objek perancangan enterprise architecture
yang akan dibuat (Where).
5. Menentukan kapan tanggal mulai dan target penyelesaian arsitektur
(When).
6. Menetapkan mengapa arsitektur ini dibangun (Why).
84
7. Mendefinisikan bagaimana (How) rancangan enterprise architecture
ini dibuat.
2. Architecture Vision (Phase A)
Dalam fase ini bertujuan untuk menciptakan keseragaman pandangan
mengenai pentingnya enterprise architecture untuk mencapai tujuan organisasi
yang dirumuskan dalam bentuk strategi serta menentukan lingkup dari arsitektur
yang akan dikembangkan, untuk itu penulis menguraikan beberapa langkah untuk
menentukan visi arsitektur, yaitu:
1. Menentukan dan mendefinisikan visi perusahaan.
2. Menentukan seluruh aktifitas proses kerja perusahaan.
3. Menentukan dan mendefinisikan actor.
4. Merancang solusi visi arsitektur.
Tools yang digunakan pada fase ini adalah Value chain diagram.
3. Business Architecture ( Phase B )
Dalam fase ini bertujuan untuk membuat model bisnis (proses, fungsi dan
aktifitas) yang diinginkan berdasarkan skenario bisnis yang sudah didefinisikan
pada tahapan Visi arsitektur. Untuk penjelasan alur bisnis ini dapat menggunakan
salah satu modeling UML yaitu Business Use Case Diagram.
Adapun keluaran atau hasil dari fase ini adalah:
1. Mengidentifikasi sejarah perusahaan.
85
2. Menjelaskan struktur organisasi usulan beserta definisinya.
3. Rancangan arsitektur bisnis dengan menggunakan model use case.
Tools yang digunakan pada fase ini adalah: Business Use Case Diagram,
Organization Catalog.
4. Information Systems Architecture (Phase C)
Pada fase arsitektur bisnis sistem informasi ini membahas arsitektur data
dan arsitektur aplikasi yang didefinisikan berdasarkan hasil keluaran dari
Arsitektur bisnis yang sudah dibuat. Fase ini menekankan bagaimana arsitektur
sistem informasi dibangun meliputi arsitektur data dan arsitektur aplikasi yang
akan digunakan oleh Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan.
Arsitektur Aplikasi
Pada arsitektur aplikasi, dilakukan dengan mengidentifikasi kandidat
aplikasi, menentukan jenis aplikasi yang dibutuhkan untuk memproses data dan
mendukung bisnis, serta membuat pemodelan arsitektur aplikasi. Beberapa
tahapannya yaitu sebagai berikut:
1. Mengidentifikasi aplikasi-aplikasi yang akan dirancang.
2. Memodelkan aplikasi-aplikasi yang akan dirancang.
3. Menjelaskan manfaat atau fungsi aplikasi yang dirancang.
4. Pemodelan menggunakan Activity Diagram.
86
Tools yang digunakan yaitu: Activity Diagram, Aplication Portfolio
Catalog.
Arsitektur Data
Pada arsitektur data, dilakukan dengan mengidentifikasi seluruh
komponen data yang akan digunakan oleh aplikasi untuk menghasilkan informasi
yang dibutuhkan organisasi. untuk fase arsitektur data diuraikan beberapa tahapan
sebagai berikut:
1. Memodelkan data yang digunakan setiap aplikasi yang akan
dirancang pada arsitektur aplikasi.
2. Pada arsitektur data, perancangan menggunakan Class Diagram.
Dalam Arsitektur Data digunakan tools: Class Diagram.
5. Technology Architecture (Phase D)
Tujuan fase arsitektur teknologi adalah untuk mendefinisikan teknologi-
teknologi utama yang dibutuhkan. Untuk fase arstektur teknologi diuraikan
beberapa tahapan sebagai berikut:
1. Mendefinisikan konfigurasi jaringan awal.
2. Menetapkan konfigurasi jaringan usulan.
3. Menentukan jenis kandidat teknologi dari sisi software dan
hardware yang diperlukan.
4. Mempertimbangkan alternatif-alternatif yang diperlukan dalam
usulan pemilihan teknologi.
87
Tools yang dipakai dalam fase ini yaitu: Communications Engineering
Diagram, Platform Technology, Technology Portofolio Catalog.
6. Opportunities & Solutions (Phase E)
Pada tahapan ini akan diuraikan tahapan sebagai berikut:
1. Mengevaluasi model yang telah dibangun untuk semua arsitektur
(Bisnis, Aplikasi, Data, dan Teknologi.
2. Mengidentifikasi hubungan arsitektur data antar aplikasi.
3. Dalam tahapan ini rancangan dibuat menggunakan Matrik Analisis
Gap.
Tools yang digunakan pada fase ini yaitu: Matrix Analysis GAP.
7. Migration Planning (Phase F)
Pada fase ini bertujuan untuk perencanaan migrasi untuk menghasilkan
pemahaman aplikasi yang nantinya akan digunakan oleh user. Pada tahapan fase
perencanaan migrasi ini akan dilakukan beberapa tahap berikut:
1. Melakukan penyusunan proyek-proyek berdasarkan prioritas dari
berbagai perspektif (perspektif manajemen dan operasional) dan
manfaat dari proyek migrasi.
2. Membuat daftar urutan prioritas proyek yang akan berjalan untuk
membentuk dasar dari perencanaan implementasi detail dan rencana
migrasi.
88
3. Menetapkan roadmap aplikasi perusahaan.
3.2.2 Alasan Penulis Menggunakan TOGAF ADM
TOGAF merupakan kerangka kerja arsitektur yang memberikan
gambaran-gambaran diantaranya desain, perencanaan, implementasi dan tata
kelola arsitektur pada perusahaan. Alasan penulis menggunakan TOGAF ADM
karena pada TOGAF terdapat metode-metode yang detail (fase-fase), serta
memiliki tools yang dapat membantu dalam perencanaan enterprise architecture
pada Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan.
89
3.3 Kerangka Berpikir Penelitian
Adapun kerangka berpikir penelitian yang dilakukan pada penulisan
skripsi ini adalah sebagai berikut:
Mulai
Tahap
Pengumpulan
Data
Melakukan
Observasi
Melakukan
Wawancara
Melakukan Studi
Literatur
Melakukan
Studi Pustaka
Metode Observasi
(Jogiyanto, 2008)
Metode Wawancarai
(Nazir, 2005)
Metode Studi
Literaturi (Nazir,
2005)
Metode Studi
Pustaka (Nazir,
2005)
Tahap Perancangan
Enterprise
Architecture (TOGAF
ADM)
REQUIREMENTS
A. Architecture
Vision
B. Business
Architecture
C. Information
Systems
Architecture
D. Technology
Architecture
E. Opportunities
And Solutions
F. Migration
Planning
Blue Print
Selesai
TOGAF 9,
The Open Group (2009)
TOGAF 9,
Architecture Development Methodology
Gambar 3.1 - Kerangka Berpikir
90
Tabel 3.2
Daftar Simbol Kerangka Penelitian
No Nama Simbol Gambar Simbol Keterangan
1. Mulai / Selesai
Mendeskripsikan
permulaan penelitian
2. Tahapan
Mendeskripsikan tahapan
penelitian yang akan
dilakukan
3. Metode
Mendeskripsikan metode
yang digunakan perproses
4. Proses
Mendeskripsikan proses
penelitian.
5. Relasi
Mendeskripsikan aliran
proses
6. Petunjuk
Menunjukkan metode
yang digunakan.
i
91
BAB IV
PERANCANGAN ENTERPRISE ARCHITECTURE
Bab ini berisi tentang analisis yang dilakukan pada Dinas Tata Kota
Bangunan Dan Permukiman serta perancangan Enterprise Architecture (EA)
menggunakan framework TOGAF ADM yang dimulai dari preliminary phase,
architecture vision, architecture business, information system architecture,
technology architecture, opportunities and soutions, sampai migration planning.
4.1 Preliminary Phase
Fase preliminary pada tahap ini merupakan tahap persiapan perusahaan
arsitektur enterprise, ini dilakukan agar proses pemodelan arsitektur dapat terarah
dengan baik. Pada tahap ini didefinisikan bagaimana arsitektur enterprise akan
dibuat. Prinsip-prinsip dimaksudkan untuk menyediakan suatu panduan bagi
pengambilan keputusan arsitektur teknologi informasi, menentukan struktur dan
komposisi komponen-komponen arsitektur, menentukan kriteria pemilihan
teknologi dan produk, serta dalam perencaaan dan pengimplementasian arsitektur.
Selain itu prinsip-prinsip arsitektur juga menggambarkan karakteristik dari
arsitektur teknologi informasi yang akan dikembangkan.
Sebagai acuan pengembangan, akan digunakan prinsip-prinsip arsitektur
sebagai berikut:
Keputusan arsitektur harus mengacu pada tujuan strategis dan proses
bisnis pada Dinas Tata Kota, Bangunan dan Permukimanan.
91
92
2. Dalam pengelolaan arsitektur ini diusahakan mudah. Hasil dari kerja
prinsip ini adalah dapat membantu kerjasama antar divisi.
3. Arsitektur yang dikembangkan harus aman.
4. Data dan informasi harus dilindungi dari akses oleh pihak-pihak yang
tidak berwenang.
5. Arsitektur dirancang agar mudah melakukan penambahan dan
pengembangan.
6. Penerapan arsitektur multi-tier dan arsitektur berbasis komponen.
7. Menggunakan open technology.
8. Definisi dari data harus konsisten di semua bagian organisasi, harus
dikelola sebagai suatu aset, data harus tersedia bagi pihak yang
membutuhkan dalam tugasnya, serta harus ada pemilik yang bertanggung
jawab atas kualitasnya.
Setelah kerangka dibuat, maka tahap selanjutnya adalah menetapkan
prinsip-prinsip yang akan digunakan. Pada tabel 4.1 menggambarkan segala
principle yang akan dipakai. Ini dapat dilihat jelas pada principle catalog
dibawah ini:
4.1.1 Prinsip-prinsip Perancangan Enterprise Architecture (EA)
Prinsip-prinsip berikut ini untuk memberikan bimbingan kepada proses
pengambilan keputusan arsiteltur teknologi informasi, menentukan struktur dan
komposisi dari komponen arsitektur, menentukan kriteria untuk memilih
93
teknologi dna produk yang akan digunakan, dan juga dalam desain arsitektur dan
implementasi.
Prinsip-prinsip yang akan digunakan sebagai acuan dalam perancangan
adlaah sebagai berikut:
1. Keputusan arsitektur yang dibuat harus sesuai dengan tujuan, aktivitas,
serta proses bisnis di Dinas Tata Kota, Bangunan, dan Permukiman Kota
Tangerang Selatan.
2. Arsitektur yang dikembangjan harus mendukung kesinambungan bisnis.
3. Arsitektur yang dikembangkan harus aman.
4. Dara (informasi) dan sistem harus dilindungi dari akses oleh pihak-pihak
yang tidak berwenang.
5. Data yang mudah diakses.
6. Perancangan arsitektur aplikasi yang mudah digunakan.
7. Penerapan arsitektur multi-tier dan arsitektur berbasis komponen.
8. Independensi teknologi.
Setelah prinsip-prinsip sudah ditetapkan maka dibuat tabel principle
catalog untuk lebih menggambarkan prinsip-prinsip yang akan dipakai oleh Dinas
Tata Kota, Bangunan, dan Permukiman Kota Tangerang Selatan dan menjelaskan
tujuan dari setiap prinsip-prinsipnya.
94
Tabel 4.1 Principle Catalog
No Prinsip Tujuan
1. Keputusan arsitektur harus
mengacu pada tujuan
strategis dan proses bisnis
pada Dinas Tata Kota,
Bangunan dan Pemukiman.
Mendukung kemampuan adaptasi
terhadap proses bisnis
Memperkuat hubungan antara
infrastruktur dan proses bisnis
serta lebih mudah menyelaraskan
proses bisnis ketika perubahan
terjadi.
2. Pengelolaan arsitektur ini
diusahakan mudah.
Meningkatkan kemampuan untuk
berbagi data dan sumber daya lain
dalam pelayanan kepada
pengguna dan membantu
kerjasama antar divisi.
3. Arsitektur yang
dikembangkan harus aman.
Dapat meminimalisasi dampak
atas bencana alam.
Mampu bertahan dari serangan
eksternal seperti virus, worm,
hack, syware, crack, phising,
denial of service.
4. Data Previlege
(Perlindungan Data)
Untuk melindungi dari akses
pihak-pihak yang tidak
95
berwenang.
Mengatur stakeholder dalam
mengolah data.
5. Arsitektur dirancang agar
mudah melakukan
penambahan dan
pengembangan.
Memungkinksn respon yang lebih
cepat apabila ada perubahan yang
dapat berakibat pada infrastruktur
yang bersifat adaptif.
6. Penerapan arsitektur multi-
tier dan arsitektur berbasis
komponen.
Memudahkan kegiatan
penggantian komponen yang
rusak (meningkatkan
availability).
Memudahkan duplikasi dan
upgrading modul.
7. Menggunakan open
technology.
Menghindari ketergantungan pada
vendor.
Menjamin dukungan produk yang
kuat terhadap teknologi.
Meminimalisasi training manusia
yang harus dilakukan setiap kali
ada perubahan dalam pilihan
vendor.
8. Data yang konsisten. Tersedianya kebutuhan bagi pihak
96
yang membutuhkan.
Meminimalkan resiko akan
kerancuan jika ada
pengembangan yang akan
dikerjakan.
4.1.2 Identifikasi 5W+1H
Setelah prinsip-prinsip beserta tujuannya sudah sudah ditentukan, maka
langkah berikutnya adalah mengidentifikasi 5W+1H dalam perancangan arsitektur
ini untuk Dinas Tata Kota, Bangunan dan Pemukiman.
Tabel 4.2 5W+1H
No Driver Deskripsi
1. What Objek: Lingkup arsitektur
Deskripsi: Membuat perancangan model
enterprise architecture
2 Who Objek: Siapa saja actor utama yang terlibat
dalam pemodelan enterprise arsitektur ini
Deskripsi:
Pemodelan: Ines Putri Karunia
97
Tanggung Jawab: Staff TI dan Organisasi
3. How Objek: Menentukan bagaimana rancangan dibuat
Deksripsi: menggunakan motodologi TOGAF
ADM
4. When Objek: Waktu penyelesaian framework
Deksripsi: Oktober 2014
5. Why Objek: Mengapa arsitektur ini dibangun
Deskripsi: Agar perusahaan mempunyai
landasan dalam pembuatan kebijakan yang
meliputi tujuan dan sasaran, penyusunan strategi,
pelaksanaan program dan fokus kegiatan serta
langkah-langkah atau implementasi yang harus
dilaksanakan oleh perusahaan
6. Where Objek: Menunjukkan lokasi kerja dan organisasi
Deskripsi: Dinas Tata Kota, Bangunan dan
Pemukiman Kota Tangerang Selatan
98
4.2 Requirement Management
Pada fase requirement management mempunyai tujuan untuk menentukan
kebutuhan proses dalam perancangan enterprise architecture pada Dinas Tata
Kota, Bangunan, dan Permukiman Kota Tangerang Selatan. Dalam fase
requirement management dibutuhkan skenario aktivitas yang menckup core
business, proces business, dan issue organisasi. Tetapi, sebelum mengembangkan
skenario aktivitas, terlebih dahulu untuk menganalisa sistem yang sedang berjalan
di DTKBDP.
4.2.1 Kondisi Sistem Berjalan
Pada bagian ini akan menggambarkan sistem yang sedang berjalan dengan
rich picture untuk masing-masing aktivitas di DTKBDP, yaitu, permohonan IMB
dan SLF, pembangunan bangunan, proses lelang proyek, manajemen keuangan,
sumber daya manusia, inventaris dan perencanaan bisnis strategis.
99
pemohon
1. Menyerahkan berkas
administrasi IMB
sekretariat
Proses Sidang
3. Melakukan proses
Sidang 1
Tim survey
4. Melaksanakan pemeriksaan
lapangan/survey
5. Mendapat rekomendasi
Site plan
TABG
6. Pemeriksaan berkas
administrasi
7. Konfirmasi kelengkapan
berkas
8. melakukan proses
Sidang 29. pemeriksaan berkas administrasi
10. Menyerahkan rekomendasi IMB
12. Menyerahkan Surat rekomendasiIMB
Tim panitia SLF
Pemerikasaan lapangan
13. Pemeriksaan berkas
administrasi SLF
15. Proses pemerikasaan
bangunan gedung
17. Memberikan surat
rekomendasi SLF
14. Konfirmasi kelengkapan
berkas administrasi SLF
Pemerintah Kota
18. Memberikan hasil
musrembang
Bag. Keuangan
19. Menyerahkan
DPA
Bidang Teknik
20. Menyerahkan
daftar proyek
Bidang bangunan
21. Menyerahkan
hasil design
Proses Lelang
22. Melaksanakan
proses lelang
Kepala Dinas
11. Pengesahan surat
rekomendasi IMB
16. Pengesahan surat
rekomendasi
SLF
Kontraktor
23. Pembangunan
Sie. Pengawasan
Bangunan
Sie. Data dan
Informasi26. Memberikan laporan
progress pembangunan
24.Memberikan data
progress pembangunan
25. Meminta laporan
progress bangunan
2. konfirmasi kelengkapan
Berkas administrasi IMB
27. Menyerahkan data inventaris
27a. Menyerahkan data inventaris
28. Menerima Laporan Inventaris
Bagian Rumah Tangga
Subbag. Tata Usaha
29. pencatatan
akuntansi
30. Pengajuan
IMB Musrembang
31. Pengajuan Rekomendasi
SLF Pemkot
Gambar 4.1 Sistem Berjalan
100
Pemohon yang ingin membuat sertifikat permohonan IMB dan SLF,
datang ke kantor DTKBDP dan mengisi formulir IMB serta menyerahkan berkas-
berkas pengajuan rekomendasi IMB, apabila berkas dianggap sudah lengkap dan
memenuhi syarat maka bagian sekretariat akan mengkonfirmasi berkas tersebut,
tetapi apabila berkas belum lengkap berkas akan dikembalikan kepada pemohon
untuk dilengkapi. Apabila berkas tersebut sudah lengkap, maka bagian sekretariat
akan melakukan sidang pertama, sidang pertama berisikan tentang kelengkapan
berkas IMB.
Setelah selesai melaksanakan sidang, maka tim survey akan melakukan
survey pada lokasi yang nantinya akan didirikan bangunan, survey tersebut
menghasilkan site plan dan diberikan kepada pemohon. Setelah itu akan
dilakukan proses pemeriksaan berkas administrasi yang diberikan kepada TABG,
setelah dikonfirmasi maka akan dilakukan proses sidang kedua yang merupakan
revisi dari kelengkapan berkas pada sidang pertama kemudian diberikan kepada
TABG untuk ditindak lanjuti. Setelah itu memberikan rekomendasi IMB kepada
bagian sekretariat dan disahkan oleh kepala dinas kemudian diberikan kepada
pemohon. Setelah rekomendasi IMB diberikan, maka pemohon memberikan
berkas administrasi SLF (Sertifikat Layak Fungsional), kepada panitia SLF dan
dikonfirmasi kepada pemohon. Dilakukan pemeriksaan bangunan gedung oleh
pemeriksa lapangan, disahkan oleh kepala dinas dan panitia SLF memberikan
rekomendasi SLF kepada pemohon. SLF berisi tentang kecocokkan bangunan
yang sudah dituliskan pada isi rekomendai IMB sebelumnya.
101
Pada proses pembangunan atau perbaikan gedung atau sarana dan
parasaran pemerintahan atau non pemerintahan, maka pemerintah kota Tangerang
Selatan memberikan hasil musyawarah rembuk bangunan (Musrembang) yang
didapat dari keluhan dari internal pemerintahan atau eksternal dari masyarakat
sekitar tentang sarana dan prasarana didaerah kota TangSel yang harus diperbarui
atau dibangun untuk kebutuhan masyarakat atau pemerintah. Setelah hasil
musrembang didapat dan diberikan kepada bagian sekretariat, kemudian
pemerintah kota memberikan daftar anggaran (DPA) kepada bagian keuangan.
DPA tersebut nantinya akan disesuaikan dengan bangunan yang akan dibangun.
Pemerintah kota menyerahkan daftar proyek kepada bidang teknik untuk
dibuatkan design sesuai yang diharapkan, kemudian design tersebut diberikan
kepada bidang bangunan untuk melaksanakan proses lelang. Apabila kontraktor
sudah sesuai dengan perjanjian dengan DTKBDP, maka kontraktor tersebut bisa
langsung mendirikan bangunan sesuai design yang sudah diberikan. Setelah
mendapatkan kontraktor yang sesuai, dan proses pembangunan sedang berjalan,
maka bidang bangunanan mengajukan rekomendasi IMB untuk pembangunan
pemerintahan ke sekretariat.
Seiring berjalannya proses pembangunan atau bahkan pembangunan
bangunan yang sudah selesai, diperlukan pemeriksaan bangunan secara berkala.
Pemeriksaan bangunan dilakukan untuk mengetahui kondisi detail setiap
bangunan, dari kondisi fisik atau kondisi material yang harus diperbaiki. Data
progress bangunan dikelola oleh pengawas bangunan dan data tersebut diberikan
kepada sie. Data dan informasi dan diberikan kepada kepala dinas sebagai laporan
102
progress bangunan didaerah Tangerang Selatan. Setelah progress bangunan
selesai, maka bagian sie. Data dan Informasi mengajukan SLF ke sekretariat,
karena SLF berisi tentang kondisi fisik bangunan yang harus disesuaikan dengan
isi IMB.
Bagian Subbag. Tata Usaha melakukan pencatatan akuntansi dan membuat
laporan periode keuangan kemudian diberikan kepada bagian keuangan.
Pencatatan masih menggunakan ms.office kemudian di print, sehingga terkadang
laporan tersebut terselip oleh berkas-berkas lainnya.
1. Flowchart Level 0
Gambar 4.2 Flowchart Sistem berjalan Level 0
Flowchart pada level 0 menggambarkan semua proses grup yaitu aktivitas
utama dan aktivitas pendukung yang ada pad Dinas Tata Kota, Bangunan, dan
Rekomendasi
IMB & SLF
Pendataan
Hasil
Musrembang
Design Lelang
Proyek
Pengecekkan
Progress
Bangunan
Pembangunan
Keuangan
Inventaris
103
Permukiman Kota Tangerang Selatan. Proses grup untuk aktivitas utama, yaitu,
rekomendasi IMB dan SLF, pendataan hasil musrembang, design, lelang proyek
dan pembangunan. Proses grup untuk aktivitas pendukung adalah keuangan dan
inventaris. Pada gambar di atas, terdapat arah dan warna tanda panah yang
menunjukan apakah proses group tersebut saling berkaitan dengan proses group
lainnya dengan alur aktivitas searah atau bolak balik.
Pada proses group rekomendasi IMB dan SLF memiliki tanda panah
berwarna hitam menuju proses pendataan hasil musrembang, design, lelang
proyek dan sampai pada proses group pengecekkan progress bangunan. Laporan
yang dikirim hanya akan menjadi laporan pasif alur aktivitasnya adalah satu arah.
Pada proses group aktivitas pendukung mempunyai panah berwarna merah, yaitu
proses group keuangan dan inventaris yang hanya terlibat pada pendataan hasil
musrembang untuk melakukan pencatatan laporan DPA (detail pagu anggaran)
pada setiap proyek yang nantinya di bangun. Sedangkan inventaris hanya untuk
melakukan pencatatan BMN (barang milik negara) yang digunakan di DTKBDP.
104
2. Flowchart Level 1
a. Rekomendasi IMB
Mulai
Pendaftaran
Upload Berkas IMB
Pengecekkan
berkas IMB
Konfirmasi
kelengkapan berkas
IMB
Sidang
Survey lapangan
Mendapat siteplan
Cetak rekomendasi
IMB
Selesai
Gambar 4.3 Flowchart Sistem Berjalan Bagian Rekomendasi IMB.
105
Pada flowchart sistem berjalan bagian rekomendasi IMB di level 1,
digambarkan bahwa ada 8 proses yaitu pendaftaran, upload berkas IMB,
pengecekkan berkas IMB, konfirmasi kelengkapan berkas IMB, sidang, survey
lapangan, mendapat siteplan, cetak rekomendasi IMB.
b. Rekomendasi SLF
Mulai
Upload berkas
SLF
Pengecekkan
berkas SLF
Konfirmasi
kelengkapan
berkas SLF
Pengecekkan
kontruksi
bangunan
Cetak
rekomendasi SLF
selesai
Gambar 4.4 Flowchart Sistem Berjalan Bagian Rekomendasi SLF
106
Pada flowchart sistem berjalan rekomendasi SLF di level 1, digambarkan
bahwa ada 5 proses yaitu proses upload berkas SLF, pengecekkan berkas SLF,
konfirmasi berkas SLF, engecekkan kontruksi bangunan dan cetak rekomendasi
SLF.
c. Pendataan Hasil Musrembang
Mulai
Pengecekkan hasil
musrembang
Penyerahan data
proyek
Mendapat DPA
(Detail Pagu
Anggaran)
Selesai
Gambar 4.5 Flowchart Sistem Berjalan Bagian Pendataan Hasil
Musrembang
Pada flowchart sistem berjalan bagian pendataan hasil musrembang di
level 1, digambarkan bahwa ada 3 proses yaitu proses pengecekkan hasil
musrembang, penyerahan data proyek dan mendapat DPA. Pada proses pertama
hasil musrembang di dapat dari rapat antar warga atau bagian pemerintahan yang
107
nantinya akan dilakukan perbaikan atau pembangunan sarana dan prasarana
pemerintahan dan non pemerintahan di Tagsel. Setelah pengecekan hasil
musrembang, maka akan didaptkan DPA yang sudah di sesuaikan dengan
anggaran pembangunan yang nantinya akan dibangun.
d. Design
Mulai
Pembuatan design
sesuai proyek
Pelaksanaan
lelang
Pembangunan
Selesai
Gambar 4.6 Flowchart Sistem Berjalan Bagian design
Pada flowchart sistm berjalan bagian design di level 1, digambarkan
bahwa ada 3 proses yaitu proses pembuatan design seuai proyek, pelaksanaan
lelang dan pembangunan.
108
e. Progress Bangunan
Mulai
Pengamatan
progress
bangunan
Pengecekkan
kontruksi
bangunan
Pembuatan
laporan progress
bangunan
Selesai
Gambar 4.7 Flowchart Sistem Berjalan Bagian progress bangunan
Pada flowchart sistem berjalan bagian progress bangunan di level 1,
digambarkan bahwa ada 3 proses, yaitu pengamatan progress bangunan,
pengecekkan kontruksi bangunan dan pembuatan laporan progress bangunan.
Progres bangunan dilakukan pada saat pembangunan sedang dilaksanakan,
fungsinya adalah untuk mengetahui secara rinci setiap tahapan proses
pembangunan.
109
f. Keuangan
Mulai
Penyusunan
rencana anggaran
Membuat
dokumen
pelaksanaan
anggaran
Pengesahan
dokumen
pelaksanaan
anggaran
Melaksanakan
akuntansi
keuanagan
Membuat laporan
keuangan
Selesai
Gambar 4.8 Flowchart Sistem Berjalan Bagian Keuangan
Pada flowchart sistem berjalan bagian keuangan level 1, digambarkan
bahwa ada 5 proses, yaitu penyusunan rencana anggaran, membuat dokumen
pelaksanaan anggaran, pengesahan dokumen pelaksanaan anggaran,
melaksanakan akuntansi keuangan dan membuat laporan keuangan. Laporan
keunagn tersebut nantinya akan dilaporkan kepada bagian administrasi DTKBDP.
110
g. Inventaris
Mulai
Melakukan pencatatan
BMN (Barang Milik
Negara)
Menyusun laporan barang
pengguna inventaris
Membuat laporan
pengelola pengguna
inventaris setiap bagian
Selesai
Gambar 4.9 Flowchart Sistem Berjalan Bagian Inventaris
pada flowchart sistem berjalan bagian inventaris level 1, terdpat 3 proses
yaitu, melakukan pencatatan BMN, menyusun laporan barang pengguna BMN
dan membuat laporan pengelola pengguna inventaris setiap bagian.
4.2.2 Issue Organisasi
Berdasarkan dari hasil pengamatan dan analisis yang dilakukan pada
seluruh aktivitas, maka didapatan beberpaa permasalahan yang dia alami
DTKBDP untuk memberikan dukungan SI/TI, seperti yang ditampilkan pada
tabel 4.3 seperti berikut :
111
Tabel 4.3 Permasalahan dalam Aktivitas Organisasi
No Aktivitas Permasalahan Deskripsi
1. Pelayanan
rekomendasi IMB
dan SLF
Pengelolaan
data
pendaftaran
rekomendasi
IMB dan SLF
Pencatatan,
penyimpanan dan
pelaporan data
rekomendasi IMB dan
SLF masih manual,
dan terkadang terjadi
redudancy data.
2. Musrembang Pelaporan
proyek
Pelaporan proyek
masih dicatat
menggunakan
ms.office, belum
mempunyai suatu
aplikasi khusus dan
terkadang data tidak
tersimpan dengan baik
dan sulit utuk dicari.
3. Design Penggambaran
proyek
Pada penggambaran
proyek penyimpanan
gambar hanya
menggunakan aplikasi
seadanya, terkadang
112
gambar banyak yang
hilang karena tidak
adanya penyimpanan
data yang baik.
4. Progress Bangunan Pelaporan
progress
proyek
Belum adanya
fasilitas untuk
pengelolaan data
progress bangunan,
karena pendataan
masih menggunakaan
proses manual.
5. Keuangan Pencatatan
Keuangan
Proses pencatatan
keuangan masih
bersifat manual
Kesulitan dalam
mebuat laporan
keuangan yang cepat
dan akurat
6. Inventaris Pendataan
inventaris
barang
Pendataan inventaris
barang masih manual
Kesulitan dalam
pencatatan inventaris
jika ada banyak
113
perubahan.
4.2.3 Solusi Aktivitas
Pada bagian ini akan dianalisis solusi aktivitas untuk mengatasi
permasalahan-permasalahan pada setiap aktivitas Dinas Tata Kota, Bangunan dan
Permukiman Kota Tangerang Selatan. Solusi yang diberikan pada bagian ini
ditinjau dari sudut pandang proses kerja. Sasaran perbaikannya terfokus hanya
pada alur kerja agar menjadi lebih baik. Solusi aktivitas yang sudah dianalisis
dapat dilihat dalam tabel 4.4.
Tabel 4.4 Solusi Aktivitas
No. Aktivitas Deskripsi Solusi Aktivitas
1. Pelayanan
rekomendasi
IMB dan SLF
Pencatatan, penyimpanan
dan pelaporan data
rekomendasi IMB dan SLF
masih manual, dan
terkadang terjadi redudancy
data.
Perancangan aplikasi
IMB dan SLF.
2. Musrembang
Pelaporan proyek masih
dicatat menggunakan
ms.office, belum
mempunyai suatu aplikasi
khusus dan terkadang data
Penyediaan fasilitas
untuk pelaporan data
proyek bangunan
yang saling
terintegrasi agar data
114
tidak tersimpan dengan baik
dan sulit utuk dicari.
dapat disimpan
dengan baik.
3. Design Pada penggambaran proyek
penyimpanan gambar hanya
menggunakan aplikasi
seadanya, terkadang gambar
banyak yang hilang karena
tidak adanya penyimpanan
data yang baik.
Penyediaan fasilitas
untuk pengelolaan
data design agar data
tersimpan dengan
baik.
4. Progress
Bangunan
Belum adanya fasilitas
untuk pengelolaan data
progress bangunan, karena
pendataan masih
menggunakaan proses
manual.
Penyediaan fasilitas
untuk pelaporan
progress bangunan
yang nantinya mudah
di akses oleh
perbagian didalam
organisasi
5. Keuangan Proses pencatatan keuangan
masih bersifat manual
Kesulitan dalam mebuat
laporan keuangan yang
cepat dan akurat
Penyediaan fasilitas
untuk pencatatan
keuangan yang saling
terintegrasi.
6. Inventaris Pendataan inventaris barang Penyediaan fasilitas
115
masih manual
Kesulitan dalam pencatatan
inventaris jika ada banyak
perubahan.
pelaporan data
inventaris yang saling
terintegrasi.
4.2.4 Data Inventaris Sarana dan Prasarana Pendukung TIK
Pada saat ini, Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan memiliki inventaris prasarana pendukung TIK yang terdapat
dalam tabel 4.4 sebagai berikut :
Tabel 4.5 Data Inventaris Sarana dan Prasarana Pendukung TIK
No Barang Fungsi Jumlah
1. Komputer Operasional 30
2. Printer Operasional 20
3. Laptop Operasional 10
4. Mobile Modem Operasional 5
4.3 Phase A : Architecture Vision
4.3.1 Profil Instansi
Dinas Tata Kota, Bangunan dan Pemukiman terbentuk Berdasarkan
Peraturan walikota No.59 Tahun 2009 dan terdiri atas 4 Bidang dan 1 Sekretariat
yaitu :
116
4.3.2 Visi dan Misi Instansi
Visi Instansi
“Terwujudnya tata ruang, bangunan dan lingkungan pemukiman yang
modern, religius dan berkelanjutan pada tahun 2015 ”.
Misi Instansi
a. Mewujudkan perencanaan yang transparan, efektif dan aplikatif
b. Meningkatkan pelayanan perencanaan teknis sesuai standar mutu
c. Meningkatkan kualitas manajemen dalam perumusan kebijakan
pembangunan kota
d. Mewujudkan perencanaan tata ruang yang modern dan serasi dengan
lingkungan
e. Mewujudkan dan mengendalikan ruang sesuai dengan fungsi dan
peruntukannya
f. Mewujudkan pusat pemerintahan yang handal dan berjati diri
g. Mewujudkan pelayanan bidang bangunan yang aspiratif dan optimal
h. Meningkatkan kualitas sanitasi lingkungan pemukiman
i. Meningkatkan prasarana dan sarana dasar serta utilitas umum di
pemukiman
j. Mewujudkan pengelolaan sampah terpadu
k. Mewujudkan hunian yang layak dan sehat
117
4.3.3 Struktur Organisasi dan Tupoksi DTKBDP
KEPALA DINAS
Ir. DENDI PRYANDANA, MT (IV/b)
NIP. 19661230 199603 1 00 1
SEKRETARIAT
Ir. LISHERNI, M.Si (IV/B)
NIP. 19660226 199303 2
KASI UMUM
Ir. Hj. DENIWATI, MM (IV/a)
NIP. 19650401 199803 1 006
KASUBAG KEUANGAN
Dra. IIS HASTATI ROCHIMAT (III/c)
NIP. 19641213 200501 2 001
KASUBAG PEP
RIKAS DIRGANTARI, ST, MT (IV/a)
NIP. 19691130 200501 1 007
Bidang Tata Ruang
TONNY SOEWANDI, ST (III/d)
NIP. 19701030 199803 1 005
Seksi Perencanaan Tata Ruang
H. BUDI FIRMANSYAH, ST, M.Si,
M.Ak (III/c)
NIP. 19690123 200212 1 002
Seksi Pemetaan
FARAH DIBA, ST, M.Si (III/c)
NIP. 19790531 200604 2 002
Seksi Pengendalian Pemanfaatan
Ruang
MUHAMMAD HAFIZ, ST (III/c)
NIP. 19730707 200604 1 002
Bidang Perumahan
CARSONO, S.ST, MM (III/d)
NIP. 19691105 199101 1 001
Seksi Perumahan
BUWANA MAHARDDIKA, ST (III/
d)
NIP. 19780811 200112 1 003
Seksi Penataan Kawasan
DIAN NUGRAHA, S.Kom (III/c)
NIP. 19730124 200604 1 006
Seksi Penyehatan Lingkungan
Permukiman (PLP)
DEWAN RIDWAN, SE, MM (III/d)
NIP. 19730923 200112 1 004
Bidang Bangunan
MUKODDAS SYUHADA, ST, MT
(III/d)
NIP. 19761028 200112 1 007
Seksi Bangunan Gedung
Pemerintahan
HERI ASARI S.Kom, M.Si (III/b)
NIP. 19800210 201001 1 001
Seksi Bangunan Non Pemerintahan
ASEEP HERMAWAN, ST (III/c)
NIP. 19750807 200212 1 004
Seksi Pemeliharaan Gedung
H. HERRY SURYADRMAWAN,
S.Sos, MM (III/d)
NIP. 19671226 200501 1 004
Seksi Data Informasi dan
Pengujian
TEGUH SUGARWONO, S.Sos
(IV/d)
NIP. 19691130 200501 1 007
Bidang Teknik
DEDENG DASA, ST (III/d)
NIP. 19740420 200112 1 003
Seksi Perenanaan
ADI HERMAWAN, ST, MT
(III/c)
NIP. 19741005 200112 1 003
Seksi Pengawasan
ACHMAD NASUHI, ST, MT
(III/c)
NIP. 19700416 199703 1 010
SUBBAGIAN
RUMAH
TANGGA
SUBBAGIAN
TATA USAHA DAN
SDM
Gambar 4.10 Struktur Organisasi DTKBDP
Dinas Tata Kota Bangunan dan Pemukiman mengepalai Sekretariat,
Bagian Umum, Bidang Tata Ruang, Bidang Perumahan, Bidang Bangunan dan
Bidang Teknik. Berikut ini merupakan tupoksi dari masing-masing bidang :
1. Sekretariat, mempunyai tugas merencanakan, melaksanakan membina
dan mengkoordinasikan serta melakukan pengendalian pada urusan
umum, kepegawaian keuangan serta program, evaluasi dan pelaporan.
Sekretariat menyelenggarakan fungsi:
118
a. Pelaksanaan Bagian Umum yang meliputi Subbagian Tata Usaha
dan SDM serta Subbagian Rumah Tangga.
b. Pelaksanaan Bagian Keuangan
c. Pelaksanaan Bagian PEP
Sekretariat terdiri dari:
1) Subbagian Umum dan Kepegawaian, mempunyai tugas merencanakan,
melaksanakan pembinaan dan mengkoordinasikan serta pengawasan
dan pengendalian sertifikat menyurat, kearsipan, urusan rumah tangga
perlengkapan, pengelolaan administrasi dan kepegawaian.
2) Subbagian Keuangan, mempunyai tugas merencanakan, melaksanakan,
pembinaan dan koordinasi serta pengawasan dan pengendalian
penyusunan rencana anggaran dan belanja dinas.
3) Subbagian Program Evaluasi dan Pelaporan, mempunyai tugas
Merencanakan, melaksanakan pembinaan dan koordinasi serta
pengawasan dan pengendalian program, evaluasi dan pelaporan.
2. Bidang Tata Ruang
Merencanakan, melaksanakan pembinaan dan koordinasi serta
pengawasan dan pengendalian program bidang pemanfaatan dan ruang, informasi
dan bina masyarakat, perencanaan Tata Kota dan Informasi.
119
a. Seksi Pemanfaatan dan Pengendalian kota
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan,
fasilitasi dan pembinaan penyelenggaraan Perencanaan, Pelaksanaan,
pembinaan dan koordinasi, pengawasan serta pengendalian bidang
pemanfaatan dan pengendalian Ruang.
b. Seksi Informasi dan Bina Masyarakat
Merencanakan, melaksanakan pembinaan dan koordinasi serta
pengawasan dan pengedalian program Informasi dan Bina Masyarakat.
c. Seksi Perencanaan Penataan Kota
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan,
fasilitasi dan pembinaan, di bidang Perencanaan Penataan Ruang.
3. Bidang Bangunan
Merencanakan, melaksanakan pembinaan dan koordinasi serta pengawasan
dan pengendalian kegiatan tugas tata bangunan.
a. Seksi Data dan Informasi
Merencanakan, melaksanakan pembinaan koordinasi serta pengawasan
dan pengendalian kegiatan pengolahan data dan informasi perencanaan
bangunan dan Pemukiman
b. Seksi Pengawasan Bangunan
Merencanakan, melaksanakan pembinaan, koordinasi kegiatan
Pengawasan Bangunan.
120
c. Seksi Pemeliharaan Gedung
Merencanakan, melaksanakan pembinaan dan koordinasi, serta
pengawasan dan pengendalian kegiatan pemeliharaan gedung.
4. Bidang Perumahan dan Pemukiman
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi
dan pembinaan di Bidang Perumahan dan Pemukiman.
a. Seksi Perumahan
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan,
fasilitasi dan pembinaan di bidang Perumahan.
b. Seksi Air Bersih
Perencanaan, pelaksanaan, pembinaan dan koordinasi, pengawasan dan
pengendalian di Bidang Pengendalian Air bersih.
c. Seksi Penyehatan Lingkungan Pemukiman (PLP)
Merencanakan, melaksanakan, pembinaan dan koordinasi, pengawasan
dan pengendalian, pengkajian penyehatan lingkungan pemukiman.
5. Bidang Teknik
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan fasilitasi,
pembinaan dan koordinasi perencanaan di bidang teknik.
121
a. Seksi Perencanaan
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan
fasilitasi dan pembinaan penyelenggaraan di bidang perencanaan.
b. Seksi Pengawasan
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan,
fasilitasi dan pembinaan penyelenggaraan di bidang pengawasan.
c. Seksi Pengujian/Laboratorium
Penyusunan bahan perumusan kebijakan umum, penyelenggaraan,
fasilitasi dan pembinaan penyelenggaraan di bidang pengujian /
laboratorium.
4.3.4 Analisis Value Chain
Visi dari Dinas Tata Kota, Bangunan dan Pemukiman adalah
terwujudnya tata ruang, bangunan dan lingkungan pemukiman yang modern,
religius dan berkelanjutan pada tahun 2015.
Sebelum membuat visi arsitektur-arsitektur yang akan dirancang, maka
perlu mendefinisikan dan menganalisis seluruh proses kerja yang ada di Dinas
Tata Kota, Bangunan dan Pemukiman menggunakan analisis value chain. Analisis
value chain dilakukan untuk memetakan seluruh proses kerja yang terjadi dalam
organisasi menjadi dua kategori aktifitas, yaitu aktivitas utama dan aktivitas
pendukung. Aktivitas utama adalah aktivitas yang berhubungan sehingga proses
122
kerja dapat berjalan. Sedangkan aktivitas pendukung digunakan untuk mendukung
dan mengawasi aktivitas utama.
Berikut diagram value chain pada DTKBDP :
Manajjhh
Inventarisvvh
=
Gambar 4.11 Value Chain
Aktivitas bisnis pada DTKBDP menurut analisa value chain sebagai berikut:
1. Aktivitas Utama, yang terdiri dari:
a. Inbound Logistic, pada DTKBDP aktivitas yang termasuk dalam inbound
logistic adalah rekomendasi permohonan pembuatan IMB (Izin
Mendirikan Bangunan), DTKBDP menerima permohonan IMB dari
pemohon yang akan mendirikan bangunan didaerah Tangerang Selatan.
Pembuatan IMB dan SLF bisa dilakukan oleh pihak internal dan eksternal.
Untuk pihak ekternal pembuatan IMB dan SLF tidak mencapai tahap
m
Sup
po
rt Activities
Manajemen Keuangan
Sumber Daya Manusia
Inventaris
Perencanaan Bisnis Strategis
Prim
ary A
ctivities
Inbound
Logistics :
1. Rekomendasi
IMB
2. Hasil
Musrembang
Operation:
1. Sidang
2. Survei
Lokasi
3. DPA
4. Lelang
Proyek
Outbond:
1. Rekomendasi
IMB
2. Bangunan
Marketing:
1. Web
Service:
1. SLF
2. Pengecekan
Progress
Bangunan
Kepuasan
Stakeholder
123
pembangunan oleh DTKBDP. Namun untuk internal DTKBDP dilakukan
sampai tahap pembangunan sampai bangunan selesai. Pemerintah kota
Tangerang Selatan menyerahkan hasil Musrembang (Musyawarah
Rembuk Bangunan) pada bagian sekretariat yang kemudian akan mendata
dan menyiapkan perencanaan bangunan didaerah tangsel.
b. Operation, aktivitas yang dilakukan untuk proses pelaksanaan dalam
melakukan pembuatan rekomendasi IMB dan pembangunan bangunan
sesuai hasil musrembang. Dalam tahap ini ada 4 langkah yang dilakukan:
1. Sidang
Aktivitas ini dilakukan pada saat pembuatan rekomendasi IMB,
sidang dilakukan dengan beberapa tahapan utuk memerikasa
kelengkapan berkas dan mengetahui rincian setiap bangunan yang
nantinya akan didirikan.
2. Survey Lokasi
DTKBDP melakukan survey lapangan pada lahan yang nantinya
akan didirikan bangunan, survey dilakukan oleh tim survey. Hasil
dari survey lapangan ini berupa site plan atau gambaran kondisi pada
lahan yang akan didirikan bangunan.
3. DPA (Detail Pagu Anggaran)
DPA ini merupakan detail pagu anggaran yang diberikan kepada
DTKBDP. Anggaran ini didapatkan melalui BAPEDA (Badan
Pengawas Daerah), anggaran ini diberikan sesuai rincian dari rapat
124
musrembang. Dan anggaran ini nantinya digunakan untuk
pembangunan bangunan dan fasilitas didaerah Tangerang Selatan.
4. Lelang Proyek
Aktivitas ini dilakukan pada saat bangunan yang akan dibangun
sudah selesai didesign oleh bidang teknik, dan kemudian bidang
bangunan melaksanakan proses lelang degan cara mencari kontraktor
yang bersedia melaksanakan proses pembangunan bangunan sampai
selesai.
c. Outbound Logistic, aktivitas ini merupakan hasil akhir, setelah melakukan
beberapa tahapan maka akan didapatkan rekomendasi IMB yang akan
diberikan kepada pemohon dan hasil bangunan yang sudah didirikan.
d. Marketing dan Sales, aktivitas ini berhubungan dengan informasi kepada
masyarakat tentang DTKBDP kota Tangerang Selatan. Informasi melalui
website merupakan aktivitas dalam rangka pengenalan tentang konsep kerja
DTKBDP.
e. Services, aktivitas yang dirancang untuk meningkatkan atau memelihara nilai
produk/jasa. Pada DTKBDP, SLF merupakan sertifikat layak fungsional yang
nantinya akan diberikan kepada pemohon apabila bangunan sudah sesuai
dengan isi pada IMB. Pengecekkan progress bangunan dilakukan untuk
mengontrol proses bangunan yang sedang dibangun.
2. Aktivitas pendukung
Aktivitas di DTKBDP (Dinas Tata Kota Bangunan dan Pemukiman) yang
termasuk ke dalam aktivitas pendukung dalam analisis value chain, yaitu
125
manajemen keuangan, sumber daya manusia, inventaris, perencanaan bisnis dan
strategis. Berikut ini penjelasan aktivitas pendukung :
a. Manajemen Keuangan
Merupakan aktivitas pendukung pada perusahaan, dimana sebuah
perusahaan pada umumnya memiliki bagian atau divisi yang membidangi
aktivitas-aktivitas ini. Aktivitas keuangan meliputi penyusunan rencana
dan program anggaran, pengelolaan keuangan dan pembuatan laporan
keuangan.
b. Sumber Daya Manusia
Aktivitas ini mempunyai fokus kepada usaha recruiting SDM yang
mempunyai potensi, kemudian untuk sumber daya manusia yang sudah
dimiliki diberi pelatihan-pelatihan untuk peningkatan kualitas SDM.
c. Inventaris
Aktivitas ini meliputi pencatatan dan pengelolaan barang milik negara,
pengamanan sarana dan prasarana yang digunakan oleh DTKBDP.
Pengelolaan dan pencatatan barang milik negara dilakukan oleh Subbagian
Rumah Tangga. Tetapi, menjaga dan memelihara sarana dan prasarana
dilakukan oleh seluruh pegawai DTKBDP yang sudah menggunakan
sarana-prasarana tersebut.
d. Perencanaan Bisnis dan Strategis
Aktivitas ini mempunyai tujuan melakukan perencanaan bisnis dan
strategis untuk menunjang rencana kegiatan yang akan dianggarkan satu
126
tahun kedepan dalam rangka memperbaiki sektor pembangunan didaerah
Tangerang Selatan.
Tabel 4.6 Target Value Chain
Langkah dalam
value chain Aktivitas Output yang diharapkan
Inbound Logistic 1. Rekomendasi IMB
2. Hasil Musrembang
Penerapan pendaftaran online
Hasil musrembang yang
akurat, serta management
penyimpanan musrembang
yang baik
Operation 1. Sidang
2. Survey Lokasi
3. DPA
4. Lelang Proyek
Penerapan penggunaan
sistem pada proses sidang,
survey lokasi dan DPA
Penerapan penggunaan
sistem pada lelang proyek,
agar mendapatkan kontraktor
yang sesuai
Outbond Logistic 1. Rekomendasi IMB
Hasil rekomendasi IMB yang
akurat serta management
penyimpanan yang baik
2. Bangunan Hasil bangunan sesuai
dengan IMB dan
musrembang
Marketing & Sales Website Pemberitahuan informasi
127
tentang DTKBDP kota
Tangerang Selatan meluas
kepada masyarakat
Service 1. SLF
2. Pengecekkan Progress
Bangunan
Sertifikat untuk kesesuaian
pembangunan dengan isi
IMB
Proses pengecekkan untuk
mengetahui kondisi
pembangunan secara detail
Aktivitas Pendukung 1. Manajemen Keuangan
2. Sumber Daya Manusia
3. Inventaris
4. Perencanaan Bisnis
Strategis
Laporan keuangan yang
tepat, akurat, terintegrasi dan
real time
Pengembangan kompetensi
setiap pegawai
Pencatatan dan pengelolaan
barang milik negara,
pengamanan sarana dan
prasarana yang digunakan
oleh DTKBDP menggunakan
sistem
Pengembangan bisnis dan
strategis untuk menujang
rencana kegiatan yang akan
dianggarkan
128
4.3.5 Struktur Organisasi Usulan
Jika melihat struktur organisasi saat ini, DTKBDP belum memiliki
bagian yang khusus melakukan pengembangan dan perawatan untuk TI di
DTKBDP. Sedangkan, jika akan mengimplementasikan arsitektur-arsitektur yang
akan dibuat, maka sangat dibutuhkan peran bagian TI dalam proses tersebut.
Oleh karena itu, maka terdapat penambahan bagian dan subbagian untuk
struktur organisasi usulan, yaitu menambahkan bagian baru, yaitu bagian IT.
Berikut ini adalah gambar untuk struktur organisasi yang diusulkan.
KEPALA DINAS
Ir. DENDI PRYANDANA, MT (IV/b)
NIP. 19661230 199603 1 00 1
SEKRETARIAT
Ir. LISHERNI, M.Si (IV/B)
NIP. 19660226 199303 2
KASI UMUM
Ir. Hj. DENIWATI, MM (IV/a)
NIP. 19650401 199803 1 006
KASUBAG KEUANGAN
Dra. IIS HASTATI ROCHIMAT (III/c)
NIP. 19641213 200501 2 001
KASUBAG PEP
RIKAS DIRGANTARI, ST, MT (IV/a)
NIP. 19691130 200501 1 007
Bidang Tata Ruang
TONNY SOEWANDI, ST (III/d)
NIP. 19701030 199803 1 005
Seksi Perencanaan Tata Ruang
H. BUDI FIRMANSYAH, ST, M.Si,
M.Ak (III/c)
NIP. 19690123 200212 1 002
Seksi Pemetaan
FARAH DIBA, ST, M.Si (III/c)
NIP. 19790531 200604 2 002
Seksi Pengendalian Pemanfaatan
Ruang
MUHAMMAD HAFIZ, ST (III/c)
NIP. 19730707 200604 1 002
Bidang Perumahan
CARSONO, S.ST, MM (III/d)
NIP. 19691105 199101 1 001
Seksi Perumahan
BUWANA MAHARDDIKA, ST (III/
d)
NIP. 19780811 200112 1 003
Seksi Penataan Kawasan
DIAN NUGRAHA, S.Kom (III/c)
NIP. 19730124 200604 1 006
Seksi Penyehatan Lingkungan
Permukiman (PLP)
DEWAN RIDWAN, SE, MM (III/d)
NIP. 19730923 200112 1 004
Bidang Bangunan
MUKODDAS SYUHADA, ST, MT
(III/d)
NIP. 19761028 200112 1 007
Seksi Bangunan Gedung
Pemerintahan
HERI ASARI S.Kom, M.Si (III/b)
NIP. 19800210 201001 1 001
Seksi Bangunan Non Pemerintahan
ASEEP HERMAWAN, ST (III/c)
NIP. 19750807 200212 1 004
Seksi Pemeliharaan Gedung
H. HERRY SURYADRMAWAN,
S.Sos, MM (III/d)
NIP. 19671226 200501 1 004
Seksi Data Informasi dan
Pengujian
TEGUH SUGARWONO, S.Sos
(IV/d)
NIP. 19691130 200501 1 007
Bidang Teknik
DEDENG DASA, ST (III/d)
NIP. 19740420 200112 1 003
Seksi Perenanaan
ADI HERMAWAN, ST, MT
(III/c)
NIP. 19741005 200112 1 003
Seksi Pengawasan
ACHMAD NASUHI, ST, MT
(III/c)
NIP. 19700416 199703 1 010
SUBBAGIAN
RUMAH
TANGGA
SUBBAGIAN
TATA USAHA DAN
SDM
Bagian IT
Application
System Analyst Programmer
Technological
Support
System
Administrator
Database
AdministratorHelpdisk
Gambar 4.12 Struktur Organisasi usulan DTKBDP
129
Adapun penjelasan terhadap pembagian sub-sub pada divisi teknologi
informasi adalah sebagai berikut:
1. Application
a. Sistem analyst
System analyst berperan dalam mendesain sistem secara
keseluruhan, baik dari segi basis data, aplikasi, dan teknologi
informasi pendukung. Dalam merancang sistem, system analyst yang
telah mengumpulkan informasi yang dibutuhkan dari pengguna.
Dengan adanya system analys maka diharapkan pengembangan dan
pembangunan aplikasi yang baru dapat berjalan dengan baik dan
sesuai dengan rencana. System analyst juga berfungsi untuk
memberikan gambaran yang baik kepada programmer untuk
membangun aplikasi agar sesuai dengan apa yang dibutuhkan.
b. Programmer
Programmer berperan dalam tahap pembangun dan
pengembangan aplikasi-aplikasi yang telah didesain oleh system
analyst. Dengan adanya acuan desain sistem yang berasal dari
system analyst diharapkan programmer dapat mengerjakan dan
menyelesaikan pembuatan aplikasi secara tepat dan sesuai dengan
perencanaan yang telah dibuat.
130
2. Technological Support
a. System administrator
System administrator berperan dalam melakukan konfigurasi
terhadap sistem jaringan komputer, baik server, client, dan system
software yang membentuk sebuah infrastruktur dimana terdapat
aplikasi dan data perusahaan. Sistem yang dimaksud adalah sistem
mail server, file sharing, proxy server dan application server. Selain
melakukan konfigurasi, system administrator juga bereperan dalam
hal maintenance dan melakukan control sistem agar dapat berjalan
dengan baik.
b. Database administrator
Database administrator berperan dalam mendesain arsitektur
database, melakukan install dan konfigurasi database software,
berpartisipasi pada desain dan pengembangan dengan programmer,
menjamin keamanan data, dan mengawasi serta meningkatkan
performansi database. Dinas Tata Kota, Bangunan, dan
Pemukiman membutuhkan tenaga yang mampu melakukakn semua
tugas diatas untuk mendukung aplikasi yang berjalan serta aplikasi
yang diusulkan. Sehingga basis data yang menyimpan data selalu
aman. Mem-backup, restore, authentication, dan role dari
pengguna juga merupakan tanggung jawab dari Database
administrator.
131
c. Helpdisk
Helpdisk atau teknisi bertugas melakukan perawatan dan
perbaikan perangkat keras/perangkat lunak komputer, instalasi
perangkat keras/lunak, pemasangan jaringan LAN, Internet dan
Intranet dan menangani tindak lanjut atas keluhan dan pengguna
layanan dalam DTKBDP.
4.3.6 Pelatihan yang Diusulkan
Pelatihan ini diusulkan kepada bagian yang baru diusulkan dalam struktur
organisasi usulan di DTKBDP agar nantinya dapat melaksanakan tugasnya
dengan baik. Berikut ini adalah daftra pelatihan usulan yang diperlukan oleh
pegawai DTKBDP.
Tabel 4.7 Daftar Pelatihan Usulan
No Jabatan Tugas Jenis Pelatihan
1. System Analyst Berperan dalam
mendesain sistem secara
keseluruhanm baik dari
segi basis data, aplikasi
dan teknologi.
Pelatihan yang diberikan
adalah untuk
mengembangkan kemampuan
untuk menganalisis dalam
perencanaan dan
pengembangan sistem
2. Programmer Perannya adalah untuk
tahap oembangunan dan
Pelatihan ini diberikan untuk
mengembangkan kemampuan
132
pengembangan aplikasi
yang telah didesain oleh
system analyst.
programming sehingga dapat
mengembangkan aplikasi
sesuai dengan tujuan bisnis.
3. System
Administrator
Berperan dalam
melakukakan konfigurasi
terhadap sistem jaringan
komputer.
Pelatihan yang diberikan
adalah untuk kemampuan
membuat, mengembangkan
dan memelihara infrastruktur
jaringan yang ada.
4. Database
Administratir
Berperan dalam
mendesain arsitektur
database, melakukan
install dan konfigurasi.
Dan juga untuk
menjamin keamanan
data, dan mengawasi
serta meningkatkan
performansi database.
Pelatihan yang diberikan
adalah untuk
mengembangkan kemampuan
dalam mengelola keamanan
sistem untuk melindungi
sistem informasi dari hal-hal
yang dapat merusak
informasi.
5. Help Disk Berperan dalam
melakukan perawatan
dan perbaikan perangkat
keras/lunak komputer
apabila mendapat suatu
masalah.
Pelatihan yang diberikan
adalah untuk mengatur
pengaduan pengguna
mengenai masalah dan
kendala penggunaan sistem
tersebut.
133
4.3.7 Hubungan Stakeholder dengan Aktivitas Organisasi
Pada tahapan ini akan dijelaskan mengenai proses bisnis di DTKBDP
memiliki beberapa stakeholder yang memiliki kepentingan terhadap proses bisnis
utama dan pendukung yaitu :
1. Bidang Tata Ruang
2. Bidang Bangunan
3. Bidang Teknik
4. Subbag Tata Usaha dan SDM
5. Pemohon
6. Bagian Keuangan
7. Pemerintah
8. Non Pemerintah
9. Kepala Dinas
Tabel 4.8 Stakeholder Map Matrix
Stakeholder
Aktivitas
Tat
a R
uan
g
Bid
. B
angu
nan
Bid
. T
eknik
Su
bb
ag. T
ata
Usa
ha
Pem
ohon
Bag
. K
euan
gan
Kep
ala
Din
as
Pem
erin
tah
Non P
emer
inta
h
Aktivitas Utama
1. Rekomendasi IMB &SLF
2. Hasil Musrembang
3. Sidang
134
4. Survey Lokasi
5. DPA
6. Lelang Proyek
7. Rekomendasi IMB &SLF
8. Bangunan
Aktivitas Pendukung
1. Manajemen Keuangan
2. SDM
3. Inventaris
4. Perencanaan Bisnis Strategis
Tabel 4.9 Penjelasan Keterlibatan Stakeholder di Setiap Aktivitas
No Aktivitas Stakeholder Keterlibatan
1. Rekomendasi IMB
dan SLF
Pemohon Memberikan berkas
Tata Ruang Mengkonfirmasi kelengkapan
berkas
Bidang Bangunan Mengecek kondisi tanah
Bidang Teknik membuatkan siteplan
Kepala Dinas Mengesahkan rekomendasi
2. Hasil Musrembang Tata Ruang Mengecek hasil muerembang
Kepala Dinas Mengesahkan musrembang
3. Sidang Bidang Bangunan Melaksanakan sidang berkas
135
Bidang Teknik Membuat gambaran kondisi
lahan (siteplan)
4. Survei Lokasi Bidang Bangunan Pelaksanakan survei lapangan
untuk mengetahui kondisi lahan
yang nantinya akan dibangun
dan dibuatkan IMB
Bidang Teknik
5. DPA Bag. Keuangan Mengatur keuangan untuk
pembangunan sarana dan
prasarana pemerintah dan non
pemerintah yang sudah
disesuaikan dengan hasil
musrembang
6. Lelang Proyek Bidang Bangunan Mencari kontraktor untuk
melaksanakan pembangunan
7. Rekomendasi IMB
dan SLF
Tata Ruang Mencetak rekomendasi
Pemohon Mendapatkan rekomendasi
Kepala Dinas Mengesahkan rekomendasi
8. Bangunan Bidang Bangunan Mendapatkan hasil bangunan
yang sesuai
Pemerintah Menyelesaikan pembangunan
untuk pemerintah
Non Pemerintah Menyelesaikan pembangunan
untuk non pemerintah
136
9. Manajemen
Keuangan
Bagian Keuangan Mengelola penggunaan
keuangan dan pencatatan
keuangan
Kepala Dinas Menerima semua laporan
aktivitas keuangan
10. SDM Subbag Tata Usaha Melakukan pelatihan kepada
setiap pegawai
11. Inventaris Subbag Tata Usaha Mengelola penggunaan
inventaris disetiap bagian
DTKBDP
Bagian Keuangan Mencatata laporan inventaris
12. Perencanaan Bisnis
Strategis
Subbag Tata Usaha Pelaksanaan proses perbaikan
berjangka setiap 5 tahun sekali
4.4 Phase B : Buseiness Architecture
4.4.1 Pemetaan Layanan Bisnis, Proses Bisnis, dan Fungsi Bisnis di Dinas
Tata Kota Bangunan dan Permukiman Kota Tangerang Selatan
Pemetaan layanan bisnis, proses bisnis, dan fungsi bisnis digambarkan
dengan bentuk seperti diagram pohon. Top Level dalam pemetaan ini adalah
layanan bisnis. Setiap layanan bisnis mempunyai beberapa proses bisnis dan sub
proses bisnis. Terakhir, setiap proses bisnis akan mempunyai beberapa fungsi
bisnis dan sub fungsi. Sub fungsi bisnis merupakan untuk aktivitas terkecil.
137
Berikut ini adalah tree diagram untuk pemetaan gabungan layanan bisnis,
proses bisnis, dang fungsi bisnis di Dinas Tata Kota Bangunan dan Permukiman
KotaTangerangSelatan.
138
Gambar 4.13 Tree Diagram Pemetaan Layanan Bisnis, Proses Bisnis dan Fungsi Bisnis DTKBDP
139
1. Layanan Bisnis
Gambar 4.14 Layanan Bisnis di DTKBDP
Pada gambar 4.14 menjelaskan bahwa layanan pada DTKBDP terdapat
pelayanan yaitu IMB dan pembangunan.
1. Proses Bisnis
Gambar 4.15 Proses Bisnis Pada Layanan IMB DTKBDP
Pada gambar 4.15 menjelaskan bahwa pada layanan IMB memiliki
beberapa proses bisnis seperti proses pendaftaran, persidangan dan verifikasi SLF.
140
Gambar 4.16 Proses Bisnis Pada Layanan Pembangunan DTKBDP
Pada gambar 4.16 menjelaskan pada layanan pembangunan DTKBDP
memiliki beberapa proses bisnis seperti proses pendataan, design dan progress
bangunan.
2. Fungsi Bisnis
a. Pendaftaran
Gambar 4.17 Fungsi Bisnis pada Proses Bisnis Pendaftaran
141
pada gambar 4.17 menjelaskan pada proses bisnis pendaftaran terdapat
beberapa fungsi bisnis seperti penyerahan berkas IMB dan SLF, pengecekkan
kelengkapan berkas, dan pengkonfirmasian kelengkapan berkas.
b. Persidangan
Gambar 4.18 Fungsi Bisnis pada Proses Bisnis Persidangan
Pada gambar 4.18 menjelaskan pada proses bisnis persidangan terdapat
beberapa fungsu bisnis seperti sidang, survey lapangan, siteplan, pemeriksaan
berkas administrasi, konfirmasi kelengkapan berkas, rekomendasi IMB dan
pelaporan IMB.
142
c. Verifikasi SLF
Gambar 4.19 Fungsi Bisnis pada Proses Bisnis Verifikasi Berkas SLF
Pada gambar 4.19 menjelaskan pada proses bisnis verifikasi berkas SLF
terdapat beberapa fungsi binsis seperti pemeriksaan berkas SLF, konfirmasi
kelengkapan berkas, pemeriksaan gedung bangunan, pengesahan rekomendasi
SLF dan rekomendasi SLF.
d. Pendataan
Gambar 4.20 Fungsi Bisnis pada Proses Bisnis Pendataan
143
Pada gambar 4.20 menjelaskan pada proses bisnis pendataan terdapat
beberapa fungsi binsis seperti pengecekkan hasil musrembang dan penyerahan
data proyek.
e. Design
Gambar 4.21 Fungsi Bisnis pada Proses Bisnis Design
Pada gambar 4.21 menjelaskan pada proses bisnis design terdapat
beberapa fungsi binsis seperti pembuatan design sesuai proyek, pelaksanaan
lelang dan pembangunan.
144
f. Progress Bangunan
Gambar 4.22 Fungsi Bisnis pada Proses Bisnis Progress Bangunan
Pada gambar 4.22 menjelaskan pada proses bisnis Progress Bangunan
terdapat beberapa fungsi binsis seperti pengamatan Progress Bangunan,
pengecekkan kontruksi bangunan dan pembuatan laporan Progress Bangunan.
145
4.4.2 Rancangan Architecture Business
Tabel 4.10 Pemetaan Kendala
No Bagian Kendala Solusi
1. Pelayanan IMB dan
SLF
Pelayanan masih
dilakukan papper
based, dan terlalu
banyak sidang
Perancangan aplikasi
IMB dan SLF
2. Tim survey IMB dan
SLF
Survey lokasi masih
dilakukan secara
manual
Perancangan sistem
pemetaan lokasi
3. DPA Belum ada
management database
Membuat DBMS
4. Sekretariat Pertukaran data masih
papper based
Sistem terintegrasi antar
bidang
5. Bangunan Proses lelang masih
manual
Pembuatan Sistem
Pendukung Keputusan
(SPK)
6. Keuangan Proses pencacatan
keuangan masih
bersifat manual
kesulitan dalam
membuat laporan
Pembuatan sistem
keuangan
146
keuangan yang
cepat dan akurat
7. Inventaris Pendataan
inventaris barang
masih manual
Kesulitan dalam
pencatatan
inventaris jika ada
banyak perubahan
Pembuatan sistem E-
inventaris
Solusi visi arsitektur sesuai dengan solusi dari kendala yang ada sebagai
berikut:
147
Portal DTKBDP
Pemohon1. Daftar IMB
2. Upload berkas SekretariatInformasi Publik
Tim Survey
Aplikasi E-IMB dan SLF
3. Cek BerkasTABG
5. Cek berkas
site plan6. Input
rekomendasi
7. Cetak rekomendasi IMB
8. Menyerahkan rekomendasi IMB
9. Upload SLF
Panitia SLF
10. Pemerikasaan
berkas SLF
12. Input berkas SLF
Pemerintah
Kota
13. Input hasil
musrembang
SPK LelangBagian Keuangan
14. Input DPA Kontraktor
16. Input spesifikasi
proyek
Bidang Teknik15. Input design
Pengawasan Bangunan
Aplikasi Progress
Bangunan
17. Manage data
pembangunan
18. Input progress
pembangunan
Kepala Dinas
19. View laporan
pembangunan
View Laporan
13. Cetak SLF
11. Konfirmasi
kontruksi bangunan
4. Survey Lapangan
Aplikasi E-Inventaris
Subbag. Rumah Tangga
Bidang Bangunan21. Manage Data Inventaris
20a. Input Data Inventaris
20. Input Data Inventaris
22. View Laporan Inventaris
Pengesahan
Aplikasi E-KeuanganSubbag Tata Usaha
Bagian Keuangan
23. Melakukakn pencantatan
akuntansi
24. Mengatur periode pembuatan
Laporan keuangan25. Melihat laporan keuangan
26. Input Rekomendasi
IMB Musrembang
27. Input Rekomendasi
SLF Pemkot
terintegrasi
Gambar 4.23 Solusi Arsitektur Bisnis
148
1. Permohonan Rekomendasi IMB dan SLF
Pemohon Portal DTKBDP
1, Daftar IMB
2. Upload Berkas
Aplikasi E-IMB dan SLF
Tim Survey
3. Cek Berkas
4. Survey Lapangan
TABG
Integrasi
5. Cek Berkas Site Plan
Sekretariat
7. Cetak Rekomendasi IMB
8. menyerahkan Rekomendasi IMB
9. Upload SLF
Panitia SLF
10. Pemeriksaan Berkas
SLF
11. Konfirmasi Kontruksi
Bangunan
12. Cetak SLF
13. menyerahkan IMB musrembang
14. Input SLF pemkot
Pengawas Bangunan
Bidang Bangunan
15. cetak IMB musrembang
16. cetak SLF pemkot
Gambar 4.24 Solusi Arsitektur Bisnis Rekomendasi IMB & SLF
Solusi arsitektur bisnis rekomendasi IMB dan SLF ini akan mengubah
sistem pengelolaan data rekomendasi yang masih menggunakan ms.offfice
menjadi sistem terkomputerisasi melalui aplikasi E-IMB dan SLF. Pemohon harus
upload berkas IMB kedalam portal DTKBDP dan akan terintegrasi kedalam
aplikasi E-IMB dan SLF. Tim survey harus melakukan log in kedalam aplikasi E-
IMB dan SLF untuk mengecek berkas kemudilan melakukan survey lapangan
sesuai dengan isi IMB melalui gps. Bagian bidang bangunan memberikan IMB
musrembang dan bagian pengawas bangunan memberikan SLF pada saat
bangunan internal DTKBDP sudah dibangun.
149
Setelah melakukan survey lokasi, maka akan didapatkan hasil siteplan
yang berisi kondisi lapangan yang nantinya akan didirikan bangunan. Sekretariat
log in ke aplikasi, kemudian mencetak rekomendasi IMB dan diserahkan kepada
pemohon. Setelah rekomendasi IMB selesai, makn dibuat SLF (Sertifikat Layak
Bangunan). Pemohon harus upload berkas SLF kedalam portal DTKBDP, panitia
SLF akan mengecek berkas, dan melakukan konfirmasi kontruksi bangunan
kedalam sistem. Apabila isi kontruksi bangunan sudah sesuai dengan isi IMB,
sekretariat mencetak rekomendasi SLF dan diberikan kepada pemohon.
Sekretariat juga memberikan berkas IMB dan SLF pada bangunan non
pemerintahan atau pemerintahan didaerah Tangerang Selatan setelah design
bangunan didapatkan dari hasil musrembang.
2. SPK Lelang
Pemerintah Kota Portal DTKBDP
1. Input Hasil Musrembang
Aplikasi SPK Lelang
Integrasi
Bagian Keuangan
2. Input DPA
Bidang Teknik
3. Input Design
Kontraktor4, Input
Spesifikasi Proyek
Gambar 4.25 Solusi Arsitektur Bisnis SPK Lelang
150
Solusi arsitektur bisnis SPK Lelang ini akan mengubah sistem
pengelolaan data SPK Lelang yang masih menggunakan ms.offfice menjadi sistem
terkomputerisasi melalui aplikasi SPK Lelang. Pemerintah kota harus terlebih
dahulu menginput data musrembang (Musyawarah Rembuk Bangunan) yang
didapat dari hasil rembuk dari masyarakat atau pemerintah mengenai
pembangunan atau perbaikan sarana dan prasaran didaerah TangSel. Setelah
diinput maka akan terintegrasi kedalam aplikasi SPK Lelang.
Setelah hasil musrembang didapat, maka bagian keuangan harus login dan
menginput DPA (Detail Pagu Anggaran) kedalam sistem, yang nantinya DPA
tersebut disesuaikan dengan rencana pembangunan atau perbaikan bangunan di
TangSel. Bidang teknik harus login kedalam sistem dan input design bangunan
kedalam sistem. Kemudian kontrakor bisa masuk kedalam sistem dengan
melakukan login dan menginput spesifikasi proyek yang sedang dicari oleh pihak
kontraktor, apabila dirasa proyek di DTKBDP sesuai, maka DTKBDP akan
melakukan konfirmasi melalui sistem kepada kontraktor.
151
3. Progress Bangunan
Pengawas Bangunan
Aplikasi Progress
Bangunan
Kepala Dinas
3. View Laporan
Pembangunan
1. kelola data bangunan
2. input progress bangunan
Gambar 4.26 Solusi Arsitektur Bisnis Progress Bangunan
Solusi arsitektur bisnis Progress Bangunan ini akan mengubah sistem
pengelolaan data progress bangunan yang masih menggunakan ms.offfice
menjadi sistem terkomputerisasi melalui aplikasi Progress Bangunan.
Pengawas bangunan harus terlebih dahulu melakukan login kedalam
aplikasi, dan melakukakn kelola data bangunan kemudian menginput kedalam
sistem. Kepala dinas melihat laporan progress bangunan dan melakukan login
kedalam sistem.
152
4. E-inventaris
Subbag. Rumah Tangga
Aplikasi E-inventaris
2. Kelola Data Inventaris
Bagian Keuangan
3. View Laporan Inventaris
Bidang Teknik
1. Input Data Inventaris
Bidang Bangunan
1a. Input Data Inventaris
Gambar 4.27 Solusi Arsitektur Bisnis E-inventaris
Solusi arsitektur bisnis E-inventaris ini akan mengubah sistem pengelolaan
data inventaris yang masih menggunakan ms.offfice menjadi sistem
terkomputerisasi melalui aplikasi E-inventaris.
Pada pencatatan penggunaan inventaris di DTKBDP, setiap bidang harus
melakukan login terlebih dahulu kedalam sisem, kemudian setiap bidang harus
menginput data inventaris yang mereka gunakan setiap bulan.
Subbag. Rumah tangga melakukan login kedalam sistem untuk mengelola
data inventaris yang digunakan setiap bidang di DTKBDP. Bagian keuangan
melihat laporan inventaris melalui sistem E-inventaris.
153
5. Keuangan
Subbag. Tata UsahaAplikasi E-keuangan
1. Melakukan Pencatatan
Akuntansi
Bagian Keuangan
2. Mengatur Periode
Pembuatan Laporan
Keuangan
Kepala Dinas
3. Melihat Laporan Keuangan
Gambar 4.28 Solusi Arsitektur Bisnis E-keuangan
Solusi visi arsitektur keuangan akan menggunakan aplikasi E-keuangan.
Aplikasi E-keuangan mengubah sistem keuangan sebelumnya hanya
menggunakan microsoft excel, dimana penggunaan tersebut rawan untuk menjaga
kualitas data keuangan. Bagian keuangan dan Tata Usaha yang terlibat dalam
aplikasi E-keuangan harus terlebih dahulu melakukan login.
Bagian keuangan mengelola periode pembuatan laporan keuangan,
menginput pemasukan keuangan. Aplikasi E-keuangan akan menghasilkan
laporan keuangan yang merupakan hasil dari pengelolaan terhadap pengeluaran
dan pemasukan keuangan tiap periodenya. Laporan keuangan tersebut akan dilihat
oleh kepala dinas sebagai bentuk pertanggungjawaban data keuangan.
154
4.5 Phase C: Information System Application
4.5.1 Application Architecture
Portofolio ini dibuat untuk memudahkan dalam melakukan identifikasi
aplikasi berdasarkan proses bisnis.
Tabel 4.11 Application Portofolio
No Aplikasi Fungsi
1. Portal DTKBDP Aplikasi berbasis web yang
memudahkan pemohon untuk
mengajukan permohonan rekomendasi
IMB dan SLF
2. Aplikasi IMB & SLF Mengkonfirmasi permohonan
rekomendasi IMB dan SLF, pencatatan
pemohon, pencatatan laporan
pendaftaran rekomendasi IMB dan SLF
3. Aplikasi SPK Lelang Mengkonfirmasi hasil musrembang
didaerah Tangsel, dan mengetahui
anggaran sesuai musrembang.
Memberikan keputusan kepada
kontraktor yang nantinya terpilih untuk
membangun bangunan yang sudah
disesuaikan dengan design, dan
anggaran dari DTKBDP Tangsel
155
4. Aplikasi Progress
Bangunan
Pencatatan hasil progress bangunan
yang sedang dibangun didaerah
Tangsel serta mengetahui grafik
pembangunan bangunan
5. Aplikasi E-inventaris Pencatatan penggunaan BMN (Barang
Milik Negara) tersebut akan selalu
terupdate pada setiap periode
semesteran atau pertahun.
6. Aplikasi Keuangan Melakukan pencatatan keuangan, untuk
mengetahui laporan keuangan di
DTKBDP. Dan mengatur periode
pembuatan laporan keuangan di dalam
sistem keuangan.
156
Rancangan ini mencakup model bisnis usulan berdasarkan skenario
bisnis yang sudah diidentifikasikan berdasarkan fase sebelumnya. Berikut
penggambaran skenario bisnis dalam use case diagram.
157
Gambar 4.29 Arsitektur Aplikasi
System
Tim Survey
Daftar Rekomendasi IMB
Upload Berkas IMB
View Berkas
Survey Lapangan
Pemohon
TABG Cek Berkas Site Plan
Input Rekomendasi IMB
Sekretariat
Cetak Rekomendasi IMB
Panitia SLF
Periksa Berkas Surat Layak Fungsioanal
Konfirmasi Kontruksi Bangunan
Cetak Rekomendasi Surat Layak Fungsional
Bagian Keuangan
Input DPA
Bidang Teknik
Input Design Proyek
KontraktorInput Proposal Proyek
Pengawas Bangunan
Manage Data Bangunan
Input Progress Bangunan
Kepala Dinas
View Laporan Progress Bangunan
View Laporan
Pengesahan
Pemerintah Kota
Input Hasil Musrembang
Memilih Kontraktor
Approve Proyek
Input Rekomendasi Surat Layak Fungsional
Subbag Rumah Tangga
Bidang Bangunan
Manage Data Inventaris
Input Pengguna Data Inventaris
Mencatat Laporan Keuangan
Manage Data Keuangan
Upload Berkas Surat Layak Fungsional
View Laporan Inventaris
View Laporan Keuangan
Input Rekomendasi SLF Pemkot
Input Rekomendasi IMB Musrembang
Log in
Log Out
<<include>>
Manajemen UserAdmin
158
4.3.5.1 Arsitektur Aplikasi Permohonan Rekomendasi IMB
Gambar 4.30 Arsitektur Aplikasi Permohonan Rekomendasi IMB
Arsitektur bisnis permohonan rekomendasi IMB memiliki 7 aktor dan 12
usecase yang dapat dilakukan dalam sistem permohonan rekomendasi IMB. Aktor
yang terlibat yaitu admin, pemohon, TABG (Tenaga Ahli Bangunan Gedung),
kepala dinas, bidang bangunan, tim survey, dan sekretariat.
Use case yang terlibat dalam sistem permohonan rekomendasi IMB yaitu,
login, logout, manajemen user, daftar rekomendasi IMB, upload berkas IMB,
view berkas, survey lapangan, cek berkas siteplan, input rekomendasi IMB, cetak
Pemohon
Daftar Rekomendasi IMB
Upload Berkas IMB
Tim Survey
View Berkas
Survey Lapangan
TABG
Cek Berkas Site Plan
Input Rekomendasi IMB
Sekretariat
Kepala Dinas
Pengesahan Permohonan Sertifikat Layak FUngsional
Cetak Rekomendasi IMB
View Laporan Rekomendasi IMB
Bidang Bangunan
Log in
Log Out
<<include>>
Admin
Manajemen User
Input Rekomendasi IMB Musrembang
159
rekomendasi IMB, pengesahan permohonan rekomendasi IMB, input
rekomendasi IMB musrembang dan view rekomendasi IMB.
Aktivitas dan fungsi bisnis Permohonan rekomendasi IMB dimulai dari
pemohon yang membuka website DTKBDP dan melakukan pendaftaran
rekomendasi IMB, kemudian pemohon mengupload berkas IMB. Tim survey
akan melihat kelengkapan berkas IMB, kemudian setelah berkas dirasa sudah
lengkap, maka tim survey mulai melakukan survey lapangan di lahan yang
nantinya akan dibuatkan IMB dan akan didirikan bangunan. Setelah tim survey
sudah melaksanakan survey lapangan, akan didapatkan siteplan yang berisi
gambaran kondisi lahan dan diberikan kepada bagian Tenaga Ahli Bangunan
Gedung (TABG) dan menginput rekomendasi IMB tersebut. kemudian
rekomendasi IMB dicetak oleh bagian Tenaga Ahli Bangunan Gedung (TABG)
dan disahkan oleh kepala dinas dan kepala dinas juga mempunyai wewenang
untuk melihat laporan rekomendasi IMB tersebut. Bidang bangunan juga
membuat rekomendasi IMB untuk musrembang di Dinas Tata Kota, Bangunan
dan Pemukiman Kota Tangerang Selatan.
160
4.3.5.2 Arsitektur Aplikasi Rekomendasi SLF
Gambar 4.31 Arsitektur Aplikasi Rekomendasi SLF
Arsitektur bisnis rekomendasi SLF memiliki 7 aktor dan 9 use case yang
dapat dilakukan dalam sistem rekomendasi SLF. Aktor yang terlibat yaitu admin,
pemohon, panitia SLF, kepala dinas, pengawas bangunan, pemeriksa lapangan
dan sekretariat.
Use case yang terlibat dalam sistem rekomendasi SLF yaitu , logout,
manajemen user, upload berkas SLF, periksa berkas sertifikat layak fungsional,
konfirmasi kontruksi bangunan, cetak rekomendasi sertifikat layak fungsional,
pengesahan sertifikat layak fungsional dan view laporan sertifikat
layakfungsional.
Pemohon
Upload Berkas SLF
Pemeriksa Lapangan
Panitia SLF
Periksa Berkas Surat Layak Fungsioanal
Konfirmasi Kontruksi Bangunan
Sekretariat
Cetak Rekomendasi Surat Layak Fungsional
Kepala Dinas
Pengesahan Permohonan Sertifikat Layak FUngsional
View Laporan Proyek
Pengawas Bangunan
Log in
Log Out<<include>>
AdminManajemen User
Input Rekomendasi SLF Pemkot
161
Aktivitas bisnis pada proses rekomendasi SLF yaitu pemohon mengupload
berkas SLF, berkas SLF tersebut didapatkan dari hasil rekomendasi IMB. Panitia
SLF memerikas kelengkapan berkas kemudian bagian panitia lapangan
mengkonfirmasi kontruksi bangunan yang sebelumnya sudah tertulis didalam
rekomendasi IMB, hanya untuk memastikan kesesuaian antara isi dari IMB dan
bangunan yang sudah dibangun. Bagian sekretariat mencetak rekomendasi SLF
dan disahkan oleh kepala dinas. Pengawas bangunan membuat rekomendasi SLF
untuk pemerintah kota. SLF dibuat setelah bangunan sudah selesai dibangun.
4.3.5.3 Arsitektur Aplikasi SPK Lelang
Gambar 4.32 Arsitektur Aplikasi SPK Lelang
Arsitektur bisnis SPK Lelang memiliki 7 aktor dan 10 use case yang dapat
dilakukan dalam sistem SPK lelang. Aktor yang terlibat yaitu, admin, bagian
Pemerintah Kota
Input Hasil Musrembang Bagian Keuangan
Input DPA
Bidang Teknik
Input Design Proyek
Kontraktor
Input Proposal Proyek
Sekretariat
Memilih Kontraktor
Kepala Dinas
Pengesahan Proyek
View Laporan Proyek
Log in
Log Out
<<include>>
Admin
Manajemen User
162
keuangan, pemerintah kota, kontraktor, bidang teknik, kepala dinas dan
sekretariat.
Use case yang terlibat dalam SPK lelang yaitu, login,logout, manajemen
user, input hasil musrembang, input DPA, input design proyek, input proposal
proyek, memilih kontraktor, pengesahan proyek, dan view laporan proyek.
Untuk melaksanakan pembangunan dan perbaikan didaerah Tangerang
Selatan maka pemerintah kota harus menginput hasil musrembang yang sudah
didapatkan dari rapat warga untuk pembangunan non pemerintahan dan rapat oleh
pemerintah untuk pembangunan pemerintahan. Hasil musrembang tersebut berisi
tentang perbaikan dan pembangunan sarana dan prasarana didaerah kota
Tangerang Selatan. Bagian keuangan menginput dana yang sudah disesuaikan
untuk pembangunan didaerah TangSel. Kemudian bidang teknik menginput hasil
design project pembangunan. Setelah design telah diinput, maka beberapa
kontraktor mulai menginput proposal project yang nantinya proposal tersebut
dijadikan bahan pertimbangan oleh pihak dinas. Apabila proyek pembangunan
memerlukan dana dibawah 200 juta, maka pihak DTKBDP sudah mempunyai
kontraktor sendiri. Akan tetapi apabila dana yang diperlukan lebih dari 200 juta
maka pihak DTKBDP mencari kontraktor yang bersedia membangun proyek
tersebut sampai selesai. Kontraktor akan dipilih oleh sekretariat, apabila
kontraktor tersebut dirasa sudah memenuhi persyaratan, dan sudah melakukan
perjanjian kontrak maka kepala dinas akan melakukan pengesahan dan kemudian
melihat laporan.
163
4.3.5.4 Arsitektur Aplikasi Progress Bangunan
Gambar 4.33 Arsitektur Aplikasi Progress Bangunan
Arsitektur bisnis progress bangunan memiliki 3 aktor dan 6 use case yang
dapat dilakukan dalam sistem progress bangunan. Aktor yang terlibat yaitu
admin, pengawas bangunan dan kepala dinas.
Use case yang terlibat dalm sistem progress bangunan yaitu login, logout,
manajemen user, manage data bangunan¸input progress bangunan dan view
laporan progress bangunan.
Aktivitas dan fungsi bisnis pada progress bangunan adalah untuk
mengetahui progress setiap bangunan yang sedang dibangun. Tujuannya adalah
untuk mengetahui bagaimana proses detail setiap bangunan yang dibangun.
Pengawas bangunan mempunyai tugas untuk mengelola data bangunan dan
menginputnya, dan kepala dinas melihat laporan progress bangunan.
Pengawas Bangunan
Manage Data Bangunan
Input Progress Bangunan
Kepala Dinas
View Laporan Progress Bangunan
Log in
Manajemen User
Admin
Log Out
<<extend>>
164
4.3.5.5 Arsitektur Aplikasi E-inventaris
Gambar 4.34 Arsitektur Aplikasi E-Inventaris
Arsitektur bisnis E-inventaris memiliki 6 aktor dan 6 use case yang dapat
dilakukan dalam sistem E-inventaris. Aktor yang terlibat yaitu admin, bagian
keuangan, bidang bangunan, bidang teknik suubag rumah tangga dan kepala
dinas.
Use case yang terlibat dalam sistem E-inventaris yaitu, login, logout,
manajemen user , input data inventaris, manage data inventaris dan view laporan
inventaris.
Aktivitas bisnis dan fungsi bisnis pada E-Inventaris adalah untuk
mengelola data penggunaan Barang Milik Negara (BMN) yang dikelola oleh
bagian Subbag rumah tangga dan diinput kedalam sistem e-inventaris agar data
Subbag. Rumah Tangga
Bidang Teknik
Bagian Keuangan
Bidang Bangunan
Manage Data Inventaris
View Laporan Inventaris
Kepala Dinas
Log in
Manajemen User
Admin
Input Data Inventaris
Log Out
<<extend>>
165
penggunaan Barang Milik Negara (BMN) tersebut akan selalu terupdate pada
setiap periode semsesteran atau pertahun. Kemudian, sistem E-inventaris akan
menghasilkan laporan inventaris per periode yang sudah ditentukan. Subbag
rumah tangga dapat melihat laporan inventaris tersebut untuk keperluan
pemerikasaan Barang Milik Negara (BMN) yang digunakan oleh DTKBDP secara
berkala. Bagian keuangan juga dapat melihat laporan inventaris untuk keperluan
pembuatan laporan keuangan.
4.3.5.6 Arsitektur Aplikasi E-keuangan
Gambar 4.35 Arsitektur Aplikasi E-Keuangan
Arsitektur bisnis E-keuangan memiliki 3 aktor dan 6 use case yang dapat
dilakukan dalam sistem E-keuangan. Aktor yang terlibat yaitu admin, bagian
keuangan dan kepala dinas.
Bagian Keuangan
pencatatan akuntansi
Manage periode pelaporan
Kepala DinasView Laporan Keuangan
Log in
Manajemen User
Admin
Log Out
<<extend>>
166
Use case yang terlibat dalam sistem E-keuangan yaitu login, logout,
manajemen user, pencatatan akuntansi, manage periode pelaporan dan view
laporan keuangan.
Aktivitas bisnis dan fungsi bisnis pada bisnis E-keuangan adalah untuk
mengetahui laporan keuangan di DTKBDP. Subbag tata usaha akan melakukan
pengelolaan keuangan untuk memenuhi kebutuhan DTKBDP. Staff tersebut juga
akan melakukan pencatatan akuntansi keuangan, serta mengatur periode
pembuatan laporan keuangan di dalam sistem keuangan. Sistem keuangan akan
menghasilkan output berupa laporan keuangan. Laporan keuangan tersebut dapat
dilihat oleh kepala dinas DTKBDP.
4.5.2 Data Architecture
Pada tahapan ini akan dilakukan perancangan data architecture yang
bertujuan untuk mendefinisikan kebutuhan data yang berupa entitas-entitas yang
akan digunakan pada application architecture tetapi tidak berhubungan dengan
rancangan database. Rancangan data architecture akan menggunakan tools data
dessemination diaram dan class diagram.
167
4.5.2.1 Data Dissemination Diagram
Gambar 4.36 Data Dessemination Diagram
Pada gambar 4.36 menggambarkan hubungan layanan Dinas Tata Kota,
Bangunan dan Permukiman Kota Tangerang Selatan, aplikasi, dan data. Di
aplikasi IMB dan SLF terdapat data level, data user, data pegawai, data customer,
data tanah, data SLF, data IMB dan data bangunan. Aplikasi SPK Lelang terdapat
data level, data user, data pegawai, data kontraktor, data material, data DPA, data
design proyek dan data lelang. Aplikasi progress bangunan terdapat data level,
data user, data pegawai, data proyek, data pengawas, data progress, dan data
Pelayanan IMB
dan SLF
Pembangunan
168
kontraktor. Aplikasi E-inventaris terdapat data user, data level, data pegawai dara
registrasi_BMN, data peralatan, data kendaraan, data tanah, data bangunan dan
data aset_tak_berwujud. Aplikasi E-keuangan terdapat data level, data pegawai,
data periode, data klasifikasi_pengeluaran, data user, data pengeluaran dan data
general_ledger.
4.5.2.2 Class Diagram
Class Diagram digunakan untuk menggambarkan model konseptual data
yang berupa entitas, atribut, dan relasi. Class diagram juga berguna untuk
menunjukkan hubungan antar kelas dalam suatu sistem yang bertujuan untuk
mendefinisikan kebutuhan data yang berupa entitas-entitas yang akan digunakan
pada application architecture tetapi tidak berhubungan dengan rancangan
database. Class diagram digunakan sebagai tools dalam pendefinisian entitas ini.
169
1. Rekomendasi Permohonan IMB dan SLF
Gambar 4.37 Arsitektur Data Aplikasi IMB dan SLF
Arsitektur data IMB dan SLF memiliki 8 kelas, yaitu Level, user ,
Pegawai, Customer, Tanah, Bangunan, SLF, dan IMB.
Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu sampai
banyak) terhadap kelas tanah dan bangunan. Kelas bangunan memilik multiplicity
11 (satu ke satu) terhadap kelas tanah. Kelas IMB dan SLF memiliki
multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas pegawai.
Kelas user memiliki multiciply 11 (satu ke satu) terhadap pegawai dan kelas
Level
+id_level+nama_Level
+tambah()+hapus()
Customer
+Id_Customer+Nama_Customer+TTL+Telp+Alamat+KTP+Akta
+Tambah()+Hapus()+Ubah()
Bangunan
+Id_Bangunan+Nama_Bangunan+Fungsi_Bangunan+Jenis_Bangunan+Luas_Bangunan+Lokasi_Bangunan
+Tambah()+Hapus()+Ubah()
Tanah
+Id_Tanah+Status_Tanah+Status_Penggunaan+Pemilik_Tanah+Batas_Tanah
+Tambah()+Hapus()+Ubah()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
*1
1..*
1
1..*
1
1..*1
1
1
IMB
+No_IMB+Tanggal_IMB+Id_Customer+Id_Tanah+Id_Bangunan+Masa_Berlaku_IMB+Pengesahan
+Tambah()+Hapus()+Ubah()+Print()
SLF
+No_SLF+Tanggal_SLF+Id_Customer+Id_Tanah+Id_Bangunan+Masa_Berlaku_SLF+Pengesahan
+Tambah()+Hapus()+Ubah()+Print()
1..*1
1..* 1
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
1
1
1
1..*
170
user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak)
terhadap kelas customer.
2. Sistem Penunjang Keputusan Lelang
Gambar 4.38 Arsitektur Data Aplikasi SPK Lelang
Arsitektur data SPK Lelang memiliki 7 kelas, yaitu, Level, user, Lelang,
Design_Proyek, Pegawai, Kontraktor dan Material.
Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
pegawai. Kelas user lelang memiliki multiplicity 1 1 (satu ke satu) terhadap
kelas pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu
sampai banyak) terhadap kelas lelang. Kelas lelang memiliki multiplicity 1 1
(satu ke satu) terhadap kelas design proyek. Kelas lelang memiliki mulplicity 1
DPA
+id_DPA+nama anggaran+budget
+Tambah()+Hapus()+Edit()
Level
+id_level+nama_Level
+tambah()+hapus()
Design_Proyek
+Id_Proyek+Nama_Design+Jenis_Design
+Tambah()+Hapus()+Ubah()
Lelang
+Id_Lelang+Nama_Proyek+Jenis_Proyek+Nomer_Lelang+Total_Biaya
+Operation1()
1 1
Material
+Id_Material+Jenis_Material+Satuan_Material+Jumlah_Material+Harga_Material
+Tambah()+Hapus()+Ubah()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
*1
1..*
1
*1
kontraktor
+Id_Kontraktor+Nama_Kontraktor+TTL+Alamat+Telp
+Tambah()+Hapus()+Ubah()
1..*
1
1 1..*
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
1
1
171
1..* (satu ke antara satu sampai banyak) terhadap kelas kontraktor dan kelas
kontraktor generalisasi dengan kelas material.
3. Progress Bangunan
Gambar 4.39 Arsitektur Data Progress Aplikasi Bangunan
Arsitektur data Progress Bangunan memiliki 7 kelas, yaitu, Level,
Pegawai, Proyek, User, Progress, Kontraktor, dan Pengawas.
Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
pegawai. Kelas pegawai memiliki multiplicity 1 1 (satu ke satu) terhadap kelas
user. Kelas user memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
pengawas. Kelas user memiliki multiplicity 1 * (satu ke banyak) terhadap kelas
progress. Kelas progress memilik multiplicity 11 (satu ke satu) terhadap kelas
kontraktor
+Id_Kontraktor+Nama_Kontraktor+TTL+Alamat+Telp
+Tambah()+Hapus()+Ubah()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
Level
+id_level+nama_Level
+tambah()+hapus()
Proyek
+Id_Proyek+Nama_Proyek+Nilai+Alamat+Status+Tanggal_Mulai+Tanggal_Selesai
+Tambah()+Hapus()+Ubah()
Progress
+Id_Progress+Rencana_Progress+Realisasi_Progress
+Tambah()+Hapus()+Ubah()
Pengawas
+Id_Pengawas+Nama_Pengawas+Alamat+Telp+Email
+Tambah()+Hapus()+Ubah()
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
*
1
1
1
1
1 1
1..*
*
1
*
1
172
proyek. Kelas proyek memiliki multiplicity 1 1..* (satu ke antara satu sampai
banyak) terhadap kelas kontraktor.
4. E-Inventaris
Gambar 4.40 Arsitektur Data Aplikasi E-inventaris
Arsitektur data E-Inventaris memiliki 9 kelas, yaitu, Level, user, Pegawai,
Registrasi_BMN, Peralatan, Kendaraan, Tanah, Bangunan, Aset_Tak_Berwujud.
Kelas level memiliki multiplicity 1* (satu ke banyak) terhadap kelas
pegawai. Kelas user memiliki multiplicity 1 1 (satu ke satu) terhadap kelas
pegawai dan memiliki multiplicity 11..* (satu ke antara satu sampai banyak)
terhadap kelas registrasi_BMN. Kelas pegawai memiliki multiplicity 11..* (satu
Level
+id_level+nama_Level
+tambah()+hapus()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
*1 *1
Registrasi_BMN
+no_Registrasi+golongan+bidang+kelompok+id_kendaraan+id_peralatan+id_tanah+id_bangunan
+Tambah()+Hapus()+Ubah()
Peralatan
+id_peralatan+nama_peralatan+merk+tipe+harga_peralatan+harga_perolehan+jumlah+kondisi
+Tambah()+Hapus()+Ubah()
Kendaraan
+id_kendaraan+merk+tipe+warna+mesin+thn_buat+thn_beli+no_polisi+tgl_bpkb+jumlah+kondisi
+Tambah()+Hapus()+Ubah()
Tanah
+Id_Tanah+Status_Tanah+Status_Penggunaan+Pemilik_Tanah+Batas_Tanah
+Tambah()+Hapus()+Ubah()
Bangunan
+Id_Bangunan+Nama_Bangunan+Fungsi_Bangunan+Jenis_Bangunan+Luas_Bangunan+Lokasi_Bangunan
+Tambah()+Hapus()+Ubah()
Aset_Tak_Berwujud
+id_ATB+nama_ATB+merk+jumlah
+Tambah()+Hapus()+Ubah()
1..*1
1 1
1
1
1
1
1
1
1
1
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
1
11..*
1
173
ke antara satu sampai banyak) terhadap kelas registrasi_BMN. Kelas peralatan,
kendaraan, tanah, bangunan dan aset_tak_berwujud memiliki multiplicity 1 1
(satu ke satu) terhadap kelas registrasi_BMN.
5. E-Keuangan
Gambar 4.41 Arsitektur Data Aplikasi E-Keuangan
Arsitektur data E-Keuangan memiliki 7 kelas, yaitu, Level, user, Pegawai,
Periode, Klasifikasi_Pengeluaran, Pengeluaran,General_Ledger.
Kelas level memiliki multiplicity 1* (satu ke banyak) terhadap kelas
pegawai. Kelas user memiliki multiplicity 1 1 (satu ke satu) terhadap kelas
pegawai dan multiplicity 1* (satu ke banyak) terhadap kelas periode dan juga
kelas user memiliki multiplicity 1 1 (satu ke satu) terhadap kelas
general_ledger. Kelas pegawai memiliki multiplicity 1* (satu ke banyak)
Level
+id_level+nama_Level
+tambah()+hapus()
Pegawai
+NIP+Nama_Pegawai+TTL+Alamat+Telp+Id_Level+Id_Jabatan+Kode_Bangunan+Kode_Subbagian
+Tambah()+Hapus()+Ubah()
*1
Periode
+id_periode+klasifikasi_periode+tgl_awal_periode+tgl_akhir_periode
+Tambah()+Hapus()+Ubah()
General_Ledger
+id_jurnal+id_periode+id_pengeluaran+jumlah_pendapatan+jumlah_pengeluaran+keterangan
+Tambah()+Hapus()+Ubah()
Pengeluaran
+id_pengeluaran+nominal_pengeluaran+tanggal+id_klasifikasi_pengeluaran
+Tambah()+Hapus()+Ubah()
Klasifikasi_Pengeluaran
+id_klasifikasi_pengeluaran+klasifikasi_pengeluaran
+Tambah()+Hapus()+Ubah()
*1
1
1..*
1 *
1
1..*
User
+Nip+Username+Password
+Tambah()+Hapus()+Ubah()
1
1
11
*
1
174
terhadap kelas periode. Kelas periode memiliki multiplicity 1..*1 (antara satu
sampai banyak ke satu) terhadap kelas general_ledger. Kelas pengeluaran
memiliki multiplicity 1..*1 1 (antara satu sampai banyak ke satu) terhadap kelas
general ledger. Kelas klasifikasi_pengeluaran memiliki multiplicity 1* (satu ke
banyak) terhadap kelas pengeluaran.
4.6 Phase D: Technology Architecture
Arsitektur teknologi menggambarkan dan menjelaskan infrastruktur
jaringan serta hardware dan software yang terlibat didalam jaringan tersebut
untuk mendukung pelayanan, arus data dan informasi, serta jalannya aplikasi yang
menunjang kegiatan di DTKBDP. Dalam arsitektur teknologi akan dijelaskan
infrastruktur jaringan awal dan usulan untuk DTKBDP, platform teknologi yang
digunakan dalam infrastruktur jaringan, serta konfigurasi hardware dan software
yang diperlukan dalam infrastruktur jaringan.
4.6.1 Infrastruktur Jaringan
a. Jaringan Awal
Pada gambar 4.21 merupakan arsitektur jaringan saat ini di DTKBDP
yang hanya mengandalkan router agar terhubung dengan internet. Router
tersebut berfungsi sebagai gateway untuk akses internet di DTKBDP saat
ini. Router menghubungkan internet ke lantai 3 melalui 1 switch,
175
sedangkan untuk menghubungkan internet ke lantai ke lantai lain hanya
melalui wireless.
Switch yang digunakan dilantai 3 di ruang bidang bangunan yang
menghubungkan dengan ruang seksi pembangunan pemerintahan, ruang
seksi pembangunan non pemerintahan dan ruang seksi pemeliharaan
gedung. Terdapat wireless disetiap gedung 1 dan 2 yang tersebar disetiap
ruangan.
176
Internet Service
Provider
Ruang kepala Bidang
Tata Kota
Ruang Perencanaan
Tata Ruang
Ruang seksi
pemetaan
Ruang seksi
pengendalian dan
pemanfaatan ruang
Lantai 1 Bidang Tata Kota
Ruang Penataan
Kawasan
Ruang Seksi
Perumahan
Ruang Seksi
Penyehatan
Lingkungan
Ruang Bid.
Perumahan dan
Permukiman
Lantai 2 Bidang Perumahan dan
Permukiman
Ruang Seksi
Pembangunan Non
Pemerintahan
Ruang Seksi
Pembangunan
Pemerintahan
Ruang
SeksiPemeliharaan
Gedung
Ruang Bidang
Bangunan
Lantai 3 Bidang Bangunan
Ruang Seksi
Pengawasan
Ruang Seksi
Perencanaan
Ruang Data Informasi
dan Pengujian
Ruang Bidang Teknik
Lantai 2 Bidang Teknik
Ruang Kasubag PEP
Ruang Kasubag
Keuangan
Ruang Subbag
Rumah Tangga
Ruang Kasi Umum
Lantai 3 Sekretariat
Ruang ResepsionisRuang Tunggu
Lantai 1 Lobby
Firewall
Router
Gambar 4.42 Arsitektur Jaringan Awal Keseluruhan DTKBDP
177
Local Server
DTKBDP
IDC (Internet Data Center)
Web Server DTKBDP
Internet Service
Provider
Ruang kepala Bidang
Tata Kota
Ruang Perencanaan
Tata Ruang
Ruang seksi
pemetaan
Ruang seksi
pengendalian dan
pemanfaatan ruang
Lantai 1 Bidang Tata Kota
Ruang Penataan
Kawasan
Ruang Seksi
Perumahan
Ruang Seksi
Penyehatan
Lingkungan
Ruang Bid.
Perumahan dan
Permukiman
Lantai 2 Bidang Perumahan dan
Permukiman
Ruang Seksi
Pembangunan Non
Pemerintahan
Ruang Seksi
Pembangunan
Pemerintahan
Ruang
SeksiPemeliharaan
Gedung
Ruang Bidang
Bangunan
Lantai 3 Bidang Bangunan
Ruang Seksi
Pengawasan
Ruang Seksi
Perencanaan
Ruang Data Informasi
dan Pengujian
Ruang Bidang Teknik
Lantai 2 Bidang Teknik
Ruang Kasubag PEP
Ruang Kasubag
Keuangan
Ruang Subbag
Rumah Tangga
Ruang Kasi Umum
Lantai 3 Sekretariat
Ruang ResepsionisRuang Tunggu
Lantai 1 Lobby
Printer Scanner
Server
Router
Gambar 4.43 Arsitektur Jaringan Usulan Keseluruhan DTKBDP
Jaringan usulan menggunakan 2 sambungan yaitu, wireless dan LAN yang
terhubung ke tiap gedung dan ruangan. Terdapat IDC (Internet Data Center)
sebagai alat penyimpanan data di DTKBDP. Terdapat juga server aplikasi untuk
menyimpan data-data aplikasi.
178
4.6.2 Platform Teknologi
Dari Platform teknologi gambar 4.21, dapat dilihat keseluruhan sistem
sudah berbasis web. Pada level client interface, user dapat mengakses sistem
melalui web browser. Pengguna dapat mengakses portal perusahaan melalui
jaringan internet. Sedangkan pengguna dari internal organisasi dapat mengakses
keseluruhan sistem melalui internet maupun jaringan lokal. Keamanan jaringan
menggunakan firewall untuk mengakses server aplikasi.
Platform teknologi meliputi client interface, network, network security,
presentation, application, dan database. Berikut usulan platform teknologi:
Gambar 4.44 Platform Teknologi
179
Pada gambar diatas, dapat dilihat pemanfaatan teknologi sesuai dengan
layer tempat teknologi tersebut berada. Berikut penjelasan pembagian layer
teknologi :
1. Layer client interface, pengguna dapat mengakses sistem melalui web
browser sebagai interface antara pengguna dan sistem.
2. Layer network, menghubungkan antara lingkungan sistem dengan
lingkungan pengguna. Pemohon dapat mengakses pendaftaran melalui
jaringan internet dan pengguna dari internal dapat mengakses Sistem
Informasi DTKBDP melalui jaringan lokal.
3. Layer Network Security, keamanan jaringan menggunakan firewall
untuk mengakses server aplikasi.
4. Layer presentation, bagian aplikasi yang menampilkan content
aplikasi untuk memudahkan interaksi dengan pengguna sistem.
Apache web server digunakan dalam layer ini.
5. Layer application, merupakan tempat dilakukannya pemrosesan
aplikasi bisnis. Hypertext Prepocessor (PHP) digunakan untuk
memproses data menjadi informasi yang dibutuhkan pengguna.
6. Layer database, merupakan layer tempat disimpannya data hasil
pemrosesan informasi.
180
4.6.3 Konfigurasi Hardware dan Software
Pada tahapan ini akan diusulkan konfigurasi hardware dan software
untuk mendukung arsitektur teknologi yang diusulkan. Berikut usulan konfigurasi
hardware:
Tabel 4.12 Konfigurasi Hardware
Hardware Spesifikasi
Server IBM System
Processor Intel Xeon 5500 series
Memory 192 GB
Storage 1 Terra Byte
Graphic Card SVGA 8Mb
Input Device mouse , keyboard
Ouput Device monitor LCD
Jumlah server yang diusulkan berjumlah 10 server utama yang terdiri dari
:
1. Web server terdiri dari 1 server dan 1 back up server ( jumlah total
2 server).
181
2. Email server terdiri dari 1 server dan 1 back up server ( jumlah
total 2 server).
3. Database server terdiri dari 1 server dan 1 back up server ( jumlah
total 2 server).
4. Proxy server terdiri dari 1 server dan 1 back up server ( jumlah
total 2 server).
5. FTP server terdiri dari 1 server dan 1 back up server ( jumlah total
2 server).
Tabel 4.13 Konfigurasi Software
Software Spesifikasi
Operating System Windows Server 2008
Web Server Apache
Web Browser Google Chrome, Mozilla Firefox
DBMS MySQL
Coding PHP
Word Processing Microsoft Word 2013
Speadsheet Microsoft Excel 2013
182
Presentation Microsoft Power Point 2013
4.6.4 Technology Portfolio Catalog
Pada tahapan ini berisi catalog untuk mengidentifikasi daftar infrastruktur
hardware, software, aplikasi software, dan jaringan.
Tabel 4.14 Technology Portfolio Catalog
Domain Portal DTKBD Sistem Informasi DTKBDP
Client interface Web Browser Web Browser
Presentation Apache Web server Apache Web Server
DBMS MySQL MySQL
Web Platform Windows Server Windows Server
Application
Platform
Windows Server Windows Server
Database Platform Windows Server Windows Server
Local Area Network Gigabit Ethernet
Wide Area Network Internet
Infrastruktur TCP/IP
183
Jaringan Gigabit Ethernet, LAN, Wireless LAN
Access Point
4.7 Phase E: Opportunities and Solution
Pada pembahasan sebelumnya telah dilakukan pengelompokan
berdasarkan arsitektur bisnis, sistem informasi, dan teknologi. Selanjutnya pada
subbab ini dilakukan analisis terhadap peluang dan solusi dengan menggunakan
analisis gap terhadap komponen-komponen arsitektur bisnis, sistem informasi dan
teknologi.
4.7.1 Analisis Gap
Analisis gap berguna menjelaskan komponen-komponen apa saja yang
harus dipertahankan (retain) atau dihilangkan (remove) dari sistem yang sedang
berjalan di DTKBDP dan untuk menjelaskan komponen-komponen apa saja yang
harus diganti (replace) atau ditambahkan (add) dengan komponen baru dari
arsitektur usulan. Analisis gap dibuat dalam bentuk matriks, dengan ketentuan
sebagai berikut ini:
1. Komponen sistem yang sedang berjalan (existing) ditempatkan pada
kolom pertama paling kiri dan matriks. Komponen arsitektur usulan
(future) ditempatkan pada baris pertama paling atas dari matriks.
184
2. Tambahkan keterangan “new” (komponen baru) pada baris pa;ing
terakhir dan ditempatkan pada kolom komponen sistem yang sedang
berjalan (existing). Tambahkan keterangan “eliminated” (komponen
yang akan dihapus) pada kolom paling kanan dan ditempatkan pada
baris komponen arsitektur usulan (future).
3. Jika komponen sistem yang sedang berjalan (existing) masih ada
dalam komponen arsitektur usulan (future), maka tandai sel yang
saling berpotongan tersebut dengan keterangan “retain” (komponen
lama masih dipertahankan dan digunakan). Jika komponen sistem
yang sedang berjalan (existing) mengalami pengembangan versi pada
komponen arsitektur usulan (future) maka tandai sel yang saling
berpotongan dengan keterangan “replace” (komponen yang lama
dikembangkan sehingga mempunyai versi baru).
4. Jika komponen sistem yang sedang berjalan (existing) tidak digunakan
lagi pada komponen arsitektur usulan (future), maka tandai dengan
keterangan “remove” pada kolom “eliminated”. Jika komponen
arsitektur usulan (future) tidak terdapat dalam komponen sistem yang
sedang berjalan (existing),maka tandai dengan keterangan “add” pada
baris “new”. Semua komponen yang diberi ketrangn “add” merupakan
gap yang harus dipenuhi.
185
a. Analis Gap Rekomendasi IMB dan SLF
186
Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF
187
b. Analisis Gap SPK Lelang
FUTURE
EXISTING Input
musr
emban
g
onli
ne
Input
DP
A
ked
alam
isi
stem
Input
daf
tar
pro
yek
ked
alam
sis
tem
Input
des
ign
pro
yek
ked
alam
sist
em
Pem
ilih
an
spes
ifik
asi
kontr
akto
r m
elal
ui
sist
em
Pem
ban
gunan
ole
h
kontr
akto
r te
rpil
ih
EL
IMIN
AT
ED
Penyerahan
hasil
musrembang
sistem manual
Replace
Penyerahan
DPA sistem
manual
Replace
Penyerahan
daftar proyek
pembangunan
sistem manual
Replace
Penyerahan
hasil design
proyek
pembangunan
sistem manual
Replace
Pelaksanaan
proses lelang Replace
Pembangunan
oleh
kontraktor
terpilih
Reta
in
NEW
Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang
188
c. Analisis Gap Progress Bangunan
FUTURE
EXISTING Man
age
dat
a
pem
ban
gunan
ked
alam
sis
tem
Input
pro
gre
ss
lapora
n b
angun
an
ked
alam
sis
tem
Vie
w l
apora
n d
ata
ban
gunan
mel
alui
sist
em
EL
IMIN
AT
ED
Penyerahan data
progress bangunan
sistem manual
Replace
Penyerahan laporan
data bangunan
sistem manual
Replace
View laporan data
bangunan sistem
manual
Replace
NEW
Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan
d. Analisis Gap Keuangan
FUTURE
EXISTING Pen
yusu
nan
ren
cana
pro
gra
m &
anggar
an
Pen
arik
an d
ana
Pen
gel
ola
an d
ata
Pen
canta
tan a
kunta
nsi
keu
angan
pad
a si
stem
kom
pute
r
Pem
buat
an l
apora
n
keu
angan
pad
a si
stem
kom
pute
r
EL
IMIN
AT
ED
Penyusunan
anggaran program &
anggaran
Retain
Penarikan dana Retain
189
Pengelolaan dana Retain
Pencatatan akuntansi
secara manual Replace
Pembuatan laporan
keuangan sistem
manual
Replace
NEW
Tabel 4.18 Analisis Gap Arsitektur Bisnis E-Keuangan
e. Analisis Gap E-Inventaris
FUTURE
EXISTING Pen
cata
tan i
nven
tari
s
pad
a si
stem
kom
pute
r
Pen
yusu
nan
lap
ora
n
pen
gguna
BM
N p
ada
sist
em k
om
pute
r
Pen
yusu
nan
lap
ora
n
pen
gel
ola
inven
tari
s p
ada
sist
em k
om
pute
r
Pen
yer
ahan
lap
ora
n
pen
gguna
&&
pen
gel
ola
pad
a si
stem
kom
pute
r
EL
IMIN
AT
ED
Pencatatan inventaris
BMN sistem manual
Replace
Penyusunan laporan
penggunan BMN sistem
manual
Replace
Pengumpulan laporan
sistem manual
X
Penyusunan laporan
pengelola inventaris
sistem manual
Replace
Penyerahan laporan
pengguna & pengelola
sistem manual
Replace
NEW
Tabel 4.19 Analisis Gap Arsitektur Bisnis E-Inventaris
190
2. Analis Gap Arsitektur Aplikasi
FUTURE
EXISTING
Port
al D
TK
BD
P
Apli
kas
i IM
B &
SL
F
Apli
kas
i S
PK
Lel
ang
Apli
kas
i P
rogre
ss
Ban
gunan
Apli
kas
i K
euan
gan
Apli
kas
i E
-Inven
tari
s
EL
IMIN
AT
ED
Portal DTKBDP Replace
NEW Add Add Add Add Add
Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP
191
3.Analisis Gap Arsitektur Data
: Replace
: New
: Delete
Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP
192
4. Analisis Gap Arsitektur Teknologi
Tabel 4.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP
193
5. Aplikasi Matriks Terhadap Data
FUTURE
EXISTING
Port
al D
TK
BD
P
Apli
kas
i IM
B &
SL
F
Apli
kas
i S
PK
Lel
ang
Apli
kas
i P
rogre
ss B
angunan
Apli
kas
i K
euan
gan
Apli
kas
i In
ven
tari
s
Pegawai C,R,U,D R R
Pemohon C C,R,U,D R
Bangunan C,R,U,D R R
IMB C,R,U,D
SLF C,R,U,D
Tanah C,R,U,D R R
DPA R C,R,U,D
Design Proyek C,R,U,D R
Lelang C,R,U,D
Kontraktor C,R,U,D R
Material C,R,U,D R
Proyek C,R,U,D C,R,U,D R
Progress C,R,U,D
Pengawas C,R,U,D
Periode C,R,U,D
194
Pengeluaran C,R,U,D
Klasifikasi
Pengeluaran C,R,U,D
General Ledger C,R,U,D
Registrasi BMN C,R,U,D
Peralatan C,R,U,D
Aset Tak
Berwujud C,R,U,D
Kendaraan C,R,U,D
Tabel 4.23 Analisis Gap Matriks Aplikasi Terhdap Data
4.8 Phase E: Migration Planning
Tahapan perencanaan migrasi bertujuan untuk merencanakan proses
peralihan teknologi dari sistem lama (existing system) menuju ke sistem baru
(future system). Rencana migrasi yang dimaksud adalah membuat suatu rencana
untuk urutan pengimplementasian aplikasi sistem informasi sesuai prioritas serta
roadmap aplikasinya.
4.8.1 Urutan Implementasi
Untuk menentukan urutan implementasi aplikasi, maka diperlukan
perspektif organisasi dari sisi operasional. Perspective operational dibagi
menjadi dua bagian, yaitu kelompok sistem aplikasi yang orientasi fungsinya
langsung memberikan pelayanan kepada penggunanya (Front Office System) dan
kelompok sistem aplikasi yang orientasi fungsinya lebih banyak ditujukan untuk
195
memberikan bantuan pekerjaan yang bersifat administrasi dan umum (Back Office
System).
a. Front Office System
Sesuai dengan orientasi fungsinya, maka kandidat aplikasi untuk
Front Office System dapat dilihat pada tabel 4.24 berikut :
Nama Aplikasi Fungsionalitas
Portal DTKBDP Pengajuan permohonan
rekomendasi IMB dan SLF,
pencatatan untuk kemudahan
tracking masalh dan FAQ,
memberikan informasi
publik tentang DTKBDP
b. Back Office System
Sesuai dengan orientasi fungsinya, maka kandidat aplikasi
untuk Back Office System dapat dilihat pada Tabel 4.25 berikut :
Nama Aplikasi Fungsionalitas
Aplikasi IMB dan SLF Mengkonfirmasi
permohonan rekomendasi
IMB dan SLF serta
196
pembuatan laporan
pendaftaran rekomendasi
IMB dan SLF
Aplikasi SPK Lelang Pencatatan tentang daftar
tempat didaerah tangsel yang
akan diperbaiki, serta
pencatatan daftar DPA
(Detail Pagu Anggaran) serta
pemilihan kontraktor yang
sesuai
Aplikasi Proress Bangunan Pencatatan laporan proses
bangunan yang sudah berdiri
atau masih dibangun
disekitar tangsel
Aplikasi E-Inventaris Pencatatan laporan
penggunaan BMN (Barang
Milik Negara) yang
digunakan di DTKBDP
Aplikasi E-Keuangan Pencatatan laporan keuangan
di DTKBDP serta mengatur
periode pembuatan laporan
keuangan
197
Berdasarkan perspective diatas, maka urutan implementasi kandidat
aplikasi adalah sebagai berikut :
Tabel 4.26 Urutan Implementasi
No Nama Aplikasi
1 Portal DTKBDP
2 Aplikasi IMB dan SLF
3 Aplikasi SPK Lelang
4 Aplikasi Progress
Bangunan
5 Aplikasi E-Inventaris
6 Aplikasi E-Keuangan
198
4.8.2 Roadmaps
Roadmaps merupakan arahan pengembangan aplikasi yang bersifat
strategis. Urutan implementasi aplikasi dapat dilihat pada gambar berikut :
2015 2016 2017
Gambar 4.45 Roadmap Aplikasi
PORTAL DTKBDP
APLIKASI
IMB & SLF
TAHAP 1
APLIKASI
SPK LEANG
APLIKASI
PROGRESS BANGUNAN
TAHAP 2
APLIKASI
E-INVENTARIS
APLIKASI
E-KEUANGAN
TAHAP 3
199
4.8.2.1 Penjelasan Roadmaps
Metode pengembangan sistem dalam pembuatan aplikasi pada Dinas
Tata Kota, Bangunan dan Pemukiman Kota Tangerang Selatan menggunakan
metode RAD (Rapid Application Development). Pada metode ini, terdapat 3
tahapan yang dilakukan, yaitu requirements planning yaitu analisis sistem
berjalan dan usulan, Desain workshop RAD yaitu tahapan perancangan sistem
dan database, dan implementasi sistem yaitu tahapan pembuatan sistem
diantaranya coding, testing dan revisi.
Berikut ini merupakan tabel-tabel penjadwalan dan rincian dari roadmap
aplikasi portal dan aplikasi IMB dan SLF pada Dinas Tata Kota, Bangunan dan
Pemukiman Kota Tangerang Selatan:
Tabel 4.27 Roadmap Aplikasi Tahun 2015
Pada pembuatan aplikasi yang pertama yaitu pembuatan portal Garda.
Portal DTKBDP bisa digunakan untuk membantu pihak eksternal seperti
200
pemohon untuk membuat rekomendasi permohonan IMB dan SLF, portal juga
bisa digunakan oleh pihak eksternal dinas. Pada tahapan requirement planning,
analisis sistem berjalan mulai dilakukan pada bulan januari di minggu pertama
selama 2 minggu, yang kemudian dilanjutkan dengan analisis sistem usulan mulai
dari minggu ketiga januari sampai dengan minggu pertama februari.
Selanjutnya pada tahapan desain sistem, perancangan sistem dan
perancangan database dilakukan dimulai dari minggu kedua februari sampai
dengan minggu ketiga maret atau dilakukas selama 6 minggu. Dilanjutkan dengan
tahapan selanjutnya yaitu tahapan implementasi, coding dimulai dari minggu
terakhir maret sampai dengan minggu ketiga mei. Setelah coding selesai
dilakukan, dilanjutkan dengan pelaksanaan testing aplikasi selama dua minggu,
dan jika ada perbaikan bisa dilakukan dimulai dari minggu kedua juni sampai
dengan akhir juni 2015.
Pada tabel roadmap aplikasi pada tahun 2016 terdapat perancangan
aplikasi SPK Lelang dan aplikasi Progress Bangunan. Tabel roadmap aplikasi
2016 dapat dilihat dibawah ini:
201
Tabel 4.28 Roadmap Aplikasi Tahun 2016
Pada tabel 4.26 diatas, dijelaskan mengenai perencanaan penjadwalan
roadmap aplikasi SPK Lelang dan aplikasi progress bangunan yang dilakukan
pada tahun 2016. Pada awal tahun, dilakukan pembuatan aplikasi SPK Lelang, hal
ini dilakukan dengan pertimbangan, karena pencatatan bangunan baru atau lama
masih menggunakan ms.office sehingga terkadang data-data terselip atau
menumpuk di file, serta memudahkan untuk mencari kontraktor yang sesuai,
maka dari itu dengan harapan dibuatnya terlebih dahulu aplikasi ini memudahkan
piha DTKBDP untuk mencari data yang diperlukan serta memudahkan untuk
mendapatkan kontraktor yang sesuai. Analisis sistem berjalan dilakukan selama
dua minggu di awal tahun, lalu dilanjutkan dengan analisis sistem usulan selama
tiga minggu. Lalu ditahapan desain sistem, perancangan sistem dan perancangan
database dilakukan selama tujuh minggu dimulai dari minggu kedua februari
sampai dengan minggu keempat maret.
Setelah perancangan tersebut selesai dibuat, dilanjutkan tahap
pembangunan aplikasi selama tujuh minggu untuk tahapan coding, dua minggu
202
untuk pelaksanaan testing sistem, dan tiga minggu untuk pelaksanaan revisi.
Begitu pula pembuatan aplikasi progress bangunan, pembuatan aplikasi progress
bangunan dilakukan setelah pembuatan aplikasi SPK Lelang selesai dibuat.
Dimulai dari awal bulan juli, sampai dengan bulan desember 2016.
Tabel 4.29 Roadmap Aplikasi Tahun 2017
Dan untuk perancangan penjadwalan roadmap aplikasi selanjutnya,
dilakukan untuk perencanaan dua aplikasi yaitu aplikasi E-inventaris dan aplikasi
E-keuangan. Aplikasi E-inventaris dimulai dengan analisis sistem berjalan selama
dua minggu, dilanjutkan dengan analisis sistem usulan selama tiga minggu. Lalu
pada tahapan desain perancangan sistem dan database dilakukan selama sembilan
minggu dimulai di minggu kedua bulan februari sampai dengan minggu kedua
bulan april. Pada tahapan implementasi sistem, coding dilakukan selama tujuh
minggu dimulai akhir bulan april sampai dengan minggu pertama bulan juni.
Pelaksanaan testing di duaminggu setelahnya dan tahapan revisi selama tiga
minggu yaitu sampai dengan akhir bulan juni.
i
203
BAB V
KESIMPULAN DAN SARAN
5.1 Kesimpulan
Berdasarkan hasil pembahasan pada penelitian ini dalam bab sebelumnya, maka
dapat disimpulkan sebagai berikut ini:
1. Berdasarkan hasil observasi dan analisis yang diperoleh dalam penelitian
ini menggambarkan bahwa DTKBDP belum memiliki perencanaan
arsitektur enterprise. Oleh karena itu, penelitian ini membuat suatu
perencanaan arsitektur enterprise menggunakan framework TOGAF 9
agar dapat menyelaraskan strategi aktivitas. Perencanaan arsitektur
enterprise berupa blueprint (cetak biru) dari arsitektur utama pada
TOGAF, yaitu arsitektur bisnis, arsitektur aplikasi, arsitektur data, dan
arsitektur teknologi.
2. DTKBDP belum memanfaatkan SI/TI secara maksimal untuk membantu
aktivitas disana, seperti untuk pegeloaan data. DTKBDP hanya
mengandalkan Microsoft Office untuk membantu aktivitas pengelolaan
data. Oleh karena itu, pada perencanaan arsitetur enterprise akan
dirancang arsitektur bisnis dan arsitektur sistem informasi untuk
memaksimalkan penggunaan SI/TI dengan cara mengomatisasi sistem
disana menggunakan aplikasi yang saling terintegrasi.
203
204
5.2 Saran
Berdasarkan dari hasil penelitian yang sudah diperoleh, maka ada beberapa
saran agar pengembangan penelitian ini di kemudian hari menjadi lebih baik,
yaitu :
1. Pada penelitian selanjutnya, fase-fase TOGAF ARCHITECTURE
DEVELOPMENT METHOD perlu dilanjutkan sampai fase tata kelola
teknologi informasi dan fase manajemen perubahan agar
pengimplementasian arsitektur pada perusahaan menjadi lebih mudah.
2. Setelah menyelesaikan setiap arsitektur, diharapkan penelitian selanjutnya
dapat membuat pengukuran ROI (return of investment) yang berguna
sebagai analisis biaya investasi yang harus dikeluarkan perusahaan untuk
seluruh proses perencanaan strategis sistem informasi ini.
i
DAFTAR PUSTAKA
Aham, Muchtar. 2012 Rancang Bangun Arsitektur Teknologi Informasi Pada
Pelayanan Rumah Makan (Studi Kasus : Rumah Makan Pecel Lele
Lela Cabang ke-33) Menggunakan TOGAF ADM. Fakultas Sains
dan Teknologi UIN Syarif Hidayatullah Jakarta.
Anggana, Ari. 2012 Perancangan Arsitektur Enterprise Berbasis Web dengan
TOGAF ADM di RSUD Dr. Soegiri Lamongan.
Bandung : Informatika
Gondodiyoto, Sanyoto. 2007. Audit Sistem Informasi + Pendekatan Cobit.
Jakarta : Mitra Wacana Media.
Jakarta.
Jogiyanto. 2005. Analisis dan Desain Sistem Informasi : Pendekatan Terstruktur
Teori dan Praktik Aplikasi Bisnis. Yogyakarta : Andi.
Jogiyanto. 2008, Sistem Teknologi Informasi : Edisi III. Yogyakarta: ANDI.
Internal Staff Workshop, 2008. TOGAF For IT Planning. Pusat Ilmu
omputer Universitas Indonesia.
Khairunisa, Anis. 2013 Perancangan Strategis Sistem Informasi Menggunakan
TOGAF ADM pada PT. Dian Nikel Mining. Fakultas Sains dan
Teknologi UIN Syarif Hidayatullah Jakarta.
Moh, Nazir 2009. Metode Penelitian. Bogor : Ghalia Indonesia.
Mulyanto, Agus. 2009. Sistem Informasi Konsep & Aplikasi. Yogyakarta :
Pustaka Pelajar.
Munawar. 2005. Pemodelan Visual dengan UML, Yogyakarta : Graha Ilmu
Pratiwi, Vivi Fydiani. 2013. Perancangan Model Enterprise Architecture dengan
Menggunakan TOGAF Architecture Development Method pada PT.
Satya Karya Utama. Fakultas Sains dan Teknologi UIN Syarif
Hidayatullah Jakarta.
Rizki, Soetam. (2011). Konsep Rekayasa Perangkat Lunak. Prestasi Pustaka:
Ruffaida, Ridda. 2012. Perancangan ArsitekturTeknologi Informasi Rumah Sakit
dengan TOGAF (The Open Group Architecture Framework).
Setiawa, Erwin Budi. 2009. Perancangan Strategis Sistem Informasi IT Telkom
untuk Menuju World Class University. Yogyakarta : Seminar Nasional
Aplikasi Teknologi Informasi 2009 (SNATI 2009).
Surendro, Krisdanto, 2009. Pengembangan Rencana Induk Sistem Informasi,
Syafriza, 2013. Perancangan Architecture Enterprise Menggunakan Kerangka
Kerja Togaf Pada Kantor Pelayanan Umum dan Perizinan Kabupaten
Kota Solok.
The Open Group. 2009. TOGAF : Sample Catalog, Metrices and Diagram. San
Fransisco : The Open Group
The Open Group. 2009. TOGAF Version 9.1. San Fransisco : The Open Group.
Umami, Aenun Jariyatul. 2013. Perencanaan Infrastruktur Teknologi Informasi di
Lembaga Penelitian (Lemlit) UIN Syarif Hidayatullah Jakarta.
Fakultas Teknolgi Informasi Universitas Islam Negri.
Whitten JL,Bentley LD, Dittman KC. (2006). Tim Penerjemah Andi.
Widiatmo, Raymod Lukito. 2012. Perencanaan Strategis Sistem
Informasi/Teknologi Informasi Menggunakan Kerangka The Open
Group Architecture Framework (TOGAF) (Studi Kasus : Pemda
Kabupaten Sumba Barat. Universitas Kristen Satya Wacana Salatiga.
Yogyakaerta:Andi.
i
Transkip wawancara I
Nama : Heri Asari S.Kom, Msi
Jabatan : Staff Bidang IT DTKBDP
Tanggal : 18 Agustus 2014
1. Bagaimana proses bisnis utama pada DTKBDP?
Proses bisnis utama dari DTKBDP adalah melakukan pelayanan
permohonan rekomendasi IMB dan SLF pada setiap bangunan yang
nantinya akan dibangun disekitar TangSel. Pelayanan tersebut ditujukan
untuk pihak eksternal, yaitu hanya pada sampai tahap pembuatan IMB dan
SLF. Namun pihak internal dinas juga memerlukan IMB dan SLF pada
setiap bangunan di TangSel. Selain melakukan pelayanan IMB, DTKBDP
juga melakukan proses pembangunan sarana dan prasarana pemerintahan
atau non pemerintahan didaerah TangSel.
2. Bagaimana alur kerja dari pelayanan IMB dan proses pembangunan
didaerah Tangerang Selatan itu sendiri?
Pemohon yang ingin membuat IMB harus datang ke DTKBDP serta
membawa berkas-berkas yang sudah ditentukan, berkas tersbut akan
disidangkan untuk mengethui kelengkapan berkas tersebut, setelah berkas
diras lengkap, maka pihak DTKBDP akan melakukan survey pada lahan
yang nantinya akan dibangun, dari hasil survey tersebut akan didapatkan
siteplan, apabila siteplan sudah sesuai maka akan dicetak rekomendasi
IMB. SLF akan dicetak setelah bangunan sudah didirikan. Dan untuk
proses pembangunan di daerah Tangsel, pemerintah kota akan melakukan
musrembang pada masyarakat, tujuannya untuk mengetahui bangunan apa
saja yang natinya akan dibangun atau diperbaiki, setelah musrembang
didapat, maka akan keluar DPA dari bapeda, kemudian bidang design akan
membuat gambar dan DTKBDP akan mencari kontraktor yang nantinya
akan membangun bangunan tersebut.
3. Apakah DTKBDP sudah mempunyai aplikasi khusus?
Untuk saat ini, DTKBDP hanya menggunakan Microsoft Exel dan word
untuk melakukan transaksi.
4. Apakah DTKBDP sudah memiliki suatu perencanaan strategis sistem
informasi?
DTKBDP belum memiliki perencanaan SI dan TI.
5. Bagaimana gambaran besar sistem informasi secara keseluruhan?
Kami disini sebagian besar hanya menggunakan Microsoft word maupun
Microsoft exel untuk mengolah data dan informasi. Belum ada sistem
informasi secara keseluruhan.
6. Bagaimana infrastruktur jaringan yang ada di DTKBDP?
Saat ini, agar semua bagian terkoneksi dengan internet maka DTKBDP
mengandalkan router di lantai 1 yang berfungsi sebagai gateway.
Kemudia, router tersebut akan terhubung dengan jaringan LAN dan
terhubung dengan wireless.
7. Aplikasi apa saja yang sudah dimiliki DTKBDP?
Yang khusus dikembangkan oleh DTKBDP sendiri belum ada. DTKBDP
hanya mempunyai website.
8. Bagaimana pengelolaan data pada DTKBDP saat ini?
Untuk pengelolaan data, kami hanya menggunakan aplikasi dasar yang
seperti microsoft word dan icrosoft exel.
9. Bagaimana rencana pengembangan sistem teknologi informasi
kedepannya?
Untuk kedepannya kami menginginkan pelayanan IMB dan SLF bisa
dilakukan secara online, begitu juga pada proses pembangunan agar
memudahkan DTKBD untuk memdapatkan kontraktor yang sesuai dan
juga adanya suatu sistem terintegrasi, sehingga memudahkan dalam
pertukaran data dan informasi.