Bab II Tinjauan Pustaka II.1 Definisi Enterprise Architecture (EA) Sebelum membahas EA, harus terlebih dahulu diketahui pengertian atau definisi tentang enterprise dan arsitektur. Definisi enterprise dalam konteks ini adalah koleksi organisasi yang mempunyai sekumpulan sasaran umum dan/atau satu tujuan. Suatu enterprise dapat berupa lembaga pemerintah, perusahaan keseluruhan, suatu divisi korporasi, satu departemen, atau satu rantai organisasi yang secara geografis terpisah, dihubungkan oleh kepemilikan perusahaan yang sama. Istilah enterprise dalam konteks enterprise architecture dapat digunakan untuk menunjukkan enterprise secara keseluruhan, meliputi seluruh sistem informasinya, dan suatu domain yang spesifik dalam organisasi (20). Saat ini belum ada definisi yang tepat tentang arsitektur atau deskripsi arsitektur yang berhubungan dengan enterprise, sistem, atau perangkat keras. The Institute of Electrical and Electronics Engineers (IEEE), Departemen Pertahanan Amerika Serikat (DoD), dan berbagai otoritas bisnis dan teknologi, pada umumnya setuju bahwa arsitektur adalah tentang struktur berbagai hal penting (sistem atau enterprise), komponen-komponennya, dan bagaimana komponen-komponen tersebut cocok dan dapat bekerja sama untuk memenuhi tujuan organisasi (15). Definisi arsitektur yang digunakan dalam standar ANSI/IEEE Std 1471-2000 adalah: Suatu organisasi fundamental dari suatu sistem, melekat dalam komponen-komponennya, hubungan satu dengan yang lain dan lingkungannya, serta pengaturan prinsip desain dan evolusinya. Beberapa definisi EA yang terkenal (15): a. EA adalah tentang pemahaman semua elemen yang berbeda yang membentuk enterprise dan bagaimana elemen-elemen tersebut saling berhubungan (The Open Group). b. EA adalah dasar aset informasi strategis, yang mendefinisikan misi bisnis, informasi dan teknologi yang diperlukan untuk melaksanakan misi, dan proses
transisi untuk mengimplementasikan teknologi baru dalam menjawab perubahan kebutuhan misi (USA Federal CIO Council). c. EA adalah ekspresi secara menyeluruh bisnis kunci, strategi informasi, aplikasi, dan teknologi organisasi, dan dampaknya terhadap proses dan fungsi bisnis. Pendekatannya memperhatikan proses bisnis, struktur organisasi, dan tipe teknologi yang digunakan untuk menjalankan proses bisnis ini (Meta Group Inc.). d. EA adalah logika pengorganisasian untuk proses bisnis dan infrastruktur TI, merefleksikan integrasi dan kebutuhan standardisasi model operasi organisasi. EA memberikan suatu pandangan jangka panjang tentang proses, sistem, dan teknologi organisasi sedemikian rupa sehingga proyek masing-masing dapat membangun kemampuan tidak hanya memenuhi kebutuhan segera (Jeanne W. Ross dkk., 2004). Dalam penelitian ini, definisi EA yang digunakan adalah sebagai berikut: EA adalah logika pengorganisasian dan penggambaran struktur elemen-elemen arsitektur enterprise dan bagaimana hubungan antar elemen-elemen tersebut agar dapat bekerja sama untuk mencapai tujuan organisasi. II.2 Manfaat EA Berikut beberapa manfaat EA (2, 15, 18): Menyediakan suatu mekanisme yang memungkinkan komunikasi tentang elemen-elemen EA di antara organisasi bisnis dan TI dan berfungsinya enterprise Menghasilkan informasi yang terpusat, stabil, dan meningkatkan konsistensi, ketelitian, ketepatan waktu, integritas, kualitas, ketersediaan, akses, dan pembagian informasi yang dikelola lintas enterprise Informasi berkualitas dan tepat yang disediakan oleh EA mempermudah enterprise untuk menanggapi kekuatan perubahan dan membuat keputusan yang lebih baik. Memungkinkan organisasi untuk mengurangi duplikasi dalam informasi Menghubungkan TI kepada misi organisasi
Meningkatkan inter-operabilitas dan mempercepat integrasi sistem lama, migrasi dan sistem baru Memungkinkan ketangkasan Mengurangi biaya atau mencapai skala ekonomis dengan cara menyediakan mekanisme untuk berbagi layanan lintas enterprise Meningkatkan keamanan Mengurangi risiko teknis Fokus adalah pada strategi penggunaan teknologi untuk mengelola data sebagai aset II.3 Elemen-elemen EA secara Umum Menurut Dirk Maurer dan Patrick Buch (2007), EA muncul sebagai perangkat kunci untuk mendokumentasikan, menganalisis, dan mengelola struktur yang kompleks pada suatu enterprise, yang pada gilirannya membentuk bagian dari satu framework arsitektur yang menggambarkan informasi yang diperlukan untuk satu arsitektur lengkap. Elemen-elemen EA secara umum, menurut Maurer dan Buch, terdiri atas empat deskripsi arsitektur yang berbeda, yaitu: 1. Arsitektur bisnis: mendefinisikan strategi bisnis dan menggambarkan struktur serta proses bisnis organisasi. 2. Arsitektur aplikasi: menggambarkan layanan dan sistem aplikasi yang mendukung proses bisnis. 3. Arsitektur informasi: menggambarkan sasaran bisnis dan pertukaran data di antara para peserta proses dan aplikasi. 4. Level paling rendah adalah arsitektur infrastruktur, yang digunakan untuk menggambarkan 'landscape' fisik perangkat keras dan jaringan yang mendukung sistem aplikasi.
Gambar II.1 Elemen-elemen Enterprise Architecture (Sumber: Dirk Maurer dan Patrick Buch, 2007) II.4 Memilih Framework EA Framework EA adalah suatu model komunikasi untuk mengembangkan EA. Framework ini menampilkan kumpulan model, prinsip, pendekatan, standar, konsep perancangan, komponen, visualisasi, dan konfigurasi yang memandu pengembangan aspek spesifik arsitektur. Framework dapat memandu pemikiran arsitektur yang lebih luas daripada hanya apa yang dapat disampaikan dalam blok diagram. Framework biasanya mengadopsi definisi arsitektur yang serupa tetapi berbeda dalam fokus, lingkup, dan tujuannya (15). Ada beberapa framework EA yang terkenal di antaranya adalah Zachman Framework, Federal Enterprise Architecture Framework (FEAF), dan The Open Group Architecture Framework (TOGAF). Karakteristik dari ketiga framework tersebut dijabarkan dalam lampiran A. Dari beberapa framework EA yang ada, TOGAF digunakan karena ada beberapa keistimewaan yaitu: Fase-fase dalam pengembangan arsitektur [(Architecture Development Methode (ADM)] dilakukan secara berurutan Bersifat open
Menyediakan kumpulan sumberdaya termasuk panduan, template, informasi latar belakang untuk membantu arsitek dalam penggunaan ADM. Menggunakan framework EA bermanfaat untuk mempercepat dan memudahkan pengembangan arsitektur, menjamin cakupan solusi rancangan lebih lengkap, dan memastikan bahwa arsitektur yang dipilih memungkinkan pertumbuhan masa depan dalam menanggapi kebutuhan bisnis. II.5 The Open Group Architecture Framework (TOGAF) TOGAF mengadopsi pengertian arsitektur pada terminologi ANSI/IEEE Std 1471-2000. Menurut TOGAF, arsitektur memiliki dua pengertian tergantung pada pemakaian konstektualnya: 1. Deskripsi formal suatu sistem, atau suatu rencana detil dari sistem pada level komponen untuk memandu implementasinya 2. Struktur komponen-komponen, saling keterhubungannya, prinsip-prinsip dan panduan-panduan yang mengatur desain dan evolusinya dari waktu ke waktu. TOGAF adalah suatu framework atau suatu metoda yang rinci dan suatu kumpulan tools pendukung untuk mengembangkan enterprise architecture. Dikembangkan oleh Open Group pada tahun 1995, framework arsitektur ini berdasarkan pada Technical Architecture Framework for Information Management (TAFIM) yang dikembangkan oleh Departemen Pertahanan Amerika Serikat (DoD). II.5.1 Elemen-elemen EA Menurut TOGAF Menurut TOGAF, ada empat tipe arsitektur yang secara umum diterima sebagai bagian dari keseluruhan enterprise architecture, yaitu: Arsitektur bisnis (proses bisnis) menggambarkan struktur organisasi, proses bisnis, aktifitas bisnis dan hubungan para aktor yang terlibat dalam proses bisnis.
Arsitektur data menggambarkan struktur aset data organisasi secara logik dan fisik serta sumberdaya manajemen data. Arsitektur aplikasi suatu bentuk arsitektur yang menyediakan cetak biru sistem aplikasi individual untuk didistribusikan, interaksi dan hubungannya dengan proses bisnis utama organisasi. Arsitektur teknologi menggambarkan kapabilitas perangkat keras dan perangkat lunak secara logik yang dibutuhkan untuk mendukung penyebaran bisnis, data, dan layanan aplikasi. Hal ini termasuk infrastruktur TI, jaringan, komunikasi, proses, standar, dan sebagainya. Elemen-elemen EA menurut TOGAF inilah yang dipakai dalam melakukan penelitian dan perancangan EA Direktorat Jenderal Perbendaharaan. II.5.2 TOGAF Architecture Development Method (ADM) TOGAF ADM menggambarkan suatu metoda untuk mengembangkan EA, dan merupakan kunci atau inti TOGAF. ADM adalah metoda generik untuk pengembangan arsitektur yang berhubungan dengan kebanyakan kebutuhan sistem dan organisasi. Akan tetapi, seringkali perlu memodifikasi atau mengembangkan ADM untuk menyesuaikan kebutuhan-kebutuhan yang spesifik. ADM terdiri atas sembilan fase. Setiap fase menggambarkan kumpulan aktifitas yang memungkinkan sponsor dan para stakeholder mencapai keputusan dalam EA. Tim bisnis dan TI bekerja sama, dari fase ke fase, untuk membuat dan mengelola EA sepanjang siklus ADM (4). ADM bersifat iteratif, dinamis, dan berkelanjutan. Output dari fase sebelumnya menjadi input pada fase selanjutnya. Hal ini dikelola dengan fase Requirements Management. EA adalah aset organisasi yang harus dikelola sebagai program formal. EA dikembangkan oleh suatu tim yang bertanggung jawab kepada dewan arsitektur. Tim arsitektur ini juga bertanggung jawab atas perawatan, pengendalian, dan pengawasan program EA.
Gambar II.2 Siklus Pengembangan Arsitektur ADM mendefinisikan urutan yang direkomendasikan untuk berbagai fase dan langkah dalam pengembangan arsitektur, tetapi tidak merekomendasikan lingkup yang harus ditetapkan oleh organisasi yang bersangkutan. Langkah-langkah untuk mengembangkan arsitektur yang terdapat dalam ADM: 1. Preliminary Phase: Frameworks and Principles (Scoping and identifying resources)
Dimulai dengan preliminary phase, membuat lingkup enterprise dan mengidentifikasi sumber daya yang dibutuhkan untuk membuat dan menghasilkan EA. Pada tahap ini orang-orang tertentu, proses, perangkat dan tata kelola dialokasikan kepada pekerjaan pengembangan EA. Satu dari keputusan kunci adalah fokus/cakupan pada upaya arsitektur, dalam kaitan luasnya enterprise yang diliput, seperti sektor bisnis, unit bisnis/organisasi yang spesifik. Faktor penting dalam konteks ini adalah meningkatnya kecenderungan untuk pengembangan arsitektur besar-besaran dilakukan dalam bentuk federated architecture yang dengan bebas mengembangkan, merawat, dan mengelola arsitektur yang kemudian diintegrasikan dalam satu framework meta-architecture. Framework seperti itu menetapkan prinsip-prinsip untuk interoperabilitas, migrasi, dan penyesuaian. Hal ini memungkinkan unit bisnis tertentu untuk mempunyai arsitektur yang dikembangkan dan dikelola sebagai proyek arsitektur yang berdiri sendiri. Fase ini adalah tentang menetapkan bagaimana melakukan arsitektur terkait dengan enterprise. Ada dua aspek utama yaitu menetapkan framework yang digunakan dan menetapkan prinsip arsitektur yang akan menginformasikan pekerjaan arsitektur. Pendekatan enterprise untuk menggunakan kembali asetaset arsitektur adalah bagian kunci dari definisi framework dan prinsip arsitektur. Pada umumnya prinsip akan menyatakan kebijakan penggunaan kembali; dan framework akan menjelaskan bagaimana penggunaan kembali itu efektif. Fase ini menetapkan prinsip arsitektur yang akan membentuk bagian pembatas pada pekerjaan arsitektur yang dilakukan. Input pada fase ini adalah: TOGAF ADM Framework arsitektur yang lain, jika diperlukan Strategi bisnis, prinsip bisnis, tujuan bisnis, dan driver bisnis, jika sudah ada
Strategi tata kelola TI, jika sudah ada Prinsip arsitektur, jika sudah ada Prinsip yang dipakai, datang dari arsitektur yang lain Langkah-langkah pada fase ini: TOGAF ADM adalah satu metoda umum, dimaksudkan untuk digunakan oleh berbagai macam enterprise berbeda, dan bersama dengan berbagai macam framework arsitektur lain, jika diperlukan. Output: Definisi framework Prinsip arsitektur Uraian baru, atau referensi kepada prinsip bisnis, tujuan bisnis, dan driver bisnis 2. Phase A: Architecture Vision (Envisioning the future state) Langkah penting selanjutnya adalah membuat visi EA masa depan. Untuk itu, digunakan skenario bisnis untuk meninjau visi, strategi dan pendorong bisnis lalu dihasilkan kumpulan kebutuhan bisnis untuk enterprise masa depan. Secara normal, elemen kunci dari visi arsitektur, seperti visi, misi, strategi dan tujuan, didokumentasikan sebagai bagian dari strategi bisnis atau aktifitas rencana enterprise yang mempunyai siklusnya sendiri. Aktifitas dalam fase A berhubungan dengan verifikasi dan pemahaman strategi dan tujuan bisnis yang didokumentasikan, menetapkan lingkup arsitektur, bagaimana membuat visi dan memperoleh persetujuan. Visi arsitektur meliputi deskripsi tingkat-tinggi lingkungan saat ini dan target dari perspektif bisnis dan teknik. Input: Permintaan untuk pekerjaan arsitektur Strategi bisnis, tujuan bisnis, dan driver bisnis
Prinsip arsitektur, termasuk prinsip bisnis, jika sebelumnya sudah ada Enterprise continuum, dokumentasi arsitektur saat ini (deskripsi framework, arsitektur, baseline, dan sebagainya) Langkah-langkah: Menetapkan proyek Melakukan prosedur yang perlu untuk mengamankan proyek enterprise keseluruhan, pengesahan manajemen perusahaan, dan dukungan serta komitmen yang diperlukan manajemen lini. Meliputi referensi kepada framework tata kelola TI untuk enterprise, menjelaskan bagaimana proyek ini berhubungan dengan framework. Identifikasi tujuan dan driver bisnis Jika hal ini telah didefinisikan dalam enterprise, pastikan bahwa definisi yang ada jelas. Jika tidak, kembali kepada awal pernyataan pekerjaan arsitektur dan definisikan hal-hal yang penting sejak awal dan pastikan pengesahannya oleh manajemen organisasi. Review prinsip arsitektur, termasuk prinsip bisnis Review prinsip pada kondisi di mana arsitektur baseline akan dikembangkan. Prinsip arsitektur secara normal berdasarkan pada prinsip bisnis yang dikembangkan sebagai bagian dari fase Preliminary. Menetapkan lingkup Tetapkan apa yang ada di dalam dan di luar lingkup upaya arsitektur bisnis. Masalah-masalah yang terlibat dalam lingkup arsitektur, secara khusus menggambarkan: o Luas cakupan enterprise o Level detil yang ditetapkan o Domain arsitektur spesifik yang diliput (bisnis, data, aplikasi, teknologi) o Tingkat masa datang yang dituju o Aset arsitektur yang akan diungkit, atau dipertimbangkan untuk digunakan, dari Enterprise Continuum organisasi:
Aset yang diciptakan dalam iterasi sebelum siklus ADM dalam enterprise Aset yang tersedia di tempat lain dalam industri (framework lain, model sistem, model industri vertikal, dan sebagainya) Menetapkan batasan Menetapkan batasan yang harus berhubungan dengan batasan enterprise keseluruhan dan proyek yang spesifik (waktu, jadwal, sumberdaya). Batasan enterprise keseluruhan akan diinformasikan oleh prinsip arsitektur dan bisnis yang dikembangkan dalam fase preliminary atau dijelaskan sebagai bagian dari fase A. Identifikasi stakeholder, kebutuhan bisnis dan visi arsitektur Mengidentifikasi stakeholder dan sasaran mereka, kebutuhan bisnis kunci yang dituju dalam upaya arsitektur, dan mengartikulasikan visi arsitektur Mengembangkan pernyataan pekerjaan arsitektur dan mengamankan persetujuan Berbasis pada tujuan, fokus, lingkup, dan batasan, menentukan domain arsitektur yang harus dikembangkan, tingkat detil, dan pandangan arsitektur yang harus dibangun. Memperkirakan sumber-sumber daya yang diperlukan, mengembangkan satu roadmap dan membuat jadwal pengembangan yang diusulkan, dan mendokumentasikannya dalam pernyataan pekerjaan arsitektur. Mengamankan persetujuan formal pernyataan pekerjaan arsitektur dalam prosedur-prosedur tata kelola yang sesuai. Output: Pernyataan pekerjaan arsitektur yang disetujui, termasuk: o Lingkup dan batasan o Rencana untuk pekerjaan arsitektur Pernyataan tujuan bisnis dan driver strategi yang diperbaiki Prinsip arsitektur, termasuk prinsip bisnis Visi arsitektur, termasuk: o Arsitektur bisnis baseline versi 0.1
o Arsitektur teknologi baseline versi 0.1 o Arsitektur data baseline versi 0.1 o Arsitektur aplikasi baseline versi 0.1 o Arsitektur bisnis target versi 0.1 o Arsitektur teknologi target versi 0.1 o Arsitektur data target versi 0.1 o Arsitektur aplikasi target versi 0.1 3. Phase B: Business Architecture Pengetahuan tentang arsitektur bisnis adalah prasyarat untuk pekerjaan arsitektur dalam domain lainnya yaitu data, aplikasi, dan teknologi. Fase ini membuat arsitektur bisnis yang meliputi proses bisnis, layanan, fungsi, organisasi dan strategi. Input: Output pada fase A Permintaan untuk pekerjaan arsitektur Enterprise continuum Langkah-langkah: Tingkat detil dalam fase ini akan tergantung kepada lingkup dan tujuan upaya arsitektur keseluruhan. Langkah-langkah kunci dalam fase B adalah sebagai berikut: Mengembangkan deskripsi arsitektur bisnis baseline Mengidentifikasi model, sudut pandang, dan tool acuan Membuat model arsitektur Memilih blok bangunan (building block) arsitektur bisnis Melakukan review model arsitektur Me-review kriteria non-fungsional (kualitatif) Melengkapi arsitektur bisnis Melakukan analisis celah (gap) dan membuat laporan
Output: Pernyataan pekerjaan arsitektur, diperbaharui jika perlu Prinsip bisnis yang divalidasi, tujuan bisnis, dan driver strategi Arsitektur bisnis target versi 1.0 (dirinci), termasuk: o struktur organisasi identifikasi lokasi bisnis dan menghubungkannya dengan unit organisasi o tujuan dan sasaran bisnis o fungsi bisnis o layanan bisnis o proses bisnis o peran bisnis o model data bisnis o hubungan organisasi dan fungsi Arsitektur bisnis baseline versi 1.0 (dirinci), jika sesuai Pandangan yang bersesuaian dengan sudut pandang perhatian stakeholder kunci Hasil analisis gap Kebutuhan teknis mengidentifikasi, menggolongkan, dan memprioritaskan implikasi untuk pekerjaan domain arsitektur lainnya Laporan arsitektur bisnis Kebutuhan bisnis yang diperbaharui 4. Phase C: Information System Architecture Fase ini membuat arsitektur sistem informasi yang mendukung arsitektur bisnis. Arsitektur sistem informasi disusun dari arsitektur data dan aplikasi. Arsitektur data: Sasaran pada fase ini adalah untuk menetapkan tipe utama dan sumber data yang penting untuk mendukung bisnis yang dapat dimengerti oleh stakeholder, lengkap dan konsisten, serta stabil. Penting untuk dicatat bahwa usaha ini tidak berhubungan dengan rancangan database. Tujuannya adalah
mendefinisikan entitas data yang berhubungan dengan enterprise, bukan untuk merancang sistem logik atau penyimpanan fisik. Input: Prinsip data, jika ada Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Visi arsitektur Kebutuhan teknis yang relevan akan berlaku pada fase C Hasil analisis gap (dari arsitektur bisnis) Arsitektur bisnis baseline, versi 1.0 (dirinci), jika sesuai Arsitektur bisnis target, versi 1.0 (dirinci) Arsitektur data baseline, Versi 0.1, jika tersedia Arsitektur data target, versi 0.1, jika tersedia Building blocks yang dapat digunakan kembali, dari enterprise continuum organisasi, jika tersedia Langkah-langkah: Mengembangkan deskripsi arsitektur data baseline Me-review dan memvalidasi prinsip, model referensi, sudut pandang, dan tool Membuat model arsitektur Memilih building block arsitektur data Melakukan review cek formal model arsitektur dan building block dengan stakeholder Me-review kriteria kualitatif Melengkapi arsitektur data Melakukan cek/analisis dampak Melakukan analisis gap dan membuat laporan Output: Pernyataan pekerjaan arsitektur, diperbaharui jika perlu
Arsitektur data baseline versi 1.0, jika sesuai Prinsip data yang divalidasi, atau prinsip data baru (jika dihasilkan di sini) Arsitektur data target versi 1.0 Sudut pandang perhatian stakeholder kunci Pandangan yang berhubungan dengan sudut pandang yang dipilih Hasil analisis gap Kebutuhan teknis yang relevan akan berlaku dalam evolusi siklus pengembangan arsitektur Laporan arsitektur data Analisis dampak Kebutuhan bisnis diperbaharui, jika sesuai Fase untuk membuat arsitektur aplikasi Sasaran dalam fase ini adalah menetapkan/mendefinisikan berbagai jenis sistem aplikasi utama yang diperlukan untuk memproses data dan mendukung bisnis. Penting untuk dicatat bahwa ini tidak berhubungan dengan rancangan sistem aplikasi. Tujuannya adalah mendefinisikan jenis sistem aplikasi yang relevan dengan enterprise dan aplikasi apa yang dibutuhkan untuk mengelola data dan menghasilkan informasi bagi pengguna di enterprise. Aplikasi tidak digambarkan sebagai sistem komputer, tetapi sebagai kumpulan kapabilitas logik yang mengelola objek data dalam arsitektur data dan mendukung fungsi bisnis dalam arsitektur bisnis. Aplikasi dan kapabilitasnya ditetapkan tanpa referensi teknologi tertentu. Aplikasi adalah stabil dan relatif tidak berubah, sedangkan teknologi yang digunakan untuk mengimplementasikannya akan berubah dari waktu ke waktu, berdasarkan pada teknologi yang ada saat ini dan perubahan kebutuhan bisnis. Input: Prinsip aplikasi, jika ada Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Visi arsitektur
Kebutuhan teknis yang relevan akan berlaku pada fase C Hasil analisis gap (dari arsitektur bisnis) Arsitektur bisnis baseline, versi 1.0 (dirinci), jika sesuai Arsitektur bisnis target, versi 1.0 (dirinci) Arsitektur aplikasi baseline, versi 0.1, jika sesuai dan tersedia Arsitektur aplikasi target, versi 0.1, jika tersedia Building blocks yang dapat digunakan kembali, dari enterprise continuum organisasi, jika tersedia Langkah-langkah: Mengembangkan deskripsi arsitektur aplikasi baseline Me-review dan memvalidasi prinsip, model referensi, sudut pandang, dan tool Membuat model arsitektur Mengidentifikasi kandidat sistem aplikasi Melakukan review cek formal model arsitektur dan building block dengan stakeholder Me-review kriteria kualitatif Melengkapi arsitektur aplikasi Melakukan analisis gap dan membuat laporan Output: Pernyataan pekerjaan arsitektur, diperbaharui jika perlu Arsitektur aplikasi baseline versi 1.0, jika sesuai Prinsip aplikasi yang divalidasi, atau prinsip aplikasi baru (jika dihasilkan di sini) Arsitektur aplikasi target versi 1.0 Sudut pandang perhatian stakeholder kunci Pandangan yang berhubungan dengan sudut pandang yang dipilih Hasil analisis gap Laporan arsitektur aplikasi Analisis dampak
Kebutuhan bisnis diperbaharui, jika sesuai 5. Phase D: Technology Architecture Fase ini membuat arsitektur teknologi yang membentuk fondasi target infrastruktur TI. Input: Prinsip teknologi, jika ada Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Visi arsitektur Arsitektur teknologi baseline, versi 0.1, jika sesuai dan tersedia (dari fase A) Arsitektur teknologi target, versi 0.1, jika tersedia (dari fase A) Kebutuhan teknis yang relevan dari fase sebelumnya Hasil analisis gap (dari arsitektur data) Hasil analisis gap (dari arsitektur aplikasi) Arsitektur bisnis baseline, versi 1.0 (dirinci), jika sesuai Arsitektur data baseline, versi 1.0, jika sesuai Arsitektur aplikasi baseline, versi 1.0, jika sesuai Arsitektur bisnis target, versi 1.0 (dirinci) Arsitektur data target, versi 1.0 Arsitektur aplikasi target, versi 1.0 Building blocks yang dapat digunakan kembali, dari enterprise continuum organisasi, jika tersedia Langkah-langkah: Mengembangkan deskripsi arsitektur teknologi baseline Mengembangkan arsitektur teknologi target Output: Pernyataan pekerjaan arsitektur, diperbaharui jika perlu
Arsitektur teknologi baseline versi 1.0, jika sesuai Prinsip teknologi yang divalidasi, atau prinsip teknologi baru (jika dihasilkan di sini) Laporan arsitektur teknologi Arsitektur teknologi target versi 1.0 Arsitektur teknologi, laporan analisis gap Sudut pandang perhatian stakeholder kunci Pandangan yang berhubungan dengan sudut pandang yang dipilih Phase B,C, dan D: Developing architecture spesifications Fase B, C, dan D berkonsentrasi pada pengembangan spesifikasi arsitektur secara individual yang membentuk arsitektur enterprise keseluruhan. Fasefase ini membuat pandangan EA yang berbeda dari area kepentingan stakeholder masing-masing. 6. Phase E: Opportunities and Solutions Fase E mengidentifikasi parameter perubahan, fase utama sepanjang tahapan, dan proyek level puncak dilakukan dalam perpindahan dari lingkungan saat ini ke lingkungan target. Keluaran dari fase E akan membentuk dasar rencana implementasi yang dibutuhkan. Fase ini juga berusaha untuk mengidentifikasi kesempatan bisnis baru yang muncul dari pekerjaan arsitektur dalam fase sebelumnya. Input: Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Arsitektur bisnis target, versi 1.0 Arsitektur data target, versi 1.0 Arsitektur aplikasi target, versi 1.0 Arsitektur teknologi target, versi 1.0 Building blocks yang dapat digunakan kembali, dari enterprise continuum organisasi, jika tersedia
Informasi produk Langkah-langkah: Mengidentifikasi driver bisnis kunci yang menghambat urutan implementasi Me-review analisis gap dari fase D Brainstorm kebutuhan teknis dari perspektif fungsional Brainstorm co-existence dan kebutuhan interoperabilitas Melakukan penilaian arsitektur dan analisis gap Mengidentifikasi paket pekerjaan atau proyek utama Klasifikasikan hal tersebut di atas sebagai pengembangan baru, kesempatan pembelian, atau penggunaan kembali sistem yang ada. Output: Strategi implementasi dan migrasi Rencana implementasi tingkat tinggi Analisis dampak daftar proyek 7. Phase F: Migration Planning Sasaran fase F adalah memilah berbagai proyek implementasi dalam urutan prioritas. Aktifitasnya meliputi penilaian ketergantungan, biaya, dan manfaat dari berbagai proyek migrasi. Daftar prioritas proyek akan terus membentuk basis rencana implementasi dan migrasi yang detil. Input: Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Arsitektur bisnis target, versi 1.0 Arsitektur data target, versi 1.0 Arsitektur aplikasi target, versi 1.0 Arsitektur teknologi target, versi 1.0 Analisis dampak daftar proyek
Langkah-langkah: Memprioritaskan proyek Memperkirakan kebutuhan dan ketersediaan sumberdaya Melakukan penilaian biaya/manfaat dari berbagai proyek migrasi Melakukan penilaian risiko Membuat roadmap implementasi Mendokumentasikan rencana migrasi Output: Analisis dampak: rencana implementasi dan migrasi dirinci (termasuk kontrak implementasi arsitektur, jika sesuai) Phase E and F: Developing and planning solutions Fase E dan F berkaitan dengan penentuan arsitektur solusi spesifik dan implementasi rencana untuk migrasi dari keadaan arsitektur saat ini ke keadaan yang baru. Semua keputusan pengadaan rencana pengembangan dibuat selama dalam fase ini. 8. Phase G: Implementation Governance (managing deployment and realising value) Implementasi tata kelola berada dalam fase G dan memberikan kerangka tata kelola arsitektur untuk pengembangan solusi dan implementasi. Fase ini memastikan bahwa pekerjaan pengembangan harus konsisten dengan spesifikasi arsitektur dan menghasilkan kebutuhan sponsor dan para stakeholder. Input: Permintaan untuk pekerjaan arsitektur Pernyataan pekerjaan arsitektur Building blocks yang dapat digunakan kembali, dari enterprise continuum organisasi, jika tersedia
Analisis dampak: rencana implementasi dan migrasi dirinci (termasuk kontrak implementasi arsitektur, jika sesuai) Langkah-langkah: Memformulasikan rekomendasi proyek Mendokumentasikan kontrak arsitektur Me-review tata kelola implementasi dan pemenuhan arsitektur yang berkelanjutan Output: Analisis dampak rekomendasi implementasi Kontrak arsitektur Sistem implementasi pemenuhan-arsitektur 9. Phase H: Architecture Change Management (Managing change) EA ditetapkan untuk beberapa tahun, tetapi harus juga diperbaharui agar dapat menyesuaikan perubahan kebutuhan bisnis. Perubahan-perubahan itu bisa saja diperlukan karena: Permintaan manajemen aset dan perbaikan infrastruktur; Peningkatan proses bisnis; Reorganisasi; Perubahan pasar dan kapasitas bisnis; Merger dan akuisisi. Manajemen perubahan arsitektur, fase terakhir, memungkinkan perubahan seperti yang disebutkan di atas baik melalui pengembangan maupun siklus operasional EA. Input: Permintaan untuk perubahan arsitektur karena perubahan teknologi Permintaan untuk perubahan arsitektur karena perubahan bisnis
Langkah-langkah: Memonitor perubahan teknologi Memonitor perubahan bisnis Menilai perubahan dan pengembangan posisi untuk bertindak Mengatur pertemuan Dewan Arsitektur (atau dewan tata kelola yang lain) Tujuan pertemuan ini adalah untuk memutuskan penanganan perubahan (teknologi dan bisnis). Output: Pembaharuan arsitektur Perubahan pada framework dan prinsip arsitektur Permintaan baru pekerjaan arsitektur, untuk berpindah ke siklus yang lain 10. Requirements Management Phase EA dibuat dari permintaan stakeholder, dikelola di sepanjang metoda ini dengan proses manajemen kebutuhan. Input pada proses manajemen kebutuhan adalah output yang berhubungan dengan kebutuhan dari tiap fase ADM. Kebutuhan tingkat tinggi pertama adalah yang diartikulasikan sebagai bagian dari visi arsitektur, dihasilkan dengan memakai skenario bisnis atau teknik yang dapat disamakan. Setiap domain arsitektur menghasilkan kebutuhan rancangan detil yang dikhususkan untuk domain tersebut dan berpotensi kepada domain lain. Langkah-langkah: Kebutuhan baseline Memonitor kebutuhan baseline Mengidentifikasi kebutuhan yang berubah dan prioritas yang dicatat Output: Pernyataan kebutuhan yang terstruktur, termasuk: Kebutuhan yang berubah
Pernyataan dampak kebutuhan II.6 Pemodelan Arsitektur Bahasa pemodelan adalah satu instrumen penting untuk deskripsi dan komunikasi arsitektur. Bahasa pemodelan dan tool bersama-sama mengembangkan deskripsi arsitektur. TOGAF merekomendasikan penggunaan Unified Modeling Language (UML) untuk memodelkan arsitektur. UML adalah bahasa standar untuk menetapkan, memvisualisasikan, membangun, dan mendokumentasikan artifak sistem perangkat lunak dan sistem non-perangkat lunak, seperti memodelkan proses bisnis dan data. UML adalah standar Object Management Group (OMG) yang menyediakan notasi pemodelan visual yang memiliki nilai untuk merancang dan memahami sistem yang kompleks. UML memiliki beberapa keuntungan umum yaitu: dikenal secara luas sebagai notasi pemodelan berorientasi objek, mempunyai notasi grafis yang dapat dipahami, dan kaya akan semantik untuk mengambil fitur kunci dari sistem berorientasi objek. Use-case model dapat menggambarkan proses bisnis atau fungsi sistem, tergantung pada fokus pemodelan. Model use-case menggambarkan proses bisnis dalam terminologi use-case dan aktor yang berhubungan dengan proses bisnis dan partisipan organisasi (orang, organisasi, dsb.). Use-case model digambarkan dalam use-case diagram. Use case diagram digunakan untuk memodelkan kebutuhan untuk sistem. Use case adalah deskripsi fungsionalitas sistem dari perspektif user. Activity model (yang juga disebut Business Process Model) menggambarkan fungsi yang diasosiasikan dengan aktifitas bisnis enterprise, pertukaran data dan/atau informasi di antara aktifitas (pertukaran internal), dan data dan/atau informasi yang dipertukarkan dengan aktifitas yang berada di luar lingkup model (pertukaran eksternal). Activity model digambarkan dalam activity diagram. Class model serupa dengan model data logik. Class model menggambarkan informasi statis dan hubungan di antara informasi. Class model
dapat merepresentasikan entitas domain bisnis. Class model digambarkan dengan class diagram.