BAB II TINJAUAN PUSTAKA. manusia atau dengan cara otomatis dengan menggunakan komputer.

BAB II

TINJAUAN PUSTAKA

2.1 Arsitektur Data

Data adalah representasi dari objek dan kejadian yang memiliki arti dan makna penting dalam lingkungan pengguna (Hoffer et al, 2007). Sehingga data dapat pula diartikan sebagai representasi dari kenyataan atau fakta, konsep, yang merupakan sumber bagi interpretasi, atau pengolahan baik yang dilakukan oleh manusia atau dengan cara otomatis dengan menggunakan komputer.

Arsitektur data adalah struktur data berupa fakta yang diketahui atau hal-hal yang digunakan sebagai dasar untuk inferensi atau perhitungan, hubungan, dan prinsip-prinsip dan pedoman yang mengatur desain dan evolusi data dari waktu ke waktu (Hoven, 2003). Arsitektur enterprise adalah bagian dari prinsip, metode, dan model yang digunakan pada perancangan dan realisasi struktur organisasi enterprise, bisnis proses, sistem informasi dan infrastruktur (Marc, 1998).

Ada tiga tahap dalam pembangunan arsitektur data yaitu pembuatan daftar entitas data, diagram hubungan entitas dan matrik proses bisnis terhadap entitas data (Surendro, 2007).

2.1.1 Normalisasi

Normalisasi adalah suatu proses yang digunakan untuk menentukan pengelompokan atribut-atribut dalam sebuah relasi sehingga diperoleh relasi yang berstruktur baik (Kadir, 2009). Pada proses normalisasi, data diuraikan dalam bentuk tabel kemudian dianalisis berdasarkan persyaratan tertentu ke beberapa tingkat. Apabila tabel yang diuji belum memenuhi persyaratan tertentu, maka

tabel tersebut perlu dipecah menjadi beberapa tabel yang lebih sederhana sampai memenuhi bentuk yang optimal.

Tahapan-tahapan dalam proses normalisasi yaitu: 1. Bentuk tidak normal (UNF / Unnormalized form)

Bentuk tidak normal merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti suatu format tertentu. Data dikumpulkan apa adanya sesuai kedatangannya (Kristanto, 2004).

2. Bentuk normal pertama (1NF / First normal form)

Bentuk normal pertama (1NF) adalah suatu keadaan yang membuat setiap perpotongan baris dan kolom dalam relasi hanya berisi satu nilai (Kadir, 2009). Untuk membentuk relasi agar berada dalam bentuk normal pertama, perlu langkah untuk menghilangkan atribut-atribut yang bernilai ganda. 3. Bentuk normal kedua (2NF / Second normal form)

Bentuk normal kedua adalah suatu bentuk yang menyaratkan bahwa relasi harus sudah berada dalam bentuk normal pertama. Atribut bukan kunci harus bergantung secara fungsi pada kunci primer / primary key sehingga untuk membentuk normal kedua haruslah sudah ditentukan kunci-kunci field / atribut kunci. Field / atribut kunci merupakan kunci yang terdapat di setiap file, harus unik dan dapat mewakili atribut lain yang menjadi anggotanya. (Kristanto, 2004)

4. Bentuk normal ketiga (3NF / Third normal form)

Bentuk normal ketiga adalah suatu keadaan yang menyaratkan bahwa relasi harus sudah berada dalam bentuk normal kedua dan semua atribut bukan primer tidak punya hubungan yang transitif (Kristanto, 2004). Dengan kata

lain, setiap atribut bukan kunci haruslah bergantung hanya pada primary key secara menyeluruh.

2.1.2 Daftar Entitas Data

Pada tahap ini dilakukan identifikasi entitas data yang muncul dari fungsi dan proses bisnis. Entitas data ini muncul sebagai kebutuhan untuk menjalankan fungsi dan proses bisnis yang ada di organisasi. Pada tabel 2.1 dicontohkan daftar entitas data dari salah satu proses bisnis. Langkah ini dimulai dengan mengidentifikasi entitas yang ada dalam lingkup enterprise.

Tabel 2.1 Daftar Entitas Data

Sumber:http://digilib.its.ac.id/public/ITS-Master-14271-5106201803-Presentation-3pdf.pdf

2.1.3 Diagram Hubungan-Entitas

Suatu entitas data bisa menunjang lebih dari satu area fungsi dan tidak berdiri sendiri. Dalam penelitian ini, pemodelan dilakukan dengan

Entity-Relationship Diagram (ERD). Seperti yang ditunjukkan pada gambar 2.1. yaitu gambar salah satu contoh pengembangan model ERD.

Model entity relationship (ER) menggambarkan data sebagai entitas, hubungan / relasi, dan atribut (Elmasri dan Navathe, 2001). Entitas adalah obyek dalam dunia nyata yang dapat dibedakan dari objek lain (Ramakhrisnan dan Gehrke, 2003). Tipe entitas adalah kumpulan entitas yang berbagi atribut (Hoffer et al, 2007). Atribut adalah properti atau karakteristik yang terdapat pada setiap entitas (Kadir, 2009). Relasi adalah hubungan antara dua atau lebih entitas (Ramakhrisnan dan Gehrke, 2003).

Sumber : http://digilib.its.ac.id/public/ITS-Master-14271-5106201803-Presentation-3pdf.pdf Gambar 2.1 Pengembangan model ERD

Menurut Winarko (2006), kardinalitas relasi adalah sebuah bilangan yang menunjukkan jumlah maksimum elemen dari sebuah entitas yang berelasi dengan elemen dari entitas yang lain. Macam kardinalitas relasi adalah sebagai berikut :

a. Satu ke satu : kardinalitas satu ke satu menyatakan bahwa setiap entitas pada tipe entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas

Gambar 2.2 relasi satu ke satu

b. Satu ke banyak : kardinalitas satu ke banyak menyatakan bahwa setiap entitas pada tipe entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B, sedangkan setiap entitas B hanya bisa berpasangan dengan satu entitas pada tipe entitas A (Kadir, 2009).

Gambar 2.3 relasi satu ke banyak

c. Banyak ke satu : kardinalitas banyak ke satu menyatakan bahwa setiap entitas pada tipe entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas B dan setiap entitas pada tipe entitas B bisa berpasangan dengan banyak entitas pada tipe entitas A. Dan hubungan satu ke banyak dan banyak ke satu sebenarnya sama saja. Yang membedakan adalah titik pandang terhadap tipe entitas yang menjadi acuan dalam hubungan (Kadir, 2009).

Gambar 2.4 Relasi banyak ke satu

d. Banyak ke banyak : kardinalitas banyak ke banyak menyatakan bahwa setiap entitas pada tipe entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B, begitu pula sebaliknya (Kadir, 2009).

Gambar 2.5 Relasi banyak ke banyak

Menurut Bagul dan Earp (2003), partisipasi antar entitas dibagi menjadi dua sebagai berikut :

1. Partisipasi penuh atau disebut juga partisipasi mandatori. Hubungan yang mewajibkan adanya keterlibatan dari entitas yang lain, minimal harus ada satu entitas A yang berasosiasi dengan entitas B.

2. Partisipasi sebagian yang disebut juga partisipasi opsional. Hubungan yang memperbolehkan tidak adanya keterlibatan dari entitas yang lain atau diperbolehkan terjadinya keadaan tidak ada entitas A yang berasosiasi dengan entitas B.

2.1.4 Matriks Proses vs. Entitas Data

Hubungan antara area fungsi dan entitas data adalah dalam hal pembuatan, pengolahan, dan penggunaan data untuk keperluan pemenuhan tujuan fungsi bisnis. Hubungan ini didefinisikan melalui matriks proses terhadap entitas data. Masing-masing sel dalam matriks diisi dengan huruf-huruf: ―C‖ (create), U (update), dan R (reference). Seperti yang ditunjukkan pada Tabel 2.2, yaitu salah satu contoh matrik proses bisnis terhadap entitas data.

Tabel 2.2 Matriks proses bisnis terhadap entitas data

Sumber : http://digilib.its.ac.id/public/ITS-Master-14271-5106201803-Presentation-3pdf.pdf

2.2 Arsitektur Enterprise

Arsitektur adalah organisasi fundamental dari sistem yang diwujudkan dengan komponen-komponennya, keterhubungannya satu sama lain dan terhadap lingkungannya, dan prinsip sebagai pedoman rancangan dan evolusinya (IEEE 1471 – 2000).

Terlepas dari konteks permasalahannya, kata ―arsitektur‖ menyiratkan suatu perencanaan yang diwujudkan dengan model dan gambar dari bagian atau komponen dari sesuatu dengan berbagai sudut pandang.

Menurut Minoli (2008), enterprise adalah beberapa kumpulan dari perusahaan atau institusi yang memiliki tugas mendukung entitas fungsional yang memiliki tujuan bersama. Dalam hal ini sebuah enterprise tidak hanya sekedar sebuah perusahaan, divisi atau departemen dari perusahaan, namun juga mencakup bagian-bagian perusahaan dalam arti luas yang merupakan agregasi logis pada bisnis internal perusahaan misalnya hubungan bersama dengan mitra dan pemasok.

Arsitektur enterprise merupakan suatu pendekatan logis yang komprehensif dan holistik untuk merancang dan mengimplementasikan sistem dan komponen sistem secara bersama-sama yang meliputi suatu infrastruktur manajemen informasi atau teknologi informasi. Arsitektur enterprise mengandung arti perencanaan, pengklasifikasian, pendefinisian dan rancangan koneksitas dari berbagai komponen yang menyusun suatu enterprise yang diwujudkan dalam bentuk model dan gambar serta memiliki komponen utama yaitu arsitektur bisnis, arsitektur informasi (data), arsitektur aplikasi dan arsitektur dan arsitektur teknologi (Parizeu dalam Fitrian, 2007). Untuk memahami tentang arsitektur enterprise, akan lebih mudah untuk mendeskripsikan arsitektur enterprise dari sudut pandang hal – hal yang bersifat tidak, yaitu (Surendro, 2009) :

1. Arsitektur Enterprise bukan merupakan kumpulan aplikasi bisnis yang digunakan untuk menjalankan organisasi saat ini, tetapi merupakan kerangka kerja untuk oengembangan aplikasi sistem informasi di masa depan yang sesuai dengan bisnis.

2. Arsitektur Enterprise bukan merupakan langkah kerja dari komponen, platforrn, dan perangkat lunak yang digunakan saat ini, tetapi merupakan suatu pernyataan kehendak tentang status komponen, platforrn, dan aplikasi yang diperlukan untuk mendukung strategi bisnis agar terus berjalan seperti yang diharapkan.

3. Arsitektur Enterprise bukan merupakan proyek satu tahunan yang digunakan untuk mendokumentasikan bagaimana sistem yang ada saat ini berinteraksi, tetapi merupakan aktivitas yang dilakukan untuk membandingkan dan

mengevaluasi status sumber daya informasi dalam organisasi saat ini dengan strategi bisnis dan akibatnya pada arsitektur bisnis.

2.3 Perencaan Arsitektur Enterprise

Perencanaan arsitektur enterprise (PAE) merupakan proses mendefinisikan arsitektur untuk penggunaan informasi yang mendukung bisnis dan juga mencakup rencana untuk mengimplementasikan arsitektur tersebut (Surendro 2009). Dari definisi tersebut, terdapat tiga hal yang menjadi kata kunci yaitu :

1. Mendefinisikan

Perencanaan arsitektur enterprise mendefinisikan bisnis dan arsitekturnya, bukan mendesain, sehingga dalam pelaksanaannya tidak dilakukan kegiatan merancang sistem, basis data, atau jaringan. Pekerjaan merancang dan implementasi sistem dilakukan setelah proses pendefinisian perencanaan arsitektur enterprise selesai.

2. Arsitektur

Perencanaan arsitektur enterprise mendefinisikan bisnis dan arsitekturnya, bukan mendesain, sehingga dalam pelaksanaannya tidak dilakukan kegiatan merancang sistem, basis data, atau jaringan. Pekerjaan merancang dan implementasi sistem dilakukan setelah proses pendefinisian perencanaan arsitektur enterprise selesai.

3. Rencana

Beberapa arsitektur mendefinisikan apa yang diperlukan, dan rencana pendukung mendefinisikan kapan arsitektur akan diimplementasikan.

2.4 Kerangka Kerja Arsitektur Enterprise

Kerangka kerja Arsitektur Enterprise (Enterprise Architecture Framework) mengidentifikasikan jenis informasi yang dibutuhkan untuk mendeskripsikan arsitektur enterprise, mengorganisasikan jenis informasi dalam struktur logis, dan mendeskripsikan hubungan antara jenis informasi tersebut. Dalam mengimplementasikan arsitektur enterprise sebaiknya organisasi mengadopsi sebuah metode atau framework yang bisa digunakan dalam melakukan pengembangan arsitektur enterprise tersebut. Dengan adanya metode enterprise arsitektur organisasi diharapkan dapat mengelola sistem yang kompleks dan dapat menyelaraskan bisnis dan TI yang akan diinvestasikan (Yunis, dkk, 2010).

Ada banyak kerangka kerja perusahaan arsitektur pada saat ini, dan dari sekian kerangka kerja yang ada selalu ada yang baru dan ditambahkan setiap hari. Beberapa kerangka kerja tersebut adalah sebagai berikut (Minolli, 2008):

a. The Open Group Architecture Framework (TOGAF) b. Zachman Enterprise Architecture Framework

c. Extended Enterprise Architecture Framework (E2AF) d. Enterprise Architecture Planning (EAP)

e. Federal Enterprise Architecture Framework (FEAF) f. Treasury Enterprise Architecture Framework (TEAF) g. Capgemini’s Integrated Architecture Framework (IAF) h. Joint Technical Architecture (JTA)

i. Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoDAF

j. Department of Defense Technical Reference Model (DoD TRM)

k. Technical Architecture Framework for Information Management (TAFIM) l. Computer Integrated Manufacturing Open System Architecture (CIMOSA) m. Purdue Enterprise Reference Architecture (PERA)

n. Standards and Architecture for eGovernment Applications (SAGA) o. European Union—IDABC & European Interoperability Framework p. ISO/IEC 14252 (IEEE Std 1003.0)

q. IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description

Diantara kerangka-kerangka kerja tersebut menurut survey yang dilakukan oleh Institute for Enterprise Architecture Development (IFEAD) tahun 2003 seperti yang tampak pada gambar 2.6. yang paling banyak digunakan dalam dunia industri maupun pemerintahan adalah Zachman, TOGAF, IAF dan FEAF (Setiawan, 2009).

Sumber : Setiawan, 2009

2.4.1 Kerangka Kerja Zachman

Kerangka kerja Zachman adalah pendekatan klasifikasi artifak arsitektur enterprise yang diterima sebagai standar de facto. Kerangka kerja ini disanjung karena keunikan dalam klasifikasi arsitektur dalam perspektif enterprise (Parizeu, 2002). Menurut Minoli (2008), kerangka kerja Zachman menggambarkan sebuah model menyeluruh dari infrastruktur informasi suatu organisasi dari 6 enam sudut pandang yakni : perencana, pemilik, perancang, pembangun, subkontraktor, dan sistem yang bekerja. Tidak ada panduan dalam urutan pengerjaan, proses, atau implementasi pada kerangka kerja ini.

Kerangka kerja ini berisi enam baris dan enam kolom dimana sumbu vertikal terdapat beberapa sudut pandang secara keseluruhan pada arsitektur, dan pada sumbu horisontal terdapat pengelompokkan dari beberapa artifak dalam arsitektur seperti dalam gambar 2.7.

Menurut Spewak (1992) dalam Priantoto (2008), secara umum tiap kolom merepresentasikan fokus, abstraksi, atau topik arsitektur enterprise, yaitu:

1. What (data) : menggambarkan kesatuan yang dianggap penting dalam bisnis. Kesatuan tersebut adalah hal -hal yang informasinya perlu dipelihara.

2. How (function) : Mendefinisikan fungsi atau aktifitas. Masukan dan keluaran juga dipertimbangkan di kolom ini.

3. Where (networks) : menunjukkan lokasi geografis dan hubungan antara aktifitas dalam organisasi, meliputi lokasi geografis bisnis yang utama.

4. Who (people) : mewakili manusia dalam organisasi dan metrik untuk mengukur kemampuan dan kinerjanya. Kolom ini juga berhubungan dengan

antar muka pengguna dan hubungan antara manusia dan pekerjaan yang menjadi tanggung jawabnya.

5. When (time) : mewakili waktu atau kegiatan yang menunjukkan kriteria kinerja. Kolom ini berguna untuk mendesain jadwal dan memproses arsitektur.

6. Why (motivation) : menjelaskan motivasi dari organisasi dan pekerjanya. Disini terlihat tujuan, sasaran, rencana bisnis, arsitektur pengetahuan, alasan pikiran, dan pengambilan keputusan dalam organisasi.

Setiap baris pada kerangka kerja Zachman mewakili perspektif yang berbeda dan unik yaitu :

1. Perspektif Perencana (baris pertama), yaitu menetapkan konteks, latar belakang, dan tujuan enterprise.

2. Perpektif Pemilik (baris kedua), yaitu menetapkan model-model konseptual dari enterprise.

3. Perspektif Perancang (baris ketiga), yaitu menetapkan model-model sistem informasi sekaligus menjembatani hal-hal yang diinginkan pemilik dan hal-hal yang dapat direalisasikan secara teknis dan fisik.

4. Perspektif Pembangun (baris keempat), yaitu menetapkan rancangan teknis dan fisik yang digunakan dalam mengawasi implementasi teknis dan fisik.

5. Perspektif Subkontraktor (baris kelima), yaitu menetapkan peran dan rujukan bagi pihak yang bertanggung jawab untuk melakukan pembangunan secara teknis dan fisik serta mengadakan komponen-komponen yang diperlukan. 6. Perspektif Functioning Enterprise (baris keenam), yaitu merepresentasikan

Menurut Spewak (1992) dalam Surendro (2007), dalam kerangka kerja Zachman, Perencanaan Arsitektur Enterprise (PAE) mencakup baris pertama dan kedua dari tiga kolom pertama seperti terlihat pada gambar 2.7. Tahapannya diilustrasikan pada gambar 2.8. Dimulai dengan menginisiasi perencanaan, memahami kondisi saat ini, pendefinisian visi masa depan, dan menyusun rencana dalam mencapai visi masa depan.

Kelebihan dari kerangka kerja Zachman adalah mudah untuk dimengerti, membahas organisasi secara keseluruhan, metode dan alat yang didefinisikan secara lepas, dan setiap masalah dapat dipetakan sehingga mudah dimengerti (Marc, 2005). Kerangka kerja Zachman sendiri bukanlah metodologi untuk mengembangkan arsitektur enterprise (meskipun banyak yang cenderung memandangnya sebagai metodologi), melainkan hanyalah kerangka kerja untuk mengkategorikan artifak arsitektur enterprise. Kerangka kerja Zachman dapat dimanfaatkan untuk menentukan apakah suatu metodologi meliputi semua aspek dalam arsitektur enterprise (Fitrian, 2007).

Kelebihan Zachman menurut Mutyarini dan Sembiring (2006):

1. Merupakan standar secara de-facto untuk mengklasifikasikan artefak arsitektur Enterprise

2. Struktur logikal untuk analisis dan presentasi artefak dari suatu perspektif manajemen

3. Menggambarkan secara parallel baik dari sisi engineering yang sudah sangat dimengerti maupun paradigma konstruksi

4. Dikenal secara luas sebagai tool manajemen untuk memeriksa kelengkapan arsitektur dan maturity level

Ga mbar 2.8. C akup an pe re nc an aa n arsitektur ente rpri se da lam ke ra ngk a ke rja Za chm an

2.4.2 Federal Enterprise Architecture Framework (FEAF)

Federal Enterprise Architecture Framework (FEAF) merupakan sebuah framework yang diperkenalkan pada tahun 1999 oleh Federal CIO Council. FEAF ini ditujukan untuk mengembangkan EA dalam Federal Agency atau system yang melewati batas multiple inter-agency. FEAF menyediakan standar untuk mengembangkan dan mendokumentasikan deskripsi arstitektur pada area yang menjadi prioritas utama. FEAF ini cocok untuk mendeskripsikan arsitektur bagi pemerintahan Federal (Setiawan,2009).

FEAF membagi arsitektur menjadi area bisnis, data, aplikasi dan teknologi, dimana sekarang FEAF juga mengadopsi tiga kolom pertama pada Zachman framework dan metodologi perencanaan EA oleh Spewak.

Sumber : Setiawan, 2009

Gambar 2.9 Struktur Komponen FEAF

Pada FEAF arsitektur yang ada (Gambar 2.9) diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis yang umum, penyisipan teknologi , aliran inforamsi dan investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan,

memelihara dan mengimplementasikan lingkungan operasional pada top-level dan mendukung implementasi dari sistem TI (Setiawan, 2009).

Karakteristik dari FEAF :

a. Merupakan EA Reference Model

b. Standar yang dipakai oleh pemerintah Amerika Serikat c. Menampilkan perspektif view yang menyeluruh d. Merupakan tool untuk perencanaan dan komunikasi

2.4.3 The Open Group Architecture Framework (TOGAF)

The Open Group Architecture Technique (TOGAF) adalah sebuah framework yang dikembangkan oleh The Open Group’s Architecture Framework pada tahun 1995. TOGAF ini digunakan untuk mengembangkan enterprise architecture, dimana terdapat metode dan tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan dengan framework EA lain misalnya framework Zachman. Salah satu kelebihan menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan bersifat open source. TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah (Setiawan,2009):

a. Business Architecture mendeskripsikan tentang bagaimana proses bisnis untuk mencapai tujuan organisasi

b. Application Architecture merupakan pendeskripsian bagaimana aplikasi tertentu didesain dan bagaimana interaksinya dengan apikasi lainnya

c. Data Architecture adalah penggambaran bagaimana penyimpanan, pengelolaan dan pengaksesan data pada perusahaan

d. Technical Architecture merupakan gambaran mengenai infastruktur hardware dan software yang mendukung aplikasi dan bagaimana interaksinya.

TOGAF secara umum memiliki struktur dan komponen sebagai berikut (gambar 2.10)

1. Architecture Development Method (ADM)

Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana menentukan sebuah enterprise architecture secara spesifik berdasarkan kebutuhan bisnisnya.

2. Foundation Architecture (Enterprise Continuum)

Foundation Architecture merupakan sebuah ― framework-within-a-framework‖ dimana didalamnya tersedia gambaran hubungan untuk pengumpulan arsitektur yang relevan, juga menyediakan bantuan petunjuk pada saat terjadinya perpindahan abstraksi level yang berbeda. Foundation Architecture dapat dikumpulkan melalui ADM.

3. Resorce Base

Pada bagian ini terdapat informasi mengenai guidelines, templates, checklists, latar belakang informasi dan detil material pendukung yang membantu arsitek didalam penggunaan ADM.

Sumber : Setiawan, 2009

2.4.4 Pemilihan Kerangka Kerja

Memilih sebuah kerangka kerja EA tidak hanya sekedar memilih sesuai dengan keinginan kita, akan tetapi terdapat kriteria yang berbeda yang bisa dijadikan sebagai acuan, misalnya (Setiawan, 2009) :

a. Tujuan dari EA dengan melihat bagaimana definisi arsitektur dan pemahamannya, proses arsitektur yang telah ditentukan sehingga mudah untuk diikuti, dukungan terhadap evolusi arsitektur

b. Input untuk aktivitas EA seperti pendorong bisnis dan input teknologi

c. Output dari aktivitas EA seperti model bisnis dan desain transisional utnuk evolusi dan perubahan kerangka kerja.

Dari survey yang sama (gambar 2.11) menunjukkan khususnya industri di luar keuangan dan asuransi framework yang banyak digunakan selain framework sendiri adalah Zachman, TOGAF dan FEAF.

Sumber : Setiawan, 2009

Gambar 2.11 Penggunaan EA framework pada industri non keuangan/asuransi[IFEAD2003]

framework di masing-masing enterprise bisa menjadi berbeda. Hal ini tergantung dengan karakteristik dari enterprise itu sendiri, fokus yang ingin dicapai dan lain-lain (Setiawan,2009).

Metodologi enterprise arsitektur memiliki pendekatan yang berbeda-beda. Namun ada 12 kriteria yang sering digunakan untuk membandingkan dan mengevaluasi perusahaan-perusahaan arsitektur metodologi. Tidak semua kriteria ini mungkin relevan untuk organisasi, dan mungkin beberapa lebih penting dari yang lain. Tapi setidaknya bagian ini berfungsi sebagai titik awal untuk melakukan evaluasi. Adapun peringkat masing-masing metodologi ditetapkan nilai sebagai berikut (Wartika dan Supriana, 2011):

1. Very poor = kurang

2. Inadequate = tidak memadai 3. Acceptable = diterima 4. Very good = sangat baik

Perlu diketahui bahwa peringkat ini bersifat subyektif.

a. Taxonomy completes mengacu pada seberapa baik anda dapat menggunakan metodologi untuk mengklasifikasikan berbagai artefak arsitektur.

b. Process completeness sepenuhnya mengacu pada bagaimana metodologi memandu anda melalui proses langkah demi langkah untuk menciptakan arsitektur enterprise.

c. Reference model guidance mengacu pada bagaimana metodologi berguna dalam membantu membangun satu set model referensi.

d. Practice guidance mengacu pada berapa banyak metodologi membantu anda mencerna pola pikir arsitektur perusahaan ke organisasi anda.

e. Maturity Model mengacu pada berapa banyak panduan metodologi memberi anda dalam menilai efektifitas dan kematangan organisasi yang berbeda dalam perusahaan anda dalam menggunakan enterprise architecture.

f. Business Focus mengacu pada apakah metodologi akan fokus pada penggunaan teknologi untuk mendorong nilai bisnis, dimana nilai bisnis secara khusus didefinisikan sebagai biaya dikurangi dan/atau pendapatan meningkat.

g. Governance guidance mengacu pada berapa banyak metodologi membantu dalam memahami dan menciptakan model pemerintahan yang efektif untuk enterprise architecture.

h. Partitioning guidance mengacu pada seberapa baik metodologi akan memimpin ke dalam partisi otonom yang efektif dari perusahaan, yang merupakan pendekatan yang penting untuk mengelola kompleksitas.

i. Prescriptive catalog mengacu pada seberapa baik metodologi memandu anda dalam menyiapkan katalog aset arsitektur yang dapat digunakan kembali dalam kegiatan di masa depan.

j. Vendor neutrality mengacu pada seberapa besar kemungkinan anda untuk menjadi terkunci ke sebuah konsultan tertentu dengan mengadopsi metodologi ini.

k. Information availability mengacu pada jumlah dan kualitas informasi gratis atau murah tentang metodologi ini.

l. Time to value mengacu pada kemungkinan lamanya waktu anda akan menggunakan metodologi ini sebelum anda mulai menggunakannya untuk membangun solusi yang memberikan nilai bisnis yang tinggi.

Ketika mempelajari lebih dalam mengenai enterprise architecture, faktanya tidak ada satupun dari pendekatan-pendekatan ini benar-benar lengkap. Masing-masing memiliki kelebihan dan kekurangan pada Masing-masing-Masing-masing sisi. Untuk beberapa enterprise, tidak ada satupun dari metodologi-metodologi ini benar-benar lengkap dijadikan sebagai suatu solusi. Ada pendekatan lain yang disebut blended metodology yaitu memilih bagian-bagian dari metodologi, memodifikasi, menggabungkan, dan menyusunnya untuk kebutuhan khusus organisasi (Wartika dan Supriana,2011).

Tabel 2.3 Kriteria dan Ringkasan Peringkat Metodologi Enterprise Architecture

Kriteria Zachman TOGAF FEAF

Taxonomy completes (Taksonomi) 4 2 1

Process completeness (Kelengkapan Proses) 1 4 3

Reference model guidance (Panduan Referensi Model) 1 3 1

Practice guidance (Panduan Pelaksanaan) 1 2 4

Maturity Model 1 1 2

Business Focus (Fokus Bisnis) 1 2 4

Governance guidance 1 2 3

Partitioning guidance (Panduan Partisi) 1 2 3

Prescriptive catalog (Katalo yang Memberi Petunjuk) 1 2 2

Vendor neutrality (Netralitas Vendor) 2 4 1

Information availability (Ketersediaan Informasi) 2 4 1

Time to value 1 3 4

Sumber : Wartika dan Supriana, 2011

2.5 Business System Planning (BSP)

Businesss System Planning sering disebut sebagai sebuah pendekatan atau metodologi terstuktur. Dasar pemikiran dalam menggunakan studi BSP adalah kebutuhan yang signifikan dalam enterprise, untuk meningkatkan kinerja sistem informasi berbasis computer, serta mengembangkan perencanaan sistem informasi enterprise (Rumapea,2000). Metodologi ini berkaitan dengan upaya bagaimana sistem informasi seharusnya distrukturkan, diintegrasikan, dan diimplementasikan

oleh organisasi dalam jangka panjang. Konsep dasar BSP dapat dikaitkan dengan tujuan jangka panjang sistem informasi sebuah organisasi yaitu (Surendro,2009) : 1. Sebuah sistem informasi harus mendukung sasaran dan tujuan bisnis.

2. Sebuah strategi sistem informasi seharusnya mengelola kebutuhan-kebutuhan dari semua tingkatan manajemen yang ada dalam bisnis.

3. Sebuah sistem informasi seharusnya memberikan konsistensi informasi dalam organisasi secara keseluruhan.

4. Sebuah sistem informasi seharusnya dapat bertahan jika terjadi perubahan-perubahan dalam manajemen.

5. Strategi sistem informasi seharusnya diimplementasikan oleh subsistem dalam arsitektur informasi secara keseluruhan.