Bab II Tinjauan Pustaka -...
Transcript of 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
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. 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:
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.