bab ii landasan teori - thesis.binus.ac.idthesis.binus.ac.id/doc/bab2/tsa-2013-0030 bab 2.pdf ·...
TRANSCRIPT
5
BAB II
LANDASAN TEORI
2.1. Enterprise
ISO/IEC 42010:2007 mendefinisikan arsitektur sebagai kumpulan organisasi
yang memiliki seperangkat tujuan.Sebagai contoh, sebuah enterprise dapat berupa
lembaga pemerintah, sebuah perusahaan secara keseluruhan, sebuah bagian dalam
perusahaan, sebuah departemen, atausebuah rangkaian organisasi yang terpisah
secara geografis dan dihubungkan oleh kepemilikan bersama. TOGAF (The Open
Group, 2011, p. 1.2) (The Open Group, 2009, p. 5)
Senada dengan definisi di atas.U.S. Cencus Bureau mendefinisikan sebuah
enterprise adalah organisasi bisnis terdiri dari satu atau lebih perusahaan domestik
yang ditentukan di bawah kepemilikan atau kontrol bersama.(U.S. Census Bureau,
2012)
Berdasarkan kepada definisi di atas, maka enterprise merupakan organisasi
yang memiliki tujuan dan arah dibawah kepemilikan atau kontrol bersama.
2.2. Arsitektur
Perry dan Wolf menyatakan arsitektur berkaitan dengan pemilihan elemen –
elemen arsitektur, interaksinya, dan batasan elemen – elemen tersebut dan
interaksi yang diperlukan untuk memberikan sebuah kerangka untuk memenuhi
6
kebutuhan dan berfungsi sebagai dasar untuk perancangan (Perry & Wolf, Oct
1992, p. 43).
ISO/IEC 42010:2007 mendefinisikan arsitektur sebagai dasar organisasi dari
sebuah sistem, terwujuddalam komponen – komponen,hubungansatu sama lain
dan lingkungan, dan prinsip – prinsip yang mengatur desain dan evolusi. (The
Open Group, 2011, p. 2.2)(The Open Group, 2009, p. 9) (ISO, 2011)
Togaf memiliki 2 definisi arsitektur(The Open Group, 2011, p. 3.8),yaitu:
1. Sebuah deskripsi formal dari sebuah sistem, atau sebuah rencana rinci
mengenai sistem pada tingkat komponen sebagai panduan implementasi.
2. Struktur dari komponen, bagaimana mereka saling terkait, prinsip dan
pedomanyang mengatur desain dan evolusi komponen – komponen
tersebut dari waktu ke waktu.
Berdasarkan kepada definisi di atas, maka arsitektur merupakan sebuah
deskripsi formal sebuah sistem, atau sebuah rencana rinci mengenai sistempada
tingkat komponen yang mendeskripsikan bagaimana komponen – komponen
tersebut saling terkait, dan prinsip – prinsip yang mengatur desain dan evolusi
komponen – komponen tersebut dari waktu ke waktu
2.3. Enterprise Architecture
Arsitektur enterprise merupakan sebuah pendekatan sebagai alat bantuuntuk
pengambilan keputusan di dalam manajemen TI,seperti: keselarasan TI dan bisnis,
keputusan investasi, penilaian kualitas dan peningkatan sistem TI. Arsitektur
enterprisememiliki cakupan luas yang memberikan solusi bagi manajemen TI
secara keseluruhan(Gammelgard, Simonsson, & Lindstorm, 2007, p. 416).
7
Marc Lankhorst et al (al, 2005, p. 3) mendefinisikan arsitektur enterprise
sebagai satu kesatuan utuh prinsip, metode, dan model yang digunakan dalam
desain dan realisasi struktur organisasi, proses bisnis, sistem informasi, dan
infrastruktur sebuah perusahaan.
Dennis A. Stevenson mendefinisikan arsitektur enterprise sebagai sebuah
model lengkap perusahaan, meliputi sebuah master planyang bertindak sebagai
kekuatan mengintegrasikan aspek perencanaan bisnis seperti tujuan, visi, strategi,
dan prinsip – prinsip tata kelola; aspek operasional bisnis seperti istilah bisnis,
struktur organisasi, proses, dan data; aspek otomatisasi seperti sistem aplikasi, dan
database; dan teknologi infrastruktur yang memungkinkan bisnisseperti komputer,
sistem operasi, dan jaringan(Lin & Dyck, 2010, p. 3)(Stevenson, 2003).
2.3.1. Motivasi Arsitektur Enterprise
Pada umumnya organisasi yang dapat mengelola perubahan secara efektif
akan lebih sukses dari pada yang mereka yang tidak dapat mengelola
perubahan secara efektif. Banyak organisasi yang sadar bahwa mereka
membutuhkan peningkatan proses dengan tujuan untuk mengelola perubahan
dengan sukses, tetapi tidak mengetahui bagaimana caranya untuk melakukan
hal tersebut(The Open Group, 2011, p. ch 51.1).
Arsitektur enterprise memiliki dampak yang besar pada efisiensi dan
efektifitas proses bisnis dan produk suatu perusahaan (Lin & Dyck,
2010).Pemberdayaan penggunaan TI yang efektif sebagai basis arsitektur
enterprisedan transparansi bisnis akanmempercepat pengambilan
keputusan(Kamogawa & Okada, 2009, p. 205).Arsitektur enterprise yang baik
8
memungkinkan sebuah organisasi untuk mencapai keseimbangan yang tepat
antara efisiensi TI dan inovasi bisnis.Menurut TOGAF keuntungan –
keuntungan yang akan diperoleh dari arsitektur enterpriseadalah sebagai
berikut (The Open Group, 2011, p. 1.2)(The Open Group, 2009, pp. 6-7):
1. Operasional bisnis yang lebih efisien
a) Lebih rendahnya biaya operasional bisnis.
b) Organisasi menjadi lebih lincah.
c) Lebih rendahnya biaya terhadap manajemen perubahan.
d) Tenaga kerja lebih fleksibel.
e) Meningkatkan produktifitas bisnis.
2. Operasional TI yang lebih efisien
a) Lebih rendahnya biaya pengembangan perangkat lunak, dukungan,
dan perawatan.
b) Meningkatnya protabilitas aplikasi.
c) Meningkatkan interoperabilitas dan manajemen sistem dan
jaringan yang lebih mudah.
d) Meningkatkan untuk mengatasi permasalahan kritis di seluruh
perusahaan, seperti masalah keamanan.
e) Lebih mudahnya proses peremajaan dan pertukaran komponen –
komponen sistem.
3. ROI (Return on Investment)kondisi saat ini yang lebih baik,
mengurangi resiko investasi di masa mendatang.
a) Mengurangi kompleksitas bisnis dan TI.
b) Memaksimalkan ROI bisnis dan infrastruktur TI berjalan.
9
c) Fleksibilitas dalam membuat keputusan untuk membeli, atau
outsourcing bisnis dan solusi TI.
d) Mengurangi keseluruhan resiko dari investasi baru dan biaya –
biaya yang harus ditanggung.
4. Pengadaan yang lebih cepat, sederhana, dan murah.
a) Keputusan membelilebih sederhana, karena informasiyang
mengaturpengadaansudah tersediadalam rencanayang koheren.
b) Proses pengadaanlebih cepat.Memaksimalkan
kecepatanpengadaandan fleksibilitastanpa
mengorbankankoherensiarsitektur.
c) Kemampuan untuk melakukan pengadaan yang heterogen,
beragam vendor dengan sistem terbuka.
d) Kemampuan untuk mengamankan lebih kemampuan ekonomi.
Untuk memaksimalkan manfaat yang diharapkan dari arsitektur enterprise,
maka program untuk meningkatkan tingkat kematangan arsitektur enterprise
perlu diselenggarakan. NASCIO(NASCIO, 2003) menyebutkan manfaat
tersebut adalah sebagai berikut:
Mengurangi redudansi software dan data
Meningkatkan penggunaan bersama informasi perusahaan
Mengurangi kompleksitas system informasi
Keselarasan yang lebih baik terhadap strategi bisnis dan
pengembangan sistem
Reliabilitas yang lebih besar pada saat implementasi dan update
10
Mengurangi keterkaitan pada sumber daya kunci
Meningkatkan akurasi dalam penjadwalan
pengembangan/implementasi perangkat lunak
Prediksi yang lebih akurat terhadap pengembangan dan dukungan
biaya
Penyebaran solusi teknologi yang lebih efisien
Kemampuan yang lebih baik untuk menetapkan tujuan yang realistis
Meningkatkan keselarasan solusi TI dengan strategi bisnis
Meningkatkan ketertelusuran.
2.3.3. Prinsip – Prinsip Arsitektur
Prinsip merupakan aturan dan pedoman umum, dimaksudkan untuk
bertahan dan jarang diubah, yang menginformasikan dan mendukung cara di
mana suatu organisasi mengatur bagaimana memenuhi misinya. (The Open
Group, 2011). TOGAF menyebutkan prinsip – prinsip arsitektur dari sisi
bisnis, data, aplikasi, dan teknologi (The Open Group, 2011, p. ch 23)(Minoli,
2008, pp. 72 - 79)
Adalah berguna memiliki sebuah cara standar untuk mendefinisikan
prinsip – prinsip. Selain pernyataan definisi, setiap prinsip harus memiliki
rasionalisasi dan pernyataan implikasi yang terkait, baik untuk meningkatkan
pemahaman dan penerimaan dari prinsip – prinsip itu sendiri, dan untuk
mendukung kegunaan prinsip – prinsip dalam menjelaskan dan membenarkan
mengapa keputusan tertentu dibuat. Tabel dibawah ini adalah format prinsip –
prinsip yang direkomendasikan TOGAF (The Open Group, 2011, p. ch. 23.3)
11
Tabel 1. Format Tabel Prinsip - Prinsip Arsitektur
Nama Harus merepresentasikan baik esensi peran serta mudah untuk diingat.
Pernyataan Harus singkat dan jelas mengkomunikasikan aturan dasar.
Rasional Harus menyoroti manfaat bisnis dari kepatuhan pada prinsip, menggunakan terminologi bisnis.
Implikasi Harus menyoroti persyaratan, baik untuk bisnis dan TI, untuk melaksanakan prinsip dalam hal sumber daya, biaya, dan aktifitas/tugas.
2.4. Perbandingan Arsitektur Enterprise
Beberapa contoh kerangka yang dapat digunakan untuk mengembangkan
arsitektur enterprise adalah The Open Group Architecture Framework (TOGAF),
Department of Defense Architectural Framework (DoDAF), Zachman Framework
(ZF).Masing – masing kerangka tersebut berbeda dalam hal detail, namun
memiliki kesamaan model konseptual (Glissmann & Sanz, 2011).Berikut ini
adalah tabel perbandingan beberapa arsitektur enterprise berdasarkan tujuan,
masukan, dan hasil (Tang, Han, & Chen, 2004).
Tabel 2. Perbandingan Kerangka Arsitektur (Tang, Han, & Chen, 2004)
ZF 4+1 View FEAF RM-ODP TOGAF DoDAF Tujuan Definisi dan pemahaman arsitektur
P P Y Y Y Y
Proses Arsitektur N N Y N Y Y Dukungan Evolusi Arsitektur
N N Y P Y Y
Analisis Arsitektur Y Y Y Y Y Y Model Arsitektur Y Y Y Y Y Y Timbal Balik Desain P P P P P Y Dasar Pemikiran Desain P P P Y Y P Standarisasi N N P Y Y Y Basis Pengetahuan Arsitektur
N N Y Y Y Y
Kemampuan Memverifikasi Arsitektur
N P N P Y N
Masukan Penggerak Bisnis P P Y P Y Y Masukan Teknologi N N Y P Y Y
12
ZF 4+1 View FEAF RM-ODP TOGAF DoDAF Kebutuhan Bisnis Y Y Y Y Y Y Lingkungan Sistem Informasi
P P Y Y Y Y
Arsitektur Saat Ini P Y Y Y Y Y Kebutuhan Non Fungsional P Y P Y Y P Hasil Model Bisnis Y P Y Y Y Y Model Sistem Y Y Y Y Y Y Model Informasi Y Y Y Y Y Y Model Komputasi Y Y Y Y Y Y Model Konfigurasi Perangkat Lunak
N Y N P Y N
Model Pemrosesan Perangkat Lunak
Y Y Y Y Y Y
Model Implementasi P P P Y Y Y Platforms Y P Y Y Y Y Rancangan Kebutuhan Non-Fungsional
P Y P Y Y P
Rancangan Transisional N N Y N Y Y Rancangan Dasar Pemikiran N P N P P P
Sebuah skema untuk memilih kerangka kerja arsitektur enterprise
dikembangkan oleh (Odongo, Kang, & Ko, 2010).Beberapa perspektif dan
kegunaan kerangka arsitektur enterprise diidentifikasi.Suatu perspektif menjadi
bagian dari satu atau lebih kegunaan.Salah satu kegunaan yang disebutkan adalah
memilih kerangka arsitektur enterprise terbaik untuk pengembangan sistem atau
arsitektur enterprise, dengan perspektif sebagai berikut.
1. Tujuan (Goals), adalah untuk prestasi, keterlibatan, area permasalahan,
kerangka waktu, persyaratan, dan kendala.
2. Masukan (Inputs), masukan arsitektur enterprse menggariskan proses –
proses yang terintegrasi dan tujuan dalam sebuah bisnis perusahaan untuk
menyediakan komponen proses.
3. Keluaran (Outputs/Outcomes), keluaran digunakan untuk memahami
kesenjangan yang ada saat perencanaan untuk lingkungan masa depan
yang lebih baik.
13
4. Pandangan (Views), pandangan adalah penggambaran dari arsitektur yang
lengkap untuk komunikasi, pemahaman arsitektur enterprise, dan
verifikasi sistem.
5. Abstraksi (Abstractions), abstraksi memberlakukan dekomposisi progresif
dan pemeliharaan yang dapat ditelusuri dari rancangan arsitektur
enterprise untuk implementasi rinci.
6. System Development Life Cycle (SDLC), proses SDLC terdiri dari proses –
proses yang didefinisikan, peran, dan tanggung jawab.
7. Pedoman (Guide), pedoman proses mendefinisikan, memelihara, dan
mengimplementasi arsitektur enterprise dengan menyediakan sebuah
pendekatan disiplin kepada manajemen siklus hidup arsitektur enterprise.
8. Kualitas (Quality), perubahan konfigurasi perangkat lunak dan pencapaian
atribut kualitas menegaskan apakah pekerjaan yang baik telah dilakukan.
9. Miscellaneous, perspektif ini mengandung aspek penting yang tidak
dicakup perspektif lain.
10. Persyaratan (Requirements), Menentukan representasi kerangka arsitektur
enterprise, mengurangi resiko, mengijinkan perubahan dan keselarasan,
dan integrasi.
11. Prinsip/Peran (Principles/Rules), mendefinisikan peran mendasar untuk
penggunaan dan penyebaran seluruh sumber daya TI dan aset.
Tabel 3. Skor Kerangka Pengembangan Arsitektur Enterprise
Perspektif/Aspek ZF DoDAF TOGAF FEAF TEAF P1. Tujuan 8 19 21 16 15 P2. Masukan 6 11 12 11 10 P3. Keluaran 14 18 21 16 15 P4. Pandangan 12 8 4 10 8P5. Abstraksi 12 8 2 6 6P6. SDLC 5 9 5 11 9
14
Perspektif/Aspek ZF DoDAF TOGAF FEAF TEAF P7. Pedoman 16 28 27 21 24P8. Kualitas 20 18 18 20 15 P9.Miscellaneous 15 18 15 17 19 P10. Persyaratan 9 13 12 4 5 P11. Prinsip 20 23 23 14 15 Total 138 173 158 147 141
Tujuan TOGAF adalah memberikan sebuah kerangkadesain, evaluasi dan
kerangka untuk membangun arsitektur bagi perusahaan.Elemen kunci TOGAF
adalah TOGAF ADM (Architecture Development Method) yang
menspesifikasikanproses untuk pengembangan arsitektur enterprise.Enterprise
Continuummerupakan sebuah penyimpanan virtual seluruh aset arsitektur yang
meliputi model, pola, dan gambaran arsitektur.TOGAF Resource Basemerupakan
seperangkat sumber daya, pedoman, template dan latarbelakang informasi guna
membantu dalam penggunaan TOGAF.
TOGAF ADM merupakan metodegenerik yang menspesifikasikan
pendekataniterasi untuk pengembangan arsitektur.ADM tidak preskriptif pada
luasnya cakupan, tingkat rincian, luasnya batas waktu atau aset arsitektur untuk
dimanfaatkan.Hal ini dapat ditentukan oleh arsitek untuk proyek tertentu.Fase –
fase yang didefinisikan oleh ADM adalah sebagai berikut.
1. Kerangka dan prinsip awal untuk mendefinisikan dasar arsitektur dalam
sebuah enterprise.
2. Siklus ADM mendefinisikan siklus pengembangan arsitektur
3. Proses manajemen kebutuhan adalah pusat siklus ADM yang
mengidentifikasi, menyimpan dan antarmuka kebutuhan dengan seluruh
fase dalam siklus ADM
15
TOGAF Enterprise Continuummenspesifikasikan sebuah TRM (Technical
Reference Model).TRM merupakan sebuah model yang merepresentasikan sistem
aplikasi, platform aplikasi dan infrastruktur komunikasi serta konektifitasyang
terjadi.TRM juga menggambarkan kualitas layanan yang disediakan oleh sistem.
TOGAF ADM adalah sebuah metodologi komprehensif yang membahas
arsitektur pada tingkat enterpriseserta tingkat sistem individu.Metodologi tersebut
mendukung evolusi arsitektur melaluienterprise continuum sebagai
basispengetahuan. Aktifitas disetiap fase kerangka ADM didefinisikan dengan
baik tetapi meninggalkan fleksibilitasimplementasi guna melatih arsitek
menentukan apa yang dibutuhkansistem dari kemungkinan hasil yang terdefinisi
dengan baik. TOGAF merekomendasikan dokumentasi rancangan pemikiran
untuk melacak desain dan keputusan arsitektur(Tang, Han, & Chen, 2004, p. 6).
Kerangka TOGAF versi 9.1 (The Open Group Architecture Framework)
dipilih karena memberikan metode yang jelas untuk membangun dokumentasi dan
proses arsitektur enterprisedi Kantor Pusat Sekolah Kristen IPEKA.
2.5. TOGAF versi 9.1 (The Open Group Architecture
Framework)
Kerangka pengembangan arsitektur enterpriseKantor Pusat Sekolah Kristen
IPEKA mengacu kepada kerangka TOGAF versi 9.1 (The Open Group
Architecture Framework).TOGAF adalah sebuah kerangka arsitektur yang
menyediakan metoda dan alat untuk membantu penerimaan, produksi,
penggunaan, dan perawatan sebuah arsitektur enterprise.Hal ini berdasarkan pada
16
model proses perulangan didukung oleh best practice dan penggunaan kembali
aset arsitektur yang sudah ada(The Open Group, 2011, p. 2.1).
2.5.1. ADM (Architecture Development Method)
TOGAF mendeskripsikan sebuah metode untuk mengembangkan dan
mengelola siklus hidup dari sebuah arsitektur enterprise yang disebut dengan
Architecture Development Method (ADM)(The Open Group, 2011, p. ch
5.1).ADM adalah inti dari TOGAF untuk memenuhi kebutuhan bisnis dan TI
Sekolah Kristen IPEKA.Gambar di bawah ini adalah tahapan – tahapan dalam
TOGAF ADM(The Open Group, 2011, pp. ch 7 - 16).
17
Gambar 1. TOGAF ADM
2.5.1.1. Preliminary
Tahapan pendahuluan menggambarkan persiapan dan aktifitas awal
yang dibutuhkan untuk memenuhi arahan bisnis untuk arsitektur enterprise
yang baru, meliputi definisi kerangka kerja arsitektur dan definisi prinsip –
prinsip yang dimiliki organisasi.
Tabel 4. Preliminary Catalog, Metrics, Core Diagram
Pedahuluan(Preliminary) Katalog
(Catalogs) Metriks
(Metricts) Diagram Inti
(Core Diagrams) Principles Catalogs - -
18
2.5.1.2. Fase A. Architecture Vision
Tahap visi arsitektur merupakan tahap awal ADM (Architecture
Development Method).Meliputi informasi tentang definisi ruang lingkup,
identifikasi stakeholders, membuat arsitektur visi, dan mendapatkan
persetujuan.
Tabel 5. Architecture Vision Catalog, Metrics, Core Diagram
A. Visi Arsitektur (Architecture Vision) Katalog
(Catalogs) Metriks
(Metricts) Diagram Inti
(Core Diagrams) Stakeholder map matrix - Value Chain Diagram Solution Concept Diagram
2.5.1.3. Fase B. Business Architecture
Mendefinisikan kondisi awal arsitektur bisnis, menentukan model
bisnis atau aktivitas bisnis yang diinginkan berdasarkan skenario bisnis.
Pada tahap ini tools dan method umum untuk pemodelan seperti:
Integration DEFinition (IDEF) dan Unified Modeling Language (UML)
bisa digunakan untuk membangun model yang diperlukan.
Tabel 6. Business Architecture Catalog, Metrics, Core Diagrams
B. Arsitektur Bisnis (Business Architecture) Katalog
(Catalogs) Metriks
(Metricts)Diagram Inti
(Core Diagrams) Organization/Actor Catalog Business Interaction
Matrix Business Footprint Diagram
Driver/Goal/Objective Catalog
Actor / Role Matrix Business Service / Information Diagram
Role Catalog Functional Decomposition Diagram
Business Service / Function Catalog
Product Lifecycle Diagram
Location Catalog Process / Event / Control / Product Catalog
Contract / Measure Catalog
Legend
19
Legend Infrastructure Consolidation Extention Governance Extention Motivation Extention Process Modeling Extension Core Content
2.5.1.4. Fase C. Information System Architecture
Pada tahapan ini lebih menekankan pada aktivitas bagaimana arsitektur
sistem informasi dikembangkan. Pendefinisian arsitektur sistem informasi
dalam tahapan ini meliputi arsitektur data dan arsitektur aplikasi yang akan
digunakan oleh organisasi. Arsitektur data lebih memfokuskan pada
bagaimana data digunakan untuk kebutuhan fungsi bisnis, proses dan
layanan. Teknik yang bisa digunakan dengan yaitu: ER Diagram, Class
Diagram, dan ObjectDiagram.
Tabel 7.Data Architecture Catalog, Metrics, Core Diagrams
C. Arsitektur Data (Data Architecture) Katalog
(Catalogs) Metriks
(Metricts) Diagram Inti
(Core Diagrams) Data Entity / Data Component Catalog
Data Entity / Business Function Matrix
Conceptual Data Diagram
Application Data Matrix Logical Data Diagram Data Dissemination
Diagram
Tabel 8.Application Architecture Catalog, Metrics, Core Diagrams
C. Arsitektur Aplikasi(Application Architecture) Katalog
(Catalogs) Metriks
(Metricts) Diagram Inti
(Core Diagrams) Application Portfolio Catalog
Application / Organization Matrix
Application Communication Diagram
Interface Catalog Role / Application Matrix Application and User Location Diagram
Application Function Matrix
Application Use-Case Diagram
Application Interaction Matrix
20
2.5.1.5. Fase D. Technology Architecture
Membangun arsitektur teknologi yang diinginkan, dimulai dari
penentuan jenis kandidat teknologi yang diperlukan dengan menggunakan
TechnologyPortfolio Catalog yang meliputi perangkat lunak dan
perangkat keras.Dalam tahapan ini juga mempertimbangkan alternatif-
alternatif yang diperlukan dalam pemilihan teknologi.
Tabel 9. Technology Architecture Catalog, Metrics, Core Diagrams
D. Arsitektur Teknologi(Technology Architecture) Katalog
(Catalogs) Metriks
(Metricts)Diagram Inti
(Core Diagrams) Technology Standart Catalog
Application Technology Matrix
Environments and Location Diagram
Technology Portfolio Catalog
Platform Decomposition Diagram
2.5.1.6. Fase E. Opportunities and Solution
Pada tahapan ini lebih menekan pada manfaat yang diperoleh dari
arsitektur enterprise yang meliputi arsitektur bisnis, arsitektur data,
arsitektur aplikasi dan arsitektur teknologi, sehingga menjadi dasar bagi
stakeholder untuk memilih dan menentukan arsitektur yang akan
diimplementasikan.
Tabel 10. Opportunities and Solution Catalogs, Metrics, Core
Diagrams
E. Peluang dan Solusi(Opportunities and Solution) Katalog
(Catalogs) Metriks
(Metricts)Diagram Inti
(Core Diagrams) - - Project Context Diagram Benefit Diagram
21
2.5.1.7. Fase F. Migration Planning
Tahap rencana migrasi menangani yaitu bagaimana memindahkan
arsitektur awal menuju sasaran dengan menyelesaikan rincian
implementasi dan rencana migrasi. Tujuan tahap ini adalah (The Open
Group, 2011, p. ch 14.1):
A. Menyelesaikan roadmap arsitektur dan mendukung implementasi dan
rencana migrasi
B. Memastikan bahwa implementasi dan rencanan migrasi
dikoordinasikan dengan pendekatan enterprise untuk mengelola dan
mengimplementasikan perubahan di dalam keseluruhan perubahan
portfolio enterprise.
C. Memastikan bahwa nilai bisnis dan biaya pekerjaan dan transisi
arsitektur dimengerti oleh stakeholders kunci
2.5.1.8. Fase G. Implementation Governance
Tahap tatakelola implementasi memberikan pengawasan terhadap
pelaksanaan arsitektur. Tujuan tahap ini adalah (The Open Group, 2011, p.
ch 15.1):
Memastikan kesesuaian dengan arsitektur sasaran dengan pelaksanaan
proyek
Melakukan fungsi – fungsi tata kelola arsitektur yang sesuai untuk
solusi dan setiap dorongan implementasi terhadap permintaan
perubahan arsitektur.
22
2.5.1.9. Fase H. Architecture Change Management
Menetapkan rencana manajemen arsitektur dari sistem yang baru
dengan cara melakukan pengawasan terhadap perkembangan teknologi
dan perubahan lingkungan organisasi, baik internal maupun eksternal serta
menentukan apakah akan dilakukan siklus pengembangan arsitektur
enterprise berikutnya.
2.5.1.10. Requirements Management
Manajemen kebutuhan melihat kepada proses mengelola kebutuhan
arsitektur di seluruh ADM. Tujuan dari tahap ini adalah (The Open Group,
2011, p. ch 17.1):
Memastikan bahwa proses kebutuhan manajemen dipertahankan dan
beroperasi untuk keseluruhan tahap ADM yang relevan.
Mengelola kebutuhan arsitektur yang diidentifikasikan selama setiap
eksekusi dari siklus atau sebuah tahap ADM.
Memastikan bahwa kebutuhan arsitektur yang relevan dapat tersedia
untuk dapat digunakan oleh setiap tahapan.
2.5.2. Iterasi TOGAF ADM
1. Iterasi Pengembangan Arsitektur (Architecture Development Iteration).
B. Business Architecture
C. Information System Architecture
D. Technology Architecture
E. Opportunities and Solutions
23
F. Migration Planning
2. Iterasi Rencana Transisi (Transition Planning Iteration)
E. Opportunities and Solutions
F. Migration Planning
3. Iterasi Tata Kelola Arsitektur (Architecture Governance Iteration)
G. Implementation Governance
H. Architecture Change Management
4. Iterasi Kapabilitas Arsitektur (Architecture Capability Iteration)
H. Architecture Change Management
A. Architecture Vision
Preliminary
2.5.3. Artifacts
Artefak adalah produk hasil karya arsitektur yang menggambarkan suatu
aspek arsitektur.Artefak pada umumnya diklasifikasi sebagai katalog (daftar
dari hal), metrik (menunjukkan hubungan antar hal), dan diagram (gambar
dari hal). Suatu penyampaian arsitektur dapat mengandung banyak artefak dan
artefak akan membentuk isi dari Architecture Repository. Artefak
mendeskripsikan Building Block(The Open Group, 2011, p. ch. 33.1)
2.5.4. Building Block
Building Blockmerepresentasikan sebuah komponen (berpotensi dapat
digunakan kembali) bisnis, IT, atau kemampuan arsitektur yang dapat
24
dikombinasikan dengan building blockslainnya untuk menyampaikan
arsitektur dan solusi.
Building Block dapat didefinisikan pada berbagai tingkatan detail,
tergantung pada tahapan pengembangan arsitektur yang telah dicapai.
Misalnya, pada tahap awal, secara sederhana sebuah building block dapat
terdiri dari sebuah nama atau sebuah deskripsi garis besar.Kemudian, sebuah
building block dapat didekomposisi menjadi beberapa building blocks
pendukung dan dapat disertai dengan spesifikasi lengkap(The Open Group,
2011, p. ch. 33.1). Contoh building block misalkan: perwakilan layanan
konsumen, proses penanganan panggilan (baseline), proses penanganan
panggilan (target).
2.5.5. Technical Reference Model (TRM)
TOGAF Foundation Architecture adalah arsitektur dari layanan dan fungsi
generik yang memberikan landasanuntuk arsitektur dan komponen arsitektur
yang lebih spesifik dapat dibangun.Landasan aristektur ini terwujud dalam
model referensi teknis, yang memberikan sebuah model dan taksonomi
platform layanan generik(The Open Group, 2011, p. ch. 43.1.1).
Tujuan
standarisa
ch. 43.1.3
dengan k
tidak men
untuk me
organisas
Dalam
kebutuha
yang mem
Ga
n TRM ada
asi platform
3). Arsitektu
kebutuhan si
ncakup selu
endukung k
si atau kepad
m membangu
an mereka s
menuhi kebu
ambar 2. Tec
alah untuk m
m aplikasi da
ur TI yang be
istem inform
uruh layanan
ebutuhan ap
da industri ve
un sebuah
sendiri dan
utuhan bisnis
chnical Refe
memungkink
an interface
erasal dari T
masi. Pada p
n TRM, mau
plikasi peran
ertikal.
arsitektur, p
memiliki se
s(The Open
erence Mode
kan definisi
terkait(The
TOGAF dapa
rakteknya, b
upun mencak
ngkat lunak
pengguna T
ervices, inte
Group, 2011
el
i terstruktur
Open Group
at berbeda –
banyak arsit
kup layanan
yang spesi
TOGAF haru
erfaces, dan
1, p. ch. 43.3
25
r mengenai
p, 2011, p.
bedasesuai
tektur yang
n tambahan
fik kepada
us menilai
standards
3.1).
26
2.6. Arsitektur Enterprise dan Service Oriented
Architecture (SOA)
Arsitektur enterprise menjadi dasar bagi orientasi layanan sebuah organisasi
karena arsitektur enterprise menghubungkan stakeholders bersama – sama,
memastikan pemenuhan kebutuhan setiap komunitas stakeholders dan setiap
komunitas stakeholders menyadari konteks yang sesuai. Keterhubungan ini
merupakan dasar interoperabilitas dan penggunaan kembali. Tanpa arsitektur
enterprise dapat terjadi peningkatan resiko seperti (The Open Group, 2011, p. 5):
Kelincahan terbatas
Kesulitan mengidentifikasi dan mengorkestrasi layanan SOA
Layanan yang renggang
Tumbuh secara eksponensial tantangan tata kelola
Interoperabilitas layanan SOA yang terbatas
Penggunaan kembali layanan SOA yang terbatas
Terbentuknya beberapa ‘lumbung’ SOA
Kesulitan berevolusi dan mengubah implementasi SOA
Sebuah arsitektur enterprise yang efektif sangat penting untuk kelangsungan
dan kesuksesan bisnis, dan merupakan sarana yang sangat diperlukan untuk
mencapai keunggulan kompetitif melalui TI. TOGAF adalah sebuah metode rinci
dan sekumpulan alat bantu untuk mengembangkan arsitektur enterprise.
Arsitektur enterprise ini merupakan kodifikasi praktek yang baik yang telah
berkembang dalam pekerjaan arsitek enterprise dan TI selama bertahun – tahun.
Arsitektur enterpriseakan membantu arsitek untuk memutuskan dimana dan
bagaimana menggunakan SOA(The Open Group, 2011, p. 6).
27
2.7. Archimate versi 2.0
Archimate merupakan bahasa pemodelan arsitektur enterprise yang
dikembangkan untuk menyediakan sebuah representasi yang seragam dan
mendeskripsikan arsitektur enterprise.Archimate menawarkan pendekatan
arsitektur terintegrasi yang mendeskripsikan dan memvisualisasikan domain
arsitektur yang berbeda dan hubungan serta dependensi yang mendasari.
Peran Archimate adalah menyediakan sebuah bahasa grafik yang
merepresentasikan arsitektur enterprise dari waktu ke waktu (Mis., meliputi
transformasi dan rencana migrasi), serta motivasi dan rasional. Archimate tidak
menyediakan serangkaian istilah yang didefinisikan sendiri, melainkan yang
disediakan oleh TOGAF.(The Open Group, 2012, p. ch 1).
Tabel 11. Notasi Archimate
Notasi Deskripsi Ekstensi Motivasi
Stakeholder Peran individu, tim, atau organisasi (atau kelas
daripadanya) yang merepresentasikan kepentingan, atau perhatian relatif terhadap hasil dari arsitektur.
Driver Sesuatu yang menciptakan, memotivasi, dan bahan
bakar perubahan dalam suatu organisasi.
Assessment Hasil beberapa analisa dari beberapa driver
Goal Sebuah keadaan akhir yang ingin dicapai oleh seorang stakeholder.
Requirement Sebuah pernyataan kebutuhan yang harus direalisasikan oleh sebuah sistem.
Constraint Sebuah pembatasan pada cara dimana sebuah sistem direalisasikan.
Principle Sebuah properti normatif dari semua sistem dalam
konteks tertentu, atau cara dimana mereka menyadari.
Lapisan Bisnis
2 28
Nota
asi
Bus
Bus
BusColl
Loca
BusObj
BusPro
BusFun
Bus
BusServ
Rep
Valu
ApplCom
iness Actor
iness Role
iness laboration
ation
iness ect
iness cess
iness nction
iness Event
iness vice
resentation
ue
Lapisalication
mponent
Suatu entiperilaku.
Tanggung spesifik, y
Suatu agryang bekeperilaku koSuatu titik
Sebuah elsuatu persp
Suatu eleperilaku bdimaksudkproduk ataSuatu eleperilaku bterpilih (bidan atau kSesuatu yadan memp
Sebuah laybisnis uneksternal oSuatu bentsebuah bus
Nilai relabusiness se
an Aplikasi
Bagian yadiganti mengenkamemperlih
Ditas organis
jawab uang mana se
egasi dari derja bersamolektif.
k konseptual
emen pasif pektif bisnis
emen perilaberdasarkan pkan untuk au layanan bemen perilaberdasarkaniasanya mem
kompetensi)ang terjadi (Spengaruhi pe
yanan yang ntuk seoranorganisasi) tuk jelas darsiness objec
atif, utilitaservice atau p
ang modulardari suatu
apsulasi phatkan melal
Deskripsi sasi yang m
untuk meleorang aktor
dua atau lema – sama
atau luas da
yang memis.
aku yang pada urutan
menghasilisnis yang daku yang
n seperangkmbutuhkan s
Secara internrilaku.
memenuhi g konsume
ri informasi t.
s, atau peproduct.
r, dapat diseu sistem perilaku dlui serangkai
mampu mela
lakukan per dapat dituga
bih businesuntuk mela
alam ruang.
liki relevans
mengelompn kegiatan. Hlkan sepera
diidentifikasimengelomp
kat kriteria umber daya
nal atau ekst
sebuah kebuen (internal
yang dibaw
entingnya s
barkan, dansoftware
dan data ian interface
akukan
erilaku askan
ss role akukan
si dari
pokkan Hal ini angkat .
pokkan yang
bisnis
ternal)
utuhan l atau
wa oleh
sebuah
n dapat yang
dan es.
Nota
asi
ApplColl
ApplInter
Data
ApplFunc
ApplInter
ApplServ
Node
Devi
Netw
ComPath
InfraInterf
InfraFunc
Infraservi
lication laboration
lication rface
a Object
lication ction
lication raction
lication vices
Lapisane
ice
work
munication
astructure rface
astructure ction
astructure ice
Sebuah agaplikasi yperilaku koSebuah tittersedia ulain. Elemen padiotomasi.
Sebuah eperilaku otkomponenSebuah eperilaku da
Sebuah serdiotomasi.
n TeknologiSebuah nodaya kompditempatkaSebuah sudisimpan a
Sebuah mperangkat.
Sebuah humana node
Sebuah tityang ditawoleh nodesSebuah eperilaku isebuah nod
Sebuah fueksternal, dieksposedengan ba
Dgregasi dariyang bekerolektif tik akses di untuk pengg
asif yang se.
lemen periltomatis yang
n aplikasi elemen periari sebuah k
rvice yang m.
i ode didefiniputasi di manan untuk eks
umber daya hatau disebark
media komun.
ubungan sates ini dapat b
tik akses diwarkan olehs dan applicalemen perilinfrastruktur de
ungsionalitasdisediakan
melalui ik, dan berm
Deskripsi i dua atau rja sama u
mana layanguna atau k
esuai untuk
laku yang g dapat dilak
ilaku yang olaborasi ap
memperlihat
sikan sebagna artifak dasekusi. hardware dimkan untuk ek
nikasi antar
tu atau lebibertukar data
i mana infrh sebuah noation compolaku yang
yang dapa
s unit yangoleh satu
interfaces makna bagi li
29
lebih komuntuk mela
nan aplikasi omponen ap
pemrosesan
mengelompkukan oleh s
mendeskripplikasi
tkan perilaku
gai sebuah sapat disimpa
mana artifakksekusi.
ra dua atau
ih nodes, ma
rastructure sode dapat donent lain
mengelompat dilakukan
g nampak atau lebih yang terd
ingkungan.
mponen akukan
dibuat plikasi
n yang
pokkan sebuah
psikan
u yang
umber an atau
k dapat
u lebih
melalui
service diakses
pokkan n oleh
secara node,
definisi
3 30
Nota
asi
Softw
Artifa
EkstWork
Deliv
Plate
Gap
Asso
Acce
Used
Aggr
Real
Assig
Aggr
Com
ware System
fak
tensi Migrask Package
verable
eau
Rociation
ess
d by
regation
lization
gnment
regation
mposition
Sistem lingkungandan objekbentuk artiSebuah artfisik data sebuah propenyebara
si dan ImpleWork pacdari tindaksebuah tujuDeliverabldidefinisik
Plateau darsitektur ywaktu terbGap didefkesenjanga
Relasi
Asosiasi mtidak tercaspesifik. Hubungankonsep perHubunganservices olkepada inkolaborasiAggregatiokesengajaaelemen keRealizationdirealisasikHubunganlogika denyang mereHubunganobyek men
Hubungansebuah obylain.
Dsoftware
n software uk yang ditemifak. tifak didefinyang digun
oses pengeman dan operas
ementasi ckage didefikan yang diruan unik dalle didefinisikkan dengan t
didefinisikanyang relatif
batas. finisikan seban antara du
memodelkanakup oleh ya
n akses mrilaku terhad
n used byleh proses, funterfaces oli. on memodean dibagi msengajaan. n memodelkan oleh beb
n penugasangan entitasealisasikan lon agregasi mngelompokk
n komposisyek terdiri d
Deskripsi merepresen
untuk tipe smpatkan di
nisikan sebanakan atau
mbangan softsi dari sistem
finisikan sebrancang untlam waktu tekan sebagai tepat dari pak
n sebagai stabil yang
bagai hasil dua plateaus
n hubungan aang lain, hub
memodelkan dap obyek biy memodelfungsi, atau ileh peran,
lkan bahwa menjadi beb
lkan bahwaberapa cara. an menghus yang lebihogika tersebu
mengindikasikkan sejumlah
si menginddari satu atau
ntasikan spesifik komdalamnya
gai sebuah bdihasilkan
tware, atau dm.
bagai sebuatuk menyeleertentu. sebuah hasi
ket pekerjaa
sebuah keada selama j
dari sebuah a
antara obyekbungan yang
akses terisnis atau dalkan pengginteraksi dan
komponen,
a beberapa eberapa elem
a beberapa
ubungkan h konkrit dut. kan bahwa s
h obyek yang
dikasikan bu lebih obyek
sebuah mponen
dalam
bagian dalam
dengan
ah seri esaikan
il yang an.
eadaan jangka
analisa
k yang g lebih
rhadap ata gunaan n akses , atau
elemen men –
akhir
entitas dengan
sebuah g lain.
bahwa k yang
h
y
Nota
Archima
hubungan) d
yang berbed
2.7.1.
Sudu
prinsip
dihadapi
motivasi
sasaran
pengaruh
Open Gr
sebagai P
asi Flow
Trigg
Influ
Junc
Spec
ate memilik
dan represen
da.Viewpoint
Princip
ut pandang p
yang relev
i di Kantor
i dari prinsi
dapat dim
h satu deng
roup, 2012,
Principles C
w
ggering
uence
ction
cialization
ki beberapa
ntasi sebuah
t tersebut ada
ple Viewp
prinsip men
an guna p
r Pusat Sek
ip – prinsip
modelkan.Se
gan lainnya
p. ch 10.5.4
Catalog(Jonk
Hubungantransfer tenilai antar Hubungantemporal adan eventsInfluencemotivasi pada realisPersimpanhubungan Hubungansebuah oblain.
a viewpoint
arsitektur y
alah sebagai
point
ngijinkan an
erancangan
kolah Kriste
p ini.Selain
bagai cont
baik penga
4).TOGAF
kers, Band, &
Dn aliran menerhadap, sebproses, fung
n pemicu atau kausal as
memodelkamemiliki psasi dari elemngan digunadengan tipe
n spesialisabyek adalah
yang mer
yang diekspr
i berikut:
nalis untuk m
solusi dar
en IPEKA,
itu, hubung
toh, prinsip
aruh positif
menyebutka
& Quartel, 20
Deskripsi ndeskripsikabagai contogsi, interaksi
mendeskripantara proses
an bahwa engaruh pomen motivasakan untuk yang sama
asi mengindspesialisasi
rupakan ko
resikan dala
memodelkan
ri permasala
meliputi t
gan antara p
p dapat m
maupun ne
an Principle
012, p. 8).
31
n pertukaranh, informasi, events psikan hubs, fungsi, inte
beberapa eositif atau nsi lain.
menghubu
dikasikan bi dari obyek
onsep (dan
m diagram
n prinsip –
ahan yang
tujuan dan
prinsip dan
memberikan
egatif (The
Viewpoint
n atau si atau
bungan eraksi,
elemen negatif
ungkan
bahwa k yang
32
2.7.2. Stakeholders viewpoint
Sudut pandang stakeholder membantu analis untuk memodelkan
stakeholders, penggerak internal dan eksternal untuk perubahan, dan penilaian
(dalam hal kekuatan, kelemahan, peluang, dan ancaman) terhadap penggerak
internal dan eksternal.Juga, hubungan pada tujuan awal (high-level) yang
menunjuk kepada deskripsi perhatian dan penilaian. Tujuan ini membentuk
basis kebutuhan bagi proses rekayasa, meliputi penyempurnaan tujuan,
kontribusi dan analisa konflik, dan derivasi terhadap permintaan yang
merealisasikan tujuan (The Open Group, 2012, p. ch. 10.5.1). TOGAF
menyebutkan Stakeholders viewpoint sebagai Stakeholders Map
Matrix(Jonkers, Band, & Quartel, 2012, p. 8).
2.7.3. Goal Realization Viewpoint
Sudut pandang realisasi tujuan membantu memodelkan penyempurnaan
tujuan (high-level) menjadi tujuan yang lebih konkret, dan penyempurnaan
tujuan konkret menjadi kebutuhan atau batasan yang mendeskripsikan properti
yang dibutuhkan untuk merealisasikan tujuan. Penyempurnaan tujuan ke
dalam sub tujuan dimodelkan menggunakan hubungan aggregation.
Penyempurnaan tujuan menjadi kebutuhan dimodelkan menggunakan
hubungan realization (The Open Group, 2012, p. ch. 10.5.2).
2.7.4. Organization Viewpoint
Sudut pandang organisasi fokus pada organisasi suatu perusahaan
(internal), sebuah departemen, sebuah jaringan perusahaan, atau entitas
33
organisasi lainnya. Hal ini mungkin untuk menyajikan model dalam sudut
pandang ini sebagai block diagrams bersarang, tetapi juga dengan cara yang
lebih tradisional seperti struktur organisasi. Sudut pandang organisasi sangat
berguna dalam mengidentifikasi kompetensi, otoritas, dan tanggung jawab
dalam sebuah organisasi (The Open Group, 2012, p. ch. 8.4.2).TOGAF
menyebut Organization Viewpoint sebagai Organization Decomposition
Diagram(Jonkers, Band, & Quartel, 2012, p. 10).
2.7.5. Business Function Viewpoint
Sudut pandang fungsi bisnis menunjukkan fungsi bisnis utama suatu
organisasi dan hubungannya dalam hal aliran informasi, nilai, atau barang
diantaranya.Fungsi bisnis digunakan untuk merepresentasikan aspek yang
paling stabil dari perusahaan dala hal kegiatan utama yang dilakukan, terlepas
dari perubahan organisasi atau pengembangan teknologi. Oleh karena itu,
arsitektur fungsi bisnis dari organisasi yang beroperasi di dalam market yang
sama sering menunjukkan persamaan yang dekat. Sudut pandang fungsi bisnis
dengan demikian menyediakan wawasan high-level dalam operasi umum
perusahaan, dan dapat digunakan untuk mengidentifikasi kompetensi yang
diperlukan, atau untuk struktur organisasi sesuai dengan aktifitas utamanya
(The Open Group, 2012, p. ch. 8.4.4). TOGAF menyebutkan Business
Function Viewpoint sebagai Functional Decomposition Diagram(Jonkers,
Band, & Quartel, 2012, p. 11)
34
2.7.6. Business Process Viewpoint
Sudut pandang proses bisnis digunakan untuk menunjukkan struktur
tingkat tinggi dan komposisi dari satu atau lebih proses bisnis. Selanjutnya
untuk proses sendiri, sudut pandang ini terdiri dari konsep-konsep lain yang
terkait secara langsung, seperti:
Layanan yang menawarkan proses bisnis ke dunia luar, menunjukkan
bagaimana sebuah proses berkontribusi pada realisasi dari produk –
produk perusahaan.
Penugasan dari proses bisnis kepada peran, yang memberikan
wawasan tentang tanggung jawab aktor terkait.
Informasi yang digunakan oleh proses bisnis.
Masing – masing dapat dipandang sebagai sebuah “sub-view” dari
pandangan proses bisnis (The Open Group, 2012, p. ch. 8.4.5). TOGAF
menyebutkan Business Process Viewpoint sebagai Process Flow
Diagram(Jonkers, Band, & Quartel, 2012, p. 12).
2.7.7. Information Structure Viewpoint
Sudut pandang struktur informasi merupakan model informasi yang dibuat
dalam pengembangan sistem informasi.Sudut pandang struktur informasi
menunjukkan struktur informasi yang digunakan dalam perusahaan, proses
bisnis yang spesifik, atau aplikasi. Sudut pandang struktur informasi
menunjukkan bagaimana informasi pada tingkat bisnis direpresentasikan pada
tingkat aplikasi dalam bentuk struktur data yang digunakan, dan bagaimana
hal ini dipetakan pada infrastruktur yang
35
2.7.8. Application Co-Operation Viewpoint
Sudut pandang kerjasama aplikasi mendeskripsikan hubungan antar
komponen aplikasi dalam hal aliran informasi yang terjadi di antaranya, atau
dalam hal layanan yang ditawarkan atau digunakan.Sudut pandang ini
biasanya digunakan untuk membuat gambaran bentangan aplikasi dari sebuah
organisasi. Sudut pandang ini juga digunakan untuk mengekspresikan
kerjasama (internal) atau orkestrasi layanan yang bersama – sama mendukung
eksekusi sebuah proses bisnis (The Open Group, 2012, p. ch. 8.4.9). TOGAF
menyebutkan Application Co-Operation Viewpoint sebagai Application
Communication Diagram(Jonkers, Band, & Quartel, 2012, p. 14)
2.7.9. Application Usage Viewpoint
Sudut pandang penggunaan aplikasi menggambarkan bagaimana aplikasi
digunakan untuk mendukung satu atau lebih proses bisnis, dan bagaimana
mereka digunakan oleh aplikasi lain. Hal ini dapat digunakan dalam
merancang sebuah aplikasi dengan mengidentifikasi layanan yang dibutuhkan
oleh proses bisnis dan aplikasi lain, atau di dalam mendesain proses bisnis
dengan mendeskripsikan layanan yang tersedia. Selanjutnya karena itu
mengidentifikasi dependensi proses bisnis pada aplikasi, itu mungkin berguna
untuk manajer operasional bertanggung jawab untuk proses ini (The Open
Group, 2012, p. ch. 8.4.11).
TOGAF tidak mendefinisikan diagram untuk keselarasan bisnis-aplikasi.
Namun, TOGAF menentukan sudut pandang berbasis matriks untuk
36
menunjukkan hubungan antara arsitektur bisnis dan aplikasi; cth,
Application/Organization matrix dan sebuah Application/Function
matrix(Jonkers, Band, & Quartel, 2012, p. 15).
2.7.10. Infrastructure Viewpoint
Sudut pandang infrastruktur terdiri dari elemen infrastruktur perangkat
lunak (software) dan perangkat keras (hardware) yang mendukung lapisan
aplikasi, seperti peralatan fisik, jaringan, atau sistem perangkat lunak (contoh,
sistem operasi, database, dan middleware) (The Open Group, 2012, p. ch.
8.4.12).TOGAF menyebut Infrastructure Viewpoints sebagai Environments
dan Location Diagram.
2.7.11. Project Viewpoint
Sudut padang proyek utamanya digunakan untuk memodelkan pengelolaan
terhadap perubahan arsitektur. Proses migrasi arsitektur dari keadaan arsitektur
enterprise saat ini menuju keadaan yang diinginkan memiliki konsekuensi
signifikan pada pertumbuhan strategi jangka menengah dan jangka panjang dan
proses pengambilan keputusan selanjutnya (The Open Group, 2012, p. ch.
11.5.1).
2.7.12. Migration Viewpoint
Sudut pandang migrasi mensyaratkan model dan konsep yang dapat
digunakan untuk menentukan transisi dari arsitektur saat ini kepada arsitektur
37
yang diinginkan (The Open Group, 2012, p. ch. 11.5.2) di Kantor Pusat Sekolah
Kristen IPEKA.
2.8. Enterprise Architecture Maturity Model (ACMM)
Penilaian proses bisnis suatu organisasi perlu dievaluasi untuk mengetahui
dimana kita berada dan kemana harus menuju, sertaapa peran yang harus
dilakukan oleh TI. Untuk itulahDepartment of Commerce (DOC) United State of
America mengembangkan EnterpriseArchitecture Maturity Model
(ACMM)sebagai alat bantuuntuk melakukan penilaian.
Tujuan ACMM adalah meningkatkan seluruh kemungkinan keberhasilan
arsitektur enterprisedengan mengidentifikasi kelemahan dan menuntun kepada
perbaikan. Menyediakan kerangka kerja yang merepresentasikan komponen –
komponen kunci proses arsitektur enterprise yang produktif. CMM melukiskan
caraevolusi untuk meningkatkan seluruh proses dimulai dari keadaan ad-hoc,
kemudian menjadi proses yang belum matang, dan akhirnya menjadi proses yang
didefinisikan dengan baik, disiplin, dan matang(U. S. Department of Commerce,
2007).
ACMM terdiri dari tiga bagian, yaitu :
1. Model kematangan arsitektur enterprise.
2. Karakteristik arsitektur enterprise pada tingkat kematangan yang berbeda
3. Scorecard model kematangan kapabilitas arsitektur enterprise.
Dua bagian pertama menjelaskan tingkat kematangan kapabilitas arsitektur
dan karakteristik arsitektur perusahaan yang sesuai untuk setiap tingkat
kematangan untuk digunakan sebagai ukuran dalam proses penilaian. Bagian
38
ketiga digunakan untuk mendorong tingkat kematangan arsitektur yang akan
dilaporkan kepada Chief Information Officer (CIO).
ACMM terdiri dari enam tingkat kematangan dan sembilan elemen arsitektur.
Enam tingkat kematangan, yaitu :
0. None – Tidak ada program arsitektur enterprise
1. Initial – Proses arsitektur enterprise informal sedang berjalan
2. Under Development – Proses arsitektur enterprise sedang dalam
pengembangan
3. Defined – Arsitektur enterprise meliputi prosedur yang tertulis detail dan
model referensi teknis.
4. Managed – Proses arsitektur enterprise yang terukur dan terkelola
5. Measured/Optimized – Peningkatan proses arsitektur enterprise yang
berkelanjutan.
Sembilan elemen arsitektur, yaitu :
1. Proses Arsitektur (Architecture Process) - Apakah ada proses arsitektur
enterprise yang ditetapkan?
Proses arsitektur merupakan siklus yang dimulai dari ide (idea), desain
(design), penggunaan (use), dan pengelolaan (management). Komunikasi
yang jelas antar stakeholders sangat dibutuhkan di seluruh fase proses
arsitektur. Proses arsitektur berfungsi untuk membimbing manajer
merancang proses bisnis dan pengembang sistem untuk membangun
aplikasi dengan cara yang sejalan dengan tujuan dan kebijakan bisnis.(al,
2005, p. 5).
39
2. Pengembangan Arsitektur (Architecture Development) - Sejauh mana
pengembangan dan kemajuan arsitektur enterpriseunit operasi
didokumentasikan?
3. Keterkaitan Bisnis (Business Linkage) – Sejauh mana arsitektur enterprise
terhubung dengan strategi/dorongan bisnis?
4. Keterlibatan Manajemen Senior (Senior Management Involvement) –
sejauh mana manajer senior dari unit operasi dilibatkan dalam penetapan
pengembangan arsitektur TI yang sedang berjalan?
Keterlibatan senior manajemen harus ditingkatkan dalam menentukan arah
dan mendefinisikan proses di seluruh perusahaan, yaitu :
Kepemilikan proses di seluruh perusahaan
Pernyataan arsitektur enterprise yang menuntun kepada prinsip –
prinsip.
Kepemimpinan proyek terhadap tim proyek
Pengawasan eksekutif senior terhadap inisiatif arsitektur
Program manajer TI
Lima praktek di atas menyoroti kebutuhan manajemen senior untuk
mengartikulasikan arah bisnis, dan untuk mengimplementasikan proses –
proses TI yang memungkinkan pemenuhan visi bisnis(Ross, 2006, p. 2).
5. Partisipasi unit operasi (Operating Unit Participation) – Sejauh mana
proses arsitektur enterprise diterima oleh unit operasi?
6. Komunikasi Arsitektur (Architecture Communication) – Sejauh upaya
perwakilan proses arsitektur enterprise dari seluruh organisasi?
40
7. Keamanaan TI (IT Security) – Sejauh mana keamanan TI terintegrasi
dengan arsitektur enterprise?
8. Tata Kelola (Governance)–Sejauh mana tata kelola proses arsitektur
enteprise tersedia dan diterima oleh manajemen senior?
Tata kelola arsitektur (architecture governance) adalah praktek dan
orintasi dimana arsitektur enterprise dan arsitektur lainnya dikelola dan
dikontrol pada tingkat seluruh perusahaan(The Open Group, 2011, p. ch.
50.1.5)
9. Investasi TI dan Strategi Akuisisi (IT Investment and Acquisition Strategy)
– Sejauh mana arsitektur enterprise mempengaruhi investasi TI dan
strategi akuisisi?
Tabel 12.ACMM Score Card
No Elemen/Karakteristik Arsitektur Skor 1. Proses Arsitektur 2. Pengembangan Arsitektur 3. Keterkaitan Bisnis 4 Keterlibatan Manajemen Senior 5A Partisipasi Unit Operasi (5A+5B)/2 5B Partisipasi Unit Operasi 6A. Komunikasi arsitektur
(6A+6B+6C)/36B. Komunikasi arsitektur 6C. Komunikasi arsitektur 7. Keamanan TI 8. Tata Kelola 9. Investasi dan Strategi Akuisisi
41
2.9. Value Chain Analysis
Konsep analisis rantai nilai dijelaskan oleh Michael Porter (Porter, 1985, p.
36)(Ward & Pappard, 2002, p. 244).Perusahaan adalah kumpulan aktifitas bisnis
untuk merancang, menghasilkan, memasarkan, menyampaikan, dan mendukung
produk atau layanan yang dihasilkan.Seluruh aktifitas bisnis dapat
direpresentasikan dalam sebuah value chain.Menurut Porter, value chain terdiri
dari dua aktifitas bisnis, yaitu (Porter, 1985, pp. 39 - 43):
Gambar 3. Business Value Chain Diagram
1. Aktifitas utama (Primary activities)
Aktifitas utama memiliki lima kategori generik. Setiap kategori memiliki
aktifitas yang berbeda sesuai dengan strategi perusahaan.
a. Inbound Logistics
Inbound logistic adalah aktifitas yang terkait dengan penerimaan,
penyimpanan, dan pendistribusian produk.
b. Operations
42
Operations adalah aktifitas yang terkait dengan pengubahan input
menjadi produk akhir seperti produksi, pembuatan, pemaketan,
perawatan peralatan, fasilitas, operasi, jaminan kualitas, proteksi
terhadap lingkungan.
c. Outbound Logistics
Outbound Logistics adalah aktivitas yang terkait dengan pengumpulan,
penyimpanan, distribusi secara fisik atau pelayanan terhadap
pelanggan.
d. Marketing and Sales
Marketing and Sales adalah aktivitas yang terkait dengan usaha
perusahaan kepada konsumen untuk dapat membeli produk dan
layanan yang dihasilkan.
e. Service
Sales adalah aktivitas yang terkait dengan penyediaan layanan untuk
meningkatkan atau memelihara nilai produk seperti instalasi,
perbaikan, pelatihan, penyediaan bahan, perawatan dan perbaikan
bimbingan teknis.
2. Aktifitas Pendukung (Secondary activities)
Aktifitas pendukung memiliki empat kategori generik.Setiap kategori
memiliki aktifitas yang berbeda sesuai dengan strategi perusahaan..
a. Infrastructure
43
Infrastructure merupakan aktivitas, biaya dan aset yang berhubungan
dengan manajemen umum, akuntansi, keuangan, keamanan dan
keselamatan sistem informasi, serta fungsi lainnya.
b. Human Resources Management
Human resouces management adalah aktifitas yang terkait dengan
penerimaan, dengar pendapat, pelatihan, pengembangan, kompensasi,
dan mengembangkan tingkat keahlian sumber daya manusia yang
dimiliki.
c. Research, Technology, and Systems Development
Research, technology, and systems development adalah aktivitas yang
terkait dengan biaya produk, perbaikan proses, perancangan peralatan,
pengembangan software, sistem telekomunikasi, kapabilitas basis data
baru, dan dukungan sistem komputer.
d. Procurement
Procurement adalah aktifitas yang terkait dengan fungsi pembelian..
Dua aktivitas yang disebutkan Porter merupakan aktivitas yang yang
saling terkait dalam hal transformasi data menjadi informasi.
2.9. Unified Modelling Language (UML)
UML merupakan bahasa visual untuk menggambarkan rancangan dan pola
perangkat lunak.UML dapat diaplikasikan untuk menggambarkan dan
mengkomunikasikan organisasi perusahaan, proses bisnis, dan sampai kepada
perangkat lunak terdistribusi dalam perusahaan.UML dimaksudkan menjadi
standar umum untuk menggambarkan dan mengekspresikan hubungan, perilaku,
44
dan ide dalam sebuah notasi yang mudah dan efisien untuk dipelajari dan
ditulis(Dan Pilone, 2005, p. ch. 1).Use case diagram, activity diagram, dan
sequence diagram adalah beberapa contoh diagram UML.
2.9.1. Use Case Diagrams
Use case diagrams memodelkan interaksi suatu sistem informasi dan
lingkunganya. Lingkungan suatu sistem informasi meliputi pengguna akhir
dan berbagai sistem eksternal yang beriteraksi dengan sistem informasi.
Kegunaan utama use case diagram adalah untuk memberikan sebuah sarana
untuk mendokumentasikan dan memahami kebutuhan evolusi sistem
informasi .Use casesmenangkap fungsionalits dan kebutuhan sistem(Alan
Denis, 2005, p. 34). Diagram use case terdiri dari fungsionalitas (use cases)
dan orang atau sesuatu yang memanggil fungsionalitas (actors) (Dan Pilone,
2005, p. ch. 7)
Tabel 13. Notasi Use Case Diagrams
Actor
Use Case
2.9.2. Activity Diagram
Diagram aktifitas memberikan analis kemampuan untuk memodelkan
proses dalam sebuah sistem informasi. Diagram aktifitas dapat digunakan
45
untuk memodelkan alur kerja, use cases individu, atau logika keputusan yang
terkandung dalam sebuah metode individual (Alan Denis, 2005, p. 33)
Tabel 14. Notasi Activity Diagrams
Initial State
Action
Flow Control
Decision
Transition (Fork/Join) Final State
2.9.3. Sequence Diagrams
Sequence diagrams merupakan salah satu tipe interaction diagrams.
Sequence diagrams mengilustrasikan objek yang berbartisipasi dalam sebuah
use case dan messages yang melewati dari waktu ke waktu untuk satu use
case. Sequence diagram merupakan sebuah model dinamis yang menunjukkan
secara eksplisit urutan pesan terjadi antar obyek dalam sebuah interaksi.
Karena sequence diagrams menekankan pada basis waktu terhadap aktifitas
yang terjadi antar objek, maka sangat membantu untuk memahami spesifikasi
use case yang real-time dan kompleks(Alan Denis, 2005, p. 238).
Tabel 15. Notasi Sequence Diagrams
46
Object Lifeline
Activation
Messages (Call)
Messages (Return)
2.10. Aplikasi Web (Web Application)
World wide web telah mengalami sejumlah fase evolusi. Awalnya halaman
web adalah dokumen tekstual sederhana dengan kemampuan interaksi pengguna
yang terbatas berdasarkan pada hyperlinks. Dengan segera dukungan terhadap
grafik dan entri data berbasiskan form ditambahkan. Dengan pengenalan DHTML
yang merupakan kombinasi HTML, XHTML, Cascading Style Sheet (CSS),
Document Object Model (DOM), ECMA(Goodman, 2002, p. ch. 1.1); secara
bertahap,memungkinkan membuat halaman web yang interaktif dengan dukungan
grafik dan animasi.
Saat ini dengan teknologi web 2.0 mengkombinasikan dua karakteristik
penting, yaitu kolaborasi dan interaksi.Kolaborasi merujuk kepada aspek sosial
yang memungkinkan banyak orang untuk berkolaborasi dan berbagi data, aplikasi