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
5
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
pengembangan sistem
Reliabilitas yang lebih besar pada saat implementasi dan update
dan
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 Pernyataan Rasional Implikasi
Harus merepresentasikan baik esensi peran serta mudah untuk diingat. Harus singkat dan jelas mengkomunikasikan aturan dasar. Harus menyoroti manfaat bisnis dari kepatuhan pada prinsip, menggunakan terminologi bisnis. 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) Tujuan Definisi dan pemahaman arsitektur Proses Arsitektur Dukungan Evolusi Arsitektur Analisis Arsitektur Model Arsitektur Timbal Balik Desain Dasar Pemikiran Desain Standarisasi Basis Pengetahuan Arsitektur Kemampuan Memverifikasi Arsitektur Masukan Penggerak Bisnis Masukan Teknologi
ZF
4+1 View
FEAF
RM-ODP
P
P
Y
Y
Y
Y
N N
N N
Y Y
N P
Y Y
Y Y
Y Y P P N N
Y Y P P N N
Y Y P P P Y
Y Y P Y Y Y
Y Y P Y Y Y
Y Y Y P Y Y
N
P
N
P
Y
N
P N
P N
Y Y
P P
Y Y
Y Y
TOGAF
DoDAF
12
Kebutuhan Bisnis Lingkungan Sistem Informasi Arsitektur Saat Ini Kebutuhan Non Fungsional Hasil Model Bisnis Model Sistem Model Informasi Model Komputasi Model Konfigurasi Perangkat Lunak Model Pemrosesan Perangkat Lunak Model Implementasi Platforms Rancangan Kebutuhan NonFungsional Rancangan Transisional Rancangan Dasar Pemikiran
Sebuah
skema
ZF Y P
4+1 View Y P
FEAF Y Y
RM-ODP Y Y
P P
Y Y
Y P
Y Y
Y Y
Y P
Y Y Y Y N
P Y Y Y Y
Y Y Y Y N
Y Y Y Y P
Y Y Y Y Y
Y Y Y Y N
Y
Y
Y
Y
Y
Y
P Y P
P P Y
P Y P
Y Y Y
Y Y Y
Y Y P
N N
N P
Y N
N P
Y P
Y P
untuk
memilih
kerangka
kerja
TOGAF Y Y
arsitektur
DoDAF Y Y
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 P1. Tujuan P2. Masukan P3. Keluaran P4. Pandangan P5. Abstraksi P6. SDLC
ZF 8 6 14 12 12 5
DoDAF 19 11 18 8 8 9
TOGAF 21 12 21 4 2 5
FEAF 16 11 16 10 6 11
TEAF 15 10 15 8 6 9
14 Perspektif/Aspek P7. Pedoman P8. Kualitas P9.Miscellaneous P10. Persyaratan P11. Prinsip Total
ZF 16 20 15 9 20 138
DoDAF 28 18 18 13 23 173
TOGAF 27 18 15 12 23 158
FEAF 21 20 17 4 14 147
TEAF 24 15 19 5 15 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) Principles Catalogs
Metriks (Metricts) -
-
Diagram Inti (Core Diagrams)
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) Stakeholder map matrix
Metriks (Metricts) -
Diagram Inti (Core Diagrams) 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) Organization/Actor Catalog Driver/Goal/Objective Catalog Role Catalog
Metriks (Metricts) Business Interaction Matrix Actor / Role Matrix
Business Service / Function Catalog Location Catalog Process / Event / Control / Product Catalog Contract / Measure Catalog
Legend
Diagram Inti (Core Diagrams) Business Footprint Diagram Business Service / Information Diagram Functional Decomposition Diagram Product Lifecycle Diagram
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) Data Entity / Component Catalog
Data
Metriks (Metricts) Data Entity / Business Function Matrix Application Data Matrix
Diagram Inti (Core Diagrams) Conceptual Data Diagram Logical Data Diagram Data Dissemination Diagram
Tabel 8.Application Architecture Catalog, Metrics, Core Diagrams C. Arsitektur Aplikasi(Application Architecture) Katalog (Catalogs) Application Portfolio Catalog Interface Catalog
Metriks (Metricts) Application / Organization Matrix Role / Application Matrix Application Matrix Application Matrix
Function Interaction
Diagram Inti (Core Diagrams) Application Communication Diagram Application and User Location Diagram Application Use-Case Diagram
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 alternatifalternatif yang diperlukan dalam pemilihan teknologi. Tabel 9. Technology Architecture Catalog, Metrics, Core Diagrams D. Arsitektur Teknologi(Technology Architecture) Katalog (Catalogs) Technology Standart Catalog Technology Portfolio Catalog
Metriks (Metricts) Application Technology Matrix
Diagram Inti (Core Diagrams) Environments and Location Diagram 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).
25
Gaambar 2. Tecchnical Refeerence Modeel Tujuann TRM adaalah untuk m memungkinkkan definisii terstrukturr mengenai standarisaasi platform m aplikasi daan interface terkait(The Open Groupp, 2011, p. ch. 43.1.3 3). Arsitektuur TI yang beerasal dari TOGAF T dapaat berbeda – bedasesuai dengan kebutuhan k siistem inform masi. Pada prakteknya, bbanyak arsittektur yang tidak menncakup selu uruh layanann TRM, mau upun mencakkup layanan n tambahan untuk meendukung kebutuhan applikasi peranngkat lunak yang spesifik kepada organisassi atau kepadda industri veertikal. Dalam m membanguun sebuah arsitektur, pengguna p T TOGAF haru us menilai kebutuhaan mereka sendiri s dan memiliki seervices, inteerfaces, dan standards yang mem menuhi kebuutuhan bisniss(The Open Group, 20111, p. ch. 43.3 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 Peran individu, tim, atau organisasi (atau kelas Stakeholder daripadanya) yang merepresentasikan kepentingan, atau perhatian relatif terhadap hasil dari arsitektur. Sesuatu yang menciptakan, memotivasi, dan bahan Driver bakar perubahan dalam suatu organisasi. Hasil beberapa analisa dari beberapa driver Assessment Goal Requirement
Sebuah keadaan akhir yang ingin dicapai oleh seorang stakeholder. 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
28 2
Nota asi
D Deskripsi mampu melaakukan Business Actor Suatu entiitas organissasi yang m perilaku. Business Role
Tanggung jawab untuk u mellakukan peerilaku spesifik, yang mana seeorang aktorr dapat ditugaaskan
Business Colllaboration Locaation
Suatu agregasi dari dua d atau lebih businesss role ma – sama untuk melaakukan yang bekeerja bersam perilaku koolektif. Suatu titik k konseptual atau luas daalam ruang.
Business Object
Sebuah elemen pasif yang memiliki relevanssi dari suatu persppektif bisniss.
Suatu eleemen perilaaku yang mengelomppokkan perilaku berdasarkan b ppada urutan n kegiatan. Hal H ini dimaksudk kan untuk menghasillkan seperaangkat produk ataau layanan bisnis yang diidentifikasi d . Suatu eleemen perilaaku yang mengelomppokkan Business perilaku berdasarkan b n seperangkkat kriteria yang Funnction terpilih (biiasanya mem mbutuhkan sumber daya bisnis dan atau kompetensi) k Secara internnal atau ekstternal) Business Event Sesuatu yaang terjadi (S dan memppengaruhi perilaku. Business Process
Sebuah layyanan yang memenuhi sebuah kebuutuhan bisnis un ntuk seorang konsumeen (internall atau eksternal organisasi) o Representation Suatu benttuk jelas darri informasi yang dibaw wa oleh sebuah bussiness object. Business Servvice
Valu ue
Nilai relaatif, utilitass, atau peentingnya sebuah s business seervice atau pproduct.
Lapisaan Aplikasi Bagian yaang modularr, dapat disebarkan, dann dapat Appllication diganti dari suatuu sistem software yang Com mponent pperilaku d dan data mengenkaapsulasi dan memperlih hatkan melallui serangkaiian interfacees.
29
Nota asi Appllication Colllaboration
Appllication Interrface
Data a Object
D Deskripsi Sebuah aggregasi darii dua atau lebih kom mponen aplikasi yang y bekerrja sama untuk u melaakukan perilaku koolektif Sebuah tittik akses di mana layan nan aplikasi dibuat tersedia untuk u penggguna atau komponen applikasi lain. Elemen paasif yang seesuai untuk pemrosesann yang diotomasi..
Appllication Interraction
Sebuah elemen perillaku yang mengelomppokkan s perilaku ottomatis yangg dapat dilakkukan oleh sebuah komponen n aplikasi Sebuah elemen e periilaku yang mendeskrippsikan perilaku daari sebuah kolaborasi applikasi
Appllication Servvices
Sebuah serrvice yang memperlihat m tkan perilakuu yang diotomasi..
Appllication Funcction
Lapisan n Teknologii Sebuah noode didefinisikan sebag gai sebuah sumber daya kompputasi di manna artifak daapat disimpaan atau ditempatkaan untuk ekssekusi. Sebuah suumber daya hardware h dim mana artifakk dapat Deviice disimpan atau a disebarkkan untuk ekksekusi.
Nodee
Netw work
Sebuah media m komunnikasi antarra dua atauu lebih perangkat..
Communication Path
Sebuah hu ubungan sattu atau lebiih nodes, melalui m mana nodees ini dapat bbertukar dataa
Infraastructure Interf rface
Sebuah tittik akses dii mana infrrastructure sservice yang ditaw warkan olehh sebuah noode dapat diakses d oleh nodess dan applicaation compoonent lain Sebuah elemen perillaku yang mengelomppokkan i perilaku infrastruktur yang dapaat dilakukann oleh sebuah nodde
Infraastructure Funcction
Infraastructure serviice
Sebuah fuungsionalitass unit yang g nampak secara eksternal, disediakan oleh satu atau lebih node, diekspose melalui interfaces yang terddefinisi makna bagi liingkungan. dengan baik, dan berm
30 3
Nota asi Softw ware System Artifa fak
D Deskripsi Sistem software merepresen ntasikan s sebuah n software uuntuk tipe spesifik kom mponen lingkungan dan objek k yang ditem mpatkan di dalamnya dalam bentuk artiifak. Sebuah arttifak didefinnisikan sebagai sebuah bbagian fisik data yang digunnakan atau dihasilkan dalam oses pengem mbangan softtware, atau dengan d sebuah pro penyebaraan dan operassi dari sistem m.
Eksttensi Migrassi dan Impleementasi Workk Package Work pacckage didefi finisikan sebbagai sebuaah seri dari tindakkan yang dirrancang unttuk menyeleesaikan sebuah tuju uan unik dallam waktu teertentu. Delivverable Deliverablle didefinisikkan sebagai sebuah hasiil yang didefinisikkan dengan ttepat dari pakket pekerjaaan.
Plateeau Gap
Plateau didefinisikan d n sebagai sebuah keeadaan arsitektur yang y relatif stabil yang ada selama jjangka waktu terbbatas. Gap dideffinisikan sebbagai hasil dari d sebuah analisa a kesenjangaan antara duua plateaus
Assoociation
Acceess
Usedd by
Aggrregation
Reallization Assig gnment
Aggrregation
R Relasi Asosiasi memodelkan m n hubungan antara a obyekk yang tidak tercaakup oleh yaang lain, hubbungan yangg lebih spesifik. Hubungann akses m memodelkan akses terrhadap konsep perrilaku terhaddap obyek biisnis atau daata Hubungann used byy memodellkan pengggunaan services olleh proses, fu fungsi, atau interaksi i dann akses kepada innterfaces olleh peran, komponen,, atau kolaborasii. Aggregatio on memodelkan bahwaa beberapa elemen e kesengajaaan dibagi menjadi m bebberapa elem men – elemen kesengajaan. Realization n memodellkan bahwaa beberapa akhir direalisasik kan oleh bebberapa cara. Hubungann penugasaan menghuubungkan entitas logika den ngan entitass yang lebihh konkrit dengan d yang mereealisasikan loogika tersebu ut. Hubungann agregasi m mengindikasik kan bahwa sebuah s obyek men ngelompokkkan sejumlahh obyek yangg lain.
Com mposition
Hubungann komposissi menginddikasikan bahwa b sebuah obyyek terdiri ddari satu atauu lebih obyekk yang lain.
31
Nota asi Flow w
Trigg ggering
Influuence
Juncction Speccialization
D Deskripsi Hubungann aliran menndeskripsikan pertukarann atau transfer teerhadap, sebbagai contoh, informassi atau nilai antar proses, funggsi, interaksii, events Hubungann pemicu mendeskrippsikan hubbungan temporal atau a kausal aantara prosess, fungsi, inteeraksi, dan eventss Influence memodelkaan bahwa beberapa elemen e n motivasi memiliki pengaruh poositif atau negatif men motivassi lain. pada realissasi dari elem Persimpan ngan digunaakan untuk menghubuungkan hubungan dengan tipe yang sama Hubungann spesialisaasi menginddikasikan bahwa b sebuah ob byek adalah spesialisasii dari obyekk yang lain.
Archimaate memilik ki beberapaa viewpoint yang merrupakan ko onsep (dan h hubungan) dan d represenntasi sebuah arsitektur yang y dieksprresikan dalam diagram y yang berbedda.Viewpointt tersebut adaalah sebagaii berikut:
2.7.1.
Princip ple Viewp point
Suduut pandang prinsip p menngijinkan annalis untuk m memodelkann prinsip – prinsip yang relevan guna perancangan solusi darri permasalaahan yang dihadapii di Kantorr Pusat Sekkolah Kristeen IPEKA, meliputi tujuan t dan motivasii dari prinsiip – prinsipp ini.Selain itu, hubunggan antara prinsip p dan sasaran dapat dim modelkan.Sebagai conttoh, prinsipp dapat memberikan m pengaruh h satu denggan lainnya baik pengaaruh positif maupun neegatif (The Open Grroup, 2012, p. ch 10.5.44).TOGAF menyebutkaan Principle Viewpoint sebagai Principles P C Catalog(Jonk kers, Band, & Quartel, 20012, p. 8).
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
Application/Organization
antara
arsitektur
matrix
dan
bisnis sebuah
dan
aplikasi;
cth,
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 1. 2. 3. 4 5A 5B 6A. 6B. 6C. 7. 8. 9.
Elemen/Karakteristik Arsitektur Proses Arsitektur Pengembangan Arsitektur Keterkaitan Bisnis Keterlibatan Manajemen Senior Partisipasi Unit Operasi Partisipasi Unit Operasi Komunikasi arsitektur Komunikasi arsitektur Komunikasi arsitektur Keamanan TI Tata Kelola Investasi dan Strategi Akuisisi
Skor
(5A+5B)/2 (6A+6B+6C)/3
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)
