Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

com

Bab 7

Fase B: Arsitektur Bisnis

Bab ini menjelaskan tentang pengembangan Arsitektur Bisnis untuk mendukung Visi Arsitektur yang
disepakati.

Pendahulua
n

A.
Visi
Arsitektur
H.
Manajemen B.
Arsitektur
Perubahan
Bisnis
Arsitektur

C.
G. Persyaratan Sistem
Tata Kelola Pengelolaan Informasi
Pelaksanaan
Ilmu
bangunan

F. D.
Perenca Arsitektur
naan Teknologi
Migrasi e.
Peluang dan
Solusi

Gambar 7-1Fase B: Arsitektur Bisnis

Bagian II: Metode Pengembangan Arsitektur (ADM) 77

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Tujuan Fase B: Arsitektur Bisnis

7.1 Tujuan
Tujuan Fase B adalah untuk:
■ Kembangkan Arsitektur Bisnis Sasaran yang menjelaskan bagaimana perusahaan perlu
beroperasi untuk mencapai tujuan bisnis, dan menanggapi penggerak strategis yang
ditetapkan dalam Visi Arsitektur, dengan cara yang membahas Pernyataan Kerja Arsitektur
dan perhatian pemangku kepentingan
■ Identifikasi calon komponen Roadmap Arsitektur berdasarkan kesenjangan antara Baseline
dan Target Arsitektur Bisnis

7.2 Input
Bagian ini mendefinisikan input ke Fase B.

7.2.1 Bahan Referensi Eksternal untuk Perusahaan

■ Bahan referensi arsitektur (lihat Bagian IV,Bagian 32.2.5)

7.2.2 Input Non-Arsitektur

■ Permintaan Pekerjaan Arsitektur (lihat Bagian IV,Bagian 32.2.17)
■ Prinsip bisnis, tujuan bisnis, dan pendorong bisnis (lihat Bagian IV,Bagian 32.2.9)
■ Penilaian Kemampuan (lihat Bagian IV,Bagian 32.2.10)
■ Rencana Komunikasi (lihat Bagian IV,Bagian 32.2.12)

7.2.3 Input Arsitektur

■ Model Organisasi untuk Arsitektur Perusahaan (lihat Bagian IV,Bagian 32.2.16), termasuk:
— Cakupan organisasi yang terkena dampak
— Penilaian kematangan, kesenjangan, dan pendekatan resolusi
— Peran dan tanggung jawab untuk tim arsitektur
— Kendala pada pekerjaan arsitektur
— Kebutuhan anggaran
— Strategi tata kelola dan dukungan
■ Kerangka Kerja Arsitektur yang Disesuaikan (lihat Bagian IV,Bagian 32.2.21), termasuk:
— Metode arsitektur yang disesuaikan
— Konten arsitektur yang disesuaikan (kiriman dan artefak)
— Alat yang dikonfigurasi dan digunakan
■ Pernyataan Pekerjaan Arsitektur yang Disetujui (lihat Bagian IV,Bagian 32.2.20)

78 Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Input

■ Prinsip Arsitektur (lihat Bagian IV,Bagian 32.2.4), termasuk prinsip bisnis, jika sudah ada
sebelumnya
■ Rangkaian Perusahaan (lihat Bagian V,Bab 35)
■ Repositori Arsitektur (lihat Bagian IV,Bagian 32.2.5), termasuk:
— Blok bangunan yang dapat digunakan kembali
— Model referensi yang tersedia untuk umum
— Model referensi khusus organisasi
— Standar organisasi
■ Visi Arsitektur (lihat Bagian IV,Bagian 32.2.8), termasuk:
— Deskripsi masalah
— Tujuan Pernyataan Karya Arsitektur
— Tampilan ringkasan
— Skenario Bisnis (opsional)
— Menyempurnakan persyaratan pemangku kepentingan tingkat tinggi utama
■ Draf Dokumen Definisi Arsitektur, termasuk (bila dalam ruang lingkup):
— Arsitektur Bisnis Dasar, Versi 0.1
— Arsitektur Teknologi Dasar, Versi 0.1
— Arsitektur Data Dasar, Versi 0.1
— Arsitektur Aplikasi Baseline, Versi 0.1
— Target Arsitektur Bisnis, Versi 0.1
— Teknologi SasaranArsitektur, Versi 0.1
— Arsitektur Data Target, Versi 0.1
— Aplikasi SasaranArsitektur, Versi 0.1

7.3 Langkah
Tingkat detail yang dibahas dalam Fase B akan bergantung pada ruang lingkup dan tujuan dari
upaya arsitektur secara keseluruhan.
Model-model baru yang mencirikan kebutuhan bisnis perlu didefinisikan secara rinci selama Fase
B. Artefak bisnis yang ada untuk dibawa dan didukung di lingkungan target mungkin sudah
cukup ditentukan dalam pekerjaan arsitektur sebelumnya; tetapi, jika tidak, mereka juga perlu
ditentukan di Fase B.
Urutan langkah-langkah dalam Fase B serta waktu dimulai dan diselesaikan secara formal harus
disesuaikan dengan situasi yang ada, sesuai dengan Tata Kelola Arsitektur yang ditetapkan.
Secara khusus, tentukan apakah dalam situasi ini tepat untuk melakukan pengembangan Baseline
atau Target Architecture terlebih dahulu, seperti yang dijelaskan pada Bagian III,Bab 18.
Semua aktivitas yang telah dimulai dalam langkah-langkah ini harus ditutup selama langkah
Finalisasi Arsitektur Bisnis (lihatBagian 7.3.8). Dokumentasi yang dihasilkan dari langkah-
langkah ini harus dipublikasikan secara formal dalam langkah Buat Dokumen Definisi Arsitektur
(lihatBagian7.3.9).

Bagian II: Metode Pengembangan Arsitektur (ADM) 79

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
kah

Langkah-langkah dalam Fase B adalah sebagai berikut:

■ Pilih model referensi, sudut pandang, dan alat (lihatBagian 7.3.1)
■ Mengembangkan Deskripsi Arsitektur Bisnis Baseline (lihatBagian 7.3.2)
■ Mengembangkan Deskripsi Arsitektur Bisnis Sasaran (lihatBagian 7.3.3)
■ Lakukan analisis kesenjangan (lihatBagian 7.3.4)
■ Tentukan kandidat komponen roadmap (lihatBagian 7.3.5)
■ Selesaikan dampak di Lanskap Arsitektur (lihatBagian 7.3.6)
■ Lakukan tinjauan pemangku kepentingan formal (lihatBagian 7.3.7)
■ Finalisasi Arsitektur Bisnis (lihatBagian 7.3.8)
■ Buat Dokumen Definisi Arsitektur (lihatBagian 7.3.9)

7.3.1 Pilih Model Referensi, Sudut Pandang, dan Alat

Pilih sumber daya Arsitektur Bisnis yang relevan (model referensi, pola, dll.) dari Repositori
Arsitektur, berdasarkan penggerak bisnis, serta pemangku kepentingan dan kepentingan.
Pilih sudut pandang Arsitektur Bisnis yang relevan (misalnya, operasi, manajemen, keuangan);
yaitu, mereka yang akan memungkinkan arsitek untuk menunjukkan bagaimana keprihatinan
pemangku kepentingan ditangani dalam Arsitektur Bisnis.
Identifikasi alat dan teknik yang sesuai untuk digunakan untuk pengambilan, pemodelan, dan
analisis, terkait dengan sudut pandang yang dipilih. Bergantung pada tingkat kecanggihan yang
dijamin, ini dapat terdiri dari dokumen atau spreadsheet sederhana, atau alat dan teknik
pemodelan yang lebih canggih, seperti model aktivitas, model proses bisnis, model kasus
penggunaan, dll.

7.3.1.1 Menentukan Keseluruhan Proses Pemodelan

Pemodelan bisnis dan penilaian strategi adalah teknik yang efektif untuk membingkai keadaan
target Arsitektur Bisnis organisasi (lihatBagian 6.3.4). Keluaran dari aktivitas tersebut kemudian
digunakan untuk mengartikulasikan kemampuan bisnis, struktur organisasi, dan aliran nilai
yang diperlukan untuk menutup kesenjangan antara kondisi saat ini dan target. Seperti yang
dibahas diBagian 6.5, kerangka kerja untuk peta ini mungkin sudah ada dan harus dimanfaatkan,
sekarang menggunakannya untuk mengkarakterisasi kesenjangan dan pemetaan nilai bisnis yang
lebih baik untuk mencapai Target Arsitektur Bisnis.
Untuk setiap sudut pandang, pilih model yang diperlukan untuk mendukung tampilan spesifik
yang diperlukan, dengan menggunakan alat atau metode yang dipilih.
Pastikan bahwa semua kekhawatiran pemangku kepentingan tercakup. Jika tidak, buat model
baru untuk mengatasi masalah yang tidak tercakup, atau tingkatkan model yang ada (lihatBagian
7.5.6). Skenario bisnis adalah teknik yang berguna untuk menemukan dan mendokumentasikan
persyaratan bisnis, dan dapat digunakan secara iteratif, pada berbagai tingkat detail dalam
dekomposisi hirarkis Arsitektur Bisnis. Skenario bisnis dijelaskan dalam Panduan Seri TOGAF®:
Skenario Bisnis.

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
80
kah Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Lang
kah

Teknik yang dijelaskan diBagian 7.5 dapat digunakan untuk semakin membusuk bisnis:
■ Pemetaan Kemampuan Bisnis: mengidentifikasi, mengkategorikan, dan menguraikan
kapabilitas bisnis yang diperlukan agar bisnis memiliki kemampuan untuk memberikan
nilai kepada satu atau lebih pemangku kepentingan
■ Pemetaan Organisasi: representasi struktur organisasi bisnis (termasuk domain pihak
ketiga), yang menggambarkan unit bisnis, penguraian unit-unit tersebut menjadi fungsi
tingkat rendah, dan hubungan organisasi (unit-ke-unit dan pemetaan ke kemampuan
bisnis, lokasi, dan atribut lainnya)
■ Pemetaan Aliran Nilai: perincian aktivitas yang dilakukan organisasi untuk menciptakan
nilai yang dipertukarkan dengan pemangku kepentingan
Peta aliran nilai menggambarkan bagaimana sebuah organisasi memberikan nilai dan
berada dalam konteks kumpulan pemangku kepentingan tertentu, dan meningkatkan
kemampuan bisnis untuk menciptakan nilai pemangku kepentingan dan menyelaraskan
dengan aspek lain dari Arsitektur Bisnis Target.
■ Analisis Terstruktur: mengidentifikasi fungsi bisnis utama dalam ruang lingkup arsitektur,
dan memetakan fungsi tersebut ke unit organisasi dalam bisnis
■ Analisis kasus penggunaan: perincian fungsi tingkat bisnis lintas pelaku dan organisasi
memungkinkan pelaku dalam suatu fungsi untuk diidentifikasi dan memungkinkan
perincian ke dalam layanan yang mendukung/menyampaikan kemampuan fungsional
tersebut
■ Pemodelan Proses: perincian fungsi atau layanan bisnis melalui pemodelan proses
memungkinkan elemen-elemen proses diidentifikasi, dan memungkinkan identifikasi
layanan atau fungsi bisnis tingkat rendah
Tingkat dan ketelitian dekomposisi yang diperlukan bervariasi dari perusahaan ke perusahaan,
serta dalam perusahaan, dan arsitek harus mempertimbangkan tujuan, sasaran, ruang lingkup,
dan tujuan perusahaan dari upaya Arsitektur Perusahaan untuk menentukan tingkat
dekomposisi.

7.3.1.2 Identifikasi Tingkat Perincian Layanan yang Diperlukan, Batasan, dan Kontrak
Kerangka konten TOGAF membedakan antara fungsi bisnis dan layanan bisnis. Layanan bisnis
adalah fungsi spesifik yang memiliki batasan yang jelas dan jelas yang diatur secara eksplisit.
Untuk memungkinkan fleksibilitas arsitek untuk menentukan layanan bisnis pada tingkat
perincian yang sesuai untuk dan dapat dikelola oleh bisnis, fungsi dibagi sebagai berikut: fungsi
tingkat mikro akan memiliki batasan yang jelas dan terdefinisi, tetapi mungkin tidak diatur secara
eksplisit . Demikian pula, fungsi bisnis makro dapat diatur secara eksplisit, tetapi mungkin tidak
memiliki batasan yang jelas dan jelas.
Oleh karena itu, fase Arsitektur Bisnis perlu mengidentifikasi komponen arsitektur mana yang
merupakan fungsi dan mana yang merupakan layanan. Layanan dibedakan dari fungsi melalui
definisi eksplisit dari kontrak layanan. Ketika Arsitektur Baseline sedang dikembangkan,
mungkin kontrak eksplisit tidak ada dan oleh karena itu akan menjadi kebijaksanaan arsitek
untuk menentukan apakah ada manfaat dalam mengembangkan kontrak tersebut sebelum
memeriksa Arsitektur Target apa pun.
Kontrak layanan mencakup antarmuka bisnis/fungsional dan juga antarmuka teknologi/data.
Arsitektur Bisnis akan menentukan kontrak layanan di tingkat bisnis/fungsional, yang akan
diperluas dalam fase Arsitektur Aplikasi dan Teknologi.
Perincian layanan bisnis harus ditentukan sesuai dengan pendorong bisnis, sasaran, sasaran, dan
ukuran untuk area bisnis ini. Layanan berbutir halus memungkinkan pengelolaan dan
pengukuran yang lebih dekat (dan dapat digabungkan untuk menciptakan layanan berbutir
© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Lang
kasar), tetapi memerlukan upaya yang lebih besar untuk mengaturnya. Pedoman untuk
kah
identifikasi layanan dan definisi mereka

Bagian II: Metode Pengembangan Arsitektur (ADM) 81

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
kah

kontrak dapat ditemukan di Panduan Seri TOGAF®: Menggunakan Kerangka Kerja TOGAF®
untuk Mendefinisikan dan Mengatur Arsitektur Berorientasi Layanan.

7.3.1.3 Identifikasi Katalog Blok Bangunan Bisnis yang Diperlukan

Katalog menangkap inventaris aset inti bisnis. Katalog bersifat hierarkis dan menangkap
dekomposisi blok bangunan dan juga dekomposisi di seluruh blok bangunan terkait (misalnya,
organisasi/aktor).
Katalog membentuk bahan mentah untuk pengembangan matriks dan tampilan dan juga
bertindak sebagai sumber daya utama untuk mengelola bisnis dan kapabilitas TI.
Katalog berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Bisnis:
■ Katalog Aliran Nilai
■ Katalog Kemampuan Bisnis
■ Katalog Tahapan Value Stream
■ Katalog Organisasi/Aktor
■ Katalog Penggerak/Tujuan/Tujuan
■ Katalog peran
■ Katalog Layanan Bisnis/Fungsi
■ Katalog lokasi
■ Katalog Proses/Peristiwa/Kontrol/Produk
■ Katalog Kontrak/Ukuran
Struktur katalog didasarkan pada atribut entitas metamodel, sebagaimana didefinisikan dalam
Bagian IV,Bab 30.

7.3.1.4 Identifikasi Matriks yang Diperlukan

Matriks menunjukkan hubungan inti antara entitas model terkait.
Matriks membentuk bahan mentah untuk pengembangan pandangan dan juga bertindak
sebagai sumber utama untuk penilaian dampak, yang dilakukan sebagai bagian dari analisis
kesenjangan.
Matriks berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Bisnis:
■ Matriks Aliran Nilai/Kemampuan (menampilkan kemampuan yang diperlukan untuk
mendukung setiap tahap aliran nilai)
■ Matriks Strategi/Kemampuan (menampilkan kemampuan yang diperlukan untuk
mendukung pernyataan strategi tertentu)
■ Matriks Kapabilitas/Organisasi (menampilkan elemen organisasi yang
mengimplementasikan setiap kapabilitas)
■ Matriks Interaksi Bisnis (menunjukkan ketergantungan dan komunikasi antara organisasi
dan aktor)
■ Matriks Aktor/Peran (menunjukkan peran yang dilakukan oleh masing-masing aktor)
Struktur matriks didasarkan pada atribut entitas metamodel, sebagaimana didefinisikan dalam
Bagian IV,Bab 30.

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
82
kah Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Lang
kah

7.3.1.5 Identifikasi Diagram yang Diperlukan

Diagram menyajikan informasi Arsitektur Bisnis dari sekumpulan perspektif (sudut pandang)
yang berbeda sesuai dengan kebutuhan pemangku kepentingan.
Diagram berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Bisnis:
■ Diagram Model Bisnis
■ Peta Kemampuan Bisnis
■ Peta Aliran Nilai
■ Peta Organisasi
■ Diagram Jejak Bisnis
■ Diagram Layanan/Informasi Bisnis
■ Diagram Dekomposisi Fungsional
■ Diagram Sasaran/Tujuan/Layanan
■ Diagram Kasus Penggunaan Bisnis
■ Diagram Dekomposisi Organisasi
■ Diagram Alur Proses
■ Diagram peristiwa
Struktur diagram didasarkan pada atribut entitas metamodel, sebagaimana didefinisikan dalam
Bagian IV,Bab 30.

7.3.1.6 Identifikasi Jenis Persyaratan yang Harus Dikumpulkan

Setelah katalog, matriks, dan diagram Arsitektur Bisnis telah dikembangkan, pemodelan
arsitektur diselesaikan dengan memformalkan persyaratan yang berfokus pada bisnis untuk
mengimplementasikan Arsitektur Target.
Persyaratan ini mungkin:
■ Berkaitan dengan domain bisnis
■ Memberikan input persyaratan ke Arsitektur Data, Aplikasi, dan Teknologi
■ Berikan panduan terperinci untuk direfleksikan selama desain dan implementasi untuk
memastikan bahwa solusi memenuhi persyaratan arsitektur asli
Dalam langkah ini, arsitek harus mengidentifikasi persyaratan yang harus dipenuhi oleh
arsitektur (lihatBagian 16.5.2).
Dalam banyak kasus, Definisi Arsitektur tidak dimaksudkan untuk memberikan persyaratan
terperinci atau komprehensif untuk suatu solusi (karena ini dapat ditangani dengan lebih baik
melalui disiplin manajemen persyaratan umum). Cakupan konten persyaratan yang diharapkan
harus ditetapkan selama fase Visi Arsitektur dan didokumentasikan dalam Pernyataan Pekerjaan
Arsitektur yang disetujui.
Persyaratan apa pun, atau perubahan persyaratan, yang berada di luar ruang lingkup yang
ditentukan dalam Pernyataan Karya Arsitektur harus diserahkan ke Repositori Persyaratan untuk
dikelola melalui proses Manajemen Persyaratan yang diatur.

Bagian II: Metode Pengembangan Arsitektur (ADM) 83

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
kah

7.3.2 Mengembangkan Deskripsi Arsitektur Bisnis Baseline

Mengembangkan Deskripsi Dasar dari Arsitektur Bisnis yang ada, sejauh yang diperlukan untuk
mendukung Arsitektur Bisnis Sasaran. Ruang lingkup dan tingkat detail yang akan didefinisikan
akan tergantung pada sejauh mana elemen bisnis yang ada kemungkinan akan dibawa ke dalam
Arsitektur Bisnis Target, dan pada apakah Deskripsi Arsitektur ada, seperti yang dijelaskan
dalamBagian 7.5. Sedapat mungkin, identifikasi blok bangunan Arsitektur Bisnis yang relevan,
dengan menggambar di Architecture Repository (lihat Bagian V,Bab 37).
Jika model arsitektur baru perlu dikembangkan untuk memenuhi kepentingan pemangku
kepentingan, gunakan model yang diidentifikasi dalam Langkah 1 sebagai panduan untuk
membuat konten arsitektur baru untuk menjelaskan Arsitektur Baseline.

7.3.3 Mengembangkan Deskripsi Arsitektur Bisnis Sasaran

Kembangkan Deskripsi Target untuk Arsitektur Bisnis, sejauh yang diperlukan untuk
mendukung Visi Arsitektur. Cakupan dan tingkat detail yang akan ditentukan akan bergantung
pada relevansi elemen bisnis untuk mencapai Visi Arsitektur Target, dan pada apakah ada
deskripsi arsitektur. Sedapat mungkin, identifikasi blok bangunan Arsitektur Bisnis yang relevan,
dengan menggambar di Architecture Repository (lihat Bagian V,Bab 37).
Jika model arsitektur baru perlu dikembangkan untuk memenuhi perhatian pemangku
kepentingan, gunakan model yang diidentifikasi dalam Langkah 1 sebagai panduan untuk
membuat konten arsitektur baru untuk menjelaskan Arsitektur Target.

7.3.4 Lakukan Analisis Gap

Verifikasi model arsitektur untuk konsistensi dan akurasi internal:
■ Lakukan analisis trade-off untuk menyelesaikan konflik (jika ada) di antara pandangan yang
berbeda
■ Validasi bahwa model mendukung prinsip, tujuan, dan kendala
■ Catat perubahan pada sudut pandang yang direpresentasikan dalam model yang dipilih
dari Repositori Arsitektur, dan dokumen
■ Uji model arsitektur untuk kelengkapan terhadap persyaratan
Identifikasi kesenjangan antara garis dasar dan target, dengan menggunakan teknik analisis
kesenjangan seperti yang dijelaskan pada Bagian III,Bab 23.

7.3.5 Menentukan Komponen Roadmap Kandidat

Menyusul pembuatan Baseline Architecture, Target Architecture, dan hasil gap analysis, business
roadmap diperlukan untuk memprioritaskan aktivitas pada fase mendatang.
Peta Jalan Arsitektur Bisnis awal ini akan digunakan sebagai bahan baku untuk mendukung
definisi yang lebih terperinci dari peta jalan lintas disiplin yang terkonsolidasi dalam fase Peluang
& Solusi.

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
84
kah Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Lang
kah

7.3.6 Selesaikan Dampak di Lanskap Arsitektur

Setelah Arsitektur Bisnis selesai, perlu untuk memahami dampak atau implikasi yang lebih luas.
Pada tahap ini, artefak arsitektur lain dalam Lanskap Arsitektur harus diperiksa untuk
mengidentifikasi:
■ Apakah Arsitektur Bisnis ini berdampak pada arsitektur yang sudah ada sebelumnya?
■ Apakah perubahan terbaru telah dilakukan yang berdampak pada Arsitektur Bisnis?
■ Apakah ada peluang untuk memanfaatkan pekerjaan dari Arsitektur Bisnis ini di area lain
dalam organisasi?
■ Apakah Arsitektur Bisnis ini memengaruhi proyek lain (termasuk yang direncanakan
maupun yang sedang berjalan)?
■ Apakah Arsitektur Bisnis ini akan terpengaruh oleh proyek lain (termasuk yang
direncanakan maupun yang sedang berjalan)?

7.3.7 Melakukan Tinjauan Pemangku Kepentingan Formal

Periksa motivasi asli untuk proyek arsitektur dan Pernyataan Pekerjaan Arsitektur terhadap
Arsitektur Bisnis yang diusulkan, tanyakan apakah cocok untuk tujuan mendukung pekerjaan
selanjutnya di domain arsitektur lainnya. Perbaiki Arsitektur Bisnis yang diusulkan hanya jika
diperlukan.

7.3.8 Finalisasi Arsitektur Bisnis

■ Pilih standar untuk setiap blok penyusun, gunakan kembali sebanyak mungkin dari model
referensi yang dipilih dari Repositori Arsitektur
■ Sepenuhnya mendokumentasikan setiap blok bangunan
■ Melakukan pemeriksaan silang akhir dari keseluruhan arsitektur terhadap tujuan bisnis;
mendokumentasikan alasan untuk keputusan blok bangunan dalam dokumen arsitektur
■ Mendokumentasikan laporan ketertelusuran persyaratan akhir
■ Dokumentasikan pemetaan akhir arsitektur dalam Architecture Repository; dari blok
bangunan yang dipilih, identifikasi yang mungkin digunakan kembali (praktik kerja, peran,
hubungan bisnis, deskripsi pekerjaan, dll.), dan publikasikan melalui Repositori Arsitektur
■ Finalisasi semua produk kerja, seperti hasil gap analysis

7.3.9 Buat Dokumen Definisi Arsitektur

■ Dokumentasikan alasan untuk membuat keputusan blok dalam Dokumen Definisi
Arsitektur
■ Persiapkan bagian bisnis dari Dokumen Definisi Arsitektur, yang terdiri dari beberapa
atau semua:
— Jejak bisnis (deskripsi tingkat tinggi tentang orang dan lokasi yang terlibat dengan
fungsi bisnis utama)

Bagian II: Metode Pengembangan Arsitektur (ADM) 85

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
kah

— Penjelasan rinci tentang fungsi bisnis dan kebutuhan informasinya

— Jejak manajemen (menunjukkan rentang kendali dan akuntabilitas)
— Standar, aturan, dan pedoman yang menunjukkan praktik kerja, undang-undang,
ukuran keuangan, dll.
— Matriks keterampilan dan serangkaian deskripsi pekerjaan
Jika sesuai, gunakan laporan dan/atau grafik yang dihasilkan oleh alat pemodelan untuk
mendemonstrasikan tampilan utama arsitektur. Rutekan dokumen untuk ditinjau oleh
pemangku kepentingan terkait, dan gabungkan umpan balik.

7.4 Keluaran
Keluaran Fase B dapat mencakup, namun tidak terbatas pada:
■ Versi penyampaian fase Architecture Vision yang disempurnakan dan diperbarui, jika
berlaku, termasuk:
— Pernyataan Pekerjaan Arsitektur (lihat Bagian IV,Bagian 32.2.20), diperbarui jika perlu
— Prinsip bisnis yang divalidasi, tujuan bisnis, dan pendorong bisnis (lihat Bagian
IV,Bagian 32.2.9), diperbarui jika perlu
— Prinsip Arsitektur (lihat Bagian IV,Bagian 32.2.4)
■ Draf Dokumen Definisi Arsitektur (lihat Bagian IV,Bagian 32.2.3), termasuk:
— Arsitektur Bisnis Baseline, Versi 1.0 (detail), jika sesuai
— Target Arsitektur Bisnis, Versi 1.0 (detail), termasuk:
— Struktur organisasi — mengidentifikasi lokasi bisnis dan menghubungkannya
dengan unit organisasi
— Tujuan dan sasaran bisnis — untuk perusahaan dan setiap unit organisasi
— Fungsi bisnis — langkah terperinci dan rekursif yang melibatkan dekomposisi
berturut-turut dari area fungsional utama menjadi sub-fungsi
— Layanan bisnis — layanan yang diberikan perusahaan dan setiap unit
perusahaan kepada pelanggannya, baik secara internal maupun eksternal
— Proses bisnis, termasuk pengukuran dan hasil
— Peran bisnis, termasuk pengembangan dan modifikasi persyaratan keterampilan
— Model data bisnis
— Korelasi organisasi dan fungsi — menghubungkan fungsi bisnis dengan unit
organisasi dalam bentuk laporan matriks
— Pandangan yang sesuai dengan sudut pandang yang dipilih menangani masalah
pemangku kepentingan utama
■ Draf Spesifikasi Persyaratan Arsitektur (lihat Bagian IV,Bagian 32.2.6, di halaman 354),
termasuk persyaratan Arsitektur Bisnis seperti:
— Hasil analisis kesenjangan
— Persyaratan teknis — mengidentifikasi, mengkategorikan, dan memprioritaskan
implikasi untuk bekerja di domain arsitektur yang tersisa; misalnya, dengan matriks
ketergantungan/prioritas (misalnya, membimbing trade-off antara kecepatan
pemrosesan transaksi dan keamanan); daftar model spesifik yang diharapkan

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Lang Fase B: Arsitektur Bisnis
86
kah Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Keluar
an

diproduksi (misalnya, dinyatakan sebagai primitif dari Zachman Framework)

— Persyaratan bisnis yang diperbarui
■ Komponen Arsitektur Bisnis dari Roadmap Arsitektur (lihat Bagian IV,Bagian 32.2.7)
Keluaran dapat mencakup beberapa atau semua hal berikut:
■ Katalog:
— Katalog Aliran Nilai
— Katalog Kemampuan Bisnis
— Katalog Tahapan Value Stream
— Katalog Organisasi/Aktor
— Katalog Penggerak/Tujuan/Tujuan
— Katalog peran
— Katalog Layanan Bisnis/Fungsi
— Katalog lokasi
— Katalog Proses/Peristiwa/Kontrol/Produk
— Katalog Kontrak/Ukuran
■ Matriks:
— Matriks Aliran Nilai/Kemampuan
— Matriks Strategi/Kemampuan
— Matriks Kemampuan/Organisasi
— Matriks Interaksi Bisnis
— Matriks aktor/peran
■ Diagram:
— Diagram Model Bisnis
— Peta Kemampuan Bisnis
— Peta Aliran Nilai
— Peta Organisasi
— Diagram Jejak Bisnis
— Diagram Layanan/Informasi Bisnis
— Diagram Dekomposisi Fungsional
— Diagram Siklus Hidup Produk
— Diagram Sasaran/Tujuan/Layanan
— Diagram Kasus Penggunaan Bisnis
— Diagram Dekomposisi Organisasi

Bagian II: Metode Pengembangan Arsitektur (ADM) 87

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Keluar Fase B: Arsitektur Bisnis
an

— Diagram Alur Proses

— Diagram peristiwa

7.5 Mendekati
Arsitektur Bisnis adalah representasi holistik, pandangan bisnis multi-dimensi dari: kemampuan,
pengiriman nilai end-to-end, informasi, dan struktur organisasi; dan hubungan antara
pandangan bisnis dan strategi, produk, kebijakan, inisiatif, dan pemangku kepentingan.
Arsitektur Bisnis menghubungkan elemen bisnis dengan tujuan bisnis dan elemen domain
lainnya.

7.5.1 Umum
Pengetahuan tentang Arsitektur Bisnis adalah prasyarat untuk pekerjaan arsitektur di domain
lain (Data, Aplikasi, Teknologi), dan oleh karena itu merupakan kegiatan arsitektur pertama yang
perlu dilakukan, jika belum dipenuhi dalam proses organisasi lainnya (perencanaan perusahaan,
perencanaan bisnis strategis, rekayasa ulang proses bisnis, dll.).
Dalam istilah praktis, Arsitektur Bisnis juga sering diperlukan sebagai sarana untuk
mendemonstrasikan nilai bisnis dari pekerjaan arsitektur selanjutnya kepada pemangku
kepentingan utama, dan pengembalian investasi kepada pemangku kepentingan tersebut dari
mendukung dan berpartisipasi dalam pekerjaan berikutnya.
Ruang lingkup pekerjaan di Tahap B terutama ditentukan oleh Visi Arsitektur sebagaimana
ditetapkan di Tahap A. Strategi bisnis menentukan tujuan dan pendorong serta metrik untuk
sukses, tetapi belum tentu bagaimana cara mencapainya. Itulah peran Arsitektur Bisnis, yang
didefinisikan secara rinci di Fase B.
Ini akan sangat tergantung pada lingkungan perusahaan. Dalam beberapa kasus, elemen kunci
dari Arsitektur Bisnis dapat dilakukan dalam aktivitas lain; misalnya, misi perusahaan, visi,
strategi, dan tujuan dapat didokumentasikan sebagai bagian dari beberapa strategi bisnis yang
lebih luas atau kegiatan perencanaan perusahaan yang memiliki siklus hidupnya sendiri di dalam
perusahaan.
Dalam kasus seperti itu, mungkin ada kebutuhan untuk memverifikasi dan memperbarui strategi
dan rencana bisnis yang saat ini didokumentasikan, dan/atau untuk menjembatani antara
penggerak bisnis tingkat tinggi, strategi bisnis, dan sasaran di satu sisi, dan persyaratan bisnis
spesifik yang relevan dengan upaya pengembangan arsitektur ini. Strategi bisnis biasanya
menentukan apa yang harus dicapai — tujuan dan pendorong, dan metrik untuk sukses — tetapi
bukan bagaimana cara mencapainya. Itulah peran Arsitektur Bisnis.
Dalam kasus lain, sedikit atau tidak ada pekerjaan Arsitektur Bisnis yang mungkin telah
dilakukan hingga saat ini. Dalam kasus seperti itu, akan ada kebutuhan bagi tim arsitektur untuk
meneliti, memverifikasi, dan mendapatkan dukungan untuk tujuan dan proses bisnis utama yang
didukung oleh arsitektur. Ini dapat dilakukan sebagai latihan berdiri bebas, baik sebelum
pengembangan arsitektur, atau sebagai bagian dari Fase A.
Dalam kedua kasus ini, teknik skenario bisnis (lihat Panduan Seri TOGAF®: Skenario Bisnis), atau
metode lain apa pun yang menjelaskan persyaratan bisnis utama dan menunjukkan persyaratan
teknis tersirat untuk arsitektur TI, dapat digunakan.
Tujuan utamanya adalah menggunakan kembali materi yang ada sebanyak mungkin. Di
lingkungan yang lebih matang secara arsitektur, akan ada Definisi Arsitektur yang ada, yang
(semoga) dipertahankan sejak siklus pengembangan arsitektur terakhir. Jika ada Deskripsi
Arsitektur, ini dapat digunakan sebagai titik awal, dan diverifikasi serta diperbarui jika perlu;
lihat Bagian V,Bagian 35.4.1.

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Keluar Fase B: Arsitektur Bisnis
an
88 Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Mendekat
i

Kumpulkan dan analisis hanya informasi yang memungkinkan dibuatnya keputusan

berdasarkan informasi yang relevan dengan ruang lingkup upaya arsitektur ini. Jika upaya ini
difokuskan pada definisi proses bisnis (kemungkinan baru), maka Fase B akan melibatkan banyak
pekerjaan yang mendetail. Jika fokus lebih pada Arsitektur Target di domain lain (data/informasi,
sistem aplikasi, infrastruktur) untuk mendukung Arsitektur Bisnis yang sudah ada secara
esensial, maka penting untuk membangun gambaran lengkap di Fase B tanpa masuk ke detail
yang tidak perlu.

7.5.2 Mengembangkan Deskripsi Baseline

Jika suatu perusahaan memiliki Deskripsi Arsitektur yang sudah ada, mereka harus digunakan
sebagai dasar untuk Deskripsi Baseline. Masukan ini mungkin telah digunakan di Fase A dalam
mengembangkan Visi Arsitektur, seperti peta kapabilitas bisnis atau rangkaian nilai inti seperti
yang diperkenalkan diBagian 6.5.2, dan mungkin cukup untuk baseline ini.
Alasan untuk memperbarui materi ini termasuk kehilangan kemampuan bisnis, aliran nilai baru,
atau mengubah unit organisasi yang sebelumnya tidak dinilai dalam lingkup proyek Arsitektur
Perusahaan.Bagian 7.5.3keBagian 7.5.5mengatasi penggunaan metode Arsitektur Bisnis inti
untuk memodelkan Arsitektur Bisnis yang didorong oleh ruang lingkup strategi dari Fase A.
Perhatikan bahwa menerapkan metode ini untuk mendorong fokus dan status target untuk
pekerjaan arsitektur selanjutnya tidak berarti kerangka dasar dari Fase A, seperti peta kapabilitas
bisnis perusahaan umum, perlu diubah tetapi diterapkan dengan cara yang didorong oleh ruang
lingkup dan kebutuhan proyek Arsitektur Perusahaan tertentu.
Jika tidak ada Deskripsi Arsitektur, informasi harus dikumpulkan dan model Arsitektur Bisnis
dikembangkan.
Apa pun ruang lingkup proyek tertentu, penting untuk menentukan apakah pandangan
mendasar dari bisnis yang berubah atau penggunaan pandangan tersebut untuk menentukan
ruang lingkup, prioritas, dan hubungan untuk proyek tertentu dalam kaitannya dengan sisa
proyek. perusahaan.

7.5.3 Menerapkan Kemampuan Bisnis

Peta kapabilitas bisnis yang ditemukan atau dikembangkan dalam fase Architecture Vision
memberikan pandangan mandiri tentang bisnis yang independen dari struktur organisasi saat
ini, proses bisnis, sistem dan aplikasi informasi, dan portofolio produk atau layanan lainnya.
Kemampuan bisnis tersebut harus dipetakan kembali ke unit organisasi, aliran nilai, sistem
informasi, dan rencana strategis dalam lingkup proyek Arsitektur Perusahaan. Pemetaan
hubungan ini memberikan wawasan yang lebih luas tentang penyelarasan dan pengoptimalan
masing-masing domain tersebut (lihat Pemetaan Hubungan dalam Panduan Grup Terbuka untuk
Kemampuan Bisnis).
Teknik analisis umum lainnya melibatkan pemetaan panas, yang dapat digunakan untuk
menunjukkan rentang perspektif yang berbeda pada rangkaian kemampuan bisnis inti yang
sama. Ini termasuk kematangan, keefektifan, kinerja, dan nilai atau biaya dari setiap kemampuan
untuk bisnis. Atribut yang berbeda menentukan warna setiap kapabilitas pada peta kapabilitas
bisnis (lihat Heat Mapping di The Open Group Guide to Business Capabilities).
Misalnya, peta panas kematangan kapabilitas bisnis menunjukkan kematangan yang diinginkan
sebagai hijau untuk kapabilitas tertentu, satu tingkat ke bawah sebagai kuning, dan dua atau lebih
tingkat ke bawah sebagai merah. Warna lain mungkin menunjukkan status, seperti ungu yang
menunjukkan kemampuan yang belum ada di perusahaan tetapi diinginkan, atau mungkin
sebagai kemampuan yang terlalu banyak dana dan memiliki lebih banyak sumber daya daripada
yang diperlukan. Analisis kesenjangan ini terkait langsung dengan proyek Arsitektur Perusahaan
yang sedang berlangsung; kesenjangan hanya relevan dalam konteks kebutuhan bisnis dan
memberikan fokus untuk lebih banyak pemetaan dalam fase ini atau prioritas untuk fase
© 2005-2018 Grup Terbuka, Semua Hak Dilindungi
Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Mendekat
arsitektur selanjutnya. i

Bagian II: Metode Pengembangan Arsitektur (ADM) 89

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Mendekat Fase B: Arsitektur Bisnis
i

7.5.4 Menerapkan Aliran Nilai

Aliran nilai memberikan konteks pemangku kepentingan yang berharga tentang mengapa
organisasi membutuhkan kapabilitas bisnis, sementara kapabilitas bisnis menyediakan apa yang
dibutuhkan organisasi agar tahap nilai tertentu berhasil.
Mulailah dengan set awal model aliran nilai untuk bisnis yang didokumentasikan dalam fase
Architecture Vision. Dalam lingkup proyek Arsitektur Perusahaan tertentu, jika luasnya cukup
besar, mungkin ada kebutuhan untuk aliran nilai baru yang belum ada dalam repositori.
Aliran nilai baru atau yang sudah ada dapat dianalisis dalam lingkup proyek melalui pemetaan
panas (berdasarkan tahap aliran nilai) atau dengan mengembangkan kasus penggunaan seputar
definisi lengkap aliran nilai (lihat Contoh Dasar dalam Panduan Seri TOGAF®: Nilai Aliran).
Sebuah proyek mungkin berfokus pada pemangku kepentingan tertentu, satu elemen dari nilai
bisnis, atau menekankan beberapa tahapan di atas yang lain untuk mengembangkan persyaratan
solusi yang lebih baik di fase selanjutnya.
Manfaat paling substantif berasal dari pemetaan hubungan antara tahapan dalam aliran nilai
dengan kapabilitas bisnis, kemudian melakukan analisis kesenjangan untuk kapabilitas (seperti
pemetaan panas) dalam konteks nilai bisnis yang dicapai oleh aliran nilai untuk pemangku
kepentingan tertentu (lihat Memetakan Value Streams ke Business Capabilities dalam TOGAF®
Series Guide: Value Streams).

7.5.5 Menerapkan Peta Organisasi

Peta organisasi menunjukkan unit organisasi utama, mitra, dan kelompok pemangku
kepentingan yang membentuk ekosistem perusahaan. Peta tersebut juga harus menggambarkan
hubungan kerja antara entitas tersebut, berbeda dari bagan organisasi yang hanya menunjukkan
hubungan pelaporan hierarkis. Peta biasanya digambarkan sebagai jaringan atau jaringan
hubungan dan interaksi antara berbagai entitas bisnis (lihat Organigraphs: Drawing How
Companies Really Work, oleh Mintzberg dan Van der Heyden, 1999).
Unit bisnis adalah konsep utama yang digunakan untuk membuat peta organisasi. Sesuai dengan
pandangan yang relatif tidak terbatas tentang apa yang dimaksud dengan perusahaan,
perusahaan dapat menjadi satu unit bisnis untuk proyek yang sedang berjalan, dapat mencakup
semua unit bisnis, atau juga termasuk pihak ketiga atau kelompok pemangku kepentingan
lainnya. Interpretasi tergantung pada ruang lingkup upaya arsitektur.
Peta ini adalah elemen kunci dari Arsitektur Bisnis karena memberikan konteks organisasi untuk
seluruh upaya Arsitektur Perusahaan. Sementara pemetaan kapabilitas mengungkap apa yang
dilakukan bisnis dan pemetaan arus nilai memaparkan bagaimana bisnis memberikan nilai
kepada pemangku kepentingan tertentu, organisasi memetakan mengidentifikasi unit bisnis atau
pihak ketiga yang memiliki atau menggunakan kapabilitas tersebut dan yang berpartisipasi
dalam arus nilai.
Diambil bersama dengan metode diBagian 7.5.3,Bagian 7.5.4, dan Panduan terkait, peta organisasi
memberikan pemahaman tentang unit bisnis mana yang akan terlibat dalam upaya arsitektur,
siapa dan kapan harus berbicara tentang persyaratan yang diberikan, dan bagaimana mengukur
dampak dari berbagai keputusan.

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Mendekat Fase B: Arsitektur Bisnis
i
90 Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Fase B: Arsitektur Bisnis Mendekat
i

7.5.6 Menerapkan Teknik Pemodelan

Teknik pemodelan dan pemetaan yang disediakan di sini adalah ekstensi yang
mengimplementasikan kapabilitas bisnis, aliran nilai, dan peta organisasi yang dijelaskan di atas
dalam Fase B ke dalam praktik bisnis. Mereka memperluas model operasi, yang merupakan
representasi bagaimana organisasi beroperasi di berbagai domain untuk mencapai fungsinya
(lihat Metode untuk Mengidentifikasi Peluang Penggunaan Ulang Proses untuk Meningkatkan
Model Operasi, M. de Vries et al. ).
Selain teknik yang dijelaskan di atas (peta kemampuan, aliran nilai, dan peta organisasi), berbagai
teknik pemodelan lainnya dapat digunakan, jika dianggap sesuai. Misalnya:
■ Model Aktivitas(juga disebut Model Proses Bisnis) menjelaskan fungsi yang terkait dengan
aktivitas bisnis perusahaan, pertukaran data dan/atau informasi antar aktivitas (pertukaran
internal), dan pertukaran data dan/atau informasi dengan aktivitas lain yang berada di luar
cakupan model (pertukaran eksternal)
Model aktivitas bersifat hierarkis. Mereka menangkap aktivitas yang dilakukan dalam
proses bisnis, dan ICOM (input, kontrol, output, dan mekanisme/sumber daya yang
digunakan) dari aktivitas tersebut. Model aktivitas dapat dijelaskan dengan pernyataan
eksplisit aturan bisnis, yang mewakili hubungan antar ICOM. Misalnya, aturan bisnis dapat
menentukan siapa yang dapat melakukan apa dalam kondisi tertentu, kombinasi input dan
kontrol yang diperlukan, serta output yang dihasilkan. Salah satu teknik pembuatan model
aktivitas adalah teknik pemodelan IDEF (Integrated Computer Aided Manufacturing
(ICAM) DEFinition).
Object Management Group (OMG) telah mengembangkan Notasi Pemodelan Proses
Bisnis™ (BPMN™), sebuah standar untuk pemodelan proses bisnis yang menyertakan
bahasa untuk menentukan proses bisnis, tugas/langkahnya, dan dokumen yang dihasilkan.
■ Model Kasus Penggunaandapat menggambarkan proses bisnis atau fungsi sistem,
tergantung pada fokus upaya pemodelan
Model use-case menggambarkan proses bisnis suatu perusahaan dalam hal kasus
penggunaan dan aktor yang sesuai dengan proses bisnis dan peserta organisasi (orang,
organisasi, dll.). Model use case dijelaskan dalam diagram use case dan spesifikasi use case.
■ Model Kelasmirip dengan model data logis
Sebuah model kelas menggambarkan informasi statis dan hubungan antara informasi.
Model kelas juga menjelaskan perilaku informasional. Seperti banyak model lainnya, model
ini juga dapat digunakan untuk memodelkan berbagai tingkat perincian. Bergantung pada
maksud model, model kelas dapat mewakili entitas domain bisnis atau kelas implementasi
sistem. Model domain bisnis mewakili informasi bisnis utama (kelas domain), karakteristik
mereka (atribut), perilaku mereka (metode atau operasi), dan hubungan (sering disebut
sebagai multiplisitas, menggambarkan berapa banyak kelas biasanya berpartisipasi dalam
hubungan), dan kardinalitas ( menggambarkan partisipasi wajib atau pilihan dalam
hubungan). Spesifikasi lebih lanjut menguraikan dan merinci informasi yang tidak dapat
direpresentasikan dalam diagram kelas.

Bagian II: Metode Pengembangan Arsitektur (ADM) 91

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Mendekat Fase B: Arsitektur Bisnis
i

Pelanggan

Kontak Alamat

Alamat
Tagih ke Alamat

Kirim ke Alamat © Grup Terbuka

Gambar 7-2Diagram Kelas Bisnis UML

Ketiga jenis model di atas dapat direpresentasikan dalam Unified Modeling Language™ (UML®),
dan terdapat berbagai alat untuk menghasilkan model tersebut.
Sektor industri tertentu memiliki teknik pemodelan khusus untuk sektor yang bersangkutan.
Misalnya, sektor Pertahanan menggunakan model berikut. Model ini harus digunakan dengan
hati-hati, terutama jika lokasi dan pelaksanaan proses bisnis akan diubah dalam Arsitektur Bisnis
visioner.
■ Diagram Konektivitas Node menggambarkan lokasi bisnis (node), "needlines" di antara
mereka, dan karakteristik informasi yang dipertukarkan
Konektivitas node dapat dijelaskan pada tiga tingkatan: konseptual, logis, dan fisik. Setiap
garis kebutuhan menunjukkan perlunya semacam transfer informasi antara dua node yang
terhubung. Node dapat mewakili peran (misalnya CIO), unit organisasi, lokasi atau fasilitas
bisnis, dan sebagainya. Panah yang menunjukkan arah aliran informasi dianotasi untuk
menjelaskan karakteristik data atau informasi — misalnya, konten, media, tingkat
keamanan atau klasifikasi, ketepatan waktu, dan persyaratan untuk interoperabilitas sistem
informasi.
■ Matriks Pertukaran Informasi mendokumentasikan persyaratan pertukaran informasi
untuk Arsitektur Perusahaan
Persyaratan pertukaran informasi mengungkapkan hubungan di tiga entitas dasar
(aktivitas, node bisnis dan elemennya, dan aliran informasi), dan fokus pada karakteristik
pertukaran informasi, seperti kinerja dan keamanan. Mereka mengidentifikasi siapa yang
bertukar informasi apa dengan siapa, mengapa informasi itu diperlukan, dan dengan cara
apa.

7.5.7 Repositori Arsitektur

Sebagai bagian dari Fase B, tim arsitektur perlu mempertimbangkan sumber daya Arsitektur
Bisnis relevan apa yang tersedia dari Repositori Arsitektur (lihat Bagian V,Bab 37), secara khusus:
■ Model referensi industri yang relevan dengan sektor industri organisasi
Ini adalah "Arsitektur Industri", dalam istilah Enterprise Continuum. Mereka diadakan di
Perpustakaan Referensi dari Architecture Repository (lihat Bagian V,Bagian 37.3). Misalnya:

92 Standar Grup Terbuka (2018)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Mendekat Fase B: Arsitektur Bisnis
i

— Grup Manajemen Objek (OMG) —www.omg.org— memiliki sejumlah

Gugus Tugas Domain vertikal yang mengembangkan model referensi
industri yang relevan dengan domain vertikal tertentu seperti Kesehatan,
Transportasi, Keuangan, dll.
— Forum TM —www.tmforum.org — telah mengembangkan model referensi
terperinci yang relevan dengan industri Telekomunikasi
— Departemen dan lembaga pemerintah di berbagai negara memiliki model
referensi dan kerangka kerja yang diamanatkan untuk digunakan,
dimaksudkan untuk mempromosikan integrasi dan interoperabilitas lintas
departemen
Contohnya adalah Model Referensi Bisnis Arsitektur Perusahaan Federal,
yang merupakan kerangka kerja berbasis fungsi untuk menggambarkan
operasi bisnis Pemerintah Federal yang independen dari lembaga yang
menjalankannya.
— Arsitektur Referensi IT4IT menyediakan Rantai Nilai TI tingkat tinggi yang
dapat digunakan dalam segmen TI arsitektur Anda
Arsitektur Referensi Level 1 IT4IT dapat digunakan untuk memandu
pembuatan Peta Kemampuan Bisnis untuk segmen TI.
■ Tampilan Arsitektur Bisnis khusus perusahaan (peta kemampuan, peta aliran
nilai, peta organisasi, dll.)
■ Blok bangunan khusus perusahaan (komponen proses, aturan bisnis, deskripsi
pekerjaan, dll.)
■ Standar yang berlaku

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi
Mendekat Fase B: Arsitektur Bisnis
i

Bagian II: Metode Pengembangan Arsitektur (ADM)

© 2005-2018 Grup Terbuka, Semua Hak Dilindungi

Undang-Undang Edisi PDF Pribadi. Bukan
untuk redistribusi