Modul Arsitektur Enterprise

TOGAF 9.1

Deskripsi Singkat

Modul ini mendeskripsikan TOGAF sebagai sebuah kerangka kerja Arsitektur Enterprise yang
umum digunakan sebagai pedoman perancangan AE pada sebuah enterprise. TOGAF memiliki
method yang dinamakan ADM yang berisi siklus tahapan pengembangan AE. TOGAF 9.1
merupakan versi TOGAF yang dikeluarkan oleh The Open Group, dimana versi ini memiliki
6 bagian yang dapat menjadi pedoman dalam membangun AE.

Capaian Pembelajaran

1 Mahasiswa mampu mendeskripsikan tujuan dan tahapan (input, proses dan output) dari
setiap fase didalam TOGAF ADM.
2 Mahasiswa mampu menganalisa perbedaan dan persamaan dari Zachman Framework dan
TOGAF dalam proses merancang Arsitektur Enterprise (struktur organisasi, proses bisnis,
sistem aplikasi, infrastruktur teknologi).

Pendahuluan

TOGAF adalah alat untuk membantu dalam penerimaan, produksi, penggunaan, dan
pemeliharaan arsitektur perusahaan. Versi pertama TOGAF, yang dikembangkan pada 1995,
didasarkan pada Kerangka Kerja Arsitektur Teknis Departemen Pertahanan AS untuk
Manajemen Informasi (TAFIM). Kunci TOGAF adalah metode yaitu Architecture
Development Method (ADM) untuk mengembangkan arsitektur perusahaan yang memenuhi
kebutuhan bisnis.

Dalam TOGAF, "arsitektur" memiliki dua makna tergantung pada konteksnya:

1. Deskripsi formal suatu sistem, atau rencana terperinci sistem pada tingkat komponen
untuk memandu implementasinya.
2. Struktur komponen, inter-relasinya, dan prinsip serta pedoman yang mengatur desain
dan evolusinya dari waktu ke waktu.

1.1 Bagian TOGAF 9.1

Togaf 9.1 memiliki bagian-bagian berikut:

▪ TOGAF ADM
 ▪ ADM guidelines and techniques
▪ Architecture content framework
▪ Enterprise continumm and tools
▪ Togaf reference model
▪ Architecture capability framework

Istilah-istilah didalam Togaf 9.1

 Activity: Tugas atau kumpulan tugas yang mendukung fungsi organisasi; misalnya,
pengguna memasukkan data ke sistem TI atau bepergian untuk mengunjungi
pelanggan.

 Application: Sistem TI yang dikerahkan dan operasionalisasi Sistem TI yang

mendukung fungsi dan layanan bisnis; misalnya, daftar gaji. Aplikasi menggunakan
data dan didukung oleh beberapa komponen teknologi tetapi berbeda dari komponen
teknologi yang mendukung aplikasi.

 Application Architecture: Deskripsi pengelompokan logis utama dari kemampuan

yang mengelola objek data yang diperlukan untuk memproses data dan mendukung
bisnis.

 Building Block: Merupakan komponen (yang berpotensi dapat digunakan kembali)

dari kemampuan bisnis, TI, atau arsitektur yang dapat dikombinasikan dengan blok
bangunan lain untuk menghasilkan arsitektur dan solusi.

 Architecture Building Block (ABB): Sebuah konstituen dari model arsitektur yang
menggambarkan satu aspek dari keseluruhan model.

 Business Architecture: Strategi bisnis, tata kelola, organisasi, dan informasi proses
bisnis utama, serta interaksi antara konsep-konsep ini.

 Architecture Principles: Pernyataan niat kualitatif yang harus dipenuhi oleh

arsitektur. Memiliki setidaknya alasan yang mendukung dan ukuran kepentingan.

 Architecture Continuum: Bagian dari Enterprise Continuum. Tempat penyimpanan

elemen arsitektur dengan peningkatan detail dan spesialisasi. Continuum ini dimulai
dengan definisi dasar seperti model referensi, strategi inti, dan blok bangunan dasar.
Dari sana membentang hingga Arsitektur Industri dan sampai ke arsitektur spesifik
organisasi.

 Architecture Development Method (ADM): Inti dari TOGAF. Pendekatan langkah

demi langkah untuk mengembangkan dan menggunakan arsitektur perusahaan.

 Architecture Domain: Area arsitektur, ada empat domain arsitektur dalam TOGAF:
Bisnis, Data, Aplikasi, dan Teknologi.

 Architecture Framework: Struktur dasar, atau serangkaian struktur, yang dapat

digunakan untuk mengembangkan beragam arsitektur yang berbeda. Ini harus berisi
 metode untuk merancang sistem informasi dalam hal satu set blok bangunan, dan untuk
menunjukkan bagaimana blok bangunan cocok bersama. Seharusnya berisi seperangkat
alat dan memberikan kosakata umum. Ini juga harus mencakup daftar standar yang
direkomendasikan dan produk yang sesuai yang dapat digunakan untuk
mengimplementasikan blok bangunan.

 Architecture View: View adalah representasi dari suatu sistem dari perspektif
seperangkat masalah terkait, apa yang dilihat (atau apa yang dilihat oleh pemangku
kepentingan), serta spesifik.

 Architecture Viewpoint: titik pandang atau perspektif. Sudut pandang umum. Model
(atau deskripsi) dari informasi yang terkandung dalam tampilan.

 Architecture Vision: Pandangan aspirasional tingkat tinggi tentang Arsitektur Target.

/ Fase dalam ADM yang memberikan pemahaman dan definisi Visi Arsitektur / Tingkat
rincian pekerjaan yang harus dilakukan.

 Baseline: Spesifikasi yang telah ditinjau dan disepakati secara formal, yang selanjutnya
berfungsi sebagai dasar untuk pengembangan atau perubahan lebih lanjut dan yang
dapat diubah hanya melalui prosedur kontrol perubahan formal atau jenis prosedur
seperti manajemen konfigurasi.

 Baseline Architecture: Arsitektur sistem yang ditetapkan sudah ada sebelum

memasuki siklus tinjauan dan desain ulang arsitektur.

 Business Governance: Berhubungan dengan memastikan bahwa proses dan kebijakan

bisnis (dan operasinya) memberikan hasil bisnis dan mematuhi peraturan bisnis yang
relevan.

 Capability: Kemampuan yang dimiliki organisasi, orang, atau sistem. Kemampuan

biasanya dinyatakan dalam istilah umum dan tingkat tinggi dan biasanya memerlukan
kombinasi organisasi, orang, proses, dan teknologi untuk dicapai.

 Concerns: Kepentingan utama yang sangat penting bagi para pemangku kepentingan
dalam suatu sistem, dan menentukan penerimaan sistem. Dapat berkaitan dengan aspek
apa pun dari fungsi, pengembangan, atau operasi sistem, termasuk pertimbangan seperti
kinerja, keandalan, keamanan, distribusi, dan kemampuan berkembang. Lebih lama
dari masalah (mis. Keadaan ekonomi), bukan kebutuhan yang bersifat jangka pendek.

 Enterprise: Level tertinggi (biasanya) dari deskripsi organisasi dan biasanya

mencakup semua misi dan fungsi. Suatu perusahaan akan sering menjangkau banyak
organisasi.
1.2 TOGAF ADM
TOGAF ADM adalah framework-agnostic, dan membantu arsitek TI untuk menggunakan
kerangka kerja yang mungkin sudah dimiliki. ADM mendukung konsep iterasi pada tiga
tingkatan:

a. Cycling around the ADM: ADM disajikan secara melingkar yang menunjukkan bahwa
penyelesaian satu fase pekerjaan arsitektur secara langsung masuk ke dalam fase berikutnya
dari pekerjaan arsitektur.
b. Iterating between phases: TOGAF menjelaskan konsep iterasi di seluruh fase (mis.,
Kembali ke Arsitektur Bisnis setelah menyelesaikan Arsitektur Teknologi).
c. Cycling around a single phase: TOGAF mendukung pelaksanaan berulang kegiatan
dalam fase ADM tunggal sebagai teknik untuk menguraikan konten arsitektur.
 Gambar 3.1 Architecture Development Cycle

1.2.1 Fase Preliminary

Preliminary Phase menjelaskan kegiatan persiapan dan inisiasi yang diperlukan untuk
mempersiapkan diri memenuhi arahan bisnis untuk arsitektur perusahaan baru, termasuk
definisi kerangka Arsitektur Organisasi-Khusus dan definisi prinsip-prinsip.

1.2.1.1 Tujuan

 Mempersiapkan organisasi untuk proyek arsitektur TOGAF yang sukses.

 Melakukan kegiatan persiapan dan inisiasi yang diperlukan untuk memenuhi arahan
bisnis untuk arsitektur perusahaan baru, termasuk definisi kerangka kerja dan alat
Arsitektur Khusus Organisasi, dan definisi prinsip.

 Mendefinisikan "di mana, apa, mengapa, siapa, dan bagaimana kita melakukan
arsitektur" di perusahaan yang bersangkutan.

4.2.1.2 Pendekatan

Aspek utama adalah sebagai berikut:

 Mendefinisikan Enterprise.

 Mengidentifikasi pendorong dan elemen utama dalam konteks organisasi.

 Menentukan persyaratan untuk pekerjaan arsitektur.

 Menentukan prinsip-prinsip arsitektur yang akan menginformasikan setiap pekerjaan

arsitektur.

 Menentukan kerangka kerja yang akan digunakan

 Mendefinisikan hubungan antara kerangka kerja manajemen

 Evaluating the enterprise architecture’s maturity

4.2.1.3 Input
Bagian ini mendefinisikan input ke Preliminary Phase.
Bahan Referensi Eksternal ke Perusahaan

▪ TOGAF
▪ Kerangka kerja arsitektur lain, jika diperlukan

Input Non-Architectural
 ▪ Strategi dewan dan rencana bisnis dewan, strategi bisnis, strategi TI, prinsip bisnis,
tujuan bisnis, dan penggerak bisnis, ketika sudah ada sebelumnya
▪ Kerangka kerja utama yang beroperasi dalam bisnis; mis., manajemen portofolio /
proyek
▪ Tata kelola dan kerangka kerja hukum, termasuk strategi tata kelola arsitektur, ketika
sudah ada sebelumnya
▪ Kemampuan Arsitektur
▪ Kemitraan dan perjanjian kontrak

4.2.1.4 Input Architectural

Model yang sudah ada sebelumnya untuk mengoperasikan Kemampuan Arsitektur

perusahaan dapat digunakan sebagai dasar untuk Tahap Awal. Input akan mencakup:

▪ Model Organisasi untuk Arsitektur Perusahaan, termasuk:

o Lingkup organisasi yang terkena dampak
o Penilaian kematangan, kesenjangan, dan pendekatan resolusi
o Peran dan tanggung jawab untuk tim arsitektur
o Persyaratan anggaran
o Tata kelola dan strategi dukungan
▪ Kerangka Arsitektur yang Ada, jika ada, termasuk:
o Metode arsitektur
o Konten arsitektur
o Alat yang dikonfigurasikan dan digunakan
o Prinsip Arsitektur
o Repositori Arsitektur

4.2.1.5 Tahapan Preliminary

▪ Lingkup organisasi perusahaan yang terkena dampak

▪ Konfirmasikan tata kelola dan kerangka kerja pendukung
▪ Menentukan dan membentuk tim dan organisasi arsitektur perusahaan
▪ Mengidentifikasi dan menetapkan prinsip-prinsip arsitektur
▪ Menyesuaikan TOGAF dan, jika ada, Kerangka Arsitektur terpilih lainnya
▪ Menerapkan alat arsitektur

4.2.1.6 Output

Output dari Tahap Awal dapat mencakup, tetapi tidak terbatas pada:

▪ Model Organisasi untuk Arsitektur Perusahaan, termasuk:

o Lingkup organisasi terkena dampak
o Penilaian kematangan, kesenjangan, dan pendekatan resolusi
o Peran dan tanggung jawab untuk tim arsitektur
o Kendala pada pekerjaan arsitektur
o Persyaratan anggaran
 o Tata kelola dan strategi dukungan
▪ Kerangka Arsitektur Disesuaikan, termasuk:
o Metode arsitektur yang disesuaikan
o Konten arsitektur yang disesuaikan (kiriman dan artefak)
o Prinsip Arsitektur
o Alat yang dikonfigurasikan dan digunakan
▪ Repositori Arsitektur Awal, diisi dengan konten kerangka kerja
▪ Penyajian kembali, atau referensi ke, prinsip bisnis, tujuan bisnis, dan pendorong
bisnis
▪ Permintaan Karya Arsitektur (opsional)
▪ Kerangka Kerja Tata Kelola Arsitektur

Keluaran dapat mencakup beberapa atau semua hal berikut:

▪ Catalogs
▪ Principles catalog

1.2.2 Fase A - Architecture Vision

Menjelaskan fase awal dari Siklus Pengembangan Arsitektur. Ini termasuk informasi tentang
mendefinisikan ruang lingkup, mengidentifikasi pemangku kepentingan, menciptakan Visi
Arsitektur, dan mendapatkan persetujuan.

4.2.2.1 Tujuan

▪ Mengembangkan visi aspiratif tingkat tinggi tentang kapabilitas dan nilai bisnis yang
akan disampaikan sebagai hasil dari arsitektur perusahaan yang diusulkan.
▪ Tetapkan ruang lingkup, kendala, dan harapan untuk proyek TOGAF.
▪ Buat Visi Arsitektur.
▪ Definisikan pemangku kepentingan.
▪ Validasi konteks bisnis dan buat Pernyataan Karya Arsitektur.
▪ Dapatkan persetujuan untuk Pernyataan Karya Arsitektur.

3.3.2.2 Membuat Visi Arsitektur

▪ Visi Arsitektur merupakan alat utama untuk mendeskripsikan manfaat dari kapabilitas
yang diusulkan kepada para pemangku kepentingan dan pembuat keputusan dalam
perusahaan.
▪ Visi Arsitektur menjelaskan bagaimana kapabilitas baru akan memenuhi tujuan bisnis
dan sasaran strategis dan mengatasi masalah pemangku kepentingan saat
diimplementasikan.
▪ Visi Arsitektur memberikan uraian tingkat pertama atau tingkat tinggi tentang
Arsitektur Dasar (baseline) dan Sasaran (target), yang mencakup domain bisnis, data,
aplikasi, dan teknologi.
▪ Skenario bisnis merupakan teknik yang tepat dan berguna untuk menemukan dan
mendokumentasikan persyaratan bisnis, dan untuk mengartikulasikan Visi Arsitektur
yang menanggapi persyaratan tersebut.
3.3.2.3 Input
Bahan Referensi Eksternal Perusahaan

▪ Bahan referensi arsitektur

Input Bukan Arsitektur

▪ Permintaan Architecture work

▪ Prinsip bisnis, sasaran bisnis, dan penggerak bisnis

Input Arsitektural

▪ Model Organisasi untuk Arsitektur Perusahaan, termasuk:

o o Lingkup organisasi terkena dampak
o o Penilaian kematangan, kesenjangan, dan pendekatan resolusi
o o Peran dan tanggung jawab untuk tim arsitektur
o o Kendala pada pekerjaan arsitektur
o o Persyaratan penggunaan ulang
o o Persyaratan anggaran
o o Permintaan perubahan
o o Tata kelola dan strategi dukungan
▪ Kerangka Arsitektur Disesuaikan, termasuk:
o o Metode arsitektur yang disesuaikan
o o Konten arsitektur yang disesuaikan (kiriman dan artefak)
o o Prinsip arsitektur, termasuk prinsip bisnis, ketika sudah ada
o o Alat yang dikonfigurasikan dan digunakan
▪ Populasi Arsitektur Repositori - dokumentasi arsitektur yang ada (deskripsi kerangka
kerja, deskripsi arsitektur, deskripsi dasar, ABB, dll.)

3.3.2.4 Tahapan Fase A

Langkah-langkah dalam Fase A adalah sebagai berikut:
▪ Membangun proyek arsitektur
▪ Identifikasi pemangku kepentingan, kekhawatiran, dan persyaratan bisnis
▪ Konfirmasikan dan uraikan sasaran bisnis, penggerak bisnis, dan kendala
▪ Mengevaluasi kemampuan bisnis
▪ Menilai kesiapan untuk transformasi bisnis
▪ Tentukan ruang lingkup
▪ Konfirmasikan dan Prinsip Arsitektur yang rumit, termasuk prinsip bisnis
▪ Mengembangkan Visi Arsitektur
▪ Menentukan proposisi nilai Arsitektur Target dan KPI
▪ Identifikasi risiko transformasi bisnis dan kegiatan mitigasi
▪ Mengembangkan Pernyataan Karya Arsitektur; mendapat persetujuan yang pasti

3.3.2.5 Output
Output dari Fase A mungkin termasuk, tetapi tidak terbatas pada:
▪ Pernyataan yang disetujui dari Karya Arsitektur, termasuk khususnya:
 o Deskripsi dan ruang lingkup proyek arsitektur
o Tinjauan Visi Arsitektur
o Rencana dan jadwal proyek arsitektur
▪ Pernyataan yang disempurnakan dari prinsip bisnis, tujuan bisnis, dan pendorong
bisnis
▪ Prinsip arsitektur
▪ Penilaian Kemampuan
▪ Kerangka Arsitektur Disesuaikan (untuk keterlibatan), termasuk:
o Metode arsitektur yang disesuaikan
o Konten arsitektur yang disesuaikan (hasil dan artefak)
o Alat yang dikonfigurasikan dan digunakan
▪ Visi Arsitektur, termasuk:
o Deskripsi masalah
o Tujuan Pernyataan Karya Arsitektur
o Tampilan ringkasan
o Skenario Bisnis (opsional)
o Kebutuhan pemangku kepentingan tingkat tinggi yang disempurnakan
▪ Dokumen Definisi Arsitektur Konsep, termasuk (ketika dalam ruang lingkup):
o Baseline Business Architecture, Version 0.1
o Baseline Technology Architecture, Version 0.1
o Baseline Data Architecture, Version 0.1
o Baseline Application Architecture, Version 0.1
o Target Business Architecture, Version 0.1
o Target Technology Architecture, Version 0.1
o Target Data Architecture, Version 0.1
o Target Application Architecture, Version 0.1
▪ Rencana Komunikasi
▪ Populasi konten tambahan

Keluaran dapat mencakup beberapa atau semua hal berikut:

▪ Matrices:
o Stakeholder Map matrix
▪ Diagrams:
o Value Chain diagram
o Solution Concept diagram

1.2.3 Fase B - Business Architecture

Menjelaskan pengembangan Arsitektur Bisnis untuk mendukung Visi Arsitektur yang

disepakati.

Tujuan

 Mengembangkan Arsitektur Bisnis Target yang menggambarkan bagaimana

perusahaan perlu beroperasi untuk mencapai tujuan bisnis, dan menanggapi pendorong
strategis yang ditetapkan dalam Visi Arsitektur, dengan cara yang menangani
Permintaan Karya Arsitektur dan perhatian pemangku kepentingan.

 Identifikasi komponen-komponen Roadmap Architecture berdasarkan kesenjangan

antara Arsitektur Bisnis Baseline dan Arsitektur Bisnis Target
Pendekatan
Singkatnya, Arsitektur Bisnis menggambarkan strategi produk dan / atau layanan, dan aspek
organisasi, fungsional, proses, informasi, dan geografis dari lingkungan bisnis.

Mengembangkan deskripsi Arsitektur Dasar (Baseline)

 Jika suatu perusahaan memiliki deskripsi arsitektur yang ada, mereka harus digunakan
sebagai dasar untuk Deskripsi Dasar.
 Pendekatan normal untuk pengembangan Arsitektur Target adalah dari atas ke bawah.
 Namun, dalam Uraian Dasar, analisis keadaan saat ini sering harus dilakukan secara
bottom-up, terutama di mana aset arsitektur sedikit atau tidak ada.
 Apa pun pendekatannya, tujuannya haruslah menggunakan kembali bahan yang ada
sebanyak mungkin, dan untuk mengumpulkan dan menganalisis hanya informasi yang
memungkinkan pengambilan keputusan berdasarkan informasi mengenai Arsitektur
Bisnis Target.

Pemodelan Bisnis

 Models Model bisnis harus merupakan perluasan logis dari skenario bisnis dari Visi
Arsitektur, sehingga arsitektur dapat dipetakan dari persyaratan bisnis tingkat tinggi ke
yang lebih rinci.

 A variety of modelling tools and techniques may be employed:

 Activity Model (juga disebut Model Proses Bisnis): menjelaskan fungsi-fungsi

yang terkait dengan kegiatan bisnis perusahaan, data dan / atau informasi yang
dipertukarkan antar kegiatan.
 Use-Case Models: dapat menggambarkan proses bisnis atau fungsi sistem,
tergantung pada fokus upaya pemodelan.
 Model Kelas: menjelaskan informasi statis dan hubungan antara informasi.

Gambar 3.2 UML Business Class Diagram

Architecture Repository

 Sebagai bagian dari Fase B, tim arsitektur perlu mempertimbangkan sumber daya
Arsitektur Bisnis apa yang tersedia dari Repositori Arsitektur. Khususnya:

 Model bisnis generik yang relevan dengan sektor industri organisasi.

  Model bisnis yang relevan dengan domain bisnis tingkat tinggi umum.

 Building block khusus perusahaan (komponen proses, aturan bisnis, deskripsi

pekerjaan, dll.).

 Mendukung Enterprise Continum adalah konsep Repositori Arsitektur yang

dapat digunakan untuk menyimpan berbagai kelas hasil arsitektur pada berbagai
tingkat abstraksi, yang dibuat oleh ADM.

 Komponen utama dalam Arsitektur Repositori adalah sebagai berikut:

 Architecture Metamodel menjelaskan aplikasi kerangka kerja arsitektur yang

dirancang secara organisasi, termasuk metamodel untuk konten arsitektur.

 Architecture Capability mendefinisikan parameter, struktur, dan proses yang

mendukung tata kelola Repositori Arsitektur.

 Architecture Landscape menunjukkan tampilan arsitektur blok bangunan

yang digunakan dalam organisasi saat ini (mis., daftar aplikasi langsung).
Lansekap cenderung ada di berbagai tingkat abstraksi agar sesuai dengan tujuan
arsitektur yang berbeda.

 Standards Information Base (SIB) menangkap standar yang harus dipenuhi

oleh arsitektur baru, yang dapat mencakup standar industri, produk dan layanan
terpilih dari pemasok, atau layanan bersama yang sudah digunakan dalam
organisasi.

 Reference Library menyediakan pedoman, templat, pola, dan bentuk lain dari
bahan referensi yang dapat dimanfaatkan untuk mempercepat penciptaan
arsitektur baru untuk perusahaan.

 Governance Log memberikan catatan kegiatan tata kelola di seluruh

perusahaan.
 Gambar 3.3 Architecture Repository

Tahapan Fase B

▪ Pilih model referensi, viewpoint, dan tools

▪ Mengembangkan Deskripsi Arsitektur Bisnis Dasar
▪ Mengembangkan Deskripsi Arsitektur Bisnis Target
▪ Lakukan analisis Gap
▪ Tentukan kandidat komponen roadmap
▪ Atasi dampak di Lansekap Arsitektur
▪ Melakukan tinjauan pemangku kepentingan secara formal
▪ Finalisasi Arsitektur Bisnis
▪ Buat Dokumen Definisi Arsitektur

1.2.4 Fase C - Information Systems Architecture

Menjelaskan pengembangan Arsitektur Sistem Informasi untuk proyek arsitektur, termasuk

pengembangan Arsitektur Data dan Aplikasi.

1.2.4.1 Tujuan
▪ Mengembangkan Arsitektur Sistem Informasi Target (Data dan Aplikasi), menjelaskan
bagaimana Arsitektur Sistem Informasi perusahaan akan memungkinkan Arsitektur Bisnis
dan Visi Arsitektur, dengan cara yang membahas Permintaan Pekerjaan Arsitektur dan
keprihatinan pemangku kepentingan.

▪ Identifikasi kandidat komponen Roadmap Arsitektur berdasarkan kesenjangan antara

Arsitektur Sistem Informasi Dasar dan Arsitektur Sistem Informasi Target (Data dan
Aplikasi).

1.2.4.2 Bagian Data Architecture dari Phase C (Tujuan)

▪ Mengembangkan Arsitektur Data Target yang memungkinkan Arsitektur Bisnis dan Visi
Arsitektur, sambil menangani Permintaan untuk Pekerjaan Arsitektur dan kepentingan
pemangku kepentingan
▪ Identifikasi kandidat komponen Roadmap Architecture berdasarkan kesenjangan antara
Arsitektur Data Baseline dan Target.

1.2.4.3 Pertimbangan Kunci untuk Data Architecture

Data Management

• Definisi yang jelas tentang komponen aplikasi mana dalam lanskap akan berfungsi
sebagai sistem catatan atau referensi untuk data master perusahaan.
• Apakah akan ada standar perusahaan yang harus diadopsi oleh semua komponen
aplikasi, termasuk paket perangkat lunak?
• Sangat memahami bagaimana entitas data digunakan oleh fungsi bisnis, proses, dan
layanan.
• Sangat memahami bagaimana dan di mana entitas data perusahaan dibuat, disimpan,
diangkut, dan dilaporkan.
• Berapa tingkat dan kompleksitas transformasi data yang diperlukan untuk mendukung
kebutuhan pertukaran informasi antar aplikasi?
• Apa yang akan menjadi persyaratan untuk perangkat lunak dalam mendukung
integrasi data dengan pelanggan dan pemasok perusahaan?

Data Migration

• Ketika aplikasi yang ada diganti, akan ada kebutuhan penting untuk memigrasikan
data (master, transaksional, dan referensi) ke aplikasi baru.
• Arsitektur Data harus mengidentifikasi persyaratan migrasi data dan juga
menyediakan indikator untuk tingkat transformasi, penyiangan, dan pembersihan yang
akan diperlukan untuk menyajikan data dalam format yang memenuhi persyaratan dan
kendala dari aplikasi target.
• Tujuannya adalah bahwa aplikasi target memiliki data berkualitas ketika diisi.
• Pastikan bahwa definisi data umum di seluruh perusahaan dibuat untuk mendukung
transformasi.

Data Governance
Pertimbangan tata kelola data memastikan bahwa perusahaan memiliki dimensi yang
diperlukan untuk memungkinkan transformasi, sebagai berikut:

▪ Struktur: Dimensi ini berkaitan dengan apakah perusahaan memiliki struktur organisasi
yang diperlukan dan badan standar untuk mengelola aspek entitas data dari transformasi.
▪ Sistem Manajemen: Di sini perusahaan harus memiliki sistem manajemen yang
diperlukan dan program terkait data untuk mengelola aspek tata kelola entitas data
sepanjang siklus hidupnya.
▪ Orang: Dimensi ini membahas keterampilan dan peran terkait data apa yang diperlukan
perusahaan untuk transformasi. Jika perusahaan tidak memiliki sumber daya dan
keterampilan seperti itu, perusahaan harus mempertimbangkan untuk memperoleh
keterampilan kritis tersebut atau melatih sumber daya internal yang ada untuk memenuhi
persyaratan melalui program pembelajaran yang terdefinisi dengan baik.

1.2.4.4 Tahapan C (Data Architecture)

▪ Pilih model referensi, viewpoint, dan tools

▪ Mengembangkan Deskripsi Arsitektur Data Dasar
▪ Mengembangkan Deskripsi Arsitektur Data Target
▪ Lakukan analisis Gap
▪ Tentukan kandidat komponen roadmap
▪ Atasi dampak di Lansekap Arsitektur
▪ Melakukan tinjauan pemangku kepentingan secara formal
▪ Finalisasi Arsitektur Data
▪ Buat Dokumen Definisi Arsitektur

1.2.4.5 Bagian Application Architecture dari Fase C

Mengembangkan Target Arsitektur Aplikasi yang memungkinkan Arsitektur Bisnis dan Visi
Arsitektur, sambil menangani Permintaan untuk Pekerjaan Arsitektur dan kepentingan
pemangku kepentingan.

Identifikasi kandidat komponen Roadmap Architecture berdasarkan kesenjangan antara

Baseline dan Target Application Architecture.

1.2.4.6 Tahapan Application Architecture

▪ Pilih model referensi, viewpoint, dan tools

▪ Mengembangkan Deskripsi Arsitektur Aplikasi Dasar
▪ Mengembangkan Deskripsi Arsitektur Aplikasi Target
▪ Lakukan analisis Gap
▪ Tentukan kandidat komponen roadmap
▪ Atasi dampak di Lansekap Arsitektur
▪ Melakukan tinjauan pemangku kepentingan secara formal
▪ Finalisasi Arsitektur Aplikasi
 ▪ Buat Dokumen Definisi Arsitektur

1.2.4.7 Output

Keluaran dapat mencakup beberapa atau semua hal berikut:

▪ Catalog:
o Application Portfolio catalog
o Interface catalog
▪ Matrix:
o Application/Organization matrix
o Role/Application matrix
o Application/Function matrix
o Application Interaction matrix
▪ Diagram:
o Application Communication diagram
o Application and User Location diagram
o Application Use-Case diagram
o Enter prise Manageability diagram
o Process/Application Realization diagram
o Software Engineering diagram
o Application Migration diagram
o Software Distribution diagram

1.2.5 Fase D - Technology Architecture

Menjelaskan pengembangan Arsitektur Teknologi untuk proyek arsitektur.

Tujuan

 Mengembangkan Arsitektur Teknologi Target yang memungkinkan aplikasi logis dan

fisik dan komponen data dan Visi Arsitektur, menangani Permintaan untuk Pekerjaan
Arsitektur dan keprihatinan pemangku kepentingan.

 Identifikasi kandidat komponen Roadmap Architecture berdasarkan kesenjangan antara

Arsitektur Teknologi Baseline dan Target.
 Gambar 3.4 Architecture Repository

Step Phase D

▪ Pilih model referensi, viewpoint, dan tools

▪ Mengembangkan Deskripsi Arsitektur Teknologi Dasar
▪ Mengembangkan Deskripsi Arsitektur Teknologi Target
▪ Lakukan analisis Gap
▪ Tentukan kandidat komponen roadmap
▪ Atasi dampak di Lansekap Arsitektur
▪ Melakukan tinjauan pemangku kepentingan secara formal
▪ Finalisasi Arsitektur Teknologi
▪ Buat Dokumen Definisi Arsitektur

Output

Keluaran dapat mencakup beberapa atau semua hal berikut:

▪ Catalog:
o Technology Standards catalog
o Technology Portfolio catalog
▪ Matrix:
 o Application/Technology matrix
▪ Diagram:
o Environments and Locations diagram
o Platfor m Decomposition diagram
o Processing diagram
o Networ ked Computing/Hardware diagram
o Communications Engineering diagram

1.2.6 Fase E - Oppurtunities and Solutions

Opportunities and Solutions melakukan perencanaan implementasi awal dan identifikasi cara
untuk menyerahkan arsitektur yang ditentukan dalam fase sebelumnya.

Tujuan

 Menghasilkan versi lengkap awal dari Roadmap Arsitektur, berdasarkan pada analisis
gap dan kandidat komponen Roadmap Arsitektur dari Fase B, C, dan D

 Menentukan apakah diperlukan pendekatan bertahap, dan jika demikian identifikasi

Arsitektur Transisi yang akan memberikan nilai bisnis berkelanjutan.

 Untuk mengkonfirmasi kemampuan perusahaan untuk mengalami perubahan.

 Untuk menghasilkan dan memperoleh konsensus tentang Garis Besar Implementasi dan
Strategi Migrasi.

Tahapan Fase E

• Tentukan / konfirmasi atribut perubahan utama perusahaan

• Menentukan kendala bisnis untuk implementasi
• Tinjau dan konsolidasi hasil analisis kesenjangan dari Fase B ke D
• Tinjau persyaratan konsolidasi di seluruh fungsi bisnis terkait
• Konsolidasi dan rekonsiliasi persyaratan interoperabilitas
• Perbaiki dan validasi dependensi
• Konfirmasikan kesiapan dan risiko untuk transformasi bisnis
• Merumuskan Strategi Implementasi dan Migrasi
• Identifikasi dan kelompokkan paket pekerjaan utama
• Identifikasi Arsitektur Transisi
• Buat Roadmap Arsitektur & Implementasi dan Rencana Migrasi

Output

Diagram:
• Project Context diagram
• Benefits diagram

1.2.7 Fase F - Migration Planning

Mengatasi perumusan sekumpulan urutan Arsitektur Transisi dengan Implementasi dan
Rencana Migrasi yang mendukung.

Tujuan

 Analisis manfaat dan risiko biaya.

 Kembangkan Rencana Implementasi dan Migrasi yang terperinci.

 Finalisasi Roadmap Arsitektur dan Rencana Implementasi dan Migrasi yang

mendukung.

 Pastikan bahwa Rencana Implementasi dan Migrasi dikoordinasikan dengan

pendekatan perusahaan untuk mengelola dan mengimplementasikan perubahan dalam
keseluruhan portofolio perubahan perusahaan.

 Pastikan bahwa nilai bisnis dan biaya paket pekerjaan dan Arsitektur Transisi dipahami
oleh para pemangku kepentingan utama.

Tahapan Fase F

▪ Konfirmasikan interaksi kerangka kerja manajemen untuk Implementasi dan Rencana

Migrasi
▪ Tetapkan nilai bisnis untuk setiap paket pekerjaan
▪ Perkirakan kebutuhan sumber daya, waktu proyek, dan ketersediaan / pengiriman
kendaraan
▪ Prioritaskan proyek migrasi melalui penilaian biaya / manfaat dan validasi risiko
▪ Konfirmasikan Roadmap Arsitektur dan perbarui Dokumen Definisi Arsitektur
▪ Selesaikan Rencana Implementasi dan Migrasi
▪ Menyelesaikan siklus pengembangan arsitektur dan mendokumentasikan lesson learned

Output Fase F
▪ Rencana Implementasi dan Migrasi
▪ Dokumen Definisi Arsitektur Final
▪ Spesifikasi Persyaratan Arsitektur Final
▪ Roadmap Arsitektur Final
▪ Building Block Arsitektur yang Dapat Digunakan Kembali
▪ Permintaan untuk Pekerjaan Arsitektur untuk iterasi baru dari siklus ADM (jika ada)
▪ Model Tata Kelola Implementasi (jika ada)
▪ Ubah Permintaan Kemampuan Arsitektur yang timbul dari pembelajaran

1.2.8 Fase G - Implementation Governance

Memberikan pengawasan arsitektur terhadap implementasi.

Tujuan

 Memberikan pengawasan implementasi arsitektur.

  Menyiapkan dan menerbitkan Kontrak Arsitektur (Dewan Tata Kelola Implementasi).

 Pastikan proyek implementasi sesuai dengan arsitektur.

Pendekatan

• Menetapkan program implementasi yang akan memungkinkan pengiriman Arsitektur

Transisi yang disepakati untuk implementasi selama fase Perencanaan Migrasi.
• Mengadopsi jadwal penyebaran bertahap yang mencerminkan prioritas bisnis yang
terkandung dalam Roadmap Arsitektur.
• Ikuti standar organisasi untuk tata kelola perusahaan, TI, dan arsitektur.
• Gunakan pendekatan manajemen portofolio / program yang telah ditetapkan organisasi,
jika ada.
• Tetapkan kerangka kerja operasi untuk memastikan masa pakai efektif yang lama dari
solusi yang digunakan

Fase G membangun koneksi antara arsitektur dan organisasi implementasi, melalui Kontrak
Arsitektur.

Rincian proyek yang dikembangkan, termasuk:

 Nama, deskripsi, dan tujuan

 Lingkup, hasil, dan kendala

 Ukuran efektivitas

 Kriteria penerimaan

 Risiko dan masalah

Gambar 3.5 Architecture Governance Framework
 Gambar 3.6 Organizational Structure

Tahapan Fase G

▪ Konfirmasikan ruang lingkup dan prioritas untuk penempatan dengan manajemen

pembangunan
▪ Identifikasi sumber daya dan keterampilan penyebaran
▪ Panduan pengembangan penerapan solusi
▪ Lakukan masukkan tinjauan kepatuhan arsitektur hadiah
▪ Menerapkan operasi bisnis dan TI
▪ Lakukan review pasca implementasi dan tutup implementasinya

Output

▪ Kontrak Arsitektur (yang telah ditandatangani), seperti yang direkomendasikan dalam

arsitektur yang diimplementasikan sesuai arsitektur
▪ Penilaian Kepatuhan
▪ Perubahan permintaan
▪ Solusi yang sesuai dengan arsitektur digunakan
1.2.9 Fase H - Architecture Change Management

Menetapkan prosedur untuk mengelola perubahan pada arsitektur baru.

Tujuan

Menyediakan pemantauan berkelanjutan dan proses manajemen perubahan untuk memastikan

bahwa arsitektur merespon kebutuhan perusahaan dan memaksimalkan nilai arsitektur untuk
bisnis.

Penggerak Perubahan

Ada tiga cara untuk mengubah infrastruktur yang ada yang harus diintegrasikan:

 Strategis, perubahan diarahkan top-down untuk meningkatkan atau menciptakan

kemampuan baru (modal)

 Perubahan dari bawah ke atas untuk memperbaiki atau meningkatkan kemampuan

(operasi dan pemeliharaan) untuk infrastruktur di bawah manajemen operasi

 Pengalaman dengan peningkatan proyek yang disampaikan sebelumnya dalam

perawatan manajemen operasi, tetapi masih disampaikan oleh proyek yang sedang
berlangsung

Proses Manajemen Perubahan Arsitektur Enterprise

Perubahan arsitektur dapat diklasifikasikan ke dalam satu dari tiga kategori:

 Perubahan penyederhanaan: Perubahan penyederhanaan biasanya dapat ditangani

melalui teknik manajemen perubahan.

 Perubahan tambahan: Perubahan tambahan mungkin dapat ditangani melalui teknik

manajemen perubahan, atau mungkin memerlukan pengerjaan ulang sebagian,
tergantung pada sifat perubahan tersebut.

 Perubahan arsitektur ulang: Perubahan arsitektur ulang mengharuskan penempatan

keseluruhan arsitektur melalui siklus pengembangan arsitektur lagi.

Tahapan Fase H

▪ Menetapkan proses realisasi nilai

▪ Menyebarkan alat monitor
▪ Kelola risiko
▪ Berikan analisis untuk manajemen perubahan arsitektur
▪ Kembangkan persyaratan perubahan untuk memenuhi target kinerja
▪ Kelola proses tata kelola
▪ Aktifkan proses untuk mengimplementasikan perubahan

Output Fase H
Output dari Fase H mungkin termasuk, tetapi tidak terbatas pada:

▪ Pembaruan arsitektur (untuk perubahan pemeliharaan)

▪ Perubahan pada kerangka dan prinsip arsitektur (untuk perubahan pemeliharaan)
▪ Permintaan Baru untuk Pekerjaan Arsitektur, untuk pindah ke siklus lain (untuk
perubahan besar)
▪ Pernyataan Karya Arsitektur, diperbarui jika perlu
▪ Kontrak Arsitektur, diperbarui jika perlu
▪ Penilaian Kepatuhan, diperbarui jika perlu