Pengertian Perancangan Penelitian Sejenis

BAB II LANDASAN TEORI

2.1 Pengertian Perancangan

Perancangan adalah sebuah proses untuk mendefinisikan sesuatu yang akan dikerjakan dengan menggunakan teknik yang bervariasi serta di dalamnya melibatkan deskripsi mengenai arsitektur serta detail komponen dan juga keterbatasan yang akan dialami dalam proses pengerjaannya Rizky, 2011. Proses perancangan memiliki tiga unsur penting yakni : pengetahuan mengenai teknik perancangan, kebutuhan sistem, serta kendala yang mungkin terjadi Rizky, 2011. 2.2 Konsep Dasar Sistem Informasi 2.2.1 Pengertian Sistem Menurut Jogiyanto 2005 , “Sistem adalah suatu kumpulan komponen yang saling berhubungan satu dengan yang lainnya untuk mencapai sebuah tujuan tertentu”. Menurut Agus Mulyanto 2009, “Sistem adalah kumpulan elemen- elemen yang berinteraksi untuk mencapai suatu tujuan tertentu sebagai satu kesatuan”. Selain itu ada pengertian lain tentang sistem menurut Sanyoto Gondo diyoto 2007, “Sistem adalah kumpulan elemen-elemen atau sumber daya yang saling berkaitan secara terpadu, dan bertujuan untuk mencapai tujuan tertentu”. 15 Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau menyelesaikan suatu sasaran tertentu.

2.2.2 Pengertian Informasi

Definisi informasi menurut Agus Mulyanto 2009, “Informasi merupakan pengetahuan dari hasil pengolahan data-data yang berhubungan menjadi sebuah kesimpulan, pengolahan data yang dibentuk agar berguna bagi pemakainya”. Menurut Sanyoto Gondodiyoto 2007, “Informasi adalah merupakan data yang sudah diolah menjadi bentuk yang lebih berguna dan lebih berarti bermanfaat bagi penerimanya, menggambarkan suatu kejadian dan kesatuan nyata yang dapat dipahami dan dapat digunakan untuk pengambilan keputusan, sekarang maupun untuk masa depan”. Dari beberapa pengertian diatas, dapat disimpulakan informasi merupakan hasil dari pengolahan data. Sedangkan data merupakan kenyataan yang menggambarkan suatu kejadian-kejadian yang nyata. Data sering kali disebut sebagai bahan mentah dari informasi. Melalui proses transformasi, data dibuat menjadi bermakna.

2.2.2.1 Kualitas Informasi

Menurut Jogiyanto 2005 untuk dapat berguna, maka informasi harus didukung oleh tiga pilar sebagai berikut: 1. Relevan Relevance, informasi harus mempunyai manfaat bagi pemakainya. 2. Tepat Waktu Timeliness, informasi harus tepat waktu datang kepada penerima, dan tidak boleh terlambat. 3. Akurat Accurate, informasi harus benar-benar nyata, dan tidak boleh terjadi kesalahan-kesalahan yang nantinya akan menyesatkan penerima informasi. Informasi yang disampaikan harus jelas maksud dan tujuannya.

2.2.3 Pengertian Sistem Informasi

Menurut Agus Mulyanto 2009, “Sistem informasi merupakan suatu komponen yang terdiri dari manusia, teknologi informasi, dan prosedur kerja yang memproses, menyimpan, menganalisis, dan menyebarkan informasi untuk mencapai suatu tujuan”. Adapula pengertian lain tentang sistem informasi menurut Jogiyanto 2005, “Sistem informasi adalah suatu sistem di dalam suatu organisasi yang merupakan kombinasi dari orang-orang, fasilitas, teknologi, media, prosedur- prosedur dan pengendalian yang ditujukan untuk mendapatkan jalur komunikasi penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada manajemen dan yang lainnya terhadap kejadian-kejadian internal dan eksternal yang penting dan menyediakan suatu dasar informasi untuk pengambilan keputusan yang cerdik.” Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem Informasi mencakup sejumlah komponen manusia, komputer, teknologi informasi dan prosedur kerja, ada sesuatu yang diproses yaitu data menjadi informasi, dan dimaksudkan untuk mencapai suatu sasaran atau tujuan.

2.3 Konsep Dasar Enterprise Architecture

2.3.1 Pengertian Enterprise

Enterprise merupakan kumpulan perusahaan atau organisasi yang memiliki beberapa tujuan tertentu. Menurut para ahli, enterprise dapat didefinisikan sebagi berikut : 1. “Enterprise bukan hanya perusahaan company yang berorientasi kepada profit saja, tetapi juga bisa berupa organisasi non-profit atau nirlaba. Seperti pemerintah, institusi pendidikan ataupun organisasi amal” Surendro, 2009. 2. “Enterprise diartikan sebagai semua kumpulan organisasi yang memiliki sekumpulan tujuan. Enterprise dapat merupakan sebuah agen pemerintahan, sebuah korporasi keseluruhan, divisi korporasi, departemen tunggal atau sebuah rantai organisasi yang berhubungan tetapi berjauhan secara geografis” The Open Group, 2009. Menurut definisi diatas, dapat disimpulkan bahwa enterprise adalah suatu kumpulan perusahaan atau organisasi yang mempunyai tujuan bisnis untuk mencapai tujuan perusahaanorganisasi.

2.3.2 Pengertian Architecture

Menurut Surendro 2009, “Architecture merupakan suatu perencanaan yang diwujudkan dengan model dan gambar dari bagiankomponen dari sesuatu dengan berbagai sudut pandang”. Enterprise Architecture diperlukan karena merupakan sebagai dasar sistem organisasi yang terdiri dari sekumpulan komponen yang memiliki hubungan satu sama lainnya serta memiliki keterhubungan dengan lingkungan sistem, dan memiliki aturan untuk perancangan dan evaluasi The Open Group, 2009. Architecture pada awalnya hanyalah sebuah prinsip dan istilah yang digunakan untuk membuat bangunan, tetapi didalam konteks teknologi informasi, architecture diperlukan untuk membangun sebuah sistem.

2.3.3 Pengertian Enterprise Architecture

Enterprise Architecture merupakan perancangan proses bisnis dan teknologi disetiap organisasi dan perusahaan, dan kemudian diintegrasikan untuk mencapai suatu tujuan tertentu. Menurut Surendro 2009, Enterprise Architecture merupakan kumpulan prinsip, metode, dan model yang bersifat masuk akal yang digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi enterprise, struktur organisasi, sistem inform asi 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 organisasiperusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsip- prinsip yang memberikan keleluasaan dalam memilih teknik pemodelan yang digunakan dan merupakan panduan gabungan dari berbagai framework pengembangan arsitektur FEAF, TEAF, DoDAF, dsb. “TOGAF memberikan metode yang detail mengenai bagaimana membangun, mengelola dan mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan Architecture Development Method ADM Surendro, 2009”. Menjelaskan bagaimana menemukan sebuah arsitektur perusahaanorganisasi 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. Menurut The Open Group 2009, ada empat jenis arsitektur yang umumnya diterima sebagai bagian dari keseluruhan Enterprise Architecture, yaitu : a. Business architecture, yaitu mendefinisikan bagaimana proses bisnis untuk mencapai tujuan organisasi. b. Data architecture, adalah penggambaran bagaimana penyimpanan, pengelolaan, dan pengaksesan data pada perusahaan. c. Application architecture, merupakan pendeskripsian bagaimana suatu aplikasi dirancang dan bagaimana interaksi dengan aplikasi lain. d. Technology architecture, yaitu gambaran mengenai infrastruktur perangkat lunak dan perangkat keras yang mendukung aplikasi dan bagaimana interaksinya.

2.4.1 TOGAF Architecture Development Method ADM

TOGAF Architecture Development Method meyediakan teruji dan berulang dalam pengembangan arsitektur yang dibutuhkan perusahaan The Open Group, 2009. ADM merupakan hasil kerjasama generik yang berisikan sekumpulan aktifitas yang mempresentasikan progresi dari setiap fase ADM dan model arsitektur yang digunakan dan dibuat selama tahap pengembangan Enterprise Architecture Surendro, 2009. Prinsip pengembangan enterprise dengan menggunakan metodelogi TOGAF ADM terdiri dari tiga bagian, yaitu : 1. Prinsip-prinsip enterprise, mendukung keputusan bisnis di seluruh bagian organisasiperusahaan. 2. Prinsip-prinsip teknologi informasi, mengarahkan penggunaan sumber daya teknologi informasi di seluruh bagian organisasiperusahaan. 3. Prinsip-prinsip arsitektur, mengembangkan arsitektur proses organisasiperusahaan dan arsitektur implementasinya. Pada prinsip ini dipengaruhi oleh rencana organisasiperusahaan, strategi, faktor pasar, sistem dan teknologi yang ada dalam organisasiperusahaan. ADM mempunyai 9 fase seperti gambar berikut : Gambar 2.1 ADM process The Open Group, 2009

2.4.2 Preliminary

Fase preliminary merupakan tahap awal yang merupakan persiapan arsitektur enterprise. Tahapan ini dilakukan agar proses pemodelan arsitektur dapat terarah dengan baik. Tujuan dari fase preliminary adalah untuk meyakinkan setiap orang yang terlibat didalamnya bahwa pendekatan ini berkomitmen untuk kesuksesan dari setiap arsitektur yang akan dibuat. Pada fase preliminary dilakukan identif ikasi “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 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 penelitian ini, objek penelitian penulis dilakukan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan DTKBDP

2.4.3 Requirement Management

Reuqirement Management adalah proses pengelolaan kebutuhan arsitektur di seluruh fase TOGAF ADM. Tujuan dari proses ini adalah untuk menentukan kebutuhan arsitektur enterprise, kebutuhan itu disimpan lalu dimasukkan ke dalam fase yang sesuai The Open Group, 2009 Sumber daya yang harus dikembangkan dalam tahapan ini adalah skenario aktivitas. Skenario aktivitas mencakup process business alur aktivitas dan issue permasalahan dalam organisasi. Process business yang dimaksud adalah penjelasan sistem yang sedang berjalan pada organisasi. Requirement Management memiliki input, serta langkah-langkah, dan berupa output sebagai berikut: a. Input 1. Keadaan sistem pada saat ini. 2. Data inventaris sarana dan prasarana pendukung TIK. b. Langkah-langkah 1. Menganalisa kekurangan dan kelebihan dari kondisi sistem pada saat ini. 2. Identifikasi permasalahan dari kondisi sistem pada saat ini. 3. Membuat solusi dari setiap permasalahan pada kondisi sistem saat ini. c. Output 1. Tabel permasalahan organisasi, yang menjelaskan daftar permasalahan dari setiap aktivitas organisasi. 2. Tabel solusi aktivitas, yang berisi tentang permasalahan dari setiap aktivitas beserta solusi yang akan mengatasi permasalahan tersebut. 3. Tabel solusi sistem informasi, pada tabel ini hampir sama dengan tabel solusi altivitas. Tetapi, perbedaannya ada pada kolom solusi. Pada tabel ini, solusi yang akan diberikan sudah menyebutkan sistem atau aplikasi apa saja yang nantinya seharusnya digunakan dalam mengatasi permasalahan organisasi.

2.4.4 Phase A : Architecture Vision

Fase ini untuk menciptakan keselarasan pandangan bagaimana pentingnya EA untuk pencapaian tujuan organisasi. Elemen kunci dalam fase ini adalah visi, misi, strategi, serta tujuan perusahaan yang telah didokumentasikan. Kesemuanya itu dibutuhkan untuk menetapkan visi arsitektur yang baru. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menentukanmenetapkan 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. 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 menjelaskan hubungan antara stakeholder dengan aktivitas dalam organisasi.

2.4.5 Phase B : Business Architecture

Pada fase ini bertujuan untuk menguraikan deskripsi arsitektur bisnis dasar, mengembangkan tujuan arsitektur bisnis dari proyek. Mengembangkan target arsitektur bisnis yang menjelaskan bagaimana pelaksanaan kebutuhan perusahaan untuk mencapai tujuan bisnis dalam mendukung visi arsitektur yang telah disetujui. Mendefinisikan kondisi awal arsitektur bisnis, menentukan pemodelan dari arsitektur saat ini serta yang diinginkan menggunakan alat bantu seperti model proses bisnis atau model business usecase. Beberapa tahap yang dilakukan di fase ini adalah: 1. Melengkapi arsitektur bisnis. 2. Melakukan Gap analysis. 3. Mengembangkan deskripsi arsitektur bisnis saat ini untuk mendukung arsitektur bisnis target. 4. Mengidentifikasi reference model, sudut pandang dan tools. 5. Menentukan kandidat calon roadmap. 6. Membuat dokumen definisi arsitektur. 7. Menyelesaikan arsitektur bisnis. Fase arsitektur bisnis memiliki input, langkah-langkah, dan output sebagai berikut : a. Input 1. Kondisi aktivitas pada saat ini. b. Langkah-langkah 1. Mengembangkan deskripsi arsitektur aktivitas dasar. 2. Melakukan analisis gap. 3. Membuat arsitektur bisnis aktivitas. c. Output 1. Pemodelan arsitektur bisnis menggunakan archimate. 2. Rancangan arsitektur bisnis yang digambarkan menggunakan rich picture. 3. Struktur organisasi usulan, merupakan rancangan struktur organisasi yang baru untuk menunjang kinerja organisasi dan kinerja sistem informasi agar dapat berjalan dengan baik. Arsitektur bisnis dapat dijelaskan meggunakan beberapa konsep tambahan berdasarkan orientasi layanan, yaitu konsep business service layanan bisnis, business process proses bisnis, dan business function fungsi bisnis. a. Business Service Business Service merepresentasikan kemampuan yang menawarkan nilai tambah untuk lingkungan dan kemampuan ini direalisasikan secara internal dan independen The Open Group, 2009. b. Business Process Business Process merepresentasikan alur kerja atau aliran nilai yang terdiri atas proses atau fungsi lebih kecil. Tujuan dari business process adalah untuk memuaskan customer The Open Group, 2009. c. Business Function Business Function menetapkan elemen perilaku berdasarkan pada sekumpulan kriteria terpilih. Business function mengelompokkan perilaku berdasarkan pada sumber daya bisnis, kemampuan, kompetensi dan pengetahuan yang dibutuhkan. Busniess function adalah tugas-tugas khusus yang dilakuan dalam sebuah organisasi The Open Group, 2009.

2.4.6 Phase C : Information Systems Architecture

Pada fase ini bertujuan untuk mendefinisikan tipe dan sumber utama data yang diperlukan untuk mendukung bisnis. Pada tahap ini tidaklah memperhatikan perancangan database, hanya menjelaskan pengembangan dari arsitektur sistem informasi untuk mendukung fase A yang telah disetujui. Beberapa tahap yang dilakukan di fase ini adalah: 1. Arsitektur data, tujuannya adalah mendefinisikan entitas data yang relevan dengan enterprise yang berhubungan dengan perusahaan, tetapi tidak memperhatikan perancangan database. 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. 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.

2.4.7 Phase D : Technology Architecture

Tujuan dari fase ini adalah untuk mengembangkan arsitektur teknologi yang diinginkan yang sesuai dengan arsitektur data dan aplikasi, yang mewakili perangkat lunak dan komponen perangkat keras, alternatif teknologi sampai pelaksanaan analisis kesenjangan. Beberapa tahap yang dilakukan di fase ini adalah: 1. Mengidentifikasi model, sudut pandang dan tools yang digunakan. 2. Mengembangkan baseline arsitektur teknologi. 3. Mengembangkan deskripsi target arsitektur teknologi. 4. Membuat analisis gap. 5. Menentukan kandidat roadmap. 6. Menanggulangi seluruh dampak arsitektur. 7. Membuat review untuk stakeholder. 8. Menyelesaikan arsitektur teknologi. 9. Membuat dokumen definisi arsitektur. Fase arsitektur teknologi memiliki input, langkah-langkah, dan output sebagai berikut : a. Input 1. Technology principles saat ini, berisi prinsip-prinsip mengenai teknologi yang digunakan untuk mendukung aktivitas pada organisasi. b. Langkah-langkah 1. Melakukan analisis gap. 2. Menyelesaikan arsitektur teknologi. 3. Mengembangkan deskripsi dasar arsitektur teknologi. 4. Mengembangkan deskripsi target arsitektur teknologi. c. Output 1. Rancangan komunikasi dalam arsitektur teknologi, seperti rancangan jaringan yang melibatkan hardware untuk membuat suatu komunikasi jaringan. Rancangan tersebut digambarkan dalam communication engineering diagram. 2. Platform decomposition diagram menggambarkan platform teknologi yang mendukung sistem informasi. 3. Identifikasi teknologi yang sudah digunakan dalam sistem yang berjalan pada organisasi. hasil tersebut dapat dijelaskan menggunakan technology portofolio catalog.

2.4.8 Phase E : Opportunities and Solution

Pada fase ini bertujuan untuk berkonsentrasi pada rencana pembuatan implementasi awal dan identifikasi penyampaian arsitektur yang telah ditetapkan pada fase sebelumnya. Pada tahapan ini pula akan dievaluasi model yang telah dibangun untuk arsitektur saat ini dan target, identifikasi proyek utama yang akan dilaksanakan untuk mengimplementasikan arsitektur tujuan dan klasifikasi sebagai pengembangan baru atau penggunaan kembali sistem yang sudah ada. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menentukan atribut key corporate change. 2. Menetapkan batasan-batasan bisnis. 3. Menggabungkan hasil analisis gap dari fase Business Architecture sampai Technology Architecture. 4. Membuat ulasan persyaratan fungsi bisnis yang terkait. 5. Menggabungkan persyaratan operasi. 6. Mengesahkan ketergantungan. 7. Menetapkan kesiapan dan resiko transformasi bisnis. 8. Merumuskan implementasi dan migrasi. 9. Mengidentifikasi paket kerja kelompok utama. 10. Mengidentifikasi arsitektur transisi. 11. Membuat roadmap arsitektur dan implementasi migrasi. Fase peluang dan solusi memiliki input, langkah-langkah dan output sebagai berikut : a. Input 1. Hasil analisis gap dari arsitektur bisnis, data, aplikasi dan teknologi. b. Langkah-langkah 1. Merumuskan implementsi dan strategi migrasi. 2. Menentukan kendala aktivitas untuk implementasi. 3. Meninjau kembali dan menggabungkan hasil analisis gap dari fase B sampai fase D. c. Output 1. Hasil analisis gap gabungan dari fase arsitektur bisnis sampai arsitektur teknologi

2.4.9 Phase F : Migration Planning

Pada fase ini bertujuan untuk memilih proyek implementasi yang bervariasi menjadi urutan prioritas. Aktivitas mencakup penilaian ketergantungan, biaya, manfaat dari proyek migrasi yang bervariasi. Prioritas proyek akan berjalan untuk membentuk dasar dari perencanaan implementasi detail dan rencana migrasi. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menetapkan nilai bisnis untuk setiap paket kerja. 2. Memperkirakan kebutuhan sumberdaya, waktu proyek dan waktu pengiriman. 3. Mengutamakan migrasi proyek berdasarkan perkiraan biaya dan resiko. 4. Menyelesaikan rencana implementasi dan migrasi. Fase rencana migrasi memiliki input, langkah-langkah dan output sebagai berikut: a. input 1. Implementation and migration plan, suatu rencana untuk menjadwalkan migrasi data dan implementasi aplikasi. b. Langkah-langkah 1. Menetapkan model bisnis pada setiap proyek. 2. Membuat roadmap implementasi arsitektur dan perencanaan migrasi. 3. Memastikan interaksi kerangka kerja manajemen untuk rencana implementasi dan migrasi. 4. Lebih memprioritaskan proyek migrasi melalui pelaksanaan penilaian biaya. c. output 1. Roadmap implementasi aplikasi.

2.4.10 Phase G : Implementation Governance

Pada fase ini, proyek dilaksanakan sebagai program rencana kerja, serta pengelolaan proyek untuk mencapai keberhasilan arsitektur yang diinginkan. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menetapkan ruang lingkup dan prioritas implementasi dengan manajemen pengembangan. 2. Mengidentifikasi sumberdaya dan kemampuan. 3. Melakukan penetapan solusi pengembangan pada setiap implementasi. 4. Menjalankan Enterprise Architecture yang telah dibuatdirancang. 5. Mengimplementasikan manajemen bisnis dan operasi IT. 6. Mengadakan post-implementation dan menyelesaikan implementasi. Fase tata kelola implementasi memiliki input, langkah-langkah dan output sebagai berikut : a. Input 1. Architecture roadmap b. Langkah-langkah 1. Mengidentifikasi sumber daya. 2. Menerapkan bisnis operasi dan IT. 3. Melaksanakan tinjauan pasca implementasi dan menutupnya. c. Output 1. Kontrak arsitektur yang telah ditandatangani

2.4.11 Phase H : Architecture Change Management

Tujuan fase ini adalah untuk memastikan bahwa arsitektur mencapai target bisnis serta untuk menentukanmenetapkan 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. 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.

2.4.12 Kelebihan dan Kekurangan TOGAF

Salah satu kelebihan menggunakan TOGAF adalah karena sifatnya yang fleksibel dan bersifat open source. TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah business architecture, application architecture, data architecture, dan technology architecture Setiawan, 2009. Secara umum TOGAF memiliki struktur dan komponen sebagai berikut: 1. Architecture Development Method ADM Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana mementukan sebuah enterprise architecture secara spesifik berdasarkan kebutuhan bisnisnya. 2. Foundation Architecture Merupakan sebuah framework-within-a-framework dimana didalamnya tersedia gambaran hubungan untuk pengumpulan arsitektur relevan, juga menyediakan bantuan petunjuk pada saat terjadinya abstraksi level yang berbeda. foundation Architecture dapat dikumpulkan melalui ADM. 3. Resource Base Pada bagian ini terdapat informasi mengenai guidelines, templates, checklist, latar belakang informasi dan detail material pendukung yang membantu arsitek dalam penggunaan ADM. Kekurangan framework TOGAF: 1. Tidak adanya template standar untuk seluruh domain misalnya untuk membuat blok diagram. 2. Tidak ada artefak yang dapat digunakan ulang ready made. 2.5 Tools Perancangan Arsitektur 2.5.1 Principle Cataloga Bertujuan dari katalog ini adalah untuk menangkap bisnis dan prinsip- prinsip yang menggambarkan solusi atau arsitektur yang seharusnya seperti apa. Nantinya prinsip-prinsip ini digunakan untuk mengevaluasi dan menyetujui hasil dari arsitektur bisnis. Prinsip ini juga digunakan sebagai tools untuk membuat tata kelola arsitektur yang mempunyai inisiatif perubahan. The Open Group, 2009. Tabel 2.1 Contoh Principle Catalog No Prinsip Tujuan 1. Keputusan arsitektur harus mengacu pada tujuan strategis dan proses bisnis pada Dinas Tata Kota, Bangunan dan Pemukiman.  Mendukung kemampuan adaptasi terhadap proses bisnis  Memperkuat hubungan antara infrastruktur dan proses bisnis serta lebih mudah menyelaraskan proses bisnis ketika perubahan terjadi. 2. Pengelolaan arsitektur ini  Meningkatkan kemampuan untuk diusahakan mudah. berbagi data dan sumber daya lain dalam pelayanan kepada pengguna dan membantu kerjasama antar divisi. 3. Arsitektur yang dikembangkan harus aman.  Dapat meminimalisasi dampak atas bencana alam.  Mampu bertahan dari serangan eksternal seperti virus, worm, hack, syware, crack, phising, denial of service. 4. Data Previlege Perlindungan Data  Untuk melindungi dari akses pihak-pihak yang tidak berwenang.  Mengatur stakeholder dalam mengolah data. 5. Arsitektur dirancang agar mudah melakukan penambahan dan pengembangan.  Memungkinksn respon yang lebih cepat apabila ada perubahan yang dapat berakibat pada infrastruktur yang bersifat adaptif. 6. Penerapan arsitektur multi- tier dan arsitektur berbasis komponen.  Memudahkan kegiatan penggantian komponen yang rusak meningkatkan availability.  Memudahkan duplikasi dan upgrading modul.

7. Menggunakan

open technology.  Menghindari ketergantungan pada vendor.  Menjamin dukungan produk yang kuat terhadap teknologi.  Meminimalisasi training manusia yang harus dilakukan setiap kali ada perubahan dalam pilihan vendor.

8. Data yang konsisten.

 Tersedianya kebutuhan bagi pihak yang membutuhkan.  Meminimalkan resiko akan kerancuan jika ada pengembangan yang akan dikerjakan.

2.5.2 Flowchart

Flowchart merupakan gambar atau bagan yang memerlihatkan urutan dan hubungan antar proses beserta intruksinya. Gambaran ini dinyatakan dengan simblo. Setiap simbol menggambarkan proses tertentu, sedangkan 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 penghubungalur flow direction symbols, simbol proses processing sysmbols, dan simbol input-output input- output symbols. Dengan uraian sebagai berikut. 1. Simbol penghubungalur 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: Tabel 2.2 Simbol Penghubung Flowchart Simbol Penjelasan ArusFlow Untuk menyatakan jalannya arus suatu proses. Communication Link Untuk menyatakan bahwa adanya transisi suatu datainformasi dari satu lokasi ke lokasi lainnya. Connector Untuk menyatakan sambungan dari suatu proses ke proses lainnya dalam halamanlembar yang sama. Off-line Connector Untuk menyatakan sambungan dari satu proses ke proses lainnya dalam halamanlembar yang berbeda. 2. Simbol Proses Processing Symbols Simbol yang menunjukkan jenis operasi pengolahan dalam suatu prosesprosedur. Simbol-simbol tersebut adalah sebagai berikut. Tabel 2.3 Simbol Proses Flowchart Simbol Penjelasan Prosespenugasan Untuk kegiatan pemrosesan input, pada simbol ini dapat menuliskan operasi- operasi yang dikenakan pada input. Manual Untuk menyatakan suatu tindakan proses yang tidak dilakukan oleh komputer manual. Decisionlogika 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. 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. Magnetic-tape Unit Untuk menyatakan input berasal dari pita magnetic atau output disimpan ke pita magnetic. Disk Storage Untuk menyatakan input berasal dari disk atau output disimpan disk. Document Untuk mencetak laporan ke printer. Display Untuk menyatakan peralatan output yang digunakan berupa layar video dan komputer.

2.5.3 Value Chain

Porter 1985, dalam buku karangan Jogiyanto 2005, value chain meliputi kegiatan-kegiatan yang terdiri dari kegiatan-kegiatan atau aktivitas- aktivitas, yaitu: 1. Aktivitas utama, yang meliputi penanganan dan penyimpanan bahan mentah yang berupa inbound logistics, operations, outbond logistics, marketing and sales, dan services. 2. Aktivitas pendukung yaitu infrastruktur perusahaan, yang berupa firm infrastructure, human resources management, technology development, dan procurement. Untuk mencapai keunggulan kompetitif, dua aktivitas besar yang terdiri dari sembilan kegiatan tersebut harus mempunyai nilai yang efektif dan efisien. Nilai disetiap kegiatan harus dapat menciptakan nilai dimasing-masing kegiatan. Gambar 2.2 : Diagram Value Chain Porter, 1985

2.5.3 Stakeholder Map Matrix

Tujuan dari Stakeholder Map Matrix ini adalah untuk mengidentifikasi stakeholder untuk keterlibatannya di dalam aktivitas utama dan aktivitas pendukung The Open Group, 2009. Tabel 2.5 Contoh Stakeholder Map Matrix Stakeholder Aktivitas Ta ta Rua ng B id. B anguna n B id. Te knik Subbag. Ta ta Us aha P emohon B ag. Ke ua nga n Ke pa la D in as P emer int ah Non Peme rinta h Aktivitas Utama 1. Rekomendasi IMB SLF 2. Hasil Musrembang 3. Sidang 4. Survey Lokasi 5. DPA 6. Lelang Proyek 7. Rekomendasi IMB SLF 8. Bangunan Aktivitas Pendukung 1. Manajemen Keuangan 2. SDM 3. Inventaris 4. Perencanaan Bisnis Strategis Pada tabel 2.5 digambarkan keterlibatan stakeholder terhadap aktivitas yang ada di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Kolom pada matriks tersebut merupaka stakeholder yang ada di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Baris pada matriks tersebut merupakan aktivitas-aktivitas yang ada pad DTKBDP. Warna biru yang ada dalam matriks tersebut menandakan siapa saja stakeholder yang terlibat dalam setiap aktivitas.

2.5.4 Archimate

Archimate adalah bahasa pemodelan untuk menggambarkan enterprise architecture. ada standarisasi archimate, terbagi menjadi 3 layer, yaitu layer teknologi, layer bisnis, dam layer aplikasi. a. Layer bisnis 1. Konsep struktural antara peran bisnis, pelaku usaha dan entitas yang melakukan prilaku seperti proses bisnis atau fungsi. Proses bisnis disini menandakan tanggung jawab untuk satu atau lebih proses bisnis atau fungsi bisnis. 2. Peran bisnis ditetapkan pada pelaku usaha. Pelaku usaha bisa berupa individu atau kelompok masyarakatdan sumber daya yang memiliki status permanen dalam organisasi. b. Layer aplikasi Konsep untuk layer ini adalah komponen aplikasi. Konsep ini digunakan untuk memodelkan entitas struktural dalam lapisan aplikasi dari perangkat lunak lengkap atau sistem informasi. c. Layer teknologi Konsep struktural untuk lapisan teknologi ini adlaah node. Konsep ini digunakan untuk memodelkan entitas struktural dlaam lapisan teknologi.

2.5.5 Rich Picture

Merupakan penggambaran sistem atau situasi dengan menggunakan gambar-gambar. Gambaran keseluruhan dari orang, objek, proses, struktur, dan maslah pada keseluruhan proses bisnis yang ada di organisasi. Subbag. Rumah Tangga Aplikasi E-inventaris 2. Kelola Data Inventaris Bagian Keuangan 3. View Laporan Inventaris Bidang Teknik 1. Input Data Inventaris Bidang Bangunan 1a. Input Data Inventaris Gambar 2.3 Contoh Rich Picture Menjelaskan bahwa pada pencatatan penggunaan inventaris di DTKBDP, setiap bidang harus melakukan login terlebih dahulu kedalam sisem, kemudian setiap bidang harus menginput data inventaris yang mereka gunakan setiap bulan. Subbag. Rumah tangga melakukan login kedalam sistem untuk mengelola data inventaris yang digunakan setiap bidang di DTKBDP. Bagian keuangan melihat laporan inventaris melalui sistem E-inventaris.

2.5.6 Data

Dissemination Diagram Data Dissemination Diagram menunjukkan hubungan antara entitas data, layanan bisnis dan komponen aplikasi. Diagram ini menunjukkan bagaimana entitas logis secara fisik diwujudkan dengan komponen aplikasi. Kemudian, menggambarkan replika data dan sistem uta,a untuk data The Open Group, 2009. Gambar 2.4 Data Dissemination Diagram Pada gambar 2.4 menggambarkan hubungan layanan Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan, aplikasi, dan data. Di aplikasi IMB dan SLF terdapat data level, data user, data pegawai, data customer, data tanah, data SLF, data IMB dan data bangunan. Aplikasi SPK Lelang terdapat data level, data user, data pegawai, data kontraktor, data material, data DPA, data design proyek dan data lelang. Aplikasi progress bangunan terdapat data level, data user, data pegawai, data proyek, data pengawas, data progress, dan data kontraktor. Aplikasi E-inventaris terdapat data user, data level, data pegawai dara registrasi_BMN, data peralatan, data kendaraan, data tanah, data bangunan dan data aset_tak_berwujud. Aplikasi E-keuangan terdapat data level, data pegawai, data periode, data klasifikasi_pengeluaran, data user, data pengeluaran dan data general_ledger.

2.5.7 UML

Unified Modelling Laguage UML adalah salah satu alat bantu yang sangat handal di dunia pengembangan sistem yang berorientasi objek. Hal ini disebabkan karena UML menyediakan bahasa pemodelan visual yang memungkinkan bagi pengembang sistem untuk membuat cetak biru atas visi mereka dalam bentuk yang baku, mudah dimengerti serta dilengkapi dengan mekanisme yang efektif untuk berbagi dan mengkomunikasikan rancangan mereka dengan yang lain. UML merupakan kesatuan dari bahasa pemodelan yang dikembangkan oleh Booch, Object Modelling Technique OMT dan Object Oriented Engineering OOSE. Metode Booch dari Grady Booch sangat terkenal dengan nama metode Design Object Oriented. Metode ini menjadikan proses analisis dan design ke dalam empat tahapan iteratif, yaitu: identifikasi kelas-kelas dan obyek- obyek, identifikasi semantik dari hubungan obyek dan kelas tersebut, perincian interface dan implementasi. Desain sistem pada UML disusun oleh simbol-simbol yang terbentuk menjadi diagram model. Berikut adalah simbol yang digunakan pada desain sistem ini. UML memiliki beberapa diagram diantaranya Munawar, 2005:

1. Diagram Use Case

Use Case adalah deskripsi fungsi dari sebuah sistem dari perspektif pengguna. Use case bekerja dengan cara mendeskripsikan tipikal interaksi antara user pengguna sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai Munawar, 2005. Usecase merupakan konstruksi untuk mendeskripsikan bagaimana sistem akan terlihat di mata pengguna potensial. Use case terdiri dari sekumpulan skenario yang dilakukan oleh seorang actor orang, perangkat keras, urutan waktu atau sistem yang lain. Use case adalah alat bantu terbaik guna menstimulasi pengguna potensial untuk mengatakan tentang suatu sistem dari sudut pandangnya. Diagram use case mempunyai 3 notasi yang menunjukkan aspek dari sistem, yaitu actor pengguna, use case dan relationship Munawar, 2005. Berikut adalah simbol-simbol yang ada pada diagram use case: sugiarti, 2013: 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 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 dijalankan sebelum use case tambahan dijalankan. Kedua sudut pandang tersebut dapat digunakan salah satu atau keduanya, tergantung pada pertimbangan dan sudut pandang yang dibutuhkan. Gambar 2.5 Contoh Model Use Case Diagram Pada gambar 2.5 menjelaskan use case diagram di sistem SPK lelang. Arsitektur bisnis SPK Lelang memiliki 7 aktor dan 10 use case yang dapat dilakukan dalam sistem SPK lelang. Aktor yang terlibat yaitu, admin, bagian Pemerintah Kota Input Hasil Musrembang Bagian Keuangan Input DPA Bidang Teknik Input Design Proyek Kontraktor Input Proposal Proyek Sekretariat Memilih Kontraktor Kepala Dinas Pengesahan Proyek View Laporan Proyek Log in Log Out include Admin Manajemen User 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. 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 Kebergantungan Depedency Relasi antar kelas dengan makna kebergantungan antar kelas. Gambar 2.6 Contoh Model Class Diagram Pada gambar 2.6 menjelaskan Class Diagram di sistem IMB dan SLF. Arsitektur data IMB dan SLF memiliki 8 kelas, yaitu Level, user , Pegawai, Customer, Tanah, Bangunan, SLF, dan IMB. Kelas level memiliki multiplicity 1  satu ke banyak terhadap kelas pegawai. Kelas pegawai memiliki multiplicity 1 1.. satu ke antara satu sampai Level +id_level +nama_Level +tambah +hapus Customer +Id_Customer +Nama_Customer +TTL +Telp +Alamat +KTP +Akta +Tambah +Hapus +Ubah Bangunan +Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah +Hapus +Ubah Tanah +Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah +Tambah +Hapus +Ubah Pegawai +NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah +Hapus +Ubah 1 1.. 1 1.. 1 1.. 1 1 1 IMB +No_IMB +Tanggal_IMB +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_IMB +Pengesahan +Tambah +Hapus +Ubah +Print SLF +No_SLF +Tanggal_SLF +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_SLF +Pengesahan +Tambah +Hapus +Ubah +Print 1.. 1 1.. 1 User +Nip +Username +Password +Tambah +Hapus +Ubah 1 1 1 1.. 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.

2.5.6.1 Sejarah UML

Pada akhir tahun 80-an dan awal 90-an, di gunakan beberapa metode berorientasi objek yang berbeda-beda. Yang paling terkenal adalah metode Booch dari Grady Booch Object Modeling Technique OMT dari James Rumbaugh OMT, dan Object Oriented Software Engineering OOSE dari Ivar Jacobson. Banyaknya teknik yang di gunakan membatasi kemampuan untuk memakai model-model pada proyek lain mengurangi reuse dan tim pengembang. Konsekuesinya, teknik ini menghambat komunikasi antara anggota tim dan pengguna, yang mengakibatkan banyak terjadi error di dalam proyek. Masalah ini dan lainnya mendorong di lakukannya usaha untuk mendesain bahasa pemodelan standar Whitten et al. 2006. Pada tahun 1994, Grady Booch dan James Rumbaugh sepakat bergabung untuk menggunakan metode pengembangan berorientasi objek dengan tujuan membuat proses standar tunggal untuk mengembangkan sistem berorientasi objek. Ivar Jacobson bergabung pada tahun 1995, dan mereka bertiga fokus membuat sebuah bahasa pemodelan objek standar sebagai ganti dari pendekatan atau metode berorientasi objek standar. Berdasarkan keja mereka dan hasil kerja lainnya pada industri, Unified Modeling Language UML versi 1.0 di rilis pada tahun 1997 Whitten et.al, 2006.

2.5.7 Principle Catalog

Catalog ini digunakan untuk menetapkan beberapa prinsip bisnis dan arsitektur perusahaan dalam memberikan solusi arsitektur yang tepat untuk perusahaan. Catalog ini juga dapat digunakan untuk mengevaluasi implementasi arsitektur serta menilai perubahan tata kelola arsitektur yang terjadi. The Open Group, 2011. Tabel 2.8 Principle Catalog No Prinsip Tujuan 1. Keputusan arsitektur harus mengacu pada tujuan strategis dan proses bisnis pada Dinas Tata Kota, Bangunan dan Pemukiman.  Mendukung kemampuan adaptasi terhadap proses bisnis  Memperkuat hubungan antara infrastruktur dan proses bisnis serta lebih mudah menyelaraskan proses bisnis ketika perubahan terjadi.

2. Pengelolaan arsitektur ini

diusahakan mudah.  Meningkatkan kemampuan untuk berbagi data dan sumber daya lain dalam pelayanan kepada pengguna dan membantu kerjasama antar divisi.

3. Arsitektur

yang dikembangkan harus aman.  Dapat meminimalisasi dampak atas bencana alam.  Mampu bertahan dari serangan eksternal seperti virus, worm, hack, syware, crack, phising, denial of service.

4. Data

Previlege Perlindungan Data  Untuk melindungi dari akses pihak-pihak yang tidak berwenang.  Mengatur stakeholder dalam mengolah data.

2.5.8 Technology Portofolio Catalog

Catalog ini digunakan untuk mengidentifikasi daftar teknologi yang digunakan dalam perusahaan, seperti hardware, infrastructure software, dan application software. Technology portfolio yang sudah disetujui akan menjadi dasar standar teknologi perusahaan yang dapat mendukung siklus hidup produk menajemen teknologi dan beberapa versi teknologi selanjutnya The Open Group, 2011. Tabel 2.9 Technology Portofolio Catalog Pada tabel 2.9 dijelaskan teknologi apa saja yang dibutuhkan dan akan digunakan DTKBDP dalam arsitektur teknologi usulan untuk setiap aplikasi yang akan dibangun.

2.5.9 Communications Engineering Diagram

Diagram ini menjelaskan maksud komunikasi antar aset dalam arsitektur teknologi. Adanya koneksi logis antara clienT dan server dalam mengidentifikasi batasan jaringan dan jaringan infrastruktur yang diperlukan secara fisik untuk mengimplementasikan koneksi tersebut. Diagram ini tidak menjelaskan format informasi ataupun konten, tetapi menjelaskan alamat protokol dan kapasitas The Open Group, 2009. Gambar 2.7 : Contoh Communication Engineering Diagram

2.5.10 Platform Decomposition Diagram

Menurut The Open Group 2009, platform decomposition diagram menggambarkan platform teknologi yang mendukung operasional arsitektur sistem informasi. Diagram ini mencakup semua aspek platform infrastruktur dan menyediakan gambaran platform teknologi pada organisasi. 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.

2.5.11 Matriks Analisis Gap

Menurut The Open Group, 2009 matrik ini menunjukan suatu ruang lingkup dari sebuah paket pekerjaan yang harus diimplementasikan sebagai bagian dari transformasi Road Map yang lebih luas dengan penggambaran baseline architecture yang ada pada saat ini dan pergambaran target arsitektur target. Premis dasar adalah untuk menyoroti kekurangan antara Arsitektur Dasar dan Arsitektur Sasaran, yaitu item yang telah sengaja dihilangkan, sengaja ditinggalkan, atau belum ditetapkan. Sebuah langkah penting dalam mengevaluasi arsitektur adalah untuk mempertimbangkan apa yang mungkin telah dilupakan. Arsitektur harus mendukung semua kebutuhan pengolahan informasi penting dari organisasi. Sumber yang paling penting dari gaps yang harus dipertimbangkan adalah kekhawatiran stakeholder yang belum dibahas dalam karya arsitektur sebelumnya.

2.6 Metode Pengembangan Sistem

Rapid Application Development RAD Metodologi pengembangan sistem adalah suatu aktivitas, metode, praktik terbaik dan peralatan terotomatisasi yang digunakan para stakeholder untuk mengembangkan dan secara berkesinambungan memperbaiki sistem informasi dan perangkat lunak Whitten et al, 2006. Pengembangan sistem informasi merupakan penyusunan suatu sistem untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang telah ada. 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 pengembangan sistem secara tradisional dan dengan menggunakan Rapid Application Development RAD. Gambar 2.9 Fase Rapid Application Development RAD

2.6.1 Perencanaan Syarat Requirement Planning

Pada tahap ini, user dan analis melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masing – masing user dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief Information Office CIO atau bagian perencana strategis terutama untuk mengembangkan suatu aplikasi untuk mendapatkan informasi yang lebih detail akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development.

2.6.2 Proses Desain Design Workshop

Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan – perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa melihat satu dengan yang lain tanpa ada halangan. Apabila memungkinkan, maka masing-masing user diberikan satu komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision Support System GDSS. Pada beberapa kasus, GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikan- perbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.

2.6.3 Implementasi Implementation

Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru.

2.7 Penelitian Sejenis

1. “Perencanaan Strategis Sistem informasiTeknologi Informasi

Menggunakan Kerangka The Open Architecture framework TOGAF Studi Kasus: Pemda kabupaten Sumba Barat”. Skripsi ini disusun oleh Raimond Lukito Widiatmo pada tahun 2012. Tujuan pembuatan skripsi ini adalah untuk menyusun enterprise Architecture pada Pemda Kabupaten Sumba Barat agar tata kelola dan administrasi berjalan dengan efektif dan efisien. Kekurangan pada skripsi ini adalah penulis hanya menggunakan 4 phase dalam penelitiannya. 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.

3. Menggunakan TOGAF

Architecture Development method Pada PT. Satya Karya Utama”. Skripsi ini disusun oleh Vivi Fyandiani Pratiwi pada tahun 2013 dengan tujuan memberikan usulan enterprise architecture agar proses bisnis pada PT. Satya Utama yang bergerak dalam bidang property, design interior, furniture dan jasa konsultan dapat berjalan dengan efektif dan efisien. Adapun kelebihan pada penelitian ini adalah tingkat analisis yang dinilai sangat detail. Dimulai dari pendahuluan sampai arsitektur teknologi, sehingga memudahkan para stakeholder untuk memahami rancangan arsitektur TI tersebut. Kekurangan pada skripsi ini adalah tidak adanya relasi antara entitas data-data yang akan digunakan sehingga menyulitkan pekembangan lebih lanjut yang terkait dengan hubungan data-data. i

BAB III METODOLOGI PENELITIAN

3.1 Metode Pengumpulan Data

Pembuatan penelitian ini dilakukan menggunakan beberapa metode yang dapat membantu penulis baik dalam hal pengumpulan data maupun informasi yang diperlukan untuk mendapatkan kebenaran materi uraian pembahasan. Oleh karena itu, riset atau penelitian dilakukan guna mendapatkan data dan referensi yang diperlukan. Teknik pengumpulan data ini dilakukan agar data-data yang dibutuhkan dalam penelitian ini dapat terpenuhi dan supaya tercapainya tujuan penelitian. Teknik pengumpulan data yang dipilih tergantung pada faktor utama dan jenis data. Berikut merupakan metode dari pengumpulan data yang dilakukan untuk mendapatkan data dan referensi yang dibutuhkan.

3.1.1 Metode Observasi

Menurut Jogiyanto, 2008 , “Observasi observation merupakan teknik atau pendekatan untuk mendapatkan data primer dengan cara mengamati langsung obyek datanya”. Pengamatan ini dilakukan dengan melihat langsung proses dan kegiatan bisnis yang berjalan pada studi kasus Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Observasi dilakukan pada bulan Agustus 2014 yang bertempat di Jl. Raya Puspiptek, Setu, Ruko Boulevard No.A1 A2 76