Archimate - Definisi Dalam Archimate

Definisi Archimate

Untuk keperluan standar ini, istilah dan definisi berikut ini berlaku. TOGAF®
framework [4] harus dirujuk untuk istilah yang berkaitan dengan Arsitektur Perusahaan yang tidak didefinisikan dalam bab ini. Kamus Collegiate Merriam-Webster (Edisi ke-11) harus dirujuk untuk semua istilah lain yang tidak didefinisikan dalam bab ini.
Setiap konflik antara definisi yang dijelaskan di sini dan kerangka kerja TOGAF tidak disengaja. Jika definisi istilah khusus untuk bahasa pemodelan ArchiMate, dan definisi umum didefinisikan oleh kerangka kerja TOGAF, maka ini dicatat dalam definisi tersebut.

2.1 ArchiMate Core Framework
Struktur referensi yang digunakan untuk mengklasifikasikan elemen-elemen dari bahasa inti ArchiMate. Terdiri dari tiga lapisan dan tiga aspek.
Catatan: Kerangka Inti ArchiMate didefinisikan secara rinci dalam Bagian 3.4.

2.2 ArchiMate Core Language
Bagian tengah dari bahasa ArchiMate yang mendefinisikan konsep untuk memodelkan Enterprise
Ilmu bangunan. Ini mencakup konsep dari tiga lapisan: Bisnis, Aplikasi, dan Teknologi
(termasuk Fisik).

2.3. Architecture View
Representasi suatu sistem dari perspektif seperangkat masalah terkait.
Catatan: Di beberapa bagian standar ini, istilah "tampilan" digunakan sebagai sinonim untuk
"Tampilan arsitektur".

2.4 Architecture Viewpoint
Spesifikasi konvensi untuk jenis tampilan arsitektur tertentu.
Catatan: Di beberapa bagian standar ini, istilah "sudut pandang" digunakan sebagai sinonim untuk
"Sudut pandang arsitektur".

2.5 Aspek
Klasifikasi elemen berdasarkan karakteristik lapisan-independen yang terkait dengan keprihatinan berbagai pemangku kepentingan. Digunakan untuk memposisikan elemen dalam metamodel ArchiMate. Lihat juga Bagian 2.9.

2.4 Sudut Pandang Arsitektur
Spesifikasi konvensi untuk jenis tampilan arsitektur tertentu.
Catatan: Di beberapa bagian standar ini, istilah "sudut pandang" digunakan sebagai sinonim untuk
"Sudut pandang arsitektur".

2.5 Aspect
Klasifikasi elemen berdasarkan karakteristik lapisan-independen yang terkait dengan keprihatinan berbagai pemangku kepentingan. Digunakan untuk memposisikan elemen dalam metamodel ArchiMate. Lihat juga Bagian 2.9.
© 2012-2019 Grup Terbuka, Semua Hak, Dilindungi. Edisi PDF Pribadi. Bukan untuk redistribusi
4 The Open Group Standard (2019)
Catatan: Aspek dijelaskan dalam Bagian 3.4.

2.6 Attribute
Properti yang terkait dengan elemen atau hubungan bahasa ArchiMate.

2.7 Composite Element
Elemen yang terdiri dari elemen lain dari berbagai aspek atau lapisan bahasa.

2.8 Concept
Entah elemen, hubungan, atau konektor hubungan. Lihat juga Bagian 2.12 dan Bagian 2.14.
Catatan: Struktur bahasa tingkat atas didefinisikan secara rinci dalam Bagian 3.2.

2.9 Conformance
Pemenuhan persyaratan yang ditentukan.

 2.10 Conforming Implementation
Suatu implementasi yang memenuhi persyaratan kesesuaian yang didefinisikan oleh klausa kesesuaian standar ini. Lihat Bagian 1.3.

2.11 Core Element
Struktur atau elemen perilaku di salah satu lapisan inti dari bahasa ArchiMate.
Catatan: Elemen inti dijelaskan secara rinci dalam Bagian 3.4.

2.12 Element
Unit dasar dalam metamodel ArchiMate. Digunakan untuk mendefinisikan dan menggambarkan bagian - bagian penyusun
Arsitektur Perusahaan dan serangkaian karakteristik unik mereka.

2.13 Layer
Sebuah abstraksi dari kerangka ArchiMate di mana suatu perusahaan dapat dimodelkan.

2.14 Model
Kumpulan konsep dalam konteks struktur bahasa ArchiMate.
Catatan: Struktur bahasa tingkat atas didefinisikan secara rinci dalam Bagian 3.2.
Untuk definisi umum model, lihat kerangka kerja TOGAF [4].

2.15 Hubungan
Koneksi antara konsep sumber dan target. Diklasifikasikan sebagai struktural, ketergantungan,
dinamis, atau lainnya.
Catatan: Hubungan didefinisikan secara rinci dalam Bab 5.

Archimate - Mengenal Archimate

Perkenalan Archimate

1.1 Tujuan
Standar ini adalah spesifikasi bahasa pemodelan ArchiMate Enterprise Architecture, bahasa visual dengan seperangkat ikonografi standar untuk menggambarkan, menganalisis, dan mengkomunikasikan banyak masalah Arsitektur Perusahaan saat mereka berubah seiring waktu. Standar ini memberikan seperangkat entitas dan hubungan dengan ikonografi yang sesuai untuk representasi Deskripsi Arsitektur. Ekosistem ArchiMate juga mendukung format pertukaran dalam XML yang memungkinkan pertukaran model dan diagram antar alat [20].

1.2 Ikhtisar
Arsitektur Perusahaan biasanya dikembangkan karena orang-orang kunci memiliki kekhawatiran yang perlu ditangani oleh sistem bisnis dan TI dalam suatu organisasi. Orang-orang seperti itu biasanya disebut sebagai "pemangku kepentingan" Arsitektur Perusahaan. Peran arsitek adalah untuk mengatasi masalah ini dengan mengidentifikasi dan memperbaiki motivasi dan strategi yang diungkapkan oleh para pemangku kepentingan, mengembangkan arsitektur, dan menciptakan pandangan arsitektur yang menunjukkan bagaimana ia mengatasi dan menyeimbangkan keprihatinan pemangku kepentingan. Tanpa Arsitektur Perusahaan, tidak mungkin semua masalah dan persyaratan dipertimbangkan dan ditangani.

Bahasa pemodelan Arsitektur Perusahaan ArchiMate memberikan representasi yang seragam untuk diagram yang menggambarkan Arsitektur Perusahaan. Ini mencakup konsep untuk menentukan arsitektur yang saling terkait, sudut pandang spesifik untuk pemangku kepentingan terpilih, dan mekanisme penyesuaian bahasa. Ini menawarkan pendekatan arsitektur terintegrasi yang menggambarkan dan memvisualisasikan domain arsitektur yang berbeda dan hubungan serta ketergantungan yang mendasarinya. Kerangka bahasanya menyediakan mekanisme penataan untuk domain arsitektur, lapisan, dan aspek. Ini membedakan antara elemen model dan notasi mereka, untuk memungkinkan penggambaran beragam, berorientasi pemangku kepentingan informasi arsitektur. Bahasa ini menggunakan orientasi layanan untuk membedakan dan menghubungkan Lapisan Bisnis, Aplikasi, dan Teknologi Arsitektur Perusahaan, dan menggunakan hubungan realisasi untuk menghubungkan elemen konkret dengan elemen yang lebih abstrak di seluruh lapisan ini.
1.3 Kesesuaian
Bahasa ArchiMate dapat diimplementasikan dalam perangkat lunak yang digunakan untuk pemodelan Arsitektur Perusahaan. Untuk keperluan standar ini, persyaratan kesesuaian untuk implementasi bahasa yang diberikan dalam bagian ini berlaku. Implementasi yang sesuai:

1. Harus mendukung struktur bahasa, metamodel generik, hubungan, lapisan, lintas-lapisan dependensi, dan elemen lainnya sebagaimana ditentukan dalam Bab 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, dan 13
2. Harus mendukung ikonografi standar sebagaimana ditentukan dalam Bab 4, 5, 6, 7, 8, 9, 10, 11, dan 13, dan diringkas dalam Lampiran A
3. Harus mendukung mekanisme sudut pandang sebagaimana ditentukan dalam Bab 14
4. Harus mendukung mekanisme penyesuaian bahasa sebagaimana ditentukan dalam Bab 15 dalam
cara implementasi yang ditentukan
5. Harus mendukung hubungan antar unsur sebagaimana ditentukan dalam Lampiran B
6. Dapat mendukung contoh sudut pandang yang dijelaskan dalam Lampiran C Pembaca disarankan untuk memeriksa situs web Open Group untuk kesesuaian tambahan dan persyaratan sertifikasi yang merujuk pada standar ini.

1.4 Referensi Normatif
Tidak ada

1.5 Terminologi
Untuk keperluan standar ini, definisi terminologi berikut berlaku: Dapat Menjelaskan fitur atau perilaku yang mungkin tersedia bagi pengguna. Barang-barang yang sudah usang yang diidentifikasi sudah tidak digunakan lagi dapat dihapus di versi standar ini selanjutnya. Implementasi-didefinisikan
Menjelaskan nilai atau perilaku yang tidak ditentukan oleh standar ini tetapi dipilih oleh
pelaksana alat perangkat lunak. Nilai atau perilaku dapat bervariasi di antara implementasi yang sesuai dengan standar ini. Seorang pengguna tidak harus bergantung pada keberadaan nilai atau perilaku. Implementor harus mendokumentasikan nilai atau perilaku sedemikian rupa sehingga dapat digunakan dengan benar oleh pengguna. Dapat Menjelaskan fitur atau perilaku yang opsional. Untuk menghindari ambiguitas, kebalikan dari "mungkin" dinyatakan sebagai "tidak perlu", bukannya "mungkin tidak". Usang Fitur-fitur tertentu sudah usang, yang artinya dapat dipertimbangkan untuk penarikan dalam versi mendatang dari standar ini. Mereka dipertahankan karena penggunaannya yang luas, tetapi penggunaannya tidak disarankan.
Harus Menjelaskan fitur atau perilaku yang merupakan persyaratan. Untuk menghindari ambiguitas, jangan gunakan "harus" sebagai alternatif "harus". Tidak akan Menggambarkan fitur atau perilaku yang merupakan larangan mutlak.
Harus Menjelaskan fitur atau perilaku yang direkomendasikan tetapi tidak diperlukan.
Akan Sama artinya dengan "harus"; "Harus" adalah istilah yang disukai.

1.6 Arah Masa Depan
Tidak ada