SKRIPSI. Disusun Oleh: Ines Putri Karunia NIM: PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI

Transkripsi

1 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: PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2015M/1435H i

2 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: PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2015M/1435H i

3 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: 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 ii

4 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 : Menyetujui, Pembimbing I Pembimbing II Elvi Fetrina, MIT NIP Evy Nurmiati, MMSI NIP. Mengetahui, Ketua Program Studi Sistem Informasi Nia Kumaladewi, MMSI NIP iii

5 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 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 NIP Suci Ratnawati, MTI NIP. Pembimbing I Pembimbing II Elvi Fetrina, MIT NIP Evy Nurmiati, MMSI NIP. Mengetahui, Dekan Fakultas Sains dan Teknologi Ketua Prodi Sistem Informasi Dr. Agus Salim, S.Ag, M.Si Nia Kumaladewi, MMSI NIP NIP iv

6 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 v

7 ABSTRAK Ines Putri Karunia ( ), 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 Halaman + 55 Gambar + 40 Tabel + 22 Pustaka + Lampiran Pustaka Acuan (20, ) vi

8 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. vii

9 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 viii

10 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 ix

11 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 Rumusan Masalah Batasan Masalah Tujuan Penelitian Manfaat Penelitian Metode Penelitian Metode Pengumpulan Data Metode Perancangan Sistematika Penulisan x

12 BAB II LANDASAN TEORI 2.1 Pengertian Perancangan Konsep Dasar Sistem Informasi Pengertian Sistem Pengertian Informasi Kualitas Informasi Pengertian Sistem Informasi Konsep Dasar Enterprise Architecture Pengertian Enterprise Pengertian Architecture Pengertian Enterprise Architecture The Open Group Architecture Framework (TOGAF) TOGAF Architecture Development Method (ADM) Preliminary Requirement Management Phase A : Architecture Vision Phase B : Business Architecture Phase C : Information Systems Architecture Phase D : Technology Architecture Phase E : Opportunities and Solution Phase F : Migration Planning Phase G : Implementation Governance Phase H : Architecture Change Management xi

13 2.4.3 Kelebihan dan Kekurangan TOGAF Tools Perancangan Arsitektur Principle Catalog Flowchart Value Chain Stakeholder Map Matrix Archimate Rich Picture Data Dissemination Diagram Unified Modelling Laguage (UML) Sejarah UML Principle Catalog Technology Portofolio Catalog Communication Engineering Diagram Matriks Analisis Gap Metode Pengembangan Sistem rapid Application Development (RAD) Perencanaan Syarat (Requirement Planning) Proses Desain (Design Project) Implementasi (Implementation) Penelitian Sejenis BAB III METODOLOGI PENELITIAN 3.1 Metode Pengumpulan Data Metode Observasi xii

14 3.1.2 Metode Wawancara Metode Studi Pustaka Metode Studi Literatur Metode Perancangan Enterprise Architecture Tahapan TOGAF Alasan Penulis Menggunakan TOGAF Kerangka Berpikir Penelitian BAB IV PERANCANGAN ENTERPRISE ARCHITECTURE 4.1 Preliminary Phase Prinsip-prinsip Perancangan Enterprise Architecture Identifikasi 5W+1H Requirement Management Kondisi Sistem Berjalan Issue Organisasi Solusi Aktivitas Data Inventaris Sarana dan Prasarana Pendukung TIK Phase A : Architecture Vision Profil Instansi Visi dan Misi Instansi Struktur Organisasi dan Tupoksi DTKBDP Analisis Value Chain Struktur Organisasi Usulan Pelatihan yang Diusulkan xiii

15 4.3.7 Hubungan Stakeholder dengan Aktivitas Organisasi Phase B: Business Architecture Pemetaan Layanan Bisnis, Proses Bisnis, dan Fungsi Bisnis di DTKBDP Rancangan Architecture Business Phase C: Information System Application Application Architecture Arsitektur Aplikasi Permohonan Rekomendasi IMB Arsitektur Aplikasi Rekomendasi SLF Arsitektur Aplikasi SPK Lelang Arsitektur Aplikasi Progress Bangunan Arsitektur Aplikasi E-inventaris Arsitektur Aplikasi E-keuangan Data Architecture Data Dissemination Diagram Class Diagram Phase D: Technology Architecture Infrastruktur Jaringan Platform Teknologi Konfigurasi Hardware dan Software Technolgy Portofolio Catalog Phase E: Opportunities and Solution Analisis Gap Phase E: Migration Planning Urutan Implementasi xiv

16 4.8.2 Roadmaps Penjelasan Roadmaps BAB V PENUTUP 5.1 Kesimpulan Saran DAFTAR PUSTAKA LAMPIRAN-LAMPIRAN xv

17 Daftar Gambar Gambar 2.1 ADM Process (The open Group, 2009) Gambar 2.2 Diagram Value chain (Porter, 1985) Gambar 2.3 Contoh Rich Picure Gambar 2.4 Data Dissemination Diagram Gambar 2.5 Contoh Model Use Case Diagram Gambar 2.6 Contoh Model Class Diagram Gambar 2.7 Contoh Communication Engineering Diagram Gambar 2.8 Platform Decomposition Diagram Gambar 2.9 Fase Rapid Application Development (RAD) Gambar 3.1 Kerangka Penelitian Gambar 4.1 Sistem Berjalan Gambar 4.2 Flowchart Sistem Berjalan Level Gambar 4.3 Flowchart Sistem Berjalan Bagian Rekomendasi IMB Gambar 4.4 Flowchart Sistem Berjalan Bagian Rekomendasi SLF Gambar 4.5 Flowchart Sistem Berjalan Bagian Pendataan Hasil Musrembang Gambar 4.6 Flowchart Sistem Berjalan Bagian Design Gambar 4.7 Flowchart Sistem Berjalan Bagian Progress Bangunan Gambar 4.8 Flowchart Sistem Berjalan Bagian Keuangan Gambar 4.9 Flowchart Sistem Berjalan Bagian Inventaris Gambar 4.10 Struktur Organisasi DTKBDP Gambar 4.11 Value Chain Gambar 4.12 Struktur Organisasi Usulan DTKBDP Gambar 4.13 Tree Diagram Pemetaan Layanan, Proses Bisnis dan Fungsi Bisnis DTKBDP Gambar 4.14 Layanan Bisnis di DTKBDP Gambar 4.15 Proses Bisnis Pada Layanan IMB DTKBDP Gambar 4.16 Proses Bisnis Pada Layanan Pembangunan DTKBDP xvi

18 Gambar 4.17 Fungsi Bisnis pada Proses Bisnis Pendaftaran Gambar 4.18 Fungsi Bisnis pada Proses Bisnis Persidangan Gambar 4.19 Fungsi Bisnis pada Proses Bisnis Verifikasi Berkas SLF Gambar 4.20 Fungsi Bisnis pada Proses Bisnis Pendataan Gambar 4.21 Fungsi Bisnis pada Proses Bisnis Design Gambar 4.22 Fungsi Bisnis pada Proses Bisnis Progress Bangunan Gambar 4.23 Solusi Arsitektur Bisnis Gambar 4.24 Solusi Arsitektur Bisnis Rekomendasi IMB&SLF Gambar 4.25 Solusi Arsitektur Bisnis SPK Lelang Gambar 4.26 Solusi Arsitektur Bisnis Solusi Bisnis Progress Bangunan Gambar 4.27 Solusi Arsitektur Bisnis E-inventaris Gambar 4.28 Solusi Arsitektur Bisnis E-keuangan Gambar 4.29 Arsitektur Aplikasi Gambar 4.30 Arsitektur Aplikasi Permohonan Rekomendasi IMB Gambar 4.31 Arsitektur Aplikasi Rekomendasi SLF Gambar 4.32 Arsitektur Aplikasi SPK Lelang Gambar 4.33 Arsitektur Aplikasi Progress Bangunan Gambar 4.34 Arsitektur Aplikasi E-inventaris Gambar 4.35 Arsitektur Aplikasi E-keuangan Gambar 4.36 Data Dissemination Diagram Gambar 4.37 Arsitektur Data Aplikasi IMB dan SLF Gambar 4.38 Arsitektur Data Aplikasi SPK Lelang Gambar 4.39 Arsitektur Data Aplikasi Progress Bangunan Gambar 4.40 Arsitektur Data Aplikasi E-inventaris Gambar 4.41 Arsitektur Data Aplikasi E-keuangan Gambar 4.42 Arsitektur Jaringan Awal Keseluruhan DTKBDP Gambar 4.43 Arsitektur Jaringan Usulan Keseluruhan DTKBDP Gambar 4.44 Platform Teknologi Gambar 4.45 Roadmap Aplikasi xvii

19 DAFTAR TABEL Tabel 2.1 Contoh Principle Catalog Tabel 2.2 Simbol Penghubung Flowchart Tabel 2.3 Simbol Proses Flowchart Tabel 2.4 Simbol Input-Output Tabel 2.5 Contoh Stakeholder Map Matrix Tabel 2.6 Daftar Simbol Use Case Diagram Tabel 2.7 Daftar Simbol Class Diagram Tabel 2.8 Principle Catalog Tabel 2.9 Technology Portofolio Catalog Tabel 3.1 Perbandingan Penelitian Sejenis Tabel 3.2 Daftar Simbol Kerangka Penelitian Tabel 4.1 Principle Catalog Tabel 4.2 5W+1H Tabel 4.3 Permasalahan dalam Aktivitas Organisasi Tabel 4.4 Solusi Aktivitas Tabel 4.5 data Inventaris Sarana dan Prasarana Pendukung TIK Tabel 4.6 Target Value Chain Tabel 4.7 Daftar Pelatihan Usulan Tabel 4.8 Stakeholder Map Matrix Tabel 4.9 Penjelasan Keterlibatan Stakeholder di Setiap Aktivitas Tabel 4.10 Pemetaan Kendala Tabel 411 Application Portofolio xviii

20 Tabel 4.12 Konfigurasi Hardware Tabel 4.13 Konfigurasi Software Tabel 4.14 Technology Portofolio Catalog Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan Tabel 4.18 Analisis Gap Arsitektur Bisnis E-keuangan Tabel 4.19 Analisis Gap Arsitektur Bisnis E-inventaris Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP Tabel 2.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP Tabel 2.23 Analisis Gap Matriks Aplikasi Terhadap Data Tabel 2.24 Front Office System Tabel 4.25 Back Office System Tabel 4.26 Urutan Implementasi Tabel 4.27 Roadmap Aplikasi Tahun Tabel 4.28 Roadmap Aplikasi Tahun Tabel 4.29 Roadmap Aplikasi Tahun xix

21 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 <<extend>> tambahan; biasanya use case tambahan memiliki nama depan yang sama dengan use case yang ditambahkan. xx

22 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) <<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. xxi

23 Simbol Use Case Diagram (Sugiarti, 2013) Simbol Kelas Deskripsi Kelas pada struktur sistem. nama_kelas +Attribute +Operation() 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 xxii

24 kebergantungan antar kelas. Simbol Business Service, Business Process, Business Function (The Open Group, 2009) Simbol Business Service Keterangan 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. Business Function Triggering Flow Elemen tindakan berdasarkan pada sekumpulan kriteria yang dipilih (kriteria yang dibutuhkan sumber daya bisnis). Triggering menjelaskan tentang hubungan sebab-akibat antara proses-proses. Flow menjelaskan tentang pertukaran informasi diantara proses bisnis dan fungsi bisnis. xxiii

25 i

26 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 aspekaspek 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 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 1

27 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

28 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

29 4 organisasi/perusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsipprinsip 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.

30 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).

31 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?

32 7 1.3 Batasan Masalah ini adalah : Berdasarkan dari rumusan masalah di atas, maka batasan dari penelitian 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.

33 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.

34 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 berikut : Diharapkan dengan adanya penelitian ini dapat memberikan manfaat 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.

35 Metodologi Penelitian 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) 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

36 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.

37 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.

38 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

39 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.

40 i

41 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 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 elemenelemen 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

42 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 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.

43 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 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, prosedurprosedur dan pengendalian yang ditujukan untuk mendapatkan jalur komunikasi penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada

44 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 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).

45 19 Menurut definisi diatas, dapat disimpulkan bahwa enterprise adalah suatu kumpulan perusahaan atau organisasi yang mempunyai tujuan bisnis untuk mencapai tujuan perusahaan/organisasi 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 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

46 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 prinsipprinsip 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

47 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.

48 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 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 :

49 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)

50 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

51 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

52 26 penelitian ini, objek penelitian penulis dilakukan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan (DTKBDP) 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.

53 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 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.

54 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

55 29 menjelaskan hubungan antara stakeholder dengan aktivitas dalam organisasi 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.

56 30 sebagai berikut : Fase arsitektur bisnis memiliki input, langkah-langkah, dan output 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).

57 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) 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.

58 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.

59 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.

60 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. sebagai berikut : Fase arsitektur teknologi memiliki input, langkah-langkah, dan output 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.

61 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 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.

62 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. berikut : Fase peluang dan solusi memiliki input, langkah-langkah dan output sebagai 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.

63 37 c. Output 1. Hasil analisis gap gabungan dari fase arsitektur bisnis sampai arsitektur teknologi 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. sebagai berikut: Fase rencana migrasi memiliki input, langkah-langkah dan output a. input 1. Implementation and migration plan, suatu rencana untuk menjadwalkan migrasi data dan implementasi aplikasi.

64 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 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.

65 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 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.

66 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.

67 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:

68 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 Principle Cataloga Bertujuan dari katalog ini adalah untuk menangkap bisnis dan prinsipprinsip 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

69 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 Untuk melindungi dari akses (Perlindungan Data) pihak-pihak yang tidak berwenang. Mengatur stakeholder dalam mengolah data. 5. Arsitektur dirancang agar Memungkinksn respon yang lebih mudah penambahan pengembangan. melakukan dan cepat apabila ada perubahan yang dapat berakibat pada infrastruktur yang bersifat adaptif. Memudahkan kegiatan 6. Penerapan arsitektur multitier dan arsitektur berbasis penggantian komponen yang komponen. rusak availability). (meningkatkan

70 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 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

71 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 (inputoutput 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:

72 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.

73 47 Tabel 2.3 Simbol Proses Flowchart Simbol Proses/penugasan Penjelasan Untuk kegiatan pemrosesan input, pada simbol ini dapat menuliskan operasioperasi 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.

74 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.

75 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) Value Chain Porter (1985), dalam buku karangan Jogiyanto (2005), value chain meliputi kegiatan-kegiatan yang terdiri dari kegiatan-kegiatan atau aktivitasaktivitas, yaitu: 1. Aktivitas utama, yang meliputi penanganan dan penyimpanan bahan mentah yang berupa inbound logistics, operations, outbond logistics, marketing and sales, dan services.

76 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) 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).

77 51 Tabel 2.5 Contoh Stakeholder Map Matrix Stakeholder Aktivitas Tata Ruang Bid. Bangunan Bid. Teknik Subbag. Tata Usaha Pemohon Bag. Keuangan Kepala Dinas Pemerintah Non Pemerintah 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

78 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 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.

79 53 c. Layer teknologi Konsep struktural untuk lapisan teknologi ini adlaah node. Konsep ini digunakan untuk memodelkan entitas struktural dlaam lapisan teknologi 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. 2. Kelola Data Inventaris 1. Input Data Inventaris Subbag. Rumah Tangga Bidang Teknik 3. View Laporan Inventaris 1a. Input Data Inventaris Bagian Keuangan Aplikasi E-inventaris Bidang Bangunan 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.

80 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

81 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 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-

82 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). (sugiarti, 2013): Berikut adalah simbol-simbol yang ada pada diagram use case:

83 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

84 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

85 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. Log in <<include>> Log Out Manajemen User Admin Input Hasil Musrembang Input DPA Bagian Keuangan Input Design Proyek Pemerintah Kota Input Proposal Proyek Memilih Kontraktor Kontraktor Pengesahan Proyek Bidang Teknik View Laporan Proyek Kepala Dinas Sekretariat 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

86 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).

87 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)

88 62 Kebergantungan (Depedency) Relasi antar kelas dengan makna kebergantungan antar kelas. User +Nip +Username +Password Level +id_level +nama_level +tambah() +hapus() SLF +No_SLF +Tanggal_SLF +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_SLF +Pengesahan +Tambah() +Hapus() +Ubah() +Print() 1 1..* 1 * Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah() +Tambah() +Hapus() +Ubah() * 1..* 1..* Customer +Id_Customer +Nama_Customer +TTL +Telp +Alamat +KTP +Akta +Tambah() +Hapus() +Ubah() IMB 1 1 +No_IMB +Tanggal_IMB +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_IMB +Pengesahan +Tambah() +Hapus() +Ubah() +Print() 1..* Tanah +Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah +Tambah() +Hapus() +Ubah() 1..* 1 1 Bangunan +Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah() +Hapus() +Ubah() 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

89 63 banyak) terhadap kelas tanah dan bangunan. Kelas bangunan memilik multiplicity 1 1 (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 1 1 (satu ke satu) terhadap pegawai dan kelas user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak) terhadap kelas customer 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

90 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) 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

91 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 Untuk melindungi dari akses (Perlindungan Data) pihak-pihak yang tidak berwenang. Mengatur stakeholder dalam mengolah data 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).

92 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 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).

93 67 Gambar 2.7 : Contoh Communication Engineering Diagram 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.

94 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.

95 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.

96 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

97 71 pengembangan sistem secara tradisional dan dengan menggunakan Rapid Application Development (RAD). Gambar 2.9 Fase Rapid Application Development (RAD) 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

98 72 akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development 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.

99 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 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.

100 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).

101 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.

102 i

103 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 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

104 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 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

105 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.

106 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 Studi Literatur Tabel 3.1 Perbandingan Penelitian Sejenis Penulis/Tahun Judul Keterangan Kekurangan & Kelebihan Vivi Fidyani Perancangan Menghasilkan Kelebihan Pratiwi Model sebuah prinsip dalam penelitian Enterprise pembuatan arsitektur menghasilkan Architecture perusahaan dan sebuah prinsip dengan Menggunakan menghasilkan blueprint rancangan dalam pembuatan arsitektur TOGAF PT. arsitektur, namun perusahaan, dan Satya Karya perancangan menghasilkan Utama enterprise blueprint

107 80 architecture hanya rancangan sampai pada tahap ke empat saja, yaitu arsitektur Kekurangan tahap technology perancangan architecture. enterpeise architectire hanya sampai dengan taha[ ke empat saja. Anis Perancangan Merancang Kelebihan Khairunnisa Strategis perencanaan penelitian ini Sistem strategis dan menghasilkan Informasi menghasilkan perencanaan menggunakan blueprint dan strategis dan TOGAF pada roadmap. Namun menghasilkan PT. Dian Nikel penempatan hanya blueprint dan Mining dilakukan dalam roadmap. beberapa fase Kekurangan ada arsitektur bisnis, di penempatan sistem informasi dan hanya dilakukan teknologi, belum dalam beberapa dijelaskan dalam fase arsitektur fase TOGAF ADM. bisnism sistem

108 81 informasi teknlogi dan namun belum dijelaskan dalam fase ADM. Muchtar Aham Rancang Merancang dan Kelebihan pada Bangun mengimplementasika penelitian ini Arsitektur n areitektur adalah penelitian Teknologi Informasi pada teknologi informasi menggunakan dilakukan mengenai Pelayanan TOGAF ADM, arsitektur Rumah Makan namun sistem hanya teknologi menggunakan terfokus pada informasi TOGAF ADM. pelayanan dan menggunakan pembayaran saja. TOGAF. Kekurangan sistem terfokus pelayanan hanya pada dan pembayaran saja. Raimond Lukito Perencanaan Meyusun ususlan Kelebihan pada Widiatmo Strategis SI/TI bagi emda penelitian ini Sistem Kabupaten Sumba adalah

109 82 Informasi/Tek nologi Informasi menggunakan kerangka TOGAF (Studi Barat agar tata laksana dan sistem administrasi pemerintahan dapat berjalan lebih efektif dan efisien, namun menghasilkan model enterprise architecture yang dapat digunakan sebagai pandual pengelolaan Kasus: Pemda perancangan EA SI/TI dalam Kabupaten hanya pada sampai jangka waktu 5 Sumba Barat) tahap technology tahun kedepan. architecture saja. Kekurangannya adalah perancangan EA hanya sampai dengan tahap ke empat saja.

110 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: 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).

111 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.

112 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.

113 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 teknologiteknologi 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.

114 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.

115 88 3. Menetapkan roadmap aplikasi perusahaan 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.

116 Kerangka Berpikir Penelitian Adapun kerangka berpikir penelitian yang dilakukan pada penulisan skripsi ini adalah sebagai berikut: Mulai Melakukan Observasi Metode Observasi (Jogiyanto, 2008) Tahap Pengumpulan Data Tahap Perancangan Enterprise Architecture (TOGAF ADM) Melakukan Wawancara Melakukan Studi Literatur Melakukan Studi Pustaka TOGAF 9, The Open Group (2009) Metode Wawancarai (Nazir, 2005) Metode Studi Literaturi (Nazir, 2005) Metode Studi Pustaka (Nazir, 2005) TOGAF 9, Architecture Development Methodology F. Migration Planning A. Architecture Vision E. Opportunities And Solutions REQUIREMENTS B. Business Architecture D. Technology Architecture C. Information Systems Architecture Blue Print Selesai Gambar Kerangka Berpikir

117 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.

118 i

119 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

120 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: 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

121 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.

122 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 Untuk melindungi dari akses (Perlindungan Data) pihak-pihak yang tidak

123 95 berwenang. Mengatur stakeholder dalam mengolah data. 5. Arsitektur dirancang agar Memungkinksn respon yang lebih mudah penambahan pengembangan. melakukan dan cepat apabila ada perubahan yang dapat berakibat pada infrastruktur yang bersifat adaptif. Memudahkan kegiatan 6. Penerapan arsitektur multitier dan arsitektur berbasis penggantian komponen yang komponen. rusak availability). (meningkatkan 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

124 96 yang membutuhkan. Meminimalkan resiko akan kerancuan jika ada pengembangan yang akan dikerjakan 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

125 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 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

126 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 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.

127 99 Bagian Rumah Tangga 27a. Menyerahkan data inventaris 27. Menyerahkan data inventaris 28. Menerima Laporan Inventaris Sie. Pengawasan Bangunan 24.Memberikan data progress pembangunan Sie. Data dan Informasi 31. Pengajuan Rekomendasi SLF Pemkot 25. Meminta laporan progress bangunan 26. Memberikan laporan progress pembangunan Subbag. Tata Usaha 29. pencatatan akuntansi 16. Pengesahan surat rekomendasi SLF Kepala Dinas Pemerikasaan lapangan 15. Proses pemerikasaan bangunan gedung 13. Pemeriksaan berkas administrasi SLF 11. Pengesahan surat rekomendasi IMB 17. Memberikan surat rekomendasi SLF Tim panitia SLF Bag. Keuangan 6. Pemeriksaan berkas administrasi 7. Konfirmasi kelengkapan berkas 10. Menyerahkan rekomendasi IMB pemohon 14. Konfirmasi kelengkapan berkas administrasi SLF 1. Menyerahkan berkas administrasi IMB 2. konfirmasi kelengkapan Berkas administrasi IMB 12. Menyerahkan Surat rekomendasiimb sekretariat 18. Memberikan hasil musrembang 30. Pengajuan IMB Musrembang 19. Menyerahkan DPA Pemerintah Kota 5. Mendapat rekomendasi Site plan 3. Melakukan proses Sidang Menyerahkan daftar proyek TABG Tim survey 8. melakukan proses Sidang 2 9. pemeriksaan berkas administrasi 4. Melaksanakan pemeriksaan lapangan/survey Proses Sidang Bidang Teknik 21. Menyerahkan hasil design Kontraktor 23. Pembangunan 22. Melaksanakan proses lelang Proses Lelang Bidang bangunan Gambar 4.1 Sistem Berjalan

128 100 Pemohon yang ingin membuat sertifikat permohonan IMB dan SLF, datang ke kantor DTKBDP dan mengisi formulir IMB serta menyerahkan berkasberkas 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.

129 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

130 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 Rekomendasi IMB & SLF Pendataan Hasil Musrembang Design Lelang Proyek Pembangunan Keuangan Pengecekkan Progress Bangunan Inventaris 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

131 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.

132 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.

133 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

134 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

135 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.

136 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.

137 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.

138 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 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 :

139 111 Tabel 4.3 Permasalahan dalam Aktivitas Organisasi No Aktivitas Permasalahan Deskripsi 1. Pelayanan Pengelolaan Pencatatan, rekomendasi IMB data penyimpanan dan dan SLF pendaftaran pelaporan data rekomendasi IMB dan SLF rekomendasi IMB dan SLF masih manual, dan terkadang terjadi redudancy data. 2. Musrembang Pelaporan Pelaporan proyek proyek masih menggunakan ms.office, mempunyai dicatat belum 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

140 112 gambar banyak yang hilang karena tidak adanya penyimpanan data yang baik. 4. Progress Bangunan Pelaporan Belum adanya progress proyek fasilitas pengelolaan progress karena untuk data bangunan, pendataan masih menggunakaan proses manual. 5. Keuangan Pencatatan Proses pencatatan Keuangan keuangan bersifat manual masih 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

141 113 perubahan 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 Pencatatan, penyimpanan Perancangan aplikasi rekomendasi IMB dan SLF dan pelaporan data rekomendasi IMB dan SLF masih manual, dan terkadang terjadi redudancy data. IMB dan SLF. 2. Musrembang Pelaporan proyek masih Penyediaan fasilitas dicatat ms.office, menggunakan belum untuk pelaporan data proyek bangunan mempunyai suatu aplikasi khusus dan terkadang data yang saling terintegrasi agar data

142 114 tidak tersimpan dengan baik dan sulit utuk dicari. dapat disimpan dengan baik. 3. Design Pada penggambaran proyek penyimpanan gambar hanya Penyediaan fasilitas untuk pengelolaan menggunakan aplikasi data design agar data seadanya, terkadang gambar banyak yang hilang karena tersimpan dengan baik. tidak adanya penyimpanan data yang baik. 4. Progress Belum adanya fasilitas Penyediaan fasilitas Bangunan untuk pengelolaan data untuk pelaporan progress bangunan, karena progress bangunan pendataan menggunakaan masih proses yang nantinya mudah di akses oleh manual. perbagian organisasi didalam 5. Keuangan Proses pencatatan keuangan masih bersifat manual Kesulitan dalam mebuat laporan keuangan yang Penyediaan fasilitas untuk pencatatan keuangan yang saling terintegrasi. cepat dan akurat 6. Inventaris Pendataan inventaris barang Penyediaan fasilitas

143 115 masih manual Kesulitan dalam pencatatan inventaris jika ada banyak pelaporan data inventaris yang saling terintegrasi. perubahan 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 Printer Operasional Laptop Operasional Mobile Modem Operasional Phase A : Architecture Vision 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 :

144 Visi dan Misi Instansi Visi Instansi Terwujudnya tata ruang, bangunan dan lingkungan pemukiman yang modern, religius dan berkelanjutan pada tahun 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

145 Struktur Organisasi dan Tupoksi DTKBDP KEPALA DINAS Ir. DENDI PRYANDANA, MT (IV/b) NIP SEKRETARIAT Ir. LISHERNI, M.Si (IV/B) NIP KASI UMUM Ir. Hj. DENIWATI, MM (IV/a) NIP KASUBAG KEUANGAN Dra. IIS HASTATI ROCHIMAT (III/c) NIP KASUBAG PEP RIKAS DIRGANTARI, ST, MT (IV/a) NIP SUBBAGIAN TATA USAHA DAN SDM SUBBAGIAN RUMAH TANGGA Bidang Tata Ruang TONNY SOEWANDI, ST (III/d) NIP Bidang Perumahan CARSONO, S.ST, MM (III/d) NIP Bidang Bangunan MUKODDAS SYUHADA, ST, MT (III/d) NIP Bidang Teknik DEDENG DASA, ST (III/d) NIP Seksi Perencanaan Tata Ruang H. BUDI FIRMANSYAH, ST, M.Si, M.Ak (III/c) NIP Seksi Perumahan BUWANA MAHARDDIKA, ST (III/ d) NIP Seksi Bangunan Gedung Pemerintahan HERI ASARI S.Kom, M.Si (III/b) NIP Seksi Perenanaan ADI HERMAWAN, ST, MT (III/c) NIP Seksi Pemetaan FARAH DIBA, ST, M.Si (III/c) NIP Seksi Penataan Kawasan DIAN NUGRAHA, S.Kom (III/c) NIP Seksi Bangunan Non Pemerintahan ASEEP HERMAWAN, ST (III/c) NIP Seksi Pengawasan ACHMAD NASUHI, ST, MT (III/c) NIP Seksi Pengendalian Pemanfaatan Ruang MUHAMMAD HAFIZ, ST (III/c) NIP Seksi Penyehatan Lingkungan Permukiman (PLP) DEWAN RIDWAN, SE, MM (III/d) NIP Seksi Pemeliharaan Gedung H. HERRY SURYADRMAWAN, S.Sos, MM (III/d) NIP Seksi Data Informasi dan Pengujian TEGUH SUGARWONO, S.Sos (IV/d) NIP 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:

146 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.

147 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.

148 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.

149 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 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 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

150 122 kerja dapat berjalan. Sedangkan aktivitas pendukung digunakan untuk mendukung dan mengawasi aktivitas utama. Berikut diagram value chain pada DTKBDP : Support Activities Primary Activities m Inbound Logistics : Manajjhh 1. Rekomendasi IMB Inventarisvvh 2. Hasil Musrembang = Operation: 1. Sidang 2. Survei Lokasi 3. DPA 4. Lelang Proyek Manajemen Keuangan Sumber Daya Manusia Inventaris Perencanaan Bisnis Strategis Outbond: 1. Rekomendasi IMB 2. Bangunan Marketing: 1. Web Service: 1. SLF 2. Pengecekan Progress Bangunan Kepuasan Stakeholder 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

151 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

152 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

153 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

154 126 tahun kedepan dalam rangka memperbaiki sektor pembangunan didaerah Tangerang Selatan. Tabel 4.6 Target Value Chain Langkah dalam value chain Inbound Logistic Aktivitas 1. Rekomendasi IMB Output yang diharapkan Penerapan pendaftaran online Operation 2. Hasil Musrembang 1. Sidang 2. Survey Lokasi 3. DPA 4. Lelang Proyek Hasil musrembang yang akurat, serta management penyimpanan musrembang yang baik 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

155 127 Service 1. SLF 2. Pengecekkan Progress Bangunan tentang DTKBDP kota Tangerang Selatan meluas kepada masyarakat Sertifikat untuk kesesuaian pembangunan dengan isi IMB Proses pengecekkan untuk mengetahui kondisi pembangunan secara detail Aktivitas Pendukung 1. Manajemen Keuangan Laporan keuangan yang tepat, akurat, terintegrasi dan real time 2. Sumber Daya Manusia Pengembangan setiap pegawai kompetensi 3. Inventaris 4. Perencanaan Bisnis Strategis 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

156 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 SEKRETARIAT Ir. LISHERNI, M.Si (IV/B) NIP KASI UMUM Ir. Hj. DENIWATI, MM (IV/a) NIP KASUBAG KEUANGAN Dra. IIS HASTATI ROCHIMAT (III/c) NIP KASUBAG PEP RIKAS DIRGANTARI, ST, MT (IV/a) NIP SUBBAGIAN TATA USAHA DAN SDM SUBBAGIAN RUMAH TANGGA Bidang Tata Ruang TONNY SOEWANDI, ST (III/d) NIP Bidang Perumahan CARSONO, S.ST, MM (III/d) NIP Bidang Bangunan MUKODDAS SYUHADA, ST, MT (III/d) NIP Bidang Teknik DEDENG DASA, ST (III/d) NIP Bagian IT Seksi Perencanaan Tata Ruang H. BUDI FIRMANSYAH, ST, M.Si, M.Ak (III/c) NIP Seksi Perumahan BUWANA MAHARDDIKA, ST (III/ d) NIP Seksi Bangunan Gedung Pemerintahan HERI ASARI S.Kom, M.Si (III/b) NIP Seksi Perenanaan ADI HERMAWAN, ST, MT (III/c) NIP Application Seksi Pemetaan FARAH DIBA, ST, M.Si (III/c) NIP Seksi Penataan Kawasan DIAN NUGRAHA, S.Kom (III/c) NIP Seksi Bangunan Non Pemerintahan ASEEP HERMAWAN, ST (III/c) NIP Seksi Pengawasan ACHMAD NASUHI, ST, MT (III/c) NIP System Analyst Programmer Seksi Pengendalian Pemanfaatan Ruang MUHAMMAD HAFIZ, ST (III/c) NIP Seksi Penyehatan Lingkungan Permukiman (PLP) DEWAN RIDWAN, SE, MM (III/d) NIP Seksi Pemeliharaan Gedung H. HERRY SURYADRMAWAN, S.Sos, MM (III/d) NIP Seksi Data Informasi dan Pengujian TEGUH SUGARWONO, S.Sos (IV/d) NIP Technological Support System Database Helpdisk Administrator Administrator Gambar 4.12 Struktur Organisasi usulan DTKBDP

157 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.

158 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.

159 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 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

160 System Administrator 4. Database Administratir pengembangan aplikasi yang telah didesain oleh system analyst. Berperan dalam melakukakan konfigurasi terhadap sistem jaringan komputer. Berperan dalam mendesain arsitektur database, melakukan install dan konfigurasi. Dan juga untuk menjamin keamanan data, dan mengawasi serta meningkatkan performansi database. programming sehingga dapat mengembangkan aplikasi sesuai dengan tujuan bisnis. Pelatihan yang diberikan adalah untuk kemampuan membuat, mengembangkan dan memelihara infrastruktur jaringan yang ada. 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.

161 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 Tata Ruang Bid. Bangunan Bid. Teknik Subbag. Tata Usaha Pemohon Bag. Keuangan Kepala Dinas Pemerintah Non Pemerintah Aktivitas Utama 1. Rekomendasi IMB &SLF 2. Hasil Musrembang 3. Sidang

162 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 Tata Ruang Bidang Bangunan Bidang Teknik Kepala Dinas Memberikan berkas Mengkonfirmasi kelengkapan berkas Mengecek kondisi tanah membuatkan siteplan Mengesahkan rekomendasi 2. Hasil Musrembang Tata Ruang Mengecek hasil muerembang Kepala Dinas Mengesahkan musrembang 3. Sidang Bidang Bangunan Melaksanakan sidang berkas

163 135 Bidang Teknik Membuat gambaran kondisi lahan (siteplan) 4. Survei Lokasi Bidang Bangunan Pelaksanakan survei lapangan Bidang Teknik untuk mengetahui kondisi lahan yang nantinya akan dibangun dan dibuatkan IMB 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 Pemohon Kepala Dinas Mencetak rekomendasi Mendapatkan rekomendasi Mengesahkan rekomendasi 8. Bangunan Bidang Bangunan Mendapatkan hasil bangunan yang sesuai Pemerintah Menyelesaikan pembangunan untuk pemerintah Non Pemerintah Menyelesaikan pembangunan untuk non pemerintah

164 Manajemen Keuangan Bagian Keuangan Kepala Dinas Mengelola penggunaan keuangan dan pencatatan keuangan 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 12. Perencanaan Bisnis Strategis Bagian Keuangan Subbag Tata Usaha Mencatata laporan inventaris Pelaksanaan proses perbaikan berjangka setiap 5 tahun sekali 4.4 Phase B : Buseiness Architecture 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.

165 137 Berikut ini adalah tree diagram untuk pemetaan gabungan layanan bisnis, proses bisnis, dang fungsi bisnis di Dinas Tata Kota Bangunan dan Permukiman KotaTangerangSelatan.

166 Gambar 4.13 Tree Diagram Pemetaan Layanan Bisnis, Proses Bisnis dan Fungsi Bisnis DTKBDP 138

167 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.

168 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

169 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.

170 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

171 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.

172 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.

173 Rancangan Architecture Business Tabel 4.10 Pemetaan Kendala No Bagian Kendala Solusi 1. Pelayanan IMB dan SLF 2. Tim survey IMB dan SLF Pelayanan masih dilakukan papper based, dan terlalu banyak sidang Survey lokasi masih dilakukan secara manual Perancangan aplikasi IMB dan SLF Perancangan sistem pemetaan lokasi 3. DPA Belum ada Membuat DBMS management database 4. Sekretariat Pertukaran data masih papper based 5. Bangunan Proses lelang masih manual Sistem terintegrasi antar bidang Pembuatan Sistem Pendukung Keputusan (SPK) 6. Keuangan Proses pencacatan keuangan masih Pembuatan sistem keuangan bersifat manual kesulitan dalam membuat laporan

174 146 keuangan yang cepat dan akurat 7. Inventaris Pendataan inventaris barang Pembuatan sistem E- inventaris masih manual Kesulitan dalam pencatatan inventaris jika ada banyak perubahan berikut: Solusi visi arsitektur sesuai dengan solusi dari kendala yang ada sebagai

175 147 Pemohon 8. Menyerahkan rekomendasi IMB 1. Daftar IMB 2. Upload berkas Informasi Publik Sekretariat 13. Cetak SLF 9. Upload SLF Portal DTKBDP terintegrasi 7. Cetak rekomendasi IMB 13. Input hasil musrembang Pemerintah Kota 27. Input Rekomendasi SLF Pemkot Panitia SLF Tim Survey 3. Cek Berkas 4. Survey Lapangan 10. Pemerikasaan berkas SLF 11. Konfirmasi kontruksi bangunan Bagian Keuangan Pengawasan Bangunan 12. Input berkas SLF 17. Manage data pembangunan 18. Input progress pembangunan Aplikasi E-IMB dan SLF SPK Lelang TABG 5. Cek berkas site plan 6. Input rekomendasi 16. Input spesifikasi proyek 14. Input DPA Kontraktor Aplikasi Progress Bangunan 15. Input design 19. View laporan pembangunan Kepala Dinas Bidang Teknik 26. Input Rekomendasi IMB Musrembang 20. Input Data Inventaris 22. View Laporan Inventaris Subbag. Rumah Tangga 21. Manage Data Inventaris Aplikasi E-Inventaris 20a. Input Data Inventaris Bidang Bangunan 23. Melakukakn pencantatan akuntansi Subbag Tata Usaha 24. Mengatur periode pembuatan Laporan keuangan Aplikasi E-Keuangan Bagian Keuangan 25. Melihat laporan keuangan View Laporan Pengesahan Gambar 4.23 Solusi Arsitektur Bisnis

176 Permohonan Rekomendasi IMB dan SLF 8. menyerahkan Rekomendasi IMB 1, Daftar IMB 2. Upload Berkas 9. Upload SLF 13. menyerahkan IMB musrembang 14. Input SLF pemkot Bidang Bangunan Pemohon Portal DTKBDP Integrasi 12. Cetak SLF Sekretariat Panitia SLF 10. Pemeriksaan Berkas SLF 16. cetak SLF pemkot Pengawas Bangunan 11. Konfirmasi Kontruksi Bangunan 7. Cetak Rekomendasi IMB 15. cetak IMB musrembang 3. Cek Berkas 4. Survey Lapangan Aplikasi E-IMB dan SLF 5. Cek Berkas Site Plan Tim Survey TABG 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.

177 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 1. Input Hasil Musrembang Pemerintah Kota Portal DTKBDP Integrasi 4, Input Spesifikasi Proyek Kontraktor 2. Input DPA 3. Input Design Bagian Keuangan Aplikasi SPK Lelang Bidang Teknik Gambar 4.25 Solusi Arsitektur Bisnis SPK Lelang

178 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.

179 Progress Bangunan 1. kelola data bangunan 2. input progress bangunan Pengawas Bangunan 3. View Laporan Pembangunan Aplikasi Progress Bangunan Kepala Dinas 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.

180 E-inventaris 2. Kelola Data Inventaris 1. Input Data Inventaris Subbag. Rumah Tangga Bidang Teknik 3. View Laporan Inventaris 1a. Input Data Inventaris Bagian Keuangan Aplikasi E-inventaris Bidang Bangunan 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.

181 Keuangan Subbag. Tata Usaha 1. Melakukan Pencatatan Akuntansi 2. Mengatur Periode Pembuatan Laporan Keuangan Aplikasi E-keuangan Bagian Keuangan 3. Melihat Laporan Keuangan Kepala Dinas 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.

182 Phase C: Information System Application 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

183 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.

184 156 Rancangan ini mencakup model bisnis usulan berdasarkan skenario bisnis yang sudah diidentifikasikan berdasarkan fase sebelumnya. Berikut penggambaran skenario bisnis dalam use case diagram.

185 157 Log Out System <<include>> Log in Daftar Rekomendasi IMB Tim Survey Upload Berkas IMB View Berkas Pemohon Survey Lapangan TABG Cek Berkas Site Plan Input Rekomendasi IMB Cetak Rekomendasi IMB Upload Berkas Surat Layak Fungsional Sekretariat Periksa Berkas Surat Layak Fungsioanal Konfirmasi Kontruksi Bangunan Input Rekomendasi Surat Layak Fungsional Panitia SLF Cetak Rekomendasi Surat Layak Fungsional Input Hasil Musrembang Pemerintah Kota Input DPA Input Design Proyek Input Proposal Proyek Memilih Kontraktor Kontraktor Bidang Teknik Input Rekomendasi IMB Musrembang Approve Proyek Manage Data Bangunan Bidang Bangunan Input Progress Bangunan Pengawas Bangunan Input Rekomendasi SLF Pemkot View Laporan Progress Bangunan View Laporan Pengesahan Kepala Dinas Subbag Rumah Tangga Manage Data Inventaris Input Pengguna Data Inventaris View Laporan Inventaris Mencatat Laporan Keuangan Manage Data Keuangan Admin View Laporan Keuangan Manajemen User Bagian Keuangan Gambar 4.29 Arsitektur Aplikasi

186 Arsitektur Aplikasi Permohonan Rekomendasi IMB <<include>> Log Out Log in Manajemen User Admin Daftar Rekomendasi IMB Upload Berkas IMB Bidang Bangunan View Berkas Pemohon Survey Lapangan Cek Berkas Site Plan Input Rekomendasi IMB Tim Survey TABG Input Rekomendasi IMB Musrembang Cetak Rekomendasi IMB Pengesahan Permohonan Sertifikat Layak FUngsional Sekretariat Kepala Dinas View Laporan 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

187 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.

188 Arsitektur Aplikasi Rekomendasi SLF <<include>> Log Out Log in Admin Manajemen User Upload Berkas SLF Pengawas Bangunan Periksa Berkas Surat Layak Fungsioanal Pemohon Konfirmasi Kontruksi Bangunan Input Rekomendasi SLF Pemkot Pemeriksa Lapangan Cetak Rekomendasi Surat Layak Fungsional Panitia SLF Pengesahan Permohonan Sertifikat Layak FUngsional View Laporan Proyek Sekretariat Kepala Dinas 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.

189 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 Arsitektur Aplikasi SPK Lelang Log in <<include>> Log Out Manajemen User Admin Input Hasil Musrembang Input DPA Bagian Keuangan Input Design Proyek Pemerintah Kota Input Proposal Proyek Memilih Kontraktor Kontraktor Pengesahan Proyek Bidang Teknik View Laporan Proyek Kepala Dinas Sekretariat 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

190 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.

191 Arsitektur Aplikasi Progress Bangunan <<extend>> Log Out Log in Manajemen User Admin Manage Data Bangunan Input Progress Bangunan View Laporan Progress Bangunan Pengawas Bangunan Kepala Dinas 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.

192 Arsitektur Aplikasi E-inventaris Log Out <<extend>> Admin Log in Manajemen User Input Data Inventaris Bagian Keuangan Bidang Bangunan Manage Data Inventaris View Laporan Inventaris Bidang Teknik Subbag. Rumah Tangga Kepala Dinas 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

193 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 Arsitektur Aplikasi E-keuangan <<extend>> Log Out Log in Manajemen User Admin pencatatan akuntansi Manage periode pelaporan Bagian Keuangan View Laporan Keuangan Kepala Dinas 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.

194 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 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.

195 Data Dissemination Diagram Pelayanan IMB Pembangunan dan SLF 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

196 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 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.

197 Rekomendasi Permohonan IMB dan SLF User +Nip +Username +Password Level +id_level +nama_level +tambah() +hapus() SLF +No_SLF +Tanggal_SLF +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_SLF +Pengesahan +Tambah() +Hapus() +Ubah() +Print() 1 1..* 1 * Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah() +Tambah() +Hapus() +Ubah() * 1..* 1..* Customer +Id_Customer +Nama_Customer +TTL +Telp +Alamat +KTP +Akta +Tambah() +Hapus() +Ubah() IMB 1 1 +No_IMB +Tanggal_IMB +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_IMB +Pengesahan +Tambah() +Hapus() +Ubah() +Print() 1..* Tanah +Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah +Tambah() +Hapus() +Ubah() 1..* 1 1 Bangunan +Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah() +Hapus() +Ubah() 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 1 1 (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 1 1 (satu ke satu) terhadap pegawai dan kelas

198 170 user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak) terhadap kelas customer. 2. Sistem Penunjang Keputusan Lelang User +Nip +Username +Password +Tambah() +Hapus() +Ubah() Level +id_level +nama_level +tambah() +hapus() 1 1 * DPA +id_dpa +nama anggaran +budget +Tambah() +Hapus() +Edit() 1 Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah() Design_Proyek 1 1..* +Id_Proyek +Nama_Design +Jenis_Design 1 +Tambah() +Hapus() +Ubah() kontraktor +Id_Kontraktor +Nama_Kontraktor +TTL +Alamat +Telp +Tambah() +Hapus() +Ubah() 1..* * 1 Lelang +Id_Lelang +Nama_Proyek +Jenis_Proyek +Nomer_Lelang +Total_Biaya +Operation1() Material +Id_Material +Jenis_Material +Satuan_Material +Jumlah_Material +Harga_Material +Tambah() +Hapus() +Ubah() 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

199 * (satu ke antara satu sampai banyak) terhadap kelas kontraktor dan kelas kontraktor generalisasi dengan kelas material. 3. Progress Bangunan Proyek Level +id_level +nama_level +tambah() +hapus() User +Nip +Username +Password +Tambah() +Hapus() +Ubah() 1 * Pengawas +Id_Pengawas +Nama_Pengawas +Alamat +Telp + +Tambah() +Hapus() +Ubah() * Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah() * Progress +Id_Progress +Rencana_Progress +Realisasi_Progress +Tambah() +Hapus() +Ubah() 1 +Id_Proyek +Nama_Proyek +Nilai +Alamat +Status +Tanggal_Mulai +Tanggal_Selesai +Tambah() +Hapus() +Ubah() * kontraktor +Id_Kontraktor +Nama_Kontraktor +TTL +Alamat +Telp +Tambah() +Hapus() +Ubah() 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 1 1 (satu ke satu) terhadap kelas

200 172 proyek. Kelas proyek memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas kontraktor. 4. E-Inventaris Pegawai Level +id_level +nama_level +tambah() +hapus() Kendaraan +id_kendaraan +merk +tipe +warna +mesin +thn_buat +thn_beli +no_polisi +tgl_bpkb +jumlah +kondisi +Tambah() +Hapus() +Ubah() User +Nip +Username +Password +Tambah() +Hapus() +Ubah() 1 * NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah() Tanah +Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah +Tambah() +Hapus() +Ubah() 1 1..* 1..* 1 1 Registrasi_BMN +no_registrasi +golongan +bidang +kelompok +id_kendaraan +id_peralatan +id_tanah +id_bangunan +Tambah() +Hapus() +Ubah() Bangunan +Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah() +Hapus() +Ubah() Peralatan +id_peralatan +nama_peralatan +merk +tipe +harga_peralatan +harga_perolehan +jumlah +kondisi +Tambah() +Hapus() +Ubah() 1 Aset_Tak_Berwujud +id_atb +nama_atb +merk +jumlah +Tambah() +Hapus() +Ubah() 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 1 1..* (satu ke antara satu sampai banyak) terhadap kelas registrasi_bmn. Kelas pegawai memiliki multiplicity 1 1..* (satu

201 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 Level +id_level +nama_level +tambah() +hapus() 1 * Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian 1 * Periode +id_periode +klasifikasi_periode +tgl_awal_periode +tgl_akhir_periode +Tambah() +Hapus() +Ubah() Klasifikasi_Pengeluaran +id_klasifikasi_pengeluaran +klasifikasi_pengeluaran +Tambah() +Hapus() +Ubah() +Tambah() +Hapus() +Ubah() 1 1 User +Nip +Username +Password +Tambah() +Hapus() +Ubah() 1 * 1 1..* 1 1 General_Ledger +id_jurnal +id_periode +id_pengeluaran +jumlah_pendapatan +jumlah_pengeluaran +keterangan +Tambah() +Hapus() +Ubah() 1 * Pengeluaran +id_pengeluaran +nominal_pengeluaran +tanggal +id_klasifikasi_pengeluaran 1..* 1 +Tambah() +Hapus() +Ubah() 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)

202 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 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,

203 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.

204 176 Lantai 3 Bidang Bangunan Ruang Seksi Ruang Bidang Pembangunan Bangunan Pemerintahan Internet Service Provider Lantai 3 Sekretariat Ruang Kasubag Ruang Kasi Umum Keuangan Firewall Ruang Seksi Pembangunan Non Pemerintahan Ruang SeksiPemeliharaan Gedung Ruang Kasubag PEP Ruang Subbag Rumah Tangga Router Lantai 2 Bidang Perumahan dan Permukiman Ruang Bid. Ruang Seksi Perumahan dan Perumahan Permukiman Lantai 2 Bidang Teknik Ruang Seksi Ruang Bidang Teknik Perencanaan Ruang Penataan Kawasan Ruang Seksi Penyehatan Lingkungan Ruang Seksi Pengawasan Ruang Data Informasi dan Pengujian Lantai 1 Bidang Tata Kota Ruang seksi Ruang Perencanaan pengendalian dan Tata Ruang pemanfaatan ruang Ruang Tunggu Lantai 1 Lobby Ruang Resepsionis Ruang kepala Bidang Tata Kota Ruang seksi pemetaan Gambar 4.42 Arsitektur Jaringan Awal Keseluruhan DTKBDP

205 177 Lantai 3 Bidang Bangunan Ruang Seksi Ruang Bidang Pembangunan Bangunan Pemerintahan IDC (Internet Data Center) Web Server DTKBDP Lantai 3 Sekretariat Ruang Kasubag Ruang Kasi Umum Keuangan Ruang Seksi Pembangunan Non Pemerintahan Ruang SeksiPemeliharaan Gedung Ruang Kasubag PEP Ruang Subbag Rumah Tangga Internet Service Provider Lantai 2 Bidang Perumahan dan Permukiman Ruang Bid. Ruang Seksi Perumahan dan Perumahan Permukiman Lantai 2 Bidang Teknik Ruang Seksi Ruang Bidang Teknik Perencanaan Local Server DTKBDP Router Ruang Penataan Kawasan Ruang Seksi Penyehatan Lingkungan Ruang Seksi Pengawasan Ruang Data Informasi dan Pengujian Server Printer Scanner Lantai 1 Bidang Tata Kota Ruang seksi Ruang Perencanaan pengendalian dan Tata Ruang pemanfaatan ruang Ruang Tunggu Lantai 1 Lobby Ruang Resepsionis Ruang kepala Bidang Tata Kota Ruang seksi pemetaan 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.

206 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

207 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.

208 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).

209 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

210 182 Presentation Microsoft Power Point 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

211 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 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.

212 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.

213 a. Analis Gap Rekomendasi IMB dan SLF 185

214 Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF 186

215 187 b. Analisis Gap SPK Lelang EXISTING FUTURE Penyerahan hasil musrembang sistem manual Penyerahan DPA sistem manual Penyerahan daftar proyek pembangunan sistem manual Penyerahan hasil design proyek pembangunan sistem manual Pelaksanaan proses lelang Pembangunan oleh kontraktor terpilih NEW Input musrembang online Replace Input DPA kedalam isistem Replace Input daftar proyek kedalam sistem Replace Input design proyek kedalam sistem Replace Pemilihan spesifikasi kontraktor melalui sistem Pembangunan oleh kontraktor terpilih Replace Reta in ELIMINATED Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang

216 188 c. Analisis Gap Progress Bangunan FUTURE EXISTING Penyerahan data progress bangunan sistem manual Penyerahan laporan data bangunan sistem manual View laporan data bangunan sistem manual NEW Manage data pembangunan kedalam sistem Replace Input progress laporan bangunan kedalam sistem Replace View laporan data bangunan melalui sistem Replace ELIMINATED Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan d. Analisis Gap Keuangan FUTURE EXISTING Penyusunan anggaran program & anggaran Penarikan dana Penyusunan rencana program & anggaran Retain Penarikan dana Retain Pengelolaan data Pencantatan akuntansi keuangan pada sistem komputer Pembuatan laporan keuangan pada sistem komputer ELIMINATED

217 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 Pencatatan inventaris BMN sistem manual Penyusunan laporan penggunan BMN sistem manual Pengumpulan laporan sistem manual Penyusunan laporan pengelola inventaris sistem manual Penyerahan laporan pengguna & pengelola sistem manual NEW Pencatatan inventaris pada sistem komputer Replace Penyusunan laporan pengguna BMN pada sistem komputer Replace Penyusunan laporan pengelola inventaris pada sistem komputer Replace Penyerahan laporan pengguna && pengelola pada sistem komputer Replace ELIMINATED X Tabel 4.19 Analisis Gap Arsitektur Bisnis E-Inventaris

218 Analis Gap Arsitektur Aplikasi EXISTING FUTURE Portal DTKBDP Aplikasi IMB &SLF Aplikasi SPK Lelang Aplikasi Progress Bangunan Aplikasi Keuangan Aplikasi E-Inventaris ELIMINATED Portal DTKBDP Replace NEW Add Add Add Add Add Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP

219 191 3.Analisis Gap Arsitektur Data : Replace : New : Delete Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP

220 Analisis Gap Arsitektur Teknologi Tabel 4.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP

221 Aplikasi Matriks Terhadap Data EXISTING FUTURE Portal DTKBDP Aplikasi IMB & SLF Aplikasi SPK Lelang Aplikasi Progress Bangunan Aplikasi Keuangan Aplikasi Inventaris Pegawai C,R,U,D R R Pemohon C C,R,U,D R Bangunan C,R,U,D R R IMB SLF C,R,U,D 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 Pengawas C,R,U,D C,R,U,D Periode C,R,U,D

222 194 Pengeluaran Klasifikasi Pengeluaran General Ledger C,R,U,D C,R,U,D C,R,U,D Registrasi BMN Peralatan Aset Tak Berwujud Kendaraan C,R,U,D C,R,U,D C,R,U,D 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 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

223 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 Portal DTKBDP Fungsionalitas 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

224 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

225 197 Berdasarkan perspective diatas, maka urutan implementasi kandidat aplikasi adalah sebagai berikut : 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 Tabel 4.26 Urutan Implementasi

226 Roadmaps Roadmaps merupakan arahan pengembangan aplikasi yang bersifat strategis. Urutan implementasi aplikasi dapat dilihat pada gambar berikut : TAHAP 1 TAHAP 2 TAHAP 3 PORTAL DTKBDP APLIKASI SPK LEANG APLIKASI E-INVENTARIS APLIKASI IMB & SLF APLIKASI PROGRESS BANGUNAN APLIKASI E-KEUANGAN Gambar 4.45 Roadmap Aplikasi

227 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

228 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 Pada tabel roadmap aplikasi pada tahun 2016 terdapat perancangan aplikasi SPK Lelang dan aplikasi Progress Bangunan. Tabel roadmap aplikasi 2016 dapat dilihat dibawah ini:

229 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 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

230 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 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.