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

47  

  

dan layanan melalui web.Interaksi merujuk kepada kemampuan web 2.0 yang

memungkinkan untuk membangun web siteyang berkelakuan seperti aplikasi

desktop(Taivalsaari, Mikkonen, Ingalls, & Palacz, 2008)