Anda di halaman 1dari 39

MAKALAH

ENTERPRISE ARCHITECTURE

BASIC ENTERPRISE ARCHITECTURE METHODOLOGY

DOSEN PENGAMPU : Bayu Rianto, S.SI.,M.Kom.

Kelompok 8 :

Febri Aditia (403201010012)

Rifky Rivaldi (403201010038)

M. Ridho Firdaus (403201010062)

PROGRAM STUDI SISTEM INFORMASI

FAKULTAS TEKNIK DAN ILMU KOMPUTER

UNIVERSITAS ISLAM INDRAGIRI

2022
KATA PENGANTAR

Puji syukur kami ucapkan kehadirat Allah SWT atas segala rahmat-Nya
sehingga makalah ini dapat tersusun sampai dengan selesai. Tidak lupa kami
mengucapkan terima kasih terhadap bantuan dari pihak yang telah berkontribusi
dengan memberikan sumbangan baik pikiran maupun materinya.
Penulis sangat berharap semoga makalah “Basic Enterprise Architecture
Methodology” dapat menambah pengetahuan dan pengalaman bagi pembaca.
Bahkan kami berharap lebih jauh lagi agar makalah ini bisa pembaca praktekkan
dalam kehidupan sehari-hari. Bagi kami sebagai penyusun merasa bahwa masih
banyak kekurangan dalam penyusunan makalah ini karena keterbatasan
pengetahuan dan pengalaman kami.
Untuk itu kami sangat mengharapkan kritik dan saran yang membangun dari
pembaca demi kesempurnaan makalah ini.
Tembilahan, 23 April 2022

Penyusun

ii | P a g e
DAFTAR ISI
BAB I Pendahuluan ....................................................................................... 1
1.1 Latar Belakang ......................................................................................... 1
1.2 Rumusan Masalah .................................................................................... 2
1.3 Tujuan Penulisan ...................................................................................... 2

BAB II Pembahasan ...................................................................................... 3

2.1 BEAM ...................................................................................................... 4


2.1.1 BEAM Basics................................................................................... 4
2.1.2 BEAM Basics 2................................................................................ 8
2.1.3 Object Basics 3 - Four Comparable Assertion Structures................ 8
2.1.4 Architecture Basics .......................................................................... 9
2.1.5 Architecture Basics 2 ....................................................................... 10
2.1.6 Enterprise Architecture Basics ......................................................... 11
2.2 Executive Overview ................................................................................. 13
2.2.1 Advantages of the BEAM Umbrella ................................................ 14
2.2.2 BEAM Business Intelligence Capability Uses EA for Drill Down
and Roll Up of Budgets, Priorities, Performance, Production
Levels............................................................................................... 15
2.2.3 BEAM for EA Governance .............................................................. 16
2.2.4 GEM Function – Enterprise Intelligence ......................................... 17
2.2.5 BEAM Function – Migrating from As-Is to ToBe .......................... 18
2.2.6 BEAM Supports the FEA and the PMA .......................................... 19
2.2.7 BEAM Spiral Life Cycle Support for Standards, Regulations, and
Legislation ....................................................................................... 20
2.3 Technical Overview ................................................................................. 21
2.3.1 EMM 3 – Extended Enterprise Architecture (EA) + ....................... 22
2.3.2 BEAM Delivers Capabilities ........................................................... 24
2.3.3 Typical Manually Controlled Role-Based Security ......................... 25
2.4 BEAM Procedure ..................................................................................... 26
2.4.1 BEAM – Procedural Flow ............................................................... 27

iii | P a g e
2.4.2 BEAM – Procedure Steps ................................................................ 29
2.4.3 Technology Insertion/Refreshment Process Flow ........................... 30
2.4.4 Technology Insertion/Refreshment Procedure................................. 30

BAB III Penutup ............................................................................................ 32

3.1 Kesimpulan .............................................................................................. 32


3.2 Saran ........................................................................................................ 32

Daftar Pustaka ............................................................................................... 33

DAFTAR GAMBAR

Gambar 1 High Level BEAM Process Steps .................................................. 5

Gambar 2 What BEAM Integrates and Why ................................................... 6

Gambar 3 BEAM Basics .................................................................................. 7

Gambar 4 BEAM Basics 2 ............................................................................... 8

Gambar 5 Object Basics 3 ................................................................................ 9

Gambar 6 Architecture Basics ......................................................................... 9

Gambar 7 Architecture Basics 2 ...................................................................... 10

Gambar 8 Open Standard EA and IT Management Repository Elements ....... 12

Gambar 9 BEAM Improvement Management Environment ........................... 12

Gambar 10 Business and IT workers would supply for BEAM ...................... 13

Gambar 11 BEAM for EA Governance ........................................................... 16

Gambar 12 Enterprise Intelligence................................................................... 17

Gambar 13 Migrating Architecture “As-Is” to “ToBe” ................................... 18

Gambar 14 BEAM Methodology Structure ..................................................... 19

Gambar 15 BEAM Spiral Life Cycle Support for Standard, regulations and
legislation ......................................................................................................... 20

iv | P a g e
Gambar 16 BEAM Process .............................................................................. 21

Gambar 17 MDEM Repository ........................................................................ 22

Gambar 18 BEAM and GEM MDEM Repository Elements ........................... 23

Gambar 19 Enterprise Capabilities Document................................................. 24

Gambar 20 BEAM Delivers Capabilities......................................................... 25

Gambar 21 Typical Manually Controlled Role-Based Security ...................... 26

Gambar 22 BEAM Based Security for Internal Control .................................. 26

Gambar 23 BEAM Project Gantt Chart ........................................................... 27

Gambar 24 BEAM Procedural Flow ................................................................ 28

Gambar 25 BEAM Procedures Steps ............................................................... 30

Gambar 26 Technology Insertion Process Flow .............................................. 31

v|Page
BAB I

PENDAHULUAN

1.1 Latar Belakang


Enterprise Architecture terbentuk dari 2 suku kata yaitu Arsitektur dan
Enterprise. Arsitektur merupakan suatu perencanaan yang ditampilkan dengan
model dan gambar berdasarkan komponen dari sesuatu dengan berbagai sudut
pandang (Surendro, 2007). Sedangkan Enterprise adalah suatu area aktivitas dan
tujuan dalam suatu organisasi atau beberapa organisasi dimana terdapat pertukaran
informasi dan sumberdaya lainnya (Bernard, 2005:31). Dari definisi tersebut,
Enterprise Architecture merupakan kegiatan pengorganisasian data yang dihasilkan
oleh organisasi yang kemudian dipergunakan untuk mecapai tujuan proses bisnis
dari organisasi tersebut (Mutyarini & Sembiring, 2006).
Dasar penggunaan konsep Enterprise Architecture didalam sebuah perusahaan
atau organisasi adalah adanya kebutuhan organisasi dalam membangun sistem
informasi untuk memisahkan data, proses infrastruktur teknologi, sumber daya
manusia, waktu, dan motivasi dalam suatu kerangka kerja Enterprise Architecture
(Zachman, 2003). Kebutuhan pemisahan komponen informasi yang berjalan dalam
suatu perusahaan dimaksudkan untuk menghindari pengulangan data, proses, dan
kesalahan identifikasi kebutuhan teknologi yang berjalan dalam suatu sistem
informasi agar berjalan secara efektif dan efisien.
Pada saat ini Enterprise Architecture (EA) belum ada yang sesuai dengan acuan
yang baku dan menghasilkan blueprint yang konkrit dengan kebutuhan bisnis
perusahaan. Acuan yang baku dalam perencanaan EA bertujuan agar kebutuhan
perusahaan agar dalam bekerja, kita bisa bersinergi satu sama lain.
BEAM (Basic Enterprise Architecture Methodology) merupakan salah satu
metodologi dalam Enterprise Architecture. BEAM adalah prosedur terperinci untuk
mendefinisikan arsitektur perusahaan yang dimaksudkan agar sesuai dengan
Perusahaan berkembang. BEAM berfungsi untuk pengembangan, operasional dan
pemeliharaan arsitektur enterprise dalam organisasi perubahan.

1|Page
Makalah ini secara garis besar membahas tentang BEAM (Basic Enterprise
Architecture Methodology) dalam merancang EA (Enterprise Architecture) agar
menyelaraskan proses bisnis pada suatu organisasi/perusahaan.

1.2 Rumusan Masalah


1. Apa itu BEAM ?
2. Apa fungsi dari metodologi BEAM ?
3. Bagaimana penggunaan BEAM dalam merancang EA?

1.3 Tujuan Penulisan


1. Untuk mengetahui metodologi BEAM.
2. Untuk mengetahui fungsi dari metodologi BEAM.
3. Untuk mengetahui penggunaan metodologi BEAM dalam merancang
arsitektur enterprise.

2|Page
BAB II

PEMBAHASAN

2.1 BEAM (Basic Enterprise Architecture Methodology)


BEAM adalah subset yang dapat disekusensi publik dari metodologi General
Enterprise Management (GEM) One World Information System.
Apa itu General Enterprise Management (GEM) methodology? GEM
menyediakan "Daftar Isi" dan "Indeks" yang terintegrasi dan terus berkembang
untuk perusahaan. BEAM membangun Daftar Isi dan Indeks perusahaan dan
membantu membangun mekanisme yang mengintegrasikannya, menggunakannya
untuk manajemen keamanan, manajemen keahlian, dan kesadaran situasional, dan
menjaganya tetap up to date (terbaru).
Kenapa menggunakan GEM? Banyak Eksekutif organisasi seperti Senior
Manajer, Manajer, Pekerja, Staf, dll., tidak akan menyukai informasi tidak tepat
yang mereka butuhkan untuk melakukan pekerjaan mereka dengan baik dan
membuat keputusan yang baik. GEM dapat membantu perusahaan untuk
menyelesaikan masalah tersebut . GEM juga dapat membantu beragam jenis
perusahaan baik Pemerintah, Komersial, Nirlaba, Komunitas, atau Individu, untuk
mencapai tujuan.
BEAM adalah prosedur terperinci untuk mendefinisikan arsitektur perusahaan
yang dimaksudkan agar sesuai dengan perusahaan yang berkembang. BEAM
merupakan superset dari pendahulunya yaitu Kerangka Kerja Zachman yang
populer untuk EA, Spewak EA Planning Methodology, dan Dod Architecture
Framework. BEAM dimaksudkan untuk memberikan dasar bagi manajemen
perusahaan penuh, dengan memanfaatkan ekstensi BEAM dari struktur dan konten
EA yang khas sebagai titik awal dari basis pengetahuan perusahaan.
BEAM mendukung ISO 9000 kualitas pendukung di perusahaan, bersama
dengan "maturity" lainnya seperti lima tingkat maturity dari Software Engineering
Institute’s Software, System, Acquisition and other Capability Maturity Model
(CMM) and CMM-Integrated (CMMI). BEAM secara khusus mendukung ISO
9000 – Delapan Prinsip Manajemen Mutu:

3|Page
1. Customer Focus
2. Leadership
3. Involvement of People
4. Process Approach
5. System Approach to Management
6. Continual Improvement
7. Factual Approach to Decision Making
8. Mutually Beneficial Supplier Relationships

2.1.1 BEAM Basics


Apa itu BEAM ? BEAM adalah prosedur alur kerja terperinci untuk
melangkah organisasi melalui komprehensif proses pengembangan EA, operasi,
dan pemeliharaan, sebagai bagian dari alur prosedur kerja yang lebih besar untuk
manajemen siklus hidup seluruh organisasi. BEAM dirilis di bawah lisensi
publik untuk penggunaan nonkomersial (misalnya, gratis untuk penggunaan alih
daya oleh pemerintah, akademisi dan organisasi lainnya).
Kenapa menggunakan Beam?
- BEAM adalah satu-satunya metodologi EA lengkap (yaitu, prosedur
alur kerja) yang tersedia, secara komersial atau sebaliknya.
- BEAM menyediakan sarana untuk simultan FEA, CCA, GPRA, GPEA,
CMM/CMMI, dan kesesuaian ISO-9000.
- BEAM mendukung kelima inisiatif PMA di seluruh pemerintah.
- BEAM didasarkan pada lebih dari dua dekade penelitian dan
pengalaman operasional di pemerintahan dan industri.
- Setiap organisasi menengah hingga besar yang khas sudah melakukan
kegiatan di dalam Alur kerja BEAM – BEAM terutama mengatur dan
mengintegrasikan kegiatan operasi kontrol, dan data.
- BEAM dapat dilakukan oleh internal resources and/or by
commercial/contracted/outsourced resources.

4|Page
Bagaimana Menggunakan Beam?

- Daftar BEAM untuk penggunaan non-komersial secara gratis.


- Tentukan BEAM sebagai metodologi EA yang Anda butuhkan dalam
Kontrak EA dan Perintah Tugas Anda.
- Menerima pelatihan resmi di BEAM atau menemukan penyedia
layanan BEAM komersial berlisensi.
- Menetapkan atau memperoleh teknologi untuk mendukung BEAM.
- mengimplementasikan proyek BEAM untuk siklus EA pertama
(Contoh Proyek)
• Tugas Survei Situs – 1 bulan.
• Arsitektur Bisnis Awal dan Tugas Kasus Bisnis EA – 2 bulan
lebih.
• Tugas Arsitektur Bisnis Penuh (BRM + PRM) – 2 bulan lebih.
• Tugas EA Penuh (BRM, PRM, SRM, DRM, TRM) – 4 bulan
lebih.
- Menerapkan alur kerja operasi BEAM berulang untuk pemeliharaan EA
berikutnya.
- Memperluas BEAM untuk kegiatan dan aplikasi fungsi bisnis lainnya.
- Ekstensi GEM BEAM (Layanan Komersial dan Dukungan dari
Penyedia Layanan GEM berlisensi).

Gambar 1 High Level BEAM Process Steps

5|Page
High Level BEAM Process Steps
1. Map the organization and its environment
1.1. Inventory, ID, and Arrange Business Functions, Organizations, and
Locations
1.2. Identify and ID the Assignment of Functional Responsibility
2. Map the organization operations and resources
2.1. Inventory, ID, and Organize Functional References, Data,
Tools/Technology, and
Standards
2.2. Inventory, ID, and Organize Goals, Objectives, Performance
Measures, and Strategies
2.3. Inventory, ID, and Organize Funded and Unfunded Plans for
Recurring Operations and
New Initiatives
2.4. Collect identified EA information
3. Perform and improve resource management and operations
3.1. Perform Function, Program, and Project Activities
3.2. Monitor, Assess, Report, and Adjust Performance
3.3. Monitor, Assess, Report, and Adjust Enterprise

Gambar 2 What BEAM Integrates and Why

6|Page
Gambar 3 BEAM Basics

Elemen dasar model, atau jenis peta apa pun yang mewakili realitas yang
dirasakan atau factual adalah konsep, kasus mereka, dan hubungan mereka
(yaitu, interfaces). Konsep (konseptual generalisasi, peristiwa, hal-hal bernama,
dll.) dihubungkan oleh hubungan mereka dan membentuk sebuah pernyataan.
The reticular (tidak mirip seperti net) ikat dari pernyataan nyata, mungkin-nyata,
dan tidak nyata membentuk pengetahuan seseorang atau kelompok. Dengan
demikian, model tidak hanya menggambarkan bahwa dua konsep ini saling
terkait, tetapi mengidentifikasi bagaimana konsep-konsep ini saling terkait.
Proposisi adalah pernyataan yang menegaskan atau menyangkal sesuatu,
dan merupakan pernyataan yang dianggap sebagai kebenaran. Bentuk lain dari
pernyataan adalah pendapat, dugaan, spekulasi, kontinjensi, kemungkinan, dll.,
Yang mungkin tidak mewakili pengetahuan faktual.

7|Page
2.1.2 BEAM Basics 2

Gambar 4 BEAM Basics 2

Informasi tambahan tentang konsep dan hubungan, Properti mereka,


membantu untuk menggambarkan dan mengidentifikasi konsep dan hubungan,
serta perilaku mereka.
Dalam domain Perpustakaan dan Ilmu Informasi, pendekatan BEAM
menggunakan apa yang dikenal sebagai "faceted classifications", untuk
memungkinkan deskripsi secara dinamis dan sangat kaya untuk menghubungkan
antar konsep.

2.1.3 Object Basics 3 – Four Comparable Assertion Structures


Ontology adalah struktur atau skema basis pengetahuan, dengan cara yang
sama seperti skema model data dari suatu database. Struktur unsur ontology
adalah tiga kali lipat (yaitu, subject/predicate/object, noun/verb/noun,
component/relation/component. Standar tiga kali lipat ini dinamakan Resource
Description Framework (RDF).

8|Page
Gambar 5 Object Basics 3

Pernyataan dapat direpresentasikan sebagai Directed Label Graph, (DLG)


matriks dan parent/child table structure.

2.1.4 Architecture Basics

Gambar 6 Architecture Basics

Strukturnya diberi diagram menggunakan “directed labeled graph” - DLG,


ditunjukkan di sini dengan persyaratan minimal dua komponen berlabel yang
terhubung dengan satu garis panah searah berlabel.

9|Page
Properti struktur didokumentasikan dalam format yang sekarang dikenal
sebagai “resource description framework” – RDF, ditetapkan sebagai standar
oleh W3C. RDF adalah dasar untuk peran objek pemodelan dan pemodelan data
yang digunakan dalam semantik dan manajemen data, dan untuk ontologi
pemodelan yang digunakan dalam manajemen pengetahuan. Properti struktur,
termasuk diagram properti, disimpan dalam format RDF, lebih disukai dalam
repositori RDF, atau metadata. Repositori Metadata ini dapat menggunakan
teknologi XML, tabular, LDAP, atau SQL. Teknologi penyimpanan Repositori
Metadata yang direkomendasikan adalah database XML dengan skema
penyimpanan RDF diimplementasikan sebagai skema Managed Object Facility
(MOF) varian RDF, dengan MOF ditetapkan sebagai standar oleh Object
Management Group. Repositori MOF memiliki fleksibilitas yang diperlukan
untuk menyimpan, memproses, menyajikan, dan memelihara skema dan konten
arsitektur yang terus berkembang.

2.1.5 Architecture Basics 2

Gambar 7 Architecture Basics 2

Arsitektur diwakili di sini secara lebih rinci, dalam kaitannya dengan


teknik dan sains. Arsitektur disajikan di sini sebagai sifat manusia untuk

10 | P a g e
memahami dunia. Nilai arsitektur masuk mengkomunikasikan struktur yang
dirasakan dengan cara yang dapat digunakan sebagai titik awal untuk rekayasa
dan ilmu pengetahuan.
2.1.6 Enterprise Architecture Basics
- Usaha yang bertujuan - sebuah perusahaan - dapat memiliki
inventarisasi yang diketahui dan komponen yang disetujui, tetapi
inventaris bukan arsitektur.
- Komponen inventarisasi yang telah menentukan antarmuka / hubungan
adalah arsitektur perusahaan, "As It Is" pada saat mengidentifikasi
komponen inventaris dan antarmuka apa pun.
- Struktur yang dimaksudkan atau diinginkan dan propertinya adalah
arsitektur "To Be" dibentuk pada suatu waktu.
- Rencana bertahap waktu untuk memperkenalkan, memodifikasi, atau
menghilangkan komponen dari inventaris seperti halnya perusahaan
saat ini, dengan pengenalan yang sesuai, modifikasi, dan / atau
penghapusan antarmuka yang relevan, untuk membentuk tujuan
arsitektur “To-Be”, adalah "Architecture Plan" untuk memigrasikan
perusahaan dari arsitektur "As-Is" untuk arsitektur "To Be".
- Architecture Plan dapat untuk single komponen, single antarmuka,
single properti, atau multiple komponen, antarmuka, dan properti.
- Architecture Plan diimplementasikan sebagai proyek individu atau
dikumpulkan dan dengan demikian memerlukan kontrol manajemen
proyek (yaitu, kontrol pada produksi jadwal, anggaran produksi, dan
kualitas produk / layanan) dengan agregasi ke dalam program,
kemudian ke portofolio, dan kemudian ke dalam strategi.

11 | P a g e
Gambar 8 Open Standard EA and IT Management Repository Elements

Repositori MOF, menampilkan arsitektur perusahaan dan komponen


manajemen operasi TI.

Gambar 9 BEAM Improvement Management Environment

Diagram ini menggambarkan jenis informasi yang diperlukan untuk


mengelola upaya peningkatan tersebut. Metodologi GEM memberikan dasar
yang kuat untuk mengelola jenis informasi ini dan kegiatan yang sesuai. Proyek

12 | P a g e
yang terkait langsung dengan misi dan tujuan organisasi bekerja dengan produk
informasi dalam kotak yang ditunjukkan dalam diagram, untuk mengelola
elemen tebal dalam cakupan garis besar manajemen strategis.
Setelah proyek direncanakan, pelaksanaan proyek membutuhkan
pelacakan, analisis, dan melaporkan peristiwa dari waktu ke waktu. Hal ini
diperlukan untuk mengidentifikasi dan menyelesaikan varians dari anggaran
proyek (resource plan) atau jadwal (time plan).
Agar perencanaan dan pelacakan proyek dilakukan secara efektif dan
efisien, terutama dalam upaya terdistribusi, teknologi yang menghubungkan
kedua proses manajemen bersama-sama harus tersedia dan dapat digunakan.

Gambar 10 Business and IT workers would supply for BEAM

"Aspek" informasi yang dikumpulkan dan diatur oleh BEAM


diilustrasikan di sini. Masing-masing aspek mewakili akar dari "katalog"
hierarkis dari hal-hal semacam ini.

2.2 Executive Overview


GEM adalah kerangka kerja "management solutions" yang terbukti merupakan
dasar untuk desain dan implementasi solusi yang konsisten.
GEM adalah generalisasi dan integrasi dari beberapa proses yang ada di semua
fungsi perusahaan, dalam semua manajemen perusahaan, dan merupakan

13 | P a g e
peningkatan proses yang telah digunakan selama berabad-abad. Melalui integrasi
ini, GEM menyediakan metode yang konsisten untuk analisis dan integrasi bisnis
perusahaan, manajemen, sistem, nilai, dan subjek lainnya. Dokumentasi analisis
dan integrasi ini dapat dimuat ke dalam basis pengetahuan multi-tujuan yang
merupakan bagian dari desain GEM. Implementasi integrasi ini menghasilkan
rantai nilai berbasis pengetahuan aplikasi alur kerja yang menjangkau batas
fungsional dan perusahaan.
Konsep dan desain di balik GEM kembali lebih awal dari 35 tahun untuk
"connection model" ekstensi populer untuk "systems model". Connection model
kemudian berganti nama menjadi “generalized object model”. Model objek awal
ini ini sebanding dengan standar industri saat ini yaitu Metaschema Object yang
didefinisikan bersama oleh OpenGroup dan Object Management Group (OMG)
sebagai dasar untuk struktur dan manajemen banyak informasi teknologi
modern.Metodologi GEM, repositori, dan desain aplikasi telah dikembangkan
selama 21 tahun terakhir sebagai teknologi informasi telah berkembang selama
periode tersebut.

2.2.1 Advantages of the BEAM Umbrella


BEAM dapat digunakan untuk mendukung, mengintegrasikan,
menggabungkan, atau menghilangkan.
- IT Architecture Management
- IT Program, Project, Task, Event Management
- System and Software Engineering Life Cycle Management
- System/Software Requirement Specification Management
- Requirement Management
- Independent Verification and Validation (IV&V) of Requirements,
Design, and Development
- A76 Outsourcing Studies
- Organization And Function Management (Staffing and Structure,
Realignment, Reorganization, Relocation, Mergers, Acquisitions, Task
Forces, BPR, etc.)

14 | P a g e
- Quality Management (Six Sigma, TQM, etc.)
- Maturity Management (e.g., ISO-9002, CMM, CMMI)
- Human Capital Knowledge Management (i.e., Building individual and
collective knowledge base, identifying skills available, identifying
skills required, identifying skills gap, driving training management and
recruiting)
- Functional strategies, plans, and budgets tracked through to completion
- Expenditures traced back to driving missions, goals, objectives, and
strategies.
- Reference Management (i.e., Policies, Processes, Procedures,
Templates, Standards, Tools).

2.2.2 BEAM Business Intelligence Capability Uses EA for Drill Down and
Roll Up of Budgets, Priorities, Performance, Production Levels
Fungsi dan Penggunaan Fitur Drill Down dan Roll-Up BEAM:
- Asset Distribution Requirements
- Asset Access Control and Information Requirements
- Summaries, aggregations, and details concerning Business Functions,
Priorities, Budget
- Gives the ability, as a business intelligence technique, to explain to
anyone (e.g., Congress, OMB) the impact of funding changes (e.g., if
you budget this agency XXX dollars you will get these outputs from
our mission area in these quantities, in these time frames, with these
qualities, etc., as in GPRA support.)

2.2.3 BEAM for EA Governance

15 | P a g e
Gambar 11 BEAM for EA Governance

BEAM memungkinkan perusahaan untuk menyelesaikan banyak masalah


EA terberatnya melalui implementasi repositori terintegrasinya. Diagram ini
menggambarkan perusahaan besar dan kegiatan manajemen fungsional yang
mendukung lingkungan BEAM, sebagai sistem loop tertutup.
Elemen diagram yang putus-putus mewakili komponen GEM, di luar
cakupan BEAM.

2.2.4 GEM Function – Enterprise Intelligence

16 | P a g e
Gambar 12 Enterprise Intelligence

Dalam GEM, Enterprise Intelligence adalah kumpulan dari hal-hal yang


dirasakan, dirasakan, dan direkam, diperlakukan sebagai sumber daya, yang
memandu keputusan perusahaan dalam menanggapi perubahan dalam situasi
yang dipantau. Sumber daya intelijen ini paling baik dikelola secara keseluruhan,
sehingga memberikan terintegrasi pernyataan (misalnya, fakta, pendapat,
kontinjensi, persyaratan) untuk keputusan dan tanggapan.
GEM mengkategorikan dan menyusun kecerdasannya dalam hal
pertanyaan dan jawaban dasar manusia dari: di mana, siapa, apa, mengapa,
bagaimana, kapan, berapa banyak, seberapa sering, untuk berapa lama, kualitas
apa, pada tahap apa, dll. Kategori intelijen GEM diberi nama: Location,
Organization, Organization Unit, Function, Process, Resource, and
Requirement. GEM digunakan untuk mengumpulkan, mengidentifikasi,
menggambarkan, menghubungkan, mengontrol, dan menyebarkan informasi
tentang subjek dalam kategori ini.

2.2.5 BEAM Function – Migrating from As-Is to ToBe

17 | P a g e
Gambar 13 Migrating Architecture “As-Is” to “ToBe”

Management : Resolusi yang bertujuan kompleksitas, inkonsistensi, dan


kekacauan dalam ilmu pengetahuan, masyarakat, dan persepsi menjadi sistem
tatanan dinamis yang relatif terkontrol. Perpindahan dari Masalah Saat Ini ke
Masalah yang Terpecahkan, atau dari Situasi As-Is ke To-Be situasi.
Sebuah perusahaan adalah "usaha yang bertujuan", dan dengan demikian
dapat mencakup tujuan (misalnya, berorientasi tujuan) usaha bangsa, koleksi
bangsa, organisasi, rantai organisasi formal dan informal terkait, pasar,
masyarakat, kelompok, dan / atau individu. Masing-masing upaya ini memiliki
"arsitektur" As-Is pada tingkat kelengkapan tertentu.
Bagian dari arsitektur perusahaan adalah mendefinisikan bagaimana
memindahkan arsitektur As-Is perusahaan, dan infrastruktur dan sistem yang
dijelaskan oleh arsitektur itu, "from here to there" dengan cara yang terarah. Ini
berarti mengetahui : 1) where you are, 2) where you want to go, 3) what path
and pace you want to follow, 4) how you’re progressing on the path and pace,
and 5) what adjustments are needed to these.
BEAM dapat menyediakan mekanisme terintegrasi untuk mendukung
kontrol ini dan dengan demikian dapat secara langsung mendukung Federal
Enterprise Architecture (FEA).

18 | P a g e
2.2.6 BEAM Supports the FEA and the PMA

Gambar 14 BEAM Methodology Strucuture

BEAM secara langsung mendukung inisiatif U.S President’s Management


Agenda (PMA) dari "Enhanced eGovernment" dan upaya FEA-nya. Metodologi
GEM yang tersedia secara komersial mendukung persyaratan yang lebih
komprehensif dari PMA penuh.
BEAM dapat langsung diterapkan untuk membantu mencapai hasil yang
diharapkan dari President’s Management Agenda, seperti yang ditunjukkan
dalam diagram ini. Di jantung dukungan BEAM untuk inisiatif PMA adalah
arsitektur perusahaan konforman FEA, memuaskan bagian EA dari inisiatif
PMA "Expanding eGovernment", dengan ekstensi ke dalam infrastruktur dan
pengembangan sistem dan operasi yang mencakup Kerangka Arsitektur DoD
(DoDAF).
Untuk membangun EA, upaya BEAM mengumpulkan dan mengatur
Arsitektur Bisnis, Data, Aplikasi, Teknologi, dan Keamanan, dengan pemetaan
ke infrastruktur dan sistem yang ada dan yang direncanakan. BEAM
memberikan dasar terstruktur untuk membangun dan menggunakan aplikasi
perusahaan secara efektif, efisien, dan aman.

19 | P a g e
Dengan EA di tempat, solusi manajemen untuk inisiatif PMA lainnya, dan
inisiatif manajemen lainnya, sangat disederhanakan. Arsitektur Bisnis BEAM,
sering dalam hubungannya dengan Arsitektur Keamanan, adalah area yang
paling umum digunakan dari Arsitektur Perusahaan yang berasal dari BEAM.
Mereka menyediakan sistem terperinci dan analisis kebutuhan yang digunakan
dalam mendefinisikan data, aplikasi, dan arsitektur teknologi dan dalam
menerapkan kemampuan sistem informasi berikutnya.

2.2.7 BEAM Spiral Life Cycle Support for Standards, Regulations, and
Legislation

Gambar 15 BEAM Spiral Life Cycle Support for Standard, regulations and legislation

Angka ini menggambarkan siklus hidup sumber informasi manajemen


perusahaan. Model perusahaan, yang menunjukkan inventaris objek terkelola
dalam perusahaan, menyediakan pemetaan untuk aktivitas manajemen
berikutnya. Dengan membangun kemampuan manajemen dari model bisnis,
Anda mendapatkan kemampuan untuk mengelola konteks perusahaan secara
keseluruhan. Ini menyediakan mekanisme untuk kesadaran situasional, kegiatan
berbasis pengetahuan, dan optimasi proses (rantai pasokan, rantai nilai).

20 | P a g e
2.3 Technical Overview

Gambar 16 BEAM Process

Produk BEAM EA sebagai dasar untuk Rekayasa dan Operasi Sistem /


Perangkat Lunak.

21 | P a g e
Gambar 17 MDEM Repository

Why Model Driven Enterprise Management (MDEM)? Dengan menggunakan


teknologi standar terbuka modern, MDEM dapat memberi pengguna perusahaan
kecerdasan yang dikelola secara efektif dan efisien yang diperlukan untuk
melakukan dan meningkatkan kegiatan operasional, mengurangi biaya, dan
mengurangi latensi keputusan.
BEAM, bersama dengan mekanisme standar terbuka yang kuat untuk
mengumpulkan dan menghubungkan data dari berbagai alat, menyediakan MDEM.
GEM adalah vendor netral, meskipun kemampuan teknis tertentu diterapkan dalam
implementasi GEM dan operasi selanjutnya disediakan oleh sejumlah vendor
teknologi.

22 | P a g e
Gambar 18 BEAM and GEM MDEM Repository Elements

Elemen BEAM dan GEM Repository, menunjukkan manajemen perusahaan,


arsitektur perusahaan, dan komponen manajemen operasi TI. Standar
digarisbawahi.

2.3.1 EMM 3 – Extended Enterprise Architecture (EA) +

23 | P a g e
Gambar 19 Enterprise Capability Document

BEAM mendukung pengembangan dan pemeliharaan arsitektur


perusahaan. Semua elemen arsitektur perusahaan skala penuh, hanya sedikit
yang berhubungan dengan teknologi informasi. CIO biasanya memiliki
keunggulan di EA karena TI memiliki ekonomi dan efisiensi yang terukur untuk
mendapatkan dalam memenuhi persyaratan bisnis, dan aturan hukum. Tetapi
prospek juga dapat berasal dari fungsional, program atau manajer proyek, atau
eksekutif lain seperti CTO, CKO, CHCO, CSO, CFO, COO, CEO, atau
Presiden.
Namun, eksekutif perusahaan dengan wewenang untuk menerapkan
arsitektur perusahaan penuh, arsitektur perusahaan operasional, dan manajemen
perusahaan cerdas biasanya adalah CEO organisasi, Presiden, Direktur, atau
Komandan Jenderal, sebagai inisiatif Agenda Manajemen Eksekutif.
BEAM memperluas "perencanaan sistem bisnis / perencanaan strategi
informasi" (BSP / ISP) dari IBM Dewey Walker, akhir 1987 Enterprise
Architecture Framework dari IBM John Zachman, dan metodologi Perencanaan
Arsitektur Perusahaan akhir 1992 Steven Spewak.
Sementara BSP / ISP, Zachman Framework, dan metodologi Spewak
sangat berguna dan paralel, dan dapat menggantikan, sebagian besar Fase awal

24 | P a g e
pendekatan BEAM, mereka hanya menyediakan subset dari kemampuan yang
disediakan oleh BEAM. Bagian dari hal ini adalah karena model dasar yang
diterapkan oleh upaya EA sebelumnya. Upaya awal berpola pada model
"relasional" atau "matriks", sedangkan BEAM adalah berpola pada model
"objek", yang memiliki kemampuan inheren untuk bekerja dengan lebih banyak
"dimensi" informasi daripada model relasional. Organisasi yang telah
menggunakan BSP / ISP, Zachman Framework (atau turunannya dari FEA /
FEAF / TEAF, DoDAF / C4ISR, CADM, DIAD, TOGAF, NASCIO, dll.), Atau
Metodologi Spewak (untuk mengejar elemen awal dari Zachman Framework)
dapat menerapkan hasil upaya tersebut langsung ke implementasi BEAM untuk
mempersingkat waktu implementasi BEAM.

2.3.2 BEAM Delivers Capabilities

Gambar 10 BEAM Delivers Capabilities

Diagram ini menggambarkan repositori GEM, dari perspektif Pemerintah


AS, sebagai mekanisme untuk menghubungkan driver bisnis, manajemen
perusahaan, manajemen TI, dan komponen / aset TI. Hal ini dapat melakukan
manajemen yang sama dari setiap kategori aset.

25 | P a g e
2.3.3 Typical Manually Controlled Role-Based Security

Gambar 11 Typical Manually Controlled Role-Based Security

Diagram ini menggambarkan elemen keamanan perusahaan yang


diaktifkan melalui proses manual yang khas. Kelemahan dalam pendekatan ini
menjadi jelas ketika jumlah persyaratan yang ditugaskan meningkat, dan
kebutuhan untuk mengubah tugas menjadi lebih cair.

Gambar 12 BEAM Based Security for Internal Control

26 | P a g e
Diagram ini menggambarkan elemen keamanan perusahaan yang
diaktifkan melalui metodologi GEM dan alat pendukung.

2.4 BEAM Procedure

Gambar 13 BEAM Project Gantt Chart

Pendekatan BEAM mudah diimplementasikan dan dikendalikan melalui teknik


manajemen proyek standar, dan dapat berfungsi sebagai analisis sistem yang
komprehensif dan konsisten yang diperlukan untuk BPR perusahaan dan / atau
fungsional dan implementasi dan operasi kemampuan fungsional berikutnya.

2.4.1 BEAM – Procedural Flow

27 | P a g e
Gambar 14 BEAM Procedural Flow

Diagram ini menggambarkan aliran operasional suatu organisasi


menggunakan siklus hidup BEAM. Ini juga mewakili hubungan multi-level
entitas EA / hubungan atau skema kelas. Prosedur BEAM setara dengan
prosedur manajemen sumber daya. Dalam hal ini, sumber daya yang dikelola
oleh BEAM adalah informasi arsitektur dan secara opsional, informasi tentang
contoh aktual atau yang dimaksudkan dari infrastruktur dan sistem perusahaan
yang dibangun, dioperasikan, dan dipelihara sesuai dengan arsitektur. BEAM
memungkinkan penyempurnaan arsitektur perusahaan di setiap siklus
berikutnya. Informasi yang dibuat, digunakan, dan dimodifikasi dalam prosedur
ini perlu disimpan dalam satu repositori untuk menghindari fragmentasi
arsitektur perusahaan.
Diagram ini juga menggambarkan elemen aliran operasional dari BEAM
Spiral Life Cycle yang dilapisi pada Model FEA OMB tingkat atas dengan PRM-
nya. Elemen BRM, SRM, DRM, dan TRM, ditampilkan sebagai bingkai kuning.

28 | P a g e
Kotak biru muda mewakili kegiatan operasional yang umum bagi sebagian besar
organisasi, baik yang dilakukan secara formal maupun informal.\
Perhatikan bahwa sementara "arsitektur perusahaan", ditampilkan di sini
sebagai komponen BEAM dalam kaitannya dengan model FEA, memiliki
elemen yang sama di semua organisasi, GEM memperluas arsitektur perusahaan
organisasi untuk mendukung proses manajemen perusahaan yang lebih besar
dari organisasi yang aman, manajemen operasi dari intelijen organisasi yang
dikelola. GEM memperluas BEAM, FEA, Zachman Framework, C4ISR /
DoDAF, TOGAF, TEAF, dan kerangka kerja EA lainnya, dan merekatkan upaya
EA ini bersama dengan upaya operasional, menggabungkannya menjadi
kerangka kerja solusi manajemen perusahaan penuh (Enterprise Management).
GEM, sebagai metodologi, repositori, dan aplikasi berbasis repositori dan
repositori terintegrasi, menyediakan aplikasi dinamis model interoperabilitas
federasi untuk komunitas yang menarik (Communities Of Interest) dalam
perusahaan, dan pendekatan manajemen EA dan EM yang komprehensif.
Konsep yang mendasari EA bukanlah hal baru. EA sebagian besar adalah
pengemasan ulang dari apa yang kebanyakan orang telah mengambil "tampilan
perusahaan", atau "pandangan sistem dari organisasi" telah dilakukan selama ini.
Perhatikan bahwa EA dan FEA, melalui BEAM atau sebaliknya, tidak
berakhir dengan sendirinya, tetapi merupakan sarana untuk mendapatkan
kendali atas pengeluaran teknologi, terutama pengeluaran TI. Kontrol atas
pengeluaran teknologi dan pengurangan suboptimisasi ini secara langsung
mendukung penyelarasan Cabang Eksekutif dan operasinya dengan Agenda
Manajemen Presiden, dalam mengejar Manajemen Kinerja dan kepatuhan
terhadap Kinerja dan Hasil Undang-Undang Pemerintah (GPRA).
Jika artefak operasional umum di atas ditinjau oleh orang-orang di luar
komunitas EA dan TI, maka sebagian besar akan mengakui bahwa organisasi
mereka melakukan kegiatan yang menghasilkan artefak operasional umum di
seluruh perusahaan yang kira-kira cocok dengan PRM dan BMR. Lebih sedikit
akan memiliki artefak operasional umum di seluruh perusahaan yang cocok

29 | P a g e
dengan SRM, sementara bahkan lebih sedikit akan memiliki artefak operasional
umum di seluruh perusahaan yang cocok dengan DRM dan TRM.

2.4.2 BEAM – Procedure Steps

Gambar 15 BEAM Procedure Steps

Arsitektur bisnis dikembangkan pada langkah 0 sampai 19 dan 25 sampai


31. Arsitektur data dikembangkan pada langkah 17 sampai 21. Arsitektur
aplikasi dikembangkan pada langkah 18 hingga 21. Arsitektur Teknis
dikembangkan pada langkah 22 hingga 25. Perhatikan bahwa Teknologi
Informasi dianggap hanya sebagai satu kategori dalam TA dan tidak diberikan
pertimbangan dalam BA, DA, atau AA.

2.4.3 Technology Insertion/Refreshment Process Flow

30 | P a g e
Gambar 16 Technology Insertion Process Flow

Diagram ini menggambarkan fase aktivitas yang terlibat dalam


pengembangan dan penerapan Arsitektur TI dan infrastruktur dan sistem terkait.
Jika membaca bilah bawah dari kanan ke kiri, sebuah organisasi tidak dapat
memperoleh penyebaran di mana-mana (yaitu, VII) dari beberapa kemampuan
TI sampai kemampuan telah berkembang melalui sebagian besar, jika tidak
semua, dari fase sebelumnya (yaitu, I – VI).

2.4.4 Technology Insertion/Refreshment Procedure


Proses peninjauan teknologi untuk penyisipan ke dalam organisasi dapat
menggunakan langkah-langkah berikut.
1. Tentukan Arsitektur Bisnis
2. Tentukan arsitektur data dan aplikasi.
3. Periksa infrastruktur dan sistem teknologi saat ini (As-Is) yang
mendukung pemrosesan data aplikasi untuk operasi bisnis.
Mengidentifikasi persyaratan untuk memasukkan teknologi lain (baik
baru atau umum digunakan) ke dalam infrastruktur atau sistem ToBe.
Rencanakan proyek penyisipan. Awalnya uji penyisipan sebagai
sistem percontohan (yaitu, # 6) di laboratorium. Awalnya menerapkan

31 | P a g e
dan mengoperasikan pilot penyisipan. Uji penyisipan secara
operasional. Mendapatkan penerimaan dari hasil operasional
penyisipan. Sepenuhnya menerapkan penyisipan sebagai sistem
produksi. Mengoperasikan dan memelihara teknologi yang
dimasukkan.
4. Mengidentifikasi komponen teknologi dalam pilot, sistem, dan
infrastruktur yang telah digunakan di beberapa aplikasi, model data,
dan proses bisnis.
5. Daftarkan teknologi percontohan dan operasional yang sukses di
TRM yang cocok untuk sistem produksi, dan minta pengembang
sistem / infrastruktur masa depan menentukan kategori TRM
teknologi dalam rencana dan desain awal mereka.
6. Mengembangkan dan menguji sistem percontohan menggunakan
adopsi awal dan teknologi standar yang digunakan di laboratorium.
7. Identifikasi teknologi dalam pilot yang perlu di prototipe di
laboratorium namun yang tampaknya memenuhi persyaratan yang
unik dan umum.
8. Sertakan teknologi yang berhasil di prototipe yang digunakan di TRM
yang cocok untuk "Next Generation" dan sistem percontohan.
9. Mengembangkan dan prototipe sistem menggunakan R&D, pra-
standar, dan teknologi standar baru di laboratorium.
10. Mengidentifikasi teknologi dalam prototipe yang membutuhkan R&D
dan standardisasi lebih lanjut.
11. Sertakan teknologi pra-standar yang berhasil di prototipe di TRM
yang cocok untuk prototipe dan pilot masa depan.
12. Bekerja dengan para peneliti untuk melakukan Demonstrasi
Teknologi Canggih sebelum standardisasi teknologi dan mendaftar
dengan sukses, teknologi yang ditingkatkan di TRM yang sesuai
untuk prototyping dan piloting sistem masa depan.

32 | P a g e
BAB III

PENUTUP

3.1 Kesimpulan
BEAM menyediakan prosedur langkah demi langkah yang komprehensif untuk
menjalankan organisasi, kelompok, atau orang melalui inventaris, identifikasi,
kategorisasi, dan manajemen selanjutnya dari hal-hal yang penting bagi mereka.
BEAM menyediakan proses dan produk informasi yang dibutuhkan untuk
manajemen arsitektur perusahaan.
BEAM dapat digunakan untuk berbagai tujuan di luar mengembangkan
arsitektur perusahaan dan portofolio TI, untuk memasukkan penyediaan dasar Basis
Pengetahuan Perusahaan untuk :
- Security Management
- Knowledge/Expertise Management
- Real-Time Situational Awareness
- Business Process Reengineering
- IT Design/Development/Operations
- Outsourcing/Reorganization/Realignment/Relocation Studies
- Performance Management of Enterprise and Functional Missions

3.2 Saran
Penulis menyadari bahwa dalam pembuatan makalah ini mengalami banyak
kesalahan dikarenakan keterbatasan dalam referensi materi. Tentunya terhadap
penulis, makalah di atas masih banyak ada kesalahan serta jauh dari kata sempurna.
Adapun nantinya penulis akan segera melakukan perbaikan susunan makalah
ini dengan menggunakan pedoman dari beberapa sumber dan kritik yang bisa
membangun dari para pembaca.

33 | P a g e
DAFTAR PUSTAKA
M.Scout, George. Management Information System for Enterprise Information
System. 2003
I. Supriana, Analisis Perbandingan Komponen Dan Karakteristik Enterprise
Architecture Framework. Konf. Nas. Sist. dan Inform., 2011.
Roy Roebuck, Basic Enterprise Architecture Methodology. OWIS. 2004

34 | P a g e

Anda mungkin juga menyukai