Bab II Tinjauan Pustaka

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:

9 Aset yang diciptakan dalam iterasi sebelum siklus ADM dalam enterprise 9 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


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


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


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:


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



Visi arsitektur

Kebutuhan teknis yang relevan akan berlaku pada fase C

Hasil analisis gap (dari arsitektur bisnis)



Arsitektur aplikasi baseline, versi 0.1, jika sesuai dan tersedia

Arsitektur aplikasi target, versi 0.1, jika tersedia


Langkah-langkah:

Mengembangkan deskripsi arsitektur aplikasi baseline

Me-review dan memvalidasi prinsip, model referensi, sudut pandang, dan tool


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:


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



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



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 data baseline, versi 1.0, jika sesuai

Arsitektur aplikasi baseline, versi 1.0, jika sesuai


Arsitektur data target, versi 1.0

Arsitektur aplikasi target, versi 1.0


Langkah-langkah:

Mengembangkan deskripsi arsitektur teknologi baseline

Mengembangkan arsitektur teknologi target

Output:


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



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:



Arsitektur bisnis target, versi 1.0



Arsitektur teknologi target, versi 1.0


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:



Arsitektur bisnis 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:




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.

Bab II Tinjauan Pustaka

Recommend Documents