UNIVERSITAS INDONESIA PERANCANGAN ENTERPRISE...

UNIVERSITAS INDONESIA

PERANCANGAN ENTERPRISE ARCHITECTURE UNTUK AIRLINE:

STUDI KASUS PT AERO SYSTEMS INDONESIA

KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister

Teknologi Informasi

BASKORO OKTIANTO 1206302320

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA JULI 2014

ii

HALAMAN PERNYATAAN ORISINALITAS

Karya Akhir ini adalah hasil karya saya sendiri, dan semua sumber baik yang dikutip maupun dirujuk

telah saya nyatakan dengan benar.

Nama : Baskoro Oktianto NPM : 1206302320 Tanda Tangan : Tanggal : 9 Juli 2014

iii

HALAMAN PENGESAHAN

Karya Akhir ini diajukan oleh :

Nama : Baskoro Oktianto

NPM : 1206302320

Program Studi : Magister Teknologi Informasi

Judul Karya Akhir : Perancangan Enterprise Architecture untuk

Airline: Studi Kasus PT Aero Systems Indonesia

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai

bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi

Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu

Komputer, Universitas Indonesia.

DEWAN PENGUJI

Pembimbing :Rizal Fathoni Aji, M.Kom ( )

Penguji :Wahyu Catur Wibowo, Ph.D ( )

Penguji :Gladhi Guarddin M.Kom ( )

Ditetapkan di : Jakarta

Tanggal : 9 Juli 2014

iv

KATA PENGANTAR

Puji dan syukur penulis panjatkan kepada Allah Azza wa Jalla karena dengan izin

dan rahmat-Nya karya akhir ini dapat diselesaikan. Karya akhir ini disusun

sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

pada program studi Magister Teknologi Informasi, Fakultas Ilmu Komputer,

Universitas Indonesia.

Dalam penyusunan karya akhir ini penulis telah menerima bantuan dari berbagai

pihak, baik yang sifatnya langsung maupun berupa motivasi sebagai pendorong

terselesaikannya karya akhir ini. Untuk itu dalam kesempatan ini penulis

menyampaikan terima kasih kepada:

1. Bapak Rizal Fathoni Aji, M.Kom, selaku dosen pembimbing yang telah

membantu penulis dalam penyusunan karya akhir dengan saran-saran,

asupan-asupan dan juga kritik yang membangun hingga terselesaikannya

karya akhir ini.

2. Bapak Wahyu Catur Wibowo, Ph.D dan bapak Gladhi Guarddin M.Kom

selaku dosen penguji yang telah membantu dalam menyempurnakan karya

akhir ini.

3. Rekan-rekan Asyst yang telah membantu dalam berbagai hal dimulai bantuan

data, waktu dan berbagai diskusi yang menarik dalam proses penyelesaian

karya akhir ini.

4. Para dosen dan staff Magister Teknologi Informasi yang telah membantu

secara keilmuan ataupun dalam hal-hal administratif yang telah mendukung

terselesaikannya karya akhir ini.

5. Allahuyarham ayah penulis yang dahulu masih berkesempatan memberikan

dorongan moril dalam proses penyusunan karya akhir ini.

6. Ibu dan istri penulis, Leny Wulandari yang selalu memberikan dukungannya

dalam penyelesaian karya akhir ini.

7. Rekan-rekan Magiter Teknologi Informasi 2012c atas berbagai bantuan dan

dukungannya dalam penyelesaian karya akhir ini.

v

Universitas Indonesia

Akhir kata penulis berharap agar karya akhir ini dapat bermanfaat baik bagi

industri ataupun dunia akademik. Kemudian untuk seluruh pihak yang telah

membantu diberikan rahmat dan karunia yang berlipat ganda dan menjadi

kebaikan bagi mereka.

Jakarta, 10 Juli 2014

Penulis

vi

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini: Nama : Baskoro Oktianto NPM : 1206302320 Program Studi : Magister Teknologi Informasi Departemen : - Fakultas : Ilmu Komputer Jenis Karya : Karya Akhir Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Noneksklusif (Non-exclusice Royalty-Free Right) atas karya ilmiah saya yang berjudul: Perancangan Enterprise Architecture untuk Airline: Studi Kasus PT Aero Systems Indonesia Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Noneksklusif ini Universitas Indonesia berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat, dan mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan nama saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di : Jakarta Pada tanggal : 9 Juli 2014

Yang menyatakan

(Baskoro Oktianto)

vii


ABSTRAK

Nama : Baskoro Oktianto Program Studi : Magister Teknologi Informasi Judul : Perancangan Enterprise Architecture untuk Airline: Studi Kasus

--PT Aero Systems Indonesia Dengan semakin berkembangnya strategi bisnis dan semakin banyaknya aplikasi yang digunakan oleh airline maka pola komunikasi yang terbentuk akan semakin kompleks. Hal ini menyebabkan beberapa permasalahan antara lain penggunaan infrastruktur yang tidak efisien dan integrasi antar aplikasi yang tidak efisien. Perkembangan strategi bisnis juga menuntut solusi SI/TI yang dapat mengakomodir kebutuhan bisnis yang ada. Permasalahan-permasalahan tersebut dialami oleh Asyst sebagai salah satu IT provider yang menyediakan solusi SI/TI bagi airline. Penelitian ini memfokuskan pada desain enterprise architectureyang dapat mengakomodir bisnis inti airline yang dapat dibangun Asyst agar tercapai resource sharing dan integrasi antar aplikasi. Enterprise architecture dibangun menggunakan TOGAF ADM. Hasil akhir penelitian adalah berupa desain enterprise architecture untuk menjawab permasalahan-permasalahan yang ada yang telah ditetapkan. Kata kunci: airline, enterprise architecture, TOGAF ADM

xii + 129 halaman; 24 gambar; 13 tabel; 7 lampiran

ABSTRACT

Name : Baskoro Oktianto Study Program : Magister of Information Technology Judul : Design of Enterprise Architecture for Airline: Case Study

---of PT Aero Systems Indonesia With the development of business strategy and the increasing number of application used by airline, the communication pattern between application will become more complex. This causes some problems, among others is inefficient use of infrastructure and integration between applications. The development of business strategy also demanding IS/IT solution which can accommodate the needs of existing businesses. These problems were faced by Asyst as one of the IT provider who provides IS/IT solution for airline. The research conducted was focused on enterprise architecture design which can accommodate the airline’s core business which can be built by Asyst in order to achieve resource sharing and integration between applications. Enterprise architecture was built using TOGAF ADM. The final result of this research is an enterprise architecture design to answer existing problems which has been defined. Keywords: airline, enterprise architecture, TOGAF ADM

xii + 129 pages; 24 pictures; 13 tables; 7 attachments.

viii


DAFTAR ISI HALAMAN JUDUL ..............................................................................................i HALAMAN PERNYATAAN ORISINALITAS ................................................. ii HALAMAN PENGESAHAN .............................................................................. iii KATA PENGANTAR .......................................................................................... iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ........................................... vi ABSTRAK ........................................................................................................... vii ABSTRACT ......................................................................................................... vii DAFTAR ISI ....................................................................................................... viii DAFTAR TABEL .................................................................................................. x DAFTAR GAMBAR ............................................................................................ xi DAFTAR LAMPIRAN ....................................................................................... xii BAB 1 PENDAHULUAN ..................................................................................... 1

1.1 Latar Belakang .......................................................................................... 1 1.2 Permasalahan ............................................................................................ 2 1.3 Batasan Penelitian ..................................................................................... 7 1.4 Research Question .................................................................................... 8 1.5 Tujuan dan Manfaat Penelitian ................................................................. 8

BAB 2 TINJAUAN PUSTAKA ............................................................................ 9 2.1 Enterprise Architecture ............................................................................. 9

2.1.1 Faktor Internal .................................................................................. 10 2.1.2 Faktor Eksternal ............................................................................... 11

2.2 Enterprise Architecture Framework (EAF) ............................................ 11 2.2.1 The Open Group Architecture Framework (TOGAF) ..................... 11 2.2.2 Zachman Framework ....................................................................... 17 2.2.3 Federal Enterprise Architecture (FEA) ........................................... 19

2.3 Perbandingan antara TOGAF, Zachman Framework dan FEA .............. 21 2.4 Service Oriented Architecture (SOA) ..................................................... 25 2.5 Internal Value Chain Analysis ................................................................ 26 2.6 Penelitian Sebelumnya ............................................................................ 27

2.6.1 Middleware Integration Model for Smart Hospital System Using the Open Group Architecture Framework (TOGAF) ............................ 27

2.6.2 On airlines sustainable innovation driven by SOA governance ...... 27 2.6.3 Web Services and Java Middleware Functional and Performance

Analysis for SOA ............................................................................. 28 2.7 Metodologi yang berhubungan dengan penelitian .................................. 30 2.8 Theoretical Framework .......................................................................... 31

BAB 3 METODOLOGI PENELITIAN ............................................................ 33 3.1 Pengumpulan data ................................................................................... 33 3.2 Pendahuluan ............................................................................................ 34

3.2.1 Requirements for architecture work ................................................ 34 3.2.2 Menentukan prinsip-prinsip arsitektur ............................................. 34 3.2.3 Pemetaaan stakeholder ..................................................................... 34

ix


3.3 Arsitektur Bisnis ..................................................................................... 35 3.4 Arsitektur sistem informasi ..................................................................... 35 3.4.1 Arsitekturdata ................................................................................... 35

3.4.2 Arsitektur aplikasi ............................................................................ 35 3.5 Arsitektur teknologi ................................................................................ 35

3.6 Identifikasi permasalahan ....................................................................... 36 3.7 Solusi permasalahan ................................................................................ 36 3.8 Visi arsitektur .......................................................................................... 36 3.9 Arsitektur sistem informasi ..................................................................... 36

3.9.1 Arsitektur data .................................................................................. 37 3.9.2 Arsitektur aplikasi ............................................................................ 37

3.10 Arsitektur Teknologi ............................................................................... 37 3.11 Peluang dan solusi ................................................................................... 38

3.12 Kesimpulan dan saran ............................................................................. 38 BAB 4 PROFIL ORGANISASI ......................................................................... 39

4.1 Profil Asyst ............................................................................................. 39 4.2 Visi dan Misi ........................................................................................... 39 4.3 Produk dan Layanan ............................................................................... 40

BAB 5 HASIL DAN PEMBAHASAN ............................................................... 44 5.1 Pendahuluan ............................................................................................ 44

5.1.1 Requirements for architecture work ................................................ 44 5.1.2 Prinsip-prinsip arsitektur .................................................................. 46

5.2 Kondisi Enterprise Saat Ini ..................................................................... 50 5.2.1 Diagram Value Chain ...................................................................... 51 5.2.2 Pemetaan stakeholder ...................................................................... 53 5.2.3 Arsitektur Bisnis .............................................................................. 55 5.2.4 Arsitektur Sistem Informasi ............................................................. 57 5.2.5 Arsitektur Teknologi Saat ini ........................................................... 72 5.2.6 Permasalahan Yang Dihadapi .......................................................... 73

5.3 Perencanaan Enterprise Architecture ...................................................... 78 5.3.1 Solusi Permasalahan ........................................................................ 78 5.3.2 Pemetaan solusi permasalahan terhadap prinsip arsitektur .............. 86 5.3.3 Visi Arsitektur .................................................................................. 94 5.3.4 Arsitektur Sistem Informasi ............................................................. 96 5.3.5 Arsitektur Teknologi ...................................................................... 100 5.3.6 Peluang dan solusi .......................................................................... 116

BAB 6 KESIMPULAN DAN SARAN ............................................................. 127 DAFTAR PUSTAKA ........................................................................................ 129 LAMPIRAN ....................................................................................................... 130

x


DAFTAR TABEL

Tabel 2.1 Kriteria dan rangking untuk tiap metodologi ....................................... 21 Tabel 5.1 Daftar stakeholder ................................................................................ 53 Tabel 5.2 Keterangan data .................................................................................... 60 Tabel 5.3 Portofolio Aplikasi ............................................................................... 64 Tabel 5.4 Permasalahan yang dihadapi ................................................................ 74 Tabel 5.5 Pola solusi permasalahan ..................................................................... 79 Tabel 5.6. Pemetaan solusi permasalahan terhadap prinsip arsitektur .................. 86 Tabel 5.7 Keterangan target arsitektur data ......................................................... 97 Tabel 5.8 Portofolio sistem informasi .................................................................. 98 Tabel 5.9 Pemetaan teknologi dan prinsip arsitektur ......................................... 103 Tabel 5.10 Mekanisme integrasi ........................................................................ 106 Tabel 5.11 Perbandingan mekanisme integrasi .................................................. 111 Tabel 5.12 Analisis kesenjangan sistem informasi ............................................ 117

xi


DAFTAR GAMBAR Gambar 1.1 Fishbone permasalahan yang dihadapi .............................................. 5 Gambar 2.1 EA sebagai instrumen manajemen ................................................... 10 Gambar 2.2 TOGAF ADM .................................................................................. 13 Gambar 2.3 Aktivitas dengan iterasi baseline terlebih dahulu ............................ 16 Gambar 2.4 Aktivitas dengan iterasi target terlebih dahulu ................................. 17 Gambar 2.5 Zachman Framework ....................................................................... 18 Gambar 2.6 Metodologi penelitian pada penelitian on airlines sustainable

innovation driven by SOA governance ............................................ 30 Gambar 2.7 Theoretical framework ..................................................................... 32 Gambar 3.1 Metodologi Penelitian ...................................................................... 33 Gambar 5.1 Diagram value chain airline ............................................................. 51 Gambar 5.2 Arsitektur bisnis airline .................................................................... 55 Gambar 5.3 Arsitektur data .................................................................................. 59 Gambar 5.4 Arsitektur sistem informasi saat ini .................................................. 64 Gambar 5.5 Topologi infrastruktur ...................................................................... 73 Gambar 5.6 Diagram konsep solusi ..................................................................... 94 Gambar 5.7 Target arsitektur data ........................................................................ 96 Gambar 5.8 Target arsitektur aplikasi .................................................................. 98 Gambar 5.9 Landscape aplikasi ......................................................................... 101 Gambar 5.10 Perspektif arsitektur ...................................................................... 102 Gambar 5.11 Arsitektur gabungan ..................................................................... 103 Gambar 5.12 Peta interoperabilitas .................................................................... 105 Gambar 5.13 Platform Arsitektur Teknologi ..................................................... 107 Gambar 5.14 Unifikasi platform arsitektur teknologi ........................................ 113 Gambar 5.15 Topologi infrastruktur .................................................................. 115

xii


DAFTAR LAMPIRAN

Lampiran 1. Wawancara dengan Chief Technical Officer (CTO) Asyst ........ 130 Lampiran 2. Wawancara dengan Head of IT di Salah Satu Klien .................. 135 Lampiran 3. Wawancara dengan Asyst account management untuk airline. . 137 Lampiran 4. Wawancara dengan manajer flight operation Asyst ................... 140 Lampiran 5. Wawancara dengan Asyst product management - IBE ............. 143 Lampiran 6. Hasil observasi aplikasi dan infrastruktur yang ada di Asyst ..... 145 Lampiran 7. Gambaran Umum Service Catalog Asyst ................................... 147

1


BAB 1

PENDAHULUAN

1.1 Latar Belakang

Dalam beberapa dekade terakhir bidang IT khususnya dalam bidang infrastruktur

mengalami perkembangan yang signifikan. Hal ini sangat mempengaruhi pola

infrastruktur yang digunakan dalam skala enterprise. Menurut Laudon (2012)

perkembangan infrastruktur TI dapat dibagi kedalam 5 tahapan dimana dalam

setiap tahapan mewakili konfigurasi kekuatan komputasi dan elemen infrastruktur

yang berbeda. Tahapan pertama adalah era mainframe dan komputer mini (1959-

saat ini). Era selanjutnya adalah era PC (1981-saat ini). Kemudian dilanjutkan

dengan era client/server (1983-saat ini) dan era enterprise computing (1992-saat

ini). Terakhir adalah era cloud dan mobile computing (2000-saat ini).

Salah satu keberhasilan era mainframe khususnya dalam industri transportasi

adalah dikembangkannya PSS (Passenger Service System) untuk airline yang

pertama, yaitu SABRE (Semi-Automated Business Research Environment). Hal

ini juga menjadi semacam prototipe dari sistem yang bersifat online, real-time dan

interaktif serta scalable sampai pada level sebuah negara. Saat inipun PSS untuk

airline masih banyak yang menggunakan mainframe sebagai basisnya terutama

bagi airline besar yang membutuhkan kekuatan komputasi yang besar, dapat

melayani sampai dengan ribuan terminal dan dengan tingkat scalability yang

tinggi.

Dengan semakin berkembangnya bidang IT, mainframe juga mengalami

perkembangan, baik dari segi ukuran mesin maupun dari segi kekuatan

komputasi. Mainframe yang ada saat ini sudah berukuran jauh lebih compact jika

dibandingkan dengan awal era mainframe. Namun demikian kekuatan komputasi

yang dimiliki sudah melebihi mainframe pada era sebelumnya.

Walaupun saat ini telah memasuki era cloud dan mobile computing, penggunaan

mainframe masih tetap dipertahankan. Hal ini terutama untuk area bisnis yang

memerlukan kekuatan komputasi yang besar dengan tingkat reliability dan

scalability yang tinggi seperti pada airline. Akan tetapi dengan berkembangnya

2


internet dan terutama pada era cloud dan mobile computing maka strategi SI/TI

dari airline juga turut berkembang. Aplikasi-aplikasi yang digunakan oleh airline

pada saat ini tidak hanya dibatasi pada mainframe dengan client terminal-nya

tetapi juga telah berkembang kearah penggunaan internet dan juga teknologi

cloud computing. Beberapa contoh aplikasi tersebut adalah IBE(internet booking

engine) B2C (business to customer), IBE B2T (business to travel), frequent flyer

program (FFP) dan lain-lain.

Antara PSS dan aplikasi-aplikasi seperti IBE B2C, IBE B2T atau FFP terdapat

pertukaran data sehingga antara aplikasi-aplikasi yang ada akan saling

berkomunikasi satu sama lain. Pada umumnya di sebuah airline, PSS akan

bertindak sebagai aplikasi operasional yang utama (core system). Hal ini

dikarenakan beberapa proses inti dari sebuah airline diantaranya yaitu reservasi,

ticketing dan departure control system kesemuanya ditangani oleh PSS. Proses

pemesanan jadwal penerbangan yang dilakukan melalui IBE B2C dan B2T akan

diteruskan ke PSS dan dengan demikian akan terjadi interaksi antara aplikasi-

aplikasi tersebut. Dengan semakin berkembangnya strategi bisnis dari airline dan

semakin banyaknya aplikasi yang digunakan oleh airlinemaka pola komunikasi

yang terbentuk akan semakin kompleks.

Salah satu konsep dari sisi arsitektur sistem yang dapat menunjang pertukaran

informasi antar aplikasi dan menawarkan fleksibilitas dalam hal tersebut adalah

service oriented architecture (SOA). Dengan SOA maka fungsi dibagi-bagi

menjadi layanan yang dapat diakses berbagai aplikasi lain sehingga reusability

dan resource sharing menjadi lebih meningkat.

1.2 Permasalahan

PT. Aero Systems Indonesia (Asyst) adalah salah satu perusahaan yang

mengkhususkan dirinya sebagai IT provider di bidang transportasi. Salah satu

layanan yang disediakan oleh Asyst adalah airline, transportations and travel

solutions (ATTS). Dengan ATTS maka bisnis proses yang ada pada sebuah

airline dapat dilayani pada sebuah sistem yang terintegrasi. Sistem ini sendiri

merupakan sinergi dari beberapa sistem yang ada, yaitu PSS, LIPS, FFP, Sales

3


Dashboard, e-briefing, Meals Monitoring, Flight Monitoring, Centralized Flight

Dispatch, Revenue Accounting, Internet Booking Engine dan Cargo Solutions.

PSS yang digunakan Asyst saat ini berbasiskan pada mainframe. PSS berinteraksi

dengan berbagai sistem lain dan membentuk ATTS. Dengan semakin banyaknya

interaksi maka interkoneksi antar aplikasi juga akan semakin banyak. Hal ini

akan meningkatkan kompleksitas yang ada pada level enterprise. Jika tidak

didefinisikan dengan baik hal ini dapat berakibat pada aplikasi yang sulit untuk di-

maintain dan juga tidak efisien.

Kondisi yang ada di Asyst pada saat ini adalah sebagai berikut:

• Belum ada arsitektur di level enterprise. Yang telah ada saat ini adalah

aplikasi-aplikasi yang saling terhubung tanpa memperhatikan arsitektur di

level enterprise.

• Interkoneksi antar aplikasi masih bersifat tersendiri untuk masing-masing

aplikasi tanpa melihat kebutuhan aplikasi lain.

• Beberapa aplikasi masih menyimpan data yang sifatnya sama dan sharing

data belum dilakukan.

• Beberapa aplikasi yang sifatdan fungsinya sama masih menggunakan

infrastruktur yang berbeda dan di-deploy di server yang berbeda.

• Interkoneksi aplikasi masih bersifat point-to-point.

• Skillful resource untuk pengembangan arsitektur aplikasi masih terbatas.

• Belum ada fungsi monitoring yang mencukupi untuk dipakai dalam sistem

operasional.

Kemudian dari manajemen, beberapa kondisi yang diharapkan adalah sebagai

berikut:

• Dapat memenuhi permintaan klien dengan cepat.

• Mempunyai data warehouse, business intelligence (BI), customer

relationship management (CRM) system dan lain-lain agar dapat

mengakomodasi kebutuhan bisnis yang ada

4


• Ada arsitektur aplikasi di level enterprise dengan mengutamakan resource

sharing dan pemanfaatan cloud computingsehingga economies of scale dapat

tercapai.

• Arsitektur yang diutamakan adalah pada level PSSdan aplikasi yang terkait

dengannya misalnya IBE dengan penggunaan ESB (enterprise service bus).

• Interkoneksi antar aplikasi tidak lagi menggunakan sistem point-to-point.

• Memberikan fleksibilitas jika terjadi perubahan pada satu aplikasi yang

terkait dengan aplikasi lainnya. Perubahan yang terjadi juga diharapkan tidak

membawa dampak siginifikan terhadap cost dan performance reliability dan

bersifat agile terhadap perubahan.

• Desain arsitektur yang robust, menggunakan standar-standar teknologi yang

bersifat best practice standard.

• Memiliki fungsi kontrol dan monitoring yang memadai untuk operasional.

• Desain arsitektur yang memenuhi standard policy dan complience yang ada

seperti IT security requirement dan lain-lain.

• Akses ke PSS yang tidak lagi menggunakan screen scrapping dan dapat

menggunakan metode lain seperti XML web servicebased. XML web service

based diharapkan dapat memberikan lebih banyak fungsi dan fitur yang

diperlukan oleh bisnis.

• PSS perlu dibuatkan GUI dengan menggunakan XML web service untuk

memberikan daya jual yang lebih baik karena sistem saat ini dengan “black

screen” menjadi kurang efisien dan costly (memerlukan constant training jika

turnover pegawai cukup tinggi.

• Arsitektur dapat men-support aplikasi dengan high availability 24/7.

Dari kesenjangan antara kondisi yang ada pada saat ini dan kondisi yang

diharapkan dapat didefiniskan permasalahan yang ada dan dapat dilihat pada

diagram fishbone yang tergambar dalam gambar 1.1.

5


Arsitektur di Level Enterprise Belum Optimal

Infrastruktur

People

Aplikasi

Skillful resource masih terbatas

Interkoneksi dan layananantar aplikasi masih bersifat

point-to-point (hanya memperhatikan aplikasi tersebut)

Aplikasi belum mengutamakanresource sharing sehingga

economies of scalebelum tercapai

Aplikasi yang sifatnya sama masih menggunakan infrastruktur yang berbeda

(belum ada resource sharinginfrastruktur)

Produk

Permintaan klien belum dapat

di-deliver dengan cukup cepat

Terdapat kebutuhanbisnis Yang

belum terpenuhi

Operasional

Fungsi monitoringbelum memadai

Pelaksanaan bisnis proses untuk penanganan

permasalahan masih minim

Akses ke PSS masih kurang efisien dan costly

Gambar 1.1 Fishbone permasalahan yang dihadapi

Dari diagram fishbone tampak beberapa pokok permasalahan dalam bidang-

bidang yang berbeda. Berikut gambaran detail dari masing-masing permasalahan

tersebut:

• Infrastruktur

Dari sisi infrastruktur permasalahan yang teridentifikasi adalah terdapat

beberapa aplikasi yang bersifat sama dan juga menyediakanlayanan yang

sama namun menggunakan infrastruktur yang berbeda. Dalam hal ini belum

ada resource sharing. Hal ini menjadi permasalahan dikarenakan dari

manajemen mengharapkan bahwa resource sharing perlu dilakukan untuk

mencapai economies of scale.

• Aplikasi

Pada level aplikasi teridentifikasi beberapa cabang permasalahan, yaitu:

o Interkoneksi dan layanan antar aplikasi masih bersifat point-to-point

(hanya memperhatikan aplikasi tersebut). Hal ini menimbulkan

permasalahan dikarenakan interkoneksi antar aplikasi masih berkaitan

erat dan tidak loosely coupled. Perubahan di salah satu aplikasi akan

membawa efek ke aplikasi lain sehingga jika jumlah point-to-point

connection sudah semakin banyak, maka tingkat kompleksitas akan

semakin tinggi dan akan menjadi sulit untuk di-maintain. Dalam hal ini

yang diharapkan dari manajemen adalah interkoneksi antar aplikasi tidak

6


lagi bersifat point-to-point. Hal ini juga menimbulkan permasalahan lain

yaitu sifat interkoneksi yang spesifik untuk aplikasi tertentu sehingga jika

ada aplikasi lain yang membutuhkan interkoneksi dan layanan baru maka

harus dibuatkan layanan baru tersendiri. Dalam hal ini aspek reuseability

belum sepenuhnya dioptimalkan.

o Akses ke PSS masih kurang efisien dan costly. Permasalahan ini terjadi

dikarenakan pola komunikasi yang digunakan oleh aplikasi adalah

dengan metode screen scrapping. Pada dasarnya pola akses PSS jika

diakses oleh manusia adalah dengan menggunakan suatu aplikasi yang

berupa command line. Setiap perintah (entry) pada command line

nantinya akan menghasilkan suatu screen respon. Metode screen

scrapping menggunakan pola entry-respon ini untuk berkomunikasi

dengan PSS. Hal ini dilakukan dengan membentuk suatu wrapper bagi

PSS yang mengolah screen respon tersebut. Aplikasi lain akan

berkomunikasi dengan wrapper jika membutuhkan komunikasi dengan

PSS. Cara demikian menurut manajemen mempunyai beberapa

permasalahan diantaranya yaitu belum efisien, hal ini diketahui karena

untuk suatu bisnis proses harus dilakukan komunikasi berulang-ulang ke

PSS karena sifatnya yang berupa urutan entry. Cara ini juga dianggap

masih costly dikarenakan diperlukan constant training untuk menjaga

ketersediaan dan kemampuan resources jika terjadi misalnya tingkat turn

over pegawai yang tinggi. Lebih jauh lagi metode screen scrapping

menyebabkan kerentanan jika terjadi perubahan layout pada sisi PSS

sehingga diperlukan upaya tambahan untuk penyesuaian.

o Aplikasi belum mengutamakan resource sharing sehingga economies of

scale belum tercapai. Hal ini menjadi permasalahan dikarenakan

manajemen menginginkan biaya SI/TI yang efisien. Dengan semakin

berkembangnya kebutuhan bisnis dan aplikasi maka tidak adanya

resource sharing akan mengakibatkan kemungkinan terjadinya duplikasi

layanan. Duplikasi layanan yaitu setiap kali ada kebutuhan layanan dari

aplikasi lain maka harus dibuatkan secara tersendiri. Hal ini dapat

7


meningkatkan biaya, baik pada saat pengembangan sistem maupun pada

saat pengoperasian aplikasi.

• Operasional

o Fungsi monitoring belum memadai. Saat ini menurut manajemen fungsi

monitoring yang ada belum memadai untuk digunakan dalam sistem

operasional sehingga menyulitkan dalam menangani incident/problem

yang ada maupun untuk melakukan enhancement.

o Pelaksanaan bisnis proses untuk penanganan permasalahan masih minim.

Hal ini menurut manajemen menjadi salah satu elemen vital untuk

mendapatkan service excellence disamping kualitas yang baik di sisi

desain dan implementasi dari solusi yang di-deploy.

• People

Pada poin ini permasalahan ada pada people yaitu masih terbatasnya skilful

resources. Hal ini menjadi permasalahan dikarenakan proses desain aplikasi

yang ada menjadi tidak optimal dikarenakan kurangnya sumberdaya manusia

dengan kemampuan yang cukup untuk mendapatkan kondisi yang diharapkan

oleh manajemen.

• Produk

Permasalahan pada sisi produk yaitu permintaan klien terhadap suatu produk

belum dapat di-deliver dengan cukup cepat. Kemudian permasalahan lain

yang ada di sisi produk yaitu kebutuhan bisnis yang ada belum dapat

diakomodasi oleh portofolio aplikasi yang ada saat ini.

1.3 Batasan Penelitian

Dari beberapa akar permasalahan yang ada, batasan penelitian adalah pada

arsitektur aplikasi, infrastrukturdan pada produk (gambar 1.1). Dalam penelitian

ini akan dibahas enterprise architecture (EA) yang dapat mengakomodir bisnis

inti dari sebuah airline (solusi ATTS Asyst) dan bagi Asyst sendiri tercapai

resource sharing dan integrasi antar aplikasi.

Penelitian dibatasi sampai dengan desain EA dan tidak sampai pada tahap

implementasi. Penelitian juga dibatasi pada bisnis inti yang ada di airline yang

dapat dilayani oleh Asyst.

8


1.4 Research Question

Research question yang ingin dijawab dari penelitian ini adalah:

Bagaimana enterprise architecture yang dapat mengakomodir bisnis inti airline

yang dapat dibangun Asyst agar tercapai resource sharing dan integrasi antar

aplikasi?

1.5 Tujuan dan Manfaat Penelitian

Tujuan dari penelitian adalah membangun enterprise architecture yang dapat

menangani permasalahan yang termasuk dalam batasan penelitian. Permasalahan

yang ingin dipecahkan adalah pada poin arsitektur aplikasi, infrastruktur, dan

produk.

Manfaat yang didapat dari penelitian ini jika tujuan penelitian tercapai maka akan

didapat suatu enterprise architecture untuk mengatasi permasalahan-

permasalahan yang telah didefinisikan. Bagi organisasi tempat studi kasus maka

signifikansi penelitian didapat suatu enterprise architecture sehingga diharapkan

tercapai resource sharing dan integrasi antar aplikasi. EA yang dibangun juga

dapat menjadi dasar dan model referensi bagi aplikasi-aplikasi lain yang belum

tercakup atau aplikasi yang kedepannya akan dikembangkan.

9


BAB 2

TINJAUAN PUSTAKA

2.1 Enterprise Architecture

Menurut Lankhorst (2009), enterprise architecture didefinisikan sebagai prinsip-

prinsip yang saling berkaitan, metode dan model yang digunakan untuk

mendesain dan merealisasikan struktur organisasi, bisnis proses, sistem informasi

dan infrastruktur perusahaan. Minoli (2008) mendefinisikan EA sebagai

kumpulan dari bisnis proses, aplikasi, teknologi dan data yang mendukung strategi

bisnis sebuah perusahaan. Kemudian menurut Schekkerman (2011), EA adalah

sebuah cetak biru, yang digunakan secara sistematis dan lengkap mendefinisikan

kondisi perusahaan saat ini dan juga kondisi yang diinginkan (target). Dari ketiga

definisi diatas dapat diambil kesimpulan bahwa EAadalah berupa sekumpulan

bisnis proses, aplikasi, teknologi, data, dan hal-hal tersebut saling berkaitan dan

didefinisikan dalam suatu model tertentu yang menggambarkan kondisi

perusahaan saat ini dan juga kondisi yang diinginkan (target).

Dengan EA, aliran informasi dan bisnis proses yang ada pada perusahaan akan

teridentifikasi. Demikian juga hal-nya dengan sistem informasi yang mendukung

hal tersebut. Tanpa EA maka hal-hal diatas sulit untuk teridentifikasi dan

mempunyai potensi bahwa sistem informasi yang dibangun di perusahaan bersifat

duplikatif, tidak interoperable satu dengan lainnya dan juga membutuhkan biaya

yang tinggi untuk maintenance.

Penerapan EA terutama menjadi penting terutama jika perusahaan menjadi

semakin besar dan semakin kompleks. Dalam hal ini maka keberadaan EA

menjadi suatu kewajiban (Lankhorst, 2009). Hal-hal yang mendorong adanya EA

dapat dibagi menjadi faktor internal dan faktor eksternal. Lankhorst (2009)

mendefinisikan faktor-faktor tersebut sebagai berikut:

10


2.1.1 Faktor Internal

Pada gambar 2.1, EA diposisikan dalam konteks managing the enterprise.

Puncak piramid pada gambar 2.1 adalah visi dan misi dari perusahaan kemudian

diikuti oleh strategi dari perusahaan. Strategi perusahaan akan menyatakan

langkah-langkah yang diambil perusahaan untuk mencapai visi dan misi. Strategi

yang dimiliki akan diterjemahkan menjadi sasaran-sasaran konkrit sebagai arahan

dalam mengeksekusi strategi yang ada. EA akan berperan dalam menerjemahkan

sasaran-sasaran tersebut menjadi kegiatan operasional. EA akan memberikan

gambaran operasional yang ada saat ini dan yang direncanakan beserta langkah-

langkah yang harus diambil untuk mencapai tujuan perusahaan.

Gambar 2.1 EA sebagai instrumen manajemen Sumber: (Lankhorst, 2009)

11


2.1.2 Faktor Eksternal

Selain dari faktor internal yang lebih memfokuskan pada pendekatan bagaimana

agar strategi perusahaan dapat dieksekusi dengan efektif termasuk optimasi dari

sisi operasional, terdapat juga faktor eksternal yang mendorong perusahaan

mengadopsi EA. Faktor eksternal pada umunya lebih dipengaruhi oleh regulasi

yang ada. Sebagai contoh di Amerika Serikat pada tahun 1996 diimplementasikan

Clinger-Cohen act yang juga dikenal sebagai reformasi manajemen teknologi

informasi (Lankhorst, 2009). Hal ini menuntut agar setiap lembaga pemerintahan

harus mempunyai arsitektur teknologi informasi. Dalam hal ini arsitektur TI

didefinisikan sebagai framework yang terintegrasi untuk mengembangkan atau

memelihara TI yang ada dan memperoleh TI yang baru untuk mencapai tujuan

strategis organisasi.

2.2 Enterprise Architecture Framework (EAF)

Pembuatan EA dapat dilakukan dengan penggunaan EAF. Dengan EAF teknik-

teknik untuk mendeskripsikan arsitektur menjadi lebih terstruktur. Hal ini

dilakukan dengan mengidentifikasi dan melihat relasi antara berbagai tahapan

arsitektur dan juga teknik modelling yang digunakan. EAF juga mendefinisikan

elemen-elemen apa saja yang termasuk ke dalam EA. Beberapa EAF yang cukup

banyak digunakan saat ini antara lain adalah zachman framework, the open group

architecture framework (TOGAF) dan federated enterprise architecture (FEA)

framework. Berikut penjelasan lebih detail tentang masing-masing EAF tersebut:

2.2.1 The Open Group Architecture Framework (TOGAF)

Pada awalnya TOGAF adalah sebuah framework dan metodologi untuk

mengembangkan arsiektur teknis dan kemudian berkembang menjadi metodologi

dan framework untuk pengembangan EA. Sejak versi 8 dan seterusnya TOGAF

dikhususkan menjadi framework untuk EA. Versi TOGAF yang terakhir di-

release oleh The Open Group adalah TOGAF versi 9.1.

TOGAF terdiri atas tiga bagian utama (Minoli, 2008):

12


2.2.1.1 TOGAF Architecture Development Method (ADM)

TOGAF ADM menjelaskan bagaimana menurunkan EA yang bersifat spesifik

organisasi dan menjawab kebutuhan bisnis. ADM menyediakan hal-hal sebagai

berikut, antara lain:

• Cara mengembangkan arsitektur yang handal dan juga sudah terbukti sebagai

practice yang diakui.

• View pada level arsitektur sehingga dapat dipastikan bahwa kebutuhan yang

ada dapat diatasi.

• Panduan untuk menggunakan tools untuk pengembangan arsitektur.

Dengan kata lain ADM menyediakan suatu cara kerja bagi enterprise architect.

ADM dapat dikatakan sebagai bagian inti dari TOGAF. ADM terdiri dari

langkah-langkah yang berupa siklus dan mencakup keseluruhan bagian dari

pengembangan EA.

Langkah-langkah dalam ADM (digambarkan pada gambar 2.2) adalah sebuah

proses iteratif. Untuk setiap iterasi keputusan akan diambil seperti untuk:

• Menentukan luas batasanenterprise yang akan didefinisikan

• Menentukan level detail yang akan didefinisikan

• Periode waktu yang ingin dicapai

• Aset arsitektur yang akan dibangun

Keputusan-keputusan tersebut dibuat berdasarkan assessment dari resource dan

kompetensi yang dimiliki dan juga manfaat yang realistis yang dapat diharapkan

sebagai nilai tambah perusahaan dari lingkup EA yang dipilih.Sebagai sebuah

metode yang bersifat umum, ADM dapat digunakan oleh perusahaan yang

bergerak di berbagai sektor dan tipe industri.

13


Gambar 2.2 TOGAF ADM Sumber: (The Open Group, 2013)

TOGAF ADM terdiri atas 8 fase dan diawali dengan fase pendahuluan (gambar

2.2) sebagai berikut (The Open Group, 2013):

• Pendahuluan

Beberapa hal yang tercakup dalam fase pendahuluan adalah

mendefinisikan kebutuhan arsitektur, menentukan prinsip-prinsip

arsitektur, menentukan stakeholder dan lain-lain sebagai langkah

pendahuluan sebelum proses TOGAF ADM.

• Visi arsitektur

Tujuan dari tahap ini adalah mengembangkan visi dari kapabilitas dan

manfaat yang diperoleh secara high level dari EA yang akan diusulkan.

Fase ini dimulai setelah adanya permintaan dari organisasi akan kebutuhan

14


EA. Dalam fase ini juga didefinisikan apa yang termasuk dan diluar

batasan arsitektur yang akan dibuat.

• Arsitektur bisnis

Tujuan dari tahap ini adalah mengembangkan target dari arsitektur bisnis

yang menggambarkan bagaimana perusahaan beroperasi untuk mencapai

tujuan bisnis. Selain itu juga bertujuan merespon hal-hal yang disebutkan

pada visi arsitektur. Pengetahuan tentang arsitektur bisnis adalah sebagai

dasar bagi tahap-tahap selanjutnya yaitu arsitektur sistem informasi

(arsitektur data dan aplikasi) dan arsitektur teknologi.

• Arsitektur sistem informasi

Tujuan dari tahap ini adalah mengembangkan arsitektur sistem informasi

dalam hal data dan aplikasi yang terkait. Hal ini akan menggambarkan

bagaimana arsitektur sistem informasi sedemikian sehingga dapat

menjalankan arsitektur bisnis dan visi arsitektur agar dapat menjawab

keinginan stakeholders.

• Arsitektur teknologi

Tujuan dari tahap ini adalah mengembangkan sedemikian sehingga dapat

menerapkan visi arsitektur untuk menjawab keinginan stakeholder. Dalam

tahap ini juga diidentifikasi komponen-komponen arsitektur yang akanada

sebagai target arsitektur teknologi.

• Solusi dan Peluang

Pada tahap ini didapat versi lengkap yang pertama dari roadmap arsitektur.

Hal ini juga berdasarkan analisis kesenjangan dan kandidat arsitektur yang

didapat dari fase B, C, dan D (pada gambar 2.2). Tahap ini akan

berkonsentrasi bagaimana men-deliver arsitektur yang diusulkan. Analisis

kesenjangan akan menjadi pertimbangan dengan mempertimbangkan

seluruh aspek yang ada. Tahap solusi dan peluang adalah sebagai langkah

awal dari tahap implementasi dan rencana migrasi yang akan dibahas pada

tahap selanjutnya.

15


• Perencanaan migrasi

Pada tahap ini roadmap arsitektur akan difinalisasi. Tahap ini juga

berfungsi untuk memastikan rencana implementasi dan migrasi sejalan

dengan pendekatan perusahaan dalam hal manajemen perubahan.

• Tata kelola implementasi

Tahap ini akan memastikan bahwa arsitektur yang diinginkan selaras

dengan proyek implementasi. Dalam tahap ini juga dilakukan tata kelola

arsitektur untuk solusi dan permintaan perubahan yang ada.

• Manajemen perubahan arsitektur

Pada manajemen perubahan arsitektur dipastikan bahwa lifecycle dari

arsitektur terpelihara. Pada tahap ini juga dipastikan bahwa framework

tata kelola arsitektur dijalankan dan juga dipastikan bahwa kapabilitas dari

EA selaras dengan kebutuhan.

• Manajemen kebutuhan

Tahap ini bertujuan untuk memastikan bahwa proses manajemen

kebutuhan terjaga dan dijalankan untuk fase ADM lain yang relevan.

Dalam tahap ini juga diatur agar kebutuhan arsitektur teridentifikasi dan

dijalankan dalam fase ADM. Selain itu tahap ini juga memastikan bahwa

kebutuhan arsitektur yang relevan tersedia untuk digunakan oleh setiap

fase jika fase tersebut akan dijalankan.

2.2.1.2 Enterprise Continuum

Enterprise continuum adalah sebuah virtual repository dari seluruh aset arsitektur.

Ide dasar dari enterprise continuum adalah untuk menggambarkan bagaimana

arsitektur dikembangkan dalam sebuah rangkaian kesatuan dimulai dari arsitektur

dasar, arsitektur yang bersifat umum, dan arsitektur yang bersifat spesifik ke

industri tertentu.

2.2.1.3 TOGAF resource base

TOGAF resource base adalah sekumpulan sumber daya, meliputi panduan,

template, informasi tentang latar belakang suatu informasi yang dapat membantu

dalam penggunaan ADM.

16


2.2.1.4 Pendekatan pendefinisian arsitektur dengan TOGAF ADM (The Open Group, 2013)

Terdapat dua pendekatan yang dapat diadopsi dalam ADM untuk mendefiniskan

arsitektur, yaitu:

• Baseline terlebih dahulu

Dengan pendekatan ini assessment terhadap baseline landscape (kondisi

saat ini) dilakukan untuk mengidentifikasi permasalahan dan peluang

pengembangan. Hal ini lebih cocok untuk diimplementasikan untuk

kondisi dimana kondisi saat ini cukup kompleks dan kurang dimengerti

dengan baik.Gambar 2.3 menyajikan aktivitas untuk pendekatan baseline

terlebih dahulu.

Gambar 2.3 Aktivitas dengan iterasi baseline terlebih dahulu Sumber: (The Open Group, 2013)

• Target terlebih dahulu

Pendekatan target terlebih dahulu dilakukan dengan mengelaborasi solusi

target terlebih dahulu dengan detail dan kemudian dipetakan dengan

kondisi yang ada saat ini. Dari hal tersebut akan didapat perubahan-

perubahan yang harus dilakukan. Pendekatan target terlebih daulu cocok

dilakukan jika target arsitektur telah disetujui di level manajemen dan

17


enterprise berkeinginan untuk secara efektif bertransisi ke arsitektur target

tersebut. Gambar 2.4 menyajikan aktivitas dengan iterasi target terlebih

dahulu.

Gambar 2.4 Aktivitas dengan iterasi target terlebih dahulu Sumber: (The Open Group, 2013)

2.2.2 Zachman Framework

Zachman framework adalah EAF yang pertama dan dikenal luas. Diperkenalkan

oleh John Zachman pada tahun 1987, zachman framework awalnya dikenal

dengan nama framework for information systems architecture.

Zachmanframework adalah berupa struktur logika untuk mengklasifikasikan dan

mengatur representasi deskriptif yang penting dari sebuah perusahaan bagi

manajemen dan pengembangan enterprise systems (Lankhorst, 2009).

18


Gambar 2.5 Zachman Framework Sumber: (Lankhorst, 2009)

Dalam gambar 2.5 digambarkan bentuk sederhana dari zachman framework. Pada

gambar 2.5 tergambar artefak desain yang terbentuk atas irisan antara peranan

dalam proses desain (sumbu x) dan abstraksi dari produk (sumbu y). Peranan

dalam proses desain yaitu: planner; owner; designer; subcontractor; dan builder.

Abstraksi dari produk yaitu:what (material); how (proses), bagaimana prosesnya;

where (geometri), dimana posisi komponen relatif terhadap komponen lainnya;

who, siapa yang melakukan proses; when, kapan sesuatu terjadi; dan why,

mengapa berbagai pilihan dibuat.

Keuntungan dari zachman framework adalah mudah dimengerti, meliputi

enterprise secara keseluruhan, didefinisikan secara independen dari tools dan

metodologi tertentu, dan dapat memetakan permasalahan. Sedangkan kekurangan

dari zachman framework adalah jumlah cells yang relatif banyak sehingga

menjadi hambatan untuk diaplikasikan dalam prakteknya. Kemudian yang juga

menjadi kekurangan adalah relasi antara satu cell dengan yang lainnya tidak

terlalu dispesifikasikan dengan jelas (Lankhorst, 2009). Namun demikian

walaupun memiliki beberapa kekurangan Zachman telah menyediakan EAF yang

19


pertama yang bersifat komprehensif dan masih digunakan dengan luas sampai

dengan saat ini.

2.2.3 Federal Enterprise Architecture (FEA)

Sessions, 2007 menggambarkan bahwa FEA adalah usaha yang dilakukan

pemerintahan federal untuk menyatukan lembaga-lembaga dan fungsinya dalam

sebuah EA. FEA mempunyai dua hal yaitu taksonomi yang komprehensif seperti

pada zachman framework dan juga mempunyai arsitektural proses seperti

TOGAF. FEA dapat dipandang sebagai sebuah metodologi atau sebagai sebuah

hasil dari mengaplikasikan proses tersebut pada sebuah organisasi, yaitu

pemerintah Amerika Serikat.

Perspektif FEA terhadap EA adalah bahwa sebuah organisasi terbentuk dari

segmen-segmen. Sebuah segmen adalah fungsi bisnis utama seperti misalnya

sumber daya manusia. Segmen terdiri atas dua tipe yaitu segmen area misi inti

dan segmen layanan bisnis. Segment area misi inti adalah sesuatu yang sifatnya

inti dari misi atau tujuan dari batasan politik tertentu dalam organisasi.

Contohnya adalah dalam instansi Pelayanan Kesehatan dan Kemanusiaan dari

pemerintah Federal, kesehatan adalah segmen area misi inti. Segmen layanan

bisnis adalah sesuatu yang mendasar bagi kebanyakan jika tidak, semua organisasi

politik. Sebagai contoh manajemen keuangan adalah segment layanan bisnisyang

diperlukan bagi seluruh instansi.

2.2.3.1 Model Referensi FEA

FEA mempunyai 5 referensi model dengan tujuan memfasilitasi komunikasi,

kerjasama, dan kolaborasi dengan penggunaan istilah dan definisi yang standar

dalam domain EA. 5 model referensi FEA adalah sebagai berikut:

• Model referensi bisnis. Model ini memberikan pandangan bisnis terhadap

berbagai fungsi yang ada dari pemerintahan federal.

• Model referensi komponen. Model ini memberikan pandangan lebih dari

sisi TI tentang sistem yang dapat mendukung fungsionalitas bisnis.

• Model referensi teknis. Model ini mendefinisikan berbagai teknologi dan

standar yang dapat digunakan untuk membangun sistem TI.

20


• Model referensi data. Model ini mendefinisikan cara-cara standar dalam

menggambarkan data.

• Model referensi kinerja. Model ini mendefinisikan cara-cara standar

dalam menggambarkan nilai didapatkan dari EA.

2.2.3.2 Proses FEA

Proses FEA intinya berfokus pada membuat arsitektur segmen untuk sebuah

subset dari keseluruhan organisasi (dalam kasus FEA, organisasi adalah

pemerintahan federal dan subsetnya adalah instansi pemerintah). Proses

pengembangan arsitektur segmen adalah sebagai berikut:

• Analisis arsitektur. Mendefinisikan visi yang sederhana dan ringkas dari

sebuah segmen dan merelasikan kembali dengan rencana organisasi.

• Definisi arsitektur. Beberapa aktivitas yang dilakukan pada tahap ini

adalah mendefinisikan arsitektur yang diinginkan dari sebuah segmen,

mendokumentasikan tujuan kinerja, mempertimbangkan alternatif desain,

dan membangun EA untuk segmen tersebut. EA yang dibangun meliputi

arsitektur bisnis, data, layanan dan teknologi.

• Strategi investasi dan pendanaan. Mempertimbangkan bagaimana

pendanaan proyek EA.

• Rencana program-manajemen dan pelaksanaan proyek. Membuat rencana

untuk mengelola dan melaksanakan proyek termasuk hambatan dan

ukuran kinerja yang akan menilai keberhasilan proyek.

2.2.3.3 Ukuran Kesuksesan FEA

Dalam mengukur kesuksesan organisasi dalam menggunakan EA terdapat 3

kategori untuk menilai tingkat kematangan dari instansi pemerintah, yaitu:

• Penyelesaian arsitektur. Level kematangan arsitektur itu sendiri.

• Penggunaan arsitektur. Seberapa efektif instansi menggunakan

arsitekturnya untuk mendorong pengambilan keputusan.

• Hasil Arsitektur. Manfaat yang dirasakan dari penggunaan arsitektur.

Dari kategori-kategori tersebut dibuat skor untuk tiap kategori (misalnya skor

hijau, kuning, dan merah) dan nantinya dihasilkan skor kumulatif.

21


2.3 Perbandingan antara TOGAF, Zachman Framework dan FEA

Dari tinjauan pustaka yang ada nampak bahwa masing-masing EAF yang ada

mempunyai pendekatan yang berbeda-beda. Pertanyaan yang timbul adalah

framework yang manakah yang sesuai digunakan untuk membangun EA di

organisasi tertentu. Sessions, 2007 memperkenalkan suatu metode berupa 12

kriteria yang sering digunakan olehnya untuk membandingkan dan mengevaluasi

metodologi pembangunan EA.

Dengan pendekatan ini setiap metodologi dirangking dalam setiap kriteria.

Urutan rangking adalah sebagai berikut:

• 1: Tidak baik untuk area ini

• 2: Kurang mencukupi untuk area ini

• 3: Mencukupi untuk area ini

• 4: Sangat baik untuk area ini

Rangking tiap metodologi disajikan pada tabel 2.1.

Tabel 2.1 Kriteria dan rangking untuk tiap metodologi

Kriteria Rangking Zachman TOGAF FEA Kelengkapan taksonomi 4 2 1

Kelengkapan proses 1 4 3

Panduan referensi-model 1 3 1

Panduan praktis 1 2 4

Model kemapanan 1 1 2

Fokus bisnis 1 2 4

Panduan tata kelola 1 2 3

Panduan mempartisi 1 2 3

Katalog aset arsitektur 1 2 2

Netralitas terhadap vendor 2 4 1

Ketersediaan informasi 2 4 1

Time to value 1 3 4

Sumber: (Sessions, 2007)

22


Penjelasan untuk masing-masing kriteria adalah sebagai berikut:

• Kelengkapan taksonomi: Klasifikasi berbagai artefak arsitektur. Zachman

framework mempunyai fokus pada bidang ini sehingga di sini zachman

framework lebih unggul dibandingkan dengan yang lain.

• Kelengkapan proses: Seberapa lengkap metodologi terkait memandu

langkah demi langkah dalam proses pembangunan EA. Hal ini adalah

bidang fokus TOGAF dengan TOGAF ADM-nya, sehingga dalam hal ini

TOGAF lebih unggul dibandingkan dengan metodologi yang lain.

• Panduan referensi-model: Seberapa baik metodologi terkait membantu

membangun model referensi. Dalam hal ini FEA lebih unggul. Akan

tetapi dalam hal ini TOGAF juga mempunyai poin yang cukup baik.

• Panduan praktis: Seberapa baik metodologi terkait membantu proses

asimilasi konsep EA ke dalam organisasi.

• Model kemapanan: Seberapa baik metodologi terkait memberikan panduan

dalam melakukan penilian tingkat efektifitas dan kemapanan organisasi

dalam penggunaan EA.

• Fokus bisnis: Penggunaan teknologi untuk mendorong nilai bisnis

(pengurangan biaya atau peningkatan pendapatan).

• Panduan tata kelola: Seberapa baik metodologi terkait membantu

memahami dan membangun model tata kelola EA yang efektif.

• Panduan mempartisi: Mempartisi bagian-bagian organisasi untuk

mengelola kompleksitas.

• Katalog aset arsitektur: Pembuatan catalog aset arsitektur yang dapat

digunakan untuk aktivitas mendatang.

• Netralitas terhadap vendor: Seberapa terikat metodologi terkait dengan

keterikatan vendor tertentu. Skor yang tinggi menandakan bahwa tingkat

keterikatan yang rendah.

• Ketersediaan informasi: Hal ini berkaitan dengan jumlah dan kualitas

informasi tentang metodologi terkait yang membutuhkan sedikit atau tanpa

biaya.

23


• Time to value: Lamanya waktu yang dalam penggunaan metodologi

terkait sebelum dapat membangun solusi yang akan memberikan nilai

bisnis yang tinggi.

Salah satu hal penting dari tabel 2.1 adalah bahwa tidak ada metodologi yang

lengkap dalam semua sisi dan masing-masing mempunyai kelebihan dan

kekurangan. Untuk memilih metodologi yang sesuai langkah-langkah berikut

dapat dilakukan (Sessions, 2007):

• Menghilangkan kriteria yang tidak penting bagi organisasi yang akan

dibangun EA-nya.

• Kriteria baru dapat ditambahkan jika diperlukan kemudian untuk tiap

metodologi diberikan rangking untuk kriteria baru tersebut.

• Penilaian yang disebutkan pada tabel 2.1 dapat diubah karena terdapat

unsur subyektivitas.

Dari langkah-langkah tersebut di atas akan didapat metodologi yang paling sesuai

untuk digunakan dalam pembangunan EA. Metodologi gabungan juga dapat

digunakan jika ternyata tidak ada metodologi yang sesuai.

Dari fakta-fakta diatas maka terkait dengan penelitian yang penulis lakukan dapat

diformulasikan pemilihan framework EA yang sesuai sebagai berikut:

Dari 12 kriteria dipilih 8 kriteria penting sebagai berikut:

• Kelengkapan proses. Dengan hal ini maka proses yang dilakukan akan

terurut langkah demi langkah.

• Panduan referensi-model: Pemodelan seperti referensi komponen dan data

diperlukan dalam pembangunan EA.

• Fokus bisnis: Salah satu tujuan EA adalah permasalahan integrasi dan

dalam hal ini terjadi pengurangan biaya.

• Panduan mempartisi: Dengan partisi maka kompleksitas dapat dikurangi

dengan berfokus pada bagian tertentu.

• Katalog aset arsitektur: Dengan katalog aset arsitektur maka aset aritektur

akan terdata dan dapat digunakan untuk aktivitas selanjutnya.

24


• Netralitas terhadap vendor. Hal ini untuk menjaga agar EA yang

dihasilkan tidak terikat atau tingkat keterikatannya menjadi minimal

dengan suatu produk tertentu.

• Ketersediaan informasi. Hal ini untuk menjaga bahwa akses informasi

menjadi lebih mudah dan diimbangi dengan kualitas informasi yang baik.

• Time to value: Dengan time to value yang pendek maka solusi dapat

dibangun dan diterapkan dengan lebih cepat.

Kriteria-kriteria yang lain tidak digunakan dikarenakan:

• Kelengkapan taksonomi: Kelengkapan taksonomi tidak diperlukan secara

menyeluruh dikarenakan dibatasi oleh batasan penelitian. Hal ini juga

sesuai dengan harapan manajemen saat ini yaitu arsitektur yang

diutamakan adalah pada level PSS dan aplikasi yang terkait dengannya

sehingga hanya terkait dengan bisnis inti airline.

• Panduan praktis: Batasan penelitian adalah pembangunan EA dan bukan

pada penerimaan EA di organisasi. Sebagai lanjutan dari penelitian ini hal

ini dapat dipertimbangkan untuk kemudian dapat dipilih metode yang

sesuai.

• Model kemapanan: Penilaian tingkat efektifitas dan kemapanan organisasi

dalam penggunaan EA tidak termasuk dalam batasan penelitian. Saat ini

hal tersebut belum menjadi salah satu kebutuhan dari arsitektur yang akan

dibuat.

• Panduan tata kelola: Tata kelola TI tidak termasuk dalam batasan

penelitian.Sebagai lanjutan dari penelitian nantinya dapat ditentukan

metode panduan tata kelola TI yang sesuai dan dapat menggunakan

metode gabungan dengan bantuan framework tata kelola.

Dari 8 kriteria yang dipilih (tabel 2.2), TOGAF mendapatkan nilai tertinggi dan

karenanya metodologi yang digunakan dalam penelitian adalah TOGAF.

25


Tabel 2.2 Tabel pemilihan EAF

Kriteria Rangking

Zachman TOGAF FEA

Kelengkapan proses 1 4 3

Panduan referensi-model 1 3 1

Fokus bisnis 1 2 4

Panduan mempartisi 1 2 3

Katalog aset arsitektur 1 2 2

Netralitas terhadap vendor 2 4 1

Ketersediaan informasi 2 4 1

Time to value 1 3 4

Total 10 24 19

Sessions, 2007 telah diolah kembali

2.4 Service Oriented Architecture (SOA)

SOA adalah sebuah konsep dengan latar belakang bahwa pada level enterprise

jumlah aplikasi dan fungsi yang ada menjadi semakin besar dan semakin

kompleks. Fungsionalitas yang ada pada aplikasi dapat dienkapsulasi menjadi

sebuah layanan/service. Kemudian jika fungsionalitas yang ada telah berbentuk

sebagai sebuah service maka service tersebut dapat digunakan oleh aplikasi lain

yang ada di level enterprise. SOA memilih pendekatan dalam pengembangan

aplikasi dengan service yang saling independen yang nantinya dengan suatu

pengaturan tertentu dapat membentuk aplikasi lain.

Menurut Lankhorst (2009). SOA merepresentasikan prinsip-prinsip desain yang

memungkinkan sebuah unit fungsional tersedia dan digunakan sebagai service.

Kemudian Minoli (2008) mendefinisikan SOA sebagai sebuah pendekatan untuk

membangun sebuah sistem TI berupa bagian-bagian modul perangkat lunak yang

dinamakan service. Minoli menambahkan bahwa tujuan dari pengembangan

sistem berbasis SOA adalah agar organisasi mengembangkan sistem dari modul-

modul yang lebih sederhana.

26


Dari beberapa definisi diatas dapat diambil kesimpulan bahwa dengan SOA maka

fungsionalitas dari aplikasi dibagi menjadi sejumlah service. Dari sejumlah

service yang ada, dapat digunakan oleh aplikasi lain sehingga interaksi antar

sistem adalah melalui sejumlah service yang ada.

2.5 Internal Value Chain Analysis

Pendekatan value chain membedakan dua tipe aktivitas bisnis, yaitu (Ward dan

Peppard, 2011): 1) Aktivitas inti; dan 2) Aktivitas pendukung. Aktivitas inti

adalah aktivitas-aktivitas yang berperan dalam value chain industri untuk

memenuhi kebutuhan customer. Aktivitas-aktivitas tersebut saling terhubung satu

sama lain. Aktivitas pendukung adalah hal-hal yang diperlukan untuk mengontrol

dan mengembangkan bisnis seiring berjalannya waktu sedemikian sehingga akan

menambah value secara tidak langsung.

Dalam Ward dan Peppard, 2011 digambarkan aktivitas inti sebagai suatu urutan

diawali dengan pemasok dan diakhiri dengan pelanggan. Urutan aktivitas tersebut

adalah sebagai berikut:

• Inbound logistics

Mendapatkan, menerima, menyimpan, penyediaan bahan-bahan dan hal-hal

utama sebagai asupan dengan kualitas dan kuantitas yang benar bagi bisnis.

• Operations

Merubah bahan-bahan asupan menjadi produk atau layanan.

• Outbound logistics

Mendistribusikan produk ke pelanggan. Dapat dilakukan direct ke pelanggan

atau melalui distribution channel.

• Sales and Marketing

Menyediakan cara agar pelanggan mengetahui tentang produk dan dapat

memilikinya.

• Services

Menambah value lebih jauh setelah produk dimiliki oleh pelanggan.

Urutan aktivitas di atas lebih cocok untuk industri manufaktur, namun dengan

logika yang sama yaitu mendapatkan bahan-bahan, merubahnya,

mendistribusikannya, membuatnya dimiliki oleh pelanggan dan mendapat value

27


lebih jauh setelah dimiliki, value chain dapat digambarkan untuk industri yang

lain.

2.6 Penelitian Sebelumnya

Berikut ini dibahas beberapa penelitian yang terkait dengan penelitian yang

dilakukan.

2.6.1 Middleware Integration Model for Smart Hospital System Using the Open Group Architecture Framework (TOGAF)

Penelitian ini dilakukan oleh Zenon Chaczko, Avtar S. Kohli, Ryszard Klempous,

dan Jan Nikodem dan dipublikasikan melalui jurnal IEEE pada tahun 2010.

Penelitian ini membahas mengenai Smart Hospital Management System (SHS).

SHS merupakan integrasi dari berbagai legacy application yang telah ada dan

harus diintegrasikan agar dihasilkan solusi yang lebih menyeluruh. Tujuan dari

penelitian ini adalah menyajikan sebuah pendekatan dalam solusi arsitektur yang

dapat digunakan sebagai framework untuk mengatasi permasalahan yang sering

dijumpai dalam solusi integrasi di level enterprise.Framework dasar yang

digunakan pada penelitian ini berbasis pada TOGAF 9 dan alur pengembangan

yang ada digambarkan dengan komponen TOGAF ADM.

Hasil akhir dari penelitian ini adalah sebuah enterprise architecture berupa SHS

yang telah dapat memenuhi kebutuhan bisnis. Arsitektur yang dibangun juga

dapat lebih terbuka terhadap fitur baru.

Kaitan penelitian ini dengan penelitian yang dilakukan penulis adalah pada

pembangunan EA. Seperti juga penelitian yang dilakukan penulis pada penelitian

ini, dilakukan integrasi dari aplikasi legacy yang sudah ada. Pendekatan yang

dilakukan pada penelitian ini dengan langkah-langkah menggunakan TOGAF

dapat menjadi referensi bagi penelitian yang dilakukan penulis.

2.6.2 On airlines sustainable innovation driven by SOA governance

Penelitian ini dilakukan oleh Zhang Yakun et al dan dipublikasikan di jurnal IEEE

pada tahun 2009. Pada penelitian ini dibahas mengenai karakteristik dari

arsitektur TI yang ada di airline. Kemudian tantangan-tantangan yang dihadapi

oleh TI dikarenakan bisnis yang selalu berubah. Pokok permasalahan adalah

28


bagaimana key dari nilai-nilai TI, dalam konteks menjaga inovasi bisnis yang

berkelanjutan. Kemudian juga bagaimana TI bersifat fleksibel dengan beragam

aplikasi yang ada dengan arsitektur TI yang juga fleksibel. Dalam hal ini

penelitian akan memfokuskan mengatasi permasalah-permasalahan yang ada

dengan pendekatan SOA governance.

Pada bagian awal dibahas bagaimana bisnis airline bergerak dengan cepat dan

selalu berkembang dari tahun ke tahun. Perkembangan tersebut memberikan

tekanan untuk menghasilkan bisnis proses yang optimal dan penggunaan resource

yang efisien. Dalam hal ini kapabilitas TI menjadi hal penting terutama dalam era

internet seperti saat ini.

Kemudian pada bagian berikutnya dibahas hal-hal yang inovatif dari SOA di

airline. Pada awalnya dibahas mengenai karakteristik TI dari airline sampai

kepada arsitektur TI termasuk portofolio aplikasi dari airline.

Pada bagian ketiga dibahas bagaimana inovasi didalam airline dapat terus

berkelanjutan dengan SOA governance. SOA-based application framework dan

SOA government framework yang didesain berorientasi pada beberapa hal, yaitu

berfokus pada bisnis, fleksibel dan bertujuan inovasi dan pengembangan yang

berkelanjutan.

Kaitan penelitian ini dengan yang dilakukan oleh penulis adalah penelitian dengan

studi kasus yang sebidang, yaitu lingkungan TI di bidang airline. Penjabaran

aplikasi-aplikasi di bidang airline beserta kesulitan-kesulitan yang ada menjadi

referensi bagi penelitian yang dilakukan oleh penulis. Terlebih juga ditambah

dengan dilakukannya pendekatan SOA agar inovasi pada airline dapat terus

berkelanjutan.

2.6.3 Web Services and Java Middleware Functional and Performance Analysis for SOA

Penelitian ini dilakukan oleh Matjaz B. Juric et aldan dipublikasikan melalui

jurnal IEEE pada tahun 2007. Penelitian ini berfokus pada analisis dari teknologi

kunci dari middleware untuk membangun sistem berbasis SOA pada platform

Java.

29


Pada bagian awal dibahas tentang SOA, web service dan teknologi-teknologi yang

terkait dengan middleware dan SOA yang ada pada platform Java.

Pada bagian selanjutnya dibahas mengenai komparasi fungsional dari teknologi-

teknologi yang ada. Beberapa teknologi yang dibahas adalah perbandingan

antara teknologi HTTP-to-port tunneling dan HTTP-to-CGI/Servlet tunneling.

Dari dua hal tersebut didapat hasil yang optimal adalah menggunakan servlet.

Perbandingan selanjutnya dilakukan untuk web service, RMI, RMI tunneling

alternatives. Beberapa hal yang yang diukur adalah waktu untuk melakukan

instantiasi dan waktu untuk pemanggilan method. Disini dibangun suatu metode

untuk melakukan komparasi.

Dari hasil komparasi maka didapatkan hasil-hasil, antara lain diketahui bahwa

RMI mempunyai waktu pemrosesan lebih cepat dibandingkan dengan web

service. Hanya saja waktu spesifik pada instantiasi, web service menempati

peringkat pertama disusul oleh RMI.

Penelitian ini menghasilkan kesimpulan bahwa RMI masih merupakan yang

tercepat pada platform java untuk mengembangkan sistem berbasiskan SOA.

Kemudian web-service ada di posisi kedua disusul dengan RMI tunneling yang

ternyata performance-nya ada dibawah RMI dan dan web-service.

Kaitan penelitian ini dengan penelitian yang dilakukan oleh penulis adalah pada

penggunaan platform teknologi untuk mendukung integrasi yang berbasiskan

SOA. Walaupun pada penelitian ini telah dilakukan perbandingan dari teknologi-

teknologi yang ada namun hal tersebut baru menyentuh pada aspek performance

dan belum pada aspek-aspek yang lainnya. Dengan demikian maka hasil yang

didapat belum dapat menjadi acuan dalam pemilihan teknologi karena masih

terdapat faktor-faktor yang lain. Faktor-faktor lain tersebut antara lain

kemampuan interoperability dengan platform lain. Dalam hal ini dimungkinkan

teknologi seperti web-service memiliki keunggulan dibandingkan dengan platform

yang lain karena sifatnya yang open standard dan tidak terikat ke suatu platform

tertentu.

30


2.7 Metodologi yang berhubungan dengan penelitian

Berikut ini akan dibahas beberapa metodologi yang berkaitan dengan penelitian

yang dilakukan:

Pada penelitian On Airlines SustainableIinnovation Driven by SOA Governance,

metodologi yang digunakan adalah sebagai berikut (gambar 2.6):

Gambar 2.6 Metodologi penelitian pada penelitian on airlines sustainable innovation driven by SOA governance

• Melakukan studi tentang karakteristik IT di airline

Dalam tahap ini didefinisikan kebutuhan seperti apa yang harus dipenuhi oleh

lingkungan TI pada sebuah airline.

• Membangun application portfolio berbasiskan karakteristik IT di airline (SOA-

based application framework)

Dalam tahap ini dibangun suatu application portfolio yang ada untuk sebuah

airline.

• Membangun SOA government framework

Agar SOA framework dapat berjalan dengan baik, maka didefinisikan dua hal

yang harus dilakukan, yaitu pengaturan SOA governance lifecycle dan service

lifecycle. SOA governance lifecycle dibagi lagi menjadi 4 tahapan yang harus

dilalui, yaitu plan, define, enable dan measure.

Kemudian pada penelitian dengan judul Middleware Integration Model for Smart

Hospital System Using the Open Group Architecture Framework (TOGAF),

31


metodologi yang digunakan adalah berbasiskan TOGAF ADM dengan langkah-

langkah yang telah diilustrasikan pada gambar 2.2dan telah dijelaskan pada bagian

tinjauan pustaka tentang TOGAF. Adapun secara singkat langkah-langkahnya

adalah sebagai berikut:

• Membangun visi arsitektur

• Membangun arsitektur bisnis

• Membangun arsitektur sistem informasi

• Membangun arsitektur teknologi

• Mengindentifikasi peluang dan solusi

• Membuat migration planning

• Mengimplementasikan tata kelola

• Mengimplementasikan arsitektur change management

2.8 Theoretical Framework

Theoretical framework yang dibangun pada penelitian ini adalah berdasarkan

TOGAF ADM. Telah disebutkan pada bagianbatasan penelitian bahwa hasil dari

penelitian ini adalah berupa desain EA yang terangkum dalam target EA.

Penelitian mencakup langkah pendahuluan dengan melibatkan requirements of

architecture work dan prinsip-prinsip arsitektur. Kemudian diikuti dengan

langkah-langkah TOGAF ADM (gambar 2.7).

Pendekatan SOA diterapkan pada tahapan desain arsitektur. Hal ini akan

mempengaruhi desain arsitektur baik dari sisi sistem informasi maupun dari sisi

teknologi dan infrastruktur yang digunakan. Desain SOA yang dibuat akan

dipengaruhi oleh layanan-layanan yang ada pada aplikasi (application services).

32


Pendahuluan

Prinsip-prinsip arsitektur

Requirements of architecture work

Arsitektur saat ini

Target Enterprise Architecture

TOGAF ADM

Application Services

SOA

Gambar 2.7 Theoretical framework

33 Universitas Indonesia

BAB 3

METODOLOGI PENELITIAN

Bab ini akan menjelaskan tentang metodologi penelitian yang digunakan dalam

membangun desain EA yang berbasis SOA. Adapun metodologi penelitian akan

berdasarkan pada TOGAF ADM framework dengan desain arsitektur sistem

berbasis pada SOA.

Tahapan-tahapan penelitian digambarkan pada gambar 3.1 dan penjelasan lebih

detail adalah sebagai berikut:

PengumpulanData

Pendahuluan

Arsitektur Bisnis

Arsitektur Teknologi

Arsitektur Sistem Informasi

Arsitektur Data

Arsitektur Aplikasi

Identifikasi Permasalahan

Solusi Permasalahan

Visi Arsitektur

Arsitektur Sistem Informasi

Arsitektur Data

Arsitektur Aplikasi

Arsitektur Teknologi

Peluang dan Solusi

Kesimpulan dan Saran

Ars

itekt

ur baseline

Arsitektur target

Gambar 3.1 Metodologi Penelitian

3.1 Pengumpulan data

Data penelitian adalah data kualitatif yang diperoleh dengan melakukan dua

metode pengumpulan data, yaitu:

34


o Data primer dengan wawancara

Wawancara akan dilakukan terhadap pihak tempat studi kasus dilakukan

dengan memperhatikan kewenangan dan kompetensi dari narasumber.

Wawancara akan dilakukan terhadap chief technical officer(CTO) dan juga

staf dari pihak aplikasi yang termasuk ke dalam batasan penelitian.

Wawancara juga dilakuan terhadap klien dari Asyst sebagai pihak airline

yang menggunakan jasa Asyst. Hal ini diperlukan karena tujuan yang juga

ingin dijawab adalah bagaimana enterprise architecture yang dapat

mengakomodir bisnis inti airline.

o Data sekunder dengan dokumen terkait

Pengumpulan data sekunder adalah berupa dokumen yang terkait dengan

batasan penelitian seperti dokumen katalog layanan, portofolio aplikasi,

dokumen aplikasi terkait dan lain-lain.

3.2 Pendahuluan

Pada pendahuluan didefinisikan hal-hal sebagai berikut:

3.2.1 Requirements for architecture work

Requirements for architecture work mencakup beberapa hal antara lain yaitu:

1. Kebutuhan bisnis. Mengidentifikasi kebutuhan bisnis yang ada untuk

pengembangan enterprise architecture.

2. Arahan organisasi. Arahan organisasi sejalan dengan visi dan misi

organisasi.

3. Aspirasi kultural. Aspirasi kultural dapat disesuaikan dengan corporate

culture yang ada pada organisasi.

3.2.2 Menentukan prinsip-prinsip arsitektur

Prinsip-prinsip arsitektur yang ditetapkan harus sesuai dengan kebutuhan

arsitektur dari tempat studi kasus

3.2.3 Pemetaaan stakeholder

Pemetaan stakeholder akan mengidentifikasi stakeholder yang terlibat beserta

peran dan tanggung jawabnya.

35


3.3 Arsitektur Bisnis

Pada arsitektur bisnis dilakukan pemodelan operasional organisasi yang

merealisasikan strategi bisnis organisasi. Dalam hal ini pemodelan akan

berdasarkan arsitektur bisnis yang ada pada airline karena dalam hal ini Asyst

akan menyediakan solusi SI/TI bagi airline. Arsitektur bisnis yang dimodelkan

meliputi aktivitas dan proses yang ada dalam batasan penelitian.

3.4 Arsitektur sistem informasi

Arsitektur sistem informasi terdiri dari arsitektur data dan arsitektur aplikasi.

Secara umum arsitektur sistem informasi menggambarkan arsitekur bisnis dapat

dijalankan dengan sistem informasi yang ada.Arsitektur sistem informasi nantinya

akan dievaluasi kembali untuk dilakukan pengecekan terhadap kesuaian dengan

kebutuhan arsitektur.

3.4.1 Arsitektur data

Arsitektur data menggambarkan data yang dibutuhkan agar arsitektur bisnis dapat

dijalankan. Arsitektur data pada tahap awal lebih sebagai baseline untuk

kemudian pada iterasi kedua dikembangkan target arsitektur data sesuai dengan

kebutuhan arsitektur bisnis dan visi arsitektur.

3.4.2 Arsitektur aplikasi

Arsitektur aplikasi merupakan bagian dari arsitektur sistem informasi dan

menggambarkan sistem informasi yang ada agar arsitektur bisnis dapat berjalan.

Sebagai langkah awal maka didefinisikan arsitektur aplikasi sebagai baseline

untuk kemudian pada iterasi ke-2 dibentuk target arsitektur aplikasi.

3.5 Arsitektur teknologi

Arsitektur teknologi dibangun agar sistem informasi dan data yang telah

didefinisikan dapat memenuhi kebutuhan arsitektur. Pada iterasi pertama hanya

akan dibuat arsitektur teknologi sebagai baseline dengan mengambil kondisi saat

ini. Pada tahap selanjutnya di iterasi ke-2 akan didetailkan arsitektur teknologi

yang dapat mendukung target arsitektur.

36


3.6 Identifikasi permasalahan

Dalam membangun enterprise architecture akan digali permasalahan-permalahan

yang ada pada stakeholder. Hal ini juga sejalan dengan research question yang

ingin dijawab pada penelitian ini yaitu bagaimana enterprise architecture yang

dapat mengakomodir bisnis inti airline.

3.7 Solusi permasalahan

Dari permasalahan-permasalahan yang dapat diidentifikasi dari tiap-tiap

stakeholder maka dibuat solusi dari tiap-tiap permasalahan tersebut. Solusi

permasalahan dilakukan dengan langkah-langkah sebagai berikut:

1. Menetapkan permasalahan yang akan diatasi. Hal ini merujuk ke tahap

sebelumnya dari permasalahan-permasalahan yang ada pada stakeholder.

2. Menetapkan sasaran solusi. Sasaran solusi dibuat untuk mengatasi

permasalahan yang ada sebagai target solusi.

3. Menetapkan pola solusi. Dari sasaran solusi yang telah ditetapkan maka

dibuat pola solusi konkrit untuk mengatasi permasalahan yang ada.

4. Menetapkan solusi SI/TI. Dari pola solusi yang telah ditetapkan,

diidentifikasi solusi SI/TI-nya.

Pola solusi yang telah dibuat juga harus memperhatikan dan sesuai dengan

prinsip-prinsip arsitektur yang telah ditetapkan. Dengan demikian juga akan

dilihat prinsip-prinsip arsitektur yang melandasi pola solusi yang ada.

3.8 Visi arsitektur

Langkah selanjutnya adalah visi arsitektur. Dalam visi arsitektur akan

didefinisikan diagram konsep solusi sebagai gambaran umum dari arsitektur

target. Diagram konsep solusi yang dibangun sebagai visi arsitektur akan

berdasarkan kondisi saat ini dan bertujuan mengatasi permasalahan-permasalahan

yang ada agar didapat arsitektur yang sesuai dengan kebutuhan.

3.9 Arsitektur sistem informasi

Arsitektur sistem informasi yang ada pada tahap kedua adalah arsitektur sistem

informasi sebagai target. Hal ini berdasarkan arsitektur baseline dengan

mengakomodir pola solusi yang ada.

37


3.9.1 Arsitektur data

Sebagai bagian dari arsitektur sistem informasi, maka arsitektur data target akan

dibuat agar kebutuhan arsitektur target dapat terpenuhi. Dengan arsitektur data

yang dibuat pada iterasi 1 sebagai baseline dan melihat pola solusi yang ada maka

akan didefinisikan target arsitektur data.

3.9.2 Arsitektur aplikasi

Arsitektur aplikasi pada iterasi ke-2 akan mengakomodir pola solusi yang ada.

Berdasarkan arsitektur aplikasi baseline dan pola solusi maka hasil akhir dari

arsitektur aplikasi adalah arsitektur aplikasi target.

3.10 Arsitektur Teknologi

Arsitektur teknologi pada iterasi ke-2 dibuat agar apa yang telah di-desain pada

tahap sebelumnya dapat diaplikasikan dan mewujudkan apa yang terdapat pada

visi arsitektur. Arsitektur teknologi terdiri dari beberapa tahap sebagai berikut:

1. Landscape aplikasi

Landscape aplikasi menggambarkan hubungan kedekatan antar aplikasi.

Dalam landscape aplikasi juga digambarkan hal-hal yang dipersyaratkan oleh

prinsip-prinsip arsitektur.

2. Perspektif arsitektur

Dalam perspektif arsitektur akan digambarkan hubungan antara landscape

aplikasi dengan TOGAF technical reference model (TRM).

3. Arsitektur gabungan

Arsitektur gabungan adalah gabungan dari landscape aplikasi dan TRM.

Dalam hal ini aplikasi infrastruktur dan hal-hal yang mendukung prinsip-

prinsip arsitektur sudah didefinisikan.

4. Peta interoperabilitas

Peta interoperabilitas akan menggambarkan aliran informasi antar aplikasi.

5. Mekanisme integrasi

Mekanisme integrasi akan menjelaskan pola integrasi antar aplikasi.

6. Platform arsitektur teknologi

Platform arsitektur teknologi akan menggambarkan platform yang digunakan

sebagai landasan aplikasi.

38


7. Topologi infrastruktur

Topologi infrastruktur akan membahas topologi dari infrastruktur yang

digunakan untuk mendukung aplikasi.

3.11 Peluang dan solusi

Dalam tahap ini akan dilakukan analisis kesenjangan secara menyeluruh dimulai

dari tahap arsitektur bisnis sampai dengan tahap arsitektur teknologi. Dari analisis

kesenjangan akan didapatkan kebutuhan-kebutuhan untuk mencapai arsitektur

yang diusulkan dibandingkan dengan kondisi saat ini.

3.12 Kesimpulan dan saran

Kesimpulan yang didapat adalah evaluasi dari EA yang telah dihasilkan.

Kesimpulan juga mencakup evaluasi dari analisis kesenjangan dari keadaan

sebelumnya dibandingkan dengan kebutuhan untuk implementasi EA yang

dihasilkan dari penelitian.

Saran akan meliputi beberapa aspek yaitu dari sisi pengembangan EA untuk

batasan yang lebih luas, kemudian proses lanjutan dari EA yang dihasilkan seperti

studi penerimaan EA di organisasi dan proses tata kelola TI dalam rangka

penerapan EA.

39 Universitas Indonesia

BAB 4

PROFIL ORGANISASI

Bab ini menjelaskan tentang profil organisasi tempat studi kasus dilakukan. Profil

organisasi akan mencakup tentang sejarah singkat organisasi dilanjutkan dengan

visi dan misi organisasi. Selanjutnya akan dipaparkan tentang produk dan layanan

yang ada di organisasi yang ditujukan untuk pihak eskternal (klien).

4.1 Profil Asyst

PT Aero Systems Indonesia (Asyst) didirikan pada tahun 2005. Asyst telah

mengalami pergantian nama dan sebelumnya bernama PT Lufthansa Systems

Indonesia. Pada awalnya Asyst adalah perusahaan joint venture antara salah satu

maskapai penerbangan di Indonesia (PT XYZ) dengan pihak asing yang bergerak

di bidang penyedia layanan TI untuk airline. Komposisi saham awal adalah 51%

dimiliki oleh PT XYZ dan sisanya dimiliki oleh pemodal asing. Pada tahun 2009

terjadi perpindahan kepemilikan dan saham yang dimiliki oleh pemodal asing

ditransfer ke salah satu anak perusahaan PT XYZ sehingga Asyst resmi tergabung

ke dalam grup XYZ.

4.2 Visi dan Misi

Asyst mempunyai visi untuk menjadi nomor satu sebagai penyedia layanan TI

untuk industri transportasi dengan solusi TI yang komprehensif, terkemuka, dan

lengkap. Sedangkan misi dari Asyst adalah: 1) Membawa nilai tambah bagi PT

XYZ dan XYZ group; 2) Menyediakan layanan TI yang berkualitas dan efisien

dan, 3) Menyediakan solusi TI dengan portofolio yang lengkap. Asyst juga

mempunyai corporate culture yang disebut dengan Get IT On yang dapat

dijabarkan sebagai berikut:

• Integrity: bertindak dengan cara yang konsis

UNIVERSITAS INDONESIA PERANCANGAN ENTERPRISE...

Documents

Transcript of UNIVERSITAS INDONESIA PERANCANGAN ENTERPRISE...

Agung Baskoro

Modul Sistem Informasi Enterprise

Enterprise 8000X (E8X)

Tugas Arsitektur Enterprise

Pm. No. 77 Tahun 2011 - Tanggung Jawab Airline

Pengantar Enterprise Resource Planning

ppt anak baskoro

Tutorial Deep Freeze Enterprise

YUWANA BASKORO 30406781

Baskoro Tedjo

BUKU Enterprise CAS

Metoda Gravitasi Kelautan Baskoro 01(1)

Penerapan Enterprise Resource Planning

PENGANTAR Software Enterprise

Perancangan Arsitektur Enterprise

Ismail Nasaruddin Abdul Wahab v Malaysia Airline System Bhd & Anor

Enterprise resources planning

Ise "Integrated System Enterprise"

ERP (Enterprise Resource Planning) - BLOG DOSEN · ERP (Enterprise Resource Planning) ERP (Enterprise Resource Planningi) atau sering jugadisebut Perencanaan Sumber Daya Perusahaan

Enterprise information system