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

aset 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


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

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

Documents

Transcript of Bab II Tinjauan Pustaka -...