Rangkuman TOGAF Tahap D: Arsitektur Teknologi

Sumber Gambar: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap10.html

Tujuan

1. Mengembangkan Teknologi Arsitektur Sasaran yang mencakup logis dan fisik aplikasi dan data komponen dan Visi Arsitektur, sesuai dengan Permintaan Arsitektur Kerja dan para pemangku kepentingan
2. Mengidentifikasi calon komponen Arsitektur Roadmap berdasarkan kesenjangan antara Baseline dan Target Teknologi Arsitektur

Pendekatan

1. Arsitektur Repository

Tim arsitektur perlu mempertimbangkan sumber daya apa saja yang relevan dan tersedia pada Repository Arsitektur, seperti :

a. Ketersediaan layanan TI seperti yang didokumentasikan dalam katalog repositori IT atau layanan IT
b. TOGAF Technical Reference Model (TRM)
c. Model teknologi generik yang relevan dengan sektor ‘vertikal’ industri organisasi

Misalnya, TeleManagement Forum (TMF) telah mengembangkan model teknologi terperinci yang relevan dengan industri Telekomunikasi.

d. Model teknologi yang relevan dengan Arsitektur Sistem Umum

Sebagai contoh, Kelompok Terbuka memiliki Model Referensi untuk Infrastruktur Informasi Terpadu (III-RM) yang berfokus pada komponen tingkat aplikasi dan layanan mendasar yang diperlukan untuk menyediakan infrastruktur informasi terintegrasi.

Input

1. Bahan Referensi Eksternal untuk Perusahaan

a. Bahan Referensi Arsitektur
b. Informasi produk tentang produk kandidat

2. Non-Architectural Inputs

a. Permintaan untuk Pekerjaan Arsitektur
b. Penilaian Kemampuan
c. Rencana Komunikasi

3. Architectural Inputs

a. Model Organisasi untuk Arsitektur Perusahaan, termasuk:

- Lingkup organisasi berdampak
- Penilaian kematangan, kesenjangan, dan pendekatan resolusi
- Peran dan tanggung jawab untuk tim arsitektur
- Kendala kerja arsitektur
- Persyaratan anggaran
- Pemerintahan dan strategi dukungan

b. Kerangka Kerja Arsitektur Disesuaikan, termasuk:

- Metode arsitektur yang disesuaikan
- Konten arsitektur yang disesuaikan (kiriman dan artefak)
- Alat yang dikonfigurasikan dan disebarkan

c. Prinsip teknolog, jika ada

d. Pernyataan Karya Arsitektur

e. Visi Arsitektur

f. Arsitektur Repositori, Termasuk:

- Dapat digunakan kembali blok bangunan
- model referensi tersedia untuk public
- model referensi organisasi-spesifik
- standar organisasi

g. Draft Dokumen Arsitektur Definition, Termasuk:

- Dasar Arsitektur Bisnis, Versi 1.0 (rinci)
- Target Bisnis Arsitektur Versi 1.0 (rinci)
- Data Dasar Arsitektur, Versi 1.0 (rinci)
- Target Data Arsitektur, Versi 1.0 (rinci)
- Dasar Aplikasi Arsitektur, Versi 1.0 (rinci)
- Target Arsitektur Aplikasi, Versi 1.0 (rinci)
- Dasar Teknologi Arsitektur, Versi 0.1 (visi)
- Target Teknologi Arsitektur, Versi 0.1 (visi)

h. Draft Persyaratan Arsitektur Keterangan, Termasuk:

- Hasil analisis Gap (dari Business, Data, dan Aplikasi Arsitektur)
- persyaratan teknis yang relevan dari tahap sebelumnya

i. Bisnis, komponen Data, dan Penerapan Arsitektur Arsitektur Roadmap

Steps

Langkah-langkah dalam Tahap D adalah sebagai berikut:

1. Pilih Model Referensi, Sudut Pandang dan Alat

1.1. Menentukan Proses Permodelan Keseluruhan

Proses untuk mengembangkan Arsitektur Teknologi menggabungkan langkah langkah berikut:

a. Tentukan taksonomi layanan platform dan komponen teknologi logis (termasuk standar)
b. Identifikasi lokasi yang relevan di mana teknologi dikerahkan
c. Lakukan inventarisasi fisik teknologi yang digunakan dan abstrak agar sesuai dengan taksonomi
d. Lihatlah aplikasi dan persyaratan bisnis untuk teknologi
e. Apakah teknologinya sesuai dengan tujuan untuk memenuhi persyaratan baru (yaitu apakah memenuhi persyaratan fungsional dan non-fungsional)?
— Sempurnakan taksonomi
— Pemilihan produk (termasuk produk yang bergantung)
f. Menentukan konfigurasi teknologi yang dipilih
g. Menentukan dampaknya:
— Sizing dan biaya
— perencanaan kapasitas
— dampak Instalasi / pemerintahan / migrasi

Dalam fase awal ADM, keputusan tertentu dibuat sekitar granularity dan layanan batas layanan akan memiliki implikasi pada komponen teknologi dan platform layanan. Daerah mana Arsitektur Teknologi mungkin terkena dampak akan meliputi:

a. prestasi: The granularity dari layanan ini akan berdampak pada persyaratan platform layanan. layanan tdk halus berisi beberapa unit fungsi yang berpotensi berbagai persyaratan non fungsional, sehingga kinerja platform yang harus dipertimbangkan. Selain itu, layanan tdk halus kadang-kadang dapat berisi informasi lebih dari benar-benar dibutuhkan oleh sistem meminta.
b. rawatan: Jika layanan granularity terlalu kasar, maka memperkenalkan perubahan layanan yang menjadi sulit dan dampak pemeliharaan layanan dan platform yang disampaikan.
c. Lokasi dan Latency: Layanan mungkin berinteraksi satu sama lain atas link jarak jauh dan komunikasi antar-layanan akan memiliki built-in latency. Menggambar batas-batas layanan dan pengaturan granularity layanan harus mempertimbangkan dampak Platform / lokasi layanan komunikasi antar ini.
c. Tersedianya: Jasa doa tunduk pada jaringan dan / atau kegagalan layanan. Jadi ketersediaan komunikasi tinggi merupakan pertimbangan penting selama layanan dekomposisi dan mendefinisikan layanan granularity

1.2. Identifikasi Katalog Blok Bangunan Teknologi yang Diwajibkan

Arsitektur Teknologi harus membuat katalog teknologi sebagai berikut:

a. Berdasarkan katalog teknologi dan analisis aplikasi dilakukan dalam fase Arsitektur Aplikasi yang ada, mengumpulkan daftar produk yang digunakan.
b. Jika persyaratan diidentifikasi dalam Arsitektur Aplikasi tidak dipenuhi oleh produk yang sudah ada, memperpanjang daftar produk dengan memeriksa produk yang tersedia di pasar yang menyediakan fungsionalitas dan memenuhi standar yang dibutuhkan.
c. Mengklasifikasikan produk terhadap TOGAF TRM jika sesuai, memperluas model yang diperlukan agar sesuai dengan klasifikasi produk teknologi digunakan.
d. Jika standar teknologi sudah ada, terapkan ini ke katalog komponen teknologi untuk mendapatkan pandangan dasar kepatuhan dengan standar teknologi.

Katalog berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Teknologi:

a. Standart Teknologi
b. Portofolio Teknologi

1.3. Identifikasi Matriks yang Diperlukan

Matriks menunjukkan hubungan inti antara entitas model terkait. Matriks berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Teknologi:

a. Matriks Aplikasi / Teknologi

1.4. Identifikasi Diagram yang Diperlukan

Untuk setiap lingkungan, buatlah diagram logis dari perangkat keras dan infrastruktur perangkat lunak yang menunjukkan isi lingkungan dan komunikasi logis antar komponen. Jika tersedia, kumpulkan informasi kapasitas pada infrastruktur yang dikerahkan.

Untuk setiap lingkungan, buatlah diagram fisik infrastruktur komunikasi, seperti router, switch, firewall, dan tautan jaringan. Jika tersedia, kumpulkan informasi kapasitas pada infrastruktur komunikasi.

Diagram berikut harus dipertimbangkan untuk pengembangan dalam Arsitektur Teknologi:

a. Peta Lingkungan dan Lokasi
b. Diagram Dekomposisi Platform
c. Memproses diagram
d. Diagram Jaringan / Diagram Jaringan
e. Rekayasa Komunikasi diagram

1.5. Identifikasi Jenis Kebutuhan yang akan Dikumpulkan

Persyaratan ini dapat:
a. Berhubungan dengan domain teknologi
b. Berikan panduan rinci untuk direfleksikan selama desain dan implementasi untuk memastikan bahwa solusi tersebut memenuhi persyaratan arsitektur asli
Dalam langkah ini, arsitek harus mengidentifikasi persyaratan yang harus dipenuhi oleh arsitektur.

1.6. Pilih Layanan

Persyaratan yang diidentifikasi sebelumnya dapat memberikan informasi lebih rinci tentang:
a. Persyaratan untuk elemen spesifik organisasi atau keputusan yang sudah ada sebelumnya (sebagaimana berlaku)
b. Elemen organisasi yang sudah ada dan tidak berubah (sebagaimana berlaku)
c. Batasan lingkungan eksternal yang diwariskan

2. Mengembangkan Deskripsi Arsitektur Teknologi Dasar

Mulai dengan mengonversi deskripsi lingkungan yang ada ke dalam istilah Arsitektur Yayasan organisasi (misalnya, TOGAF Foundation Architecture’s TRM). Ini akan memungkinkan tim mengembangkan arsitektur untuk mendapatkan pengalaman dengan model dan untuk memahami bagian-bagian komponennya. Tim mungkin dapat mengambil keuntungan dari definisi arsitektur sebelumnya, tetapi diasumsikan bahwa beberapa adaptasi mungkin diperlukan untuk mencocokkan teknik definisi arsitektur yang digambarkan sebagai bagian dari proses ini. Tugas penting lainnya adalah menyusun daftar pertanyaan kunci yang dapat digunakan kemudian dalam proses pengembangan untuk mengukur keefektifan arsitektur baru.

3. Mengembangkan Sasaran Teknologi Arsitektur Deskripsi

Mengembangkan Keterangan Target Arsitektur Teknologi, sejauh yang diperlukan untuk mendukung Arsitektur Visi, Sasaran Arsitektur Bisnis, dan Sistem Informasi Sasaran Arsitektur. Ruang lingkup dan tingkat detail untuk didefinisikan akan tergantung pada relevansi unsur-unsur teknologi untuk mencapai Arsitektur Target, dan apakah deskripsi arsitektur ada. Sejauh mungkin, mengidentifikasi blok bangunan Teknologi Arsitektur yang relevan, menggambar pada Repository Arsitektur.

4. Lakukan Analisis Gap

Verifikasi model arsitektur untuk konsistensi internal dan akurasi:
a. Melakukan analisis trade-off untuk menyelesaikan konflik (jika ada) di antara pandangan yang berbeda
b. Memvalidasi bahwa model mendukung prinsip-prinsip, tujuan, dan kendala
c. Catatan perubahan pada sudut pandang diwakili dalam model yang dipilih dari Repositori Arsitektur, dan dokumen
d. Uji model arsitektur untuk kelengkapan terhadap persyaratan

5. Tentukan Calon Roadmap Komponen

Berikut penciptaan Dasar Arsitektur, Sasaran Arsitektur, dan analisis kesenjangan, sebuah Roadmap Teknologi diperlukan untuk memprioritaskan kegiatan selama fase mendatang. Teknologi Arsitektur roadmap ini akan digunakan sebagai bahan baku untuk mendukung definisi yang lebih rinci dari konsolidasi, lintas disiplin roadmap dalam fase Peluang & Solusi.

6. Mengatasi Dampak seberang Arsitektur Lansekap

Setelah Arsitektur Teknologi selesai, perlu untuk memahami dampak atau implikasi yang lebih luas.
Pada tahap ini, artefak arsitektur lainnya dalam Lanskap Arsitektur harus diperiksa untuk mengidentifikasi:
a. Apakah Arsitektur Teknologi ini berdampak pada arsitektur yang sudah ada sebelumnya?
b. Apakah perubahan terbaru telah dilakukan yang berdampak pada Arsitektur Teknologi?
c. Adakah peluang untuk memanfaatkan kerja dari Arsitektur Teknologi ini di area lain dari organisasi?
d. Apakah Arsitektur Teknologi ini berdampak pada proyek lain (termasuk yang direncanakan dan yang sedang berlangsung)?
e. Apakah Arsitektur Teknologi ini akan dipengaruhi oleh proyek lain (termasuk yang direncanakan dan yang sedang berlangsung)?

7. Melakukan Tinjauan Stakeholder Secara Formal

Periksa motivasi asli untuk proyek arsitektur dan Pernyataan Karya Arsitektur terhadap Arsitektur Teknologi yang diusulkan, tanyakan apakah cocok untuk tujuan mendukung pekerjaan berikutnya dalam domain arsitektur lainnya. Sempurnakan Arsitektur Teknologi yang diusulkan hanya jika diperlukan.

8. Menyelesaikan Arsitektur Teknologi

a. Pilih standar untuk setiap blok bangunan, gunakan kembali sebanyak mungkin dari model referensi yang dipilih dari Arsitektur Repositori
b. Dokumentasikan dengan lengkap setiap blok bangunan
c. Melakukan pemeriksaan silang akhir dari keseluruhan arsitektur terhadap tujuan bisnis; mendokumentasikan alasan untuk membuat keputusan blok dalam dokumen arsitektur
d. Dokumen laporan persyaratan keterlacakan tugas
e. Pemetaan akhir dokumen arsitektur dalam Arsitektur Repositori; dari blok bangunan yang dipilih, identifikasi yang mungkin digunakan kembali (praktik kerja, peran, hubungan bisnis, deskripsi pekerjaan, dll.), dan terbitkan melalui Arsitektur Repositori
f. Selesaikan semua produk kerja, seperti analisis kesenjangan

9. Buat Dokumen Definisi Arsitektur

Dokumentasikan alasan untuk membuat keputusan blok dalam Dokumen Definisi Arsitektur.
Siapkan bagian teknologi dari Dokumen Definisi Arsitektur, yang terdiri dari beberapa atau semua:
a. Fungsionalitas dan atribut yang mendasar - semantik, tidak ambigu, termasuk kemampuan dan pengelolaan keamanan
b. Blok bangunan dependen dengan fungsionalitas yang diperlukan dan antarmuka bernama
c. Antarmuka - set yang dipilih, disediakan (API, format data, protokol, antarmuka perangkat keras, standar)
d. Peta untuk bisnis / entitas dan kebijakan organisasi
Jika sesuai, menggunakan laporan dan / atau grafis yang dihasilkan oleh pemodelan alat untuk menunjukkan pandangan utama dari arsitektur. Route dokumen untuk ditinjau oleh pihak terkait, dan memasukkan umpan balik.

Output

Yang termasuk Output dari Tahap D:
a. Versi halus dan update dari kiriman fase Arsitektur Visi, mana yang berlaku:
- Pernyataan Arsitektur Kerja, Diperbarui jika diperlukan
- prinsip-prinsip teknologi divalidasi, atau prinsip-prinsip teknologi baru (jika dihasilkan di sini)
b. Draft Dokumen Arsitektur Definition, Termasuk:
- Target Teknologi Arsitektur, Versi 1.0 (rinci), termasuk:
- Teknologi Komponen dan hubungan mereka ke sistem informasi
- Teknologi platform dan dekomposisi mereka, yang menunjukkan kombinasi dari teknologi yang dibutuhkan untuk mewujudkan teknologi tertentu '' tumpukan ''
- Lingkungan dan lokasi - pengelompokan teknologi yang dibutuhkan dalam lingkungan komputasi (misalnya, pengembangan, produksi)
- beban pengolahan diharapkan dan distribusi beban di komponen teknologi
- Fisik (jaringan) komunikasi
- Hardware dan jaringan spesifikasi
- Dasar Teknologi Arsitektur, Versi 1.0 (rinci), jika sesuai
- Dilihat sesuai dengan sudut pandang yang dipilih menangani keprihatinan utama pemangku kepentingan
c. Draft Persyaratan Arsitektur Keterangan, Termasuk persyaratan Teknologi Arsitektur seperti:
- Hasil analisis Gap
- Persyaratan keluaran dari Fase B dan C
- persyaratan teknologi diperbarui
d. Teknologi komponen arsitektur Arsitektur Roadmap

Output dapat mencakup beberapa atau semua hal berikut:
a. Katalog:
- Teknologi Katalog standar
- Teknologi Katalog portofolio
b. Matriks:
- Aplikasi / matrix Teknologi
c. Diagram:
- Lingkungan dan Lokasi diagram
- diagram Platform penguraian
- Jaringan Komputasi / diagram Hardware
- Komunikasi Teknik diagram
- diagram pengolahan

Postscript

Memilih ruang lingkup siklus pengembangan arsitektur dengan hati-hati akan mempercepat pembayaran kembali. Sebaliknya, ruang lingkup yang sangat besar tidak mungkin mengarah pada implementasi yang sukses.

Sumber

https://pubs.opengroup.org/architecture/togaf91-doc/arch/