TOGAF

TOGAF

TOGAF atau The Open Group Architecture Framework adalah metode yang

komprehensif dan satu set alat yang mendukung bagi pengembangan arsitektur enterprise.

TOGAF telah dikembangkan dan dikelola oleh anggota The Open Group. Perkembangan asli

TOGAF Versi 1 tahun 1995 didasarkan pada Technical Architecture Framework for

Information Management (TAFIM), yang dikembangkan oleh Departemen Pertahanan

Amerika Serikat. Departemen Pertahanan memberikan The Open Group izin eksplisit dan

dorongan untuk membuat TOGAF dengan membangun di TAFIM, yang itu sendiri

merupakan hasil dari upaya pengembangan bertahun-tahun dan investasi jutaan dolar dari

Pemerintah AS. TOGAF diterbitkan pada server web publik. Hal ini dapat digunakan secara

cuma-cuma oleh organisasi untuk menggunakannya secara internal untuk menciptakan

arsitektur.

TOGAF memberikan metode dan alat untuk membantu dalam penerimaan, produksi,

penggunaan, dan pemeliharaan arsitektur enterprise. Hal ini didasarkan pada model proses

berulang yang didukung oleh best practices dan satu set yang dapat digunakan kembali dari

aset arsitektur yang sudah ada.

TOGAF mencakup tetapi tidak benar-benar mengikuti terminologi ISO/IEC

42010:2007. Di TOGAF, '' arsitektur '' memiliki dua arti tergantung pada konteks sebagai

berikut:

1. Penjelasan formal sistem, atau rencana rinci dari sistem pada tingkat komponen untuk

memandu pelaksanaannya.

2. Struktur komponen, hubungan antar mereka, dan prinsip-prinsip serta pedoman yang

mengatur desain dan evolusinya dari waktu ke waktu.

Ada empat domain arsitektur yang umum diterima sebagai himpunan bagian dari

arsitektur perusahaan secara keseluruhan, yang semuanya dirancang TOGAF untuk

mendukung:

1. Arsitektur Bisnis mendefinisikan strategi bisnis, tata kelola, organisasi, dan proses

bisnis utama.

2. Arsitektur Data menggambarkan struktur aset data logis dan fisik organisasi dan

sumber daya manajemen data.

3. Arsitektur Aplikasi menyediakan cetak biru untuk sistem aplikasi individu untuk

digunakan, interaksi mereka, dan hubungan mereka dengan proses bisnis inti

organisasi.

4. Teknologi Arsitektur menggambarkan perangkat lunak dan perangkat keras

kemampuan logis yang diperlukan untuk mendukung penyebaran layanan bisnis, data,

dan aplikasi. Ini termasuk infrastruktur TI, middleware, jaringan, komunikasi,

pengolahan, standar, dll.

Architecture Development Method (ADM) TOGAF menggambarkan suatu metoda

untuk mengembangkan Enterprise Architecture, 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.

Gambar 1. Fase ADM

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.

ADM bersifat iteratif, dinamis, dan berkelanjutan. Output dari fase sebelumnya menjadi input

pada fase selanjutnya. Hal ini dikelola dengan fase Requirements Management.

ADM mendefinisikan urutan yang direkomendasikan untuk berbagai fase dan langkah

dalam pengembangan arsitektur, tetapi tidak merekomendasikan lingkup—yang harus

ditetapkan oleh organisasi yang bersangkutan. Berikut ini adalah tahapan untuk

mengembangkan arsitektur yang terdapat dalam ADM:

1. Preliminary Phase: Frameworks and Principles (Scoping and identifying resource)

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.

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

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

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

a. 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)

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

c. 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:

Luas cakupan enterprise o Level detil yang ditetapkan

Domain arsitektur spesifik yang diliput (bisnis, data, aplikasi, teknologi)

Tingkat masa datang yang dituju

Aset arsitektur yang akan diungkit, atau dipertimbangkan untuk digunakan, dari

Enterprise Continuum organisasi:

o Aset yang diciptakan dalam iterasi sebelum siklus ADM dalam enterprise

o Aset yang tersedia di tempat lain dalam industri (framework lain, model sistem,

model industri vertikal, dan sebagainya)

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

e. Output:

Pernyataan pekerjaan arsitektur yang disetujui, termasuk:

Lingkup dan batasan

Rencana untuk pekerjaan arsitektur

Pernyataan tujuan bisnis dan driver strategi yang diperbaiki

Prinsip arsitektur, termasuk prinsip bisnis

Visi arsitektur, termasuk:

Arsitektur bisnis baseline versi 0.1

Arsitektur teknologi baseline versi 0.1 o Arsitektur data baseline versi 0.1

Arsitektur aplikasi baseline versi 0.1 o Arsitektur bisnis target versi 0.1

Arsitektur teknologi target versi 0.1 o Arsitektur data target versi 0.1

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.

a. Input:

Output pada fase A


Enterprise continuum

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

c. Output:

Pernyataan pekerjaan arsitektur, diperbaharui jika perlu

Prinsip bisnis yang divalidasi, tujuan bisnis, dan driver strategi

Arsitektur bisnis target versi 1.0 (dirinci), termasuk:

struktur organisasi—identifikasi lokasi bisnis dan menghubungkannya dengan unit

organisasi

tujuan dan sasaran bisnis o fungsi bisnis

layanan bisnis o proses bisnis o peran bisnis

model data bisnis

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.

a. Input:

Prinsip data, jika ada


Pernyataan pekerjaan arsitektur

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

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

d. Output:


Arsitektur data baseline versi 1.0, jika sesuai

Prinsip data yang divalidasi, atau prinsip data baru (jika dihasilkan di sini)

Arsitektur data target versi 1.0

Sudut pandang perhatian stakeholder kunci

Pandangan yang berhubungan dengan sudut pandang yang dipilih

Hasil analisis gap

Kebutuhan teknis yang relevan akan berlaku dalam evolusi siklus pengembangan

arsitektur

Laporan arsitektur data

Analisis dampak

Kebutuhan bisnis diperbaharui, jika sesuai

Fase untuk membuat arsitektur aplikasi

Sasaran dalam fase ini adalah menetapkan/mendefinisikan berbagai jenis sistem

aplikasi utama yang diperlukan untuk memproses data dan mendukung bisnis. Penting

untuk dicatat bahwa ini tidak berhubungan dengan rancangan sistem aplikasi.

Tujuannya adalah mendefinisikan jenis sistem aplikasi yang relevan dengan enterprise

dan aplikasi apa yang dibutuhkan untuk mengelola data dan menghasilkan informasi

bagi pengguna di enterprise.

Aplikasi tidak digambarkan sebagai sistem komputer, tetapi sebagai kumpulan

kapabilitas logik yang mengelola objek data dalam arsitektur data dan mendukung

fungsi bisnis dalam arsitektur bisnis. Aplikasi dan kapabilitasnya ditetapkan tanpa

referensi teknologi tertentu. Aplikasi adalah stabil dan relatif tidak berubah,

sedangkan teknologi yang digunakan untuk mengimplementasikannya akan berubah

dari waktu ke waktu, berdasarkan pada teknologi yang ada saat ini dan perubahan

kebutuhan bisnis.

5. Phase D: Technology Architecture

Fase ini membuat arsitektur teknologi yang membentuk fondasi target infrastruktur

TI.

a. Input:

Prinsip teknologi, jika ada



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


jika tersedia

c. Langkah-langkah:

Mengembangkan deskripsi arsitektur teknologi baseline

Mengembangkan arsitektur teknologi target

d. Output:


Arsitektur teknologi baseline versi 1.0, jika sesuai

Prinsip teknologi yang divalidasi, atau prinsip teknologi baru (jika dihasilkan di sini)

Laporan arsitektur teknologi

Arsitektur teknologi target versi 1.0

Arsitektur teknologi, laporan analisis gap

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.

a. Input:



Arsitektur bisnis target, versi 1.0



Arsitektur teknologi target, versi 1.0


jika tersedia

Informasi produk

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

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

a. Input:



Arsitektur bisnis target, versi 1.0



Arsitektur teknologi target, versi 1.0

Analisis dampak—daftar proyek

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

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

a. Input:




jika tersedia

Analisis dampak: rencana implementasi dan migrasi dirinci (termasuk kontrak

implementasi arsitektur, jika sesuai)

b. Langkah-langkah:

Memformulasikan rekomendasi proyek

Mendokumentasikan kontrak arsitektur

Me-review tata kelola implementasi dan pemenuhan arsitektur yang berkelanjutan

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

a. Input:

Permintaan untuk perubahan arsitektur karena perubahan teknologi

Permintaan untuk perubahan arsitektur karena perubahan bisnis

b. 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).

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

a. Langkah-langkah:

Kebutuhan baseline

Memonitor kebutuhan baseline

Mengidentifikasi kebutuhan yang berubah dan prioritas yang dicatat

b. Output:

Pernyataan kebutuhan yang terstruktur, termasuk:

Kebutuhan yang berubah

Pernyataan dampak kebutuhan

Deliverables, Artefak, dan Building Blocks

Arsitek yang melaksanakan ADM akan menghasilkan sejumlah output sebagai hasil

dari upaya mereka, seperti proses flows, persyaratan arsitektur, rencana proyek, penilaian

kepatuhan proyek, dll. Architecture Content Framework TOGAF memberikan struktural

model untuk konten arsitektur yang memungkinkan produk kerja utama yang harus konsisten

didefinisikan, terstruktur, dan disajikan.

Architecture Content Framework menggunakan tiga kategori berikut untuk menggambarkan

jenis produk karya arsitektur dalam konteks penggunaan:

1. Sebuah penyampaian merupakan produk kerja kontrak yang ditentukan secara resmi

diulas, disetujui, dan ditandatangani oleh para pemangku kepentingan. Kiriman

merupakan output dari proyek dan orang-orang kiriman yang ada di dokumentasi

biasanya akan diarsipkan pada penyelesaian proyek, atau dialihkan menjadi Arsitektur

Repository sebagai model referensi, standar, atau snapshot Architecture Landscape

pada titik waktu.

2. Artefak adalah produk kerja arsitektur lebih rinci yang menggambarkan arsitektur dari

sudut pandang tertentu. Contohnya termasuk diagram jaringan, spesifikasi server

spesifikasi use case, daftar persyaratan arsitektur, dan matriks interaksi bisnis. Artefak

umumnya diklasifikasikan sebagai katalog (daftar), matriks (menunjukkan hubungan

antara hal-hal), dan diagram (gambar). Sebuah penyampaian arsitektur berisi banyak

artefak dan artefak akan membentuk isi Architecture Repository.

3. Sebuah blok bangunan merupakan komponen (berpotensi dapat digunakan kembali)

bisnis, IT, atau kemampuan arsitektur yang dapat dikombinasikan dengan blok

bangunan lainnya untuk memberikan arsitektur dan solusi.

Building blocks dapat didefinisikan pada berbagai tingkat detail, tergantung pada apa

tahap perkembangan arsitektur telah tercapai. Misalnya, pada tahap awal, sebuah blok

bangunan dapat hanya terdiri dari nama atau deskripsi garis. Kemudian, sebuah blok

bangunan dapat didekomposisi menjadi beberapa blok bangunan pendukung dan dapat

disertai dengan spesifikasi lengkap. Blok bangunan dapat berhubungan dengan '' arsitektur ''

atau '' solusi ''.

Architecture Building Blocks (ABBs) biasanya menggambarkan kemampuan yang

diperlukan dan bentuk spesifikasi Solution Building Blocks (SBBS). Misalnya kemampuan

layanan pelanggan mungkin diperlukan dalam suatu perusahaan yang didukung oleh banyak

SBBS, seperti proses, data, dan perangkat lunak aplikasi.

Solution Building Block (SBBS) merupakan komponen yang akan digunakan untuk

melaksanakan kemampuan yang diperlukan. Misalnya, jaringan adalah sebuah blok bangunan

yang dapat digambarkan melalui artefak komplementer dan kemudian dimanfaatkan untuk

mewujudkan solusi untuk perusahaan. Hubungan antara deliverables, artefak, dan building

blocks ditunjukkan pada gambar 2 berikut.

Gambar 2. Hubungan Antara Deliverables, Artefak, dan Building Blocks

Sebagai contoh, sebuah dokumen definisi arsitektur adalah penyampaian yang

mendokumentasikan deskripsi arsitektur. Dokumen ini akan berisi sejumlah artefak

pelengkap yang dilihat dari blok bangunan yang relevan dengan arsitektur. Sebagai contoh,

diagram alir proses (artefak) dapat dibuat untuk menggambarkan proses penanganan sasaran

panggilan (blok bangunan). Artefak ini juga dapat menjelaskan blok bangunan lainnya,

seperti aktor yang terlibat dalam proses (misalnya, sebuah layanan perwakilan nasabah).

Contoh dari hubungan antara deliverables, artefak, dan building blocks diilustrasikan dalam

Gambar 3.

Gambar 3. Contoh Dokumen Definisi Arsitektur

Enterprise Continuum

TOGAF termasuk konsep Enterprise Continuum, yang menetapkan konteks yang

lebih luas untuk seorang arsitek dan menjelaskan bagaimana solusi generik dapat

dimanfaatkan dan khusus untuk mendukung kebutuhan organisasi individu. Enterprise

Continuum adalah gambaran Arsitektur Repository yang menyediakan metode untuk

mengklasifikasikan arsitektur dan solusi artefak. Enterprise Continuum terdiri dari dua

konsep yang saling melengkapi: Continuum Arsitektur dan Solusi Continuum. Sebuah

gambaran dari struktur dan konteks untuk Enterprise Continuum ditunjukkan pada Gambar 4.

Gambar 4. Enterprise Continuum

Menggunakan TOGAF dengan Framework Lain

Dua elemen kunci dari kerangka arsitektur enterprise adalah:

1. Definisi kiriman bahwa aktivitas architecting harus menghasilkan

2. Penjelasan metode yang digunakan ini harus dilakukan

Dengan beberapa pengecualian, sebagian besar framework arsitektur enterprise fokus

pada yang pertama ini - set spesifik dari kiriman - dan relatif diam tentang metode yang akan

digunakan untuk menghasilkan mereka (sengaja begitu, dalam beberapa kasus). Karena

TOGAF adalah framework kerja umum dan dimaksudkan untuk digunakan dalam berbagai

lingkungan, TOGAF menyediakan framework kerja yang fleksibel dan extensible konten

yang mendukung satu set kiriman arsitektur generik. Akibatnya, TOGAF dapat digunakan

baik dalam dirinya sendiri, dengan kiriman generik yang menggambarkan; atau kiriman

tersebut dapat diganti atau diperpanjang oleh satu set yang lebih spesifik, yang didefinisikan

dalam suatu framework arsitek dianggap relevan. Dalam semua kasus, diharapkan arsitek

akan beradaptasi dan membangun framework TOGAF dalam rangka untuk menentukan

metode yang disesuaikan yang terintegrasi ke dalam proses dan struktur organisasi

perusahaan. Menyusun arsitektur ini mungkin termasuk mengadopsi unsur-unsur dari

framework arsitektur lain, atau mengintegrasikan metode TOGAF dengan framework standar

lainnya, seperti ITIL, CMMI, COBIT, PRINCE2, PMBOK, dan MSP. Sebagai framework

umum dan metode untuk arsitektur enterprise, TOGAF juga melengkapi framework lainnya

yang ditujukan khusus domain bisnis vertikal, khusus bidang teknologi horizontal (seperti

keamanan atau pengelolaan), atau area aplikasi spesifik (seperti e-Commerce).

Sumber:

http://www.togaf.biz/TOGAFWebsitefiles/TOGAF%20-%20presentatie.pdf

http://www.central2013.eu/fileadmin/user_upload/Downloads/outputlib/

Innotrain_Systematization_2011_04_05_FINAL.PDF

http://www.kingdee.com/news/subject/10togaf/pdf/TOGAF_9_ziyuan.pdf

http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf

http://digilib.itb.ac.id/files/disk1/687/jbptitbpp-gdl-sitizulaih-34307-1-2009ts-r.pdf

http://digilib.itb.ac.id/files/disk1/687/jbptitbpp-gdl-sitizulaih-34307-1-2009ts-r.pdf

http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf

http://www.central2013.eu/fileadmin/user_upload/Downloads/outputlib/Innotrain_Systematization_2011_04_05_FINAL.PDF

http://www.central2013.eu/fileadmin/user_upload/Downloads/outputlib/Innotrain_Systematization_2011_04_05_FINAL.PDF

TOGAF

Documents

Transcript of TOGAF